From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: linux-pci@vger.kernel.org, Len Brown <lenb@kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
linux-pm@lists.linux-foundation.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Garrett <mjg@redhat.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [RFC][PATCH] PCI / PCIe: Ask BIOS for control of all native services simultaneously
Date: Tue, 27 Jul 2010 20:31:15 +0200 [thread overview]
Message-ID: <201007272031.15517.rjw@sisk.pl> (raw)
In-Reply-To: <4C4E2BBD.7080003@jp.fujitsu.com>
On Tuesday, July 27, 2010, Kenji Kaneshige wrote:
> Hi,
>
> If I understand your patch correctly, the PCIe port services work
> only when firmware grants all the controls for port services with
> your patch. Correct?
Yes, that's correct.
> I think this will break PCIe services currently working. For example,
> firmware doesn't grant PCIe AER control on my hardware. On the other
> hand, firmware grants PCIe native hot-plug control on the same machine.
> So I think PCIe hot-plug will not work with your patch.
It won't, but the question is if it should. Namely, PCIe native hot-plug
requires control of the PCIe capability structure, which is also used for
AER, so the BIOS granting control of the PCIe capability structure and
not granting control of AER is arguably broken.
> Another example, what would happen on the platform that doesn't have any PCIe
> hot-plug slot? I guess firmware doesn't grant PCIe native hot-plug control on
> that environment. So I think all the other PCIe port services would
> not work on such platform.
You would be surprised. :-)
> My suggestion is that
>
> (1) Query all controls for PCIe port services and see what controls
> will be granted to OS by firmware.
We do that already.
> (2) Request all the controls acquired in step (1) at the same time.
Yes, we can do that, although it would complicate things quite a bit and I'm
not sure that's _really_ necessary, given that all of the native services
require access to the PCIe capability structure and once _that_ is granted,
the BIOS has no reason not to grant any other bits.
> (3) Create PCIe port services for those controls.
I don't really think (3) is necessary in that case. It should be OK not to
load a service driver, in which case the service will simply be disabled.
> What do you think about this?
>
> I think there is still a problem that needs to be addressed. The problem
> is that if ACPIPHP (ACPI based hot-plug driver) is required for PCIe hot-
> plug, all the PCIe port services needs to be disabled. I don't think it
> is acceptable for ACPIPHP users.
I'm not sure what you mean. The $subject patch (rather the last version of it
at https://patchwork.kernel.org/patch/114127/) doesn't change the existing
behavior in that respect other than PCIeHP will not be enabled without PME and
possibly AER.
Certainly, though, our current behavior is wrong, since all of the port service
drivers request OSC_PCI_EXPRESS_CAP_STRUCTURE_CONTROL on their own, which leads
to problems in real systems.
Thanks,
Rafael
next prev parent reply other threads:[~2010-07-27 18:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-24 23:05 Rafael J. Wysocki
2010-07-25 12:23 ` [RFC][PATCH] PCI / PCIe: Ask BIOS for control of all native services at once Rafael J. Wysocki
2010-07-27 0:43 ` [RFC][PATCH] PCI / PCIe: Ask BIOS for control of all native services simultaneously Kenji Kaneshige
2010-07-27 17:18 ` Matthew Garrett
2010-07-27 18:42 ` Rafael J. Wysocki
2010-07-27 18:56 ` Matthew Garrett
2010-07-27 22:55 ` [RFC][PATCH] PCI / PCIe: Ask BIOS for control of all native services at once (v2) Rafael J. Wysocki
2010-07-28 10:59 ` [RFC][PATCH] PCI / PCIe: Ask BIOS for control of all native services at once (v3) Rafael J. Wysocki
2010-07-27 18:31 ` Rafael J. Wysocki [this message]
2010-07-28 3:39 ` [RFC][PATCH] PCI / PCIe: Ask BIOS for control of all native services simultaneously Hidetoshi Seto
2010-07-28 10:49 ` Rafael J. Wysocki
2010-07-28 11:55 ` Matthew Garrett
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=201007272031.15517.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=jbarnes@virtuousgeek.org \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mjg@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®