Re: [PATCH] usb: move usb_calc_bus_time into common code

[John Youn]

On 2/19/2016 2:48 PM, Doug Anderson wrote:
> Hi,
> 
> On Fri, Feb 19, 2016 at 1:52 PM, Alan Stern  wrote:
>> On Fri, 19 Feb 2016, Arnd Bergmann wrote:
>>
>>> The dwc2 dual-role USB controller driver has started calling
>>> usb_calc_bus_time, and does so regardless of whether it is
>>> being built as a host controller or gadget. In case all
>>
>> Out of curiosity...  Why does dwc2 need to calculate bus times when it
>> is in device mode?
> 
> Hoo boy.  it doesn't.  Nor does it need to properly set the even/odd
> frame in device mode.
> 
> Basically dwc2's "core.c" has a whole bunch of stuff in it that's host
> only and isn't guarded with any #ifdef.  ...yet that file is included
> in gadget-only builds.  It's a bit of a mess.  Take a gander at all of
> the "dwc2_hc_xxx" functions sitting in "drivers/usb/dwc2/core.c".
> 
> Long term that needs to be cleaned up, but such a cleanup is going to
> be a bit of churn so we'd need to schedule it for a time when not much
> else is going on (and presumably it should be done by John or in close
> coordination with him so it can get Acked / landed quickly to avoid
> conflicts?).  To do this we'd have to figure out why some things are
> in "core.c" and some in "hcd.c" and if it makes sense to move them all
> to "hcd.c" or if we need a new "core_hc.c" or something...  All of
> that design predates me.
> 

Yeah, that stuff has been bugging me for a while. I have a branch that
started a lot of clean-ups, but it's never been a great time to merge
it.

> In any case I guess we need a solution for right now, huh?
> 
> One terribly lame hack would be to just make a dummy no-op
> "dwc2_hc_set_even_odd_frame()" if host mode is disabled.  That doesn't
> really fix the root problem of lots of host mode code being compiled
> in a gadget-only driver.  It also adds an ugly "#ifdef".  ...but it
> does get around the current compile error.
> 
> 
> What do folks think?
> 

I think if we can fix it for -next in dwc2 by moving all host code out
of core then we should do it that way. I'll see if I can revive my
patches.

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

[PATCH] usb: dwc3: Validate the maximum_speed parameter

[John Youn]

Check that dwc->maximum_speed is set to a valid value. Also add an error
when we use it later if we encounter an invalid value.

Signed-off-by: John Youn 
---

Hi Felipe,

This patch depends on the previous SuperSpeed patches I sent. Let me
know if you'd rather I amend the relevant patches in that series
instead.

Regards,
John


 drivers/usb/dwc3/core.c   | 18 --
 drivers/usb/dwc3/gadget.c |  9 ++---
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 001c755..17fd814 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1012,8 +1012,20 @@ static int dwc3_probe(struct platform_device *pdev)
goto err1;
}
 
-   /* default to superspeed if no maximum_speed passed */
-   if (dwc->maximum_speed == USB_SPEED_UNKNOWN) {
+   /* Check the maximum_speed parameter */
+   switch (dwc->maximum_speed) {
+   case USB_SPEED_LOW:
+   case USB_SPEED_FULL:
+   case USB_SPEED_HIGH:
+   case USB_SPEED_SUPER:
+   case USB_SPEED_SUPER_PLUS:
+   break;
+   default:
+   dev_err(dev, "invalid maximum_speed parameter %d\n",
+   dwc->maximum_speed);
+   /* fall through */
+   case USB_SPEED_UNKNOWN:
+   /* default to superspeed */
dwc->maximum_speed = USB_SPEED_SUPER;
 
/*
@@ -1023,6 +1035,8 @@ static int dwc3_probe(struct platform_device *pdev)
(DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
 DWC3_GHWPARAMS3_SSPHY_IFC_GEN2))
dwc->maximum_speed = USB_SPEED_SUPER_PLUS;
+
+   break;
}
 
/* Adjust Frame Length */
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 482e6a1..3ac170f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1670,10 +1670,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
case USB_SPEED_SUPER_PLUS:
reg |= DWC3_DSTS_SUPERSPEED_PLUS;
break;
-   case USB_SPEED_SUPER:   /* FALLTHROUGH */
-   case USB_SPEED_UNKNOWN: /* FALTHROUGH */
default:
-   reg |= DWC3_DSTS_SUPERSPEED;
+   dev_err(dwc->dev, "invalid dwc->maximum_speed (%d)\n",
+   dwc->maximum_speed);
+   /* fall through */
+   case USB_SPEED_SUPER:
+   reg |= DWC3_DCFG_SUPERSPEED;
+   break;
}
}
dwc3_writel(dwc->regs, DWC3_DCFG, reg);
-- 
2.6.3

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

Re: [PATCH] usb: move usb_calc_bus_time into common code

[Doug Anderson]

Hi,

On Fri, Feb 19, 2016 at 1:52 PM, Alan Stern  wrote:
> On Fri, 19 Feb 2016, Arnd Bergmann wrote:
>
>> The dwc2 dual-role USB controller driver has started calling
>> usb_calc_bus_time, and does so regardless of whether it is
>> being built as a host controller or gadget. In case all
>
> Out of curiosity...  Why does dwc2 need to calculate bus times when it
> is in device mode?

Hoo boy.  it doesn't.  Nor does it need to properly set the even/odd
frame in device mode.

Basically dwc2's "core.c" has a whole bunch of stuff in it that's host
only and isn't guarded with any #ifdef.  ...yet that file is included
in gadget-only builds.  It's a bit of a mess.  Take a gander at all of
the "dwc2_hc_xxx" functions sitting in "drivers/usb/dwc2/core.c".

Long term that needs to be cleaned up, but such a cleanup is going to
be a bit of churn so we'd need to schedule it for a time when not much
else is going on (and presumably it should be done by John or in close
coordination with him so it can get Acked / landed quickly to avoid
conflicts?).  To do this we'd have to figure out why some things are
in "core.c" and some in "hcd.c" and if it makes sense to move them all
to "hcd.c" or if we need a new "core_hc.c" or something...  All of
that design predates me.

In any case I guess we need a solution for right now, huh?

One terribly lame hack would be to just make a dummy no-op
"dwc2_hc_set_even_odd_frame()" if host mode is disabled.  That doesn't
really fix the root problem of lots of host mode code being compiled
in a gadget-only driver.  It also adds an ugly "#ifdef".  ...but it
does get around the current compile error.


What do folks think?

-Doug
--
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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Fri, 19 Feb 2016, Daniel Fraga wrote:

> On Fri, 19 Feb 2016 14:13:25 -0500 (EST)
> Alan Stern  wrote:
> 
> > -22 is -EINVAL, so we need to figure out which of the many possible
> > EINVAL errors you're getting.  Try the patch below.
> 
>   I applied your patch, but when it wakes up from S3, the system
> is stalled: nothing works. No keyboard, no mouse... 
> 
>   And nothing in the log.

Probably something about the patch causes a runtime error and that 
causes the resume to fail.  I'll try some testing on my machine and get 
back to you next week...

Alan Stern

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

Re: [PATCH] usb: move usb_calc_bus_time into common code

[Alan Stern]

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

> The dwc2 dual-role USB controller driver has started calling
> usb_calc_bus_time, and does so regardless of whether it is
> being built as a host controller or gadget. In case all

Out of curiosity...  Why does dwc2 need to calculate bus times when it
is in device mode?

Alan Stern

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

[PATCH] usb: move usb_calc_bus_time into common code

[Arnd Bergmann]

The dwc2 dual-role USB controller driver has started calling
usb_calc_bus_time, and does so regardless of whether it is
being built as a host controller or gadget. In case all
USB host support is disabled (CONFIG_USB=n), this now causes
a link error:

ERROR: "usb_calc_bus_time" [drivers/usb/dwc2/dwc2.ko] undefined!

Moving the function that is called from the USB HCD specific code
into the shared USB code avoids this problem.

Signed-off-by: Arnd Bergmann 
Fixes: f889904b25df ("usb: dwc2: host: Properly set even/odd frame")
---
I have no idea if this is the correct solution for the problem,
it just seemed like the easiest way to avoid the build failure.

 drivers/usb/common/common.c | 51 +
 drivers/usb/core/hcd.c  | 51 -
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index e3d01619d6b3..654fd37f89d5 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 const char *usb_otg_state_string(enum usb_otg_state state)
@@ -126,6 +127,56 @@ enum usb_dr_mode usb_get_dr_mode(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(usb_get_dr_mode);
 
+/*-*/
+
+/**
+ * usb_calc_bus_time - approximate periodic transaction time in nanoseconds
+ * @speed: from dev->speed; USB_SPEED_{LOW,FULL,HIGH}
+ * @is_input: true iff the transaction sends data to the host
+ * @isoc: true for isochronous transactions, false for interrupt ones
+ * @bytecount: how many bytes in the transaction.
+ *
+ * Return: Approximate bus time in nanoseconds for a periodic transaction.
+ *
+ * Note:
+ * See USB 2.0 spec section 5.11.3; only periodic transfers need to be
+ * scheduled in software, this function is only used for such scheduling.
+ */
+long usb_calc_bus_time (int speed, int is_input, int isoc, int bytecount)
+{
+   unsigned long   tmp;
+
+   switch (speed) {
+   case USB_SPEED_LOW: /* INTR only */
+   if (is_input) {
+   tmp = (67667L * (31L + 10L * BitTime (bytecount))) / 
1000L;
+   return 64060L + (2 * BW_HUB_LS_SETUP) + BW_HOST_DELAY + 
tmp;
+   } else {
+   tmp = (66700L * (31L + 10L * BitTime (bytecount))) / 
1000L;
+   return 64107L + (2 * BW_HUB_LS_SETUP) + BW_HOST_DELAY + 
tmp;
+   }
+   case USB_SPEED_FULL:/* ISOC or INTR */
+   if (isoc) {
+   tmp = (8354L * (31L + 10L * BitTime (bytecount))) / 
1000L;
+   return ((is_input) ? 7268L : 6265L) + BW_HOST_DELAY + 
tmp;
+   } else {
+   tmp = (8354L * (31L + 10L * BitTime (bytecount))) / 
1000L;
+   return 9107L + BW_HOST_DELAY + tmp;
+   }
+   case USB_SPEED_HIGH:/* ISOC or INTR */
+   /* FIXME adjust for input vs output */
+   if (isoc)
+   tmp = HS_NSECS_ISO (bytecount);
+   else
+   tmp = HS_NSECS (bytecount);
+   return tmp;
+   default:
+   pr_debug ("%s: bogus device speed!\n", __func__);
+   return -1;
+   }
+}
+EXPORT_SYMBOL_GPL(usb_calc_bus_time);
+
 #ifdef CONFIG_OF
 /**
  * of_usb_get_dr_mode_by_phy - Get dual role mode for the controller device
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 0b8a91004737..cbaa78043793 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1170,57 +1170,6 @@ EXPORT_SYMBOL_GPL(usb_hcd_end_port_resume);
 
 /*-*/
 
-/**
- * usb_calc_bus_time - approximate periodic transaction time in nanoseconds
- * @speed: from dev->speed; USB_SPEED_{LOW,FULL,HIGH}
- * @is_input: true iff the transaction sends data to the host
- * @isoc: true for isochronous transactions, false for interrupt ones
- * @bytecount: how many bytes in the transaction.
- *
- * Return: Approximate bus time in nanoseconds for a periodic transaction.
- *
- * Note:
- * See USB 2.0 spec section 5.11.3; only periodic transfers need to be
- * scheduled in software, this function is only used for such scheduling.
- */
-long usb_calc_bus_time (int speed, int is_input, int isoc, int bytecount)
-{
-   unsigned long   tmp;
-
-   switch (speed) {
-   case USB_SPEED_LOW: /* INTR only */
-   if (is_input) {
-   tmp = (67667L * (31L + 10L * BitTime (bytecount))) / 
1000L;
-   return 64060L + (2 * BW_HUB_LS_SETUP) + BW_HOST_DELAY + 
tmp;
-   } else {
-   tmp = (66700L * (31L + 10L * BitTime (bytecount))) / 
1000L;
-   return 64107L + (2 * BW_HUB_LS_SETUP) + 

Re: [PATCH] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Daniel Johnson]

On Fri, Feb 19, 2016 at 2:31 AM, Bjørn Mork  wrote:
> Good.  So you have a few alternative configs here. I forgot to ask, but
> I assume you've ended up with cfg #2 by default (because Linux has a
> class preference, making it select the first config with a non 0xff
> class as the first interface).  Anyway, we can go through all three as
> they will share most of the functions.

Yes confirmed that it was using configuration 2.

> If this behaves like other Huawei NCM devices, then it uses AT^NDISDUP
> and other Huawei specific AT commands for connection management. Some
> firmwares accept these over a serial function, but some insist that the
> management channel embedded in the CDC NCM device is used.  The
> huawei_cdc_ncm driver provides access to this channel via a
> /dev/cdc-wdmX character device.

I remember trying the AT^NDISDUP command at some point. I think I got
an invalid command error.

> So, what I'd like to have tested is (replace 'x-y' with your actual bus
> and port number):
>
>  1) echo 3 >/sys/bus/usb/devices/x-y/bConfigurationValue

