From: Jiang Liu <liuj97@gmail.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: 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>,
Hanjun Guo <guohanjun@huawei.com>,
Yijing Wang <wangyijing@huawei.com>,
Gong Chen <gong.chen@linux.intel.com>,
Jiang Liu <jiang.liu@huawei.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>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [RFC PATCH v3 00/28] ACPI based system device hotplug framework
Date: Mon, 08 Oct 2012 23:45:49 +0800 [thread overview]
Message-ID: <5072F52D.6090807@gmail.com> (raw)
In-Reply-To: <4290643.jEcV9mqAac@vostro.rjw.lan>
On 10/08/2012 05:47 AM, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday 06 of October 2012 23:27:08 Jiang Liu wrote:
>> The patchset is based on "5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6"
>> from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> And you pull the changeset from git://github.com/jiangliu/linux.git acpihp
>>
>> Modern high-end server may support advanced hotplug features for system
>> devices, including physical processor, memory board, IO extension board
>> and/or computer node. The ACPI specifications have provided standard
>> interfaces between firmware and OS to support device hotplug at runtime.
>> This patch series provide an ACPI based hotplug framework to support system
>> device hotplug at runtime, which will replace current existing ACPI device
>> driver based CPU/memory/CONTAINER hotplug mechanism.
>>
>> The new ACPI system device hotplug framework has following design goals:
>> 1) Provide a mechanism to detect hotplug slots by checking ACPI _EJ0 method,
>> ACPI PRCT (platform RAS capabilities table) and other platform specific
>> mechanisms.
>
> Which of the patches does that?
Hi Rafael,
Thanks for your review:)
Currently we have only implemented slot detection based on _EJ0 method. PRCT is
still in plan because that spec is not in public domain yet, ACPI5.0 only reserves
that key word without any detail information about it:(
The patch 1-4 implement the slot enumeration driver.
>
>> 2) Unify the way to enumerate ACPI based hotplug slots. All hotplug slots
>> will be enumerated by the enumeration driver
>
> What is the enumeration driver?
The enumerator is a driver to create ACPI system device hotplug slots, which
takes following responsibilities:
1) walk the ACPI namespace to scan for hotpug slot with platform specific knowledge.
2) create hotplug slot device for each hotplug slot found, later a hotplug driver
will bind to those hotplug slots.
3) Provide platform specific callback methods to control those hotplug slots,
such as get slot capabilities, power on slot, power off slot etc.
>
>> , instead of by ACPI device drivers.
>> 3) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
>> for system devices will be handled by a generic ACPI hotplug driver,
>> instead of handled by ACPI device drivers.
>
> What are "system devices"
System devices includes CPU, memory, PCI host bridge and node (ACPI module device
contains CPU, memory and/or PCI host bridge).
>
>> 4) Solve dependencies among hotplug slots. You need first to remove the
>> memory device before removing a physical processor if a hotpluggable memory
>> device is connected to a hotpluggable physical processor.
>> 5) Provide better error handling and recover.
>> 6) Provide interface to cancel ongoing hotplug operations. It may take a
>> very long time to remove a memory device, so provide interface to cancel
>> the operation. This is important especially for memory hot-removal.
>> 7) Support new RAS features, such as socket/memory migration.
>> 8) Provide better user interfaces to the hotplug functionalities.
>> 9) Trigger hotplug events/operations by software. This feature is useful
>> for hardware fault management and power saving.
>
> Well, this may or may not be OK. I'm going to review the patches, but I can't
> really say when it's going to happen (not really soon for sure).
>
>> create mode 100644 drivers/acpi/hotplug/slot_fake.c
>> create mode 100644 drivers/acpi/hotplug/state_machine.c
>> create mode 100644 drivers/acpi/hotplug/sysfs.c
>> create mode 100644 include/acpi/acpi_hotplug.h
>> delete mode 100644 include/acpi/container.h
>
> And I seriously think this is too much material for a single patchset.
>
> Please consider splitting it into smaller and well-documented series of
> patches, so that the reviewers can understand things more easily.
Thanks for your advice, I will split them into small groups next time.
The patch set could be divided into four parts:
patch 1-4: implement a ACPI system device hotplug slot enumerator
patch 6-17: implement a hotplug driver to manage all ACPI system device hotplug slots
patch 18-19: refine ACPI container driver to support new hotplug framework
patch 20-28: refine ACPI processor driver to support new hotplug framewor, also with some code cleanup
Thanks
Gerry
prev parent reply other threads:[~2012-10-08 15:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-06 15:27 [RFC PATCH v3 00/28] ACPI based system device hotplug framework Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 01/28] ACPIHP: introduce a framework for ACPI based system device hotplug Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 02/28] ACPIHP: ACPI system device hotplug slot enumerator driver Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 03/28] ACPIHP: detect ACPI hotplug slots by checking ACPI _EJ0 method Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 04/28] ACPIHP: implement a fake ACPI system device hotplug slot enumerator Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 05/28] ACPI: introduce interfaces to manage ACPI device reference count Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 06/28] ACPIHP: introduce interfaces to scan and walk ACPI devices connecting to a slot Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 07/28] ACPIHP: use klist to manage " Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 08/28] ACPIHP: add callbacks into acpi_device_ops to support new hotplug framework Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 09/28] ACPIHP: provide interfaces to associate driver specific data with slots Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 10/28] ACPIHP: implement utility functions to support system device hotplug Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 11/28] ACPIHP: implement skeleton of ACPI system device hotplug driver Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 12/28] ACPIHP: analyse dependencies among ACPI hotplug slots Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 13/28] ACPIHP: provide interface to cancel inprogress hotplug operations Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 14/28] ACPIHP: configure/unconfigure system devices connecting to a hotplug slot Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 15/28] ACPIHP: implement the state machine for ACPI hotplug slots Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 16/28] ACPIHP: implement sysfs interfaces for ACPI system device hotplug Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 17/28] ACPIHP: block ACPI device driver unloading when executing hotplug operations Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 18/28] ACPIHP/container: change ACPI container driver to support new hotplug framework Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 19/28] ACPIHP/container: move container.c into drivers/acpi/hotplug Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 20/28] ACPI/processor: remove dead code from processor_driver.c Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 21/28] ACPIHP/processor: reorganize ACPI processor driver for new hotplug framework Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 22/28] ACPIHP/processor: protect accesses to device->driver_data Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 23/28] ACPIHP/processor: enhance processor driver to support new hotplug framework Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 24/28] CPU: introduce busy flag to temporarily disable CPU online sysfs interface Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 25/28] ACPIHP/processor: reject online/offline requests when doing processor hotplug Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 26/28] ACPI/processor: save parsed APIC ID in processor driver data structure Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 27/28] x86: simplify _acpi_map_lsapic() Jiang Liu
2012-10-06 15:27 ` [RFC PATCH v3 28/28] ACPI/processor: serialize call to acpi_map/unmap_lsapic Jiang Liu
2012-10-07 21:47 ` [RFC PATCH v3 00/28] ACPI based system device hotplug framework Rafael J. Wysocki
2012-10-08 15:45 ` Jiang Liu [this message]
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=5072F52D.6090807@gmail.com \
--to=liuj97@gmail.com \
--cc=bhelgaas@google.com \
--cc=gong.chen@linux.intel.com \
--cc=guohanjun@huawei.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=rjw@sisk.pl \
--cc=robert.moore@intel.com \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=tangchen@cn.fujitsu.com \
--cc=tony.luck@intel.com \
--cc=wangyijing@huawei.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).