21 Dec, 2010

1 commit

  • * 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
    Revert "USB: gadget: Allow function access to device ID data during bind()"
    USB: misc: uss720.c: add another vendor/product ID
    USB: usb-storage: unusual_devs entry for the Samsung YP-CP3
    USB: gadget: Remove suspended sysfs file before freeing cdev
    USB: core: Add input prompt and help text for USB_OTG config
    USB: ftdi_sio: Add D.O.Tec PID
    xhci: Fix issue with port array setup and buggy hosts.

    Linus Torvalds
     

17 Dec, 2010

5 commits


15 Dec, 2010

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (75 commits)
    pppoe.c: Fix kernel panic caused by __pppoe_xmit
    WAN: Fix a TX IRQ causing BUG() in PC300 and PCI200SYN drivers.
    bnx2x: Advance a version number to 1.60.01-0
    bnx2x: Fixed a compilation warning
    bnx2x: LSO code was broken on BE platforms
    qlge: Fix deadlock when cancelling worker.
    net: fix skb_defer_rx_timestamp()
    cxgb4vf: Ingress Queue Entry Size needs to be 64 bytes
    phy: add the IC+ IP1001 driver
    atm: correct sysfs 'device' link creation and parent relationships
    MAINTAINERS: remove me from tulip
    SCTP: Fix SCTP_SET_PEER_PRIMARY_ADDR to accpet v4mapped address
    enic: Bug Fix: Pass napi reference to the isr that services receive queue
    ipv6: fix nl group when advertising a new link
    connector: add module alias
    net: Document the kernel_recvmsg() function
    r8169: Fix runtime power management
    hso: IP checksuming doesn't work on GE0301 option cards
    xfrm: Fix xfrm_state_migrate leak
    net: Convert netpoll blocking api in bonding driver to be a counter
    ...

    Linus Torvalds
     

11 Dec, 2010

2 commits


10 Dec, 2010

1 commit

  • Fix two bugs with the port array setup.

    The first bug will only show up with broken xHCI hosts with Extended
    Capabilities registers that have duplicate port speed entries for the same
    port. The idea with the original code was to set the port_array entry to
    -1 if the duplicate port speed entry said the port was a different speed
    than the original port speed entry. That would mean that later, the port
    would not be exposed to the USB core. Unfortunately, I forgot a continue
    statement, and the port_array entry would just be overwritten in the next
    line.

    The second bug would happen if there are conflicting port speed registers
    (so that some entry in port_array is -1), or one of the hardware port
    registers was not described in the port speed registers (so that some
    entry in port_array is 0). The code that sets up the usb2_ports array
    would accidentally claim those ports. That wouldn't really cause any
    user-visible issues, but it is a bug.

    This patch should go into the stable trees that have the port array and
    USB 3.0 port disabling prevention patches.

    Signed-off-by: Sarah Sharp
    Cc: stable@kernel.org

    Sarah Sharp
     

01 Dec, 2010

7 commits


24 Nov, 2010

1 commit

  • * 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
    USB: EHCI: fix obscure race in ehci_endpoint_disable
    USB: gadget: AT91: fix typo in atmel_usba_udc driver
    USB: isp1362-hcd - fix section mismatch warning
    USB: EHCI: AMD periodic frame list table quirk
    USB: OTG: langwell_otg: fix up some sysfs attribute permissions
    USB: misc: usbsevseg: fix up some sysfs attribute permissions
    USB: misc: usbled: fix up some sysfs attribute permissions
    USB: misc: trancevibrator: fix up a sysfs attribute permission
    USB: misc: cypress_cy7c63: fix up some sysfs attribute permissions
    USB: storage: sierra_ms: fix sysfs file attribute
    USB: ehci: fix debugfs 'lpm' permissions
    USB: atm: ueagle-atm: fix up some permissions on the sysfs files
    xhci: Fix command ring replay after resume.
    xHCI: fix wMaxPacketSize mask
    xHCI: release spinlock when setup interrupt
    xhci: Remove excessive printks with shared IRQs.

    Linus Torvalds
     

