Re: Runtime PM enabled EHCI does not respond to device plugging.

[Kai-Heng Feng]

On Wed, May 24, 2017 at 12:43 AM, Alan Stern  wrote:
>>
>> Output of `cat /sys/kernel/debug/usb/usbmon/1u`:
>> Runtime PM disabled as attachment.
>
> When you say "runtime PM disabled", you mean that it is disabled for
> the EHCI controller but enabled for other devices, right?

Yes, disabled for the ehci-hcd. Runtime PM is enabled for ehci-pci.

>
>> It's empty when runtime PM is enabled.
>
> And nothing shows up in the dmesg log either?  This suggests that the
> PME signal isn't working properly.
>
> Try doing this: With runtime PM enabled, plug in a device.  When
> nothing happens, do:
>
> lspci -v -s 00:12.0
>
> The output should show whether the controller is sending a wakeup
> signal.  Does it cause the device to be detected?

No.

00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
EHCI Controller (rev 39) (prog-if 20 [EHCI])
Subsystem: Dell FCH USB EHCI Controller
Flags: 66MHz, medium devsel, IRQ 18
Memory at fe769000 (32-bit, non-prefetchable) [size=256]
Capabilities: [c0] Power Management version 2
Capabilities: [e4] Debug port: BAR=1 offset=00e0
Kernel driver in use: ehci-pci

> If it doesn't, run lsusb.  That definitely should wake up the
> controller and cause the device to be detected.  Then run the lspci
> command again.  Let's see what the output from these commands shows.

I plugged an optical mouse to test:
lsusb or "lsusb -s 001:001" does nothing, the mouse is not shown in
lsusb. The optical light is off.
"lsusb -s 001:001 -v" wakes up the controller and make the mouse to be
detected, the mouse is in lsusb and works correctly.
Once I turned on runtime PM on the mouse, it no longer works. The
optical light is still on but it did not response to movement or
click.

This is the lspci right after I use "lsusb -s 001:001 -v" to wake up
the controller:
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB
EHCI Controller (rev 39) (prog-if 20 [EHCI])
Subsystem: Dell FCH USB EHCI Controller
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18
Memory at fe769000 (32-bit, non-prefetchable) [size=256]
Capabilities: [c0] Power Management version 2
Capabilities: [e4] Debug port: BAR=1 offset=00e0
Kernel driver in use: ehci-pci
--
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: dwc2 audio gadget with high data rates

[Jassi Brar]

On Wed, May 24, 2017 at 12:22 AM, Francesco Lavra
 wrote:
> On Sun, May 21, 2017 at 4:42 PM, Francesco Lavra
>  wrote:
>> Hi,
>> I'm using the dwc2 OTG controller as a USB audio gadget (g_audio driver),
>> and I'm having trouble with making it work at high data rates, e.g. 192 kHz
>> sampling rate or 6 channels.
>> When I load the g_audio driver with the above parameters (p_srate=192000
>> p_chmask=0x3F), I get this error message "dwc2 ff58.usb:
>> dwc2_hsotg_ep_enable: No suitable fifo found", followed by a full stack
>> trace; as a result, the gadget driver is not operational. If I try to first
>> load the driver with its default parameters, then unload it and reload it
>> with the above parameters, then I don't see any error message, but the
>> driver misbehaves: when I send audio from the USB peripheral to a host, the
>> audio data is sent at the rate corresponding to the default parameters. For
>> example, a speaker-test run which is supposed to output audio for 3 seconds
>> to each channel takes a longer time, to be precise 36 seconds per channel,
>> i.e. 12 times the amount it should take. 12 is exactly the ratio between the
>> audio data rate with default parameters (48 kHz, 2 channels) and the rate
>> with the (p_srate=192000 p_chmask=0x3F) settings.
>> Using other combinations of parameter values, I get similar results, e.g.
>> the audio is 3 times slower if I use 6 channels with the default 48 kHz
>> sampling rate.
>>
>> So it looks like something gets misconfigured when the gadget driver is
>> loaded and unloaded multiple times with different parameters, but my main
>> question is about the "No suitable fifo found" error that I get when trying
>> to load the g_audio driver: does it stem for an inherent hardware limitation
>> of the dwc2 controller? is it specific to the SoC I'm using (Rockchip
>> rk3288)? or is it possible via code changes to the dwc2 driver to overcome
>> these issues?
>>
>> For the record, I'm using the latest kernel stable release (4.11.2).
>
> Since the g_audio module is now a legacy driver and there is a better
> way (configfs) for setting up a USB gadget as a UAC2 device, I tried
> following the configfs route, but unfortunately the end result is the
> same: above a certain audio data rate, when I bind the gadget to the
> UDC controller I get the "No suitable fifo found" error followed by a
> stack trace.
> I also tried to configure first the gadget with supported parameters
> (2 channels, 4 bytes per sample, 44.1 kHz), then disable the gadget
> and clean up its configuration, and then re-configure it with
> different parameter values (e.g. 96 kHz instead of 44.1): this time it
> doesn't give any error, but it is somehow using (at least in part) the
> older settings, because the audio flows at the same speed as it would
> flow with the older settings.
> So the behavior is the same as with the legacy g_audio driver. Any
> clue on what is going on? And is this a limitation of the UDC
> controller, or can the issue be solved with driver changes?
>
Some UDC controllers use fixed length buffer divided among all EPs so
no one EP may have large enough buffer to support high bandwidth
required, while others may have unnecessary space. So may be look into
the cause of message "No suitable fifo found"
--
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: typec: Add a sysfs node to manage port type

[Guenter Roeck]

On 05/23/2017 06:28 PM, Badhri Jagan Sridharan wrote:

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
   the current port type instead of changing type member in
   typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
   suggested by Heikki Krogerus.
>   Documentation/ABI/testing/sysfs-class-typec | 13 ++
  drivers/usb/typec/typec.c   | 66 +
  include/linux/usb/typec.h   |  4 ++
  3 files changed, 83 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..1f224c2e391f 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -73,6 +73,19 @@ Description:
  
  		Valid values: source, sink, none (to remove preference)
  
+What:   /sys/class/typec//port_type

+Date:   May 2017
+Description:
+   Indicates the type of the port. This attribute can be used for
+   requesting a change in the port type. Port type change is
+   supported as a synchronous operation, so write(2) to the
+   attribute will not return until the operation has finished.
+
+   Valid values:
+   - source
+   - sink
+   - dual
+
  What: /sys/class/typec//supported_accessory_modes
  Date: April 2017
  Contact:  Heikki Krogerus 
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..5063d6e0f8c7 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -69,6 +69,7 @@ struct typec_port {
enum typec_role pwr_role;
enum typec_role vconn_role;
enum typec_pwr_opmode   pwr_opmode;
+   enum typec_port_typeport_type;


I am missing where this variable is initialized (when the port is registered ?).

  
  	const struct typec_capability	*cap;

  };
@@ -789,6 +790,12 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
  };
  
+static const char * const typec_port_types[] = {

+   [TYPEC_PORT_DFP] = "source",
+   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_DRP] = "dual",
+};
+
  static ssize_t
  preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -856,6 +863,12 @@ static ssize_t data_role_store(struct device *dev,
return -EOPNOTSUPP;
}
  
+	if (port->port_type != TYPEC_PORT_DRP) {

+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   return -EIO;


?? This is already there, or am I missing something ?


+   }
+
ret = sysfs_match_string(typec_data_roles, buf);
if (ret < 0)
return ret;
@@ -897,6 +910,12 @@ static ssize_t power_role_store(struct device *dev,
return -EOPNOTSUPP;
}
  
+	if (port->port_type != TYPEC_PORT_DRP) {

+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   return -EIO;


Unrelated change; should be in a separate patch. Also, it should
probably return -EOPNOTSUPP.


+   }
+
if (port->pwr_opmode != TYPEC_PWR_MODE_PD) {
dev_dbg(dev, "partner unable to swap power role\n");
return -EIO;
@@ -926,6 +945,52 @@ static ssize_t power_role_show(struct device *dev,
  }
  static DEVICE_ATTR_RW(power_role);
  
+static ssize_t

+port_type_store(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t size)
+{
+   struct typec_port *port = to_typec_port(dev);
+   int ret, type;
+


I think 'type' should be 'enum typec_port_type'.


+   if (!port->cap->port_type_set || port->cap->type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "changing port type not supported\n");
+   return -EOPNOTSUPP;
+   }
+
+   ret = sysfs_match_string(typec_port_types, buf);
+   if (ret < 0)
+   return ret;
+

If the new type matches the current type, you could return immediately here.


+   type = ret;
+
+   ret = port->cap->port_type_set(port->cap, type);
+   if (ret)
+   return ret;
+
+   port->port_type = type;


We have no locking here, meaning a second request could be processed in 
parallel.
There is no guarantee that the resulting value in port->port_type matches
the actual port type

[PATCH v2] usb: typec: Add a sysfs node to manage port type

[Badhri Jagan Sridharan]

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
  the current port type instead of changing type member in
  typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
  suggested by Heikki Krogerus.

 Documentation/ABI/testing/sysfs-class-typec | 13 ++
 drivers/usb/typec/typec.c   | 66 +
 include/linux/usb/typec.h   |  4 ++
 3 files changed, 83 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..1f224c2e391f 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -73,6 +73,19 @@ Description:
 
Valid values: source, sink, none (to remove preference)
 
+What:   /sys/class/typec//port_type
+Date:   May 2017
+Description:
+   Indicates the type of the port. This attribute can be used for
+   requesting a change in the port type. Port type change is
+   supported as a synchronous operation, so write(2) to the
+   attribute will not return until the operation has finished.
+
+   Valid values:
+   - source
+   - sink
+   - dual
+
 What:  /sys/class/typec//supported_accessory_modes
 Date:  April 2017
 Contact:   Heikki Krogerus 
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..5063d6e0f8c7 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -69,6 +69,7 @@ struct typec_port {
enum typec_role pwr_role;
enum typec_role vconn_role;
enum typec_pwr_opmode   pwr_opmode;
+   enum typec_port_typeport_type;
 
const struct typec_capability   *cap;
 };
@@ -789,6 +790,12 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
 };
 
