This commit merge tag Linux 4.14.

Signed-off-by: Fabio Berton <fabio.berton@...>
---
recipes-kernel/linux/linux-fslc_4.14.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-fslc_4.14.bb b/recipes-kernel/linux/linux-fslc_4.14.bb
index 6adc12e1..a96880fd 100644
--- a/recipes-kernel/linux/linux-fslc_4.14.bb
+++ b/recipes-kernel/linux/linux-fslc_4.14.bb
@@ -12,6 +12,6 @@ include linux-fslc.inc
PV = "4.14+git${SRCPV}"

SRCBRANCH = "4.14.x+fslc"
-SRCREV = "bd340b0f7370015791413ea458c0f56715f17e19"
+SRCREV = "c4404197b0b22f479d9548e81a8a4ed639d4dd7c"

COMPATIBLE_MACHINE = "(mxs|mx5|mx6|vf|use-mainline-bsp)"
--
2.14.2

On 20/11/2017 19:22, Fabio Berton wrote:

This commit merge tag Linux 4.14.
Signed-off-by: Fabio Berton <fabio.berton@...>
---
recipes-kernel/linux/linux-fslc_4.14.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-kernel/linux/linux-fslc_4.14.bb b/recipes-kernel/linux/linux-fslc_4.14.bb
index 6adc12e1..a96880fd 100644
--- a/recipes-kernel/linux/linux-fslc_4.14.bb
+++ b/recipes-kernel/linux/linux-fslc_4.14.bb
@@ -12,6 +12,6 @@ include linux-fslc.inc
PV = "4.14+git${SRCPV}"
SRCBRANCH = "4.14.x+fslc"
-SRCREV = "bd340b0f7370015791413ea458c0f56715f17e19"
+SRCREV = "c4404197b0b22f479d9548e81a8a4ed639d4dd7c"
COMPATIBLE_MACHINE = "(mxs|mx5|mx6|vf|use-mainline-bsp)"

I see a regression in imx SPI with this change:

bd340b0f7370015791413ea458c0f56715f17e19:

[ 8.610321] spi_imx 200c000.ecspi: registered master spi1
[ 8.626154] spi spi1.0: spi_imx_setup: mode 0, 8 bpw, 5000000 hz
[ 8.626207] spi spi1.0: setup mode 0, 8 bits/w, 5000000 Hz max --> 0
[ 8.633467] spi_imx 200c000.ecspi: registered child spi1.0
[ 8.633593] spi_imx 200c000.ecspi: probed


c4404197b0b22f479d9548e81a8a4ed639d4dd7c:

[ 1.196374] spi_imx 200c000.ecspi: No CS GPIOs available
[ 1.201760] spi_imx: probe of 200c000.ecspi failed with error -22

Platform is i.MX6 dual core.

In the latter case, my SPI device is not working.

I'm investigating right now.

Cheers,

Bas.

On Tue, Nov 21, 2017 at 10:52 AM, Bas Mevissen <abuse@...> wrote:

On 20/11/2017 19:22, Fabio Berton wrote:

This commit merge tag Linux 4.14.

Signed-off-by: Fabio Berton <fabio.berton@...>
---
recipes-kernel/linux/linux-fslc_4.14.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-fslc_4.14.bb
b/recipes-kernel/linux/linux-fslc_4.14.bb
index 6adc12e1..a96880fd 100644
--- a/recipes-kernel/linux/linux-fslc_4.14.bb
+++ b/recipes-kernel/linux/linux-fslc_4.14.bb
@@ -12,6 +12,6 @@ include linux-fslc.inc
PV = "4.14+git${SRCPV}"
SRCBRANCH = "4.14.x+fslc"
-SRCREV = "bd340b0f7370015791413ea458c0f56715f17e19"
+SRCREV = "c4404197b0b22f479d9548e81a8a4ed639d4dd7c"
COMPATIBLE_MACHINE = "(mxs|mx5|mx6|vf|use-mainline-bsp)"

I see a regression in imx SPI with this change:

bd340b0f7370015791413ea458c0f56715f17e19:

