[PATCH 08/15] dm: core: Support multiple drivers with same compatibles
Markus Schneider-Pargmann
msp at baylibre.com
Thu Nov 20 11:42:53 CET 2025
Hi Tom,
On Tue Nov 18, 2025 at 3:08 PM CET, Tom Rini wrote:
> On Tue, Nov 18, 2025 at 11:40:28AM +0100, Markus Schneider-Pargmann (TI.com) wrote:
>
>> Currently once a driver matched the compatible string of a device, other
>> drivers are ignored. If the first matching driver returns -ENODEV, no
>> other possibly matching drivers are iterated with that compatible of the
>> device. Instead the next compatible in the list of compatibles is
>> selected, assuming only one driver matches one compatible at a time.
>>
>> To be able to use the bind function to return -ENODEV and continue
>> matching other drivers with the same compatible, move the for loop a bit
>> to continue the for loop after -ENODEV was returned.
>>
>> This is required for ti-musb-host and ti-musb-peripheral which both
>> match on the same device but differ based on the dr_mode DT property.
>> Depending on this property, the driver is either UCLASS_USB or
>> UCLASS_USB_GADGET_GENERIc. By checking the DT property in the bind
>> function and returning -ENODEV the other driver can probe instead.
>>
>> Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp at baylibre.com>
>> ---
>> drivers/core/lists.c | 62 +++++++++++++++++++++++++++-------------------------
>> 1 file changed, 32 insertions(+), 30 deletions(-)
>
> This seems like a big generic change (with potential performance
> impact?) for a rather specific case. I assume the linux kernel simply
> doesn't have this issue by handling OTG differently. So is there some
> other way we can handle this here?
I didn't find a nice way to do this differently. I did have a different
idea to do this by overriding the compatible of the parent node of the
usb devices. But I didn't like that idea so I proposed this solution.
But I would be happy to hear about other ideas.
For the performance part: I don't think this reduces performance in most
cases. This will only add overhead through additional iterations if a
driver with a matching compatible has a bind function that returns
-ENODEV. In all other cases this should not add any iterations to the
loops. Grepping through the code a bit, I don't think returning -ENODEV
in bind() is widely used at the moment.
Best
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 289 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251120/8c82747e/attachment.sig>
More information about the U-Boot
mailing list