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. Thanks, Rafael -- 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
