[PATCH 08/15] dm: core: Support multiple drivers with same compatibles

[Tom Rini]

On Thu, Nov 20, 2025 at 11:42:53AM +0100, Markus Schneider-Pargmann wrote:
> 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.

OK, thanks. I guess barring someone else having a better idea, we can
try this direction.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251120/dadb944f/attachment.sig>