Re: [PATCH] USB: serial: option: adding support for ublox R410M

[Dan Williams]

On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> > On 4/26/2018 23:12, Johan Hovold wrote:
> > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> > > > On 4/26/2018 18:39, Lars Melin wrote:
> > > > > On 4/26/2018 18:19, Bjørn Mork wrote:
> > > > > > Anyway, Qualcomm based designs are definitely handled by
> > > > > > both drivers.
> > > > > > Using qcserial only makes sense if the interface layout
> > > > > > matches one of
> > > > > > the defined shared schemes, which currently are:
> > > > > > 
> > > > > >  QCSERIAL_G2K = 0,/* Gobi 2000 */
> > > > > >  QCSERIAL_G1K = 1,/* Gobi 1000 */
> > > > > >  QCSERIAL_SWI = 2,/* Sierra Wireless */
> > > > > >  QCSERIAL_HWI = 3,/* Huawei */
> > > > > 
> > > > > It seems to me that this Quectel device matches the interface
> > > > > layout for
> > > > > Gobi1K:
> > > Yeah, but qcserial appears to select a different altsetting for
> > > the DM
> > > port for Gobi 1000, an altsetting which this particular device
> > > does not
> > > have.
> > > 
> > > I didn't re-read the full thread I referred to earlier, but I
> > > think in
> > > it, Dan mentioned Gobi 1000 device requiring firmware to be
> > > loaded too.
> > > 
> > > So if it's not a G1K device, we probably shouldn't be using
> > > qcserial
> > > even if the interface layout happens to match.
> > Good point, I forgot about the required firmware loading for
> > Gobi1K.
> > So this device should be handled by the option driver.
> 
> Yeah, we probably should document all of this at some point. :)
> 
> I didn't include the patch in this weeks -rc updates, but I've queued
> it
> up for the next batch.

Option is likely the right driver for this device.

qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as
the modem port and a secondary DIAG/DM port driven by qcaux.  The DM
port doesn't have an interrupt endpoint thus it's not a normal modem
port requiring the larger buffers of option and its control signaling.

qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with
the specific layouts and the firmware loading requirement where the 1K
and 2K devices start in a special 1-port mode waiting for firmware and
then become 4-port devices on firmware reboot.

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

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Dan Williams]

On Tue, 2018-04-24 at 09:55 +0700, Lars Melin wrote:
> On 4/23/2018 23:54, Dan Williams wrote:
> 
> > > MI_00 D-Link Mobile Broadband Device  (cdc_ether)
> > > MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp m
> > > MI_03 D-Link HSPA+DataCard NMEA Device
> > > MI_04 D-Link HSPA+DataCard Speech Port
> > 
> > Any idea what format this port speaks?  Some Huawei Qualcomm-based
> > devices still use a TTY driver but send/receive 16-bit 8000hz PCM
> > audio
> > frames via a serial port.  If the D-Link does something similar, it
> > may
> > still make sense to drive it via option.
> > 
> > > MI_05 D-Link HSPA+DataCard Debug Port
> > 
> > If it's FCCID KA2WM158B1 then it's a Qualcomm device, and this port
> > may
> > be a DIAG port.  It should also be driven by option if that's the
> > case.
> > 
> > I looked but couldn't find downloadable drivers for the DWM-158 so
> > I
> > couldn't double-check myself.
> > 
> > Dan
> 
> This is a DWM-158D1 or maybe they have versioned it E1, it is
> Mediatek 
> based.

Fair enough, then it certainly won't have DM/DIAG.

Dan

> Most (all?) of new D-Link modems are made by BroadMobi using
> Mediatek 
> chipset and having an additional AT cmdset in the AT+BM form.
> 
> 
> /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] usb:serial:optrion: fix dwm-158 3g modem interface

[Dan Williams]

On Mon, 2018-04-23 at 14:14 +0700, Lars Melin wrote:
> On 4/23/2018 14:03, Giuseppe Lippolis wrote:
> > The dwm-158 interface 4 and 5 doesn't answer to the AT commands
> > and doesn't appears a option interface.
> > Tested on openwrt distribution (kernel 4.14 using the old blacklist
> > definitions).
> > 
> > Signed-off-by: Giuseppe Lippolis 
> > ---
> >   drivers/usb/serial/option.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/serial/option.c
> > b/drivers/usb/serial/option.c
> > index c3f252283ab9..f0c3612467a3 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -1911,7 +1911,8 @@ static const struct usb_device_id
> > option_ids[] = {
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d01, 0xff) },   
> > /* D-Link DWM-156 (variant) */
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d02, 0xff) },
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d03, 0xff) },
> > -   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
> > /* D-Link DWM-158 */
> > +   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff), 
> > /* D-Link DWM-158 */
> > +.driver_info = RSVD(4) | RSVD(5) },
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d0e, 0xff) },   
> > /* D-Link DWM-157 C1 */
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
> > /* D-Link DWM-221 B1 */
> >   .driver_info = RSVD(4) },
> 
> Blacklisting interface 4 and 5 is correct because:
> 
> MI_00 D-Link Mobile Broadband Device  (cdc_ether)
> MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp modem)
> MI_03 D-Link HSPA+DataCard NMEA Device
> MI_04 D-Link HSPA+DataCard Speech Port

Any idea what format this port speaks?  Some Huawei Qualcomm-based
devices still use a TTY driver but send/receive 16-bit 8000hz PCM audio
frames via a serial port.  If the D-Link does something similar, it may
still make sense to drive it via option.

> MI_05 D-Link HSPA+DataCard Debug Port

If it's FCCID KA2WM158B1 then it's a Qualcomm device, and this port may
be a DIAG port.  It should also be driven by option if that's the case.

I looked but couldn't find downloadable drivers for the DWM-158 so I
couldn't double-check myself.

Dan

> MI_06 USB Mass Storage Device
> 
> 
> rgds
> /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
--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Dan Williams]

On Sun, 2018-03-25 at 13:52 -0700, Tony Lindgren wrote:
> * Pavel Machek  [180325 19:00]:
> > Hi!
> > 
> > > > Hmm. Interesting. Anyway, for me ttyUSB4 is interesting, as it
> > > > seems
> > > > to react to AT commands, and in particular reacts to ADT123; (;
> > > > is
> > > > important).
> > > 
> > > Is that to dial a voice call?
> > 
> > Yes. And it is ATD123; not ATD.
> 
> Strange, no semicolon is needed when using /dev/gsmtty to
> dial a voice call with my current pile of pending changes,
> just doing ATD123 dials..
> 
> Anyways, looks like qmi_wwan needs to be loaded before
> qcserial module, otherwise we get nine ttyUSB instances
> and ModemManager can't find any modems.

Use qcaux.c or option, unless the 6600 actually *does* have the same
layout as Gobi 1K/2K/etc devices.

If you're going to use qcaux or optoin, then you need to use some
variant of USB_DEVICE_AND_INTERFACE_INFO to lock the serial driver to
the specific USB interfaces that expose the TTYs and to ignore the QMI
interfaces and netdevs.

Dan

> With qcserial module loaded after qmi_wwan, it still takes
> a long time for ModemManager to find the modem.
> 
> Then unrelated to the qcserial module, also looks like I can
> no longer use the GPS with ModemManager:
> 
> $ mmcli -m 0 --enable
> $ mmcli -m 0 --location-enable-gps-raw
> 
> And then chmod a+r /dev/cdc-wdm0 and pointing gpsd to use
> /dev/cdc-wdm0 used to work, but now it seems that gpsd
> can no longer read it. Trying to start gpsd manually produces:
> 
> # gpsd -b -n -N /dev/cdc-wdm0
> gpsd:ERROR: SER: /dev/cdc-wdm0 already opened by another process
> gpsd:ERROR: initial GPS device /dev/cdc-wdm0 open failed
> gpsd:ERROR: can't run with neither control socket nor devices open
> 
> And lsof shows /usr/libexec/qmi-proxy having it open.
> 
> Anybody know what I might be doing wrong? Sounds like something
> now needs to be done with qmi-proxy to get access to GPS?
> 
> > > Anyway, "good" solution is to get ofonod running, then use ofone
> > > from
> > > here: https://github.com/pavelmachek/unicsy_demo
> 
> Thanks I'll take a look.
> 
> > > I think it's the cpcap based config to route voice call audio
> > > to SoC, Sebastian knows the details :)
> > > 
> > > The way to figure that one out is to dump the cpcap registers
> > > before and during voice call on android with cpcaprw, then
> > > diff the output for the audio registers. Probably some SoC
> > > registers need to be diffed too with rwmem or similar tool
> > > for the mcbsp instance(s) used.
> > 
> > That sounds like hard way to do it. There's source available, I'm
> > now
> > trying to understand it / fit it into Sebastian's driver.
> > 
> > https://raw.githubusercontent.com/NotKit/android_kernel_motorola_om
> > ap4-common/hybris-11.0/sound/soc/codecs/cpcap.c
> 
> Sure that hopefully helps too :)
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Dan Williams]

On Fri, 2018-03-23 at 21:13 +0100, Pavel Machek wrote:
> On Fri 2018-03-23 12:35:21, Sebastian Reichel wrote:
> > Hi,
> > 
> > On Fri, Mar 23, 2018 at 11:54:55AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > > Do you have the related dts patches picked from next?
> > > > > > 
> > > > > > fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port
> > > > > > naming")
> > > > > > e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600
> > > > > > USB PHY")
> > > > > > 
> > > > > > But yeah all you need to do is have phy-mapphone-mdm6600
> > > > > > and
> > > > > > ohci-platform loaded and then ifconfig should show four
> > > > > > wwan
> > > > > > interfaces being added.
> > > > > 
> > > > > ifconfig? I thought I should get /dev/ttyUSB0..3?
> > > > 
> > > > I believe they are QMI via qmi_wwan, not TTYs.
> > > 
> > > Well, qmicli expects device path... and I see nothing on
> > > ifconfig. Any
> > > idea how the device would be named?
> > > 
> > > But I believe it just does not work, see the qcserial experiment
> > > with
> > > new_id below.
> > 
> > Dan is right, you need qmi_wwan driver. qmicli expects
> > /dev/cdc-wdm device. I use this on Droid 4:
> > 
> > qmicli -d /dev/cdc-wdm0 --some-other-option
> 
> Aha, there's ./drivers/usb/serial/usb_wwan.c and there's
> ./drivers/net/usb/qmi_wwan.o . That confused me.
> 
> qmicli now works for me, thanks!
> 
> Tested-by: Pavel Machek 
> 
> Does ofonod work for you? I could not get that one to work...

Because it's looking for a Gobi modem but the MDM6600 isn't one and
doesn't expose that layout (and doesn't really need to anyway).  I
don't think ofono has a generic QMI driver, so you'd either need to for
ce it to use the telitqmi or quectelqmi drivers, or write your own
generic QMI one.

Dan

> ofonod[4083]: plugins/udevng.c:create_modem()
> /sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/u
> sb2/2-1
> ofonod[4083]: plugins/udevng.c:create_modem() driver=gobi
> ofonod[4083]: src/modem.c:ofono_modem_create() name: (null), type:
> gobi
> ofonod[4083]: plugins/udevng.c:setup_gobi()
> /sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/u
> sb2/2-1
> ofonod[4083]: plugins/udevng.c:setup_gobi() /dev/cdc-wdm0 255/251/255
> 05 (null) (null) usbmisc
> ofonod[4083]: plugins/udevng.c:setup_gobi() wwan0 255/251/255 05
> (null) (null) net
> ofonod[4083]: plugins/udevng.c:setup_gobi() /dev/cdc-wdm1 255/251/255
> 06 (null) (null) usbmisc
> ofonod[4083]: plugins/udevng.c:setup_gobi() wwan1 255/251/255 06
> (null) (null) net
> ofonod[4083]: plugins/udevng.c:setup_gobi() /dev/cdc-wdm2 255/251/255
> 07 (null) (null) usbmisc
> ofonod[4083]: plugins/udevng.c:setup_gobi() wwan2 255/251/255 07
> (null) (null) net
> ofonod[4083]: plugins/udevng.c:setup_gobi() /dev/cdc-wdm3 255/251/255
> 08 (null) (null) usbmisc
> ofonod[4083]: plugins/udevng.c:setup_gobi() wwan3 255/251/255 08
> (null) (null) net
> ofonod[4083]: plugins/udevng.c:destroy_modem()
> /sys/devices/platform/4400.ocp/4a064000.usbhshost/4a064800.ohci/u
> sb2/2-1
> ofonod[4083]: src/modem.c:ofono_modem_remove() 0x5eb380
> ofonod[4083]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm0
> ofonod[4083]: plugins/udevng.c:destroy_modem() wwan0
> ofonod[4083]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm1
> ofonod[4083]: plugins/udevng.c:destroy_modem() wwan1
> ofonod[4083]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm2
> ofonod[4083]: plugins/udevng.c:destroy_modem() wwan2
> ofonod[4083]: plugins/udevng.c:destroy_modem() /dev/cdc-wdm3
> ofonod[4083]: plugins/udevng.c:destroy_modem() wwan3
> ofonod[4083]: plugins/upower.c:upower_connect() upower connect
> ofonod[4083]: plugins/hfp_hf_bluez5.c:connect_handler() Registering
> External Profile handler ...
> 
>   
> Pavel
--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Dan Williams]

On Thu, 2018-03-22 at 20:28 +0100, Pavel Machek wrote:
> Hi!
> 
> > > user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost
> > > $
> > > sudo lsusb
> > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > > Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > > user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost
> > > $
> > > zcat /proc/config.gz | grep MAPPH
> > > CONFIG_PHY_MAPPHONE_MDM6600=y
> > > user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost
> > > $
> > > zcat /proc/config.gz | grep OHCI_
> > > CONFIG_USB_OHCI_LITTLE_ENDIAN=y
> > > CONFIG_USB_OHCI_HCD=y
> > > CONFIG_USB_OHCI_HCD_OMAP3=y
> > > CONFIG_USB_OHCI_HCD_PLATFORM=y
> > > user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost
> > > $
> > > 
> > > As far as I can tell,
> > > 
> > > +CONFIG_USB_WDM=y
> > > +CONFIG_USB_SERIAL=y
> > > +CONFIG_USB_SERIAL_QUALCOMM=y
> > > +CONFIG_USB_SERIAL_WWAN=y
> > > 
> > > should be enabled to enable the drivers (and I did that), but
> > > without
> > > device showing on the bus...
> > > 
> > > Any ideas?
> > 
> > Do you have the related dts patches picked from next?
> > 
> > fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port naming")
> > e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
> > 
> > But yeah all you need to do is have phy-mapphone-mdm6600 and
> > ohci-platform loaded and then ifconfig should show four wwan
> > interfaces being added.
> 
> ifconfig? I thought I should get /dev/ttyUSB0..3?

I believe they are QMI via qmi_wwan, not TTYs.

Dan

> Anyway, that does not seem to work. Something is detected now:
> 
> [   10.819549] ALSA device list:
> [   10.831787]   #0: HDMI 58006000.encoder
> [   10.841186] Waiting 10 sec before mounting root device...
> [   10.887573] usb 2-1: New USB device found, idVendor=22b8,
> idProduct=2a70
> [   10.897521] usb 2-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [   10.907684] usb 2-1: Product: Flash MZ600
> [   10.914611] usb 2-1: Manufacturer: Motorola, Incorporated
> [   20.967193] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to
> feature incompatibilities
> 
> But qcserial driver does not bind to that. If I attempt to force it:
> 
> root@devuan:/sys/bus/usb-serial/drivers/qcserial# lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 002: ID 22b8:2a70 Motorola PCS
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> root@devuan:/sys/bus/usb-serial/drivers/qcserial# echo "22b8 2a70" >
> new_id
> [ 2059.267730] usb 2-1: unknown number of interfaces: 9
> [ 2059.272949] usb 2-1: unknown number of interfaces: 9
> [ 2059.278045] usb 2-1: unknown number of interfaces: 9
> [ 2059.283233] usb 2-1: unknown number of interfaces: 9
> [ 2059.288330] usb 2-1: unknown number of interfaces: 9
> [ 2059.293457] usb 2-1: unknown number of interfaces: 9
> [ 2059.298553] usb 2-1: unknown number of interfaces: 9
> [ 2059.303680] usb 2-1: unknown number of interfaces: 9
> [ 2059.308776] usb 2-1: unknown number of interfaces: 9
> 
> I don't get anything useful. Do I need to boot android before booting
> Linux or something? How does your lsusb look like?
> 
> Thanks,
>   Pavel
--
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] option: Add support for Quectel EP06

[Dan Williams]

On Wed, 2018-01-31 at 16:32 -0600, Dan Williams wrote:
> On Thu, 2018-02-01 at 09:17 +1100, Johan Hovold wrote:
> > On Wed, Jan 31, 2018 at 09:56:01AM +0100, Kristian Evensen wrote:
> > > Hi Johan,
> > > 
> > > On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold <jo...@kernel.org>
> > > wrote:
> > > > This will probably have to do for now, but we already have
> > > > another
> > > > blacklist struct with the same content which we could rename
> > > > and
> > > > reuse.
> > > 
> > > I noticed the same, but wasn't quite sure about the policy on
> > > renaming/recycling and added a new blacklist entry. I can rename
> > > the
> > > entry and update references as part of this commit. What would be
> > > an
> > > appropriate name, something straight-forward like
> > > "net_intf4_intf5_blacklist"?
> > 
> > Yeah, the policy isn't entirely clear to me either. ;) The
> > net_blacklist
> > are used to blacklist a single network interface, but here the
> > other
> > interface was used for ADB and for the other driver it was for an
> > audio
> > interface I think.
> 
> When I added/consolidated this feature a long time back I didn't
> think
> we'd end up with as many common entries as we have.  I think it's
> fine
> to re-use use a common entry, but if you do and the common entry is
> named after a vendor/model, then make it generic.

IIRC I considered just dumping the BIT(x) into the .driver_info but
then we'd only have 16 bits for each of send_setup and reserved on 32-
bit arches and I wasn't sure that was enough.  I've seen some devices
with lots of interfaces.  But doing it this way might have been clearer
than a sidecar struct like option_blacklist_info.

Dan

> Dan
> 
> > You can just add the duplicate entry for now and if this comes up
> > again,
> > we'll figure out a new (naming) policy.
> > 
> > Thanks,
> > Johan
> > --
> > 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
--
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] option: Add support for Quectel EP06

[Dan Williams]

On Thu, 2018-02-01 at 09:17 +1100, Johan Hovold wrote:
> On Wed, Jan 31, 2018 at 09:56:01AM +0100, Kristian Evensen wrote:
> > Hi Johan,
> > 
> > On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold 
> > wrote:
> > > This will probably have to do for now, but we already have
> > > another
> > > blacklist struct with the same content which we could rename and
> > > reuse.
> > 
> > I noticed the same, but wasn't quite sure about the policy on
> > renaming/recycling and added a new blacklist entry. I can rename
> > the
> > entry and update references as part of this commit. What would be
> > an
> > appropriate name, something straight-forward like
> > "net_intf4_intf5_blacklist"?
> 
> Yeah, the policy isn't entirely clear to me either. ;) The
> net_blacklist
> are used to blacklist a single network interface, but here the other
> interface was used for ADB and for the other driver it was for an
> audio
> interface I think.

When I added/consolidated this feature a long time back I didn't think
we'd end up with as many common entries as we have.  I think it's fine
to re-use use a common entry, but if you do and the common entry is
named after a vendor/model, then make it generic.

Dan

> You can just add the duplicate entry for now and if this comes up
> again,
> we'll figure out a new (naming) policy.
> 
> Thanks,
> Johan
> --
> 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

Re: [PATCH] USB: cdc-wdm: ignore -EPIPE from GetEncapsulatedResponse

[Dan Williams]

On Fri, 2017-09-22 at 22:18 +0200, Bjørn Mork wrote:
> The driver will forward errors to userspace after turning most of
> them
> into -EIO. But all status codes are not equal. The -EPIPE (stall) in
> particular can be seen more as a result of normal USB signaling than
> an actual error. The state is automatically cleared by the USB core
> without intervention from either driver or userspace.
> 
> And most devices and firmwares will never trigger a stall as a result
> of GetEncapsulatedResponse. This is in fact a requirement for CDC WDM
> devices. Quoting from section 7.1 of the CDC WMC spec revision 1.1:
> 
>   The function shall not return STALL in response to
>   GetEncapsulatedResponse.
> 
> But this driver is also handling GetEncapsulatedResponse on behalf of
> the qmi_wwan and cdc_mbim drivers. Unfortunately the relevant specs
> are not as clear wrt stall. So some QMI and MBIM devices *will*
> occasionally stall, causing the GetEncapsulatedResponse to return an
> -EPIPE status. Translating this into -EIO for userspace has proven to
> be harmful. Treating it as an empty read is safer, making the driver
> behave as if the device was conforming to the CDC WDM spec.
> 
> There have been numerous reports of issues related to -EPIPE errors
> from some newer CDC MBIM devices in particular, like for example the
> Fibocom L831-EAU.  Testing on this device has shown that the issues
> go away if we simply ignore the -EPIPE status.  Similar handling of
> -EPIPE is already known from e.g. usb_get_string()
> 
> The -EPIPE log message is still kept to let us track devices with
> this
> unexpected behaviour, hoping that it attracts attention from firmware
> developers.
> 
> Cc: 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100938
> Reported-and-tested-by: Christian Ehrig  turn-bt.com>
> Reported-and-tested-by: Patrick Chilton 
> Reported-and-tested-by: Andreas Böhler 
> Signed-off-by: Bjørn Mork 
> ---
> The fallout of this problem has been reported by a number of people
> for a long time.  Many more than those being listed above. Apologies
> to all who didn't get the appropriate credit.  Sorry, I am lousy with
> paper work and lost track of you all.
> 
> Hoping the fix will make up for it...

FWIW, tested on the oldest MBIM devices I have (Ericsson F5321 and
Huawei EM820W for while with light traffic, browsing and git pull/push.
  Neither of these devices exhibit the original problem of course. 
Might find time to test on the newer ones this week or next, but it
seems OK.

Dan

> 
> Bjørn
> 
>  drivers/usb/class/cdc-wdm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-
> wdm.c
> index 0b845e550fbd..9f001659807a 100644
> --- a/drivers/usb/class/cdc-wdm.c
> +++ b/drivers/usb/class/cdc-wdm.c
> @@ -194,8 +194,10 @@ static void wdm_in_callback(struct urb *urb)
>   /*
>    * only set a new error if there is no previous error.
>    * Errors are only cleared during read/open
> +  * Avoid propagating -EPIPE (stall) to userspace since it is
> +  * better handled as an empty read
>    */
> - if (desc->rerr  == 0)
> + if (desc->rerr == 0 && status != -EPIPE)
>   desc->rerr = status;
>  
>   if (length + desc->length > desc->wMaxCommand) {
--
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: new usb LTE modem device

[Dan Williams]

On Wed, 2017-08-09 at 11:19 +0700, Lars Melin wrote:
> On 8/9/2017 02:33, Bjørn Mork wrote:
> > 
> > The qmi_wwan part looks fine to me. But you
> > will need to split it in two patches since the two
> > drivers are parts of different subsystems.
> > 
> > The option driver use interface blacklists
> > instead of multiple match entries. You should
> > probably follow the same style there. But this
> > is up to Johan...
> > 
> > Use the get_maintainer script to figure out
> > where the patches should be sent.
> > 
> > 
> > Bjørn
> 
> 
> Whitelisting all 6 interfaces in the option driver and
> then blacklist 4 of them (3 qmi + 1 Android debug) is
> not efficient when you so easily can selectively whitelist
> the ones (0 and 2) that the option driver should handle.
> Giuseppe is doing it the right way imho.

Yeah, in this case you're right.

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

Re: AW: new usb LTE modem device

[Dan Williams]

On Tue, 2017-08-08 at 22:22 +0200, Giuseppe Lippolis wrote:
> > The option driver use interface blacklists instead of multiple
> > match entries.
> > You should probably follow the same style there. But this is up to
> > Johan...
> 
> Can I ask what ist he difference between .sendsetup and .reserved and
> how to use the bitmask in drivers/usb/serial/option.c ?

The "blacklists" (which they really aren't anymore, just quirks) say
which USB interfaces have that specific quick.

sendsetup is to prevent the driver from sending a specific USB control
message for setting up serial parameters, which some devices ignore and
cause the driver to stall.

reserved is what you're looking for.  This one tells option not to bind
to the given USB interfaces.

So for example, ".reserved = BIT(3)" tells the option driver to ignore
USB interface 3 on that device.  ".reserved = BIT(3) | BIT(5)" tells it
to ignore both interfaces 3 and 5.

For your device, you'll want to set "reserved" in option.c to all the
interfaces that qmi_wwan is going to claim, to make sure option doesn't
claim them.  option by default is a greedy driver.

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

Re: [PATCH v2] usb: serial: Add support for Qivicon USB ZigBee dongle

[Dan Williams]

On Mon, 2017-07-03 at 10:16 +0200, Frans Klaver wrote:
> On Mon, Jul 3, 2017 at 10:13 AM, Johan Hovold 
> wrote:
> > On Fri, Jun 30, 2017 at 02:49:55PM +0200, Frans Klaver wrote:
> > > On Fri, Jun 30, 2017 at 2:44 PM, Stefan Triller  > > ller.de> wrote:
> > > > The German Telekom offers a ZigBee USB Stick under the brand
> > > > name Qivicon
> > > > for their SmartHome Home Base in its 1. Generation. The
> > > > productId is not
> > > > known by the according kernel module, this patch adds support
> > > > for it.
> > > > 
> > > > Signed-off-by: Stefan Triller 
> > > 
> > > Reviewed-by: Frans Klaver 
> > 
> > Thanks for the patch and review. I've queued this one up for -rc2.
> 
> I guess this could go into stable as well?

Random question, but what protocol does the serial interface speak?

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

Re: [PATCH v1] ACPI: Switch to use generic UUID API

[Dan Williams]

On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
<andriy.shevche...@linux.intel.com> wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki <r...@rjwysocki.net>
> Cc: Mika Westerberg <mika.westerb...@linux.intel.com>
> Cc: Borislav Petkov <b...@suse.de>
> Cc: Dan Williams <dan.j.willi...@intel.com>
> Cc: Amir Goldstein <amir7...@gmail.com>
> Cc: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Ben Skeggs <bske...@redhat.com>
> Cc: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
> Cc: Joerg Roedel <j...@8bytes.org>
> Cc: Adrian Hunter <adrian.hun...@intel.com>
> Cc: Yisen Zhuang <yisen.zhu...@huawei.com>
> Cc: Bjorn Helgaas <bhelg...@google.com>
> Cc: Zhang Rui <rui.zh...@intel.com>
> Cc: Felipe Balbi <ba...@kernel.org>
> Cc: Mathias Nyman <mathias.ny...@intel.com>
> Cc: Heikki Krogerus <heikki.kroge...@linux.intel.com>
> Cc: Liam Girdwood <lgirdw...@gmail.com>
> Cc: Mark Brown <broo...@kernel.org>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
[..]
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 0f7982a1caaf..bd3e45ede056 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -74,11 +74,11 @@ struct nfit_table_prev {
> struct list_head flushes;
>  };
>
> -static u8 nfit_uuid[NFIT_UUID_MAX][16];
> +static uuid_le nfit_uuid[NFIT_UUID_MAX];
>
> -const u8 *to_nfit_uuid(enum nfit_uuids id)
> +const uuid_le *to_nfit_uuid(enum nfit_uuids id)
>  {
> -   return nfit_uuid[id];
> +   return _uuid[id];
>  }
>  EXPORT_SYMBOL(to_nfit_uuid);
>
> @@ -207,7 +207,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, 
> struct nvdimm *nvdimm,
> u32 offset, fw_status = 0;
> acpi_handle handle;
> unsigned int func;
> -   const u8 *uuid;
> +   const uuid_le *uuid;
> int rc, i;
>
> func = cmd;
> @@ -394,7 +394,7 @@ int nfit_spa_type(struct acpi_nfit_system_address *spa)
> int i;
>
> for (i = 0; i < NFIT_UUID_MAX; i++)
> -   if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0)
> +   if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le 
> *)spa->range_guid))

What is _cmp_pp? Why not _compare?

Other than that, looks ok to me.
--
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] option: add Quectel UC15, UC20, EC21, and EC25 modems

[Dan Williams]

On Thu, 2017-03-09 at 13:14 -0500, Balazs Harmath wrote:
> So i can expect these to be added soon?

Are you able to apply and test this patch, and see if it works for your
device?  That would help.

Thanks!
Dan

> Thanks,
> Bali
> 
> 
> > On Mar 9, 2017, at 12:32 PM, Dan Williams <d...@redhat.com> wrote:
> > 
> > Add Quectel UC15, UC20, EC21, and EC25.  The EC20 is handled by
> > qcserial due to a USB VID/PID conflict with an existing Acer
> > device.
> > 
> > Signed-off-by: Dan Williams <d...@redhat.com>
> > ---
> > NOTE: The UC20, EC21, and EC25 should also get a corresponding
> > qmi_wwan
> > patch but I don't have that lying around at this time.
> > 
> > diff --git a/drivers/usb/serial/option.c
> > b/drivers/usb/serial/option.c
> > index 9894e34..d4f36df 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -233,6 +233,14 @@ static void option_instat_callback(struct urb
> > *urb);
> > #define BANDRICH_PRODUCT_1012   0x1012
> > 
> > #define QUALCOMM_VENDOR_ID  0x05C6
> > +/* These Quectel products use Qualcomm's vendor ID */
> > +#define QUECTEL_PRODUCT_UC15   0x9090
> > +#define QUECTEL_PRODUCT_UC20   0x9003
> > +
> > +#define QUECTEL_VENDOR_ID  0x2c7c
> > +/* These Quectel products use Quectel's vendor ID */
> > +#define QUECTEL_PRODUCT_EC21   0x0121
> > +#define QUECTEL_PRODUCT_EC25   0x0125
> > 
> > #define CMOTECH_VENDOR_ID   0x16d8
> > #define CMOTECH_PRODUCT_60010x6001
> > @@ -1159,7 +1167,14 @@ static const struct usb_device_id
> > option_ids[] = {
> > { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE
> > MF330 */
> > { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
> > { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
> > -   { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9003), /* Quectel UC20
> > */
> > +   /* Quectel products using Qualcomm vendor ID */
> > +   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)},
> > +   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20),
> > +     .driver_info = (kernel_ulong_t)_intf4_blacklist },
> > +   /* Quectel products using Quectel vendor ID */
> > +   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC21),
> > +     .driver_info = (kernel_ulong_t)_intf4_blacklist },
> > +   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
> >   .driver_info = (kernel_ulong_t)_intf4_blacklist },
> > { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
> > { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
> 
> 
--
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] option: add Quectel UC15, UC20, EC21, and EC25 modems

[Dan Williams]

Add Quectel UC15, UC20, EC21, and EC25.  The EC20 is handled by
qcserial due to a USB VID/PID conflict with an existing Acer
device.

Signed-off-by: Dan Williams <d...@redhat.com>
---
NOTE: The UC20, EC21, and EC25 should also get a corresponding qmi_wwan
patch but I don't have that lying around at this time.

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 9894e34..d4f36df 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -233,6 +233,14 @@ static void option_instat_callback(struct urb *urb);
 #define BANDRICH_PRODUCT_1012  0x1012
 
 #define QUALCOMM_VENDOR_ID 0x05C6
+/* These Quectel products use Qualcomm's vendor ID */
+#define QUECTEL_PRODUCT_UC15   0x9090
+#define QUECTEL_PRODUCT_UC20   0x9003
+
+#define QUECTEL_VENDOR_ID  0x2c7c
+/* These Quectel products use Quectel's vendor ID */
+#define QUECTEL_PRODUCT_EC21   0x0121
+#define QUECTEL_PRODUCT_EC25   0x0125
 
 #define CMOTECH_VENDOR_ID  0x16d8
 #define CMOTECH_PRODUCT_6001   0x6001
@@ -1159,7 +1167,14 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
-   { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9003), /* Quectel UC20 */
+   /* Quectel products using Qualcomm vendor ID */
+   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)},
+   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20),
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
+   /* Quectel products using Quectel vendor ID */
+   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC21),
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
+   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
--
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: Requeste to add Quectel EC21 in USB:serial:qcserial

[Dan Williams]

On Thu, 2017-03-09 at 10:28 +0100, Oliver Neukum wrote:
> Am Mittwoch, den 08.03.2017, 17:30 -0500 schrieb Balazs Harmath:
> > Hi guys,
> > 
> > I’w working with a Quectel EC21 modem and i ran into an issue that
> > the qcserial driver is not getting installed for it. 
> > Previously i was working with the Quectel EC20 which was working
> > properly but the cell carrier requested LTE Cat 1 modem so that’s
> > why
> > the switch to EC21.
> > 
> > Can you add the product ID for the Quectel EC21 in the qcserial.c ?
> > 
> > Thanks,
> > Bali
> > 
> > Below info for Quectel EC21
> > 
> > root@raspberrypi:~# uname -a
> > Linux raspberrypi 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017
> > armv7l GNU/Linux
> > 
> > 
> > output for dmesg:
> > 
> > [7.575835] usb 1-1.4: new high-speed USB device number 7 using
> > dwc_otg
> > [7.715808] usb 1-1.4: New USB device found, idVendor=2c7c,
> > idProduct=0121
> > [7.715819] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [7.715824] usb 1-1.4: Product: Android
> > [7.715827] usb 1-1.4: Manufacturer: Android
> > [7.728580] usbcore: registered new interface driver cdc_wdm
> > [7.735897] qmi_wwan 1-1.4:1.4: cdc-wdm0: USB WDM device
> > [7.737829] qmi_wwan 1-1.4:1.4 wwan0: register 'qmi_wwan' at
> > usb-
> > 3f98.usb-1.4, WWAN/QMI device, ce:db:66:0e:df:26
> > 
> > output for lsusb -t:
> > 
> > root@raspberrypi:~# lsusb -t
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
> > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> > |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
> > |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class,
> > Driver=smsc95xx, 480M
> > |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class,
> > Driver=ftdi_sio, 12M
> > |__ Port 3: Dev 6, If 0, Class=Mass Storage, Driver=usb-
> > storage, 480M
> > |__ Port 4: Dev 7, If 1, Class=Vendor Specific Class,
> > Driver=, 480M
> > |__ Port 4: Dev 7, If 4, Class=Vendor Specific Class,
> > Driver=qmi_wwan, 480M
> 
> qmi_wwan is binding to this interface.
> 
> > |__ Port 4: Dev 7, If 2, Class=Vendor Specific Class,
> > Driver=, 480M
> > |__ Port 4: Dev 7, If 0, Class=Vendor Specific Class,
> > Driver=, 480M
> > |__ Port 4: Dev 7, If 3, Class=Vendor Specific Class,
> > Driver=, 480M
> 
> Do you need qcserial for these interfaces?

