From: Jiang Liu <liuj97@gmail.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Toshi Kani <toshi.kani@hp.com>, Jiang Liu <jiang.liu@huawei.com>,
Yinghai Lu <yinghai@kernel.org>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Wen Congyang <wency@cn.fujitsu.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
Taku Izumi <izumi.taku@jp.fujitsu.com>,
Tony Luck <tony.luck@intel.com>,
Huang Ying <ying.huang@intel.com>,
Bob Moore <robert.moore@intel.com>, Len Brown <lenb@kernel.org>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [RFC PATCH v2 00/16] ACPI based system device hotplug framework
Date: Thu, 09 Aug 2012 23:24:47 +0800 [thread overview]
Message-ID: <5023D63F.1080502@gmail.com> (raw)
In-Reply-To: <CAErSpo7S0zuU=tSJVzxk8cPjop0B+JKJjkM46sFCirJCX9KQ2g@mail.gmail.com>
On 08/09/2012 12:27 AM, Bjorn Helgaas wrote:
> On Wed, Aug 8, 2012 at 8:44 AM, Jiang Liu <liuj97@gmail.com> wrote:
>> On 08/08/2012 07:38 AM, Toshi Kani wrote:
>
>>> It is nice to see redundant ACPI namespace walks removed from the ACPI
>>> drivers. But why do you need to add a new enumerator to create the
>>> acpihp_slot tree, in addition to the current acpi_device tree? I'd
>>> prefer hotplug features to be generally integrated into the current ACPI
>>> core code and data structures, instead of adding a new layer on top of
>>> it.
>> The idea comes from PCI hotplug framework, which has an concepts of PCI
>> hotplug slot and PCI device. For system device hotplug, we could follow
>> the same model as PCI by abstracting control points as slots. By introducing
>> of hotplug slot, we could:
>>
>> 1) Report all hotplug slots and slot's capabilities to user, no matter whether
>> there are devices connecting to a slot. If we integrate hotplug functionality
>> into current ACPI device tree, the slot (or device) is only visible when the
>> connected devices are enabled.
>
> In PCI, the idea of a slot is a pretty explicit -- you can look at the
> capabilities of a bridge device and see whether it supports hot-add of
> a device below it. Is it the same way in ACPI? My impression is that
> it is not: there will be a parent ACPI device under which a new device
> can be added, but you might not be able to tell by looking at the
> parent device that hot-add is possible. I thought the platform could
> just give us a Notify event on the parent, asking us to rescan the
> namespace below it and potentially discover new devices.
>
Hi Bjorn,
You are right. With current ACPI V5 specification, we can't get the slot
information from the ACPI namespace, and could only guess that a device with _EJ0
supports hot-add/hot-remove.
Realized that limitation, there's ongoing effort to provide ACPI hotplug
slot (or platform RAS capabilities) information to OS through static ACPI tables,
so OS could enable hotplug and reserve enough resources for system device hotplug.
If that static ACPI table is available, we could construct ACPI hotplug slots from
it.
Regards!
Gerry
next prev parent reply other threads:[~2012-08-09 15:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-04 12:13 [RFC PATCH v2 00/16] ACPI based system device hotplug framework Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 01/16] ACPIHP: introduce a framework for ACPI based system device hotplug Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 02/16] ACPIHP: ACPI system device hotplug slot enumerator Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 03/16] ACPIHP: detect ACPI hotplug slots by checking ACPI _EJ0 method Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 04/16] ACPI: introduce interfaces to manage ACPI device reference count Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 05/16] ACPIHP: scan and walk ACPI devices connecting to an ACPI hotplug slot Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 06/16] ACPIHP: group devices connecting to a hotplug slot according to device types Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 07/16] ACPIHP: add callbacks into acpi_device_ops to support new hotplug framework Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 08/16] ACPIHP: provide interfaces to associate driver specific data to hotplug slots Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 09/16] ACPIHP: implement utility functions to support system device hotplug Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 10/16] ACPIHP: system device hotplug driver skeleton Jiang Liu
2012-08-09 7:12 ` Tang Chen
2012-08-09 7:40 ` Jiang Liu
2012-08-09 8:41 ` Tang Chen
2012-08-09 9:36 ` Jiang Liu
2012-08-10 4:39 ` Tang Chen
2012-08-04 12:13 ` [RFC PATCH v2 11/16] ACPIHP: analyse dependences among ACPI system device hotplug slots Jiang Liu
2012-08-04 12:13 ` [RFC PATCH v2 12/16] ACPIHP: cancel inprogress ACPI system device hotplug operations Jiang Liu
2012-08-04 12:14 ` [RFC PATCH v2 13/16] ACPIHP: configure/unconfigure system devices connecting to a hotplug slot Jiang Liu
2012-08-04 12:14 ` [RFC PATCH v2 14/16] ACPIHP: implement the state machine for ACPI hotplug slots Jiang Liu
2012-08-04 12:14 ` [RFC PATCH v2 15/16] ACPIHP: implement ACPI hotplug sysfs interfaces Jiang Liu
2012-08-04 12:14 ` [RFC PATCH v2 16/16] ACPIHP: enhance ACPI container driver to support new hotplug framework Jiang Liu
2012-08-07 23:38 ` [RFC PATCH v2 00/16] ACPI based system device " Toshi Kani
2012-08-08 15:44 ` Jiang Liu
2012-08-08 16:27 ` Bjorn Helgaas
2012-08-09 15:24 ` Jiang Liu [this message]
2012-08-08 21:05 ` Toshi Kani
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=5023D63F.1080502@gmail.com \
--to=liuj97@gmail.com \
--cc=bhelgaas@google.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=jiang.liu@huawei.com \
--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=robert.moore@intel.com \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=tangchen@cn.fujitsu.com \
--cc=tony.luck@intel.com \
--cc=toshi.kani@hp.com \
--cc=wency@cn.fujitsu.com \
--cc=ying.huang@intel.com \
--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).