Re: Question about "unit address format error" of DTC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux