linux-kernel - Re: [PATCH v1] spi: fix client driver breakages when using GPIO descriptors

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:   Mon, 16 Nov 2020 21:06:32 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Grant Likely <grant.likely@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Jonathan Cameron <jonathan.cameron@...wei.com>,
        Simon Han <z.han@...bus.com>, Lukas Wunner <lukas@...ner.de>,
        linux-spi <linux-spi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] spi: fix client driver breakages when using GPIO
 descriptors

On Wed, Nov 11, 2020 at 02:36:07PM +0100, Linus Walleij wrote:
> On Wed, Nov 11, 2020 at 1:33 PM Mark Brown <broonie@...nel.org> wrote:
> > On Wed, Nov 11, 2020 at 02:05:19AM +0100, Linus Walleij wrote:

> > This is not clear to me, most of these settings are things that are
> > constant for the device so it's not clear that they should be being set
> > by the device tree in the first place.

> This was added initially with some two properties
> in drivers/of/of_spi.c in 2008:
> commit 284b01897340974000bcc84de87a4e1becc8a83d
> "spi: Add OF binding support for SPI busses"

> This was around the time ARM was first starting to migrate
> to device tree, so I suppose it made sense to them/us back
> then.

That's from PowerPC days, not ARM, and frankly a lot of DT conversions
were just fairly mechanical conversions of what was in platform data to
DT so they may not have been especially considered.

> compatible-string. It was later that especially Rob pointed out that
> random properties on device nodes was overused and that simply
> knowing the compatible is often enough.

I've been pushing this since forever as well, as far as I remember it's
been a thing since we started doing this.

> I don't know if we ever formalized it, there is nowadays a rule akin to

> "if a property can be determined from the compatible-string, and if the
>  compatible-string is identifying the variant of the electronic component,
>  then do not add this property to the device tree description. Just
>  deduce it from the compatible-string, assign it with code to the device
>  model of the operating system and handle it inside the operating system."

> I think this, while clear and intuitive, wasn't at all clear and intuitive in
> the recent past.

I think the main push in the other direction has always been people who
want to not have to write a driver at all and put absolutely everything
into DT which has scaling issues :/

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)