[Uboot-stm32] [PATCH v1 2/2] cmd: bind: allow to bind driver with driver data

[Patrice CHOTARD]

Hi Simon

On 4/22/20 6:32 PM, Simon Glass wrote:
> Hi Patrice,
>
> On Wed, 22 Apr 2020 at 02:13, Patrice CHOTARD <patrice.chotard at st.com> wrote:
>>
>> On 4/21/20 7:36 PM, Simon Glass wrote:
>>> Hi Patrice,
>>>
>>> On Tue, 21 Apr 2020 at 08:09, Patrice Chotard <patrice.chotard at st.com> wrote:
>>>> Initial implementation invokes device_bind_with_driver_data()
>>>> with driver_data parameter equal to 0.
>>>> For driver with driver data, the bind command can't bind
>>>> correctly this driver or even worse causes data abort.
>>>>
>>>> Add find_udevice_id() to parse the driver's of_match list
>>>> and return the entry corresponding to the driver compatible string.
>>>> This allows to get access to driver_data and to use it as
>>>> parameters of device_bind_with_driver_data().
>>>>
>>>> Signed-off-by: Patrice Chotard <patrice.chotard at st.com>
>>>> Cc: Jean-Jacques Hiblot <jjhiblot at ti.com>
>>>>
>>>> ---
>>>>
>>>>  cmd/bind.c | 29 ++++++++++++++++++++++++++++-
>>>>  1 file changed, 28 insertions(+), 1 deletion(-)
>>>>
>>> The thing I don't quite get here is why the driver name needs to be
>>> specified. If the device tree node is present, and it has a compatible
>> Sorry, i didn't get your point when you said "why the driver name needs to be specified"
> It's just that I don't understand it at all. If the compatible string
> is available, why not use lists_bind_fdt()?

Ok i got it !  Sorry i was too much focused on device_bind_with_driver_data() usage ;-)

Yes you are right, list_bind_fdt() must be used here to solve the issue.

I will repost with lists_bind_fdt() usage .

>
>> Which part of this patch do you made reference to ?
> The whole thing, because I just don't understand the bind command.
>
>>> string, can't DM find the driver and bind a device automatically?
>>>
>>> Also, is there any docs for this command? It would be good to add to
>> Is what in cmd/bind.c not enough ?
> I am just confused here. You obviously have a use case in mind, but
> the help below is not sufficient to understand what is going on. As I
> said, if you have a device-tree node you can find the driver. I am
> just not sure what this is for.
Sorry, i was not clear enough in the reason of this patch.

For debug purpose on STM32MP1 platform, i needed to unbind/bind the ethernet driver (dwc_eth_qos.c).

This driver is using driver data as shown below:

static const struct udevice_id eqos_ids[] = {
    {
        .compatible = "nvidia,tegra186-eqos",
        .data = (ulong)&eqos_tegra186_config
    },
    {
        .compatible = "snps,dwmac-4.20a",
        .data = (ulong)&eqos_stm32_config
    },

    { }
};

After unbinding/binding this driver and probing it (with the dhcp command ), we got a prefetch abort as below:

STM32MP> unbind eth ethernet at 5800a000
STM32MP> bind /soc/ethernet at 5800a000 eth_eqos
STM32MP> dhcp
prefetch abort
pc : [<4310801c>]          lr : [<ffc8f4ad>]
reloc pc : [<035ba01c>]    lr : [<c01414ad>]
sp : fdaf19b0  ip : ffcea83c     fp : 00000001
r10: ffcfd4a0  r9 : fdaffed0     r8 : 00000000
r7 : ffcff304  r6 : fdc63220     r5 : 00000000  r4 : fdc5b108
r3 : 43108020  r2 : 00003d39     r1 : ffcea544  r0 : fdc63220
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Code: data abort
pc : [<ffc4f9c0>]          lr : [<ffc4f9ad>]
reloc pc : [<c01019c0>]    lr : [<c01019ad>]
sp : fdaf18b8  ip : 00000000     fp : 00000001
r10: ffcd69b2  r9 : fdaffed0     r8 : ffcd69aa
r7 : 00000000  r6 : 00000008     r5 : 4310801c  r4 : fffffffc
r3 : 00000001  r2 : 00000028     r1 : 00000000  r0 : 00000006
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32 (T)
Code: 2f00 d1e9 2c00 dce9 (f855) 2024
Resetting CPU ...

This was due to the fact that, currently bind command is passing 0 as driver_data parameter to device_bind_with_driver_data()

which was not correct and can't allow the dwc_eth_qos driver to be probed with its correct driver data.

Patrice


> It could really use a short document as I said, to explain the uses of
> this command and what it does in a bit more detail.

>
>>
>> U_BOOT_CMD(
>>     bind,    4,    0,    do_bind_unbind,
>>     "Bind a device to a driver",
>>     "<node path> <driver>\n"
>>     "bind <class> <index> <driver>\n"
>> );
>>
>> U_BOOT_CMD(
>>     unbind,    4,    0,    do_bind_unbind,
>>     "Unbind a device from a driver",
>>     "<node path>\n"
>>     "unbind <class> <index>\n"
>>     "unbind <class> <index> <driver>\n"
>> );
>>
>>
>>> doc/driver-model and also add a simple test.
>> Ok i will add an additionnal test to test/py/tests/test_bind.py
> OK thanks.
>
> Regards,
> SImon
> _______________________________________________
> Uboot-stm32 mailing list
> Uboot-stm32 at st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32