From: Bjorn Helgaas <helgaas@kernel.org>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
linux-pci@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-kernel@vger.kernel.org, Vidya Sagar <vidyas@nvidia.com>,
Michael Bottini <michael.a.bottini@linux.intel.com>,
"Limonciello, Mario" <mario.limonciello@amd.com>,
intel-wired-lan@osuosl.org, bhelgaas@google.com,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [Intel-wired-lan] [PATCH] PCI/ASPM: Enable ASPM on external PCIe devices
Date: Wed, 5 Jul 2023 15:06:17 -0500 [thread overview]
Message-ID: <20230705200617.GA72825@bhelgaas> (raw)
In-Reply-To: <CAAd53p5YjKbOkzBUmhu=EctusO7d38tHhg_b+zzvfVt97hLuOA@mail.gmail.com>
On Wed, Jun 28, 2023 at 01:09:49PM +0800, Kai-Heng Feng wrote:
> On Wed, Jun 28, 2023 at 4:54 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Jun 27, 2023 at 04:35:25PM +0800, Kai-Heng Feng wrote:
> > > On Fri, Jun 23, 2023 at 7:06 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Tue, Jun 20, 2023 at 01:36:59PM -0500, Limonciello, Mario wrote:
> > It's perfectly fine for the IP to support PCI features that are not
> > and can not be enabled in a system design. But I expect that
> > strapping or firmware would disable those features so they are not
> > advertised in config space.
> >
> > If BIOS leaves features disabled because they cannot work, but at the
> > same time leaves them advertised in config space, I'd say that's a
> > BIOS defect. In that case, we should have a DMI quirk or something to
> > work around the defect.
>
> That means most if not all BIOS are defected.
> BIOS vendors and ODM never bothered (and probably will not) to change
> the capabilities advertised by config space because "it already works
> under Windows".
This is what seems strange to me. Are you saying that Windows never
enables these power-saving features? Or that Windows includes quirks
for all these broken BIOSes? Neither idea seems very convincing.
> > > So the logic is to ignore the capability and trust the default set
> > > by BIOS.
> >
> > I think limiting ASPM support to whatever BIOS configured at boot-time
> > is problematic. I don't think we can assume that all platforms have
> > firmware that configures ASPM as aggressively as possible, and
> > obviously firmware won't configure hot-added devices at all (in
> > general; I know ACPI _HPX can do some of that).
>
> Totally agree. I was not suggesting to limiting the setting at all.
> A boot-time parameter to flip ASPM setting is very useful. If none has
> been set, default to BIOS setting.
A boot-time parameter for debugging and workarounds is fine. IMO,
needing a boot-time parameter in the course of normal operation is
not OK.
Bjorn
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
linux-pci@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-kernel@vger.kernel.org, Vidya Sagar <vidyas@nvidia.com>,
Michael Bottini <michael.a.bottini@linux.intel.com>,
"Limonciello, Mario" <mario.limonciello@amd.com>,
intel-wired-lan@osuosl.org, bhelgaas@google.com,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [Intel-wired-lan] [PATCH] PCI/ASPM: Enable ASPM on external PCIe devices
Date: Wed, 5 Jul 2023 15:06:17 -0500 [thread overview]
Message-ID: <20230705200617.GA72825@bhelgaas> (raw)
In-Reply-To: <CAAd53p5YjKbOkzBUmhu=EctusO7d38tHhg_b+zzvfVt97hLuOA@mail.gmail.com>
On Wed, Jun 28, 2023 at 01:09:49PM +0800, Kai-Heng Feng wrote:
> On Wed, Jun 28, 2023 at 4:54 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Jun 27, 2023 at 04:35:25PM +0800, Kai-Heng Feng wrote:
> > > On Fri, Jun 23, 2023 at 7:06 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Tue, Jun 20, 2023 at 01:36:59PM -0500, Limonciello, Mario wrote:
> > It's perfectly fine for the IP to support PCI features that are not
> > and can not be enabled in a system design. But I expect that
> > strapping or firmware would disable those features so they are not
> > advertised in config space.
> >
> > If BIOS leaves features disabled because they cannot work, but at the
> > same time leaves them advertised in config space, I'd say that's a
> > BIOS defect. In that case, we should have a DMI quirk or something to
> > work around the defect.
>
> That means most if not all BIOS are defected.
> BIOS vendors and ODM never bothered (and probably will not) to change
> the capabilities advertised by config space because "it already works
> under Windows".
This is what seems strange to me. Are you saying that Windows never
enables these power-saving features? Or that Windows includes quirks
for all these broken BIOSes? Neither idea seems very convincing.
> > > So the logic is to ignore the capability and trust the default set
> > > by BIOS.
> >
> > I think limiting ASPM support to whatever BIOS configured at boot-time
> > is problematic. I don't think we can assume that all platforms have
> > firmware that configures ASPM as aggressively as possible, and
> > obviously firmware won't configure hot-added devices at all (in
> > general; I know ACPI _HPX can do some of that).
>
> Totally agree. I was not suggesting to limiting the setting at all.
> A boot-time parameter to flip ASPM setting is very useful. If none has
> been set, default to BIOS setting.
A boot-time parameter for debugging and workarounds is fine. IMO,
needing a boot-time parameter in the course of normal operation is
not OK.
Bjorn
next prev parent reply other threads:[~2023-07-05 20:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 7:04 [PATCH] PCI/ASPM: Enable ASPM on external PCIe devices Kai-Heng Feng
2023-06-15 14:02 ` Ilpo Järvinen
2023-06-15 17:07 ` Sathyanarayanan Kuppuswamy
2023-06-16 2:37 ` Kai-Heng Feng
2023-06-15 17:12 ` Bjorn Helgaas
2023-06-16 3:01 ` Kai-Heng Feng
2023-06-19 16:16 ` Limonciello, Mario
2023-06-19 21:37 ` Bjorn Helgaas
2023-06-19 22:09 ` Limonciello, Mario
2023-06-20 18:28 ` Bjorn Helgaas
2023-06-20 18:36 ` Limonciello, Mario
2023-06-22 23:06 ` Bjorn Helgaas
2023-06-27 8:35 ` Kai-Heng Feng
2023-06-27 20:54 ` Bjorn Helgaas
2023-06-28 5:09 ` [Intel-wired-lan] " Kai-Heng Feng
2023-06-28 5:09 ` Kai-Heng Feng
2023-07-05 20:06 ` Bjorn Helgaas [this message]
2023-07-05 20:06 ` [Intel-wired-lan] " Bjorn Helgaas
2023-07-06 4:07 ` Mario Limonciello
2023-07-06 4:07 ` Mario Limonciello
2023-07-14 8:17 ` Kai-Heng Feng
2023-07-14 8:17 ` Kai-Heng Feng
2023-07-14 16:37 ` Mario Limonciello
2023-07-14 16:37 ` Mario Limonciello
2023-07-17 3:34 ` Kai-Heng Feng
2023-07-17 3:34 ` Kai-Heng Feng
2023-07-17 16:51 ` Limonciello, Mario
2023-07-17 16:51 ` Limonciello, Mario
2023-07-18 19:24 ` Bjorn Helgaas
2023-07-18 19:24 ` Bjorn Helgaas
2023-08-11 8:34 ` Kai-Heng Feng
2023-08-11 8:34 ` Kai-Heng Feng
2023-06-16 22:01 ` Bjorn Helgaas
2023-06-21 3:08 ` Kai-Heng Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230705200617.GA72825@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=intel-wired-lan@osuosl.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=michael.a.bottini@linux.intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=vidyas@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.