Hi Mark, On Fri, Sep 4, 2020 at 12:05 PM Mark Brown <broonie@xxxxxxxxxx> 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.