linux-kernel - Re: [PATCH 1/2] dt-bindings: Add syscon-names support

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: <CAK8P3a23jcNgFErik1PFr=tG6n8kc8Pj9fARw47n=ou8t8iV+Q@mail.gmail.com>
Date:   Fri, 15 Nov 2019 10:33:30 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Orson Zhai <orson.zhai@...soc.com>
Cc:     Lee Jones <lee.jones@...aro.org>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        DTML <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        steven.tang@...soc.com
Subject: Re: [PATCH 1/2] dt-bindings: Add syscon-names support

On Thu, Nov 14, 2019 at 12:48 PM Orson Zhai <orson.zhai@...soc.com> wrote:
>
>
> Make life easier when syscon consumer want to access multiple syscon
> nodes.
> Add syscon-names and relative properties to help manage complicated
> cases when accessing more one syscon node.
>
> Signed-off-by: Orson Zhai <orson.zhai@...soc.com>

Hi Orson,

Can you explain why the number of cells in this binding is specific
to the syscon node rather than the node referencing it?

In most other bindings that follow the same scheme, the additional
arguments are interpreted by the subsystem that is being referenced,
but the syscon driver is just a simple driver with no subsystem and no
code to interpret those arguments.

The way would otherwise handle the example from your binding
would be with two separate properties in the display node, like

syscon-enable = <&ap_apb_regs 0x4 0xf00>;
syscon-power = <&aon_regs 0x8>;

in which case, the syscon driver does not need to know anything
about how it's being used, and the display driver is the one making
sense of the arguments according to its own binding.

I assume you have some good reason for introducing the other
approach, but I don't understand it from your submission.

       Arnd