The only reason the EC20 is part of qcserial is because Quectel didn't
bother getting their own VID/PID for it, instead using an existing
Qualcomm one (05c6:9215) that was previously used by an Acer device. 
Gobi used to be mainly for devices that kept the same Gobi-type layout
(4 interfaces) and G1K/G2K devices that needed initial firmware upload.
 That distinction has been muddled recently though so I'm not sure it
matters much where they go.

Quectel recommends option for the UC15, UC20, EC20, EC25, and EC21.  I
don't think it makes much difference, except that the UC15 is an AT-
only device and should go into 'option'.  Might as well just put them
all there and blacklist the QMI interface (#4).

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

Re: [PATCH net,stable] qmi_wwan/cdc_ether: add device ID for HP lt2523 (Novatel E371) WWAN card

[Dan Williams]

On Tue, 2017-01-24 at 10:36 +0100, Bjørn Mork wrote:
> Bjørn Mork <bj...@mork.no> writes:
> 
> > From: Dan Williams <d...@redhat.com>
> 
> Woops! I didn't intend to blame this on you Dan.  Sorry. I reused
> your
> commit message, and obviously unintentionally also the "author"
> line...
> 
> But you did create the pattern, so it was only fair to give you the
> credit :)

Hey, I'll take whatever credit I can get!

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

Re: AW: add usb option device

[Dan Williams]

On Wed, 2016-11-16 at 22:11 +0100, Giuseppe Lippolis wrote:
> > 
> > > 
> > > This will make option grab all the ports, as shown by your dmesg
> > > output.  But USB interfaces 0 and 1 are actually cdc-ether and
> > > should
> > > *not* be grabbed by option.
> 
> I also have another curiosity:
> Why the driver architecture doesn't recognize autonomously the cdc-
> ether
> Interface and only gets the serial ports?

I'm not 100% sure, but driver loading order is undependable enough (for
good reason) to be effectively random.  So you must do the right thing
in each driver for ID matching or you will sometimes get the wrong
result.  This also prevents people from being lazy :)

But also, it's not just about automatically loading.  You can
rmmod/modprobe any driver at any time (as long as it's a module and not
built-in) and if you don't do the right thing for ID matching, this
sequence ends up with the wrong driver bound:

rmmod cdc-ether
rmmod option
modprobe option
modprobe cdc-ether

Now option is bound to the ether port and cdc-ether can't bind to it.

The point is, drivers should *only* claim interfaces and devices they
actually should drive.  They should not claim interfaces they should
not or cannot drive.

Dan

> Thanks,
> Bye.
> 
> > 
> > -Ursprüngliche Nachricht-
> > Von: Oliver Neukum [mailto:oneu...@suse.com]
> > Gesendet: Mittwoch, 16. November 2016 21:57
> > An: Dan Williams <d...@redhat.com>
> > Cc: Giuseppe Lippolis <giu.lippo...@gmail.com>; linux-...@vger.kern
> > el.org
> > Betreff: Re: add usb option device
> > 
> > On Wed, 2016-11-16 at 11:49 -0600, Dan Williams wrote:
> > > 
> > > This will make option grab all the ports, as shown by your dmesg
> > > output.  But USB interfaces 0 and 1 are actually cdc-ether and
> > > should
> > > *not* be grabbed by option.
> > > 
> > > You want to limit option to grabbing bInterfaceClass=255 to make
> > > sure
> > > it only gets the serial ports.
> > 
> > Hi,
> > 
> > what happens if you actually use these ethernet interfaces while
> > somebody
> > uses the serial interfaces?
> > 
> > Regards
> > Oliver
> > 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: add usb option device

[Dan Williams]

On Thu, 2016-11-17 at 11:15 +0100, Johan Hovold wrote:
> On Wed, Nov 16, 2016 at 10:03:52PM +0100, Giuseppe Lippolis wrote:
> > 
> > Dear All,
> > thanks for the very interesting discussion.
> > 
> > > 
> > > > 
> > > > This will make option grab all the ports, as shown by your
> > > > dmesg
> > > > output.  But USB interfaces 0 and 1 are actually cdc-ether and
> > > > should
> > > > *not* be grabbed by option.
> > > > 
> > > > You want to limit option to grabbing bInterfaceClass=255 to
> > > > make sure
> > > > it only gets the serial ports.
> > > 
> > 
> > Actually the device have 2 cdc_ether interface and the others are
> > serial comm.
> > This is the bootlog of the original oem firmware:
> > 
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 1 port detected
> > usb 2-1: new high speed USB device using rt3xxx-ehci and address 2
> > usb 2-1: configuration #1 chosen from 1 choice
> > usbcore: registered new interface driver cdc_ether
> > usbcore: registered new interface driver usbserial
> > drivers/usb/serial/usb-serial.c: USB Serial support registered for
> > generic
> > usbserial_generic 2-1:1.2: generic converter detected
> > usb 2-1: generic converter now attached to ttyUSB0
> > usbserial_generic 2-1:1.3: generic converter detected
> > usb 2-1: generic converter now attached to ttyUSB1
> > usbserial_generic 2-1:1.4: generic converter detected
> > usb 2-1: generic converter now attached to ttyUSB2
> > usbserial_generic 2-1:1.5: generic converter detected
> > usb 2-1: generic converter now attached to ttyUSB3
> > usbserial_generic 2-1:1.6: generic converter detected
> > usb 2-1: generic converter now attached to ttyUSB4
> > usbcore: registered new interface driver usbserial_generic
> > drivers/usb/serial/usb-serial.c: USB Serial Driver core
> > 
> > and at the end of the modem configuration:
> > usbnet0   Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
> >   inet
> > addr:77.25.169.193  Bcast:77.25.169.195  Mask:255.255.255.252
> >   inet6 addr: fe80:::feaa:/64 Scope:Link
> >   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >   RX packets:6 errors:0 dropped:0 overruns:0 frame:0
> >   TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
> >   collisions:0 txqueuelen:1000
> >   RX bytes:272 (272.0 B)  TX bytes:600 (600.0 B)
> > 
> > Therefore I also consider convenient preserve the first two
> > interface
> > for the cdc_ether.
> > Can you please clarify me the differences between black and white
> > list
> > and how to configure it?
> 
> If possible you want to tell the option driver which interfaces to
> bind
> to (white-listing) rather than specifying which not to bind to
> (black-listing). The latter typically means probing all interfaces,
> checking the black list, and then bailing out for unsupported
> interfaces.
> 
> By matching on the interface class it is sometimes possible to rely
> solely on white-listing, for example:
> 
>   USB_DEVICE_INTERFACE_CLASS(VID, PID, 0xff)

Johan said what I was going to say, though with a bit of ambiguity on
what you should do.  I'll try to be less ambiguous: you should do what
he says.  Look at how it's done for the D-Link DWM-221 B1 or OLICARD300
and do the same thing for your device.

While you're there, use the same 0x2001 vendor ID #define for the DWM-
221 and your device.

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

Re: add usb option device

[Dan Williams]

On Wed, 2016-11-16 at 11:49 -0600, Dan Williams wrote:
> On Tue, 2016-11-15 at 20:13 +0100, Giuseppe Lippolis wrote:
> > 
> > Dear all,
> > I'm porting the Dlink DWR-512 device to LEDE (embedded linux).
> > This device embed a 3G modem connected through the usb bus .
> > The modem work properly with the option kernel module.
> > 
> > I added these line in the 
> > 
> > #define DLINK_PRODUCT_DWM_652  0x3e04
> > #define DLINK_PRODUCT_DWM_652_U5  0xce16
> > #define DLINK_PRODUCT_DWM_652_U5A   0xce1e
> > 
> > +   #define DLINK_ATL_VENDOR_ID 0x
> > 20
> > 01
> > +   #define DLINK_PRODUCT_DWM_158  0x7d04
> > 
> > #define QISDA_VENDOR_ID     0x1da5
> > #define QISDA_PRODUCT_H21_4512  0x4512
> > 
> > [...]
> > 
> > { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5) },
> > /*
> > Yes,
> > ALINK_VENDOR_ID */
> > { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5A) },
> > + { USB_DEVICE(DLINK_ATL_VENDOR_ID, DLINK_PRODUCT_DWM_158) },
> 
> This will make option grab all the ports, as shown by your dmesg
> output.  But USB interfaces 0 and 1 are actually cdc-ether and should
> *not* be grabbed by option.
> 
> You want to limit option to grabbing bInterfaceClass=255 to make sure
> it only gets the serial ports.

Also, is it really a D-Link DWM-158?  That appears to be a USB dongle-
type device, while what's in the DWR-512 is a PCI-E minicard that looks
like a ZTE MF210, from the FCC pictures.

Dan

> Dan
> 
> > 
> > { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4512) },
> > { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4523) },
> > 
> > And at the end the system work as expected:
> > 
> > [   11.659320] usbcore: registered new interface driver usbserial
> > [   11.671412] usbcore: registered new interface driver
> > usbserial_generic
> > [   11.684835] usbserial: USB Serial support registered for generic
> > [   11.739752] xt_time: kernel timezone is -
> > [   11.865508] PPP generic driver version 2.4.2
> > [   11.880069] NET: Registered protocol family 24
> > [   11.919594] usbcore: registered new interface driver option
> > [   11.931155] usbserial: USB Serial support registered for GSM
> > modem
> > (1-port)
> > [   11.945724] option 1-1:1.0: no of_node; not parsing pinctrl DT
> > [   11.946566] option 1-1:1.0: GSM modem (1-port) converter
> > detected
> > [   11.959201] option1 ttyUSB0: no of_node; not parsing pinctrl DT
> > [   11.959661] option 1-1:1.1: no of_node; not parsing pinctrl DT
> > [   11.960472] option 1-1:1.1: GSM modem (1-port) converter
> > detected
> > [   11.973103] option1 ttyUSB1: no of_node; not parsing pinctrl DT
> > [   11.973542] option 1-1:1.2: no of_node; not parsing pinctrl DT
> > [   11.974347] option 1-1:1.2: GSM modem (1-port) converter
> > detected
> > [   11.986980] option1 ttyUSB2: no of_node; not parsing pinctrl DT
> > [   11.987462] usb 1-1: GSM modem (1-port) converter now attached
> > to
> > ttyUSB2
> > [   12.001470] option 1-1:1.3: no of_node; not parsing pinctrl DT
> > [   12.002354] option 1-1:1.3: GSM modem (1-port) converter
> > detected
> > [   12.015005] option1 ttyUSB3: no of_node; not parsing pinctrl DT
> > [   12.015479] usb 1-1: GSM modem (1-port) converter now attached
> > to
> > ttyUSB3
> > [   12.029487] option 1-1:1.4: no of_node; not parsing pinctrl DT
> > [   12.030327] option 1-1:1.4: GSM modem (1-port) converter
> > detected
> > [   12.042978] option1 ttyUSB4: no of_node; not parsing pinctrl DT
> > [   12.043463] usb 1-1: GSM modem (1-port) converter now attached
> > to
> > ttyUSB4
> > [   12.057468] option 1-1:1.5: no of_node; not parsing pinctrl DT
> > [   12.058395] option 1-1:1.5: GSM modem (1-port) converter
> > detected
> > [   12.070971] option1 ttyUSB5: no of_node; not parsing pinctrl DT
> > [   12.071482] usb 1-1: GSM modem (1-port) converter now attached
> > to
> > ttyUSB5
> > [   12.085484] option 1-1:1.6: no of_node; not parsing pinctrl DT
> > 
> > 
> > Here the relevant lsusb info:
> > 
> > Bus 001 Device 002: ID 2001:7d04 D-Link Corp. 
> > Device Descriptor:
> >   bLength18
> >   bDescriptorType 1
> >   bcdUSB   2.00
> >   bDeviceClass2 Communications
> >   bDeviceSubClass 0 
> >   bDeviceProtocol 0

Re: add usb option device

[Dan Williams]

On Tue, 2016-11-15 at 20:13 +0100, Giuseppe Lippolis wrote:
> Dear all,
> I'm porting the Dlink DWR-512 device to LEDE (embedded linux).
> This device embed a 3G modem connected through the usb bus .
> The modem work properly with the option kernel module.
> 
> I added these line in the 
> 
>   #define DLINK_PRODUCT_DWM_652  0x3e04
>   #define DLINK_PRODUCT_DWM_652_U5  0xce16
>   #define DLINK_PRODUCT_DWM_652_U5A   0xce1e
> 
> + #define DLINK_ATL_VENDOR_ID 0x20
> 01
> + #define DLINK_PRODUCT_DWM_158  0x7d04
> 
>   #define QISDA_VENDOR_ID     0x1da5
>   #define QISDA_PRODUCT_H21_4512  0x4512
> 
> [...]
> 
> { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5) }, /*
> Yes,
> ALINK_VENDOR_ID */
> { USB_DEVICE(ALINK_VENDOR_ID, DLINK_PRODUCT_DWM_652_U5A) },
> + { USB_DEVICE(DLINK_ATL_VENDOR_ID, DLINK_PRODUCT_DWM_158) },

This will make option grab all the ports, as shown by your dmesg
output.  But USB interfaces 0 and 1 are actually cdc-ether and should
*not* be grabbed by option.

You want to limit option to grabbing bInterfaceClass=255 to make sure
it only gets the serial ports.

Dan

> { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4512) },
> { USB_DEVICE(QISDA_VENDOR_ID, QISDA_PRODUCT_H21_4523) },
> 
> And at the end the system work as expected:
> 
> [   11.659320] usbcore: registered new interface driver usbserial
> [   11.671412] usbcore: registered new interface driver
> usbserial_generic
> [   11.684835] usbserial: USB Serial support registered for generic
> [   11.739752] xt_time: kernel timezone is -
> [   11.865508] PPP generic driver version 2.4.2
> [   11.880069] NET: Registered protocol family 24
> [   11.919594] usbcore: registered new interface driver option
> [   11.931155] usbserial: USB Serial support registered for GSM modem
> (1-port)
> [   11.945724] option 1-1:1.0: no of_node; not parsing pinctrl DT
> [   11.946566] option 1-1:1.0: GSM modem (1-port) converter detected
> [   11.959201] option1 ttyUSB0: no of_node; not parsing pinctrl DT
> [   11.959661] option 1-1:1.1: no of_node; not parsing pinctrl DT
> [   11.960472] option 1-1:1.1: GSM modem (1-port) converter detected
> [   11.973103] option1 ttyUSB1: no of_node; not parsing pinctrl DT
> [   11.973542] option 1-1:1.2: no of_node; not parsing pinctrl DT
> [   11.974347] option 1-1:1.2: GSM modem (1-port) converter detected
> [   11.986980] option1 ttyUSB2: no of_node; not parsing pinctrl DT
> [   11.987462] usb 1-1: GSM modem (1-port) converter now attached to
> ttyUSB2
> [   12.001470] option 1-1:1.3: no of_node; not parsing pinctrl DT
> [   12.002354] option 1-1:1.3: GSM modem (1-port) converter detected
> [   12.015005] option1 ttyUSB3: no of_node; not parsing pinctrl DT
> [   12.015479] usb 1-1: GSM modem (1-port) converter now attached to
> ttyUSB3
> [   12.029487] option 1-1:1.4: no of_node; not parsing pinctrl DT
> [   12.030327] option 1-1:1.4: GSM modem (1-port) converter detected
> [   12.042978] option1 ttyUSB4: no of_node; not parsing pinctrl DT
> [   12.043463] usb 1-1: GSM modem (1-port) converter now attached to
> ttyUSB4
> [   12.057468] option 1-1:1.5: no of_node; not parsing pinctrl DT
> [   12.058395] option 1-1:1.5: GSM modem (1-port) converter detected
> [   12.070971] option1 ttyUSB5: no of_node; not parsing pinctrl DT
> [   12.071482] usb 1-1: GSM modem (1-port) converter now attached to
> ttyUSB5
> [   12.085484] option 1-1:1.6: no of_node; not parsing pinctrl DT
> 
> 
> Here the relevant lsusb info:
> 
> Bus 001 Device 002: ID 2001:7d04 D-Link Corp. 
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass2 Communications
>   bDeviceSubClass 0 
>   bDeviceProtocol 0 
>   bMaxPacketSize064
>   idVendor   0x2001 D-Link Corp.
>   idProduct  0x7d04 
>   bcdDevice3.00
>   iManufacturer  10 D-Link,Inc  
>   iProduct   11 D-Link DWM-158
>   iSerial 0 
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength  229
> bNumInterfaces  7
> bConfigurationValue 1
> iConfiguration  0 
> bmAttributes 0xa0
>   (Bus Powered)
>   Remote Wakeup
> MaxPower  500mA
> Interface Association:
>   bLength 8
>   bDescriptorType11
>   bFirstInterface 0
>   bInterfaceCount 2
>   bFunctionClass  2 Communications
>   bFunctionSubClass   6 Ethernet Networking
>   bFunctionProtocol   0 
>   iFunction   2 COM(comm_if)
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   

Re: [patch] USB: serial: option: add WeTelecom WM-D200

[Dan Williams]

On Mon, 2016-08-22 at 20:07 +0300, Aleksandr Makarov wrote:
> 22.08.2016 18:03, Dan Williams пишет:
> > 
> > On Sat, 2016-08-20 at 14:50 +0300, Aleksandr Makarov wrote:
> > > 
> > > USB: serial: option: add WeTelecom WM-D200
> > > 
> > > Add support for WeTelecom WM-D200.
> > > 
> > > T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
> > > D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> > > P:  Vendor=22de ProdID=6801 Rev=00.00
> > > S:  Manufacturer=WeTelecom Incorporated
> > > S:  Product=WeTelecom Mobile Products
> > > C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
> > > I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff
> > > Driver=(none)
> > > I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff
> > > Driver=(none)
> > > I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff
> > > Driver=(none)
> > > I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
> > > Driver=usb-
> > > storage
> > While you're at it, why not add PID 0x6802 and 0x6803?  These are
> > also
> > listed here:
> > 
> > http://www.mts.ua/upload/files/we/te/wetelecom_windows_drivers.zip
> > 
> > with the same USB layout as the WM-D200.
> > 
> > Dan
> > 
> Does it mean that if 0x6803 (WeTelecom WM-D300) has the same
> USB layout, it does not need testing?

Yes, since the Windows drivers use the exact same layout for all three
devices, we should do the same for Linux.

> If it does not, why don't I copy the whole usb_modeswitch data
> into the option driver?

What specifically would you copy over?  All I see there are two data
files, one for 6801 and one for 6803, but they don't have any
interesting data in them...

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

Re: [patch] USB: serial: option: add WeTelecom WM-D200

[Dan Williams]

On Sat, 2016-08-20 at 14:50 +0300, Aleksandr Makarov wrote:
> USB: serial: option: add WeTelecom WM-D200
> 
> Add support for WeTelecom WM-D200.
> 
> T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
> D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=22de ProdID=6801 Rev=00.00
> S:  Manufacturer=WeTelecom Incorporated
> S:  Product=WeTelecom Mobile Products
> C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
> I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-
> storage

While you're at it, why not add PID 0x6802 and 0x6803?  These are also
listed here:

http://www.mts.ua/upload/files/we/te/wetelecom_windows_drivers.zip

with the same USB layout as the WM-D200.

Dan

> Signed-off-by: Aleksandr Makarov 
> ---
> --- a/linux/drivers/usb/serial/option.c   2016-08-20
> 14:44:19.668791103 +0300
> +++ b/linux/drivers/usb/serial/option.c   2016-08-20
> 14:43:24.376790761 +0300
> @@ -525,6 +525,10 @@ static void option_instat_callback(struc
>  #define VIATELECOM_VENDOR_ID 0x15eb
>  #define VIATELECOM_PRODUCT_CDS7  0x0001
>  
> +/* WeTelecom products */
> +#define WETELECOM_VENDOR_ID  0x22de
> +#define WETELECOM_PRODUCT_WMD200 0x6801
> +
>  struct option_blacklist_info {
>   /* bitmask of interface numbers blacklisted for send_setup
> */
>   const unsigned long sendsetup;
> @@ -1991,6 +1995,7 @@ static const struct usb_device_id option
>   { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff)
> },/* OLICARD300 - MT6225 */
>   { USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
>   { USB_DEVICE(VIATELECOM_VENDOR_ID, VIATELECOM_PRODUCT_CDS7)
> },
> + { USB_DEVICE_AND_INTERFACE_INFO(WETELECOM_VENDOR_ID,
> WETELECOM_PRODUCT_WMD200, 0xff, 0xff, 0xff) },
>   { } /* Terminating entry */
>  };
>  MODULE_DEVICE_TABLE(usb, option_ids);
> 
> 20.08.2016 13:29, Aleksandr Makarov пишет:
> > 
> > From: Aleksandr Makarov 
> > 
> > USB: serial: option: add WeTelecom WM-D200
> > 
> > Add support for WeTelecom WM-D200.
> > 
> > T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
> > D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> > P:  Vendor=22de ProdID=6801 Rev=00.00
> > S:  Manufacturer=WeTelecom Incorporated
> > S:  Product=WeTelecom Mobile Products
> > C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
> > I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff
> > Driver=(none)
> > I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff
> > Driver=(none)
> > I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff
> > Driver=(none)
> > I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-
> > storage
> > 
> > Signed-off-by: Aleksandr Makarov 
> > ---
> > --- drivers/usb/serial/option.c.orig2016-08-19
> > 15:15:17.173146316 +0300
> > +++ drivers/usb/serial/option.c 2016-08-19
> > 15:16:04.241147738 +0300
> > @@ -519,6 +519,10 @@ static void option_instat_callback(struc
> >  #define VIATELECOM_VENDOR_ID   0x15eb
> >  #define VIATELECOM_PRODUCT_CDS70x0001
> >  
> > +/* WeTelecom products */
> > +#define WETELECOM_VENDOR_ID0x22de
> > +#define WETELECOM_PRODUCT_WMD200   0x6801
> > +
> >  struct option_blacklist_info {
> >     /* bitmask of interface numbers blacklisted for send_setup
> > */
> >     const unsigned long sendsetup;
> > @@ -1969,6 +1973,7 @@ static const struct usb_device_id option
> >     { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff)
> > },/* OLICARD300 - MT6225 */
> >     { USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
> >     { USB_DEVICE(VIATELECOM_VENDOR_ID,
> > VIATELECOM_PRODUCT_CDS7) },
> > +   { USB_DEVICE_AND_INTERFACE_INFO(WETELECOM_VENDOR_ID,
> > WETELECOM_PRODUCT_WMD200, 0xff, 0xff, 0xff) },
> >     { } /* Terminating entry */
> >  };
> >  MODULE_DEVICE_TABLE(usb, option_ids);
> > 
> > 20.08.2016 13:05, Greg KH пишет:
> > > 
> > > On Sat, Aug 20, 2016 at 11:19:37AM +0300, Aleksandr Makarov
> > > wrote:
> > > > 
> > > > From: Aleksandr Makarov 
> > > > 
> > > > USB: serial: option: add WeTelecom WM-D200
> > > > 
> > > > Add support for WeTelecom WM-D200.
> > > > 
> > > > T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh=
> > > > 0
> > > > D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> > > > P:  Vendor=22de ProdID=6801 Rev=00.00
> > > > S:  Manufacturer=WeTelecom Incorporated
> > > > S:  Product=WeTelecom Mobile Products
> > > > C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
> > > > I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff
> > > > Driver=(none)
> 

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

[Dan Williams]

On Thu, 2016-02-25 at 18:15 +0100, Bjørn Mork wrote:
> Dan Williams <d...@redhat.com> writes:
> > On Mon, 2016-02-22 at 18:03 +0700, Lars Melin wrote:
> > > On 2016-02-21 10:09, Daniel Johnson wrote:
> > > > On Fri, Feb 19, 2016 at 12:27 AM, Bjørn Mork <bj...@mork.no>
> > > > wrote:
> > > > > 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 found the FCC ID for the device.
> > > > QISME206V-561
> > > > 
> > > > Searching for this at the FCC website revealed internal photos.
> > > > Looks
> > > > like it's Intel based. The significant non intel parts seem to
> > > > be
> > > > DRAM, and a radio amplifier.
> > > > https://www.fcc.gov/general/fcc-id-search-page
> > > > --
> > > > 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.h
> > > > tml
> > > > 
> > > 
> > > The serial interfaces should be handled by the option serial
> > > driver 
> > > which btw already has support for it.
> > > 
> > > qcserial will fight with option for ownership of the interfaces
> > > so
> > > the 
> > > currently defined DEVICE_HWI(0x03f0, 0x581d) should be taken out
> > > of
> > > qcserial. Bjorn?
> > 
> > If it's an Intel device, which it certainly looks like from the FCC
> > photos, then it should not be in qcserial at all.  The Windows
> > driver
> > config and the usb-devices dumps indicate that instead of the
> > normal
> > Intel cdc-acm/mbim configuration that this device uses a Huawei-
> > specific layout like their Qualcomm-based devices.  So this device
> > should probably go into 'option' for Cfg#1 (Jungo) and Cfg#2
> > (cdc_ether) and it'll certainly need locking on specific
> > Class/SubClass/Protocol to ensure that option only claims the
> > serial
> > interfaces and not the ethernet/ncm ones.
> 
> Agreed.  The DEVICE_HWI stuff in qcserial got a bit messy.  There are
> either too many or too few high speed serial drivers based on
> usb_wwan
> :)
> 
> But I guess the rule should be:  Does it speak QCDM on any of the
> serial
> ports, then it goes in qcserial.  Anything else goes in option.  Does
> that match the original qcserial intention?

No.  There are plenty of things that speak QCDM that are driven by
'option' or 'qcaux'.  The original intention of qcserial was to
facilitate the firmware download with gobi_loader that is more or less
obsolete these days, since the Gobi devices usually carry their own
firmware onboard.  But G1K, G2K, and G3K devices still require the
loader.

If devices don't need the loader, or their firmware can be upgraded
through that special QMI mode then great, they don't need qcserial.  Or
if we figure out how to support whatever special magic snowflake-ness
qcserial does in option, great.

> Regarding the entries in option: It is unfortunate that HP (and other
> laptop vendors) insist on using their own vendor IDs for vendor
> specifc
> OEM products like these mdoem. The Huawei vendor matching in option
> works very well, but when the modules are programmed with a HP ID,
> then
> we are back to adding entries per device ID.  Which is a game we
> cannot
> win wrt rarely seen laptop accessories.  How many Linux users will
> care
> about the average HP LTE modem?  My bet is less than one.
> 
> What do you think are the chances that HP will be stupid enough to
> ever
> create a USB device with a ff/05/xx interface which is *not* a Huawei
> modem?  How about just duplicating every Huawei ff/05/xx entry in
> option
> with the HP vendor ID?  Seems less error prone than the alternatives
> to
> me.

That makes me both concerned (because I think the chance of this is
non-zero) and sad (for the same reason).  For now I think we should
just add the few specific class/subclass/protocol lines for this modem
for the specific HP USB IDs.  I'm not sure there's any way around this.

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

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

[Dan Williams]

On Sun, 2016-02-21 at 12:44 +0700, Lars Melin wrote:
> On 2016-02-20 03:34, Dan Williams wrote:
> > On Fri, 2016-02-19 at 18:21 +0100, Bjørn Mork wrote:
> > > Dan Williams <d...@redhat.com> 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
> > 
> 
> usb_modeswitch does already handle one module under Huawei's own id
> so 
> it should also be able to switch the HP branded ones.
> There are more HP branded modules which we may see in the future and 
> I'll make sure that they will be added to usb_modeswitch as soon as I
> know their interface layout.
> HP's own drivers tells what kind of interfaces are available but not
> in 
> which config they are present or in which order within a config.
> There is at least some useful info in them about baseline drivers:
> 
>  Remark="HP"/>
>  Remark="HP"/>
>  Remark="HP"/>
>  Remark="HP"/>
>  Remark="HP"/>
>  Remark="HP"/>
>  Remark="HP"/>
>  Remark="HP"/>
>  Remark="HP"/>
>  Remark="HP"/>
> 
> which makes me think that lt4114 should not be in qcserial but in
> option 
> instead.

Yes, since it's an Intel XMM 7160 device, it should not be in qcserial.

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

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

[Dan Williams]

On Mon, 2016-02-22 at 18:03 +0700, Lars Melin wrote:
> On 2016-02-21 10:09, Daniel Johnson wrote:
> > On Fri, Feb 19, 2016 at 12:27 AM, Bjørn Mork  wrote:
> > > 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 found the FCC ID for the device.
> > QISME206V-561
> > 
> > Searching for this at the FCC website revealed internal photos.
> > Looks
> > like it's Intel based. The significant non intel parts seem to be
> > DRAM, and a radio amplifier.
> > https://www.fcc.gov/general/fcc-id-search-page
> > --
> > 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
> > 
> 
> The serial interfaces should be handled by the option serial driver 
> which btw already has support for it.
> 
> qcserial will fight with option for ownership of the interfaces so
> the 
> currently defined DEVICE_HWI(0x03f0, 0x581d) should be taken out of
> qcserial. Bjorn?

If it's an Intel device, which it certainly looks like from the FCC
photos, then it should not be in qcserial at all.  The Windows driver
config and the usb-devices dumps indicate that instead of the normal
Intel cdc-acm/mbim configuration that this device uses a Huawei-
specific layout like their Qualcomm-based devices.  So this device
should probably go into 'option' for Cfg#1 (Jungo) and Cfg#2
(cdc_ether) and it'll certainly need locking on specific
Class/SubClass/Protocol to ensure that option only claims the serial
interfaces and not the ethernet/ncm ones.

Dan

> /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
--
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 <d...@redhat.com> 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

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

Re: [PATCH] cdc_acm: blacklist Samsung Phones in firmware update mode

[Dan Williams]

On Mon, 2016-01-04 at 12:32 +0700, Lars Melin wrote:
> On 2016-01-04 05:00, Jose Alonso wrote:
> > 
> > The program Heimdall (http://glassechidna.com.au/heimdall) is used
> > to flash a new firmware in Samsung Mobile Phones. It uses only the
> > library libusb to access the device.
> > 
> > The module "cdc_acm" recognizes it as CDC ACM device, creates a
> > device /dev/ttyACM* and send a USB_CDC_REQ_SET_LINE_CODING. Then,
> > for some phones when Heimdall call libusb_set_interface_alt_setting
> > or libusb_get_string_descriptor_ascii the device locks.
> > Also, the ModemManager initialization locks the device.
> > 
> > There are 3 devices used by Samsung in firmware update mode:
> > idVendor=0x04e8  idProduct=0x6601 idProduct=0x685d IdProduct=0x68c3
> > source:
> > (https://github.com/Benjamin-Dobell/Heimdall/blob/master/heimdall/
> >   source/BridgeManager.h)
> > 
> > Signed-off-by: Jose Alonso 
> > ---
> >   drivers/usb/class/cdc-acm.c | 11 +++
> >   1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc
> > -acm.c
> > index 26ca4f9..8728afc 100644
> > --- a/drivers/usb/class/cdc-acm.c
> > +++ b/drivers/usb/class/cdc-acm.c
> > @@ -1843,6 +1843,17 @@ static const struct usb_device_id acm_ids[]
> > = {
> > .driver_info = IGNORE_DEVICE,
> > },
> > 
> > +   /* Exclude Samsung Mobile Phones in firmware update mode
> > */
> > +   { USB_DEVICE(0x04e8, 0x6601),
> > +   .driver_info = IGNORE_DEVICE,
> > +   },
> > +   { USB_DEVICE(0x04e8, 0x685d),
> > +   .driver_info = IGNORE_DEVICE,
> > +   },
> > +   { USB_DEVICE(0x04e8, 0x68c3),
> > +   .driver_info = IGNORE_DEVICE,
> > +   },
> > +
> > /* control interfaces without any protocol set */
> > { USB_INTERFACE_INFO(USB_CLASS_COMM,
> > USB_CDC_SUBCLASS_ACM,
> > USB_CDC_PROTO_NONE) },
> > --
> 
> NAK
> 
> 04e8:6601 is also used for Samsung SCH-U209 CDMA modem so can not be 
> ignored.

Probably used by a bunch of Samsung WWAN modems.  I have a SGH-Z810
(UMTS) that also uses this ID in regular modem mode.

Dan

> 04e8:685d is an update mode id so it can be ignored by cdc-acm.
> 04e8:68c3 does not look like update mode, it has cdc-acm modem and 
> cdc-acm device management interfaces.
> 
> 
> wbr
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] net: usb: cdc_ncm: Adding support for two new Dell devices

[Dan Williams]

On Wed, 2015-12-16 at 10:39 +0100, Daniele Palmas wrote:
> This patch series add support in the cdc_ncm driver for two devices
> based on the same platform, that are different only for carrier
> customization.
> 
> The devices do not have ARP capabilities.
> 
> Daniele Palmas (2):
>   net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband
> Card
>   net: usb: cdc_ncm: Adding Dell DW5813 LTE AT Mobile Broadband
> Card

Quite interesting; Google knows nothing about these devices that I can
find.  What platform are these based on?

But in any case, since these blocks are almost identical to the DW5550
block, maybe update the comments to indicate that they need NOARP
unlike the MBM platform that the 5550 is based on?

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

Re: [PATCH 0/6] net: qmi_wwan: MDM9x30 support

[Dan Williams]

On Thu, 2015-12-03 at 19:24 +0100, Bjørn Mork wrote:
> We add new device IDs all the time, often without any testing on
> actual hardware. This is usually OK as long as the device is similar
> to already supported devices, using the same chipset and firmware
> basis.  But the Sierra Wireless MC7455 is an example of a new chipset
> generation. Adding it based on assumed similarity with its ancestors
> proved too optimistic.
> 
> This series adds the missing bits and pieces necessary to support LTE
> Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks
> to
> Sierra Wireless for providing MC7455 samples for testing
> 
> The most important change is the "raw-ip" support. The series also
> adds a necessary control request, removes an unsupported device ID,
> and adds a driver specific entry in MAINTAINERS.
> 
> A few random notes about "raw-ip":
> 
> "I rather have these all running in raw IP mode. The 802.3 framing is
> utterly stupid." - Marcel Holtmann in Jan 2012 [1]
> 
> Marcel was right.  I should have listened to him. What more can I
> say?

The decision was less clear-cut at the time, since all the devices did
support 802.3 framing and DHCP.  And people wanted easy-1-2-3 DHCP and
bridging capability too.  We still get a lot of people asking about
issues with DHCP and even bridging.  802.3 makes it *look* simple but
of course we know it's not that simple...

> The 802.3 framing has provided a steady supply of firmware bugs for
> many years. We've added driver workarounds for many of these, but
> there are still known bugs where the workaround is so yucky that we
> have refused to apply it. But all that is over now.  The latest
> generation Qualcomm chips no longer supports 802.3 framing at all.
> 
> I had two open questions regarding the "raw-ip" userspace API:
> 
> 1) Should we continue faking an ethernet device, even if we don't use
>the L2 headers on the USB link anymore?
> 
>There was a vote in favour of the "headerless" device. This is the
>honest representation of the hardware/firmware interface.

