mass storage behaviour

[Paul Jones]

I’m investigating the (lack of) performance (around 150MB/s) of the USB3380 
gadget in mass storage mode.
Whilst tracing on a Linux 4.1 host I noticed that the Linux max storage driver 
is requesting 240 blocks, 16 blocks, 240 blocks, 16 blocks, etc. when doing a 
dd directly on the device:
dd if=/dev/sdb of=/dev/null bs=64k count=8k
where /dev/sdb is the emulated device.
The emulated device is provided from a secondary machine with a USB3380 card 
emulating the mass storage device from a local SSD (local dd of the disk file 
reads at 542 MB/s).

lsusb on the host:
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M

lspci on the host:
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller 
(rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor 
PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor 
HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series 
Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series Chipset 
Family KT Controller (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 
05)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High 
Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI 
Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI 
Express Root Port #3 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation Q87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 
6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus 
Controller (rev 05)

Tracing using usbmon on the host shows:
88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c2  
0600    00
88002ea45b40 558636455 C Bo:2:003:2 0 31 >
88002ea45b40 558636459 S Bi:2:003:1 -115 13 <
88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c2  00
88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c2  
061e 0001   00
88002ea45b40 558636610 C Bo:2:003:2 0 31 >
88002ea45b40 558636627 S Bi:2:003:1 -115 13 <
88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c2  00
88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c2 00e00100 
8a28  00f0  00
88002ea45b40 558636757 C Bo:2:003:2 0 31 >
880407982f00 558636765 S Bi:2:003:1 -115 122880 <
880407982f00 558637699 C Bi:2:003:1 0 122880 =    
    
88002ea45b40 558637717 S Bi:2:003:1 -115 13 <
88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c2  00
88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c2 0020 
8a28  f010  00
88002ea45b40 558637778 C Bo:2:003:2 0 31 >
88040ca76a80 558637797 S Bi:2:003:1 -115 8192 <
88040ca76a80 558637892 C Bi:2:003:1 0 8192 =    
    
88002ea45b40 558637908 S Bi:2:003:1 -115 13 <
88002ea45b40 558637933 C Bi:2:003:1 0 13 = 55534253 66c2  00
88002ea45b40 558637959 S Bo:2:003:2 -115 31 = 55534243 67c2 00e00100 
8a28 0001 00f0  00
88002ea45b40 558637973 C Bo:2:003:2 0 31 >
880407982f00 558637976 S Bi:2:003:1 -115 122880 <
880407982f00 558638898 C Bi:2:003:1 0 122880 =    
    
88002ea45b40 558638901 S Bi:2:003:1 -115 13 <
88002ea45b40 558638938 C Bi:2:003:1 0 13 = 55534253 67c2  00
88002ea45b40 558638976 S Bo:2:003:2 -115 31 = 55534243 68c2 0020 
8a28 0001 f010  00
88002ea45b40 

Re: mass storage behaviour

[Alan Stern]

On Mon, 5 Oct 2015, Paul Jones wrote:

> I�m investigating the (lack of) performance (around 150MB/s) of the USB3380 
> gadget in mass storage mode.
> Whilst tracing on a Linux 4.1 host I noticed that the Linux max storage 
> driver is requesting 240 blocks, 16 blocks, 240 blocks, 16 blocks, etc. when 
> doing a dd directly on the device:
>   dd if=/dev/sdb of=/dev/null bs=64k count=8k
> where /dev/sdb is the emulated device.
> The emulated device is provided from a secondary machine with a USB3380 card 
> emulating the mass storage device from a local SSD (local dd of the disk file 
> reads at 542 MB/s).
> 
> lsusb on the host:
> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
> |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> |__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
> 
> lspci on the host:

...

> Tracing using usbmon on the host shows:
> 88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c2  
> 0600    00
> 88002ea45b40 558636455 C Bo:2:003:2 0 31 >
> 88002ea45b40 558636459 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c2  00
> 88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c2  
> 061e 0001   00
> 88002ea45b40 558636610 C Bo:2:003:2 0 31 >
> 88002ea45b40 558636627 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c2  00
> 88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c2 00e00100 
> 8a28  00f0  00
> 88002ea45b40 558636757 C Bo:2:003:2 0 31 >
> 880407982f00 558636765 S Bi:2:003:1 -115 122880 <
> 880407982f00 558637699 C Bi:2:003:1 0 122880 =    
>     
> 88002ea45b40 558637717 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c2  00
> 88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c2 0020 
> 8a28  f010  00
> 88002ea45b40 558637778 C Bo:2:003:2 0 31 >
> 88040ca76a80 558637797 S Bi:2:003:1 -115 8192 <
> 88040ca76a80 558637892 C Bi:2:003:1 0 8192 =    
>     
> 88002ea45b40 558637908 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558637933 C Bi:2:003:1 0 13 = 55534253 66c2  00
> 88002ea45b40 558637959 S Bo:2:003:2 -115 31 = 55534243 67c2 00e00100 
> 8a28 0001 00f0  00
> 88002ea45b40 558637973 C Bo:2:003:2 0 31 >
> 880407982f00 558637976 S Bi:2:003:1 -115 122880 <
> 880407982f00 558638898 C Bi:2:003:1 0 122880 =    
>     
> 88002ea45b40 558638901 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558638938 C Bi:2:003:1 0 13 = 55534253 67c2  00
> 88002ea45b40 558638976 S Bo:2:003:2 -115 31 = 55534243 68c2 0020 
> 8a28 0001 f010  00
> 88002ea45b40 558638984 C Bo:2:003:2 0 31 >
> 88040ca76a80 558638992 S Bi:2:003:1 -115 8192 <
> 88040ca76a80 558639095 C Bi:2:003:1 0 8192 =    
>     
> 88002ea45b40 558639110 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558639136 C Bi:2:003:1 0 13 = 55534253 68c2  00
> 
> Any ideas why the driver is requesting varying block sizes?

The usb-storage driver requests what the block layer tells it to
request.

Unless you change the settings, the maximum number of blocks allowed in
a single transfer is 240 (i.e., 120 KB).  Consequently, 128-KB reads
get broken up into 120 KB followed by 8 KB.  (You can alter the default
by writing to /sys/block/sd*/queue/max_sectors_kb -- fill in the *
appropriately).

> It also seems odd that the mass storage gadget takes a long time to
> respond to the CBW of each read request (as it doesn�t actually need
> to return the data at that point).

I don't know what you mean.  The response time for the first READ CBW
was 9 microseconds (558636757 - 558636748 in the timestamp column); for
the second it was 18 us; then 14 us and 8 us for the third and fourth.  
Those don't seem very long.

Are you sure you're not looking at the time required to transfer the 
actual data?

>  It seems that the gadget is waiting for the underlying request to
> retrieve data blocks to actually finish, before acknowledging the
> request, as the response time after a 240 block request is
> consistently much longer 

Re: mass storage behaviour

[Alan Stern]

On Mon, 5 Oct 2015, Paul Jones wrote:

> > g_mass_storage, by default, uses 2 struct usb_request, try increasing that 
> > to 4
> > (can be done from make menuconfig itself) and see if anything changes.
> If you are talking about the �number of storage pipeline buffers� I already 
> have them at 4.
> I had similar results in previous kernels where I hadn�t set this value to 4.

My feeling is that the number of buffers won't make a whole lot of 
difference to the final throughput.  Increasing the number will smooth 
out variations and remove latencies caused by other tasks.  But the two 
fundamental limits on the throughput are the USB data transfer rate and 
the rate at which data can be transferred to/from the backing storage.  
Whichever is slower will be the bottleneck, and using more buffers 
won't change that.

Increasing the max_sectors_kb value, on the other hand, might remove
overhead by allowing a higher percentage of the transfer to consist of
real data as opposed to CBW and CSW packets.  This depends to some
extent on other factors (such as whether the memory pages are
contiguous, allowing for larger transfers), but it can't hurt.

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

[PATCH] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

[Nathan Sullivan]

From: Ben Shelton 

The USB gadget support currently depends on power management
(CONFIG_PM) being enabled, but does not actually need it enabled.
Remove this dependency.

Tested on Bay Trail hardware with dwc3 USB.

Signed-off-by: Nathan Sullivan 
---
 drivers/usb/core/Kconfig |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index a99c89e..9c5cdf3 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -43,7 +43,6 @@ config USB_DYNAMIC_MINORS
 
 config USB_OTG
bool "OTG support"
-   depends on PM
default n
help
  The most notable feature of USB OTG is support for a
-- 
1.7.10.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

Re: mass storage behaviour

[Paul Jones]

On 05 Oct 2015, at 20:29, Alan Stern  wrote:

> On Mon, 5 Oct 2015, Paul Jones wrote:
> 
>> I�m investigating the (lack of) performance (around 150MB/s) of the USB3380 
>> gadget in mass storage mode.
>> Whilst tracing on a Linux 4.1 host I noticed that the Linux max storage 
>> driver is requesting 240 blocks, 16 blocks, 240 blocks, 16 blocks, etc. when 
>> doing a dd directly on the device:
>>  dd if=/dev/sdb of=/dev/null bs=64k count=8k
>> where /dev/sdb is the emulated device.
>> The emulated device is provided from a secondary machine with a USB3380 card 
>> emulating the mass storage device from a local SSD (local dd of the disk 
>> file reads at 542 MB/s).
>> 
>> lsusb on the host:
>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
>>|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>>|__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
>> 
>> lspci on the host:
> 
> ...
> 
>> Tracing using usbmon on the host shows:
>> 88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c2  
>> 0600    00
>> 88002ea45b40 558636455 C Bo:2:003:2 0 31 >
>> 88002ea45b40 558636459 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c2  00
>> 88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c2  
>> 061e 0001   00
>> 88002ea45b40 558636610 C Bo:2:003:2 0 31 >
>> 88002ea45b40 558636627 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c2  00
>> 88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c2 00e00100 
>> 8a28  00f0  00
>> 88002ea45b40 558636757 C Bo:2:003:2 0 31 >
>> 880407982f00 558636765 S Bi:2:003:1 -115 122880 <
>> 880407982f00 558637699 C Bi:2:003:1 0 122880 =   
>>      
>> 88002ea45b40 558637717 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c2  00
>> 88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c2 0020 
>> 8a28  f010  00
>> 88002ea45b40 558637778 C Bo:2:003:2 0 31 >
>> 88040ca76a80 558637797 S Bi:2:003:1 -115 8192 <
>> 88040ca76a80 558637892 C Bi:2:003:1 0 8192 =    
>>     
>> 88002ea45b40 558637908 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558637933 C Bi:2:003:1 0 13 = 55534253 66c2  00
>> 88002ea45b40 558637959 S Bo:2:003:2 -115 31 = 55534243 67c2 00e00100 
>> 8a28 0001 00f0  00
>> 88002ea45b40 558637973 C Bo:2:003:2 0 31 >
>> 880407982f00 558637976 S Bi:2:003:1 -115 122880 <
>> 880407982f00 558638898 C Bi:2:003:1 0 122880 =   
>>      
>> 88002ea45b40 558638901 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558638938 C Bi:2:003:1 0 13 = 55534253 67c2  00
>> 88002ea45b40 558638976 S Bo:2:003:2 -115 31 = 55534243 68c2 0020 
>> 8a28 0001 f010  00
>> 88002ea45b40 558638984 C Bo:2:003:2 0 31 >
>> 88040ca76a80 558638992 S Bi:2:003:1 -115 8192 <
>> 88040ca76a80 558639095 C Bi:2:003:1 0 8192 =    
>>     
>> 88002ea45b40 558639110 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558639136 C Bi:2:003:1 0 13 = 55534253 68c2  00
>> 
>> Any ideas why the driver is requesting varying block sizes?
> 
> The usb-storage driver requests what the block layer tells it to
> request.
I’m running a dd with a block size of 64k, so it seems to be aggregating 2 
requests and then splits them again.

> Unless you change the settings, the maximum number of blocks allowed in
> a single transfer is 240 (i.e., 120 KB).  Consequently, 128-KB reads
> get broken up into 120 KB followed by 8 KB.  (You can alter the default
> by writing to /sys/block/sd*/queue/max_sectors_kb -- fill in the *
> appropriately).
I’ll give that a try.

> 
>> It also seems odd that the mass storage gadget takes a long time to
>> respond to the CBW of each read request (as it doesn�t actually need
>> to return the data at that point).
> 
> I don't know what you mean.  The response time for the first READ CBW
> was 9 microseconds (558636757 - 558636748 in the timestamp column); for
> the second it was 18 us; then 14 us and 8 us for the third and fourth.  
> Those don't seem very 

Re: mass storage behaviour

[Felipe Balbi]

On Mon, Oct 05, 2015 at 07:30:05PM +0200, Paul Jones wrote:
> I’m investigating the (lack of) performance (around 150MB/s) of the USB3380
> gadget in mass storage mode.  Whilst tracing on a Linux 4.1 host I noticed
> that the Linux max storage driver is requesting 240 blocks, 16 blocks, 240
> blocks, 16 blocks, etc. when doing a dd directly on the device: dd if=/dev/sdb
> of=/dev/null bs=64k count=8k where /dev/sdb is the emulated device.  The
> emulated device is provided from a secondary machine with a USB3380 card
> emulating the mass storage device from a local SSD (local dd of the disk file
> reads at 542 MB/s).
> 
> lsusb on the host:
> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
> |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> |__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
> 
> lspci on the host:
> 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller 
> (rev 06)
> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor 
> PCI Express x16 Controller (rev 06)
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
> Core Processor Integrated Graphics Controller (rev 06)
> 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor HD Audio Controller (rev 06)
> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
> USB xHCI (rev 05)
> 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series 
> Chipset Family MEI Controller #1 (rev 04)
> 00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series Chipset 
> Family KT Controller (rev 04)
> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM 
> (rev 05)
> 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
> USB EHCI #2 (rev 05)
> 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High 
> Definition Audio Controller (rev 05)
> 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI 
> Express Root Port #1 (rev d5)
> 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI 
> Express Root Port #3 (rev d5)
> 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
> USB EHCI #1 (rev 05)
> 00:1f.0 ISA bridge: Intel Corporation Q87 Express LPC Controller (rev 05)
> 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset 
> Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
> 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus 
> Controller (rev 05)
> 
> Tracing using usbmon on the host shows:
> 88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c2  
> 0600    00
> 88002ea45b40 558636455 C Bo:2:003:2 0 31 >
> 88002ea45b40 558636459 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c2  00
> 88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c2  
> 061e 0001   00
> 88002ea45b40 558636610 C Bo:2:003:2 0 31 >
> 88002ea45b40 558636627 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c2  00
> 88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c2 00e00100 
> 8a28  00f0  00
> 88002ea45b40 558636757 C Bo:2:003:2 0 31 >
> 880407982f00 558636765 S Bi:2:003:1 -115 122880 <
> 880407982f00 558637699 C Bi:2:003:1 0 122880 =    
>     
> 88002ea45b40 558637717 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c2  00
> 88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c2 0020 
> 8a28  f010  00
> 88002ea45b40 558637778 C Bo:2:003:2 0 31 >
> 88040ca76a80 558637797 S Bi:2:003:1 -115 8192 <
> 88040ca76a80 558637892 C Bi:2:003:1 0 8192 =    
>     
> 88002ea45b40 558637908 S Bi:2:003:1 -115 13 <
> 88002ea45b40 558637933 C Bi:2:003:1 0 13 = 55534253 66c2  00
> 88002ea45b40 558637959 S Bo:2:003:2 -115 31 = 55534243 67c2 00e00100 
> 8a28 0001 00f0  00
> 88002ea45b40 558637973 C Bo:2:003:2 0 31 >
> 880407982f00 558637976 S Bi:2:003:1 -115 122880 <
> 880407982f00 558638898 C Bi:2:003:1 0 122880 =    
>     
> 88002ea45b40 558638901 S Bi:2:003:1 -115 

Re: Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects

[Alan Stern]

On Mon, 5 Oct 2015, Eugen Rogoza wrote:

> Hello,
> 
> in xHCI mode I'm experiencing random disconnects and reconnects of my ASMedia 
> ASM1051-based external HDD enclosure.
> 
> The only combination where the disconnects are happening is Intel USB Host 
> Controller + Linux kernel + XHCI mode (see further observations below).
> 
> I did some tracing with libpcap (can be opened in Wireshark). I did one trace 
> on the NEC chipset where I have no disconnects and one on the Intel chipset 
> where I do experience disconnects. The Intel output clearly shows that at 
> some point in time a URB_INTERRUPT is sent from "1.1" (I suppose it is the 
> hub) to the host (packet 1780) and the host requests a port reset (packet 
> 1800). The procedure repeats after a random time (packet 3648). The NEC trace 
> does not have such interrupts.
> 
> Why is that interrupt sent? Where is it coming from?

It comes from the xHCI host controller.  It is an indication that the
link to the device became inactive, possibly as a result of Link Power
Management.

> Additional info and observations below:
> 
> Observations:
> 
> - independent of activity/workload

Are you sure about that?  In your Intel pcap file, the problem occurred 
only after long periods of inactivity: 40 seconds the first time, 150 
seconds the second time.

> - works perfectly under Windows 7 in XHCI mode
> - works everywhere (Linux and Windows) when using USB 2.0 mode (EHCI)
> - tried with kernels 4.0.5, 4.2.0 and 3.18.16 - no difference
> - enabling/disabling runtime PM and USB power management doesn't make any 
> difference

The only way to turn off Link Power Management currently is to disable
CONFIG_PM entirely.

> - works on a different host hardware with a NEC USB3.0 host controller (see 
> details below). Tested with kernel 3.17.7.
> 
> Traces can be downloaded here:
> 
> http://wikisend.com/download/136936/usb3_intel.pcapng.gz
> http://wikisend.com/download/612580/usb3_nec.pcapng.gz
> 
> 
> Output of /var/log/messages demonstrating the issue: 
> http://pastebin.com/wbUr5mMe
> 
> 
> lsusb and lspci outputs (Intel hardware): http://pastebin.com/XDEz2x2g
> 
> 
> lsusb and lspci outputs (NEC hardware): http://pastebin.com/1M1ZVyJr
> 
> 
> Thanks for help,

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: mass storage behaviour

[Paul Jones]

On 05 Oct 2015, at 20:08, Felipe Balbi  wrote:

> On Mon, Oct 05, 2015 at 07:30:05PM +0200, Paul Jones wrote:
>> I’m investigating the (lack of) performance (around 150MB/s) of the USB3380
>> gadget in mass storage mode.  Whilst tracing on a Linux 4.1 host I noticed
>> that the Linux max storage driver is requesting 240 blocks, 16 blocks, 240
>> blocks, 16 blocks, etc. when doing a dd directly on the device: dd 
>> if=/dev/sdb
>> of=/dev/null bs=64k count=8k where /dev/sdb is the emulated device.  The
>> emulated device is provided from a secondary machine with a USB3380 card
>> emulating the mass storage device from a local SSD (local dd of the disk file
>> reads at 542 MB/s).
>> 
>> lsusb on the host:
>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
>>|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>>|__ Port 6: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
>> 
>> lspci on the host:
>> 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM 
>> Controller (rev 06)
>> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor 
>> PCI Express x16 Controller (rev 06)
>> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
>> Core Processor Integrated Graphics Controller (rev 06)
>> 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
>> Processor HD Audio Controller (rev 06)
>> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family USB xHCI (rev 05)
>> 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series 
>> Chipset Family MEI Controller #1 (rev 04)
>> 00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family KT Controller (rev 04)
>> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM 
>> (rev 05)
>> 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family USB EHCI #2 (rev 05)
>> 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High 
>> Definition Audio Controller (rev 05)
>> 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family 
>> PCI Express Root Port #1 (rev d5)
>> 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family 
>> PCI Express Root Port #3 (rev d5)
>> 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family USB EHCI #1 (rev 05)
>> 00:1f.0 ISA bridge: Intel Corporation Q87 Express LPC Controller (rev 05)
>> 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset 
>> Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
>> 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus 
>> Controller (rev 05)
>> 
>> Tracing using usbmon on the host shows:
>> 88002ea45b40 558636438 S Bo:2:003:2 -115 31 = 55534243 63c2  
>> 0600    00
>> 88002ea45b40 558636455 C Bo:2:003:2 0 31 >
>> 88002ea45b40 558636459 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558636537 C Bi:2:003:1 0 13 = 55534253 63c2  00
>> 88002ea45b40 558636593 S Bo:2:003:2 -115 31 = 55534243 64c2  
>> 061e 0001   00
>> 88002ea45b40 558636610 C Bo:2:003:2 0 31 >
>> 88002ea45b40 558636627 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558636669 C Bi:2:003:1 0 13 = 55534253 64c2  00
>> 88002ea45b40 558636748 S Bo:2:003:2 -115 31 = 55534243 65c2 00e00100 
>> 8a28  00f0  00
>> 88002ea45b40 558636757 C Bo:2:003:2 0 31 >
>> 880407982f00 558636765 S Bi:2:003:1 -115 122880 <
>> 880407982f00 558637699 C Bi:2:003:1 0 122880 =   
>>      
>> 88002ea45b40 558637717 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558637728 C Bi:2:003:1 0 13 = 55534253 65c2  00
>> 88002ea45b40 558637760 S Bo:2:003:2 -115 31 = 55534243 66c2 0020 
>> 8a28  f010  00
>> 88002ea45b40 558637778 C Bo:2:003:2 0 31 >
>> 88040ca76a80 558637797 S Bi:2:003:1 -115 8192 <
>> 88040ca76a80 558637892 C Bi:2:003:1 0 8192 =    
>>     
>> 88002ea45b40 558637908 S Bi:2:003:1 -115 13 <
>> 88002ea45b40 558637933 C Bi:2:003:1 0 13 = 55534253 66c2  00
>> 88002ea45b40 558637959 S Bo:2:003:2 -115 31 = 55534243 67c2 00e00100 
>> 8a28 0001 00f0  00
>> 88002ea45b40 558637973 C Bo:2:003:2 0 31 >
>> 880407982f00 558637976 S Bi:2:003:1 -115 122880 <
>> 880407982f00 

Re: [PATCH] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

[Felipe Balbi]

Nathan Sullivan  writes:

> From: Ben Shelton 
>
> The USB gadget support currently depends on power management
> (CONFIG_PM) being enabled, but does not actually need it enabled.
> Remove this dependency.
>
> Tested on Bay Trail hardware with dwc3 USB.
>
> Signed-off-by: Nathan Sullivan 
> ---
>  drivers/usb/core/Kconfig |1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index a99c89e..9c5cdf3 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -43,7 +43,6 @@ config USB_DYNAMIC_MINORS
>  
>  config USB_OTG
>   bool "OTG support"
> - depends on PM

IIRC we had this dependency because OTG needs support USB bus suspend
and afaict, that's only available on PM builds

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Rafael J. Wysocki]

