[meta-freescale] [PATCH] linux-fslc: 4.14: Bump revision to c4404197b0b2
Bas Mevissen
abuse at basmevissen.nl
Tue Nov 21 07:07:26 PST 2017
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 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?
>>
>
> 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 at 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 at 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 at 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.
More information about the meta-freescale
mailing list