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] [day] [month] [year] [list]

Date:   Thu, 5 Dec 2019 08:19:52 +0000
From:   "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>
To:     "broonie@...nel.org" <broonie@...nel.org>
CC:     "kernel-usp@...glegroups.com" <kernel-usp@...glegroups.com>,
        "knaack.h@....de" <knaack.h@....de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        "Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "jic23@...nel.org" <jic23@...nel.org>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "Hennerich, Michael" <Michael.Hennerich@...log.com>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "Popa, Stefan Serban" <StefanSerban.Popa@...log.com>,
        "rodrigorsdc@...il.com" <rodrigorsdc@...il.com>,
        "pmeerw@...erw.net" <pmeerw@...erw.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] dt-bindings: iio: accel: add binding documentation for
 ADIS16240

On Wed, 2019-12-04 at 17:00 +0000, Mark Brown wrote:
> On Wed, Dec 04, 2019 at 07:18:15AM +0000, Ardelean, Alexandru wrote:
> 
> > One example (for spi-cpha):
> >         if (of_property_read_u32(nc, "spi-cpha", &tmp) == 0) {
> >                 spi->mode |= SPI_CPHA_OVERRIDE;
> >                 if (tmp)
> >                     spi->mode |= SPI_CPHA;
> 
> We could also do this with a separate flag saying that the wire
> format is forced from DT rather than having one per setting.
> 

I will admit that [since you seem to incline towards this approach], I am
also inclined to consider it over the spi-mode-conv driver.
And also since you're saying that the driver would be harder to achieve.

I'll see about an implementation for this flag and come back for a review
[on it].
[Until then] I also owe you some more "delay_usecs" cleanup in other
subsystems.

Thanks
Alex

> > Or maybe, a more complete solution would be an "spi-mode-conv" driver.
> > Similar to the fixed-factor-clock clk driver, which just does a
> > computation
> > based on values from the DT.
> > To tell the truth, this would be a great idea, because we have
> > something
> > like a passive 3-wire-to-4-wire HDL converter. This requires that the
> > driver be configured in 3-wire mode, the SPI controller in normal 4-
> > wire.
> > That's because the SPI framework does a validation of the supported
> > modes
> > (for the SPI controller) and invalidates what the device wants (which
> > is
> > very reasonable).
> 
> This is harder to achieve here because we don't have drivers for
> random bits of the wire format...