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: <CALw8SCWtTvWGmKru2MX7T7sFpoUpD-V400+w2nPkxaFB5WUKSA@mail.gmail.com>
Date:   Fri, 26 Aug 2016 06:53:59 +0200
From:   Mirza Krak <mirza.krak@...il.com>
To:     Jon Hunter <jonathanh@...dia.com>
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, robh+dt@...nel.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

2016-08-24 21:54 GMT+02:00 Mirza Krak <mirza.krak@...il.com>:
> 2016-08-24 17:56 GMT+02:00 Jon Hunter <jonathanh@...dia.com>:
> +
>>> +Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the
>>> +controllers with a simple-bus node since they are all connected to the same
>>> +chip-select (CS4), in this example external address decoding is provided:
>>> +
>>> +gmi@...90000 {
>>> +     compatible = "nvidia,tegra20-gmi";
>>> +     reg = <0x70009000 0x1000>;
>>> +     #address-cells = <1>;
>>> +     #size-cells = <1>;
>>> +     clocks = <&tegra_car TEGRA20_CLK_NOR>;
>>> +     clock-names = "gmi";
>>> +     resets = <&tegra_car 42>;
>>> +     reset-names = "gmi";
>>> +     ranges = <4 0x48000000 0x7ffffff>;
>>> +
>>> +     status = "disabled";
>>> +
>>> +     bus@4 {
>>> +             compatible = "simple-bus";
>>> +             reg = <4>;
>>> +             #address-cells = <1>;
>>> +             #size-cells = <1>;
>>> +             ranges = <0 4 0x40100>;
>>
>> Does this work? I tried to add an example like this and I got ...
>>
>> Warning (reg_format): "reg" property in /gmi@...09000/bus@4 has invalid
>> length (4 bytes) (#address-cells == 1, #size-cells == 1)
>
> Shoot, to get rid of the warning it should be
>
> reg = <4 0 >;
>
> But it works either way.
>
>>
>> I am wondering if we should just following the arm,pl172 example and
>> have ...
>>
>>         cs4 {
>>                 compatible = "simple-bus";
>>                 #address-cells = <1>;
>>                 #size-cells = <1>;
>>                 ranges;
>>
>>                 nvidia,snor-cs = <4>;
>>                 nvidia,snor-mux-mode;
>>                 nvidia,snor-adv-inv;
>>
>>                 can@0 {
>>                         reg = <0 0x100>;
>>                         ...
>>                 };
>>
>>                 ...
>>         };
>>
>
> That means to go back to V1 really (almost :)). Which I do not mind.
> Will give it a test run.
>
> But I am a little hesitant if will be any better/cleaner. In your example above:
>
> can@0 {
>          reg = <0 0x100>;
>          ...
> };
>
> Would this really translate correctly? In the pl172 example they have
> multiple ranges and address with "flash@0,0" which a range defined in
> parent node. "can@0" does not have valid match in parent node in our
> example. So I probably need add some more logic for it to properly
> translate.
>
> I have an idea which is following:
>
> gmi@...90000 {
>          status = "okay";
>          #address-cells = <2>;
>          #size-cells = <1>;
>          ranges = <4 0 0x48000000 0x00040000>;
>
>          cs4 {
>                  compatible = "simple-bus";
>                  #address-cells = <2>;
>                  #size-cells = <1>;
>                  ranges;
>
>                  nvidia,snor-cs = <4>;
>                  nvidia,snor-mux-mode;
>                  nvidia,snor-adv-inv;
>
>                  can@0 {
>                          compatible = "nxp,sja1000";
>                          reg = <4 0 0x100>;
>                          ...
>                  };
>
>
>                  can@...00 {
>                          compatible = "nxp,sja1000";
>                          reg = <4 0x40000 0x100>;
>                          ...
>                  };
>          };
> };
>
> Do not know if above will work at all (not able to test at current
> location), anyway I will play around with it some more and get back to
> you.

Gave above a test run and it works like a charm. Are we happy with that?

Best Regards
Mirza

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