linux-kernel - Re: [PATCH] i2c: imx-lpi2c: Fix clock count when probe defers

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: <l7meopd4ny4lbux64w5jgyugza3idt4sabwzojmvrafw67fhsw@uf4xbbajzfrj>
Date: Mon, 28 Apr 2025 21:17:09 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Carlos Song <carlos.song@....com>
Cc: Aisheng Dong <aisheng.dong@....com>, Frank Li <frank.li@....com>, 
	"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: Fix clock count when probe defers

Hi Carlos,

> rpm_disable:
> 	pm_runtime_put(&pdev->dev);
> 	pm_runtime_disable(&pdev->dev);
> 	pm_runtime_dont_use_autosuspend(&pdev->dev);
> 
> pm_runtime_put() may not work really sometimes.
> 
> [    3.203715] imx-lpi2c 42530000.i2c: defer probe
> [    3.208324] imx-lpi2c 42530000.i2c: lpi2c_runtime_suspend
> [    3.214801] imx-lpi2c 42540000.i2c: defer probe
> ---> (No lpi2c_runtime_suspend callback(pm_runtime_put() is not really wrok))
> [    3.220672] imx-lpi2c 426c0000.i2c: defer probe
> [    3.225248] imx-lpi2c 426c0000.i2c: lpi2c_runtime_suspend
> 
> After apply this change:
> rpm_disable:
> 	pm_runtime_dont_use_autosuspend(&pdev->dev);
> 	pm_runtime_put_sync(&pdev->dev);
> 	pm_runtime_disable(&pdev->dev);
> 
> all issues gone.
> [    3.093025] imx-lpi2c 42530000.i2c: defer probe
> [    3.097592] imx-lpi2c 42530000.i2c: lpi2c_runtime_suspend
> [    3.104281] imx-lpi2c 42540000.i2c: defer probe
> [    3.108858] imx-lpi2c 42540000.i2c: lpi2c_runtime_suspend
> [    3.115278] imx-lpi2c 426c0000.i2c: defer probe
> [    3.119818] imx-lpi2c 426c0000.i2c: lpi2c_runtime_suspend

Thanks for the explanation. If we lose the count here, I think we
also need for the Fixes tag, do you agree? Should we add:

Fixes: 13d6eb20fc79 ("i2c: imx-lpi2c: add runtime pm support")
Cc: <stable@...r.kernel.org> # v4.16+

as well?

...

> > > Signed-off-by: Carlos Song <carlos.song@....com>
> > > Signed-off-by: Clark Wang <xiaoning.wang@....com>
> > > Signed-off-by: Jun Li <jun.li@....com>
> > > Signed-off-by: Haibo Chen <haibo.chen@....com>
> > 
> > Carlo's SoB should be at the end of the chain. Should be nice to know what these
> > are, though, are they co-developed-by? tested-by?
> > Why so many SoB's?
> > 
> 
> This patch author is not me and they meet similar issue at some boards(Vague history), now
> I meet this issue at new SOC again. I think this local patch is helpful and looks reasonable.
> So I send the patch to community adding my SoB.

So Clark has authored the patch and you have sent it. And your
SoB makes sense (even though, your SoB shoud be placed at the
end, because you sent the patch).

Juan and Haibo have tested it? Reported it?

A practical rule of thumb for tags is that they are placed in
chronological order, e.g.:

 Reported-by: <reporter of the bug>
 Fixes: <commit that introduced the bug>
 Closes: <link where the bug has been reported>
 Co-developed-by: <co-developer>
 Signed-off-by: <co-developer>
 Signed-off-by: <developer>
 Cc: <people who should be aware of the patch>
 Tested-by: <tester>
 Reviewed-by: <reviewer>
 Acked-by: <someone who agrees>
 Signed-off-by: <patch sender>
 Link: <lore link>
 Signed-off-by: <maintainer who applies the patch>

If you notice, more or less things are in chronological order. I
hope this makes it a bit clearer.

Andi