I like the approach of the current patchset where it's more like a tun
device.  Simple.

> 2) What input should the driver base its framing on?
> 
>Snooping or directly manipulating QMI is considered out of the
>question. We delegated all QMI handling to userspace from the
>beginning.
> 
>We have so far required userspace to configure the firmware for
>"802.3" framing, or fail if that proved impossible.  This
>requirement is now changed.  Userspace must now inform the driver
>if it negotiates "raw-ip" framing.  Two alternative interfaces
> were
>proposed:
> - ethtool private driver flag, or
> - sysfs file
> 
>The NetworkManager/ModemManager developers were in favour of the
>sysfs alternative.

Sysfs is the easiest for most things to touch; ethtool requires being
able to do ioctls and bit operations or shell out to ethtool.  Just
stating the reasons for my above vote.

Dan

> These questions (or any other you migh have :) are of course still
> open.  This patch set presents the solutions I currently prefer,
> considering the above.
> 
> All comments are appreciated, even simple '+1' ones.
> 
> 
> Bjørn
> 
> [1] http://www.spinics.net/lists/linux-usb/msg57056.html
> 
> 
> Bjørn Mork (6):
>   net: qmi_wwan: MDM9x30 specific power management
>   net: qmi_wwan: remove 1199:9070 device id
>   usbnet: allow mini-drivers to consume L2 headers
>   net: qmi_wwan: support "raw IP" mode
>   net: qmi_wwan: document the qmi/raw_ip sysfs file
>   MAINTAINERS: add qmi_wwan driver entry
> 
>  Documentation/ABI/testing/sysfs-class-net-qmi |  23 +
>  MAINTAINERS   |   7 ++
>  drivers/net/usb/qmi_wwan.c| 138
> +-
>  drivers/net/usb/usbnet.c  |   5 +-
>  4 files changed, 169 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-net-qmi
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: Quiet down false peer failure messages

[Dan Williams]

On Thu, Dec 3, 2015 at 2:26 PM, Don Zickus <dzic...@redhat.com> wrote:
> My recent Intel box is spewing these messages:
>
> xhci_hcd :00:14.0: xHCI Host Controller
> xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
> usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb2: Product: xHCI Host Controller
> usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
> usb usb2: SerialNumber: :00:14.0
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 6 ports detected
> usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port2: failed to peer to usb1-port1 (-16)
> usb: port power management may be unreliable
> usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port3: failed to peer to usb1-port1 (-16)
> usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port5: failed to peer to usb1-port1 (-16)
> usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port6: failed to peer to usb1-port1 (-16)
>
> Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the 
> XHCI
> hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
> (including port 1 of the EHCI hub).
>
> Further the unused ports have location data initialized to 0x8000.
>
> Now each unused port on the xhci hub walks the port list and finds a matching
> peer with port1 of the EHCI hub because the zero'd out group id bits falsely 
> match.
> After port1 of the XHCI hub, each following matching peer will generate the
> above warning.
>
> These warnings seem to be harmless for this scenario as I don't think it
> matters that unused ports could not create a peer link.
>
> The attached patch utilizes that assumption and just turns the pr_warn into
> pr_debug to quiet things down.
>
> Tested on my Intel box.
>
> Signed-off-by: Don Zickus <dzic...@redhat.com>

Acked-by: Dan Williams <dan.j.willi...@intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: Quiet down false peer failure messages

[Dan Williams]

On Tue, Nov 17, 2015 at 1:00 PM, Don Zickus  wrote:
> My recent Intel box is spewing these messages:
>
> xhci_hcd :00:14.0: xHCI Host Controller
> xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
> usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb2: Product: xHCI Host Controller
> usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
> usb usb2: SerialNumber: :00:14.0
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 6 ports detected
> usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port2: failed to peer to usb1-port1 (-16)
> usb: port power management may be unreliable
> usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port3: failed to peer to usb1-port1 (-16)
> usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port5: failed to peer to usb1-port1 (-16)
> usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) 
> (usb1-port1:usb2-port1)
> usb usb2-port6: failed to peer to usb1-port1 (-16)
>
> Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the 
> XHCI
> hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
> (including port 1 of the EHCI hub).
>
> Further the unused ports have location data initialized to 0x8000.
>
> Now each unused port on the xhci hub walks the port list and finds a matching
> peer with port1 of the EHCI hub because the zero'd out group id bits falsely 
> match.
> After port1 of the XHCI hub, each following matching peer will generate the
> above warning.
>
> These warnings seem to be harmless for this scenario as I don't think it
> matters that unused ports could not create a peer link.
>
> The attached patch utilizes that assumption and just skips the
> find_and_link_peer setup if a port is determined to be unused.  This further
> assumes that port's status will never change.
>
> Tested on my Intel box.
>
> Signed-off-by: Don Zickus 
> ---
>  drivers/usb/core/port.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> index 2106183..3a8f84a 100644
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -353,6 +353,13 @@ static void find_and_link_peer(struct usb_hub *hub, int 
> port1)
> struct usb_hub *peer_hub;
>
> /*
> +* Un-used ports have zero'd out data that can create a false
> +* peer in-use failure.
> +*/
> +   if (port_dev->connect_type == USB_PORT_NOT_USED)
> +   return;
> +
> +   /*
>  * If location data is available then we can only peer this port
>  * by a location match, not the default peer (lest we create a
>  * situation where we need to go back and undo a default peering

Looks reasonable, but it may hide real errors in the ACPI tables.

How about just changing the dev_warn() in link_peers_report() to
dev_dbg?  We'll still get the pr_warn_once() to get the notification
that something went wrong, but won't continue to spam the logs if the
user does not care about peer port power management.
--
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: Celot modem driver

[Dan Williams]

On Wed, 2015-11-25 at 13:13 +0100, M. Hrdlička wrote:
> Hello,
> log script told me, that I may to tell you about add this device to
> propper linux driver.
> 
> Device is combo USB modem Celot CTD-200, manufacturing date in
> September 2010, it´s combinated GSM (GPRS/UMTS/HSPA) and CDMA modem.
> I run this device with usbserial driver, adding this line in
> /etc/udev/rules.d/90-celot-combo.rules:
> ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="211f",
> ATTR{idProduct}=="6805", RUN+="/sbin/modprobe usbserial vendor=0x211f
> product=0x6805"
> ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="211f",
> ATTR{idProduct}=="6809", RUN+="/sbin/modprobe usbserial vendor=0x211f
> product=0x6809"
> 
> In windows driver and connect program, there is choice to switch
> between GSM and CDMA network mode. In my linux instalation only one
> mode working - preferred is GSM mode. When I commented GSM line in
> /etc/udev/rules.d (id 6809), then CDMA works and ModemManager make
> ttyUSB ports.
> 
> I have OpenSuse 13.1 with standard kernel 3.11.10-29
> 
> Attached extract of /var/log/messages and lsusb command.
> 

The modem appears to have two Qualcomm chips in it, one for CDMA and
the other for GSM/WCDMA, but this is not a Gobi-type modem.  The
connection manager appears to use QCDM to talk to the modem on Windows,
but normal AT commands on Mac OS X.  The Windows CM has some mechanism
for switching between the two modes and will even tell you if it can
find a faster HSPA link while you're on CDMA.

In any case, I think the 'option' driver is most appropriate for this
device's two USB IDs.  Communication traces of the Windows CM switching
between this device's modes would be necessary to figure out switching
between CDMA and GSM/WCDMA on Linux.

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

Re: Obtaining USB vendor/product ID in C language given a modem file path

[Dan Williams]

On Wed, 2015-11-18 at 18:56 -0800, ToddA wrote:
> Hi,
> 
> If this isn't the correct mailing list for this question, do let me
> know 
> if there's a better one where I could ask.
> 
> I have a C language program that talks to modems and these days it is
> almost always a USB modem. For diagnostic purposes, I would like to
> be 
> able to pass the modem's file path and get back the vendor and
> product 
> ID info (at least), and if I could also get the vendor name, that
> would 
> be great. Portable code would be the best so I can compile it on
> Ubuntu, 
> Fedora, Raspbian, etc.
> 
> For example, given the modem is at /dev/ttyACM0 and lsusb gives:
> 
>   Bus 001 Device 004: ID 0572:1329 Conexant Systems (Rockwell),
> Inc.

cat /sys/class/tty/ttyACM0/device/../idVendor
cat /sys/class/tty/ttyACM0/device/../idProduct

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

Re: [PATCH] USB: qcserial: Add support for Quectel EC20 Mini PCIe module

[Dan Williams]

On Wed, 2015-11-04 at 16:57 +0100, Bjørn Mork wrote:
> Petr Štetiar  writes:
> 
> > Bjørn Mork  [2015-11-04 13:15:10]:
> >
> >> Based on that, I wonder if it wouldn't be more appropriate to simply do
> >> this as a device specific quirk in the qmi_wwan probe?
> >
> > So rather something like this?
> >
> > diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> > index 2a7c1be..2dafc69 100644
> > --- a/drivers/net/usb/qmi_wwan.c
> > +++ b/drivers/net/usb/qmi_wwan.c
> > @@ -822,6 +822,7 @@ static const struct usb_device_id products[] = {
> > {QMI_GOBI_DEVICE(0x05c6, 0x9245)},  /* Samsung Gobi 2000 
> > Modem device (VL176) */
> > {QMI_GOBI_DEVICE(0x03f0, 0x251d)},  /* HP Gobi 2000 Modem 
> > device (VP412) */
> > {QMI_GOBI_DEVICE(0x05c6, 0x9215)},  /* Acer Gobi 2000 Modem 
> > device (VP413) */
> > +   {QMI_FIXED_INTF(0x05c6, 0x9215, 4)},/* Quectel EC20 Mini 
> > PCIe Module */
> > {QMI_GOBI_DEVICE(0x05c6, 0x9265)},  /* Asus Gobi 2000 Modem 
> > device (VR305) */
> > {QMI_GOBI_DEVICE(0x05c6, 0x9235)},  /* Top Global Gobi 2000 
> > Modem device (VR306) */
> > {QMI_GOBI_DEVICE(0x05c6, 0x9275)},  /* iRex Technologies 
> > Gobi 2000 Modem device (VR307) */
> > @@ -853,6 +854,23 @@ static const struct usb_device_id products[] = {
> >  };
> >  MODULE_DEVICE_TABLE(usb, products);
> >
> > or rather something like this?
> >  
> > +#define QUECTEL_EC20_VENDORID 0x05c6
> > +#define QUECTEL_EC20_PRODUCTID 0x9215
> > +#define QUECTEL_EC20_NINTERFACES 5
> > +#define QUECTEL_EC20_QMI_IFACE_FIX 4
> 
> Not directly related to the issue at hand, but I sort of hate macros
> like that.  They provide little or no value, and make it much more
> difficult to see what is going on.  In particular, if you went this
> route then you would probably want to define
> 
>   #define ACER_GOBI2K_VENDORID 0x05c6
>   #define ACER_GOBI2K_PRODUCTID 0x9215
>   #define ACER_GOBI2K_NINTERFACES 4
>   #define ACER_GOBI2K_QMI_IFACE_FIX 0
> 
> to make this complete.  And noone would notice that
> ACER_GOBI2K_PRODUCTID  and QUECTEL_EC20_PRODUCTID are the same value.
> 
> In fact, the QUECTEL_EC20_VENDORID is really a Qualcomm device ID.
> That's confusing already.  Please use literals instead.

Yeah, please just use "QUALCOMM" here, since that's the vendor assigned
to that ID, not QUECTEL.  They just stupidly forgot to change that value
in the firmware source they got from Qualcomm, apparently.

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

Re: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Dan Williams]

On Thu, 2015-10-22 at 10:39 +0200, Erwin Van de Velde wrote:
> Hi all,
> 
> Thank you for your helpful answers! I have investigated it further,
> stopping potential culprits in userspace and I have found the issue:
> it is modemmanager that seems to keep the devices open somewhere and
> thus causes the ttyUSB numbers to go up. So now I will redirect the
> issue to their developers :-)

There was a bug between ModemManager 1.2 and 1.4.2 that could have
triggered this, which was fixed in commit
009af02f6d06d5020e397455354b9ccc56557b02.  So make sure you have 1.4.2
(released on 13-Jan-2015) or later.

Dan

> I do not care about the device node name per se, I use symlinks anyway
> to have consistent naming, but since there is a limit of max. 512
> ttyUSB devices and each modem consists of 3 of those, the system hits
> the limit rather quickly.
> 
> Thanks a lot!
> Erwin
> 
> 
> On Wed, Oct 21, 2015 at 4:37 PM, Greg K-H  wrote:
> > On Wed, Oct 21, 2015 at 11:39:04AM +0200, Erwin Van de Velde wrote:
> >> Hi all,
> >>
> >> As advised, I retried with a more recent kernel (4.2.0), but I get a
> >> similar result:
> >>
> >> I tested via 'echo 1 > /sys/bus/pci/ehci-pci/\:00\:1a.0/remove'
> >> and 'echo 1 > /sys/bus/pci/rescan'.
> >
> > Why did you remove the PCI device?  Do you have a PCI hotplug system
> > that recan will work for?
> >
> > You are removing the whole USB host controller here, not just the USB
> > device itself, it's a "fake" hotplug, which is odd, and your PCI device
> > might not work correctly when you add it back...
> >
> >> There are two possible results: no
> >> errors when removing the device and then the devices are reinserted
> >> with the same ttyUSB number or, with an error:
> >> 'usb_wwan_indat_callback: resubmit read urb failed. (-19)' (as shown
> >> in the dmesg copied below) and then the numbers increase, even though
> >> the ttyUSB devices with the previously used numbers have been removed
> >> from /dev. On following attempts the numbers only remain the same or
> >> increase, never reusing the freed ttyUSB numbers. Can someone please
> >> tell me how I can prevent the error or circumvent the issue otherwise?
> >> Sometimes the devices get stuck and resetting them via removal seems
> >> to be the only option.
> >>
> >> Thanks in advance!
> >> Erwin
> >>
> >> [  623.366025] ehci-pci :00:1a.0: remove, state 1
> >> [  623.366042] usb usb1: USB disconnect, device number 1
> >> [  623.366047] usb 1-1: USB disconnect, device number 2
> >> [  623.366051] usb 1-1.1: USB disconnect, device number 4
> >> [  623.366270] option1 ttyUSB6: GSM modem (1-port) converter now
> >> disconnected from ttyUSB6
> >> [  623.366294] option 1-1.1:1.0: device disconnected
> >> [  623.368715] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
> >> urb failed. (-19)
> >> [  623.369327] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
> >> urb failed. (-19)
> >> [  623.369863] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
> >> urb failed. (-19)
> >> [  623.370398] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
> >> urb failed. (-19)
> >
> > Those are normal, the device is being removed.
> >
> >> [  623.371083] option1 ttyUSB9: GSM modem (1-port) converter now
> >> disconnected from ttyUSB9
> >> [  623.371097] option 1-1.1:1.2: device disconnected
> >> [  623.371315] option1 ttyUSB14: GSM modem (1-port) converter now
> >> disconnected from ttyUSB14
> >
> >
> > Have you also shut down the userspace program that had these device
> > nodes open?  That's the issue here, what program has the device nodes
> > open, if they don't close them, no matter what you do, the device nodes
> > will not be recycled within the kernel.  This isn't a kernel issue, it's
> > a userspace issue to properly shut them down in order for the numbers to
> > be reused.
> >
> > But even if they aren't reused, it's not a big deal, userspace should
> > not care about the device node names at all, this isn't a problem, they
> > will be recycled once userspace closes the device node, eventually.
> >
> > So focus on your userspace programs if you are really worried about the
> > device numbers here.
> >
> > hope this helps,
> >
> > 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


--
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: Huawei E3131

[Dan Williams]

On Wed, 2015-08-12 at 23:17 +0200, Martin Mokrejs wrote:
 Hi Bjorn,
 my have a new USB 3G modem sold in Czech Republic by T-Mobile. So far it 
 works for me only using the option driver and pppd. The 'qmi-network 
 /dev/cdc-wdm0' does not work for me. Maybe it has no QMI interface ('modprobe 
 qmi_wwan' does not log any new device found through dmesg but maybe that is 
 because it is already claimed by cdc_ncm driver)? I haven't seen the virtual 
 CD-ROM associated media errors with my old Huawei E372. I believe I can 
 ignore them but is that because of the modem firmware being ... suboptimal? 
 BTW, usb_modeswitch used to log that it flipped a device. Isn't this needed 
 anymore?

I doubt this one will work with QMI for a couple reasons; first that the
3xxx series are HiLink and usually don't use Qualcomm chipsets.  But
second, I think all Huawei modems that expose an NCM interface are
HiLink too.  So basically, you've got a HiLink and it's only usable with
AT commands for control, over which you send some Huawei-proprietary AT
commands like NDISDUP and then you can use another command to get the IP
address details you can apply to the NCM interface.  Sometimes DHCP on
the NCM interface can also works after setting up the packet data
connection via the AT interface.

So in summary, if this is indeed a HiLink device you should have one or
more AT serial ports driven by option, and one cdc-ncm ethernet
interface.

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

Re: [PATCH] usb-storage: ignore ZTE MF 823 in mode 0x1225

[Dan Williams]

On Thu, 2015-07-02 at 15:43 +0200, Oliver Neukum wrote:
 On Thu, 2015-07-02 at 20:33 +0700, Lars Melin wrote:
  On 2015-07-02 20:01, Oliver Neukum wrote:
   On Thu, 2015-07-02 at 14:43 +0200, Oliver Neukum wrote:
   On Wed, 2015-07-01 at 22:50 +0700, Lars Melin wrote:
  
   Then I would like to see an lsusb listing for 19d2:1225 with an SD-card
   interface, I have only seen 19d2:1225 with a single storage interface
   which is for the windows install cd-rom.
   There are almost no 3G dongles having the SD-card interface active in
   default (non-switched) mode.
  
   Though I see your point. Is the switching desirable at all for this
   device or do I need to block the device on the SCSI level?
  
Regards
Oliver
  
   However, when I reinstall usb_modeswitch I see that the storage
   functionality is unnecessary to switch this device.
  
   Jul 02 14:56:10 linux-dtbq.site kernel: usb 3-10: new high-speed USB 
   device number 8 using xhci_hcd
   Jul 02 14:56:10 linux-dtbq.site kernel: usb 3-10: New USB device found, 
   idVendor=19d2, idProduct=1225
   Jul 02 14:56:10 linux-dtbq.site kernel: usb 3-10: New USB device strings: 
   Mfr=1, Product=2, SerialNumber=3
   Jul 02 14:56:10 linux-dtbq.site kernel: usb 3-10: Product: ZTE WCDMA 
   Technologies MSM
   Jul 02 14:56:10 linux-dtbq.site kernel: usb 3-10: Manufacturer: 
   ZTE,Incorporated
   Jul 02 14:56:10 linux-dtbq.site kernel: usb 3-10: SerialNumber: 
   MF8230ZTED01CP261718U46EM0SHF3BW707_8C650
   Jul 02 14:56:10 linux-dtbq.site kernel: usb-storage 3-10:1.0: USB Mass 
   Storage device detected
   Jul 02 14:56:10 linux-dtbq.site kernel: Vendor: 0x19d2, Product: 0x1225, 
   Revision: 0xf0f1
   Jul 02 14:56:10 linux-dtbq.site kernel: Interface Subclass: 0x06, 
   Protocol: 0x50
   Jul 02 14:56:10 linux-dtbq.site kernel: usb-storage 3-10:1.0: device 
   ignored
   Jul 02 14:56:10 linux-dtbq.site kernel: storage_probe() failed
   Jul 02 14:56:10 linux-dtbq.site kernel: -- sending exit command to thread
   Jul 02 14:56:10 linux-dtbq.site mtp-probe[2730]: checking bus 3, device 
   8: /sys/devices/pci:00/:00:14.0/usb3/3-10
   Jul 02 14:56:10 linux-dtbq.site mtp-probe[2730]: bus: 3, device: 8 was 
   not an MTP device
   Jul 02 14:56:10 linux-dtbq.site usb_modeswitch[2740]: switch device 
   19d2:1225 on 003/008
   Jul 02 14:56:15 linux-dtbq.site kernel: usb 3-10: USB disconnect, device 
   number 8
   Jul 02 14:56:16 linux-dtbq.site kernel: usb 3-10: new high-speed USB 
   device number 9 using xhci_hcd
  
 Regards
 Oliver
  
  
  Yes but there are other 19d2:1225 devices which don't have dual-mode
 
 So they reused the ID. Oh just great.

Welcome to the world of USB WWAN dongles.  This happens *all* the
time...  The worst offenders I know of are Huawei and ZTE, probably
because they make so many.  For example 12d1:1001 is used by like 50
devices before modeswitch (I jest, but not by much).

Dan

  (19d2:1403 RNDIS or 19d2:1405 ECM) they do only have one of the modes 
  and they don't auto-flip so they need usb_modeswitch.
 
 Understood. And I just found out that the auto flip is unreliable
 without storage. But do they need storage interfaces to switch
 to the other modes? As the virtual CD does not go away I don't
 really see much value in retaining the original (storage only) mode,
 as all it offers is an opportunity to lose data.
 
  This is the first 3G dongle I have seen with multiple LUN on the same 
  USB interface, there has always been one interface for each storage 
  function in the past. So yes I jumped to conclusion..
  
  Anyway, it would be good if you could block the MMC interface on LUN 
  level while still having the virtual cd-rom working.
 
 This device is total crap. Do you know about alternative commands
 that allow selecting the mode the device switches to?
 
   Regards
   Oliver 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
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: cdc_acm / cdc_wdm issue. Connection to device lost (Sony Ericsson w660)

[Dan Williams]

On Fri, 2015-06-19 at 19:43 +0200, Fab Stz wrote:
 Oh ! I just realized my mistake. Actually it is not the kernel that is faulty 
 but my configuration (since I migrated from debian wheezy to jessie).
 
 I had connection/disconnection issues because of conflicts between gammu and 
 ModemManager.
 
 It is also ModemManager which took the control of my phone and switched to 3G 
 network.

Yes, unless disabled or told to ignore your device, ModemManager will
probe many serial devices with some AT commands which might conflict
with other tools like gammu that want to do the same thing.

But MM (at least 0.7 or later) shouldn't be changing any settings on
your device unless it has been told to enable it by some other tool.
NetworkManager will ask MM to enable the modem if NM's WWAN switch
hasn't been turned off (nmcli radio wwan [on|off]).  So that's probably
what was happening.

dan

--
To unsubscribe from this list: send the line unsubscribe linux-usb in

Re: usbserial option driver newid

[Dan Williams]

On Wed, 2015-03-04 at 22:00 -0500, Rick Farina wrote:
 On 03/04/15 13:01, Greg KH wrote:
  And again, a kernel patch is the real way to fix it for everyone.
 
 
 Okay, got a lot of things figured out and have everything working now.
 Glad I spent the extra time because I found some neat things on the device.
 
 I've made the following changes:
 diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
 index f0c0c53..9d11676 100644
 --- a/drivers/usb/serial/option.c
 +++ b/drivers/usb/serial/option.c
 @@ -80,11 +80,13 @@ static void option_instat_callback(struct urb *urb);
  #define OPTION_PRODUCT_GTM380_MODEM0x7201
 
  #define HUAWEI_VENDOR_ID   0x12D1
 +#define HUAWEI_PRODUCT_E3276_HILINK0X1001

Actually, I don't think the 0x1001 ID should be in 'option' at all.  I
believe that's actually the mass-storage ID of some Huawei devices
*before* they get switched to modem mode.  That ID is already listed in
storage/unusual_devs.h *and* handled by usb_modeswitch, so it doesn't
really have a place in the option driver, which only deals with TTYs.

I think you just need 0x1566.

Dan

  #define HUAWEI_PRODUCT_E1730x140C
  #define HUAWEI_PRODUCT_E1750   0x1406
  #define HUAWEI_PRODUCT_K4505   0x1464
  #define HUAWEI_PRODUCT_K3765   0x1465
  #define HUAWEI_PRODUCT_K4605   0x14C6
 +#define HUAWEI_PRODUCT_E3276_HILINK_DEBUG  0x1566
  #define HUAWEI_PRODUCT_E173S6  0x1C07
 
  #define QUANTA_VENDOR_ID   0x0408
 
 However, there is a bunch of code that looks like this below the code
 block I added to:
 { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
 HUAWEI_PRODUCT_K3765, 0xff, 0xff, 0xff),
 .driver_info = (kernel_ulong_t) huawei_cdc12_blacklist },
 { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x14ac, 0xff,
 0xff, 0xff),/* Huawei E1820 */
 .driver_info = (kernel_ulong_t) net_intf1_blacklist },
 
 I assume that I don't need to add anything like this since just echoing
 the usbid into new_id seems to work fine?  I've tested using it as a
 serial interface to send direct AT commands to the modem as well as
 actually dialing up with the modem and establishing connections.
 Everything seems to be working so it is safe to assume that the only
 change I need to make is the one I made in the diff above?
 
 I am a little confused in that my older e3276 (before the switch to
 hilink) seems to be supported by the option driver, however, it's
 usbid is not seen anywhere in the serial folder:
 
 Bus 002 Device 010: ID 12d1:1506 Huawei Technologies Co., Ltd.
 Modem/Networkcard
 
 
 [374876.873580] usb 2-6: new high-speed USB device number 10 using xhci_hcd
 [374877.043245] option 2-6:1.0: GSM modem (1-port) converter detected
 [374877.043338] usb 2-6: GSM modem (1-port) converter now attached to
 ttyUSB0
 [374877.043432] option 2-6:1.1: GSM modem (1-port) converter detected
 [374877.043507] usb 2-6: GSM modem (1-port) converter now attached to
 ttyUSB1
 
 The closest I can find in the code is this line, but it doesn't make
 sense because if this line does match 0x1506 then one of the lines above
 it should have matched 0x1001 and it clearly doesn't.
 
 { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06,
 0x15) },
 
 Looking at commit ee6f827d I am adding it wrong, but I don't understand
 how to add the new product ids correctly.  Any pointers?
 
 Thanks,
 Zero
 --
 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

Re: difference in option.ko and sierra.ko Linux drivers

[Dan Williams]

On Thu, 2015-02-05 at 07:33 -0800, Greg KH wrote:
 On Thu, Feb 05, 2015 at 07:36:40PM +0530, temp sha wrote:
  You mean to say only Sierra has its own proprietary commands and no one 
  else ?
  What is so special about Sierra that requires a dedicated driver in
  Linux while rest of
  all vendors share the same option driver ? Does Sierra do something unique 
  and
  different from rest of all vendors?
 
 Sierra does unique things for their chips, the driver source itself
 should explain this.

Yes, it has some specific commands for power control and a few other
functions.  While it is not extremely different than option, the Sierra
driver is currently meant to drive Sierra devices.

temp sha, what is the problem with using the Huawei device with the
option driver?  Is there a bug that prevents the device from working
there?  Every other non-Gobi/non-MBIM Huawei device is currently driven
by 'option' and I think yours should also be the same.

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

Re: [PATCH v2 11/11] hso: fix rfkill name conflicts

[Dan Williams]