[ 8.610321] spi_imx 200c000.ecspi: registered master spi1
[ 8.626154] spi spi1.0: spi_imx_setup: mode 0, 8 bpw, 5000000 hz
[ 8.626207] spi spi1.0: setup mode 0, 8 bits/w, 5000000 Hz max --> 0
[ 8.633467] spi_imx 200c000.ecspi: registered child spi1.0
[ 8.633593] spi_imx 200c000.ecspi: probed


c4404197b0b22f479d9548e81a8a4ed639d4dd7c:

[ 1.196374] spi_imx 200c000.ecspi: No CS GPIOs available
[ 1.201760] spi_imx: probe of 200c000.ecspi failed with error -22

Platform is i.MX6 dual core.

In the latter case, my SPI device is not working.

commit 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047
Author: Trent Piepho <tpiepho@...>
Date: Thu Oct 26 18:08:39 2017 -0700

spi: imx: Fix failure path leak on GPIO request error

If the code that requests any chip select GPIOs fails, the cleanup of
spi_bitbang_start() by calling spi_bitbang_stop() is not done.

Fix this by moving spi_bitbang_start() to after the code that requets
GPIOs. The GPIOs are dev managed and don't need explicit cleanup.
Since spi_bitbang_start() is now the last operation, it doesn't need
to be cleaned up in the failure path.

CC: Shawn Guo <shawnguo@...>
CC: Sascha Hauer <kernel@...>
CC: Fabio Estevam <fabio.estevam@...>
CC: Mark Brown <broonie@...>
Reviewed-by: Oleksij Rempel <o.rempel@...>
Signed-off-by: Trent Piepho <tpiepho@...>
Signed-off-by: Mark Brown <broonie@...>

Seems to be the culprit; I think you might be missing the chip-select pin, no?

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750

On 21/11/2017 14:26, Otavio Salvador wrote:

On Tue, Nov 21, 2017 at 10:52 AM, Bas Mevissen <abuse@...> wrote:

On 20/11/2017 19:22, Fabio Berton wrote:

This commit merge tag Linux 4.14.

Signed-off-by: Fabio Berton <fabio.berton@...>
---
recipes-kernel/linux/linux-fslc_4.14.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-fslc_4.14.bb
b/recipes-kernel/linux/linux-fslc_4.14.bb
index 6adc12e1..a96880fd 100644
--- a/recipes-kernel/linux/linux-fslc_4.14.bb
+++ b/recipes-kernel/linux/linux-fslc_4.14.bb
@@ -12,6 +12,6 @@ include linux-fslc.inc
PV = "4.14+git${SRCPV}"
SRCBRANCH = "4.14.x+fslc"
-SRCREV = "bd340b0f7370015791413ea458c0f56715f17e19"
+SRCREV = "c4404197b0b22f479d9548e81a8a4ed639d4dd7c"
COMPATIBLE_MACHINE = "(mxs|mx5|mx6|vf|use-mainline-bsp)"

I see a regression in imx SPI with this change:

bd340b0f7370015791413ea458c0f56715f17e19:

[ 8.610321] spi_imx 200c000.ecspi: registered master spi1
[ 8.626154] spi spi1.0: spi_imx_setup: mode 0, 8 bpw, 5000000 hz
[ 8.626207] spi spi1.0: setup mode 0, 8 bits/w, 5000000 Hz max --> 0
[ 8.633467] spi_imx 200c000.ecspi: registered child spi1.0
[ 8.633593] spi_imx 200c000.ecspi: probed


c4404197b0b22f479d9548e81a8a4ed639d4dd7c:

[ 1.196374] spi_imx 200c000.ecspi: No CS GPIOs available
[ 1.201760] spi_imx: probe of 200c000.ecspi failed with error -22

Platform is i.MX6 dual core.

In the latter case, my SPI device is not working.

commit 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047
Author: Trent Piepho <tpiepho@...>
Date: Thu Oct 26 18:08:39 2017 -0700
spi: imx: Fix failure path leak on GPIO request error
If the code that requests any chip select GPIOs fails, the cleanup of
spi_bitbang_start() by calling spi_bitbang_stop() is not done.
Fix this by moving spi_bitbang_start() to after the code that requets
GPIOs. The GPIOs are dev managed and don't need explicit cleanup.
Since spi_bitbang_start() is now the last operation, it doesn't need
to be cleaned up in the failure path.
CC: Shawn Guo <shawnguo@...>
CC: Sascha Hauer <kernel@...>
CC: Fabio Estevam <fabio.estevam@...>
CC: Mark Brown <broonie@...>
Reviewed-by: Oleksij Rempel <o.rempel@...>
Signed-off-by: Trent Piepho <tpiepho@...>
Signed-off-by: Mark Brown <broonie@...>
Seems to be the culprit; I think you might be missing the chip-select pin, no?

