Skip to content

L
linux
Switch branch/tag
  1. 01 Dec, 2009 5 commits
    • Ajay Kumar Gupta's avatar
      USB: musb: Remove unwanted message in boot log · 1230435c
      Ajay Kumar Gupta authored 
      Removes below unnecessary log of almost 28 lines during boot.

musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
...
...
musb_hdrc: hw_ep 13shared, max 4096
musb_hdrc: hw_ep 14shared, max 1024
musb_hdrc: hw_ep 15shared, max 1024
Signed-off-by: default avatarAjay Kumar Gupta <ajay.gupta@ti.com>
Acked-by: default avatarFelipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1230435c
    • Thomas Dahlmann's avatar
      usb: amd5536udc: fixed shared interrupt bug and warning oops · c5deb832
      Thomas Dahlmann authored 
      - fixed shared interrupt bug reported by Vadim Lobanov
 - fixed possible warning oops on driver unload when connected
 - prevent interrupt flood in PIO mode ("modprobe amd5536udc use_dma=0")
   when using gadget ether
Signed-off-by: default avatarThomas Dahlmann <dahlmann.thomas@arcor.de>
Cc: Robert Richter <robert.richter@amd.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c5deb832
    • Eric W. Biederman's avatar
      USB: ftdi_sio: Keep going when write errors are encountered. · 0de6ab8b
      Eric W. Biederman authored 
      The use of urb->actual_length to update tx_outstanding_bytes
implicitly assumes that the number of bytes actually written is the
same as the number of bytes we tried to write.  On error that
assumption is violated so just use transfer_buffer_length the number
of bytes we intended to write to the device.

If an error occurs we need to fall through and call
usb_serial_port_softint to wake up processes waiting in
tty_wait_until_sent.
Signed-off-by: default avatarEric W. Biederman <ebiederm@aristanetworks.com>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0de6ab8b
    • Sergei Shtylyov's avatar
      USB: musb_gadget: fix STALL handling · cea83241
      Sergei Shtylyov authored 
      The driver incorrectly cancels the mass-storage device CSW request
(which leads to device reset) due to giving back URB at the head of
endpoint's queue after sending each STALL handshake; stop doing that
and start checking for the queue being non-empty before stalling an
endpoint and disallowing stall in such case in musb_gadget_set_halt()
like the other gadget drivers do.

Moreover, the driver starts Rx request despite of the endpoint being
halted -- fix this by moving the SendStall bit check from musb_g_rx()
to rxstate().  And we also sometimes get into rxstate() with DMA still
active after clearing an endpoint's halt (not clear why), so bail out
in this case, similarly to what txstate() does...

While at it, also do the following changes :

- in musb_gadget_set_halt(), remove pointless Tx FIFO flushing (the
  driver does not allow stalling with non-empty Tx FIFO anyway);

- in rxstate(), stop pointlessly zeroing the 'csr' variable;

- in musb_gadget_set_halt(), move the 'done' label to a more proper
  place;

- in musb_g_rx(), eliminate the 'done' label completely...
Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      cea83241
    • Alan Stern's avatar
      USB: EHCI: don't send Clear-TT-Buffer following a STALL · c2f6595f
      Alan Stern authored 
      This patch (as1304) fixes a regression in ehci-hcd.  Evidently some
hubs don't handle Clear-TT-Buffer requests correctly, so we should
avoid sending them when they don't appear to be absolutely necessary.
The reported symptom is that output on a downstream audio device cuts
out because the hub stops relaying isochronous packets.

The patch prevents Clear-TT-Buffer requests from being sent following
a STALL handshake.  In theory a STALL indicates either that the
downstream device sent a STALL or that no matching TT buffer could be
found.  In either case, the transfer is completed and the TT buffer
does not remain busy, so it doesn't need to be cleared.

Also, the patch fixes a minor flaw in the code that actually sends the
Clear-TT-Buffer requests.  Although the pipe direction isn't really
used for control transfers, it should be a Send rather than a Receive.
Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Reported-by: default avatarJavier Kohen <jkohen@users.sourceforge.net>
CC: David Brownell <david-b@pacbell.net>
Cc: stable <stable@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c2f6595f
  3. 30 Nov, 2009 35 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7