linux-kernel - Re: (EXT) Re: (EXT) Re: [PATCH] spi-imx: remove num-cs support, set num

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]

Date:   Fri, 4 Sep 2020 12:42:37 -0300
From:   Fabio Estevam <festevam@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        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 <linux-spi@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: (EXT) Re: (EXT) Re: [PATCH] spi-imx: remove num-cs support, set
 num_chipselect to 4

Hi Mark,

On Fri, Sep 4, 2020 at 12:05 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Fri, Sep 04, 2020 at 04:34:43PM +0200, Matthias Schiffer wrote:
>
> > Nevertheless, I don't see why we should deliberately remove the native
> > CS support - my understanding was that we try to avoid breaking changes
> > to DT interpretation even for unknown/out-of-tree DTS.
>
> Yes, we should try to maintain compatibility for anyone that was using
> it.

We are not breaking compatibility.

Prior to 8cdcd8aeee281 ("spi: imx/fsl-lpspi: Convert to GPIO
descriptors")  num_chipselect was 1 for all device tree users.
i.MX board files will be removed, so we don't need to worry about them.

What will cause breakage is to say that the driver supports the native
chip-select.

I have just done a quick test on an imx6q-sabresd.

With the original dts that uses cs-gpios the SPI NOR is correctly probed:

[    5.402627] spi-nor spi0.0: m25p32 (4096 Kbytes)

However, using native chip select with this dts change:

--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -189,7 +189,6 @@
 };

 &ecspi1 {
-       cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ecspi1>;
        status = "okay";
@@ -506,7 +505,7 @@
                                MX6QDL_PAD_KEY_COL1__ECSPI1_MISO        0x100b1
                                MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI        0x100b1
                                MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK        0x100b1
-                               MX6QDL_PAD_KEY_ROW1__GPIO4_IO09         0x1b0b0
+                               MX6QDL_PAD_KEY_ROW1__ECSPI1_SS0         0x1b0b0
                        >;
                };

Causes SPI NOR probe to fail:

[    5.388704] spi-nor spi0.0: unrecognized JEDEC id bytes: 00 00 00 00 00 00

That's why I prefer we do not advertise that we can use the native
chip-select with this driver.