netdev - Re: [PATCH v4 1/3] pm: runtime: Simplify pm_runtime_get_if

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: <20240123214801.GA330312@bhelgaas>
Date: Tue, 23 Jan 2024 15:48:01 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: linux-pm@...r.kernel.org, "Rafael J. Wysocki" <rafael@...nel.org>,
	linux-pci@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Jaroslav Kysela <perex@...ex.cz>,
	Stanislaw Gruszka <stanislaw.gruszka@...ux.intel.com>,
	laurent.pinchart@...asonboard.com, David Airlie <airlied@...il.com>,
	Paul Elder <paul.elder@...asonboard.com>,
	linux-media@...r.kernel.org,
	Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
	intel-gfx@...ts.freedesktop.org,
	Lucas De Marchi <lucas.demarchi@...el.com>,
	Mark Brown <broonie@...nel.org>,
	Jacek Lawrynowicz <jacek.lawrynowicz@...ux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	intel-xe@...ts.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
	Alex Elder <elder@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-sound@...r.kernel.org, Takashi Iwai <tiwai@...e.com>,
	Daniel Vetter <daniel@...ll.ch>, netdev@...r.kernel.org
Subject: Re: [PATCH v4 1/3] pm: runtime: Simplify pm_runtime_get_if_active()
 usage

On Tue, Jan 23, 2024 at 08:44:04PM +0000, Sakari Ailus wrote:
> On Tue, Jan 23, 2024 at 11:24:23AM -0600, Bjorn Helgaas wrote:
> ...

> > - I don't know whether it's feasible, but it would be nice if the
> >   intel_pm_runtime_pm.c rework could be done in one shot instead of
> >   being split between patches 1/3 and 2/3.
> > 
> >   Maybe it could be a preliminary patch that uses the existing
> >   if_active/if_in_use interfaces, followed by the trivial if_active
> >   updates in this patch.  I think that would make the history easier
> >   to read than having the transitory pm_runtime_get_conditional() in
> >   the middle.
> 
> I think I'd merge the two patches. The second patch is fairly small, after
> all, and both deal with largely the same code.

I'm not sure which two patches you mean, but the fact that two patches
deal with largely the same code is not necessarily an argument for
merging them.  From a reviewing perspective, it's nice if a patch like
1/3, where it's largely mechanical and easy to review, is separated
from patches that make more substantive changes.

That's why I think it'd be nice if the "interesting"
intel_pm_runtime_pm.c changes were all in the same patch, and ideally,
if that patch *only* touched intel_pm_runtime_pm.c.

Bjorn