Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 7月, 2013 19 次提交
  3. 26 7月, 2013 13 次提交
  5. 25 7月, 2013 8 次提交
    • L
      pinctrl: fix a memleak when freeing maps · db6c2c69
      由 Linus Walleij 提交于 
      We forgot to free the node itself when free:ing a map.
Reported-by: Nxulinuxkernel <xulinuxkernel@gmail.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      db6c2c69
    • O
      xhci: fix null pointer dereference on ring_doorbell_for_active_rings · d66eaf9f
      由 Oleksij Rempel 提交于 
      in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.

This patch should be backported to kernels as old as 2.6.35, that
contain the commit e9df17eb "USB: xhci:
Correct assumptions about number of rings per endpoint"
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      d66eaf9f
    • G
      usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 · 07f3cb7c
      由 George Cherian 提交于 
      Xhci controllers with hci_version > 0.96 gives spurious success
events on short packet completion. During webcam capture the
"ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.

Note from Sarah:

The xHCI 1.0 spec changed how hardware handles short packets.  The HW
will notify SW of the TRB where the short packet occurred, and it will
also give a successful status for the last TRB in a TD (the one with the
IOC flag set).  On the second successful status, that warning will be
triggered in the driver.

Software is now supposed to not assume the TD is not completed until it
gets that last successful status.  That means we have a slight race
condition, although it should have little practical impact.  This patch
papers over that issue.

It's on my long-term to-do list to fix this race condition, but it is a
much more involved patch that will probably be too big for stable.  This
patch is needed for stable to avoid serious log spam.

This patch should be backported to kernels as old as 3.0, that
contain the commit ad808333 "Intel xhci:
Ignore spurious successful event."

The patch will have to be modified for kernels older than 3.2, since
that kernel added the xhci_gen_setup function for xhci platform devices.
The correct conflict resolution for kernels older than 3.2 is to set
XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts.
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
      07f3cb7c
    • R
      usb: fix build warning in pci-quirks.h when CONFIG_PCI is not enabled · c4d949b7
      由 Randy Dunlap 提交于 
      Fix warning when CONFIG_PCI is not enabled
(from commit 29636578).

drivers/usb/host/pci-quirks.h: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c4d949b7
    • O
      usb: xhci: Mark two functions __maybe_unused · d5c82feb
      由 Olof Johansson 提交于 
      Resolves the following build warnings:
drivers/usb/host/xhci.c:332:13: warning: 'xhci_msix_sync_irqs' defined but not used [-Wunused-function]
drivers/usb/host/xhci.c:3901:12: warning: 'xhci_change_max_exit_latency' defined but not used [-Wunused-function]

These functions are not always used, and since they're marked static
they will produce build warnings:
- xhci_msix_sync_irqs is only used with CONFIG_PCI.
- xhci_change_max_exit_latency is a little more complicated with
  dependencies on CONFIG_PM and CONFIG_PM_RUNTIME.

Instead of building a bigger maze of ifdefs in this code, I've just
marked both with __maybe_unused.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d5c82feb
    • S
      xhci: Avoid NULL pointer deref when host dies. · 203a8661
      由 Sarah Sharp 提交于 
      When the host controller fails to respond to an Enable Slot command, and
the host fails to respond to the register write to abort the command
ring, the xHCI driver will assume the host is dead, and call
usb_hc_died().

The USB device's slot_id is still set to zero, and the pointer stored at
xhci->devs[0] will always be NULL.  The call to xhci_check_args in
xhci_free_dev should have caught the NULL virt_dev pointer.

However, xhci_free_dev is designed to free the xhci_virt_device
structures, even if the host is dead, so that we don't leak kernel
memory.  xhci_free_dev checks the return value from the generic
xhci_check_args function.  If the return value is -ENODEV, it carries on
trying to free the virtual device.

The issue is that xhci_check_args looks at the host controller state
before it looks at the xhci_virt_device pointer.  It will return -ENIVAL
because the host is dead, and xhci_free_dev will ignore the return
value, and happily dereference the NULL xhci_virt_device pointer.

The fix is to make sure that xhci_check_args checks the xhci_virt_device
pointer before it checks the host state.

See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
further details.  This patch doesn't solve the underlying issue, but
will ensure we don't see any more NULL pointer dereferences because of
the issue.

This patch should be backported to kernels as old as 3.1, that
contain the commit 7bd89b40 "xhci: Don't
submit commands or URBs to halted hosts."
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NVincent Thiele <vincentthiele@gmail.com>
Cc: stable@vger.kernel.org
      203a8661
    • J
      drm/i915: initialize gt_lock early with other spin locks · 14c5cec5
      由 Jani Nikula 提交于 
      commit 181d1b9e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 21 13:16:24 2013 +0200

    drm/i915: fix up gt init sequence fallout

moved dev_priv->gt_lock initialization after use. Do the initialization
much earlier with other spin lock initializations.
Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Cc: stable@vger.kernel.org (since the regressing patch is also cc: stable)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      14c5cec5
    • N
      md/raid5: fix interaction of 'replace' and 'recovery'. · f94c0b66
      由 NeilBrown 提交于 
      If a device in a RAID4/5/6 is being replaced while another is being
recovered, then the writes to the replacement device currently don't
happen, resulting in corruption when the replacement completes and the
new drive takes over.

This is because the replacement writes are only triggered when
's.replacing' is set and not when the similar 's.sync' is set (which
is the case during resync and recovery - it means all devices need to
be read).

So schedule those writes when s.replacing is set as well.

In this case we cannot use "STRIPE_INSYNC" to record that the
replacement has happened as that is needed for recording that any
parity calculation is complete.  So introduce STRIPE_REPLACED to
record if the replacement has happened.

For safety we should also check that STRIPE_COMPUTE_RUN is not set.
This has a similar effect to the "s.locked == 0" test.  The latter
ensure that now IO has been flagged but not started.  The former
checks if any parity calculation has been flagged by not started.
We must wait for both of these to complete before triggering the
'replace'.

Add a similar test to the subsequent check for "are we finished yet".
This possibly isn't needed (is subsumed in the STRIPE_INSYNC test),
but it makes it more obvious that the REPLACE will happen before we
think we are finished.

Finally if a NeedReplace device is not UPTODATE then that is an
error.  We really must trigger a warning.

This bug was introduced in commit 9a3e1101
(md/raid5:  detect and handle replacements during recovery.)
which introduced replacement for raid5.
That was in 3.3-rc3, so any stable kernel since then would benefit
from this fix.

Cc: stable@vger.kernel.org (3.3+)
Reported-by: Nqindehua <13691222965@163.com>
Tested-by: Nqindehua <qindehua@163.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      f94c0b66