[219042.445533] cdc_ncm 1-3:2.0 enx022c80139263: unregister 'cdc_ncm'
usb-:00:14.0-3, CDC NCM
[219042.466164] qcserial ttyUSB0: Qualcomm USB modem converter now
disconnected from ttyUSB0
[219042.466224] qcserial 1-3:2.2: device disconnected
[219042.467695] qcserial ttyUSB1: Qualcomm USB modem converter now
disconnected from ttyUSB1
[219042.467753] qcserial 1-3:2.3: device disconnected
[219042.468210] qcserial ttyUSB2: Qualcomm USB modem converter now
disconnected from ttyUSB2
[219042.468252] qcserial 1-3:2.4: device disconnected
[219042.468703] qcserial ttyUSB3: Qualcomm USB modem converter now
disconnected from ttyUSB3
[219042.468747] qcserial 1-3:2.5: device disconnected
[219042.476337] cdc_mbim 1-3:3.0: setting rx_max = 16384
[219042.482837] cdc_mbim 1-3:3.0: setting tx_max = 16384
[219042.483099] cdc_mbim 1-3:3.0: cdc-wdm2: USB WDM device
[219042.483902] cdc_mbim 1-3:3.0 wwan0: register 'cdc_mbim' at
usb-:00:14.0-3, CDC MBIM, 62:aa:ce:37:a2:53
[219042.485445] qcserial 1-3:3.2: Qualcomm USB modem converter detected
[219042.485764] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB0

>Does cdc_mbim load?  Does mbimcli work?

I'm not sure if I'm using it right.

$ sudo mbimcli -d /dev/cdc-wdm2 --query-device-caps
error: couldn't open the MbimDevice: Transaction timed out

>Can ModemManager connect?
>Does the netwrok interface work after connecting?

ModemManager recognizes it, as it did with config 2. With the
unactivated Verizon SIM the computer came with.

$ mmcli -m 1 --3gpp-scan

Found 4 networks:
311480 - Verizon (lte, forbidden)
310410 - AT (lte, available)
310120 - Sprint (lte, available)
310260 - T-Mobile (lte, available)

No luck as far as NMEA

When I inserted my activated T-Mobile SIM it started resetting every
30 seconds or so. It does that in windows too, so it may be an
unhealthy reaction to that particular SIM. In Windows it will actually
get a working network connection before it resets so I might be able
to script this. I should probably get an activated SIM that works in
Windows to test with though.

>  2) echo 2 > >/sys/bus/usb/devices/x-y/bConfigurationValue

[223519.579459] cdc_mbim 1-3:3.0 wwan0: unregister 'cdc_mbim'
usb-:00:14.0-3, CDC MBIM
[223519.628860] qcserial ttyUSB0: Qualcomm USB modem converter now
disconnected from ttyUSB0
[223519.628980] qcserial 1-3:3.2: device disconnected
[223519.673883] cdc_ncm 1-3:2.0: MAC-Address: 02:2c:80:13:92:63
[223519.673900] cdc_ncm 1-3:2.0: setting rx_max = 16384
[223519.674543] cdc_ncm 1-3:2.0: setting tx_max = 16384
[223519.677536] cdc_ncm 1-3:2.0 usb0: register 'cdc_ncm' at
usb-:00:14.0-3, CDC NCM, 02:2c:80:13:92:63
[223519.682192] qcserial 1-3:2.2: Qualcomm USB modem converter detected
[223519.682417] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB0
[223519.686049] qcserial 1-3:2.3: Qualcomm USB modem converter detected
[223519.686524] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB1
[223519.689555] qcserial 1-3:2.4: Qualcomm USB modem converter detected
[223519.689725] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB2
[223519.690928] qcserial 1-3:2.5: Qualcomm USB modem converter detected
[223519.694418] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB3
[223519.712453] cdc_ncm 1-3:2.0 enx022c80139263: renamed from usb0
[223519.746520] IPv6: ADDRCONF(NETDEV_UP): enx022c80139263: link is not ready
[223519.748424] IPv6: ADDRCONF(NETDEV_UP): enx022c80139263: link is not ready

>Does cdc_ncm load? Can you connect with 'AT^NDISDUP=1,1,"yourapn"'?
>Can you get the IP config with DHCP (e.g 'dhclient -d wwan0')? How
>about 'AT^DHCP?'?  Does the network device work (forwarding traffic)?

With the constant resets mentioned above I'm not going to get very far
when trying to connect.

It at least seems to treat that as a valid command.
AT^DHCP?
+CME ERROR: 1
AT^DHCP=?
OK

>  3) echo 1 > 

Re: driver migration

[tilman]

Greg KH  writes:

> 
> On Fri, Feb 19, 2016 at 06:49:50AM +, tilman wrote:
> > Hello
> > 
> > I configured and setup a more recent kernel:  V4.5.0-rc4
> > 
> > The driver compiles and inserts.
> 
> What driver?  You have provided no context here :(
My apologies -- what I meant to say was: I inserted the compile usbrsa
driver. The code of the driver I posted on Feb 16th.

> 
> > When I plugin the USB-Dongle, the machine
> > freezes (not sure whether it freezes during the firmware download or after
> > it once it has reenumerated). 
> 
> Your kernel logs should show you this.

The kernel freezes before it can log the kernel oops:

Feb 19 07:26:35 btron kernel: [  241.247360] usbcore: registered new interface d
river usbrsa
Feb 19 07:26:35 btron kernel: [  241.247388] usbserial: USB Serial support regis
tered for IO-DATA - USB-RSA - (prerenumeration)
Feb 19 07:26:35 btron kernel: [  241.247412] usbserial: USB Serial support regis
tered for IO-DATA - USB-RSA

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@


> The kernel logs can provide you with a full traceback, we can't do much
> without that.
I understand that and I would love to provide one -- there is however no
traceback logged. All I have is a kernel message on the console:

BUG: unable to handle kernel paging request at ...

When I had the driver running on the kernel version 3.13.0, things started
to go wrong in usbrsa_attach of the usbrsa driver (see first posting on Feb
16th)

I will comment out all functional parts of the driver, and check if it still
fails. If it no longer crashes, I will comment in procedure by procedure
until it crashes hoping that I can isolate the problem that way ... 
If there are better/faster debugging techniques I would love to learn about
them :-)

Thanks

Tilman



--
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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Fri, 19 Feb 2016 14:13:25 -0500 (EST)
Alan Stern  wrote:

> -22 is -EINVAL, so we need to figure out which of the many possible
> EINVAL errors you're getting.  Try the patch below.

I applied your patch, but when it wakes up from S3, the system
is stalled: nothing works. No keyboard, no mouse... 

And nothing in the log.

-- 
Linux 4.4.1-dirty: Blurry Fish Butt
http://www.youtube.com/DanielFragaBR
http://exchangewar.info
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL
--
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] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Dan Williams]

On Fri, 2016-02-19 at 18:21 +0100, Bjørn Mork wrote:
> Dan Williams  writes:
> > On Fri, 2016-02-19 at 21:20 +0700, Lars Melin wrote:
> > 
> > > cfg #1
> > > MI_00 HP Mobile Connect - PC UI Interface
> > > MI_01 HP Mobile Connect - Application Interface
> > > MI_02 HP Mobile Connect - Modem
> > > MI_03 HP Mobile Connect - Network Card (jungo ncm)
> > > MI_04 HP Mobile Connect - GPS Interface
> > > 
> > > cfg#2
> > > MI_00 HP Mobile Connect - Network Card (cdc_ether)
> > > MI_02 HP Mobile Connect - Modem
> > > MI_03 HP Mobile Connect - Application Interface
> > > MI_04 HP Mobile Connect - PC UI Interface
> > > MI_05 HP Mobile Connect - GPS Interface
> > > 
> > > cfg#3
> > > MI_00 HP Mobile Connect - Network Card (cdc_mbim)
> > > MI_02 HP Mobile Connect - GPS Interface
> > 
> > Bjorn, with these devices that technically "support" a bunch of
> > different modes, what should our advice be on mode select?
> >  Personally
> > I'd love to switch modems that support MBIM into MBIM by default...
> 
> Yup, me too.  That is the configuration with a class driver and
> standardized management, allowing it to work without any device or
> vendor specific support.  It is also the configuration used by
> current
> Windows versions and therefore most likely tested.
> 
> I don't think such a policy is suitable for the kernel, though.  In
> fact, I don't think the current kernel policy is appropriate for the
> kernel either :) But we'll have to leave that as it is.
> 
> Do you think it is possible to create a catch-all udev rule
> preferring
> MBIM?  I guess we'll need some helper for that, since it means making
> a
> choice based on the attributes of an inactive configuration.  

usb_modeswitch would be the most logical helper.

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

[GIT PULL] USB-serial fixes for v4.5-rc5

[Johan Hovold]

Hi Greg,

Here are some new device ids for rc5.

Thanks,
Johan


