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

Message-ID: <CAGngYiXFag-C9-0XvGxVVWs5AxL2qn0UhU2W1Ds9LE+BJYgvDQ@mail.gmail.com>
Date:   Thu, 29 Nov 2018 15:59:34 -0500
From:   Sven Van Asbroeck <thesven73@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Sven Van Asbroeck <svendev@...x.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Lee Jones <lee.jones@...aro.org>, mark.rutland@....com,
        Andreas Färber <afaerber@...e.de>,
        treding@...dia.com, David Lechner <david@...hnology.com>,
        noralf@...nnes.org, johan@...nel.org,
        Michal Simek <monstr@...str.eu>, michal.vokac@...ft.com,
        Arnd Bergmann <arnd@...db.de>, gregkh@...uxfoundation.org,
        john.garry@...wei.com, geert+renesas@...der.be,
        robin.murphy@....com, paul.gortmaker@...driver.com,
        sebastien.bourdelin@...oirfairelinux.com, icenowy@...c.io,
        Stuart Yoder <stuyoder@...il.com>, maxime.ripard@...tlin.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH anybus v4 6/7] dt-bindings: anybuss-host: document
 devicetree binding

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?