1. 04 10月, 2011 3 次提交
  2. 27 9月, 2011 1 次提交
    • R
      PM / Clocks: Do not acquire a mutex under a spinlock · e8b364b8
      Rafael J. Wysocki 提交于
      Commit b7ab83ed (PM: Use spinlock instead of mutex in clock
      management functions) introduced a regression causing clocks_mutex
      to be acquired under a spinlock.  This happens because
      pm_clk_suspend() and pm_clk_resume() call pm_clk_acquire() under
      pcd->lock, but pm_clk_acquire() executes clk_get() which causes
      clocks_mutex to be acquired.  Similarly, __pm_clk_remove(),
      executed under pcd->lock, calls clk_put(), which also causes
      clocks_mutex to be acquired.
      
      To fix those problems make pm_clk_add() call pm_clk_acquire(), so
      that pm_clk_suspend() and pm_clk_resume() don't have to do that.
      Change pm_clk_remove() and pm_clk_destroy() to separate
      modifications of the pcd->clock_list list from the actual removal of
      PM clock entry objects done by __pm_clk_remove().
      Reported-and-tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e8b364b8
  3. 24 9月, 2011 6 次提交
  4. 23 9月, 2011 7 次提交
    • A
      drm/radeon/kms: fix DDIA enable on some rs690 systems · fdfc6159
      Alex Deucher 提交于
      DVOOutputControl checks the value of of bios scratch reg 3
      on some tables and assumes the encoder is already enabled
      if the DFP2_ACTIVE bit is set.  Clear that bit so the table
      sets the DDIA enable bit properly.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      fdfc6159
    • D
      Revert "drm/radeon/kms: fix typo in r100_blit_copy" · d9ad77eb
      Dave Airlie 提交于
      This reverts commit 18b4fada.
      
      This code was correct, apologies to anyone who noticed things broke.
      
      revert contents are different due to another commit in between.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      d9ad77eb
    • P
      TPM: Zero buffer after copying to userspace · 3321c07a
      Peter Huewe 提交于
      Since the buffer might contain security related data it might be a good idea to
      zero the buffer after we have copied it to userspace.
      
      This got assigned CVE-2011-1162.
      Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      Cc: Stable Kernel <stable@kernel.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      3321c07a
    • P
      TPM: Call tpm_transmit with correct size · 6b07d30a
      Peter Huewe 提交于
      This patch changes the call of tpm_transmit by supplying the size of the
      userspace buffer instead of TPM_BUFSIZE.
      
      This got assigned CVE-2011-1161.
      
      [The first hunk didn't make sense given one could expect
       way less data than TPM_BUFSIZE, so added tpm_transmit boundary
       check over bufsiz instead
       The last parameter of tpm_transmit() reflects the amount
       of data expected from the device, and not the buffer size
       being supplied to it. It isn't ideal to parse it directly,
       so we just set it to the maximum the input buffer can handle
       and let the userspace API to do such job.]
      Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      Cc: Stable Kernel <stable@kernel.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      6b07d30a
    • A
      TPM: tpm_nsc: Fix a double free of pdev in cleanup_nsc · de69113e
      Axel Lin 提交于
      platform_device_unregister() will release all resources
      and remove it from the subsystem, then drop reference count by
      calling platform_device_put().
      
      We should not call kfree(pdev) after platform_device_unregister(pdev).
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      de69113e
    • G
      TPM: TCG_ATMEL should depend on HAS_IOPORT · 5ce5ed35
      Geert Uytterhoeven 提交于
      On m68k, I get:
      
      drivers/char/tpm/tpm_atmel.h: In function ‘atmel_get_base_addr’:
      drivers/char/tpm/tpm_atmel.h:129: error: implicit declaration of function ‘ioport_map’
      drivers/char/tpm/tpm_atmel.h:129: warning: return makes pointer from integer without a cast
      
      The code in tpm_atmel.h supports PPC64 (using the device tree and ioremap())
      and "anything else" (using ioport_map()). However, ioportmap() is only
      available on platforms that set HAS_IOPORT.
      
      Although PC64 seems to have HAS_IOPORT, a "depends on HAS_IOPORT" should work,
      but I think it's better to expose the special PPC64 handling explicit using
      "depends on PPC64 || HAS_IOPORT".
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      5ce5ed35
    • G
      zorro: Defer device_register() until all devices have been identified · a7f4d00a
      Geert Uytterhoeven 提交于
      As the Amiga Zorro II address space is limited to 8.5 MiB and Zorro
      devices can contain only one BAR, several Amiga Zorro II expansion
      boards (mainly graphics cards) contain multiple Zorro devices: a small
      one for the control registers and one (or more) for the graphics memory.
      
      The conversion of cirrusfb to the new driver framework introduced a
      regression: the driver contains a zorro_driver for the first Zorro
      device, and uses the (old) zorro_find_device() call to find the second
      Zorro device.
      
      However, as the Zorro core calls device_register() as soon as a Zorro
      device is identified, it may not have identified the second Zorro device
      belonging to the same physical Zorro expansion card.  Hence cirrusfb
      could no longer find the second part of the Picasso II graphics card,
      causing a NULL pointer dereference.
      
      Defer the registration of Zorro devices with the driver framework until
      all Zorro devices have been identified to fix this.
      
      Note that the alternative solution (modifying cirrusfb to register a
      zorro_driver for all Zorro devices belonging to a graphics card, instead
      of only for the first one, and adding a synchronization mechanism to
      defer initialization until all have been found), is not an option, as on
      some cards one device may be optional (e.g.  the second bank of 2 MiB of
      graphics memory on the Picasso IV in Zorro II mode).
      Reported-by: NIngo Jürgensmann <ij@2011.bluespice.org>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7f4d00a
  5. 22 9月, 2011 5 次提交
  6. 21 9月, 2011 14 次提交
  7. 20 9月, 2011 4 次提交