Hi, On Thu, 20 Nov 2025 at 14:29, Tom Rini <[email protected]> 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) <[email protected]> > > >> --- > > >> 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