The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865:

  Linux 4.5-rc4 (2016-02-14 13:05:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.5-rc5

for you to fetch changes up to d061c1caa31d4d9792cfe48a2c6b309a0e01ef46:

  USB: option: add "4G LTE usb-modem U901" (2016-02-18 13:08:03 +0100)


USB-serial fixes for v4.5-rc5

Here are some new device ids.

Signed-off-by: Johan Hovold 


Andrey Skvortsov (1):
  USB: option: add support for SIM7100E

Bjørn Mork (1):
  USB: option: add "4G LTE usb-modem U901"

Ken Lin (1):
  USB: cp210x: add IDs for GE B650V3 and B850V3 boards

 drivers/usb/serial/cp210x.c | 2 ++
 drivers/usb/serial/option.c | 9 +
 2 files changed, 11 insertions(+)
--
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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Thu, 18 Feb 2016, Daniel Fraga wrote:

> On Thu, 18 Feb 2016 15:23:00 -0500 (EST)
> Alan Stern  wrote:
> 
> > Something like the patch below (untested).
> 
> > +   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
> 
>   Ok, so I got the following:
> 
> Feb 18 19:22:26 tux kernel: [  258.693120] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb 18 19:22:26 tux kernel: [  258.783654] usbhid 3-1.6:1.0: post reset 
> hid_start_in -> -22

>   If you need more tests, just ask.

-22 is -EINVAL, so we need to figure out which of the many possible
EINVAL errors you're getting.  Try the patch below.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1427,6 +1427,7 @@ static int hid_post_reset(struct usb_int
struct usb_host_interface *interface = intf->cur_altsetting;
int status;
char *rdesc;
+   extern int alantest;
 
/* Fetch and examine the HID report descriptor. If this
 * has changed, then rebind. Since usbcore's check of the
@@ -1457,7 +1458,10 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
+   alantest = 1;
status = hid_start_in(hid);
+   alantest = 0;
+   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
Index: usb-4.4/drivers/usb/core/urb.c
===
--- usb-4.4.orig/drivers/usb/core/urb.c
+++ usb-4.4/drivers/usb/core/urb.c
@@ -184,6 +184,9 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
 
 /*---*/
 
+int alantest;
+EXPORT_SYMBOL(alantest);
+
 /**
  * usb_submit_urb - issue an asynchronous transfer request for an endpoint
  * @urb: pointer to the urb describing the request
@@ -332,8 +335,10 @@ int usb_submit_urb(struct urb *urb, gfp_
int is_out;
unsigned intallowed;
 
+   if (alantest)  dev_info(>dev->dev, "submit A\n");
if (!urb || !urb->complete)
return -EINVAL;
+   if (alantest)  dev_info(>dev->dev, "submit B\n");
if (urb->hcpriv) {
WARN_ONCE(1, "URB %p submitted while active\n", urb);
return -EBUSY;
@@ -395,6 +400,7 @@ int usb_submit_urb(struct urb *urb, gfp_
 * but drivers only control those sizes for ISO.
 * while we're checking, initialize return status.
 */
+   if (alantest)  dev_info(>dev->dev, "submit C\n");
if (xfertype == USB_ENDPOINT_XFER_ISOC) {
int n, len;
 
@@ -433,6 +439,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (sg->length % max)
return -EINVAL;
}
+   if (alantest)  dev_info(>dev->dev, "submit D\n");
 
/* the I/O buffer must be mapped/unmapped, except when length=0 */
if (urb->transfer_buffer_length > INT_MAX)
@@ -487,6 +494,7 @@ int usb_submit_urb(struct urb *urb, gfp_
case USB_ENDPOINT_XFER_ISOC:
case USB_ENDPOINT_XFER_INT:
/* too small? */
+   if (alantest)  dev_info(>dev->dev, "submit E\n");
switch (dev->speed) {
case USB_SPEED_WIRELESS:
if ((urb->interval < 6)
@@ -497,6 +505,7 @@ int usb_submit_urb(struct urb *urb, gfp_
return -EINVAL;
break;
}
+   if (alantest)  dev_info(>dev->dev, "submit F\n");
/* too big? */
switch (dev->speed) {
case USB_SPEED_SUPER:   /* units are 125us */
@@ -532,6 +541,7 @@ int usb_submit_urb(struct urb *urb, gfp_
default:
return -EINVAL;
}
+   if (alantest)  dev_info(>dev->dev, "submit G\n");
if (dev->speed != USB_SPEED_WIRELESS) {
/* Round down to a power of 2, no more than max */
urb->interval = min(max, 1 << ilog2(urb->interval));

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

Re: [PATCH v4 1/2] usb: musb: Fix DMA for host mode

[Sergei Shtylyov]

Hello.

On 02/19/2016 07:41 PM, Joshua Henderson wrote:


From: Cristian Birsan 

Commit ac33cdb16681 ("usb: musb: Remove ifdefs for musb_host_rx in
musb_host.c part5") introduces a problem setting DMA host mode.

This commit fixes the done condition that advances the musb schedule.
Without this patch the the msub_advance_schedule() is called immediately
after receiving an endpoint RX interrupt without waiting for the DMA
transfer to complete. As a consequence when the dma complete interrupt
arrives the in_qh member of hw_ep is already null an the musb_host_rx()
exits on !urb error case.

Signed-off-by: Cristian Birsan 
Signed-off-by: Joshua Henderson 
Tested-by: Ladislav Michl 


Acked-by: Sergei Shtylyov 

   Although you didn't describe your changes to the original patch in the 
change log...


MBR, Sergei

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

Re: [PATCH] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Bjørn Mork]

Dan Williams  writes:
> On Fri, 2016-02-19 at 21:20 +0700, Lars Melin wrote:
>
>> cfg #1
>> MI_00 HP Mobile Connect - PC UI Interface
>> MI_01 HP Mobile Connect - Application Interface
>> MI_02 HP Mobile Connect - Modem
>> MI_03 HP Mobile Connect - Network Card (jungo ncm)
>> MI_04 HP Mobile Connect - GPS Interface
>> 
>> cfg#2
>> MI_00 HP Mobile Connect - Network Card (cdc_ether)
>> MI_02 HP Mobile Connect - Modem
>> MI_03 HP Mobile Connect - Application Interface
>> MI_04 HP Mobile Connect - PC UI Interface
>> MI_05 HP Mobile Connect - GPS Interface
>> 
>> cfg#3
>> MI_00 HP Mobile Connect - Network Card (cdc_mbim)
>> MI_02 HP Mobile Connect - GPS Interface
>
> Bjorn, with these devices that technically "support" a bunch of
> different modes, what should our advice be on mode select?  Personally
> I'd love to switch modems that support MBIM into MBIM by default...

Yup, me too.  That is the configuration with a class driver and
standardized management, allowing it to work without any device or
vendor specific support.  It is also the configuration used by current
Windows versions and therefore most likely tested.

I don't think such a policy is suitable for the kernel, though.  In
fact, I don't think the current kernel policy is appropriate for the
kernel either :) But we'll have to leave that as it is.

Do you think it is possible to create a catch-all udev rule preferring
MBIM?  I guess we'll need some helper for that, since it means making a
choice based on the attributes of an inactive configuration.  


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

Re: driver migration

[Greg KH]

On Fri, Feb 19, 2016 at 06:49:50AM +, tilman wrote:
> Hello
> 
> I configured and setup a more recent kernel:  V4.5.0-rc4
> 
> The driver compiles and inserts.

What driver?  You have provided no context here :(

> When I plugin the USB-Dongle, the machine
> freezes (not sure whether it freezes during the firmware download or after
> it once it has reenumerated). 

Your kernel logs should show you this.

> I could observe  a kernel oops message starting with BUG. Probably a null
> pointer dereference...

The kernel logs can provide you with a full traceback, we can't do much
without that.

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

[PATCH v4 2/2] usb: musb: Fix DMA desired mode for Mentor DMA engine

[Joshua Henderson]

From: Cristian Birsan 

Commit 754fe4a92c07 ("usb: musb: Remove ifdefs for TX DMA for musb_host.c")
introduces a problem setting the desired channel mode for the Mentor DMA
engine.

There is a case where an address is incorrectly assigned to the DMA
channel desired mode when it should instead be assigned the actual mode
value. This results in the value of channel->desired_mode not being
correct.

Signed-off-by: Cristian Birsan 
Signed-off-by: Joshua Henderson 
Tested-by: Ladislav Michl 
Acked-by: Sergei Shtylyov 
---
Changes since v3: None
Changes since v2:
- Fix wording in commit message.
Changes since v1:
- Fix commit comment citing the cause of the regression.
---
 drivers/usb/musb/musb_host.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 75c89b4..58487a4 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -662,7 +662,7 @@ static int musb_tx_dma_set_mode_mentor(struct 
dma_controller *dma,
csr &= ~(MUSB_TXCSR_AUTOSET | MUSB_TXCSR_DMAMODE);
csr |= MUSB_TXCSR_DMAENAB; /* against programmer's guide */
}
-   channel->desired_mode = mode;
+   channel->desired_mode = *mode;
musb_writew(epio, MUSB_TXCSR, csr);
 
return 0;
-- 
1.7.9.5

--
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/5] usb: musb: core: added helper functions for parsing DT

[Bin Liu]

Hi,

On Fri, Feb 12, 2016 at 03:58:40PM +0100, Petr Kulhavy wrote:
> This adds two functions to get DT properties "mentor,power" and "dr_mode":
> musb_get_power() and musb_mode musb_get_mode()

Please add revision # in the [PATCH...] prefix in subject.

> 
> Signed-off-by: Petr Kulhavy 
> ---
>  drivers/usb/musb/musb_core.c | 37 +
>  drivers/usb/musb/musb_core.h | 20 
>  2 files changed, 57 insertions(+)
> 
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index c3791a0..0836375 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -100,6 +100,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "musb_core.h"
>  
> @@ -129,6 +130,42 @@ static inline struct musb *dev_to_musb(struct device 
> *dev)
>   return dev_get_drvdata(dev);
>  }
>  
> +enum musb_mode musb_get_mode(struct device *dev)
> +{
> + enum usb_dr_mode mode;
> +
> + mode = usb_get_dr_mode(dev);
> + switch (mode) {
> + case USB_DR_MODE_HOST:
> + return MUSB_HOST;
> + case USB_DR_MODE_PERIPHERAL:
> + return MUSB_PERIPHERAL;
> + case USB_DR_MODE_OTG:
> + return MUSB_OTG;
> + default:
> + return MUSB_UNDEFINED;

return MUSB_OTG in non-HOST or non-PERIPHERAL case. I am wondering if
MUSB_UNDEFINED will cause regression if dr_mode is not defined in DT.

case USB_DR_MODE_UNKNOWN:
case USB_DR_MODE_OTG:
default:
return MUSB_OTG;

Regards,
-Bin.

> + }
> +}
> +EXPORT_SYMBOL_GPL(musb_get_mode);
> +
> +#ifdef CONFIG_OF
> +u8 musb_get_power(struct device *dev)
> +{
> + int ret;
> + unsigned power_ma;
> +
> + /* the "mentor,power" value is in milliamperes, whereas
> +  * the mentor configuration is in 2mA units
> +  */
> + ret = of_property_read_u32(dev->of_node, "mentor,power", _ma);
> + if (ret)
> + return 0;
> +
> + return power_ma > 510 ? 255 : power_ma / 2;
> +}
> +EXPORT_SYMBOL_GPL(musb_get_power);
> +#endif
> +
>  /*-*/
>  
>  #ifndef CONFIG_BLACKFIN
> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> index fd215fb..89d6290 100644
> --- a/drivers/usb/musb/musb_core.h
> +++ b/drivers/usb/musb/musb_core.h
> @@ -614,4 +614,24 @@ static inline void 
> musb_platform_post_root_reset_end(struct musb *musb)
>   musb->ops->post_root_reset_end(musb);
>  }
>  
> +/* gets the "dr_mode" property from DT and converts it into musb_mode
> + * if the property is not found returns MUSB_UNDEFINED
> + */
> +extern enum musb_mode musb_get_mode(struct device *dev);
> +
> +#if IS_ENABLED(CONFIG_OF)
> +/* gets the "mentor,power" property from DT
> + * and converts it from mA to 2mA units for the "power" parameter
> + * in struct musb_hdrc_platform_data
> + *
> + * in case the property is not found returns 0
> + */
> +extern u8 musb_get_power(struct device *dev);
> +#else
> +static inline u8 musb_get_power(struct device *dev)
> +{
> + return 0;
> +}
> +#endif
> +
>  #endif   /* __MUSB_CORE_H__ */
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] usb: musb: Fix DMA for host mode

[Joshua Henderson]

From: Cristian Birsan 

Commit ac33cdb16681 ("usb: musb: Remove ifdefs for musb_host_rx in
musb_host.c part5") introduces a problem setting DMA host mode.

This commit fixes the done condition that advances the musb schedule.
Without this patch the the msub_advance_schedule() is called immediately
after receiving an endpoint RX interrupt without waiting for the DMA
transfer to complete. As a consequence when the dma complete interrupt
arrives the in_qh member of hw_ep is already null an the musb_host_rx()
exits on !urb error case.

Signed-off-by: Cristian Birsan 
Signed-off-by: Joshua Henderson 
Tested-by: Ladislav Michl 
---
Changes since v3:
- Fix formatting to 2 lines.
Changes since v2:
- Put function call in if condition.
Changes since v1:
- Don't add unecessary new variable. Just correct done.
---
 drivers/usb/musb/musb_host.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 795a45b..75c89b4 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2003,10 +2003,8 @@ void musb_host_rx(struct musb *musb, u8 epnum)
qh->offset,
urb->transfer_buffer_length);
 
-   done = musb_rx_dma_in_inventra_cppi41(c, hw_ep, qh,
- urb, xfer_len,
- iso_err);
-   if (done)
+   if (musb_rx_dma_in_inventra_cppi41(c, hw_ep, qh, urb,
+  xfer_len, iso_err))
goto finish;
else
dev_err(musb->controller, "error: rx_dma 
failed\n");
-- 
1.7.9.5

--
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] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Dan Williams]

On Fri, 2016-02-19 at 21:20 +0700, Lars Melin wrote:
> On 2016-02-19 17:31, Bjørn Mork wrote:
> > Daniel Johnson  writes:
> > 
> > > > > Currently 4 ttyUSB devices are detected, but only the second
> > > > > two respond to
> > > > > AT commands. The first two serial ports may be falsely
> > > > > detected.
> > > > 
> > > > One of them is likely a QCDM port if this is really a Qualcomm
> > > > based
> > > > device.  The other might be an inactive NMEA port.  Serial
> > > > doesn't
> > > > necessarily imply AT commands...
> > > 
> 
> 
> cfg #1
> MI_00 HP Mobile Connect - PC UI Interface
> MI_01 HP Mobile Connect - Application Interface
> MI_02 HP Mobile Connect - Modem
> MI_03 HP Mobile Connect - Network Card (jungo ncm)
> MI_04 HP Mobile Connect - GPS Interface
> 
> cfg#2
> MI_00 HP Mobile Connect - Network Card (cdc_ether)
> MI_02 HP Mobile Connect - Modem
> MI_03 HP Mobile Connect - Application Interface
> MI_04 HP Mobile Connect - PC UI Interface
> MI_05 HP Mobile Connect - GPS Interface
> 
> cfg#3
> MI_00 HP Mobile Connect - Network Card (cdc_mbim)
> MI_02 HP Mobile Connect - GPS Interface

Bjorn, with these devices that technically "support" a bunch of
different modes, what should our advice be on mode select?  Personally
I'd love to switch modems that support MBIM into MBIM by default...

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

[PATCH] usb: musb: host: Fix NULL pointer dereference in SMP environment

[Liu Xiang]

In multi-core SoC, if enable USB endpoint/transmit urb/disable 
USB endpoint repeatedly,it can cause a NULL pointer dereference bug:

Unable to handle kernel NULL pointer dereference at virtual address 0010
pgd = d3eb4000
[0010] *pgd=
Internal error: Oops: 5 [#1] PREEMPT SMP
Pid: 1017, comm:  mediaserver
CPU: 0Not tainted  (3.0.101-ZXICTOS_V2.00.20_P2B4_ZTE_ZX296700_ASIC+ #2)
PC is at musb_h_disable+0xfc/0x15c
LR is at musb_h_disable+0xfc/0x15c
pc : []lr : []psr: 60070093
sp : d3e5bc80  ip : 0027  fp : d3e5bca4
r10:   r9 : ff94  r8 : 0080
r7 : 60070013  r6 : d45900f0  r5 : d4717720  r4 : cee2d860
r3 :   r2 : c0875628  r1 : d3e5bbc0  r0 : 002a
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 18c53c7d  Table: b3eb404a  DAC: 0015
[] (__dabt_svc+0x70/0xa0) from [] 
(musb_h_disable+0xfc/0x15c)
[] (musb_h_disable+0xfc/0x15c) from [] 
(usb_hcd_disable_endpoint+0x3c/0x44)
[] (usb_hcd_disable_endpoint+0x3c/0x44) from [] 
(usb_disable_endpoint+0x64/0x7c)
[] (usb_disable_endpoint+0x64/0x7c) from [] 
(usb_disable_interface+0x48/0x58)
[] (usb_disable_interface+0x48/0x58) from [] 
(usb_set_interface+0x158/0x274)
[] (usb_set_interface+0x158/0x274) from [] 
(uvc_video_enable+0x78/0x9c)
[] (uvc_video_enable+0x78/0x9c) from [] 
(uvc_v4l2_do_ioctl+0xd08/0x12ec)
[] (uvc_v4l2_do_ioctl+0xd08/0x12ec) from [] 
(video_usercopy+0x144/0x500)
[] (video_usercopy+0x144/0x500) from [] 
(uvc_v4l2_ioctl+0x2c/0x74)
[] (uvc_v4l2_ioctl+0x2c/0x74) from [] 
(v4l2_ioctl+0x94/0x154)
[] (v4l2_ioctl+0x94/0x154) from [] (do_vfs_ioctl+0x84/0x5ac)
[] (do_vfs_ioctl+0x84/0x5ac) from [] (sys_ioctl+0x78/0x80)
[] (sys_ioctl+0x78/0x80) from [] (ret_fast_syscall+0x0/0x30)

Considering the following execution sequence:
CPU0   CPU1
musb_urb_dequeue
 spin_lock_irqsave(>lock, flags);
  ready = qh->is_ready;
   qh->is_ready = 0;
musb_giveback(musb, urb, 0);
 spin_unlock(>lock);
   zx296702_musb_interrupt
musb_interrupt
 spin_lock_irqsave(>lock, flags);
  musb_advance_schedule
   ready = qh->is_ready;
qh->is_ready = 0;
 musb_giveback(musb, urb, status);
  spin_unlock(>lock);
  spin_lock(>lock);
   qh->is_ready = ready;
spin_unlock_irqrestore(>lock, flags);
   spin_lock(>lock);
qh->is_ready = ready;

When musb_urb_dequeue is called finally, the qh->is_ready has already 
been set to 0 in error.Thus the recycling qh job in musb_urb_dequeue 
can not be done. That results in accessing empty qh in musb_h_disable.
So the qh in musb_h_disable should be checked.If the qh is emtpy, 
then recycle it and go to exit directly.

Signed-off-by: Liu Xiang 
---
 drivers/usb/musb/musb_host.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 795a45b..438f5b4 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2515,7 +2515,12 @@ musb_h_disable(struct usb_hcd *hcd, struct 
usb_host_endpoint *hep)
qh->is_ready = 0;
if (musb_ep_get_qh(qh->hw_ep, is_in) == qh) {
urb = next_urb(qh);
-
+   if (urb == NULL) {
+   qh->hep->hcpriv = NULL;
+   list_del(>ring);
+   kfree(qh);
+   goto exit;
+   }
/* make software (then hardware) stop ASAP */
if (!urb->unlinked)
urb->status = -ESHUTDOWN;
-- 
1.9.1


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

Re: [PATCH 2/5] usb: musb: core: added helper functions for parsing DT

[Bin Liu]

Hi,

On Fri, Feb 19, 2016 at 02:08:37PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Sergei Shtylyov  writes:
> > On 2/19/2016 10:23 AM, Felipe Balbi wrote:
> >
> >>> This adds two functions to get DT properties "mentor,power" and 
> >>> "dr_mode":
> >>> musb_get_power() and musb_mode musb_get_mode()
> >>>
> >>> Signed-off-by: Petr Kulhavy 
> >> seems like I don't have patch 1/5. After fixing Sergei's comments,
> >> please resend with his Acked-by already in place.
> >>
> >> thanks
> > Hi Felipe,
> >
> > I will do as soon as the patch 1/5 gets approved.
> > It seem to be a bit stuck at the moment as Rob Herring from the DT wants
> > the "mentor,power"
> > to be represented as a regulator, whereas Sergei and me want to stick to
> > the existing "mentor,power" integer property.
> >
> > As soon as this get clarified I will do the final updates and send the
> > patch again.
> > Maybe this is something you can help to clarify?
> 
>  I don't think that makes sense as a regulator. It's just a number which
>  gets passed to USB Core as is.
> >>>
> >>>  Well, in case of DaVinci's it's an external GPIO controlled
> >>>  regulator indeed.
> >>
> >> oh, I see. Not controller by SetPortPower. That's a shame.
> >>
>  However, it seems like everything in kernel right now is passing it as
>  500. So why don't you deprecate that property, hardcode it to 500 and
>  avoid the problem altogether ?
> >>>
> >>>  OMAP boards can only supply 100 mA, AFAIK. Isn't it too early for the
> >>> deprecation? :-)
> >>
> >>   $ git --no-pager grep -e mentor,power
> >
> > Grep for "power =" in arch/arm/boot/dts/ instead. OMAP props didn't 
> > even 
> > have "mentor," prefix. :-/
> 
> s**t! Okay, then we can't ignore the detail heh. Adding Bin here to see
> if he can patch those older devicetree files.

Sure, I can fix this. When do we need this fix? I am currently tied in a
task for a week or two.

Thanks,
-Bin.

> 
> -- 
> balbi


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

[HELP] USB 3.0 PCI Endpoint problem

[Joao Pinto]

Hi to all!
I am testing a PCIe Root Complex prototyping setup in which I have a USB 3.0
host as a PCI Endpoint.
Running in an ARC CPU platform it works well, but when running in an emulated
ARM64 (this is done by a Synopsys virtualization tool) the endpoint
initialization fails as can be seen in the following log:

xhci_hcd :01:00.0: xHCI Host Controller
xhci_hcd :01:00.0: new USB bus registered, assigned bus number 1
xhci_hcd :01:00.0: xHCI capability registers at ff80002c4000:
xhci_hcd :01:00.0: CAPLENGTH AND HCIVERSION 0x960020:
xhci_hcd :01:00.0: CAPLENGTH: 0x20
xhci_hcd :01:00.0: HCIVERSION: 0x96
xhci_hcd :01:00.0: HCSPARAMS 1: 0x4000820
xhci_hcd :01:00.0:   Max device slots: 32
xhci_hcd :01:00.0:   Max interrupters: 8
xhci_hcd :01:00.0:   Max ports: 4
xhci_hcd :01:00.0: HCSPARAMS 2: 0x11
xhci_hcd :01:00.0:   Isoc scheduling threshold: 1
xhci_hcd :01:00.0:   Maximum allowed segments in event ring: 1
xhci_hcd :01:00.0: HCSPARAMS 3 0x0:
xhci_hcd :01:00.0:   Worst case U1 device exit latency: 0
xhci_hcd :01:00.0:   Worst case U2 device exit latency: 0
xhci_hcd :01:00.0: HCC PARAMS 0x14042cb:
xhci_hcd :01:00.0:   HC generates 64 bit addresses
xhci_hcd :01:00.0:   FIXME: more HCCPARAMS debugging
xhci_hcd :01:00.0: RTSOFF 0x600:
xhci_hcd :01:00.0: xHCI operational registers at ff80002c4020:
xhci_hcd :01:00.0: USBCMD 0x0:
xhci_hcd :01:00.0:   HC is being stopped
xhci_hcd :01:00.0:   HC has finished hard reset
xhci_hcd :01:00.0:   Event Interrupts disabled
xhci_hcd :01:00.0:   Host System Error Interrupts disabled
xhci_hcd :01:00.0:   HC has finished light reset
xhci_hcd :01:00.0: USBSTS 0x9:
xhci_hcd :01:00.0:   Event ring is not empty
xhci_hcd :01:00.0:   No Host System Error
xhci_hcd :01:00.0:   HC is halted
xhci_hcd :01:00.0: ff80002c4420 port status reg = 0x2a0
xhci_hcd :01:00.0: ff80002c4424 port power reg = 0x0
xhci_hcd :01:00.0: ff80002c4428 port link reg = 0x0
xhci_hcd :01:00.0: ff80002c442c port reserved reg = 0x0
xhci_hcd :01:00.0: ff80002c4430 port status reg = 0x2a0
xhci_hcd :01:00.0: ff80002c4434 port power reg = 0x0
xhci_hcd :01:00.0: ff80002c4438 port link reg = 0x0
xhci_hcd :01:00.0: ff80002c443c port reserved reg = 0x0
xhci_hcd :01:00.0: ff80002c4440 port status reg = 0x2a0
xhci_hcd :01:00.0: ff80002c port power reg = 0x0
xhci_hcd :01:00.0: ff80002c4448 port link reg = 0x0
xhci_hcd :01:00.0: ff80002c444c port reserved reg = 0x0
xhci_hcd :01:00.0: ff80002c4450 port status reg = 0x2a0
xhci_hcd :01:00.0: ff80002c4454 port power reg = 0x0
xhci_hcd :01:00.0: ff80002c4458 port link reg = 0x0
xhci_hcd :01:00.0: ff80002c445c port reserved reg = 0x0
xhci_hcd :01:00.0: // Halt the HC
xhci_hcd :01:00.0: Resetting HCD
xhci_hcd :01:00.0: // Reset the HC
xhci_hcd :01:00.0: Wait for controller to be ready for doorbell rings
xhci_hcd :01:00.0: Reset complete
xhci_hcd :01:00.0: Enabling 64-bit DMA addresses.
xhci_hcd :01:00.0: Calling HCD init
xhci_hcd :01:00.0: xhci_init
xhci_hcd :01:00.0: xHCI doesn't need link TRB QUIRK
xhci_hcd :01:00.0: Supported page size register = 0x1
xhci_hcd :01:00.0: Supported page size of 4K
xhci_hcd :01:00.0: HCD page size set to 4K
xhci_hcd :01:00.0: // xHC can handle at most 32 device slots.
xhci_hcd :01:00.0: // Setting Max device slots reg = 0x20.
xhci_hcd :01:00.0: // Device context base array address = 0xfcafb000 (DMA),
ff80002c7000 (virt)
xhci_hcd :01:00.0: Allocated command ring at ffc07db28cc0
xhci_hcd :01:00.0: First segment DMA is 0xfc42c000
xhci_hcd :01:00.0: // Setting command ring address to 0x20
xhci_hcd :01:00.0: // xHC command ring deq ptr low bits + flags = @
xhci_hcd :01:00.0: // xHC command ring deq ptr high bits = @
xhci_hcd :01:00.0: // Doorbell array is located at offset 0x800 from cap
regs base addr
xhci_hcd :01:00.0: // xHCI capability registers at ff80002c4000:
xhci_hcd :01:00.0: // @ff80002c4000 = 0x960020 (CAPLENGTH AND 
HCIVERSION)
xhci_hcd :01:00.0: //   CAPLENGTH: 0x20
xhci_hcd :01:00.0: // xHCI operational registers at ff80002c4020:
xhci_hcd :01:00.0: // @ff80002c4018 = 0x600 RTSOFF
xhci_hcd :01:00.0: // xHCI runtime registers at ff80002c4600:
xhci_hcd :01:00.0: // @ff80002c4014 = 0x800 DBOFF
xhci_hcd :01:00.0: // Doorbell array at ff80002c4800:
xhci_hcd :01:00.0: xHCI runtime registers at ff80002c4600:
xhci_hcd :01:00.0:   ff80002c4600: Microframe index = 0x0
xhci_hcd :01:00.0: // Allocating event ring
xhci_hcd :01:00.0: TRB math tests passed.
xhci_hcd :01:00.0: // Allocated event ring segment table at 0xfc42e000
xhci_hcd :01:00.0: Set ERST to 0; private num segs = 1, virt addr =

RE: [RESEND PATCH v6 07/10] usb: chipidea: otg: enable HNP polling support for gadget and host

[Jun Li]

Hi,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Jun Li
> Sent: Friday, February 19, 2016 10:49 PM
> To: Felipe Balbi ; ba...@kernel.org; Peter Chen
> 
> Cc: linux-usb@vger.kernel.org
> Subject: RE: [RESEND PATCH v6 07/10] usb: chipidea: otg: enable HNP
> polling support for gadget and host
> 
> Hi Felipe,
> 
> > -Original Message-
> > From: Felipe Balbi [mailto:bal...@gmail.com]
> > Sent: Friday, February 19, 2016 10:07 PM
> > To: Jun Li ; ba...@kernel.org; Peter Chen
> > 
> > Cc: linux-usb@vger.kernel.org; Jun Li 
> > Subject: Re: [RESEND PATCH v6 07/10] usb: chipidea: otg: enable HNP
> > polling support for gadget and host
> >
> >
> > hi,
> >
> > Li Jun  writes:
> > > Enable HNP polling support for chipidea gadget and allocate memory
> > > for host request flag when otg fsm init.
> > >
> > > Acked-by: Peter Chen 
> > > Signed-off-by: Li Jun 
> >
> > Why do you guys do this to me ? It's v6 and this thing still doesn't
> > compile. Why even send stuff you haven't even compile tested  Why ???
> 
> I certainly tested my patch set on multiple i.MX6 platforms, so, the build
> is ok in my side.
> 
> >
> > > ---
> > >  drivers/usb/chipidea/otg_fsm.c | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/usb/chipidea/otg_fsm.c
> > > b/drivers/usb/chipidea/otg_fsm.c index cb28e76..9a963a7 100644
> > > --- a/drivers/usb/chipidea/otg_fsm.c
> > > +++ b/drivers/usb/chipidea/otg_fsm.c
> > > @@ -797,6 +797,10 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
> > >   ci->fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
> > >   ci->fsm.otg->state = OTG_STATE_UNDEFINED;
> > >   ci->fsm.ops = _otg_ops;
> > > + ci->gadget.hnp_polling_support = 1;
> > > + ci->fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
> > > + if (!ci->fsm.host_req_flag)
> >
> > the name of the flag is host_request_flag, not host_req_flag. Now, how
> > can I be certain you really tested this at all ? I won't accept this
> > without hard-proof of this really working.
> 
> Nope, the flag is host_req_flag, not "host_request_flag" as you said, See
> my patch 3/7:
> [RESEND PATCH v6 03/10] usb: common: otg-fsm: add HNP polling support
> 
> @@ -119,6 +131,8 @@ struct otg_fsm {
> /* Current usb protocol used: 0:undefine; 1:host; 2:client */
> int protocol;
> struct mutex lock;
> +   u8 *host_req_flag;
> +   struct delayed_work hnp_polling_work;
>  };
> 
> 
> >
> > Sorry guys, but it's v6 of this patch series and we're still having
> > build issues.
> >
> 
> I don't know why you has this build issue, I created my patchset against
> Peter's chipidea tree(ci-for-usb-next branch). I will apply my patches to
> your tree(testing_next) and try again.
> 

Also NO build issue found with my patchset on your tree(testing/next branch).

> Li Jun
> 
> > make -k -j8 -- drivers/usb/
> >   CHK include/config/kernel.release
> >   CHK include/generated/uapi/linux/version.h
> >   UPD include/config/kernel.release
> >   CHK include/generated/utsrelease.h
> >   UPD include/generated/utsrelease.h
> >   CHK include/generated/timeconst.h
> >   CHK include/generated/bounds.h
> >   CHK include/generated/asm-offsets.h
> >   CALLscripts/checksyscalls.sh
> >   CC [M]  drivers/usb/chipidea/otg_fsm.o
> > drivers/usb/chipidea/otg_fsm.c: In function ‘ci_hdrc_otg_fsm_init’:
> > drivers/usb/chipidea/otg_fsm.c:801:9: error: ‘struct otg_fsm’ has no
> > member named ‘host_req_flag’
> >   ci->fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
> >  ^
> > drivers/usb/chipidea/otg_fsm.c:802:14: error: ‘struct otg_fsm’ has no
> > member named ‘host_req_flag’
> >   if (!ci->fsm.host_req_flag)
> >   ^
> > scripts/Makefile.build:258: recipe for target
> > 'drivers/usb/chipidea/otg_fsm.o' failed
> > make[2]: *** [drivers/usb/chipidea/otg_fsm.o] Error 1
> > make[2]: Target '__build' not remade because of errors.
> > scripts/Makefile.build:407: recipe for target 'drivers/usb/chipidea'
> > failed
> > make[1]: *** [drivers/usb/chipidea] Error 2
> > make[1]: Target '__build' not remade because of errors.
> > Makefile:1557: recipe for target 'drivers/usb/' failed
> > make: *** [drivers/usb/] Error 2
> >
> > --
> > balbi
>  {.n +   +%  lzwm  b 맲  r  zX   n)   w*jg    ݢj/   z ޖ  2 ޙ
> & )ߡ a     G   h  j:+v   w ٥
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Fabio Estevam]

