On Fri, Dec 27, 2013 at 11:21:59PM +0100, Rafael J. Wysocki wrote: > Hi Greg, > > The following series of 2 patches (patch [2/2] in particular) make changes > needed to handle hot-removal of system container devices (represented by > ACPI container and module device objects) on Fujitsu systems. Those devices > represent things like CPU packages, so we need to be able to take care of them > cleanly for things like in-the-field CPU socked replacement to work. > > The problem being addressed here is that on the systems in question the removal > of container devices has to be carried out with the help of user space that > needs to be notified of the container removal before the kernel attempts to > offline any devices below the container (e.g. in the package represented by the > container device object in the ACPI tables). However, our current code works > the other way around and the entire thing is messed up. > > This patchset adds the bare bones of what's needed to address that issue and it > should be possible to build on top of the code added by it in the future if > need be. > > Patch [1/2] introduces a new demand_offline flag for struct acpi_hotplug_profile > that makes acpi_scan_hot_remove() check the offline status of the device object's > companion physical devices to start with and return -EBUSY if at least one of them > is not offline. > > Patch [2/2] uses that flag to implement the container handling. The details are > in the changelog, but that's how it works. > > During the initial namespace scan the container ACPI scan handler creates > "physical" system container device under /sys/devices/system/container/ for > each ACPI container object whose status is "present" at that time (the sysfs > name of that device is the same as the sysfs name of the corresponding > container object and they are linked to each other via the firmware_node and > physical_node symbolic links, respectively). Those system container devices > are initially online. > > The container ACPI scan handler has the demand_offline flag set in its hotplug > profile, so when a container eject event happens, acpi_scan_hot_remove() will > notice that the flag is set in the device object's scan handler and will > check the online status of its "physical" companion device, which is online > (that is the system container device the above paragraph is about). That will > cause KOBJ_CHANGE to be emitted for the system container device and -EBUSY to > be returned by acpi_scan_hot_remove(). User space is expected to respond to > that KOBJ_CHANGE by doing what's necessary to remove the container. > > To that end, it needs to offline the system container device through its online > sysfs attribute (which is present, because the bus type for containers provides > the online and offline callbacks). However, the offline for system container > devices will only succeed if the physical devices right below the container > (e.g. in the package represented by it) are all offline, so user space will > have to offline those devices before attempting to offline the system container > device itself. When finished, user space can trigger the container removal > with the help of the eject sysfs attribute of the ACPI container object pointed > to by the system container device's firmware_node link (this time the check in > acpi_scan_hot_remove() will succeed, because the system container device in > question is now offline). > > Please let me know if you have any objections. If not, I'd like to queue up > these patches for 3.14. No objection from me, I've acked the second patch, feel free to take both of them in your tree. thanks, greg k-h -- 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
