linux-kernel - RE: [PATCH] i2c: imx: add irqf_no

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]

Date:   Fri, 9 Dec 2022 02:37:44 +0000
From:   Clark Wang <xiaoning.wang@....com>
To:     Wolfram Sang <wsa@...nel.org>,
        Oleksij Rempel <o.rempel@...gutronix.de>
CC:     "linux@...pel-privat.de" <linux@...pel-privat.de>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "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: add irqf_no_suspend flag

Hi Wolfram,

> -----Original Message-----
> From: Wolfram Sang <wsa@...nel.org>
> Sent: 2022年12月2日 7:11
> To: Oleksij Rempel <o.rempel@...gutronix.de>
> Cc: Clark Wang <xiaoning.wang@....com>; linux@...pel-privat.de;
> kernel@...gutronix.de; shawnguo@...nel.org; s.hauer@...gutronix.de;
> festevam@...il.com; dl-linux-imx <linux-imx@....com>;
> linux-i2c@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH] i2c: imx: add irqf_no_suspend flag
> 
> On Wed, Nov 16, 2022 at 10:02:49AM +0100, Oleksij Rempel wrote:
> > On Wed, Nov 16, 2022 at 03:44:31PM +0800, Clark Wang wrote:
> > > The i2c irq is masked when user starts an i2c transfer process
> > > during noirq suspend stage. As a result, i2c transfer fails.
> > > To solve the problem, IRQF_NO_SUSPEND is added to i2c bus.
> > >
> > > Signed-off-by: Clark Wang <xiaoning.wang@....com>
> >
> > Acked-by: Oleksij Rempel <o.rempel@...gutronix.de>
> 
> Is this really happening? The driver already implements master_xfer_atomic,
> so I'd suspect it gets called instead?

Yes, you are right!

For the atomic API, I have a question. Will this api be used only in the noirq phase? We have a case that is currently bothering us.

Case description: Use the typec device interrupt pin to wake up the suspend system. We used ptn5110 for typec device. It's an i2c device, configure it via i2c bus.

We found that when the system is in the resume process of wakeup, because the typec interrupt is not disabled during suspend, once the noirq phase is over, it will immediately call i2c xfer to read and write ptn5110 to handle that interrupt. At this time, even resume_early has not been called, that is, the runtime pm of the i2c controller has not been enabled.
We made a workaround to check whether the runtime pm is enabled in i2c xfer. If it is not enabled, temporarily enable it, and call pm_runtime_disable at the end of i2c xfer. However, sometimes the resume_early will be called when the runtime pm is temporarily enabled in this workaround, resulting in an unbalanced enabling of the runtime pm of i2c controller.

Do you think this is a problem? Is the I2C atomic API helpful for this case?

Thank you very much!

Best Regards,
Clark Wang