On Fri, Feb 19, 2016 at 12:13 PM, Felipe Balbi  wrote:

> h, okay. So you have another problem, actually. Seems like ci_hdrc
> just shouldn't call your phy->suspend(), or your phy->suspend()
> shouldn't do anything. How about below?
>
> @@ -370,6 +370,9 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
> struct mxs_phy *mxs_phy = to_mxs_phy(x);
> bool low_speed_connection, vbus_is_on;
>
> +   if (mxs_phy->data->flags & MXS_PHY_ABNORMAL_IN_SUSPEND)
> +   return 0; /* or should we return -EBUSY ? */
> +

Tested with 0 and also -EBUSY. This code is called now, but it does
not fix the problem. Same log:

[3.005881] hub 1-1:1.0: USB hub found
[3.010341] hub 1-1:1.0: 2 ports detected
[3.536362] usb 1-1: USB disconnect, device number 2
[3.582732] usb usb1-port1: cannot reset (err = -32)
[3.588289] usb usb1-port1: cannot reset (err = -32)
[3.593546] usb usb1-port1: cannot reset (err = -32)
[3.598929] usb usb1-port1: cannot reset (err = -32)
[3.604188] usb usb1-port1: cannot reset (err = -32)
[3.609339] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
--
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: [RESEND PATCH v6 07/10] usb: chipidea: otg: enable HNP polling support for gadget and host

