On 11/27/2012 09:08 AM, Hanjun Guo wrote:
On 2012/11/26 14:06, Tang Chen wrote:
On 11/26/2012 01:42 PM, Hanjun Guo wrote:
Hi all,
I think Yasuaki mentioned the key point for the container device remove,
that is dependency.
Currently, container, processor, and memory hotpulg are managed by different ACPI
hotplug drivers, the driver works when handle device hotplug individually, but they
have no idea for each other.
This may introduce some issues, such as Yasuaki mentioned above, that is to say, we
should remove its child before remove the device itself, and hot add its parent before
the device itself.
According to the ACPI namespace, we can resolve most of dependency issues. On a typical
two processor sockets system, the namespace is like this:
/_SB ---container device, with HID ACPI0004
|_SCK0 ---container device, with HID ACPI0004
|_CPU0 ---processor device, with HID ACPI0009 or LNXCPU
|_...
|_CPUx
|_MEM0 ---Memory device, with HID PNP0C80
|_SCK1
|_CPU0
|_...
|_CPUx
|_MEM1
|_PCI0 ---Host bridge, with HID PNP0A03 or PNP0A08
If hot remove the container device, such as SCK0, we can easily know the dependency list
is CPU0~CPUx and MEM0, but I think the ACPI hotplug driver haven't resolve this now.
And there is another corner case for hotplug devices in the namespace above, that is:
1) Remove SCK0. yes, we can remove it with no dependency to the host bridge PCI0;
2) Remove SCK1 after SCK0. we should remove the host bridge PCI0 first,
or the system will crash down. yes, dynamic dependency analysis is needed here.
and the ACPI hotplug driver totally have no idea of this.
so, should we do something to settle this down ?
Hi Guo,
I am trying to do this too. :)
Great， what's your idea of this?
Hi Guo,
I noticed they had a lot of discussion on this topic.
https://lkml.org/lkml/2012/11/15/159
And Vasilis's latest patches are here:
https://lkml.org/lkml/2012/11/23/335
I think we can have a review of this patchset first. :)
And also, as you said, the new ACPI hotplug framework from Liu Jiang
will settle this problem more properly.
So I think any solution now could be temporary. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
