Re: [PATCH v3 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Lu, Baolu]

On 05/23/2015 12:08 AM, David Cohen wrote:

Hi,

On Fri, May 22, 2015 at 07:29:15PM +0800, Lu Baolu wrote:

Phy drivers and the ulpi interface providers depend on the
registeration of the ulpi bus.  Ulpi registers the bus in
module_init(). This could result in a load order issue, i.e.

It's still not an issue :(
I'd say unnecessary probe delays.


I managed to boot a kernel built from the top of Felipe's
remotes/origin/next branch under an Ubuntu environment
on Intel's Bay Trail tablet.

The same panic (as I found in the Android environment previously)
shows up as well. And if I replace module_init() with sys_initcall(),
the panic disappears.

Thanks,
-Baolu



But of cource it's Felipe's call :) Description looks better now.

BR, David


ulpi phy drivers or the ulpi interface providers loading
before the bus registeration.

This patch fixes this load order issue by putting ulpi_init
in subsys_initcall().

Reported-by: Zhuo Qiuxu qiuxu.z...@intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
  drivers/usb/common/ulpi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..01c0c04 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -242,7 +242,7 @@ static int __init ulpi_init(void)
  {
return bus_register(ulpi_bus);
  }
-module_init(ulpi_init);
+subsys_initcall(ulpi_init);
  
  static void __exit ulpi_exit(void)

  {
--
2.1.4





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

Re: USB Host Controller no PCD interrupt and CCS and CSC update on the device disconnect

[Rong Wang]

On Fri, May 22, 2015 at 10:06 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Fri, 22 May 2015, Rong Wang wrote:

 Hi,

 We have one USB 2.0 Controller on an ARM SoC, with internal PHY
 confirming to UTMI.
 The PHY would detect unexpected disconnect (amplitude of the
 differential envelop still  625 mV)
 and assert the HostDisconnect signal to the Controller to indicate a
 disconnection event.
 When the HostDisconnect signal is asserted, the Controller will first
 do some internal clean work
 before it update CCS and CSC in PORTSCx and reports a Port Change
 Detect interrupt.
 We want to improve the situation

 Why do you want to improve the situation?  What's wrong with the way it
 is now?  Detecting a disconnect while the differential amplitude is 
 625 mv is perfectly legal.  The USB-2.0 spec requires: Signals with
 differential amplitudes = 525 mV must never activate the Disconnection
 Envelope Detector (section 7.1.7.3).


Our customer oberserved some unexpected disconnections during the
shaking test (user scenario simulation). They want the disconnection
detection to be less sensitive (= 625 mV). Because once the
discoonection is reported, the APP SW will be re-launched and the USB
device will also notify user the disconnection event, which is not
accepted by our customer.

  by masking the HostDisconnect signal
 from PHY (take the
 cost into consideration), but it will cause no CCS and CSC update in
 PORTSCx, and no PCD interrupt. Thus the true disconnection only can be
 determined by an XactErr. Once the driver
 determine that it's a true disconnect, the HostDisconnect signal can
 be unmasked and the
 Controller will detect this disconnect.
 We are worried about the workaroud, since there may be many corner
 cases we have not taken into consideration, such as the race condition
 on connect and disconnect.

 It sounds like you are going to make the situation worse, not improve
 it.

We are going to filter the intermittent disconnection signal from PHY,
but we must determine a true disconnection by driver with a retry scheme.
I agree that it will make the situation more complicated because there may
be many corner cases that we don't forsee and one of them may even
make this workaround not workable.


 So have you encountered this situation before? Or is there any
 suggestion on this workaround?

 I don't see any reason to make any changes.

 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 v3 00/11] usbip: features to USB over WebSocket

[Krzysztof Opasiak]

Hi,

On 05/25/2015 03:30 AM, fx IWATA NOBUO wrote:

Hello,


I see your point and what you have done in patches.
I'm only showing you that you may achieve almost the same effect
without any changes in kernel.


I tested wstunnel.

The performance comparison in my environment is as following.
Round trip time of keyboard key down and up URBs at host.

wstunnel: 4.4msec
usbws(my patch): 2.7msec

wstunnel passes TCP/IP stack twice so it's slower.

I'd like to keep the usbws implementation because it's worth for
performance.

memory usage (VSZ/RSS)
  wstunnel   usbws
Server wstunnel  734K/20K
usbipa25K/2K
usbwsa   25K/2K
Client wstunnel  75K/17K
usbipa   113K/3K



I don't say that wstunnel is the best implementation of this 
functionality. There is plenty implementations of such tunneling daemons 
and wstunnel is only an example.


Maybe with other daemon or if you write your own one you will get better 
performance. It is obvious that it will never be as fast as dedicated 
implementation but the difference may be small enough.


--
Krzysztof Opasiak
Samsung RD Institute Poland
Samsung Electronics
--
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: usb:gadget:hid:Add BOOT mode support

[Golmer Palmer]

Alan Stern stern@... writes:

  I feel that this person ins't at time maintaining this source code.
 
 You seem to be right, since his email address doesn't work any more.
 
  I'm suposing that this mailing list is readed by very competent 
people 
  that can implement this simple change. I hope someone likes to fix 
  that problem...
 
 I took a look at the driver.  The change you seem to be asking for is
 not simple at all.
 
 The problem is that the f_hid driver doesn't support either the Report
 or Boot protocols.  Instead, it relies on a user program to generate 
or
 consume the reports that get sent to/from the host.  Currently the
 driver has no way to inform the user program about which protocol to
 use, and the program has no way to tell the driver when the protocol 
 is changed.
 
 Your original email message said:
 
  The problem is that several Keyboard and Mouse implementations using 
this 
  framework are in fact fully compatible with BOOT mode.
 
 As far as I can tell, an implementation can support either the Report
 or Boot protocol, but not both.  The problem is that when you use a
 keyboard or mouse during boot-up, the BIOS will want to use the Boot
 protocol, and once the boot-up is complete, the operating system will
 want to switch to the Report protocol.

Hi Alan,

Thank you for your response and the patch.

First a comment:

Please, take into account that I mentioned that the ASSUMPTION that 
keyboard and mouse drivers are compatible with BOTH protocols is really 
TRUE. Then any program that implements keyboard and/or mouse emulation 
is only implementing the BOOT protocol (6KRO for keyboard and 3button 
for mouse). The real problem is that the driver don't implements the two 
needed functions [ Get_Protocol()  Set_Protocol() ], although the 
program implements the BOOT protocol. Remember that BOOT protocol is 
only a subset of REPORT protocol; and no one has interest in 
implementing a more complex keyboard or mouse target. So, the question 
is why the hid usb gadget driver don't implements these two functions 
for supporting the BOOT protocol? When the device is compatible with 
both protocols, the status info reported by the driver is not relevant, 
and this is the point that I suggest to change: report the change 
instead what is doing the program, because the two protocols are the 
same.

 The patch below adds support for Get Protocol and Set Protocol, but
 only for one protocol at a time (switching is not supported).  Does
 this do what you want?