[Jun Li]

Hi Felipe,

> -Original Message-
> From: Felipe Balbi [mailto:bal...@gmail.com]
> Sent: Friday, February 19, 2016 10:07 PM
> To: Jun Li ; ba...@kernel.org; Peter Chen
> 
> Cc: linux-usb@vger.kernel.org; Jun Li 
> Subject: Re: [RESEND PATCH v6 07/10] usb: chipidea: otg: enable HNP
> polling support for gadget and host
> 
> 
> hi,
> 
> Li Jun  writes:
> > Enable HNP polling support for chipidea gadget and allocate memory for
> > host request flag when otg fsm init.
> >
> > Acked-by: Peter Chen 
> > Signed-off-by: Li Jun 
> 
> Why do you guys do this to me ? It's v6 and this thing still doesn't
> compile. Why even send stuff you haven't even compile tested  Why ???

I certainly tested my patch set on multiple i.MX6 platforms, so, the build
is ok in my side.

> 
> > ---
> >  drivers/usb/chipidea/otg_fsm.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/usb/chipidea/otg_fsm.c
> > b/drivers/usb/chipidea/otg_fsm.c index cb28e76..9a963a7 100644
> > --- a/drivers/usb/chipidea/otg_fsm.c
> > +++ b/drivers/usb/chipidea/otg_fsm.c
> > @@ -797,6 +797,10 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
> > ci->fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
> > ci->fsm.otg->state = OTG_STATE_UNDEFINED;
> > ci->fsm.ops = _otg_ops;
> > +   ci->gadget.hnp_polling_support = 1;
> > +   ci->fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
> > +   if (!ci->fsm.host_req_flag)
> 
> the name of the flag is host_request_flag, not host_req_flag. Now, how can
> I be certain you really tested this at all ? I won't accept this without
> hard-proof of this really working.

Nope, the flag is host_req_flag, not "host_request_flag" as you said,
See my patch 3/7:
[RESEND PATCH v6 03/10] usb: common: otg-fsm: add HNP polling support

@@ -119,6 +131,8 @@ struct otg_fsm {
/* Current usb protocol used: 0:undefine; 1:host; 2:client */
int protocol;
struct mutex lock;
+   u8 *host_req_flag;
+   struct delayed_work hnp_polling_work;
 };


> 
> Sorry guys, but it's v6 of this patch series and we're still having build
> issues.
>

I don't know why you has this build issue, I created my patchset against
Peter's chipidea tree(ci-for-usb-next branch). I will apply my patches
to your tree(testing_next) and try again.

Li Jun
 
> make -k -j8 -- drivers/usb/
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   UPD include/config/kernel.release
>   CHK include/generated/utsrelease.h
>   UPD include/generated/utsrelease.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/bounds.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   CC [M]  drivers/usb/chipidea/otg_fsm.o
> drivers/usb/chipidea/otg_fsm.c: In function ‘ci_hdrc_otg_fsm_init’:
> drivers/usb/chipidea/otg_fsm.c:801:9: error: ‘struct otg_fsm’ has no
> member named ‘host_req_flag’
>   ci->fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
>  ^
> drivers/usb/chipidea/otg_fsm.c:802:14: error: ‘struct otg_fsm’ has no
> member named ‘host_req_flag’
>   if (!ci->fsm.host_req_flag)
>   ^
> scripts/Makefile.build:258: recipe for target
> 'drivers/usb/chipidea/otg_fsm.o' failed
> make[2]: *** [drivers/usb/chipidea/otg_fsm.o] Error 1
> make[2]: Target '__build' not remade because of errors.
> scripts/Makefile.build:407: recipe for target 'drivers/usb/chipidea'
> failed
> make[1]: *** [drivers/usb/chipidea] Error 2
> make[1]: Target '__build' not remade because of errors.
> Makefile:1557: recipe for target 'drivers/usb/' failed
> make: *** [drivers/usb/] Error 2
> 
> --
> balbi

USB oops regression caused by -stable patch

[Tony Battersby]

This upstream commit is causing an oops:
d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device")

This patch has already been included in several -stable kernels.  Here
are the affected kernels:
4.5.0-rc4 (current git)
4.4.2
4.3.6 (currently in review)
4.1.18
3.18.27
3.14.61

How to reproduce the problem:
Boot kernel with slub debugging enabled (otherwise memory corruption
will cause random oopses later instead of immediately)
Plug in USB 3.0 disk to xhci USB 3.0 port
dd if=/dev/sdc of=/dev/null bs=65536
(where /dev/sdc is the USB 3.0 disk)
Unplug USB cable while dd is still going
Oops is immediate:

blk_update_request: I/O error, dev sdc, sector 864768
blk_update_request: I/O error, dev sdc, sector 865008
blk_update_request: I/O error, dev sdc, sector 865024
blk_update_request: I/O error, dev sdc, sector 865264
blk_update_request: I/O error, dev sdc, sector 864768
Buffer I/O error on dev sdc, logical block 108096, async page read
general protection fault:  [#1] SMP DEBUG_PAGEALLOC 
Modules linked in: netconsole igb i2c_algo_bit ptp pps_core sg eeprom i2c_i801
CPU: 3 PID: 24 Comm: kworker/3:0 Not tainted 4.5.0-rc4-00095-g2850713 #14
Hardware name: Supermicro X8DTH-i/6/iF/6F/X8DTH, BIOS 2.1b   05/04/12  
Workqueue: usb_hub_wq hub_event
task: 88042b09f080 ti: 88042b0a4000 task.ti: 88042b0a4000
RIP: 0010:[]  [] kfree+0x49/0x110
RSP: 0018:88042b0a7988  EFLAGS: 00010207
RAX: ea00 RBX: 6b6b6b6b0100 RCX: 0018
RDX: 0018 RSI:  RDI: 01ad998dac00
RBP: 88042b0a79c8 R08: ea0010a72210 R09: ea0010a72218
R10: 880429c88548 R11: 0001 R12: 8800bb1b8000
R13: 880429a21ce0 R14: 8800bb1a0690 R15: 0001
FS:  () GS:88043dc6() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 7f3a6186b990 CR3: 00a0a000 CR4: 06e0
Stack:
 ea0002ea2220  880429c88548 0001
 88042b0a79e8 804f56cb 880401002801 880429c80948
 88042b0a79e8 804f3df0 8800bb1a0690 880429c80948
Call Trace:
 [] ? usb_destroy_configuration+0x11b/0x140
 [] usb_release_bos_descriptor+0x20/0x40
 [] usb_release_dev+0x2c/0x70
 [] device_release+0x33/0xa0
 [] kobject_release+0x47/0x90
 [] kobject_put+0x2c/0x60
 [] put_device+0x12/0x20
 [] usb_disconnect+0x1cb/0x220
 [] hub_event+0x46a/0x1070
 [] ? dequeue_task_fair+0x73a/0x820
 [] ? next_zone+0x25/0x30
 [] ? pick_next_task_fair+0xa9/0x850
 [] process_one_work+0x151/0x3c0
 [] ? mod_timer+0xe9/0x160
 [] ? lock_timer_base+0x55/0x70
 [] ? schedule+0x3b/0xa0
 [] worker_thread+0x158/0x6b0
 [] ? __schedule+0x27a/0x6e0
 [] ? default_wake_function+0xd/0x10
 [] ? __wake_up_common+0x51/0x80
 [] ? schedule+0x3b/0xa0
 [] ? process_one_work+0x3c0/0x3c0
 [] kthread+0xc7/0xf0
 [] ? kthread_parkme+0x20/0x20
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_parkme+0x20/0x20
Code: 00 00 80 ff 77 00 00 48 01 df 48 0f 42 05 50 33 70 00 48 8d 3c 38 48 b8 
00 00 00 00 00 ea ff ff 48 c1 ef 0c 48 c1 e7 06 48 01 c7 <48> 8b 47 20 48 89 45 
e0 a8 01 75 64 48 8b 47 20 48 8d 57 20 48 
RIP  [] kfree+0x49/0x110
 RSP 
---[ end trace a3bcfa253dbef567 ]---
BUG: unable to handle kernel paging request at ffd8
IP: [] kthread_data+0xb/0x20
PGD a0b067 PUD a0d067 PMD 0 
Oops:  [#2] SMP DEBUG_PAGEALLOC 
Modules linked in: netconsole igb i2c_algo_bit ptp pps_core sg eeprom i2c_i801
CPU: 3 PID: 24 Comm: kworker/3:0 Tainted: G  D 
4.5.0-rc4-00095-g2850713 #14
Hardware name: Supermicro X8DTH-i/6/iF/6F/X8DTH, BIOS 2.1b   05/04/12  
task: 88042b09f080 ti: 88042b0a4000 task.ti: 88042b0a4000
RIP: 0010:[]  [] kthread_data+0xb/0x20
RSP: 0018:88042b0a7608  EFLAGS: 00010096
RAX:  RBX: 0003 RCX: 88043dc73840
RDX: 88042b09f080 RSI: 0003 RDI: 88042b09f080
RBP: 88042b0a7608 R08: 88043dc738a8 R09: 00016800
R10: 0001 R11: 0001 R12: 00013840
R13: 88042b09f4c8 R14: 0003 R15: 
FS:  () GS:88043dc6() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 0028 CR3: 00a0a000 CR4: 06e0
Stack:
 88042b0a7648 802731c0 88042b0a7648 8027d642
 88042b09f448 88043dc73840 00013840 88043dc73840
 88042b0a76f8 80608438 88042b09f3e0 88042b09f080
Call Trace:
 [] wq_worker_sleeping+0x10/0xa0
 [] ? deactivate_task+0x52/0x60
 [] __schedule+0x3a8/0x6e0
 [] ? exit_notify+0xed/0x1e0
 [] schedule+0x3b/0xa0
 [] do_exit+0x39a/0x580
 [] ? vprintk_default+0x1a/0x20
 [] ? printk+0x41/0x43
 [] oops_end+0x72/0xa0
 [] die+0x56/0x80
 [] do_general_protection+0xce/0x150
 [] general_protection+0x1f/0x30
 [] ? kfree+0x49/0x110
 [] ? usb_release_interface_cache+0x4a/0x60
 [] ? usb_destroy_configuration+0x11b/0x140
 

Re: [PATCH] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Lars Melin]

On 2016-02-19 17:31, Bjørn Mork wrote:

Daniel Johnson  writes:


Currently 4 ttyUSB devices are detected, but only the second two respond to
AT commands. The first two serial ports may be falsely detected.


One of them is likely a QCDM port if this is really a Qualcomm based
device.  The other might be an inactive NMEA port.  Serial doesn't
necessarily imply AT commands...





cfg #1
MI_00 HP Mobile Connect - PC UI Interface
MI_01 HP Mobile Connect - Application Interface
MI_02 HP Mobile Connect - Modem
MI_03 HP Mobile Connect - Network Card (jungo ncm)
MI_04 HP Mobile Connect - GPS Interface

cfg#2
MI_00 HP Mobile Connect - Network Card (cdc_ether)
MI_02 HP Mobile Connect - Modem
MI_03 HP Mobile Connect - Application Interface
MI_04 HP Mobile Connect - PC UI Interface
MI_05 HP Mobile Connect - GPS Interface

cfg#3
MI_00 HP Mobile Connect - Network Card (cdc_mbim)
MI_02 HP Mobile Connect - GPS Interface

Application Interface = QCDM

/Lars





--
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 RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Felipe Balbi]

Hi,

Fabio Estevam  writes:
> On Fri, Feb 19, 2016 at 11:33 AM, Felipe Balbi  wrote:
>
>> alright, in which sense doesn't it help ? Which platform did you use ?
>
> USB devices are not recognized with your patch applied on a mx28 board
> with an on-board USB hub and if I remove 'usbcore.autosuspend=-1' from
> the kernel command line.
>
>> mx23 or mx28 ? Did you check that mxs_phy_runtime_idle() got called ?
>
> mxs_phy_runtime_idle() is not being called on my mx28 board.

h, okay. So you have another problem, actually. Seems like ci_hdrc
just shouldn't call your phy->suspend(), or your phy->suspend()
shouldn't do anything. How about below?

@@ -370,6 +370,9 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
struct mxs_phy *mxs_phy = to_mxs_phy(x);
bool low_speed_connection, vbus_is_on;
 
+   if (mxs_phy->data->flags & MXS_PHY_ABNORMAL_IN_SUSPEND)
+   return 0; /* or should we return -EBUSY ? */
+
low_speed_connection = mxs_phy_is_low_speed_connection(mxs_phy);
vbus_is_on = mxs_phy_get_vbus_status(mxs_phy);
 


-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH v6 07/10] usb: chipidea: otg: enable HNP polling support for gadget and host

[Felipe Balbi]

hi,

Li Jun  writes:
> Enable HNP polling support for chipidea gadget and allocate memory
> for host request flag when otg fsm init.
>
> Acked-by: Peter Chen 
> Signed-off-by: Li Jun 

Why do you guys do this to me ? It's v6 and this thing still doesn't
compile. Why even send stuff you haven't even compile tested  Why ???

> ---
>  drivers/usb/chipidea/otg_fsm.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> index cb28e76..9a963a7 100644
> --- a/drivers/usb/chipidea/otg_fsm.c
> +++ b/drivers/usb/chipidea/otg_fsm.c
> @@ -797,6 +797,10 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
>   ci->fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
>   ci->fsm.otg->state = OTG_STATE_UNDEFINED;
>   ci->fsm.ops = _otg_ops;
> + ci->gadget.hnp_polling_support = 1;
> + ci->fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
> + if (!ci->fsm.host_req_flag)

the name of the flag is host_request_flag, not host_req_flag. Now, how
can I be certain you really tested this at all ? I won't accept this
without hard-proof of this really working.

Sorry guys, but it's v6 of this patch series and we're still having
build issues.

make -k -j8 -- drivers/usb/
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  UPD include/config/kernel.release
  CHK include/generated/utsrelease.h
  UPD include/generated/utsrelease.h
  CHK include/generated/timeconst.h
  CHK include/generated/bounds.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CC [M]  drivers/usb/chipidea/otg_fsm.o
drivers/usb/chipidea/otg_fsm.c: In function ‘ci_hdrc_otg_fsm_init’:
drivers/usb/chipidea/otg_fsm.c:801:9: error: ‘struct otg_fsm’ has no member 
named ‘host_req_flag’
  ci->fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
 ^
drivers/usb/chipidea/otg_fsm.c:802:14: error: ‘struct otg_fsm’ has no member 
named ‘host_req_flag’
  if (!ci->fsm.host_req_flag)
  ^
scripts/Makefile.build:258: recipe for target 'drivers/usb/chipidea/otg_fsm.o' 
failed
make[2]: *** [drivers/usb/chipidea/otg_fsm.o] Error 1
make[2]: Target '__build' not remade because of errors.
scripts/Makefile.build:407: recipe for target 'drivers/usb/chipidea' failed
make[1]: *** [drivers/usb/chipidea] Error 2
make[1]: Target '__build' not remade because of errors.
Makefile:1557: recipe for target 'drivers/usb/' failed
make: *** [drivers/usb/] Error 2

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Fabio Estevam]

On Fri, Feb 19, 2016 at 11:33 AM, Felipe Balbi  wrote:

> alright, in which sense doesn't it help ? Which platform did you use ?

USB devices are not recognized with your patch applied on a mx28 board
with an on-board USB hub and if I remove 'usbcore.autosuspend=-1' from
the kernel command line.

> mx23 or mx28 ? Did you check that mxs_phy_runtime_idle() got called ?

mxs_phy_runtime_idle() is not being called on my mx28 board.

> Did you have any splats on dmesg ?

[2.788614] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[2.837487] fec 800f.ethernet eth0: Freescale FEC PHY driver
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=800f.etherne:00, irq=
-1)
[2.968109] hub 1-1:1.0: USB hub found
[2.972876] hub 1-1:1.0: 2 ports detected
[3.499166] usb 1-1: USB disconnect, device number 2
[3.544724] usb usb1-port1: cannot reset (err = -32)
[3.550257] usb usb1-port1: cannot reset (err = -32)
[3.16] usb usb1-port1: cannot reset (err = -32)
[3.560903] usb usb1-port1: cannot reset (err = -32)
[3.566159] usb usb1-port1: cannot reset (err = -32)
[3.571306] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[3.579584] usb usb1-port1: cannot reset (err = -32)
[3.584850] usb usb1-port1: cannot reset (err = -32)
[3.590368] usb usb1-port1: cannot reset (err = -32)
[3.595628] usb usb1-port1: cannot reset (err = -32)
[3.601014] usb usb1-port1: cannot reset (err = -32)
[3.606027] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[3.613481] usb usb1-port1: cannot reset (err = -32)
[3.618868] usb usb1-port1: cannot reset (err = -32)
[3.624125] usb usb1-port1: cannot reset (err = -32)
[3.629615] usb usb1-port1: cannot reset (err = -32)
[3.634867] usb usb1-port1: cannot reset (err = -32)
[3.639988] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[3.647249] usb usb1-port1: cannot reset (err = -32)
[3.652744] usb usb1-port1: cannot reset (err = -32)
[3.657999] usb usb1-port1: cannot reset (err = -32)
[3.663369] usb usb1-port1: cannot reset (err = -32)
[3.668856] usb usb1-port1: cannot reset (err = -32)
[3.673866] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[3.680862] usb usb1-port1: unable to enumerate USB device
--
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 v6 00/10] add HNP polling support for usb otg fsm

[Jun Li]

Hi Felipe,

> -Original Message-
> From: Felipe Balbi [mailto:bal...@gmail.com]
> Sent: Friday, February 19, 2016 4:58 PM
> To: Jun Li ; Felipe Balbi 
> Cc: linux-usb@vger.kernel.org; Peter Chen ;
> hzpeterc...@gmail.com; gre...@linuxfoundation.org
> Subject: RE: [PATCH v6 00/10] add HNP polling support for usb otg fsm
> 
> 
> hi,
> 
> Jun Li  writes:
> > Hi Felipe
> >
> > I didn't get any response for this request, if you need a resend of
> > the whole patchset, please let me know.
> 
> please do, I can't find these on my inbox :-s

Already resend the whole series, you should have all of them now.

"[RESEND PATCH v6 00/10] add HNP polling support for usb otg fsm"

Li Jun
> 
> sorry. With all the changes lately, it took me a while to get things
> properly setup and I ended up loosing a few patches, apparently.
> 
> cheers
> 
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Felipe Balbi]

Hi,

Fabio Estevam  writes:
> Hi Felipe,
>
> On Fri, Feb 19, 2016 at 10:05 AM, Felipe Balbi  wrote:
>
>> how about detecting that you're running on mx23/mx28 and returning
>> -EBUSY on your runtime_idle implementation ? You already have the basics
>> done for it. Care to test below and tell me whether it helps ?
>
> Thanks for the suggestion. I tested it and unfortunately it does not
> help.

alright, in which sense doesn't it help ? Which platform did you use ?
mx23 or mx28 ? Did you check that mxs_phy_runtime_idle() got called ?
Did you have any splats on dmesg ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Fabio Estevam]

Hi Felipe,

On Fri, Feb 19, 2016 at 10:05 AM, Felipe Balbi  wrote:

> how about detecting that you're running on mx23/mx28 and returning
> -EBUSY on your runtime_idle implementation ? You already have the basics
> done for it. Care to test below and tell me whether it helps ?

Thanks for the suggestion. I tested it and unfortunately it does not help.
--
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/5] usb: musb: core: added helper functions for parsing DT

[Felipe Balbi]

Hi,

