Hm, according to include/linux/pm.h,
* It is allowed to unregister devices while the above callbacks are being
* executed. However, a callback routine MUST NOT try to
unregister the device
* it was called for, although it may unregister children of that device (for
* example, if it detects that a child was unplugged while the system was
* asleep).
So, it seems if we want to add shutdown to class->pm, we'll need to do
the refactoring for sysfs now to avoid the implicit lock in order to
safely NULL out chip->ops. (Otherwise, I believe we'd need to
unregister.)\\
I'll start work on that, but I wanted to send this email first to
double-check that my understanding was correct and I wasn't missing an
easier path.
Thanks,
Josh
On Fri, May 5, 2017 at 3:46 PM, Jason Gunthorpe
<[email protected]> wrote:
> On Fri, May 05, 2017 at 03:39:01PM -0700, Josh Zimmerman wrote:
>
>> I've seen some reference to the existing `suspend` method as being
>> legacy. e.g., drivers/base/power/main.c:__device_suspend:
>
> I think this is because class->pm is the modern way to do
> class->suspend, not because class methods are legacy.
>
>> In addition, it's not clear to me that the tpm codebase is using
>> class->suspend right now; it looks like for the most part each
>> device
>
> Yes, but that doesn't mean this is the right way to do things, it just
> means this old code hasn't really been updated. The tpm subsystem was
> a total mess just a few years ago, not everything is cleaned up yet..
>
> eg it would probably make much more sense to hook class->pm to do
> tpm_pm_suspend rather than have each driver include the same
> STATIC_DEV_PM_OPS.
>
>> Is there some reason a similar approach of having each driver type
>> register its own shutdown function pointer (that might just all be the
>> same function, much like tpm_pm_suspend) would not be acceptable?
>
> Now that we have so many tpm drivers it is a very good idea not to
> introduce boilerplate into every driver, we should be going the other
> way :)
>
> Jason
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tpmdd-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