+static const char * const typec_port_types[] = {
+   [TYPEC_PORT_DFP] = "source",
+   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_DRP] = "dual",
+};
+
 static ssize_t
 preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -856,6 +863,12 @@ static ssize_t data_role_store(struct device *dev,
return -EOPNOTSUPP;
}
 
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   return -EIO;
+   }
+
ret = sysfs_match_string(typec_data_roles, buf);
if (ret < 0)
return ret;
@@ -897,6 +910,12 @@ static ssize_t power_role_store(struct device *dev,
return -EOPNOTSUPP;
}
 
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   return -EIO;
+   }
+
if (port->pwr_opmode != TYPEC_PWR_MODE_PD) {
dev_dbg(dev, "partner unable to swap power role\n");
return -EIO;
@@ -926,6 +945,52 @@ static ssize_t power_role_show(struct device *dev,
 }
 static DEVICE_ATTR_RW(power_role);
 
+static ssize_t
+port_type_store(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t size)
+{
+   struct typec_port *port = to_typec_port(dev);
+   int ret, type;
+
+   if (!port->cap->port_type_set || port->cap->type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "changing port type not supported\n");
+   return -EOPNOTSUPP;
+   }
+
+   ret = sysfs_match_string(typec_port_types, buf);
+   if (ret < 0)
+   return ret;
+
+   type = ret;
+
+   ret = port->cap->port_type_set(port->cap, type);
+   if (ret)
+   return ret;
+
+   port->port_type = type;
+
+   return size;
+}
+
+static ssize_t
+port_type_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct typec_port *port = to_typec_port(dev);
+
+   if (port->cap->type == TYPEC_PORT_DRP) {
+   if (port->port_type == TYPEC_PORT_DRP)
+   return sprintf(buf, "%s\n", "[dual] source sink");
+   else if (port->port_type == TYPEC_PORT_DFP)
+   return sprintf(buf, "%s\n", "dual [source] sink");
+   else
+   return sprintf(buf, "%s\n", "dual source [sink]"

USB hub clear POWER feature -> device still in 'lsusb' ?!

[Harald Welte]

Dear Linux Kernel USB hackers,

I'm facing the following overall problem / use case:

* there is an embedded device, attached to USB, with complex internal
  software, which every so often needs to be physically power cycled in
  order to reset all of its internal state.  In the particular case it's
  a cellular modem, but that doesn't really matter here

* in order to perform the power cycle, I use a (custom built) USB hub
  of which I'm sure that disabling the POWER feature of the hub port
  actually will control the downstream VBUS supply to the device

* In absence of any sysfs control or other API exposed to userland, I'm
  using uhubctl (https://github.com/mvp/uhubctl) to directly clear the
  POWER feature on said downstream USB port of the hub.

* The Linux kernel USB stack (tested up to 4.11) does notice this state
  change (I can see it doing GET_STATUS as a follow-up), but the USB
  device still stays in the USB tree, i.e. it shows up in lsusb despite
  being powered off.  This also means that all associated devices like
  cdc_acm, cdc_ether etc. still remain seen by applications, despite the
  device being gone

* Only when the device is turned on again via SET_FEATURE POWER, the
  USB device logical structure is remove from the kernel USB stack, and
  it subsequently re-enumerates.

I know that bypassin the kernel USB hub driver is probably not the
cleanest approach, but in absence of any API/sysfs to do so (forgive me
if I simply didn't find it), we have to resort to issuing CONTROL
requests to the USB hub directly.

As a work-around, I have found that issuing something like
"echo 1 > /sys/bus/usb/devices/1-4.1/remove"
will clear the ENABLE feature on the port and at the same time the
kernel code will call usb_remove_device() and hence it disappears from
lsusb as well as any associated device nodes re removed.

Hoewver, in this case I have not found any designated way to re-attach
the device.  Given that we're talking about embedded devices in
industrial applications installed at remote locations, and about a mPCIe
physical form factor, re-plugging the device simply won't be an option.

I'm wondering that after decades of a production-grade Linux USB stack,
why is there no standard method to re-enable such a port.  Once again,
if I'm missing it, please let me know.

Given that power cycling was the actual requirement at hand: With ENABLE
cleared via sysfs "remove", the POWER feature is still set and hence
power is still applied to the downstream usb port at this point.  But
then, as indicated above, I can use uhubctl to remove the power and
re-enable the power, which will make the device re-enumerate.

But this weird combination between sysfs on the one hand side and
directly issuing USB hub control requests via uhubctl on the other side
really looks ugly.  Is this really how one is supposed to power-cycle a
USB device?  It doesn't seam like such a completely odd requirement,
does it?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

[Stephen Boyd]

On 05/23, Fabien Lahoudere wrote:
> Hi,
> 
> We investigate on the topic and now our device tree look like:
> 
> in imx53.dtsi:
> 
> usbh2: usb@53f80400 {
>   compatible = "fsl,imx53-usb", "fsl,imx27-usb";
> reg = <0x53f80400 0x0200>;
> interrupts = <16>;
> clocks = <&clks IMX5_CLK_USBOH3_GATE>;
> fsl,usbmisc = <&usbmisc 2>;
> dr_mode = "host";
> status = "disabled";
> };
> 
> usbmisc: usbmisc@53f80800 {
>   #index-cells = <1>;
>   compatible = "fsl,imx53-usbmisc";
>   reg = <0x53f80800 0x200>;
>   clocks = <&clks IMX5_CLK_USBOH3_GATE>;
> };
> 
> and in our dts:
> 
> &usbh2 {
> pinctrl-names = "default";
>   pinctrl-0 = <&pinctrl_usbh2>;
>   disable-int60ck;
> dr_mode = "host";
> //fsl,usbphy = <&usbphy2>;
> vbus-supply = <®_usbh2_vbus>;
> status = "okay";
>   ulpi {
> phy {
> compatible = "smsc,usb3315-ulpi";
> reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
>   clock-names = "main_clk";
>   /*
>  * Hardware uses CKO2 at 24MHz at several places. Set 
> the parent
>    *  clock of CKO2 to OSC.
>  */
>   clock-frequency = <2400>;
>   clocks = <&clks IMX5_CLK_CKO2>;
> assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks 
> IMX5_CLK_OSC>;
>   assigned-clock-parents = <&clks IMX5_CLK_OSC>;
> status = "okay";
> };
> };
> };
> 
> And we create a basic driver to check what happened:
> 
> static int smsc_usb3315_phy_probe(struct ulpi *ulpi)
> {
> printk(KERN_ERR "Fabien: %s:%d-%s\n", __FILE__, __LINE__, __func__);
> 
> return 0;
> }
> 
> static const struct of_device_id smsc_usb3315_phy_match[] = {
> { .compatible = "smsc,usb3315-phy", },
> { }
> };
> MODULE_DEVICE_TABLE(of, smsc_usb3315_phy_match);
> 
> static struct ulpi_driver smsc_usb3315_phy_driver = {
> .probe = smsc_usb3315_phy_probe,
> .driver = {
> .name = "smsc_usb3315_phy",
> .of_match_table = smsc_usb3315_phy_match,
> },
> };
> module_ulpi_driver(smsc_usb3315_phy_driver);
> 
> /*MODULE_ALIAS("platform:usb_phy_generic");*/
> MODULE_AUTHOR("GE Healthcare");
> MODULE_DESCRIPTION("SMSC USB 3315 ULPI Phy driver");
> MODULE_LICENSE("GPL v2");
> 
> I checked that the driver is registered by 
> drivers/usb/common/ulpi.c:__ulpi_register_driver
> successfully.

Does the ulpi device have some vendor/product ids associated
with it? The design is made to only fallback to matching the
device to driver based on DT if the ulpi vendor id is 0.
Otherwise, if vendor is non-zero you'll need to have a
ulpi_device_id id table in your ulpi_driver structure.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt

[Thinh Nguyen]

Hi Felipe,

On 5/11/2017 6:12 PM, Thinh Nguyen wrote:
> On 4/11/2017 11:03 PM, Felipe Balbi wrote:
>> Thinh Nguyen  writes:
>> Felipe Balbi  writes:
>>> Thinh Nguyen  writes:
 This patch fixes a commit that causes a hang from device waiting for
 data with the wrong sequence number. The commit ffb80fc672c3 ("usb:
 dwc3: gadget: skip Set/Clear Halt when invalid") adds a check to return
 early depending on DWC3_EP_STALL is set or not, prevent sending the ep
 halt command to HW endpoint to do CLEAR_FEATURE(ENDPOINT_HALT) request.
 This was to workaround the issue for macOS where the device hangs from
 sending DWC3 clear stall command.

 In USB 3.1 spec, 9.4.5, CLEAR_FEATURE(ENDPOINT_HALT) request always
 results in the data sequence being reinitialized to zero regardless
 whether the endpoint has been halted or not. Some device class depends
 on this feature for its protocol. For instance, in mass storage class,
 there is MSC reset protocol that does CLEAR_FEATURE(ENDPOINT_HALT) on
 bulk endpoints. This protocol reinitializes the data sequence and
 ensures that whatever pending data requested from previous CBW will be
 reset. Otherwise this will cause a hang as the device can wait for the
 data with the wrong sequence number from the previous CBW. We found 
 this
 failure in USB CV: MSC Error Recovery Test with f_mass_storage.

 This patch fixes this issue by checking to see whether the set/halt ep
 call is a protocol call before early exit to make sure that set/clear
 halt endpoint command can go through if it is a device class protocol.

 Fixes: ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt when 
 invalid")
 Signed-off-by: Thinh Nguyen 
>>>
>>> this will regress the macOS case I wrote that commit for. We need to
>>
>> no wait, it won't regress macOS, but we're still left with the problem
>> of host and peripheral being able to get DataToggle/SeqN out of sync.
>>
>
> This patch is for the regression we have. Can you provide more
> information for the macOS? I'm not sure if this is the case for macOS,

 I need to find a way to reproduce it again first. When I first
 reproduced it was with dwc3 running adb and connecting it to a macOS
 machine.

> but maybe there is still pending transfer when it tries to send the
> request? (There shouldn't be any before issuing ClearStall command). Do

 this could be, I don't remember if I checked this or not :-)

 Really, the best way here, IMHO, would be to re-verify what's going on
 with macOS and revert my orignal patch since it's, rather clearly,
 wrong.

>>>
>>> Sure. Are you going to make a revert patch or I am?
>>
>> Well, after we really know what's going on with macOS and have a better
>> fix, then who makes the revert is less important as long as problems get
>> sorted out :-) Either way is fine for me.
>>
> 
> Do you have any update on this issue?
> 

The patch ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt when 
invalid") still causes a regression for us. As there hasn't any update 
for the macOS issue, can I submit a revert patch for this?

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

Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Baxter, Jim]

From: David S. Miller (da...@davemloft.net)
Sent: Tue, 23 May 2017 11:26:25 -0400 
> From: Oliver Neukum 
> Date: Tue, 23 May 2017 10:42:48 +0200
> 
>>
>> We could use a counter. After the first failure, do it once, after the
>> second twice and so on. And reset the counter as a higher order
>> allocation works. (just bound it somewhere)
> 
> So an exponential backoff, that might work.
> 

As an idea I have created this patch as an addition to the original patch
in this series.

Would this be acceptable?

At the moment I have capped the value at 10, does anyone think it needs to
be much higher then that?

Regards,
Jim


diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index c06d20f..0e40603 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -89,6 +89,8 @@ struct cdc_ncm_stats {
CDC_NCM_SIMPLE_STAT(rx_ntbs),
 };
 
+#define CDC_NCM_LOW_MEM_MAX_CNT 10
+
 static int cdc_ncm_get_sset_count(struct net_device __always_unused *netdev, 
int sset)
 {
switch (sset) {
@@ -,8 +1113,13 @@ struct sk_buff *
 
/* allocate a new OUT skb */
if (!skb_out) {
-   ctx->tx_curr_size = ctx->tx_max;
-   skb_out = alloc_skb(ctx->tx_curr_size, GFP_ATOMIC);
+   if (ctx->tx_low_mem_val == 0) {
+   ctx->tx_curr_size = ctx->tx_max;
+   skb_out = alloc_skb(ctx->tx_curr_size, GFP_ATOMIC);
+   if (skb_out == NULL) {
+   ctx->tx_low_mem_max_cnt = 
min(ctx->tx_low_mem_max_cnt + 1, CDC_NCM_LOW_MEM_MAX_CNT);
+   ctx->tx_low_mem_val = ctx->tx_low_mem_max_cnt;
+   }
if (skb_out == NULL) {
/* See if a very small allocation is possible.
 * We will send this packet immediately and hope
@@ -1127,12 +1134,13 @@ struct sk_buff *
 
/* No allocation possible so we will abort */
if (skb_out == NULL) {
-   if (skb != NULL) {
+   if (skb) {
dev_kfree_skb_any(skb);
dev->net->stats.tx_dropped++;
}
goto exit_no_skb;
}
+   ctx->tx_low_mem_val--;
}
/* fill out the initial 16-bit NTB header */
nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, 
sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16));
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index 5162f38..25a0aed 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -118,6 +118,8 @@ struct cdc_ncm_ctx {
u32 rx_max;
u32 tx_max;
u32 tx_curr_size;
+   u32 tx_low_mem_max_cnt;
+   u32 tx_low_mem_val;
u32 max_datagram_size;
u16 tx_max_datagrams;
u16 tx_remainder;
--
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: dwc2 audio gadget with high data rates

[Francesco Lavra]

On Sun, May 21, 2017 at 4:42 PM, Francesco Lavra
 wrote:
> Hi,
> I'm using the dwc2 OTG controller as a USB audio gadget (g_audio driver),
> and I'm having trouble with making it work at high data rates, e.g. 192 kHz
> sampling rate or 6 channels.
> When I load the g_audio driver with the above parameters (p_srate=192000
> p_chmask=0x3F), I get this error message "dwc2 ff58.usb:
> dwc2_hsotg_ep_enable: No suitable fifo found", followed by a full stack
> trace; as a result, the gadget driver is not operational. If I try to first
> load the driver with its default parameters, then unload it and reload it
> with the above parameters, then I don't see any error message, but the
> driver misbehaves: when I send audio from the USB peripheral to a host, the
> audio data is sent at the rate corresponding to the default parameters. For
> example, a speaker-test run which is supposed to output audio for 3 seconds
> to each channel takes a longer time, to be precise 36 seconds per channel,
> i.e. 12 times the amount it should take. 12 is exactly the ratio between the
> audio data rate with default parameters (48 kHz, 2 channels) and the rate
> with the (p_srate=192000 p_chmask=0x3F) settings.
> Using other combinations of parameter values, I get similar results, e.g.
> the audio is 3 times slower if I use 6 channels with the default 48 kHz
> sampling rate.
>
> So it looks like something gets misconfigured when the gadget driver is
> loaded and unloaded multiple times with different parameters, but my main
> question is about the "No suitable fifo found" error that I get when trying
> to load the g_audio driver: does it stem for an inherent hardware limitation
> of the dwc2 controller? is it specific to the SoC I'm using (Rockchip
> rk3288)? or is it possible via code changes to the dwc2 driver to overcome
> these issues?
>
> For the record, I'm using the latest kernel stable release (4.11.2).

Since the g_audio module is now a legacy driver and there is a better
way (configfs) for setting up a USB gadget as a UAC2 device, I tried
following the configfs route, but unfortunately the end result is the
same: above a certain audio data rate, when I bind the gadget to the
UDC controller I get the "No suitable fifo found" error followed by a
stack trace.
I also tried to configure first the gadget with supported parameters
(2 channels, 4 bytes per sample, 44.1 kHz), then disable the gadget
and clean up its configuration, and then re-configure it with
different parameter values (e.g. 96 kHz instead of 44.1): this time it
doesn't give any error, but it is somehow using (at least in part) the
older settings, because the audio flows at the same speed as it would
flow with the older settings.
So the behavior is the same as with the legacy g_audio driver. Any
clue on what is going on? And is this a limitation of the UDC
controller, or can the issue be solved with driver changes?

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

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

[Fabien Lahoudere]

Hi,

We investigate on the topic and now our device tree look like:

in imx53.dtsi:

usbh2: usb@53f80400 {
compatible = "fsl,imx53-usb", "fsl,imx27-usb";
reg = <0x53f80400 0x0200>;
interrupts = <16>;
clocks = <&clks IMX5_CLK_USBOH3_GATE>;
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
status = "disabled";
};

usbmisc: usbmisc@53f80800 {
#index-cells = <1>;
compatible = "fsl,imx53-usbmisc";
reg = <0x53f80800 0x200>;
clocks = <&clks IMX5_CLK_USBOH3_GATE>;
};

and in our dts:

&usbh2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh2>;
disable-int60ck;
dr_mode = "host";
//fsl,usbphy = <&usbphy2>;
vbus-supply = <®_usbh2_vbus>;
status = "okay";
ulpi {
phy {
compatible = "smsc,usb3315-ulpi";
reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
clock-names = "main_clk";
/*
 * Hardware uses CKO2 at 24MHz at several places. Set 
the parent
 *  clock of CKO2 to OSC.
 */
clock-frequency = <2400>;
clocks = <&clks IMX5_CLK_CKO2>;
assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks 
IMX5_CLK_OSC>;
assigned-clock-parents = <&clks IMX5_CLK_OSC>;
status = "okay";
};
};
};

And we create a basic driver to check what happened:

static int smsc_usb3315_phy_probe(struct ulpi *ulpi)
{
printk(KERN_ERR "Fabien: %s:%d-%s\n", __FILE__, __LINE__, __func__);

return 0;
}

static const struct of_device_id smsc_usb3315_phy_match[] = {
{ .compatible = "smsc,usb3315-phy", },
{ }
};
MODULE_DEVICE_TABLE(of, smsc_usb3315_phy_match);

static struct ulpi_driver smsc_usb3315_phy_driver = {
.probe = smsc_usb3315_phy_probe,
.driver = {
.name = "smsc_usb3315_phy",
.of_match_table = smsc_usb3315_phy_match,
},
};
module_ulpi_driver(smsc_usb3315_phy_driver);

/*MODULE_ALIAS("platform:usb_phy_generic");*/
MODULE_AUTHOR("GE Healthcare");
MODULE_DESCRIPTION("SMSC USB 3315 ULPI Phy driver");
MODULE_LICENSE("GPL v2");

I checked that the driver is registered by 
drivers/usb/common/ulpi.c:__ulpi_register_driver
successfully.

But our probe function (smsc_usb3315_phy_probe) is never called.

Our understanding is that we need to use the ulpi_bus instead of 
devm_usb_get_phy_by_phandle(&pdev-
>dev, "fsl,usbphy", 0); in drivers/usb/chipidea/ci_hdrc_imx.c.

Is our approach good?
How can we use this bus from our controller probe function ?

Thanks
Fabien

On Thu, 2017-04-20 at 16:50 +0800, Peter Chen wrote:
> On Wed, Apr 19, 2017 at 06:14:13AM +, Peter Senna Tschudin wrote:
> > We need the SMSC USB3315 clock and regulator to always be initialized.
> > We also need the PHY driver to take the PHY out of reset. This patch
> > extends the existing USB generic nop phy driver to include a new
> > initialization path.
> > 
> > A new compatible string "smsc,usb3315" is used to decide which
> > initialization path to use.
> > 
> 
> Hi Peter,
> 
> This is an ULPI PHY, so it is not suitable using generic USB PHY.
> Taking a look of drivers/phy/phy-qcom-usb-hs.c, you may have some
> clues.
> 
> Peter
> 
> > CC: Peter Chen 
> > CC: Stephen Boyd 
> > CC: Fabien Lahoudere 
> > Signed-off-by: Peter Senna Tschudin 
> > ---
> > 
> > This is a follow-up of previous discussion:
> >   https://www.spinics.net/lists/linux-usb/msg146680.html
> > 
> >  drivers/usb/phy/phy-generic.c | 33 +
> >  drivers/usb/phy/phy-generic.h |  1 +
> >  2 files changed, 30 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
> > index 89d6e7a..6ea9ce4 100644
> > --- a/drivers/usb/phy/phy-generic.c
> > +++ b/drivers/usb/phy/phy-generic.c
> > @@ -151,6 +151,9 @@ int usb_gen_phy_init(struct usb_phy *phy)
> >     struct usb_phy_generic *nop = dev_get_drvdata(phy->dev);
> >     int ret;
> >  
> > +   if (nop->init_done)
> > +   return 0;
> > +
> >     if (!IS_ERR(nop->vcc)) {
> >     if (regulator_enable(nop->vcc))
> >     dev_err(phy->dev, "Failed to enable power\n");
> > @@ -164,6 +167,8 @@ int usb_gen_phy_init(struct usb_phy *phy)
> >  
> >     nop_reset(nop);
> >  
> > +   nop->init_done = true;
> > +
> >     return 0;
> >  }
> >  EXPORT_SYMBOL_GPL(usb_gen_phy_init);
> > @@ -216,18 +221,29 @@ static int nop_set_host(struct usb_otg *otg, struct 
> > usb_bus *host)
> >     otg->host = host;
> >     return 0;
> >  }
> > +int smsc_usb3315_init(struct usb_phy_generic *nop)
> > +{
> > +   /*
> > +    * If the gpio for controlling reset state is not available, try again
> > +    * later
> > +    */
> > +   if(!nop->gpiod_reset)
> 

Re: [PATCH 1/3] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

* Alan Stern  [170523 09:57]:
> On Mon, 22 May 2017, Tony Lindgren wrote:
> > Alan, do you have some better ideas for the ohci_platform_remove()
> > path below?
...
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -290,7 +294,14 @@ static int ohci_platform_remove(struct platform_device 
> > *dev)
> > struct usb_hcd *hcd = platform_get_drvdata(dev);
> > struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
> > struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> > -   int clk, rst;
> > +   int clk, rst, enabled;
> > +
> > +   enabled = pm_runtime_get_sync(&dev->dev);
> > +   if (enabled < 0) {
> > +   dev_warn(&dev->dev, "pm_runtime_get failed: %i\n",
> > +enabled);
> > +   pm_runtime_put_noidle(&dev->dev);
> > +   }
> 
> I wouldn't worry about checking the return value.  There's no 
> particular reason for this call to fail, is there?

OK yeah if it was to fail it would already fail on probe
already :)

> > usb_remove_hcd(hcd);
> >  
> > @@ -305,6 +316,10 @@ static int ohci_platform_remove(struct platform_device 
> > *dev)
> >  
> > usb_put_hcd(hcd);
> >  
> > +   if (enabled >= 0)
> > +   pm_runtime_put_sync(&dev->dev);
> > +   pm_runtime_disable(&dev->dev);
> 
> And here you could just do the put_sync, with no test.  If the get_sync
> failed then this will probably fail too, but you won't be any worse off
> for the attempt.

OK fine with me.

Thanks,

Tony
--
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 3/3] usb: host: ohci-omap3: Remove driver in favor of ohci-platform

[Alan Stern]

On Mon, 22 May 2017, Tony Lindgren wrote:

> This driver is no longer needed and can be removed. The reason why
> it's safe to remove this driver is that most omap devices don't have a
> USB low-speed or full-speed compatible PHY installed and configured
> with drivers/mfd/omap-usb-host.c. This means that devices like
> beagleboard and pandaboard need to use a high-speed USB hub in order
> to use devices like keyboard and mice.
> 
> Currently the only known configured for a full-speed PHY is the
> mdm6600 modem on droid 4 and I've verified it works just fine with
> ohci-platform.
> 
> Cc: Roger Quadros 
> Cc: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/usb/host/Kconfig  |   6 +-
>  drivers/usb/host/Makefile |   1 -
>  drivers/usb/host/ohci-omap3.c | 211 
> --
>  3 files changed, 5 insertions(+), 213 deletions(-)
>  delete mode 100644 drivers/usb/host/ohci-omap3.c
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -473,8 +473,12 @@ config USB_OHCI_HCD_AT91
>  config USB_OHCI_HCD_OMAP3
>   tristate "OHCI support for OMAP3 and later chips"
>   depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
> + select USB_OHCI_HCD_PLATFORM
>   default y
> - ---help---
> + help
> +   This option is deprecated now and the driver was removed, use
> +   USB_OHCI_HCD_PLATFORM instead.
> +
> Enables support for the on-chip OHCI controller on
> OMAP3 and later chips.
>  
...

Acked-by: 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] usb: host: ohci-platform: Add basic runtime PM support

[Alan Stern]

On Mon, 22 May 2017, Tony Lindgren wrote:

> This is needed in preparation of adding support for omap3 and
> later OHCI. The runtime PM will only do something on platforms
> that implement it.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Hans de Goede 
> Cc: Rob Herring 
> Cc: Roger Quadros 
> Cc: Sebastian Reichel 
> Cc: Yoshihiro Shimoda 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Alan, do you have some better ideas for the ohci_platform_remove()
> path below?
> 
> ---
>  drivers/usb/host/ohci-platform.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ohci-platform.c 
> b/drivers/usb/host/ohci-platform.c
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -242,6 +243,8 @@ static int ohci_platform_probe(struct platform_device 
> *dev)
>   }
>  #endif
>  
> + pm_runtime_set_active(&dev->dev);
> + pm_runtime_enable(&dev->dev);
>   if (pdata->power_on) {
>   err = pdata->power_on(dev);
>   if (err < 0)
> @@ -271,6 +274,7 @@ static int ohci_platform_probe(struct platform_device 
> *dev)
>   if (pdata->power_off)
>   pdata->power_off(dev);
>  err_reset:
> + pm_runtime_disable(&dev->dev);
>   while (--rst >= 0)
>   reset_control_assert(priv->resets[rst]);
>  err_put_clks:
> @@ -290,7 +294,14 @@ static int ohci_platform_remove(struct platform_device 
> *dev)
>   struct usb_hcd *hcd = platform_get_drvdata(dev);
>   struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
>   struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> - int clk, rst;
> + int clk, rst, enabled;
> +
> + enabled = pm_runtime_get_sync(&dev->dev);
> + if (enabled < 0) {
> + dev_warn(&dev->dev, "pm_runtime_get failed: %i\n",
> +  enabled);
> + pm_runtime_put_noidle(&dev->dev);
> + }

I wouldn't worry about checking the return value.  There's no 
particular reason for this call to fail, is there?

>  
>   usb_remove_hcd(hcd);
>  
> @@ -305,6 +316,10 @@ static int ohci_platform_remove(struct platform_device 
> *dev)
>  
>   usb_put_hcd(hcd);
>  
> + if (enabled >= 0)
> + pm_runtime_put_sync(&dev->dev);
> + pm_runtime_disable(&dev->dev);

And here you could just do the put_sync, with no test.  If the get_sync
failed then this will probably fail too, but you won't be any worse off
for the attempt.

Alan Stern

> +
>   if (pdata == &ohci_platform_defaults)
>   dev->dev.platform_data = NULL;

--
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: Anomalies reported by usbtest module using testusb

[Alan Stern]

On Tue, 23 May 2017, Marek Pikarski wrote:

> Hi Alan,
> First of all, many thanks for the reply! Please read my comments below...
> 
> On 22.05.2017 21:46, Alan Stern wrote:
> > On Mon, 22 May 2017, Marek Pikarski wrote:
> >
> >> Hi!
> >>
> >> I am currently hunting the source of an issue that we have with an USB
> >> modem. There could even be some HW / board design issue.
> >>
> >> My idea was to try the kernel USB unit tests and this seems to work out
> >> as it gave me some interesting results!
> >>
> >> It would be so great if someone on this list had an idea what the test
> >> results mean and whether these results are pointing to a certain problem...
> >>
> >> Here the interesting part (TEST 10 is the one always failing) of the
> >> testusb output:
> >>
> >> # ./testusb -l -D /dev/bus/usb/001/003 -t 10
> >> unknown speed/dev/bus/usb/001/0030
> >> /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
> >> /dev/bus/usb/001/003 test 10,8.011131 secs
> >> /dev/bus/usb/001/003 test 10,8.010904 secs
> >> /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
> >> /dev/bus/usb/001/003 test 10 --> 121 (Remote I/O error)
> >> /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
> >> /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
> >> /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
> >> /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
> >> /dev/bus/usb/001/003 test 10,8.012122 secs
> >> /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
> >> ...
> > Test 10 tests how well control messages are handled when they are
> > queued up.  It has a large number of subcases that get tried
> > iteratively, and the whole thing is repeated, in this case 1000 times.
> 
> Do you possibly have any idea why its only TEST 10 which is failing?

No.

> Compared to the other tests, does TEST 10 (queued control messages) 
> require some special treatment by the HW or USB-bus or kernel or something?

Just the ability to manage a queue of control requests.

> Maybe you could even images what could be the reason for this? Like 
> USB-bus clock or speed?

No idea.

> >> And here the corresponding info from the usbtest kernel module (dmesg
> >> output):
> >>
> >> [15298.99] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 
> >> times
> >> [15300.33] usbtest 1-2:3.0: subtest 4 error, status -32
> >> [15300.33] usbtest 1-2:3.0: control queue 80.00, err -32, 26667
> >> left, subcase 4, len 0/2
> > Subtest 4 is a Get-Device-Status control request.  It is not expected
> > to fail.  The log indicates that the device sent a STALL instead of a
> > proper reply -- that's what the -32 means.  However, the subtest did
> > complete correctly over a hundred times before the failure occurred.
> >
> >> [15300.35] usbtest 1-2:3.0: subcase 5 completed out of order, last 3
> > This means subtest 3 was the one that completed previously.  This
> > should not happen -- requests are always supposed to complete in order,
> > so subtest 4 should have completed before 5.
> >
> >> [15300.35] usbtest 1-2:3.0: subcase 4 completed out of order, last 4
> > That's even weirder.  I don't see how that could happen.  But the
> > error pathways in this driver have not been tested thoroughly.
> 
> I also cannot understand why this can happen... Do you know at which 
> level this kind of Queue for these messages is implemented, is it kernel 
> driver or maybe device firmware?

In the kernel driver.

> >> [15300.37] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 
> >> times
> >> [15308.38] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 
> >> times
> >> [15316.39] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 
> >> times
> >> [15322.23] usbtest 1-2:3.0: subtest 4 error, status -32
> >> [15322.23] usbtest 1-2:3.0: control queue 80.00, err -32, 8715 left,
> >> subcase 4, len 0/2
> >> [15322.24] usbtest 1-2:3.0: subcase 5 completed out of order, last 3
> >> [15322.25] usbtest 1-2:3.0: subcase 4 completed out of order, last 4
> >> [15322.26] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 
> >> times
> >> [15324.87] usbtest 1-2:3.0: subtest 9 error, status -121
> >> [15324.87] usbtest 1-2:3.0: control queue 82.00, err -121, 21574
> >> left, subcase 9, len 0/2
> > Error code -121 means a short reply was received -- in this case 0
> > bytes instead of 2.
> >
> > The rest of the errors are all similar to these.
> >
> >> Looking forward to hear from you! Best regards, Marek
> > Bear in mind that the problem could lie in the test computer rather
> > than in the device!
> >
> 
> The traces above were produced when 2 (problem) devices were connected, 
> one of them running testusb on UST-Host, connected to the other device 
> with g_zero module loaded.
> When I run testusb on my notebook, still connected to one of the 
> devices, then I get the same results from TEST 10 except that
> 
> /dev/bus/usb/001/003 test 10 --> 121 (Remote I/O error)
> 
> never appears. There are

Re: Runtime PM enabled EHCI does not respond to device plugging.

[Alan Stern]

On Tue, 23 May 2017, Kai-Heng Feng wrote:

> >> Sorry for not explaining the original question well enough - the real
> >> problem is that after enabling runtime PM on EHCI, the two physical
> >> ports on the right side of the laptop no longer response to any
> >> device, e.g. an USB storage or an USB mouse.
> >
> > Please collect two usbmon traces: one with runtime PM disabled and one
> > with runtime PM enabled.  For each trace, start with nothing plugged
> > into the right-side ports.  Then after the trace has been running for a
> > second or two, plug in a device.  Stop the trace a couple of seconds
> > after that.
> 
> Output of `cat /sys/kernel/debug/usb/usbmon/1u`:
> Runtime PM disabled as attachment.

When you say "runtime PM disabled", you mean that it is disabled for 
the EHCI controller but enabled for other devices, right?

> It's empty when runtime PM is enabled.

And nothing shows up in the dmesg log either?  This suggests that the
PME signal isn't working properly.

Try doing this: With runtime PM enabled, plug in a device.  When 
nothing happens, do:

lspci -v -s 00:12.0

The output should show whether the controller is sending a wakeup 
signal.  Does it cause the device to be detected?

If it doesn't, run lsusb.  That definitely should wake up the 
controller and cause the device to be detected.  Then run the lspci 
command again.  Let's see what the output from these commands shows.

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 06/15] mlx5: Replace PCI pool old API

[David Miller]

From: Romain Perier 
Date: Tue, 23 May 2017 10:53:36 +0200

> Hello,
> 
> 
> Le 23/05/2017 à 09:27, Leon Romanovsky a écrit :
>> On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
>>> The PCI pool API is deprecated. This commit replaces the PCI pool old
>>> API by the appropriate function with the DMA pool API.
>>>
>>> Signed-off-by: Romain Perier 
>>> Reviewed-by: Peter Senna Tschudin 
>>> Acked-by: Doug Ledford 
>>> Tested-by: Doug Ledford 
>>> ---
>>>  drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
>>>  include/linux/mlx5/driver.h   |  2 +-
>>>  2 files changed, 7 insertions(+), 6 deletions(-)
>>>
>> Who is supposed to merge this patch series?
>>
>> Acked-by: Leon Romanovsky 
> Each maintainer of the corresponding subsystem, can take a patch, I
> guess. No ?

It might be easier to accumulate acks and you submit them as a series,
in my opinion.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[David Miller]

From: Oliver Neukum 
Date: Tue, 23 May 2017 10:42:48 +0200

> Am Montag, den 22.05.2017, 11:54 -0400 schrieb David Miller:
>> 
>> Unfortunately without a real notifier of some sort (there isn't one, and
>> it isn't actually easy to come up with a clean way to do this which is
>> probably why it doesn't exist yet in the first place) I really cannot
>> recommend anything better.
>> 
>> That being said, probably for the time being we should just backoff each
>> and every request, always trying initially to do the higher order thing.
> 
> We could use a counter. After the first failure, do it once, after the
> second twice and so on. And reset the counter as a higher order
> allocation works. (just bound it somewhere)

So an exponential backoff, that might work.
--
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] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

* Roger Quadros  [170523 00:14]:
> On 22/05/17 19:00, Tony Lindgren wrote:
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -290,7 +294,14 @@ static int ohci_platform_remove(struct platform_device 
> > *dev)
> > struct usb_hcd *hcd = platform_get_drvdata(dev);
> > struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
> > struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> > -   int clk, rst;
> > +   int clk, rst, enabled;
> > +
> > +   enabled = pm_runtime_get_sync(&dev->dev);
> 
> Why do we need to pm_runtime_get_sync() here?

ohci_platform_remove()
usb_remove_hcd()
ohci_stop()

Will cause "external abort on non-linefetch" otherwise.

Regards,

Tony
--
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: typec: Add a sysfs node to manage port type

[Guenter Roeck]

On 05/23/2017 06:39 AM, Heikki Krogerus wrote:

On Tue, May 23, 2017 at 06:16:28AM -0700, Guenter Roeck wrote:

On 05/23/2017 03:46 AM, Heikki Krogerus wrote:

Hi,

On Mon, May 22, 2017 at 01:05:42PM -0700, Badhri Jagan Sridharan wrote:

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
   Documentation/ABI/testing/sysfs-class-typec | 13 ++
   drivers/usb/typec/typec.c   | 40 
+
   include/linux/usb/typec.h   |  4 +++
   3 files changed, 57 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..853b2ef73641 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -73,6 +73,19 @@ Description:
Valid values: source, sink, none (to remove preference)
+What:   /sys/class/typec//port_type
+Date:   May 2017
+Description:
+   Indicates the type of the port. This attribute can be used for
+   requesting a change in the port type. Port type change is
+   supported as a synchronous operation, so write(2) to the
+   attribute will not return until the operation has finished.
+
+   Valid values:
+   - DRP
+   - DFP
+   - UFP

   What:/sys/class/typec//supported_accessory_modes
   Date:April 2017
   Contact: Heikki Krogerus 
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..684a13bb744d 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -789,6 +789,12 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
   };
+static const char * const typec_port_types[] = {
+   [TYPEC_PORT_DFP] = "dfp",
+   [TYPEC_PORT_UFP] = "ufp",
+   [TYPEC_PORT_DRP] = "drp",
+};


The meaning of those abbreviations has changed in every version of the
spec since v1.0 which makes me a bit uncomfortable using them with the
attributes. In USB Type-C specification v1.2, DRP now means
Dual-Role-Power, but DFP and UFP are used with USB data operation.

I would prefer "source, "sink" and "drp". Actually, I don't even like
"drp". How about "dual" instead?


   static ssize_t
   preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -926,6 +932,39 @@ static ssize_t power_role_show(struct device *dev,
   }
   static DEVICE_ATTR_RW(power_role);
+static ssize_t
+port_type_store(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t size)
+{
+   struct typec_port *port = to_typec_port(dev);
+   int ret;
+
+   if (!port->cap->port_type_set) {
+   dev_dbg(dev, "changing port type not supported\n");
+   return -EOPNOTSUPP;
+   }
+
+   ret = sysfs_match_string(typec_port_types, buf);
+   if (ret < 0)
+   return ret;
+
+   ret = port->cap->port_type_set(port->cap, ret);
+   if (ret)
+   return ret;
+
+   return size;
+}
+
+static ssize_t
+port_type_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct typec_port *port = to_typec_port(dev);
+
+   return sprintf(buf, "%s\n", typec_port_types[port->cap->type]);
+}
+static DEVICE_ATTR_RW(port_type);


