Re: Broken usb stick after plug it on an usb port?

[Emma]

Hello,

On Mon, Nov 9, 2015 at 9:52 AM, Bjørn Mork  wrote:
> Javi Barroso  writes:
>> El 6 de noviembre de 2015 0:28:40 CET, Greg KH  escribió:
>>>On Thu, Nov 05, 2015 at 06:03:15PM +0100, Javier Barroso wrote:
 Hello,

 I have a usb stick which was (apparently) broken after plug it on a
 usb port on my laptop [1]
>>>
>>>What do you mean exactly by "broken"?
>>>
>> USB stick owner tell me about the stick was working about 5 years more
>> or less without any problem with her windows laptop. She used this
>> stick to order print some picture last week in a paper shop (other
>> computer different) and it worked fine.
>>
>> The first time that I plugged the stick on my laptop, it was not
>> recognized any more. No windows recognize, no linux, no apple.
>>
>> So the stick is currently broken
>
> http://rationalwiki.org/wiki/Correlation_does_not_imply_causation

Hello, I` m  Emma, usb stick`s owner . I would like to retrieve the
information I had in it, Javi doesn`t know how, what could I do in
order to get it? Thank you
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] usb: core: lpm: add sysfs node for usb3 lpm permit

[Lu Baolu]

USB3 LPM is default on in Linux kernel if both xHCI host controller
and the USB devices declare to be LPM-capable. Unfortunately, some
devices are known to work well with LPM disabled, but to be broken
if LPM is enabled, although it declares the LPM capability.  Users
won't be able to use this kind of devices, until someone puts them
in the kernel blacklist and gets the kernel upgraded.

This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2
entry for a port. The settings apply to both before and after device
enumeration. Supported values are "0" - neither u1 nor u2 permitted,
"u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" -
both u1 and u2 are permitted. With this interface, users can use an
LPM-unfriendly USB device on a released Linux kernel.

Signed-off-by: Lu Baolu 
Signed-off-by: Zhuang Jin Can 
---
 Documentation/ABI/testing/sysfs-bus-usb | 11 
 drivers/usb/core/hub.c  | 15 +-
 drivers/usb/core/hub.h  |  5 +-
 drivers/usb/core/port.c | 89 -
 4 files changed, 116 insertions(+), 4 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-usb 
b/Documentation/ABI/testing/sysfs-bus-usb
index 136ba17..0bd731c 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -189,6 +189,17 @@ Description:
The file will read "hotplug", "wired" and "not used" if the
information is available, and "unknown" otherwise.
 
+What:  /sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit
+Date:  November 2015
+Contact:   Lu Baolu 
+Description:
+   Some USB3.0 devices are not friendly to USB3 LPM.  
usb3_lpm_permit
+   attribute allows enabling/disabling usb3 lpm of a port. It takes
+   effect both before and after a usb device is enumerated. 
Supported
+   values are "0" if both u1 and u2 are NOT permitted, "u1" if 
only u1
+   is permitted, "u2" if only u2 is permitted, "u1_u2" if both u1 
and
+   u2 are permitted.
+
 What:  /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
 Date:  May 2013
 Contact:   Mathias Nyman 
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 59f998e..db7683e 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4020,6 +4020,8 @@ EXPORT_SYMBOL_GPL(usb_unlocked_disable_lpm);
 void usb_enable_lpm(struct usb_device *udev)
 {
struct usb_hcd *hcd;
+   struct usb_hub *hub;
+   struct usb_port *port_dev;
 
if (!udev || !udev->parent ||
udev->speed != USB_SPEED_SUPER ||
@@ -4039,8 +4041,17 @@ void usb_enable_lpm(struct usb_device *udev)
if (udev->lpm_disable_count > 0)
return;
 
-   usb_enable_link_state(hcd, udev, USB3_LPM_U1);
-   usb_enable_link_state(hcd, udev, USB3_LPM_U2);
+   hub = usb_hub_to_struct_hub(udev->parent);
+   if (!hub)
+   return;
+
+   port_dev = hub->ports[udev->portnum - 1];
+
+   if (port_dev->usb3_lpm_u1_permit)
+   usb_enable_link_state(hcd, udev, USB3_LPM_U1);
+
+   if (port_dev->usb3_lpm_u2_permit)
+   usb_enable_link_state(hcd, udev, USB3_LPM_U2);
 }
 EXPORT_SYMBOL_GPL(usb_enable_lpm);
 
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 688817f..45d070d 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -92,6 +92,8 @@ struct usb_hub {
  * @status_lock: synchronize port_event() vs usb_port_{suspend|resume}
  * @portnum: port index num based one
  * @is_superspeed cache super-speed status
+ * @usb3_lpm_u1_permit: whether USB3 U1 LPM is permitted.
+ * @usb3_lpm_u2_permit: whether USB3 U2 LPM is permitted.
  */
 struct usb_port {
struct usb_device *child;
@@ -104,6 +106,8 @@ struct usb_port {
struct mutex status_lock;
u8 portnum;
unsigned int is_superspeed:1;
+   unsigned int usb3_lpm_u1_permit:1;
+   unsigned int usb3_lpm_u2_permit:1;
 };
 
 #define to_usb_port(_dev) \
@@ -155,4 +159,3 @@ static inline int hub_port_debounce_be_stable(struct 
usb_hub *hub,
 {
return hub_port_debounce(hub, port1, false);
 }
-
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 2106183..cb18ce0 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -50,6 +50,72 @@ static ssize_t connect_type_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(connect_type);
 
+static ssize_t usb3_lpm_permit_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct usb_port *port_dev = to_usb_port(dev);
+   const char *p;
+
+   if (port_dev->usb3_lpm_u1_permit) {
+   if (port_dev->usb3_lpm_u2_permit)
+   p = "u1_u2";
+   

[PATCH v3 3/3] usb: core: lpm: remove usb3_lpm_enabled in usb_device

[Lu Baolu]

Commit 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.")
adds usb3_lpm_enabled member to struct usb_device. There is no reference
to this member now. Hence, it could be removed.

Signed-off-by: Lu Baolu 
---
 include/linux/usb.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/usb.h b/include/linux/usb.h
index b79925d..89533ba 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -510,7 +510,6 @@ struct usb3_lpm_parameters {
  * @usb2_hw_lpm_besl_capable: device can perform USB2 hardware BESL LPM
  * @usb2_hw_lpm_enabled: USB2 hardware LPM is enabled
  * @usb2_hw_lpm_allowed: Userspace allows USB 2.0 LPM to be enabled
- * @usb3_lpm_enabled: USB3 hardware LPM enabled
  * @usb3_lpm_u1_enabled: USB3 hardware U1 LPM enabled
  * @usb3_lpm_u2_enabled: USB3 hardware U2 LPM enabled
  * @string_langid: language ID for strings
@@ -585,7 +584,6 @@ struct usb_device {
unsigned usb2_hw_lpm_besl_capable:1;
unsigned usb2_hw_lpm_enabled:1;
unsigned usb2_hw_lpm_allowed:1;
-   unsigned usb3_lpm_enabled:1;
unsigned usb3_lpm_u1_enabled:1;
unsigned usb3_lpm_u2_enabled:1;
int string_langid;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/3] usb: core: lpm: fix usb3_hardware_lpm sysfs node

[Lu Baolu]

Commit 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3
hardware LPM") introduced usb3_hardware_lpm sysfs node. This
doesn't show the correct status of USB3 U1 and U2 LPM status.

This patch fixes this by replacing usb3_hardware_lpm with two
nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2
(for U2), and recording the U1/U2 LPM status in right places.

This patch should be back-ported to kernels as old as 4.3,
that contains Commit 655fe4effe0f ("usbcore: add sysfs support
to xHCI usb3 hardware LPM").

Cc: sta...@vger.kernel.org
Signed-off-by: Lu Baolu 
---
 Documentation/ABI/testing/sysfs-bus-usb | 16 --
 Documentation/usb/power-management.txt  | 11 +-
 drivers/usb/core/hub.c  | 39 +
 drivers/usb/core/sysfs.c| 31 +-
 include/linux/usb.h |  4 
 5 files changed, 75 insertions(+), 26 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-usb 
b/Documentation/ABI/testing/sysfs-bus-usb
index 3a4abfc..136ba17 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -134,19 +134,21 @@ Description:
enabled for the device. Developer can write y/Y/1 or n/N/0 to
the file to enable/disable the feature.
 
-What:  /sys/bus/usb/devices/.../power/usb3_hardware_lpm
-Date:  June 2015
+What:  /sys/bus/usb/devices/.../power/usb3_hardware_lpm_u1
+   /sys/bus/usb/devices/.../power/usb3_hardware_lpm_u2
+Date:  November 2015
 Contact:   Kevin Strasser 
+   Lu Baolu 
 Description:
If CONFIG_PM is set and a USB 3.0 lpm-capable device is plugged
in to a xHCI host which supports link PM, it will check if U1
and U2 exit latencies have been set in the BOS descriptor; if
-   the check is is passed and the host supports USB3 hardware LPM,
+   the check is passed and the host supports USB3 hardware LPM,
USB3 hardware LPM will be enabled for the device and the USB
-   device directory will contain a file named
-   power/usb3_hardware_lpm. The file holds a string value (enable
-   or disable) indicating whether or not USB3 hardware LPM is
-   enabled for the device.
+   device directory will contain two files named
+   power/usb3_hardware_lpm_u1 and power/usb3_hardware_lpm_u2. These
+   files hold a string value (enable or disable) indicating whether
+   or not USB3 hardware LPM U1 or U2 is enabled for the device.
 
 What:  /sys/bus/usb/devices/.../removable
 Date:  February 2012
diff --git a/Documentation/usb/power-management.txt 
b/Documentation/usb/power-management.txt
index 4a15c90..0a94ffe 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -537,17 +537,18 @@ relevant attribute files are usb2_hardware_lpm and 
usb3_hardware_lpm.
can write y/Y/1 or n/N/0 to the file to enable/disable
USB2 hardware LPM manually. This is for test purpose mainly.
 
-   power/usb3_hardware_lpm
+   power/usb3_hardware_lpm_u1
+   power/usb3_hardware_lpm_u2
 
When a USB 3.0 lpm-capable device is plugged in to a
xHCI host which supports link PM, it will check if U1
and U2 exit latencies have been set in the BOS
descriptor; if the check is is passed and the host
supports USB3 hardware LPM, USB3 hardware LPM will be
-   enabled for the device and this file will be created.
-   The file holds a string value (enable or disable)
-   indicating whether or not USB3 hardware LPM is
-   enabled for the device.
+   enabled for the device and these files will be created.
+   The files hold a string value (enable or disable)
+   indicating whether or not USB3 hardware LPM U1 or U2
+   is enabled for the device.
 
USB Port Power Control
--
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bdeadc1..59f998e 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3875,17 +3875,30 @@ static void usb_enable_link_state(struct usb_hcd *hcd, 
struct usb_device *udev,
return;
}
 
-   if (usb_set_lpm_timeout(udev, state, timeout))
+   if (usb_set_lpm_timeout(udev, state, timeout)) {
/* If we can't set the parent hub U1/U2 timeout,
 * device-initiated LPM won't be allowed either, so let the xHCI
 * host know that this link state won't be enabled.
 */

Re: USB Device needs to be unplugged and plugged in to work

[Peter Stuge]

Jose Colmenares wrote:
> If the computer starts, and the IMU is already plugged in, I have
> to unplug it and plug it again. This is unacceptable because the
> IMU will be used in a robot, so we cannot just unplug it every time
> the robot starts.

In a prototype you could work around this problem with custom hardware
to control VBUS in the IMU USB connection, which to the device looks
like the cable has been disconnected.

TI TPS20xxC power switches (e.g. TPS2051C and TPS2065C) are designed
for USB, are frequently used in PCs, and work just fine.

But please provide the debugging information already asked for in this
thread, so that the software problem may be resolved for the future.


Thanks

//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Page allocation failure

[Alan Stern]

On Fri, 13 Nov 2015, Steinar H. Gunderson wrote:

> On Fri, Nov 13, 2015 at 04:02:48PM -0500, Alan Stern wrote:
> >> So what is the road from here? I guess the original questions about cache
> >> coherency still apply, and that this is what I'm seeing in dmesg.
> > What questions?  It should be obvious that the user program should not 
> > touch the buffer contents while the transfer is taking place.
> 
> The subthread I'm thinking of starts at 
> 
>   http://marc.info/?l=linux-usb=138091207413756=2
> 
> I can't claim to have gone deeply into the details, though.

Ah, okay.  I don't think that's an issue.  The pages don't need to be 
uncached because the system will flush the cache contents when the 
pages are mapped for DMA.  That's the normal mechanism for ordinary USB 
transfer buffers (which are always located in cacheable memory).

> > What are you seeing in dmesg?
> 
> Several copies of
> 
> [ 1175.838536] x86/PAT: app:2838 map pfn RAM range req uncached-minus for 
> [mem 0x9fa4c000-0x9fa4], got write-back

Perhaps that will go away if you don't ask for uncached memory.

> > The next step would be to massage the patch and get it into a form
> > suitable for applying.  This may well include changing the way the API
> > works; for example, I'm not sure that allocating memory should be a
> > separate step from mmap.
> 
> Yes, it sounds a bit odd to me, too.
> 
> I suppose there's no way to let userspace allocate this memory? Again,
> for me personally it would be ideal to be able to give it in from a PBO
> (ie., GPU memory).

The problem with letting userspace allocate the memory is that there's 
no way to guarantee that the pages will lie in the first 4 GB of 
memory.  While this doesn't matter for host controllers capable of 
doing 64-bit DMA, not all controllers have that capability.

And you probably couldn't use GPU memory for this purpose because (I
assume) the USB host controller wouldn't be able to access it via DMA.

Incidentally, I wonder how well this patch really does fix your 
problem.  What happens if you run the old program until it fails with 
the "unable to allocate memory" error and then try running the new 
program?  I suspect the new program will also fail under those 
circumstances.  The only advantage it has is that if the initial 
allocations succeed then you don't have to worry about later 
allocations failing, because the buffer memory is allocated only once.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Page allocation failure

[Steinar H. Gunderson]

On Sat, Nov 14, 2015 at 12:09:38PM -0500, Alan Stern wrote:
> And you probably couldn't use GPU memory for this purpose because (I
> assume) the USB host controller wouldn't be able to access it via DMA.

I guess that depends a bit; on my particular system, I'm using an Intel GPU,
so memory is shared. But I assume you can't do this if the memory is
dedicated and just mapped up from a dedicated GPU.

> Incidentally, I wonder how well this patch really does fix your 
> problem.  What happens if you run the old program until it fails with 
> the "unable to allocate memory" error and then try running the new 
> program?  I suspect the new program will also fail under those 
> circumstances.  The only advantage it has is that if the initial 
> allocations succeed then you don't have to worry about later 
> allocations failing, because the buffer memory is allocated only once.

You are right in that it doesn't solve at all the problem “can't allocate
memory on startup”, but that's not the problem I have at all. So it really
does solve my problem, but it does not solve all other related problems.

Incidentally, once it's really bad (without the patch), I can usually run for
a few frames before it starts failing again, so I would assume that the
result of the experiment you're proposing would actually be “it works well”.
Seemingly the memory fragmentation (or whatever it is) just increases the
probability of the allocation failing by a lot, it doesn't move it to 100%.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Alan Stern]

On Fri, 13 Nov 2015, Doug Anderson wrote:

> To handle things smarter, I think I need to research how to deal with
> hubs attached to hubs attached to hubs.  For instance:
> 
> dwc2
> -> multi_tt hub
> -> single_tt hub
> -> device 1
> -> device 2
> -> single_tt hub
> -> device 3
> -> device 4
> vs.
> 
> dwc2
> -> single_tt hub
> -> multi_tt hub
> -> device 1
> -> device 2
> -> multi_tt hub
> -> device 3
> -> device 4
> 
> In the first case I presume I could schedule device 1 and device 3 at
> the same time, but not device 2 and device 4.

Devices 2 and 4 are related in exactly the same way as 1 and 3.  You 
can schedule them independently.  But you can't schedule 1 
independently of 2 or 3 independently of 4.

>  In the 2nd case I
> presume I could schedule all 4 devices independently.  ...but I
> haven't dug through the spec to confirm that, yet.

That's right.  The basic rule is very simple: Independent scheduling 
requires that the devices in question be attached through different 
TTs, where a multi-TT hub has a separate TT for each port.

On the other hand, it's important to keep in mind that even though you
can consider the devices independently as far as scheduling on the
FS/LS buses is concerned, you also have to consider the bandwidth
requirements of the SSPLIT and CSPLIT packets on the HS bus.  Since
there's only one HS bus, those things can't be independent.

How do you decide which microframes to dedicate to a particular
endpoint?  The scheduler in ehci-hcd isn't especially sophisticated
about this, and it can easily work itself into a corner by allocating
things in such a way that there's no microframe to put a new request
even though the total amount of available bandwidth is more than
sufficient.  I have put a lot of thought into ways of improving this,
but there doesn't seem to be any good approach that doesn't require
rebalancing (i.e., changing the microframes allocated to certain
endpoints) from time to time.  Rebalancing is very awkward because it
means stopping some ongoing transfers temporarily, removing the entries
from their old scheduled positions, putting them into the new
positions, and then restarting the transfers.  It can't be done
transparently or quickly.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: at91sam9x5: USB mass storage gadget problems

[Douglas Gilbert]

On 15-11-12 05:18 PM, Alan Stern wrote:

On Thu, 12 Nov 2015, Douglas Gilbert wrote:


Yes, the X201 has USB 2.0 host ports. It is running a stock Ubuntu
15.10 kernel: 4.2.0-18-generic and the log indicates that the
ehci_pci driver is being used. Part of the X201's syslog is
attached in which a driver complains about the invalid maxpacket
values of 64.

So its seems that the ehci drivers as used on the X201 can work
around the invalid maxpacket value (64) while the xhci drivers
used by the X240 (due to the USB 3.0 host ports) get tripped up.


Yes, I think that's right.  The restriction that high speed bulk
endpoints must have a maxpacket size of 512 is enforced by the xHCI
hardware but not by the EHCI hardware; this explains why ehci-hcd is
able to work around such violations while xhci-hcd isn't.


Still looking at drivers/usb/gadget/udc/atmel_usba_udc.c which
has lots of changes between lk 3.19.0-rc4 and 4.0.0-rc4 . The
maxpacket value seems (to me) to be related to the fifo-size
in the gadget section of this dts include file:
arch/arm/boot/dts/at91sam9x5.dtsi
which has 1024 for ep1 through ep5 and 64 for ep0.


The assignment of endpoints isn't done in the UDC driver; it is carried
out by epautoconf.c in drivers/usb/gadget/.  So you may need to expand
your bisection search beyond the single UDC driver source file.

Have you tried enabling debugging in the gadget drivers and checking
out the kernel log on the gadget?


So it looks like 1.5 bugs:
- one in atmel's udc driver for the at91sam9x5 family, and
- the inconsistency between the ehci driver working around
  invalid maxpacket values and the xhci driver behaving
  badly (lots of bus resets and a badly made SCSI storage
  device [e.g. INQUIRY works but READ(10) fails]).


The first is clearly a bug, although at the moment we can't be sure
where.  The second is an unavoidable hardware restriction, not a bug.
Anyway, if you fix the first problem then the second won't be an issue.


Found the udc driver bug. A shadow register value was introduced
around lk 4.0 for the Atmel 9x5/sama5d3 UDPHS driver
(atmel_usba_udc.c) for the interrupt status register. It used the
interrupt enable register (last written) value as a mask. At least
for the at91sam9g25 that works apart from the SPEED bit (bit 0)
which is only present in the interrupt status register.

It seems that USB negotiates the link speed during resets and at
the G25 end, even though the hardware had negotiated a "high
speed" link with the host, the logic in usba_udc_irq() deduced it
was only a full speed link (due to the above bug). Thereafter
there was confusion which the ehci_hcd host driver could handle
but the xhci_pci driver could not. In the xhci_pci case there
were multiple high speed link resets in the host log, matched
at the device (G25) end with a similar number of reported _full_
speed resets.

The author of the changes to the code that caused this is
cc-ed on this post. He might like to consider the attached
patch which fixed my problem. However the shadow mask register
technique might have other subtle issues that I'm not
qualified to address.

If I don't hear anything on this issue then I can produce
a patch. Does it go through the ARM or USB (or both) trees?

If my patch is sufficient, then perhaps it should also be
issued against the lk 4.0, 4.1, 4.2 and 4.3 kernels that are
still actively maintained.

Doug Gilbert


diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index f0f2b06..f92f5af 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1633,7 +1633,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
 	spin_lock(>lock);
 
 	int_enb = usba_int_enb_get(udc);
-	status = usba_readl(udc, INT_STA) & int_enb;
+	status = usba_readl(udc, INT_STA) & (int_enb | USBA_HIGH_SPEED);
 	DBG(DBG_INT, "irq, status=%#08x\n", status);
 
 	if (status & USBA_DET_SUSPEND) {

Re: Page allocation failure

[Alan Stern]

On Sat, 14 Nov 2015, Steinar H. Gunderson wrote:

> On Sat, Nov 14, 2015 at 12:09:38PM -0500, Alan Stern wrote:
> > And you probably couldn't use GPU memory for this purpose because (I
> > assume) the USB host controller wouldn't be able to access it via DMA.
> 
> I guess that depends a bit; on my particular system, I'm using an Intel GPU,
> so memory is shared. But I assume you can't do this if the memory is
> dedicated and just mapped up from a dedicated GPU.

Hmmm.  If the shared memory can be accessed by the CPU using ordinary
load and store instructions and it can be kmalloc'ed, then it should be
usable for zerocopy I/O.  But again, only if it satisfies the
restrictions imposed by the USB controller's DMA hardware.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: at91sam9x5: USB mass storage gadget problems

[Boris Brezillon]

Hi Douglas,

On Sat, 14 Nov 2015 14:15:30 -0500
Douglas Gilbert  wrote:

> On 15-11-12 05:18 PM, Alan Stern wrote:
> > On Thu, 12 Nov 2015, Douglas Gilbert wrote:
> >
> >> Yes, the X201 has USB 2.0 host ports. It is running a stock Ubuntu
> >> 15.10 kernel: 4.2.0-18-generic and the log indicates that the
> >> ehci_pci driver is being used. Part of the X201's syslog is
> >> attached in which a driver complains about the invalid maxpacket
> >> values of 64.
> >>
> >> So its seems that the ehci drivers as used on the X201 can work
> >> around the invalid maxpacket value (64) while the xhci drivers
> >> used by the X240 (due to the USB 3.0 host ports) get tripped up.
> >
> > Yes, I think that's right.  The restriction that high speed bulk
> > endpoints must have a maxpacket size of 512 is enforced by the xHCI
> > hardware but not by the EHCI hardware; this explains why ehci-hcd is
> > able to work around such violations while xhci-hcd isn't.
> >
> >> Still looking at drivers/usb/gadget/udc/atmel_usba_udc.c which
> >> has lots of changes between lk 3.19.0-rc4 and 4.0.0-rc4 . The
> >> maxpacket value seems (to me) to be related to the fifo-size
> >> in the gadget section of this dts include file:
> >> arch/arm/boot/dts/at91sam9x5.dtsi
> >> which has 1024 for ep1 through ep5 and 64 for ep0.
> >
> > The assignment of endpoints isn't done in the UDC driver; it is carried
> > out by epautoconf.c in drivers/usb/gadget/.  So you may need to expand
> > your bisection search beyond the single UDC driver source file.
> >
> > Have you tried enabling debugging in the gadget drivers and checking
> > out the kernel log on the gadget?
> >
> >> So it looks like 1.5 bugs:
> >> - one in atmel's udc driver for the at91sam9x5 family, and
> >> - the inconsistency between the ehci driver working around
> >>   invalid maxpacket values and the xhci driver behaving
> >>   badly (lots of bus resets and a badly made SCSI storage
> >>   device [e.g. INQUIRY works but READ(10) fails]).
> >
> > The first is clearly a bug, although at the moment we can't be sure
> > where.  The second is an unavoidable hardware restriction, not a bug.
> > Anyway, if you fix the first problem then the second won't be an issue.
> 
> Found the udc driver bug. A shadow register value was introduced
> around lk 4.0 for the Atmel 9x5/sama5d3 UDPHS driver
> (atmel_usba_udc.c) for the interrupt status register. It used the
> interrupt enable register (last written) value as a mask. At least
> for the at91sam9g25 that works apart from the SPEED bit (bit 0)
> which is only present in the interrupt status register.
> 
> It seems that USB negotiates the link speed during resets and at
> the G25 end, even though the hardware had negotiated a "high
> speed" link with the host, the logic in usba_udc_irq() deduced it
> was only a full speed link (due to the above bug). Thereafter
> there was confusion which the ehci_hcd host driver could handle
> but the xhci_pci driver could not. In the xhci_pci case there
> were multiple high speed link resets in the host log, matched
> at the device (G25) end with a similar number of reported _full_
> speed resets.
> 
> The author of the changes to the code that caused this is
> cc-ed on this post. He might like to consider the attached
> patch which fixed my problem. However the shadow mask register
> technique might have other subtle issues that I'm not
> qualified to address.

Looks good to me, and sorry for the inconvenience.

> 
> If I don't hear anything on this issue then I can produce
> a patch. Does it go through the ARM or USB (or both) trees?

You can go ahead and send a patch to the ARM and USB MLs (+
appropriate maintainers), unless you want me to do it.

> 
> If my patch is sufficient, then perhaps it should also be
> issued against the lk 4.0, 4.1, 4.2 and 4.3 kernels that are
> still actively maintained.

Yep, adding the following line after your SoB should do the trick:

Cc:  #4.0+

Thanks,

Boris



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 00/14] Equivalent of tcm_usb_gadget with configfs

[Nicholas A. Bellinger]

Hi Andrzej & Co,

Apologies for the delayed follow up on this series.

On Tue, 2015-10-27 at 10:39 +0100, Andrzej Pietrasiewicz wrote:
> Dear All,
> 
> This series adds support to tcm usb gadget for composing it with configfs.
> 
> @target-devel folks: You might be wondering why add configfs for something
> which already supports configfs. In tcm_usb_gadget configfs has beeen
> used for configuring the SCSI target part, but the usb gadget part
> is considered a legacy gadget. A legacy gadget is a composite usb gadget
> whose composition is defined statically at compilation time.
> Composite gadgets can consist of a number of "functions" and configurations.
> In legacy gadgets the selection is hardcoded in a dedicated kernel
> module. But with configfs the selection can be made at runtime without
> writing any kernel code. The conversion process started almost three
> years ago.
> 
> The series aims at integrating configfs into tcm, the way it has been
> done with 19 of 20 usb functions. In other words this concludes the
> process of conversion to configfs in usb gadgets.
> 
> The series depends on the series from Chrisoph:
> http://www.spinics.net/lists/target-devel/msg10730.html

Ok, the configfs attribute conversion changes merged into mainline as of
yesterday.

> 
> @Nicholas: In order to use the series from Christoph (simplifying
> configfs attributes) I rebased my series on top of your for-next,
> which happens not to contain your patches which strip off nexus
> WWPN prefix, fix nexus leak and fix enabled attribute failure.
> I re-post them here. I have split one of them to separate
> unrelated changes.

Thanks for including those fixes in this series.  I've dropped the
original patches.

> 
> @Joel: I resend the patch which adds unlocked versions of
> configfs_(un)depend_item(). The purpose of configfs_(un)depend_item()
> is to allow other kernel subsystems to prohibit deletion of a config
> item until they can live without it. This is exactly the case with
> tcm usb gadget, but the other kernel subsystem happens to be another
> subsystem in configfs: the user must create an instance of the tcm
> function in usb_gadget subsystem in order to be able to create
> a tpg in target subsystem. But once a tpg goes live its corresponding
> tcm function must not be removed until the tpg is deleted.
> Even though these are two distinct configfs subsystems the
> configfs_(un)depend_item() will not work from a configfs callback.
> That is why there is a need to provide the "unlocked" variant.
> 
> v2..v3:
> - dropped a patch adding unlocked versions of depend/undepend item,
> instead this series depends on a series from Krzysztof:
> 
> http://www.spinics.net/lists/linux-usb/msg131720.html

I haven't seen any further discussion on Krzysztof's -v4 configfs
changes to add configfs_depend_item_unlocked() for the special usb-gaget
case described here.

Jlbec, do you have any further objections or concerns..?

> 
> v1..v2:
> - added missing comments
> - used the next version of configfs_(un)depend_item_unlocked()
> - fixed bug: THIS_MODULE is NULL if a module is compiled-in, so we cannot
> rely on opts->dependent being non-NULL if a dependent module is present
> - added passing configfs subsystem to configfs_(un)depend_item_unlocked()
> 
> BACKWARD COMPATIBILITY
> ==
> 
> Please note that the old tcm_usb_gadget.ko is still available and works.
> 

Ok, I've added both series into target-pending/queue-next so kbuild can
give it a first pass.

We'll need to get Jlbec's ACK on the configfs parts, and Sebastian's ACK
on this series ahead of getting them into next as v4.5-rc code.

I don't have a preference of taking these through target-pending, so if
other folks prefer to merge via other means, I'm happy to drop them.

Thank you,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Atmel USB High speed device port, speed fix

[Douglas Gilbert]

Following changes that appeared in lk 4.0.0, the gadget udc driver for
some ARM based Atmel SoCs (e.g. at91sam9x5 and sama5d3 families)
incorrectly deduced full-speed USB link speed even when the hardware
had negotiated a high-speed link. The fix is to make sure that the
UDPHS Interrupt Enable Register value does not mask the SPEED bit
in the Interrupt Status Register.

For a mass storage gadget this problem lead to failures when the host
had a USB 3 port with the xhci_hcd driver. If the host was a USB 2
port using the ehci_hcd driver then the mass storage gadget worked
(but probably at a lower speed than it should have).


Signed-of-by: Douglas Gilbert 
Cc:  #4.0+
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index f0f2b06..f92f5af 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1633,7 +1633,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
 	spin_lock(>lock);
 
 	int_enb = usba_int_enb_get(udc);
-	status = usba_readl(udc, INT_STA) & int_enb;
+	status = usba_readl(udc, INT_STA) & (int_enb | USBA_HIGH_SPEED);
 	DBG(DBG_INT, "irq, status=%#08x\n", status);
 
 	if (status & USBA_DET_SUSPEND) {