[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f96e4a8a-1b69-a783-d1ca-7d8e48100954@gmail.com>
Date: Thu, 11 May 2023 22:11:32 +0200
From: Heiner Kallweit <hkallweit1@...il.com>
To: Lukas Wunner <lukas@...ner.de>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: 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 <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 14/17] r8169: Use pcie_lnkctl_clear_and_set() for changing
LNKCTL
On 11.05.2023 22:10, Lukas Wunner wrote:
> On Thu, May 11, 2023 at 11:00:02PM +0300, Ilpo Järvinen wrote:
>> On Thu, 11 May 2023, 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()?
>>
>> As per discussion for the other patch, that's where this series is now
>> aiming to in v2.
>
> That discussion wasn't cc'ed to Heiner. For reference, this is the
> message Ilpo is referring to:
>
> https://lore.kernel.org/linux-pci/ZF1AjOKDVlbNFJPK@bhelgaas/
Thanks for the link!
Powered by blists - more mailing lists