On Monday, October 05, 2015 04:45:28 PM Tomeu Vizoso wrote:
> Hi,
> 
> this is v9 of an attempt to make it easier for devices to remain in
> runtime PM when the system goes to sleep, mainly to reduce the time
> spent resuming devices.
> 
> For this, we interpret the absence of all PM callback implementations as
> it being safe to do direct_complete, so their ancestors aren't prevented
> from remaining runtime-suspended.
> 
> Additionally, the prepare() callback of USB devices will return 1 if
> runtime PM is enabled and the current wakeup settings are correct.
> 
> With these changes, a uvcvideo device (for example) stays in runtime
> suspend when the system goes to sleep and is left in that state when the
> system resumes, not delaying it unnecessarily.
> 
> Thanks,
> 
> Tomeu
> 
> Changes in v9:
> - Add docs noting the need for the device lock to be held before calling
>   device_is_bound()
> - Add docs noting the need for the device lock to be held before calling
>   dev_pm_domain_set()
> - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
> - Rename from device_check_pm_callbacks to device_pm_check_callbacks to
>   follow with the naming convention of existing API.
> - Re-add calling to device_pm_check_callbacks from device registration
>   and when updating the PM domain of a device.
> 
> Changes in v8:
> - Add device_is_bound()
> - Add dev_pm_domain_set() and update code to use it
> - Move no_pm_callbacks field into CONFIG_PM_SLEEP
> - Call device_check_pm_callbacks only after a device is bound or unbound
> 
> Changes in v7:
> - Reduce indentation by adding a label in device_prepare()
> 
> Changes in v6:
> - Add stub for !CONFIG_PM.
> - Move implementation of device_check_pm_callbacks to power/main.c as it
>   doesn't belong to CONFIG_PM_SLEEP.
> - Take dev->power.lock before modifying flag.
> 
> Changes in v5:
> - Check for all dev_pm_ops instances associated to a device, updating a
>   no_pm_callbacks flag at the times when that could change.
> 
> Tomeu Vizoso (4):
>   device core: add device_is_bound()
>   PM / Domains: add setter for dev.pm_domain
>   PM / sleep: Go direct_complete if driver has no callbacks
>   USB / PM: Allow USB devices to remain runtime-suspended when sleeping
> 
>  arch/arm/mach-omap2/omap_device.c |  7 ---
>  drivers/acpi/acpi_lpss.c  |  5 +++--
>  drivers/acpi/device_pm.c  |  5 +++--
>  drivers/base/dd.c | 21 +++--
>  drivers/base/power/clock_ops.c|  5 +++--
>  drivers/base/power/common.c   | 24 
>  drivers/base/power/domain.c   |  6 --
>  drivers/base/power/main.c | 35 +++
>  drivers/base/power/power.h|  3 +++
>  drivers/gpu/vga/vga_switcheroo.c  | 10 +-
>  drivers/misc/mei/pci-me.c |  5 +++--
>  drivers/misc/mei/pci-txe.c|  5 +++--
>  drivers/usb/core/port.c   |  6 ++
>  drivers/usb/core/usb.c| 11 ++-
>  include/linux/device.h|  2 ++
>  include/linux/pm.h|  1 +
>  include/linux/pm_domain.h |  3 +++
>  17 files changed, 131 insertions(+), 23 deletions(-)

The series looks good to me now, but patch [4/4] needs an ACK from the USB
maintainers and patch [1/4] needs an ACK from Greg.

Thanks,
Rafael

--
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: [PATCH 0/7][v4] Add OTG support for FSL socs

[Felipe Balbi]

Ramneek Mehresh  writes:

> Add support for otg for all freescale socs having internal
> usb phy.
>
> Ramneek Mehresh (7):
>   usb:fsl:otg: Make fsl otg driver as tristate
>   usb:fsl:otg: Add controller version based ULPI and UTMI phy
>   usb:fsl:otg: Add support to add/remove usb host driver
>   usb:fsl:otg: Signal host drv when host is otg
>   usb:fsl:otg: Modify otg_event to start host drv
>   usb:fsl:otg: Combine host/gadget start/resume for ID change
>   usb:fsl:otg: Add host-gadget drv sync delay
>
>  drivers/usb/host/ehci-fsl.c   | 73 
> +++
>  drivers/usb/host/ehci-fsl.h   | 16 ++

Alan, how do you want to handle these patches ? Do I get your Acked-by
or do we split everything up ?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2 3/7] usb: dwc3: pci: Add the PCI Product ID for Synopsys USB 3.1

[John Youn]

This adds the PCI product ID for the Synopsys USB 3.1 IP core
(DWC_usb31) on a HAPS-based PCI development platform.

Cc:  # v3.18+
Signed-off-by: John Youn 
---
 drivers/usb/dwc3/dwc3-pci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 4c44a77..e09cb40 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -28,6 +28,7 @@
 
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31 0xabcf
 #define PCI_DEVICE_ID_INTEL_BYT0x0f37
 #define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
 #define PCI_DEVICE_ID_INTEL_BSW0x22B7
@@ -184,6 +185,10 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI),
},
+   {
+   PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
+   PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31),
+   },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
-- 
2.5.0.GIT

--
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 v2 4/7] usb: dwc3: pci: Add platform data for Synopsys HAPS

[John Youn]

Add platform data and set usb3_lpm_capable and has_lpm_erratum.

Cc:  # v3.18+
Signed-off-by: John Youn 
---
 drivers/usb/dwc3/dwc3-pci.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index e09cb40..4479a41 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -108,6 +108,21 @@ static int dwc3_pci_quirks(struct pci_dev *pdev)
}
}
 
+   if (pdev->vendor == PCI_VENDOR_ID_SYNOPSYS &&
+   (pdev->device == PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 ||
+pdev->device == PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI ||
+pdev->device == PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31)) {
+
+   struct dwc3_platform_data pdata;
+
+   memset(, 0, sizeof(pdata));
+   pdata.usb3_lpm_capable = true;
+   pdata.has_lpm_erratum = true;
+
+   return platform_device_add_data(pci_get_drvdata(pdev), ,
+   sizeof(pdata));
+   }
+
return 0;
 }
 
-- 
2.5.0.GIT

--
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 v2 0/7] Various updates for Synopsys platforms

[John Youn]

This patch contains several updates to dwc3 to support Synopsys
platforms.

Patch 1: Initial support for 3.1 IP (applies to all platforms)
Patch 2-4: PCI id and platform data for Synopsys platforms
Patch 5-6: Add a quirk to program a global register
Patch 6: Formatting

Tested on Synopsys HAPS PCI platform mostly mass-storage and CV and
some internal testing.


v2:
* Updated the way the revisions are handled for 3.1
* Split up the dis_enblslpm_quirk patch



John Youn (7):
  usb: dwc3: Support Synopsys USB 3.1 IP
  usb: dwc3: pci: Add the Synopsys HAPS AXI Product ID
  usb: dwc3: pci: Add the PCI Product ID for Synopsys USB 3.1
  usb: dwc3: pci: Add platform data for Synopsys HAPS
  usb: dwc3: Add dis_enblslpm_quirk
  usb: dwc3: pci: Set enblslpm quirk for Synopsys platforms
  usb: dwc3: pci: trivial: Formatting

 Documentation/devicetree/bindings/usb/dwc3.txt |  2 ++
 drivers/usb/dwc3/core.c| 16 +--
 drivers/usb/dwc3/core.h| 22 +++
 drivers/usb/dwc3/dwc3-pci.c| 38 ++
 drivers/usb/dwc3/platform_data.h   |  1 +
 5 files changed, 71 insertions(+), 8 deletions(-)

-- 
2.5.0.GIT

--
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: [PATCH v4] usb: of: add an api to get dr_mode by the phy node

[Felipe Balbi]

Bin Liu  writes:

> Hi Felipe,
>
> On 09/24/2015 03:37 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 23-09-15 22:59, Bin Liu wrote:
>>> Hi,
>>>
>>> On 09/23/2015 02:53 PM, Hans de Goede wrote:
 Hi,

 On 23-09-15 19:10, Bin Liu wrote:
> Hi,
>
> On 09/22/2015 04:18 PM, Felipe Balbi wrote:
>> On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote:
>>> Hi,
>>>
>>> On 09/22/2015 09:40 AM, Felipe Balbi wrote:
 On Mon, Sep 21, 2015 at 10:50:56AM -0500, Bin Liu wrote:
> Some USB phy drivers have different handling for the controller in
> each
> dr_mode. But the phy driver does not have visibility to the
> dr_mode of
> the controller.
>
> This adds an api to return the dr_mode of the controller which
> associates the given phy node.
>
> Signed-off-by: Bin Liu 


 doesn't apply anymore. Probably because of Heikki's series which I
 just
 added to testing/next.

 Please rebase there.