Related to your patch, if the default mode is BOOT, I feel it can work. 
However, why not implement the change? If both protocols are the same, 
the change can be done with any trouble.

Regards!


--
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: [Bulk] seagate SRD00f2 expansion 4Tb desktop drive does not work on USB 3.0 Part 2 xhci-debug

[Lu, Baolu]

On 05/23/2015 10:00 PM, Donald Harter wrote:
May 23 08:52:05 pc_u kernel: [53875.075976] xhci_hcd :00:14.0: 
Port Status Change Event for port 3
May 23 08:52:05 pc_u kernel: [53875.075979] xhci_hcd :00:14.0: 
port resume event for port 3
May 23 08:52:05 pc_u kernel: [53875.075981] xhci_hcd :00:14.0: 
resume HS port 3
May 23 08:52:05 pc_u kernel: [53875.075983] xhci_hcd :00:14.0: 
handle_port_status: starting port polling.
May 23 08:52:05 pc_u kernel: [53875.135221] xhci_hcd :00:14.0: 
Resume USB2 port 3
May 23 08:52:05 pc_u kernel: [53875.135230] xhci_hcd :00:14.0: 
Port Status Change Event for port 3
May 23 08:52:05 pc_u kernel: [53875.135240] xhci_hcd :00:14.0: get 
port status, actual port 2 status  = 0xfe3
May 23 08:52:05 pc_u kernel: [53875.135241] xhci_hcd :00:14.0: Get 
port status returned 0x40503
May 23 08:52:05 pc_u kernel: [53875.135262] xhci_hcd :00:14.0: 
clear port suspend/resume change, actual port 2 status  = 0xe03
May 23 08:52:05 pc_u kernel: [53875.151222] xhci_hcd :00:14.0: get 
port status, actual port 2 status  = 0xe03
May 23 08:52:05 pc_u kernel: [53875.151224] xhci_hcd :00:14.0: Get 
port status returned 0x503
May 23 08:52:05 pc_u kernel: [53875.255453] xhci_hcd :00:14.0: // 
Ding dong!
May 23 08:52:05 pc_u kernel: [53875.255496] xhci_hcd :00:14.0: 
Slot 15 output ctx = 0x4018f1000 (dma)
May 23 08:52:05 pc_u kernel: [53875.255498] xhci_hcd :00:14.0: 
Slot 15 input ctx = 0x401e2a000 (dma)
May 23 08:52:05 pc_u kernel: [53875.255499] xhci_hcd :00:14.0: Set 
slot id 15 dcbaa entry 8804028f2078 to 0x4018f1000
May 23 08:52:06 pc_u kernel: [53875.343311] usb 3-3.4: new high-speed 
USB device number 14 using xhci_hcd
May 23 08:52:06 pc_u kernel: [53875.343314] xhci_hcd :00:14.0: Set 
root hub portnum to 3
May 23 08:52:06 pc_u kernel: [53875.343315] xhci_hcd :00:14.0: Set 
fake root hub portnum to 3
May 23 08:52:06 pc_u kernel: [53875.343315] xhci_hcd :00:14.0: 
udev-tt =   (null)
May 23 08:52:06 pc_u kernel: [53875.343316] xhci_hcd :00:14.0: 
udev-ttport = 0x0
May 23 08:52:06 pc_u kernel: [53875.343317] xhci_hcd :00:14.0: 
Slot ID 15 Input Context: 


It looks like USB device doesn't complete resuming while host controller 
tries

to assign USB address to it.

Do you mind trying below change?

diff --git a/include/linux/usb.h b/include/linux/usb.h
index 447fe29..660e2d7 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -229,7 +229,7 @@ void usb_put_intf(struct usb_interface *intf);
  * should cope with both LPJ calibration errors and devices not 
following every

  * detail of the USB Specification.
  */
-#define USB_RESUME_TIMEOUT 40 /* ms */
+#define USB_RESUME_TIMEOUT 100 /* ms */

 /**
  * struct usb_interface_cache - long-term representation of a device 
interface


Thanks,
-Baolu
--
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: usbhid: add Chicony/Pixart usb optical mouse that needs QUIRK_ALWAYS_POLL

[Jiri Kosina]

On Thu, 21 May 2015, Herton R. Krzesinski wrote:

 I received a report from an user of following mouse which needs this quirk:
 
 usb 1-1.6: USB disconnect, device number 58
 usb 1-1.6: new low speed USB device number 59 using ehci_hcd
 usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053
 usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-1.6: Product: USB Optical Mouse
 usb 1-1.6: Manufacturer: PixArt
 usb 1-1.6: configuration #1 chosen from 1 choice
 input: PixArt USB Optical Mouse as 
 /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input5887
 generic-usb 0003:04F2:1053.16FE: input,hidraw2: USB HID v1.11 Mouse [PixArt 
 USB Optical Mouse] on usb-:00:1a.0-1.6/input0
 
 The quirk was tested by the reporter and it fixed the frequent disconnections 
 etc.
 
 Signed-off-by: Herton R. Krzesinski her...@redhat.com

Applied (with Benjamin's nit taken into account). Thanks,

-- 
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] usb: ulpi: don't register drivers if bus doesn't exist

[Heikki Krogerus]

Hi,

 Why do we even need that? If you take patch that makes ulpi_init a
 subsys_initcall you won't have this problem, and no additional weird
 hacks and errors will be needed

Using subsys_initcall will work around the problem for now, but I
would not make the assumption that there will never be ulpi phy
drivers and ulpi interface drivers that don't use subsys_initcall
themselves. By checking the old phy drivers at drivers/usb/phy/, at
least so far it hasn't been uncommon for them to use subsys_initcall.

I would much prefer to have a proper fix for this issue instead of
just working around it, but we need to use subsys_initcall in any
case.

   +   /* Was the bus registered successfully? */
   +   if (!ulpi_bus.p)
   +   return -ENODEV;
 
  Ick, no, don't go mucking around in the bus internals like this, that's
  not ok.  You should either know the bus is registered, or something is
  really wrong with the design here.
  can't we use a variable which can be initialized to 1 in ulpi_init() if
  the bus registers successfully and later check that?

Just a note. We should also be aware if the bus registration failed or
if it just hasn't been loaded yet.

If we used a variable like that, I guess it could initially have the
value -EAGAIN. If bus_register returns error, we store -ENODEV to it.
If bus_register succeeds we store 0 to it. I don't know if we can just
store the return value from bus_register to it.

In ulpi_register_driver and ulpi_register_interface we can then just
return it if it has a value other then 0.

But couldn't we add a helper function to drivers/base/bus.c that the
bus drivers can use to at least check was the bus already loaded or
not? It looks like there are a couple of bus drivers that use the
struct bus member p to check that.

Greg, what do you think?


Thanks,

-- 
heikki
--
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 v3 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Heikki Krogerus]

