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

[Otavio Salvador]

On Tue, Nov 21, 2017 at 10:52 AM, Bas Mevissen <abuse at 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 at 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 at 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 at kernel.org>
    CC: Sascha Hauer <kernel at pengutronix.de>
    CC: Fabio Estevam <fabio.estevam at nxp.com>
    CC: Mark Brown <broonie at kernel.org>
    Reviewed-by: Oleksij Rempel <o.rempel at pengutronix.de>
    Signed-off-by: Trent Piepho <tpiepho at impinj.com>
    Signed-off-by: Mark Brown <broonie at 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