>>> I have to rewrite my patch. Before Heikki's patch
>>> of_usb_get_dr_mode() takes
>>> parameter 'struct *device_node', but now usb_get_dr_mode() takes
>>> parameter
>>> 'struct *device'. The logic in my patch iterates over of nodes, I am
>>> not
>>> sure how to get the 'struct *device' from a of node yet...
>>
>> okay.
>>
> There is no way to get the 'struct *device' to the controller in the
> phy driver, because the controller device might not be registered yet
> by the time the phy probe is called.
>
> So I have to put back the implementation of the removed
> of_usb_get_dr_mode() into this new of_usb_get_dr_mode_by_phy()
> function. Please let me know if this is acceptable then I will send
> the v5.

 Sounds to me like it is better to revert the API change / removal of
 of_usb_get_dr_mode()
 as a separate patch and then stick with your v4 patch.
>>>
>>> +1
>>
>> If you agree, then the best way to do this is probably to send a patch
>> series with the actual revert + your v4 patch. Probably best to call
>> that series v5.
>
> Since Heikki's patch is only in your testing/next branch, do you want to 
> just drop that patch and take my v4 patch, or you want me to send the 
> revert patch?

I'm not sure that's the way we want to go. Heikki's patch is doing a
cleanup which is necessary for the USB layer to be able to use device
properties instead of relying exclusively on DT or PCI. Device
properties is the unification of the two.

Heikki, any comments

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

[Felipe Balbi]

Gregory CLEMENT  writes:

> Hi Felipe,
>  
>  On ven., août 21 2015, Gregory CLEMENT  
> wrote:
>>> According to the OTG specification after a timeout of
>>> OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must
>>> move from the state a_wait_vrise to the state a_wait_bcon. However,
>>> the dsps version of musb does not handle this case.
>>> 
>>> Without it, the driver could remain stuck in the a_wait_vrise. It can
>>> be reproduce with the following steps:
>>> 
>>> 1) Boot a board with no USB adapter inserted
>>> 2) Insert an empty OTG adapter
>>> 3) Wait 2 seconds then remove the OTG adapter
>>> 4) The unit is now stuck in host mode, the VBUS switch is latched on
>>> and the ID pin is no longer polled.
>>> 
>>> The only way to exit this state was to insert a OTG adapter with an
>>> USB device connected. Until this, the usb device mode was not
>>> available.
>>> 
>>> It was tested on a AM35x based board.
>>> 
>>> CC: 
>>> Signed-off-by: Gregory CLEMENT 
>>> ---
>>>  drivers/usb/musb/musb_dsps.c | 14 +-
>>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
>>> index 65d931a..2d22683 100644
>>> --- a/drivers/usb/musb/musb_dsps.c
>>> +++ b/drivers/usb/musb/musb_dsps.c
>>> @@ -145,6 +145,7 @@ struct dsps_glue {
>>> struct timer_list timer;/* otg_workaround timer */
>>> unsigned long last_timer;/* last timer data for each instance */
>>> bool sw_babble_enabled;
>>> +   int otg_state_a_wait_vrise_timeout;
>>>  
>>> struct dsps_context context;
>>> struct debugfs_regset32 regset;
>>> @@ -268,9 +269,18 @@ static void otg_timer(unsigned long _musb)
>>>  
>>> spin_lock_irqsave(>lock, flags);
>>> switch (musb->xceiv->otg->state) {
>>> +   case OTG_STATE_A_WAIT_VRISE:
>>> +   if ((glue->otg_state_a_wait_vrise_timeout)) {
>>> +   musb->xceiv->otg->state = OTG_STATE_A_WAIT_BCON;
>>> +   musb->is_active = 0;
>>> +   }
>>> +   mod_timer(>timer, jiffies +
>>> + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE));
>>
>> After more test on more USB drive, it seems that for some of them
>> OTG_TIME_A_WAIT_VRISE is too short. 200ms seems better. It is
>> disturbing because according to the OTG specification the maximum
>> is 100ms, however I am not so surprised that USB device maker don't
>> follow it.
>
> So after many tests on different devices, 200ms is enough for most of
> them, but for one, 2000ms (2s) was needed!
>
> I see several option:
> - adding a sysfs entry to setup the time
> - adding a debugs entry entry
> - adding configuration option in menuconfig
> - using 2000ms and hopping it was enough for everyone
>
> My preference would go to the first option, what is your opinion?

I'm not sure if either of them is good. man 2s is just too large. If the
device isn't following the specification, I'm afraid that device needs
to be fixed.

I think the real issue here is the lack of a disconnect IRQ from AM335x
devices. But here's something I've been meaning to test but never had
time. If you look into AM335x address space, there's a bit in the
wrapper which tells it to use the standard MUSB registers for IRQ,
instead of the TI-specific thing. Can you see if we get a disconnect IRQ
with that ?

TRM is at [1], see page 2566. Basically, if you set bit 3 in register
offset 0x1014, then it should use Mentor IRQ registers. If that works,
quite a few problems will actually vanish :-p

[1] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4] usb: of: add an api to get dr_mode by the phy node

[Bin Liu]

Hi,

On 10/05/2015 02:54 PM, Felipe Balbi wrote:

Bin Liu  writes:


Hi Felipe,

On 09/24/2015 03:37 AM, Hans de Goede wrote:

Hi,

On 23-09-15 22:59, Bin Liu wrote:

Hi,

On 09/23/2015 02:53 PM, Hans de Goede wrote:

Hi,

On 23-09-15 19:10, Bin Liu wrote:

Hi,

On 09/22/2015 04:18 PM, Felipe Balbi wrote:

On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote:

Hi,

On 09/22/2015 09:40 AM, Felipe Balbi wrote:

On Mon, Sep 21, 2015 at 10:50:56AM -0500, Bin Liu wrote:

Some USB phy drivers have different handling for the controller in
each
dr_mode. But the phy driver does not have visibility to the
dr_mode of
the controller.

This adds an api to return the dr_mode of the controller which
associates the given phy node.

Signed-off-by: Bin Liu 



doesn't apply anymore. Probably because of Heikki's series which I
just
added to testing/next.

Please rebase there.


I have to rewrite my patch. Before Heikki's patch
of_usb_get_dr_mode() takes
parameter 'struct *device_node', but now usb_get_dr_mode() takes
parameter
'struct *device'. The logic in my patch iterates over of nodes, I am
not
sure how to get the 'struct *device' from a of node yet...


okay.


There is no way to get the 'struct *device' to the controller in the
phy driver, because the controller device might not be registered yet
by the time the phy probe is called.

So I have to put back the implementation of the removed
of_usb_get_dr_mode() into this new of_usb_get_dr_mode_by_phy()
function. Please let me know if this is acceptable then I will send
the v5.


Sounds to me like it is better to revert the API change / removal of
of_usb_get_dr_mode()
as a separate patch and then stick with your v4 patch.


+1


If you agree, then the best way to do this is probably to send a patch
series with the actual revert + your v4 patch. Probably best to call
that series v5.


Since Heikki's patch is only in your testing/next branch, do you want to
just drop that patch and take my v4 patch, or you want me to send the
revert patch?


I'm not sure that's the way we want to go. Heikki's patch is doing a
cleanup which is necessary for the USB layer to be able to use device
properties instead of relying exclusively on DT or PCI. Device
properties is the unification of the two.


How about add a new function as follows to convert dr_mode from string 
to enum, then both Keikki's and my function will be shorter by calling it?


static enum usb_dr_mode of_usb_get_dr_mode_from_string(char *string)
{
 for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
 if (!strcmp(string, usb_dr_modes[i]))
 return i;
 return USB_DR_MODE_UNKNOWN;
}

Thanks,
-Bin.



Heikki, any comments


--
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 v2 2/7] usb: dwc3: pci: Add the Synopsys HAPS AXI Product ID

[John Youn]

This ID is for the Synopsys DWC_usb3 core with AXI interface on PCIe
HAPS platform. This core has the debug registers mapped at a separate
BAR in order to support enhanced hibernation.

Cc:  # v3.18+
Signed-off-by: John Youn 
---
 drivers/usb/dwc3/dwc3-pci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 89eb364..4c44a77 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -27,6 +27,7 @@
 #include "platform_data.h"
 
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
 #define PCI_DEVICE_ID_INTEL_BYT0x0f37
 #define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
 #define PCI_DEVICE_ID_INTEL_BSW0x22B7
@@ -179,6 +180,10 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
},
+   {
+   PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
+   PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI),
+   },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
-- 
2.5.0.GIT

--
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 v2 1/7] usb: dwc3: Support Synopsys USB 3.1 IP

[John Youn]

This patch allows the dwc3 driver to run on the new Synopsys USB 3.1
IP core, albeit in USB 3.0 mode only.

The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register
interface and programming model as the existing USB 3.0 controller IP
(DWC_usb3). However the GSNPSID and version numbers are different.

Add checking for the new ID to pass driver probe.

Also, since the DWC_usb31 version number is lower in value than the
full GSNPSID of the DWC_usb3 IP, we set the high bit to identify
DWC_usb31 and to ensure the values are higher.

Finally, add a documentation note about the revision numbering scheme.
Any future revision checks (for STARS, workarounds, and new features)
should take into consideration how it applies to both the 3.1/3.0 IP.

Cc:  # v3.18+
Signed-off-by: John Youn 
---
 drivers/usb/dwc3/core.c | 10 --
 drivers/usb/dwc3/core.h | 18 ++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c72c8c5..1e276d5 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -534,12 +534,18 @@ static int dwc3_core_init(struct dwc3 *dwc)
 
reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
/* This should read as U3 followed by revision number */
-   if ((reg & DWC3_GSNPSID_MASK) != 0x5533) {
+   if ((reg & DWC3_GSNPSID_MASK) == 0x5533) {
+   /* Detected DWC_usb3 IP */
+   dwc->revision = reg;
+   } else if ((reg & DWC3_GSNPSID_MASK) == 0x3331) {
+   /* Detected DWC_usb31 IP */
+   dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
+   dwc->revision |= DWC3_REVISION_IS_DWC31;
+   } else {
dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
ret = -ENODEV;
goto err0;
}
-   dwc->revision = reg;
 
/*
 * Write Linux Version Code to our GUID register so it's easy to figure
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 9188745..0d65be7 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -108,6 +108,9 @@
 #define DWC3_GPRTBIMAP_FS0 0xc188
 #define DWC3_GPRTBIMAP_FS1 0xc18c
 
+#define DWC3_VER_NUMBER0xc1a0
+#define DWC3_VER_TYPE  0xc1a4
+
 #define DWC3_GUSB2PHYCFG(n)(0xc200 + (n * 0x04))
 #define DWC3_GUSB2I2CCTL(n)(0xc240 + (n * 0x04))
 
@@ -771,6 +774,14 @@ struct dwc3 {
u32 num_event_buffers;
u32 u1u2;
u32 maximum_speed;
+
+   /*
+* All 3.1 IP version constants are greater than the 3.0 IP
+* version constants. This works for most version checks in
+* dwc3. However, in the future, this may not apply as
+* features may be developed on newer versions of the 3.0 IP
+* that are not in the 3.1 IP.
+*/
u32 revision;
 
 #define DWC3_REVISION_173A 0x5533173a
@@ -793,6 +804,13 @@ struct dwc3 {
 #define DWC3_REVISION_270A 0x5533270a
 #define DWC3_REVISION_280A 0x5533280a
 
+/*
+ * NOTICE: we're using bit 31 as a "is usb 3.1" flag. This is really
+ * just so dwc31 revisions are always larger than dwc3.
+ */
+#define DWC3_REVISION_IS_DWC31 0x8000
+#define DWC3_USB31_REVISION_110A   (0x3131302a | DWC3_REVISION_IS_USB31)
+
enum dwc3_ep0_next  ep0_next_event;
enum dwc3_ep0_state ep0state;
enum dwc3_link_statelink_state;
-- 
2.5.0.GIT

--
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 v2 5/7] usb: dwc3: Add dis_enblslpm_quirk

[John Youn]

Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls
whether the PHY receives the suspend signal from the controller.

Cc:  # v3.18+
Signed-off-by: John Youn 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
 drivers/usb/dwc3/core.c| 6 ++
 drivers/usb/dwc3/core.h| 4 
 drivers/usb/dwc3/platform_data.h   | 1 +
 4 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 8c7d585..9ff48e0 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -35,6 +35,8 @@ Optional properties:
LTSSM during USB3 Compliance mode.
  - snps,dis_u3_susphy_quirk: when set core will disable USB3 suspend phy.
  - snps,dis_u2_susphy_quirk: when set core will disable USB2 suspend phy.
+ - snps,dis_enblslpm_quirk: when set clears the enblslpm in GUSB2PHYCFG,
+   disabling the suspend signal to the PHY.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 1e276d5..22b47973 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -515,6 +515,9 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_u2_susphy_quirk)
reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
 
+   if (dwc->dis_enblslpm_quirk)
+   reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
 
return 0;
@@ -912,6 +915,8 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,dis_u3_susphy_quirk");
dwc->dis_u2_susphy_quirk = device_property_read_bool(dev,
"snps,dis_u2_susphy_quirk");
+   dwc->dis_enblslpm_quirk = device_property_read_bool(dev,
+   "snps,dis_enblslpm_quirk");
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
@@ -945,6 +950,7 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->rx_detect_poll_quirk = pdata->rx_detect_poll_quirk;
dwc->dis_u3_susphy_quirk = pdata->dis_u3_susphy_quirk;
dwc->dis_u2_susphy_quirk = pdata->dis_u2_susphy_quirk;
+   dwc->dis_enblslpm_quirk = pdata->dis_enblslpm_quirk;
 
dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
if (pdata->tx_de_emphasis)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0d65be7..36f1cb7 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -179,6 +179,7 @@
 #define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
 #define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
 #define DWC3_GUSB2PHYCFG_ULPI_UTMI (1 << 4)
+#define DWC3_GUSB2PHYCFG_ENBLSLPM  (1 << 8)
 
 /* Global USB2 PHY Vendor Control Register */
 #define DWC3_GUSB2PHYACC_NEWREGREQ (1 << 25)