On Fri, May 22, 2015 at 09:08:45AM -0700, David Cohen wrote:
 Hi,
 
 On Fri, May 22, 2015 at 07:29:15PM +0800, Lu Baolu wrote:
  Phy drivers and the ulpi interface providers depend on the
  registeration of the ulpi bus.  Ulpi registers the bus in
  module_init(). This could result in a load order issue, i.e.
 
 It's still not an issue :(
 I'd say unnecessary probe delays.
 
 But of cource it's Felipe's call :) Description looks better now.
 
 BR, David
 
  ulpi phy drivers or the ulpi interface providers loading
  before the bus registeration.
  
  This patch fixes this load order issue by putting ulpi_init
  in subsys_initcall().
  
  Reported-by: Zhuo Qiuxu qiuxu.z...@intel.com
  Signed-off-by: Lu Baolu baolu...@linux.intel.com

Adding Felipe. FWIW, my ACK in any case:

Acked-by: Heikki Krogerus heikki.kroge...@linux.intel.com


Thanks,

-- 
heikki
--
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: gadget: f_uac1: check return code from config_ep_by_speed

[Michael Trimarchi]

Hi Felipe

On Mon, May 18, 2015 at 05:28:58PM +0200, Michael Trimarchi wrote:
 Not checking config_ep_by_speed could lead to a kernel
 NULL pointer dereference error in usb_ep_enable
 
 Cc: Felipe Balbi ba...@ti.com
 Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com
 
 ---
 
 v2:
 - fix mail subject
 - add description


Is it fine now? My last email was rejected by the mailing list (html tags)

Michael
 
 ---
  drivers/usb/gadget/function/f_uac1.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/gadget/function/f_uac1.c 
 b/drivers/usb/gadget/function/f_uac1.c
 index 9719abf..7856b33 100644
 --- a/drivers/usb/gadget/function/f_uac1.c
 +++ b/drivers/usb/gadget/function/f_uac1.c
 @@ -588,7 +588,10 @@ static int f_audio_set_alt(struct usb_function *f, 
 unsigned intf, unsigned alt)
  
   if (intf == 1) {
   if (alt == 1) {
 - config_ep_by_speed(cdev-gadget, f, out_ep);
 + err = config_ep_by_speed(cdev-gadget, f, out_ep);
 + if (err)
 + return err;
 +
   usb_ep_enable(out_ep);
   out_ep-driver_data = audio;
   audio-copy_buf = f_audio_buffer_alloc(audio_buf_size);
 -- 
 1.9.1
 

-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 16/21] usb: phy: Probe phy devices on demand

[Tomeu Vizoso]

When looking up a phy through its DT node, ensure that the corresponding
device has been registered.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
 drivers/usb/phy/phy.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index d1cd6b5..7084f21 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -13,6 +13,7 @@
 #include linux/err.h
 #include linux/device.h
 #include linux/module.h
+#include linux/of_platform.h
 #include linux/slab.h
 #include linux/of.h
 
@@ -192,6 +193,8 @@ struct usb_phy *devm_usb_get_phy_by_phandle(struct device 
*dev,
goto err0;
}
 
+   of_platform_device_ensure(node);
+
spin_lock_irqsave(phy_lock, flags);
 
phy = __of_usb_find_phy(node);
-- 
2.4.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: USB Host Controller no PCD interrupt and CCS and CSC update on the device disconnect

[Alan Stern]

On Mon, 25 May 2015, Rong Wang wrote:

 On Fri, May 22, 2015 at 10:06 PM, Alan Stern st...@rowland.harvard.edu 
 wrote:
  On Fri, 22 May 2015, Rong Wang wrote:
 
  Hi,
 
  We have one USB 2.0 Controller on an ARM SoC, with internal PHY
  confirming to UTMI.
  The PHY would detect unexpected disconnect (amplitude of the
  differential envelop still  625 mV)
  and assert the HostDisconnect signal to the Controller to indicate a
  disconnection event.
  When the HostDisconnect signal is asserted, the Controller will first
  do some internal clean work
  before it update CCS and CSC in PORTSCx and reports a Port Change
  Detect interrupt.
  We want to improve the situation
 
  Why do you want to improve the situation?  What's wrong with the way it
  is now?  Detecting a disconnect while the differential amplitude is 
  625 mv is perfectly legal.  The USB-2.0 spec requires: Signals with
  differential amplitudes = 525 mV must never activate the Disconnection
  Envelope Detector (section 7.1.7.3).
 
 
 Our customer oberserved some unexpected disconnections during the
 shaking test (user scenario simulation). They want the disconnection
 detection to be less sensitive (= 625 mV). Because once the
 discoonection is reported, the APP SW will be re-launched and the USB
 device will also notify user the disconnection event, which is not
 accepted by our customer.

It seems that your customer wants to change the hardware, not the
software.

  It sounds like you are going to make the situation worse, not improve
  it.
 
 We are going to filter the intermittent disconnection signal from PHY,
 but we must determine a true disconnection by driver with a retry scheme.
 I agree that it will make the situation more complicated because there may
 be many corner cases that we don't forsee and one of them may even
 make this workaround not workable.

Sometimes there are hardware problems that can not be solved in
software, or are too difficult to solve in software.  I think this is 
one of them.

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] drivers: usb :fsl: Add support for USB controller version-2.5

[Greg KH]

On Mon, May 25, 2015 at 05:51:06AM +, Badola Nikhil wrote:
  -Original Message-
  From: Greg KH [mailto:g...@kroah.com]
  Sent: Monday, September 29, 2014 11:56 AM

You are responding to a very old email, why?

  On Mon, Sep 29, 2014 at 03:46:02AM +, nikhil.bad...@freescale.com
  wrote:
   -Original Message-
   From: Greg KH [mailto:g...@kroah.com]
   Sent: Wednesday, September 24, 2014 10:19 AM
   To: Badola Nikhil-B46172
   Cc: linux-usb@vger.kernel.org
   Subject: Re: [PATCH] drivers: usb :fsl: Add support for USB
   controller version-2.5
   
   On Thu, Aug 21, 2014 at 12:56:22PM +0530, Nikhil Badola wrote:
Add support for USB controller version-2.5 used in
T4240 rev2.0, T1024, B3421, T1040, T2080, LS1021A.
   
Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com
---
   - Depends on commit 990c2c7829d98517228f2b2ff14919c83b75e124
 drivers: usb: fsl: Check IP version 2.4 for mph USB controller
   
 drivers/usb/host/fsl-mph-dr-of.c | 5 +
 include/linux/fsl_devices.h  | 1 +
 2 files changed, 6 insertions(+)
   
diff --git a/drivers/usb/host/fsl-mph-dr-of.c
b/drivers/usb/host/fsl-mph-dr-of.c
index e0315de..45b9e36 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -127,6 +127,7 @@ static int usb_get_ver_info(struct device_node
  *np)
