On Mon, Apr 11, 2016 at 11:41:24AM +0300, Jarkko Sakkinen wrote: > On Thu, Apr 07, 2016 at 07:36:54AM -0700, Jason Gunthorpe wrote: > > I will have to look closer after the conference, but this does not look > > right. > > > > I vaguely recall commenting on this before. Move the shutdown into the > > core code to fix it. > > This fix that I sent is not the right way to do it. > > One example scenario: > > 1. TIS driver gets detached, which causes tpm_tis_remove() to be called. > 2. Some in-kernel subsystem uses TPM, which should not be done since the > hardware is already unitialized. > 3. The devres subsystem sets ops to NULL. > > Even though the fix is wrong I feel that it might put the rwsem into > question. > > I'm just thinking that maybe there could be a release callback in > tpm_class_ops that could be called by tpm_del_char_device(). There can't > be clients for the chip at that point so no synchronization mechanism > is needed.
As a fix for this regression moving shutdown to tmp_chip_unregister() does make more sense since the patch is already merged to next. Lets not get stuck into locking discussion... /Jarkko