22 Nov, 2010

4 commits

  • The Inventra DMA engine used with the MUSB controller in many
    SoCs cannot use DMA for control transfers on EP0, but can use
    DMA for all other transfers.

    The USB core maps urbs for DMA if hcd->self.uses_dma is true.
    (hcd->self.uses_dma is true for MUSB as well).

    Split the uses_dma flag into two - one that says if the
    controller needs to use PIO for control transfers, and
    another which says if the controller uses DMA (for all
    other transfers).

    Also, populate this flag for all MUSB by default.

    (Tested on OMAP3 and OMAP4 boards, with EHCI and MUSB HCDs
    simultaneously in use).

    Signed-off-by: Maulik Mankad
    Signed-off-by: Santosh Shilimkar
    Signed-off-by: Anand Gadiyar
    Cc: Oliver Neukum
    Cc: Alan Stern
    Cc: Praveena NADAHALLY
    Cc: Ajay Kumar Gupta
    Signed-off-by: Felipe Balbi

    Anand Gadiyar
     
  • Fixes below compilation warning when musb driver is compiled for
    PIO mode:

    drivers/usb/musb/musb_gadget.c: In function 'musb_g_rx':
    drivers/usb/musb/musb_gadget.c:840:
    warning: label 'exit' defined but not used

    Signed-off-by: Ajay Kumar Gupta
    Signed-off-by: Felipe Balbi

    Ajay Kumar Gupta
     
  • If RXCSR_AUTOCLEAR flag is not cleard before PIO reading, one packet
    may be recieved by musb fifo, but no chance to notify
    software, so cause packet loss, follows the detailed process:

    - PIO read one packet
    - musb fifo auto clear the MUSB_RXCSR_RXPKTRDY
    - musb continue to recieve the next packet, and MUSB_RXCSR_RXPKTRDY
    is set
    - software clear the MUSB_RXCSR_RXPKTRDY, so there is no chance for
    musb to notify software that the 2nd recieved packet.

    The patch does fix the g_ether issue below:

    - use fifo_mode 3 to enable double buffer
    - 'ping -s 1024 IP_OF_BEAGLE_XM'
    - one usb packet of 512 byte is lost, so ping failed,
    which can be observed by wireshark

    note:
    Beagle xm takes musb rtl1.8 and may fallback to pio mode
    for unaligned buffer.

    Signed-off-by: Ming Lei
    Signed-off-by: Felipe Balbi

    Ming Lei
     
  • Buffer is mapped to dma when dma channel is
    allocated. If, for some reason, dma channel
    programming fails, musb code will fallback
    to PIO mode to transfer that request. In
    that case, we need to unmap the buffer
    back to CPU.

    MUSB RTL1.8 and above cannot handle buffers
    which are not 32bit aligned. That happens to
    every request sent by g_ether gadget
    driver. Since the buffer sent was unaligned,
    we need to fallback to PIO.

    Because of that, g_ether was failing due
    to missing buffer unmapping.

    With this patch and [1] g_ether works fine
    with all MUSB revisions.

    Verified with OMAP3630 board, which has
    MUSB RTL1.8 using g_ether and g_zero.

    [1] http://www.spinics.net/lists/linux-usb/msg38400.html

    Signed-off-by: Hema HK
    Signed-off-by: Felipe Balbi

    Hema Kalliguddi
     

20 Nov, 2010

