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

[Markus Schneider-Pargmann]

Hi Marek,

On Fri Nov 21, 2025 at 12:23 AM CET, Marek Vasut wrote:
> 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.

Thanks for the pointer, this is using the exact same mechanism as I want
to use. Is this tested and works? Because if I look into the current
code for probing and binding:

	/*
	 * Walk through the compatible string list, attempting to match each
	 * compatible string in order such that we match in order of priority
	 * from the first string to the last.
	 */
	for (i = 0; i < compat_length; i += strlen(compat) + 1) {
		compat = compat_list + i;
    ...
		for (entry = driver; entry != driver + n_ents; entry++) {
      ...
			ret = driver_check_compatible(entry->of_match, &id,
						      compat);
			if (!ret)
				break;
		}
		if (entry == driver + n_ents)
			continue;

		...
		ret = device_bind_with_driver_data(parent, entry, name,
						   id ? id->data : 0, node,
						   &dev);
		if (ret == -ENODEV) {
			log_debug("Driver '%s' refuses to bind\n", entry->name);
			continue;
		}
		...
		break;
	}

So if I understand this correctly, the returned -ENODEV will cause a
continue in the outer loop which iterates through the device compatible
string list, jumping to the next compatible of the device if any is
given. It does not continue in the inner for loop that iterates the
drivers.

Best
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 289 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251121/bb204a45/attachment.sig>