This patch (as1462) updates the special accessor functions defined in
uhci-hcd.h. Rather than using a full compiler barrier, all we really
need is the ACCESS_ONCE() mechanism, because the idea is to force the
compiler to store a fixed copy of a possibly changing value.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for big endian mmio to the UHCI HCD. Big endian
mmio is supported by adding a flag bit to the UHCI HCD replicating the
solution used in the EHCI HCD.
When adding big endian support this patch also adds a check to see if we
need to support HCs with PCI I/O registers when we support HCs with MMIO.
This patch also adds 'const' to the register access functions' uhci_hcd
argument.
Signed-off-by: Jan Andersson <jan@gaisler.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits ae38c78a03
and 00914025cc added quirk flags
US_FL_NO_READ_DISC_INFO and US_FL_NO_READ_CAPACITY_16 to
the usb-storage driver. However they did not add the corresponding flags
to adjust_quirks() in usb.c, so there was no facility for a user
to over-ride/add them via the quirks module parameter.
Signed-off-by: Karl Relton <karllinuxtest.relton@ntlworld.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use skip map to avoid spurious interrupts from unlinked transfers.
Also changes to urb_dequeue() and endpoint_disable() to avoid
release of spinlock in uncertain state.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Preparation for patch #2. The function isp1760_endpoint_disable() does almost
the same thing as urb_dequeue(). In patch #2 I change these to use a common
helper function instead of calling each other - for clarity but also to
avoid releasing the spinlock while in a "questionable" state. It seemed
proper to have these functions close to each other in the code.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1467) removes the last usages of hcd->state from
usbcore. We no longer check to see if an interrupt handler finds that
a controller has died; instead we rely on host controller drivers to
make an explicit call to usb_hc_died().
This fixes a regression introduced by commit
9b37596a2e (USB: move usbcore away from
hcd->state). It used to be that when a controller shared an IRQ with
another device and an interrupt arrived while hcd->state was set to
HC_STATE_HALT, the interrupt handler would be skipped. The commit
removed that test; as a result the current code doesn't skip calling
the handler and ends up believing the controller has died, even though
it's only temporarily stopped. The solution is to ignore HC_STATE_HALT
following the handler's return.
As a consequence of this change, several of the host controller
drivers need to be modified. They can no longer implicitly rely on
usbcore realizing that a controller has died because of hcd->state.
The patch adds calls to usb_hc_died() in the appropriate places.
The patch also changes a few of the interrupt handlers. They don't
expect to be called when hcd->state is equal to HC_STATE_HALT, even if
the controller is still alive. Early returns were added to avoid any
confusion.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Manuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Unaligned sizes and buffers are not supported and they will be filtered
out by is_compatible().
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Although U8500 and U5500 platforms use paltform dma, Inventra dma specific code
can work for them for the most part. Only difference is for the Rx path where
this patch is making use of request->short_not_ok to select dma mode.
Signed-off-by: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 35a83365da6aa10095c6138cc428c15853409c32
(usb: musb: drop unneeded musb_debug trickery)
introduced a compile error for blackfin and
tusb6010 glue layers. Fix it.
Reported-by: Mike Frysinger <vapier.adi@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch (as1461) fixes the unusual_devs entries for the Realtek USB
card reader. They should be ordered by PID, and they should not
override the Subclass and Protocol values provided by the device.
Otherwise a notification about unnecessary entries gets printed in the
kernel log during probing.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-By: Tony Vroon <tony@linx.net>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
as_out_ep_desc contines to be used during gadget enumeration and thus
should not be marked as __initdata
Signed-off-by: Martin Jackson <mjackson220.list@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1466) speeds up processing of ehci-hcd's periodic list.
The existing code will pointlessly rescan an interrupt endpoint queue
each time it encounters the queue's QH in the periodic list, which can
happen quite a few times if the endpoint's period is low. On some
embedded systems, this useless overhead can waste so much time that
the driver falls hopelessly behind and loses events.
The patch introduces a "periodic_stamp" variable, which gets
incremented each time scan_periodic() runs and each time the scan
advances to a new frame. If the corresponding stamp in an interrupt
QH is equal to the current periodic_stamp, we assume the QH has
already been scanned and skip over it. Otherwise we scan the QH as
usual, and if none of its URBs have completed then we store the
current periodic_stamp in the QH's stamp, preventing it from being
scanned again.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1463) fixes a regression caused by commit
3df7169e73 (OHCI: work around for nVidia
shutdown problem).
The original problem encountered by people using NVIDIA chipsets was
that USB devices were not turning off when the system shut down. For
example, the LED on an optical mouse would remain on, draining a
laptop's battery. The problem was caused by a bug in the chipset; an
OHCI controller in the Reset state would continue to drive a bus reset
signal even after system shutdown. The workaround was to put the
controllers into the Suspend state instead.
It turns out that later NVIDIA chipsets do not suffer from this bug.
Instead some have the opposite bug: If a system is shut down while an
OHCI controller is in the Suspend state, USB devices remain powered!
On other systems, shutting down with a Suspended controller causes the
system to reboot immediately. Thus, working around the original bug
on some machines exposes other bugs on other machines.
The best solution seems to be to limit the workaround to OHCI
controllers with a low-numbered PCI product ID. I don't know exactly
at what point NVIDIA changed their chipsets; the value used here is a
guess. So far it was worked out okay for all the people who have
tested it.
This fixes Bugzilla #35032.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: Yury Siamashka <yurand2@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If for some reason we fail to set the voltage range for the VDDCX regulator
when removing it's better to still disable and free the regulator as that
avoids leaking a reference to it and is likely to ensure that it's turned
off completely.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When not active the hardware should be able to tolerate voltages within
the normal operating range so when removing set the maximum voltage we
can use to the maximum rather than minimum of the operating range. This
will improve interoperability in case we end up sharing the supply in
some design.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I am sharing patch to the devices/usb/serial/option.c. This allows
operation of Huawei E353 broadband modem using the “option” driver. The
patch simply adds new constant with proper product ID and an entry to
usb_device_id. I worked on the 2.6.38.6 sources. Tested on Dell inspiron
1764 (i3 core cpu) and brand new Huawei E353 modem, Fedora 15 beta.
Looking at the type of change, i doubt it has potential to introduce
problems in other parts of kernel or the driver itself.
Signed-off-by: Marcin Galczynski <marcin@galczynski.pl>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the USB core wants to change to an alternate interface setting that
doesn't include an active endpoint, or de-configuring the device, the xHCI
driver needs to issue a Configure Endpoint command to tell the host to
drop some endpoints from the schedule. After the command completes, the
xHCI driver needs to free rings for any endpoints that were dropped.
Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings
for dropped endpoints. The rings would be freed if the endpoint's
information was simply changed (and a new ring was installed), but dropped
endpoints never had their rings freed. This caused errors when the ring
segment DMA pool was freed when the xHCI driver was unloaded:
[ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff88003371d000 busy
[ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033716000 busy
[ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033455000 busy
[ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool
[ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool
[ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool
[ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool
[ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1
[ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered
[ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled
Fix this issue and free endpoint rings when their endpoints are
successfully dropped.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full. If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented. The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.
Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0. This was caused by the second assignment to rings_cached:
rings_cached = virt_dev->num_rings_cached;
if (rings_cached < XHCI_MAX_RINGS_CACHED) {
virt_dev->num_rings_cached++;
rings_cached = virt_dev->num_rings_cached;
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed. When the driver was unloaded, this caused interesting messages
like:
xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy
This should be queued to stable kernels back to 2.6.33.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Dmitry's patch
dfa49c4ad1 USB: xhci - fix math in xhci_get_endpoint_interval()
introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.
Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding. The isochronous endpoint encoding was the same.
This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
[ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
...
[ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000
When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-next' of master.kernel.org:/pub/scm/linux/kernel/git/balbi/usb:
MAINTAINERS: tree moved to kernel.org
usb: musb: Calling VBUS pulsing API when SRP is initiated.
usb: otg: TWL6030: OMAP4430: Adding SRP VBUS pulsing API
usb: musb: host: remove duplicate check in musb_ep_program()
usb: musb: export musb_interrupt symbol
usb: musb: allow musb and glue layers to be modules
usb: musb: drop unneeded musb_debug trickery
composite.c always sets req->length to zero
and expects function driver's setup handlers
to return the amount of bytes to be used
on req->length. If we test against req->length
w_length will always be greater than req->length
thus making us always stall that particular
SEND_ENCAPSULATED_COMMAND request.
Tested against a Windows XP SP3.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
on 9g20 they are the same as the 9260
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Several resources have been allocated before this kmalloc failure, and thus
they should be released in this error handling code, as done in nearby
error handling code.
The semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
local idexpression urb;
statement S;
position p1,p2;
@@
urb = usb_alloc_urb@p1(...);
... when != urb
if (urb == NULL) S
... when != urb
(
return <+...urb...+>;
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
cocci.print_main("",p1)
cocci.print_secs("",p2)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the checkpatch warnings listed below:
WARNING: braces {} are not necessary for any arm of this statement
WARNING: please, no space before tabs
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the checkpatch error and warning listed below:
ERROR: code indent should use tabs where possible
WARNING: please, no spaces at the start of a line
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Implement the start_srp API to generate the VBUS pulsing and assign it to
otg_transciever function pointer. This will be used by the link driver when
there is SRP initiation from user.
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
musb_ep_program() contains obviously duplicate check for 'dma_channel' in its
IN/receive path -- removing it allows to save one level of indentation. While
at it, improve the comment style...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
currently that's used by another module
(am35x) which, granted, it shouldn't be
using that, but in order to avoid compile
errors, let's export that symbol temporarily
until re-factoring work is done on that
driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This in part reverts commit 7a180e70cf.
(usb: musb: temporarily make it bool) and while
at that we also allow glue layers to be compiled
as modules.
There are still some other changes needed
until we can have a fully functional build
with this setup, but we're getting there.
Signed-off-by: Felipe Balbi <balbi@ti.com>
We have a generic way of enabling/disabling
different debug messages on a driver called
DYNAMIC_PRINTK. Anyone interested in enabling
just part of the debug messages, please read
the documentation under:
Documentation/dynamic-debug-howto.txt
for information on how to use that great
infrastructure.
Signed-off-by: Felipe Balbi <balbi@ti.com>
There are several functions using same code to get max ports and port array,
this patch moves the common code to a function in order to reuse them easily.
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The BIOS handoff for the unused EHCI controller on the ExoPC tablet
hangs for 90 seconds on boot. Detect that device, skip negotiation
and force the handoff.
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Factor the handoff code out from quirk_usb_disable_ehci
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing. The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs). The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.
Unfortunately, there is a long-standing bug in the control transfer
completion code. It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed. So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.
When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel. It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs. Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.
It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior. Fix this
behavior.
This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@kernel.org
The error processing order was wrong.
This patch modify it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It was necessary to check pipe condition after disable fifo.
Current driver checked it in a wrong place.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Droids MuIn LCD operates like a serial remote terminal.
Data received are displayed directly on the LCD. This patch
fixes the kernel null pointer oops when it is plugged in.
Add NO_DATA_INTERFACE quirk to tell the driver that "control"
and "data" interfaces are not separated for this device, which
prevents dereferencing a null pointer in the device probe code.
Signed-off-by: Erik Slagter <erik@slagter.name>
Signed-off-by: Maxin B. John <maxin.john@gmail.com>
Tested-by: Erik Slagter <erik@slagter.name>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Samsung's S3C2416, S3C2443 and S3C2450 includes a USB High-Speed
device controller module. This driver enables support for USB high-speed
gadget functionality for the Samsung S3C24xx SoC's that include this
controller.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Alexander Neumann <alexander@bumpern.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add support for USB 2.0 High-Speed gadget controller driver for Samsung's
S3C2416 processor.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
S3C2416, S3C2443 and S3C2450 includes a USB High-Speed Gadget controller module.
This patch adds the following for supporting this controller.
1. Definition for USB High-Speed controller base address.
2. Platform device instantiation.
3. Declaration for platform data structure.
4. Functionality to setup platform data for the controller.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add register definitions required to configure the USB Phy. The definitions
for PHYCTRL, PHYPWR, URSTCON and UCLKCON registers and corresponding bit
field definitions are added.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Comparing an unsigned integer with greater than or equal to zero is
always true. So, it is safe to remove similar checks from
'f_mass_storage.c' and 'file_storage.c'
Signed-off-by: Maxin B. John <maxin.john@gmail.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On amd64 unsigned is not as wide as pointer and this causes a compiler
warning. Switching to unsigned long corrects the problem.
Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>