On Saturday, December 28, 2013 07:59:09 PM Greg Kroah-Hartman wrote: > 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.
I will, thanks a lot! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