@@ -720,6 +721,8 @@ struct dwc3_scratchpad_array {
  * @rx_detect_poll_quirk: set if we enable rx_detect to polling lfps quirk
  * @dis_u3_susphy_quirk: set if we disable usb3 suspend phy
  * @dis_u2_susphy_quirk: set if we disable usb2 suspend phy
+ * @dis_enblslpm_quirk: set if we clear enblslpm in GUSB2PHYCFG,
+ *  disabling the suspend signal to the PHY.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -864,6 +867,7 @@ struct dwc3 {
unsignedrx_detect_poll_quirk:1;
unsigneddis_u3_susphy_quirk:1;
unsigneddis_u2_susphy_quirk:1;
+   unsigneddis_enblslpm_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index 400b197..2bb4d3a 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -42,6 +42,7 @@ struct dwc3_platform_data {
unsigned rx_detect_poll_quirk:1;
unsigned dis_u3_susphy_quirk:1;
unsigned dis_u2_susphy_quirk:1;
+   unsigned dis_enblslpm_quirk:1;
 
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
-- 
2.5.0.GIT

--
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: [PATCH 0/7][v4] Add OTG support for FSL socs

[Alan Stern]

On Mon, 5 Oct 2015, Felipe Balbi wrote:

> Ramneek Mehresh  writes:
> 
> > Add support for otg for all freescale socs having internal
> > usb phy.
> >
> > Ramneek Mehresh (7):
> >   usb:fsl:otg: Make fsl otg driver as tristate
> >   usb:fsl:otg: Add controller version based ULPI and UTMI phy
> >   usb:fsl:otg: Add support to add/remove usb host driver
> >   usb:fsl:otg: Signal host drv when host is otg
> >   usb:fsl:otg: Modify otg_event to start host drv
> >   usb:fsl:otg: Combine host/gadget start/resume for ID change
> >   usb:fsl:otg: Add host-gadget drv sync delay
> >
> >  drivers/usb/host/ehci-fsl.c   | 73 
> > +++
> >  drivers/usb/host/ehci-fsl.h   | 16 ++
> 
> Alan, how do you want to handle these patches ? Do I get your Acked-by
> or do we split everything up ?

I'll send an Acked-by after looking carefully at the parts that affect 
ehci-fsl.

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: [PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property

[RAJESH BHAGAT]

Hi Shawn,

Regarding below patch, Felipe has suggested to talk to you:

> [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116

talk to you ARM-SoC maintainer.

https://lkml.org/lkml/2015/9/4/7

Please provide your comments. Inform me in case, if a resend is required.

Best Regards,
Rajesh Bhagat

-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com] 
Sent: Saturday, October 03, 2015 1:29 AM
To: Bhagat Rajesh-B56421
Cc: ba...@ti.com; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org; 
linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/3][v4] Documentation: dt: dwc3: Add 
snps,quirk-frame-length-adjustment property

On Thu, Sep 24, 2015 at 09:42:59AM +, RAJESH BHAGAT wrote:
> Hi Felipe, 
> 
> Any comments on the below [v4] patches?
> 
> [PATCH 1/3][v4] Documentation: dt: dwc3: Add 
> snps,quirk-frame-length-adjustment property

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next=3737c54418c35034127bf2837e9b27a3c3c67940

> [PATCH 2/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next=db2be4e9e30c6e43e48c5749d3fc74cee0a6bbb3

> [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116

talk to you ARM-SoC maintainer.

> I will be taking forward these patches, as Nikhil has left freescale.

okay, thanks for letting me know.

-- 
balbi
--
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: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16

[Vaishali Thakkar]

On Tue, Oct 6, 2015 at 4:59 AM, Felipe Balbi  wrote:
> Vaishali Thakkar  writes:
>
>> On Mon, Aug 24, 2015 at 2:29 PM, David Laight  
>> wrote:
>>> From: Vaishali Thakkar [mailto:vthakkar1...@gmail.com]
 Sent: 22 August 2015 02:57
>>> ...
 >> - .bcdADC =   __constant_cpu_to_le16(0x0100),
 >> - .wTotalLength = 
 >> __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH),
 >> + .bcdADC =   cpu_to_le16(0x0100),
 >> + .wTotalLength = cpu_to_le16(UAC_DT_TOTAL_LENGTH),
 >
 > Have you test compiled this on a big-endian system?
 > My gut feeling is that is fails.

 No. I have tested it on little-endian system only. But I'll
 be really surprised if this will fail. Can you please tell me
 if I am missing something in this particular case or same
 applies for other cases because most of the cases like
 __constant_ are already converted to ?

 As far as I know, if the argument is a constant the
 conversion happens at compile time. And unfolding both
 definitions returns to same expression. Still I am trying if
 someone can test it for me on big endian system.
>>>
>>> Flip one to cpu_to_be16() and see if it still compiles.
>>
>> Yes. It still compiles.
>
> it's unclear to me if this is really safe to apply. Until then I'm
> dropping this from queue. Seems like, at a minimum, we need a better
> commit log

I compared both .s files [before the change and after the change] and
I don't see any difference between instructions in them. I am not sure
but it looks like if expression contains 'a ? t : f' then either 't'
OR 'f' should
be constant not both.

Also, the code still complies on little endian machines after changing
cpu_to_be16(). And on top of that fact is there are many patches
applied in the kernel from years for the same and very less are remaining.
In case, this fails then I think we need to change those cases as well. But
I have never seen people reporting a bug for the same and changing
 to __constant_ again.

Still I think probably it would be good if someone can test this patch on big
endian machine [just to be sure about the change].

> --
> balbi



-- 
Vaishali
--
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: iperf UDP packet loss with Chipidea HDRC

[Fabio Estevam]

On Mon, Oct 5, 2015 at 10:57 AM, Jayan John  wrote:
> We are developing a custom USB device on a iMX6q platform with a Chipidea
> HDRC. The device uses a single NCM interface for communication with another
> OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP performance
> after role reversal with iperf server running on gadget.
>
> Kernel: 3.10.17 using Wandboard config

Could you test this using kernel 4.2.3 or 4.3-rc4?
--
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: [PATCH 0/7][v4] Add OTG support for FSL socs

[Fabio Estevam]

On Thu, Aug 27, 2015 at 1:43 PM, Ramneek Mehresh
 wrote:
> Add support for otg for all freescale socs having internal
> usb phy.
>
> Ramneek Mehresh (7):
>   usb:fsl:otg: Make fsl otg driver as tristate
>   usb:fsl:otg: Add controller version based ULPI and UTMI phy
>   usb:fsl:otg: Add support to add/remove usb host driver
>   usb:fsl:otg: Signal host drv when host is otg
>   usb:fsl:otg: Modify otg_event to start host drv
>   usb:fsl:otg: Combine host/gadget start/resume for ID change
>   usb:fsl:otg: Add host-gadget drv sync delay
>
>  drivers/usb/host/ehci-fsl.c   | 73 
> +++
>  drivers/usb/host/ehci-fsl.h   | 16 ++
>  drivers/usb/phy/Kconfig   |  2 +-
>  drivers/usb/phy/phy-fsl-usb.c | 58 +-
>  drivers/usb/phy/phy-fsl-usb.h |  7 +
>  include/linux/usb.h   |  1 +
>  6 files changed, 122 insertions(+), 35 deletions(-)

Isn't this all Chipidea IP? If so, why don't you use the existing
chipidea driver instead?
--
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: mass storage behaviour

[Alan Stern]

On Mon, 5 Oct 2015, Paul Jones wrote:

> > Increasing the max_sectors_kb value, on the other hand, might remove
> > overhead by allowing a higher percentage of the transfer to consist of
> > real data as opposed to CBW and CSW packets.  This depends to some
> > extent on other factors (such as whether the memory pages are
> > contiguous, allowing for larger transfers), but it can't hurt.
> 
> I tried changing the max_sectors_kb to 64 with 64k block size in dd and it’s 
> transferring at the same speed.

That's a decrease, not an increase.  Try changing it to 1024 or more.

> I verified using usbmon and it then indeed requests 64k in each request.
> Increasing the dd block size to 240k doesn’t change the transfer speed 
> either, and it keeps using alternating 120k/8k requests.
> Increasing the dd block size to 1M doesn’t change the transfer speed either, 
> although I get sequences of 2x 120k followed by 1x 16k requests.

The dd block size makes no difference at all, because the kernel 
aggregates the requests from dd.

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: [PATCH] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

[Nathan Sullivan]

On Mon, Oct 05, 2015 at 02:33:56PM -0500, Felipe Balbi wrote:
> 
> IIRC we had this dependency because OTG needs support USB bus suspend
> and afaict, that's only available on PM builds
> 
> -- 
> balbi

Hmm, our use case is separate device and host controllers on a Bay Trail
system.  We don't ever need to suspend the bus, since the roles are fixed.
Also, the system is running RT tasks and we don't want PM on.

Maybe the device-side USB option should be separate from the OTG option?  We
really don't want HNP or any of the dual-role features, just support for
gadget drivers and USB device controllers.
--
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: mass storage behaviour

[Alan Stern]

On Mon, 5 Oct 2015, Paul Jones wrote:

> >> Any ideas why the driver is requesting varying block sizes?
> > 
> > The usb-storage driver requests what the block layer tells it to
> > request.
> I’m running a dd with a block size of 64k, so it seems to be
> aggregating 2 requests and then splits them again.

More or less.  The kernel aggregates requests from dd, and then splits 
them up based on the max_sector value and other requirements.


> Note that both machines in question are not doing anything else.
> Both machine have a core i5 4690s (quad core 3.2Ghz) with 16GB of RAM, so I 
> am not sure why there is a 35us delay...

That's probably just the time needed by the USB hardware plus the
overhead involved in interrupt handling.  It's negligible in
comparison to the time spent in the actual data transfers, anyway.

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: [PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Ulf Hansson]

On 5 October 2015 at 16:45, Tomeu Vizoso  wrote:
> Hi,
>
> this is v9 of an attempt to make it easier for devices to remain in
> runtime PM when the system goes to sleep, mainly to reduce the time
> spent resuming devices.
>
> For this, we interpret the absence of all PM callback implementations as
> it being safe to do direct_complete, so their ancestors aren't prevented
> from remaining runtime-suspended.
>
> Additionally, the prepare() callback of USB devices will return 1 if
> runtime PM is enabled and the current wakeup settings are correct.
>
> With these changes, a uvcvideo device (for example) stays in runtime
> suspend when the system goes to sleep and is left in that state when the
> system resumes, not delaying it unnecessarily.
>
> Thanks,
>
> Tomeu
>
> Changes in v9:
> - Add docs noting the need for the device lock to be held before calling
>   device_is_bound()
> - Add docs noting the need for the device lock to be held before calling
>   dev_pm_domain_set()
> - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
> - Rename from device_check_pm_callbacks to device_pm_check_callbacks to
>   follow with the naming convention of existing API.
> - Re-add calling to device_pm_check_callbacks from device registration
>   and when updating the PM domain of a device.
>
> Changes in v8:
> - Add device_is_bound()
> - Add dev_pm_domain_set() and update code to use it
> - Move no_pm_callbacks field into CONFIG_PM_SLEEP
> - Call device_check_pm_callbacks only after a device is bound or unbound
>
> Changes in v7:
> - Reduce indentation by adding a label in device_prepare()
>
> Changes in v6:
> - Add stub for !CONFIG_PM.
> - Move implementation of device_check_pm_callbacks to power/main.c as it
>   doesn't belong to CONFIG_PM_SLEEP.
> - Take dev->power.lock before modifying flag.
>
> Changes in v5:
> - Check for all dev_pm_ops instances associated to a device, updating a
>   no_pm_callbacks flag at the times when that could change.
>
> Tomeu Vizoso (4):
>   device core: add device_is_bound()
>   PM / Domains: add setter for dev.pm_domain
>   PM / sleep: Go direct_complete if driver has no callbacks
>   USB / PM: Allow USB devices to remain runtime-suspended when sleeping
>
>  arch/arm/mach-omap2/omap_device.c |  7 ---
>  drivers/acpi/acpi_lpss.c  |  5 +++--
>  drivers/acpi/device_pm.c  |  5 +++--
>  drivers/base/dd.c | 21 +++--
>  drivers/base/power/clock_ops.c|  5 +++--
>  drivers/base/power/common.c   | 24 
>  drivers/base/power/domain.c   |  6 --
>  drivers/base/power/main.c | 35 +++
>  drivers/base/power/power.h|  3 +++
>  drivers/gpu/vga/vga_switcheroo.c  | 10 +-
>  drivers/misc/mei/pci-me.c |  5 +++--
>  drivers/misc/mei/pci-txe.c|  5 +++--
>  drivers/usb/core/port.c   |  6 ++
>  drivers/usb/core/usb.c| 11 ++-
>  include/linux/device.h|  2 ++
>  include/linux/pm.h|  1 +
>  include/linux/pm_domain.h |  3 +++
>  17 files changed, 131 insertions(+), 23 deletions(-)
>
> --
> 2.4.3
>

This looks good to me, for the series you may add:

Reviewed-by: Ulf Hansson 

Kind regards
Uffe
--
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: simplify configfs attributes V2

[Andrew Morton]

On Sat,  3 Oct 2015 15:32:36 +0200 Christoph Hellwig  wrote:

> This series consolidates the code to implement configfs attributes
> by providing the ->show and ->store method in common code and using
> container_of in the methods to access the containing structure.
> 
> This reduces source and binary size of configfs consumers a lot.

There's a version of this patch series (I assume V1) in linux-next via
Nicholas's tree so my hands are tied.  I trust that Nicholas will
update things.

Or maybe it was a slipup - modifying usb, ocfs2 etc from the iscsi tree
is innovative ;)

--
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: [PATCH v2] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()

[John Youn]

On 10/1/2015 1:50 PM, Doug Anderson wrote:
> John,
> 
> On Tue, Aug 18, 2015 at 5:19 PM, John Youn  wrote:
>> Hi Yunzhi,
>>
>> My concern is with the delays due to calling the dwc2_core_reset
>> during probe. You could factor out the assertion of the core
>> soft reset from the dwc2_core_reset and just use that before
>> calling dwc2_get_hwparams().
>>
>> You had previously addressed the lengthy probe time issue here:
>> http://marc.info/?l=linux-usb=142357721304377
>>
>> This reducing delays patch looks reasonable to me and I think it
>> should get merged also. I'll do some testing with it later this
>> week.
> 
> Note: you can also avoid the extra reset during probe with something
> like .  I'm
> happy to post that up if you want, though it depends on lyz's patch.
> 
> ...in Chrome OS we've also just landed lyz's patch to reduce delays.
> If there's any fallout I'll report on the list.
> 
> -Doug
> 


Yes, I appreciate if you could submit that. I'd like to merge lyz's
reduce delays, lyz's bug fix for hwparams, and your fix for double
reset.

The gadget side will also need something similar which I can do if
needed. Do you guys run gadget mode?

Regards,
John

--
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

Aw: Re: Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects

[Eugen Rogoza]

> > Observations:
> > 
> > - independent of activity/workload
> 
> Are you sure about that?  In your Intel pcap file, the problem occurred 
> only after long periods of inactivity: 40 seconds the first time, 150 
> seconds the second time.

Yes, because it can disconnect any time. Last time it managed to disconnect 
during a file transfer. And also tonight I managed to capture a disconnect 
while just browsing a directory structure on the HDD (see below).

> The only way to turn off Link Power Management currently is to disable
> CONFIG_PM entirely.

I recompiled the 4.2.0 having disabled CONFIG_PM:

# CONFIG_PM is not set

This time there were no observable disconnects after just plugging in the 
device and not doing anything else (like mounting). However, a disconnect 
happened much later while browsing the directory structure on a mounted FS of 
the HDD. Surprisingly, the disconnects do not strictly correlate with the load: 
some heavy copying and seeking back and forth in a HD movie worked just fine. 
Therefore I think the disconnect would have happened on an idle connection as 
well.

Below is a fresh trace. The reason for the disconnect is URB_INTERRUPT again 
(triggered in packet #2473):

http://wikisend.com/download/150664/usb3_intel2.pcapng.gz


Cheers,

Eugen
--
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: iperf UDP packet loss with Chipidea HDRC

[Jayan John]

On Tue, Oct 6, 2015 at 3:38 AM, Fabio Estevam  wrote:
> On Mon, Oct 5, 2015 at 10:57 AM, Jayan John  wrote:
>> We are developing a custom USB device on a iMX6q platform with a Chipidea
>> HDRC. The device uses a single NCM interface for communication with another
>> OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP performance
>> after role reversal with iperf server running on gadget.
>>
>> Kernel: 3.10.17 using Wandboard config
>
> Could you test this using kernel 4.2.3 or 4.3-rc4?
Thanks. Moving to 4.2.3 or 4.3 would be a rather large exercise as a number of
drivers would need changes and significant testing efforts as well.This maybe
planned at a later point if there is a real need identified.
--
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: mass storage behaviour

[Paul Jones]

On 05 Oct 2015, at 20:54, Alan Stern  wrote:

> On Mon, 5 Oct 2015, Paul Jones wrote:
> 
>>> g_mass_storage, by default, uses 2 struct usb_request, try increasing that 
>>> to 4
>>> (can be done from make menuconfig itself) and see if anything changes.
>> If you are talking about the �number of storage pipeline buffers� I already 
>> have them at 4.
>> I had similar results in previous kernels where I hadn�t set this value to 4.
> 
> My feeling is that the number of buffers won't make a whole lot of 
> difference to the final throughput.  Increasing the number will smooth 
> out variations and remove latencies caused by other tasks.  But the two 
> fundamental limits on the throughput are the USB data transfer rate and 
> the rate at which data can be transferred to/from the backing storage.  
> Whichever is slower will be the bottleneck, and using more buffers 
> won't change that.
> 
> Increasing the max_sectors_kb value, on the other hand, might remove
> overhead by allowing a higher percentage of the transfer to consist of
> real data as opposed to CBW and CSW packets.  This depends to some
> extent on other factors (such as whether the memory pages are
> contiguous, allowing for larger transfers), but it can't hurt.

I tried changing the max_sectors_kb to 64 with 64k block size in dd and it’s 
transferring at the same speed.
I verified using usbmon and it then indeed requests 64k in each request.
Increasing the dd block size to 240k doesn’t change the transfer speed either, 
and it keeps using alternating 120k/8k requests.
Increasing the dd block size to 1M doesn’t change the transfer speed either, 
although I get sequences of 2x 120k followed by 1x 16k requests.

Paul.


--
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 v2 6/7] usb: dwc3: pci: Set enblslpm quirk for Synopsys platforms

[John Youn]

Certain Synopsys prototyping PHY boards are not able to meet timings
constraints for LPM. This allows the PHY to meet those timings by
leaving the PHY clock running during suspend.

Cc:  # v3.18+
Signed-off-by: John Youn 
---
 drivers/usb/dwc3/dwc3-pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 4479a41..b34bd79 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -118,6 +118,7 @@ static int dwc3_pci_quirks(struct pci_dev *pdev)
memset(, 0, sizeof(pdata));
pdata.usb3_lpm_capable = true;
pdata.has_lpm_erratum = true;
+   pdata.dis_enblslpm_quirk = true;
 
return platform_device_add_data(pci_get_drvdata(pdev), ,
sizeof(pdata));
-- 
2.5.0.GIT

--
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 v2 7/7] usb: dwc3: pci: trivial: Formatting

[John Youn]

Fix the alignment of the PCI device definitions. Also change the hex
digit capitalization of one constant to make it consistent with the
rest of the file and driver.

Signed-off-by: John Youn 
---
 drivers/usb/dwc3/dwc3-pci.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index b34bd79..77a622c 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -26,14 +26,14 @@
 
 #include "platform_data.h"
 
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31 0xabcf
-#define PCI_DEVICE_ID_INTEL_BYT0x0f37
-#define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
-#define PCI_DEVICE_ID_INTEL_BSW0x22B7
-#define PCI_DEVICE_ID_INTEL_SPTLP  0x9d30
-#define PCI_DEVICE_ID_INTEL_SPTH   0xa130
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI0xabce
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB31   0xabcf
+#define PCI_DEVICE_ID_INTEL_BYT0x0f37
+#define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
+#define PCI_DEVICE_ID_INTEL_BSW0x22b7
+#define PCI_DEVICE_ID_INTEL_SPTLP  0x9d30
+#define PCI_DEVICE_ID_INTEL_SPTH   0xa130
 
 static const struct acpi_gpio_params reset_gpios = { 0, 0, false };
 static const struct acpi_gpio_params cs_gpios = { 1, 0, false };
-- 
2.5.0.GIT

--
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: [PATCH 1/4] usb: host: xhci-rcar: add xhci_rcar_is_compatible() function

[Geert Uytterhoeven]

Hi Shimoda-san,

On Mon, Oct 5, 2015 at 2:06 PM, Yoshihiro Shimoda
 wrote:
> +bool xhci_rcar_is_compatible(struct usb_hcd *hcd)
> +{
> +   struct device_node *of_node = hcd->self.controller->of_node;
> +
> +   if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
> +   of_device_is_compatible(of_node, "renesas,xhci-r8a7791"))
> +   return true;

If you want to match against multiple compatible values, you may be better
off with of_match_node().
This may also simplify the code to match specific firmware paths to the
various compatible entries.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [PATCH v4 4/4] usb: dwc2: refactor common low-level hw code to platform.c

[John Youn]

On 10/2/2015 12:45 AM, Marek Szyprowski wrote:
> DWC2 module on some platforms needs three additional hardware
> resources: phy controller, clock and power supply. All of them must be
> enabled/activated to properly initialize and operate. This was initially
> handled in s3c-hsotg driver, which has been converted to 'gadget' part
> of dwc2 driver. Unfortunately, not all of this code got moved to common
> platform code, what resulted in accessing DWC2 registers without
> enabling low-level hardware resources. This fails for example on Exynos
> SoCs. This patch moves all the code for managing those resources to
> common platform.c file and provides convenient wrappers for controlling
> them.
> 
> Signed-off-by: Marek Szyprowski 
> ---
> Changelog:
> v4:
> - fixed broken conditional compilation and adjusted comments in dwc2_hsotg
>   structure documentation
> 
> v3:
> - rebased onto latest 'testing/next' from Felipe Balbi (includes
>   s3c_hsotg -> dwc2 rename)
> 
> v2:
> - moved setting of ll_hw_enabled flag to enable/disable functions,
>   as suggested by John Youn
> - moved setting of phy width to dwc2_lowlevel_init function
> ---
>  drivers/usb/dwc2/core.h |  24 +++--
>  drivers/usb/dwc2/gadget.c   | 193 
>  drivers/usb/dwc2/platform.c | 234 
> +---
>  3 files changed, 228 insertions(+), 223 deletions(-)
> 

Hi Marek,

I still see lockdep warnings.

Any ideas about these?


[ 1618.179611] ==
[ 1618.179612] [ INFO: possible circular locking dependency detected ]
[ 1618.179613] 4.3.0-rc3-snps-00125-g744fd93 #28 Not tainted
[ 1618.179614] ---
[ 1618.179615] modprobe/2658 is trying to acquire lock:
[ 1618.179616]  (>init_mutex){+.+.+.}, at: [] 
dwc2_hsotg_udc_start+0x5c/0x200 [dwc2]
[ 1618.179622] 
[ 1618.179622] but task is already holding lock:
[ 1618.179623]  (udc_lock){+.+.+.}, at: [] 
usb_gadget_probe_driver+0x3a/0xd0 [udc_core]
[ 1618.179627] 
[ 1618.179627] which lock already depends on the new lock.
[ 1618.179627] 
[ 1618.179628] 
[ 1618.179628] the existing dependency chain (in reverse order) is:
[ 1618.179629] 
[ 1618.179629] -> #1 (udc_lock){+.+.+.}:
[ 1618.179631][] lock_acquire+0xdd/0x1f0
[ 1618.179635][] mutex_lock_nested+0x76/0x3e0
[ 1618.179638][] 
usb_add_gadget_udc_release+0x187/0x240 [udc_core]
[ 1618.179640][] usb_add_gadget_udc+0x10/0x20 
[udc_core]
[ 1618.179642][] dwc2_gadget_init+0x47c/0x580 [dwc2]
[ 1618.179645][] dwc2_driver_probe+0x422/0x4b0 [dwc2]
[ 1618.179648][] platform_drv_probe+0x34/0x90
[ 1618.179650][] driver_probe_device+0x224/0x480
[ 1618.179652][] __device_attach_driver+0x71/0xa0
[ 1618.179654][] bus_for_each_drv+0x5d/0x90
[ 1618.179655][] __device_attach+0xbf/0x140
[ 1618.179657][] device_initial_probe+0x13/0x20
[ 1618.179658][] bus_probe_device+0xa3/0xb0
[ 1618.179660][] device_add+0x40d/0x690
[ 1618.179661][] platform_device_add+0x111/0x270
[ 1618.179663][] dwc2_pci_probe+0xe8/0x1d2 [dwc2_pci]
[ 1618.179665][] local_pci_probe+0x45/0xa0
[ 1618.179668][] pci_device_probe+0xe1/0x130
[ 1618.179669][] driver_probe_device+0x224/0x480
[ 1618.179671][] __driver_attach+0x88/0x90
[ 1618.179672][] bus_for_each_dev+0x66/0xa0
[ 1618.179674][] driver_attach+0x1e/0x20
[ 1618.179675][] bus_add_driver+0x1ee/0x280
[ 1618.179677][] driver_register+0x60/0xe0
[ 1618.179678][] __pci_register_driver+0x60/0x70
[ 1618.179680][] 0xc000601e
[ 1618.179681][] do_one_initcall+0xb3/0x200
[ 1618.179684][] do_init_module+0x5f/0x1e7
[ 1618.179687][] load_module+0x21a8/0x2840
[ 1618.179689][] SyS_finit_module+0x9a/0xc0
[ 1618.179691][] entry_SYSCALL_64_fastpath+0x16/0x7a
[ 1618.179693] 
[ 1618.179693] -> #0 (>init_mutex){+.+.+.}:
[ 1618.179695][] __lock_acquire+0x1d35/0x1db0
[ 1618.179697][] lock_acquire+0xdd/0x1f0
[ 1618.179698][] mutex_lock_nested+0x76/0x3e0
[ 1618.179700][] dwc2_hsotg_udc_start+0x5c/0x200 
[dwc2]
[ 1618.179703][] udc_bind_to_driver+0xa4/0x100 
[udc_core]
[ 1618.179705][] usb_gadget_probe_driver+0x7a/0xd0 
[udc_core]
[ 1618.179707][] usb_composite_probe+0xa4/0xc0 
[libcomposite]
[ 1618.179709][] msg_init+0x10/0x1000 [g_mass_storage]
[ 1618.179711][] do_one_initcall+0xb3/0x200
[ 1618.179713][] do_init_module+0x5f/0x1e7
[ 1618.179714][] load_module+0x21a8/0x2840
[ 1618.179716][] SyS_finit_module+0x9a/0xc0
[ 1618.179717][] entry_SYSCALL_64_fastpath+0x16/0x7a
[ 1618.179719] 
[ 1618.179719] other info that might help us debug this:
[ 1618.179719] 
[ 1618.179720]  Possible unsafe locking scenario:
[ 1618.179720] 
[ 1618.179721]

Re: mass storage behaviour

[Paul Zimmerman]

On Mon, 5 Oct 2015, Alan Stern wrote:
> On Mon, 5 Oct 2015, Paul Jones wrote:
>
>>> Increasing the max_sectors_kb value, on the other hand, might remove
>>> overhead by allowing a higher percentage of the transfer to consist of
>>> real data as opposed to CBW and CSW packets.  This depends to some
>>> extent on other factors (such as whether the memory pages are
>>> contiguous, allowing for larger transfers), but it can't hurt.
>>
>> I tried changing the max_sectors_kb to 64 with 64k block size in dd and it’s 
>> transferring at the same \
> speed.
>
> That's a decrease, not an increase.  Try changing it to 1024 or more.
>
>> I verified using usbmon and it then indeed requests 64k in each request.
>> Increasing the dd block size to 240k doesn’t change the transfer speed 
>> either, and it keeps using \
>> alternating 120k/8k requests. Increasing the dd block size to 1M doesn’t 
>> change the transfer speed \
>> either, although I get sequences of 2x 120k followed by 1x 16k requests.
>
> The dd block size makes no difference at all, because the kernel
> aggregates the requests from dd.

In my experience, you need to do at least the following to get max
performance from the mass storage gadget:

- Use Windows 8 or higher on the host. It's much faster than Linux.
- Put the backing file for the mass storage gadget on a tmpfs.
- Increase FSG_BUFLEN (in
drivers/usb/gadget/function/storage_common.h) to at least 128K.

-- 
Paul
--
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: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16

[Felipe Balbi]

Vaishali Thakkar  writes:

> On Mon, Aug 24, 2015 at 2:29 PM, David Laight  wrote:
>> From: Vaishali Thakkar [mailto:vthakkar1...@gmail.com]
>>> Sent: 22 August 2015 02:57
>> ...
>>> >> - .bcdADC =   __constant_cpu_to_le16(0x0100),
>>> >> - .wTotalLength = 
>>> >> __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH),
>>> >> + .bcdADC =   cpu_to_le16(0x0100),
>>> >> + .wTotalLength = cpu_to_le16(UAC_DT_TOTAL_LENGTH),
>>> >
>>> > Have you test compiled this on a big-endian system?
>>> > My gut feeling is that is fails.
>>>
>>> No. I have tested it on little-endian system only. But I'll
>>> be really surprised if this will fail. Can you please tell me
>>> if I am missing something in this particular case or same
>>> applies for other cases because most of the cases like
>>> __constant_ are already converted to ?
>>>
>>> As far as I know, if the argument is a constant the
>>> conversion happens at compile time. And unfolding both
>>> definitions returns to same expression. Still I am trying if
>>> someone can test it for me on big endian system.
>>
>> Flip one to cpu_to_be16() and see if it still compiles.
>
> Yes. It still compiles.

it's unclear to me if this is really safe to apply. Until then I'm
dropping this from queue. Seems like, at a minimum, we need a better
commit log

-- 
balbi


signature.asc
Description: PGP signature

Re: mass storage behaviour

[John Youn]

Hi Paul,

Good to see you're still hanging around.

On 10/5/2015 3:38 PM, Paul Zimmerman wrote:
> On Mon, 5 Oct 2015, Alan Stern wrote:
>> On Mon, 5 Oct 2015, Paul Jones wrote:
>>
 Increasing the max_sectors_kb value, on the other hand, might remove
 overhead by allowing a higher percentage of the transfer to consist of
 real data as opposed to CBW and CSW packets.  This depends to some
 extent on other factors (such as whether the memory pages are
 contiguous, allowing for larger transfers), but it can't hurt.
>>>
>>> I tried changing the max_sectors_kb to 64 with 64k block size in dd and 
>>> it’s transferring at the same \
>> speed.
>>
>> That's a decrease, not an increase.  Try changing it to 1024 or more.
>>
>>> I verified using usbmon and it then indeed requests 64k in each request.
>>> Increasing the dd block size to 240k doesn’t change the transfer speed 
>>> either, and it keeps using \
>>> alternating 120k/8k requests. Increasing the dd block size to 1M doesn’t 
>>> change the transfer speed \
>>> either, although I get sequences of 2x 120k followed by 1x 16k requests.
>>
>> The dd block size makes no difference at all, because the kernel
>> aggregates the requests from dd.
> 
> In my experience, you need to do at least the following to get max
> performance from the mass storage gadget:
> 
> - Use Windows 8 or higher on the host. It's much faster than Linux.
> - Put the backing file for the mass storage gadget on a tmpfs.
> - Increase FSG_BUFLEN (in

Speaking of which...

I found this old patch to set the FSG_BUFLEN. Any idea why it never
got merged?

http://marc.info/?l=linux-usb=138722294117498=2

Regards,
John


--
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: [PATCH v4 4/4] usb: dwc2: refactor common low-level hw code to platform.c

[Felipe Balbi]

John Youn  writes:

Hi,

> On 10/2/2015 12:45 AM, Marek Szyprowski wrote:
>> DWC2 module on some platforms needs three additional hardware
>> resources: phy controller, clock and power supply. All of them must be
>> enabled/activated to properly initialize and operate. This was initially
>> handled in s3c-hsotg driver, which has been converted to 'gadget' part
>> of dwc2 driver. Unfortunately, not all of this code got moved to common
>> platform code, what resulted in accessing DWC2 registers without
>> enabling low-level hardware resources. This fails for example on Exynos
>> SoCs. This patch moves all the code for managing those resources to
>> common platform.c file and provides convenient wrappers for controlling
>> them.
>> 
>> Signed-off-by: Marek Szyprowski 
>> ---
>> Changelog:
>> v4:
>> - fixed broken conditional compilation and adjusted comments in dwc2_hsotg
>>   structure documentation
>> 
>> v3:
>> - rebased onto latest 'testing/next' from Felipe Balbi (includes
>>   s3c_hsotg -> dwc2 rename)
>> 
>> v2:
>> - moved setting of ll_hw_enabled flag to enable/disable functions,
>>   as suggested by John Youn
>> - moved setting of phy width to dwc2_lowlevel_init function
>> ---
>>  drivers/usb/dwc2/core.h |  24 +++--
>>  drivers/usb/dwc2/gadget.c   | 193 
>>  drivers/usb/dwc2/platform.c | 234 
>> +---
>>  3 files changed, 228 insertions(+), 223 deletions(-)
>> 
>
> Hi Marek,
>
> I still see lockdep warnings.
>
> Any ideas about these?
>
>
> [ 1618.179611] ==
> [ 1618.179612] [ INFO: possible circular locking dependency detected ]
> [ 1618.179613] 4.3.0-rc3-snps-00125-g744fd93 #28 Not tainted
> [ 1618.179614] ---
> [ 1618.179615] modprobe/2658 is trying to acquire lock:
> [ 1618.179616]  (>init_mutex){+.+.+.}, at: [] 
> dwc2_hsotg_udc_start+0x5c/0x200 [dwc2]
> [ 1618.179622] 
> [ 1618.179622] but task is already holding lock:
> [ 1618.179623]  (udc_lock){+.+.+.}, at: [] 
> usb_gadget_probe_driver+0x3a/0xd0 [udc_core]
> [ 1618.179627] 
> [ 1618.179627] which lock already depends on the new lock.
> [ 1618.179627] 
> [ 1618.179628] 
> [ 1618.179628] the existing dependency chain (in reverse order) is:
> [ 1618.179629] 
> [ 1618.179629] -> #1 (udc_lock){+.+.+.}:
> [ 1618.179631][] lock_acquire+0xdd/0x1f0
> [ 1618.179635][] mutex_lock_nested+0x76/0x3e0
> [ 1618.179638][] 
> usb_add_gadget_udc_release+0x187/0x240 [udc_core]
> [ 1618.179640][] usb_add_gadget_udc+0x10/0x20 
> [udc_core]
> [ 1618.179642][] dwc2_gadget_init+0x47c/0x580 [dwc2]
> [ 1618.179645][] dwc2_driver_probe+0x422/0x4b0 
> [dwc2]
> [ 1618.179648][] platform_drv_probe+0x34/0x90
> [ 1618.179650][] driver_probe_device+0x224/0x480
> [ 1618.179652][] __device_attach_driver+0x71/0xa0
> [ 1618.179654][] bus_for_each_drv+0x5d/0x90
> [ 1618.179655][] __device_attach+0xbf/0x140
> [ 1618.179657][] device_initial_probe+0x13/0x20
> [ 1618.179658][] bus_probe_device+0xa3/0xb0
> [ 1618.179660][] device_add+0x40d/0x690
> [ 1618.179661][] platform_device_add+0x111/0x270
> [ 1618.179663][] dwc2_pci_probe+0xe8/0x1d2 
> [dwc2_pci]
> [ 1618.179665][] local_pci_probe+0x45/0xa0
> [ 1618.179668][] pci_device_probe+0xe1/0x130
> [ 1618.179669][] driver_probe_device+0x224/0x480
> [ 1618.179671][] __driver_attach+0x88/0x90
> [ 1618.179672][] bus_for_each_dev+0x66/0xa0
> [ 1618.179674][] driver_attach+0x1e/0x20
> [ 1618.179675][] bus_add_driver+0x1ee/0x280
> [ 1618.179677][] driver_register+0x60/0xe0
> [ 1618.179678][] __pci_register_driver+0x60/0x70
> [ 1618.179680][] 0xc000601e
> [ 1618.179681][] do_one_initcall+0xb3/0x200
> [ 1618.179684][] do_init_module+0x5f/0x1e7
> [ 1618.179687][] load_module+0x21a8/0x2840
> [ 1618.179689][] SyS_finit_module+0x9a/0xc0
> [ 1618.179691][] entry_SYSCALL_64_fastpath+0x16/0x7a
> [ 1618.179693] 
> [ 1618.179693] -> #0 (>init_mutex){+.+.+.}:
> [ 1618.179695][] __lock_acquire+0x1d35/0x1db0
> [ 1618.179697][] lock_acquire+0xdd/0x1f0
> [ 1618.179698][] mutex_lock_nested+0x76/0x3e0
> [ 1618.179700][] dwc2_hsotg_udc_start+0x5c/0x200 
> [dwc2]
> [ 1618.179703][] udc_bind_to_driver+0xa4/0x100 
> [udc_core]
> [ 1618.179705][] usb_gadget_probe_driver+0x7a/0xd0 
> [udc_core]
> [ 1618.179707][] usb_composite_probe+0xa4/0xc0 
> [libcomposite]
> [ 1618.179709][] msg_init+0x10/0x1000 
> [g_mass_storage]
> [ 1618.179711][] do_one_initcall+0xb3/0x200
> [ 1618.179713][] do_init_module+0x5f/0x1e7
> [ 1618.179714][] load_module+0x21a8/0x2840
> [ 1618.179716][] 

Re: [PATCH 01/15] pcnet32: use pci_set_dma_mask insted of pci_dma_supported

[Don Fry]

On Sat, 2015-10-03 at 17:19 +0200, Christoph Hellwig wrote:
> This ensures the dma mask that is supported by the driver is recorded
> in the device structure.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/net/ethernet/amd/pcnet32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Acked-by: Don Fry 

> diff --git a/drivers/net/ethernet/amd/pcnet32.c 
> b/drivers/net/ethernet/amd/pcnet32.c
> index bc8b04f..e2afabf 100644
> --- a/drivers/net/ethernet/amd/pcnet32.c
> +++ b/drivers/net/ethernet/amd/pcnet32.c
> @@ -1500,7 +1500,7 @@ pcnet32_probe_pci(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   return -ENODEV;
>   }
>  
> - if (!pci_dma_supported(pdev, PCNET32_DMA_MASK)) {
> + if (!pci_set_dma_mask(pdev, PCNET32_DMA_MASK)) {
>   if (pcnet32_debug & NETIF_MSG_PROBE)
>   pr_err("architecture does not support 32bit PCI 
> busmaster DMA\n");
>   return -ENODEV;


--
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 0/4] usb: host: xhci-plat: add support for the R-Car M2-N and H3 xHCI controllers

[Yoshihiro Shimoda]

This patch set adds support for R-Car M2-N (r8a7793) and H3 (r8a7795) xHCI
controllers. To add support these new SoCs, this patch set modify some codes.

This patch is based on the latest usb.git / usb-next branch.
(The commit id = 07294cc2ea3000da706fd88c8ec7dcfadc715e14.)

Yoshihiro Shimoda (4):
  usb: host: xhci-rcar: add xhci_rcar_is_compatible() function
  usb: host: xhci-plat: add support for the R-Car M2-N xHCI controller
  usb: host: xhci-rcar: Change code for new SoCs
  usb: host: xhci-plat: add support for the R-Car H3 xHCI controllers

 Documentation/devicetree/bindings/usb/usb-xhci.txt |  4 +-
 drivers/usb/host/xhci-plat.c   | 11 ++-
 drivers/usb/host/xhci-rcar.c   | 83 ++
 drivers/usb/host/xhci-rcar.h   |  6 ++
 4 files changed, 81 insertions(+), 23 deletions(-)

-- 
1.9.1

--
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] usb: host: xhci-plat: add support for the R-Car H3 xHCI controllers

[Yoshihiro Shimoda]

This patch adds a firmware for the USB 3.0 host controllers of Renesas
R-Car H3 SoC.
This firmware is possible to use on R-Car H2 and M2. However, this
version causes performance degradation on R-Car H2 and M2. So, we would
like to keep the v1 firmware.

Signed-off-by: Yoshihiro Shimoda 
---
 WHENCE|   3 ++-
 r8a779x_usb3_v2.dlmem | Bin 0 -> 9472 bytes
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 r8a779x_usb3_v2.dlmem

diff --git a/WHENCE b/WHENCE
index c310c8b..2890465 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2749,9 +2749,10 @@ Licence:
 
 --
 
-Driver: xhci-rcar -- Renesas R-Car H2/M2 USB 3.0 host controller driver
+Driver: xhci-rcar -- Renesas R-Car H2/M2/H3 USB 3.0 host controller driver
 
 File: r8a779x_usb3_v1.dlmem
+File: r8a779x_usb3_v2.dlmem
 
 Licence: Redistributable. See LICENCE.r8a779x_usb3 for details.
 
diff --git a/r8a779x_usb3_v2.dlmem b/r8a779x_usb3_v2.dlmem
new file mode 100644
index 
..7db71726f45943e7162d8e21ce7d80885bd79184
GIT binary patch
literal 9472
zcmai44O~=J+J9z-JD0DE%!QeY2nRww5Cf
zN@k|M>6%}e4W?AC61Zi0qY280H9#4W6o(P~7+pbD-BR(s|8ob#ecSi9{C@v?{~C
z=R9BMInQ~9k{Q48Mp8YozY7#;Wv$+l8J(kO$gcFK`_ZOEFQuL*UQN#vJD){1{m1>a
z#63hw47M9|MfAdqSbgMaq5w{~mpxk!V3iL!rymL0Y{>@tLiXt@SPOBxf;E
zcrN-@$>@Gh+;6tE+g2p%i%3hF_}7TyWo5n2lj`MIuNA$69Hm`1`bX`>D8eZA?Kbgq
zPF7Y6l~SbJx?OS~8$~25wUaezN&2Pq%=KaV&3%Xx^|@h0OR0eI{^$L+LE>V9C
zlwKs;N~3*{zLw3Mkf;yTXlXH-J2+0mjeR|kbgw0u$ZjwS#vr5h26Y8-14NzC_D8e*
z{!tq0FXl>y%tZY-e6@&@F(=cH{(`K83a@2oh;bqF!GhIfkz)0jkUCK~pC=e_PiTGL`W)Oz(cUS2w@3
zYYJa0Xv7q$PH?o>30b}t!md>V!_A+-O%O66|BPD|;ia3wFh%slqiuTh7^)`8vCD
zAhL?nz;;^6kys~mjp;lcqbEa2iFOQo+Gx7oz!Y%E~6#w^|*21$PPkWM#$OC#T?z
zqXX>9{+<0$jZXI?<$}#!CfF;G|I}+WZ1?{MoYSKb+SQYWRfyJvu@Y8kF6w(
z{M?-@bp*;v?A`C}2CMGHM0CbS-g=52}Al+yjmnuXU;o3dQ#Y>vnP

[PATCH 2/4] usb: host: xhci-plat: add support for the R-Car M2-N xHCI controller

[Yoshihiro Shimoda]

This patch adds support for R-Car M2-N (r8a7793) xHCI controller.
This SoC is compatible with R-Car H2 (r8a7790) and R-Car M2-W (r8a7791).

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 4 ++--
 drivers/usb/host/xhci-plat.c   | 1 +
 drivers/usb/host/xhci-rcar.c   | 3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 86f67f0..106299a 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -3,8 +3,8 @@ USB xHCI controllers
 Required properties:
   - compatible: should be one of "generic-xhci",
 "marvell,armada-375-xhci", "marvell,armada-380-xhci",
-"renesas,xhci-r8a7790", "renesas,xhci-r8a7791" (deprecated:
-"xhci-platform").
+"renesas,xhci-r8a7790", "renesas,xhci-r8a7791", "renesas,xhci-r8a7793"
+(deprecated: "xhci-platform").
   - reg: should contain address and length of the standard XHCI
 register set for the device.
   - interrupts: one XHCI interrupt should be described here.
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 26acece..401110f 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -252,6 +252,7 @@ static const struct of_device_id usb_xhci_of_match[] = {
{ .compatible = "marvell,armada-380-xhci"},
{ .compatible = "renesas,xhci-r8a7790"},
{ .compatible = "renesas,xhci-r8a7791"},
+   { .compatible = "renesas,xhci-r8a7793"},
{ },
 };
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
index 642fe55..b4b110e 100644
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -62,7 +62,8 @@ bool xhci_rcar_is_compatible(struct usb_hcd *hcd)
struct device_node *of_node = hcd->self.controller->of_node;
 
if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
-   of_device_is_compatible(of_node, "renesas,xhci-r8a7791"))
+   of_device_is_compatible(of_node, "renesas,xhci-r8a7791") ||
+   of_device_is_compatible(of_node, "renesas,xhci-r8a7793"))
return true;
 
return false;
-- 
1.9.1

--
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 1/4] usb: host: xhci-rcar: add xhci_rcar_is_compatible() function

[Yoshihiro Shimoda]

To add support for other SoCs in the future, this patch adds
xhci_rcar_is_compatible() to check the compatible string.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/host/xhci-plat.c |  9 ++---
 drivers/usb/host/xhci-rcar.c | 12 
 drivers/usb/host/xhci-rcar.h |  6 ++
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 890ad9d..26acece 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -48,11 +48,9 @@ static void xhci_plat_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 /* called during probe() after chip reset completes */
 static int xhci_plat_setup(struct usb_hcd *hcd)
 {
-   struct device_node *of_node = hcd->self.controller->of_node;
int ret;
 
-   if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
-   of_device_is_compatible(of_node, "renesas,xhci-r8a7791")) {
+   if (xhci_rcar_is_compatible(hcd)) {
ret = xhci_rcar_init_quirk(hcd);
if (ret)
return ret;
@@ -63,10 +61,7 @@ static int xhci_plat_setup(struct usb_hcd *hcd)
 
 static int xhci_plat_start(struct usb_hcd *hcd)
 {
-   struct device_node *of_node = hcd->self.controller->of_node;
-
-   if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
-   of_device_is_compatible(of_node, "renesas,xhci-r8a7791"))
+   if (xhci_rcar_is_compatible(hcd))
xhci_rcar_start(hcd);
 
return xhci_run(hcd);
diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
index ff0d1b4..642fe55 100644
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -56,6 +57,17 @@ MODULE_FIRMWARE(FIRMWARE_NAME);
 #define RCAR_USB3_RX_POL_VAL   BIT(21)
 #define RCAR_USB3_TX_POL_VAL   BIT(4)
 
+bool xhci_rcar_is_compatible(struct usb_hcd *hcd)
+{
+   struct device_node *of_node = hcd->self.controller->of_node;
+
+   if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
+   of_device_is_compatible(of_node, "renesas,xhci-r8a7791"))
+   return true;
+
+   return false;
+}
+
 void xhci_rcar_start(struct usb_hcd *hcd)
 {
u32 temp;
diff --git a/drivers/usb/host/xhci-rcar.h b/drivers/usb/host/xhci-rcar.h
index 5850125..0eb67fa 100644
--- a/drivers/usb/host/xhci-rcar.h
+++ b/drivers/usb/host/xhci-rcar.h
@@ -12,9 +12,15 @@
 #define _XHCI_RCAR_H
 
 #if IS_ENABLED(CONFIG_USB_XHCI_RCAR)
+bool xhci_rcar_is_compatible(struct usb_hcd *);
 void xhci_rcar_start(struct usb_hcd *hcd);
 int xhci_rcar_init_quirk(struct usb_hcd *hcd);
 #else
+static inline bool xhci_rcar_is_compatible(struct usb_hcd *hcd)
+{
+   return false;
+}
+
 static inline void xhci_rcar_start(struct usb_hcd *hcd)
 {
 }
-- 
1.9.1

--
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: [PATCH 8/8] bdc_pci: use PCI_VDEVICE() instead of PCI_DEVICE()

[Sergei Shtylyov]

Hello.

On 10/5/2015 6:16 AM, Greg KH wrote:


Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().



Why?


   Seemed a good idea to me back in March. :-)


I hate PCI_VDEVICE(), it's impossible to grep for things and does


   Didn't think about grepping...


not help with readability and is pointless.  My one wish was that when I
was the PCI maintainer I would have just deleted the thing from the
kernel entirely instead of leaving it there hoping no one would use it.


   Thanks for the idea. :-)


I don't like these types of pointless patches, sorry.


   I hope you don't have the same strong feelings about PCI_DEVICE_SUB().
There's one place (in ohci-pci.c IIRC) it can be used...


thanks,

greg k-h


MBR, Sergei

--
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: [PATCH] net: usb: asix: Fix crash on skb alloc failure

[David Miller]

From: "David B. Robins" 
Date: Wed, 30 Sep 2015 16:20:04 -0400

> If asix_rx_fixup_internal() fails to allocate rx->ax_skb, it will return
> but not clear rx->size. rx points to driver private data. A later call
> assumes that nonzero size means ax_skb was allocated and passes a null
> ax_skb to skb_put. Changed allocation failure return to clear size first.
> 
> Found testing board with AX88772B devices.
> 
> Signed-off-by: David B. Robins 

Applied, thanks.
--
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 4/4] usb: host: xhci-plat: add support for the R-Car H3 xHCI controllers

