1. 22 7月, 2011 20 次提交
  2. 19 7月, 2011 4 次提交
  3. 18 7月, 2011 3 次提交
  4. 17 7月, 2011 1 次提交
    • R
      watchdog: hpwdt depends on PCI · f71d26bb
      Randy Dunlap 提交于
      hpwdt is a PCI driver so it should depend on PCI.
      Fixes these build errors:
      
      drivers/watchdog/hpwdt.c:762: error: implicit declaration of function 'pci_iomap'
      drivers/watchdog/hpwdt.c:762: warning: assignment makes pointer from integer without a cast
      drivers/watchdog/hpwdt.c:797: error: implicit declaration of function 'pci_iounmap'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
      Cc: Thomas Mingarelli <thomas.mingarelli@hp.com>
      f71d26bb
  5. 16 7月, 2011 3 次提交
  6. 15 7月, 2011 3 次提交
  7. 14 7月, 2011 6 次提交
    • K
      drm/i915: Add quirk to disable SSC on Lenovo U160 LVDS · 435793df
      Keith Packard 提交于
      We've tried several times to make this machine 'just work', but every
      patch that does causes many other machines to fail. This adds a quirk
      which special cases this hardware and forces ssc to be
      disabled. There's no way to override this from the command line; that
      would be a significantly more invasive change.
      
      This patch fixes #36656 on fdo bugzilla:
      https://bugs.freedesktop.org/show_bug.cgi?id=36656Signed-off-by: NKeith Packard <keithp@keithp.com>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=36656Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      435793df
    • H
      ACPI, APEI, HEST, Detect duplicated hardware error source ID · 4d2b2956
      Huang Ying 提交于
      The firmware on some machine will report duplicated hardware error
      source ID in HEST.  This is considered a firmware bug.  To provide
      better warning message, this patch adds duplicated hardware error
      source ID detecting and corresponding printk.
      
      This patch fixes #37412 on kernel bugzilla:
      https://bugzilla.kernel.org/show_bug.cgi?id=37412
      
      Reported-by: marconifabio@ubuntu-it.org
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Tested-by: NMathias <janedo.spam@gmail.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4d2b2956
    • M
      [media] tuner-core: fix a 2.6.39 regression with mt20xx · a1ad5ec7
      Mauro Carvalho Chehab 提交于
      As Simon reported, digital TV broke with mt20xx tuner due to
      commit ad020dc2.
      
      The mt20xx tuner passes V4L2_TUNER_DIGITAL_TV to tuner core. However, the
      check_mode code now doesn't handle it well. Change the logic there to
      avoid the breakage, and fix a test for analog-only at g_tuner.
      Reported-by: NSimon Arlott <simon@fire.lp0.eu>
      Tested-by: NSimon Arlott <simon@fire.lp0.eu>
      Cc: stable@kernel.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a1ad5ec7
    • D
      [media] dvb_frontend: fix race condition in stopping/starting frontend · 2d196931
      Devin Heitmueller 提交于
      Attached is a patch which addresses a race condition in the DVB core
      related to closing/reopening the DVB frontend device in quick
      succession.  This is the reason that devices such as the HVR-1300,
      HVR-3000, and HVR-4000 have been failing to scan properly under MythTV
      and w_scan.
      
      The gory details of the race are described in the patch.
      
      Devin
      
      There is a race condition exhibited when channel scanners such as w_scan and
      MythTV quickly close and then reopen the frontend device node.
      
      Under normal conditions, the behavior is as follows:
      
      1.  Application closes the device node
      2.  DVB frontend ioctl calls dvb_frontend_release which sets
          fepriv->release_jiffies
      3.  DVB frontend thread *eventually* calls dvb_frontend_is_exiting() which
          compares fepriv->release_jiffies, and shuts down the thread if timeout has
          expired
      4.  Thread goes away
      5.  Application opens frontend device
      6.  DVB frontend ioctl() calls ts_bus_ctrl(1)
      7.  DVB frontend ioctl() creates new frontend thread, which calls
          dvb_frontend_init(), which has demod driver init() routine setup initial
          register state for demod chip.
      8.  Tuning request is issued.
      
      The race occurs when the application in step 5 performs the new open() call
      before the frontend thread is shutdown.  In this case the ts_bus_ctrl() call
      is made, which strobes the RESET pin on the demodulator, but the
      dvb_frontend_init() function never gets called because the frontend thread
      hasn't gone away yet.  As a result, the initial register config for the demod
      is *never* setup, causing subsequent tuning requests to fail.
      
      If there is time between the close and open (enough for the dvb frontend
      thread to be torn down), then in that case the new frontend thread is created
      and thus the dvb_frontend_init() function does get called.
      
      The fix is to set the flag which forces reinitialization if we did in fact
      call ts_bus_ctrl().
      
      This problem has been seen on the HVR-1300, HVR-3000, and HVR-4000, and is
      likely occuring on other designs as well where ts_bus_ctrl() actually strobes
      the reset pin on the demodulator.
      
      Note that this patch should supercede any patches submitted for the
      1300/3000/4000 which remove the code that removes GPIO code in
      cx8802_dvb_advise_acquire(), which have been circulating by users for some
      time now...
      
      Canonical tracking this issue in Launchpad 439163:
      
      Thanks to Jon Sayers from Hauppauge and Florent Audebert from Anevia S.A. for
      providing hardware to test/debug with.
      Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
      Cc: Jon Sayers <j.sayers@hauppauge.co.uk>
      Cc: Florent Audebert <florent.audebert@anevia.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      2d196931
    • R
      [media] media: fix radio-sf16fmr2 build when SND is not enabled · 42a741dc
      Randy Dunlap 提交于
      When CONFIG_SND is not enabled, radio-sf16fmr2 build fails with:
      
      so make this driver depend on SND.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Hans Verkuil <hverkuil@xs4all.nl>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: linux-media@vger.kernel.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      42a741dc
    • P
      mmc: core: Bus width testing needs to handle suspend/resume · f39b2dd9
      Philip Rakity 提交于
      On reading the ext_csd for the first time (in 1 bit mode), save the
      ext_csd information needed for bus width compare.
      
      On every pass we make re-reading the ext_csd, compare the data
      against the saved ext_csd data.
      
      This fixes a regression introduced in 3.0-rc1 by 08ee80cc
      ("mmc: core: eMMC bus width may not work on all platforms"), which
      incorrectly assumed we would be re-reading the ext_csd at resume-
      time.
      Signed-off-by: NPhilip Rakity <prakity@marvell.com>
      Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      f39b2dd9