From: Christoph Hellwig <hch@infradead.org>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Bjorn Helgaas <helgaas@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: Lost PCIe PME after a914ff2d78ce ("PCI/ASPM: Don't select CONFIG_PCIEASPM by default")
Date: Sat, 30 May 2020 04:33:44 -0700 [thread overview]
Message-ID: <20200530113344.GA2834@infradead.org> (raw)
In-Reply-To: <20200530071434.vjkqxfmgo7xpls6j@srcf.ucam.org>
On Sat, May 30, 2020 at 08:14:34AM +0100, Matthew Garrett wrote:
> On Sat, May 30, 2020 at 08:33:50AM +0200, Heiner Kallweit wrote:
>
> > It *was* default y. This changed with a914ff2d78ce ("PCI/ASPM: Don't
> > select CONFIG_PCIEASPM by default") and that's what triggered the
> > problem. If there's no easy solution, then maybe it's best to revert
> > the change for now.
>
> Oh, sorry, I was looking at mainline. CONFIG_PCIEASPM should
> *definitely* be enabled by default - platforms expect the OS to support
> it. If we want to get rid of default y then I think it'd make more sense
> to have a CONFIG_DISABLE_PCIEASPM that's under EXPERT, and people who
> really want to disable the code can do so.
I think the fact that the EXPERT didn't get removed in the above bug
is a defintive bug. But I'd go further and think the CONFIG_PCIEASPM
option should be removed entirely. There is absolutely no good reason
to not build this small amount of code if PCIe support is enabled.
next prev parent reply other threads:[~2020-05-30 11:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 21:44 Lost PCIe PME after a914ff2d78ce ("PCI/ASPM: Don't select CONFIG_PCIEASPM by default") Heiner Kallweit
2020-05-29 18:50 ` Heiner Kallweit
2020-05-29 19:21 ` Bjorn Helgaas
2020-05-29 19:40 ` Heiner Kallweit
2020-05-29 20:09 ` Heiner Kallweit
2020-05-29 20:21 ` Bjorn Helgaas
2020-05-29 20:53 ` Heiner Kallweit
2020-05-29 20:59 ` Matthew Garrett
2020-05-29 22:26 ` Heiner Kallweit
2020-05-29 22:58 ` Matthew Garrett
2020-05-30 6:33 ` Heiner Kallweit
2020-05-30 7:14 ` Matthew Garrett
2020-05-30 11:33 ` Christoph Hellwig [this message]
2020-06-01 10:58 ` Rafael J. Wysocki
2020-06-01 15:13 ` Bjorn Helgaas
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=20200530113344.GA2834@infradead.org \
--to=hch@infradead.org \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rjw@rjwysocki.net \
/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.