[Yoshihiro Shimoda]

The R-Car H3 has two xHCI controllers. This SoC is compatible with
R-Car Gen2 SoCs, however this SoC doesn't need some specific registers
setting, and need a new firmware.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt |  4 ++--
 drivers/usb/host/xhci-plat.c   |  1 +
 drivers/usb/host/xhci-rcar.c   | 23 +-
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 106299a..0825732 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -3,8 +3,8 @@ USB xHCI controllers
 Required properties:
   - compatible: should be one of "generic-xhci",
 "marvell,armada-375-xhci", "marvell,armada-380-xhci",
-"renesas,xhci-r8a7790", "renesas,xhci-r8a7791", "renesas,xhci-r8a7793"
-(deprecated: "xhci-platform").
+"renesas,xhci-r8a7790", "renesas,xhci-r8a7791", "renesas,xhci-r8a7793",
+"renesas,xhci-r8a7795" (deprecated: "xhci-platform").
   - reg: should contain address and length of the standard XHCI
 register set for the device.
   - interrupts: one XHCI interrupt should be described here.
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 401110f..358febb 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -253,6 +253,7 @@ static const struct of_device_id usb_xhci_of_match[] = {
{ .compatible = "renesas,xhci-r8a7790"},
{ .compatible = "renesas,xhci-r8a7791"},
{ .compatible = "renesas,xhci-r8a7793"},
+   { .compatible = "renesas,xhci-r8a7795"},
{ },
 };
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
index acfa03a..eb1aed0 100644
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -17,8 +17,16 @@
 #include "xhci.h"
 #include "xhci-rcar.h"
 
