The status/sense URB is allocated on per-command basis. A read/write
looks the following way on a stream-less connection:
- send cmd tag X, queue status
- receive status, oh it is a read for tag X. queue status & read
- receive read
- receive status, oh I'm done for tag X. Cool call complete and free
status urb.
This block repeats itself 1:1 for further commands and looks great so
far. Lets take a look now what happens if we do allow multiple commands:
- send cmd tag X, queue statusX (belongs to the command with the X tag)
- send cmd tag Y, queue statusY (belongs to the command with the Y tag)
- receive statusX, oh it is a read for tag X. queue statusX & a read
- receive read
- receive statusY, oh I'm done for tag X. Cool call complete and free statusY.
- receive statusX, oh it is a read for tag Y. queue statusY & before we
queue the read the the following message can be observed:
|sd 0:0:0:0: [sda] sense urb submission failure
followed by a second attempt with the same result.
In order to address this problem we will use only one status URB for
each scsi host in case we don't have stream support (as suggested by
Matthew). This URB is requeued until the device removed. Nothing changes
on stream based endpoints.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
In "usb/uas: use unique tags for all LUNs" we make sure to create unique
tags across all LUNs. This patch uses scsi_host_find_tag() to obtain the
correct command which is associated with the tag.
The following changes are required:
- don't use sdev->current_cmnd anymore
Since we can have devices which don't support command queueing we must
ensure that we can tell the two commands apart. Even if a device
supports comand queuing we send the INQUIRY command "untagged" for
LUN1 while we can send a tagged command to LUN0 at the same time.
devinfo->cmnd is used for stashing the one "untagged" command.
- tag number is altered. If stream support is used then the tag number
must match the stream number. Therefore we can't use tag 0 and must
start at tag 1.
In case we have untagged commands (at least the first command) we must
be able to distinguish between command tag 0 (which becomes 1) and
untagged command (which becomes curently also 1).
The following tag numbers are used:
0: never
1: for untagged commands (devinfo->cmnd)
2+: tagged commands.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
I observed that on a device with multiple LUNs UAS was re-using the same
tag number for requests which were issued at the same time to both LUNs.
This patch uses scsi_init_shared_tag_map() to use unique tags for all
LUNs. With this patch I haven't seen the same tag number during the init
sequence anymore. Tag 1 is used for devices which do not adverise
command queueing.
This patch initilizes the queue before adding the scsi host like the
other two user in tree.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
In the UAS status URB completion handler, we need to free the URB, no
matter what happens. Fix a bug where we would leak the URB (and its
buffer) if we couldn't find a SCSI command that is associated with this
status phase.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
UAS can work with either USB 3.0 devices that support bulk streams, or
USB 2.0 devices that do not support bulk streams. When we're working
with a non-streams device, we need to be able to uniquely identify a
SCSI command with a tag in the IU. Devices will barf and abort all
queued commands if they find a duplicate tag.
uas_queuecommand_lck() sets cmdinfo->stream to zero if the device
doesn't support streams, which is later passed into uas_alloc_cmd_urb()
as the variable stream. This means the UAS driver was setting the tag
in all commands to zero for non-stream devices. So the UAS driver won't
currently work with USB 2.0 devices.
Use the SCSI command tag instead of the stream ID for the command IU
tag. We have to add one to the SCSI command tag because SCSI tags are
zero-based, but stream IDs are one-based, and the command tag must match
the stream ID that we're queueing the data IUs for. Untagged SCSI
commands use stream ID 1.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
If the original submission (or allocation) of the URBs for a SCSI
command fails, the UAS driver sticks the command structure in a
workqueue and schedules uas_do_work() to run. That function removes the
entire queue before walking across it and attempting to resubmit.
Unfortunately, if the second submission fails, we will leak memory
(because an allocated URB was not submitted) and possibly leave the SCSI
command partially enqueued on some of the stream rings. Fix this by
checking whether the second submission failed and re-queueing the
command to the UAS workqueue and scheduling it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
* 'for-greg' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb:
usb: gadget: epautoconf: do not change number of streams
usb: dwc3: core: fix cached revision on our structure
usb: musb: fix reset issue with full speed device
This commit:
commit 8f5d621543
Author: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Date: Mon Oct 10 18:06:54 2011 +0200
usb/isp1760: Let OF bindings depend on general CONFIG_OF instead of PPC_OF .
To be able to use the driver on other OF-aware architectures, too.
And add necessary OF related #includes to fix compilation error.
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
enabled the build on all CONFIG_OF architectures, but it cannot do
this.
This driver depends upon CONFIG_OF_IRQ but not all CONFIG_OF platforms
support that infrastructure, in particular Sparc does not so the
build fails.
Please push a patch like the following to Linus so that this code only
gets built where it actually should.
--------------------
usb/isp1760: Add missing CONFIG_OF_IRQ dependency on OF code.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* master: (848 commits)
SELinux: Fix RCU deref check warning in sel_netport_insert()
binary_sysctl(): fix memory leak
mm/vmalloc.c: remove static declaration of va from __get_vm_area_node
ipmi_watchdog: restore settings when BMC reset
oom: fix integer overflow of points in oom_badness
memcg: keep root group unchanged if creation fails
nilfs2: potential integer overflow in nilfs_ioctl_clean_segments()
nilfs2: unbreak compat ioctl
cpusets: stall when updating mems_allowed for mempolicy or disjoint nodemask
evm: prevent racing during tfm allocation
evm: key must be set once during initialization
mmc: vub300: fix type of firmware_rom_wait_states module parameter
Revert "mmc: enable runtime PM by default"
mmc: sdhci: remove "state" argument from sdhci_suspend_host
x86, dumpstack: Fix code bytes breakage due to missing KERN_CONT
IB/qib: Correct sense on freectxts increment and decrement
RDMA/cma: Verify private data length
cgroups: fix a css_set not found bug in cgroup_attach_proc
oprofile: Fix uninitialized memory access when writing to writing to oprofilefs
Revert "xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel"
...
Conflicts:
kernel/cgroup_freezer.c
add support for SG lists on dwc3 driver. With
this we can e.g. use VFS layer's SG lists on
storage gadgets so that we can start bigger
transfers and improve throughput.
Signed-off-by: Felipe Balbi <balbi@ti.com>
the LST bit is to be set on the last of a series
of consecutive TRBs. We had a workaround for a
problem where data would get corrupted but that
doesn't happen anymore. It's likely that it was
caused by some FPGA instability during development
phase.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This is just a minor optimization for the long
if we have on the driver.
When we want to check that one input is true
and the other must be false, the bitwise XOR
operator will achieve that for us.
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Instead use container_of to retrieve the s3c_hsudc from the
struct usb_gadget pointer.
[ balbi@ti.com : changed verbose container_of() into
an already provided helper 'to_hsudc()' ]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
As the memory region is requested through request_mem_region
use the correct paired method to release it in the error path
and don't go "beneath the API".
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The udc has three supplies: vdda (3.3V), vddi (1.2V) and vddosc (1.8-3.3V).
Turn these on and off on start and stop calls.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
udc_start and udc_stop reduce code duplication in comparison to
start and stop generalising calls done by all drivers
(i.e. bind and unbind) and moving these calls to common code.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Instead of adding and deleting the gadget device in the start and stop
invocations. Use device_register in the probe method to initialize
and add the gadget device.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Gadget drivers should be compilable on all architectures.
This patch removes one dependency on architecture-specific code.
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This change removes confusing extern qualifier, which doesn't have any practical
sense there.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@nokia.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
After a bus reset, we should move our state to
Default, in order to be able to re-enumerate again.
I only managed to trigger this problem with g_ether
by removing the cable after a few transfers had been
completed.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Spaces to tabs, proper alignment, and start sentences as they should.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The whole thing depends on USB_MUSB_HDRC, just add an 'if'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Shuffle the code a bit so the description is at the top.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
These are handled by drivers core, and in a way that doesn't wake up the
devices.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
enabled && driver || !enabled can be simplified to !enabled || driver.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In musb_init_controller() there's a pm_runtime_put(), but there's no
pm_runtime_get(), which creates a mismatch that causes the driver to
sleep when it shouldn't.
This was introduced in 7acc619[1], but it wasn't triggered in my setup
until 18a2689[2] was merged to Linus' branch at point df0914[3]. IOW;
when PM is working as it was supposed to.
However, it seems most of the time this is used in a way that keeps the
counter above 0, so nobody noticed. Also, it seems to depend on the
configuration used in versions before 3.1, but not later (or in it).
I found the problem by loading isp1704_charger before any usb gadgets:
http://article.gmane.org/gmane.linux.kernel/1226122
All versions after 2.6.39 are affected.
[1] usb: musb: Idle path retention and offmode support for OMAP3
[2] OMAP2+: musb: hwmod adaptation for musb registration
[3] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
Cc: stable@vger.kernel.org
Cc: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch adds support for EHCI compliant HSUSB Host controller found
on Marvell Socs.
It fits both OTG and SPH controller on marvell Socs, including
PXA9xx/MMP2/MMP3/MGx.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This driver is for ChipIdea USB OTG controller on Marvell Socs.
PXA9xx/MMP2/MMP3/MGx all have this USB OTG controller.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch do the following things:
1. Change the Kconfig information.
2. Rename the driver name.
3. Don't do any type cast to io memory.
4. Add dummy stub for clk framework.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
According to ChipIdea's SPEC, we cannot touch curr_dtd_ptr in dqh
directly, use prime endpoint instead.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We should not change gadget driver's descriptors just
because we think it's right to do so.
There are several of reasons which would support this
statement but it suffices to say that this was probably
never tested because it updates bmAttributes without
asking the driver if it's ok to do so.
This means that e.g. on UASP gadget it would enable
stream support even for the command endpoint which must
not have stream support enabled.
In fact, this change is fixing the bug introduced by
commit a59d6b9 (usb: gadget: add streams support to
the gadget framework) which was caught when testing
UASP gadget with dwc3 driver.
Cc: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Rewrite function queue_dtd according to ChipIdea's reference manual.
Remove all unnecessary logic, it will enhance the performance.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The ehci and ohci drivers does not use the APIs of the usbhs
core driver; the runtime pm APIs are used for clock
enable/disable. Since usbhs is parent platform device of the
ehci and ohci devices, the runtime apis indirectly uses the
usb hs core device as input parameter to for clock functions.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Gcc complains about this printk:
drivers/usb/renesas_usbhs/mod_gadget.c:188:3: warning: format ‘%x’
expects argument of type ‘unsigned int’, but argument 3 has type
‘dma_addr_t’ [-Wformat]
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch tidyup below smatch complaint
drivers/usb/renesas_usbhs/mod_host.c +642 usbhsh_queue_done()
warn: variable dereferenced before check 'urb' (see line 636)
Special thanks to Dan
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
All our revision macros are defined with the entire
32-bits which we read from GSNPSID register, so we
must cache all 32-bits properly rather than masking
the top 16-bits.
This will fix all revision checks we have on current
driver.
Signed-off-by: Felipe Balbi <balbi@ti.com>
TXMAXP register is not getting programmed correctly for a full speed device
as can_bulk_split() have been removed by
"0662481: usb: musb: disable double buffering when it's broken" patch.
Adding back the case for can_bulk_split() to fix the reset message seen with
a full speed stick.
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Use an getter function in plat-orion/addr-map.c to get the address map
structure, rather than pass it to drivers in the platform_data
structures. When the drivers are built for none orion platforms, a
dummy function is provided instead which returns NULL.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Michael Walle <michael@walle.cc>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Huawei use the product code HUAWEI_PRODUCT_E353 (0x1506) for a
number of different devices, which each can appear with a number
of different descriptor sets. Different types of interfaces
can be identified by looking at the subclass and protocol fields
Subclass 1 protocol 8 is actually the data interface of a CDC
ECM set, with subclass 1 protocol 9 as the control interface.
Neither support serial data communcation, and cannot therefore
be supported by this driver.
At the same time, add a few other sets which appear if the
device is configured in "Windows mode" using this modeswitch
message:
55534243000000000000000000000011060000000100000000000000000000
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
