On Monday, November 12, 2012 06:20:47 PM Vasilis Liaskovitis wrote: > On Mon, Nov 12, 2012 at 12:00:55PM +0800, Wen Congyang wrote: > > At 11/09/2012 02:29 AM, Vasilis Liaskovitis Wrote: > > > As discussed in > > > https://patchwork.kernel.org/patch/1581581/ > > > the driver core remove function needs to always succeed. This means we need > > > to know that the device can be successfully removed before acpi_bus_trim / > > > acpi_bus_hot_remove_device are called. This can cause panics when OSPM-initiated > > > eject (echo 1 > /sys/bus/acpi/devices/PNP/eject) of memory devices fails, since > > > the ACPI core goes ahead and ejects the device regardless of whether the memory > > > is still in use or not. > > > > > > For this reason a new acpi_device operation called prepare_remove is introduced. > > > This operation should be registered for acpi devices whose removal (from kernel > > > perspective) can fail. Memory devices fall in this category. > > > > > > acpi_bus_hot_remove_device is changed to handle removal in 2 steps: > > > - preparation for removal i.e. perform part of removal that can fail outside of > > > ACPI core. Should succeed for device and all its children. > > > - if above step was successfull, proceed to actual ACPI removal > > > > If we unbind the device from the driver, we still need to do preparation. But > > you don't do it in your patch. > > yes, driver_unbind breaks with the current patchset. I 'll try to fix and > repost. However, I think this will require a new driver-core wide prepare_remove > callback (not only acpi-specific). I am not sure that would be acceptable. However, you can't break driver_unbind either. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>