* returns 1 for usb controller version 1.6
* returns 2 for usb controller version 2.2
* returns 3 for usb controller version 2.4
+   * returns 4 for usb controller version 2.5
* returns 0 otherwise
*/
   if (of_device_is_compatible(np, fsl-usb2-dr)) { @@ -136,6
+137,8 @@ static int usb_get_ver_info(struct device_node *np)
   ver = FSL_USB_VER_2_2;
   else if (of_device_is_compatible(np, 
fsl-usb2-dr-v2.4))
   ver = FSL_USB_VER_2_4;
+  else if (of_device_is_compatible(np, 
fsl-usb2-dr-v2.5))
+  ver = FSL_USB_VER_2_5;
   else /* for previous controller versions */
   ver = FSL_USB_VER_OLD;
   
@@ -153,6 +156,8 @@ static int usb_get_ver_info(struct device_node
  *np)
   ver = FSL_USB_VER_2_2;
   else if (of_device_is_compatible(np, 
fsl-usb2-mph-v2.4))
   ver = FSL_USB_VER_2_4;
+  else if (of_device_is_compatible(np, 
fsl-usb2-mph-v2.5))
+  ver = FSL_USB_VER_2_5;
   else /* for previous controller versions */
   ver = FSL_USB_VER_OLD;
   }
diff --git a/include/linux/fsl_devices.h
b/include/linux/fsl_devices.h index a82296a..2a2f56b 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -24,6 +24,7 @@
 #define FSL_USB_VER_1_6   1
 #define FSL_USB_VER_2_2   2
 #define FSL_USB_VER_2_4   3
+#define FSL_USB_VER_2_5   4
   
   Why not just keep going and add the rest of the numbers while you are at
  it?
  
   This is the last controller version of this family hence there would
   not be any requirement to add further numbers.
  
  People always bring products back, you never know this :)
  
   Seriously, what are these two patches doing?  You just set the value,
   never do anything with it, what good is it?
  
   We indeed use these macros for controller version specific code, for
   example in following snippet from ehci-fsl.c if (pdata-have_sysif_regs 
   pdata-controller_ver  FSL_USB_VER_1_6 
   (phy_mode == FSL_USB2_PHY_ULPI)) {
   /* check PHY_CLK_VALID to get phy clk valid */ .
   .
   If we don't set the macros then by default FSL_USB_VER_OLD, which is
   0, is assigned as controller version and in that case phy_clk_valid bit 
   would
  not be checked for controller version 2.4 and 2.5.
  
  You are relying on a define to be  a specific value, which seems wrong as 
  it's
  impossible to figure this type of thing out.  Please use an enumerated type 
  at
  the very least if you want to test this type of thing.
  
 
 Patch for replacing macros with enumerated type sent

When?  Where?
--
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: ulpi: don't register drivers if bus doesn't exist

[Greg KH]

On Mon, May 25, 2015 at 02:40:10PM +0300, Heikki Krogerus wrote:
 Hi,
 
  Why do we even need that? If you take patch that makes ulpi_init a
  subsys_initcall you won't have this problem, and no additional weird
  hacks and errors will be needed
 
 Using subsys_initcall will work around the problem for now, but I
 would not make the assumption that there will never be ulpi phy
 drivers and ulpi interface drivers that don't use subsys_initcall
 themselves. By checking the old phy drivers at drivers/usb/phy/, at
 least so far it hasn't been uncommon for them to use subsys_initcall.
 
 I would much prefer to have a proper fix for this issue instead of
 just working around it, but we need to use subsys_initcall in any
 case.
 
+   /* Was the bus registered successfully? */
+   if (!ulpi_bus.p)
+   return -ENODEV;
  
   Ick, no, don't go mucking around in the bus internals like this, that's
   not ok.  You should either know the bus is registered, or something is
   really wrong with the design here.
   can't we use a variable which can be initialized to 1 in ulpi_init() if
   the bus registers successfully and later check that?
 
 Just a note. We should also be aware if the bus registration failed or
 if it just hasn't been loaded yet.
 
 If we used a variable like that, I guess it could initially have the
 value -EAGAIN. If bus_register returns error, we store -ENODEV to it.
 If bus_register succeeds we store 0 to it. I don't know if we can just
 store the return value from bus_register to it.
 
 In ulpi_register_driver and ulpi_register_interface we can then just
 return it if it has a value other then 0.
 
 But couldn't we add a helper function to drivers/base/bus.c that the
 bus drivers can use to at least check was the bus already loaded or
 not? It looks like there are a couple of bus drivers that use the
 struct bus member p to check that.
 
 Greg, what do you think?

I think your design is wrong if you need to worry about this :)

If there are other bus drivers that do this, I'll go fix them up,
pointers to those files would be appreciated.

thanks,

greg k-h
--
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: ulpi: don't register drivers if bus doesn't exist

[Bjørn Mork]

Greg KH gre...@linuxfoundation.org writes:

 If there are other bus drivers that do this, I'll go fix them up,
 pointers to those files would be appreciated.

git grep -E 'if .*\.p\W' found a couple of interesting candidates you
might want to check out:

 drivers/i2c/i2c-core.c: if (unlikely(WARN_ON(!i2c_bus_type.p))) {
 drivers/i2c/i2c-core.c: if (unlikely(WARN_ON(!i2c_bus_type.p)))
 drivers/spmi/spmi.c:if (WARN_ON(!spmi_bus_type.p))

And this looks somewhat suspicious too, but could very well be OK for
all I know (very close to nothing :)

 drivers/gpio/gpiolib-sysfs.c:   if (!gpio_class.p) {
 drivers/gpio/gpiolib-sysfs.c:   if (!gpio_class.p)



Bjørn
--
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/5] usb: xhci: cleanup xhci_hcd allocation

[Mathias Nyman]

 I've been testing add/remove HCD extensively and didn't observe any issues 
 after applying
 these 5 patches. Well there is one issue that comes up but it has nothing 
 to do with xhci
 not being allocated. It has more to do with command being queued after the 
 HCD has gone away
 and so getting stuck forever without timing out.

 I went through the codepaths and you're right, should work fine. My concern 
 wasn't valid.
 This patchset doesn't even touch the order how primary and shared HCDs are 
 created and added
 in the PCI case, only for the platform device case.

 I'll try it out and send forward once rc1 is out.

 did you get a chance to try this series?

 
 Sorry, not yet, got delayed by other internal tasks.
 I'll try it out as soon as possible.
 


Ok, back to this, I'd like to get both this series and Andrew's xhci-tegra
support to 4.2

I did similar changes to xhci-tegra.c as Roger did to xhci-pci.c and 
xhci-plat.c,
but I can't test them and would need both your eyes on this to make sure it 
looks ok.

Both series are in a tegra_otg_merge topic branch in:
  
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git tegra_otg_merge

It contains Andrews full xhci tegra support series, but If I understood 
correctly only
patch 9/9 (maybe 8/9 as well?) will actually go through the xhci tree. 
Patch 1/9 is not needed with Roger's changes anymre  

The changes are in the last patch, here:
https://git.kernel.org/cgit/linux/kernel/git/mnyman/xhci.git/commit/?h=tegra_otg_merge

and would be squashed together with patch 9/9.

Thanks
Mathias 
--
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 00/21] On-demand device registration

