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

[Marek Vasut]

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) <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.

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.