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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5220C77B7C for ; Thu, 11 May 2023 20:23:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239193AbjEKUXh (ORCPT ); Thu, 11 May 2023 16:23:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238381AbjEKUXf (ORCPT ); Thu, 11 May 2023 16:23:35 -0400 Received: from bmailout1.hostsharing.net (bmailout1.hostsharing.net [83.223.95.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49C6549DB; Thu, 11 May 2023 13:23:34 -0700 (PDT) Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 06D00300002CB; Thu, 11 May 2023 22:23:33 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id E47DD160E04; Thu, 11 May 2023 22:23:32 +0200 (CEST) Date: Thu, 11 May 2023 22:23:32 +0200 From: Lukas Wunner To: Bjorn Helgaas Cc: Ilpo =?iso-8859-1?Q?J=E4rvinen?= , linux-pci@vger.kernel.org, Rob Herring , Lorenzo Pieralisi , Krzysztof Wilczy??ski , Bjorn Helgaas , linux-kernel@vger.kernel.org Subject: Re: [PATCH 01/17] PCI: Add concurrency safe clear_and_set variants for LNKCTL{,2} Message-ID: <20230511202332.GD31598@wunner.de> References: <20230511131441.45704-2-ilpo.jarvinen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 11, 2023 at 10:55:06AM -0500, Bjorn Helgaas wrote: > On Thu, May 11, 2023 at 04:14:25PM +0300, Ilpo Järvinen wrote: > > +int pcie_capability_clear_and_set_word_locked(struct pci_dev *dev, int pos, > > + u16 clear, u16 set) > > +{ > > + unsigned long flags; > > + int ret; > > + > > + spin_lock_irqsave(&dev->cap_lock, flags); > > + ret = pcie_capability_clear_and_set_word(dev, pos, clear, set); > > + spin_unlock_irqrestore(&dev->cap_lock, flags); > > + > > + return ret; > > +} > > +EXPORT_SYMBOL(pcie_capability_clear_and_set_word_locked); > > I didn't see the prior discussion with Lukas, so maybe this was > answered there, but is there any reason not to add locking to > pcie_capability_clear_and_set_word() and friends directly? > > It would be nice to avoid having to decide whether to use the locked > or unlocked versions. I think we definitely want to also offer lockless accessors which can be used in hotpaths such as interrupt handlers if the accessed registers don't need any locking (e.g. because there are no concurrent accesses). So the relatively lean approach chosen here which limits locking to Link Control and Link Control 2, but allows future expansion to other registers as well, seemed reasonable to me. Thanks, Lukas