linux-kernel - RE: [PATCH] i2c: imx-lpi2c: change to PIO mode in system-wide suspend/resume progress

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:
 <VI2PR04MB1114708FCF7C75A48CC7054FAE8D4A@VI2PR04MB11147.eurprd04.prod.outlook.com>
Date: Thu, 20 Nov 2025 03:02:51 +0000
From: Carlos Song <carlos.song@....com>
To: Frank Li <frank.li@....com>
CC: Aisheng Dong <aisheng.dong@....com>, "andi.shyti@...nel.org"
	<andi.shyti@...nel.org>, "shawnguo@...nel.org" <shawnguo@...nel.org>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>, "kernel@...gutronix.de"
	<kernel@...gutronix.de>, "festevam@...il.com" <festevam@...il.com>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] i2c: imx-lpi2c: change to PIO mode in system-wide
 suspend/resume progress



> -----Original Message-----
> From: Frank Li <frank.li@....com>
> Sent: Thursday, November 20, 2025 12:06 AM
> To: Carlos Song <carlos.song@....com>
> Cc: Aisheng Dong <aisheng.dong@....com>; andi.shyti@...nel.org;
> shawnguo@...nel.org; s.hauer@...gutronix.de; kernel@...gutronix.de;
> festevam@...il.com; linux-i2c@...r.kernel.org; imx@...ts.linux.dev;
> linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH] i2c: imx-lpi2c: change to PIO mode in system-wide
> suspend/resume progress
> 
> On Wed, Nov 19, 2025 at 06:02:45AM +0000, Carlos Song wrote:
> >
> >
> > > -----Original Message-----
> > > From: Frank Li <frank.li@....com>
> > > Sent: Tuesday, November 18, 2025 11:58 PM
> > > To: Carlos Song <carlos.song@....com>
> > > Cc: Aisheng Dong <aisheng.dong@....com>; andi.shyti@...nel.org;
> > > shawnguo@...nel.org; s.hauer@...gutronix.de; kernel@...gutronix.de;
> > > festevam@...il.com; linux-i2c@...r.kernel.org; imx@...ts.linux.dev;
> > > linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org
> > > Subject: Re: [PATCH] i2c: imx-lpi2c: change to PIO mode in
> > > system-wide suspend/resume progress
> > >
> > > On Tue, Nov 18, 2025 at 03:18:37PM +0800, Carlos Song wrote:
> > > > If a system-wide suspend or resume transition is in progress.
> > > > LPI2C should use PIO to transfer data not DMA to avoid issue
> > > > caused by not ready DMA HW resource.
> > >
> > > Currently there is no device link between the DMA engine and its DMA
> > > consumer, which allows the DMA engine to suspend before the consumer.
> > >
> > > To avoid this, switch to PIO mode instead of DMA during
> > > suspend/resume so the transfer does not rely on the DMA engine’s state.
> > >
> > > Notes: I suppose DMA engine suspend before LPI2C. Do you meet this
> > > or other reason cause DMA HW resource ready.
> > >
> > > Not sure if below
> > > https://lore.kernel.org/dmaengine/20250912-v6-16-topic-dma-devlink-v
> > > 1-0-4de
> > > bc2fbf901@...gutronix.de/
> > > can fix your problem.
> > >
> > > Anyway, I think it is fine to use PIO at suspend to reduce
> > > dependence. But we need know why DMA HW is not ready.
> > >
> > > Frank
> > >
> > Hi, Frank
> >
> > EDMA resume is in early stage and suspend is in late stage, but LPI2C resume
> and suspend are in NOIRQ stage.
> > So LPI2C resource become ready earlier than EDMA. When IRQ enabled,
> > immediately slave will trigger I2C to read data and the length meets
> > the requirements for DMA usage, the DMA will be needed at this time. Within
> a very small time window, EDMA is still not resumed. The root cause is from
> here.
> 
> Put these information to commit message.
> 
> Frank
> 
Will do. Thank you.

Carlos
> >
> > dev link maybe useful in the same PM stage. But in different stage, I don’t
> know if it can help some.
> > Maybe it is better that DMA move PM stage to NOIRQ, but now there is
> > no dev link for EDMA, the resume/suspend sequence between LPI2C and
> EDMA in NOIRQ still cannot be completely guaranteed.
> >
> > I totally agree your point: use PIO to reduce dependence.
> >
> > If someday EDMA support dev link and move PM callback to NOIRQ stage both,
> this patch can be reverted I think.
> >
> > Carlos
> > > >
> > > > Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for
> > > > LPI2C")
> > > > Signed-off-by: Carlos Song <carlos.song@....com>
> > > > ---
> > > >  drivers/i2c/busses/i2c-imx-lpi2c.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > > > b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > > > index 2a0962a0b441..5050e14a9919 100644
> > > > --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> > > > +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> > > > @@ -592,6 +592,13 @@ static bool is_use_dma(struct
> > > > lpi2c_imx_struct
> > > *lpi2c_imx, struct i2c_msg *msg)
> > > >  	if (!lpi2c_imx->can_use_dma)
> > > >  		return false;
> > > >
> > > > +	/*
> > > > +	 * When system is in suspend process. LPI2C should use PIO to
> > > > +transfer
> > > data to
> > > > +	 * avoid issue caused by not ready DMA HW resource.
> > > > +	 */
> > > > +	if (pm_suspend_in_progress())
> > > > +		return false;
> > > > +
> > > >  	/*
> > > >  	 * When the length of data is less than I2C_DMA_THRESHOLD,
> > > >  	 * cpu mode is used directly to avoid low performance.
> > > > --
> > > > 2.34.1
> > > >