From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E940726A08F; Tue, 11 Feb 2025 23:16:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739315809; cv=none; b=qkFIZccYC/Va3QL5lHZq+HSR14Rwog0uSECaZoaXQaCNq+Banu1TubhQhHxoBly1/OvkAHhvHMOJo1xmzP2N98+Qxb4k7u+9OLmRfYfTk/d03QNbulFJ4vUaV7lsrd9E/CcIrj02zF9nH5rbl/PlysZ2mHzOGPJgsl38cxZc+hE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739315809; c=relaxed/simple; bh=3zTpwPVBu5FhsZX4yiDd5kXq166OpvaNogmElK6aTus=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=ja4KmqyQGro7DhUzxizSEdtBgbeY96e+AUG54pGutGaB+QG+ppTdgunfZOhigc+vXQA9Uqay5Ud1EvYwBPu5o6hsgrHWm0XpvIpWOhNJSn8Ay6nnOXn0ZOb1kgacjbmSuUYC7D3Ngode17kaWlA2DDz2AT6MN+60Z1tZs0Pmcxo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bttBPPcj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bttBPPcj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 218A4C4CEE2; Tue, 11 Feb 2025 23:16:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739315808; bh=3zTpwPVBu5FhsZX4yiDd5kXq166OpvaNogmElK6aTus=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=bttBPPcjLAml4vtqknB3/v0wkFPPoVEK8XZ2S+iaArQyIcmJF8Ai/gxtHPWBlHF3G /7ZI0j7SBZCnw4BO85GshXa2qKk0PRM0mIYpBXsM58GxjFQ3p61g/k1AqIuyXtdZ1w flr6BOMRxeRTC8IjVyv45+6xPabbmlmqEsa8jJtZFXZuLmckds/S/wFbauFftMY9Vs uzKGfSWphT53CgHR7Bn3D6yDJkbxlE1psObKa1cNbjLh4EW/Yfwba9BJLQR/lUPGUO pHz5o5yVMm5YY/foY11CLPaxo19JesEZ9IJCAs3CC9vjBsOvlbP5c1x/G+Htn1Pr94 aIcSdF5qBOUwA== Date: Tue, 11 Feb 2025 17:16:46 -0600 From: Bjorn Helgaas To: Markus Elfring Cc: Thippeswamy Havalige , linux-pci@vger.kernel.org, kernel-janitors@vger.kernel.org, LKML , devicetree@vger.kernel.org, Rob Herring , Bharat Kumar Gogada , Bjorn Helgaas , Conor Dooley , Jingoo Han , Krzysztof Kozlowski , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Lorenzo Pieralisi , Manivannan Sadhasivam , Michal Simek , Peter Zijlstra Subject: Re: [v8 3/3] PCI: amd-mdb: Add AMD MDB Root Port driver Message-ID: <20250211231646.GA58828@bhelgaas> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60c5504d-341f-4ce5-b337-1eca92a9506f@web.de> On Fri, Feb 07, 2025 at 07:39:03AM +0100, Markus Elfring wrote: > > I don't *really* like guard() anyway because it's kind of magic in > > that the unlock doesn't actually appear in the code, and it's kind of > > hard to unravel what guard() is and how it works. But I guess that's > > mostly because it's just a new idiom that takes time to internalize. > > How will the circumstances evolve further for growing applications of > scope-based resource management? I'm sure it will evolve to become the typical style. Right now, it's not quite there yet, as evidenced by the fact that the only reference to them in Documentation/ is this somewhat ambivalent note: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/maintainer-netdev.rst?id=v6.13#n380 We do already have a few uses of guard() and scoped_guard() in drivers/pci, and I don't really object to more, including in this amd-mdb case. Whatever we do, I *would* want to do it consistently throughout the file. Bjorn