[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b508d80f-71a9-c34a-bbb2-c0ced3f6f399@ilande.co.uk>
Date: Wed, 5 Sep 2018 17:01:52 +0100
From: Mark Cave-Ayland <mark.cave-ayland@...nde.co.uk>
To: Rob Herring <robh@...nel.org>
Cc: Frank Rowand <frowand.list@...il.com>, devicetree@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>, sparclinux@...r.kernel.org
Subject: Re: [PATCH 3/3] of: make default address and size cells sizes private
On 05/09/18 13:12, Rob Herring wrote:
> On Tue, Sep 4, 2018 at 11:59 PM Mark Cave-Ayland
> <mark.cave-ayland@...nde.co.uk> wrote:
>>
>> On 05/09/18 02:55, Frank Rowand wrote:
>>
>>> On 08/30/18 12:05, Rob Herring wrote:
>>>> Only some old OpenFirmware implementations rely on default sizes. Any
>>>> FDT and modern implementation should have explicit properties. Make the
>>>> OF_ROOT_NODE_*_CELLS_DEFAULT defines private so we don't get any outside
>>>> users.
>>>>
>>>> This also gets us one step closer to removing the asm/prom.h dependency on
>>>> Sparc.
>>
>> Just for the record: you say "any FDT and modern implementation should
>> have explicit properties", however the default values of these
>> properties when missing are clearly defined in the IEEE-1275
>> specification (Annex A):
>
> The spec may define defaults, but best practice is to be explicit. For
> FDT, dtc doesn't allow defaults (and never has). No arch added in the
> last 10 years has relied on the defaults.
>
>> "#address-cells"
>> Standard property name to define the package’s address format.
>> ...
>> In a package with a "decode-unit" method, a missing "#address-cells"
>> property signifies that the number of
>> address cells is two.
>
> So only Sparc is compliant as the default for everyone else is 1.
>
>> "#size-cells"
>> Standard property name to define the package’s address size format.
>> ...
>> A missing "#size-cells" property signifies the default value of one.
>>
>> I can't speak for FDT but it isn't completely unreasonable for a guest
>> parsing a DT without these properties to assume these default values.
>
> I'm not removing the defaults. Just not allowing for code outside of
> drivers/of/ to use the defaults.
Got it - if dtc requires explicit properties, then I agree there should
be no issues with this patch. Sorry for the noise.
ATB,
Mark.
Powered by blists - more mailing lists