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

Attachment: signature.asc
Description: PGP signature

Reply via email to