That one looked innocent to me, but it is indeed the only change in spi-imx.c between the two commits I mentioned. It feels quite odd that no one would have noticed the regression in a month time.

Just to be sure, the relevant snippet from the device tree file:

&ecspi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
status = "okay";
mrf24j40mc@0 {
compatible = "microchip,mrf24j40mc";
spi-max-frequency = <5000000>; /* datasheet: max 10000000 */
reg = <0>;
interrupts = <20 8>;
interrupt-parent = <&gpio5>;
#ifndef SPIDEV_SPI1_ENABLE
status = "okay";
#else
status = "disabled";
#endif
};
/* Test device */
spidev1_0: spi@0 {
compatible = "spidev", "rohm,dh2228fv"; /* spidev driver needs this entry to avoid runtime warning */
reg = <0>;
spi-max-frequency = <5000000>;
#ifndef SPIDEV_SPI1_ENABLE
status = "disabled";
#else
status = "okay";
#endif
};
};

SPIDEV_SPI1_ENABLE is not defined; it is a terrible kludge to produce a separate device tree file where we can have direct SPI access to the microchip radio during test. If someone has a better idea, please let me know. Creating a DT overlay came to mind, but I haven't got around it yet.

&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hog>, <&pinctrl_expansion_hdr_gpio>;

(...)

pinctrl_ecspi2: ecspi2grp {
fsl,pins = <
MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x0b0b0 /* MOSI */
MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x0b0b0 /* MISO */
MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x0b0b0 /* SCK */
MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x0b0b0 /* CS_N */
>;
};

(...)

};

Hi Bas,

On Tue, Nov 21, 2017 at 11:38 AM, Bas Mevissen <abuse@...> wrote:

That one looked innocent to me, but it is indeed the only change in
spi-imx.c between the two commits I mentioned. It feels quite odd that no
one would have noticed the regression in a month time.

Could you please apply this commit?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/spi/spi-imx.c?h=next-20171121&id=881a0b993e9f065cbb3673c94c395fa1de24bdcc

On 21/11/2017 15:36, Fabio Estevam wrote:

Hi Bas,
On Tue, Nov 21, 2017 at 11:38 AM, Bas Mevissen <abuse@...> wrote:

That one looked innocent to me, but it is indeed the only change in
spi-imx.c between the two commits I mentioned. It feels quite odd that no
one would have noticed the regression in a month time.

Could you please apply this commit?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/spi/spi-imx.c?h=next-20171121&id=881a0b993e9f065cbb3673c94c395fa1de24bdcc

No problem to try it, but it looks like this is a patch to be for the case one has *no* cs-gpios defined, while I *do* have them.

-- Bas.

On 21/11/2017 14:38, Bas Mevissen wrote:

On 21/11/2017 14:26, Otavio Salvador wrote:

On Tue, Nov 21, 2017 at 10:52 AM, Bas Mevissen <abuse@...> wrote:

On 20/11/2017 19:22, Fabio Berton wrote:

This commit merge tag Linux 4.14.

Signed-off-by: Fabio Berton <fabio.berton@...>
---
   recipes-kernel/linux/linux-fslc_4.14.bb | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-fslc_4.14.bb
b/recipes-kernel/linux/linux-fslc_4.14.bb
index 6adc12e1..a96880fd 100644
--- a/recipes-kernel/linux/linux-fslc_4.14.bb
+++ b/recipes-kernel/linux/linux-fslc_4.14.bb
@@ -12,6 +12,6 @@ include linux-fslc.inc
   PV = "4.14+git${SRCPV}"
     SRCBRANCH = "4.14.x+fslc"
-SRCREV = "bd340b0f7370015791413ea458c0f56715f17e19"
+SRCREV = "c4404197b0b22f479d9548e81a8a4ed639d4dd7c"
     COMPATIBLE_MACHINE = "(mxs|mx5|mx6|vf|use-mainline-bsp)"

