linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiang Liu <jiang.liu@huawei.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <liuj97@gmail.com>, Len Brown <lenb@kernel.org>,
	Tony Luck <tony.luch@intel.com>,
	Bob Moore <robert.moore@intel.com>,
	Huang Ying <ying.huang@intel.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	Taku Izumi <izumi.taku@jp.fujitsu.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-pci@vger.kernel.org, Gaohuai Han <hangaohuai@huawei.com>
Subject: Re: [RFC PATCH 2/3] ACPIHP: ACPI system device hotplug slot enumerator
Date: Sun, 5 Aug 2012 17:36:45 +0800	[thread overview]
Message-ID: <501E3EAD.9090905@huawei.com> (raw)
In-Reply-To: <CAE9FiQU=HmRCy0nxLgi7oqnjbaW4DJ2ct1EE2pVP+=rac2D+wQ@mail.gmail.com>

On 2012-8-5 4:14, Yinghai Lu wrote:
> On Sat, Jul 28, 2012 at 4:42 AM, Jiang Liu <liuj97@gmail.com> wrote:
>> The first is an ACPI hotplug slot enumerator, which enumerates ACPI hotplug
>> slots on load and provides callbacks to manage those hotplug slots.
>> An ACPI hotplug slot is an abstraction of receptacles, where a group of
>> system devices could be connected to. This patch implements the skeleton for
>> ACPI system device hotplug slot enumerator. On loading, the driver scans the
>> whole ACPI namespace for hotplug slots and creates a device node for each
>> hotplug slots. Every slot is associated with a device class named
>> acpihp_slot_class and will be managed by ACPI hotplug drivers.
> 
> I was thinking:
>    We can have module in ACPI DSDT, and every module is coresponding
> to SystemModule.
>    so it will be
> 	\_SB.NOD1
> 		CPU0
> 		CPU1
> 		CPU2
> 		CPU3
> 		MEM0
> 		MEM1
> 		MEM2
> 		MEM3
> 		PCI0
> 		PCI1
> 		PCI2
> 		PCI3
> 		NTFY
> 		STAT
> 		STOP
>     NTFY will be something like:
> 	Notify(\_SB.NOD1.CPU0,....)
> 	Notify(\_SB.NOD1.CPU1,....)
> 	Notify(\_SB.NOD1.CPU2,....)
> 	Notify(\_SB.NOD1.CPU3,....)
> 
> 	Notify(\_SB.NOD1.MEM0,....)
> 	Notify(\_SB.NOD1.MEM1,....)
> 	Notify(\_SB.NOD1.MEM2,....)
> 	Notify(\_SB.NOD1.MEM3,....)
> 
> 	Notify(\_SB.NOD1.PCI0,....)
> 	Notify(\_SB.NOD1.PCI1,....)
> 	Notify(\_SB.NOD1.PCI2,....)
> 	Notify(\_SB.NOD1.PCI3,....)
> 
>    and will link GPE button for SystemModule to call NTFY.
> 
>    STAT could be 32bit integer for final turn off the power.
> 	every CPU, MEM, PCI will own one bit, it will clear that bit in this own
> 	_EJ0.
> 	Every _EJ0 will double check if all are cleared, then it call extra STOP
> 	to power off the whole SystemModule.
> 
> if OS already have seperated handler for those type objects (CPU, MEM,
> PCI),  we may not need to change to much to os.

Hi Yinghai,
	Thanks for your comments.
	It's one of the major concerns that we may need to make too many changes
to existing code, and even break backward compatibilities:(

	There are two possible ways to support hotplug in ACPI BIOS:
	1) send hotplug notifications to each sub-component of an FRU/module.
	2) send hotplug notifications to the FRU itself. 

	We have had discussions with BIOS team and chose to adopt the second 
solution because:
	1) It's more convenient for user to operate on FRUs instead of sub-components.
	2) BIOS will be simpler because it only need to track status of FRU itself
	instead	of sub-components.
	3) It will be much more complex to do error recover if OS/BIOS cooperate on
	sub-component granularity.
	Any suggestions here?
	Regards!
	Gerry

  reply	other threads:[~2012-08-05  9:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-28 11:42 [RFC PATCH 0/3] ACPI based system device hotplug framework Jiang Liu
2012-07-28 11:42 ` [RFC PATCH 1/3] ACPIHP: introduce a framework for ACPI based system device hotplug Jiang Liu
2012-08-02  7:07   ` Tang Chen
2012-08-02  7:07     ` Jiang Liu
2012-07-28 11:42 ` [RFC PATCH 2/3] ACPIHP: ACPI system device hotplug slot enumerator Jiang Liu
2012-08-03  6:10   ` Taku Izumi
2012-08-04  9:40     ` Jiang Liu
2012-08-04 20:14   ` Yinghai Lu
2012-08-05  9:36     ` Jiang Liu [this message]
2012-07-28 11:42 ` [RFC PATCH 3/3] ACPIHP: detect ACPI hotplug slots by checking ACPI _EJ0 method 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=501E3EAD.9090905@huawei.com \
    --to=jiang.liu@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=guohanjun@huawei.com \
    --cc=hangaohuai@huawei.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.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=liuj97@gmail.com \
    --cc=robert.moore@intel.com \
    --cc=tony.luch@intel.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).