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. -- Tom
signature.asc
Description: PGP signature
