The seg argument to xhci_segment_free is never passed as NULL, so
no need to check for this in xhci_segment_free.
Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are 2 situations wherein the xhci_ring* might not get freed:
- When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and
we goto the fail: label in xhci_ring_alloc. In this case, the ring
will not get kfreed.
- When the num_segs argument to xhci_ring_alloc is passed as 0 and
we try to free the rung after that.
( This doesn't really happen as of now in the code but we seem to
be entertaining num_segs=0 in xhci_ring_alloc )
This should be backported to kernels as old as 2.6.31.
Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When a hot reset (standard USB port reset) fails on a USB 3.0 port, the
host controller transitions to the "Error" state. It reports the port
link state as "Inactive", sets the link state change flag, and (if the
device disconnects) also reports the disconnect and connect change status.
It's also supposed to transition the link state to "RxDetect", but the NEC
µPD720200 xHCI host does not.
Unfortunately, Harald found that the combination of the NEC µPD720200 and
a LogiLink USB 3.0 to SATA adapter triggered this issue. The USB core
would reset the device, the port would go into this error state, and the
device would never be enumerated. This combination works under Windows,
but not under Linux.
When a hot reset fails on a USB 3.0 port, and the link state is reported
as Inactive, fall back to a warm port reset instead. Harald confirms that
with a warm port reset (along with all the change bits being correctly
cleared), the USB 3.0 device will successfully enumerate.
Harald also had to add two other patches ("xhci: Set change bit when warm
reset change is set." and "usbcore: refine warm reset logic") to make this
setup work. Since the warm reset refinement patch is not destined for the
stable kernels (it's too big), this patch should not be backported either.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=41752
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Harald Brennich <harald.brennich@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Intel Panther Point xHCI host tracks SuperSpeed endpoints in a
different way than USB 2.0/1.1 endpoints. The bandwidth interval tables
are not used, and instead the bandwidth is calculated in a very simple
way. Bandwidth for SuperSpeed endpoints is tracked individually in each
direction, since each direction has the full USB 3.0 bandwidth available.
10% of the bus bandwidth is reserved for non-periodic transfers.
This checking would be more complex if we had USB 3.0 LPM enabled, because
an additional latency for isochronous ping times need to be taken into
account. However, we don't have USB 3.0 LPM support in Linux yet.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The "Mult" bits in the SuperSpeed Endpoint Companion Descriptor are
zero-based, and the xHCI host controller wants them to be zero-based in
the input context. However, for the bandwidth math, we want them to be
one-based. Fix this.
Fix the documentation about the endpoint bandwidth mult variable in the
xhci.h file, which says it is zero-based. Also fix the documentation
about num_packets, which is also one-based, not zero-based.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short
for xHC host to complete the warm reset and report a BH reset change.
This patch increases the waiting time for warm reset and merges the function
into hub_port_reset(), so it can handle both cold reset and warm reset, and
factor out hub_port_finish_reset() to make the code looks cleaner.
This fixes the issue that driver fails to clear BH reset change and port is
"dead".
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
instead of reading the xhci interface version each time _even_ if the
quirk is not required, simply check if the quirk flag is set. This flag
is only set of the module parameter is set and here is where I moved the
version check to.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
After auto-delink command is triggered, the CSW won't be sent back
to host side, in which scenario, the USB Mass Storage driver will
wait for the completion of the URB for MAX_SCHEDULE_TIMEOUT.
Signed-off-by: edwin_rong <edwin_rong@realsil.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The new runtime PM code has shown that many webcams suffer
from a race condition that may crash them upon resume.
Runtime PM is especially prone to show the problem because
it retains power to the cameras at all times. However
system suspension may also crash the devices and retain
power to the devices.
The only way to solve this problem without races is in
usbcore with the RESET_RESUME quirk.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
According to ehci spec 4.10.2, Advance Queue
If the fetched qTD has its Active bit set to a zero, the
host controller aborts the queue advance and follows the
queue head's horizontal pointer to the next schedule data
structure.
the 'qtd' will be linked into qh hardware queue after the line
below
*dummy = *qtd;
is executed and observed by EHCI HC, but EHCI HC won't have chance to
fetch the qtd descriptor pointed by 'qtd' in qh_append_tds until the
line below
dummy->hw_token = token; #set Active bit here
is executed by CPU and observed by EHCI HC.
There is already one 'wmb' to order writing to 'dummy'/'qtd' descriptors
and writing 'token' to 'dummy' descriptor(set Active bit), so the 1st
wmb is not needed and can be removed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
EHCI_SHRINK_JIFFIES should be 5ms, which was just used originally,
and not 200ms, so fix it.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Obviously, ZLP is only required for transfer of OUT direction,
so just take same policy with UHCI for ZLP packet.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
qh_refresh is always called when the qh is idle and has not been
linked into hardware queue, so EHCI will not access overlay of
the qh at this time. Just before linking qh into hardware queue, there
has already one wmb to order writing qh descriptor and writing dma
address of the qh into hardware queue, so HC can always see
up-to-date qh descriptor once the qh is fetched with its dma address
by EHCI.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A typo in the configuration variable name prevents from activating the
USB autosuspend on the device.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The allocated chardevice region range is only 1 device but on
unregister it currently tries to deregister 2.
Found this while doing a insmod/rmmod/insmod/rm... of the module
which seemed to eat major numbers.
Signed-off-by: Fabian Godehardt <fg@emlix.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When a transceiver is available use otg_set_power to submit
the target current to it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In a few places in the kernel, the code prints
a human-readable USB device speed (eg. "high speed").
This involves a switch statement sometimes wrapped
around in ({ ... }) block leading to code repetition.
To mitigate this issue, this commit introduces
usb_speed_string() function, which returns
a human-readable name of provided speed.
It also changes a few places switch was used to use
this new function. This changes a bit the way the
speed is printed in few instances at the same time
standardising it.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
IDs found in the Windows driver's ZTEusbnet.inf file from the
ZTE MF100 drivers (O2 UK). Also fixes the ZTE MF626 device
since it really is distinct from the 4G Systems stick and
apparently needs the net interface blacklisted too, while
there's no indication (yet) that the 4G Systems stick does.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
That's what the blacklist is for...
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It's cleaner than the array stuff, and we're about to add a bunch
more blacklist entries. Second, there are devices that need both
the sendsetup and the reserved interface blacklists, which the
current code can't accommodate.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
remove the following two paragraphs as they are not needed:
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for more details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc.,59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There is a multi-year old bug in the MUSB hardware which is not documented.
It causes spurious interrupts and have various symptoms, like endless
"SetupEnd came in a wrong ep0stage" messages. The fix is taken from the
FreeBSD's musb driver.
How to reproduce:
For example issue clear-stall on a couple of endpoints very fast,
like one request per 125us. After a while the bug triggers and the
musb-chip becomes unusable until next re-enumeration.
Signed-off-by: Hans Petter Selasky <hps@bitfrost.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A return value of -EINPROGRESS from pm_runtime_get indicates that
the device is already resuming due to a previous call. Internally,
usb_autopm_get_interface_async doesn't treat this as an error and
increments the usage count, but passes the error status along
to the caller. The logical assumption of the caller is that
any negative return value reflects the device not resuming
and the pm_usage_cnt not being incremented. Since the usage count
is being incremented and the device is resuming, return success (0)
instead.
Signed-off-by: James Wylder <james.wylder@motorola.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch solves two things:
1) Enables autosense emulation code to correctly
interpret descriptor format sense data, and
2) Fixes a bug whereby the autosense emulation
code would overwrite descriptor format sense data
with SENSE KEY HARDWARE ERROR in fixed format, to
incorrectly look like this:
Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor]
Oct 21 14:11:07 localhost kernel: Descriptor sense data with sense descriptors (in hex):
Oct 21 14:11:07 localhost kernel: 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00
Oct 21 14:11:07 localhost kernel: 00 4f 00 c2 00 50
Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The xhci_hcd->devs is an array of pointers rather than pointer to pointer.
Hence this check is not required.
Signed-off-by: Sifram Rajas <Sifram Rajas sifram.rajas@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In xhci_urb_enqueue(), allocate a block of memory for all the TDs instead
of allocating memory for each of them separately. This reduces the number
of kzalloc calling when an isochronous usb is submitted.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Now that the xHCI driver always return a status value of zero for isochronous
URBs, when the last TD of an isochronous URB is short, the local variable
"status" stays set to -EINPROGRESS. When xHCI driver debugging is turned on,
this causes the log file to fill with messages like this:
[ 38.859282] xhci_hcd 0000:00:14.0: Giveback URB ffff88013ad47800, len = 1408, expected = 580, status = -115
Don't print out the status of an URB for isochronous URBs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The xHCI host controller in the Intel Panther Point chipset needs to have
software check whether new devices will fit in the available bus
bandwidth. Activate the software bandwidth checking quirk when we find
the right PCI device.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Now that we have a bandwidth interval table per root port or TT that
describes the endpoint bandwidth information, we can finally use it to
check whether the bus bandwidth is oversubscribed for a new device
configuration/alternate interface setting.
The complication for this algorithm is that the bit of hardware logic that
creates the bus schedule is only 12-bit logic. In order to make sure it
can represent the maximum bus bandwidth in 12 bits, it has to convert the
endpoint max packet size and max esit payload into "blocks" (basically a
less-precise representation). The block size for each speed of device is
different, aside from low speed and full speed. In order to make sure we
don't allow a setup where the scheduler might fail, we also have to do the
bandwidth checking in blocks.
After checking that the endpoints fit in the schedule, we store the
bandwidth used for this root port or TT. If this is a FS/LS device under
an external HS hub, we also update the TT bandwidth and the root port
bandwidth (if this is a newly activated or deactivated TT).
I won't go into the details of the algorithm, as it's pretty well
documented in the comments.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In the upcoming patches, we'll use some stored endpoint information to
make software keep track of the worst-case bandwidth schedule. We need to
store several variables associated with each periodic endpoint:
- the type of endpoint
- Max Packet Size
- Mult
- Max ESIT payload
- Max Burst Size (aka number of packets, stored in one-based form)
- the endpoint interval (normalized to powers of 2 microframes)
All this information is available to the hardware, and stored in its
device output context. However, we need to ensure that the new
information is stored before the xHCI driver drops the xhci->lock to wait
on the Configure Endpoint command, so that another driver requesting a
configuration or alt setting change will see the update. The Configure
Endpoint command will never fail on the hardware that needs this software
bandwidth checking (assuming the slot is enabled and the flags are set
properly), so updating the endpoint info before the command completes
should be fine.
Until we add in the bandwidth checking code, just update the endpoint
information after the Configure Endpoint command completes, and after a
Reset Device command completes. Don't bother to clear the endpoint
bandwidth info when a device is being freed, since the xhci_virt_ep is
just going to be freed anyway.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since the xHCI driver now has split USB2/USB3 roothubs, devices under each
roothub can have duplicate "fake" port numbers. For the next set of
patches, we need to keep track of the "real" port number that the xHCI
host uses to index into the port status arrays.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move the code to check whether we've reached the host controller's limit
on the number of endpoints out of the two conditional statements, to
remove duplicate code.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The "port" field in xhci_virt_dev stores the port number associated with
one of the two xHCI split roothubs, not the unique port number the xHCI
hardware uses. Since we'll need to store the real hardware port number in
future patches, rename this field to "fake_port".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some alternate interface settings have no endpoints associated with them.
This shows up in some USB webcams, particularly the Logitech HD 1080p,
which uses the uvcvideo driver. If a driver switches between two alt
settings with no endpoints, there is no need to issue a configure endpoint
command, because there is no endpoint information to update.
The only time a configure endpoint command with just the add slot flag set
makes sense is when the driver is updating hub characteristics in the slot
context. However, that code never calls xhci_check_bandwidth, so we
should be safe not issuing a command if only the slot context add flag is
set.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch enables DMA mode1 for the RX path when we know
there won't be any short packets. We check that by looking
into the short_no_ok flag, if it's true we enable mode1, otherwise
we use mode0 to transfer the data.
This will result in a throughput performance gain of around
40% for USB mass-storage/mtp use cases.
[ balbi@ti.com : updated commit log and code comments slightly ]
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Tested-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
On Audio class, the wLength field of the Setup
packet, contains the data payload size of the
following Data phase. Instead of harcoding values,
use wLength.
This also fixes a bug where Gadget driver had to
receive 3 bytes, but it was queueing a ZLP.
Signed-off-by: Felipe Balbi <balbi@ti.com>
While testing g_audio with HighSpeed UDC on a
FS Hub, we had no configurations to present to
the host. That's because both speeds where
mutually exclusive.
Signed-off-by: Felipe Balbi <balbi@ti.com>
FSG_NUM_BUFFERS is set to 2 as default.
Usually 2 buffers are enough to establish a good buffering pipeline.
The number may be increased in order to compensate a for bursty VFS
behaviour.
Here follows a description of system that may require more than
2 buffers.
* CPU ondemand governor active
* latency cost for wake up and/or frequency change
* DMA for IO
Use case description.
* Data transfer from MMC via VFS to USB.
* DMA shuffles data from MMC and to USB.
* The CPU wakes up every now and then to pass data in and out from VFS,
which cause the bursty VFS behaviour.
Test set up
* Running dd on the host reading from the mass storage device
* cmdline: dd if=/dev/sdb of=/dev/null bs=4k count=$((256*100))
* Caches are dropped on the host and on the device before each run
Measurements on a Snowball board with ondemand_governor active.
FSG_NUM_BUFFERS 2
104857600 bytes (105 MB) copied, 5.62173 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.61811 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.57817 s, 18.8 MB/s
FSG_NUM_BUFFERS 4
104857600 bytes (105 MB) copied, 5.26839 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2691 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2711 s, 19.9 MB/s
There may not be one optimal number for all boards. This is why
the number is added to Kconfig. If selecting USB_GADGET_DEBUG_FILES
this value may be set by a module parameter as well.
Signed-off-by: Per Forlin <per.forlin@linaro.org>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch (as1481) fixes a problem affecting g_file_storage and
g_mass_storage when running at SuperSpeed. The two drivers currently
assume that the bulk-out maxpacket size can evenly divide the SCSI
block size, which is 512 bytes. But SuperSpeed bulk endpoints have a
maxpacket size of 1024, so the assumption is no longer true.
This patch removes that assumption from the drivers, by getting rid of
a small optimization (they try to align VFS reads and writes on page
cache boundaries). If a command's starting logical block address is
512 bytes below the end of a page, it's not okay to issue a USB
command for just those 512 bytes when the maxpacket size is 1024 -- it
would result in either babble (for an OUT transfer) or a short packet
(for an IN transfer).
Also, for backward compatibility, the test for writes extending beyond
the end of the backing storage has to be changed. If the host tries
to do this, we should accept the data that fits in the backing storage
and ignore the rest. Because the storage's end may not align with a
USB packet boundary, this means we may have to accept a USB OUT
transfer that extends beyond the end of the storage and then write out
only the part of the data that fits.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Now the mass storage driver has fixed logic block size of 512 bytes.
The mass storage gadget read/write bound devices only through VFS, so the
bottom level devices actually are just RAW devices to the driver and connected
PC. As a RAW, hosts can always format, read and write it right in 512 bytes
logic block and don't care about the actual logic block size of devices bound
to the gadget.
But if we want to share the bound block device partition between target board
and PC, in case the logic block size of the bound block device is 4KB, we
execute the following steps:
1. connect a board with mass storage gadget to PC(the board has set one
partition of on-board block device as file name of the mass storage)
2. PC format the mass storage to VFAT by default logic block size and
read/write it
3. disconnect boards from PC
4. target board mount the partition as VFAT
Step 4 will fail since kernel on target thinks the logic block size of the
bound partition as 4KB.
A typical error is "FAT: logical sector size too small for device (logical
sector size = 512)"
If we execute opposite steps:
1. format the partition to VFAT on target board and read/write this partition
2. connect the board to Windows PC as usb mass storage gadget, windows will
think the disk is not formatted
So the conclusion is that only as a gadget, the mass storage driver has no any
problem. But being shared VFAT or other filesystem on PC and target board, it
will fail.
This patch adapts logic block size to bound block devices and fix the issue.
Cc: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Peiyu Li <peiyu.li@csr.com>
Signed-off-by: Xianglong Du <xianglong.du@csr.com>
Signed-off-by: Huayi Li <huayi.li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
It's useful to know which states core is going
through, as it might help us figure out misbehavior
on specific link states.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This flag will tell us which direction we're
expecting on the next (data or status) phase.
It will help us catching errors of host going
crazy and requesting data of the wrong direction.
Signed-off-by: Felipe Balbi <balbi@ti.com>
