1. 11 3月, 2011 6 次提交
  2. 08 3月, 2011 4 次提交
  3. 07 3月, 2011 3 次提交
  4. 06 3月, 2011 2 次提交
  5. 05 3月, 2011 4 次提交
  6. 04 3月, 2011 6 次提交
  7. 03 3月, 2011 4 次提交
  8. 02 3月, 2011 11 次提交
    • T
      block: add @force_kblockd to __blk_run_queue() · 1654e741
      Tejun Heo 提交于
      __blk_run_queue() automatically either calls q->request_fn() directly
      or schedules kblockd depending on whether the function is recursed.
      blk-flush implementation needs to be able to explicitly choose
      kblockd.  Add @force_kblockd.
      
      All the current users are converted to specify %false for the
      parameter and this patch doesn't introduce any behavior change.
      
      stable: This is prerequisite for fixing ide oops caused by the new
              blk-flush implementation.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      1654e741
    • B
      e1000e: disable broken PHY wakeup for ICH10 LOMs, use MAC wakeup instead · 4def99bb
      Bruce Allan 提交于
      When support for 82577/82578 was added[1] in 2.6.31, PHY wakeup was in-
      advertently enabled (even though it does not function properly) on ICH10
      LOMs.  This patch makes it so that the ICH10 LOMs use MAC wakeup instead
      as was done with the initial support for those devices (i.e. 82567LM-3,
      82567LF-3 and 82567V-4).
      
      [1] commit a4f58f54Reported-by: NAurelien Jarno <aurelien@aurel32.net>
      Cc: <stable@kernel.org>
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4def99bb
    • J
      9dc441f3
    • S
      e1000: fix sparse warning · 2db1badf
      Stephen Hemminger 提交于
      Sparse complains because the e1000 driver is calling ioread on a pointer
      not tagged as __iomem.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Reviewed-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      2db1badf
    • V
      mfd: Avoid tps6586x burst writes · 4b57018d
      vwadekar@nvidia.com 提交于
      tps6586 does not support burst writes. i2c writes have to be
      1 byte at a time.
      
      Cc: stable@kernel.org
      Signed-off-by: NVarun Wadekar <vwadekar@nvidia.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      4b57018d
    • M
      mfd: Don't suspend WM8994 if the CODEC is not suspended · 77bd70e9
      Mark Brown 提交于
      ASoC supports keeping the audio subsysetm active over suspend in order
      to support use cases such as audio passthrough from a cellular modem
      with the main CPU suspended. Ensure that we don't power down the CODEC
      when this is happening by checking to see if VMID is up and skipping
      suspend and resume when it is. If the CODEC has suspended then it'll
      turn VMID off before the core suspend() gets called.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      77bd70e9
    • M
      mfd: Fix DaVinci voice codec device name · 73ee6524
      Manjunathappa, Prakash 提交于
      Fix the device name in DaVinci Voice Codec MFD driver to load
      davinci-vcif and cq93vc codec client drivers.
      Signed-off-by: NManjunathappa, Prakash <prakash.pm@ti.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      73ee6524
    • J
      mfd: Fix NULL pointer due to non-initialized ucb1x00-ts absinfo · 9063f1f1
      Jochen Friedrich 提交于
      Call input_set_abs_params instead of manually setting absbit only.
      This fixes this oops:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000024
      Internal error: Oops: 41b67017 [#1]
      CPU: 0    Not tainted  (2.6.37 #4)
      pc : [<c016d1fc>]    lr : [<00000000>]    psr: 20000093
      sp : c19e5f30  ip : c19e5e6c  fp : c19e5f58
      r10: 00000000  r9 : c19e4000  r8 : 00000003
      r7 : 000001e4  r6 : 00000001  r5 : c1854400  r4 : 00000003
      r3 : 00000018  r2 : 00000018  r1 : 00000018  r0 : c185447c
      Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: c1b6717f  Table: c1b6717f  DAC: 00000017
      Stack: (0xc19e5f30 to 0xc19e6000)
      5f20:                                     00000003 00000003 c1854400 00000013
      5f40: 00000001 000001e4 000001c5 c19e5f80 c19e5f5c c016d5e8 c016cf5c 000001e4
      5f60: c1854400 c18b5860 00000000 00000171 000001e4 c19e5fc4 c19e5f84 c01559a4
      5f80: c016d584 c18b5868 00000000 c1bb5c40 c0035afc c18b5868 c18b5868 c1a55d54
      5fa0: c18b5860 c0155750 00000013 00000000 00000000 00000000 c19e5ff4 c19e5fc8
      5fc0: c0050174 c015575c 00000000 c18b5860 00000000 c19e5fd4 c19e5fd4 c1a55d54
      5fe0: c00500f0 c003b464 00000000 c19e5ff8 c003b464 c00500fc 04000400 04000400
      Backtrace:
      Function entered at [<c016cf50>] from [<c016d5e8>]
      Function entered at [<c016d578>] from [<c01559a4>]
       r8:000001e4 r7:00000171 r6:00000000 r5:c18b5860 r4:c1854400
      Function entered at [<c0155750>] from [<c0050174>]
      Function entered at [<c00500f0>] from [<c003b464>]
       r6:c003b464 r5:c00500f0 r4:c1a55d54
      Code: e59520fc e1a03286 e0433186 e0822003 (e592000c)
      
      >>PC;  c016d1fc <input_handle_event+2ac/5a0>   <=====
      
      Trace; c016cf50 <input_handle_event+0/5a0>
      Trace; c016d5e8 <input_event+70/88>
      Trace; c016d578 <input_event+0/88>
      Trace; c01559a4 <ucb1x00_thread+254/2dc>
      Trace; c0155750 <ucb1x00_thread+0/2dc>
      Trace; c0050174 <kthread+84/8c>
      Trace; c00500f0 <kthread+0/8c>
      Trace; c003b464 <do_exit+0/624>
      Signed-off-by: NJochen Friedrich <jochen@scram.de>
      CC: stable@kernel.org
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      9063f1f1
    • L
    • J
      [CPUFREQ] fix BUG on cpufreq policy init failure · 8f5bc2ab
      Jiri Slaby 提交于
      cpufreq_register_driver sets cpufreq_driver to a structure owned (and
      placed) in the caller's memory. If cpufreq policy fails in its ->init
      function, sysdev_driver_register returns nonzero in
      cpufreq_register_driver. Now, cpufreq_register_driver returns an error
      without setting cpufreq_driver back to NULL.
      
      Usually cpufreq policy modules are unloaded because they propagate the
      error to the module init function and return that.
      
      So a later access to any member of cpufreq_driver causes bugs like:
      BUG: unable to handle kernel paging request at ffffffffa00270a0
      IP: [<ffffffff8145eca3>] cpufreq_cpu_get+0x53/0xe0
      PGD 1805067 PUD 1809063 PMD 1c3f90067 PTE 0
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/devices/virtual/net/tun0/statistics/collisions
      CPU 0
      Modules linked in: ...
      Pid: 5677, comm: thunderbird-bin Tainted: G        W   2.6.38-rc4-mm1_64+ #1389 To be filled by O.E.M./To Be Filled By O.E.M.
      RIP: 0010:[<ffffffff8145eca3>]  [<ffffffff8145eca3>] cpufreq_cpu_get+0x53/0xe0
      RSP: 0018:ffff8801aec37d98  EFLAGS: 00010086
      RAX: 0000000000000202 RBX: 0000000000000000 RCX: 0000000000000001
      RDX: ffffffffa00270a0 RSI: 0000000000001000 RDI: ffffffff8199ece8
      ...
      Call Trace:
       [<ffffffff8145f490>] cpufreq_quick_get+0x10/0x30
       [<ffffffff8103f12b>] show_cpuinfo+0x2ab/0x300
       [<ffffffff81136292>] seq_read+0xf2/0x3f0
       [<ffffffff8126c5d3>] ? __strncpy_from_user+0x33/0x60
       [<ffffffff8116850d>] proc_reg_read+0x6d/0xa0
       [<ffffffff81116e53>] vfs_read+0xc3/0x180
       [<ffffffff81116f5c>] sys_read+0x4c/0x90
       [<ffffffff81030dbb>] system_call_fastpath+0x16/0x1b
      ...
      
      It's all cause by weird fail path handling in cpufreq_register_driver.
      To fix that, shuffle the code to do proper handling with gotos.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NDave Jones <davej@redhat.com>
      8f5bc2ab
    • J
      drm/i915: fix memory corruption with GM965 and >4GB RAM · 6927faf3
      Jan Niehusmann 提交于
      On a Thinkpad x61s, I noticed some memory corruption when
      plugging/unplugging the external VGA connection. The symptoms are that
      4 bytes at the beginning of a page get overwritten by zeroes.
      The address of the corruption varies when rebooting the machine, but
      stays constant while it's running (so it's possible to repeatedly write
      some data and then corrupt it again by plugging the cable).
      
      Further investigation revealed that the corrupted address is
      (dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of
      the hardware status page of the i965 graphics card, cut to 32 bits.
      
      So it seems that for some memory access, the hardware uses only 32 bit
      addressing. If the hardware status page is located >4GB, this
      corrupts unrelated memory.
      Signed-off-by: NJan Niehusmann <jan@gondor.com>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      6927faf3