From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-pci@vger.kernel.org, "Rob Herring" <robh@kernel.org>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Lukas Wunner" <lukas@wunner.de>,
"Bjorn Helgaas" <bhelgaas@google.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 01/17] PCI: Add concurrency safe clear_and_set variants for LNKCTL{,2}
Date: Thu, 11 May 2023 14:22:52 -0500 [thread overview]
Message-ID: <ZF1AjOKDVlbNFJPK@bhelgaas> (raw)
In-Reply-To: <5140259d-4425-3166-438a-bc9fbbaa49f9@linux.intel.com>
On Thu, May 11, 2023 at 08:35:48PM +0300, Ilpo Järvinen wrote:
> On Thu, 11 May 2023, Bjorn Helgaas wrote:
>
> > On Thu, May 11, 2023 at 04:14:25PM +0300, Ilpo Järvinen wrote:
> > > A few places write LNKCTL and LNKCTL2 registers without proper
> > > concurrency control and this could result in losing the changes
> > > one of the writers intended to make.
> > >
> > > Add pcie_capability_clear_and_set_word_locked() and helpers to use it
> > > with LNKCTL and LNKCTL2. The concurrency control is provided using a
> > > spinlock in the struct pci_dev.
> > >
> > > Suggested-by: Lukas Wunner <lukas@wunner.de>
> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> >
> > Thanks for raising this issue! Definitely looks like something that
> > needs attention.
> >
> > > ---
> > > drivers/pci/access.c | 14 ++++++++++++++
> > > drivers/pci/probe.c | 1 +
> > > include/linux/pci.h | 17 +++++++++++++++++
> > > 3 files changed, 32 insertions(+)
> > >
> > > diff --git a/drivers/pci/access.c b/drivers/pci/access.c
> > > index 3c230ca3de58..d92a3daadd0c 100644
> > > --- a/drivers/pci/access.c
> > > +++ b/drivers/pci/access.c
> > > @@ -531,6 +531,20 @@ int pcie_capability_clear_and_set_dword(struct pci_dev *dev, int pos,
> > > }
> > > EXPORT_SYMBOL(pcie_capability_clear_and_set_dword);
> > >
> > > +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. It would also be nice to preserve the use of
> > PCI_EXP_LNKCTL directly, for grep purposes. And it would obviate the
> > need for some of these patches, e.g., the use of
> > pcie_capability_clear_word(), where it's not obvious at the call site
> > why a change is needed.
>
> There wasn't that big discussion about it (internally). I brought both
> alternatives up and Lukas just said he didn't know what's the best
> approach (+ gave a weak nudge towards the separate accessor so I went
> with it to make forward progress). Based on that I don't think he had a
> strong opinion on it.
>
> I'm certainly fine to just use it in the normal accessor functions that
> do RMW and add the locking there. It would certainly have to those good
> sides you mentioned.
Let's start with that, then.
Many of these are ASPM-related updates that IMHO should not be in
drivers at all. Drivers should use PCI core interfaces so the core
doesn't get confused.
Bjorn
next prev parent reply other threads:[~2023-05-11 19:23 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 13:14 [PATCH 00/17] PCI: Improve LNKCTL & LNKCTL2 concurrency control Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 01/17] PCI: Add concurrency safe clear_and_set variants for LNKCTL{,2} Ilpo Järvinen
2023-05-11 15:55 ` Bjorn Helgaas
2023-05-11 17:35 ` Ilpo Järvinen
2023-05-11 19:22 ` Bjorn Helgaas [this message]
2023-05-11 19:58 ` Ilpo Järvinen
2023-05-11 20:07 ` Lukas Wunner
2023-05-11 20:28 ` Ilpo Järvinen
2023-05-11 22:21 ` Bjorn Helgaas
2023-05-11 21:27 ` Bjorn Helgaas
2023-05-11 20:23 ` Lukas Wunner
2023-05-12 8:25 ` Ilpo Järvinen
2023-05-14 10:10 ` Lukas Wunner
2023-05-15 11:59 ` Ilpo Järvinen
2023-05-15 18:28 ` Bjorn Helgaas
2023-05-15 22:12 ` Lukas Wunner
2023-05-11 13:14 ` [PATCH 02/17] PCI: pciehp: Protect LNKCTL changes Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 03/17] PCI/ASPM: Use pcie_lnkctl_clear_and_set() Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 04/17] drm/amdgpu: Use pcie_lnkctl{,2}_clear_and_set() for changing LNKCTL{,2} Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 05/17] drm/radeon: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 06/17] IB/hfi1: " Ilpo Järvinen
2023-05-11 15:19 ` Dean Luick
2023-05-11 20:02 ` Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 07/17] e1000e: Use pcie_lnkctl_clear_and_set() for changing LNKCTL Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 08/17] net/mlx5: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 09/17] wifi: ath9k: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 10/17] mt76: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 11/17] Bluetooth: hci_bcm4377: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 12/17] misc: rtsx: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 13/17] net/tg3: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 14/17] r8169: " Ilpo Järvinen
2023-05-11 19:49 ` Heiner Kallweit
2023-05-11 20:00 ` Ilpo Järvinen
2023-05-11 20:10 ` Lukas Wunner
2023-05-11 20:11 ` Heiner Kallweit
2023-05-11 20:02 ` Lukas Wunner
2023-05-11 20:17 ` Heiner Kallweit
2023-05-11 13:14 ` [PATCH 15/17] wifi: ath11k: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 16/17] wifi: ath12k: " Ilpo Järvinen
2023-05-11 13:14 ` [PATCH 17/17] wifi: ath10k: " Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZF1AjOKDVlbNFJPK@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=lukas@wunner.de \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox