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.
