linux-kernel - RE: (EXT) [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 3 Jun 2020 09:50:42 +0000
From:   Robin Gong <yibin.gong@....com>
To:     Matthias Schiffer <matthias.schiffer@...tq-group.com>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "will.deacon@....com" <will.deacon@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "festevam@...il.com" <festevam@...il.com>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "martin.fuzzey@...wbird.group" <martin.fuzzey@...wbird.group>,
        "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        Markus Niebel <Markus.Niebel@...group.com>
Subject: RE: (EXT) [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family

On 2020/06/03 Matthias Schiffer <matthias.schiffer@...tq-group.com> wrote:
 > On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote:
> > There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> > transfer to be send twice in DMA mode. Please get more information
> > from:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&amp;data=02%7C01%7C
> yibin.g
> >
> ong%40nxp.com%7C4621358b9be04a79d2d508d80798835b%7C686ea1d3bc2b
> 4c6fa92
> >
> cd99c5c301635%7C0%7C1%7C637267698912634476&amp;sdata=hR66H1hP%
> 2Fqb6OXe
> > w9wpXizY8DiNfZZ1KLwu3Kty87jc%3D&amp;reserved=0. The workaround is
> > adding new sdma ram script which works in XCH  mode as PIO inside sdma
> > instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue
> should be exist on all legacy i.mx6/7 soc family before i.mx6ul.
> > NXP fix this design issue from i.mx6ul, so newer chips including
> > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All other
> > i.mx6/7/8 chips still need this workaroud. This patch set add new
> > 'fsl,imx6ul-ecspi'
> > for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need
> > errata or not.
> > The first two reverted patches should be the same issue, though, it
> > seems 'fixed' by changing to other shp script. Hope Sean or Sascha
> > could have the chance to test this patch set if could fix their
> > issues.
> > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
> > on i.mx8mm because the event id is zero.
> >
> > PS:
> >    Please get sdma firmware from below linux-firmware and copy it to
> > your local rootfs /lib/firmware/imx/sdma.
> 
> 
> Hello Robin,
> 
> we have tried out this series, and there seems to be an issue with the
> PIO fallback. We are testing on an i.MX6Q board, and our kernel is a
> mostly-unmodified 5.4, on which we backported all SDMA patches from
> next-20200602 (imx-sdma.c is identical to next-20200602 version), and
> then applied this whole series.
> 
> We build the SDMA driver as a kernel module, which is loaded by udev,
> so the root filesystem is ready and the SDMA firmware can be loaded.
> The behaviour we're seeing is the following:
> 
> 1. As long as the SDMA driver is not loaded, initializing spi_imx will
> be deferred
> 2. imx_sdma is loaded. The SDMA firmware is not yet loaded at this
> point
> 3. spi_imx is initialized and an SPI-NOR flash is probed. To load the
> BFPT, the driver will attempt to use DMA; this will fail with EINVAL as
> long as the SDMA firmware is not ready, so the fallback to PIO happens
> (4. SDMA firmware is ready, subsequent SPI transfers use DMA)
> 
> The problem happens in step 3: Whenever the driver falls back to PIO,
> the received data is corrupt. The behaviour is specific to the
> fallback: When I disable DMA completely via spi_imx.use_dma, or when
> the timing is lucky and the SDMA firmware gets loaded before the flash
> is probed, no corruption can be observed.
Thanks Matthias, would you like post log?