linux-kernel - Re: [PATCH anybus v4 6/7] dt-bindings: anybuss-host: document devicetree binding

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]

Message-ID: <CAL_JsqLEDvs0Ktr2aoyS9-aCeybjHFcVv6L+fQMsvd8Hy88ong@mail.gmail.com>
Date:   Thu, 29 Nov 2018 19:39:01 -0600
From:   Rob Herring <robh@...nel.org>
To:     Sven Van Asbroeck <thesven73@...il.com>
Cc:     Sven Van Asbroeck <svendev@...x.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Andreas Färber <afaerber@...e.de>,
        Thierry Reding <treding@...dia.com>,
        David Lechner <david@...hnology.com>,
        Noralf Trønnes <noralf@...nnes.org>,
        Johan Hovold <johan@...nel.org>,
        Michal Simek <monstr@...str.eu>,
        Michal Vokáč <michal.vokac@...ft.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        John Garry <john.garry@...wei.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Robin Murphy <robin.murphy@....com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Sebastien Bourdelin <sebastien.bourdelin@...oirfairelinux.com>,
        Icenowy Zheng <icenowy@...c.io>,
        Stuart Yoder <stuyoder@...il.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH anybus v4 6/7] dt-bindings: anybuss-host: document
 devicetree binding

On Thu, Nov 29, 2018 at 2:59 PM Sven Van Asbroeck <thesven73@...il.com> wrote:
>
> Rob,
>
> Eliminating the 'compatible' property for the anybus gives me an interesting
> devicetree problem.
>
> The imx-weim code naively loops through all subnodes, applying timing settings
> to the CS in the first reg entry.
> In the example below, WEIM CS0 is programmed with the settings in
> fsl,weim-cs-timing, because the CS part of reg is 0:
>
>
> weim: weim@...8000 {
>         compatible = "fsl,imx6q-weim";
>         reg = <0x021b8000 0x4000>;
>         clocks = <&clks 196>;
>         #address-cells = <2>;
>         #size-cells = <1>;
>         ranges = <0 0 0x08000000 0x08000000>;
>         fsl,weim-cs-gpr = <&gpr>;
>
>         nor@0,0 {
>                 compatible = "cfi-flash";
>                 reg = <0 0 0x02000000>;
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 bank-width = <2>;
>                 fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
>                                 0x0000c000 0x1404a38e 0x00000000>;
>         };
> };
>
> The problem is that my 'anybus controller' hardware spans chip selects.
> It requires access to various memory areas. In the example below, CS1
> will not be programmed with timing settings:
>
> weim {
>         controller@0 {
>                 compatible = "arcx,anybus-controller";
>                 reg = <0 0 0x100>, <0 0x400000 0x800>, <1 0x400000 0x800>;
>                 fsl,weim-cs-timing = ...;
>         };
> };
>
> I've coped with this in the past by creating a 'dummy' subnode, without a
> compatible property. But it's ugly:
>
> weim {
>         controller@0 {
>                 compatible = "arcx,anybus-controller";
>                 reg = <0 0 0x100>, <0 0x400000 0x800>, <1 0x400000 0x800>;
>                 fsl,weim-cs-timing = ...;
>         };
>         dummy@1 { /* this works ! */
>                 reg = <1 0 0>;
>                 fsl,weim-cs-timing = ...;
>         };
> };
>
> Is there a better way? I've looked and looked, but can't find anything that's
> similar.
>
> Or should I extend the imx-weim driver to cope?

Yes, I think it should iterate on child reg properties not just nodes.
Hopefully, you don't need different timing for each CS though.

Rob