[PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Fabio Berton]

This commit merge tag Linux 4.14.

Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
---
 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

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Bas Mevissen]

On 20/11/2017 19:22, Fabio Berton wrote:
> This commit merge tag Linux 4.14.
> 
> Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
> ---
>   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.

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Otavio Salvador]

On Tue, Nov 21, 2017 at 10:52 AM, Bas Mevissen <abuse@basmevissen.nl> wrote:
> On 20/11/2017 19:22, Fabio Berton wrote:
>>
>> This commit merge tag Linux 4.14.
>>
>> Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
>> ---
>>   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@impinj.com>
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@kernel.org>
    CC: Sascha Hauer <kernel@pengutronix.de>
    CC: Fabio Estevam <fabio.estevam@nxp.com>
    CC: Mark Brown <broonie@kernel.org>
    Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Trent Piepho <tpiepho@impinj.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

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

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Bas Mevissen]

On 21/11/2017 14:26, Otavio Salvador wrote:
> On Tue, Nov 21, 2017 at 10:52 AM, Bas Mevissen <abuse@basmevissen.nl> wrote:
>> On 20/11/2017 19:22, Fabio Berton wrote:
>>>
>>> This commit merge tag Linux 4.14.
>>>
>>> Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
>>> ---
>>>    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@impinj.com>
> 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@kernel.org>
>      CC: Sascha Hauer <kernel@pengutronix.de>
>      CC: Fabio Estevam <fabio.estevam@nxp.com>
>      CC: Mark Brown <broonie@kernel.org>
>      Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
>      Signed-off-by: Trent Piepho <tpiepho@impinj.com>
>      Signed-off-by: Mark Brown <broonie@kernel.org>
> 
> 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 */
> 		>;
> 	};

(...)
> };

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Fabio Estevam]

Hi Bas,

On Tue, Nov 21, 2017 at 11:38 AM, Bas Mevissen <abuse@basmevissen.nl> 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

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Bas Mevissen]

On 21/11/2017 15:36, Fabio Estevam wrote:
> Hi Bas,
> 
> On Tue, Nov 21, 2017 at 11:38 AM, Bas Mevissen <abuse@basmevissen.nl> 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.

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Bas Mevissen]

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@basmevissen.nl> 
>> wrote:
>>> On 20/11/2017 19:22, Fabio Berton wrote:
>>>>
>>>> This commit merge tag Linux 4.14.
>>>>
>>>> Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
>>>> ---
>>>>    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@impinj.com>
>> 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@kernel.org>
>>      CC: Sascha Hauer <kernel@pengutronix.de>
>>      CC: Fabio Estevam <fabio.estevam@nxp.com>
>>      CC: Mark Brown <broonie@kernel.org>
>>      Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
>>      Signed-off-by: Trent Piepho <tpiepho@impinj.com>
>>      Signed-off-by: Mark Brown <broonie@kernel.org>
>>
>> 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.

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Fabio Estevam]

On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@basmevissen.nl> 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.

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Otavio Salvador]

Hello,

On Tue, Nov 21, 2017 at 1:24 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@basmevissen.nl> 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

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Bas Mevissen]

On 21/11/2017 17:05, Otavio Salvador wrote:
> Hello,
> 
> On Tue, Nov 21, 2017 at 1:24 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@basmevissen.nl> 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.

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Bas Mevissen]

On 21/11/2017 16:24, Fabio Estevam wrote:
> On Tue, Nov 21, 2017 at 1:07 PM, Bas Mevissen <abuse@basmevissen.nl> 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.

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Bas Mevissen]

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@basmevissen.nl> 
>> 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.

Re: [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2

[Fabio Estevam]

Hi Bas,

On Mon, Nov 27, 2017 at 7:21 AM, Bas Mevissen <abuse@basmevissen.nl> 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