On Fri, 2015-01-30 at 13:22 +0100, Olivier Sobrie wrote:
 By using only the usb interface number for the rfkill name, we might
 have a name conflicts in case two similar hso devices are connected.
 
 In this patch, the name of the hso rfkill interface embed the value
 of a counter that is incremented each time a new rfkill interface is
 added.
 
 Suggested-by: Dan Williams d...@redhat.com
 Signed-off-by: Olivier Sobrie oliv...@sobrie.be
 ---
  drivers/net/usb/hso.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
 index c14fc80..d31a165 100644
 --- a/drivers/net/usb/hso.c
 +++ b/drivers/net/usb/hso.c
 @@ -153,7 +153,7 @@ struct hso_net {
   struct hso_device *parent;
   struct net_device *net;
   struct rfkill *rfkill;
 - char name[8];
 + char name[24];
  
   struct usb_endpoint_descriptor *in_endp;
   struct usb_endpoint_descriptor *out_endp;
 @@ -2469,9 +2469,10 @@ static void hso_create_rfkill(struct hso_device 
 *hso_dev,
  {
   struct hso_net *hso_net = dev2net(hso_dev);
   struct device *dev = hso_net-net-dev;
 + static u32 rfkill_counter;

It'll probably be initialized to 0, but still, it would feel safer with
an explicit rfkill_counter = 0...

Dan
 
   snprintf(hso_net-name, sizeof(hso_net-name), hso-%d,
 -  interface-altsetting-desc.bInterfaceNumber);
 +  rfkill_counter++);
  
   hso_net-rfkill = rfkill_alloc(hso_net-name,
  interface_to_usbdev(interface)-dev,


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

Re: [PATCH v2 11/11] hso: fix rfkill name conflicts

[Dan Williams]

On Fri, 2015-01-30 at 17:15 +0100, Olivier Sobrie wrote:
 Hello Dan,
 
 On Fri, Jan 30, 2015 at 09:47:59AM -0600, Dan Williams wrote:
  On Fri, 2015-01-30 at 13:22 +0100, Olivier Sobrie wrote:
   By using only the usb interface number for the rfkill name, we might
   have a name conflicts in case two similar hso devices are connected.
   
   In this patch, the name of the hso rfkill interface embed the value
   of a counter that is incremented each time a new rfkill interface is
   added.
   
   Suggested-by: Dan Williams d...@redhat.com
   Signed-off-by: Olivier Sobrie oliv...@sobrie.be
   ---
drivers/net/usb/hso.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
   
   diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
   index c14fc80..d31a165 100644
   --- a/drivers/net/usb/hso.c
   +++ b/drivers/net/usb/hso.c
   @@ -153,7 +153,7 @@ struct hso_net {
 struct hso_device *parent;
 struct net_device *net;
 struct rfkill *rfkill;
   - char name[8];
   + char name[24];

 struct usb_endpoint_descriptor *in_endp;
 struct usb_endpoint_descriptor *out_endp;
   @@ -2469,9 +2469,10 @@ static void hso_create_rfkill(struct hso_device 
   *hso_dev,
{
 struct hso_net *hso_net = dev2net(hso_dev);
 struct device *dev = hso_net-net-dev;
   + static u32 rfkill_counter;
  
  It'll probably be initialized to 0, but still, it would feel safer with
  an explicit rfkill_counter = 0...
  
 
 If I set explicitly rfkill_counter = 0, checkpatch triggers an error:
 
   ERROR: do not initialise statics to 0 or NULL
   #36: FILE: drivers/net/usb/hso.c:2472:
   +   static u32 rfkill_counter = 0;

Well OK then, life has changed since I last submitted a patch with a
static variable :)  If checkpatch complains, then it is almost always
correct, and you can ignore me.

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

Re: difference in option.ko and sierra.ko Linux drivers

[Dan Williams]

On Thu, 2015-01-29 at 06:23 -0800, Greg KH wrote:
 On Thu, Jan 29, 2015 at 02:50:13PM +0530, temp sha wrote:
  Can any one let me know the difference in option and sierra kernel
  modules ? looks like both drivers support GSM modem. And from the
  source code perspective both look similar. I am able to load sierra
  module for my Huawei USB dongle E156 and able to connect to internet
  using pppd. Is it OK to use sierra driver for Huawei in case there is
  no technical issue? If yes why there are two different modules?
 
 They support two different chipsets and control them differently.  If
 the sierra module works for your hardware, great!  Please send us a
 patch that adds the device id to the driver and we will be glad to merge
 it into the kernel tree.

I'd really, really rather not have non-Sierra devices controlled by
'sierra'.  There are some Sierra-specific things the driver does, like
interface enumeration, enabling/disabling power state and NMEA ports
using Sierra-proprietary commands, and a few other things.

Since PPP-using Huawei devices are usually done by 'option', I'd prefer
to have them added there, and if there is some issue, then I'd prefer to
have that issue fixed in option.

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

Re: Fatal Exception on device when Hotsyncing Palm in linux

[Dan Williams]

On Mon, 2015-01-26 at 19:17 +0100, Johan Hovold wrote:
 On Mon, Jan 26, 2015 at 04:00:26PM +0100, Henri Manson wrote:
  Hello,
  
  I performed the test using VirtualBox and live cd iso images, so
  mixing different version of kernel and user-space programs does not
  happen.
 
 You'd probably need to compile your own kernel (e.g. test an old kernel
 on your recent userspace) if you really want to rule out that this is
 kernel related (which it doesn't seem to be).
 
  In 9.04 there is no usb communication until pilot-xfer is
  started (a user-space program), in 10.04 usb communication happens
  directly after hotsyncing. Does anyone know which, if at all,
  user-space program is auto-started in 10.04 after a Palm is detected?
  Do I need to check udev rules?
 
 No idea, sorry. Perhaps you should file a bug report with your distro.

It might be ModemManager; try moving /usr/sbin/ModemManager out of the
way.  If so, we'll update the USB device blacklist for various Palm
devices upstream, so that it ignores them.

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

Re: Fatal Exception on device when Hotsyncing Palm in linux

[Dan Williams]

On Mon, 2015-01-26 at 22:49 +0100, Henri Manson wrote:
 Indeed /usr/sbin/ModemManager (Ubuntu 14.04) or
 /usr/sbin/modem-manager (Ubuntu 10.04) is the program that is started
 when a Palm is connected and is causing the 'Fatal Exception' on the
 Palm m505. Moving it out of the way is the solution. How can I update
 the blacklist myself?

It's based on udev rules, so look
at /usr/lib/udev/rules.d/77-mm-usb-device-blacklist.rules.  You can copy
the file to /etc/udev/rules.d, remove the existing devices, and add your
device there by USB VID and PID.  When you plug it in again,
ModemManager will then ignore it.

What is the VID/PID again so that we can add it to the upstream
blacklist?

Dan

 On Mon, Jan 26, 2015 at 10:20 PM, Dan Williams d...@redhat.com wrote:
  On Mon, 2015-01-26 at 19:17 +0100, Johan Hovold wrote:
  On Mon, Jan 26, 2015 at 04:00:26PM +0100, Henri Manson wrote:
   Hello,
  
   I performed the test using VirtualBox and live cd iso images, so
   mixing different version of kernel and user-space programs does not
   happen.
 
  You'd probably need to compile your own kernel (e.g. test an old kernel
  on your recent userspace) if you really want to rule out that this is
  kernel related (which it doesn't seem to be).
 
   In 9.04 there is no usb communication until pilot-xfer is
   started (a user-space program), in 10.04 usb communication happens
   directly after hotsyncing. Does anyone know which, if at all,
   user-space program is auto-started in 10.04 after a Palm is detected?
   Do I need to check udev rules?
 
  No idea, sorry. Perhaps you should file a bug report with your distro.
 
  It might be ModemManager; try moving /usr/sbin/ModemManager out of the
  way.  If so, we'll update the USB device blacklist for various Palm
  devices upstream, so that it ignores them.
 
  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


--
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: Fatal Exception on device when Hotsyncing Palm in linux

[Dan Williams]

On Mon, 2015-01-26 at 23:33 +0100, Henri Manson wrote:
 From lsusb:
 
 Bus 008 Device 013: ID 0830:0002 Palm, Inc. m505

I've blacklisted anything driven by 'visor' upstream in ModemManager,
since most of those appear to be non-phone devices.  Yes, 3 are phones
(Samsung and Acer) but they are so old (2002 - 2005) that I hope nobody
is using them anymore for dialup WWAN access...

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

Re: [PATCH 04/11] hso: fix memory leak in hso_create_rfkill()

[Dan Williams]

On Tue, 2015-01-20 at 14:13 +0100, Oliver Neukum wrote:
 On Tue, 2015-01-20 at 13:29 +0100, Olivier Sobrie wrote:
  When the rfkill interface was created, a buffer containing the name
  of the rfkill node was allocated. This buffer was never freed when the
  device disappears.
  
  To fix the problem, we put the name given to rfkill_alloc() in
  the hso_net structure.
  
  Signed-off-by: Olivier Sobrie oliv...@sobrie.be
  ---
   drivers/net/usb/hso.c | 12 +++-
   1 file changed, 3 insertions(+), 9 deletions(-)
  
  diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
  index 470ef9e..a49ac2e 100644
  --- a/drivers/net/usb/hso.c
  +++ b/drivers/net/usb/hso.c
  @@ -153,6 +153,7 @@ struct hso_net {
  struct hso_device *parent;
  struct net_device *net;
  struct rfkill *rfkill;
  +   char name[8];
   
  struct usb_endpoint_descriptor *in_endp;
  struct usb_endpoint_descriptor *out_endp;
  @@ -2467,27 +2468,20 @@ static void hso_create_rfkill(struct hso_device 
  *hso_dev,
   {
  struct hso_net *hso_net = dev2net(hso_dev);
  struct device *dev = hso_net-net-dev;
  -   char *rfkn;
   
  -   rfkn = kzalloc(20, GFP_KERNEL);
  -   if (!rfkn)
  -   dev_err(dev, %s - Out of memory\n, __func__);
  -
  -   snprintf(rfkn, 20, hso-%d,
  +   snprintf(hso_net-name, sizeof(hso_net-name), hso-%d,
   interface-altsetting-desc.bInterfaceNumber);
 
 That number is not unique. Indeed it will be identical for all devices.

I would say just do static u32 rfkill_counter = 0 and 

+   snprintf(hso_net-name, sizeof(hso_net-name), hso-%d,
+rfkill_counter++);

We can't just use the netdev's name because that may have conflicts.
eg, the netdev will get hso0 when plugged in (and thus rfkill would get
hso-0) but then udev will rename that to something like wwp0s26f7u2i8.
Then the second HSO you plug in will get the name 'hso0', and so the
second rfkill would get 'hso-0', but that's already taken by the first
rfkill...  Which is why I just suggest a counter.

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

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Dan Williams]

On Fri, 2014-11-14 at 11:56 +0100, Sedat Dilek wrote:
 On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek sedat.di...@gmail.com wrote:
  On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams d...@redhat.com wrote:
  On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
  Hi,
 
  I wanted to understand what is going on the kernel-side when
  connecting to the Internet via a Huawei E173 USB web-stick (3rd
  Generation: UMTS / HSPA).
 
  Especially the correlation between the diverse USB/NET kernel-drivers
  and how the networking is setup.
 
 
  [ Sitting in front of a foreign Windows machine ]
 
  [ CC Aleksander ]
 
  Hi Dan,
 
  sorry for the late (and short) response.
 
  AFAICS you have given a skeleton for a usb-wwan-networking
  documentation :-).
 
  Personally, I would like to take into account some kernel-config
  options and some more things.
 
 
 I started with documenting...
 
 I have still some difficulties in understanding USB WWAN Networking.
 So, this is what I revealed...
 
 # USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK
 
 ### USB-NETWORKING AND WWAN SETUP
 CONFIG_USB_USBNET=m--- usb networking
 CONFIG_USB_NET_CDCETHER=m  --- usb-wwan (net) configuration
 CONFIG_USB_SERIAL_WWAN=m   --- usb-wwan (serial) configuration
 CONFIG_USB_SERIAL_OPTION=m --- usb-serial driver called option

Most WWAN devices actually require option, because most WWAN devices
have serial ports (even if they aren't used for PPP), and 'option' is
the driver that handles this.  The 'option' name is historic, but the
driver should really be called something like 'wwan-serial-generic' or
something like that.

You're missing a few other net type drivers:

CONFIG_USB_NET_QMI_WWAN = Qualcomm QMI capable devices (net)
CONFIG_USB_HSO = Option High-Speed (net) devices
CONFIG_USB_NET_KALMIA = Samsung LTE dongle (net)
CONFIG_USB_SIERRA_NET = Sierra devices (net)
CONFIG_USB_NET_CDC_NCM = Ericsson F5321 (?) and some others (net)
CONFIG_USB_NET_HUAWEI_CDC_NCM = Huawei NCM variant (net)
CONFIG_USB_VL600 = LG VL600 / AD600 LTE device (net)
CONFIG_USB_NET_CDC_MBIM = MBIM (net) devices (popular currently)

and maybe even:

CONFIG_USB_CDC_PHONET = Nokia phones and USB sticks, not net but
proprietary protocol that handles both data/control channels

For the serial side:

CONFIG_USB_ACM = generic serial devices, many are *not* WWAN but many
WWAN devices use this class/driver
CONFIG_USB_SERIAL_QCAUX = Various Qualcomm-based devices' auxiliary
ports (DIAG, GPS, etc)
CONFIG_USB_SERIAL_QUALCOMM = Firmware loading and auxiliary ports on
various Qualcomm Gobi devices
CONFIG_USB_SERIAL_SIERRAWIRELESS = Older Sierra device serial ports for
PPP/control and auxiliary functions

WWAN devices basically mix  match these drivers depending on what
interfaces the firmware exposes.

For example, some Sierra devices may require both
CONFIG_USB_SERIAL_SIERRAWIRELESS and CONFIG_USB_SIERRA_NET.

Older Sierra devices may use only CONFIG_USB_SERIAL_SIERRAWIRELESS and
do not provide a 'net' port at all, but use only PPP.

Sierra devices based on Icera chips may use CONFIG_USB_ACM and either
CONFIG_USB_SIERRA_NET or CONFIG_USB_NET_CDCETHER.

Some Huawei devices may use CONFIG_USB_NET_CDCETHER and either
CONFIG_USB_SERIAL_OPTION or CONFIG_USB_ACM.

Other Huawei devices may use CONFIG_USB_NET_QMI_WWAN and
CONFIG_USB_SERIAL_OPTION.

Even other Huawei devices may be Qualcomm Gobi type and use
CONFIG_USB_NET_QMI_WWAN and CONFIG_USB_SERIAL_QUALCOMM.

So you see it really depends on exactly how the firmware is implemented.
But in general, devices still fall into the categories I originally
listed, and the drivers fall into specific categories too (net,
serial, proprietary), and devices mix  match drivers to achieve the
end result.

Dan

 ### PPP OPTIONS
 CONFIG_PPP=y
 CONFIG_PPP_BSDCOMP=m
 CONFIG_PPP_DEFLATE=m
 CONFIG_PPP_FILTER=y
 CONFIG_PPP_MULTILINK=y
 CONFIG_PPP_ASYNC=m
 
 Beyond the PPP options, I wanted to understand what
 CONFIG_USB_NET_CDCETHER does and why I need it.
 Can someone help?




 Thanks.
 
 - Sedat -
 
 [1] 
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/Kconfig#n189
 
 P.S.: cdc_ether Kconfig option and checking my logs
 
 From [1]...
 ...
 config USB_NET_CDCETHER
 tristate CDC Ethernet support (smart devices such as cable modems)
 depends on USB_USBNET
 default y
 help
  This option supports devices conforming to the Communication Device
  Class (CDC) Ethernet Control Model, a specification that's easy to
  implement in device firmware.  The CDC specifications are available
  from http://www.usb.org/.
 
  CDC Ethernet is an implementation option for DOCSIS cable modems
  that support USB connectivity, used for non-Microsoft USB hosts.
  The Linux-USB CDC Ethernet Gadget driver is an open implementation.
This driver should work with at least the following devices:
 
* Dell Wireless 5530 HSPA
  * Ericsson PipeRider (all variants)
* Ericsson Mobile Broadband Module (all variants)
  * Motorola

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Dan Williams]

On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
 Hi,
 
 I wanted to understand what is going on the kernel-side when
 connecting to the Internet via a Huawei E173 USB web-stick (3rd
 Generation: UMTS / HSPA).
 
 Especially the correlation between the diverse USB/NET kernel-drivers
 and how the networking is setup.

General overview:  there are many different types of WWAN devices and
they fall into a couple groups:

1) PPP-only via serial ports; IP packets are transmitted via a PPP
interface (eg, ppp0) created after sending some AT commands to the modem
over that serial port.  IP addressing happens via PPP's IPCP/IPV6CP
protocols.

2) Net interface with AT commands over serial ports: the modem provides
a 'net' interface that is activated with proprietary AT commands over a
serial port. IP addressing happens via either DHCP on that net interface
after the AT setup, or the IP/DNS details are queried via proprietary AT
commands.

3) Net interface with proprietary protocols: the modem provides a 'net'
interface that is activated via proprietary protocols (QMI, MBIM, CnS,
etc).  IP addressing happens either via DHCP on the net interface after
proprietary protocol setup, or the IP/DNS details are queried via
proprietary protocol commands.

It's often possible to know what category a device fits into, but even
devices from the same manufacturer with *the same model number* can fall
into different categories, because the firmware is different, or because
the firmware can switch between these categories using special commands.

 I have tested a Ubuntu trusty kernel on my Ubuntu/precise system and
 compared the configs to get the stuff run on 3.18-rc2+.
 Beyond the option driver, I required usb_serial / usb_wwan to be
 activated and some more (cde-ether or sth. sound similiar...).
 ( Currently, I am not sitting (it's a Windows machine) in front of my
 machine, so I cannot send you my latest kernel-config. )
 
 As usually I looked into Documentation directory.
 So, my 1st question where do I get some informations in general on
 this topic - usb [1] or net subdirectory (seen from kernel-side)?
 I found a usb-serial kernel-doc [1].
 ( I have no Linux Git source so I cannot grep for patterns. )

None of those really have any information about WWAN specific setup, and
I fear that if documentation was added, it would be quickly out-of-date
because device manufacturers change things so frequently.

 The next mystery is what is network-manager doing in the background?
 I have seen that modem-manager is invoked, but as said I would like to
 understand the internas (means check the logs, turn on some
 debugging kernel-space/user-space, etc.).

NetworkManager uses ModemManager for all WWAN control, NM only handles
the configuration storage and IP addressing parts of the setup.
ModemManager handles modem hardware detection, capability detection,
WWAN registration and setup, signal strength reporting, network
connection initiation, and bearer IP addressing method determination.

If you want more information from ModemManager, you can run mmcli
--help or mmcli --set-logging=debug.

 I am not sure but syncing with 3G network seems to take a while since
 I really can connect to the Internet.

What do you mean by syncing?

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

Re: [PATCH] USB: cdc-acm: add device id for GW Instek AFG-2225

[Dan Williams]

On Mon, 2014-10-27 at 20:40 +0100, Oliver Neukum wrote:
 On Mon, 2014-10-27 at 19:07 +0100, Johan Hovold wrote:
 
  I guess we could use that quirk, but I'm actually leaning towards just
  removing that quirk and reducing the log level of the message to info.
  
  Oliver, what do you say?
 
 Now that I think about this, I'd say that we should actually
 export the flag via sysfs and ask the ModemManager people
 to honour it.

And we'd be happy to do that in ModemManager.  However:

[24919.251413] usb 2-6: New USB device found, idVendor=0421,
idProduct=03d2
[24919.251425] usb 2-6: New USB device strings: Mfr=2, Product=3,
SerialNumber=4
[24919.251431] usb 2-6: Product: Nokia N950
[24919.251437] usb 2-6: Manufacturer: Nokia
[24919.251442] usb 2-6: SerialNumber: x
[24919.255343] cdc_acm 2-6:1.7: This device cannot do calls on its own.
It is not a modem.
[24919.255434] cdc_acm 2-6:1.7: ttyACM0: USB ACM device

lt-ModemManager[13913]: debug [1414441686.310970]
[mm-port-serial-at.c:440] debug_log(): (ttyACM0): -- 'ATD*99***2#CR'
lt-ModemManager[13913]: debug [1414441686.357306]
[mm-port-serial-at.c:440] debug_log(): (ttyACM0): --
'CRLFCONNECTCRLF'

nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 8 /
phase 'network'
local  IP address 33.197.88.195
remote IP address 10.6.6.6
primary   DNS address 10.177.0.34

so whenever that flag gets exported, we also need to make sure that
things that the kernel says *aren't* modems, actually aren't modems.
Which we apparently get wrong right now for various Nokia devices.  I
don't really trust the manufacturers to set the right descriptor bits
for their devices, even Nokia.

Dan

Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber7
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands (v.25ter)
  iInterface 11 CDC Abstract Control Model (ACM)
  CDC Header:
bcdCDC   1.10
  CDC Call Management:
bmCapabilities   0x00
bDataInterface  8
  CDC ACM:
bmCapabilities   0x02
  line coding and serial state
  CDC Union:
bMasterInterface7
bSlaveInterface 8 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87  EP 7 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   9
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber8
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface 12 CDC ACM Data
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86  EP 6 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05  EP 5 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   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

Re: [PATCH] option: add Haier CE81B CDMA modem

[Dan Williams]

On Wed, 2014-10-22 at 10:18 +0200, Johan Hovold wrote:
 On Tue, Oct 14, 2014 at 11:10:41AM -0500, Dan Williams wrote:
  Port layout:
  
  0: QCDM/DIAG
  1: NMEA
  2: AT
  3: AT/PPP
  
  Signed-off-by: Dan Williams d...@redhat.com
  ---
   drivers/usb/serial/option.c | 2 ++
   1 file changed, 2 insertions(+)
  
  diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
  index d1a3f60..8d8764d 100644
  --- a/drivers/usb/serial/option.c
  +++ b/drivers/usb/serial/option.c
  @@ -358,14 +358,15 @@ static void option_instat_callback(struct urb *urb);
   #define ZOOM_PRODUCT_4597  0x9607
   
   /* SpeedUp SU9800 usb 3g modem */
   #define SPEEDUP_PRODUCT_SU9800 0x9800
   
   /* Haier products */
   #define HAIER_VENDOR_ID0x201e
  +#define HAIER_PRODUCT_CE81B0x10f8
   #define HAIER_PRODUCT_CE1000x2009
   
   /* Cinterion (formerly Siemens) products */
   #define SIEMENS_VENDOR_ID  0x0681
   #define CINTERION_VENDOR_ID0x1e2d
   #define CINTERION_PRODUCT_HC25_MDM 0x0047
   #define CINTERION_PRODUCT_HC25_MDMNET  0x0040
  @@ -1616,14 +1617,15 @@ static const struct usb_device_id option_ids[] = {
  { USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) },
  { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
.driver_info = (kernel_ulong_t)four_g_w14_blacklist
  },
  { USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
  SPEEDUP_PRODUCT_SU9800, 0xff) },
  { USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
  { USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
  +   { USB_DEVICE_AND_INTERFACE_INFO(HAIER_VENDOR_ID, HAIER_PRODUCT_CE81B, 
  0xff, 0xff, 0xff) },
  { USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
 
 Please, try to keep the id-table entries sorted alphabetically by the
 define names (if possible). Fixed it up here and applied.

Do you mean CE81B after CE100?

Dan

 Thanks,
 Johan
 
  /* Pirelli  */
  { USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_1, 
  0xff) },
  { USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_2, 
  0xff) },
  { USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1004, 
  0xff) },
  { USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1005, 
  0xff) },
  { USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1006, 
  0xff) },
 --
 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] option: add Haier CE81B CDMA modem

[Dan Williams]

Port layout:

0: QCDM/DIAG
1: NMEA
2: AT
3: AT/PPP

Signed-off-by: Dan Williams d...@redhat.com
---
 drivers/usb/serial/option.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index d1a3f60..8d8764d 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -358,14 +358,15 @@ static void option_instat_callback(struct urb *urb);
 #define ZOOM_PRODUCT_4597  0x9607
 
 /* SpeedUp SU9800 usb 3g modem */
 #define SPEEDUP_PRODUCT_SU9800 0x9800
 
 /* Haier products */
 #define HAIER_VENDOR_ID0x201e
+#define HAIER_PRODUCT_CE81B0x10f8
 #define HAIER_PRODUCT_CE1000x2009
 
 /* Cinterion (formerly Siemens) products */
 #define SIEMENS_VENDOR_ID  0x0681
 #define CINTERION_VENDOR_ID0x1e2d
 #define CINTERION_PRODUCT_HC25_MDM 0x0047
 #define CINTERION_PRODUCT_HC25_MDMNET  0x0040
@@ -1616,14 +1617,15 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
  .driver_info = (kernel_ulong_t)four_g_w14_blacklist
},
{ USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 
SPEEDUP_PRODUCT_SU9800, 0xff) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, ZOOM_PRODUCT_4597) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, IBALL_3_5G_CONNECT) },
+   { USB_DEVICE_AND_INTERFACE_INFO(HAIER_VENDOR_ID, HAIER_PRODUCT_CE81B, 
0xff, 0xff, 0xff) },
{ USB_DEVICE(HAIER_VENDOR_ID, HAIER_PRODUCT_CE100) },
/* Pirelli  */
{ USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_1, 
0xff) },
{ USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_C100_2, 
0xff) },
{ USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1004, 
0xff) },
{ USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1005, 
0xff) },
{ USB_DEVICE_INTERFACE_CLASS(PIRELLI_VENDOR_ID, PIRELLI_PRODUCT_1006, 
0xff) },
-- 
1.9.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: ax88179_178a hang over xhci

[Dan Williams]