[Tomeu Vizoso]

Hello,

I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or playing with
initcall levels.

While reading the thread [1] that Alexander Holler started with his series to
make probing order deterministic, it occurred to me that it should be possible
to achieve the same by registering devices as they are referenced by other
devices.

This basically reuses the information that is already implicit in the probe()
implementations, saving us from refactoring existing drivers or adding
information to DTBs.

Something I'm not completely happy with is that I have had to move the call to
of_platform_populate after all platform drivers have been registered.
Otherwise I don't see how I could register drivers on demand as we don't have
yet each driver's compatible strings.

For machs that don't move of_platform_populate() to a later point, these
patches shouldn't cause any problems but it's not guaranteed that we'll avoid
all the deferred probes as some drivers may not be registered yet.

I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
patches were enough to eliminate all the deferred probes.

With this series I get the kernel to output to the panel in 0.5s, instead of 
2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

Tomeu Vizoso (21):
  regulator: core: Reduce critical area in _regulator_get
  ARM: tegra: Add gpio-ranges property
  ARM: tegra: Register drivers before devices
  ARM: EXYNOS: Register drivers before devices
  ARM i.MX6q: Register drivers before devices
  of/platform: Add of_platform_device_ensure()
  of/platform: Ensure device registration on lookup
  gpio: Probe GPIO drivers on demand
  gpio: Probe pinctrl devices on demand
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c master devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on demand
  dma: of: Probe DMA controllers on demand
  power-supply: Probe power supplies on demand

 arch/arm/boot/dts/tegra124.dtsi |  1 +
 arch/arm/mach-exynos/exynos.c   |  4 +--
 arch/arm/mach-imx/mach-imx6q.c  | 12 -
 arch/arm/mach-tegra/tegra.c | 21 ++-
 drivers/clk/clk.c   |  3 +++
 drivers/dma/of-dma.c|  3 +++
 drivers/gpio/gpiolib-of.c   |  5 
 drivers/gpu/drm/drm_panel.c |  3 +++
 drivers/gpu/drm/tegra/dpaux.c   |  3 +++
 drivers/i2c/i2c-core.c  |  3 +++
 drivers/of/platform.c   | 53 +
 drivers/phy/phy-core.c  |  3 +++
 drivers/pinctrl/devicetree.c|  2 ++
 drivers/power/power_supply_core.c   |  3 +++
 drivers/pwm/core.c  |  3 +++
 drivers/regulator/core.c| 45 +++
 drivers/usb/phy/phy.c   |  3 +++
 drivers/video/backlight/backlight.c |  3 +++
 include/linux/of_platform.h |  2 ++
 19 files changed, 130 insertions(+), 45 deletions(-)

-- 
2.4.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: usb:gadget:hid:Add BOOT mode support

[Alan Stern]

On Mon, 25 May 2015, Golmer Palmer wrote:

 Alan Stern stern@... writes:
 
   I feel that this person ins't at time maintaining this source code.
  
  You seem to be right, since his email address doesn't work any more.
  
   I'm suposing that this mailing list is readed by very competent 
 people 
   that can implement this simple change. I hope someone likes to fix 
   that problem...
  
  I took a look at the driver.  The change you seem to be asking for is
  not simple at all.
  
  The problem is that the f_hid driver doesn't support either the Report
  or Boot protocols.  Instead, it relies on a user program to generate 
 or
  consume the reports that get sent to/from the host.  Currently the
  driver has no way to inform the user program about which protocol to
  use, and the program has no way to tell the driver when the protocol 
  is changed.
  
  Your original email message said:
  
   The problem is that several Keyboard and Mouse implementations using 
 this 
   framework are in fact fully compatible with BOOT mode.
  
  As far as I can tell, an implementation can support either the Report
  or Boot protocol, but not both.  The problem is that when you use a
  keyboard or mouse during boot-up, the BIOS will want to use the Boot
  protocol, and once the boot-up is complete, the operating system will
  want to switch to the Report protocol.
 
 Hi Alan,
 
 Thank you for your response and the patch.
 
 First a comment:
 
 Please, take into account that I mentioned that the ASSUMPTION that 
 keyboard and mouse drivers are compatible with BOTH protocols is really 
 TRUE.

No, it isn't.  You said several Keyboard and Mouse implementations
using this framework are in fact fully compatible with BOOT mode.  
This means that other implementations are _not_ compatible with Boot
mode.  The assumption is _sometimes_ true and _sometimes_ false.

  Then any program that implements keyboard and/or mouse emulation 
 is only implementing the BOOT protocol (6KRO for keyboard and 3button 
 for mouse). The real problem is that the driver don't implements the two 
 needed functions [ Get_Protocol()  Set_Protocol() ], although the 
 program implements the BOOT protocol. Remember that BOOT protocol is 
 only a subset of REPORT protocol; and no one has interest in 
 implementing a more complex keyboard or mouse target. So, the question 
 is why the hid usb gadget driver don't implements these two functions 
 for supporting the BOOT protocol? When the device is compatible with 
 both protocols, the status info reported by the driver is not relevant, 
 and this is the point that I suggest to change: report the change 
 instead what is doing the program, because the two protocols are the 
 same.

But then the driver would do the wrong thing in cases where the program 
is not compatible with the Boot protocol.

  The patch below adds support for Get Protocol and Set Protocol, but
  only for one protocol at a time (switching is not supported).  Does
  this do what you want?
 
 Related to your patch, if the default mode is BOOT, I feel it can work. 
 However, why not implement the change? If both protocols are the same, 
 the change can be done with any trouble.

The reason for not implementing the change is because the change _will_ 
cause trouble in cases where the protocols are not the same.

If there was some way for the program to tell the driver that it was 
compatible with both protocols, then the driver could safely implement 
the change.  But there is no way for the program to do this.

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

PROBLEM: USB drive errors with newer kernel versions

[Gary Dalmadge]

[1.] One line summary of the problem:

USB drive errors with newer kernel versions


[2.] Full description of the problem/report:

I am seeing various USB drive errors while trying to use the drives with later 
versions of the kernel.

I have tested with 4.1-rc5 and still see the issues.

For instance, I am unable to successfully create a new file system on the 
drives. 

One example is parted -l which returns the following error: Error 
fsyncing/closing /dev/sdc: Remote I/O error

dmesg shows the following error in this case: end_request: critical target 
error, dev sdc, sector 0

The errors appear with different brands and types of USB drives.

After a kernel bisect, this seems to be the commit that caused the issue:

89fb4cd1f717a871ef79fa7debbe840e3225cd54
scsi: handle flush errors properly


[3.] Keywords (i.e., modules, networking, kernel):


[4.] Kernel information

