linux-kernel - Re: [PATCH V2 1/2] dt-bindings: syscon: Add syscon-names to refer to syscon easily

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: <CAK8P3a3_r6z6Qk133=4gUzJ0rYmMH7sDDqpEF8ZVXS_bc3OtkQ@mail.gmail.com>
Date:   Wed, 4 Dec 2019 18:00:17 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Rob Herring <robh@...nel.org>
Cc:     Orson Zhai <orson.zhai@...soc.com>,
        Lee Jones <lee.jones@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        DTML <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kevin.tang@...soc.com, baolin.wang@...soc.com,
        Chunyan Zhang <chunyan.zhang@...soc.com>
Subject: Re: [PATCH V2 1/2] dt-bindings: syscon: Add syscon-names to refer to
 syscon easily

On Wed, Dec 4, 2019 at 5:38 PM Rob Herring <robh@...nel.org> wrote:
> On Wed, Nov 20, 2019 at 11:41:47PM +0800, Orson Zhai wrote:
> > Make life easier when syscon consumer want to access multiple syscon
> > nodes with dozens of items.
> > Add syscon-names and relative properties to help to manage different
> > cases when accessing more than one syscon node even with arguments.
> >
> > Signed-off-by: Orson Zhai <orson.zhai@...soc.com>
> > ---
> >  .../devicetree/bindings/mfd/syscon.txt        | 43 +++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt b/Documentation/devicetree/bindings/mfd/syscon.txt
> > index 25d9e9c2fd53..4c7bdb74bb0a 100644
> > --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> > +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> > @@ -30,3 +30,46 @@ hwlock1: hwspinlock@...00000 {
> >         reg = <0x40500000 0x1000>;
> >         #hwlock-cells = <1>;
> >  };
> > +
> > +
> > +
> > +==Syscon Name==
> > +
> > +Syscon name is a helper to be used in consumer nodes who refer to system
> > +controller node. It provides a way to refer to syscon node by names with
> > +phandle args in syscon consumer node. It will help people who have a lot
> > +of syscon references to be managed. It is not a must feature and has no
> > +effect to syscon node itself at all.
> > +
> > +Required properties:
> > +- syscons: List of phandles and any number of arguments if needed. Arguments
> > +  is specific to differnet vendors and its usage should be described at each
> > +  vendor's bindings. For example: In Unisoc SoCs, the 1st arg will be treated
> > +  as register address offset and the 2nd is bit mask.
> > +
> > +- syscon-names:        List of syscon node name strings sorted in the same order as
> > +  what it represents in property syscons.
> > +
> > +Optional property:
> > +- #.*-cells: Represents the number of arguments in single phandle in syscons
> > +  list. ".*" is vendor specific. If this property is not set, default value
> > +  will be 0.
>
> This breaks the normal pattern of how '#.*-cells' works. While Arnd
> suggests removing it, I don't think that works well either with having a
> generic 'syscons' property. That means every syscon in a system has to
> have the same number of cells.
>
> I don't really want to see syscon binding expanded. Really, I'd like
> 'syscon' to go away. It's nothing more than a flag to create a regmap.

Not expanding the syscon binding is the point about not having a #*-cells:
In the examples that Orson listed, the cell count would always be
specific to the user of the syscon regmap, and not interpreted by the
syscon itself.

> I think it is better to keep the property names specific to exactly what
> the functionality is for each syscon phandle rather than a generic
> binding.
>
> What are the eamples of where you want to use this?

I think generally speaking this would be useful for random registers that
logically belong to one device but are grouped with other unrelated
registers in a syscon, and that are in a different register offset for
each chip that has them. Using named properties instead of a list
of phandle/arg tuples with names is clearly a simpler alternative
and more like we do it today, but I can also see some API simplification
with Orson's patch without the binding getting out of hand.

> Keep in mind that
> this sort of connection should *only* be used for things that have no
> other binding and kernel subsystem.

+1

       Arnd