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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230825052946.GX3465@black.fi.intel.com>
Date:   Fri, 25 Aug 2023 08:29:46 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Kai-Heng Feng <kai.heng.feng@...onical.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 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.

> 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