Re: [PATCH 2/5] dt-bindings: pinctrl: brcm,ns-pinmux: extend example

["Rafał Miłecki" <zajec5@gmail.com>]

On 23.11.2021 08:38, Tony Lindgren wrote:
> 200* Rafał Miłecki <zajec5@gmail.com> [211118 13:30]:
>> @@ -83,6 +83,33 @@ examples:
>>           reg = <0x1800c1c0 0x24>;
>>           reg-names = "cru_gpio_control";
>>   
>> +        pins {
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +
>> +            pin@4 {
>> +                reg = <4>;
>> +                label = "i2c_scl";
>> +            };
>> +
>> +            pin@5 {
>> +                reg = <5>;
>> +                label = "i2c_sda";
>> +            };
>> +        };
> 
> The reg property should indicate the hardware offset from the device base
> address. The reg values above for 4 and 5 seem to be indexed instead :)
> Please update to use real register offsets from the 0x1800c1c0 base
> instead. If a reg offset + bit offset are needed, the #address-cells or
> #pinctrl-cells can be used.

It's true those are "reg"s are PINS indexes and not actual hw registers.
That concept of changing "reg" context is nothing new here however. It's
used in many other places.

Some examples:

1. net/mdio-mux.yaml
"reg" is used for "The sub-bus number" (not actual hw register)

2. usb/usb-device.yaml
"reg" is used for USB port index on USB hub

3. spi/spi-controller.yaml
"reg" is used for "Chip select used by the device."

4. mtd/partitions/partition.yaml
"reg" is used for "partition's offset and size within the flash"

Does it mean above "reg" usages are all incorrect and binding "reg" in
such way is deprecated? This is something totally new to me, can you
confirm that, please?


> The main problem using an index is that you need to keep it in sync
> between the dts and device driver. And if a new SoC variant adds an entry
> between the registers, you end up having to renumber the index.

I don't understand that part. That index ("reg" value in above example)
is actual PIN number. It's expected to match hw datasheets. Order
doesn't matter there.

If new hw revision adds PIN 2, I could just add pin@2 { ... };