linux-kernel - Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller

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]

Date:   Tue, 6 Sep 2016 11:32:14 +0100
From:   Jon Hunter <jonathanh@...dia.com>
To:     Mirza Krak <mirza.krak@...il.com>, Rob Herring <robh@...nel.org>
CC:     Stephen Warren <swarren@...dotorg.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Alexandre Courbot <gnurou@...il.com>, <linux@...linux.org.uk>,
        <pdeschrijver@...dia.com>, Prashant Gaikwad <pgaikwad@...dia.com>,
        Michael Turquette <mturquette@...libre.com>,
        <sboyd@...eaurora.org>, <mark.rutland@....com>,
        <devicetree@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-clk@...r.kernel.org>
Subject: Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller


On 31/08/16 12:22, Mirza Krak wrote:
> 2016-08-30 19:06 GMT+02:00 Rob Herring <robh@...nel.org>:

...

>>>                  nvidia,snor-cs = <4>;
>>
>> NAK, no custom CS properties.

Ok, so ...

> gmi@...90000 {
>         compatible = "nvidia,tegra20-gmi";
>         reg = <0x70009000 0x1000>;
>         #address-cells = <2>;
>         #size-cells = <1>;
>         clocks = <&tegra_car TEGRA20_CLK_NOR>;
>         clock-names = "gmi";
>         resets = <&tegra_car 42>;
>         reset-names = "gmi";
>         ranges = <4 0 0xd0000000 0xfffffff>;
> 
>         status = "okay";
> 
>         bus@4,0 {
>                 compatible = "simple-bus";
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 ranges = <0 4 0 0x40000>;
> 
>                 nvidia,snor-mux-mode;
>                 nvidia,snor-adv-inv;
> 
>                 can@0 {
>                         reg = <0 0x100>;
>                         ...
>                 };
> 
>                 can@...00 {
>                         reg = <0x40000 0x100>;
>                         ...
>                 };
>         };
> };
> 
> Have I understood you correct?
> 
> Also wanted to verify the example case where you only have on device
> connected to one CS#, from what I see in other implementations it
> seems OK to put the CS# in the reg property in that case. Is this
> correct?
> 
> Example with one SJA1000 CAN controller connected to the GMI bus
> on CS4:
> 
> gmi@...90000 {
>         compatible = "nvidia,tegra20-gmi";
>         reg = <0x70009000 0x1000>;
>         #address-cells = <2>;
>         #size-cells = <1>;
>         clocks = <&tegra_car TEGRA20_CLK_NOR>;
>         clock-names = "gmi";
>         resets = <&tegra_car 42>;
>         reset-names = "gmi";
>         ranges = <4 0 0xd0000000 0xfffffff>;
> 
>         status = "okay";
> 
>         can@4,0 {
>                 reg = <4 0 0x100>;
>                 nvidia,snor-mux-mode;
>                 nvidia,snor-adv-inv;
>                 ...
>         };
> };
> 
> Jon, to be able to handle both cases in the driver we would first
> attempt to decode the CS# from the ranges property, and fallback to
> reg property if no ranges are defined. Does that sound reasonable?

Given the above examples that may be supported, is there a
better/simpler way to extract the CS# than what Mirza is proposing? For
example, from the node-name unit-address?

Cheers
Jon

-- 
nvpublic