linux-kernel - Re: [PATCH v2] clk: imx8mm: Switch to platform driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4cdbd500-2199-762c-43d9-2a49bd8e2414@kontron.de>
Date:   Tue, 17 Mar 2020 10:45:40 +0000
From:   Schrempf Frieder <frieder.schrempf@...tron.de>
To:     Peng Fan <peng.fan@....com>, Abel Vesa <abel.vesa@....com>,
        Mike Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        Anson Huang <anson.huang@....com>, Jacky Bai <ping.bai@....com>
CC:     dl-linux-imx <linux-imx@....com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>
Subject: Re: [PATCH v2] clk: imx8mm: Switch to platform driver

Hi Peng,

On 17.03.20 04:56, Peng Fan wrote:
>> Subject: Re: [PATCH v2] clk: imx8mm: Switch to platform driver
>>
>> On 06.02.20 11:37, Frieder Schrempf wrote:
>>> On 06.02.20 11:34, Schrempf Frieder wrote:
>>>> Hi,
>>>>
>>>> On 09.07.19 16:20, Abel Vesa wrote:
>>>>> There is no strong reason for this to use CLK_OF_DECLARE instead of
>>>>> being a platform driver. Plus, this will now be aligned with the
>>>>> other i.MX8M clock drivers which are platform drivers.
>>>>>
>>>>> In order to make the clock provider a platform driver all the data
>>>>> and code needs to be outside of .init section.
>>>>>
>>>>> Signed-off-by: Abel Vesa <abel.vesa@....com>
>>>>> Acked-by: Stephen Boyd <sboyd@...nel.org>
>>>>
>>>> This has been upstream for quite some time now, but somehow I have an
>>>> issue with SPI on the i.MX8MM that gets resolved when I revert this
>>>> patch.
>>>>
>>>> When I try to probe an SPI NOR flash with latest 5.4 or even 5.5:
>>>>
>>>>      spi_imx 30820000.spi: dma setup error -19, use pio
>>>>      spi-nor spi0.0: unrecognized JEDEC id bytes: 00 00 00 00 00 00
>>>>      spi_imx 30820000.spi: probed
>>>>
>>>> When I revert this patch:
>>>>
>>>>      spi_imx 30820000.spi: dma setup error -19, use pio
>>>>      spi-nor spi0.0: mx25r1635f (2048 Kbytes)
>>>>      spi_imx 30820000.spi: probed
>>>>
>>>> Please note, that in both cases I have disabled DMA, as this causes
>>>> even more trouble (see [1]). But even with DMA enabled and ignoring
>>>> the DMA errors, the issue described above occurs.
>>>>
>>>> Does someone have an idea what's wrong?
>>>> Am I the only user of SPI on i.MX8MM as this issue seems to exist
>>>> upstream since v5.4-rc1?
>>
>> This issue still persists in v5.6-rc6. Can someone please have a look?
> 
> Would you post your full boot log somewhere?

Sure, the two bootlogs are here: https://paste.ee/p/8uDwd.
The only difference is that in the OK case this patch is applied: 
https://paste.ee/p/xUBrO

> 
> With success/fail case, are there any differences in spi controller registers?
> I suppose no.

No, they are the same, except for BURST_LENGTH in ECSPI1_CONREG, which 
is 0x2F in case of failure and 0x3F in case it is working. But I guess 
that's a result of the failed/successful transfers.

> 
> Did you measure the signal saying data in when cs is low?

It's a bit difficult to access the signals on the board so I didn't 
check the signals, yet.

> 
> Anyway it is a bit wired since this patch just delayed the probe for a while.

Yes, it's really weird and it's very unfortunate that the EVK does not 
have a SPI device onboard. I guess that would have helped to prevent 
regressions due to better testing.

If you have any suggestions, please let me know.

Thanks,
Frieder