Hi Rob,
2017-11-10 3:04 GMT+09:00 Rob Herring <robh+dt@xxxxxxxxxx>:
> On Thu, Nov 9, 2017 at 9:09 AM, Masahiro Yamada
> <yamada.masahiro@xxxxxxxxxxxxx> wrote:
>> Hi Rob,
>>
>> 2017-11-09 23:15 GMT+09:00 Rob Herring <robh+dt@xxxxxxxxxx>:
>>> On Thu, Nov 9, 2017 at 6:14 AM, Masahiro Yamada
>>> <yamada.masahiro@xxxxxxxxxxxxx> wrote:
>>>> Hi Rob, David,
>>>>
>>>>
>>>> I am just curious about a DTC warning.
>>>>
>>>>
>>>> For example,
>>>>
>>>> soc {
>>>> compatible = "simple-bus";
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> ranges;
>>>>
>>>> foo@11111111 {
>>>> compatible = "foo";
>>>> reg = <0x54006800 0x40>;
>>>> };
>>>> };
>>>>
>>>> This emits the following warning.
>>>>
>>>> Warning (simple_bus_reg): Node /soc/foo@11111111 simple-bus unit
>>>> address format error, expected "54006800"
>>>>
>>>>
>>>> But, if I replace "simple-bus" with "simple-mfd",
>>>> DTC is completely happy.
>>>
>>> We could probably add simple-mfd to the check. Though, if you have
>>> addresses, then you probably should use simple-bus. I'm not a bit fan
>>> of simple-mfd in general.
>>>
>>>> Why is this check limited to simple bus / PCI bus?
>>>
>>> Because bus types are free to define their own unit address format to
>>> some extent.
>>>
>>>> For other cases, is mismatching @<address> allowed?
>>>
>>> No, but it is not checked. Most other cases such as I2C and SPI buses
>>> aren't checked because we have no generic way to key off of them. We
>>> need schema data with compatible strings of those bus controllers to
>>> do the checking.
>>>
>>> Any bus type needs to define its unit address format. Generally, it
>>> must match data fields in reg property and distinct fields are
>>> separated by commas.
>>>
>>
>> Thanks.
>> I had a more specific example I wanted to ask,
>> but your last comment "distinct fields are separated by commas"
>> probably answered the question.
>>
>>
>> The following is an example of NVMEM data cells.
>> The generic binding is Documentation/devicetree/binding/nvmem/nvmem.txt
>>
>>
>> reg: specifies the offset in byte within the storage device.
>>
>> bits: Is pair of bit location and number of bits, which specifies offset
>> in bit and number of bits within the address range specified
>> by reg property.
>> Offset takes values from 0-7.
>>
>> So, it is possible to have multiple data cells
>> that share the same "reg".
>
> In hindsight, I think I'd do away with bits and just define that reg
> is the offset and size in bits. Maybe we did discuss that and I've
> just forgotten the reasons not to do that.
Yeah, I like the idea, but "in hindsight".
>>
>> @<reg-offset>,<bit-position>
>> was the idea in my mind, but I was not 100% sure.
>
> Yeah, this is fine. Bonus points if you write a check in dtc for it. I
> think we can match on #nvmem-cells in the parent node.
I have no idea when I can look into it.
I think most (all?) of DTC checks are from your contribution.
It would be appreciated if you care to it.
One idea for generic solution might be DTC checks:
- @* exactly matches to reg
or
- The first field of comma separated @*,*,... matches to reg
I do not know if other patterns exist.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