+/*
+ * - The V2 firmware is possible to use on R-Car Gen2. However, the V2 causes
+ *   performance degradation. So, this driver continues to use the V1 if R-Car
+ *   Gen2.
+ * - The V1 firmware is impossible to use on R-Car Gen3.
+ */
 #define FIRMWARE_NAME_V1   "r8a779x_usb3_v1.dlmem"
+#define FIRMWARE_NAME_V2   "r8a779x_usb3_v2.dlmem"
 MODULE_FIRMWARE(FIRMWARE_NAME_V1);
+MODULE_FIRMWARE(FIRMWARE_NAME_V2);
 
 /*** Register Offset ***/
 #define RCAR_USB3_INT_ENA  0x224   /* Interrupt Enable */
@@ -69,9 +77,20 @@ static bool xhci_rcar_is_compatible_with_gen2(struct usb_hcd 
*hcd)
return false;
 }
 
+static bool xhci_rcar_is_compatible_with_gen3(struct usb_hcd *hcd)
+{
+   struct device_node *of_node = hcd->self.controller->of_node;
+
+   if (of_device_is_compatible(of_node, "renesas,xhci-r8a7795"))
+   return true;
+
+   return false;
+}
+
 bool xhci_rcar_is_compatible(struct usb_hcd *hcd)
 {
-   if (xhci_rcar_is_compatible_with_gen2(hcd))
+   if (xhci_rcar_is_compatible_with_gen2(hcd) ||
+   xhci_rcar_is_compatible_with_gen3(hcd))
return true;
 
return false;
@@ -176,6 +195,8 @@ int xhci_rcar_init_quirk(struct usb_hcd *hcd)
 
if (xhci_rcar_is_compatible_with_gen2(hcd))
firmware_name = FIRMWARE_NAME_V1;
+   if (xhci_rcar_is_compatible_with_gen3(hcd))
+   firmware_name = FIRMWARE_NAME_V2;
 
return xhci_rcar_download_firmware(hcd->self.controller, hcd->regs,
   firmware_name);
-- 
1.9.1

--
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 3/4] usb: host: xhci-rcar: Change code for new SoCs