3 commits

  • Disabling SuperSpeed ports is a Very Bad Thing (TM). It disables
    SuperSpeed terminations, which means that devices will never connect at
    SuperSpeed on that port. For USB 2.0/1.1 ports, disabling the port meant
    that the USB core could always get a connect status change later. That's
    not true with USB 3.0 ports.

    Do not let the USB core disable SuperSpeed ports. We can't rely on the
    device speed in the port status registers, since that isn't valid until
    there's a USB device connected to the port. Instead, we use the port
    speed array that's created from the Extended Capabilities registers.

    Signed-off-by: Sarah Sharp
    Tested-by: Don Zickus
    Cc: stable@kernel.org

    Sarah Sharp
     
  • An xHCI host controller contains USB 2.0 and USB 3.0 ports, which can
    occur in any order in the PORTSC registers. We cannot read the port speed
    bits in the PORTSC registers at init time to determine the port speed,
    since those bits are only valid when a USB device is plugged into the
    port.

    Instead, we read the "Supported Protocol Capability" registers in the xHC
    Extended Capabilities space. Those describe the protocol, port offset in
    the PORTSC registers, and port count. We use those registers to create
    two arrays of pointers to the PORTSC registers, one for USB 3.0 ports, and
    another for USB 2.0 ports. A third array keeps track of the port protocol
    major revision, and is indexed with the internal xHCI port number.

    This commit is a bit big, but it should be queued for stable because the "Don't
    let the USB core disable SuperSpeed ports" patch depends on it. There is no
    other way to determine which ports are SuperSpeed ports without this patch.

    Signed-off-by: Sarah Sharp
    Tested-by: Don Zickus
    Cc: stable@kernel.org

    Sarah Sharp
     
  • We have been having problems with the USB-IF Gold Tree tests when plugging
    and unplugging devices from the tree. I have seen that the reset-device
    and configure-endpoint commands, which are invoked from
    xhci_discover_or_reset_device() and xhci_configure_endpoint(), will sometimes
    time out.

    After much debugging, I determined that the commands themselves do not actually
    time out, but rather their completion events do not get delivered to the right
    place.

    This happens when the command ring has just wrapped around, and it's enqueue
    pointer is left pointing to the link TRB. xhci_discover_or_reset_device() and
    xhci_configure_endpoint() use the enqueue pointer directly as their command
    TRB pointer, without checking whether it's pointing to the link TRB.

    When the completion event arrives, if the command TRB is pointing to the link
    TRB, the check against the command ring dequeue pointer in
    handle_cmd_in_cmd_wait_list() fails, so the completion inside the command does
    not get signaled.

    The patch below fixes the timeout problem for me.

    This should be queued for the 2.6.35 and 2.6.36 stable trees.

    Signed-off-by: Paul Zimmerman
    Signed-off-by: Sarah Sharp
    Cc: stable@kernel.org

    Paul Zimmerman
     

18 Nov, 2010

1 commit


17 Nov, 2010

5 commits

  • 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: Alan Stern
    Reported-by: Stefan Richter
    CC: David Brownell
    CC: stable
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     
  • compile fix for bug introduced by 969affff547027)

    Signed-off-by: Josh Wu
    Cc: Jiri Kosina
    Signed-off-by: Greg Kroah-Hartman

    Josh Wu
     
  • 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: Axel Lin
    Acked-by: Mike Frysinger
    Signed-off-by: Greg Kroah-Hartman

    Axel Lin
     
  • 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: Andiry Xu
    Acked-by: David Brownell
    Signed-off-by: Greg Kroah-Hartman

    Andiry Xu
     
  • Move the mid-layer's ->queuecommand() invocation from being locked
    with the host lock to being unlocked to facilitate speeding up the
    critical path for drivers who don't need this lock taken anyway.

    The patch below presents a simple SCSI host lock push-down as an
    equivalent transformation. No locking or other behavior should change
    with this patch. All existing bugs and locking orders are preserved.

    Additionally, add one parameter to queuecommand,
    struct Scsi_Host *
    and remove one parameter from queuecommand,
    void (*done)(struct scsi_cmnd *)

    Scsi_Host* is a convenient pointer that most host drivers need anyway,
    and 'done' is redundant to struct scsi_cmnd->scsi_done.

    Minimal code disturbance was attempted with this change. Most drivers
    needed only two one-line modifications for their host lock push-down.

    Signed-off-by: Jeff Garzik
    Acked-by: James Bottomley
    Signed-off-by: Linus Torvalds

    Jeff Garzik
     

16 Nov, 2010

9 commits