This doesn't tell the user the capabilities of the port. All the
supported roles should be listed here like with the other attributes,
the active one in brackets. This probable means we need a small
addition/change to the API too.


Sorry, not the API..


typec_capability already lists the port type. Presumably it can be
restricted to TYPEC_PORT_DFP or TYPEC_PORT_UFP only if it is reported
as TYPEC_PORT_DRP. Am I missing something ?


I mean, we should not overwrite the type member in typec_capability.
DRP capable port is still DRP capable even if we fix it to DFP or UFP.
So the active, fixed role, should be stored to struct typec_port.


Yes, you are right. Makes sense.

Thanks,
Guenter
--
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: typec: Add a sysfs node to manage port type

[Heikki Krogerus]

On Tue, May 23, 2017 at 06:16:28AM -0700, Guenter Roeck wrote:
> On 05/23/2017 03:46 AM, Heikki Krogerus wrote:
> > Hi,
> > 
> > On Mon, May 22, 2017 at 01:05:42PM -0700, Badhri Jagan Sridharan wrote:
> > > User space applications in some cases have the need to enforce a
> > > specific port type(DFP/UFP/DRP). This change allows userspace to
> > > attempt setting the desired port type. Low level drivers can
> > > however reject the request if the specific port type is not supported.
> > > 
> > > Signed-off-by: Badhri Jagan Sridharan 
> > > ---
> > >   Documentation/ABI/testing/sysfs-class-typec | 13 ++
> > >   drivers/usb/typec/typec.c   | 40 
> > > +
> > >   include/linux/usb/typec.h   |  4 +++
> > >   3 files changed, 57 insertions(+)
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> > > b/Documentation/ABI/testing/sysfs-class-typec
> > > index d4a3d23eb09c..853b2ef73641 100644
> > > --- a/Documentation/ABI/testing/sysfs-class-typec
> > > +++ b/Documentation/ABI/testing/sysfs-class-typec
> > > @@ -73,6 +73,19 @@ Description:
> > >   Valid values: source, sink, none (to remove preference)
> > > +What:   /sys/class/typec//port_type
> > > +Date:   May 2017
> > > +Description:
> > > + Indicates the type of the port. This attribute can be used for
> > > + requesting a change in the port type. Port type change is
> > > + supported as a synchronous operation, so write(2) to the
> > > + attribute will not return until the operation has finished.
> > > +
> > > + Valid values:
> > > + - DRP
> > > + - DFP
> > > + - UFP
> > > 
> > >   What:   /sys/class/typec//supported_accessory_modes
> > >   Date:   April 2017
> > >   Contact:Heikki Krogerus 
> > > diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
> > > index 89e540bb7ff3..684a13bb744d 100644
> > > --- a/drivers/usb/typec/typec.c
> > > +++ b/drivers/usb/typec/typec.c
> > > @@ -789,6 +789,12 @@ static const char * const typec_data_roles[] = {
> > >   [TYPEC_HOST]= "host",
> > >   };
> > > +static const char * const typec_port_types[] = {
> > > + [TYPEC_PORT_DFP] = "dfp",
> > > + [TYPEC_PORT_UFP] = "ufp",
> > > + [TYPEC_PORT_DRP] = "drp",
> > > +};
> > 
> > The meaning of those abbreviations has changed in every version of the
> > spec since v1.0 which makes me a bit uncomfortable using them with the
> > attributes. In USB Type-C specification v1.2, DRP now means
> > Dual-Role-Power, but DFP and UFP are used with USB data operation.
> > 
> > I would prefer "source, "sink" and "drp". Actually, I don't even like
> > "drp". How about "dual" instead?
> > 
> > >   static ssize_t
> > >   preferred_role_store(struct device *dev, struct device_attribute *attr,
> > >const char *buf, size_t size)
> > > @@ -926,6 +932,39 @@ static ssize_t power_role_show(struct device *dev,
> > >   }
> > >   static DEVICE_ATTR_RW(power_role);
> > > +static ssize_t
> > > +port_type_store(struct device *dev, struct device_attribute *attr,
> > > + const char *buf, size_t size)
> > > +{
> > > + struct typec_port *port = to_typec_port(dev);
> > > + int ret;
> > > +
> > > + if (!port->cap->port_type_set) {
> > > + dev_dbg(dev, "changing port type not supported\n");
> > > + return -EOPNOTSUPP;
> > > + }
> > > +
> > > + ret = sysfs_match_string(typec_port_types, buf);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + ret = port->cap->port_type_set(port->cap, ret);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + return size;
> > > +}
> > > +
> > > +static ssize_t
> > > +port_type_show(struct device *dev, struct device_attribute *attr,
> > > + char *buf)
> > > +{
> > > + struct typec_port *port = to_typec_port(dev);
> > > +
> > > + return sprintf(buf, "%s\n", typec_port_types[port->cap->type]);
> > > +}
> > > +static DEVICE_ATTR_RW(port_type);
> > 
> > This doesn't tell the user the capabilities of the port. All the
> > supported roles should be listed here like with the other attributes,
> > the active one in brackets. This probable means we need a small
> > addition/change to the API too.

