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

[Simon Glass]

Hi,

On Thu, 20 Nov 2025 at 14:29, Tom Rini <trini at konsulko.com> wrote:
>
> 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.

This seems fine to me. But please add a test, e.g. in test/dm/core.c

Regards,
Simon