linux-kernel - Re: [RFC PATCH v2 00/16] ACPI based system device hotplug framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5023D63F.1080502@gmail.com>
Date:	Thu, 09 Aug 2012 23:24:47 +0800
From:	Jiang Liu <liuj97@...il.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	Toshi Kani <toshi.kani@...com>, Jiang Liu <jiang.liu@...wei.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Wen Congyang <wency@...fujitsu.com>,
	Tang Chen <tangchen@...fujitsu.com>,
	Taku Izumi <izumi.taku@...fujitsu.com>,
	Tony Luck <tony.luck@...el.com>,
	Huang Ying <ying.huang@...el.com>,
	Bob Moore <robert.moore@...el.com>,
	Len Brown <lenb@...nel.org>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [RFC PATCH v2 00/16] ACPI based system device hotplug framework

On 08/09/2012 12:27 AM, Bjorn Helgaas wrote:
> On Wed, Aug 8, 2012 at 8:44 AM, Jiang Liu <liuj97@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/