Sorry, not the API..

> typec_capability already lists the port type. Presumably it can be
> restricted to TYPEC_PORT_DFP or TYPEC_PORT_UFP only if it is reported
> as TYPEC_PORT_DRP. Am I missing something ?

I mean, we should not overwrite the type member in typec_capability.
DRP capable port is still DRP capable even if we fix it to DFP or UFP.
So the active, fixed role, should be stored to struct typec_port.


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] usb: typec: Add a sysfs node to manage port type

[Guenter Roeck]

On 05/23/2017 03:46 AM, Heikki Krogerus wrote:

Hi,

On Mon, May 22, 2017 at 01:05:42PM -0700, Badhri Jagan Sridharan wrote:

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
  Documentation/ABI/testing/sysfs-class-typec | 13 ++
  drivers/usb/typec/typec.c   | 40 +
  include/linux/usb/typec.h   |  4 +++
  3 files changed, 57 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..853b2ef73641 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -73,6 +73,19 @@ Description:
  
  		Valid values: source, sink, none (to remove preference)
  
+What:   /sys/class/typec//port_type

+Date:   May 2017
+Description:
+   Indicates the type of the port. This attribute can be used for
+   requesting a change in the port type. Port type change is
+   supported as a synchronous operation, so write(2) to the
+   attribute will not return until the operation has finished.
+
+   Valid values:
+   - DRP
+   - DFP
+   - UFP

  What: /sys/class/typec//supported_accessory_modes
  Date: April 2017
  Contact:  Heikki Krogerus 
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..684a13bb744d 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -789,6 +789,12 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
  };
  
+static const char * const typec_port_types[] = {

+   [TYPEC_PORT_DFP] = "dfp",
+   [TYPEC_PORT_UFP] = "ufp",
+   [TYPEC_PORT_DRP] = "drp",
+};


The meaning of those abbreviations has changed in every version of the
spec since v1.0 which makes me a bit uncomfortable using them with the
attributes. In USB Type-C specification v1.2, DRP now means
Dual-Role-Power, but DFP and UFP are used with USB data operation.

I would prefer "source, "sink" and "drp". Actually, I don't even like
"drp". How about "dual" instead?


  static ssize_t
  preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -926,6 +932,39 @@ static ssize_t power_role_show(struct device *dev,
  }
  static DEVICE_ATTR_RW(power_role);
  
+static ssize_t

+port_type_store(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t size)
+{
+   struct typec_port *port = to_typec_port(dev);
+   int ret;
+
+   if (!port->cap->port_type_set) {
+   dev_dbg(dev, "changing port type not supported\n");
+   return -EOPNOTSUPP;
+   }
+
+   ret = sysfs_match_string(typec_port_types, buf);
+   if (ret < 0)
+   return ret;
+
+   ret = port->cap->port_type_set(port->cap, ret);
+   if (ret)
+   return ret;
+
+   return size;
+}
+
+static ssize_t
+port_type_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct typec_port *port = to_typec_port(dev);
+
+   return sprintf(buf, "%s\n", typec_port_types[port->cap->type]);
+}
+static DEVICE_ATTR_RW(port_type);


This doesn't tell the user the capabilities of the port. All the
supported roles should be listed here like with the other attributes,
the active one in brackets. This probable means we need a small
addition/change to the API too.


typec_capability already lists the port type. Presumably it can be
restricted to TYPEC_PORT_DFP or TYPEC_PORT_UFP only if it is reported
as TYPEC_PORT_DRP. Am I missing something ?


I do like the idea of being able to fix the role, assuming others are
OK with it too.



I am definitely ok with it.

Thanks,
Guenter
--
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: Anomalies reported by usbtest module using testusb

[Marek Pikarski]

Hi Alan,
First of all, many thanks for the reply! Please read my comments below...

On 22.05.2017 21:46, Alan Stern wrote:

On Mon, 22 May 2017, Marek Pikarski wrote:


Hi!

I am currently hunting the source of an issue that we have with an USB
modem. There could even be some HW / board design issue.

My idea was to try the kernel USB unit tests and this seems to work out
as it gave me some interesting results!

It would be so great if someone on this list had an idea what the test
results mean and whether these results are pointing to a certain problem...

Here the interesting part (TEST 10 is the one always failing) of the
testusb output:

# ./testusb -l -D /dev/bus/usb/001/003 -t 10
unknown speed/dev/bus/usb/001/0030
/dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
/dev/bus/usb/001/003 test 10,8.011131 secs
/dev/bus/usb/001/003 test 10,8.010904 secs
/dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
/dev/bus/usb/001/003 test 10 --> 121 (Remote I/O error)
/dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
/dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
/dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
/dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
/dev/bus/usb/001/003 test 10,8.012122 secs
/dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)
...

Test 10 tests how well control messages are handled when they are
queued up.  It has a large number of subcases that get tried
iteratively, and the whole thing is repeated, in this case 1000 times.


Do you possibly have any idea why its only TEST 10 which is failing?
Compared to the other tests, does TEST 10 (queued control messages) 
require some special treatment by the HW or USB-bus or kernel or something?


Maybe you could even images what could be the reason for this? Like 
USB-bus clock or speed?



And here the corresponding info from the usbtest kernel module (dmesg
output):

[15298.99] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 times
[15300.33] usbtest 1-2:3.0: subtest 4 error, status -32
[15300.33] usbtest 1-2:3.0: control queue 80.00, err -32, 26667
left, subcase 4, len 0/2

Subtest 4 is a Get-Device-Status control request.  It is not expected
to fail.  The log indicates that the device sent a STALL instead of a
proper reply -- that's what the -32 means.  However, the subtest did
complete correctly over a hundred times before the failure occurred.


[15300.35] usbtest 1-2:3.0: subcase 5 completed out of order, last 3

This means subtest 3 was the one that completed previously.  This
should not happen -- requests are always supposed to complete in order,
so subtest 4 should have completed before 5.


[15300.35] usbtest 1-2:3.0: subcase 4 completed out of order, last 4

That's even weirder.  I don't see how that could happen.  But the
error pathways in this driver have not been tested thoroughly.


I also cannot understand why this can happen... Do you know at which 
level this kind of Queue for these messages is implemented, is it kernel 
driver or maybe device firmware?



[15300.37] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 times
[15308.38] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 times
[15316.39] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 times
[15322.23] usbtest 1-2:3.0: subtest 4 error, status -32
[15322.23] usbtest 1-2:3.0: control queue 80.00, err -32, 8715 left,
subcase 4, len 0/2
[15322.24] usbtest 1-2:3.0: subcase 5 completed out of order, last 3
[15322.25] usbtest 1-2:3.0: subcase 4 completed out of order, last 4
[15322.26] usbtest 1-2:3.0: TEST 10:  queue 32 control calls, 1000 times
[15324.87] usbtest 1-2:3.0: subtest 9 error, status -121
[15324.87] usbtest 1-2:3.0: control queue 82.00, err -121, 21574
left, subcase 9, len 0/2

Error code -121 means a short reply was received -- in this case 0
bytes instead of 2.

The rest of the errors are all similar to these.


Looking forward to hear from you! Best regards, Marek

Bear in mind that the problem could lie in the test computer rather
than in the device!



The traces above were produced when 2 (problem) devices were connected, 
one of them running testusb on UST-Host, connected to the other device 
with g_zero module loaded.
When I run testusb on my notebook, still connected to one of the 
devices, then I get the same results from TEST 10 except that


/dev/bus/usb/001/003 test 10 --> 121 (Remote I/O error)

never appears. There are only

/dev/bus/usb/001/003 test 10 --> 32 (Broken pipe)

messages in this case... can one possibly conclude something from this 
fact...?

The devices I am speaking about have an Atmel at91 sam9260 controller.
Anyways, if you have any idea of any possibilities what could be wrong 
to produce such test results... that would be great help!


Many thanks!!! Marek

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

Re: [PATCH] usb:host:xhci:USB 3.1 Speed

['Greg KH']

On Tue, May 23, 2017 at 06:42:46PM +0800, yd_tseng wrote:
> Hi Greg,
> 
>  One of our xHCI host controlers has 3 extended speed protocol lists.  The
> content of extended speed protocol lists is shown as below.
>  In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
> is set as 0x10.  And then USB 3.0 is parsed.  However, the min_rev of
> usb3_rhub will be changed to 0x00.
>  If USB 3.1 device is connected behind this host controller, the speed of
> USB 3.1 device just reports 5G speed using lsusb.
> 
>   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
>  00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
>  10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
>  30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
>  50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
>  70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

All of this belongs in your changelog text please :)

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 v2] usb:host:xhci:USB 3.1 Speed

[Greg KH]

On Tue, May 23, 2017 at 06:50:49PM +0800, YD wrote:
> From: YD Tseng 
> 
> Hi Greg and Mathias,

Why is this here?  :)