[Yoshihiro Shimoda]

This patch changes code to ease the addition of next generation SoCs.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/host/xhci-rcar.c | 51 +++-
 1 file changed, 36 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
index b4b110e..acfa03a 100644
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -17,8 +17,8 @@
 #include "xhci.h"
 #include "xhci-rcar.h"
 
-#define FIRMWARE_NAME  "r8a779x_usb3_v1.dlmem"
-MODULE_FIRMWARE(FIRMWARE_NAME);
+#define FIRMWARE_NAME_V1   "r8a779x_usb3_v1.dlmem"
+MODULE_FIRMWARE(FIRMWARE_NAME_V1);
 
 /*** Register Offset ***/
 #define RCAR_USB3_INT_ENA  0x224   /* Interrupt Enable */
@@ -57,7 +57,7 @@ MODULE_FIRMWARE(FIRMWARE_NAME);
 #define RCAR_USB3_RX_POL_VAL   BIT(21)
 #define RCAR_USB3_TX_POL_VAL   BIT(4)
 
-bool xhci_rcar_is_compatible(struct usb_hcd *hcd)
+static bool xhci_rcar_is_compatible_with_gen2(struct usb_hcd *hcd)
 {
struct device_node *of_node = hcd->self.controller->of_node;
 
@@ -69,6 +69,27 @@ bool xhci_rcar_is_compatible(struct usb_hcd *hcd)
return false;
 }
 
+bool xhci_rcar_is_compatible(struct usb_hcd *hcd)
+{
+   if (xhci_rcar_is_compatible_with_gen2(hcd))
+   return true;
+
+   return false;
+}
+
+static void xhci_rcar_start_gen2(struct usb_hcd *hcd)
+{
+   /* LCLK Select */
+   writel(RCAR_USB3_LCLK_ENA_VAL, hcd->regs + RCAR_USB3_LCLK);
+   /* USB3.0 Configuration */
+   writel(RCAR_USB3_CONF1_VAL, hcd->regs + RCAR_USB3_CONF1);
+   writel(RCAR_USB3_CONF2_VAL, hcd->regs + RCAR_USB3_CONF2);
+   writel(RCAR_USB3_CONF3_VAL, hcd->regs + RCAR_USB3_CONF3);
+   /* USB3.0 Polarity */
+   writel(RCAR_USB3_RX_POL_VAL, hcd->regs + RCAR_USB3_RX_POL);
+   writel(RCAR_USB3_TX_POL_VAL, hcd->regs + RCAR_USB3_TX_POL);
+}
+
 void xhci_rcar_start(struct usb_hcd *hcd)
 {
u32 temp;
@@ -78,19 +99,13 @@ void xhci_rcar_start(struct usb_hcd *hcd)
temp = readl(hcd->regs + RCAR_USB3_INT_ENA);
temp |= RCAR_USB3_INT_ENA_VAL;
writel(temp, hcd->regs + RCAR_USB3_INT_ENA);
-   /* LCLK Select */
-   writel(RCAR_USB3_LCLK_ENA_VAL, hcd->regs + RCAR_USB3_LCLK);
-   /* USB3.0 Configuration */
-   writel(RCAR_USB3_CONF1_VAL, hcd->regs + RCAR_USB3_CONF1);
-   writel(RCAR_USB3_CONF2_VAL, hcd->regs + RCAR_USB3_CONF2);
-   writel(RCAR_USB3_CONF3_VAL, hcd->regs + RCAR_USB3_CONF3);
-   /* USB3.0 Polarity */
-   writel(RCAR_USB3_RX_POL_VAL, hcd->regs + RCAR_USB3_RX_POL);
-   writel(RCAR_USB3_TX_POL_VAL, hcd->regs + RCAR_USB3_TX_POL);
+   if (xhci_rcar_is_compatible_with_gen2(hcd))
+   xhci_rcar_start_gen2(hcd);
}
 }
 
-static int xhci_rcar_download_firmware(struct device *dev, void __iomem *regs)
+static int xhci_rcar_download_firmware(struct device *dev, void __iomem *regs,
+  const char *firmware_name)
 {
const struct firmware *fw;
int retval, index, j, time;
@@ -98,7 +113,7 @@ static int xhci_rcar_download_firmware(struct device *dev, 
void __iomem *regs)
u32 data, val, temp;
 
/* request R-Car USB3.0 firmware */
-   retval = request_firmware(, FIRMWARE_NAME, dev);
+   retval = request_firmware(, firmware_name, dev);
if (retval)
return retval;
 
@@ -153,9 +168,15 @@ static int xhci_rcar_download_firmware(struct device *dev, 
void __iomem *regs)
 /* This function needs to initialize a "phy" of usb before */
 int xhci_rcar_init_quirk(struct usb_hcd *hcd)
 {
+   const char *firmware_name = NULL;
+
/* If hcd->regs is NULL, we don't just call the following function */
if (!hcd->regs)
return 0;
 
-   return xhci_rcar_download_firmware(hcd->self.controller, hcd->regs);
+   if (xhci_rcar_is_compatible_with_gen2(hcd))
+   firmware_name = FIRMWARE_NAME_V1;
+
+   return xhci_rcar_download_firmware(hcd->self.controller, hcd->regs,
+  firmware_name);
 }
-- 
1.9.1

--
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: [PATCH v2 0/5] Improve ASIX RX memory allocation error handling

[David Miller]

From: Dean Jenkins 
Date: Fri, 2 Oct 2015 14:29:03 +0100

> The ASIX RX handler algorithm is weak on error handling.
> There is a design flaw in the ASIX RX handler algorithm because the
> implementation for handling RX Ethernet frames for the DUB-E100 C1 can
> have Ethernet frames spanning multiple URBs. This means that payload data
> from more than 1 URB is sometimes needed to fill the socket buffer with a
> complete Ethernet frame. When the URB with the start of an Ethernet frame
> is received then an attempt is made to allocate a socket buffer. If the
> memory allocation fails then the algorithm sets the buffer pointer member
> to NULL and the function exits (no crash yet). Subsequently, the RX hander
> is called again to process the next URB which assumes there is a socket
> buffer available and the kernel crashes when there is no buffer.
> 
> This patchset implements an improvement to the RX handling algorithm to
> avoid a crash when no memory is available for the socket buffer.
> 
> The patchset will apply cleanly to the net-next master branch but the
> created kernel has not been tested. The driver was tested on ARM kernels
> v3.8 and v3.14 for a commercial product.

Series applied, thanks.
--
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: [PATCH] net: usb: asix: Fix crash on skb alloc failure

[David B. Robins]

On 2015-10-05 06:31, David Miller wrote:

From: "David B. Robins" 
Date: Wed, 30 Sep 2015 16:20:04 -0400

If asix_rx_fixup_internal() fails to allocate rx->ax_skb, it will 
return

but not clear rx->size. rx points to driver private data. A later call
assumes that nonzero size means ax_skb was allocated and passes a null
ax_skb to skb_put. Changed allocation failure return to clear size 
first.


Found testing board with AX88772B devices.

Signed-off-by: David B. Robins 


Applied, thanks.


While I am happy for the patch I submitted to be applied, and it is 
consistent with existing error handling and does fix the specific issue, 
I believe a later series of 5 patches by Dean Jenkins that more 
comprehensively address the issue (grouped under subject "Improve ASIX 
RX memory allocation error handling") should be preferred.


--
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

iperf UDP packet loss with Chipidea HDRC

[Jayan John]

We are developing a custom USB device on a iMX6q platform with a Chipidea
HDRC. The device uses a single NCM interface for communication with another
OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP performance
after role reversal with iperf server running on gadget.

Kernel: 3.10.17 using Wandboard config

Test sequence:
1. Connect both boards (board A and board B) using OTG cable
2. Board A is assigned as A device and board B is assigned as B device
3. B device initiates role reversal
echo -n host > /sys/kernel/debug/ci_hdrc.0/role
4. A device switches to gadget mode
echo -n gadget > /sys/kernel/debug/ci_hdrc.0/role
5. Assign IPV6 address on board A (now gadget).. ifconfig usb0 2012::1/64 up
6. Assign IPV6 address on board B (now host).. ifconfig usb0 2012::2/64 up
7. Run iperf server on board A.. iperf -V -s -u
8. Run iperf client on board B.. iperf -u -t 10 -V -c 2012::1 -b 150M

iperf server logs:
[  4] local fe80::6cc9:b6ff:fec5:be28 port 5001 connected with
fe80::54e0:86ff:fea6:8987 port 35629
[  4]  0.0-10.0 sec  63.7 MBytes  53.4 Mbits/sec 0.171 ms 61701/107109 (58%)
[  4]  0.0-10.0 sec  1 datagrams received out-of-order
[  3] local fe80::6cc9:b6ff:fec5:be28 port 5001 connected with
fe80::54e0:86ff:fea6:8987 port 33609
[  3]  0.0-10.0 sec  62.1 MBytes  52.1 Mbits/sec 0.215 ms 62551/106825 (59%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Query:
1. The UDP packet loss is seen only in the case of iperf server on gadget
after role reversal. I see there are patches (12) from Peter for performance
improvements on the newer kernels. Will they help?
2. The issue is not seen if UDP socket buffer size/ datagram size on iperf is
increased i.e. iperf -u -t 10 -l 32k -V -c 2012::1 -b 150M. Is this only
hiding an issue with Chipidea driver e.g. TXFIFO or burst size?
3. Should ncm be tweaked to have different buffer size or NTB handling?
--
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: [PATCH] HID: hiddev: fix returned errno code in hiddev_connect()

[Jiri Kosina]

On Sat, 3 Oct 2015, Luis de Bethencourt wrote:

> > But I am not really sure where you are seeing the bug (mapping to 
> > -EPERM) in this case? I think the only caller of hiddev_connect() 
> > should be hid_connect(), and the only thing that guy cares about 
> > whether individual callbacks succeed or fail, so that it sets 
> > hdev->clamed flags accordingly.
> > 
> > Could you please be more specific about the -EPERM mapping you are 
> > talking about?
> > 
> I agree with you. The only caller of hiddev_connect() only checks if the
> callback succeded. It checks if the return < 0.
> What I meant is that -1 means -EPERM. [0]

I still don't understand what problem you are chasing here, sorry. EPERM 
is defined to be 1, yes. So are many other completely unrelated #defines.

> This patch is purely about the correctness of using -ENOMEM. The word 
> "propagated" was not the best way to describe this problem. I could edit 
> the commit message if you would like.

You seem to imply that someone might be interpreting that -1 as a define 
from errno.h. But that's not the case.

Are you going to look at every 'return -1' occurence in the kernel and 
convert it to something else? That can keep you busy for quite some time:

$ git grep 'return -1' | wc -l
9167

The only cleanup I'd imagine at least remotely possible in this case would 
be to convert the ->connect() callbacks return bool.

-- 
Jiri Kosina
SUSE Labs

--
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: [PATCH 11/15] sfc: don't call dma_supported

[Bert Kenward]

On 03/10/15 16:19, Christoph Hellwig wrote:

dma_set_mask already checks for a supported DMA mask before updating it,
the call to dma_supported is redundant.

Signed-off-by: Christoph Hellwig 


Acked-by: Bert Kenward 
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.
--
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 v9 4/4] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Have dev_pm_ops.prepare return 1 for USB devices and ports so that USB
devices can remain runtime-suspended when the system goes to a sleep
state, if their wakeup state is correct and they have runtime PM enabled.

Signed-off-by: Tomeu Vizoso 
---


 drivers/usb/core/port.c |  6 ++
 drivers/usb/core/usb.c  | 11 ++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 210618319f10..f49707d73b5a 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -168,12 +168,18 @@ static int usb_port_runtime_suspend(struct device *dev)
 
return retval;
 }
+
+static int usb_port_prepare(struct device *dev)
+{
+   return 1;
+}
 #endif
 
 static const struct dev_pm_ops usb_port_pm_ops = {
 #ifdef CONFIG_PM
.runtime_suspend =  usb_port_runtime_suspend,
.runtime_resume =   usb_port_runtime_resume,
+   .prepare =  usb_port_prepare,
 #endif
 };
 
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 8d5b2f4113cd..cf4dde11db1c 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -316,7 +316,16 @@ static int usb_dev_uevent(struct device *dev, struct 
kobj_uevent_env *env)
 
 static int usb_dev_prepare(struct device *dev)
 {
-   return 0;   /* Implement eventually? */
+   struct usb_device *udev = to_usb_device(dev);
+
+   if (!pm_runtime_enabled(dev))
+   return 0;
+
+   /* Return 0 if the current wakeup setting is wrong, otherwise 1 */
+   if (udev->do_remote_wakeup != device_may_wakeup(dev))
+   return 0;
+
+   return 1;
 }
 
 static void usb_dev_complete(struct device *dev)
-- 
2.4.3

--
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: [PATCH v4 1/5] gadget: Introduce the notifier functions

[Felipe Balbi]

On Sun, Oct 04, 2015 at 11:55:06PM +0100, Mark Brown wrote:
> On Fri, Oct 02, 2015 at 02:11:25PM -0500, Felipe Balbi wrote:
> > On Fri, Oct 02, 2015 at 07:49:09PM +0100, Mark Brown wrote:
> > > On Fri, Oct 02, 2015 at 12:23:11PM -0500, Felipe Balbi wrote:
> 
> > > > > Things more difficult, if nothing else it means we need to get 
> > > > > whatever
> > > > > userspace component deployed in all relevant userspace stacks with
> > > > > appropriate configuration in order to do things.
> 
> > > > but that will be a thing for the kernel too. We will have to deploy 
> > > > this new
> > > > kernel component in all relevant stacks with appropriate configuration 
> > > > in order
> > > > to do things :-) No changes there.
> 
> > > Sure, but it's one project which is developed entirely in the open -
> > > that's a lot more manageable.
> 
> > We can have a fully open source userland daemon too. Much like systemd, 
> > bluez,
> > neard, and many, many others. Why wouldn't that be a thing ?
> 
> The trouble is getting traction on adoption.  Vendors have a habit of doing
> things like finding problems and rather than reporting them deciding that the
> open source solution isn't great and going and writing their own thing
> (especially when they're in stealth mode) rather than talking to anyone.
> Sometimes we manage to avoid that but it can be challenging, and often we only
> even hear about the new thing after it's shipping and there's a lot of inertia
> behind changing it.  The kernel ABIs tend to be a lot sticker than userspace
> things here.

but this is not a solid enough argument to push anything into the kernel.

> > Similar applies to power delivery charging profile themselves. Not all
> > profiles are mandatory. Some are optional and that will be completely
> > device/board specific. How an OEM implements that in the PCB is also
> > completely board-specific :-) Some might have a dumb IC hardcoding some
> > messages, some might have something largely more flexible.
> 
> Right, and what I was trying to say was that it seems like the kernel ought to
> be worrying about the board specific bits and userspace worrying about what to
> do with those bits.

