[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230511200244.GA31598@wunner.de>
Date: Thu, 11 May 2023 22:02:44 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
linux-pci@...r.kernel.org, Bjorn Helgaas <helgaas@...nel.org>,
Rob Herring <robh@...nel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Krzysztof Wilczy??ski <kw@...ux.com>, nic_swsd@...ltek.com,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 14/17] r8169: Use pcie_lnkctl_clear_and_set() for
changing LNKCTL
On Thu, May 11, 2023 at 09:49:52PM +0200, Heiner Kallweit wrote:
> On 11.05.2023 15:14, Ilpo Järvinen wrote:
> > Don't assume that only the driver would be accessing LNKCTL. ASPM
> > policy changes can trigger write to LNKCTL outside of driver's control.
> >
> > Use pcie_lnkctl_clear_and_set() which does proper locking to avoid
> > losing concurrent updates to the register value.
>
> Wouldn't it be more appropriate to add proper locking to the
> underlying pcie_capability_clear_and_set_word()?
PCI config space accessors such as this one are also used in hot paths
(e.g. interrupt handlers). They should be kept lean (and lockless)
by default. We only need locking for specific PCIe Extended Capabilities
which are concurrently accessed by PCI core code and drivers.
Thanks,
Lukas
Powered by blists - more mailing lists