I see a regression in imx SPI with this change:

bd340b0f7370015791413ea458c0f56715f17e19:

[    8.610321] spi_imx 200c000.ecspi: registered master spi1
[    8.626154] spi spi1.0: spi_imx_setup: mode 0, 8 bpw, 5000000 hz
[    8.626207] spi spi1.0: setup mode 0, 8 bits/w, 5000000 Hz max --> 0
[    8.633467] spi_imx 200c000.ecspi: registered child spi1.0
[    8.633593] spi_imx 200c000.ecspi: probed


c4404197b0b22f479d9548e81a8a4ed639d4dd7c:

[    1.196374] spi_imx 200c000.ecspi: No CS GPIOs available
[    1.201760] spi_imx: probe of 200c000.ecspi failed with error -22

Platform is i.MX6 dual core.

In the latter case, my SPI device is not working.

commit 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047
Author: Trent Piepho <tpiepho@...>
Date:   Thu Oct 26 18:08:39 2017 -0700

     spi: imx: Fix failure path leak on GPIO request error

     If the code that requests any chip select GPIOs fails, the cleanup of
     spi_bitbang_start() by calling spi_bitbang_stop() is not done.

     Fix this by moving spi_bitbang_start() to after the code that requets
     GPIOs.  The GPIOs are dev managed and don't need explicit cleanup.
     Since spi_bitbang_start() is now the last operation, it doesn't need
     to be cleaned up in the failure path.

     CC: Shawn Guo <shawnguo@...>
     CC: Sascha Hauer <kernel@...>
     CC: Fabio Estevam <fabio.estevam@...>
     CC: Mark Brown <broonie@...>
     Reviewed-by: Oleksij Rempel <o.rempel@...>
     Signed-off-by: Trent Piepho <tpiepho@...>
     Signed-off-by: Mark Brown <broonie@...>

Seems to be the culprit; I think you might be missing the chip-select pin, no?

That one looked innocent to me, but it is indeed the only change in spi-imx.c between the two commits I mentioned. It feels quite odd that no one would have noticed the regression in a month time.
Just to be sure, the relevant snippet from the device tree file:

&ecspi2 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ecspi2>;
    cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
    status = "okay";

    mrf24j40mc@0 {
        compatible = "microchip,mrf24j40mc";
        spi-max-frequency = <5000000>; /* datasheet: max 10000000 */
        reg = <0>;
        interrupts = <20 8>;
        interrupt-parent = <&gpio5>;
#ifndef SPIDEV_SPI1_ENABLE
        status = "okay";
#else
        status = "disabled";
#endif
    };

    /* Test device */
    spidev1_0: spi@0 {
        compatible = "spidev", "rohm,dh2228fv"; /* spidev driver needs this entry to avoid runtime warning */
        reg = <0>;
        spi-max-frequency = <5000000>;
#ifndef SPIDEV_SPI1_ENABLE
        status = "disabled";
#else
        status = "okay";
#endif
    };
};

SPIDEV_SPI1_ENABLE is not defined; it is a terrible kludge to produce a separate device tree file where we can have direct SPI access to the microchip radio during test. If someone has a better idea, please let me know. Creating a DT overlay came to mind, but I haven't got around it yet.

&iomuxc {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_hog>, <&pinctrl_expansion_hdr_gpio>;

(...)

    pinctrl_ecspi2: ecspi2grp {
        fsl,pins = <
            MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI        0x0b0b0 /* MOSI */
            MX6QDL_PAD_EIM_OE__ECSPI2_MISO        0x0b0b0 /* MISO */
            MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK        0x0b0b0 /* SCK */
            MX6QDL_PAD_EIM_RW__GPIO2_IO26        0x0b0b0 /* CS_N */
        >;
    };

(...)

};

I tried linux-fslc@c4404197b0b22f479d9548e81a8a4ed639d4dd7c with commit 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 reverted and that works fine.

What's the best thing to do now? Revert 3e9b36e for now and push that to linux-fslc?

Cheers,

Bas.

On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@...> wrote:

I tried linux-fslc@c4404197b0b22f479d9548e81a8a4ed639d4dd7c with commit
3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 reverted and that works fine.

I don't think that 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 should
have been applied to linux-fslc to start with.

This commit is in linux-next currently and it will be part of the
upcoming 4.15-rc1.

IMHO linux-fslc should only contain the patches from linux-stable tree
with a few exceptions like: new dts files, for example.

What's the best thing to do now? Revert 3e9b36e for now and push that to
linux-fslc?

I think we can do two things:

- Revert 3e9b36e from linux-fslc

- If you could try linux-next on your board and see if it works well
or not. This way we can antecipate any possible issues with the SPI
driver for the upcoming 4.15-rc1.

Hello,

On Tue, Nov 21, 2017 at 1:24 PM, Fabio Estevam <festevam@...> wrote:

On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@...> wrote:

I tried linux-fslc@c4404197b0b22f479d9548e81a8a4ed639d4dd7c with commit
3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 reverted and that works fine.

I don't think that 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 should
have been applied to linux-fslc to start with.

This commit is in linux-next currently and it will be part of the
upcoming 4.15-rc1.

IMHO linux-fslc should only contain the patches from linux-stable tree
with a few exceptions like: new dts files, for example.

What's the best thing to do now? Revert 3e9b36e for now and push that to
linux-fslc?

I think we can do two things:

- Revert 3e9b36e from linux-fslc

I did revert the it and pushed to linux-fslc.

Please confirm it works.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750

On 21/11/2017 17:05, Otavio Salvador wrote:

Hello,
On Tue, Nov 21, 2017 at 1:24 PM, Fabio Estevam <festevam@...> wrote:

On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@...> wrote:

I tried linux-fslc@c4404197b0b22f479d9548e81a8a4ed639d4dd7c with commit
3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 reverted and that works fine.

I don't think that 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 should
have been applied to linux-fslc to start with.

This commit is in linux-next currently and it will be part of the
upcoming 4.15-rc1.

IMHO linux-fslc should only contain the patches from linux-stable tree
with a few exceptions like: new dts files, for example.

What's the best thing to do now? Revert 3e9b36e for now and push that to
linux-fslc?

I think we can do two things:

- Revert 3e9b36e from linux-fslc

I did revert the it and pushed to linux-fslc.
Please confirm it works.

Thanks a lot! I can confirm it works like a charm.

Cheers,

Bas.

On 21/11/2017 16:24, Fabio Estevam wrote:

On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@...> wrote:

I tried linux-fslc@c4404197b0b22f479d9548e81a8a4ed639d4dd7c with commit
3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 reverted and that works fine.

I don't think that 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 should
have been applied to linux-fslc to start with.
This commit is in linux-next currently and it will be part of the
upcoming 4.15-rc1.
IMHO linux-fslc should only contain the patches from linux-stable tree
with a few exceptions like: new dts files, for example.

What's the best thing to do now? Revert 3e9b36e for now and push that to
linux-fslc?

I think we can do two things:
- Revert 3e9b36e from linux-fslc

This is what Otavio kindly pushed in a4f7f0ac8250ff10d6111df25e7d940a2f36801a and I can confirm it works on my board (i.MX6 dual).

- If you could try linux-next on your board and see if it works well
or not. This way we can antecipate any possible issues with the SPI
driver for the upcoming 4.15-rc1.

Yes, will do that later this week.

Thanks for your help,

Cheers,

Bas.

On 22/11/2017 00:31, Bas Mevissen wrote:

On 21/11/2017 16:24, Fabio Estevam wrote:

On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@...> wrote:

(...)

- If you could try linux-next on your board and see if it works well
or not. This way we can antecipate any possible issues with the SPI
driver for the upcoming 4.15-rc1.

Yes, will do that later this week.

Current (2017-11-27) Linux-next boots fine. So no SPI issues on my i.MX6 board for this kernel version.

-- Bas.

Hi Bas,

On Mon, Nov 27, 2017 at 7:21 AM, Bas Mevissen <abuse@...> wrote:

Current (2017-11-27) Linux-next boots fine. So no SPI issues on my i.MX6
board for this kernel version.

Thanks for testing. Looks like the issue was linux-fslc related.

Otavio, please avoid applying patches from linux-next into linux-fslc
to avoid breakages.

Thanks