Sergei Shtylyov  writes:
> On 2/19/2016 10:23 AM, Felipe Balbi wrote:
>
>>> This adds two functions to get DT properties "mentor,power" and 
>>> "dr_mode":
>>> musb_get_power() and musb_mode musb_get_mode()
>>>
>>> Signed-off-by: Petr Kulhavy 
>> seems like I don't have patch 1/5. After fixing Sergei's comments,
>> please resend with his Acked-by already in place.
>>
>> thanks
> Hi Felipe,
>
> I will do as soon as the patch 1/5 gets approved.
> It seem to be a bit stuck at the moment as Rob Herring from the DT wants
> the "mentor,power"
> to be represented as a regulator, whereas Sergei and me want to stick to
> the existing "mentor,power" integer property.
>
> As soon as this get clarified I will do the final updates and send the
> patch again.
> Maybe this is something you can help to clarify?

 I don't think that makes sense as a regulator. It's just a number which
 gets passed to USB Core as is.
>>>
>>>  Well, in case of DaVinci's it's an external GPIO controlled
>>>  regulator indeed.
>>
>> oh, I see. Not controller by SetPortPower. That's a shame.
>>
 However, it seems like everything in kernel right now is passing it as
 500. So why don't you deprecate that property, hardcode it to 500 and
 avoid the problem altogether ?
>>>
>>>  OMAP boards can only supply 100 mA, AFAIK. Isn't it too early for the
>>> deprecation? :-)
>>
>>   $ git --no-pager grep -e mentor,power
>
> Grep for "power =" in arch/arm/boot/dts/ instead. OMAP props didn't even 
> have "mentor," prefix. :-/

s**t! Okay, then we can't ignore the detail heh. Adding Bin here to see
if he can patch those older devicetree files.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Felipe Balbi]

Hi,

Fabio Estevam  writes:
> From: Fabio Estevam 
>
> On a mx28 board with a USB hub the following error is observed:
>
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 2 ports detected
> usb 1-1: USB disconnect, device number 2
> usb usb1-port1: cannot reset (err = -32)
> usb usb1-port1: cannot reset (err = -32)
> usb usb1-port1: cannot reset (err = -32)
> usb usb1-port1: cannot reset (err = -32)
> usb usb1-port1: cannot reset (err = -32)
> usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
>
> ,which is caused by a problem described by the MXS_PHY_ABNORMAL_IN_SUSPEND
> flag.

how about detecting that you're running on mx23/mx28 and returning
-EBUSY on your runtime_idle implementation ? You already have the basics
done for it. Care to test below and tell me whether it helps ?

modified   drivers/usb/phy/phy-mxs-usb.c
@@ -564,8 +564,23 @@ static int mxs_phy_system_resume(struct device *dev)
 }
 #endif /* CONFIG_PM_SLEEP */
 
-static SIMPLE_DEV_PM_OPS(mxs_phy_pm, mxs_phy_system_suspend,
-   mxs_phy_system_resume);
+#ifdef CONFIG_PM
+static int mxs_phy_runtime_idle(struct device *dev)
+{
+   struct mxs_phy *mxs_phy = dev_get_drvdata(dev);
+
+   if (mxs_phy->data->flags & MXS_PHY_ABNORMAL_IN_SUSPEND)
+   return -EBUSY;
+
+   return 0;
+}
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops mxs_phy_pm = {
+   SET_SYSTEM_SLEEP_PM_OPS(mxs_phy_system_suspend,
+   mxs_phy_system_resume)
+   SET_RUNTIME_PM_OPS(NULL, NULL, mxs_phy_runtime_idle)
+};
 
 static struct platform_driver mxs_phy_driver = {
.probe = mxs_phy_probe,



-- 
balbi


signature.asc
Description: PGP signature

[PATCH RESEND] usb: phy: mxs: Suggest passing "usbcore.autosuspend=-1" for mx23/mx28

[Fabio Estevam]

From: Fabio Estevam 

On a mx28 board with a USB hub the following error is observed:

hub 1-1:1.0: USB hub found
hub 1-1:1.0: 2 ports detected
usb 1-1: USB disconnect, device number 2
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: Cannot enable. Maybe the USB cable is bad?

,which is caused by a problem described by the MXS_PHY_ABNORMAL_IN_SUSPEND
flag.

As we currently do not have a proper implementation for this issue, one
possible workaround is to pass "usbcore.autosuspend=-1" in the kernel
command line, so add this suggestion into the MXS_PHY_ABNORMAL_IN_SUSPEND
flag description.

Signed-off-by: Fabio Estevam 
Acked-by: Peter Chen 
---
 drivers/usb/phy/phy-mxs-usb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 00bfea0..be46ab3 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -98,6 +98,10 @@
  * The PHY will be in messy if there is a wakeup after putting
  * bus to suspend (set portsc.suspendM) but before setting PHY to low
  * power mode (set portsc.phcd).
+ *
+ * To work around this problem on mx23/mx28 user should pass
+ * "usbcore.autosuspend=-1" in the kernel command line for now, as
+ * we do not have a proper fix for this flag in the kernel yet.
  */
 #define MXS_PHY_ABNORMAL_IN_SUSPENDBIT(1)
 
-- 
1.9.1

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

Re: [PATCH 2/5] usb: musb: core: added helper functions for parsing DT

[Sergei Shtylyov]

On 2/19/2016 10:23 AM, Felipe Balbi wrote:


This adds two functions to get DT properties "mentor,power" and "dr_mode":
musb_get_power() and musb_mode musb_get_mode()

Signed-off-by: Petr Kulhavy 

seems like I don't have patch 1/5. After fixing Sergei's comments,
please resend with his Acked-by already in place.

thanks

Hi Felipe,

I will do as soon as the patch 1/5 gets approved.
It seem to be a bit stuck at the moment as Rob Herring from the DT wants
the "mentor,power"
to be represented as a regulator, whereas Sergei and me want to stick to
the existing "mentor,power" integer property.

As soon as this get clarified I will do the final updates and send the
patch again.
Maybe this is something you can help to clarify?


I don't think that makes sense as a regulator. It's just a number which
gets passed to USB Core as is.


 Well, in case of DaVinci's it's an external GPIO controlled
 regulator indeed.


oh, I see. Not controller by SetPortPower. That's a shame.


However, it seems like everything in kernel right now is passing it as
500. So why don't you deprecate that property, hardcode it to 500 and
avoid the problem altogether ?


 OMAP boards can only supply 100 mA, AFAIK. Isn't it too early for the
deprecation? :-)


  $ git --no-pager grep -e mentor,power


   Grep for "power =" in arch/arm/boot/dts/ instead. OMAP props didn't even 
have "mentor," prefix. :-/



Documentation/devicetree/bindings/usb/am33xx-usb.txt:44:- mentor,power: Should be 
"500". This signifies the controller can supply up to
Documentation/devicetree/bindings/usb/am33xx-usb.txt:112:   mentor,power 
= <500>;
Documentation/devicetree/bindings/usb/am33xx-usb.txt:157:   mentor,power 
= <500>;
arch/arm/boot/dts/am33xx.dtsi:580:  mentor,power = 
<500>;
arch/arm/boot/dts/am33xx.dtsi:627:  mentor,power = 
<500>;
arch/arm/boot/dts/dm814x.dtsi:91:   mentor,power = 
<500>;
arch/arm/boot/dts/dm814x.dtsi:129:  mentor,power = 
<500>;
arch/arm/boot/dts/dm816x.dtsi:414:  mentor,power = 
<500>;
arch/arm/boot/dts/dm816x.dtsi:454:  mentor,power = 
<500>;
drivers/usb/musb/musb_dsps.c:744:   pdata.power = get_int_prop(dn, 
"mentor,power") / 2;

Even documentation says it _must_ be 500.


   AM33xx is not exactly OMAP. Look at the device trees having names starting 
with "omap" and look at 'omap-usb.txt' in the bindings USB subdir.


MBR, Sergei

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

ftdi_sio: ftdi_set_termios

[Matwey V. Kornilov]

Dear Bill and all,

I am facing an issue with ftdi_sio module and FTDI FT232-based
devices. Now I am trying to understand where the origin is.
By indirect evidences, I think that there is a small time gap between
return of tcsetattr(fd_, TCSANOW, _termios) and actual settings
application in the hardware. From the kernel sources I see that
tcsetattr returns after ftdi_set_termios complete, which uses sync
usb_control_msg calls.
Unfortunately, I've not found data-sheet for FT232 describing USB
protocol, so I would like to ask whether it is guaranteed that new
settings are applied in hardware before ftdi_set_termios returns?

-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
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] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Bjørn Mork]

Daniel Johnson  writes:

>>> Currently 4 ttyUSB devices are detected, but only the second two respond to
>>> AT commands. The first two serial ports may be falsely detected.
>>
>> One of them is likely a QCDM port if this is really a Qualcomm based
>> device.  The other might be an inactive NMEA port.  Serial doesn't
>> necessarily imply AT commands...
>
> I remember that some tool I tried didn't like the first two serial
> ports for some reason. I thought that might be another clue.
>
>>> Of the two responsive serial devices the first is the source of unsolicited
>>> information such as a SIM insert. The second is always the source of NMEA
>>> messages.
>>>
>>> A have not figured out the correct AT commands to connect to a cell network
>>> so the created network interface is untested.
>>
>> Huawei use subclass+protocol to differentiate their vendor specific
>> functions, so we usually get some idea of what to expect from the USB
>> descriptors.
>>
>> Could you post the output of "lsusb -vd 03f0:9a1d", or the relevant part
>> of /sys/kernel/debug/usb/devices?
>>
>> If this doesn't help, then the Windows drivers (if any?) should give
>> some clue.
>
> It has a windows driver. It is build into the US model of the HP
> Spectre X2 I'm typing on. HP only officially supports the Verizon cell
> phone even though Huawei manuals indicate it supporting many networks.
> It can certainly scan for all the major US carriers. I don't have an
> activated Verizon SIM so I tried the T-Mobile one from my phone. In
> windows it would connect, and get a working internet connection, and
> then reset after about a minute. In Linux the T-Mobile SIM would
> sometimes cause the same behavior where the module seemed to be doing
> a hardware reset.

The reset could of course be by purpose, but I'd say that a firmware
crash is just as likely.  Modem firmwares often tend to be unstable
under unexpected conditions...

> Bus 001 Device 028: ID 03f0:9a1d Hewlett-Packard
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass  239 Miscellaneous Device
>   bDeviceSubClass 2 ?
>   bDeviceProtocol 1 Interface Association
>   bMaxPacketSize064
>   idVendor   0x03f0 Hewlett-Packard
>   idProduct  0x9a1d
>   bcdDevice0.01
>   iManufacturer   6 Hewlett-Packard
>   iProduct5 HP lt4114 LTE 4G Module
>   iSerial 0
>   bNumConfigurations  3

Good.  So you have a few alternative configs here. I forgot to ask, but
I assume you've ended up with cfg #2 by default (because Linux has a
class preference, making it select the first config with a non 0xff
class as the first interface).  Anyway, we can go through all three as
they will share most of the functions.

The driver messages in dmesg will tell you which configuration was
selected, or you can read the /sys/bus/usb/devices/x-y/bConfigurationValue
sysfs attribute. Switching configs is as easy as writing to the same
attribute.  E.g

 echo 3 >/sys/bus/usb/devices/x-y/bConfigurationValue


1st, assumed inactive, config:

>  Configuration Descriptor:
>bLength 9
>bDescriptorType 2
>wTotalLength  259
>bNumInterfaces  5
>bConfigurationValue 1
>iConfiguration  2 configuration 0
>bmAttributes 0xa0
>  (Bus Powered)
>  Remote Wakeup
>MaxPower  500mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass   255 Vendor Specific Class
>   bInterfaceSubClass  5
>   bInterfaceProtocol 18

This is a serial function of some kind. It would be handled by the
option driver if the modem had a Huawei vendor ID.

> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber1
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass   255 Vendor Specific Class
>   bInterfaceSubClass  5
>   bInterfaceProtocol 19

Like intf #0. The different protocol numbers probably indicate different
types of serial functions, but I don't know that mapping.


> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber2
>   bAlternateSetting   0
>   bNumEndpoints   3
>   bInterfaceClass   255 Vendor Specific Class
>   bInterfaceSubClass  5
>   bInterfaceProtocol 16

And another serial function.

> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber3
>   bAlternateSetting   0
>   bNumEndpoints   1
>   bInterfaceClass   255 Vendor 

Re: [PATCH v6 1/1] USB: core: let USB device know device node

[Arnd Bergmann]

