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] [thread-next>] [day] [month] [year] [list]

Message-ID: <56F0C375.1030907@nvidia.com>
Date:	Tue, 22 Mar 2016 13:00:53 +0900
From:	Alexandre Courbot <acourbot@...dia.com>
To:	Rob Herring <robh@...nel.org>, Alexandre Courbot <gnurou@...il.com>
CC:	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 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?

Thanks,
Alex.