On 11/20/25 10:29 PM, Tom Rini 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.
I didn't fully grok the discussion, so please pardon my ignorance. But
isn't this matching exactly the same problem that is already solved by
Renesas RPC drivers ?
drivers/mtd/renesas_rpc_hf.c
drivers/spi/renesas_rpc_spi.c
Look at rpc_hf_bind() and rpc_spi_bind() implementation there, which
selects which of the two drivers binds to the controller and which does not.
