Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 17 11月, 2010 3 次提交
    • A
      USB: EHCI: fix obscure race in ehci_endpoint_disable · 02e2c51b
      由 Alan Stern 提交于 
      This patch (as1435) fixes an obscure and unlikely race in ehci-hcd.
When an async URB is unlinked, the corresponding QH is removed from
the async list.  If the QH's endpoint is then disabled while the URB
is being given back, ehci_endpoint_disable() won't find the QH on the
async list, causing it to believe that the QH has been lost.  This
will lead to a memory leak at best and quite possibly to an oops.

The solution is to trust usbcore not to lose track of endpoints.  If
the QH isn't on the async list then it doesn't need to be taken off
the list, but the driver should still wait for the QH to become IDLE
before disabling it.

In theory this fixes Bugzilla #20182.  In fact the race is so rare
that it's not possible to tell whether the bug is still present.
However, adding delays and making other changes to force the race
seems to show that the patch works.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
CC: David Brownell <david-b@pacbell.net>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      02e2c51b
    • A
      USB: isp1362-hcd - fix section mismatch warning · f52022b5
      由 Axel Lin 提交于 
      Fix section mismatch warning by using "__devinit" annotation for isp1362_probe.

WARNING: drivers/usb/host/isp1362-hcd.o(.data+0x0): Section mismatch in reference from the variable isp1362_driver to the function .init.text:isp1362_probe()
The variable isp1362_driver references
the function __init isp1362_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f52022b5
    • A
      USB: EHCI: AMD periodic frame list table quirk · 3d091a6f
      由 Andiry Xu 提交于 
      On AMD SB700/SB800/Hudson-2/3 platforms, USB EHCI controller may read/write
to memory space not allocated to USB controller if there is longer than
normal latency on DMA read encountered. In this condition the exposure will
be encountered only if the driver has following format of Periodic Frame
List link pointer structure:

For any idle periodic schedule, the Frame List link pointers that have the
T-bit set to 1 intending to terminate the use of frame list link pointer
as a physical memory pointer.

Idle periodic schedule Frame List Link pointer shoule be in the following
format to avoid the issue:

Frame list link pointer should be always contains a valid pointer to a
inactive QHead with T-bit set to 0.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3d091a6f
  3. 16 11月, 2010 2 次提交
    • G
      USB: ehci: fix debugfs 'lpm' permissions · 723b991a
      由 Greg Kroah-Hartman 提交于 
      The permissions for the lpm debugfs file is incorrect, this fixes it.
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Alek Du <alek.du@intel.com>
Cc: Jacob Pan <jacob.jun.pan@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      723b991a
    • S
      xhci: Fix command ring replay after resume. · 89821320
      由 Sarah Sharp 提交于 
      Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.

After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer.  I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.

Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned.  The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.

Here's a log excerpt.  On init, the xHCI driver places a vendor-specific
command on the command ring:

[  215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[  215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[  215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)

When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010.  Instead, it's 0x3781e000:

[  235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[  235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[  235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[  235.557866] usb usb9: root hub lost power or was reset

(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)

The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring.  We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory.  (The pointer isn't required to
be in the suspend power well, but it could be.)  The command ring pointer
is set again after the host resumes.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: NAndiry Xu <andiry.xu@amd.com>
      89821320
  5. 12 11月, 2010 4 次提交
  7. 11 11月, 2010 4 次提交
  9. 30 10月, 2010 1 次提交
    • D
      USB: Add EHCI and OHCH glue for OCTEON II SOCs. · 1643accd
      由 David Daney 提交于 
      The OCTEON II SOC has USB EHCI and OHCI controllers connected directly
to the internal I/O bus.  This patch adds the necessary 'glue' logic
to allow ehci-hcd and ohci-hcd drivers to work on OCTEON II.

The OCTEON normally runs big-endian, and the ehci/ohci internal
registers have host endianness, so we need to select
USB_EHCI_BIG_ENDIAN_MMIO.

The ehci and ohci blocks share a common clocking and PHY
infrastructure.  Initialization of the host controller and PHY clocks
is common between the two and is factored out into the
octeon2-common.c file.

Setting of USB_ARCH_HAS_OHCI and USB_ARCH_HAS_EHCI is done in
arch/mips/Kconfig in a following patch.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
To: linux-usb@vger.kernel.org
To: dbrownell@users.sourceforge.net
Patchwork: http://patchwork.linux-mips.org/patch/1675/Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1643accd
  11. 23 10月, 2010 26 次提交