When we reach to link trb, we just need to increase free_slot and then
calculate TRB. Return is not correct, as it will cause wrong TRB DMA
address to fetch in case of update transfer.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
There were still some corner cases where isoc transfer was not able to
restart, specially when missed isoc does not happen , and in fact gadget does
not queue any new request during giveback.
Cleanup function calls giveback first, which provides a way to queue
another request to gadget. But gadget did not had any data. So , it did
not call ep_queue. To twist it further, gadget did not queue till
cleanup for last queued TRB is called. If we ever reach this scenario,
we must call END TRANSFER, so that we receive a new xfernotready with
information about current microframe number.
Also insure that there is no request submitted to core when issuing END
TRANSFER.
Cc: <stable@vger.kernel.org> # v3.8
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Its better to return from each if condition as they are mutually
exclusive.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
There are two reasons to generate missed isoc.
1. when the host does not poll for all the data.
2. because of application-side delays that prevent all the data from
being transferred in programmed microframe.
Current code was able to handle first case only. This patch handles
scenario 2 as well.Scenario 2 sometime may occur with complex gadget
application, however it can be easily reproduced for testing purpose as
follows:
a. use isoc binterval as 1 in f_sourcesink.
b. use pattern=0
c. introduce a delay of 150us deliberately in source_sink_complete, so
that after few frames it lands into scenario 2.
d. now run testusb 16 (isoc in test). You will notice that if this
patch is not applied then isoc transfer is not able to recover after
first missed.
Current patch's approach is as under:
If missed isoc occurs and there is no request queued then issue END
TRANSFER, so that core generates next xfernotready and we will issue a
fresh START TRANSFER.
If there are still queued request then wait, do not issue either END or
UPDATE TRANSFER, just attach next request in request_list during giveback.
If any future queued request is successfully transferred then we will issue
UPDATE TRANSFER for all request in the request_list.
Cc: <stable@vger.kernel.org> # v3.6 v3.7 v3.8
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Synopsys says:
The HIRD Threshold field must be set to ‘0’ when the device core is
operating in super speed mode.
This patch implements above statement.
Cc: <stable@vger.kernel.org> # v3.6 v3.7 v3.8
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The devm_ functions allocate memory that is released when a driver
detaches. This makes the code smaller and a bit simpler.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Currently we're allocating an entire page to
serve as our event buffer. Provided our events
are 4 bytes long, it's very unlikely we will
even trigger 1k events at once.
Even in the worst case scenario where every
endpoint triggers one event and we still have
a couple of error events, that would still
be less than 40 events.
In order to cope with future versions of the
IP which could (or could not) increase the
amount of possible events to trigger
simultaneously, we're using an arbitrary size
of 64 events for our event buffer.
We're saving 3840 bytes by doing so.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Here are a bunch of USB fixes for your 3.8-rc3 tree. They all either fix
problems that have been reported (like the xhci/hub changes) or add new device
ids to existing drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEABECAAYFAlDzjz0ACgkQMUfUDdst+yn5YwCeOyqqCgQvyuP2JsacN/2a4wRN
Wn4AoM/Pg+b+B8M7Z/SBO10DRzj24xYj
=Kkq8
-----END PGP SIGNATURE-----
Merge tag 'usb-3.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg Kroah-Hartman:
"Here are a bunch of USB fixes for your 3.8-rc3 tree. They all either
fix problems that have been reported (like the xhci/hub changes) or
add new device ids to existing drivers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'usb-3.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (39 commits)
usb: ftdi_sio: Crucible Technologies COMET Caller ID - pid added
usb: host: ohci-tmio: fix compile warning
USB: Add device quirk for Microsoft VX700 webcam
USB: ehci-fsl: fix regression on mpc5121e
usb: chipidea: Allow disabling streaming not only in udc mode
USB: fsl-mph-dr-of: fix regression on mpc5121e
USB: select USB_ARCH_HAS_EHCI for MXS
USB: hub: handle claim of enabled remote wakeup after reset
USB: cdc-acm: Add support for "PSC Scanning, Magellan 800i"
USB: option: add Nexpring NP10T terminal id
USB: option: add Telekom Speedstick LTE II
USB: option: blacklist network interface on ZTE MF880
usb: imx21-hcd: Include missing linux/module.h
USB: option: Add new MEDIATEK PID support
USB: ehci: make debug port in-use detection functional again
USB: usbtest: fix test number in log message
xhci: Avoid "dead ports", add roothub port polling.
USB: Handle warm reset failure on empty port.
USB: Ignore port state until reset completes.
USB: Increase reset timeout.
...
Simple fix to add support for Crucible Technologies COMET Caller ID
USB decoder - a device containing FTDI USB/Serial converter chip,
handling 1200bps CallerID messages decoded from the phone line -
adding correct USB PID is sufficient.
Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8
and 3.8.0-rc3 on both amd64 and x86 arches.
Signed-off-by: Tomasz Mloduchowski <q@qdot.me>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the following compile warning:
In file included from drivers/usb/host/ohci-hcd.c:1170:0:
drivers/usb/host/ohci-tmio.c: In function 'tmio_start_hc':
drivers/usb/host/ohci-tmio.c:130:2: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'resource_size_t' [-Wformat]
seen on ARM 32-bit builds.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When running a scp transfer using a USB/Ethernet adapter the following crash
happens:
$ scp test.tar.gz fabio@192.168.1.100:/home/fabio
fabio@192.168.1.100's password:
test.tar.gz 0% 0 0.0KB/s --:-- ETA
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x2cc/0x2f0()
NETDEV WATCHDOG: eth0 (asix): transmit queue 0 timed out
Modules linked in:
Backtrace:
[<80011c94>] (dump_backtrace+0x0/0x10c) from [<804d3a5c>] (dump_stack+0x18/0x1c)
r6:000000ff r5:80412388 r4:80685dc0 r3:80696cc0
[<804d3a44>] (dump_stack+0x0/0x1c) from [<80021868>]
(warn_slowpath_common+0x54/0x6c)
[<80021814>] (warn_slowpath_common+0x0/0x6c) from [<80021924>]
(warn_slowpath_fmt+0x38/0x40)
...
Setting SDIS (Stream Disable Mode- bit 4 of USBMODE register) fixes the problem.
However, in current code CI13XXX_DISABLE_STREAMING flag is only set in udc mode,
so allow disabling streaming also in host mode.
Tested on a mx6qsabrelite board.
Suggested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fsl-ehci probing fails on mpc5121e:
...
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: Could not get controller version
fsl-ehci fsl-ehci.0: can't setup
fsl-ehci fsl-ehci.0: USB bus 1 deregistered
fsl-ehci fsl-ehci.0: init fsl-ehci.0 fail, -22
fsl-ehci: probe of fsl-ehci.0 failed with error -22
Fix it by returning appropriate version info for mpc5121, too.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 09f6ffde (USB: EHCI: fix build error by making ChipIdea host a
normal EHCI driver) introduced a dependency on USB_EHCI_HCD for the
chipidea USB host driver, that in turns depends on USB_ARCH_HAS_EHCI.
If this symbol is not set for MXS, the MXS boards are not able to use
the chipidea driver anymore.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some touchscreens have buggy firmware which claims
remote wakeup to be enabled after a reset. They nevertheless
crash if the feature is cleared by the host.
Add a check for reset resume before checking for
an enabled remote wakeup feature. On compliant
devices the feature must be cleared after a reset anyway.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adding support "PSC Scanning, Magellan 800i" in cdc-acm
Very simple, but very necessary.
Suitable for all versions of the kernel > 2.6
Signed-off-by: Denis N Ladin <denladin@gmail.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
also known as Alcatel One Touch L100V LTE
The driver description files gives these names to the vendor specific
functions on this modem:
Application1: VID_1BBB&PID_011E&MI_00
Application2: VID_1BBB&PID_011E&MI_01
Modem: VID_1BBB&PID_011E&MI_03
Ethernet: VID_1BBB&PID_011E&MI_04
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Include <linux/module.h>, so that the following errors are fixed:
drivers/usb/host/imx21-hcd.c:1929:20: error: expected declaration specifiers or '...' before string constant
drivers/usb/host/imx21-hcd.c:1930:15: error: expected declaration specifiers or '...' before string constant
drivers/usb/host/imx21-hcd.c:1931:16: error: expected declaration specifiers or '...' before string constant
drivers/usb/host/imx21-hcd.c:1932:14: error: expected declaration specifiers or '...' before string constant
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In option.c, add some new MEDIATEK PIDs support for MEDIATEK new products. This
is a MEDIATEK inc. release patch.
Signed-off-by: Quentin.Li <snowmanli88@163.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Debug port in-use determination must be done before the controller gets
reset the first time, i.e. before the call to ehci_setup() as of commit
1a49e2ac96. That commit effectively
rendered commit 9fa5780bee useless.
While moving that code around, also fix the BAR determination - the
respective capability field is a 3- rather than a 2-bit one -, and use
PCI_CAP_ID_DBG instead of the literal 0x0a.
It's unclear to me whether the debug port functionality is important
enough to warrant fixing this in stable kernels too.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1639) fixes a minor bug in the usbtest driver. Due to
concurrent changes, a test originally written as number 17 got changed
to number 24, but the corresponding change was not made in the log
message. This updates the log message.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg,
Happy New Year! Here's some bug fixes for 3.8. I have usb-next
patches that are based on this set, so please merge your usb-linus
branch into usb-next after this set is applied.
The bulk of the patchset (patches 2-7) improve the USB core's warm
reset error handling.
There's also one patch that fixes an arithmetic error in the xHCI
driver, and another to avoid the "dead ports" issue caused by
unhandled port status change events.
These are all marked for stable.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQ5gLZAAoJEBMGWMLi1Gc57FUP/3PqGOZeHY9O//8tZrJGn4aL
N1pLAO6Nz/sVcIT69G1DAFyOthD3iJJHR6yd3vlVwGYVD85M+P4DKM/xMTSeTpR0
75RxTbcphCMKzmLvYjeWkoG2SrUNEIuTRNSRF+GaB2gp6wviNSEBJGHlxdmbXfub
SWulb6qlr5KaSz1ecVGsGVRc0PX3m5EMq+Phi8arUyA+a5X6Q2ekcCj2IuZSCk6F
aHJo0rcWd6Er3OpjGXM8svdQYeuBsisxQJu4/M40sxFrUJhnMujC02r0EYgSrg15
Xjof82d22v1eFUfOAvMfSuPokMuTMakRVzLF9tCciFafYbMtYEoFUkyWHJH2tGnP
Tn++43ps66L/vwVFy7MwRqAgekgQiCmirPaL/mFjVCrSJa3rzq4lU7Nh2+21Ri7x
QyeVp5g0O+HufiS0koB1LARsi3M1LOG1AwFAnnf6i2L1S/i5L/cF7qr99QWELnlz
cvhmk5w/2bsovJfiR54F4Bhod77P6U1wwjFmsYunsuPsZBRGAmPw11y24humSwll
C2xP3tM5D8tEwvZ7rW7fwLCniJPx1aCV94Tz/vu/tuSQ+gzLEqzMyKqIwdnJMthY
NX20cduuBMpS+F3kQ4+8yYquK0O1Vq39szPgcm2JB/ijjew10peGXw3Kwg2yBSyQ
JuUvdVXjwUze3cDT7OaL
=9YSo
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2013-01-03' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Sarah says:
usb-linus: USB core fixes for warm reset
Hi Greg,
Happy New Year! Here's some bug fixes for 3.8. I have usb-next
patches that are based on this set, so please merge your usb-linus
branch into usb-next after this set is applied.
The bulk of the patchset (patches 2-7) improve the USB core's warm
reset error handling.
There's also one patch that fixes an arithmetic error in the xHCI
driver, and another to avoid the "dead ports" issue caused by
unhandled port status change events.
These are all marked for stable.
Sarah Sharp
Here is the first set of fixes for v3.8-rc cycle.
There is a build fix for musb's dsps glue layer caused
by some header cleanup on the OMAP tree.
Marvel's USB drivers got a fix up for clk API usage
switching over to clk_prepare() calls.
u_serial has a bug fix for a missing wake_up() which
would make gs_cleanup() wait forever for gs_close()
to finish.
A minor bug fix on dwc3's debugfs interface which
would make us read wrong addresses when dumping
all registers.
dummy_hcd learned how to enumerate g_multi.
s3c-hsotg now understands that we shouldn't kfree()
memory allocated with devm_*.
Other than that, there are a bunch of other minor fixes
on renesas_usbhs, tcm_usb_gadget and amd5536udc.
All patches have been pending on mailing for many weeks
and shouldn't cause any problems.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQya06AAoJEIaOsuA1yqRERaoQAIwzE4HkoOVX8SU/8r02eFr7
O+mU0bMhL8RgQ1MggSLYjA4k/E/pB4ybu1Hr/ebIcGFziyjmiZIKGeYFOXfSefnO
AtvKRrqB62bFouTbV8JXsvfHIYIjWTqDl6Sxqjyg98lKmyBNjCWrHpWEi+7KOpI/
1ecPonRb+SfFaFrQkHtH+1XpTca4YOemHValz/W9bHhbLFsHw1yVX9PP3Nz7MV+t
EhOs0+uPYNs5LVyIsAslFVEnhnv4KE+eVIltnPFG/sdR02jGKo8r8JD9iIUdr6zB
U8ScU0cqDtr3E57wa0TuoVaFaMUcWLwOpY1V1ykLWTtT3Fn6W3DlU9a7WkH+Gmis
mH6frNUpFuMqPj+5UJv/J3p+qXMq9KmuKB2KMGCpaNg4FVVipI4Y7nNSMm9C/JEt
0Sw2EpCo5S0Pc4DHINPVzELviTr7sSjF4q1LtY6k+4t3ZzLvxeeUlNOZvmnmNiHL
jDBYh7EeyU4otsp0JFgK+Lj9AogP2hXCymRKz5iVwoiXYN2jK5edXkRmOnNYsNWH
7h6mFq62sKFE9fJoJxD9Kw6PPOj64bSq0byUIUTKe62c2GuKmon94qhO6ubRI5dE
KX/HdNxBk92hmnyp9NfVOvcG1AACReE2kqEsLBetrRhWJaiFvZupo5be0LnGM9eo
c9bZrTZrAgIH+s+ks40X
=UsKi
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.8-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe says:
usb: fixes for v3.8-rc2
Here is the first set of fixes for v3.8-rc cycle.
There is a build fix for musb's dsps glue layer caused
by some header cleanup on the OMAP tree.
Marvel's USB drivers got a fix up for clk API usage
switching over to clk_prepare() calls.
u_serial has a bug fix for a missing wake_up() which
would make gs_cleanup() wait forever for gs_close()
to finish.
A minor bug fix on dwc3's debugfs interface which
would make us read wrong addresses when dumping
all registers.
dummy_hcd learned how to enumerate g_multi.
s3c-hsotg now understands that we shouldn't kfree()
memory allocated with devm_*.
Other than that, there are a bunch of other minor fixes
on renesas_usbhs, tcm_usb_gadget and amd5536udc.
All patches have been pending on mailing for many weeks
and shouldn't cause any problems.
This snuck in from a different tree during the merge and needs to be
removed.
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits. When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event. If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.
This means that the hub code may lose port status changes because of
race conditions between clearing change bits. The user sees this as a
"dead port" that doesn't react to device connects.
The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.
We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's. Instead, stop the port polling timer, and
unconditionally restart it when the host resumes. If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.
This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
An empty port can transition to either Inactive or Compliance Mode if a
newly connected USB 3.0 device fails to link train. In that case, we
issue a warm reset. Some devices, such as John's Roseweil eusb3
enclosure, slip back into Compliance Mode after the warm reset.
The current warm reset code does not check for device connect status on
warm reset completion, and it incorrectly reports the warm reset
succeeded. This causes the USB core to attempt to send a Set Address
control transfer to a port in Compliance Mode, which will always fail.
Make hub_port_wait_reset check the current connect status and link state
after the warm reset completes. Return a failure status if the device
is disconnected or the link state is Compliance Mode or SS.Inactive.
Make hub_events disable the port if warm reset fails. This will disable
the port, and then bring it back into the RxDetect state. Make the USB
core ignore the connect change until the device reconnects.
Note that this patch does NOT handle connected devices slipping into the
Inactive state very well. This is a concern, because devices can go
into the Inactive state on U1/U2 exit failure. However, the fix for
that case is too large for stable, so it will be submitted in a separate
patch.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
The port reset code bails out early if the current connect status is
cleared (device disconnected). If we're issuing a hot reset, it may
also look at the link state before the reset is finished.
Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state, the port connection bit retains the
value from the previous state. Therefore we can't trust it until the
reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software
shall ignore the link state while the port is resetting, as it can be in
an unknown state.
The port state during reset is also unknown for USB 2.0 hubs. The hub
sends a reset signal by driving the bus into an SE0 state. This
overwhelms the "connect" signal from the device, so the port can't tell
whether anything is connected or not.
Fix the port reset code to ignore the port link state and current
connect bit until the reset finishes, and USB_PORT_STAT_RESET is
cleared.
Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case,
because it's redundant. When the warm reset finishes, the port reset
bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set.
Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit
in the code to deal with the finished reset.
This patch should be backported to all stable kernels.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete. The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host. The xHC then updates its internal
representation of the USB device to the 'Default' device state. If the
device was already in the Default state, the xHC will complete the
command with an error status.
If a device needs to be reset several times during enumeration, the
second reset will always fail because of the xHCI Reset Device command.
This can cause issues during enumeration.
For example, usb_reset_and_verify_device calls into hub_port_init in a
loop. Say that on the first call into hub_port_init, the device is
successfully reset, but doesn't respond to several set address control
transfers. Then the port will be disabled, but the udev will remain in
tact. usb_reset_and_verify_device will call into hub_port_init again.
On the second call into hub_port_init, the device will be reset, and the
xHCI driver will issue a Reset Device command. This command will fail
(because the device is already in the Default state), and
usb_reset_and_verify_device will fail. The port will be disabled, and
the device won't be able to enumerate.
Fix this by ignoring the return value of the HCD reset_device callback.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset. In that case, the warm reset change bit
will be set, and the link state change bit may also be set. Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs. If these bits are not cleared, we may lose port change events
from the roothub.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK. If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).
The xHCI code to compute the NAK interval does not handle the special
case of zero properly. The current code unconditionally subtracts one
from bInterval and uses it as an exponent. This causes a very large
bInterval to be used, and warning messages like these will be printed:
usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes
This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.
This patch should be backported to kernels as old as 2.6.31, that contain
commit dfa49c4ad1 "USB: xhci - fix math in
xhci_get_endpoint_interval()".
Reported-by: Vincent Pelletier <plr.vincent@gmail.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
The {read,write}s{b,w,l} operations are not defined by all architectures
and are being removed from the asm-generic/io.h interface.
This patch replaces the usage of these string functions in the musb
accessors with io{read,write}{8,16,32}_rep calls instead.
Signed-off-by: Matthew Leach <matthew@mattleach.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The {read,write}s{b,w,l} operations are not defined by all architectures
and are being removed from the asm-generic/io.h interface.
This patch replaces the usage of these string functions in the tusb6010
accessors with io{read,write}{8,16,32}_rep calls instead.
Signed-off-by: Matthew Leach <matthew@mattleach.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
These devices are not available on other architectures, so
let's limit them to omap.
If the driver subsystem maintainers want to build test
system wide changes without building for each target,
it's easy to carry a test patch that just strips out the
depends entries from Kconfig files.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull trivial branch from Jiri Kosina:
"Usual stuff -- comment/printk typo fixes, documentation updates, dead
code elimination."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
HOWTO: fix double words typo
x86 mtrr: fix comment typo in mtrr_bp_init
propagate name change to comments in kernel source
doc: Update the name of profiling based on sysfs
treewide: Fix typos in various drivers
treewide: Fix typos in various Kconfig
wireless: mwifiex: Fix typo in wireless/mwifiex driver
messages: i2o: Fix typo in messages/i2o
scripts/kernel-doc: check that non-void fcts describe their return value
Kernel-doc: Convention: Use a "Return" section to describe return values
radeon: Fix typo and copy/paste error in comments
doc: Remove unnecessary declarations from Documentation/accounting/getdelays.c
various: Fix spelling of "asynchronous" in comments.
Fix misspellings of "whether" in comments.
eisa: Fix spelling of "asynchronous".
various: Fix spelling of "registered" in comments.
doc: fix quite a few typos within Documentation
target: iscsi: fix comment typos in target/iscsi drivers
treewide: fix typo of "suport" in various comments and Kconfig
treewide: fix typo of "suppport" in various comments
...
This branch contains a largeish set of updates of power management and
clock setup. The bulk of it is for OMAP/AM33xx platforms, but also a
few around hotplug/suspend/resume on Exynos.
It includes a split-up of some of the OMAP clock data into separate
files which adds to the diffstat, but gross delta is fairly reasonable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQySrdAAoJEIwa5zzehBx3XBMQAJCgrE/I1vbuiENiVMLpQkN7
0Y5t89SwoALnme5jsM8vW/H0o6b163FfH+249UNs6dyk6MdCqqSv8cQVvSfCKRKn
m4JTXS6njSnYgU025klNU9W3FyMuFcgH8b63+c5+sCcqfvdkxrjpNoKqAYNxQlgJ
6DHgHCKZP3JB1e2EFqViw0GJgZIjTNxlWvx8XLcAShSapQ+Ovq/iAcKo41o7ZadB
4zV//VkBMv0TLNTs6SoR0EO8qM+2nIUKE8fgPrRxvvb98tuasKPvlSq9VUeIjnYk
kWjNTQYbD1IkrAMPYrwcpLU3xkEr14wrKDBtPK6GdCDcXzdyKq3fzROOXNsqrLmn
Y8PkY+J39B59F0DKjyrCjasZyi0tQQV6ps5Xm2X2CB003GWEbo1yu+BodShYEyaL
7OvkLiVpOtq+LOYcsScHtOGdO9le2O3yZevNRvlrCDCvJUYbXNjaM9ZrWcQuTlJc
oseYNSRPaIP5PMv2c+Xup9qh/dyAjj8g6gSi9BlDvwVOu/+Cf3laaCAXaFph22jT
/m8fW2paiP5UJ0gSt1MLAGFxKi0YI/Qxck8G11LJxUwMZd3SIfOPUAY27tnNC4yL
GRynOi3BFRMUAe/Leu2qgwEyoME5nHn+OmAKb36WTYH/HL+PGzHq84e+Wfdan8ha
YcSKc1A52LSoYTi4XTUX
=h2Qo
-----END PGP SIGNATURE-----
Merge tag 'pm-merge' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC power management and clock changes from Olof Johansson:
"This branch contains a largeish set of updates of power management and
clock setup. The bulk of it is for OMAP/AM33xx platforms, but also a
few around hotplug/suspend/resume on Exynos.
It includes a split-up of some of the OMAP clock data into separate
files which adds to the diffstat, but gross delta is fairly reasonable."
* tag 'pm-merge' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (60 commits)
ARM: OMAP: Move plat-omap/dma-omap.h to include/linux/omap-dma.h
ASoC: OMAP: mcbsp fixes for enabling ARM multiplatform support
watchdog: OMAP: fixup for ARM multiplatform support
ARM: EXYNOS: Add flush_cache_all in suspend finisher
ARM: EXYNOS: Remove scu_enable from cpuidle
ARM: EXYNOS: Fix soft reboot hang after suspend/resume
ARM: EXYNOS: Add support for rtc wakeup
ARM: EXYNOS: fix the hotplug for Cortex-A15
ARM: OMAP2+: omap_device: Correct resource handling for DT boot
ARM: OMAP2+: hwmod: Add possibility to count hwmod resources based on type
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count
ARM: OMAP2+: PRM: initialize some PRM functions early
ARM: OMAP2+: voltage: fixup oscillator handling when CONFIG_PM=n
ARM: OMAP4: USB: power down MUSB PHY during boot
ARM: OMAP2+: clock: Cleanup !CONFIG_COMMON_CLK parts
ARM: OMAP2xxx: clock: drop obsolete clock data
ARM: OMAP2: clock: Cleanup !CONFIG_COMMON_CLK parts
ARM: OMAP3+: DPLL: drop !CONFIG_COMMON_CLK sections
ARM: AM33xx: clock: drop obsolete clock data
ARM: OMAP3xxx: clk: drop obsolete clock data
...
Continued device tree conversion and enablement across a number of
platforms; Kirkwood, tegra, i.MX, Exynos, zynq and a couple of other
smaller series as well.
ux500 has seen continued conversion for platforms. Several platforms have
seen pinctrl-via-devicetree conversions for simpler multiplatform. Tegra
is adding data for new devices/drivers, and Exynos has a bunch of new
bindings and devices added as well.
So, pretty much the same progression in the right direction as the last
few releases.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQySW7AAoJEIwa5zzehBx39xcP/jzEQOTOJdK4zJd1OjgrQoX/
WnhbGJT941RNjRjvDG6HmZzhpsRoE4q/zkjFEKoKELdikRW0hYoR+zPCGuB7XtN5
aF1ZQrTx4gHf4KE7doIB8slaWeOq8aG2TLFhylyy+cuaIpRK0NG0pAR0ZqWaoga9
tZFciqzplLeo50vZ+y+lVVsR40j/w29EjwPXhCV30//gGOYLyp/VDu5PRtrBdgh8
EgpcT2EWJwMCN/Upcao/q2JbQktPHPpSwnpaUAALYB20uD7k5jo7wtYE/+L9nn6B
bxcCDTMVmqzNTF+y0P16hDcs5jMLVjpI0xBiyZ1G6gShpggsSZCHY5ynjAtQ19se
r+2WrNfOR23k6arJuOUAQSEnLdx0T5SlW6CJeFEofKv4uoebxAbKUiNO4ShWskhd
nNptX1+L3hj3zpjGcEHmL6bd+nGtyMeoG9Yekcv1oZxdVcpKhFxh0s5PEJBEeXcN
M7aAWlWJkplV22Olqhpc/3INCweq6E+zBrBxZaUBW/JCzGrqBUGC0BULDPAkmC4J
CKL6IqIB73jGQ4OY14IaMU20GJrIGxZ7wzXOp4aw3OUpRlxsgurfyFQeIjUvVoZL
PJ8DRoAVwreVHvKfgZZVKpSAY7dwcWbxpWsYlrH3zWIC5vRJ0UFwsD0TpLJWd6Vi
XA8gQcJRWKGS8E5mRY39
=Rk9v
-----END PGP SIGNATURE-----
Merge tag 'dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC device tree conversions and enablement from Olof Johansson:
"Continued device tree conversion and enablement across a number of
platforms; Kirkwood, tegra, i.MX, Exynos, zynq and a couple of other
smaller series as well.
ux500 has seen continued conversion for platforms. Several platforms
have seen pinctrl-via-devicetree conversions for simpler
multiplatform. Tegra is adding data for new devices/drivers, and
Exynos has a bunch of new bindings and devices added as well.
So, pretty much the same progression in the right direction as the
last few releases."
Fix up conflicts as per Olof.
* tag 'dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (185 commits)
ARM: ux500: Rename dbx500 cpufreq code to be more generic
ARM: dts: add missing ux500 device trees
ARM: ux500: Stop registering the PCM driver from platform code
ARM: ux500: Move board specific GPIO info out to subordinate DTS files
ARM: ux500: Disable the MMCI gpio-regulator by default
ARM: Kirkwood: remove kirkwood_ehci_init() from new boards
ARM: Kirkwood: Add support LED of OpenBlocks A6
ARM: Kirkwood: Convert to EHCI via DT for OpenBlocks A6
ARM: kirkwood: Add NAND partiton map for OpenBlocks A6
ARM: kirkwood: Add support second I2C bus and RTC on OpenBlocks A6
ARM: kirkwood: Add support DT of second I2C bus
ARM: kirkwood: Convert mplcec4 board to pinctrl
ARM: Kirkwood: Convert km_kirkwood to pinctrl
ARM: Kirkwood: support 98DX412x kirkwoods with pinctrl
ARM: Kirkwood: Convert IX2-200 to pinctrl.
ARM: Kirkwood: Convert lsxl boards to pinctrl.
ARM: Kirkwood: Convert ib62x0 to pinctrl.
ARM: Kirkwood: Convert GoFlex Net to pinctrl.
ARM: Kirkwood: Convert dreamplug to pinctrl.
ARM: Kirkwood: Convert dockstar to pinctrl.
...
Commit 5c8a86e10a (usb: musb: drop unneeded
musb_debug trickery) erroneously removed '\n' from the driver's banner.
Concatenate all the banner substrings while adding it back...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: stable@vger.kernel.org # 3.0+
Signed-off-by: Felipe Balbi <balbi@ti.com>
When a device is switched off by software, gserial_cleanup will
be called, and switch off will be blocked in this function
because wake_up_interruptible() in gs_close() can not wake_up
the wait_event() in gserial_cleanup(), it should be changed to
wake_up() to match the wait_event().
Signed-off-by: Haipeng YU <haipeng.yu@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In the error handling case of tcm_usbg_drop_nexus(), the error code
is assigned to 'ret', but it is ignored. We'd better return 'ret'
instead of always return 0.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
"54db6ee ARM: OMAP2+: Introduce local usb.h" moved control module bit
definitions from plat/usb.h (which dsps glue was using) to a local
header in mach-omap2. And in parallel,
"c68bb4c usb: musb: dsps: control module handling (quirk)" added
control module handling capability to dsps glue driver that used
those control module bit definitions.
Integration of above two changes would cause build error in musb dsps
glue driver (they go through different trees upstream) as is seen now
in linux-next. Fix it by adding necessary definitions in dsps glue
driver.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If we do have endpoints named like "ep-a" then bEndpointAddress is
counted internally by the gadget framework.
If we do have endpoints named like "ep-1" then bEndpointAddress is
assigned from the digit after "ep-".
If we do have both, then it is likely that after we used up the
"generic" endpoints we will use the digits and thus assign one
bEndpointAddress to multiple endpoints.
This theory can be proofed by using the completely enabled g_multi.
Without this patch, the mass storage won't enumerate and times out
because it shares endpoints with RNDIS.
This patch also adds fills up the endpoints list so we have in total
endpoints 1 to 15 in + out available while some of them are restricted
to certain types like BULK or ISO. Without this change the nokia gadget
won't load because the system does not provide enough (BULK) endpoints
but it did before ep-a - ep-f were removed.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
the clock common driver changes, and arch-mmp will make use of
the common clock driver instead of its own.
So for enable clock.
first prepare the clock
then enable the clock.
for disable clock
first disable the clock
then unprepare the clock
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
