From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CBABDC47DDC for ; Tue, 23 Jan 2024 21:48:09 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 78C6710E1A5; Tue, 23 Jan 2024 21:48:09 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id D3BB110E164; Tue, 23 Jan 2024 21:48:07 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 91A1261F66; Tue, 23 Jan 2024 21:48:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DADADC433C7; Tue, 23 Jan 2024 21:48:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706046483; bh=lCHfHu6EUXojzzHzheXE7xt3G/zJ41N3IKBiY+lqP0k=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=FB8Yh7m8pOYpYOeAiLCyS+voeY7F7smKIjPd1R48tio2TEDLdM6AiEiEqhtBn2q4A vk68s1BpElRSXfqEsy0ZQVB2bgbFpAOMsuj6L+lfCPKDLHFHnZd0SOwD6SKdBHCy1q Tt4isjg3ca4S7YLKd3INw4nVouhbKP86dTgaeSEVG8NanW6zL8IrvCR+n5ZakDH9xG 5rhQeuoRzar3sj6qaZkQNcGT9+tqVWcKcIoAKjxzH7dy4En63k5CCutR8hmFVuCVnB osZb6XsfznsRDMcPdbrjCwBC1bUZeLf6c+iq09L1FsFUNHBOv4VIrMLZZ8r4Esu8mO vGnoJv/BKxZtw== Date: Tue, 23 Jan 2024 15:48:01 -0600 From: Bjorn Helgaas To: Sakari Ailus Subject: Re: [PATCH v4 1/3] pm: runtime: Simplify pm_runtime_get_if_active() usage Message-ID: <20240123214801.GA330312@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Rafael J. Wysocki" , linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org, Jaroslav Kysela , Stanislaw Gruszka , laurent.pinchart@ideasonboard.com, David Airlie , Paul Elder , linux-media@vger.kernel.org, linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org, Lucas De Marchi , linux-sound@vger.kernel.org, Mark Brown , Jacek Lawrynowicz , Rodrigo Vivi , Andy Shevchenko , intel-xe@lists.freedesktop.org, Alex Elder , Greg Kroah-Hartman , Takashi Iwai , Daniel Vetter , netdev@vger.kernel.org Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" 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