On Mon, Jan 23, 2017 at 02:19:29PM -0800, Andrey Pronin wrote: > Simplifying to class vs driver handlers, it checks class suspend > first. And if it exists, calls it. Otherwise, it calls driver > suspend. So, it's "either-or", not "first one, then another". > Unless I'm missing something obvious, of course...
I belive the typical approach is that the class handler then chains to the driver handler at the proper point in the shutdown flow. (ie this way class code can execute before and after the driver power management method) > if it is needed. Even if we reverse the order and do "driver > first, and iff it doesn't exist, then class", we'd still > need to create and export 'tpm_shutdown' for drivers to use The purpose of the driver shutdown would be to shutdown the bus, not the chip. So it would be called with ops already disabled by the core code, there is never a reason for a bus driver to call tpm_shutdown. > We can go the register_reboot_notifier() route. Which already > explicitly supports priorites for those notify handlers, so one This is probably OK too, but it just feels weird to ignore the basic core code pattern and fall back to notifiers, but I understand it can be hard to make those changes.. But still worth at least one attempt, IMHO. Jason