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

[Markus Schneider-Pargmann]

Hi Marek,

On Fri Nov 21, 2025 at 3:43 PM CET, Marek Vasut wrote:
> On 11/21/25 9:28 AM, Markus Schneider-Pargmann wrote:
>
> Hello Markus,
>
> [...]
>
>> 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.
>
> I check the HF one regularly, the SPI is a bit less accessible, but the 
> binding code didn't change for a while so I don't think it should be broken.
>
> I wonder if the RPC works by accident, and one driver matches on SoC 
> compatible and the other on fallback compatible. In that case, I think 
> the bind code should be patched to try other drivers and check whether 
> they might also be compatible in case the bind returns -ENODEV, indeed.

I rechecked the compatible lists, but they do not have two different
matching compatibles, mostly just one matches to a driver.

But I think I may know why there was no issue with this. Grepping the
config symbols it seems there is no config in which both drivers are
actually enabled at the same time:

  configs/renesas_rcar64.config:CONFIG_RENESAS_RPC_SPI=y
  configs/renesas_rza1.config:CONFIG_RENESAS_RPC_SPI=y

  configs/r8a77990_ebisu_defconfig:CONFIG_RENESAS_RPC_HF=y
  configs/r8a77995_draak_defconfig:CONFIG_RENESAS_RPC_HF=y
  configs/rcar3_salvator-x_defconfig:CONFIG_RENESAS_RPC_HF=y
  configs/rcar3_ulcb_defconfig:CONFIG_RENESAS_RPC_HF=y

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/67c6db01/attachment.sig>