1. 22 5月, 2013 1 次提交
  2. 17 4月, 2013 1 次提交
    • D
      TPM: Retry SaveState command in suspend path · 32d33b29
      Duncan Laurie 提交于
      If the TPM has already been sent a SaveState command before the driver
      is loaded it may have problems sending that same command again later.
      
      This issue is seen with the Chromebook Pixel due to a firmware bug in
      the legacy mode boot path which is sending the SaveState command
      before booting the kernel.  More information is available at
      http://crbug.com/203524
      
      This change introduces a retry of the SaveState command in the suspend
      path in order to work around this issue.  A future firmware update
      should fix this but this is also a trivial workaround in the driver
      that has no effect on systems that do not show this problem.
      
      When this does happen the TPM responds with a non-fatal TPM_RETRY code
      that is defined in the specification:
      
        The TPM is too busy to respond to the command immediately, but the
        command could be resubmitted at a later time.  The TPM MAY return
        TPM_RETRY for any command at any time.
      
      It can take several seconds before the TPM will respond again.  I
      measured a typical time between 3 and 4 seconds and the timeout is set
      at a safe 5 seconds.
      
      It is also possible to reproduce this with commands via /dev/tpm0.
      The bug linked above has a python script attached which can be used to
      test for this problem.  I tested a variety of TPMs from Infineon,
      Nuvoton, Atmel, and STMicro but was only able to reproduce this with
      LPC and I2C TPMs from Infineon.
      
      The TPM specification only loosely defines this behavior:
      
        TPM Main Level 2 Part 3 v1.2 r116, section 3.3. TPM_SaveState:
        The TPM MAY declare all preserved values invalid in response to any
        command other than TPM_Init.
      
        TCG PC Client BIOS Spec 1.21 section 8.3.1.
        After issuing a TPM_SaveState command, the OS SHOULD NOT issue TPM
        commands before transitioning to S3 without issuing another
        TPM_SaveState command.
      
        TCG PC Client TIS 1.21, section 4. Power Management:
        The TPM_SaveState command allows a Static OS to indicate to the TPM
        that the platform may enter a low power state where the TPM will be
        required to enter into the D3 power state.  The use of the term "may"
        is significant in that there is no requirement for the platform to
        actually enter the low power state after sending the TPM_SaveState
        command.  The software may, in fact, send subsequent commands after
        sending the TPM_SaveState command.
      
      Change-Id: I52b41e826412688e5b6c8ddd3bb16409939704e9
      Signed-off-by: NDuncan Laurie <dlaurie@chromium.org>
      Signed-off-by: NKent Yoder <key@linux.vnet.ibm.com>
      32d33b29
  3. 05 2月, 2013 6 次提交
  4. 10 10月, 2012 1 次提交
  5. 23 8月, 2012 4 次提交
  6. 11 7月, 2012 1 次提交
  7. 15 2月, 2012 1 次提交
  8. 19 1月, 2012 1 次提交
  9. 16 11月, 2011 5 次提交
  10. 13 7月, 2011 3 次提交
    • S
      tpm_tis: Fix the probing for interrupts · a7b66822
      Stefan Berger 提交于
      This patch fixes several aspects of the probing for interrupts.
      
      This patch reads the TPM's timeouts before probing for the interrupts. The
      tpm_get_timeouts() function is invoked in polling mode and gets the proper
      timeouts from the TPM so that we don't need to fall back to 2 minutes timeouts
      for short duration commands while the interrupt probing is happening.
      
      This patch introduces a variable probed_irq into the vendor structure that gets
      the irq number if an interrupt is received while the the tpm_gen_interrupt()
      function is run in polling mode during interrupt probing. Previously some
      parts of tpm_gen_interrupt() were run in polling mode, then the irq variable
      was set in the interrupt handler when an interrupt was received and execution
      of tpm_gen_interrupt() ended up switching over to interrupt mode.
      tpm_gen_interrupt() execution ended up on an event queue where it eventually
      timed out since the probing handler doesn't wake any queues.
      
      Before calling into free_irq() clear all interrupt flags that may have
      been set by the TPM. The reason is that free_irq() will call into the probing
      interrupt handler and may otherwise fool us into thinking that a real interrupt
      happened (because we see the flags as being set) while the TPM's interrupt line
      is not even connected to anything on the motherboard. This solves a problem
      on one machine I did testing on (Thinkpad T60).
      
      If a TPM claims to use a specifc interrupt, the probing is done as well
      to verify that the interrupt is actually working. If a TPM indicates
      that it does not use a specific interrupt (returns '0'), probe all interrupts
      from 3 to 15.
      Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
      Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      a7b66822
    • S
      tpm_tis: Add timeouts sysfs entry · 62592101
      Stefan Berger 提交于
      Display the TPM's interface timeouts in a 'timeouts' sysfs entry. Display
      the entries as having been adjusted when they were scaled due to their values
      being reported in milliseconds rather than microseconds.
      Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
      Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      62592101
    • S
      tpm_tis: Introduce durations sysfs entry · 04ab2293
      Stefan Berger 提交于
      Display the TPM's command timeouts in a 'durations' sysfs entry. Display
      the entries as having been adjusted when they were scaled due to their values
      being reported in milliseconds rather than microseconds.
      Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
      Tested-by: NGuillaume Chazarain <guichaz@gmail.com>
      Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      04ab2293
  11. 21 2月, 2011 1 次提交
    • L
      Revert "tpm_tis: Use timeouts returned from TPM" · e5871372
      Linus Torvalds 提交于
      This reverts commit 9b29050f.
      
      It has caused hibernate regressions, for example Juri Sladby's report:
      
        "I'm unable to hibernate 2.6.37.1 unless I rmmod tpm_tis:
         [10974.074587] Suspending console(s) (use no_console_suspend to debug)
         [10974.103073] tpm_tis 00:0c: Operation Timed out
         [10974.103089] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -62
         [10974.103095] PM: Device 00:0c failed to freeze: error -62"
      
      and Rafael points out that some of the new conditionals in that commit
      seem to make no sense.  This commit needs more work and testing, let's
      revert it for now.
      Reported-by: NNorbert Preining <preining@logic.at>
      Reported-and-requested-by: NJiri Slaby <jirislaby@gmail.com>
      Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
      Cc: Guillaume Chazarain <guichaz@gmail.com>
      Cc: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e5871372
  12. 11 2月, 2011 1 次提交
  13. 29 11月, 2010 1 次提交
  14. 15 6月, 2010 1 次提交
  15. 03 2月, 2009 2 次提交
  16. 11 10月, 2008 2 次提交
  17. 07 2月, 2008 1 次提交
  18. 23 8月, 2007 1 次提交
  19. 09 5月, 2007 1 次提交
  20. 03 5月, 2007 1 次提交
    • J
      PCI: Cleanup the includes of <linux/pci.h> · 6473d160
      Jean Delvare 提交于
      I noticed that many source files include <linux/pci.h> while they do
      not appear to need it. Here is an attempt to clean it all up.
      
      In order to find all possibly affected files, I searched for all
      files including <linux/pci.h> but without any other occurence of "pci"
      or "PCI". I removed the include statement from all of these, then I
      compiled an allmodconfig kernel on both i386 and x86_64 and fixed the
      false positives manually.
      
      My tests covered 66% of the affected files, so there could be false
      positives remaining. Untested files are:
      
      arch/alpha/kernel/err_common.c
      arch/alpha/kernel/err_ev6.c
      arch/alpha/kernel/err_ev7.c
      arch/ia64/sn/kernel/huberror.c
      arch/ia64/sn/kernel/xpnet.c
      arch/m68knommu/kernel/dma.c
      arch/mips/lib/iomap.c
      arch/powerpc/platforms/pseries/ras.c
      arch/ppc/8260_io/enet.c
      arch/ppc/8260_io/fcc_enet.c
      arch/ppc/8xx_io/enet.c
      arch/ppc/syslib/ppc4xx_sgdma.c
      arch/sh64/mach-cayman/iomap.c
      arch/xtensa/kernel/xtensa_ksyms.c
      arch/xtensa/platform-iss/setup.c
      drivers/i2c/busses/i2c-at91.c
      drivers/i2c/busses/i2c-mpc.c
      drivers/media/video/saa711x.c
      drivers/misc/hdpuftrs/hdpu_cpustate.c
      drivers/misc/hdpuftrs/hdpu_nexus.c
      drivers/net/au1000_eth.c
      drivers/net/fec_8xx/fec_main.c
      drivers/net/fec_8xx/fec_mii.c
      drivers/net/fs_enet/fs_enet-main.c
      drivers/net/fs_enet/mac-fcc.c
      drivers/net/fs_enet/mac-fec.c
      drivers/net/fs_enet/mac-scc.c
      drivers/net/fs_enet/mii-bitbang.c
      drivers/net/fs_enet/mii-fec.c
      drivers/net/ibm_emac/ibm_emac_core.c
      drivers/net/lasi_82596.c
      drivers/parisc/hppb.c
      drivers/sbus/sbus.c
      drivers/video/g364fb.c
      drivers/video/platinumfb.c
      drivers/video/stifb.c
      drivers/video/valkyriefb.c
      include/asm-arm/arch-ixp4xx/dma.h
      sound/oss/au1550_ac97.c
      
      I would welcome test reports for these files. I am fine with removing
      the untested files from the patch if the general opinion is that these
      changes aren't safe. The tested part would still be nice to have.
      
      Note that this patch depends on another header fixup patch I submitted
      to LKML yesterday:
        [PATCH] scatterlist.h needs types.h
        http://lkml.org/lkml/2007/3/01/141Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6473d160
  21. 04 12月, 2006 1 次提交
  22. 16 5月, 2006 1 次提交
  23. 23 4月, 2006 2 次提交