[lkml]   [2010]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] tpm_infineon: Fix suspend/resume handler for pnp_driver
Andrew Morton <> writes:

>> With recent quick review, I found the bug of tpm_infineon. (I don't have
>> this device, and compile test only)
> hm. What bug? Is there a bugzilla reference, or do you have a
> description of that bug? Perhaps the device is not functional after
> suspend/resume?

Unfortunately, the thing what I can say for this is small.

With review, it seems anybody doesn't call pnp_driver->driver.suspend/resume().
(pnp_bus calls pnp_device->pnp_driver->suspend/resume())

> This matters because people who are experiencing problems with this
> device will want to know whether this patch is likely to fix them
> (although that'll be pretty obvious in this case).
> It also matters because people (ie: me) will want to know whether the
> bug is sufficiently serious to warrant backporting the fix into earlier
> -stable kernels.

I guess it might be tpm_infineon can't suspend/resume properly. However,
with it, I don't know what happen actually. (it might be, tpm can't
verify the security issue on suspend/resume process? or can't wakeup
from tpm? or spend power? or other?)

> Is the patch actually needed in earlier kernels? It applies cleanly.
> When did this pnp_driver->suspend/resume requirement come about?

With quick search, I found commit 1b8333b02aa281a2849331ad62ee595c46a1c5ac.
It converts tpm from pci to pnp, and start to use

But, I'm not sure there is the actual user of
pnp_driver->driver.suspend/resume() at that commit time.

>> PNP driver must use pnp_driver->suspend/resume anymore.
> I assume this text should have read "PNP driver must use
> pnp_driver->suspend/resume.".

OGAWA Hirofumi <>

 \ /
  Last update: 2010-01-10 00:43    [W:0.030 / U:8.504 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site