linux-kernel - RE: [PATCH] arm64: defconfig: Enable FSL

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]

Message-ID: <VE1PR04MB6687EE0E22DA0697A0A7038F8FEF0@VE1PR04MB6687.eurprd04.prod.outlook.com>
Date:   Thu, 13 Jun 2019 14:01:11 +0000
From:   Leo Li <leoyang.li@....com>
To:     Shawn Guo <shawnguo@...nel.org>
CC:     Madalin-cristian Bucur <madalin.bucur@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Aisheng Dong <aisheng.dong@....com>,
        Vinod Koul <vkoul@...nel.org>,
        Grant Likely <grant.likely@....com>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "wsa@...-dreams.de" <wsa@...-dreams.de>
Subject: RE: [PATCH] arm64: defconfig: Enable FSL_EDMA driver



> -----Original Message-----
> From: Shawn Guo <shawnguo@...nel.org>
> Sent: Wednesday, June 12, 2019 7:45 PM
> To: Leo Li <leoyang.li@....com>
> Cc: Madalin-cristian Bucur <madalin.bucur@....com>; Rob Herring
> <robh+dt@...nel.org>; Aisheng Dong <aisheng.dong@....com>; Vinod Koul
> <vkoul@...nel.org>; Grant Likely <grant.likely@....com>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <linux-arm-
> kernel@...ts.infradead.org>; lkml <linux-kernel@...r.kernel.org>
> Subject: Re: [PATCH] arm64: defconfig: Enable FSL_EDMA driver
> 
> On Wed, Jun 12, 2019 at 03:01:29PM -0500, Li Yang wrote:
> > On Thu, May 9, 2019 at 10:15 PM Shawn Guo <shawnguo@...nel.org>
> wrote:
> > >
> > > On Mon, Apr 22, 2019 at 01:30:56PM -0500, Li Yang wrote:
> > > > Enables the FSL EDMA driver by default.  This also works around an
> > > > issue that imx-i2c driver keeps deferring the probe because of the
> > > > DMA is not ready.  And currently the DMA engine framework can not
> > > > correctly tell if the DMA channels will truly become available
> > > > later (it will never be available if the DMA driver is not enabled).
> > > >
> > > > This will cause indefinite messages like below:
> > > > [    3.335829] imx-i2c 2180000.i2c: can't get pinctrl, bus recovery not
> supported
> > > > [    3.344455] ina2xx 0-0040: power monitor ina220 (Rshunt = 1000
> uOhm)
> > > > [    3.350917] lm90 0-004c: 0-004c supply vcc not found, using dummy
> regulator
> > > > [    3.362089] imx-i2c 2180000.i2c: can't get pinctrl, bus recovery not
> supported
> > > > [    3.370741] ina2xx 0-0040: power monitor ina220 (Rshunt = 1000
> uOhm)
> > > > [    3.377205] lm90 0-004c: 0-004c supply vcc not found, using dummy
> regulator
> > > > [    3.388455] imx-i2c 2180000.i2c: can't get pinctrl, bus recovery not
> supported
> > > > .....
> > > >
> > > > Signed-off-by: Li Yang <leoyang.li@....com>
> > >
> > > Applied, thanks.
> >
> > Hi Shawn,
> >
> > Is it possible to move this patch to the -fix series so that it can
> > reach the mainline earlier?  It is having a boot failure in mainline
> > for platforms using this device without this workaround.
> 
> Why would I2C device deferring cause boot failure on a platform?  I'm just
> trying to understand severity of the problem.

Currently the probe of imx-i2c will be retried immediately after it is deferred when the optional dependency on DMA driver is not met.  This will cause an indefinite loop of probe-defer-probe and keep printing the message as shown in the commit message.

On a further look into the imx-i2c driver, it looks like the driver need some fix too.  The requesting of dma channel is done at the very late stage of the imx-i2c probe after registering the i2c adapter.  Adding the i2c adapter triggers the probe of the i2c bus which probably immediately triggers the retry of deferred probe.  This was fine previously as requesting dma channel didn't trigger a defer.  But now it triggers defer after commit e1ab9a468e3b1636d60cebd0a778461270dde208.  We probably should move the i2c_imx_dma_request() to the beginning of the probe as it is considered as a dependency now.

Regards,
Leo