[4] Kernel version (from /proc/version):
Linux version 4.1.0-040100rc5-generic (kernel@gloin) (gcc version 4.6.3 
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201505250235 SMP Mon May 25 02:37:02 UTC 
2015


[5.] Output of Oops.. message (if applicable) with symbolic information
 resolved (see Documentation/oops-tracing.txt)
 

[6.] A small shell script or example program which triggers the
problem (if possible)

 parted -l
 

[7.] EnvironmentDescription:

Ubuntu 14.04.2 LTS
Release:14.04


[7.1.] Software (add the output of the ver_linux script here)

Linux gary-av 4.1.0-040100rc5-generic #201505250235 SMP Mon May 25 02:37:02 
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 
Gnu C  4.8
Gnu make   3.81
binutils   2.24
util-linux 2.20.1
mount  support
module-init-tools  15
e2fsprogs  1.42.9
pcmciautils018
PPP2.4.5
Linux C Library2.19
Dynamic linker (ldd)   2.19
Procps 3.3.9
Net-tools  1.60
Kbd1.15.5
Sh-utils   8.21
wireless-tools 30
Modules Loaded uas usb_storage nouveau snd_intel8x0 mxm_wmi wmi 
snd_ac97_codec video ac97_bus ttm snd_pcm drm_kms_helper snd_seq_midi drm 
snd_seq_midi_event snd_rawmidi snd_seq i2c_algo_bit snd_seq_device snd_timer 
snd soundcore edac_core serio_raw edac_mce_amd k8temp shpchp 8250_fintek 
ppdev i2c_nforce2 lp parport_pc parport mac_hid pata_acpi psmouse pata_amd 
forcedeth sata_nv floppy


[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 39
model name  : AMD Athlon(tm) 64 Processor 4000+
stepping: 1
cpu MHz : 2411.075
cache size  : 1024 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat 
pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow 
rep_good nopl pni lahf_lm 3dnowprefetch vmmcall
bugs: fxsave_leak sysret_ss_attrs
bogomips: 4822.15
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc


[7.3.] Module information (from /proc/modules):

uas 24576 0 - Live 0x
usb_storage 69632 1 uas, Live 0x
nouveau 1429504 3 - Live 0x
snd_intel8x0 40960 4 - Live 0x
mxm_wmi 16384 1 nouveau, Live 0x
wmi 20480 2 nouveau,mxm_wmi, Live 0x
snd_ac97_codec 139264 1 snd_intel8x0, Live 0x
video 28672 1 nouveau, Live 0x
ac97_bus 16384 1 snd_ac97_codec, Live 0x
ttm 102400 1 nouveau, Live 0x
snd_pcm 110592 2 snd_intel8x0,snd_ac97_codec, Live 0x
drm_kms_helper 126976 1 nouveau, Live 0x
snd_seq_midi 16384 0 - Live 0x
drm 352256 6 nouveau,ttm,drm_kms_helper, Live 0x
snd_seq_midi_event 16384 1 snd_seq_midi, Live 0x
snd_rawmidi 32768 1 snd_seq_midi, Live 0x
snd_seq 69632 2 snd_seq_midi,snd_seq_midi_event, Live 0x
i2c_algo_bit 16384 1 nouveau, Live 0x
snd_seq_device 16384 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 
0x
snd_timer 32768 2 snd_pcm,snd_seq, Live 0x
snd 86016 15 
snd_intel8x0,snd_ac97_codec,snd_pcm,snd_rawmidi,snd_seq,snd_seq_device,snd_timer,
 
Live 0x
soundcore 16384 1 snd, Live 0x
edac_core 53248 0 - Live 0x
serio_raw 16384 0 - Live 0x
edac_mce_amd 24576 0 - Live 0x
k8temp 16384 0 - Live 0x
shpchp 40960 0 - Live 0x
8250_fintek 16384 0 - Live 0x
ppdev 20480 0 - Live 0x

Re: [Bulk] seagate SRD00f2 expansion 4Tb desktop drive does not work on USB 3.0 Part 2 xhci-debug SOLVED

[Donald Harter]

Yes, this fixed the problem.  Thanks for your help.
Here is the kernel version that I compiled:
Linux  4.1.0-rc2+ #2 SMP Mon May 25 10:58:36 CDT 2015 x86_64 x86_64 
x86_64 GNU/Linux


On the non-working generic ubuntu kernel,the USB 3.0 ports that time out 
became non-working.  I could plug my other working USB 3.0 devices into 
that port, and they would not come up.  So maybe if there is a timeout, 
you should consider resetting such a port on the chip.  For a while I 
thought that some of my usb 3.0 ports were bad.



May 25 13:38:50 (none) mtp-probe: checking bus 2, device 7: 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.4

May 25 13:38:50 (none) mtp-probe: bus: 2, device: 7 was not an MTP device
May 25 13:38:51 (none) kernel: [  222.919894] scsi 9:0:0:0: 
Direct-Access Seagate  Expansion Desk   0739 PQ: 0 ANSI: 6
May 25 13:38:51 (none) kernel: [  222.920119] sd 9:0:0:0: Attached scsi 
generic sg6 type 0
May 25 13:38:51 (none) kernel: [  222.921015] sd 9:0:0:0: [sdf] Spinning 
up disk...

May 25 13:39:01 (none) kernel: [  228.375368] ..ready
May 25 13:39:01 (none) kernel: [  233.395760] sd 9:0:0:0: [sdf] 
976754645 4096-byte logical blocks: (3.90 TB/3.63 TiB)
May 25 13:39:01 (none) kernel: [  233.396383] sd 9:0:0:0: [sdf] Write 
Protect is off
May 25 13:39:01 (none) kernel: [  233.396390] sd 9:0:0:0: [sdf] Mode 
Sense: 2b 00 10 08
May 25 13:39:01 (none) kernel: [  233.396945] sd 9:0:0:0: [sdf] Write 
cache: enabled, read cache: enabled, supports DPO and FUA
May 25 13:39:01 (none) kernel: [  233.397602] sd 9:0:0:0: [sdf] 
976754645 4096-byte logical blocks: (3.90 TB/3.63 TiB)

May 25 13:39:01 (none) kernel: [  233.435743]  sdf: sdf1
May 25 13:39:01 (none) kernel: [  233.436474] sd 9:0:0:0: [sdf] 
976754645 4096-byte logical blocks: (3.90 TB/3.63 TiB)
May 25 13:39:01 (none) kernel: [  233.437674] sd 9:0:0:0: [sdf] Attached 
SCSI disk


Bus 002 Device 007: ID 0bc2:3312 Seagate RSS LLC
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 9
  idVendor   0x0bc2 Seagate RSS LLC
  idProduct  0x3312
  bcdDevice7.39
  iManufacturer   1 Seagate
  iProduct2 Expansion Desk
  iSerial 3 NA4MZS4N
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  121
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower2mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
:
iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   7
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0a  EP 10 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   7
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   1
  bNumEndpoints   4
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 98
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x08  EP 8 OUT
:  bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   0
Command pipe (0x01)
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval 

Re: [PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option

[Arun Ramamurthy]

On 15-05-14 05:52 PM, Felipe Balbi wrote:

Hi,

On Wed, Apr 22, 2015 at 04:04:10PM -0700, Arun Ramamurthy wrote:

Most of the phy providers use select to enable GENERIC_PHY. Since select
is only recommended when the config is not visible, GENERIC_PHY is changed
an invisible option. To maintain consistency, all phy providers are changed
to select GENERIC_PHY and all non-phy drivers use depends on when the
phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic
dependency, so it is left as select.

Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com
---
  drivers/ata/Kconfig   | 1 -
  drivers/media/platform/exynos4-is/Kconfig | 2 +-
  drivers/phy/Kconfig   | 4 ++--
  drivers/usb/host/Kconfig  | 4 ++--
  drivers/video/fbdev/exynos/Kconfig| 2 +-
  5 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 5f60155..6d2e881 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -301,7 +301,6 @@ config SATA_MV
tristate Marvell SATA support
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
   ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
-   select GENERIC_PHY
help
  This option enables support for the Marvell Serial ATA family.
  Currently supports 88SX[56]0[48][01] PCI(-X) chips,
diff --git a/drivers/media/platform/exynos4-is/Kconfig 
b/drivers/media/platform/exynos4-is/Kconfig
index b7b2e47..b6f3eaa 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC
  config VIDEO_S5P_MIPI_CSIS
tristate S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver
depends on REGULATOR
-   select GENERIC_PHY
+   depends on GENERIC_PHY
help
  This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2
  receiver (MIPI-CSIS) devices.
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2962de2..edecdb1 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -5,7 +5,7 @@
  menu PHY Subsystem

  config GENERIC_PHY
-   bool PHY Core
+   bool
help
  Generic PHY support.

@@ -72,7 +72,7 @@ config PHY_MIPHY365X
  config PHY_RCAR_GEN2
tristate Renesas R-Car generation 2 USB PHY driver
depends on ARCH_SHMOBILE
-   depends on GENERIC_PHY
+   select GENERIC_PHY


so some you changed from depends to select...


help
  Support for USB PHY found on Renesas R-Car generation 2 SoCs.

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5ad60e4..e2197e2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR
  config USB_EHCI_HCD_STI
tristate Support for ST STiHxxx on-chip EHCI USB controller
depends on ARCH_STI  OF
-   select GENERIC_PHY
+   depends on GENERIC_PHY


while others you changed from select to depends.

NAK.

Felipe, I dont understand your concern, could you please explain it more 
detail?  The logic behind the changes is that in cases where there was 
an explicit dependency, I changed it to depends on and in other cases 
I changed it to selects. 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 v3 00/11] usbip: features to USB over WebSocket

[fx IWATA NOBUO]

Hi,

 Maybe with other daemon or if you write your own one you will get 
 better performance. It is obvious that it will never be as fast as 
 dedicated implementation but the difference may be small enough.

Yes.
If there's any other trick other than TCP/IP loopback, please, let me 
know.

Thank you,

n.iwata
//

[PATCH] usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset

[Robert Schlabbach]

Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.

Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().

Verbose Problem Description:

USB 3.0 devices may be lost for good during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.

The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following warm reset.

However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the preliminary status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.

Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.

Link: 
http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach rober...@gmx.net
---
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3b71516..fd787de 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2616,9 +2616,6 @@ static bool use_new_scheme(struct usb_device *udev, int 
retry)
return USE_NEW_SCHEME(retry);
 }
 
-static int hub_port_reset(struct usb_hub *hub, int port1,
-   struct usb_device *udev, unsigned int delay, bool warm);
-
 /* Is a USB 3.0 port in the Inactive or Compliance Mode state?
  * Port worm reset is required to recover
  */
@@ -2706,44 +2703,6 @@ static int hub_port_wait_reset(struct usb_hub *hub, int 
port1,
return 0;
 }
 
-static void hub_port_finish_reset(struct usb_hub *hub, int port1,
-   struct usb_device *udev, int *status)
-{
-   switch (*status) {
-   case 0:
-   /* TRSTRCY = 10 ms; plus some extra */
-   msleep(10 + 40);
-   if (udev) {
-   struct usb_hcd *hcd = bus_to_hcd(udev-bus);
-
-   update_devnum(udev, 0);
-   /* The xHC may think the device is already reset,
-* so ignore the status.
-*/
-   if (hcd-driver-reset_device)
-   hcd-driver-reset_device(hcd, udev);
-   }
-   /* FALL THROUGH */
-   case -ENOTCONN:
-   case -ENODEV:
-   usb_clear_port_feature(hub-hdev,
-   port1, USB_PORT_FEAT_C_RESET);
-   if (hub_is_superspeed(hub-hdev)) {
-   usb_clear_port_feature(hub-hdev, port1,
-   USB_PORT_FEAT_C_BH_PORT_RESET);
-   usb_clear_port_feature(hub-hdev, port1,
-   USB_PORT_FEAT_C_PORT_LINK_STATE);
-   usb_clear_port_feature(hub-hdev, port1,
-   USB_PORT_FEAT_C_CONNECTION);
-   }
-   if (udev)
-   usb_set_device_state(udev, *status
-   ? USB_STATE_NOTATTACHED
-   : USB_STATE_DEFAULT);
-   break;
-   }
-}
-
 /* Handle port reset and port warm(BH) reset (for USB3 protocol ports) */
 static int hub_port_reset(struct usb_hub *hub, int port1,
struct usb_device *udev, unsigned int delay, bool warm)
@@ -2767,13 +2726,10 @@ static int hub_port_reset(struct usb_hub *hub, int 
port1,
 * If the caller hasn't explicitly requested a warm reset,
 * double check and see if one is needed.
 */
-   status = hub_port_status(hub, port1,
-   portstatus, portchange);
-   if (status  0)
-   goto done;
-
-   if (hub_port_warm_reset_required(hub, port1, portstatus))
-   warm = true;
+   if (hub_port_status(hub, port1, portstatus, portchange) == 0)
+   if (hub_port_warm_reset_required(hub, port1,
+   portstatus))
+   warm = true;
}
clear_bit(port1, hub-warm_reset_bits);
 
@@ 

RE: [PATCH v2 2/2] usb: renesas_usbhs: Add support for R-Car E2

[Yoshihiro Shimoda]

Hi Felipe,

 Sent: Monday, May 18, 2015 8:56 PM
 
 On Mon, May 18, 2015 at 1:04 PM, Yoshihiro Shimoda
 yoshihiro.shimoda...@renesas.com wrote:
  This patch adds a compatible string to support for R-Car E2.
 
  Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
  Acked-by: Geert Uytterhoeven geert+rene...@glider.be in patch 2
  ---
   Remarks: Geert's Acked-by is for the DT binding part (renesas_usbhs.txt).
 
 For the remaining part:
 Acked-by: Geert Uytterhoeven geert+rene...@glider.be

Would you apply this patch set to your testing/next branch?
I confirmed that this patch set could be applied on the latest testing/next 
branch.
(commit id = 672bfdaa310004368a0d493478e2a40f2f2f914f)

Best regards,
Yoshihiro Shimoda

 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

Re: [Bulk] seagate SRD00f2 expansion 4Tb desktop drive does not work on USB 3.0 Part 2 xhci-debug SOLVED

[Lu, Baolu]

On 05/26/2015 03:06 AM, Donald Harter wrote:

Yes, this fixed the problem.  Thanks for your help.


That doesn't mean exactly that this change fixes your problem.

I would suggest you to try the latest kernel without any changes
to check whether the fix is already there. Then you can go ahead
with changing the timeout value to check whether it helps.


Here is the kernel version that I compiled:
Linux  4.1.0-rc2+ #2 SMP Mon May 25 10:58:36 CDT 2015 x86_64 x86_64 
x86_64 GNU/Linux


On the non-working generic ubuntu kernel,the USB 3.0 ports that time 
out became non-working.  I could plug my other working USB 3.0 devices 
into that port, and they would not come up.  So maybe if there is a 
timeout, you should consider resetting such a port on the chip.  For a 
while I thought that some of my usb 3.0 ports were bad.


The USB 3.0 port non-working issue might be due to CEC error
not cleared. Again, I would suggest you to check with the latest
kernel version. If the port non-working issue still exists, you can
report a bug in the bugzilla and forward that to this mailing list
somebody will assume the responsibility to get it fixed.




May 25 13:38:50 (none) mtp-probe: checking bus 2, device 7: 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.4

May 25 13:38:50 (none) mtp-probe: bus: 2, device: 7 was not an MTP device
May 25 13:38:51 (none) kernel: [  222.919894] scsi 9:0:0:0: 
Direct-Access Seagate  Expansion Desk   0739 PQ: 0 ANSI: 6
May 25 13:38:51 (none) kernel: [  222.920119] sd 9:0:0:0: Attached 
scsi generic sg6 type 0
May 25 13:38:51 (none) kernel: [  222.921015] sd 9:0:0:0: [sdf] 
Spinning up disk...

May 25 13:39:01 (none) kernel: [  228.375368] ..ready
May 25 13:39:01 (none) kernel: [  233.395760] sd 9:0:0:0: [sdf] 
976754645 4096-byte logical blocks: (3.90 TB/3.63 TiB)
May 25 13:39:01 (none) kernel: [  233.396383] sd 9:0:0:0: [sdf] Write 
Protect is off
May 25 13:39:01 (none) kernel: [  233.396390] sd 9:0:0:0: [sdf] Mode 
Sense: 2b 00 10 08
May 25 13:39:01 (none) kernel: [  233.396945] sd 9:0:0:0: [sdf] Write 
cache: enabled, read cache: enabled, supports DPO and FUA
May 25 13:39:01 (none) kernel: [  233.397602] sd 9:0:0:0: [sdf] 
976754645 4096-byte logical blocks: (3.90 TB/3.63 TiB)

May 25 13:39:01 (none) kernel: [  233.435743]  sdf: sdf1
May 25 13:39:01 (none) kernel: [  233.436474] sd 9:0:0:0: [sdf] 
976754645 4096-byte logical blocks: (3.90 TB/3.63 TiB)
May 25 13:39:01 (none) kernel: [  233.437674] sd 9:0:0:0: [sdf] 
Attached SCSI disk


Bus 002 Device 007: ID 0bc2:3312 Seagate RSS LLC
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 9
  idVendor   0x0bc2 Seagate RSS LLC
  idProduct  0x3312
  bcdDevice7.39
  iManufacturer   1 Seagate
  iProduct2 Expansion Desk
  iSerial 3 NA4MZS4N
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  121
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower2mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
:
iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   7
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0a  EP 10 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   7
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   1
  bNumEndpoints   4
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 98
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x08  EP 8 OUT
:  bmAttributes2
  

Re: USB Host Controller no PCD interrupt and CCS and CSC update on the device disconnect

[Rong Wang]

Hi Alan,

On Mon, May 25, 2015 at 10:16 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Mon, 25 May 2015, Rong Wang wrote:

 On Fri, May 22, 2015 at 10:06 PM, Alan Stern st...@rowland.harvard.edu 
 wrote:
  On Fri, 22 May 2015, Rong Wang wrote:
 
  Hi,
 
  We have one USB 2.0 Controller on an ARM SoC, with internal PHY
  confirming to UTMI.
  The PHY would detect unexpected disconnect (amplitude of the
  differential envelop still  625 mV)
  and assert the HostDisconnect signal to the Controller to indicate a
  disconnection event.
  When the HostDisconnect signal is asserted, the Controller will first
  do some internal clean work
  before it update CCS and CSC in PORTSCx and reports a Port Change
  Detect interrupt.
  We want to improve the situation
 
  Why do you want to improve the situation?  What's wrong with the way it
  is now?  Detecting a disconnect while the differential amplitude is 
  625 mv is perfectly legal.  The USB-2.0 spec requires: Signals with
  differential amplitudes = 525 mV must never activate the Disconnection
  Envelope Detector (section 7.1.7.3).
 

 Our customer oberserved some unexpected disconnections during the
 shaking test (user scenario simulation). They want the disconnection
 detection to be less sensitive (= 625 mV). Because once the
 discoonection is reported, the APP SW will be re-launched and the USB
 device will also notify user the disconnection event, which is not
 accepted by our customer.

 It seems that your customer wants to change the hardware, not the
 software.

Yes. We plan to do a hardware modification. But we want to make as little
change as possible. So we plan to make the internal signal HostDisconnect
, which is sent from PHY to indicate a disconnection event, configurable
by software.
We'll mask this signal at first, once the software determines that there's a
disconnection event, we unmask this signal to notify the USB controller.
The advantage of this implementation is that the disconnection indication
signal will not go to USB controller directlly, thus no internal clean up work
will be done, which will make software recovery possible.
The disadvantage is that since there's no disconnection indication signal,
there's no PCD interrupt and no CCS and CSC update avalable. It's totally
determined by software.
We don't konw whether this implementation can handle all the corner cases.

BTW, how's the USB Device Controller (HS/FS) detetct the disconnection?
Does it detect the disconnection by a SE0 line status or by VBUS status?

Thanks!


  It sounds like you are going to make the situation worse, not improve
  it.

 We are going to filter the intermittent disconnection signal from PHY,
 but we must determine a true disconnection by driver with a retry scheme.
 I agree that it will make the situation more complicated because there may
 be many corner cases that we don't forsee and one of them may even
 make this workaround not workable.

 Sometimes there are hardware problems that can not be solved in
 software, or are too difficult to solve in software.  I think this is
 one of them.

 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