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

[Marek Vasut]

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.