From: Jiang Liu <jiang.liu@huawei.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
Taku Izumi <izumi.taku@jp.fujitsu.com>,
<linux-pci@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
<kaneshige.kenji@jp.fujitsu.com>
Subject: Re: [PATCH 0/7][RESEND] acpi, pci: hostbridge hotplug support
Date: Fri, 31 Aug 2012 13:19:10 +0800 [thread overview]
Message-ID: <5040494E.8080501@huawei.com> (raw)
In-Reply-To: <CAErSpo6A_rR=5OREu-OC=ykC_qjeGi7jZOybcurUZBThskp-YA@mail.gmail.com>
On 2012-8-31 13:04, Bjorn Helgaas wrote:
> On Thu, Aug 30, 2012 at 6:03 PM, Jiang Liu <jiang.liu@huawei.com> wrote:
>> On 2012-8-31 8:43, Bjorn Helgaas wrote:
>>> On Thu, Aug 30, 2012 at 8:48 AM, Yinghai Lu <yinghai@kernel.org> wrote:
>>>> On Wed, Aug 29, 2012 at 11:23 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>>
>>>>> 1) For patch [1/7], I pointed out that there is currently no way to
>>>>> remove a non-ACPI host bridge, which means the fact that we don't free
>>>>> the pci_sysdata is not really a leak. If you want to add the
>>>>> release_fn so that you can add support for removing and adding these
>>>>> non-ACPI host bridges in the future, I do not understand that. It
>>>>> just doesn't make sense to me to try to support hotplug for those
>>>>> bridges.
>>>>
>>>> for Intel Nehalem and westmere -ex system, there will be root bus from
>>>> 0xf8 to 0xff for cpus.
>>>> and BIOS does not put the in ACPI, but __pci_mmcfg_init will set the
>>>> pcibios_last_bus.
>>>> so those but get probed via pcibios_fixup_peer_bridges.
>>>
>>> I understand how these buses get scanned. What I don't understand is
>>> what value we get from trying to make these buses hot-pluggable.
>>>
>>>> I hope I could use /sys to remove non-acpi root bus.
>>>
>>> Why? I don't think there's any value in being able to remove non-ACPI
>>> host bridges. Any x86 host bridge hotplug that's actually useful to
>>> users will be done via ACPI.
>>>
>>> You mention later that you want to remove these buses because they
>>> only contain CPU devices that don't seem to be good for anything. I
>>> would rather do this by simply not scanning for peer bridges in the
>>> first place. That's simpler than scanning the bridge, deciding we
>>> don't care about what we found, then trying to hot-remove it.
>
>> Actually some memory error handling mechanism may depend on those CPU
>> devices to do memory address decoding. For example, EDAC needs to access
>> them. And we are working on a project to do memory address translation
>> by reading memory controller information from those CPU devices too.
>
> If you depend on those CPU-related PCI devices for EDAC or any other
> reason, your BIOS should expose a host bridge leading to them. If it
> does, we'll enumerate them just like we do today, and whatever host
> bridge hotplug support we add should work for those bridges just like
> any other host bridge.
Yes, BIOS should export those PCI buses for CPU devices through ACPI,
but some legacy hardware platform doesn't do that.
I feel it's not worth to provide hotplug support for those PCI buses too,
it just hides those PCI devices.
--Gerry
next prev parent reply other threads:[~2012-08-31 5:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-10 6:09 [PATCH 0/7][RESEND] acpi, pci: hostbridge hotplug support Taku Izumi
2012-08-10 6:11 ` [PATCH 1/7][RESEND] x86, PCI: Fix non acpi path pci_sysdata leaking with release_fn Taku Izumi
2012-08-16 16:42 ` Bjorn Helgaas
2012-08-10 6:12 ` [PATCH 2/7][RESEND] PCI: Correctly clean up pci root buses in function pci_remove_bus() Taku Izumi
2012-08-16 17:11 ` Bjorn Helgaas
2012-08-30 15:43 ` Jiang Liu
2012-08-10 6:12 ` [PATCH 3/7][RESEND] ACPI, PCI: Use normal list for struct acpi_pci_driver Taku Izumi
2012-08-10 6:13 ` [PATCH 4/7][RESEND] ACPI, PCI: Notify acpi_pci_drivers when hot-plugging PCI root bridges Taku Izumi
2012-08-10 6:14 ` [PATCH 5/7][RESEND] ACPI, PCI: Protect global lists in drivers/acpi/pci_root.c Taku Izumi
2012-08-16 17:25 ` Bjorn Helgaas
2012-08-10 6:14 ` [PATCH 6/7][RESEND] ACPI, PCI: add hostbridge removal function Taku Izumi
2012-08-10 6:15 ` [PATCH 7/7][RESEND] ACPI, PCI: add resoruce-assign code for devices under hot-added hostbridge Taku Izumi
2012-08-10 16:41 ` [PATCH 0/7][RESEND] acpi, pci: hostbridge hotplug support Yinghai Lu
2012-08-20 5:02 ` Taku Izumi
2012-08-30 6:23 ` Bjorn Helgaas
2012-08-30 6:33 ` Jiang Liu
2012-08-30 15:48 ` Yinghai Lu
2012-08-30 16:38 ` Jiang Liu
2012-08-30 17:29 ` Yinghai Lu
2012-08-31 0:43 ` Bjorn Helgaas
2012-08-31 1:03 ` Jiang Liu
2012-08-31 5:04 ` Bjorn Helgaas
2012-08-31 5:19 ` Jiang Liu [this message]
2012-08-31 5:42 ` Bjorn Helgaas
2012-08-31 16:44 ` Yinghai Lu
2012-09-01 3:56 ` Jiang Liu
2012-09-03 2:28 ` Taku Izumi
2012-09-03 4:04 ` Jiang Liu
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=5040494E.8080501@huawei.com \
--to=jiang.liu@huawei.com \
--cc=bhelgaas@google.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=yinghai@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).