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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