On Friday 19 February 2016 17:26:15 Peter Chen wrote:
> From: Peter Chen 
> 
> Although most of USB devices are hot-plug's, there are still some devices
> are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> If these kinds of USB devices are multiple functions, and they can supply
> other interfaces like i2c, gpios for other devices, we may need to
> describe these at device tree.
> 
> In this commit, it uses "reg" in dts as physical port number to match
> the phyiscal port number decided by USB core, if they are the same,
> then the device node is for the device we are creating for USB core.
> 
> Signed-off-by: Peter Chen 
> Acked-by: Philipp Zabel 
> Acked-by: Alan Stern 
> Acked-by: Rob Herring 
> 

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

[PATCH v6 1/1] USB: core: let USB device know device node

[Peter Chen]

From: Peter Chen 

Although most of USB devices are hot-plug's, there are still some devices
are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
If these kinds of USB devices are multiple functions, and they can supply
other interfaces like i2c, gpios for other devices, we may need to
describe these at device tree.

In this commit, it uses "reg" in dts as physical port number to match
the phyiscal port number decided by USB core, if they are the same,
then the device node is for the device we are creating for USB core.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Alan Stern 
Acked-by: Rob Herring 
---

Changes for v6:
- Add textual representation for VID and PID in binding doc, and changing
  example accordingly.
- Add three Acks.

Changes for v5:
- Refine the code how to get the device node at usb_alloc_dev according
  to Alan's comment.
- Point out "usbVID,PID" is the recommented compatible, and others
  compatibles at binding doc could also be used.

Changes for v4:
- The range of "reg" should be 1-31, changing device node address
  style as in lower case hexadecimal with leading zeroes suppressed
  [binding doc, usb-device.txt]
- Improve the example at binding doc, it describes node from the top
  (the controller)
- Delete the struct of_node * within struct usb_device
- Using usb_hcd_find_raw_port_number to get raw port number under root
  hub port

Changes for v3:
- typo: s/descirbe/describe/

Changes for v2:
- Fix build error reported by kbuild robot, lack of "static" for
  inline usb_of_get_child_node
- Fix typo, "devcie_node" -> "device_node"
- Add kernel-doc for of_node at struct usb_device

Changes from RFC:
- Fix the error address for binding doc, and add compatible for binding doc
- Change get child node API from "usb_of_find_node" to
  "usb_of_get_child_node"
- Delete unecessary header files
- One typo

 .../devicetree/bindings/usb/usb-device.txt | 28 +
 drivers/usb/core/Makefile  |  2 +-
 drivers/usb/core/of.c  | 47 ++
 drivers/usb/core/usb.c | 10 +
 include/linux/usb/of.h |  7 
 5 files changed, 93 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
 create mode 100644 drivers/usb/core/of.c

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
b/Documentation/devicetree/bindings/usb/usb-device.txt
new file mode 100644
index 000..1c35e7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -0,0 +1,28 @@
+Generic USB Device Properties
+
+Usually, we only use device tree for hard wired USB device.
+The reference binding doc is from:
+http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
+
+Required properties:
+- compatible: usbVID,PID. The textual representation of VID, PID shall
+  be in lower case hexadecimal with leading zeroes suppressed. The
+  other compatible strings from the above standard binding could also
+  be used, but a device adhering to this binding may leave out all except
+  for usbVID,PID.
+- reg: the port number which this device is connecting to, the range
+  is 1-31.
+
+Example:
+
+ {
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hub: genesys@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+   };
+}
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 2f6f932..9780877 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -5,7 +5,7 @@
 usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
 usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
 usbcore-y += devio.o notify.o generic.o quirks.o devices.o
-usbcore-y += port.o
+usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)  += hcd-pci.o
 usbcore-$(CONFIG_ACPI) += usb-acpi.o
diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
new file mode 100644
index 000..2289700
--- /dev/null
+++ b/drivers/usb/core/of.c
@@ -0,0 +1,47 @@
+/*
+ * of.cThe helpers for hcd device tree support
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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, see 

[PATCH] MAINTAINERS: drop OMAP USB and MUSB maintainership

[Felipe Balbi]

Now that I have switched to another company, I won't
be able to help by maintaining OMAP USB Support and/or
the MUSB driver.

OMAP USB Support is left Orphaned. MUSB's new
maintainer will be Bin Liu from Texas Instruments
who has accepted to take over starting with v4.6.

Cc: Bin Liu 
Signed-off-by: Felipe Balbi 
---
 MAINTAINERS | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cc2f753cb357..65f34bb04d7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3444,7 +3444,6 @@ F:drivers/usb/dwc2/
 DESIGNWARE USB3 DRD IP DRIVER
 M: Felipe Balbi 
 L: linux-usb@vger.kernel.org
-L: linux-o...@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
 S: Maintained
 F: drivers/usb/dwc3/
@@ -7354,7 +7353,7 @@ F:drivers/tty/isicom.c
 F: include/linux/isicom.h
 
 MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER
-M: Felipe Balbi 
+M: Bin Liu 
 L: linux-usb@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
 S: Maintained
@@ -7923,11 +7922,9 @@ F:   drivers/media/platform/omap3isp/
 F: drivers/staging/media/omap4iss/
 
 OMAP USB SUPPORT
-M: Felipe Balbi 
 L: linux-usb@vger.kernel.org
 L: linux-o...@vger.kernel.org
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
-S: Maintained
+S: Orphan
 F: drivers/usb/*/*omap*
 F: arch/arm/*omap*/usb*
 
-- 
2.7.0.GIT

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

RE: [PATCH v6 00/10] add HNP polling support for usb otg fsm

[Felipe Balbi]

hi,

Jun Li  writes:
> Hi Felipe
>
> I didn't get any response for this request, if you need a resend
> of the whole patchset, please let me know.

please do, I can't find these on my inbox :-s

sorry. With all the changes lately, it took me a while to get things
properly setup and I ended up loosing a few patches, apparently.

cheers

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Daniel Johnson]

>> Currently 4 ttyUSB devices are detected, but only the second two respond to
>> AT commands. The first two serial ports may be falsely detected.
>
> One of them is likely a QCDM port if this is really a Qualcomm based
> device.  The other might be an inactive NMEA port.  Serial doesn't
> necessarily imply AT commands...

I remember that some tool I tried didn't like the first two serial
ports for some reason. I thought that might be another clue.

>> Of the two responsive serial devices the first is the source of unsolicited
>> information such as a SIM insert. The second is always the source of NMEA
>> messages.
>>
>> A have not figured out the correct AT commands to connect to a cell network
>> so the created network interface is untested.
>
> Huawei use subclass+protocol to differentiate their vendor specific
> functions, so we usually get some idea of what to expect from the USB
> descriptors.
>
> Could you post the output of "lsusb -vd 03f0:9a1d", or the relevant part
> of /sys/kernel/debug/usb/devices?
>
> If this doesn't help, then the Windows drivers (if any?) should give
> some clue.

It has a windows driver. It is build into the US model of the HP
Spectre X2 I'm typing on. HP only officially supports the Verizon cell
phone even though Huawei manuals indicate it supporting many networks.
It can certainly scan for all the major US carriers. I don't have an
activated Verizon SIM so I tried the T-Mobile one from my phone. In
windows it would connect, and get a working internet connection, and
then reset after about a minute. In Linux the T-Mobile SIM would
sometimes cause the same behavior where the module seemed to be doing
a hardware reset.

Bus 001 Device 028: ID 03f0:9a1d Hewlett-Packard
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x03f0 Hewlett-Packard
  idProduct  0x9a1d
  bcdDevice0.01
  iManufacturer   6 Hewlett-Packard
  iProduct5 HP lt4114 LTE 4G Module
  iSerial 0
  bNumConfigurations  3
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  259
bNumInterfaces  5
bConfigurationValue 1
iConfiguration  2 configuration 0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  5
  bInterfaceProtocol 18
  iInterface  0
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  5
  bInterfaceProtocol 19
  iInterface  0
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 01 00 01
  ** UNRECOGNIZED:  05 24 06 01 01
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 

Re: [PATCH v5 1/1] USB: core: let USB device know device node

[Philipp Zabel]

Hi Peter,

Am Dienstag, den 16.02.2016, 16:42 +0800 schrieb Peter Chen:
> From: Peter Chen 
> 
> Although most of USB devices are hot-plug's, there are still some devices
> are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> If these kinds of USB devices are multiple functions, and they can supply
> other interfaces like i2c, gpios for other devices, we may need to
> describe these at device tree.
> 
> In this commit, it uses "reg" in dts as physical port number to match
> the phyiscal port number decided by USB core, if they are the same,
> then the device node is for the device we are creating for USB core.
> 
> Signed-off-by: Peter Chen 
> ---
> Changes for v5:
> - Refine the code how to get the device node at usb_alloc_dev according
>   to Alan's comment.
> - Point out "usbVID,PID" is the recommented compatible, and others
>   compatibles at binding doc could also be used.
> 
> Changes for v4:
> - The range of "reg" should be 1-31, changing device node address
>   style as in lower case hexadecimal with leading zeroes suppressed
>   [binding doc, usb-device.txt]
> - Improve the example at binding doc, it describes node from the top
>   (the controller)
> - Delete the struct of_node * within struct usb_device
> - Using usb_hcd_find_raw_port_number to get raw port number under root
>   hub port
> 
> Changes for v3:
> - typo: s/descirbe/describe/
> 
> Changes for v2:
> - Fix build error reported by kbuild robot, lack of "static" for
>   inline usb_of_get_child_node
> - Fix typo, "devcie_node" -> "device_node"
> - Add kernel-doc for of_node at struct usb_device
> 
> Changes from RFC:
> - Fix the error address for binding doc, and add compatible for binding doc
> - Change get child node API from "usb_of_find_node" to
>   "usb_of_get_child_node"
> - Delete unecessary header files
> - One typo
> 
>  .../devicetree/bindings/usb/usb-device.txt | 26 
>  drivers/usb/core/Makefile  |  2 +-
>  drivers/usb/core/of.c  | 47 
> ++
>  drivers/usb/core/usb.c | 10 +
>  include/linux/usb/of.h |  7 
>  5 files changed, 91 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
>  create mode 100644 drivers/usb/core/of.c
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
> b/Documentation/devicetree/bindings/usb/usb-device.txt
> new file mode 100644
> index 000..a997a23
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-device.txt
> @@ -0,0 +1,26 @@
> +Generic USB Device Properties
> +
> +Usually, we only use device tree for hard wired USB device.
> +The reference binding doc is from:
> +http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> +
> +Required properties:
> +- compatible: usbVID,PID. The other compatible strings from the above
> +  standard binding could also be used, but a device adhering to this
> +  binding may leave out all except for usbVID,PID.

I asked to document the format of VID and PID ("lower case hexadecimal
with leading zeroes suppressed") here.

> +- reg: the port number which this device is connecting to, the range
> +  is 1-31.
> +
> +Example:
> +
> + {
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hub: genesys@1 {
> + compatible = "usb05e3,0608";

This should be:
compatible = "usb5e3,608";

After those two issues are fixed,
Acked-by: Philipp Zabel 

best regards
Philipp


--
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] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Bjørn Mork]

Daniel Patrick Johnson  writes:

> Adds HP lt4114 LTE module USB ID as a Huawei device.
>
> Currently 4 ttyUSB devices are detected, but only the second two respond to
> AT commands. The first two serial ports may be falsely detected.

One of them is likely a QCDM port if this is really a Qualcomm based
device.  The other might be an inactive NMEA port.  Serial doesn't
necessarily imply AT commands...

> Of the two responsive serial devices the first is the source of unsolicited
> information such as a SIM insert. The second is always the source of NMEA
> messages.
>
> A have not figured out the correct AT commands to connect to a cell network
> so the created network interface is untested.

Huawei use subclass+protocol to differentiate their vendor specific
functions, so we usually get some idea of what to expect from the USB
descriptors.

Could you post the output of "lsusb -vd 03f0:9a1d", or the relevant part
of /sys/kernel/debug/usb/devices?

If this doesn't help, then the Windows drivers (if any?) should give
some clue.


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

[PATCH] Support HP lt4114 LTE Module (Huawei ME206V-561)

[Daniel Patrick Johnson]

Adds HP lt4114 LTE module USB ID as a Huawei device.

Currently 4 ttyUSB devices are detected, but only the second two respond to
AT commands. The first two serial ports may be falsely detected.

Of the two responsive serial devices the first is the source of unsolicited
information such as a SIM insert. The second is always the source of NMEA
messages.

A have not figured out the correct AT commands to connect to a cell network
so the created network interface is untested.

Signed-off-by: Daniel Patrick Johnson 
---
 drivers/usb/serial/qcserial.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 9919d2a..4f8f65f 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -168,6 +168,7 @@ static const struct usb_device_id id_table[] = {
 
/* Huawei devices */
{DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G Modem 
(Huawei me906e) */
+   {DEVICE_HWI(0x03f0, 0x9a1d)},   /* HP lt4114 LTE (Huawei ME206V-561) */
 
{ } /* Terminating entry */
 };
-- 
2.5.0

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