linux-kernel - Re: [PATCH 1/3] PCI: Add helper to check if any of ancestor device support D3cold

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAd53p71gLHq71WtnWBXOaX6K6rXyZ=nrGND5x8ZKXvyNsWBtw@mail.gmail.com>
Date:   Fri, 25 Aug 2023 13:43:08 +0800
From:   Kai-Heng Feng <kai.heng.feng@...onical.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     bhelgaas@...gle.com, koba.ko@...onical.com,
        sathyanarayanan.kuppuswamy@...ux.intel.com,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] PCI: Add helper to check if any of ancestor device
 support D3cold

On Fri, Aug 25, 2023 at 1:29 PM Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
>
> On Thu, Aug 24, 2023 at 09:46:00PM +0800, Kai-Heng Feng wrote:
> > Hi,
> >
> > On Thu, Aug 24, 2023 at 7:57 PM Mika Westerberg
> > <mika.westerberg@...ux.intel.com> wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Aug 24, 2023 at 12:46:43PM +0800, Kai-Heng Feng wrote:
> > > > In addition to nearest upstream bridge, driver may want to know if the
> > > > entire hierarchy can be powered off to perform different action.
> > > >
> > > > So walk higher up the hierarchy to find out if any device has valid
> > > > _PR3.
> > >
> > > I'm not entirely sure this is good idea. The drivers should expect that
> > > the power will be turned off pretty soon after device enters D3hot. Also
> > > _PR3 is not PCI concept it's ACPI concept so API like this would only
> > > work on systems with ACPI.
> >
> > IIUC, Bjorn wants to limit the AER/DPC disablement when device power
> > is really off.
> > Is "the power will be turned off pretty soon after device enters
> > D3hot" applicable to most devices? Since config space is still
> > accessible when device is in D3hot.
>
> Well the device may be part of a topology, say Thunderbolt/USB4 (but can
> be NVMe or similar) where it initially goes into D3hot but in the end
> the whole topology is put into D3cold. The device driver really should
> expect that this happens always and not try to distinguish between the
> D3hot or D3cold.

What if the device is not in such topology? There are cases that the
rootport doesn't have Power Resources associated so the rootport also
stays in D3hot.
I think what Bjorn suggested is to keep AER enabled for D3hot, and
only disable it for D3cold and S3.

>
> > Unless there are cases when device firmware behave differently to
> > D3hot? Then maybe it's better to disable AER for both D3hot, D3cold
> > and system S3.
>
> Yes, this makes sense.

I agree that differentiate between D3hot and D3cold unnecessarily make
things more complicated, but Bjorn suggested errors reported by AER
under D3hot should still be recorded.
Do you have more compelling data to persuade Bjorn that AER should be
disabled for both D3 states?

Kai-Heng