Hint, send what you want in the changelog, in the changelog area,
anything else you want to say, put below the --- line, like
Documentation/SubmittingPatches says to do.

> 
> This patch works around for parsing extended speed protocol lists. 

Trailing space :(

> If the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
> it could show as one 3.1 roothub.

I don't understand, what does it do today?


> 
> Changes since v1:
> - change diff path

The changes go below ---


> 
> Signed-off-by: YD Tseng 
> 
> ---
> 
> diff -up linux/drivers/usb/host/xhci-mem.c{.orig,} > /tmp/patch

Where did this line come from?  git?

> --- linux/drivers/usb/host/xhci-mem.c.orig  2017-04-08 15:35:38.0 
> +0800
> +++ linux/drivers/usb/host/xhci-mem.c   2017-05-22 11:56:21.362907677 +0800
> @@ -2111,11 +2111,12 @@ static void xhci_add_in_port(struct xhci
>  {
> u32 temp, port_offset, port_count;
> int i;
> -   u8 major_revision;
> +   u8 major_revision, minor_revision;
> struct xhci_hub *rhub;
> 
> temp = readl(addr);

All of your tabs got changed into spaces, making this patch impossible
to apply :(

> major_revision = XHCI_EXT_PORT_MAJOR(temp);
> +   minor_revision = XHCI_EXT_PORT_MINOR(temp);
> 
> if (major_revision == 0x03) {
> rhub = &xhci->usb3_rhub;
> @@ -2129,7 +2130,9 @@ static void xhci_add_in_port(struct xhci
> return;
> }
> rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
> -   rhub->min_rev = XHCI_EXT_PORT_MINOR(temp);
> +
> +   if (rhub->min_rev < minor_revision)
> +   rhub->min_rev = minor_revision;

Why change the revision from what it was?

> 
> /* Port offset and count in the third dword, see section 7.2 */
> temp = readl(addr + 2);
> @@ -2280,6 +2283,8 @@ static int xhci_setup_port_arrays(struct
> 
> offset = cap_start;
> 
> +   xhci->usb3_rhub.min_rev = 0;
> +   xhci->usb2_rhub.min_rev = 0;

Why set these?  Are they not already cleared out at initialization time?

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: drivers/usb/host/xhci-ring.c:1390 handle_cmd_completion

[Mathias Nyman]

On 23.05.2017 12:50, Mathias Nyman wrote:

On 22.05.2017 18:42, Greg KH wrote:

On Fri, May 19, 2017 at 02:53:20PM +0200, Jason A. Donenfeld wrote:

I'm having this issue on kernel 4.11.0 and 4.11.1. It usually happens
after a while of ordinary USB use. Afterwards, USB does not work. If I
rmmod all the modules and reinsert them, it works for a while, but
even sooner after it stops working again.

[48112.422418] [ cut here ]
[48112.422441] WARNING: CPU: 0 PID: 14420 at
drivers/usb/host/xhci-ring.c:1390 handle_cmd_completion+0xb17/0xc00
[xhci_hcd]
[48112.422446] Modules linked in: xt_hashlimit ip6_udp_tunnel
udp_tunnel rfcomm pl2303 hid_lenovo bnep cdc_mbim cdc_ncm qcserial
cdc_wdm usb_wwan usbnet usbserial mii uvcvideo videobuf2_vmalloc
videobuf2_memops
[48112.422480] xhci_hcd :00:14.0: Timeout while waiting for setup
device command
[48112.422481] videobuf2_v4l2 videobuf2_core cdc_acm videodev btusb
btintel usbhid bluetooth af_packet nf_conntrack_ipv4 nf_defrag_ipv4
iptable_filter xt_hl nf_conntrack_ipv6 nf_defrag_ipv6 xt_multiport
8021q xt_conntrack nf_conntrack ip6table_filter ip6_tables
algif_skcipher joydev mousedev snd_hda_codec_realtek
snd_hda_codec_generic arc4 iwlmvm mac80211 rtsx_pci_sdmmc mmc_core
intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp
kvm_intel kvm iwlwifi snd_hda_intel ahci irqbypass snd_hda_codec
crc32_pclmul snd_hwdep xhci_pci xhci_hcd libahci crc32c_intel
snd_hda_core mei_me cfg80211 usbcore snd_pcm rtsx_pci ie31200_edac
input_leds mfd_core e1000e libata usb_common mei snd_timer psmouse
edac_core intel_pch_thermal thinkpad_acpi snd soundcore led_class
rfkill tpm_tis tpm_tis_core evdev
[48112.422556] tpm sch_fq_codel
[48112.422565] CPU: 0 PID: 14420 Comm: kworker/0:7 Tainted: P W O
4.11.1-gentoo #1
[48112.422567] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS
N1EET65W (1.38 ) 02/09/2017
[48112.422577] Workqueue: events xhci_handle_command_timeout [xhci_hcd]
[48112.422580] Call Trace:
[48112.422583] 
[48112.422589] ? dump_stack+0x46/0x5e
[48112.422595] ? __warn+0xb9/0xe0
[48112.422603] ? handle_cmd_completion+0xb17/0xc00 [xhci_hcd]
[48112.422609] ? try_to_wake_up+0x22e/0x390
[48112.422617] ? xhci_irq+0x38f/0x1460 [xhci_hcd]
[48112.422624] ? run_timer_softirq.part.2+0x4c/0xa0
[48112.422629] ? expire_timers+0x6e/0xe0
[48112.422634] ? __handle_irq_event_percpu+0x36/0x190
[48112.422637] ? handle_irq_event_percpu+0x1b/0x50
[48112.422640] ? handle_irq_event+0x22/0x40
[48112.422644] ? handle_edge_irq+0x65/0x120
[48112.422649] ? handle_irq+0x11/0x20
[48112.422653] ? do_IRQ+0x3c/0xc0
[48112.422658] ? common_interrupt+0x7f/0x7f
[48112.422660] 
[48112.422664] ? _raw_spin_unlock_irqrestore+0x5/0x10
[48112.422671] ? xhci_handle_command_timeout+0xf4/0x1b0 [xhci_hcd]
[48112.422684] ? process_one_work+0x1d9/0x450
[48112.422689] ? worker_thread+0x42/0x4b0
[48112.422695] ? process_one_work+0x450/0x450
[48112.422698] ? kthread+0x112/0x130
[48112.422702] ? kthread_create_on_node+0x40/0x40
[48112.422705] ? ret_from_fork+0x23/0x30
[48112.422709] ---[ end trace eb9505885b6e349e ]---
[48113.446247] xhci_hcd :00:14.0: xHCI host not responding to stop
endpoint command.
[48113.446250] xhci_hcd :00:14.0: Assuming host is dying, halting host.
[48113.446348] xhci_hcd :00:14.0: HC died; cleaning up


Ugh, that does not look good, Mathias, anything Jason can do here to
help debug this?



both traces and dynamic debugging could be useful here

mount -t debugfs none /sys/kernel/debug
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

then send output of both dmesg and /sys/kernel/debug/tracing/trace



Actually these symptoms match the xhci command ring stop regression in 4.11,
4.12-rc2 contains a fix, does that work?

fix is:
commit 604d02a2a66ab7f93fd3b2bde3698c29ef057b65

-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

RE: [PATCH] usb:host:xhci:USB 3.1 Speed

[yd_tseng]

Hi Greg,

 One of our xHCI host controlers has 3 extended speed protocol lists.  The
content of extended speed protocol lists is shown as below.
 In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set as 0x10.  And then USB 3.0 is parsed.  However, the min_rev of
usb3_rhub will be changed to 0x00.
 If USB 3.1 device is connected behind this host controller, the speed of
USB 3.1 device just reports 5G speed using lsusb.

  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
 00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org] 
Sent: Tuesday, May 23, 2017 5:18 PM
To: YD
Cc: mathias.ny...@intel.com; linux-usb@vger.kernel.org;
yd_ts...@asmedia.com.tw
Subject: Re: [PATCH] usb:host:xhci:USB 3.1 Speed

On Tue, May 23, 2017 at 03:00:47PM +0800, YD wrote:
> From: YD Tseng 
> 
> Hi Mathias,
> 
> This patch works around for parsing extended speed protocol lists. 
> If the xHCI controller supports USB 3.1 and 3.0 extended speed 
> protocol, it could show as one 3.1 roothub.
> 
> Signed-off-by: YD Tseng 
> 
> ---
> 
> A file is modified.
> drivers/usb/host/xhci-mem.c   Modified file

What does this mean?

> 
> diff -up xhci-mem{.orig,} > /tmp/patch
> --- xhci-mem.c.orig 2017-04-08 15:35:38.0 +0800
> +++ xhci-mem.c  2017-05-22 11:56:21.362907677 +0800

You need to make the patch "deeper", please see
Documentation/SubmittingPatches for how to create it properly.

thanks,

greg k-h

==
This email and any attachments to it contain confidential information and are 
intended solely for the use of the individual to whom it 
is addressed.If you are not the intended recipient or receive it accidentally, 
please immediately notify the sender by e-mail and delete 
the message and any attachments from your computer system, and destroy all hard 
copies. If any, please be advised that any unauthorized 
disclosure, copying, distribution or any action taken or omitted in reliance on 
this, is illegal and prohibited. Furthermore, any views 
or opinions expressed are solely those of the author and do not represent those 
of ASMedia Technology Inc. Thank you for your cooperation.
==

--
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: kernel does not receive any USB3.0 plug/unplug events from the Renesas upd720202 chipset

[Mathias Nyman]

On 22.05.2017 21:24, Xavier . wrote:

Hello and thanks

dmesg.4.12-rc1.with_dyndbg_pendrive_connected_at_boot_1r.txt (1r and
2n are very different on xhci)


[0.00] Linux version 4.12.0-041200rc1-generic (kernel@gomeisa)
(gcc version 6.3.0 20170510 (Ubuntu 6.3.0-17ubuntu1) ) #201705131731
SMP Sat May 13 21:48:41 UTC 2017

...

[4.281409] xhci_hcd :02:00.0: xHCI Host Controller
[4.281431] xhci_hcd :02:00.0: new USB bus registered, assigned
bus number 2
[4.281466] xhci_hcd :02:00.0: xHCI capability registers at f8452000:
[4.281473] xhci_hcd :02:00.0: CAPLENGTH AND HCIVERSION 0x120:
[4.281477] xhci_hcd :02:00.0: CAPLENGTH: 0x20
[4.281482] xhci_hcd :02:00.0: HCIVERSION: 0x100
[4.281489] xhci_hcd :02:00.0: HCSPARAMS 1: 0x4000820
[4.281493] xhci_hcd :02:00.0:   Max device slots: 32
[4.281498] xhci_hcd :02:00.0:   Max interrupters: 8
[4.281502] xhci_hcd :02:00.0:   Max ports: 4
[4.281509] xhci_hcd :02:00.0: HCSPARAMS 2: 0x2411
[4.281513] xhci_hcd :02:00.0:   Isoc scheduling threshold: 1
[4.281518] xhci_hcd :02:00.0:   Maximum allowed segments in
event ring: 1
[4.281524] xhci_hcd :02:00.0: HCSPARAMS 3 0x0:
[4.281529] xhci_hcd :02:00.0:   Worst case U1 device exit latency: 0
[4.281533] xhci_hcd :02:00.0:   Worst case U2 device exit latency: 0
[4.281540] xhci_hcd :02:00.0: HCC PARAMS 0x14051cf:
[4.281545] xhci_hcd :02:00.0:   HC generates 64 bit addresses
[4.281549] xhci_hcd :02:00.0:   HC hasn't Contiguous Frame ID Capability
[4.281554] xhci_hcd :02:00.0:   HC can't generate Stopped -
Short Package event
[4.281558] xhci_hcd :02:00.0:   FIXME: more HCCPARAMS debugging
[4.281565] xhci_hcd :02:00.0: RTSOFF 0x600:
[4.281570] xhci_hcd :02:00.0: xHCI operational registers at f8452020:
[4.281576] xhci_hcd :02:00.0: USBCMD 0x0:
[4.281581] xhci_hcd :02:00.0:   HC is being stopped
[4.281585] xhci_hcd :02:00.0:   HC has finished hard reset
[4.281589] xhci_hcd :02:00.0:   Event Interrupts disabled
[4.281594] xhci_hcd :02:00.0:   Host System Error Interrupts disabled
[4.281598] xhci_hcd :02:00.0:   HC has finished light reset
[4.281605] xhci_hcd :02:00.0: USBSTS 0x1:
[4.281609] xhci_hcd :02:00.0:   Event ring is empty
[4.281613] xhci_hcd :02:00.0:   No Host System Error
[4.281617] xhci_hcd :02:00.0:   HC is halted
[4.281625] xhci_hcd :02:00.0: f8452420 port status reg = 0x80
[4.281632] xhci_hcd :02:00.0: f8452424 port power reg = 0x0
[4.281640] xhci_hcd :02:00.0: f8452428 port link reg = 0x0
[4.281647] xhci_hcd :02:00.0: f845242c port reserved reg = 0x0
[4.281654] xhci_hcd :02:00.0: f8452430 port status reg = 0x80
[4.281661] xhci_hcd :02:00.0: f8452434 port power reg = 0x0
[4.281668] xhci_hcd :02:00.0: f8452438 port link reg = 0x0
[4.281676] xhci_hcd :02:00.0: f845243c port reserved reg = 0x0
[4.281683] xhci_hcd :02:00.0: f8452440 port status reg = 0x80
[4.281690] xhci_hcd :02:00.0: f8452444 port power reg = 0x0
[4.281697] xhci_hcd :02:00.0: f8452448 port link reg = 0x0
[4.281704] xhci_hcd :02:00.0: f845244c port reserved reg = 0x0
[4.281711] xhci_hcd :02:00.0: f8452450 port status reg = 0x80
[4.281718] xhci_hcd :02:00.0: f8452454 port power reg = 0x0
[4.281725] xhci_hcd :02:00.0: f8452458 port link reg = 0x0
[4.281732] xhci_hcd :02:00.0: f845245c port reserved reg = 0x0
[4.281738] xhci_hcd :02:00.0: QUIRK: Resetting on resume
[4.281743] xhci_hcd :02:00.0: // Halt the HC
[4.281755] xhci_hcd :02:00.0: Resetting HCD
[4.281762] xhci_hcd :02:00.0: // Reset the HC
[4.286927] xhci_hcd :02:00.0: Wait for controller to be ready
for doorbell rings
[4.286934] xhci_hcd :02:00.0: Reset complete
[4.286940] xhci_hcd :02:00.0: Enabling 64-bit DMA addresses.
[4.286944] xhci_hcd :02:00.0: Calling HCD init
[4.286949] xhci_hcd :02:00.0: xhci_init
[4.286953] xhci_hcd :02:00.0: xHCI doesn't need link TRB QUIRK
[4.286960] xhci_hcd :02:00.0: Supported page size register = 0x1
[4.286965] xhci_hcd :02:00.0: Supported page size of 4K
[4.286969] xhci_hcd :02:00.0: HCD page size set to 4K
[4.286976] xhci_hcd :02:00.0: // xHC can handle at most 32 device slots.
[4.286982] xhci_hcd :02:00.0: // Setting Max device slots reg = 0x20.
[4.287128] ata2: port disabled--ignoring
[4.287171] xhci_hcd :02:00.0: // Device context base array
address = 0x35617000 (DMA), f5617000 (virt)
[4.287194] xhci_hcd :02:00.0: Allocated command ring at f5615840
[4.287198] xhci_hcd :02:00.0: First segment DMA is 0x3562
[4.287207] xhci_hcd :02:00.0: // Setting command ring address
to 0x35620001
[4.287216] xhci_hcd 

[PATCH v2] usb:host:xhci:USB 3.1 Speed

[YD]

From: YD Tseng 

Hi Greg and Mathias,

This patch works around for parsing extended speed protocol lists. 
If the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
it could show as one 3.1 roothub.

Changes since v1:
- change diff path

Signed-off-by: YD Tseng 

---

diff -up linux/drivers/usb/host/xhci-mem.c{.orig,} > /tmp/patch
--- linux/drivers/usb/host/xhci-mem.c.orig  2017-04-08 15:35:38.0 
+0800
+++ linux/drivers/usb/host/xhci-mem.c   2017-05-22 11:56:21.362907677 +0800
@@ -2111,11 +2111,12 @@ static void xhci_add_in_port(struct xhci
 {
u32 temp, port_offset, port_count;
int i;
-   u8 major_revision;
+   u8 major_revision, minor_revision;
struct xhci_hub *rhub;

temp = readl(addr);
major_revision = XHCI_EXT_PORT_MAJOR(temp);
+   minor_revision = XHCI_EXT_PORT_MINOR(temp);

if (major_revision == 0x03) {
rhub = &xhci->usb3_rhub;
@@ -2129,7 +2130,9 @@ static void xhci_add_in_port(struct xhci
return;
}
rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
-   rhub->min_rev = XHCI_EXT_PORT_MINOR(temp);
+
+   if (rhub->min_rev < minor_revision)
+   rhub->min_rev = minor_revision;

/* Port offset and count in the third dword, see section 7.2 */
temp = readl(addr + 2);
@@ -2280,6 +2283,8 @@ static int xhci_setup_port_arrays(struct

offset = cap_start;

+   xhci->usb3_rhub.min_rev = 0;
+   xhci->usb2_rhub.min_rev = 0;
while (offset) {
xhci_add_in_port(xhci, num_ports, base + offset, cap_count);
if (xhci->num_usb2_ports + xhci->num_usb3_ports == num_ports)
--
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: typec: Add a sysfs node to manage port type

[Heikki Krogerus]

Hi,

On Mon, May 22, 2017 at 01:05:42PM -0700, Badhri Jagan Sridharan wrote:
> User space applications in some cases have the need to enforce a
> specific port type(DFP/UFP/DRP). This change allows userspace to
> attempt setting the desired port type. Low level drivers can
> however reject the request if the specific port type is not supported.
> 
> Signed-off-by: Badhri Jagan Sridharan 
> ---
>  Documentation/ABI/testing/sysfs-class-typec | 13 ++
>  drivers/usb/typec/typec.c   | 40 
> +
>  include/linux/usb/typec.h   |  4 +++
>  3 files changed, 57 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> b/Documentation/ABI/testing/sysfs-class-typec
> index d4a3d23eb09c..853b2ef73641 100644
> --- a/Documentation/ABI/testing/sysfs-class-typec
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -73,6 +73,19 @@ Description:
>  
>   Valid values: source, sink, none (to remove preference)
>  
> +What:   /sys/class/typec//port_type
> +Date:   May 2017
> +Description:
> + Indicates the type of the port. This attribute can be used for
> + requesting a change in the port type. Port type change is
> + supported as a synchronous operation, so write(2) to the
> + attribute will not return until the operation has finished.
> +
> + Valid values:
> + - DRP
> + - DFP
> + - UFP
> 
>  What:/sys/class/typec//supported_accessory_modes
>  Date:April 2017
>  Contact: Heikki Krogerus 
> diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
> index 89e540bb7ff3..684a13bb744d 100644
> --- a/drivers/usb/typec/typec.c
> +++ b/drivers/usb/typec/typec.c
> @@ -789,6 +789,12 @@ static const char * const typec_data_roles[] = {
>   [TYPEC_HOST]= "host",
>  };
>  
> +static const char * const typec_port_types[] = {
> + [TYPEC_PORT_DFP] = "dfp",
> + [TYPEC_PORT_UFP] = "ufp",
> + [TYPEC_PORT_DRP] = "drp",
> +};

The meaning of those abbreviations has changed in every version of the
spec since v1.0 which makes me a bit uncomfortable using them with the
attributes. In USB Type-C specification v1.2, DRP now means
Dual-Role-Power, but DFP and UFP are used with USB data operation.

I would prefer "source, "sink" and "drp". Actually, I don't even like
"drp". How about "dual" instead?

>  static ssize_t
>  preferred_role_store(struct device *dev, struct device_attribute *attr,
>const char *buf, size_t size)
> @@ -926,6 +932,39 @@ static ssize_t power_role_show(struct device *dev,
>  }
>  static DEVICE_ATTR_RW(power_role);
>  
> +static ssize_t
> +port_type_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + struct typec_port *port = to_typec_port(dev);
> + int ret;
> +
> + if (!port->cap->port_type_set) {
> + dev_dbg(dev, "changing port type not supported\n");
> + return -EOPNOTSUPP;
> + }
> +
> + ret = sysfs_match_string(typec_port_types, buf);
> + if (ret < 0)
> + return ret;
> +
> + ret = port->cap->port_type_set(port->cap, ret);
> + if (ret)
> + return ret;
> +
> + return size;
> +}
> +
> +static ssize_t
> +port_type_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct typec_port *port = to_typec_port(dev);
> +
> + return sprintf(buf, "%s\n", typec_port_types[port->cap->type]);
> +}
> +static DEVICE_ATTR_RW(port_type);

This doesn't tell the user the capabilities of the port. All the
supported roles should be listed here like with the other attributes,
the active one in brackets. This probable means we need a small
addition/change to the API too.

I do like the idea of being able to fix the role, assuming others are
OK with it too.


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: [RFC][PATCH 0/3] add EXTCON_CHG_USB_* cables to MSM USB phy

[Chanwoo Choi]

Hi,

On 2017년 05월 17일 22:12, Damien Riegel wrote:
> Hi,
> 
> On Fri, Apr 14, 2017 at 02:43:27PM -0400, Damien Riegel wrote:
>> This patchset adds a way for the MSM USB phy to notify a power supply
>> when the charging state changes. It achieves that using the extcon
>> subsystem.
>>
>> The first patch makes sure msm_otg_notify_charger is called after the
>> charger attributes have been set.
>> The second one makes sure that function is called when unplugging a
>> "in-the-wall" charger.
>> The last one adds EXTCON_CHG_USB_* cables to the phy.
>>
>>
>> I send this patchset as RFC because it seems a bit peculiar to have
>> different drivers that generate the EXTCON_USB_* and EXTCON_CHG_USB_*
>> events, so I want to make sure to get things right.
>>
>> As far as I can tell, all the drivers in the kernel that have USB
>> charger events also have the EXTCON_USB one. In this case, this patchset
>> would make things a bit different for the MSM phy:
>>
>>+--+  +--+
>>|   gpio   |  | PMIC |<-+
>>+--+  +--+  |
>>||  |
>>`+  |  EXTCON_CHG_USB_*
>> |  |   events
>> EXTCON_USB  |  |
>>   events|  |
>>\|/ |
>>  +--+  |
>>  |   USB PHY|--+
>>  +--+
>>
>> Text version: EXTCON_USB comes from a GPIO or a PMIC, that triggers a
>> notifier in the USB phy. That notifier will determine the new
>> EXTCON_CHG_USB_XXX state and the PMIC will be notified about it and
>> determine how much current it can use to charge a battery.
>>
>> Please let me know if this is the correct way to go.
> 
> I wanted to know if someone has any comment to make on this patchset?
> I'm currently working on the PMIC driver and it uses the EXTCON
> notifications, so I just want to make sure it makes sense to do that.

It looks like some strange situation. In this case, it seems like
that usb phy just uses the extcon as a notifier chain.


IMHO, USB PHY might handle the regulator provided by PMIC
instead of extcon notifier as following:
But, I'm not sure. It is just my opinion.

+--+  +--+
|   gpio   |  | PMIC |
+--+  +--+
||
`--+ |
   |  regulator
 EXTCON_USB  |
   events|
  \|/   \|/
   +--+
   |   USB PHY|
   +--+
   |
  \|/
   USB PHY may determine how much current
   it can use to charge a battery according
   to the charger cable. Because USB PHY
   know the kind of connected charger cable.

-- 
Best Regards,
Chanwoo Choi
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: drivers/usb/host/xhci-ring.c:1390 handle_cmd_completion

[Mathias Nyman]

On 22.05.2017 18:42, Greg KH wrote:

On Fri, May 19, 2017 at 02:53:20PM +0200, Jason A. Donenfeld wrote:

I'm having this issue on kernel 4.11.0 and 4.11.1. It usually happens
after a while of ordinary USB use. Afterwards, USB does not work. If I
rmmod all the modules and reinsert them, it works for a while, but
even sooner after it stops working again.

[48112.422418] [ cut here ]
[48112.422441] WARNING: CPU: 0 PID: 14420 at
drivers/usb/host/xhci-ring.c:1390 handle_cmd_completion+0xb17/0xc00
[xhci_hcd]
[48112.422446] Modules linked in: xt_hashlimit ip6_udp_tunnel
udp_tunnel rfcomm pl2303 hid_lenovo bnep cdc_mbim cdc_ncm qcserial
cdc_wdm usb_wwan usbnet usbserial mii uvcvideo videobuf2_vmalloc
videobuf2_memops
[48112.422480] xhci_hcd :00:14.0: Timeout while waiting for setup
device command
[48112.422481] videobuf2_v4l2 videobuf2_core cdc_acm videodev btusb
btintel usbhid bluetooth af_packet nf_conntrack_ipv4 nf_defrag_ipv4
iptable_filter xt_hl nf_conntrack_ipv6 nf_defrag_ipv6 xt_multiport
8021q xt_conntrack nf_conntrack ip6table_filter ip6_tables
algif_skcipher joydev mousedev snd_hda_codec_realtek
snd_hda_codec_generic arc4 iwlmvm mac80211 rtsx_pci_sdmmc mmc_core
intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp
kvm_intel kvm iwlwifi snd_hda_intel ahci irqbypass snd_hda_codec
crc32_pclmul snd_hwdep xhci_pci xhci_hcd libahci crc32c_intel
snd_hda_core mei_me cfg80211 usbcore snd_pcm rtsx_pci ie31200_edac
input_leds mfd_core e1000e libata usb_common mei snd_timer psmouse
edac_core intel_pch_thermal thinkpad_acpi snd soundcore led_class
rfkill tpm_tis tpm_tis_core evdev
[48112.422556] tpm sch_fq_codel
[48112.422565] CPU: 0 PID: 14420 Comm: kworker/0:7 Tainted: P W O
4.11.1-gentoo #1
[48112.422567] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS
N1EET65W (1.38 ) 02/09/2017
[48112.422577] Workqueue: events xhci_handle_command_timeout [xhci_hcd]
[48112.422580] Call Trace:
[48112.422583] 
[48112.422589] ? dump_stack+0x46/0x5e
[48112.422595] ? __warn+0xb9/0xe0
[48112.422603] ? handle_cmd_completion+0xb17/0xc00 [xhci_hcd]
[48112.422609] ? try_to_wake_up+0x22e/0x390
[48112.422617] ? xhci_irq+0x38f/0x1460 [xhci_hcd]
[48112.422624] ? run_timer_softirq.part.2+0x4c/0xa0
[48112.422629] ? expire_timers+0x6e/0xe0
[48112.422634] ? __handle_irq_event_percpu+0x36/0x190
[48112.422637] ? handle_irq_event_percpu+0x1b/0x50
[48112.422640] ? handle_irq_event+0x22/0x40
[48112.422644] ? handle_edge_irq+0x65/0x120
[48112.422649] ? handle_irq+0x11/0x20
[48112.422653] ? do_IRQ+0x3c/0xc0
[48112.422658] ? common_interrupt+0x7f/0x7f
[48112.422660] 
[48112.422664] ? _raw_spin_unlock_irqrestore+0x5/0x10
[48112.422671] ? xhci_handle_command_timeout+0xf4/0x1b0 [xhci_hcd]
[48112.422684] ? process_one_work+0x1d9/0x450
[48112.422689] ? worker_thread+0x42/0x4b0
[48112.422695] ? process_one_work+0x450/0x450
[48112.422698] ? kthread+0x112/0x130
[48112.422702] ? kthread_create_on_node+0x40/0x40
[48112.422705] ? ret_from_fork+0x23/0x30
[48112.422709] ---[ end trace eb9505885b6e349e ]---
[48113.446247] xhci_hcd :00:14.0: xHCI host not responding to stop
endpoint command.
[48113.446250] xhci_hcd :00:14.0: Assuming host is dying, halting host.
[48113.446348] xhci_hcd :00:14.0: HC died; cleaning up


Ugh, that does not look good, Mathias, anything Jason can do here to
help debug this?



both traces and dynamic debugging could be useful here

mount -t debugfs none /sys/kernel/debug
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

then send output of both dmesg and /sys/kernel/debug/tracing/trace

-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

Re: [PATCH] usb:host:xhci:USB 3.1 Speed

[Greg KH]

On Tue, May 23, 2017 at 03:00:47PM +0800, YD wrote:
> From: YD Tseng 
> 
> Hi Mathias,
> 
> This patch works around for parsing extended speed protocol lists. 
> If the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
> it could show as one 3.1 roothub.
> 
> Signed-off-by: YD Tseng 
> 
> ---
> 
> A file is modified.
> drivers/usb/host/xhci-mem.c   Modified file

What does this mean?

> 
> diff -up xhci-mem{.orig,} > /tmp/patch
> --- xhci-mem.c.orig 2017-04-08 15:35:38.0 +0800
> +++ xhci-mem.c  2017-05-22 11:56:21.362907677 +0800

You need to make the patch "deeper", please see
Documentation/SubmittingPatches for how to create it properly.

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 v2] usb/uhci: Add support for Aspeed BMC SoCs

[Greg KH]

On Tue, May 23, 2017 at 10:44:05AM +1000, Benjamin Herrenschmidt wrote:
> The Aspeed 2400/2500 families have a variant of UHCI which requires
> some quirks to the driver to work:
> 
>  - The register offsets are different. We add a remapping helper.
> 
>  - All accesses have to be done via 32-bit loads and stores. We
>force all accessors to use readl/writel. This is of no consequence
>for reads as we never read "in the middle" of a register. For writes
>it also works fine as the registers only actually implement the bits
>we try to write (16-bit for the registers accessed with writew and
>8-bit for the register accessed with writeb), so always using a
>32-bit write will have no negative effect. We never do partial writes.
> 
>  - The resume detect interrupt is broken
> 
>  - The number of ports is (optionally) provided via the device-tree
> 
> Signed-off-by: Benjamin Herrenschmidt 

Looks much nicer to me, thanks for the changes.

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 v9 06/15] mlx5: Replace PCI pool old API

[Leon Romanovsky]

On Tue, May 23, 2017 at 10:53:36AM +0200, Romain Perier wrote:
> Hello,
>
>
> Le 23/05/2017 à 09:27, Leon Romanovsky a écrit :
> > On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
> >> The PCI pool API is deprecated. This commit replaces the PCI pool old
> >> API by the appropriate function with the DMA pool API.
> >>
> >> Signed-off-by: Romain Perier 
> >> Reviewed-by: Peter Senna Tschudin 
> >> Acked-by: Doug Ledford 
> >> Tested-by: Doug Ledford 
> >> ---
> >>  drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
> >>  include/linux/mlx5/driver.h   |  2 +-
> >>  2 files changed, 7 insertions(+), 6 deletions(-)
> >>
> > Who is supposed to merge this patch series?
> >
> > Acked-by: Leon Romanovsky 
> Each maintainer of the corresponding subsystem, can take a patch, I
> guess. No ?

I wonder if they know that.

Dave,

Do you want us to resubmit mlx4/mlx5 patches as part of our general series,
or do you prefer to grab them from this patch series?

Thanks


>
> Romain


signature.asc
Description: PGP signature

Re: resolving issue by: USB_AUTOSUSPEND=0

[Daniel Duris]

Sorry about that, -v output here:


Bus 004 Device 004: ID 0bda:8153 Realtek Semiconductor Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 9
  idVendor   0x0bda Realtek Semiconductor Corp.
  idProduct  0x8153
  bcdDevice   30.00
  iManufacturer   1
  iProduct2
  iSerial 6
  bNumConfigurations  2
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   57
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower   64mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol  0
  iInterface  0
  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   0
bMaxBurst   3
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   3
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0002  1x 2 bytes
bInterval   8
bMaxBurst   0
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   98
bNumInterfaces  2
bConfigurationValue 2
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower   64mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  6 Ethernet Networking
  bInterfaceProtocol  0
  iInterface  5
  CDC Header:
bcdCDC   1.10
  CDC Union:
bMasterInterface0
bSlaveInterface 1
  CDC Ethernet:
iMacAddress  3 (??)
bmEthernetStatistics0x
wMaxSegmentSize   1514
wNumberMCFilters0x
bNumberPowerFilters  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   8
bMaxBurst   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0
  iInterface  0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   1
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0
  iInterface  4
  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   0
bMaxBurst   3
  Endpoint D

Re: resolving issue by: USB_AUTOSUSPEND=0

[Oliver Neukum]

Am Montag, den 22.05.2017, 15:55 +0200 schrieb Daniel Duris:
> Bus 004 Device 004: ID 0bda:8153 Realtek Semiconductor Corp.
> Bus 004 Device 003: ID 2109:0813 VIA Labs, Inc.
> Bus 004 Device 002: ID 05e3:0617 Genesys Logic, Inc.
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 004: ID 0835:2a01 Action Star Enterprise Co., Ltd
> Bus 003 Device 006: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
> Bus 003 Device 005: ID 046d:c326 Logitech, Inc.
> Bus 003 Device 003: ID 2109:2813 VIA Labs, Inc.
> Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 004: ID 0bda:5682 Realtek Semiconductor Corp.
> Bus 001 Device 003: ID 04f3:20d0 Elan Microelectronics Corp.
> Bus 001 Device 002: ID 0a5c:6412 Broadcom Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Hi,

that is plain "lsusb". "lsusb -v" is needed to determine which
device type the driver will detect.

Regards
Oliver

--
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 3/3] usb: host: ohci-omap3: Remove driver in favor of ohci-platform

[Sebastian Reichel]

Hi,

On Mon, May 22, 2017 at 09:00:07AM -0700, Tony Lindgren wrote:
> This driver is no longer needed and can be removed. The reason why
> it's safe to remove this driver is that most omap devices don't have a
> USB low-speed or full-speed compatible PHY installed and configured
> with drivers/mfd/omap-usb-host.c. This means that devices like
> beagleboard and pandaboard need to use a high-speed USB hub in order
> to use devices like keyboard and mice.
> 
> Currently the only known configured for a full-speed PHY is the
> mdm6600 modem on droid 4 and I've verified it works just fine with
> ohci-platform.
> 
> Cc: Roger Quadros 
> Cc: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 

Reviewed-by: Sebastian Reichel 

-- Sebastian

> ---
>  drivers/usb/host/Kconfig  |   6 +-
>  drivers/usb/host/Makefile |   1 -
>  drivers/usb/host/ohci-omap3.c | 211 
> --
>  3 files changed, 5 insertions(+), 213 deletions(-)
>  delete mode 100644 drivers/usb/host/ohci-omap3.c
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -473,8 +473,12 @@ config USB_OHCI_HCD_AT91
>  config USB_OHCI_HCD_OMAP3
>   tristate "OHCI support for OMAP3 and later chips"
>   depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
> + select USB_OHCI_HCD_PLATFORM
>   default y
> - ---help---
> + help
> +   This option is deprecated now and the driver was removed, use
> +   USB_OHCI_HCD_PLATFORM instead.
> +
> Enables support for the on-chip OHCI controller on
> OMAP3 and later chips.
>  
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -52,7 +52,6 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)  += ohci-pci.o
>  obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)  += ohci-platform.o
>  obj-$(CONFIG_USB_OHCI_EXYNOS)+= ohci-exynos.o
>  obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o
> -obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
>  obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
>  obj-$(CONFIG_USB_OHCI_HCD_STI)   += ohci-st.o
>  obj-$(CONFIG_USB_OHCI_HCD_AT91)  += ohci-at91.o
> diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
> deleted file mode 100644
> --- a/drivers/usb/host/ohci-omap3.c
> +++ /dev/null
> @@ -1,211 +0,0 @@
> -/*
> - * ohci-omap3.c - driver for OHCI on OMAP3 and later processors
> - *
> - * Bus Glue for OMAP3 USBHOST 3 port OHCI controller
> - * This controller is also used in later OMAPs and AM35x chips
> - *
> - * Copyright (C) 2007-2010 Texas Instruments, Inc.
> - * Author: Vikram Pandita 
> - * Author: Anand Gadiyar 
> - * Author: Keshava Munegowda 
> - *
> - * Based on ehci-omap.c and some other ohci glue layers
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
> - *
> - * TODO (last updated Feb 27, 2011):
> - *   - add kernel-doc
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include "ohci.h"
> -
> -#define DRIVER_DESC "OHCI OMAP3 driver"
> -
> -static const char hcd_name[] = "ohci-omap3";
> -static struct hc_driver __read_mostly ohci_omap3_hc_driver;
> -
> -/*
> - * configure so an HC device and id are always provided
> - * always called with process context; sleeping is OK
> - */
> -
> -/**
> - * ohci_hcd_omap3_probe - initialize OMAP-based HCDs
> - *
> - * Allocates basic resources for this USB host controller, and
> - * then invokes the start() method for the HCD associated with it
> - * through the hotplug entry's driver_data.
> - */
> -static int ohci_hcd_omap3_probe(struct platform_device *pdev)
> -{
> - struct device   *dev = &pdev->dev;
> - struct ohci_hcd *ohci;
> - struct usb_hcd  *hcd = NULL;
> - void __iomem*regs = NULL;
> - struct resource *res;
> - int ret;
> - int irq;
> -
> - if (usb_disabled())
> - return -ENODEV;
> -
> - if (!dev->parent) {
> - dev_err(dev, "Missing parent device\n");
> - return -ENODEV;
> - }
> -
> - irq = platform_get_irq(pdev, 0);
> - if 

Re: [PATCH v9 06/15] mlx5: Replace PCI pool old API

[Romain Perier]

Hello,


Le 23/05/2017 à 09:27, Leon Romanovsky a écrit :
> On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
>> The PCI pool API is deprecated. This commit replaces the PCI pool old
>> API by the appropriate function with the DMA pool API.
>>
>> Signed-off-by: Romain Perier 
>> Reviewed-by: Peter Senna Tschudin 
>> Acked-by: Doug Ledford 
>> Tested-by: Doug Ledford 
>> ---
>>  drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
>>  include/linux/mlx5/driver.h   |  2 +-
>>  2 files changed, 7 insertions(+), 6 deletions(-)
>>
> Who is supposed to merge this patch series?
>
> Acked-by: Leon Romanovsky 
Each maintainer of the corresponding subsystem, can take a patch, I
guess. No ?

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

Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Oliver Neukum]

Am Montag, den 22.05.2017, 11:54 -0400 schrieb David Miller:
> 
> Unfortunately without a real notifier of some sort (there isn't one, and
> it isn't actually easy to come up with a clean way to do this which is
> probably why it doesn't exist yet in the first place) I really cannot
> recommend anything better.
> 
> That being said, probably for the time being we should just backoff each
> and every request, always trying initially to do the higher order thing.

We could use a counter. After the first failure, do it once, after the
second twice and so on. And reset the counter as a higher order
allocation works. (just bound it somewhere)

Regards
Oliver


--
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 3/3] mfd: twl: move header file out of I2C realm

[Kishon Vijay Abraham I]

On Monday 22 May 2017 03:32 AM, Wolfram Sang wrote:
> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
> 
> Signed-off-by: Wolfram Sang 

Acked-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/mach-omap2/common.h| 2 +-
>  arch/arm/mach-omap2/omap_twl.c  | 2 +-
>  drivers/gpio/gpio-twl4030.c | 2 +-
>  drivers/iio/adc/twl4030-madc.c  | 2 +-
>  drivers/iio/adc/twl6030-gpadc.c | 2 +-
>  drivers/input/keyboard/twl4030_keypad.c | 2 +-
>  drivers/input/misc/twl4030-pwrbutton.c  | 2 +-
>  drivers/input/misc/twl4030-vibra.c  | 2 +-
>  drivers/mfd/twl-core.c  | 6 +++---
>  drivers/mfd/twl4030-audio.c | 2 +-
>  drivers/mfd/twl4030-irq.c   | 2 +-
>  drivers/mfd/twl4030-power.c | 2 +-
>  drivers/mfd/twl6030-irq.c   | 2 +-
>  drivers/phy/phy-twl4030-usb.c   | 2 +-
>  drivers/power/supply/twl4030_charger.c  | 2 +-
>  drivers/pwm/pwm-twl-led.c   | 2 +-
>  drivers/pwm/pwm-twl.c   | 2 +-
>  drivers/regulator/twl-regulator.c   | 2 +-
>  drivers/regulator/twl6030-regulator.c   | 2 +-
>  drivers/rtc/rtc-twl.c   | 2 +-
>  drivers/usb/phy/phy-twl6030-usb.c   | 2 +-
>  drivers/video/backlight/pandora_bl.c| 2 +-
>  drivers/watchdog/twl4030_wdt.c  | 2 +-
>  include/linux/{i2c => mfd}/twl.h| 0
>  sound/soc/codecs/twl4030.c  | 2 +-
>  25 files changed, 26 insertions(+), 26 deletions(-)
>  rename include/linux/{i2c => mfd}/twl.h (100%)
> 
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 8cc6338fcb1288..b5ad7fcb80ed24 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 1346b3ab34a5e3..295124b248ae3f 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -16,7 +16,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "soc.h"
>  #include "voltage.h"
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 24f388ed46d4c4..9b511df5450eb6 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  /*
>   * The GPIO "subchip" supports 18 GPIOs which can be configured as
> diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
> index 0c74869a540ad3..5a64eda1652061 100644
> --- a/drivers/iio/adc/twl4030-madc.c
> +++ b/drivers/iio/adc/twl4030-madc.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
> index becbb0aef232b9..bc0e60b9da452e 100644
> --- a/drivers/iio/adc/twl6030-gpadc.c
> +++ b/drivers/iio/adc/twl6030-gpadc.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/keyboard/twl4030_keypad.c 
> b/drivers/input/keyboard/twl4030_keypad.c
> index 39e72b3219d8a4..f9f98ef1d98e3f 100644
> --- a/drivers/input/keyboard/twl4030_keypad.c
> +++ b/drivers/input/keyboard/twl4030_keypad.c
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/misc/twl4030-pwrbutton.c 
> b/drivers/input/misc/twl4030-pwrbutton.c
> index 1c13005b228fa7..b307cca1702226 100644
> --- a/drivers/input/misc/twl4030-pwrbutton.c
> +++ b/drivers/input/misc/twl4030-pwrbutton.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #define PWR_PWRON_IRQ (1 << 0)
>  
> diff --git a/drivers/input/misc/twl4030-vibra.c 
> b/drivers/input/misc/twl4030-vibra.c
> index caa5a62c42fbe0..6c51d404874bbd 100644
> --- a/drivers/input/misc/twl4030-vibra.c
> +++ b/drivers/input/misc/twl4030-vibra.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index c64615dca2bd33..2a09dde4ca6efc 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -44,7 +44,7 @@
>  #include 
>  
>  #include 
> -#include 
> +#include 
>  
>  /* Register descriptions for audio */
>  #include 
> @@ -173,7 +173,7 @@ static struct twl_private *twl_priv;
>  static struct twl_mapping twl4030_map[] = {
>   /*
>* NOTE:  don't change this table without updating the
> -  *  defines for TWL4030_MODULE_*
> +  *  defines for TWL4030_MODULE_*
>* so they continue to match the order in this table.
>*/
>  
> @@ -344,7 +344,7 @@ static const struct reg

Re: [PATCH v9 06/15] mlx5: Replace PCI pool old API

[Leon Romanovsky]

On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
> The PCI pool API is deprecated. This commit replaces the PCI pool old
> API by the appropriate function with the DMA pool API.
>
> Signed-off-by: Romain Perier 
> Reviewed-by: Peter Senna Tschudin 
> Acked-by: Doug Ledford 
> Tested-by: Doug Ledford 
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
>  include/linux/mlx5/driver.h   |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
>

Who is supposed to merge this patch series?

Acked-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH 3/3] mfd: twl: move header file out of I2C realm

[Wolfram Sang]

> For my own reference:
>   Acked-for-MFD-by: Lee Jones 
> 
> I guess this will be going through the MFD tree?

I'd prefer that, yes. Thanks!



signature.asc
Description: PGP signature

Re: [PATCH 2/3] mfd: tps65010: move header file out of I2C realm

[Lee Jones]

On Mon, 22 May 2017, Wolfram Sang wrote:

> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  arch/arm/mach-omap1/board-h2-mmc.c  | 2 +-
>  arch/arm/mach-omap1/board-h2.c  | 2 +-
>  arch/arm/mach-omap1/board-h3-mmc.c  | 2 +-
>  arch/arm/mach-omap1/board-h3.c  | 2 +-
>  arch/arm/mach-omap1/board-osk.c | 2 +-
>  arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
>  arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-

>  drivers/mfd/tps65010.c  | 2 +-

For my own reference:
  Acked-for-MFD-by: Lee Jones 
  
>  drivers/usb/host/ohci-omap.c| 2 +-
>  drivers/usb/phy/phy-isp1301-omap.c  | 2 +-
>  drivers/video/fbdev/omap/lcd_h3.c   | 2 +-
>  include/linux/{i2c => mfd}/tps65010.h   | 2 +-
>  12 files changed, 12 insertions(+), 12 deletions(-)
>  rename include/linux/{i2c => mfd}/tps65010.h (99%)
> 
> diff --git a/arch/arm/mach-omap1/board-h2-mmc.c 
> b/arch/arm/mach-omap1/board-h2-mmc.c
> index 357be2debc9da8..91bda9c802ff38 100644
> --- a/arch/arm/mach-omap1/board-h2-mmc.c
> +++ b/arch/arm/mach-omap1/board-h2-mmc.c
> @@ -14,7 +14,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "board-h2.h"
>  #include "mmc.h"
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index 675254ee4b1e93..dece47d76282ac 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap1/board-h3-mmc.c 
> b/arch/arm/mach-omap1/board-h3-mmc.c
> index 4f58bfa5e7549e..692c267a9a9052 100644
> --- a/arch/arm/mach-omap1/board-h3-mmc.c
> +++ b/arch/arm/mach-omap1/board-h3-mmc.c
> @@ -14,7 +14,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include "common.h"
>  #include "board-h3.h"
> diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
> index e62f9d454f1005..6d32beeb2d8857 100644
> --- a/arch/arm/mach-omap1/board-h3.c
> +++ b/arch/arm/mach-omap1/board-h3.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index 4dfb995048103b..f20361b8ffb6e0 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -38,7 +38,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c 
> b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
> index 262ab07447483a..6cac7da15e2b0d 100644
> --- a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
> +++ b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
> @@ -17,7 +17,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c 
> b/arch/arm/mach-s3c24xx/mach-osiris.c
> index 70b0eb7d31347f..64b1a0b7b803a1 100644
> --- a/arch/arm/mach-s3c24xx/mach-osiris.c
> +++ b/arch/arm/mach-s3c24xx/mach-osiris.c
> @@ -24,7 +24,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c
> index d829a6131f09e5..2ab67386b4ef1e 100644
> --- a/drivers/mfd/tps65010.c
> +++ b/drivers/mfd/tps65010.c
> @@ -32,7 +32,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include 
>  
> diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
> index a4d814b7f38066..91393ec7d8503c 100644
> --- a/drivers/usb/host/ohci-omap.c
> +++ b/drivers/usb/host/ohci-omap.c
> @@ -53,7 +53,7 @@
>  #define DRIVER_DESC "OHCI OMAP driver"
>  
>  #ifdef CONFIG_TPS65010
> -#include 
> +#include 
>  #else
>  
>  #define LOW  0
> diff --git a/drivers/usb/phy/phy-isp1301-omap.c 
> b/drivers/usb/phy/phy-isp1301-omap.c
> index 042c5a8fd423d8..c6052c814bcc24 100644
> --- a/drivers/usb/phy/phy-isp1301-omap.c
> +++ b/drivers/usb/phy/phy-isp1301-omap.c
> @@ -96,7 +96,7 @@ struct isp1301 {
>  
>  #if IS_REACHABLE(CONFIG_TPS65010)
>  
> -#include 
> +#include 
>  
>  #else
>  
> diff --git a/drivers/video/fbdev/omap/lcd_h3.c 
> b/drivers/video/fbdev/omap/lcd_h3.c
> index 9d2da146813ef0..796f4634c4c6f1 100644
> --- a/drivers/video/fbdev/omap/lcd_h3.c
> +++ b/drivers/video/fbdev/omap/lcd_h3.c
> @@ -21,7 +21,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #include "omapfb.h"
> diff --git a/include/linux/i2c/tps65010.h b/include/linux/mfd/tps65010.h
> similarity index 99%
> rename from include/linux/i2c/tps65010.h
> rename to include/linux/mfd/tps65010.h
> index 08aa92278d71cd..a1fb9bc5311de4 100644
> --- a/include/linux/i2c/tps65010.h
> +++ b/include/linux/mfd/tps65010.h
> @@ -1,4 +1,4 @@
> -/* linux/i2c/tps65010.h
> +/* linux/mfd/tps65010.h
>   *
>   * Func

Re: [PATCH 3/3] mfd: twl: move header file out of I2C realm

[Lee Jones]

On Mon, 22 May 2017, Wolfram Sang wrote:

> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
> 
> Signed-off-by: Wolfram Sang 
> ---
>  arch/arm/mach-omap2/common.h| 2 +-
>  arch/arm/mach-omap2/omap_twl.c  | 2 +-
>  drivers/gpio/gpio-twl4030.c | 2 +-
>  drivers/iio/adc/twl4030-madc.c  | 2 +-
>  drivers/iio/adc/twl6030-gpadc.c | 2 +-
>  drivers/input/keyboard/twl4030_keypad.c | 2 +-
>  drivers/input/misc/twl4030-pwrbutton.c  | 2 +-
>  drivers/input/misc/twl4030-vibra.c  | 2 +-

>  drivers/mfd/twl-core.c  | 6 +++---
>  drivers/mfd/twl4030-audio.c | 2 +-
>  drivers/mfd/twl4030-irq.c   | 2 +-
>  drivers/mfd/twl4030-power.c | 2 +-
>  drivers/mfd/twl6030-irq.c   | 2 +-

For my own reference:
  Acked-for-MFD-by: Lee Jones 

I guess this will be going through the MFD tree?

>  drivers/phy/phy-twl4030-usb.c   | 2 +-
>  drivers/power/supply/twl4030_charger.c  | 2 +-
>  drivers/pwm/pwm-twl-led.c   | 2 +-
>  drivers/pwm/pwm-twl.c   | 2 +-
>  drivers/regulator/twl-regulator.c   | 2 +-
>  drivers/regulator/twl6030-regulator.c   | 2 +-
>  drivers/rtc/rtc-twl.c   | 2 +-
>  drivers/usb/phy/phy-twl6030-usb.c   | 2 +-
>  drivers/video/backlight/pandora_bl.c| 2 +-
>  drivers/watchdog/twl4030_wdt.c  | 2 +-
>  include/linux/{i2c => mfd}/twl.h| 0
>  sound/soc/codecs/twl4030.c  | 2 +-
>  25 files changed, 26 insertions(+), 26 deletions(-)
>  rename include/linux/{i2c => mfd}/twl.h (100%)
> 
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 8cc6338fcb1288..b5ad7fcb80ed24 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 1346b3ab34a5e3..295124b248ae3f 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -16,7 +16,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "soc.h"
>  #include "voltage.h"
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 24f388ed46d4c4..9b511df5450eb6 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  /*
>   * The GPIO "subchip" supports 18 GPIOs which can be configured as
> diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
> index 0c74869a540ad3..5a64eda1652061 100644
> --- a/drivers/iio/adc/twl4030-madc.c
> +++ b/drivers/iio/adc/twl4030-madc.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
> index becbb0aef232b9..bc0e60b9da452e 100644
> --- a/drivers/iio/adc/twl6030-gpadc.c
> +++ b/drivers/iio/adc/twl6030-gpadc.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/keyboard/twl4030_keypad.c 
> b/drivers/input/keyboard/twl4030_keypad.c
> index 39e72b3219d8a4..f9f98ef1d98e3f 100644
> --- a/drivers/input/keyboard/twl4030_keypad.c
> +++ b/drivers/input/keyboard/twl4030_keypad.c
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/misc/twl4030-pwrbutton.c 
> b/drivers/input/misc/twl4030-pwrbutton.c
> index 1c13005b228fa7..b307cca1702226 100644
> --- a/drivers/input/misc/twl4030-pwrbutton.c
> +++ b/drivers/input/misc/twl4030-pwrbutton.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #define PWR_PWRON_IRQ (1 << 0)
>  
> diff --git a/drivers/input/misc/twl4030-vibra.c 
> b/drivers/input/misc/twl4030-vibra.c
> index caa5a62c42fbe0..6c51d404874bbd 100644
> --- a/drivers/input/misc/twl4030-vibra.c
> +++ b/drivers/input/misc/twl4030-vibra.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index c64615dca2bd33..2a09dde4ca6efc 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -44,7 +44,7 @@
>  #include 
>  
>  #include 
> -#include 
> +#include 
>  
>  /* Register descriptions for audio */
>  #include 
> @@ -173,7 +173,7 @@ static struct twl_private *twl_priv;
>  static struct twl_mapping twl4030_map[] = {
>   /*
>* NOTE:  don't change this table without updating the
> -  *  defines for TWL4030_MODULE_*
> +  *  defines for TWL4030_MODULE_*
>* so they continue to match the order in this table.
> 

Re: [PATCH 1/3] usb: host: ohci-platform: Add basic runtime PM support

[Roger Quadros]

Hi,

On 22/05/17 19:00, Tony Lindgren wrote:
> This is needed in preparation of adding support for omap3 and
> later OHCI. The runtime PM will only do something on platforms
> that implement it.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Hans de Goede 
> Cc: Rob Herring 
> Cc: Roger Quadros 
> Cc: Sebastian Reichel 
> Cc: Yoshihiro Shimoda 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Alan, do you have some better ideas for the ohci_platform_remove()
> path below?
> 
> ---
>  drivers/usb/host/ohci-platform.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ohci-platform.c 
> b/drivers/usb/host/ohci-platform.c
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -242,6 +243,8 @@ static int ohci_platform_probe(struct platform_device 
> *dev)
>   }
>  #endif
>  
> + pm_runtime_set_active(&dev->dev);
> + pm_runtime_enable(&dev->dev);
>   if (pdata->power_on) {
>   err = pdata->power_on(dev);
>   if (err < 0)
> @@ -271,6 +274,7 @@ static int ohci_platform_probe(struct platform_device 
> *dev)
>   if (pdata->power_off)
>   pdata->power_off(dev);
>  err_reset:
> + pm_runtime_disable(&dev->dev);
>   while (--rst >= 0)
>   reset_control_assert(priv->resets[rst]);
>  err_put_clks:
> @@ -290,7 +294,14 @@ static int ohci_platform_remove(struct platform_device 
> *dev)
>   struct usb_hcd *hcd = platform_get_drvdata(dev);
>   struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
>   struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> - int clk, rst;
> + int clk, rst, enabled;
> +
> + enabled = pm_runtime_get_sync(&dev->dev);

Why do we need to pm_runtime_get_sync() here?

> + if (enabled < 0) {
> + dev_warn(&dev->dev, "pm_runtime_get failed: %i\n",
> +  enabled);
> + pm_runtime_put_noidle(&dev->dev);
> + }
>  
>   usb_remove_hcd(hcd);
>  
> @@ -305,6 +316,10 @@ static int ohci_platform_remove(struct platform_device 
> *dev)
>  
>   usb_put_hcd(hcd);
>  
> + if (enabled >= 0)
> + pm_runtime_put_sync(&dev->dev);
> + pm_runtime_disable(&dev->dev);
> +
>   if (pdata == &ohci_platform_defaults)
>   dev->dev.platform_data = NULL;
>  
> 

-- 
cheers,
-roger
--
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 3/3] usb: host: ohci-omap3: Remove driver in favor of ohci-platform

[Roger Quadros]

On 22/05/17 19:00, Tony Lindgren wrote:
> This driver is no longer needed and can be removed. The reason why
> it's safe to remove this driver is that most omap devices don't have a
> USB low-speed or full-speed compatible PHY installed and configured
> with drivers/mfd/omap-usb-host.c. This means that devices like
> beagleboard and pandaboard need to use a high-speed USB hub in order
> to use devices like keyboard and mice.
> 
> Currently the only known configured for a full-speed PHY is the
> mdm6600 modem on droid 4 and I've verified it works just fine with
> ohci-platform.
> 
> Cc: Roger Quadros 
> Cc: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 

Acked-by: Roger Quadros 

> ---
>  drivers/usb/host/Kconfig  |   6 +-
>  drivers/usb/host/Makefile |   1 -
>  drivers/usb/host/ohci-omap3.c | 211 
> --
>  3 files changed, 5 insertions(+), 213 deletions(-)
>  delete mode 100644 drivers/usb/host/ohci-omap3.c
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -473,8 +473,12 @@ config USB_OHCI_HCD_AT91
>  config USB_OHCI_HCD_OMAP3
>   tristate "OHCI support for OMAP3 and later chips"
>   depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
> + select USB_OHCI_HCD_PLATFORM
>   default y
> - ---help---
> + help
> +   This option is deprecated now and the driver was removed, use
> +   USB_OHCI_HCD_PLATFORM instead.
> +
> Enables support for the on-chip OHCI controller on
> OMAP3 and later chips.
>  
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -52,7 +52,6 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)  += ohci-pci.o
>  obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)  += ohci-platform.o
>  obj-$(CONFIG_USB_OHCI_EXYNOS)+= ohci-exynos.o
>  obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o
> -obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
>  obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
>  obj-$(CONFIG_USB_OHCI_HCD_STI)   += ohci-st.o
>  obj-$(CONFIG_USB_OHCI_HCD_AT91)  += ohci-at91.o
> diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
> deleted file mode 100644
> --- a/drivers/usb/host/ohci-omap3.c
> +++ /dev/null
> @@ -1,211 +0,0 @@
> -/*
> - * ohci-omap3.c - driver for OHCI on OMAP3 and later processors
> - *
> - * Bus Glue for OMAP3 USBHOST 3 port OHCI controller
> - * This controller is also used in later OMAPs and AM35x chips
> - *
> - * Copyright (C) 2007-2010 Texas Instruments, Inc.
> - * Author: Vikram Pandita 
> - * Author: Anand Gadiyar 
> - * Author: Keshava Munegowda 
> - *
> - * Based on ehci-omap.c and some other ohci glue layers
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
> - *
> - * TODO (last updated Feb 27, 2011):
> - *   - add kernel-doc
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include "ohci.h"
> -
> -#define DRIVER_DESC "OHCI OMAP3 driver"
> -
> -static const char hcd_name[] = "ohci-omap3";
> -static struct hc_driver __read_mostly ohci_omap3_hc_driver;
> -
> -/*
> - * configure so an HC device and id are always provided
> - * always called with process context; sleeping is OK
> - */
> -
> -/**
> - * ohci_hcd_omap3_probe - initialize OMAP-based HCDs
> - *
> - * Allocates basic resources for this USB host controller, and
> - * then invokes the start() method for the HCD associated with it
> - * through the hotplug entry's driver_data.
> - */
> -static int ohci_hcd_omap3_probe(struct platform_device *pdev)
> -{
> - struct device   *dev = &pdev->dev;
> - struct ohci_hcd *ohci;
> - struct usb_hcd  *hcd = NULL;
> - void __iomem*regs = NULL;
> - struct resource *res;
> - int ret;
> - int irq;
> -
> - if (usb_disabled())
> - return -ENODEV;
> -
> - if (!dev->parent) {
> - dev_err(dev, "Missing parent device\n");
> - return -ENODEV;
> - }
> -
> - irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(dev, "OHCI ir

[PATCH] usb:host:xhci:USB 3.1 Speed

[YD]

From: YD Tseng 

Hi Mathias,

This patch works around for parsing extended speed protocol lists. 
If the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
it could show as one 3.1 roothub.

Signed-off-by: YD Tseng 

---

A file is modified.
drivers/usb/host/xhci-mem.c Modified file

diff -up xhci-mem{.orig,} > /tmp/patch
--- xhci-mem.c.orig 2017-04-08 15:35:38.0 +0800
+++ xhci-mem.c  2017-05-22 11:56:21.362907677 +0800
@@ -2111,11 +2111,12 @@ static void xhci_add_in_port(struct xhci
 {
u32 temp, port_offset, port_count;
int i;
-   u8 major_revision;
+   u8 major_revision, minor_revision;
struct xhci_hub *rhub;

temp = readl(addr);
major_revision = XHCI_EXT_PORT_MAJOR(temp);
+   minor_revision = XHCI_EXT_PORT_MINOR(temp);

if (major_revision == 0x03) {
rhub = &xhci->usb3_rhub;
@@ -2129,7 +2130,9 @@ static void xhci_add_in_port(struct xhci
return;
}
rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
-   rhub->min_rev = XHCI_EXT_PORT_MINOR(temp);
+
+   if (rhub->min_rev < minor_revision)
+   rhub->min_rev = minor_revision;

/* Port offset and count in the third dword, see section 7.2 */
temp = readl(addr + 2);
@@ -2280,6 +2283,8 @@ static int xhci_setup_port_arrays(struct

offset = cap_start;

+   xhci->usb3_rhub.min_rev = 0;
+   xhci->usb2_rhub.min_rev = 0;
while (offset) {
xhci_add_in_port(xhci, num_ports, base + offset, cap_count);
if (xhci->num_usb2_ports + xhci->num_usb3_ports == num_ports)
--
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