This reverts commit 247bf55727.
This commit, together with commit 3804fad454
"USBNET: ax88179_178a: enable tso if usb host supports sg dma" were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.
USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.
The proper soluition is to implement the TD fragment rules required, but for now
this patch needs to be reverted to get USB 3.0 mass storage devices working at the
level they used to.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
threadirqs option is used. To prevent the deadlock use
spin_lock_irqsave() in ehci_irq().
This change can be reverted when hrtimer callbacks become threaded.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hello,
the following patch adds an entry for the PID of a Cressi Leonardo
diving computer interface to kernel 3.13.0.
It is detected as FT232RL.
Works with subsurface.
Signed-off-by: Joerg Dorchain <joerg@dorchain.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ENDPTFLUSH and ENDPTPRIME registers are set by software and clear
by hardware. There is a bit for each endpoint. When we are setting
a bit for an endpoint we should make sure we do not touch other
endpoint bit. There is a race condition if the hardware clear the
bit between the read and the write in hw_write.
Cc: stable <stable@vger.kernel.org> # 3.11+
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
Tested-by: Michael Grzeschik <mgrzeschik@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are 10 fixes for our current -rc cycle. It's likely
the last round of fixes for this merge window. All patches
have soaked for a long time and have all been tested in real
HW.
The most interesting fixes are a fix for enumeration of superspeed
hubs when MUSB is acting as host, and a remote-wakeup fix also on
MUSB.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTBh4hAAoJEIaOsuA1yqRE+ygP/jl+bAZl2YXJ5obPHWu6N/Px
G90zXh39+n4mLWNo+uVOBUkwDs+T/7bnorQQdiOAQ8+GUYG7rbn5wYM8ufD2aiPN
lrHIRVS//hOuz6M6i50Y6SM5DnmImF7h4muKiTT76azFNRLSuBL1jJphsjVCg7bl
6xfB0Uvb2lcjXgjzAbrxHzb0/4TtUXJup1CPiFba7oc1YtfeyLbmdZmsayyH0HGB
g+8WLaQpCz7s7vekSMauO1Kqj4+FBuEyP34D0M61H1KARsNu89KT+NEY9z/G8stt
/r7zPr9lVoJaBXucjmRWu+7FCcktj0h4Ys+HKkzkx6S2NSAcL9P7jC/yB6bCzvvx
AkU9vaZ9cY9XaENfhKKAO4Sqr2KqzHSpTcRy8VfZzbb8SvAgt4lZNCMjmpGDfLzw
DoxP4OpK7HGVIOmVbgecl/gep7lAxHP6QrWMMuGt/T3yVj5Qes6dydKUTYOtbn+o
aKa+euf2La9mj8cXeaV/NI4ewU34ejhYCGLQ7bG9zsi2t2QUB2QdSKKMQHN3tL+3
lcmAYvtQKbda21i7AXdO/ddUzdqOU9k3uAiPD9/u7Kdj+1iC3LiXie0GiLwNEm1S
QWzBZiSb73+NjTpztshim2f8GjhOkjTO8OvP3x9wdqo/SLp0LLN/WY+j09YI9S0o
AZWQh5GGHUGK48bTS2zB
=AnZJ
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.14-rc4
Here are 10 fixes for our current -rc cycle. It's likely
the last round of fixes for this merge window. All patches
have soaked for a long time and have all been tested in real
HW.
The most interesting fixes are a fix for enumeration of superspeed
hubs when MUSB is acting as host, and a remote-wakeup fix also on
MUSB.
Signed-of-by: Felipe Balbi <balbi@ti.com>
schedule_delayed_work() takes the delay in jiffies, not msecs.
This bug slipped in with the recent reset logic cleanup
(8ed1fb790e: "usb: musb: finish suspend/reset work independently from
musb_hub_control()").
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.
Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().
While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.
This address the following errors Russell King has hit doing randconfig
builds:
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function 'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function 'msm_otg_resume'
Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fix possible NULL pointer dereference introduced in
commit 219580e (usb: f_fs: check quirk to pad epout
buf size when not aligned to maxpacketsize)
In cases we do wait with:
wait_event_interruptible(epfile->wait, (ep = epfile->ep));
for endpoint to be enabled, functionfs_bind() has not been called yet
and epfile->ffs->gadget is still NULL and the automatic variable 'gadget'
has been initialized with NULL at the point of its definition.
Later on it is used as a parameter to:
usb_ep_align_maybe(gadget, ep->ep, len)
which in turn dereferences it.
This patch fixes it by moving the actual assignment to the local 'gadget'
variable after the potential waiting has completed.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We need to use gadget_is_otg to check if the gadget is really
otg support at runtime, other composite gadget drivers have already
followed this method.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
schedule_delayed_work() takes the delay in jiffies, not msecs. Fix the
caller sites in musb. This bug caused regressions with the cleanups
that went in for 3.14 (8ed1fb790e: "usb: musb: finish suspend/reset
work independently from musb_hub_control()").
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
musb_port_reset() is called from musb_hub_control() which in turn holds
a spinlock, so musb_port_reset() is not allowed to call msleep().
With the asynchronous work helpers in place, this is fortunately easy to
fix by rescheduling the reset deassertion function to after the time
when the wait period is finished.
Note, however, that the MUSB_POWER_RESUME bit is only set on AM33xx
processors under rare conditions such as when to another driver
reporting an error during suspend. Hence, this didn't hit me yet in
normal operation.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This interface is to be handled by the qmi_wwan driver.
CC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
CC: Christian Schmiedl <christian.schmiedl@gemalto.com>
CC: Nicolaus Colberg <nicolaus.colberg@gemalto.com>
CC: David McCullough <david.mccullough@accelecon.com>
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
High-speed USB connections revert back to full-speed signalling when
the device goes into suspend. This takes several milliseconds, and
during that time it's not possible to tell reliably whether the device
has been disconnected.
On some platforms, the Wake-On-Disconnect circuitry gets confused
during this intermediate state. It generates a false wakeup signal,
which can prevent the controller from going to sleep.
To avoid this problem, this patch adds a 5-ms delay to the
ehci_bus_suspend() routine if any ports have to switch over to
full-speed signalling. (Actually, the delay was already present for
devices using a particular kind of PHY power management; the patch
merely causes the delay to be used more widely.)
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Peter Chen <Peter.Chen@freescale.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 3dc6475 ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
changed the ENETDMA[CS] macros such that they are no longer macros, but
actual register offset definitions. The bcm63xx_udc driver was not
updated, and as a result, causes the following build error to pop up:
CC drivers/usb/gadget/u_ether.o
drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_write':
drivers/usb/gadget/bcm63xx_udc.c:642:24: error: called object '0' is not
a function
drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_reset_channel':
drivers/usb/gadget/bcm63xx_udc.c:698:46: error: called object '0' is not
a function
drivers/usb/gadget/bcm63xx_udc.c:700:49: error: called object '0' is not
a function
Fix this by updating usb_dmac_{read,write}l and usb_dmas_{read,write}l to
take an extra channel argument, and use the channel width
(ENETDMA_CHAN_WIDTH) to offset the register we want to access, hence
doing again what the macro implicitely did for us.
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Jonas Gorski <jogo@openwrt.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
musb_port_reset() is called from musb_hub_control() which in turn holds
a spinlock, so musb_port_reset() is not allowed to call msleep().
With the asynchronous work helpers in place, this is fortunately easy to
fix by rescheduling the reset deassertion function to after the time
when the wait period is finished.
Note, however, that the MUSB_POWER_RESUME bit is only set on AM33xx
processors under rare conditions such as when to another driver
reporting an error during suspend. Hence, this didn't hit me yet in
normal operation.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Pass value instead of address as expected by 'usb_ep_set_maxpacket_limit'.
Fixes the following compilation error introduced by commit e117e742d3
("usb: gadget: add "maxpacket_limit" field to struct usb_ep"):
drivers/usb/gadget/s3c2410_udc.c: In function ‘s3c2410_udc_reinit’:
drivers/usb/gadget/s3c2410_udc.c:1632:3: error:
cannot take address of bit-field ‘maxpacket’
usb_ep_set_maxpacket_limit(&ep->ep, &ep->ep.maxpacket);
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Reviewed-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
During resume don't touch SUSPENDM/RESUME bits of POWER register
while restoring controller context. These bits might be changed
by the controller during resume operation and so will be different
than what they were during suspend.
e.g. SUSPENDM bit is set by software during USB global suspend but
automatically cleared by the controller during remote wakeup or
during resume. Setting this bit back while restoring context
causes undesired behaviour. i.e. Babble interrupt is generated
and USB is broken.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Disables PING on status phase of control transfer.
PING token is not mandatory in status phase of control transfer
and so some high speed USB devices don't support it. If such devices
are connected to MUSB then they would not respond to PING token
causing delayed or failed enumeration.
[Roger Q] Fixes enumeration issues with some Super-Speed USB hubs
e.g. Dlink DUB-1340
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Interface #5 of 19d2:1270 is a net interface which has been submitted to the
qmi_wwan driver so consequently remove it from the option driver.
Signed-off-by: Raymond Wanyoike <raymond.wanyoike@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 35773dac5f. It's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb. Commit 70cabb7d992f "xhci 1.0: Limit
arbitrarily-aligned scatter gather." should fix the issues seen with the
ax88179_178a driver on xHCI 1.0 hosts, without causing regressions.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org # 3.12
This reverts commit d6c9ea9069.
We are ripping out commit 35773dac5f "usb:
xhci: Link TRB must not occur within a USB payload burst" because it's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb. This commit attempted to fix the
issues with that patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org # 3.12
This reverts commit f2d9b991c5.
We are ripping out commit 35773dac5f "usb:
xhci: Link TRB must not occur within a USB payload burst" because it's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb. This commit attempted to fix the
issues with that patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org #3.12
xHCI 1.0 hosts have a set of requirements on how to align transfer
buffers on the endpoint rings called "TD fragment" rules. When the
ax88179_178a driver added support for scatter gather in 3.12, with
commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a:
enable tso if usb host supports sg dma", it broke the device under xHCI
1.0 hosts. Under certain network loads, the device would see an
unexpected short packet from the host, which would cause the device to
stop sending ethernet packets, even through USB packets would still be
sent.
Commit 35773dac5f "usb: xhci: Link TRB must not occur within a USB
payload burst" attempted to fix this. It was a quick hack to partially
implement the TD fragment rules. However, it caused regressions in the
usb-storage layer and userspace USB drivers using libusb. The patches
to attempt to fix this are too far reaching into the USB core, and we
really need to implement the TD fragment rules correctly in the xHCI
driver, instead of continuing to wallpaper over the issues.
Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0
hosts. Only the ax88179_178a driver checks the no_sg_constraint flag,
so don't set it for 1.0 hosts. This should not impact usb-storage or
usbfs behavior, since they pass down max packet sized aligned sg-list
entries (512 for USB 2.0 and 1024 for USB 3.0).
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Mark Lord <mlord@pobox.com>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Bjørn Mork <bjorn@mork.no>
Cc: Freddy Xin <freddy@asix.com.tw>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: stable@vger.kernel.org # 3.12
Fix a memory leak in the usb_store_new_id() error paths. When bailing out
due to sanity checks, the function left the already allocated usb_dynid
struct in place. This regression was introduced by the following commits:
c63fe8f6 (usb: core: add sanity checks when using bInterfaceClass with new_id)
1b9fb31f (usb: core: check for valid id_table when using the RefId feature)
52a6966c (usb: core: bail out if user gives an unknown RefId when using new_id)
Detected by Coverity: CID 1162604.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adding two more IDs to the ftdi_sio usb serial driver.
It now connects Tagsys RFID readers.
There might be more IDs out there for other Tagsys models.
Signed-off-by: Ulrich Hahn <uhahn@eanco.de>
Cc: Johan Hovold <johan@hovold.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This device was mentioned in an OpenWRT forum. Seems to have a "standard"
Sierra Wireless ifnumber to function layout:
0: qcdm
2: nmea
3: modem
8: qmi
9: storage
Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
People sometimes create their own custom-configured kernels and forget
to enable CONFIG_SCSI_MULTI_LUN. This causes problems when they plug
in a USB storage device (such as a card reader) with more than one
LUN.
Fortunately, we can tell fairly easily when a storage device claims to
have more than one LUN. When that happens, this patch asks the SCSI
layer to probe all the LUNs automatically, regardless of the config
setting.
The patch also updates the Kconfig help text for usb-storage,
explaining that CONFIG_SCSI_MULTI_LUN may be necessary.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Thomas Raschbacher <lordvan@lordvan.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
CC: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for ANT USB-m Stick from Dynastream Innovations, by listing
USB pid
[34366.944805] usb 6-1: New USB device found, idVendor=0fcf, idProduct=1009
[34366.944817] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[34366.944824] usb 6-1: Product: ANT USB-m Stick
[34366.944831] usb 6-1: Manufacturer: Dynastream Innovations
Device reported (https://code.google.com/p/antpm/issues/detail?id=5) to
work through:
$ modprobe usbserial vendor=0x0fcf product=0x1009
Signed-off-by: Kristóf Ralovich <kristof.ralovich@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 adds an unusual-devs entry for the BlackBerry 9000. This
fixes Bugzilla #22442.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de>
Tested-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Cypress ATACB unusual-devs entry for the Super Top SATA bridge
causes problems. Although it was originally reported only for
bcdDevice = 0x160, its range was much larger. This resulted in a bug
report for bcdDevice 0x220, so the range was capped at 0x219. Now
Milan reports errors with bcdDevice 0x150.
Therefore this patch restricts the range to just 0x160.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Milan Svoboda <milan.svoboda@centrum.cz>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
the PHY layer is supposed to be optional,
considering some PHY have no control bus
for SW to poke around.
After commit 1ae5799 (usb: hcd: Initialize
USB phy if needed) any HCD which didn't provide
a PHY driver would emit annoying error messages.
In this patch we're decreasing those messages
to debugging only and we also add a PHY prefix
or use dev_dbg so we know where they're coming from.
Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The move from the staging tree to the main tree exposed a
longstanding memory corruption bug in the dwc2 driver. The
reordering of the driver initialization caused the dwc2 driver
to corrupt the initialization data of the sdhci driver on the
Raspberry Pi platform, which made the bug show up.
The error is in calling to_usb_device(hsotg->dev), since ->dev
is not a member of struct usb_device. The easiest fix is to
just remove the offending code, since it is not really needed.
Thanks to Stephen Warren for tracking down the cause of this.
Reported-by: Andre Heider <a.heider@gmail.com>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit beb7e592bc "staging: dwc2: add check on dwc2_core_reset
return" broke the B -> A role switching on OTG-enabled platforms.
This commit fixes it.
Reported-by: Dinh Nguyen <dinguyen@altera.com>
Tested-by: Dinh Nguyen <dinguyen@altera.com>
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add usb_disabled() check to prevent kernel oops when booting with "nousb"
in the cmdline:
Unable to handle kernel NULL pointer dereference at virtual address 00000030
...
PC is at bus_add_device+0xe0/0x18c
LR is at device_add_groups+0x1c/0x20
...
[<c02191c0>] (bus_add_device) from [<c0217130>] (device_add+0x41c/0x538)
[<c0217130>] (device_add) from [<c023b1d4>] (usb_new_device+0x270/0x35c)
[<c023b1d4>] (usb_new_device) from [<c0241174>] (usb_add_hcd+0x4fc/0x760)
[<c0241174>] (usb_add_hcd) from [<c0254ce0>] (dwc2_hcd_init+0x434/0x510)
[<c0254ce0>] (dwc2_hcd_init) from [<c02594f4>] (dwc2_driver_probe+0x130/0x170)
[<c02594f4>] (dwc2_driver_probe) from [<c021bbd0>] (platform_drv_probe+0x28/0x58)
Signed-off-by: Andre Heider <a.heider@gmail.com>
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg,
Here's four patches for 3.14.
One of them adds an xHCI host quirk, and the other three of them fix
regressions introduced in 3.14. One regression causes USB 3.0 Link PM to
be enabled on all xHCI hosts (even those that may not support it), which
causes some USB 3.0 devices to not enumerate. A second regression causes
some xHCI hosts that don't support 64-bit addressing to stop responding to
commands and die.
Note, these patches don't fix the recent usbfs regression that was caused
by commit 35773dac5f "usb: xhci: Link TRB
must not occur within a USB payload burst". I'm waiting for those patches
to be tested.
Please pull usb-linus into usb-next, as I have feature patches that rely on
140e3026a5 Revert "usbcore: set lpm_capable field for LPM capable root
hubs"
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJS8UyYAAoJEBMGWMLi1Gc5G9AP/jTLQoh/9ILE3fPN9UeXHr7x
TR3sWrB2JB6HzO53FJqoIWdnyei+GQRHRYKFZbJRMIXSdfI7EiJ9ZaFvGKYkOjyg
FblD2WqYn5jY2yiW8roxOebDzDadxxqafwtrqIGx88sV9o9yKInhBq5NqxD1ZC/X
QM9Dbgxed4TX6OVVE8hvUbzr1gldYiUr8rKfvN8X6RDBEi6wh6HV0B/7T96vw6Hp
hFDIgIdwgVYsnah2QjS007tpNFfWQtoi3sq+Jcq0S6QVpCrTPjPB6MqHJM/MQtG+
8JkmZRPA8jjwaPvow8Kx3bmt89H5Q/hWKlUPZmaShOO4OKN3xOQNh+FNbvqs1pPZ
XpL3/dv/w/zzQ7sqD2IaT9HiDfzeYfspdiv9QsSJg7XlfiulgdCggrhIGvta6p51
bR0JEHMxSuI/Aqe/fr5Prf4YyeWS+fDKIwRsaNXG143pd7hFJxoyT91QE3FCxAdD
qmw/YdeDT7J+3TB55OCPIxuaOTEjJQ9GyKXP/TKaSrTVWcH8/N0wNMa7IPSplysN
fgeNNDtZ0A7P4XyyMNxaQpbRcM39eV/yGaVR6yDqjJ4RlEZTTTOMfNSaVoCXIb74
3km6DVSqEQ0xPq08nrIcWbPqor+hShbw/bbUJCQBITKJp6oDeImacCvZw7RaYhfs
cx7UuQPKmv7iYaG1Vmcm
=sPwW
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2014-02-04' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Sarah writes:
xhci: Fix some regressions introduced in 3.14.
Hi Greg,
Here's four patches for 3.14.
One of them adds an xHCI host quirk, and the other three of them fix
regressions introduced in 3.14. One regression causes USB 3.0 Link PM to
be enabled on all xHCI hosts (even those that may not support it), which
causes some USB 3.0 devices to not enumerate. A second regression causes
some xHCI hosts that don't support 64-bit addressing to stop responding to
commands and die.
Note, these patches don't fix the recent usbfs regression that was caused
by commit 35773dac5f "usb: xhci: Link TRB
must not occur within a USB payload burst". I'm waiting for those patches
to be tested.
Please pull usb-linus into usb-next, as I have feature patches that rely on
140e3026a5 Revert "usbcore: set lpm_capable field for LPM capable root
hubs"
Sarah Sharp
This reverts commit e8b373326d. Many xHCI
host controllers can only handle 32-bit addresses, and writing 64-bits
at a time causes them to fail. Reading 64-bits at a time may also cause
them to return 0xffffffff, so revert this commit as well.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This reverts commit 7dd09a1af2.
Many xHCI host controllers can only handle 32-bit addresses, and writing
64-bits at a time causes them to fail. Rafał reports that USB devices
simply do not enumerate, and reverting this patch helps. Branimir
reports that his host controller doesn't respond to an Enable Slot
command and dies:
[ 75.576160] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
[ 88.991634] xhci_hcd 0000:03:00.0: Stopped the command ring failed, maybe the host is dead
[ 88.991748] xhci_hcd 0000:03:00.0: Abort command ring failed
[ 88.991845] xhci_hcd 0000:03:00.0: HC died; cleaning up
[ 93.985489] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
[ 93.985494] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead.
[ 98.982586] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
[ 98.982591] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead.
[ 103.979696] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
[ 103.979702] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead
Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com>
Reported-by: Rafał Miłecki <zajec5@gmail.com>
Reported-by: Branimir Maksimovic <branimir.maksimovic@gmail.com>
Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
<<
Switch mpc512x to the common clock framework and adapt mpc512x
drivers to use the new clock driver. Old PPC_CLOCK code is
removed entirely since there are no users any more.
>>
- ACPI core changes to make it create a struct acpi_device object for every
device represented in the ACPI tables during all namespace scans regardless
of the current status of that device. In accordance with this, ACPI hotplug
operations will not delete those objects, unless the underlying ACPI tables
go away.
- On top of the above, new sysfs attribute for ACPI device objects allowing
user space to check device status by triggering the execution of _STA for
its ACPI object. From Srinivas Pandruvada.
- ACPI core hotplug changes reducing code duplication, integrating the
PCI root hotplug with the core and reworking container hotplug.
- ACPI core simplifications making it use ACPI_COMPANION() in the code
"glueing" ACPI device objects to "physical" devices.
- ACPICA update to upstream version 20131218. This adds support for the
DBG2 and PCCT tables to ACPICA, fixes some bugs and improves debug
facilities. From Bob Moore, Lv Zheng and Betty Dall.
- Init code change to carry out the early ACPI initialization earlier.
That should allow us to use ACPI during the timekeeping initialization
and possibly to simplify the EFI initialization too. From Chun-Yi Lee.
- Clenups of the inclusions of ACPI headers in many places all over from
Lv Zheng and Rashika Kheria (work in progress).
- New helper for ACPI _DSM execution and rework of the code in drivers
that uses _DSM to execute it via the new helper. From Jiang Liu.
- New Win8 OSI blacklist entries from Takashi Iwai.
- Assorted ACPI fixes and cleanups from Al Stone, Emil Goode, Hanjun Guo,
Lan Tianyu, Masanari Iida, Oliver Neukum, Prarit Bhargava, Rashika Kheria,
Tang Chen, Zhang Rui.
- intel_pstate driver updates, including proper Baytrail support, from
Dirk Brandewie and intel_pstate documentation from Ramkumar Ramachandra.
- Generic CPU boost ("turbo") support for cpufreq from Lukasz Majewski.
- powernow-k6 cpufreq driver fixes from Mikulas Patocka.
- cpufreq core fixes and cleanups from Viresh Kumar, Jane Li, Mark Brown.
- Assorted cpufreq drivers fixes and cleanups from Anson Huang, John Tobias,
Paul Bolle, Paul Walmsley, Sachin Kamat, Shawn Guo, Viresh Kumar.
- cpuidle cleanups from Bartlomiej Zolnierkiewicz.
- Support for hibernation APM events from Bin Shi.
- Hibernation fix to avoid bringing up nonboot CPUs with ACPI EC disabled
during thaw transitions from Bjørn Mork.
- PM core fixes and cleanups from Ben Dooks, Leonardo Potenza, Ulf Hansson.
- PNP subsystem fixes and cleanups from Dmitry Torokhov, Levente Kurusa,
Rashika Kheria.
- New tool for profiling system suspend from Todd E Brandt and a cpupower
tool cleanup from One Thousand Gnomes.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJS3a1eAAoJEILEb/54YlRxnTgP/iGawvgjKWm6Qqp7WSIvd5gQ
zZ6q75C6Pc/W2fq1+OzVGnpCF8WYFy+nFDAXOvUHjIXuoxSwFcuW5l4aMckgl/0a
TXEWe9MJrCHHRfDApfFacCJ44U02bjJAD5vTyL/hKA+IHeinq4WCSojryYC+8jU0
cBrUIV0aNH8r5JR2WJNAyv/U29rXsDUOu0I4qTqZ4YaZT6AignMjtLXn1e9AH1Pn
DPZphTIo/HMnb+kgBOjt4snMk+ahVO9eCOxh/hH8ecnWExw9WynXoU5Nsna0tSZs
ssyHC7BYexD3oYsG8D52cFUpp4FCsJ0nFQNa2kw0LY+0FBNay43LySisKYHZPXEs
2WpESDv+/t7yhtnrvM+TtA7aBheKm2XMWGFSu/aERLE17jIidOkXKH5Y7ryYLNf/
uyRKxNS0NcZWZ0G+/wuY02jQYNkfYz3k/nTr8BAUItRBjdporGIRNEnR9gPzgCUC
uQhjXWMPulqubr8xbyefPWHTEzU2nvbXwTUWGjrBxSy8zkyy5arfqizUj+VG6afT
NsboANoMHa9b+xdzigSFdA3nbVK6xBjtU6Ywntk9TIpODKF5NgfARx0H+oSH+Zrj
32bMzgZtHw/lAbYsnQ9OnTY6AEWQYt6NMuVbTiLXrMHhM3nWwfg/XoN4nZqs6jPo
IYvE6WhQZU6L6fptGHFC
=dRf6
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management updates from Rafael Wysocki:
"As far as the number of commits goes, the top spot belongs to ACPI
this time with cpufreq in the second position and a handful of PM
core, PNP and cpuidle updates. They are fixes and cleanups mostly, as
usual, with a couple of new features in the mix.
The most visible change is probably that we will create struct
acpi_device objects (visible in sysfs) for all devices represented in
the ACPI tables regardless of their status and there will be a new
sysfs attribute under those objects allowing user space to check that
status via _STA.
Consequently, ACPI device eject or generally hot-removal will not
delete those objects, unless the table containing the corresponding
namespace nodes is unloaded, which is extremely rare. Also ACPI
container hotplug will be handled quite a bit differently and cpufreq
will support CPU boost ("turbo") generically and not only in the
acpi-cpufreq driver.
Specifics:
- ACPI core changes to make it create a struct acpi_device object for
every device represented in the ACPI tables during all namespace
scans regardless of the current status of that device. In
accordance with this, ACPI hotplug operations will not delete those
objects, unless the underlying ACPI tables go away.
- On top of the above, new sysfs attribute for ACPI device objects
allowing user space to check device status by triggering the
execution of _STA for its ACPI object. From Srinivas Pandruvada.
- ACPI core hotplug changes reducing code duplication, integrating
the PCI root hotplug with the core and reworking container hotplug.
- ACPI core simplifications making it use ACPI_COMPANION() in the
code "glueing" ACPI device objects to "physical" devices.
- ACPICA update to upstream version 20131218. This adds support for
the DBG2 and PCCT tables to ACPICA, fixes some bugs and improves
debug facilities. From Bob Moore, Lv Zheng and Betty Dall.
- Init code change to carry out the early ACPI initialization
earlier. That should allow us to use ACPI during the timekeeping
initialization and possibly to simplify the EFI initialization too.
From Chun-Yi Lee.
- Clenups of the inclusions of ACPI headers in many places all over
from Lv Zheng and Rashika Kheria (work in progress).
- New helper for ACPI _DSM execution and rework of the code in
drivers that uses _DSM to execute it via the new helper. From
Jiang Liu.
- New Win8 OSI blacklist entries from Takashi Iwai.
- Assorted ACPI fixes and cleanups from Al Stone, Emil Goode, Hanjun
Guo, Lan Tianyu, Masanari Iida, Oliver Neukum, Prarit Bhargava,
Rashika Kheria, Tang Chen, Zhang Rui.
- intel_pstate driver updates, including proper Baytrail support,
from Dirk Brandewie and intel_pstate documentation from Ramkumar
Ramachandra.
- Generic CPU boost ("turbo") support for cpufreq from Lukasz
Majewski.
- powernow-k6 cpufreq driver fixes from Mikulas Patocka.
- cpufreq core fixes and cleanups from Viresh Kumar, Jane Li, Mark
Brown.
- Assorted cpufreq drivers fixes and cleanups from Anson Huang, John
Tobias, Paul Bolle, Paul Walmsley, Sachin Kamat, Shawn Guo, Viresh
Kumar.
- cpuidle cleanups from Bartlomiej Zolnierkiewicz.
- Support for hibernation APM events from Bin Shi.
- Hibernation fix to avoid bringing up nonboot CPUs with ACPI EC
disabled during thaw transitions from Bjørn Mork.
- PM core fixes and cleanups from Ben Dooks, Leonardo Potenza, Ulf
Hansson.
- PNP subsystem fixes and cleanups from Dmitry Torokhov, Levente
Kurusa, Rashika Kheria.
- New tool for profiling system suspend from Todd E Brandt and a
cpupower tool cleanup from One Thousand Gnomes"
* tag 'pm+acpi-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (153 commits)
thermal: exynos: boost: Automatic enable/disable of BOOST feature (at Exynos4412)
cpufreq: exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ
Documentation: cpufreq / boost: Update BOOST documentation
cpufreq: exynos: Extend Exynos cpufreq driver to support boost
cpufreq / boost: Kconfig: Support for software-managed BOOST
acpi-cpufreq: Adjust the code to use the common boost attribute
cpufreq: Add boost frequency support in core
intel_pstate: Add trace point to report internal state.
cpufreq: introduce cpufreq_generic_get() routine
ARM: SA1100: Create dummy clk_get_rate() to avoid build failures
cpufreq: stats: create sysfs entries when cpufreq_stats is a module
cpufreq: stats: free table and remove sysfs entry in a single routine
cpufreq: stats: remove hotplug notifiers
cpufreq: stats: handle cpufreq_unregister_driver() and suspend/resume properly
cpufreq: speedstep: remove unused speedstep_get_state
platform: introduce OF style 'modalias' support for platform bus
PM / tools: new tool for suspend/resume performance optimization
ACPI: fix module autoloading for ACPI enumerated devices
ACPI: add module autoloading support for ACPI enumerated devices
ACPI: fix create_modalias() return value handling
...
Updates of SoC-near drivers and other driver updates that makes more sense to
take through our tree.
The largest part of this is a conversion of device registration for some
renesas shmobile/sh devices over to use resources. This has required
coordination with the corresponding arch/sh changes, and we've agreed
to merge the arch/sh changes through our tree.
Added in this branch is support for Trusted Foundations secure firmware,
which is what is used on many of the commercial Nvidia Tegra products
that are in the market, including the Nvidia Shield. The code is local
to arch/arm at this time since it's uncertain whether it will be shared
with arm64 longer-term, if needed we will refactor later.
A couple of new RTC drivers used on ARM boards, merged through our tree
on request by the RTC maintainer.
... plus a bunch of smaller updates across the board, gpio conversions
for davinci, etc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJS4ViqAAoJEIwa5zzehBx3m4QP/07VXVE77RFRyly5Bky5AaMY
zo7ZpoJyg/IT9lxtSAQDhbQq49tKZQVS16oJ7LWXzjAyCY9XrVDX2IkcuqudmYSy
Xtx+R0jZGK4czqljgjwdHgNCSwugCmO/kgNY3h8ar53dTmGIFiq5boPeMDizRTGD
g3sgYuQbIqepcHd2jUjJSBXNyvZIlwBJ4wDyZgxRfzyM7unS8T46BpYNJz0esAL+
0DwIk0nv1eJ6LI0aEL+7bgFaitjUNLpcrroToi1IiIEJuTvZY4AuBjAKt5/181zL
i1ugimsHahmbwNclAmUimc0rtW4Nn+YHGa8WpYiQ9O7+kPFsYkfLRplHPOjaUBPz
r76ucgBMGH6i04tvstwlONznO4NhkACWmb4wrfJfRoDTglELLoOd6QGAYKyRublH
SnrKKmuXzBvtmj2zgUU+S0ka9LdYrjzxoSYprrXQpDr89pUs/AZrlAm9yRjQ3hGw
0eL9UsDFtYAQwCQtPvin2bjKRgNNDbgdwNYNbA7n8jvE/uZ4rlYr3Ot+oxdfs75e
K4fY6JwtbZxQVcOU25M3WBYXLl0V61ZISFa16XhYC2hjzgMZ3bfmFUn+TW9C8V4V
03QqtFyT3FP+VfA3QUS3PuBxALT0HWXmDqp0VJc6UCiXX2InWR+uZQp7a30EawOZ
WHLqgf+nT3bD3kfagCZN
=JJlw
-----END PGP SIGNATURE-----
Merge tag 'drivers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM driver updates from Olof Johansson:
"Updates of SoC-near drivers and other driver updates that makes more
sense to take through our tree.
The largest part of this is a conversion of device registration for
some renesas shmobile/sh devices over to use resources. This has
required coordination with the corresponding arch/sh changes, and
we've agreed to merge the arch/sh changes through our tree.
Added in this branch is support for Trusted Foundations secure
firmware, which is what is used on many of the commercial Nvidia Tegra
products that are in the market, including the Nvidia Shield. The
code is local to arch/arm at this time since it's uncertain whether it
will be shared with arm64 longer-term, if needed we will refactor
later.
A couple of new RTC drivers used on ARM boards, merged through our
tree on request by the RTC maintainer.
... plus a bunch of smaller updates across the board, gpio conversions
for davinci, etc"
* tag 'drivers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (45 commits)
watchdog: davinci: rename platform driver to davinci-wdt
tty: serial: Limit msm_serial_hs driver to platforms that use it
mmc: msm_sdcc: Limit driver to platforms that use it
usb: phy: msm: Move mach dependent code to platform data
clk: versatile: fixup IM-PD1 clock implementation
clk: versatile: pass a name to ICST clock provider
ARM: integrator: pass parent IRQ to the SIC
irqchip: versatile FPGA: support cascaded interrupts from DT
gpio: davinci: don't create irq_domain in case of unbanked irqs
gpio: davinci: use chained_irq_enter/chained_irq_exit API
gpio: davinci: add OF support
gpio: davinci: remove unused variable intc_irq_num
gpio: davinci: convert to use irqdomain support.
gpio: introduce GPIO_DAVINCI kconfig option
gpio: davinci: get rid of DAVINCI_N_GPIO
gpio: davinci: use {readl|writel}_relaxed() instead of __raw_*
serial: sh-sci: Add OF support
serial: sh-sci: Add device tree bindings documentation
serial: sh-sci: Remove platform data mapbase and irqs fields
serial: sh-sci: Remove platform data scbrr_algo_id field
...
This is the branch where we usually queue up cleanup efforts, moving
drivers out of the architecture directory, header file restructuring,
etc. Sometimes they tangle with new development so it's hard to keep it
strictly to cleanups.
Some of the things included in this branch are:
* Atmel SAMA5 conversion to common clock
* Reset framework conversion for tegra platforms
- Some of this depends on tegra clock driver reworks that are shared with Mike
Turquette's clk tree.
* Tegra DMA refactoring, which are shared branches with the DMA tree.
* Removal of some header files on exynos to prepare for multiplatform
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJS4Vf7AAoJEIwa5zzehBx3f9UP/jwMlbfbSZHfNQ/QG0SqZ9RD
zvddyDMHY/qXnzgF3Dax+JR9BDDVy8AlQe713FCoiHJZggWRAbbavkx8gxITDrZQ
6NYaEkkuVxqyM8APl3PwMqYm8UZ8MUf4lCltlOA4jkesY9vue91AFnfyKh2CvHrn
Leg4XT6mFzf/vYDL6RbvTz/Qr253uv3KvYBxkeiRNa0Y7OXRemEXSOfgxh0YGxUl
LZ2IWQFOh/DH4kaeQI8V4G67X3ceHiFyhCnl0CPwfxaZaNBVaxvIFgIUTdetS6Sb
zcXa029tE/Dfsr55vZAv9LUHEipCSOeE5rn2EJWehTWyM7vJ42Eozqgh+zfCjXS7
Ib6g2npsvIluQit/RdITu44h5yZlrQsLgKTGJ8jjXqbT4HQ/746W8b/TP0YLtbw7
N8oqr7k4vsZyF0dAYZQtfQUZeGISz67UbFcdzl9tmYOR7HFuAYkAQYst77zkVJf8
om59BAYYTG5FNjQ4I9AKUfJzxXYveI6AKpXSCCZiahpFM2D1CJIzp9Wi0GwK1HRR
sFVWhS0dajvz63pVVC2tw5Sq4J7onRRNGIXFPoE5fkmlelm0/q0zzGjw3Z0nTqbZ
8zxuwuy2FfPJK11GbUAIhAgn1sCLYyAhl6IE+FsanGeMOSGIMrH0v5/HphAxoCXt
BvqMDogyLoGPce1Gm3pJ
=3CcT
-----END PGP SIGNATURE-----
Merge tag 'cleanup-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC cleanups from Olof Johansson:
"This is the branch where we usually queue up cleanup efforts, moving
drivers out of the architecture directory, header file restructuring,
etc. Sometimes they tangle with new development so it's hard to keep
it strictly to cleanups.
Some of the things included in this branch are:
* Atmel SAMA5 conversion to common clock
* Reset framework conversion for tegra platforms
- Some of this depends on tegra clock driver reworks that are shared
with Mike Turquette's clk tree.
* Tegra DMA refactoring, which are shared branches with the DMA tree.
* Removal of some header files on exynos to prepare for
multiplatform"
* tag 'cleanup-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (169 commits)
ARM: mvebu: move Armada 370/XP specific definitions to armada-370-xp.h
ARM: mvebu: remove prototypes of non-existing functions from common.h
ARM: mvebu: move ARMADA_XP_MAX_CPUS to armada-370-xp.h
serial: sh-sci: Rework baud rate calculation
serial: sh-sci: Compute overrun_bit without using baud rate algo
serial: sh-sci: Remove unused GPIO request code
serial: sh-sci: Move overrun_bit and error_mask fields out of pdata
serial: sh-sci: Support resources passed through platform resources
serial: sh-sci: Don't check IRQ in verify port operation
serial: sh-sci: Set the UPF_FIXED_PORT flag
serial: sh-sci: Remove duplicate interrupt check in verify port op
serial: sh-sci: Simplify baud rate calculation algorithms
serial: sh-sci: Remove baud rate calculation algorithm 5
serial: sh-sci: Sort headers alphabetically
ARM: EXYNOS: Kill exynos_pm_late_initcall()
ARM: EXYNOS: Consolidate selection of PM_GENERIC_DOMAINS for Exynos4
ARM: at91: switch Calao QIL-A9260 board to DT
clk: at91: fix pmc_clk_ids data type attriubte
PM / devfreq: use inclusion <mach/map.h> instead of <plat/map-s5p.h>
ARM: EXYNOS: remove <mach/regs-clock.h> for exynos
...
Pull trivial tree updates from Jiri Kosina:
"Usual rocket science stuff from trivial.git"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
neighbour.h: fix comment
sched: Fix warning on make htmldocs caused by wait.h
slab: struct kmem_cache is protected by slab_mutex
doc: Fix typo in USB Gadget Documentation
of/Kconfig: Spelling s/one/once/
mkregtable: Fix sscanf handling
lp5523, lp8501: comment improvements
thermal: rcar: comment spelling
treewide: fix comments and printk msgs
IXP4xx: remove '1 &&' from a condition check in ixp4xx_restart()
Documentation: update /proc/uptime field description
Documentation: Fix size parameter for snprintf
arm: fix comment header and macro name
asm-generic: uaccess: Spelling s/a ny/any/
mtd: onenand: fix comment header
doc: driver-model/platform.txt: fix a typo
drivers: fix typo in DEVTMPFS_MOUNT Kconfig help text
doc: Fix typo (acces_process_vm -> access_process_vm)
treewide: Fix typos in printk
drivers/gpu/drm/qxl/Kconfig: reformat the help text
...
Commit 9df89d85b4 "usbcore: set
lpm_capable field for LPM capable root hubs" was created under the
assumption that all USB host controllers should have USB 3.0 Link PM
enabled for all devices under the hosts.
Unfortunately, that's not the case. The xHCI driver relies on knowledge
of the host hardware scheduler to calculate the LPM U1/U2 timeout
values, and it only sets lpm_capable to one for Intel host controllers
(that have the XHCI_LPM_SUPPORT quirk set).
When LPM is enabled for some Fresco Logic hosts, it causes failures with
a AgeStar 3UBT USB 3.0 hard drive dock:
Jan 11 13:59:03 sg-laptop kernel: usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd
Jan 11 13:59:03 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed.
Jan 11 13:59:08 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed.
Jan 11 13:59:08 sg-laptop kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Jan 11 13:59:08 sg-laptop mtp-probe[613]: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb3/3-1"
Jan 11 13:59:08 sg-laptop mtp-probe[613]: bus: 3, device: 2 was not an MTP device
Jan 11 13:59:08 sg-laptop kernel: scsi6 : usb-storage 3-1:1.0
Jan 11 13:59:13 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed.
Jan 11 13:59:18 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed.
Jan 11 13:59:18 sg-laptop kernel: usbcore: registered new interface driver usb-storage
Jan 11 13:59:40 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
Jan 11 13:59:41 sg-laptop kernel: usb 3-1: device descriptor read/8, error -71
Jan 11 13:59:41 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
Jan 11 13:59:46 sg-laptop kernel: usb 3-1: device descriptor read/8, error -110
Jan 11 13:59:46 sg-laptop kernel: scsi 6:0:0:0: Device offlined - not ready after error recovery
Jan 11 13:59:46 sg-laptop kernel: usb 3-1: USB disconnect, device number 2
lspci for the affected host:
04:00.0 0c03: 1b73:1000 (rev 04) (prog-if 30 [XHCI])
Subsystem: 1043:1039
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at dd200000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [80] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Kernel driver in use: xhci_hcd
Kernel modules: xhci_hcd
The commit was backported to stable kernels, and will need to be
reverted there as well.
Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com>
Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com>
Cc: stable@vger.kernel.org
Don Zickus <dzickus@redhat.com> writes:
Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
Those ports did not resume correctly (the driver would timeout communicating
and fail). This led to frustration as suspend/resume is a common use for
laptops.
Poking around, I applied the reset on resume quirk to this chipset and the
resume started working. Reloading the xhci_hcd module had been the temporary
workaround.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Don Zickus <dzickus@redhat.com>
Tested-by: Prarit Bhargava <prarit@redhat.com>
Cc: stable # 2.6.37
Here's the big USB pull request for 3.14-rc1
Lots of little things all over the place, and the usual USB gadget
updates, and XHCI fixes (some for an issue reported by a lot of people.)
USB PHY updates as well as chipidea updates and fixes.
All of these have been in the linux-next tree with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlLdjwIACgkQMUfUDdst+ylBIQCgkRoR8lJc0L5lZ3fugIJL4IzZ
j6AAn0nBLP6VI0cvUEi3TcrPTzv4MEuL
=Yb+I
-----END PGP SIGNATURE-----
Merge tag 'usb-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB updates from Greg KH:
"Here's the big USB pull request for 3.14-rc1
Lots of little things all over the place, and the usual USB gadget
updates, and XHCI fixes (some for an issue reported by a lot of
people). USB PHY updates as well as chipidea updates and fixes.
All of these have been in the linux-next tree with no reported issues"
* tag 'usb-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (318 commits)
usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX
usb: chipidea: need to mask INT_STATUS when write otgsc
usb: chipidea: put hw_phymode_configure before ci_usb_phy_init
usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
usb: chipidea: add freescale imx28 special write register method
usb: ehci: add freescale imx28 special write register method
usb: core: check for valid id_table when using the RefId feature
usb: cdc-wdm: resp_count can be 0 even if WDM_READ is set
usb: core: bail out if user gives an unknown RefId when using new_id
usb: core: allow a reference device for new_id
usb: core: add sanity checks when using bInterfaceClass with new_id
USB: image: correct spelling mistake in comment
USB: c67x00: correct spelling mistakes in comments
usb: delete non-required instances of include <linux/init.h>
usb:hub set hub->change_bits when over-current happens
Revert "usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28"
xhci: Set scatter-gather limit to avoid failed block writes.
xhci: Avoid infinite loop when sg urb requires too many trbs
usb: gadget: remove unused variable in gr_queue_int()
...
We have met a bug that the high bandwidth ISO-TX transfer has failed
at the last packet if it is less than 1024, the TD status shows it
is "Transaction Error".
The root cause of this problem is: the mult value at qh is not correct
for current TD's transfer length. We use TD list to queue un-transfer
TDs, and change mult for new adding TDs. If new adding TDs transfer length
less than 1024, but the queued un-transfer TDs transfer length is larger
than 1024, the transfer error will occur, and vice versa.
Usually, this problem occurs at the last packet, and the first packet for
new frame.
We fixed this problem by setting Mult at QH as the largest value (3), and
set MultO (Multiplier Override) at TD according to every transfer length.
It can cover both hardware version less than 2.3 (the real mult is MultO
if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)).
Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior
unchanged.
For stable tree: 3.11+.
Cc: stable <stable@vger.kernel.org>
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
Reported-by: Matthieu Vanin <b47495@freescale.com>
Tested-by: Matthieu Vanin <b47495@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