On Sat, Sep 6, 2014 at 10:05 AM, Andrea Arcangeli aarca...@redhat.com wrote:
 On Sat, Sep 06, 2014 at 05:33:19PM +0200, Andrea Arcangeli wrote:
 without weaking any /sysfs pm runtime related file, and I'll let you
 know if it hangs again.

 No luck... it already hung again with the patches applied.

 try #1:

 [ 1484.886330] [drm:intel_dp_start_link_train] *ERROR* too many full retries, 
 give up
 [ 1492.387055] xhci_hcd :00:14.0: remove, state 1
 [ 1492.387060] usb usb2: USB disconnect, device number 1
 [ 1492.387062] usb 2-2: USB disconnect, device number 2
 [ 1497.404610] xhci_hcd :00:14.0: xHCI host not responding to stop 
 endpoint command.
 [ 1497.404615] xhci_hcd :00:14.0: Assuming host is dying, halting host.
 [ 1497.404638] xhci_hcd :00:14.0: HC died; cleaning up
 [ 1497.404643] ax88179_178a 2-2:1.0 enp0s20u2: unregister 'ax88179_178a' 
 usb-:00:14.0-2, ASIX AX88179 USB 3.0 Gigabit Ethernet
 [ 1497.404657] ax88179_178a 2-2:1.0 enp0s20u2: Failed to read reg index 
 0x0002: -19
 [ 1497.404660] ax88179_178a 2-2:1.0 enp0s20u2: Failed to write reg index 
 0x0002: -19
 [ 1497.431477] ax88179_178a 2-2:1.0 (unregistered net_device): Failed to 
 write reg index 0x0002: -19
 [ 1497.431481] ax88179_178a 2-2:1.0 (unregistered net_device): Failed to 
 write reg index 0x0001: -19
 [ 1497.431482] ax88179_178a 2-2:1.0 (unregistered net_device): Failed to 
 write reg index 0x0002: -19
 [ 1497.431859] xhci_hcd :00:14.0: USB bus 2 deregistered
 [ 1497.431868] xhci_hcd :00:14.0: remove, state 4
 [ 1497.431873] usb usb1: USB disconnect, device number 1
 [ 1497.432070] xhci_hcd :00:14.0: USB bus 1 deregistered

 try #2:

 [ 2237.795264] [drm:intel_dp_start_link_train] *ERROR* too many full retries, 
 give up
 [ 2248.167653] IPv6: ADDRCONF(NETDEV_UP): enp0s20u2: link is not ready
 [ 2252.773689] xhci_hcd :00:14.0: xHCI host not responding to stop 
 endpoint command.
 [ 2252.773697] xhci_hcd :00:14.0: Assuming host is dying, halting host.
 [ 2252.773744] xhci_hcd :00:14.0: HC died; cleaning up
 [ 2252.773786] usb 4-2: USB disconnect, device number 2
 [ 2252.773847] ax88179_178a 4-2:1.0 enp0s20u2: unregister 'ax88179_178a' 
 usb-:00:14.0-2, ASIX AX88179 USB 3.0 Gigabi
 t Ethernet
 [ 2252.787032] ax88179_178a 4-2:1.0 (unregistered net_device): Failed to 
 write reg index 0x0002: -19
 [ 2252.787036] ax88179_178a 4-2:1.0 (unregistered net_device): Failed to 
 write reg index 0x0001: -19
 [ 2252.787037] ax88179_178a 4-2:1.0 (unregistered net_device): Failed to 
 write reg index 0x0002: -19
 [ 2253.721716] xhci_hcd :00:14.0: remove, state 1
 [ 2253.721721] usb usb4: USB disconnect, device number 1
 [ 2253.721916] xhci_hcd :00:14.0: USB bus 4 deregistered
 [ 2253.721920] xhci_hcd :00:14.0: remove, state 4
 [ 2253.721923] usb usb3: USB disconnect, device number 1
 [ 2253.722461] xhci_hcd :00:14.0: USB bus 3 deregistered

 Earlier run from yesterday using upstream 17-rc3:

 [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up
 IPv6: ADDRCONF(NETDEV_UP): enp0s20u2: link is not ready
 ax88179_178a 2-2:1.0 enp0s20u2: ax88179 - Link status is: 1
 ax88179_178a 2-2:1.0 enp0s20u2: ax88179 - Link status is: 1
 IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u2: link becomes ready
 IPv6: ADDRCONF(NETDEV_UP): enp0s20u2: link is not ready
 ax88179_178a 2-2:1.0 enp0s20u2: ax88179 - Link status is: 1
 ax88179_178a 2-2:1.0 enp0s20u2: ax88179 - Link status is: 1
 IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u2: link becomes ready
 xhci_hcd :00:14.0: remove, state 1
 usb usb2: USB disconnect, device number 1

 I noticed that sometime before the hang there's the drm error
 message... I tried also to xset dpms force off or xset dpms force
 standby during the network load, or to switch to console
 (CTRL+ALT+F1) but it doesn't hang that way. And it also happily hangs
 when there are no messages from drm. So I think it's just an accident
 the hang is shortly preceeded by the drm msg, but mentioning it just
 in case. There should be no obvious connection at least.

 In normal usage it tends to work fine, it's just my flooding stress
 test that triggers the problem eventually. It's quite simple:

 netcat otherhost discard /dev/zero
 netcat otherhost chargen /dev/null

 It only requires to enable discard and chargen services in xinetd to
 reproduce. I cannot exclude it's a problem in my laptop xhci hardware
 though (I tested two different usb devices with this same chip and
 same driver, and they both hang eventually). I also need to be logged
 in the GUI to reproduce quicker.

Thanks for giving that branch a try Andrea.  Let me give your test
case a shot and I'll come back to you with some debug options.

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

Re: [xhci] BUG: unable to handle kernel NULL pointer dereference at (null)

[Dan Williams]

I love 0day!  That is all.

On Wed, Aug 27, 2014 at 10:09 AM, Fengguang Wu fengguang...@intel.com wrote:
 Greetings,

 0day kernel testing robot got the below dmesg and the first bad commit is

 git://git.kernel.org/pub/scm/linux/kernel/git/djbw/usb.git td-fragments-v1

 commit e65e21a542cab81d794db4e5fe919c4e1d624ea7
 Author: Dan Williams dan.j.willi...@intel.com
 AuthorDate: Tue Jul 22 00:08:51 2014 -0700
 Commit: Dan Williams dan.j.willi...@intel.com
 CommitDate: Fri Aug 22 10:06:50 2014 -0700

 xhci: unit test ring enqueue/dequeue routines

 Given the complexity of satisfying xhci 1.0+ host trb boundary
 constraints, provide a test case that exercises inserting mid-segment
 links into a ring.

 The linker --wrap= option is used to not pollute the global identifier
 space and to make it clear which standard xhci driver routines are being
 mocked-up.  The --wrap= option does not come into play when both
 xhci-hcd and xhci-test are built-in to the kernel, so namespace
 collisions are prevented by excluding xhci-test from the build when
 xhci-hcd is built-in.

 It's unfortunate that this is an in-kernel test rather than userspace
 and that the infrastructure is custom rather than generic.  That said,
 it serves its purpose of exercising the corner cases of the scatterlist
 parsing implementation in xhci.

 Cc: Rusty Russell ru...@rustcorp.com.au
 Signed-off-by: Dan Williams dan.j.willi...@intel.com

 +--+++
 |  | fb6fa3e625 | 
 e65e21a542 |
 +--+++
 | boot_successes   | 60 | 0   
|
 | boot_failures| 0  | 20  
|
 | BUG:unable_to_handle_kernel_NULL_pointer_dereference | 0  | 20  
|
 | Oops | 0  | 20  
|
 | RIP:setup_test_skip64| 0  | 20  
|
 | Kernel_panic-not_syncing:Fatal_exception | 0  | 20  
|
 | backtrace:do_test| 0  | 20  
|
 | backtrace:xhci_test_init | 0  | 20  
|
 | backtrace:kernel_init_freeable   | 0  | 20  
|
 +--+++

 [   12.405859] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
 [   12.406471] ohci-pci: OHCI PCI platform driver
 [   12.406906] ohci-platform: OHCI generic platform driver
 [   12.407510] BUG: unable to handle kernel NULL pointer dereference at   
 (null)
 [   12.408218] IP: [81968843] setup_test_skip64+0x183/0x270
 [   12.408781] PGD 0
 [   12.409010] Oops:  [#1] SMP DEBUG_PAGEALLOC
 [   12.409450] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
 3.16.0-rc5-00225-ge65e21a #6
 [   12.410102] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 [   12.410599] task: 880012128000 ti: 88001213 task.ti: 
 88001213
 [   12.410950] RIP: 0010:[81968843]  [81968843] 
 setup_test_skip64+0x183/0x270
 [   12.410950] RSP: :880012133d08  EFLAGS: 00010202
 [   12.410950] RAX: 880012117000 RBX:  RCX: 
 0007800f
 [   12.410950] RDX: 0040 RSI: 0f01 RDI: 
 
 [   12.410950] RBP: 880012133d48 R08: 0fe0 R09: 
 
 [   12.410950] R10: 000f R11: 0001 R12: 
 8000
 [   12.410950] R13:  R14: ffe0 R15: 
 ffe0
 [   12.410950] FS:  () GS:88001240() 
 knlGS:
 [   12.410950] CS:  0010 DS:  ES:  CR0: 8005003b
 [   12.410950] CR2:  CR3: 02568000 CR4: 
 06b0
 [   12.410950] Stack:
 [   12.410950]  880012133ddc 880012133de8 880012133e10 
 
 [   12.410950]   88000b1a2400  
 
 [   12.410950]  880012133e48 81d71168  
 303a35343200
 [   12.410950] Call Trace:
 [   12.410950]  [81d71168] do_test.constprop.70+0x47/0x894
 [   12.410950]  [819686c0] ? setup_test_32_248_8+0x340/0x340
 [   12.410950]  [81826630] ? device_create_groups_vargs+0xe0/0x1a0
 [   12.410950]  [82d3a394] ? ohci_platform_init+0x60/0x60
 [   12.410950]  [82d3a585] xhci_test_init+0x1f1/0x2a5
 [   12.410950]  [819686c0] ? setup_test_32_248_8+0x340/0x340
 [   12.410950]  [81968380] ? setup_test_wrap64+0x320/0x320
 [   12.410950]  [81968060] ? setup_test_dont_trim+0x2f0/0x2f0
 [   12.410950]  [81967d70

Re: [RFC PATCH 09/20] xhci: introduce ring ops to handle event vs non-event rings

[Dan Williams]

On Tue, Aug 26, 2014 at 3:37 AM, David Laight david.lai...@aculab.com wrote:
 From: Dan Williams
 It's confusing (to me at least) to keep on remembering the differences
 between event rings (managed by the hardware) and non-event rings
 managed by the host.  Replace if (ring-type == FOO) branches with
 ring ops that are specific to the type of ring.

 This is a tradeoff of direct code readability vs isolation and better
 readability of diffs (i.e. diff-context will now explicitly identify the
 ring type).

 I think it would be better to completely separate the event/cmd rings
 calls at their call sites.
 IIRC there is almost no overlap because the operations are different.
 Using common code must have seemed a good idea at the start.

 It promotes quirky rings to their own type in that they have their own
 distinct ring ops, as a result we no longer need to pass 'xhci' to
 queue_trb().

 Finally, this is a preparation for xhci1.0+ ring handling which will
 have it's own ring ops.

 Do you need to worry?
 I suspect the 0.9 hardware will be happy with the 1.0 ring handling.
 Maybe even the setting for the residual number of transfer buffers.


That's exactly the point, I don't have to worry because v0.9 hardware
will not see any of this thrash.  This situation might be a good
candidate for a flag that forces v1.0 ring handling on v0.9 hardware
so others can test it over time.  For now, since I can't/won't test on
v0.9 hardware, I'd rather not worry about inadvertently breaking those
hosts.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 19/20] xhci: v1.0 scatterlist enqueue support (td-fragment rework)

[Dan Williams]

On Tue, Aug 26, 2014 at 3:55 AM, David Laight david.lai...@aculab.com wrote:
 From: Dan Williams
 v1.0 hosts require that TD-fragments (portions of a TD that do not end
 on a MPB boundary) not cross a TRB segment boundary. This constraint is
 in addition to the constraint that a TRB may not specify a transfer that
 crosses a 64K boundary. This enabling permits the driver to accept
 scatterlists of nearly any geometry.  Nearly because there is one
 unlikely remaining degenerate case of a driver submitting a transfer
 that consumes all the TRBs in a segment before hitting an MBP boundary.
 That case is trapped and the transfer is rejected.

 Given the multi-dimensional constraints of queuing TRBs from a
 scattelist, this implementation does not attempt to pre-calculate the
 number TRBs in a TD.  Instead it attempts a dry-run of enqueuing the
 TRBs to the ring.

 Presumably not really a 'dry run', it is just willing to back up to
 the buffer than contained the previous boundary.

In the first pass we don't modify the enqueue pointer or any other
ring state (outside of ring expansion).  If we encounter an error in
the first pass we can simply return and no ring tracking state will
have been modified.  That's why I consider it a dry-run.

 If it discovers a TD-fragment straddling a segment
 boundary it backs up to the last MBP boundary, inserts a link-trb at
 that boundary, and restarts enqueuing in the next segment.

 You have to be careful doing that.
 At least some controllers don't like following a LINK and then finding
 that they can't process the 'linked-to' TRB.
 This means that the ownership of the LINK TRB can't be changed until
 the ownership of the rest of the TRBs has been set (the controller could
 be active and process the LINK at the end of the previous transfer).

 This is why I ended up with a patch that moved the ownership setting
 out of the callers.

I believe I have this case covered, and the existing code was careful
to not link until there was a valid TRB in the next segement.

 A side
 effect of not pre-calculating the number of required TRBs is that the
 ring is now expanded as the scatterlist is walked, rather than in
 prepare_ring().

 To simplify the math and forgo the need to track (union xhci_trb *) and
 (struct xhci_segment *) pointers, modulo-power-of-2 ring indexes are
 used.  A small portion of the patch is adding infrastructure to convert
 from a (struct xhci_ring_pointer *) to an integer index.

 Glossary of acronyms:
 TRB: Transfer Request Buffer, 16-byte xhci-hardware scatterlist entry

 TD: Transfer Descriptor, the set of trbs that comprise a transfer

 TRB segment: A contiguous allocation of TRBs.  They are of size
   PAGE_SIZE in the xhci driver.  Each segment ends with a link TRB
   pointing to the next segment, but the link trb may appear at any TRB
   boundary in the segment.

 Ring: A linked list of segments.

 MBP: Max Burst Packet, is the minimum amount of data hardware expects to
   transfer before the end of a segment (assuming the TD spans a segment
   boundary).

 I think you can ignore MBP, and only align to 1k boundaries.
 However, I suspect that all that happens is the host controller splits
 the transfer as the ring end - so provided it is at a 1k boundary
 the target device can't tell the difference.
 Indeed the 'end of TRB list' flag could be set on the 1k boundary.

 1k boundaries were enough to make the Ge card I had (I don't have
 them any more) work on the Intel Ivy bridge USB3.


That's great, but the spec says:

If the TD Transfer Size is an even multiple of the MBP then all TD
Fragments shall define exact multiples of MBP data bytes. If not, then
the only last TD Fragment shall define less than MBP data (or the
Residue) bytes

If you convince the spec author to add ...just kidding ignore that,
then I'll relax the implementation. :-)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 09/20] xhci: introduce ring ops to handle event vs non-event rings

[Dan Williams]

On Tue, Aug 26, 2014 at 9:21 AM, David Laight david.lai...@aculab.com wrote:
 From: Dan Williams [mailto:dan.j.willi...@intel.com]
 On Tue, Aug 26, 2014 at 3:37 AM, David Laight david.lai...@aculab.com 
 wrote:
  From: Dan Williams
  It's confusing (to me at least) to keep on remembering the differences
  between event rings (managed by the hardware) and non-event rings
  managed by the host.  Replace if (ring-type == FOO) branches with
  ring ops that are specific to the type of ring.
 
  This is a tradeoff of direct code readability vs isolation and better
  readability of diffs (i.e. diff-context will now explicitly identify the
  ring type).
 
  I think it would be better to completely separate the event/cmd rings
  calls at their call sites.
  IIRC there is almost no overlap because the operations are different.
  Using common code must have seemed a good idea at the start.
 
  It promotes quirky rings to their own type in that they have their own
  distinct ring ops, as a result we no longer need to pass 'xhci' to
  queue_trb().
 
  Finally, this is a preparation for xhci1.0+ ring handling which will
  have it's own ring ops.
 
  Do you need to worry?
  I suspect the 0.9 hardware will be happy with the 1.0 ring handling.
  Maybe even the setting for the residual number of transfer buffers.
 

 That's exactly the point, I don't have to worry because v0.9 hardware
 will not see any of this thrash.  This situation might be a good
 candidate for a flag that forces v1.0 ring handling on v0.9 hardware
 so others can test it over time.  For now, since I can't/won't test on
 v0.9 hardware, I'd rather not worry about inadvertently breaking those
 hosts.

 But the indirected function calls are probably over-engineering.

I'm more than willing to rip it out, but only in the presence of
positive test results.

 They also come at moderate execution cost.
 Not that any of the xhci code seems to have considered execution time.
 I could saturate a Ge full duplex, but the next version of USB hardware
 will be fast enough for 10Ge - and then execution time does start mattering.
 It might even matter for USB3 on newer tablets/phones.

Yes, we can cross that bridge when we come to it.  But, I will say,
modern cpus are quite good at indirect-branches.
--
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

[RFC PATCH 01/20] xhci: cleanup remaining cycle bit toggles via ternary conditional

[Dan Williams]

These can simply be toggled via xor.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-ring.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 749fc68eb5c1..0efbbf0b6233 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -237,9 +237,9 @@ static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring 
*ring,
next-link.control ^= cpu_to_le32(TRB_CYCLE);
 
/* Toggle the cycle bit after the last ring segment. */
-   if (last_trb_on_last_seg(xhci, ring, ring-enq_seg, 
next)) {
-   ring-cycle_state = (ring-cycle_state ? 0 : 1);
-   }
+   if (last_trb_on_last_seg(xhci, ring, ring-enq_seg,
+   next))
+   ring-cycle_state ^= 1;
}
ring-enq_seg = ring-enq_seg-next;
ring-enqueue = ring-enq_seg-trbs;
@@ -2875,9 +2875,9 @@ static int prepare_ring(struct xhci_hcd *xhci, struct 
xhci_ring *ep_ring,
next-link.control ^= cpu_to_le32(TRB_CYCLE);
 
/* Toggle the cycle bit after the last ring segment. */
-   if (last_trb_on_last_seg(xhci, ring, ring-enq_seg, 
next)) {
-   ring-cycle_state = (ring-cycle_state ? 0 : 1);
-   }
+   if (last_trb_on_last_seg(xhci, ring, ring-enq_seg,
+   next))
+   ring-cycle_state ^= 1;
ring-enq_seg = ring-enq_seg-next;
ring-enqueue = ring-enq_seg-trbs;
next = ring-enqueue;

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

[RFC PATCH 02/20] xhci: remove invalid cast of xhci to a usb_device in xhci_log_ctx trace

[Dan Williams]

An xhci controller device is a pci or a platform device, never a
usb_device.

Cc: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-trace.h |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
index dde3959b7a33..fe7ee98d2a2b 100644
--- a/drivers/usb/host/xhci-trace.h
+++ b/drivers/usb/host/xhci-trace.h
@@ -77,20 +77,15 @@ DECLARE_EVENT_CLASS(xhci_log_ctx,
__field(dma_addr_t, ctx_dma)
__field(u8 *, ctx_va)
__field(unsigned, ctx_ep_num)
-   __field(int, slot_id)
__dynamic_array(u32, ctx_data,
((HCC_64BYTE_CONTEXT(xhci-hcc_params) + 1) * 8) *
((ctx-type == XHCI_CTX_TYPE_INPUT) + ep_num + 1))
),
TP_fast_assign(
-   struct usb_device *udev;
-
-   udev = to_usb_device(xhci_to_hcd(xhci)-self.controller);
__entry-ctx_64 = HCC_64BYTE_CONTEXT(xhci-hcc_params);
__entry-ctx_type = ctx-type;
__entry-ctx_dma = ctx-dma;
__entry-ctx_va = ctx-bytes;
-   __entry-slot_id = udev-slot_id;
__entry-ctx_ep_num = ep_num;
memcpy(__get_dynamic_array(ctx_data), ctx-bytes,
((HCC_64BYTE_CONTEXT(xhci-hcc_params) + 1) * 32) *

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

[RFC PATCH 04/20] xhci: increase trb segment size, kill -segment_pool

[Dan Williams]

TRB segments are allocated relatively infrequently and would benefit
from being larger (to reduce probability of overrunning a segment in a
TD fragment).  We already burn a page satisfying a single segment
allocation, so there's little reason to not allocate in page-sized
chunks in the first instance.

In support of freeing segments from irq context struct xhci_segment
grows a -dev and -ew field (exectue_work).  As a result there is no
longer a need to pass a 'xhci' parameter down to xhci_free_segment().

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-mem.c |   70 ---
 drivers/usb/host/xhci.c |2 +
 drivers/usb/host/xhci.h |   19 +++-
 3 files changed, 45 insertions(+), 46 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index fcae0ce47daa..1d05dc9e1928 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -40,14 +40,15 @@ static struct xhci_segment *xhci_segment_alloc(struct 
xhci_hcd *xhci,
unsigned int cycle_state, gfp_t flags)
 {
struct xhci_segment *seg;
-   dma_addr_t  dma;
int i;
 
seg = kzalloc(sizeof *seg, flags);
if (!seg)
return NULL;
 
-   seg-trbs = dma_pool_alloc(xhci-segment_pool, flags, dma);
+   seg-dev = xhci_to_dev(xhci);
+   seg-trbs = dma_alloc_coherent(seg-dev, TRB_SEGMENT_SIZE,
+   seg-dma, flags);
if (!seg-trbs) {
kfree(seg);
return NULL;
@@ -59,33 +60,43 @@ static struct xhci_segment *xhci_segment_alloc(struct 
xhci_hcd *xhci,
for (i = 0; i  TRBS_PER_SEGMENT; i++)
seg-trbs[i].link.control |= cpu_to_le32(TRB_CYCLE);
}
-   seg-dma = dma;
seg-next = NULL;
 
return seg;
 }
 
-static void xhci_segment_free(struct xhci_hcd *xhci, struct xhci_segment *seg)
+static void xhci_segment_free_work(struct work_struct *w)
 {
+   struct xhci_segment *seg = container_of(w, typeof(*seg), work);
+
if (seg-trbs) {
-   dma_pool_free(xhci-segment_pool, seg-trbs, seg-dma);
+   dma_free_coherent(seg-dev, TRB_SEGMENT_SIZE, seg-trbs,
+   seg-dma);
seg-trbs = NULL;
}
+   put_device(seg-dev);
kfree(seg);
 }
 
-static void xhci_free_segments_for_ring(struct xhci_hcd *xhci,
-   struct xhci_segment *first)
+static void xhci_segment_free(struct xhci_segment *seg)
+{
+   INIT_WORK(seg-work, xhci_segment_free_work);
+   get_device(seg-dev);
+   schedule_work(seg-work);
+}
+
+static void xhci_free_segments_for_ring(struct xhci_segment *first)
 {
struct xhci_segment *seg;
 
seg = first-next;
while (seg != first) {
struct xhci_segment *next = seg-next;
-   xhci_segment_free(xhci, seg);
+
+   xhci_segment_free(seg);
seg = next;
}
-   xhci_segment_free(xhci, first);
+   xhci_segment_free(first);
 }
 
 /*
@@ -273,7 +284,7 @@ static int xhci_update_stream_mapping(struct xhci_ring 
*ring, gfp_t mem_flags)
 }
 
 /* XXX: Do we need the hcd structure in all these functions? */
-void xhci_ring_free(struct xhci_hcd *xhci, struct xhci_ring *ring)
+void xhci_ring_free(struct xhci_ring *ring)
 {
if (!ring)
return;
@@ -281,7 +292,7 @@ void xhci_ring_free(struct xhci_hcd *xhci, struct xhci_ring 
*ring)
if (ring-first_seg) {
if (ring-type == TYPE_STREAM)
xhci_remove_stream_mapping(ring);
-   xhci_free_segments_for_ring(xhci, ring-first_seg);
+   xhci_free_segments_for_ring(ring-first_seg);
}
 
kfree(ring);
@@ -336,7 +347,7 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd 
*xhci,
prev = *first;
while (prev) {
next = prev-next;
-   xhci_segment_free(xhci, prev);
+   xhci_segment_free(prev);
prev = next;
}
return -ENOMEM;
@@ -411,7 +422,7 @@ void xhci_free_or_cache_endpoint_ring(struct xhci_hcd *xhci,
virt_dev-num_rings_cached,
(virt_dev-num_rings_cached  1) ? s : );
} else {
-   xhci_ring_free(xhci, virt_dev-eps[ep_index].ring);
+   xhci_ring_free(virt_dev-eps[ep_index].ring);
xhci_dbg(xhci, Ring cache full (%d rings), 
freeing ring\n,
virt_dev-num_rings_cached);
@@ -482,7 +493,7 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
struct xhci_segment *next

[RFC PATCH 05/20] xhci: prepare for mid-segment link-trbs

[Dan Williams]

Break the assumption that link-trbs are always located at the end of a
segment.  Introduce -link to struct xhci_segment and use that every
place that looks up the link-trb for a segment.  This is meant to be
functionally equivalent to the existing driver and is just a search and
replace for hard coded link at the end assumption.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-mem.c  |   17 +++--
 drivers/usb/host/xhci-ring.c |7 ++-
 drivers/usb/host/xhci.c  |   12 
 drivers/usb/host/xhci.h  |1 +
 4 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1d05dc9e1928..1eda6166b30f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -115,11 +115,11 @@ static void xhci_link_segments(struct xhci_hcd *xhci, 
struct xhci_segment *prev,
return;
prev-next = next;
if (type != TYPE_EVENT) {
-   prev-trbs[TRBS_PER_SEGMENT-1].link.segment_ptr =
-   cpu_to_le64(next-dma);
+   prev-link = prev-trbs[TRBS_PER_SEGMENT-1];
+   prev-link-link.segment_ptr = cpu_to_le64(next-dma);
 
/* Set the last TRB in the segment to have a TRB type ID of 
Link TRB */
-   val = le32_to_cpu(prev-trbs[TRBS_PER_SEGMENT-1].link.control);
+   val = le32_to_cpu(prev-link-link.control);
val = ~TRB_TYPE_BITMASK;
val |= TRB_TYPE(TRB_LINK);
/* Always set the chain bit with 0.95 hardware */
@@ -128,7 +128,7 @@ static void xhci_link_segments(struct xhci_hcd *xhci, 
struct xhci_segment *prev,
(type == TYPE_ISOC 
 (xhci-quirks  XHCI_AMD_0x96_HOST)))
val |= TRB_CHAIN;
-   prev-trbs[TRBS_PER_SEGMENT-1].link.control = cpu_to_le32(val);
+   prev-link-link.control = cpu_to_le32(val);
}
 }
 
@@ -152,10 +152,8 @@ static void xhci_link_rings(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
ring-num_trbs_free += (TRBS_PER_SEGMENT - 1) * num_segs;
 
if (ring-type != TYPE_EVENT  ring-enq_seg == ring-last_seg) {
-   ring-last_seg-trbs[TRBS_PER_SEGMENT-1].link.control
-   = ~cpu_to_le32(LINK_TOGGLE);
-   last-trbs[TRBS_PER_SEGMENT-1].link.control
-   |= cpu_to_le32(LINK_TOGGLE);
+   ring-last_seg-link-link.control = ~cpu_to_le32(LINK_TOGGLE);
+   last-link-link.control |= cpu_to_le32(LINK_TOGGLE);
ring-last_seg = last;
}
 }
@@ -395,8 +393,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd 
*xhci,
/* Only event ring does not use link TRB */
if (type != TYPE_EVENT) {
/* See section 4.9.2.1 and 6.4.4.1 */
-   ring-last_seg-trbs[TRBS_PER_SEGMENT - 1].link.control |=
-   cpu_to_le32(LINK_TOGGLE);
+   ring-last_seg-link-link.control |= cpu_to_le32(LINK_TOGGLE);
}
xhci_initialize_ring_info(ring, cycle_state);
return ring;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 0efbbf0b6233..ae436cb7e06d 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -374,12 +374,10 @@ static struct xhci_segment *find_trb_seg(
union xhci_trb  *trb, int *cycle_state)
 {
struct xhci_segment *cur_seg = start_seg;
-   struct xhci_generic_trb *generic_trb;
 
while (cur_seg-trbs  trb ||
cur_seg-trbs[TRBS_PER_SEGMENT - 1]  trb) {
-   generic_trb = cur_seg-trbs[TRBS_PER_SEGMENT - 1].generic;
-   if (generic_trb-field[3]  cpu_to_le32(LINK_TOGGLE))
+   if (cur_seg-link-link.control  cpu_to_le32(LINK_TOGGLE))
*cycle_state ^= 0x1;
cur_seg = cur_seg-next;
if (cur_seg == start_seg)
@@ -1735,8 +1733,7 @@ struct xhci_segment *trb_in_td(struct xhci_segment 
*start_seg,
if (start_dma == 0)
return NULL;
/* We may get an event for a Link TRB in the middle of a TD */
-   end_seg_dma = xhci_trb_virt_to_dma(cur_seg,
-   cur_seg-trbs[TRBS_PER_SEGMENT - 1]);
+   end_seg_dma = xhci_trb_virt_to_dma(cur_seg, cur_seg-link);
/* If the end TRB isn't in this segment, this is set to 0 */
end_trb_dma = xhci_trb_virt_to_dma(cur_seg, end_trb);
 
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1d3dc014b477..0b05f67fde5b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -820,10 +820,14 @@ static void xhci_clear_command_ring(struct xhci_hcd *xhci)
ring = xhci-cmd_ring;
seg = ring-deq_seg;
do {
-   memset(seg-trbs, 0

[RFC PATCH 03/20] xhci: introduce xhci_to_dev

[Dan Williams]

Replace many occurrences of xhci_to_hcd(xhci)-self.controller with a
helper.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-mem.c |   29 -
 drivers/usb/host/xhci.c |6 +++---
 drivers/usb/host/xhci.h |   13 +
 3 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8056d90690ee..fcae0ce47daa 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -574,11 +574,10 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs,
struct xhci_stream_ctx *stream_ctx, dma_addr_t dma)
 {
-   struct device *dev = xhci_to_hcd(xhci)-self.controller;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
 
if (size  MEDIUM_STREAM_ARRAY_SIZE)
-   dma_free_coherent(dev, size,
+   dma_free_coherent(xhci_to_dev(xhci), size,
stream_ctx, dma);
else if (size = SMALL_STREAM_ARRAY_SIZE)
return dma_pool_free(xhci-small_streams_pool,
@@ -602,11 +601,10 @@ static struct xhci_stream_ctx 
*xhci_alloc_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs, dma_addr_t *dma,
gfp_t mem_flags)
 {
-   struct device *dev = xhci_to_hcd(xhci)-self.controller;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
 
if (size  MEDIUM_STREAM_ARRAY_SIZE)
-   return dma_alloc_coherent(dev, size,
+   return dma_alloc_coherent(xhci_to_dev(xhci), size,
dma, mem_flags);
else if (size = SMALL_STREAM_ARRAY_SIZE)
return dma_pool_alloc(xhci-small_streams_pool,
@@ -1644,7 +1642,6 @@ void xhci_slot_copy(struct xhci_hcd *xhci,
 static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags)
 {
int i;
-   struct device *dev = xhci_to_hcd(xhci)-self.controller;
int num_sp = HCS_MAX_SCRATCHPAD(xhci-hcs_params2);
 
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
@@ -1657,7 +1654,7 @@ static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t 
flags)
if (!xhci-scratchpad)
goto fail_sp;
 
-   xhci-scratchpad-sp_array = dma_alloc_coherent(dev,
+   xhci-scratchpad-sp_array = dma_alloc_coherent(xhci_to_dev(xhci),
 num_sp * sizeof(u64),
 xhci-scratchpad-sp_dma, flags);
if (!xhci-scratchpad-sp_array)
@@ -1676,8 +1673,8 @@ static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t 
flags)
xhci-dcbaa-dev_context_ptrs[0] = 
cpu_to_le64(xhci-scratchpad-sp_dma);
for (i = 0; i  num_sp; i++) {
dma_addr_t dma;
-   void *buf = dma_alloc_coherent(dev, xhci-page_size, dma,
-   flags);
+   void *buf = dma_alloc_coherent(xhci_to_dev(xhci),
+   xhci-page_size, dma, flags);
if (!buf)
goto fail_sp5;
 
@@ -1690,7 +1687,7 @@ static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t 
flags)
 
  fail_sp5:
for (i = i - 1; i = 0; i--) {
-   dma_free_coherent(dev, xhci-page_size,
+   dma_free_coherent(xhci_to_dev(xhci), xhci-page_size,
xhci-scratchpad-sp_buffers[i],
xhci-scratchpad-sp_dma_buffers[i]);
}
@@ -1700,7 +1697,7 @@ static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t 
flags)
kfree(xhci-scratchpad-sp_buffers);
 
  fail_sp3:
-   dma_free_coherent(dev, num_sp * sizeof(u64),
+   dma_free_coherent(xhci_to_dev(xhci), num_sp * sizeof(u64),
xhci-scratchpad-sp_array,
xhci-scratchpad-sp_dma);
 
@@ -1716,7 +1713,6 @@ static void scratchpad_free(struct xhci_hcd *xhci)
 {
int num_sp;
int i;
-   struct device *dev = xhci_to_hcd(xhci)-self.controller;
 
if (!xhci-scratchpad)
return;
@@ -1724,13 +1720,13 @@ static void scratchpad_free(struct xhci_hcd *xhci)
num_sp = HCS_MAX_SCRATCHPAD(xhci-hcs_params2);
 
for (i = 0; i  num_sp; i++) {
-   dma_free_coherent(dev, xhci-page_size,
+   dma_free_coherent(xhci_to_dev(xhci), xhci-page_size,
xhci-scratchpad-sp_buffers[i],
xhci-scratchpad-sp_dma_buffers[i]);
}
kfree(xhci-scratchpad-sp_dma_buffers);
kfree(xhci-scratchpad-sp_buffers);
-   dma_free_coherent(dev, num_sp * sizeof(u64),
+   dma_free_coherent(xhci_to_dev(xhci), num_sp * sizeof(u64),
xhci-scratchpad-sp_array,
xhci-scratchpad-sp_dma);
kfree(xhci-scratchpad);
@@ -1792,7 +1788,6 @@ void xhci_free_command

[RFC PATCH 11/20] xhci: provide helpers for retrieving 'enqueue' and 'dequeue' pointers

[Dan Williams]

In prepartion for converting ring management from pointers to power-of-2
indexes, introduce xhci_ring_dequeue(), xhci_ring_enqueue(),
xhci_ring_set_dequeue(), and xhci_ring_set_enqueue().

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-dbg.c  |   16 ++--
 drivers/usb/host/xhci-mem.c  |   14 ++--
 drivers/usb/host/xhci-ring.c |  166 ++
 drivers/usb/host/xhci.c  |6 +-
 drivers/usb/host/xhci.h  |   27 ++-
 5 files changed, 130 insertions(+), 99 deletions(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index ad22409ddecb..19a6037257c3 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -328,16 +328,16 @@ void xhci_debug_segment(struct xhci_hcd *xhci, struct 
xhci_segment *seg)
 
 void xhci_dbg_ring_ptrs(struct xhci_hcd *xhci, struct xhci_ring *ring)
 {
-   xhci_dbg(xhci, Ring deq = %p (virt), 0x%llx (dma)\n,
-   ring-dequeue,
-   (unsigned long long)xhci_trb_virt_to_dma(ring-deq_seg,
-   ring-dequeue));
+   dma_addr_t dma;
+
+   dma = xhci_trb_virt_to_dma(ring-deq_seg, xhci_ring_dequeue(ring));
+   xhci_dbg(xhci, Ring deq = %p (virt), %pad (dma)\n,
+   xhci_ring_dequeue(ring), dma);
xhci_dbg(xhci, Ring deq updated %u times\n,
ring-deq_updates);
-   xhci_dbg(xhci, Ring enq = %p (virt), 0x%llx (dma)\n,
-   ring-enqueue,
-   (unsigned long long)xhci_trb_virt_to_dma(ring-enq_seg,
-   ring-enqueue));
+   dma = xhci_trb_virt_to_dma(ring-enq_seg, xhci_ring_enqueue(ring));
+   xhci_dbg(xhci, Ring enq = %p (virt), %pad (dma)\n,
+   xhci_ring_enqueue(ring), dma);
xhci_dbg(xhci, Ring enq updated %u times\n,
ring-enq_updates);
 }
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index cfc7acc6482d..e0b459441807 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -261,9 +261,9 @@ static void xhci_initialize_ring_info(struct xhci_ring 
*ring,
struct xhci_segment *first_seg = xhci_ring_first_seg(ring);
 
/* The ring is empty, so the enqueue pointer == dequeue pointer */
-   ring-enqueue = first_seg-trbs;
+   xhci_ring_set_enqueue(ring, first_seg-trbs);
ring-enq_seg = first_seg;
-   ring-dequeue = ring-enqueue;
+   xhci_ring_set_dequeue(ring, xhci_ring_enqueue(ring));
ring-deq_seg = first_seg;
/* The ring is initialized to 0. The producer must write 1 to the cycle
 * bit to handover ownership of the TRB, so PCS = 1.  The consumer must
@@ -749,9 +749,11 @@ void xhci_setup_no_streams_ep_input_ctx(struct xhci_hcd 
*xhci,
struct xhci_ep_ctx *ep_ctx,
struct xhci_virt_ep *ep)
 {
+   struct xhci_ring *ring = ep-ring;
dma_addr_t addr;
+
ep_ctx-ep_info = cpu_to_le32(~(EP_MAXPSTREAMS_MASK | EP_HAS_LSA));
-   addr = xhci_trb_virt_to_dma(ep-ring-deq_seg, ep-ring-dequeue);
+   addr = xhci_trb_virt_to_dma(ring-deq_seg, xhci_ring_dequeue(ring));
ep_ctx-deq  = cpu_to_le64(addr | ep-ring-cycle_state);
 }
 
@@ -1014,8 +1016,8 @@ void xhci_copy_ep0_dequeue_into_input_ctx(struct xhci_hcd 
*xhci,
 * been completed or cancelled before the reset.
 */
ep0_ctx-deq = cpu_to_le64(xhci_trb_virt_to_dma(ep_ring-enq_seg,
-   ep_ring-enqueue)
-  | ep_ring-cycle_state);
+   xhci_ring_enqueue(ep_ring))
+   | ep_ring-cycle_state);
 }
 
 /*
@@ -2020,7 +2022,7 @@ static void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
dma_addr_t deq;
 
deq = xhci_trb_virt_to_dma(xhci-event_ring-deq_seg,
-   xhci-event_ring-dequeue);
+   xhci_ring_dequeue(xhci-event_ring));
if (deq == 0  !in_interrupt())
xhci_warn(xhci, WARN something wrong with SW event ring 
dequeue ptr.\n);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 61c48ed4db9b..01e6685738ff 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -122,7 +122,7 @@ static bool ep_last_trb(struct xhci_ring *ring, struct 
xhci_segment *seg,
 
 static int enqueue_is_link_trb(struct xhci_ring *ring)
 {
-   struct xhci_link_trb *link = ring-enqueue-link;
+   struct xhci_link_trb *link = xhci_ring_enqueue(ring)-link;
return TRB_TYPE_LINK_LE32(link-control);
 }
 
@@ -148,11 +148,11 @@ static void next_trb(struct xhci_ring *ring, struct 
xhci_segment **seg,
 static void event_inc_deq(struct xhci_ring *ring)
 {
ring-deq_updates++;
-   ring-dequeue

[RFC PATCH 06/20] xhci: drop 'xhci' argument to last_trb

[Dan Williams]

last_trb() can simply distinguish event rings by the ring -type.  With
this in place the 'xhci' parameter can be removed from
last_trb_on_last_seg(), next_trb(), and inc_deq().

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-ring.c |   75 --
 1 files changed, 35 insertions(+), 40 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ae436cb7e06d..8f4e900128b5 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -90,12 +90,12 @@ dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg,
 /* Does this link TRB point to the first segment in a ring,
  * or was the previous TRB the last TRB on the last segment in the ERST?
  */
-static bool last_trb_on_last_seg(struct xhci_hcd *xhci, struct xhci_ring *ring,
+static bool last_trb_on_last_seg(struct xhci_ring *ring,
struct xhci_segment *seg, union xhci_trb *trb)
 {
-   if (ring == xhci-event_ring)
+   if (ring-type == TYPE_EVENT)
return (trb == seg-trbs[TRBS_PER_SEGMENT]) 
-   (seg-next == xhci-event_ring-first_seg);
+   (seg-next == ring-first_seg);
else
return le32_to_cpu(trb-link.control)  LINK_TOGGLE;
 }
@@ -104,10 +104,10 @@ static bool last_trb_on_last_seg(struct xhci_hcd *xhci, 
struct xhci_ring *ring,
  * segment?  I.e. would the updated event TRB pointer step off the end of the
  * event seg?
  */
-static int last_trb(struct xhci_hcd *xhci, struct xhci_ring *ring,
-   struct xhci_segment *seg, union xhci_trb *trb)
+static int last_trb(struct xhci_ring *ring, struct xhci_segment *seg,
+   union xhci_trb *trb)
 {
-   if (ring == xhci-event_ring)
+   if (ring-type == TYPE_EVENT)
return trb == seg-trbs[TRBS_PER_SEGMENT];
else
return TRB_TYPE_LINK_LE32(trb-link.control);
@@ -123,12 +123,10 @@ static int enqueue_is_link_trb(struct xhci_ring *ring)
  * TRB is in a new segment.  This does not skip over link TRBs, and it does not
  * effect the ring dequeue or enqueue pointers.
  */
-static void next_trb(struct xhci_hcd *xhci,
-   struct xhci_ring *ring,
-   struct xhci_segment **seg,
+static void next_trb(struct xhci_ring *ring, struct xhci_segment **seg,
union xhci_trb **trb)
 {
-   if (last_trb(xhci, ring, *seg, *trb)) {
+   if (last_trb(ring, *seg, *trb)) {
*seg = (*seg)-next;
*trb = ((*seg)-trbs);
} else {
@@ -140,7 +138,7 @@ static void next_trb(struct xhci_hcd *xhci,
  * See Cycle bit rules. SW is the consumer for the event ring only.
  * Don't make a ring full of link TRBs.  That would be dumb and this would 
loop.
  */
-static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring)
+static void inc_deq(struct xhci_ring *ring)
 {
ring-deq_updates++;
 
@@ -149,7 +147,7 @@ static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring 
*ring)
 * is not on a link TRB, there is one more usable TRB
 */
if (ring-type != TYPE_EVENT 
-   !last_trb(xhci, ring, ring-deq_seg, ring-dequeue))
+   !last_trb(ring, ring-deq_seg, ring-dequeue))
ring-num_trbs_free++;
 
do {
@@ -158,9 +156,9 @@ static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring 
*ring)
 * we're at the end of an event ring segment (which doesn't have
 * link TRBS)
 */
-   if (last_trb(xhci, ring, ring-deq_seg, ring-dequeue)) {
+   if (last_trb(ring, ring-deq_seg, ring-dequeue)) {
if (ring-type == TYPE_EVENT 
-   last_trb_on_last_seg(xhci, ring,
+   last_trb_on_last_seg(ring,
ring-deq_seg, ring-dequeue)) {
ring-cycle_state ^= 1;
}
@@ -169,7 +167,7 @@ static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring 
*ring)
} else {
ring-dequeue++;
}
-   } while (last_trb(xhci, ring, ring-deq_seg, ring-dequeue));
+   } while (last_trb(ring, ring-deq_seg, ring-dequeue));
 }
 
 /*
@@ -198,7 +196,7 @@ static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring 
*ring,
chain = le32_to_cpu(ring-enqueue-generic.field[3])  TRB_CHAIN;
/* If this is not event ring, there is one less usable TRB */
if (ring-type != TYPE_EVENT 
-   !last_trb(xhci, ring, ring-enq_seg, ring-enqueue))
+   !last_trb(ring, ring-enq_seg, ring-enqueue))
ring-num_trbs_free--;
next = ++(ring-enqueue);
 
@@ -206,7 +204,7 @@ static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring 
*ring,
/* Update the dequeue pointer further

[RFC PATCH 08/20] xhci: refactor inc_enq(), share a common advance_enq() with prepare_ring()

[Dan Williams]

There are two locations where we advance the enqueue pointer through a
chain of link trbs, in inc_enq() and prepare_ring().  Factor that into a
common advance_enq().  Also, in preparation for per-ring operations
factor out the differences between the event-rings, chain-quirk-rings
and normal endpoint rings into event_ring_inc_enq() and
common_inc_enq().

Unfortunately this isn't a net win in the diffstat, but it does
eliminate the liability of failing to update one of the instances
especially in preparation for overhauling TD-fragment handling for
xhci1.0+ hosts.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-ring.c |  164 ++
 1 files changed, 86 insertions(+), 78 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bee5c18b0509..d8c9a8211ace 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -171,9 +171,39 @@ static void inc_deq(struct xhci_ring *ring)
 }
 
 /*
- * See Cycle bit rules. SW is the consumer for the event ring only.
- * Don't make a ring full of link TRBs.  That would be dumb and this would 
loop.
- *
+ * Don't make a ring full of link TRBs.  That would be dumb and this
+ * would loop.
+ */
+static void advance_enq(struct xhci_ring *ring, u32 chain, bool do_carry_chain)
+{
+   union xhci_trb *next = ring-enqueue;
+
+   /*
+* Update the enqueue pointer further if we're now pointing to a
+* link TRB
+*/
+   while (last_trb(ring, ring-enq_seg, next)) {
+   if (do_carry_chain) {
+   next-link.control = cpu_to_le32(~TRB_CHAIN);
+   next-link.control |= cpu_to_le32(chain);
+   } else {
+   next-link.control |= cpu_to_le32(TRB_CHAIN);
+   }
+
+   /* Give this link TRB to the hardware */
+   wmb();
+   next-link.control ^= cpu_to_le32(TRB_CYCLE);
+
+   /* Toggle the cycle bit after the last ring segment. */
+   if (last_trb_on_last_seg(ring, ring-enq_seg, next))
+   ring-cycle_state ^= 1;
+   ring-enq_seg = xhci_segment_next(ring, ring-enq_seg);
+   ring-enqueue = ring-enq_seg-trbs;
+   next = ring-enqueue;
+   }
+}
+
+/*
  * If we've just enqueued a TRB that is in the middle of a TD (meaning the
  * chain bit is set), then set the chain bit in all the following link TRBs.
  * If we've enqueued the last TRB in a TD, make sure the following link TRBs
@@ -187,63 +217,68 @@ static void inc_deq(struct xhci_ring *ring)
  * @more_trbs_coming:  Will you enqueue more TRBs before calling
  * prepare_transfer()?
  */
-static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring *ring,
-   bool more_trbs_coming)
+static void common_inc_enq(struct xhci_ring *ring, bool more_trbs_coming,
+   bool do_carry_chain)
 {
-   u32 chain;
-   union xhci_trb *next;
-
-   chain = le32_to_cpu(ring-enqueue-generic.field[3])  TRB_CHAIN;
-   /* If this is not event ring, there is one less usable TRB */
-   if (ring-type != TYPE_EVENT 
-   !last_trb(ring, ring-enq_seg, ring-enqueue))
-   ring-num_trbs_free--;
-   next = ++(ring-enqueue);
+   u32 chain = le32_to_cpu(ring-enqueue-generic.field[3])  TRB_CHAIN;
 
+   ring-num_trbs_free--;
+   (ring-enqueue)++;
ring-enq_updates++;
-   /* Update the dequeue pointer further if that was a link TRB or we're at
-* the end of an event ring segment (which doesn't have link TRBS)
+
+   /*
+* If the caller doesn't plan on enqueueing more TDs before
+* ringing the doorbell, then we don't want to give the link TRB
+* to the hardware just yet.  We'll give the link TRB back in
+* prepare_ring() just before we enqueue the TD at the top of
+* the ring.
 */
-   while (last_trb(ring, ring-enq_seg, next)) {
-   if (ring-type != TYPE_EVENT) {
-   /*
-* If the caller doesn't plan on enqueueing more
-* TDs before ringing the doorbell, then we
-* don't want to give the link TRB to the
-* hardware just yet.  We'll give the link TRB
-* back in prepare_ring() just before we enqueue
-* the TD at the top of the ring.
-*/
-   if (!chain  !more_trbs_coming)
-   break;
+   if (!chain  !more_trbs_coming)
+   return;
+   advance_enq(ring, chain, do_carry_chain);
+}
 
-   /* If we're not dealing with 0.95 hardware or
-* isoc rings on AMD 0.96 host,
-* carry over the chain bit of the previous TRB

[RFC PATCH 12/20] xhci: introduce struct xhci_ring_pointer

[Dan Williams]

Consolidate ring pointer tracking variables into their own type.  This
simplifies the calling convention of some routines and allows for the
later introduction of integer ring index variables.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-dbg.c  |8 +
 drivers/usb/host/xhci-mem.c  |   26 ++--
 drivers/usb/host/xhci-ring.c |  306 +++---
 drivers/usb/host/xhci.c  |   32 ++--
 drivers/usb/host/xhci.h  |   55 +---
 5 files changed, 201 insertions(+), 226 deletions(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 19a6037257c3..f1230629978c 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -330,12 +330,12 @@ void xhci_dbg_ring_ptrs(struct xhci_hcd *xhci, struct 
xhci_ring *ring)
 {
dma_addr_t dma;
 
-   dma = xhci_trb_virt_to_dma(ring-deq_seg, xhci_ring_dequeue(ring));
+   dma = xhci_trb_virt_to_dma(ring-deq);
xhci_dbg(xhci, Ring deq = %p (virt), %pad (dma)\n,
xhci_ring_dequeue(ring), dma);
xhci_dbg(xhci, Ring deq updated %u times\n,
ring-deq_updates);
-   dma = xhci_trb_virt_to_dma(ring-enq_seg, xhci_ring_enqueue(ring));
+   dma = xhci_trb_virt_to_dma(ring-enq);
xhci_dbg(xhci, Ring enq = %p (virt), %pad (dma)\n,
xhci_ring_enqueue(ring), dma);
xhci_dbg(xhci, Ring enq updated %u times\n,
@@ -379,7 +379,7 @@ void xhci_dbg_ep_rings(struct xhci_hcd *xhci,
ring = ep-stream_info-stream_rings[i];
xhci_dbg(xhci, Dev %d endpoint %d stream ID %d:\n,
slot_id, ep_index, i);
-   xhci_debug_segment(xhci, ring-deq_seg);
+   xhci_debug_segment(xhci, ring-deq.seg);
}
} else {
ring = ep-ring;
@@ -387,7 +387,7 @@ void xhci_dbg_ep_rings(struct xhci_hcd *xhci,
return;
xhci_dbg(xhci, Dev %d endpoint ring %d:\n,
slot_id, ep_index);
-   xhci_debug_segment(xhci, ring-deq_seg);
+   xhci_debug_segment(xhci, ring-deq.seg);
}
 }
 
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index e0b459441807..452aa75a096c 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -107,7 +107,7 @@ static void xhci_link_rings(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
 
new_tail = list_last_entry(segments, typeof(*new_tail), list);
new_head = list_first_entry(segments, typeof(*new_head), list);
-   insert_head = ring-enq_seg;
+   insert_head = ring-enq.seg;
insert_next = xhci_segment_next(ring, insert_head);
 
/* link them physically */
@@ -259,12 +259,12 @@ static void xhci_initialize_ring_info(struct xhci_ring 
*ring,
unsigned int cycle_state)
 {
struct xhci_segment *first_seg = xhci_ring_first_seg(ring);
+   struct xhci_ring_pointer enq = { first_seg, first_seg-trbs };
 
/* The ring is empty, so the enqueue pointer == dequeue pointer */
-   xhci_ring_set_enqueue(ring, first_seg-trbs);
-   ring-enq_seg = first_seg;
-   xhci_ring_set_dequeue(ring, xhci_ring_enqueue(ring));
-   ring-deq_seg = first_seg;
+   xhci_ring_set_enqueue(ring, enq);
+   xhci_ring_set_dequeue(ring, enq);
+
/* The ring is initialized to 0. The producer must write 1 to the cycle
 * bit to handover ownership of the TRB, so PCS = 1.  The consumer must
 * compare CCS to the cycle bit to check ownership, so CCS = 1.
@@ -753,7 +753,7 @@ void xhci_setup_no_streams_ep_input_ctx(struct xhci_hcd 
*xhci,
dma_addr_t addr;
 
ep_ctx-ep_info = cpu_to_le32(~(EP_MAXPSTREAMS_MASK | EP_HAS_LSA));
-   addr = xhci_trb_virt_to_dma(ring-deq_seg, xhci_ring_dequeue(ring));
+   addr = xhci_trb_virt_to_dma(ring-deq);
ep_ctx-deq  = cpu_to_le64(addr | ep-ring-cycle_state);
 }
 
@@ -1015,8 +1015,7 @@ void xhci_copy_ep0_dequeue_into_input_ctx(struct xhci_hcd 
*xhci,
 * configured device has reset, so all control transfers should have
 * been completed or cancelled before the reset.
 */
-   ep0_ctx-deq = cpu_to_le64(xhci_trb_virt_to_dma(ep_ring-enq_seg,
-   xhci_ring_enqueue(ep_ring))
+   ep0_ctx-deq = cpu_to_le64(xhci_trb_virt_to_dma(ep_ring-enq)
| ep_ring-cycle_state);
 }
 
@@ -1859,11 +1858,13 @@ static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
unsigned long long start_dma;
unsigned long long end_dma;
struct xhci_segment *seg;
+   struct xhci_ring_pointer start_rp = { input_seg, start_trb };
+   struct xhci_ring_pointer end_rp = { input_seg, end_trb };
 
-   start_dma = xhci_trb_virt_to_dma(input_seg, start_trb);
-   end_dma

[RFC PATCH 13/20] xhci: use %pad for printing dma_addr_t

[Dan Williams]

Clean up verbose (unsigned long long) casts.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-dbg.c   |   70 -
 drivers/usb/host/xhci-mem.c   |   46 ---
 drivers/usb/host/xhci-ring.c  |   41 +++-
 drivers/usb/host/xhci-trace.h |8 ++---
 drivers/usb/host/xhci.c   |   19 +--
 5 files changed, 79 insertions(+), 105 deletions(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index f1230629978c..8789d930f517 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -425,10 +425,8 @@ static void dbg_rsvd64(struct xhci_hcd *xhci, u64 *ctx, 
dma_addr_t dma)
 {
int i;
for (i = 0; i  4; ++i) {
-   xhci_dbg(xhci, @%p (virt) @%08llx 
-(dma) %#08llx - rsvd64[%d]\n,
-ctx[4 + i], (unsigned long long)dma,
-ctx[4 + i], i);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08llx - rsvd64[%d]\n,
+   ctx[4 + i], dma, ctx[4 + i], i);
dma += 8;
}
 }
@@ -464,25 +462,21 @@ static void xhci_dbg_slot_ctx(struct xhci_hcd *xhci, 
struct xhci_container_ctx *
int csz = HCC_64BYTE_CONTEXT(xhci-hcc_params);
 
xhci_dbg(xhci, Slot Context:\n);
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - dev_info\n,
-   slot_ctx-dev_info,
-   (unsigned long long)dma, slot_ctx-dev_info);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08x - dev_info\n,
+   slot_ctx-dev_info, dma, slot_ctx-dev_info);
dma += field_size;
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - dev_info2\n,
-   slot_ctx-dev_info2,
-   (unsigned long long)dma, slot_ctx-dev_info2);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08x - dev_info2\n,
+   slot_ctx-dev_info2, dma, slot_ctx-dev_info2);
dma += field_size;
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - tt_info\n,
-   slot_ctx-tt_info,
-   (unsigned long long)dma, slot_ctx-tt_info);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08x - tt_info\n,
+   slot_ctx-tt_info, dma, slot_ctx-tt_info);
dma += field_size;
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - dev_state\n,
-   slot_ctx-dev_state,
-   (unsigned long long)dma, slot_ctx-dev_state);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08x - dev_state\n,
+   slot_ctx-dev_state, dma, slot_ctx-dev_state);
dma += field_size;
for (i = 0; i  4; ++i) {
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - rsvd[%d]\n,
-   slot_ctx-reserved[i], (unsigned long long)dma,
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08x - rsvd[%d]\n,
+   slot_ctx-reserved[i], dma,
slot_ctx-reserved[i], i);
dma += field_size;
}
@@ -512,26 +506,21 @@ static void xhci_dbg_ep_ctx(struct xhci_hcd *xhci,
xhci_dbg(xhci, %s Endpoint %02d Context (ep_index %02d):\n,
usb_endpoint_out(epaddr) ? OUT : IN,
epaddr  USB_ENDPOINT_NUMBER_MASK, i);
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - ep_info\n,
-   ep_ctx-ep_info,
-   (unsigned long long)dma, ep_ctx-ep_info);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08x - ep_info\n,
+   ep_ctx-ep_info, dma, ep_ctx-ep_info);
dma += field_size;
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - ep_info2\n,
-   ep_ctx-ep_info2,
-   (unsigned long long)dma, ep_ctx-ep_info2);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08x - ep_info2\n,
+   ep_ctx-ep_info2, dma, ep_ctx-ep_info2);
dma += field_size;
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08llx - deq\n,
-   ep_ctx-deq,
-   (unsigned long long)dma, ep_ctx-deq);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08llx - deq\n,
+   ep_ctx-deq, dma, ep_ctx-deq);
dma += 2*field_size;
-   xhci_dbg(xhci, @%p (virt) @%08llx (dma) %#08x - tx_info\n,
-   ep_ctx-tx_info,
-   (unsigned long long)dma, ep_ctx-tx_info);
+   xhci_dbg(xhci, @%p (virt) @%pad (dma) %#08x - tx_info\n,
+   ep_ctx-tx_info, dma, ep_ctx-tx_info);
dma += field_size;
for (j = 0; j  3; ++j

[RFC PATCH 09/20] xhci: introduce ring ops to handle event vs non-event rings

[Dan Williams]

It's confusing (to me at least) to keep on remembering the differences
between event rings (managed by the hardware) and non-event rings
managed by the host.  Replace if (ring-type == FOO) branches with
ring ops that are specific to the type of ring.

This is a tradeoff of direct code readability vs isolation and better
readability of diffs (i.e. diff-context will now explicitly identify the
ring type).

It promotes quirky rings to their own type in that they have their own
distinct ring ops, as a result we no longer need to pass 'xhci' to
queue_trb().

Finally, this is a preparation for xhci1.0+ ring handling which will
have it's own ring ops.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-mem.c  |   63 ++---
 drivers/usb/host/xhci-ring.c |  306 +-
 drivers/usb/host/xhci.h  |   28 +++-
 3 files changed, 252 insertions(+), 145 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ad682731153f..cfc7acc6482d 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -96,36 +96,6 @@ static void xhci_free_segments(struct list_head *segments)
 }
 
 /*
- * Change the last TRB in the prev segment to be a Link TRB which points to the
- * DMA address of the next segment.  The caller needs to set any Link TRB
- * related flags, such as End TRB, Toggle Cycle, and no snoop.
- */
-static void xhci_link_segments(struct xhci_hcd *xhci, struct xhci_segment 
*prev,
-   struct xhci_segment *next, enum xhci_ring_type type)
-{
-   u32 val;
-
-   if (!prev || !next)
-   return;
-   if (type != TYPE_EVENT) {
-   prev-link = prev-trbs[TRBS_PER_SEGMENT-1];
-   prev-link-link.segment_ptr = cpu_to_le64(next-dma);
-
-   /* Set the last TRB in the segment to have a TRB type ID of 
Link TRB */
-   val = le32_to_cpu(prev-link-link.control);
-   val = ~TRB_TYPE_BITMASK;
-   val |= TRB_TYPE(TRB_LINK);
-   /* Always set the chain bit with 0.95 hardware */
-   /* Set chain bit for isoc rings on AMD 0.96 host */
-   if (xhci_link_trb_quirk(xhci) ||
-   (type == TYPE_ISOC 
-(xhci-quirks  XHCI_AMD_0x96_HOST)))
-   val |= TRB_CHAIN;
-   prev-link-link.control = cpu_to_le32(val);
-   }
-}
-
-/*
  * Link the ring to the new segments.
  * Set Toggle Cycle for the new ring if needed.
  */
@@ -141,8 +111,8 @@ static void xhci_link_rings(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
insert_next = xhci_segment_next(ring, insert_head);
 
/* link them physically */
-   xhci_link_segments(xhci, insert_head, new_head, ring-type);
-   xhci_link_segments(xhci, new_tail, insert_next, ring-type);
+   ring-ops-link_segments(insert_head, new_head);
+   ring-ops-link_segments(new_tail, insert_next);
 
/* link them logically */
list_splice_init(segments, insert_head-list);
@@ -150,7 +120,8 @@ static void xhci_link_rings(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
ring-num_segs += num_segs;
ring-num_trbs_free += (TRBS_PER_SEGMENT - 1) * num_segs;
 
-   if (ring-type != TYPE_EVENT  insert_head == last_seg) {
+   BUG_ON(xhci_is_event_ring(ring));
+   if (insert_head == last_seg) {
last_seg-link-link.control = ~cpu_to_le32(LINK_TOGGLE);
new_tail-link-link.control |= cpu_to_le32(LINK_TOGGLE);
}
@@ -276,7 +247,7 @@ void xhci_ring_free(struct xhci_ring *ring)
return;
 
if (!list_empty(ring-segments)) {
-   if (ring-type == TYPE_STREAM)
+   if (ring-is_stream)
xhci_remove_stream_mapping(ring);
xhci_free_segments(ring-segments);
}
@@ -316,7 +287,8 @@ static void xhci_initialize_ring_info(struct xhci_ring 
*ring,
 /* Allocate segments and link them for a ring */
 static int xhci_alloc_segments_for_ring(struct xhci_hcd *xhci,
struct list_head *segments, unsigned int num_segs,
-   unsigned int cycle_state, enum xhci_ring_type type, gfp_t flags)
+   unsigned int cycle_state, const struct xhci_ring_ops *ops,
+   gfp_t flags)
 {
struct xhci_segment *seg;
int i;
@@ -338,7 +310,7 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd 
*xhci,
 
if (next-list == segments)
next = list_first_entry(segments, typeof(*next), list);
-   xhci_link_segments(xhci, seg, next, type);
+   ops-link_segments(seg, next);
}
 
return 0;
@@ -362,20 +334,20 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd 
*xhci,
if (!ring)
return NULL;
 
+   xhci_ring_init_type(xhci, ring, type);
ring-num_segs = num_segs

[RFC PATCH 00/20] xhci: implement xhci-v1+ td-fragment rules, test

[Dan Williams]

Sending as an RFC primarily to get feedback on the unit testing approach
while there's still time to yell at me in person at LinuxCon.  Including
Rusty in pursuit of comments on how to do mocked interfaces for testing
purposes in-tree.

===

This series updates the xhci driver to honor all the rules specified in
section 4.11.7.1 of the xhci specification (v1.1).  See the changelog
for patch 19 for more background.

Patches 1-18 are cleanups, fixes, and smaller ring geometry changes to
support patches 19 and 20.  If you only review one of these patches
please review patch 20 (xhci: unit test ring enqueue/dequeue routines)
to see the current passing test cases and please do propose additional
ones.  As it stands Sarah would like, and I agree, that we need a
cancellation unit test before proposing this for inclusion.

The current unit test is passing as well as basic verification with a
SuperSpeed USB Mass Storage device.  Testing with known problematic
devices is requested / required before this is ready for upstream.

Note the comment in v1_inc_deq() in patch 19.

/*
 * ep_inc_deq() lets the dequeue-pointer (deq/tail) wrap the
 * enqueue-pointer (enq/head)!  However, since room_on_ring() looks at
 * -num_trbs_free instead of the position of the ring pointers, it
 * never causes a problem as enq gets back in line with deq at the next
 * submission.
 *
 * In the case of v1+ rings, conditional_expand() is sensitive to this
 * wrap and prematurely expands the ring.  Prevent that condition by
 * stopping once deq == enq.  Eventually, -num_trbs_free should be
 * deprecated entirely in favor of just comparing the ring pointers.
 * For now, for legacy compatibility, we leave well enough alone and
 * limit this to xhci-v1+ implementations.
 */

I'm wondering if this is the root cause behind the set ring dequeue
pointer problem reported by Julius [1]?  I'll be taking a closer look
at that as I revise this series.

[1]: http://marc.info/?l=linux-usbm=140484618509288w=2

Finally, note that this conversion should be a nop for xhci hosts prior
to v1.0 as the old enqueue scheme is preserved.  I'm taking this
approach to limit bug hunting diversions on older hosts.  If anyone has
a pre-1.0 host, test reports are appreciated to verify that it indeed
does not break those hosts.

---

For testing convenience these patches are available via git at:

  git://git.kernel.org/pub/scm/linux/kernel/git/djbw/usb td-fragments-v1

Note that this branch may be rebased and/or abandoned (in favor of a
td-fragments-v2+) as the set is revised.

Dan Williams (20):
  xhci: cleanup remaining cycle bit toggles via ternary conditional
  xhci: remove invalid cast of xhci to a usb_device in xhci_log_ctx trace
  xhci: introduce xhci_to_dev
  xhci: increase trb segment size, kill -segment_pool
  xhci: prepare for mid-segment link-trbs
  xhci: drop 'xhci' argument to last_trb
  xhci: make xhci_segments doubly linked
  xhci: refactor inc_enq(), share a common advance_enq() with prepare_ring()
  xhci: introduce ring ops to handle event vs non-event rings
  xhci: clarify ring valid checks
  xhci: provide helpers for retrieving 'enqueue' and 'dequeue' pointers
  xhci: introduce struct xhci_ring_pointer
  xhci: use %pad for printing dma_addr_t
  xhci: power-of-2 ring sizes
  xhci: kill -num_trbs_free_temp in struct xhci_ring
  xhci: refactor prepare_transfer()
  xhci: combine xhci_queue_bulk_tx() and queue_bulk_sg_tx()
  xhci: add xhci_ring_reap_td() helper
  xhci: v1.0 scatterlist enqueue support (td-fragment rework)
  xhci: unit test ring enqueue/dequeue routines


 drivers/usb/host/Kconfig|   13 
 drivers/usb/host/Makefile   |1 
 drivers/usb/host/xhci-dbg.c |   97 +-
 drivers/usb/host/xhci-hub.c |5 
 drivers/usb/host/xhci-mem.c |  580 +-
 drivers/usb/host/xhci-ring.c| 1638 ++-
 drivers/usb/host/xhci-trace.h   |   13 
 drivers/usb/host/xhci.c |   82 +
 drivers/usb/host/xhci.h |  230 +++-
 drivers/usb/host/xhcitest/Makefile  |   35 +
 drivers/usb/host/xhcitest/xhci-trace.h  |   96 ++
 drivers/usb/host/xhcitest/xhci-unit-dbg.c   |1 
 drivers/usb/host/xhcitest/xhci-unit-trace.c |2 
 drivers/usb/host/xhcitest/xhci-unit.c   |  641 +++
 14 files changed, 2457 insertions(+), 977 deletions(-)
 create mode 100644 drivers/usb/host/xhcitest/Makefile
 create mode 100644 drivers/usb/host/xhcitest/xhci-trace.h
 create mode 100644 drivers/usb/host/xhcitest/xhci-unit-dbg.c
 create mode 100644 drivers/usb/host/xhcitest/xhci-unit-trace.c
 create mode 100644 drivers/usb/host/xhcitest/xhci-unit.c
--
To unsubscribe from this list: send the line unsubscribe linux

[RFC PATCH 10/20] xhci: clarify ring valid checks

[Dan Williams]

All rings have -dequeue = -enqueue = first trb in first segment, so
it is redundant to check if -dequeue is NULL when -ring is set.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-hub.c  |5 ++---
 drivers/usb/host/xhci-ring.c |2 +-
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index aa79e8749040..b01778002be2 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -285,7 +285,7 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
slot_id, int suspend)
 
spin_lock_irqsave(xhci-lock, flags);
for (i = LAST_EP_INDEX; i  0; i--) {
-   if (virt_dev-eps[i].ring  virt_dev-eps[i].ring-dequeue) {
+   if (virt_dev-eps[i].ring) {
struct xhci_command *command;
command = xhci_alloc_command(xhci, false, false,
 GFP_NOWAIT);
@@ -322,8 +322,7 @@ void xhci_ring_device(struct xhci_hcd *xhci, int slot_id)
int i;
 
for (i = 0; i  LAST_EP_INDEX + 1; i++)
-   if (xhci-devs[slot_id]-eps[i].ring 
-   xhci-devs[slot_id]-eps[i].ring-dequeue)
+   if (xhci-devs[slot_id]-eps[i].ring)
xhci_ring_ep_doorbell(xhci, slot_id, i, 0);
 
return;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 8a46c99c6ba5..61c48ed4db9b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2767,7 +2767,7 @@ static int xhci_handle_event(struct xhci_hcd *xhci)
int update_ptrs = 1;
int ret;
 
-   if (!xhci-event_ring || !xhci-event_ring-dequeue) {
+   if (!xhci-event_ring) {
xhci-error_bitmask |= 1  1;
return 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

[RFC PATCH 17/20] xhci: combine xhci_queue_bulk_tx() and queue_bulk_sg_tx()

[Dan Williams]

The only difference between these two routines is that the latter
handles a scatterlist of more than one entry.  Fake a single entry
scatterlist for the non-sg case, and delete the duplicate code.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-ring.c |  158 +-
 1 files changed, 19 insertions(+), 139 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 3a9ed6543dfe..ed42704f68ad 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3044,17 +3044,15 @@ static int prepare_transfer(struct xhci_hcd *xhci,
return prepare_td(ep_ring, urb, td_index);
 }
 
-static unsigned int count_sg_trbs_needed(struct xhci_hcd *xhci, struct urb 
*urb)
+static unsigned int count_sg_trbs_needed(struct xhci_hcd *xhci,
+   struct urb *urb, struct scatterlist *sgl, int num_sgs)
 {
-   int num_sgs, num_trbs, running_total, temp, i;
+   int num_trbs, running_total, temp, i;
struct scatterlist *sg;
 
-   sg = NULL;
-   num_sgs = urb-num_mapped_sgs;
temp = urb-transfer_buffer_length;
-
num_trbs = 0;
-   for_each_sg(urb-sg, sg, num_sgs, i) {
+   for_each_sg(sgl, sg, num_sgs, i) {
unsigned int len = sg_dma_len(sg);
 
/* Scatter gather list entries may cross 64KB boundaries */
@@ -3198,15 +3196,15 @@ static u32 xhci_v1_0_td_remainder(int running_total, 
int trb_buff_len,
 }
 
 static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
-   struct urb *urb, int slot_id, unsigned int ep_index)
+   struct urb *urb, struct scatterlist *sgl, int num_sgs,
+   int slot_id, unsigned int ep_index)
 {
struct xhci_ring *ep_ring;
unsigned int num_trbs;
struct urb_priv *urb_priv;
struct xhci_td *td;
-   struct scatterlist *sg;
-   int num_sgs;
int trb_buff_len, this_sg_len, running_total;
+   struct scatterlist *sg = sgl;
unsigned int total_packet_count;
bool first_trb;
u64 addr;
@@ -3218,8 +3216,7 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t 
mem_flags,
if (!ep_ring)
return -EINVAL;
 
-   num_trbs = count_sg_trbs_needed(xhci, urb);
-   num_sgs = urb-num_mapped_sgs;
+   num_trbs = count_sg_trbs_needed(xhci, urb, sgl, num_sgs);
total_packet_count = DIV_ROUND_UP(urb-transfer_buffer_length,
usb_endpoint_maxp(urb-ep-desc));
 
@@ -3250,7 +3247,6 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t 
mem_flags,
 *the amount of memory allocated for this scatter-gather list.
 * 3. TRBs buffers can't cross 64KB boundaries.
 */
-   sg = urb-sg;
addr = (u64) sg_dma_address(sg);
this_sg_len = sg_dma_len(sg);
trb_buff_len = TRB_MAX_BUFF_SIZE - (addr  (TRB_MAX_BUFF_SIZE - 1));
@@ -3349,140 +3345,24 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, 
gfp_t mem_flags,
return 0;
 }
 
-/* This is very similar to what ehci-q.c qtd_fill() does */
 int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
struct urb *urb, int slot_id, unsigned int ep_index)
 {
-   struct xhci_ring *ep_ring;
-   struct urb_priv *urb_priv;
-   struct xhci_td *td;
-   int num_trbs;
-   bool first_trb;
-   bool more_trbs_coming;
-   int start_cycle;
-   u32 field, length_field;
-   union xhci_trb *start_trb;
-   int running_total, trb_buff_len, ret;
-   unsigned int total_packet_count;
-   u64 addr;
-
if (urb-num_sgs)
-   return queue_bulk_sg_tx(xhci, mem_flags, urb, slot_id, 
ep_index);
+   return queue_bulk_sg_tx(xhci, mem_flags, urb, urb-sg,
+   urb-num_mapped_sgs, slot_id, ep_index);
+   else {
+   struct scatterlist scatter, *sg = scatter;
 
-   ep_ring = xhci_urb_to_transfer_ring(xhci, urb);
-   if (!ep_ring)
-   return -EINVAL;
-
-   num_trbs = 0;
-   /* How much data is (potentially) left before the 64KB boundary? */
-   running_total = TRB_MAX_BUFF_SIZE -
-   (urb-transfer_dma  (TRB_MAX_BUFF_SIZE - 1));
-   running_total = TRB_MAX_BUFF_SIZE - 1;
+   sg_init_table(sg, 1);
+   sg_set_buf(sg, urb-transfer_buffer,
+   urb-transfer_buffer_length);
+   sg-dma_address = urb-transfer_dma;
+   sg_dma_len(sg) = sg-length;
 
-   /* If there's some data on this 64KB chunk, or we have to send a
-* zero-length transfer, we need at least one TRB
-*/
-   if (running_total != 0 || urb-transfer_buffer_length == 0)
-   num_trbs++;
-   /* How many more 64KB chunks to transfer, how many more TRBs? */
-   while (running_total  urb-transfer_buffer_length) {
-   num_trbs

[RFC PATCH 16/20] xhci: refactor prepare_transfer()

[Dan Williams]

In preparation for honoring xhci-v1.0+ td-fragment handling rules break
out the subroutines of prepare_transfer().  Rather than calculating the
number of trbs required and expanding the ring, v1.0+ hosts will
dynamically resize the ring as it discovers td-fragments that end up
straddling a segment boundary.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-ring.c |  122 --
 1 files changed, 70 insertions(+), 52 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 27d271e26445..3a9ed6543dfe 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2920,10 +2920,69 @@ static void queue_trb(struct xhci_ring *ring, bool 
more_trbs_coming,
  * FIXME allocate segments if the ring is full.
  */
 static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
-   u32 ep_state, unsigned int num_trbs, gfp_t mem_flags)
+   unsigned int num_trbs, gfp_t mem_flags)
 {
unsigned int num_trbs_needed;
 
+   while (1) {
+   if (room_on_ring(xhci, ep_ring, num_trbs))
+   break;
+
+   if (ep_ring == xhci-cmd_ring) {
+   xhci_err(xhci, Do not support expand command ring\n);
+   return -ENOMEM;
+   }
+
+   xhci_dbg_trace(xhci, trace_xhci_dbg_ring_expansion,
+   ERROR no room on ep ring, try ring expansion);
+   num_trbs_needed = num_trbs - ep_ring-num_trbs_free;
+   if (xhci_ring_expansion(xhci, ep_ring, num_trbs_needed,
+   mem_flags)) {
+   xhci_err(xhci, Ring expansion failed\n);
+   return -ENOMEM;
+   }
+   }
+
+   if (enqueue_is_link_trb(ep_ring))
+   advance_enq(ep_ring, 0, do_carry_chain(xhci, ep_ring));
+   return 0;
+}
+
+static int prepare_td(struct xhci_ring *ring, struct urb *urb,
+   unsigned int td_index)
+{
+   struct urb_priv *urb_priv;
+   struct xhci_td *td;
+
+   urb_priv = urb-hcpriv;
+   td = urb_priv-td[td_index];
+
+   INIT_LIST_HEAD(td-td_list);
+   INIT_LIST_HEAD(td-cancelled_td_list);
+
+   if (td_index == 0) {
+   struct usb_hcd *hcd = bus_to_hcd(urb-dev-bus);
+   int ret = usb_hcd_link_urb_to_ep(hcd, urb);
+
+   if (ret)
+   return ret;
+   }
+
+   td-urb = urb;
+   /* Add this TD to the tail of the endpoint ring's TD list */
+   list_add_tail(td-td_list, ring-td_list);
+   td-start_seg = ring-enq.seg;
+   td-first_trb = xhci_ring_enqueue(ring);
+   urb_priv-td[td_index] = td;
+
+   return 0;
+}
+
+static int check_ep_submit_state(struct xhci_hcd *xhci,
+   struct xhci_ep_ctx *ep_ctx)
+{
+   u32 ep_state = le32_to_cpu(ep_ctx-ep_info)  EP_STATE_MASK;
+
/* Make sure the endpoint has been added to xHC schedule */
switch (ep_state) {
case EP_STATE_DISABLED:
@@ -2951,28 +3010,6 @@ static int prepare_ring(struct xhci_hcd *xhci, struct 
xhci_ring *ep_ring,
 */
return -EINVAL;
}
-
-   while (1) {
-   if (room_on_ring(xhci, ep_ring, num_trbs))
-   break;
-
-   if (ep_ring == xhci-cmd_ring) {
-   xhci_err(xhci, Do not support expand command ring\n);
-   return -ENOMEM;
-   }
-
-   xhci_dbg_trace(xhci, trace_xhci_dbg_ring_expansion,
-   ERROR no room on ep ring, try ring expansion);
-   num_trbs_needed = num_trbs - ep_ring-num_trbs_free;
-   if (xhci_ring_expansion(xhci, ep_ring, num_trbs_needed,
-   mem_flags)) {
-   xhci_err(xhci, Ring expansion failed\n);
-   return -ENOMEM;
-   }
-   }
-
-   if (enqueue_is_link_trb(ep_ring))
-   advance_enq(ep_ring, 0, do_carry_chain(xhci, ep_ring));
return 0;
 }
 
@@ -2986,8 +3023,6 @@ static int prepare_transfer(struct xhci_hcd *xhci,
gfp_t mem_flags)
 {
int ret;
-   struct urb_priv *urb_priv;
-   struct xhci_td  *td;
struct xhci_ring *ep_ring;
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci, xdev-out_ctx, 
ep_index);
 
@@ -2998,33 +3033,15 @@ static int prepare_transfer(struct xhci_hcd *xhci,
return -EINVAL;
}
 
-   ret = prepare_ring(xhci, ep_ring,
-  le32_to_cpu(ep_ctx-ep_info)  EP_STATE_MASK,
-  num_trbs, mem_flags);
+   ret = check_ep_submit_state(xhci, ep_ctx);
if (ret)
return ret;
 
-   urb_priv = urb-hcpriv;
-   td = urb_priv-td[td_index];
-
-   INIT_LIST_HEAD(td-td_list

[RFC PATCH 18/20] xhci: add xhci_ring_reap_td() helper

[Dan Williams]

TDs from endpoint rings are open-coded cleaned up in a duplicate fashion
in two places.  Provide common helper.  This is later used to as a place
to inject ring-type-specific post-reap operations.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-ring.c |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ed42704f68ad..ef9d58039666 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1962,6 +1962,13 @@ int xhci_is_vendor_info_code(struct xhci_hcd *xhci, 
unsigned int trb_comp_code)
return 0;
 }
 
+static void xhci_ring_reap_td(struct xhci_ring *ep_ring, struct xhci_td *td)
+{
+   while (xhci_ring_dequeue(ep_ring) != td-last_trb)
+   xhci_ring_inc_deq(ep_ring);
+   xhci_ring_inc_deq(ep_ring);
+}
+
 /*
  * Finish the td processing, remove the td from td list;
  * Return 1 if the urb can be given back.
@@ -2020,10 +2027,7 @@ static int finish_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
slot_id, ep_index, ep_ring-stream_id,
td, event_trb);
} else {
-   /* Update ring dequeue pointer */
-   while (xhci_ring_dequeue(ep_ring) != td-last_trb)
-   xhci_ring_inc_deq(ep_ring);
-   xhci_ring_inc_deq(ep_ring);
+   xhci_ring_reap_td(ep_ring, td);
}
 
 td_cleanup:
@@ -2272,10 +2276,7 @@ static int skip_isoc_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
/* calc actual length */
frame-actual_length = 0;
 
-   /* Update ring dequeue pointer */
-   while (xhci_ring_dequeue(ep_ring) != td-last_trb)
-   xhci_ring_inc_deq(ep_ring);
-   xhci_ring_inc_deq(ep_ring);
+   xhci_ring_reap_td(ep_ring, td);
 
return finish_td(xhci, td, NULL, event, ep, status, true);
 }

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

[RFC PATCH 14/20] xhci: power-of-2 ring sizes

[Dan Williams]

In preparation for dynamic ring expansion while walking scatterlists for
v1.0+ xhci hosts force the ring sizes to be a power-of-2.  This property
combined with the conversion of segments to a doubly linked list allows
for translating ring pointers to integers enabling simple math to
interrogate the state of the ring.  Beyond determining the amount of
free space in the ring this enables easy to calculate answers to
questions like:

* whether a trb is free or allocated?
* which segment precedes the current segment?
* how many trbs before the enqueue pointer wraps into the same segment
  as the dequeue pointer?

The open coded num_trbs alignment statement in xhci_ring_expansion()
is replaced with the standard ALIGN macro.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-mem.c |   45 ++-
 drivers/usb/host/xhci.c |2 +-
 drivers/usb/host/xhci.h |8 +++-
 3 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b1ba9ec79c88..edaa49798172 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -117,7 +117,6 @@ static void xhci_link_rings(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
/* link them logically */
list_splice_init(segments, insert_head-list);
 
-   ring-num_segs += num_segs;
ring-num_trbs_free += (TRBS_PER_SEGMENT - 1) * num_segs;
 
BUG_ON(xhci_is_event_ring(ring));
@@ -281,7 +280,7 @@ static void xhci_initialize_ring_info(struct xhci_ring 
*ring,
 * Each segment has a link TRB, and leave an extra TRB for SW
 * accounting purpose
 */
-   ring-num_trbs_free = ring-num_segs * (TRBS_PER_SEGMENT - 1) - 1;
+   ring-num_trbs_free = (1  ring-order) * (TRBS_PER_SEGMENT - 1) - 1;
 }
 
 /* Allocate segments and link them for a ring */
@@ -324,7 +323,7 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd 
*xhci,
  * See section 4.9.1 and figures 15 and 16.
  */
 static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
-   unsigned int num_segs, unsigned int cycle_state,
+   unsigned int order, unsigned int cycle_state,
enum xhci_ring_type type, gfp_t flags)
 {
struct xhci_ring *ring;
@@ -335,13 +334,10 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd 
*xhci,
return NULL;
 
xhci_ring_init_type(xhci, ring, type);
-   ring-num_segs = num_segs;
+   ring-order = order;
INIT_LIST_HEAD(ring-segments);
INIT_LIST_HEAD(ring-td_list);
-   if (num_segs == 0)
-   return ring;
-
-   ret = xhci_alloc_segments_for_ring(xhci, ring-segments, num_segs,
+   ret = xhci_alloc_segments_for_ring(xhci, ring-segments, (1  order),
cycle_state, ring-ops, flags);
if (ret)
goto fail;
@@ -425,17 +421,21 @@ static void xhci_reinit_cached_ring(struct xhci_hcd *xhci,
 int xhci_ring_expansion(struct xhci_hcd *xhci, struct xhci_ring *ring,
unsigned int num_trbs, gfp_t flags)
 {
-   unsigned intnum_segs;
-   unsigned intnum_segs_needed;
-   int ret;
+   int ret;
LIST_HEAD(segments);
+   unsigned int num_segs, inc, base;
 
-   num_segs_needed = (num_trbs + (TRBS_PER_SEGMENT - 1) - 1) /
-   (TRBS_PER_SEGMENT - 1);
+   num_segs = ALIGN(num_trbs, TRBS_PER_SEGMENT) / TRBS_PER_SEGMENT;
 
-   /* Allocate number of segments we needed, or double the ring size */
-   num_segs = ring-num_segs  num_segs_needed ?
-   ring-num_segs : num_segs_needed;
+   /*
+* Increase the order to accommodate the number of new segments
+* needed
+*/
+   inc = 1;
+   base = xhci_ring_num_segs(ring);
+   while (((1  (ring-order + inc)) - base)  num_segs)
+   inc++;
+   num_segs = (1  (ring-order + inc)) - base;
 
ret = xhci_alloc_segments_for_ring(xhci, segments,
num_segs, ring-cycle_state, ring-ops, flags);
@@ -451,9 +451,10 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
}
 
xhci_link_rings(xhci, ring, segments, num_segs);
+   ring-order = ilog2((1  ring-order) + num_segs);
xhci_dbg_trace(xhci, trace_xhci_dbg_ring_expansion,
ring expansion succeed, now has %d segments,
-   ring-num_segs);
+   xhci_ring_num_segs(ring));
 
return 0;
 }
@@ -668,7 +669,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct 
xhci_hcd *xhci,
struct xhci_segment *first_seg;
 
stream_info-stream_rings[cur_stream] =
-   xhci_ring_alloc(xhci, 2, 1, TYPE_STREAM, mem_flags);
+   xhci_ring_alloc(xhci, 1, 1, TYPE_STREAM

[RFC PATCH 15/20] xhci: kill -num_trbs_free_temp in struct xhci_ring

[Dan Williams]

This can simply be done inline in xhci_queue_isoc_tx().

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-ring.c |6 +++---
 drivers/usb/host/xhci.h  |1 -
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ed167f17b2d2..27d271e26445 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3672,6 +3672,7 @@ static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, 
gfp_t mem_flags,
struct xhci_ring_pointer rp;
u64 start_addr, addr;
int i, j;
+   unsigned int num_trbs_free_save;
bool more_trbs_coming;
 
ep_ring = xhci-devs[slot_id]-eps[ep_index].ring;
@@ -3687,6 +3688,7 @@ static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, 
gfp_t mem_flags,
start_cycle = ep_ring-cycle_state;
 
urb_priv = urb-hcpriv;
+   num_trbs_free_save = ep_ring-num_trbs_free;
/* Queue the first TRB, even if it's zero-length */
for (i = 0; i  num_tds; i++) {
unsigned int total_packet_count;
@@ -3834,7 +3836,7 @@ cleanup:
rp.ptr = urb_priv-td[0]-first_trb;
xhci_ring_set_enqueue(ep_ring, rp);
ep_ring-cycle_state = start_cycle;
-   ep_ring-num_trbs_free = ep_ring-num_trbs_free_temp;
+   ep_ring-num_trbs_free = num_trbs_free_save;
usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb-dev-bus), urb);
return ret;
 }
@@ -3903,8 +3905,6 @@ int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, 
gfp_t mem_flags,
urb-dev-speed == USB_SPEED_FULL)
urb-interval /= 8;
}
-   ep_ring-num_trbs_free_temp = ep_ring-num_trbs_free;
-
return xhci_queue_isoc_tx(xhci, mem_flags, urb, slot_id, ep_index);
 }
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index c38b10b96898..94c5d74e35b8 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1350,7 +1350,6 @@ struct xhci_ring {
unsigned intstream_id;
unsigned intorder;
unsigned intnum_trbs_free;
-   unsigned intnum_trbs_free_temp;
boollast_td_was_short;
boolis_command;
boolis_stream;

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

[RFC PATCH 19/20] xhci: v1.0 scatterlist enqueue support (td-fragment rework)

[Dan Williams]

v1.0 hosts require that TD-fragments (portions of a TD that do not end
on a MPB boundary) not cross a TRB segment boundary.  This constraint is
in addition to the constraint that a TRB may not specify a transfer that
crosses a 64K boundary. This enabling permits the driver to accept
scatterlists of nearly any geometry.  Nearly because there is one
unlikely remaining degenerate case of a driver submitting a transfer
that consumes all the TRBs in a segment before hitting an MBP boundary.
That case is trapped and the transfer is rejected.

Given the multi-dimensional constraints of queuing TRBs from a
scattelist, this implementation does not attempt to pre-calculate the
number TRBs in a TD.  Instead it attempts a dry-run of enqueuing the
TRBs to the ring.  If it discovers a TD-fragment straddling a segment
boundary it backs up to the last MBP boundary, inserts a link-trb at
that boundary, and restarts enqueuing in the next segment.  A side
effect of not pre-calculating the number of required TRBs is that the
ring is now expanded as the scatterlist is walked, rather than in
prepare_ring().

To simplify the math and forgo the need to track (union xhci_trb *) and
(struct xhci_segment *) pointers, modulo-power-of-2 ring indexes are
used.  A small portion of the patch is adding infrastructure to convert
from a (struct xhci_ring_pointer *) to an integer index.

Glossary of acronyms:
TRB: Transfer Request Buffer, 16-byte xhci-hardware scatterlist entry

TD: Transfer Descriptor, the set of trbs that comprise a transfer

TRB segment: A contiguous allocation of TRBs.  They are of size
  PAGE_SIZE in the xhci driver.  Each segment ends with a link TRB
  pointing to the next segment, but the link trb may appear at any TRB
  boundary in the segment.

Ring: A linked list of segments.

MBP: Max Burst Packet, is the minimum amount of data hardware expects to
  transfer before the end of a segment (assuming the TD spans a segment
  boundary).

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/xhci-mem.c  |   17 +
 drivers/usb/host/xhci-ring.c |  620 +-
 drivers/usb/host/xhci.h  |   75 +
 3 files changed, 695 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index edaa49798172..1fc38ec60c25 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -103,7 +103,8 @@ static void xhci_link_rings(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
struct list_head *segments, unsigned int num_segs)
 {
struct xhci_segment *insert_head, *insert_next, *new_head, *new_tail;
-   struct xhci_segment *last_seg = xhci_ring_last_seg(ring);
+   struct xhci_segment *last_seg = xhci_ring_last_seg(ring), *seg;
+   int i;
 
new_tail = list_last_entry(segments, typeof(*new_tail), list);
new_head = list_first_entry(segments, typeof(*new_head), list);
@@ -124,6 +125,11 @@ static void xhci_link_rings(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
last_seg-link-link.control = ~cpu_to_le32(LINK_TOGGLE);
new_tail-link-link.control |= cpu_to_le32(LINK_TOGGLE);
}
+
+   i = insert_head-segid + 1;
+   seg = insert_head;
+   list_for_each_entry_continue(seg, ring-segments, list)
+   seg-segid = i++;
 }
 
 /*
@@ -257,8 +263,9 @@ void xhci_ring_free(struct xhci_ring *ring)
 static void xhci_initialize_ring_info(struct xhci_ring *ring,
unsigned int cycle_state)
 {
-   struct xhci_segment *first_seg = xhci_ring_first_seg(ring);
+   struct xhci_segment *first_seg = xhci_ring_first_seg(ring), *seg;
struct xhci_ring_pointer enq = { first_seg, first_seg-trbs };
+   int i;
 
/* The ring is empty, so the enqueue pointer == dequeue pointer */
xhci_ring_set_enqueue(ring, enq);
@@ -280,7 +287,11 @@ static void xhci_initialize_ring_info(struct xhci_ring 
*ring,
 * Each segment has a link TRB, and leave an extra TRB for SW
 * accounting purpose
 */
-   ring-num_trbs_free = (1  ring-order) * (TRBS_PER_SEGMENT - 1) - 1;
+   ring-num_trbs_free = xhci_ring_size(ring) - xhci_ring_num_segs(ring) - 
1;
+
+   i = 0;
+   list_for_each_entry(seg, ring-segments, list)
+   seg-segid = i++;
 }
 
 /* Allocate segments and link them for a ring */
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ef9d58039666..82a24ce58c3e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -168,6 +168,40 @@ static void ep_inc_deq(struct xhci_ring *ring)
} while (ring-ops-last_trb(ring, ring-deq));
 }
 
+static void v1_inc_deq(struct xhci_ring *ring)
+{
+   ring-deq_updates++;
+
+   if (!ring-ops-last_trb(ring, ring-deq))
+   ring-num_trbs_free++;
+
+   /*
+* ep_inc_deq() lets the dequeue-pointer (deq/tail) wrap

[RFC PATCH 20/20] xhci: unit test ring enqueue/dequeue routines

[Dan Williams]

Given the complexity of satisfying xhci 1.0+ host trb boundary
constraints, provide a test case that exercises inserting mid-segment
links into a ring.

The linker --wrap= option is used to not pollute the global identifier
space and to make it clear which standard xhci driver routines are being
mocked-up.  The --wrap= option does not come into play when both
xhci-hcd and xhci-test are built-in to the kernel, so namespace
collisions are prevented by excluding xhci-test from the build when
xhci-hcd is built-in.

It's unfortunate that this is an in-kernel test rather than userspace
and that the infrastructure is custom rather than generic.  That said,
it serves its purpose of exercising the corner cases of the scatterlist
parsing implementation in xhci.

Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/host/Kconfig|   13 +
 drivers/usb/host/Makefile   |1 
 drivers/usb/host/xhci-mem.c |2 
 drivers/usb/host/xhci-ring.c|2 
 drivers/usb/host/xhcitest/Makefile  |   35 +
 drivers/usb/host/xhcitest/xhci-trace.h  |   96 
 drivers/usb/host/xhcitest/xhci-unit-dbg.c   |1 
 drivers/usb/host/xhcitest/xhci-unit-trace.c |2 
 drivers/usb/host/xhcitest/xhci-unit.c   |  641 +++
 9 files changed, 793 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/host/xhcitest/Makefile
 create mode 100644 drivers/usb/host/xhcitest/xhci-trace.h
 create mode 100644 drivers/usb/host/xhcitest/xhci-unit-dbg.c
 create mode 100644 drivers/usb/host/xhcitest/xhci-unit-trace.c
 create mode 100644 drivers/usb/host/xhcitest/xhci-unit.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a775501..9ac2b817c7e6 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -24,6 +24,19 @@ config USB_XHCI_HCD
  To compile this driver as a module, choose M here: the
  module will be called xhci-hcd.
 
+config USB_XHCI_TEST
+   tristate xHCI Unit Tests
+   depends on USB_XHCI_HCD!=y
+   depends on !DEBUG_SG
+   ---help---
+ This module runs sanity checks against the xhci ring
+ enqueue/dequeue code.
+
+ It really only makes sense to compile this driver as a module,
+ and only load it when doing xhci driver development.
+
+ Choose M to compile this driver as a module named xhci_test.
+
 if USB_XHCI_HCD
 
 config USB_XHCI_PLATFORM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 144c038ef70f..715c0011a792 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PXA27X) += ohci-pxa27x.o
 obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
 obj-$(CONFIG_USB_XHCI_HCD) += xhci-hcd.o
+obj-$(CONFIG_USB_XHCI_TEST)+= xhcitest/
 obj-$(CONFIG_USB_SL811_HCD)+= sl811-hcd.o
 obj-$(CONFIG_USB_SL811_CS) += sl811_cs.o
 obj-$(CONFIG_USB_U132_HCD) += u132-hcd.o
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1fc38ec60c25..febcbbac980e 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -526,6 +526,7 @@ struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd 
*xhci,
(ctx-bytes + CTX_SIZE(xhci-hcc_params));
 }
 
+#ifndef XHCI_UNIT
 struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci,
struct xhci_container_ctx *ctx,
unsigned int ep_index)
@@ -538,6 +539,7 @@ struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci,
return (struct xhci_ep_ctx *)
(ctx-bytes + (ep_index * CTX_SIZE(xhci-hcc_params)));
 }
+#endif
 
 
 /* Streams structures manipulation */
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 82a24ce58c3e..13f42ff9f55a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -536,6 +536,7 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
return 0;
 }
 
+#ifndef XHCI_UNIT
 void xhci_ring_ep_doorbell(struct xhci_hcd *xhci,
unsigned int slot_id,
unsigned int ep_index,
@@ -560,6 +561,7 @@ void xhci_ring_ep_doorbell(struct xhci_hcd *xhci,
 * write-posting flush.  It'll get there soon enough.
 */
 }
+#endif
 
 /* Ring the doorbell for any rings with pending URBs */
 static void ring_doorbell_for_active_rings(struct xhci_hcd *xhci,
diff --git a/drivers/usb/host/xhcitest/Makefile 
b/drivers/usb/host/xhcitest/Makefile
new file mode 100644
index ..b60009b220e8
--- /dev/null
+++ b/drivers/usb/host/xhcitest/Makefile
@@ -0,0 +1,35 @@
+CFLAGS_xhci-unit-trace.o := -I$(src)
+
+# Boilplate wrappers for functions defined in xhci.c (not included)
+ldflags-y := --wrap=xhci_find_slot_id_by_port
+ldflags-y += --wrap

Re: [RFC PATCH 19/20] xhci: v1.0 scatterlist enqueue support (td-fragment rework)

[Dan Williams]

On Fri, Aug 22, 2014 at 10:57 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Fri, 22 Aug 2014, Dan Williams wrote:

 v1.0 hosts require that TD-fragments (portions of a TD that do not end
 on a MPB boundary) not cross a TRB segment boundary.  This constraint is
 in addition to the constraint that a TRB may not specify a transfer that
 crosses a 64K boundary. This enabling permits the driver to accept
 scatterlists of nearly any geometry.  Nearly because there is one
 unlikely remaining degenerate case of a driver submitting a transfer
 that consumes all the TRBs in a segment before hitting an MBP boundary.
 That case is trapped and the transfer is rejected.

 That last part sounds problematic.  The issue will arise at
 unpredictable times, depending on the lengths of the scatterlists that
 have been submitted in the past, so it's not easily reproducible.  What
 is the caller supposed to do when this happens?

 As for the likelihood of this occurring...  A ring segment is one page,
 so 4096 bytes.  Each TRB is 16 bytes, so a segment can hold 256 TRBs.
 With a bulk maxpacket size of 1024 and a (typical?) maxburst size of 8,
 MPB boundaries occur every 8192 bytes.  Therefore if a scatterlist
 contains more than 256 entries, with an average length  32 bytes, it
 is likely trigger this condition (depending on the exact alignment with
 respect to the MPB boundary).  I don't know exactly how unlikely such a
 situation is, but it's not hard to imagine a network packet composed of
 lots of little pieces.

 Instead of failing the submission, we ought to set up some sort of
 bounce buffers.  I have no good suggestions on how to implement that,
 however.

Yes.  I was hoping to cross that bridge when we come to it.
Currently, we silently send something down that the hardware can't
handle, so at least it's caught and reported.

Bounce buffers... or urb splitting... but yes I have no idea how
frequent something pathological like this gets sent down all in one
urb.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net/usb/hso: Add support for Option GTM671WFS

[Dan Williams]

On Tue, 2014-08-05 at 08:59 +0200, Ricardo Ribalda Delgado wrote:
 Hello Dan.
 
 I have also been able to start/stop the gps via the gps control port
 (ttyHS2) and get nmea data port through the gps port. (ttyHS1)
 
 Please tell me if you need more tests

No, this looks good enough.  Because (a) 'hsotype' is valid for the
ports and (b) we get the hso0 net device and (c) you can get an IP
address on that interface, then this device should definitely be driven
by 'hso' and not option.  I'll ack the hso patch.

Dan


 Regards!
 
 root@qt5022:~# cat /sys/class/tty/*/hsotype
 Diagnostic
 GPS
 GPS Control
 Application
 Control
 Modem
 root@qt5022:~# hso_connect up
 Using /etc/conninfo.ini as connection file
 Using /dev/ttyHS3 application port.
 Initializing...
 Trying internet ...
 Connecting...
 trying
 Connected
 Setting IP address to  10.198.XXX.115
 Adding route
 Done.
 root@qt5022:~# ifconfig hso0
 hso0  Link encap:UNSPEC  HWaddr
 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
   inet addr:10.198.XXX.115  P-t-P:10.198.XXX.115  Mask:255.255.255.255
   UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1486  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:10
   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
 root@qt5022:~# ping 8.8.8.8
 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=1163 ms
 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=304 ms
 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=72.5 ms
 64 bytes from 8.8.8.8: icmp_seq=4 ttl=46 time=60.7 ms
 ^C
 --- 8.8.8.8 ping statistics ---
 4 packets transmitted, 4 received, 0% packet loss, time 3003ms
 rtt min/avg/max/mdev = 60.790/400.296/1163.670/451.296 ms, pipe 2
 root@qt5022:~# cat /dev/ttyHS1
 $GPGSV,4,1,16,24271232,,,*7A
 $GPGSV,4,2,16,31302928,,,*78
 $GPGSV,4,3,16,26252322,,,*7B
 $GPGSV,4,4,16,21201918,,,*7E
 $GPGGA,,0*66
 $PQXFI,,*56
 $GPVTG,,T,,M,,N,,K,N*2C
 $GPRMC,,V,,N*53
 $GPGSA,A,1,,,*1E
 $GPGSV,4,1,16,04242712,,,*7F
 $GPGSV,4,2,16,32313029,,,*73
 $GPGSV,4,3,16,28262523,,,*71
 $GPGSV,4,4,16,22212019,,,*77
 $GPGGA,,0*66
 $PQXFI,,*56
 $GPVTG,,T,,M,,N,,K,N*2C
 $GPRMC,,V,,N*53
 $GPGSA,A,1,,,*1E
 
 On Mon, Aug 4, 2014 at 8:30 PM, Dan Williams d...@redhat.com wrote:
  On Mon, 2014-08-04 at 11:20 +0200, Ricardo Ribalda Delgado wrote:
  Suggested-by: Dan Williams d...@redhat.com
 
  Before we apply this patch though, can you grab for the following for
  me?
 
  cat /sys/class/tty/*/hsotype
 
  and lets see if the firmware actually responds.  Also, do you get an
  'hso0' network interface as reported by ifconfig or /sbin/ip?  If you
  do, then lets do some additional verification to ensure it should be
  driven by 'hso' instead of option.
 
  Dan
 
  On Mon, Aug 4, 2014 at 11:11 AM, Ricardo Ribalda Delgado
  ricardo.riba...@gmail.com wrote:
   After this patch:
  
   [ 32.985530] hso: drivers/net/usb/hso.c: Option Wireless
   [ 33.000452] hso 2-1.4:1.7: Not our interface
   [ 33.001849] usbcore: registered new interface driver hso
  
   root@qt5022:~# ls /dev/ttyHS*
   /dev/ttyHS0  /dev/ttyHS1  /dev/ttyHS2  /dev/ttyHS3  /dev/ttyHS4
   /dev/ttyHS5
  
   root@qt5022:~# lsusb -d 0af0: -vvv
  
   Bus 002 Device 003: ID 0af0:9200 Option
   Device Descriptor:
 bLength18
 bDescriptorType 1
 bcdUSB   2.00
 bDeviceClass  255 Vendor Specific Class
 bDeviceSubClass   255 Vendor Specific Subclass
 bDeviceProtocol   255 Vendor Specific Protocol
 bMaxPacketSize064
 idVendor   0x0af0 Option
 idProduct  0x9200
 bcdDevice0.00
 iManufacturer   3 Option N.V.
 iProduct2 Globetrotter HSUPA Modem
 iSerial 0
 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength  200
   bNumInterfaces  8
   bConfigurationValue 1
   iConfiguration  1 Option Configuration
   bmAttributes 0xe0
 Self Powered
 Remote Wakeup
   MaxPower  100mA
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   2
 bInterfaceClass   255 Vendor Specific Class
 bInterfaceSubClass255 Vendor Specific Subclass
 bInterfaceProtocol255 Vendor Specific Protocol
 iInterface  0
 Endpoint Descriptor:
   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x81  EP 1

Re: [PATCH] net/usb/hso: Add support for Option GTM671WFS

[Dan Williams]

On Mon, 2014-08-04 at 11:11 +0200, Ricardo Ribalda Delgado wrote:
 After this patch:
 
 [   32.985530] hso: drivers/net/usb/hso.c: Option Wireless
 [   33.000452] hso 2-1.4:1.7: Not our interface
 [   33.001849] usbcore: registered new interface driver hso
 
 root@qt5022:~# ls /dev/ttyHS*
 /dev/ttyHS0  /dev/ttyHS1  /dev/ttyHS2  /dev/ttyHS3  /dev/ttyHS4
 /dev/ttyHS5

Acked-by: Dan Williams d...@redhat.com

 root@qt5022:~# lsusb -d 0af0: -vvv
 
 Bus 002 Device 003: ID 0af0:9200 Option
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass  255 Vendor Specific Class
   bDeviceSubClass   255 Vendor Specific Subclass
   bDeviceProtocol   255 Vendor Specific Protocol
   bMaxPacketSize064
   idVendor   0x0af0 Option
   idProduct  0x9200
   bcdDevice0.00
   iManufacturer   3 Option N.V.
   iProduct2 Globetrotter HSUPA Modem
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength  200
 bNumInterfaces  8
 bConfigurationValue 1
 iConfiguration  1 Option Configuration
 bmAttributes 0xe0
   Self Powered
   Remote Wakeup
 MaxPower  100mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass255 Vendor Specific Subclass
   bInterfaceProtocol255 Vendor Specific Protocol
   iInterface  0
   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
   bInterfaceSubClass255 Vendor Specific Subclass
   bInterfaceProtocol255 Vendor Specific Protocol
   iInterface  0
   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 512 bytes
 bInterval  32
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber2
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass255 Vendor Specific Subclass
   bInterfaceProtocol255 Vendor Specific Protocol
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x83  EP 3 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x03  EP 3 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber3

Re: [PATCH] serial/option: Add support for Option GTM671WFS

[Dan Williams]

On Mon, 2014-08-04 at 11:12 +0200, Ricardo Ribalda Delgado wrote:
 Hello Dan
 
 
  Are you 100% sure these don't go into the 'hso' driver?  'option' is
  used for mostly older Option devices (like 5+ years old).  I tried to
  find information about this module, and the closest I could come for
  0af0:9200 was:
 
  http://trac.gateworks.com/wiki/3g
 
  which indicates they might be 'hso' instead.  Can you give that a try?

Follow-up note: this device should indeed be driven by 'hso' (not
option) and Ricardo has submitted a patch for that to netdev@.

Dan

 With all the hso_ids configuration I get the following error message:
 
 [  553.501693] hso: drivers/net/usb/hso.c: Option Wireless
 [  553.524898] hso 2-1.4:1.7: Not our interface
 
 and depending on the mode I get 3, 4 or 6 ttySH interfaces
 
 But, if we ignore this, the device can connect to the internet with
 hso_connect.sh. I have already post a patch using the hso driver.
 
 The device could also connect with option.ko... Do you think that
 there could be other devices wrongly handled with option ?
 
 Ricardo
 --
 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

Re: [PATCH] net/usb/hso: Add support for Option GTM671WFS

[Dan Williams]

On Mon, 2014-08-04 at 11:20 +0200, Ricardo Ribalda Delgado wrote:
 Suggested-by: Dan Williams d...@redhat.com

Before we apply this patch though, can you grab for the following for
me?

cat /sys/class/tty/*/hsotype

and lets see if the firmware actually responds.  Also, do you get an
'hso0' network interface as reported by ifconfig or /sbin/ip?  If you
do, then lets do some additional verification to ensure it should be
driven by 'hso' instead of option.

Dan

 On Mon, Aug 4, 2014 at 11:11 AM, Ricardo Ribalda Delgado
 ricardo.riba...@gmail.com wrote:
  After this patch:
 
  [ 32.985530] hso: drivers/net/usb/hso.c: Option Wireless
  [ 33.000452] hso 2-1.4:1.7: Not our interface
  [ 33.001849] usbcore: registered new interface driver hso
 
  root@qt5022:~# ls /dev/ttyHS*
  /dev/ttyHS0  /dev/ttyHS1  /dev/ttyHS2  /dev/ttyHS3  /dev/ttyHS4
  /dev/ttyHS5
 
  root@qt5022:~# lsusb -d 0af0: -vvv
 
  Bus 002 Device 003: ID 0af0:9200 Option
  Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB   2.00
bDeviceClass  255 Vendor Specific Class
bDeviceSubClass   255 Vendor Specific Subclass
bDeviceProtocol   255 Vendor Specific Protocol
bMaxPacketSize064
idVendor   0x0af0 Option
idProduct  0x9200
bcdDevice0.00
iManufacturer   3 Option N.V.
iProduct2 Globetrotter HSUPA Modem
iSerial 0
bNumConfigurations  1
Configuration Descriptor:
  bLength 9
  bDescriptorType 2
  wTotalLength  200
  bNumInterfaces  8
  bConfigurationValue 1
  iConfiguration  1 Option Configuration
  bmAttributes 0xe0
Self Powered
Remote Wakeup
  MaxPower  100mA
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting   0
bNumEndpoints   2
bInterfaceClass   255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface  0
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
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface  0
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 512 bytes
  bInterval  32
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber2
bAlternateSetting   0
bNumEndpoints   2
bInterfaceClass   255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface  0
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x83  EP 3 IN
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0200  1x

Re: USB modem interface not detected sometimes

[Dan Williams]

On Fri, 2014-08-01 at 21:44 +0530, Rahul Bedarkar wrote:
 Hi,
 
 I have USB modem which has also support for micro SD card.
 
 With kernel version 3.15 and later, I am facing a issue with modem
 interface detection. When I connect it first time only storage
 interface is detected. I had to disconnect it and reconnect it again.
 
 This issue is not seen with kernel version 3.11.
 
 Following are dmesg logs with version 3.15
 
 After USB modem attached first time

The device is actually switched from fake CD mode to modem mode by
usb_modeswitch, and it appears that usb_modeswitch is failing to do that
here sometimes.  You should probably debug the usb_modeswitch stuff a
bit more first.

usb_modeswitch provides a udev helper (/usr/lib/udev/usb_modeswitch)
that calls the main usb_modeswitch binary whenever a known device is
inserted.  You might get some more info by turning on udev verbose
logging, or by modifying /etc/usb_modeswitch.conf and setting
EnableLogging=1.

Dan

 [   44.044105] usb 4-1: USB disconnect, device number 3
 [   52.764071] usb 1-1: new high-speed USB device number 4 using ehci-pci
 [   52.898661] usb 1-1: New USB device found, idVendor=1c9e, idProduct=f000
 [   52.898667] usb 1-1: New USB device strings: Mfr=3, Product=2, 
 SerialNumber=4
 [   52.898670] usb 1-1: Product: USB Modem
 [   52.898672] usb 1-1: Manufacturer: USB Modem
 [   52.898675] usb 1-1: SerialNumber: 1234567890ABCDEF
 [   53.479638] usb-storage 1-1:1.0: USB Mass Storage device detected
 [   53.479889] scsi4 : usb-storage 1-1:1.0
 [   53.480139] usbcore: registered new interface driver usb-storage
 [   54.480352] scsi 4:0:0:0: CD-ROMUSBModem Disk
   2.31 PQ: 0 ANSI: 2
 [   54.485187] sr1: scsi-1 drive
 [   54.485575] sr 4:0:0:0: Attached scsi CD-ROM sr1
 [   54.486557] sr 4:0:0:0: Attached scsi generic sg2 type 5
 
 After disconnecting and connecting it again.
 
 [  119.964616] usb 1-1: USB disconnect, device number 4
 [  126.736117] usb 1-1: new high-speed USB device number 5 using ehci-pci
 [  126.870805] usb 1-1: New USB device found, idVendor=1c9e, idProduct=f000
 [  126.870813] usb 1-1: New USB device strings: Mfr=3, Product=2, 
 SerialNumber=4
 [  126.870818] usb 1-1: Product: USB Modem
 [  126.870822] usb 1-1: Manufacturer: USB Modem
 [  126.870826] usb 1-1: SerialNumber: 1234567890ABCDEF
 [  126.872936] usb-storage 1-1:1.0: USB Mass Storage device detected
 [  126.873225] scsi5 : usb-storage 1-1:1.0
 [  127.873602] scsi 5:0:0:0: CD-ROMUSBModem Disk
   2.31 PQ: 0 ANSI: 2
 [  127.877304] sr1: scsi-1 drive
 [  127.877740] sr 5:0:0:0: Attached scsi CD-ROM sr1
 [  127.878452] sr 5:0:0:0: Attached scsi generic sg2 type 5
 [  130.122519] usb 1-1: USB disconnect, device number 5
 [  130.488100] usb 1-1: new high-speed USB device number 6 using ehci-pci
 [  130.622919] usb 1-1: New USB device found, idVendor=1c9e, idProduct=9605
 [  130.622926] usb 1-1: New USB device strings: Mfr=3, Product=2, 
 SerialNumber=4
 [  130.622931] usb 1-1: Product: USB Modem
 [  130.622935] usb 1-1: Manufacturer: USB Modem
 [  130.622939] usb 1-1: SerialNumber: 1234567890ABCDEF
 [  131.265801] usb-storage 1-1:1.4: USB Mass Storage device detected
 [  131.265991] scsi6 : usb-storage 1-1:1.4
 [  131.363101] usbcore: registered new interface driver usbserial
 [  131.363126] usbcore: registered new interface driver usbserial_generic
 [  131.363143] usbserial: USB Serial support registered for generic
 [  131.446570] usbcore: registered new interface driver option
 [  131.446593] usbserial: USB Serial support registered for GSM modem (1-port)
 [  131.446737] option 1-1:1.0: GSM modem (1-port) converter detected
 [  131.451834] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
 [  131.451933] option 1-1:1.1: GSM modem (1-port) converter detected
 [  131.452394] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
 [  131.452471] option 1-1:1.2: GSM modem (1-port) converter detected
 [  131.452574] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
 [  131.452636] option 1-1:1.3: GSM modem (1-port) converter detected
 [  131.452733] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3
 [  132.265188] scsi 6:0:0:0: Direct-Access USBModem Disk
   2.31 PQ: 0 ANSI: 2
 [  132.268559] sd 6:0:0:0: Attached scsi generic sg2 type 0
 [  132.271063] sd 6:0:0:0: [sdb] Attached SCSI removable disk
 [  135.440547] option1 ttyUSB3: option_instat_callback: error -2
 [  152.486473] option1 ttyUSB3: option_instat_callback: error -2
 
 
 lsusb -d 1c9e:9605 -v
 
 Bus 001 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY
 Couldn't open device, some information will be missing
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize064
   idVendor   0x1c9e OMEGA TECHNOLOGY
   idProduct  0x9605
   bcdDevice  

Re: [PATCH] serial/option: Add support for Option GTM671WFS

[Dan Williams]

On Fri, 2014-08-01 at 14:00 +0200, Ricardo Ribalda Delgado wrote:
 After this patch:
 
 [5.389385] usbserial: USB Serial support registered for GSM modem (1-port)
 [5.390181] option 2-1.4:1.0: GSM modem (1-port) converter detected
 [5.390556] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB0
 [5.390636] option 2-1.4:1.1: GSM modem (1-port) converter detected
 [5.390935] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB1
 [5.391002] option 2-1.4:1.2: GSM modem (1-port) converter detected
 [5.391258] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB2
 [5.391318] option 2-1.4:1.3: GSM modem (1-port) converter detected
 [5.391650] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB3
 [5.391685] option 2-1.4:1.4: GSM modem (1-port) converter detected
 [5.391895] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB4
 [5.391927] option 2-1.4:1.5: GSM modem (1-port) converter detected
 [5.392076] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB5
 [5.392109] option 2-1.4:1.6: GSM modem (1-port) converter detected
 [5.392278] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB6
 
 root@qt5022:~# lsusb -d 0af0: -vvv

Are you 100% sure these don't go into the 'hso' driver?  'option' is
used for mostly older Option devices (like 5+ years old).  I tried to
find information about this module, and the closest I could come for
0af0:9200 was:

http://trac.gateworks.com/wiki/3g

which indicates they might be 'hso' instead.  Can you give that a try?

Dan

 Bus 002 Device 003: ID 0af0:9200 Option
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass  255 Vendor Specific Class
   bDeviceSubClass   255 Vendor Specific Subclass
   bDeviceProtocol   255 Vendor Specific Protocol
   bMaxPacketSize064
   idVendor   0x0af0 Option
   idProduct  0x9200
   bcdDevice0.00
   iManufacturer   3 Option N.V.
   iProduct2 Globetrotter HSUPA Modem
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength  200
 bNumInterfaces  8
 bConfigurationValue 1
 iConfiguration  1 Option Configuration
 bmAttributes 0xe0
   Self Powered
   Remote Wakeup
 MaxPower  100mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass255 Vendor Specific Subclass
   bInterfaceProtocol255 Vendor Specific Protocol
   iInterface  0
   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
   bInterfaceSubClass255 Vendor Specific Subclass
   bInterfaceProtocol255 Vendor Specific Protocol
   iInterface  0
   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 512 bytes
 bInterval  32
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber2
   

Re: [xhci] kernel BUG at include/linux/scatterlist.h:115!

[Dan Williams]

On Tue, Jul 29, 2014 at 8:57 PM, Fengguang Wu fengguang...@intel.com wrote:
 Greetings,

 0day kernel testing robot got the below dmesg and the first bad commit is

 git://git.kernel.org/pub/scm/linux/kernel/git/djbw/usb.git td-fragments-v1
 commit 61d9c2ad31b11b87c319bbc2a963040742bac77c
 Author: Dan Williams dan.j.willi...@intel.com
 AuthorDate: Tue Jul 22 00:08:51 2014 -0700
 Commit: Dan Williams dan.j.willi...@intel.com
 CommitDate: Thu Jul 24 18:12:38 2014 -0700

 xhci: unit test ring enqueue/dequeue routines

 Given the complexity of satisfying xhci 1.0+ host trb boundary
 constraints, provide a test case that exercises inserting mid-segment
 links into a ring.

 The linker --wrap= option is used to not pollute the global identifier
 space and to make it clear which standard xhci driver routines are being
 mocked-up.  The --wrap= option does not come into play when both
 xhci-hcd and xhci-test are built-in to the kernel, so namespace
 collisions are prevented by excluding xhci-test from the build when
 xhci-hcd is built-in.

 It's unfortunate that this is an in-kernel test rather than userspace
 and that the infrastructure is custom rather than generic.  That said,
 it serves its purpose of exercising the corner cases of the scatterlist
 parsing implementation in xhci.

 Signed-off-by: Dan Williams dan.j.willi...@intel.com

Looks like I either need specify valid addresses to sg_set_buf(), or
just make the unit test depend on !CONFIG_DEBUG_SG.  I'll go with the
latter since this test is not about scatterlist api correctness and
there's nothing to be gained by unwinding virt_addr_valid()
requirements for this.
--
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: Problem with D-Link USB 3.0 to Gigabit Ethernet Adapter DUB-1312

[Dan Williams]

On Wed, Jul 23, 2014 at 6:52 AM, Marek Uher xu...@seznam.cz wrote:

 Hi Sarah,

 Thank you very much for your answer. I bought three same all-in-one, 
 low-energy
 and space effective computers from ASUS. There isn’t any possibility to add an
 additional extension PCIe card. There is only the option to upgrade the memory
 and hard drive (which I already did it). I want to use these computers as home
 GlusterFS cluster / NAS solution. Therefore, I need to add a second 1 Gbps
 ethernet interface to each computer (I want to use link aggregation). And the
 only way ho to realize such network connection is via USB 3 interface.

 For these reasons described above the only way for me is to solve the problems
 in the ASMedia xHCI and ASIX driver on existing hardware. I can help to solve
 this problem. In the case of interested I can make remote access for the
 developers to my computer via SSH. Developers would have the opportunity to
 access the problematic hardware and solve problems directly. Everything is 
 just
 a matter of agreement.


Hi Marek,

I have an initial draft version of the patchset Sarah mentioned that I
am still in the process of testing before I post to the mailing list.
If you want to give it a shot realize that it is early access code and
has not seen any testing outside of a super-speed USB Mass Storage
Device and my own unit tests.  If you want to give it a shot I'd
appreciate a test report, it's based on Greg's usb-next branch from
yesterday.

--
Dan

The following changes since commit d508d992026c8225d529f39795e1ed6d2867bd2c:

  Merge tag 'for_3.17' of
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into
usb-next (2014-07-22 16:33:00 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/djbw/usb td-fragments-v1

for you to fetch changes up to 61d9c2ad31b11b87c319bbc2a963040742bac77c:

  xhci: unit test ring enqueue/dequeue routines (2014-07-24 18:12:38 -0700)
--
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: 03f0:521d Hewlett-Packard (HP hs3110)

[Dan Williams]

On Wed, 2014-07-23 at 14:33 +, Stanescu Victor wrote:
 /dev/cdc-wdm2 doesn't work. Further more, instead of freezing at cat, it 
 freezes from echo.
 
 Ctrl-c doesn't stop the frozen echo.

I'm pretty sure this device does not expose QMI at all, from looking at
through the drivers.  The driver package from HP *does* have QMI
drivers, but only for the lt4112/lt4124/lt4126.  The hs3110/hs3114 are
assigned to the Jungo-type driver for Win  8.  For example:

  DeviceInfo
 item module=MU736 VID=03F0 PID=521D Baseline=JUNGO Remark=HP/
 item module=MU736 VID=03F0 PID=541D Baseline=JUNGO Remark=HP/
 item module=ME906 VID=03F0 PID=581D Baseline=QUALCOMM 
Remark=HP/
 item module=ME906 VID=03F0 PID=561D Baseline=QUALCOMM 
Remark=HP/
 item module=ME906 VID=03F0 PID=591D Baseline=QUALCOMM 
Remark=HP/
  /DeviceInfo

In any case, if the devices have MBIM descriptors, then we should try to
drive them via MBIM, since that appears to be what happens with these
devices on Windows 8.  Otherwise, it should be AT+ECM I think, but not
QMI for the 3110/3114.

Dan

 On 07/23/2014 12:45 PM, Bjørn Mork wrote:
  Stanescu Victor victor.stane...@gtsce.com writes:
 
  root@victor-laptop:~# modprobe qmi_wwan
  root@victor-laptop:~# dmesg
  [ 6005.900671] usbcore: registered new interface driver cdc_wdm
  [ 6005.902682] usbcore: registered new interface driver qmi_wwan
  root@victor-laptop:~# echo 03f0 521d 
  /sys/bus/usb/drivers/qmi_wwan/new_id
  root@victor-laptop:~# dmesg
  [ 6005.900671] usbcore: registered new interface driver cdc_wdm
  [ 6005.902682] usbcore: registered new interface driver qmi_wwan
  [ 6023.507185] qmi_wwan 2-6:1.0: cdc-wdm0: USB WDM device
  [ 6023.507419] qmi_wwan 2-6:1.0 wwan0: register 'qmi_wwan' at
  usb-:00:14.0-6, WWAN/QMI device, 02:b2:8c:7a:5d:55
  Right.  I was hoping you would have the usb-serial driver bound to this
  and the other serial functions so you avoided this.  But it's not really
  a problem, just a bit confusing.  You have to adjust the tests a bit.
 
 
  [ 6023.508210] qmi_wwan: probe of 2-6:1.1 failed with error -22
  [ 6023.509177] qmi_wwan: probe of 2-6:1.2 failed with error -22
  [ 6023.509871] qmi_wwan 2-6:1.3: cdc-wdm1: USB WDM device
  [ 6023.510099] qmi_wwan 2-6:1.3 wwan1: register 'qmi_wwan' at
  usb-:00:14.0-6, WWAN/QMI device, 02:b2:8c:7a:5d:55
  [ 6023.511420] qmi_wwan 2-6:1.4: cdc-wdm2: USB WDM device
  [ 6023.511604] qmi_wwan 2-6:1.4 wwan2: register 'qmi_wwan' at
  usb-:00:14.0-6, WWAN/QMI device, 58:2c:80:13:92:63
 
  This is the only possible candidate.  So you should do all testing on
  the wwan2 and /dev/cdc-wdm2 devices.
 
  root@victor-laptop:~# qmicli -d /dev/cdc-wdm0 --device-open-version-info
  --wds-noop
  error: couldn't open the QmiDevice: Transaction timed out
  root@victor-laptop:~# echo -e ATI\r  /dev/cdc-wdm0
  root@victor-laptop:~# cat /dev/cdc-wdm0
  [frozen]
  Please repeat this using the /dev/cdc-wdm2 instead.  The frozen output
  can be cancelled by ctrl+C
 
 
 
  Bjørn


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

Re: [PATCH 2/2] hso: fix deadlock when receiving bursts of data

[Dan Williams]

On Mon, 2014-07-07 at 11:06 +0200, Olivier Sobrie wrote:
 When the module sends bursts of data, sometimes a deadlock happens in
 the hso driver when the tty buffer doesn't get the chance to be flushed
 quickly enough.
 
 To avoid this, first, we remove the endless while loop in
 put_rx_bufdata() which is the root cause of the deadlock.
 Secondly, when there is no room anymore in the tty buffer, we set up a
 timer of 100 msecs to give a chance to the upper layer to flush the tty
 buffer and make room for new data.

I assume this problem happens when using PPP for data transfer, instead
of using the network port that the modules expose?  Or maybe the NMEA
port?  I can't imagine that AT commands would make this happen...

Dan

 Signed-off-by: Olivier Sobrie oliv...@sobrie.be
 ---
  drivers/net/usb/hso.c |   51 
 +
  1 file changed, 35 insertions(+), 16 deletions(-)
 
 diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
 index 9ca2b41..1dff74f 100644
 --- a/drivers/net/usb/hso.c
 +++ b/drivers/net/usb/hso.c
 @@ -106,6 +106,8 @@
  
  #define MAX_RX_URBS  2
  
 +#define UNTHROTTLE_TIMEOUT   100 /* msecs */
 +
  
 /*/
  /* Debugging functions   
 */
  
 /*/
 @@ -261,6 +263,7 @@ struct hso_serial {
   u16  curr_rx_urb_offset;
   u8   rx_urb_filled[MAX_RX_URBS];
   struct tasklet_struct unthrottle_tasklet;
 + struct timer_list unthrottle_timer;
  };
  
  struct hso_device {
 @@ -1161,13 +1164,18 @@ static void 
 put_rxbuf_data_and_resubmit_bulk_urb(struct hso_serial *serial)
   while (serial-rx_urb_filled[serial-curr_rx_urb_idx]) {
   curr_urb = serial-rx_urb[serial-curr_rx_urb_idx];
   count = put_rxbuf_data(curr_urb, serial);
 - if (count == -1)
 - return;
   if (count == 0) {
   serial-curr_rx_urb_idx++;
   if (serial-curr_rx_urb_idx = serial-num_rx_urbs)
   serial-curr_rx_urb_idx = 0;
   hso_resubmit_rx_bulk_urb(serial, curr_urb);
 + } else if (count  0) {
 + mod_timer(serial-unthrottle_timer,
 +   jiffies
 + + msecs_to_jiffies(UNTHROTTLE_TIMEOUT));
 + break;
 + } else {
 + break;
   }
   }
  }
 @@ -1251,6 +1259,11 @@ static void hso_unthrottle(struct tty_struct *tty)
   tasklet_hi_schedule(serial-unthrottle_tasklet);
  }
  
 +static void hso_unthrottle_schedule(unsigned long data)
 +{
 + tasklet_schedule((struct tasklet_struct *)data);
 +}
 +
  /* open the requested serial port */
  static int hso_serial_open(struct tty_struct *tty, struct file *filp)
  {
 @@ -1286,6 +1299,10 @@ static int hso_serial_open(struct tty_struct *tty, 
 struct file *filp)
   tasklet_init(serial-unthrottle_tasklet,
(void (*)(unsigned long))hso_unthrottle_tasklet,
(unsigned long)serial);
 + serial-unthrottle_timer.function = hso_unthrottle_schedule;
 + serial-unthrottle_timer.data =
 + (unsigned long)serial-unthrottle_tasklet;
 + init_timer(serial-unthrottle_timer);
   result = hso_start_serial_device(serial-parent, GFP_KERNEL);
   if (result) {
   hso_stop_serial_device(serial-parent);
 @@ -1333,6 +1350,7 @@ static void hso_serial_close(struct tty_struct *tty, 
 struct file *filp)
   tty_port_tty_set(serial-port, NULL);
   if (!usb_gone)
   hso_stop_serial_device(serial-parent);
 + del_timer_sync(serial-unthrottle_timer);
   tasklet_kill(serial-unthrottle_tasklet);
   }
  
 @@ -2012,22 +2030,23 @@ static int put_rxbuf_data(struct urb *urb, struct 
 hso_serial *serial)
  
   tty = tty_port_tty_get(serial-port);
  
 + if (tty  test_bit(TTY_THROTTLED, tty-flags)) {
 + tty_kref_put(tty);
 + return -1;
 + }
 +
   /* Push data to tty */
 - write_length_remaining = urb-actual_length -
 - serial-curr_rx_urb_offset;
   D1(data to push to tty);
 - while (write_length_remaining) {
 - if (tty  test_bit(TTY_THROTTLED, tty-flags)) {
 - tty_kref_put(tty);
 - return -1;
 - }
 - curr_write_len = tty_insert_flip_string(serial-port,
 - urb-transfer_buffer + serial-curr_rx_urb_offset,
 - write_length_remaining);
 - serial-curr_rx_urb_offset += curr_write_len;
 - write_length_remaining -= 

Re: Re:Re: move ZTE CDMA device pid from zte_ev.c back to option.c and modify a parameter in zte_ev.ko

[Dan Williams]

On Mon, 2014-06-23 at 18:15 +0800, 刘磊 wrote:
 Could you try the first patch (only) and see if it fixes the problem?
 Does it also fix the problem you're having with PID 0xfffe?
 
 yes, the first patch could solve the problem with pid 0xfffe.
 
 
 When you you have tested the first patch, could you test the second one
 as well and see if everything still works?
 
 yes, the second path i had been tested and it works fine.
 
 
 In you other two mails, you want to modify the line-coding handling, but i'm 
 not sure that have some problem.
 otherwise, it will be have some problem in the pid  of 0xfffe for our 
 company(the pid of 0xfffe belongs our company).
 i suggest you sould move the pid of 0xfffe from zte_ev.c to option.c at first 
 and then modify others.
 
 
 i don't know why create the file of zte_ev.c that is not necessary. i suggest 
 we can move all the pid from zte_ev.c to option.c.

The file is derived from the zte_ev.c that was distributed by ZTE
themselves in the ztemtApp software for 0xffeb - 0x, 0x3917,
0x6000, and 0x9008, which include the AC8700, AC8710, MG880, AC2726,
AC8710_V3, AC2716, and a bunch of other CDMA devices.  They were
originally driven by option, but users were having problems with that
and I think people thought that maybe the official ZTE drivers would
work better.

I would like to move them to option if we can, and get rid of zte_ev.c,
but to do that we must understand what zte_ev.c was actually trying to
do so that we ensure that option can do it too.

Dan

 
  
 
 
 
 
 
 
 
 At 2014-06-23 05:33:55, Johan Hovold jo...@kernel.org wrote:
 On Fri, Jun 20, 2014 at 06:30:23PM +0800, 刘磊 wrote:
  patch2: Modify the parameter from 0x0003 to 0x. you must submit patch1 
  at first.
  Reason:In the USB serial protocol,  if set the control state
  (SET_CONTROL_LINE_STATE(22h)) and the parameter of RTS must be 0x 
  that make the carrier signal invalid state when close network.
  otherwise can't disconnect the network.
 
 Ok, that makes sense, but I think it should be implemented differently
 using the infrastructure provided by usb-serial (and tty-port).
 
 I'm responding to this mail with two patches.
 
 Could you try the first patch (only) and see if it fixes the problem?
 Does it also fix the problem you're having with PID 0xfffe?
 
 When you you have tested the first patch, could you test the second one
 as well and see if everything still works?
 
 Thanks,
 Johan
 NrybXǧv^)޺{.n+{^nrzhGh(階ݢjmzޖfh~m


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

Re: [RFC] xhci: Fix xhci block system enter system suspend state.

[Dan Williams]

On Sun, Jun 22, 2014 at 7:33 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Sun, 22 Jun 2014, Wang, Yu wrote:

 From: Wang, Yu yu.y.w...@intel.com

 The system suspend flow as following:
 1, Freeze all user processes and kenrel threads.

 2, Trying to suspend all devices.

 2.1, If pci device under RPM suspended state, then pci driver will try
 to resume it to RPM active state in prepare stage.

 2.2, xhci_resume function will call usb_hcd_resume_root_hub to queue two
 workqueue items to resume usb2usb3 roothub devices.

 2.3, Call suspend callbacks of devices.

 2.3.1, All suspend callbacks be called of all hcd's children included
 roothub devices.

 2.3.2, Fianlly, hcd_pci_suspend callback be called.

 Due to workqueue threads were already frozen in step 1. So the workqueue
 items can't be scheduled which will cause roothub devices can't be
 resumed in this flow. Then HCD_FLAG_WAKEUP_PENDING flags will not be
 clear which set in usb_hcd_resume_root_hub function. Finally,
 hcd_pci_suspend will return -EBUSY, and system suspend is failed.

 The reason why this issue doesn't show up very often, it is due to
 choose_wakeup will be called in step step 2.3.1. In step 2.3.1
 udev-do_remote_wakeup is not equal device_may_wakeup(udev-dev), then
 udev will be resume to RPM active for change the wakeup settings. This
 is one be resumed to RPM active to change lucky hit which hides this
 issue.

 For some special xHCI controllers which have no USB2 port, then roothub
 will not match hub driver due to probe failed. Then its
 do_remote_wakeup will be set to zero, then will not hit above lucky.

 Actually, xhci driver needn't to resume roothub devices everytime like
 above case. It's only needed when there are pending event TRBs.

 Signed-off-by: Wang, Yu yu.y.w...@intel.com

 Acked-by: Alan Stern st...@rowland.harvard.edu

Alan, I'm wondering if we should be looking at a change in the core to
prevent these rpm_suspend() vs dpm_suspend() collisions?  I.e. waking
up runtime suspended hubs prior to khubd being frozen?
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net,stable] net: huawei_cdc_ncm: increase command buffer size

[Dan Williams]

On Wed, 2014-06-18 at 14:21 +0200, Bjørn Mork wrote:
 Messages from the modem exceeding 256 bytes cause communication
 failure.
 
 The WDM protocol is strictly read on demand, meaning that we only
 poll for unread data after receiving a notification from the modem.
 Since we have no way to know how much data the modem has to send,
 we must make sure that the buffer we provide is big enough.
 Message truncation does not work. Truncated messages are left unread
 until the modem has another message to send.  Which often won't
 happen until the userspace application has given up waiting for the
 final part of the last message, and therefore sends another command.
 
 With a proper CDC WDM function there is a descriptor telling us
 which buffer size the modem uses. But with this vendor specific
 implementation there is no known way to calculate the exact big
 enough number.  It is an unknown property of the modem firmware.
 Experience has shown that 256 is too small.  The discussion of
 this failure ended up concluding that 512 might be too small as
 well. So 1024 seems like a reasonable value for now.
 
 Fixes: 41c47d8cfd68 (net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm 
 driver)
 Cc: Enrico Mioso mrkiko...@gmail.com
 Reported-by: Dan Williams d...@redhat.com
 Signed-off-by: Bjørn Mork bj...@mork.no

Tested-by: Dan Williams d...@redhat.com

'CRLF^SYSCFGEX:
(00,01,02,03,99),((400380,GSM900/GSM1800/WCDMA2100),(6a8,GSM850/GSM1900/WCDMA850/AWS/WCDMA1900),(3fff,All
 
bands)),(0-2),(0-4),((1081b,LTE_B1/LTE_B2/LTE_B4/LTE_B5/LTE_B12/LTE_B17),(7fff,All
 bands))CRLFCRLFOKCRLF'

I get the last LF now :)

 ---
 
 The problem is a showstopper for anyone hitting it, so I believe this
 fix should go into all maintained stable kernels with this driver.
 That is anything based on v3.13 or newer.
 
 Thanks,
 Bjørn
 
 
  drivers/net/usb/huawei_cdc_ncm.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/net/usb/huawei_cdc_ncm.c 
 b/drivers/net/usb/huawei_cdc_ncm.c
 index f9822bc75425..5d95a13dbe2a 100644
 --- a/drivers/net/usb/huawei_cdc_ncm.c
 +++ b/drivers/net/usb/huawei_cdc_ncm.c
 @@ -84,12 +84,13 @@ static int huawei_cdc_ncm_bind(struct usbnet *usbnet_dev,
   ctx = drvstate-ctx;
  
   if (usbnet_dev-status)
 - /* CDC-WMC r1.1 requires wMaxCommand to be at least 256
 -  * decimal (0x100)
 + /* The wMaxCommand buffer must be big enough to hold
 +  * any message from the modem. Experience has shown
 +  * that some replies are more than 256 bytes long
*/
   subdriver = usb_cdc_wdm_register(ctx-control,
usbnet_dev-status-desc,
 -  256, /* wMaxCommand */
 +  1024, /* wMaxCommand */

 huawei_cdc_ncm_wdm_manage_power);
   if (IS_ERR(subdriver)) {
   ret = PTR_ERR(subdriver);


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

Re: [PATCH 0/3] port power control fixes for 3.16-rc2

[Dan Williams]

On Wed, Jun 18, 2014 at 1:18 AM, Bjørn Mork bj...@mork.no wrote:
 Dan Williams dan.j.willi...@intel.com writes:

 I put patch 3 usb: fix hub-port pm_runtime_enable() vs runtime pm
 transitions through it's paces, but I'd still like to see a positive
 test report from Bjørn... even if it's too late to add a Tested-by.

 Fixes the problem for me.  Thanks


Thanks for the report and the test.  Much appreciated!
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] usb: fix hub-port pm_runtime_enable() vs runtime pm transitions

[Dan Williams]

On Wed, Jun 18, 2014 at 7:54 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Tue, 17 Jun 2014, Dan Williams wrote:

 Commit 9262c19d14c4 usb: disable port power control if not supported in
 wHubCharacteristics gated enabling runtime pm for usb_port devices on
 whether the parent hub supports power control, which causes a
 regression.  The port must still be allowed to carry out runtime pm
 callbacks and receive a -EAGAIN or -EBUSY result.  Otherwise the
 usb_port device will transition to the pm error state and trigger the
 same for the child usb_device.

 Prior to the offending commit usb_hub_create_port_device() arranged for
 runtime pm to be disabled is dev_pm_qos_expose_flags() failed.  Instead,
 force the default state of PM_QOS_FLAG_NO_POWER_OFF flag to be set prior
 to enabling runtime pm.  If that policy can not be set then fail
 registration.

 This whole thing seems much more complicated than necessary.

 Instead of messing around with PM-QOS settings, why not just do an
 extra pm_runtime_get_noresume() if the hub doesn't support power
 control?

In that scenario userspace has to fishing for why the port is not
powering off vs no pm_qos_no_power_off == no capability.

 Or, what about leaving this code the way it was and changing the PM
 core (see http://marc.info/?l=linux-pmm=140303690820354w=2)?

I like this approach too, but was not sure a core change like that
would be accepted now that -rc1 is out.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] port power control fixes for 3.16-rc2

[Dan Williams]

Fallout / regression fixes for the port power control rework that landed
in 3.16-rc1.

1/ Cosmetic fix to an error message

2/ Handle ACPI port-location-data conflicts by disabling port power off
   rather than spewing a backtrace and trying to continue.

3/ Handle hubs that do not support port power off by enforcing the
   PM_QOS_NO_POWER_OFF constraint from the kernel rather than disabling
   runtime power management.

---

Dan Williams (3):
  usb: improve not suspended yet message in hub_suspend()
  usb: quiet peer failure warning, disable poweroff
  usb: fix hub-port pm_runtime_enable() vs runtime pm transitions


 drivers/usb/core/hub.c  |9 -
 drivers/usb/core/hub.h  |2 +
 drivers/usb/core/port.c |   89 ++-
 3 files changed, 75 insertions(+), 25 deletions(-)
--
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 2/3] usb: quiet peer failure warning, disable poweroff

[Dan Williams]

In the case where platform firmware has specified conflicting values for
port locations it is confusing and otherwise not helpful to throw a
backtrace.  Instead, include enough information to determine that
firmware has done something wrong and globally disable port poweroff.

Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/core/port.c |   24 +++-
 1 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 62036faf56c0..9347ade7d5fe 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -21,6 +21,8 @@
 
 #include hub.h
 
+static int usb_port_block_power_off;
+
 static const struct attribute_group *port_dev_group[];
 
 static ssize_t connect_type_show(struct device *dev,
@@ -142,6 +144,9 @@ static int usb_port_runtime_suspend(struct device *dev)
== PM_QOS_FLAGS_ALL)
return -EAGAIN;
 
+   if (usb_port_block_power_off)
+   return -EBUSY;
+
usb_autopm_get_interface(intf);
retval = usb_hub_set_port_power(hdev, hub, port1, false);
usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_C_CONNECTION);
@@ -190,11 +195,19 @@ static int link_peers(struct usb_port *left, struct 
usb_port *right)
if (left-peer || right-peer) {
struct usb_port *lpeer = left-peer;
struct usb_port *rpeer = right-peer;
-
-   WARN(1, failed to peer %s and %s (%s - %p) (%s - %p)\n,
-   dev_name(left-dev), dev_name(right-dev),
-   dev_name(left-dev), lpeer,
-   dev_name(right-dev), rpeer);
+   char *method;
+
+   if (left-location  left-location == right-location)
+   method = location;
+   else
+   method = default;
+
+   pr_warn(usb: failed to peer %s and %s by %s (%s:%s) (%s:%s)\n,
+   dev_name(left-dev), dev_name(right-dev), method,
+   dev_name(left-dev),
+   lpeer ? dev_name(lpeer-dev) : none,
+   dev_name(right-dev),
+   rpeer ? dev_name(rpeer-dev) : none);
return -EBUSY;
}
 
@@ -251,6 +264,7 @@ static void link_peers_report(struct usb_port *left, struct 
usb_port *right)
dev_warn(left-dev, failed to peer to %s (%d)\n,
dev_name(right-dev), rc);
pr_warn_once(usb: port power management may be unreliable\n);
+   usb_port_block_power_off = 1;
}
 }
 

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

[PATCH 3/3] usb: fix hub-port pm_runtime_enable() vs runtime pm transitions

[Dan Williams]

Commit 9262c19d14c4 usb: disable port power control if not supported in
wHubCharacteristics gated enabling runtime pm for usb_port devices on
whether the parent hub supports power control, which causes a
regression.  The port must still be allowed to carry out runtime pm
callbacks and receive a -EAGAIN or -EBUSY result.  Otherwise the
usb_port device will transition to the pm error state and trigger the
same for the child usb_device.

Prior to the offending commit usb_hub_create_port_device() arranged for
runtime pm to be disabled is dev_pm_qos_expose_flags() failed.  Instead,
force the default state of PM_QOS_FLAG_NO_POWER_OFF flag to be set prior
to enabling runtime pm.  If that policy can not be set then fail
registration.

Report: http://marc.info/?l=linux-usbm=140290586301336w=2
Fixes: 9262c19d14c4 (usb: disable port power control if not supported in 
wHubCharacteristics)
Reported-by: Bjørn Mork bj...@mork.no
Reported-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/core/hub.c  |6 
 drivers/usb/core/hub.h  |2 +
 drivers/usb/core/port.c |   65 +--
 3 files changed, 54 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 6ac87cbf3af7..e476e767c8de 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1589,6 +1589,12 @@ static int hub_configure(struct usb_hub *hub,
}
}
hdev-maxchild = i;
+   for (i = 0; i  hdev-maxchild; i++) {
+   struct usb_port *port_dev = hub-ports[i];
+
+   pm_runtime_put(port_dev-dev);
+   }
+
mutex_unlock(usb_port_peer_mutex);
if (ret  0)
goto fail;
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 0a7cdc0ef0a9..326308e53961 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -84,6 +84,7 @@ struct usb_hub {
  * @dev: generic device interface
  * @port_owner: port's owner
  * @peer: related usb2 and usb3 ports (share the same connector)
+ * @req: default pm qos request for hubs without port power control
  * @connect_type: port's connect type
  * @location: opaque representation of platform connector location
  * @status_lock: synchronize port_event() vs usb_port_{suspend|resume}
@@ -95,6 +96,7 @@ struct usb_port {
struct device dev;
struct usb_dev_state *port_owner;
struct usb_port *peer;
+   struct dev_pm_qos_request *req;
enum usb_port_connect_type connect_type;
usb_port_location_t location;
struct mutex status_lock;
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 9347ade7d5fe..fe1b6d0967e3 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -68,6 +68,7 @@ static void usb_port_device_release(struct device *dev)
 {
struct usb_port *port_dev = to_usb_port(dev);
 
+   kfree(port_dev-req);
kfree(port_dev);
 }
 
@@ -400,9 +401,13 @@ int usb_hub_create_port_device(struct usb_hub *hub, int 
port1)
int retval;
 
port_dev = kzalloc(sizeof(*port_dev), GFP_KERNEL);
-   if (!port_dev) {
-   retval = -ENOMEM;
-   goto exit;
+   if (!port_dev)
+   return -ENOMEM;
+
+   port_dev-req = kzalloc(sizeof(*(port_dev-req)), GFP_KERNEL);
+   if (!port_dev-req) {
+   kfree(port_dev);
+   return -ENOMEM;
}
 
hub-ports[port1 - 1] = port_dev;
@@ -418,31 +423,53 @@ int usb_hub_create_port_device(struct usb_hub *hub, int 
port1)
port1);
mutex_init(port_dev-status_lock);
retval = device_register(port_dev-dev);
-   if (retval)
-   goto error_register;
+   if (retval) {
+   put_device(port_dev-dev);
+   return retval;
+   }
+
+   /* Set default policy of port-poweroff disabled. */
+   retval = dev_pm_qos_add_request(port_dev-dev, port_dev-req,
+   DEV_PM_QOS_FLAGS, PM_QOS_FLAG_NO_POWER_OFF);
+   if (retval  0) {
+   device_unregister(port_dev-dev);
+   return retval;
+   }
 
find_and_link_peer(hub, port1);
 
+   /*
+* Enable runtime pm and hold a refernce that hub_configure()
+* will drop once the PM_QOS_NO_POWER_OFF flag state has been set
+* and the hub has been fully registered (hdev-maxchild set).
+*/
pm_runtime_set_active(port_dev-dev);
+   pm_runtime_get_noresume(port_dev-dev);
+   pm_runtime_enable(port_dev-dev);
+   device_enable_async_suspend(port_dev-dev);
 
/*
-* Do not enable port runtime pm if the hub does not support
-* power switching.  Also, userspace must have final say of
-* whether a port is permitted to power-off.  Do not enable
-* runtime pm if we fail to expose pm_qos_no_power_off.
+* Keep hidden the ability

[PATCH 1/3] usb: improve not suspended yet message in hub_suspend()

[Dan Williams]

Reading through a recent bug report [1], Alan notes:

  Dan, the warning message in hub_suspend() should mention that the
   child device isn't suspended yet.

...update the warning from:

  usb usb3-port4: not suspended yet

...to:

   usb usb3-port4: device 3-4: not suspended yet

[1]: http://marc.info/?l=linux-usbm=140290586301336w=2

Reported-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
 drivers/usb/core/hub.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 879b66e13370..6ac87cbf3af7 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3458,7 +3458,8 @@ static int hub_suspend(struct usb_interface *intf, 
pm_message_t msg)
struct usb_device *udev = port_dev-child;
 
if (udev  udev-can_submit) {
-   dev_warn(port_dev-dev, not suspended yet\n);
+   dev_warn(port_dev-dev, device %s not suspended 
yet\n,
+   dev_name(udev-dev));
if (PMSG_IS_AUTO(msg))
return -EBUSY;
}

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

Re: [PATCH 0/3] port power control fixes for 3.16-rc2

[Dan Williams]

On Tue, Jun 17, 2014 at 5:06 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Tue, Jun 17, 2014 at 04:16:16PM -0700, Dan Williams wrote:
 Fallout / regression fixes for the port power control rework that landed
 in 3.16-rc1.

 1/ Cosmetic fix to an error message

 2/ Handle ACPI port-location-data conflicts by disabling port power off
rather than spewing a backtrace and trying to continue.

 3/ Handle hubs that do not support port power off by enforcing the
PM_QOS_NO_POWER_OFF constraint from the kernel rather than disabling
runtime power management.

 All now applied, along with your previously sent patch.  Have I missed
 anything else pending from you for 3.16-final?

This is all I had pending.

I put patch 3 usb: fix hub-port pm_runtime_enable() vs runtime pm
transitions through it's paces, but I'd still like to see a positive
test report from Bjørn... even if it's too late to add a Tested-by.
--
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