We've got regression reports that my previous fix for spurious wakeups
after S5 on HP Haswell machines leads to the automatic reboot at
shutdown on some machines. It turned out that the fix for one side
triggers another BIOS bug in other side. So, it's exclusive.
Since the original S5 wakeups have been confirmed only on HP machines,
it'd be safer to apply it only to limited machines. As a wild guess,
limiting to machines with HP PCI SSID should suffice.
This patch should be backported to kernels as old as 3.12, that
contain the commit 638298dc66 "xhci: Fix
spurious wakeups after S5 on Haswell".
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: <dashing.meng@gmail.com>
Reported-by: Niklas Schnelle <niklas@komani.de>
Reported-by: Giorgos <ganastasiouGR@gmail.com>
Reported-by: <art1@vhex.net>
If we connect Male-A-To-Male-A cable between otg-host and host pc,
the ci->vbus_active is set wrongly, and cause the controller run
at peripheral mode when we load gadget module (ci_udc_start will be run),
but the software runs at host mode due to id = 0. The ehci_irq
can't handle suspend (USBi_SLI) interrupt which is enabled for
peripheral mode, it causes no one will handle irq error.
This patch is needed for 3.12 stable
Cc: stable <stable@vger.kernel.org>
Acked-by: Michael Grzeschik <mgr@pengutronix.de>
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 40ed51a4b (usb: chipidea: host: add vbus regulator
control) introduced a smatch complaint because regulator_disable() is called
without checking whether ci->platdata->reg_vbus is not NULL.
Fix this by adding the check.
This patch is needed for 3.12 stable
Cc: stable <stable@vger.kernel.org>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ZTE AC2726 EVDO modem drops ppp connection every minute when driven by
zte_ev but works fine when driven by option. Move the support for AC2726
back to option driver.
Signed-off-by: Dmitry Kunilov <dmitry.kunilov@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DWC3 learned that it can't resume a PHY which wasn't
initialized and it also learned to not leave PHY powered
up in case of an error.
twl6030-usb PHY driver got a fix for a signedness bug in
twl6030_readb().
Tegra PHY driver got a bug fix where it could return success
even though there was an error.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJSphkAAAoJEIaOsuA1yqRE7tUP/0NjOJBbirUH8adlyxLXGCZK
9ASyH6irzuQz5QDqB3tSMstPTwUQ353ZIGI/xX6pHIEsOzUjKMzUDC0Hs81dZkgR
SGNDOlttpiD4WiV3XpYRH5gYj+50ustgd4K+CmwS3255tVBxXTIVU2qvAp4+hu1T
4lBhNy/vlmuO4Lal3lT1xAQojH0KyX7tnOHByoPSsdZ6NXTR8+Ytui58vCzrFgwW
rUIBsl7WGZjI2gyM3Zxw9KgD5oVTyxmq2KPBgE9V13dZ0OdwOYWScws0cfDAiWJ8
Yrg3d0o+JEFIjf3kYJEbsCjyyv4nWtFLOIgS58i3yHS1SZ9a+PvwOAaCulZY9pVq
42Jp8nzXV1jgsARgjIVO65yxg3ZedybvXDpNQQ7j2AamaYoGHLohYxhHn6d0rLCM
8VkIyG1xtC1llf8gl8xkTbAMDs410be5IfOfi1CrbbZHWR2gnsuq8iin+1eUCg31
0OWmMKMk9S+qD69oNcujV8vj86QbUslS/+2KnpZNT7S+FGLSVjkGEHrbSftTTbcV
G/kL/rovisYTB0dqV6jeYjTTSXrGJ+FEaFKBnNonWY5Mh+TLL3MMrz13lsHB62cQ
QO8Al3d8OP6PFDKJUljxq8vCwZ0t2LhrZPUJoqEycdbMZ4465AQzv/IG0k7q6Wc6
vNkK5aE47ocYVpeuKknz
=MfzU
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.13-rc4
DWC3 learned that it can't resume a PHY which wasn't
initialized and it also learned to not leave PHY powered
up in case of an error.
twl6030-usb PHY driver got a fix for a signedness bug in
twl6030_readb().
Tegra PHY driver got a bug fix where it could return success
even though there was an error.
Signed-of-by: Felipe Balbi <balbi@ti.com>
usb: phy-tegra-usb.c: wrong pointer check for remap UTMI
A wrong pointer was used to test the result of devm_ioremap()
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Acked-by: Venu Byravarasu <vbyravarasu@nvidia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch adds a check for USB_STATE_NOTATTACHED to the
hub_port_warm_reset_required() workaround for ports that end up in
Compliance Mode in hub_events() when trying to decide which reset
function to use. Trying to call usb_reset_device() with a NOTATTACHED
device will just fail and leave the port broken.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Include linux/dma-mapping.h to make the new functions available that are
used since 22d9d8e83 ("DMA-API: usb: use dma_set_coherent_mask()").
drivers/usb/host/ohci-pxa27x.c: In function ‘ohci_pxa_of_init’:
drivers/usb/host/ohci-pxa27x.c:310:2: error: implicit declaration of function ‘dma_coerce_mask_and_coherent’ [-Werror=implicit-function-declaration]
drivers/usb/host/ohci-pxa27x.c:310:2: error: implicit declaration of function ‘DMA_BIT_MASK’ [-Werror=implicit-function-declaration]
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reproduce:
ray@hr-bak:~/usb$ make -C tools/usb/
make: Entering directory `/home/ray/usb/tools/usb'
gcc -Wall -Wextra -g -lpthread -I../include -o testusb testusb.c
/tmp/cc0EMxfy.o: In function `main':
/home/ray/usb/tools/usb/testusb.c:508: undefined reference to `pthread_create'
/home/ray/usb/tools/usb/testusb.c:531: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
make: *** [testusb] Error 1
make: Leaving directory `/home/ray/usb/tools/usb'
Comments:
In the latest version (4.7.3) of gcc compiler, it requres that
libraries must follow the object or source files like below:
"gcc hello.c -lpthread" instead of "gcc -lpthread hello.c"
And it isn't encountered at gcc version 4.7.2.
So this patch fix to move the pthread option after testusb.c.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander isn't able to maintain the Chipidea code anymore, and as Peter
has been acting as the de-facto maintainer anyway, make it official.
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Acked-by: Peter Chen <Peter.Chen@freescale.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes the CS5 setting on the PL2303 USB-to-serial devices. CS5 has a
value of 0 and the CSIZE setting has been skipped altogether by the enclosing
if. Tested on 3.11.6 and the scope shows the correct output after the fix has
been applied.
Tagged to be added to stable, because it fixes a user visible driver bug and is
simple enough to backport easily.
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
FTDI UARTs support only 7 or 8 data bits. Until now the ftdi_sio driver would
only report this limitation for CS6 to dmesg and fail to reflect this fact to
tcgetattr.
This patch reverts the unsupported CSIZE setting and reports the fact with less
severance to dmesg for both CS5 and CS6.
To test the patch it's sufficient to call
stty -F /dev/ttyUSB0 cs5
which will succeed without the patch and report an error with the patch
applied.
As an additional fix this patch ensures that the control request will always
include a data bit size.
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch removes an erroneous check of CSIZE, which made it impossible to set
CS5.
Compiles clean, but couldn't test against hardware.
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch removes an erroneous check of CSIZE, which made it impossible to set
CS5.
Compiles clean, but couldn't test against hardware.
Signed-off-by: Colin Leitner <colin.leitner@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When multiple wireless USB devices are connected and one of the devices
disconnects, the host will distribute a new group key to the remaining
devicese using wusbhc_gtk_rekey. wusbhc_gtk_rekey takes the
wusbhc->mutex and holds it while it submits a URB to set the new key.
This causes a deadlock in wa_urb_enqueue when it calls a device lookup
helper function that takes the same lock.
This patch changes wusbhc_gtk_rekey to submit a work item to set the GTK
so that the URB is submitted without holding wusbhc->mutex.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch modifies the device notification handler to not look up the
wusb_dev object before it calls the lower-level handler routines since
the wusbhc mutex is not held when calling those routines and the device
could go away in the meantime. Instead, let the individual notification
handlers get the device ptr if they need to after they have taken the
mutex.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch modifies the WUSB device disconnect timer code to send
keepalives to all connected devices even if they are not authenticated.
This fixes a problem where unauthenticated devices that lose their
connection before they are authenticated will stay in the device tree
forever. More importantly, devices in this situation will never
relinquish their port on the root hub so eventually all root ports will
be taken up and no other devices can connect.
A comment in the existing code states that there are some devices that
may not respond to keepalives if they have not been authenticated. That
comment is about 5 years old and I don't know of any WUSB devices that
act that way. Either way, any buggy devices that may still be around
will continue to work as long as they can transition to the
authenticated state within the WUSB LOA timeout of 4s, which is not
unreasonable to expect.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add new supporting declarations to option.c, to support Huawei new
devices with new bInterfaceProtocol value.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:
tty_release: ttyUSB1: read/write wait queue active!
It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there - it's likely used by the card reader.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg,
Here's one bug fix for 3.13.
usb-net added support for bulk scatter-gather in 3.12, and it triggered a
bug in the xHCI driver. This bug causes xHCI hosts to send an unexpected
short transfer, which will cause the USB ethernet device to stop sending
packets.
The patch is marked for the 3.12 stable kernel. It's a long standing bug,
but the usb-net drivers are the first to trigger it. The only other
driver that does bulk scatter-gather (usb-storage) will not trigger this
bug.
I'm not sure what the effect of the no-op TRBs will be on various xHCI
host controllers, so I would only like to be conservative and only queue
it for 3.13 and 3.12 stable.
Please queue this for 3.13.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJSnPB6AAoJEBMGWMLi1Gc54rYP/jfd+LC3M/SFxeMGwkU5oCr5
+2xs9mUJso0izC+KFXS39pLvqdFiVQ+Jitl0JtIGj6sbjg02jwrPn+cknqKrg1zm
R8gYolnNjEGUBKUk1t7epy/wrR5mtms/XCM6VG+K7Dxd4A0NacncHUjlECBqjm5i
P2NhprvdUtJdtr+Hxmy1Z7MH85swKT0YHt4jnUD1QqIKbKiCGmSZ6ZvhMioDs9xL
ivGbQLMh44vuZxDLk9OcFUCtIUqjdavAbZcFejeq6z+Zyul7SLioOk9OtKtA240E
XvczX13vs73bgKGLuA0lEoi26NhynHkok9sdV317XsgYgiFZL1pd9q5sgmwvjyWO
qMOMSgmwpHLV3YDzl9FGpj04h/eHHkYQQ0US08CMRtIadp6sbVOCtrVNdnLLkuAT
A+HNMXFZO+8l5UxJFTms2lETdKNaQmG2qH7ur4m+TIiy54wEdwySHrR8XpyBEZZo
tmFsD+RFhy5YT2Y+OVsxJDwUsxDcxFF8at2BWOYH6yefguSndebC9ReqPiKwynQn
h4cf1308jcQUwU+gwCLxTp6ZTXFiZXPwFfJlk8z5/rXvbI8mNeoUxaPJCTb0cI0Z
J10sm7+P5DEP4KveB0ChviHsb4D2auDqs8JedMjzi4soI/UPIaOKdPuDmwAYBnvA
FOIoeJgkGoIBgmlIxwHI
=kO2u
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2013-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Sarah writes:
xhci: Regression fix for 3.13.
Hi Greg,
Here's one bug fix for 3.13.
usb-net added support for bulk scatter-gather in 3.12, and it triggered a
bug in the xHCI driver. This bug causes xHCI hosts to send an unexpected
short transfer, which will cause the USB ethernet device to stop sending
packets.
The patch is marked for the 3.12 stable kernel. It's a long standing bug,
but the usb-net drivers are the first to trigger it. The only other
driver that does bulk scatter-gather (usb-storage) will not trigger this
bug.
I'm not sure what the effect of the no-op TRBs will be on various xHCI
host controllers, so I would only like to be conservative and only queue
it for 3.13 and 3.12 stable.
Please queue this for 3.13.
Sarah Sharp
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
can only occur at a boundary between underlying USB frames (512 bytes for
high speed devices).
If this isn't done the USB frames aren't formatted correctly and, for example,
the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.
This should be a candidate for stable, the ax88179_178a driver defaults to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Notes from Sarah:
Discussion: http://marc.info/?l=linux-usb&m=138384509604981&w=2
This patch fixes a long-standing xHCI driver bug that was revealed by a
change in 3.12 in the usb-net driver. Commit
638c5115a7 "USBNET: support DMA SG" added
support to use bulk endpoint scatter-gather (urb->sg). Only the USB
ethernet drivers trigger this bug, because the mass storage driver sends
sg list entries in page-sized chunks.
This patch only fixes the issue for bulk endpoint scatter-gather. The
problem will still occur for periodic endpoints, because hosts will
interpret no-op transfers as a request to skip a service interval, which
is not what we want.
Luckily, the USB core isn't set up for scatter-gather on isochronous
endpoints, and no USB drivers use scatter-gather for interrupt
endpoints. Document this known limitation so that developers won't try
to use urb->sg for interrupt endpoints until this issue is fixed. The
more comprehensive fix would be to allow link TRBs in the middle of the
endpoint ring and revert this patch, but that fix would touch too much
code to be allowed in for stable.
This patch should be backported to kernels as old as 3.12, that contain
the commit 638c5115a7 "USBNET: support DMA
SG". Without this patch, the USB network device gets wedged, and stops
sending packets. Mark Lord confirms this patch fixes the regression:
http://marc.info/?l=linux-netdev&m=138487107625966&w=2
Signed-off-by: David Laight <david.laight@aculab.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Mark Lord <mlord@pobox.com>
Cc: stable@vger.kernel.org
First set of fixes for this -rc cycle. A few important
fixes which should be backported to stable kernels and
the usual set of sparse warning fixes. There's also a
regression fix on phy-generic.c which would prevent
am335x-based platforms from having their PHY drivers
probed.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJSk5HFAAoJEIaOsuA1yqRE7xoP/Rz2ZMt1BlRH3rHorQL+0mqs
2KDN7Vz+vLlt4BldLYiMpKTe7zTmV28yR+MaTHzX1RVJEXJl0/hJVPvOmOdAPAkX
Y5KnjWrUNhrG6ChxUwaJslWLA8ACnV5PwdQDsSJYGKAi0jWuXE0qSJoGqX8PgJX/
gU9TK5iWHFflmkpg8M8UPx2XyMFHYfonJ6Nh2A8bYTkHqHFZp/CoCZKQqmAathKg
9Kyze3elKyA5Ch1JXf++WIViCXMkNRgWp4YNYUDj9t32mw2iLyg0czMvTNK0OqeR
ICqzz4EgiSQjFq4p70kJSDXqRUGIre/JcZk7Gq3zAAUw0ScuJRQOZBmDiyu5K2vk
UG+H05YZCFXqr4e+80WoIzLyaZzokOA/RI9sDPKeF3NvaxCCtf9BsEu4ugOwoBrz
9MQhHJBcvJAYbBeUy/L80btL7SoSc76mQ08+HImeDoolZMFgVcS0bUTPE0VSwW9U
oDnOAe/kSCRSZPEkDp6nbKqp3OX1tvWA+1bsYslsEbPotnulYWawd4OCPhPWKc2J
Uu6HBC6aDZ6DS3YH/GKkJONV3oRjaqjDwHMoTlZa3bDftPACzGgXc+r8s4iiLzya
VHK5R8JK32hD/GI/5oWhJVgDQmFbp2Kk6MeSTT1AgiJ75x7Z1dWncePohdaPrMt/
Wn19N0Ype+72HhTZ3oP2
=ZzE5
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.13-rc2
First set of fixes for this -rc cycle. A few important
fixes which should be backported to stable kernels and
the usual set of sparse warning fixes. There's also a
regression fix on phy-generic.c which would prevent
am335x-based platforms from having their PHY drivers
probed.
Signed-of-by: Felipe Balbi <balbi@ti.com>
"ret" needs to be signed for the error handling to work.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb phy was power'ed on but was never power'ed off in the error path.
Fix it.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb_phy_set_suspend(phy, 0) is called before usb_phy_init. Fix it.
Reported-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Call try_to_freeze() in sleep_thread() only when it's safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these won't call try_to_freeze() by passing can_freeze flag
to sleep_thread.
Calling try_to_freeze() with a lock hold was done since day one in
f_mass_storage but since commit 0f9548ca1 ("lockdep: check that no
locks held at freeze time") lockdep complains about it.
Signed-off-by: George Cherian <george.cherian@ti.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
that symbol is only used inside this function driver,
we should mark it static. Fixes sparse's:
drivers/usb/gadget/tcm_usb_gadget.c:373:6: warning: symbol \
'bot_cleanup_old_alt' was not declared. Should it \
be static?
Signed-off-by: Felipe Balbi <balbi@ti.com>
g_zero's module parameters can, and should, be
static. This fixes sparse warnings.
Cc: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
fsg_common_set_inquiry_string() expects pointers
as second and third argument. Let's fix that by
passing NULL instead of plain 0 just so we silence
sparse's:
drivers/usb/gadget/f_mass_storage.c:3114:60: warning: \
Using plain integer as NULL pointer
drivers/usb/gadget/f_mass_storage.c:3114:63: warning: \
Using plain integer as NULL pointer
Signed-off-by: Felipe Balbi <balbi@ti.com>
In case of error, the function platform_device_register_simple() returns
ERR_PTR() and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The dwc3 UDC driver doesn't implement endpoint wedging correctly.
When an endpoint is wedged, the gadget driver should be allowed to
clear the wedge by calling usb_ep_clear_halt(). Only the host is
prevented from resetting the endpoint.
This patch fixes the implementation.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Pratyush Anand <pratyush.anand@st.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Mass storage gadget returns DELAYED_STATUS in stead of
USB_GADGET_DELAYED_STATUS while handling bulk reset request. Since
peripheral driver uses USB_GADGET_DELAYED_STATUS for delayed status
handling, therefore replace DELAYED_STATUS by USB_GADGET_DELAYED_STATUS
in mass storage driver.
Since, DELAYED_STATUS and hence EP0_BUFSIZE will no longer be used now,
so remove them.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Cc: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Legacy gadgets supporting mass storage (g_mass_storage, g_acm_ms, g_multi)
all depend on BLOCK.
Make the standalone compilation of f_mass_storage (without any legacy
gadget) dependent no BLOCK, too.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We need to set mxs_phy rather as the platform drvdata so that we can get
the correct mxs_phy in mxs_phy_remove().
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Since commit c5340bd14 ("usb: musb: cancel work on removal") the workqueue
is cancelled but then if we bail out before the workqueue is setup we
get this:
|INFO: trying to register non-static key.
|the code is fine but needs lockdep annotation.
|turning off the locking correctness validator.
|CPU: 0 PID: 708 Comm: modprobe Not tainted 3.12.0+ #435
|[<c00867bc>] (lock_acquire+0xf0/0x108) from [<c00529d0>] (flush_work+0x38/0x2ec)
|[<c00529d0>] (flush_work+0x38/0x2ec) from [<c0052d24>] (__cancel_work_timer+0xa0/0x134)
|[<c0052d24>] (__cancel_work_timer+0xa0/0x134) from [<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc])
|[<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) from [<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc])
|[<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24)
|[<c0294bf0>] (platform_drv_probe+0x1c/0x24) from [<c0293970>] (driver_probe_device+0x90/0x224)
|[<c0293970>] (driver_probe_device+0x90/0x224) from [<c0291ef0>] (bus_for_each_drv+0x60/0x8c)
|[<c0291ef0>] (bus_for_each_drv+0x60/0x8c) from [<c02938bc>] (device_attach+0x80/0xa4)
|[<c02938bc>] (device_attach+0x80/0xa4) from [<c0292b24>] (bus_probe_device+0x88/0xac)
|[<c0292b24>] (bus_probe_device+0x88/0xac) from [<c0291490>] (device_add+0x388/0x6c8)
|[<c0291490>] (device_add+0x388/0x6c8) from [<c02952a0>] (platform_device_add+0x188/0x22c)
|[<c02952a0>] (platform_device_add+0x188/0x22c) from [<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps])
|[<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24)
|platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
|musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
This patch moves the init part to earlier part so it can be cleaned as
part of the fail3 label because now it is surrounded by the fail4 label.
Step two is to remove it from musb_free() and add it to the two cleanup
paths (error path and device removal) separately.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The delayed_status value is used to keep track of status response
packets on ep0. It needs to be reset or the set_config function would
still delay the answer, if the usb device got unplugged while waiting
for setup_continue to be called.
Cc: stable@vger.kernel.org
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The TX-complete interrupt of the CPPI41 on AM335x fires too early.
Adding a loop and counting how long it takes until the
MUSB_TXCSR_TXPKTRDY bit is cleared I see
FS:
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadc54002, len=1514 is_tx=1
|cppi41_dma_callback() 74 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadcd8802, len=1514 is_tx=1
|cppi41_dma_callback() 66 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadcd8002, len=1514 is_tx=1
|cppi41_dma_callback() 136 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadf55802, len=1514 is_tx=1
|cppi41_dma_callback() 136 loops
avg: 110 - 150us
HS:
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xaca6f002, len=1514 is_tx=1
|cppi41_dma_callback() 0 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xadd6f802, len=1514 is_tx=1
|cppi41_dma_callback() 2 loops
|musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xadd6f002, len=1514 is_tx=1
|cppi41_dma_callback() 13 loops
avg: 2us
for the same test case. One loop means a udelay(1). The delay seems to
depend on the packet size. On HS the bit is always cleared for small
packet sizes while on FS it is never the case, it mostly around 110us.
This testing has been performed with g_ether (musb as device) and using BULK
transfers.
INTR transfers are way more fun: during init the gadget sends a INT
packet to the host and cppi41 says "transfer done" shortly after. The
MUSB_TXCSR_TXPKTRDY bit is set even seconds later. The reason is that the host
did not try to receive it, it does so after the interface (on host side) has
been configured. Until this happens, that packet remains in musb's FIFO.
To fix this, two things are done:
- No DMA transfers for INT based endpoints. These transfer are usually
very small and rare so it is likely better to skip the DMA engine and
stuff the four bytes directly into the FIFO
- on HS we poll up to 25us and hope that bit goes away. If not we setup
a hrtimer to poll for it. The 140us delay is a rule of thumb. In FS
the command
| ping 10.10.10.10 -c1 -s65130
creates about 44 1514bytes transfers. About 19 of them need a second
timer to complete.
Reported-by: Bin Liu <b-liu@ti.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch moves most of the logic in cppi41_dma_callback() into
cppi41_trans_done() where it can be called from another function.
Instead of computing "transferred" (the number of bytes transferred in
the last transaction) in cppi41_trans_done() the member
"cppi41_channel->prog_len" is now set to 0 if the transfer as a whole
can be considered as done. If it is != 0 then the next iteration is
assumed.
This is a preparation for a workaround.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fix regression introduced by commit 818f60365a ("USB: serial: add
memory flags to usb_serial_generic_write_start"), which incorrectly used
GFP_KERNEL in write(), which must not not sleep.
Reported-by: Dave Jones <davej@fedoraproject.org>
Tested-by: Dave Jones <davej@fedoraproject.org>
Cc: Dave Jones <davej@fedoraproject.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix race in generic write implementation, which could lead to
temporarily degraded throughput.
The current generic write implementation introduced by commit
27c7acf220 ("USB: serial: reimplement generic fifo-based writes") has
always had this bug, although it's fairly hard to trigger and the
consequences are not likely to be noticed.
Specifically, a write() on one CPU while the completion handler is
running on another could result in only one of the two write urbs being
utilised to empty the remainder of the write fifo (unless there is a
second write() that doesn't race during that time).
Cc: stable <stable@vger.kernel.org> # 2.6.35
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit bd27fa44e1 (usb: phy: generic:
Don't use regulator framework for RESET line) introduced regression: All
users of usb_nop_xceiv_register() will fail because there is no platform
data and the default reset GPIO is 0 which is a valid GPIO. Fix that.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The musb driver is usable in host, gadget or dual role mode depending
on the kernel configuration.
However, the musb gadget part of the driver is enabling OTG mode
whether the driver is built for dual role or gadget only mode. This
induces a bug for gadget only USB device controllers where the kernel
tries to use Host Negotiation Protocol with such controllers, which
causes a panic.
This behaviour is now fixed by enabling OTG mode only when musb driver
is built for dual role mode.
Signed-off-by: Apelete Seketeli <apelete@seketeli.net>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In commit
88f718e3fa
"ARM: pxa: delete the custom GPIO header"
we removed the implicit inclusion of <mach/gpio.h>
from <linux/gpio.h>.
The pxa25x_udc was not using that, but it was relying
on <linux/gpio.h> to implictly include <mach/gpio.h>
which in turn implicitly included <mach/hardware.h>,
which was needed for the driver to compile.
Fix this up by explicitly including the necessary
<mach/hardware.h> header.
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch moves s3c_hsotg_disconnect function call from USBSusp interrupt
handler to SET_ADDRESS request handler.
It's because disconnected state can't be detected directly, because this
hardware doesn't support Disconnected interrupt for device mode. For both
Suspend and Disconnect events there is one interrupt USBSusp, but calling
s3c_hsotg_disconnect from this interrupt handler causes config reset in
composite layer, which is not undesirable for Suspended state.
For this reason s3c_hsotg_disconnect is called from SET_ADDRESS request
handler, which occurs always after disconnection, so we do disconnect
immediately before we are connected again. It's probably only way we
can do handle disconnection correctly.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch adds missing spinlock locking in s3c_hsotg_complete_setup function,
and unlocking for gadget setup call.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
