On Wed, Jul 16, 2014 at 11:08 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> I am not so much concerned about userspace, but about reusing of as >> much of existing PM framework in the drivers. Right now it is very >> hard to correctly track dependencies between general open/close, >> system suspend/resume, and various runtime-PM transitions. Adding yet >> another PM mechanism into the mix will just add more complexity. > > Would it make sense to unbind the drivers for these devices when the > lid is closed? With the drivers gone, there would naturally be no I/O > interactions with the hardware and the class devices would disappear. FWIW, per your earlier recommendation[1], that is the approach that my group has been using to disable various host controllers when Linux is running (not suspended) but certain power-hungry peripherals are not needed. It has mostly worked out OK; each driver typically implements its own special PHY init/shutdown procedure, and calls into the common clk_* functions to enable/disable the appropriate clocks. Obviously the application needs to be able to cope with disappearing devices, and you wouldn't want to have any filesystems mounted on top of them when the unbind event happens. Our devices are on an SoC's internal bus, not PCI. [1] http://lists.linuxfoundation.org/pipermail/linux-pm/2012-April/033976.html -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
