linux-kernel - Re: [PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 22 Mar 2016 07:44:37 -0500
From:	Rob Herring <robh@...nel.org>
To:	Alexandre Courbot <acourbot@...dia.com>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU

On Mon, Mar 21, 2016 at 11:00 PM, Alexandre Courbot <acourbot@...dia.com> wrote:
> On 03/22/2016 10:41 AM, Rob Herring wrote:
>>
>> On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot <gnurou@...il.com>
>> wrote:
>>>
>>> On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring <robh@...nel.org> wrote:
>>>>
>>>> On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote:
>>>>>
>>>>> GM20B's definition is mostly similar to GK20A's, but requires an
>>>>> additional clock.
>>
>>
>> [...]
>>
>>>>>        gpu@0,57000000 {
>>>>>                compatible = "nvidia,gk20a";
>>>>> @@ -45,3 +49,22 @@ Example:
>>>>>                iommus = <&mc TEGRA_SWGROUP_GPU>;
>>>>>                status = "disabled";
>>>>>        };
>>>>> +
>>>>> +Example for GM20B:
>>>>> +
>>>>> +     gpu@0,57000000 {
>>>>
>>>>
>>>> Drop the comma and leading zero.
>>>
>>>
>>> Even though this is how it appears in the actual DT?
>>
>>
>> Yes, those will need to get fixed, too.
>
>
> Sorry, I just want to confirm that I understand why this needs to be fixed.
> The parent node has #address-cells = <2>, and the practice of specifying two
> cells in the node name is consistent with what I see in
> http://www.devicetree.org/Device_Tree_Usage.
>
> However in the device tree usage example one can interpret the two cells as
> being two different components of the address, whereas in our case we are
> using two cells because the address is 64-bit - hence we should specify it
> in the name as a single entity. Is this correct?

Exactly, commas are for separating distinct fields like chip select
and offset in the wiki example. A 64-bit address is a single field.

The other reason to fix it is dtc is going to start warning for this.

Rob