linux-kernel - Re: [PATCH v4 1/3] spi: add SPI_MOSI_IDLE

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEktqcuMrqiwDfGM=SAoHiKPY-hupS+jipt=6Tasr1q8VUvRQQ@mail.gmail.com>
Date:   Thu, 18 May 2023 01:20:14 +0200
From:   Börge Strümpfel <boerge.struempfel@...il.com>
To:     Fabio Estevam <festevam@...il.com>
Cc:     bstruempfel@...ratronik.de, andy.shevchenko@...il.com,
        amit.kumar-mahapatra@....com, broonie@...nel.org,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        NXP Linux Team <linux-imx@....com>,
        linux-spi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/3] spi: add SPI_MOSI_IDLE_LOW mode bit

Thank you for your prompt feedback

Am Do., 18. Mai 2023 um 00:43 Uhr schrieb Fabio Estevam <festevam@...il.com>:
>
> On Wed, May 17, 2023 at 7:30 PM Boerge Struempfel
> <boerge.struempfel@...il.com> wrote:
> >
> > Some spi controller switch the mosi line to high, whenever they are
> > idle. This may not be desired in all use cases. For example neopixel
> > leds can get confused and flicker due to misinterpreting the idle state.
> > Therefore, we introduce a new spi-mode bit, with which the idle behaviour
> > can be overwritten on a per device basis.
> >
> > Signed-off-by: Boerge Struempfel <boerge.struempfel@...il.com>
> >
> >
> > Link for versions:
> >   v1 and v2: https://lore.kernel.org/linux-spi/20230511135632.78344-1-bstruempfel@ultratronik.de/
> >   v3: https://lore.kernel.org/linux-spi/20230517103007.26287-1-boerge.struempfel@gmail.com/T/#t
> >
> > Changes from V3:
> >   - Added missing paranthesis which caused builderrors
> >
> > Changes from V2:
> >   - Removed the device-tree binding since this should not be managed by
> >     the DT but by the device itself.
> >   - Replaced all occurences of spi->chip_select with the corresponding
> >     macro spi_get_chipselect(spi,0)
> >
> > Changes from V1:
> >   - Added patch, introducing the new devicetree binding flag
> >   - Split the generic spi part of the patch from the imx-spi specific
> >     part
> >   - Replaced SPI_CPOL and SPI_CPHA by the combined SPI_MODE_X_MASK bit
> >     in the imx-spi.c modebits.
> >   - Added the SPI_MOSI_IDLE_LOW bit to spidev
>
> The change log should be placed below the --- line.
>

My bad. Thanks for letting me know. Just to clarify: I put the
changelog directly below
the first ---? And do I then put another --- between the changelog and
the following
include/uapi/linux/spi/spi.h | 3 ++- line?  or is there just a
new-line seperating them.

And if you don't mind my trivial questions, am I supposed to write a
cover letter for
the patch-stack? I seem to find contradictory answers to this question online.

> > ---
> >  include/uapi/linux/spi/spi.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/spi/spi.h b/include/uapi/linux/spi/spi.h
> > index 9d5f58059703..ca56e477d161 100644
> > --- a/include/uapi/linux/spi/spi.h
> > +++ b/include/uapi/linux/spi/spi.h
> > @@ -28,6 +28,7 @@
> >  #define        SPI_RX_OCTAL            _BITUL(14)      /* receive with 8 wires */
> >  #define        SPI_3WIRE_HIZ           _BITUL(15)      /* high impedance turnaround */
> >  #define        SPI_RX_CPHA_FLIP        _BITUL(16)      /* flip CPHA on Rx only xfer */
> > +#define SPI_MOSI_IDLE_LOW      _BITUL(17)      /* leave mosi line low when idle */
>
> Should tools/spi/spidev_test.c be changed to include this new
> mosi-idle-low option?

Until now I actually wasn't aware of this tool. However on first
glance, it seems
reasonable to add this mode bit. I can certainly add this mode bit to
the spidev_test
if desired.

While looking through the code, I noticed, that the latest two
additions to the spi->mode
(SPI_3WIRE_HIZ and SPI_RX_CPHA_FLIP) are also missing from this tool. Is this
by design, or should they then be included as well?