linux-kernel - Re: [PATCH v4] dt-bindings: iio: accel: add binding documentation for ADIS16240

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:   Tue, 3 Dec 2019 16:51:54 +0000
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Mark Brown <broonie@...nel.org>
CC:     Jonathan Cameron <jic23@...nel.org>,
        "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>,
        "rodrigorsdc@...il.com" <rodrigorsdc@...il.com>,
        "Popa, Stefan Serban" <StefanSerban.Popa@...log.com>,
        "kernel-usp@...glegroups.com" <kernel-usp@...glegroups.com>,
        "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "pmeerw@...erw.net" <pmeerw@...erw.net>,
        "Hennerich, Michael" <Michael.Hennerich@...log.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "knaack.h@....de" <knaack.h@....de>
Subject: Re: [PATCH v4] dt-bindings: iio: accel: add binding documentation
 for ADIS16240

On Tue, 3 Dec 2019 16:38:50 +0000
Mark Brown <broonie@...nel.org> wrote:

> On Sun, Dec 01, 2019 at 11:40:32AM +0000, Jonathan Cameron wrote:
> 
> > +CC Mark as we probably need a more general view point on
> > the question of whether SPI mode should be enforced by binding
> > or in the driver.  
> 
> Not sure I see the question here, I think I was missing a bit of
> the conversation?  It's perfectly fine for a driver to specify a
> mode, if the hardware always uses some unusual mode then there's
> no sense in forcing every single DT to set the same mode.  On the
> other hand if there's some configuration for the driver that was
> handling some board specific configuration that there's already
> some generic SPI support for setting then it seems odd to have a
> custom driver specific configuration mechanism.
> 

If the driver picks a mode because that's what it says on the datasheet
it prevents odd board configurations from working.  The question
becomes whether it makes sense in general to assume those odd board
conditions don't exist until we actually have one, or to assume that
they might and push the burden on to all DT files.

Traditionally in IIO at least we've mostly taken the view the DT
should be right and complete and had bindings state what normal
parameters must be for it to work (assuming no inverters etc)

If we encode it in the driver, and we later meet such a board we
end up with a custom dance to query the DT parameters again and
only override if present.

We can't rely on the core SPI handling because I don't think
there is any means of specifying a default.

We can adopt the view that in general these weird boards with inverters
are weird and just handle them when they occur.  Sounds like that is your
preference, at least for new parts.

For old ones we have no idea if there are boards out there using
them with inverters so easiest is probably to just carry on putting them
in the DT bindings.

Jonathan