[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8112dfe4-2fae-417b-ac33-bbf8e38da621@amd.com>
Date: Wed, 19 Jun 2024 13:44:31 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Markus Elfring <Markus.Elfring@....de>, linux-pci@...r.kernel.org,
linux-usb@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mathias Nyman <mathias.nyman@...el.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Daniel Drake <drake@...lessos.org>,
Gary Li <Gary.Li@....com>, Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 1/4] PCI: Check PCI_PM_CTRL in pci_dev_wait()
On 6/19/2024 13:33, Markus Elfring wrote:
>> A device that has gone through a reset may return a value in PCI_COMMAND
>> but that doesn't mean it's finished transitioning to D0. On devices that
>> support power management explicitly check PCI_PM_CTRL to ensure the
>> transition happened. Devicees that don't support power management will
>
> Devices?
Yes, thanks. I'll fix that up for the next version once we have some
alignment on the functionality outlined in these patches.
>
>
>> continue to use PCI_COMMAND.
>
> Would the tag “Fixes” be relevant for such a change description?
>
> Regards,
> Markus
I did trace back the history of the wait function and it goes back to
4.6. In my mind yes; it is a fix, but I don't think it should go that
far back automatically. I think we should prioritize getting it fixed
for 6.11 or 6.12 and then can revisit how far back to do a stable backport.
For example AMD Rembrandt (where this race condition was found) isn't
enabled until 5.17 or 5.18 IIRC.
The backports would have a dependency on 08e3ed12ca861 (from 6.5-rc1)
and bae26849372b8 (from 5.5-rc1) and 821cdad5c46ca (from 4.14) and
5adecf817dd63 (from 4.6-rc1).
Powered by blists - more mailing lists