linux-kernel - Re: [PATCH v4 0/3] PM: runtime: Auto-cleanup macros for runtime PM

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: <20250929121525.00001775@huawei.com>
Date: Mon, 29 Sep 2025 12:15:25 +0100
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: Linux PM <linux-pm@...r.kernel.org>, Takashi Iwai <tiwai@...e.de>, LKML
	<linux-kernel@...r.kernel.org>, Linux PCI <linux-pci@...r.kernel.org>, "Alex
 Williamson" <alex.williamson@...hat.com>, Bjorn Helgaas <helgaas@...nel.org>,
	Zhang Qilong <zhangqilong3@...wei.com>, Ulf Hansson <ulf.hansson@...aro.org>,
	Frank Li <Frank.Li@....com>, Dhruva Gole <d-gole@...com>
Subject: Re: [PATCH v4 0/3] PM: runtime: Auto-cleanup macros for runtime PM

On Fri, 26 Sep 2025 17:40:29 +0200
"Rafael J. Wysocki" <rafael@...nel.org> wrote:

> Hi All,
> 
> This supersedes
> 
> https://lore.kernel.org/linux-pm/12763087.O9o76ZdvQC@rafael.j.wysocki/
> 
> which was an update of
> 
> https://lore.kernel.org/linux-pm/6204724.lOV4Wx5bFT@rafael.j.wysocki/
> 
> that superseded both
> 
> https://lore.kernel.org/linux-pm/5049058.31r3eYUQgx@rafael.j.wysocki/
> 
> and
> 
> https://lore.kernel.org/linux-pm/20250919163147.4743-1-tiwai@suse.de/
> 
> It follows the Jonathan's suggestion to use ACQUIRE()/ACQUIRE_ERR()
> instead af raw CLASS() to make the code somewhat cleaner.
> 
> Thanks!

Looks excellent to me.  I've already been pointing a few people at this
in driver reviews, so I expect to see a lot of adoption in IIO (and elsewhere).
That RPM_TRANSPARENT handling is particularly nice.

With the tweaks you've already called out.

Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>

Given timing, if this ends up as a next cycle thing please could we have
an immutable branch?  If it is going to make the merge window then no need.

Thanks,

Jonathan