we're not saying anything different in this front. I, too, want kernel to deal
with certain details and expose notifications. Where we disagree is how granular
should these notifications be and where they should be sent to.

 > > The things we've got with audio are a combination of tuning to taste and
> > > (even more importantly) very different ideas about what you want to do
> > > with an audio subsystem that influence how you set things up in a given
> > > use case.
> 
> > the same thing will happen with Type-C and power delivery. There won't be 
> > tuning
> > to taste, of course :-) But there will be "very different ideas what what 
> > you
> > want to do with" your charging methodology.
> 
> Are those very different things about the use cases ("don't bother with
> high speed data, get all the power you can" or whatever) or are they
> about the details of the board?

I'm pretty sure there will be interesting designs in the market. I'm pretty sure
there will be type-C systems which won't support USB 3.1 for example, even
though they'll support USB Power Delivery in its entirety.

> > > > Actually, I was thinking about it in a more granular fashion. Kernel
> > > > exposes a charger/power_supply, a few regulators, a UDC view and this
> > > > single userspace daemon figures out how to tie those together.
> 
> > > That sounds worrying - it means that new hardware support needs
> > > supporting in every userspace (it seems inevitable that there will be at
> > > least some reimplementations because that's fun) which gets old really
> > > fast, and every userspace needs to understand every topology.
> 
> > very true, but it's also true for a kernel solution.
> 
> > It seems like you want it in the kernel because of it being convenient :-)
> 
> Yes, definitely - my experience both in terms of watching how people
> like handset vendors often work internally and in terms of getting
> things adopted is that it's a lot easier if you can have one component
> you need to update to handle new hardware rather than multiple ones that
> need to be upgraded for things that are purely board differences.

IMO, just because you have it in the kernel, it doesn't mean it'll be
adopted. Look at pm_runtime, for example; it's a very nice API and, yet, not
used by Android (or has that changed ?)

> > > > The view here isn't really a USB port, it's just a source of power. But 
> > > > how much
> > > > power we can draw from it depends on, possibly, a ton of different 
> > > > chips and
> > > > different notifications.
> 
> > > Right, yes - it's the power input/output associated with the USB port.
> > > The USB port is just the physical thing users can see so it's a good way
> > > to label it.  That could mean that we ought to move the aggregation bit
> > > into the power supply code of 

[PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Tomeu Vizoso]

Hi,

this is v9 of an attempt to make it easier for devices to remain in
runtime PM when the system goes to sleep, mainly to reduce the time
spent resuming devices.

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

With these changes, a uvcvideo device (for example) stays in runtime
suspend when the system goes to sleep and is left in that state when the
system resumes, not delaying it unnecessarily.

Thanks,

Tomeu

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  device_is_bound()
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()
- Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
- Rename from device_check_pm_callbacks to device_pm_check_callbacks to
  follow with the naming convention of existing API.
- Re-add calling to device_pm_check_callbacks from device registration
  and when updating the PM domain of a device.

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 21 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 24 
 drivers/base/power/domain.c   |  6 --
 drivers/base/power/main.c | 35 +++
 drivers/base/power/power.h|  3 +++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c| 11 ++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 131 insertions(+), 23 deletions(-)

-- 
2.4.3

--
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: [PATCH v4 1/5] gadget: Introduce the notifier functions

[Mark Brown]

On Mon, Oct 05, 2015 at 10:15:11AM -0500, Felipe Balbi wrote:
> On Sun, Oct 04, 2015 at 11:55:06PM +0100, Mark Brown wrote:

> > The trouble is getting traction on adoption.  Vendors have a habit of doing
> > things like finding problems and rather than reporting them deciding that 
> > the
> > open source solution isn't great and going and writing their own thing
> > (especially when they're in stealth mode) rather than talking to anyone.
> > Sometimes we manage to avoid that but it can be challenging, and often we 
> > only
> > even hear about the new thing after it's shipping and there's a lot of 
> > inertia
> > behind changing it.  The kernel ABIs tend to be a lot sticker than userspace
> > things here.

> but this is not a solid enough argument to push anything into the kernel.

To my mind it is a concern when considering design - it's not the only
consideration certainly but it should influence if or how we split
things.

> > > the same thing will happen with Type-C and power delivery. There won't be 
> > > tuning
> > > to taste, of course :-) But there will be "very different ideas what what 
> > > you
> > > want to do with" your charging methodology.

> > Are those very different things about the use cases ("don't bother with
> > high speed data, get all the power you can" or whatever) or are they
> > about the details of the board?

> I'm pretty sure there will be interesting designs in the market. I'm pretty 
> sure
> there will be type-C systems which won't support USB 3.1 for example, even
> though they'll support USB Power Delivery in its entirety.

That's sounding like generic USB stuff to me.

> > Yes, definitely - my experience both in terms of watching how people
> > like handset vendors often work internally and in terms of getting
> > things adopted is that it's a lot easier if you can have one component
> > you need to update to handle new hardware rather than multiple ones that
> > need to be upgraded for things that are purely board differences.

> IMO, just because you have it in the kernel, it doesn't mean it'll be
> adopted. Look at pm_runtime, for example; it's a very nice API and, yet, not
> used by Android (or has that changed ?)

That's always been a bit of a myth - most Android systems use runtime PM
extensively when they're running, the discussion is really about the
edge case where you're idling the system.  The Android suspend behaviour
is about the system idle case and is as much about providing a simple
way to go into an idle state, especially bearing in mind that they have
apps installed from the app store there, as anything else.  It's the
making sure things are idle part of things that's different.

> > > okay, this is a fair point :-) I just don't see, as of now at least, how 
> > > we can
> > > get to that in a way that's somewhat future-proof. It seems like we will
> > > add more and more notifications until we can't maintain this anymore.

> > So we need to look at the new/upcoming USB specs and understand the

> not upcoming, it's already out there.

I assume there's ongoing work on further revisions to the spec though?

> > Yup, which is a really cool feature and keeps us all employed too! :)
> > This is one reason for attaching things to the USB stack, right now it
> > does a limited negotiation but in future like you say there's more and
> > more features coming.

> keep in mind that the same stack used to change a charging current, will also 
> be
> used to tell the other end to mux those lines differently.

Sure.

> > Does the problem not get easier if we break it down to just the charger
> > elements and realise that the USB C modes are going to have a lot more
> > policy in them?

> the thing with USB C is that it's not only for negotiating a charging power
> (with power delivery you're not necessarily tied to 5V, btw), that very stack
> will also be used to change to other alternate modes, and those can be 
> anything:
> Thunderbolt, PCIe, DisplayPort, etc.

Surely these features have sufficient orthogonality to allow us to split
things up and deal with some of the problems while providing spaces for
future work?


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

[Felipe Balbi]

Hi,

On Mon, Oct 05, 2015 at 05:18:33PM +0100, Mark Brown wrote:
> On Mon, Oct 05, 2015 at 10:15:11AM -0500, Felipe Balbi wrote:
> > On Sun, Oct 04, 2015 at 11:55:06PM +0100, Mark Brown wrote:
> 
> > > The trouble is getting traction on adoption.  Vendors have a habit of 
> > > doing
> > > things like finding problems and rather than reporting them deciding that 
> > > the
> > > open source solution isn't great and going and writing their own thing
> > > (especially when they're in stealth mode) rather than talking to anyone.
> > > Sometimes we manage to avoid that but it can be challenging, and often we 
> > > only
> > > even hear about the new thing after it's shipping and there's a lot of 
> > > inertia
> > > behind changing it.  The kernel ABIs tend to be a lot sticker than 
> > > userspace
> > > things here.
> 
> > but this is not a solid enough argument to push anything into the kernel.
> 
> To my mind it is a concern when considering design - it's not the only
> consideration certainly but it should influence if or how we split
> things.

sure

> > > > the same thing will happen with Type-C and power delivery. There won't 
> > > > be tuning
> > > > to taste, of course :-) But there will be "very different ideas what 
> > > > what you
> > > > want to do with" your charging methodology.
> 
> > > Are those very different things about the use cases ("don't bother with
> > > high speed data, get all the power you can" or whatever) or are they
> > > about the details of the board?
> 
> > I'm pretty sure there will be interesting designs in the market. I'm pretty 
> > sure
> > there will be type-C systems which won't support USB 3.1 for example, even
> > though they'll support USB Power Delivery in its entirety.
> 
> That's sounding like generic USB stuff to me.
> 
> > > Yes, definitely - my experience both in terms of watching how people
> > > like handset vendors often work internally and in terms of getting
> > > things adopted is that it's a lot easier if you can have one component
> > > you need to update to handle new hardware rather than multiple ones that
> > > need to be upgraded for things that are purely board differences.
> 
> > IMO, just because you have it in the kernel, it doesn't mean it'll be
> > adopted. Look at pm_runtime, for example; it's a very nice API and, yet, not
> > used by Android (or has that changed ?)
> 
> That's always been a bit of a myth - most Android systems use runtime PM
> extensively when they're running, the discussion is really about the
> edge case where you're idling the system.  The Android suspend behaviour
> is about the system idle case and is as much about providing a simple
> way to go into an idle state, especially bearing in mind that they have
> apps installed from the app store there, as anything else.  It's the
> making sure things are idle part of things that's different.

okay

> > > > okay, this is a fair point :-) I just don't see, as of now at least, 
> > > > how we can
> > > > get to that in a way that's somewhat future-proof. It seems like we will
> > > > add more and more notifications until we can't maintain this anymore.
> 
> > > So we need to look at the new/upcoming USB specs and understand the
> 
> > not upcoming, it's already out there.
> 
> I assume there's ongoing work on further revisions to the spec though?

that'd be a correct assumption

> > > Does the problem not get easier if we break it down to just the charger
> > > elements and realise that the USB C modes are going to have a lot more
> > > policy in them?
> 
> > the thing with USB C is that it's not only for negotiating a charging power
> > (with power delivery you're not necessarily tied to 5V, btw), that very 
> > stack
> > will also be used to change to other alternate modes, and those can be 
> > anything:
> > Thunderbolt, PCIe, DisplayPort, etc.
> 
> Surely these features have sufficient orthogonality to allow us to split
> things up and deal with some of the problems while providing spaces for
> future work?

yeah, might. As long as we keep that voice in our heads that things are likely
to change.

-- 
balbi


signature.asc
Description: PGP signature

Intel XHCI: random URB_INTERRUPTs triggering port resets and device disconnects

[Eugen Rogoza]

Hello,

in xHCI mode I'm experiencing random disconnects and reconnects of my ASMedia 
ASM1051-based external HDD enclosure.

The only combination where the disconnects are happening is Intel USB Host 
Controller + Linux kernel + XHCI mode (see further observations below).

I did some tracing with libpcap (can be opened in Wireshark). I did one trace 
on the NEC chipset where I have no disconnects and one on the Intel chipset 
where I do experience disconnects. The Intel output clearly shows that at some 
point in time a URB_INTERRUPT is sent from "1.1" (I suppose it is the hub) to 
the host (packet 1780) and the host requests a port reset (packet 1800). The 
procedure repeats after a random time (packet 3648). The NEC trace does not 
have such interrupts.

Why is that interrupt sent? Where is it coming from?
 

Additional info and observations below:

Observations:

- independent of activity/workload
- works perfectly under Windows 7 in XHCI mode
- works everywhere (Linux and Windows) when using USB 2.0 mode (EHCI)
- tried with kernels 4.0.5, 4.2.0 and 3.18.16 - no difference
- enabling/disabling runtime PM and USB power management doesn't make any 
difference
- works on a different host hardware with a NEC USB3.0 host controller (see 
details below). Tested with kernel 3.17.7.

Traces can be downloaded here:

http://wikisend.com/download/136936/usb3_intel.pcapng.gz
http://wikisend.com/download/612580/usb3_nec.pcapng.gz


Output of /var/log/messages demonstrating the issue: 
http://pastebin.com/wbUr5mMe


lsusb and lspci outputs (Intel hardware): http://pastebin.com/XDEz2x2g


lsusb and lspci outputs (NEC hardware): http://pastebin.com/1M1ZVyJr


Thanks for help,

Eugen
--
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