Re: [PATCH 2/2] usb: serial: option: add Cellient MPL200 card

[Lars Melin]

On 10/5/2020 18:06, Johan Hovold wrote:

On Mon, Oct 05, 2020 at 01:01:34PM +0200, Wilken Gottwalt wrote:

On Mon, 5 Oct 2020 10:20:45 +0200
Johan Hovold  wrote:


On Sat, Oct 03, 2020 at 11:40:29AM +0200, Wilken Gottwalt wrote:

Add usb ids of the Cellient MPL200 card.

Signed-off-by: Wilken Gottwalt 
---



@@ -1982,6 +1983,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 
MEDIATEK_PRODUCT_DC_4COM2, 0xff,
0x02, 0x01) }, { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 
MEDIATEK_PRODUCT_DC_4COM2,
0xff, 0x00, 0x00) }, { USB_DEVICE(CELLIENT_VENDOR_ID, CELLIENT_PRODUCT_MEN200) 
},
+   { USB_DEVICE(CELLIENT_VENDOR_ID, CELLIENT_PRODUCT_MPL200),
+ .driver_info = RSVD(1) | RSVD(4) },


Would you mind posting the output of "lsusb -v" for this device?


I would like to, but unfortunately I lost access to this really rare hardware
about a month ago. It is a Qualcomm device (0x05c6:0x9025) with a slightly
modified firmware to rebrand it as a Cellient product with a different vendor
id. How to proceed here, if I have no access to it anymore? Drop it?


No, that's ok, I've applied the patch now. It's just that in case we
ever need to revisit the handling of quirky devices, it has proven
useful to have a record the descriptors.

Do you remember the interface layout and why you blacklisted interface
1?

Johan



It is very likely that Cellient has replaced the VID with their own and 
kept the PID, it is something other mfgrs has done when buying modules 
from Qualcomm's series of devices with predefined composition.


The MS Windows driver for 05c6:9025 describes the interfaces as:

MI_00 Qualcomm HS-USB Diagnostics 9025
MI_01 Android Composite ADB Interface
MI_02 Qualcomm HS-USB Android Modem 9025
MI_03 Qualcomm HS-USB NMEA 9025
MI_04 Qualcomm Wireless HS-USB Ethernet Adapter 9025
MI_05 USB Mass Storage Device

where the net interface is for QMI/RMNET.
It fully matches the blacklisting Wilken has done for 2692:9025

br
Lars

Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition

[Lars Melin]

On 10/4/2020 23:03, Leonid Bloch wrote:

Lars,


Thank you for your review! The changes which you have suggested also 
made ModemManager to recognize the device (which it didn't do before). 
Please check out the v2.



Cheers,
Leonid.


The v2 looks good to me

br
Lars

Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition

[Lars Melin]

On 10/4/2020 21:16, Lars Melin wrote:

On 10/4/2020 20:29, Leonid Bloch wrote:

On 10/4/20 1:58 PM, Lars Melin wrote:

On 10/4/2020 16:57, Leonid Bloch wrote:

This commit adds the following Telit FT980-KS composition:

0x1054: rndis, diag, adb, nmea, modem, modem, aux

AT commands can be sent to /dev/ttyUSB5.



Please submit a verbose lsusb listing for the device, I can't imagine
that the adb interface should be handled by the option serial driver so
there will never be a ttyUSB5.


Please see below.

Thanks,
Leonid.

```
Bus 001 Device 005: ID 1bc7:1054 Telit Wireless Solutions
Device Descriptor:
   bLength    18
   bDescriptorType 1
   bcdUSB   2.10
   bDeviceClass    0
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize0    64
   idVendor   0x1bc7 Telit Wireless Solutions
   idProduct  0x1054
   bcdDevice    4.14
   iManufacturer   1 Telit Wireless Solutions
   iProduct    2 FT980-KS
   iSerial 3 cb42f61
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   0x013d
 bNumInterfaces  8
 bConfigurationValue 1
 iConfiguration  4 RNDIS_DIAG_ADB_NMEA_DUN_DUN_SER
 bmAttributes 0xa0
   (Bus Powered)
   Remote Wakeup
 MaxPower  500mA
 Interface Association:
   bLength 8
   bDescriptorType    11
   bFirstInterface 0
   bInterfaceCount 2
   bFunctionClass    239 Miscellaneous Device
   bFunctionSubClass   4
   bFunctionProtocol   1
   iFunction   7 RNDIS
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber    0
   bAlternateSetting   0
   bNumEndpoints   1
   bInterfaceClass   239 Miscellaneous Device
   bInterfaceSubClass  4
   bInterfaceProtocol  1
   iInterface  5 RNDIS Communications Control
   ** UNRECOGNIZED:  05 24 00 10 01
   ** UNRECOGNIZED:  05 24 01 00 01
   ** UNRECOGNIZED:  04 24 02 00
   ** UNRECOGNIZED:  05 24 06 00 01
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes    3
   Transfer Type    Interrupt
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0008  1x 8 bytes
 bInterval   9
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber    1
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass    10 CDC Data
   bInterfaceSubClass  0
   bInterfaceProtocol  0
   iInterface  6 RNDIS Ethernet Data
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x8e  EP 14 IN
 bmAttributes    2
   Transfer Type    Bulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x0f  EP 15 OUT
 bmAttributes    2
   Transfer Type    Bulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber    2
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass    255 Vendor Specific Subclass
   bInterfaceProtocol 48
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x82  EP 2 IN
 bmAttributes    2
   Transfer Type    Bulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x01  EP 1 OUT
 bmAttributes    2
   Transfer Type    Bulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval   0
 Interface Descriptor:
   bLength 9

Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition

[Lars Melin]

On 10/4/2020 20:29, Leonid Bloch wrote:

On 10/4/20 1:58 PM, Lars Melin wrote:

On 10/4/2020 16:57, Leonid Bloch wrote:

This commit adds the following Telit FT980-KS composition:

0x1054: rndis, diag, adb, nmea, modem, modem, aux

AT commands can be sent to /dev/ttyUSB5.



Please submit a verbose lsusb listing for the device, I can't imagine
that the adb interface should be handled by the option serial driver so
there will never be a ttyUSB5.


Please see below.

Thanks,
Leonid.

```
Bus 001 Device 005: ID 1bc7:1054 Telit Wireless Solutions
Device Descriptor:
   bLength    18
   bDescriptorType 1
   bcdUSB   2.10
   bDeviceClass    0
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize0    64
   idVendor   0x1bc7 Telit Wireless Solutions
   idProduct  0x1054
   bcdDevice    4.14
   iManufacturer   1 Telit Wireless Solutions
   iProduct    2 FT980-KS
   iSerial 3 cb42f61
   bNumConfigurations  1
   Configuration Descriptor:
     bLength 9
     bDescriptorType 2
     wTotalLength   0x013d
     bNumInterfaces  8
     bConfigurationValue 1
     iConfiguration  4 RNDIS_DIAG_ADB_NMEA_DUN_DUN_SER
     bmAttributes 0xa0
   (Bus Powered)
   Remote Wakeup
     MaxPower  500mA
     Interface Association:
   bLength 8
   bDescriptorType    11
   bFirstInterface 0
   bInterfaceCount 2
   bFunctionClass    239 Miscellaneous Device
   bFunctionSubClass   4
   bFunctionProtocol   1
   iFunction   7 RNDIS
     Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber    0
   bAlternateSetting   0
   bNumEndpoints   1
   bInterfaceClass   239 Miscellaneous Device
   bInterfaceSubClass  4
   bInterfaceProtocol  1
   iInterface  5 RNDIS Communications Control
   ** UNRECOGNIZED:  05 24 00 10 01
   ** UNRECOGNIZED:  05 24 01 00 01
   ** UNRECOGNIZED:  04 24 02 00
   ** UNRECOGNIZED:  05 24 06 00 01
   Endpoint Descriptor:
     bLength 7
     bDescriptorType 5
     bEndpointAddress 0x81  EP 1 IN
     bmAttributes    3
   Transfer Type    Interrupt
   Synch Type   None
   Usage Type   Data
     wMaxPacketSize 0x0008  1x 8 bytes
     bInterval   9
     Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber    1
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass    10 CDC Data
   bInterfaceSubClass  0
   bInterfaceProtocol  0
   iInterface  6 RNDIS Ethernet Data
   Endpoint Descriptor:
     bLength 7
     bDescriptorType 5
     bEndpointAddress 0x8e  EP 14 IN
     bmAttributes    2
   Transfer Type    Bulk
   Synch Type   None
   Usage Type   Data
     wMaxPacketSize 0x0200  1x 512 bytes
     bInterval   0
   Endpoint Descriptor:
     bLength 7
     bDescriptorType 5
     bEndpointAddress 0x0f  EP 15 OUT
     bmAttributes    2
   Transfer Type    Bulk
   Synch Type   None
   Usage Type   Data
     wMaxPacketSize 0x0200  1x 512 bytes
     bInterval   0
     Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber    2
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass    255 Vendor Specific Subclass
   bInterfaceProtocol 48
   iInterface  0
   Endpoint Descriptor:
     bLength 7
     bDescriptorType 5
     bEndpointAddress 0x82  EP 2 IN
     bmAttributes    2
   Transfer Type    Bulk
   Synch Type   None
   Usage Type   Data
     wMaxPacketSize 0x0200  1x 512 bytes
     bInterval   0
   Endpoint Descriptor:
     bLength 7
     bDescriptorType 5
     bEndpointAddress 0x01  EP 1 OUT
     bmAttributes    2
   Transfer Type    Bulk
   Synch Type   None
   Usage Type   Data
     wMaxPacketSize 0x0200  1x 512 bytes
     bInterval   0
     Interface Descriptor:
   bLength 9
   bDescriptorType 4

Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition

[Lars Melin]

On 10/4/2020 16:57, Leonid Bloch wrote:

This commit adds the following Telit FT980-KS composition:

0x1054: rndis, diag, adb, nmea, modem, modem, aux

AT commands can be sent to /dev/ttyUSB5.



Please submit a verbose lsusb listing for the device, I can't imagine 
that the adb interface should be handled by the option serial driver so 
there will never be a ttyUSB5.



thanks
Lars

Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

[Lars Melin]

On 9/10/2020 10:02, Oliver Neukum wrote:

Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:

This patch detects and reverses the effects of the malicious FTDI
Windows driver version 2.12.00(FTDIgate).


Hi,

this raises questions.
Should we do this unconditionally without asking?
Does this belong into kernel space?



My answer to both of those question is a strong NO.

The patch author tries to justify the patch with egoistical arguments 
(easier for him and his customers) without thinking of all other users 
of memory constrained embedded hardware that doesn't need the patch code 
but have to carry it.


The bricked PID is btw already supported by the linux ftdi driver so 
there is no functionality gain in the patch.


br
Lars

Re: [PATCH AUTOSEL 4.14 17/33] net: usb: qmi_wwan: add Telit 0x1050 composition

[Lars Melin]

On 9/8/2020 01:15, Sasha Levin wrote:

On Mon, Sep 07, 2020 at 11:36:37AM +0200, Kristian Evensen wrote:

// snip


When testing the FN980 with kernel 4.14, I noticed that the qmi device
was not there. Checking the git log, I see that this patch was never
applied. The patch applies fine, so I guess it was just missed
somewhere. If it could be added to the next 4.14 release, it would be
much appreciated.


Interesting, yes - I'm not sure why it's missing. I'll queue it up.



The patch is missing from all 4.x LTS kernels, not only 4.14


br
Lars

Re: [PATCH] HID: quirks: Add USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for BYD zhaoxin notebook

[Lars Melin]

On 9/4/2020 08:48, Penghao wrote:


--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -387,6 +387,10 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x0b05, 0x17e0), .driver_info =
USB_QUIRK_IGNORE_REMOTE_WAKEUP },
  
+	/* SONiX USB DEVICE Touchpad */

+   { USB_DEVICE(0x0c45, 0x7056), .driver_info =
+   USB_QUIRK_IGNORE_REMOTE_WAKEUP },
+
/* Realtek hub in Dell WD19 (Type-C) */
{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
  



This list was sorted in a beautiful ascending order of vid, pid before 
you entered your quirk..


rgds
Lars

Re: [PATCH] ALSA: usb-audio: quirks: Add USB_QUIRK_DISCONNECT_SUSPEND quirk for Lenovo A630Z TIO built-in usb audio card

[Lars Melin]

On 9/4/2020 08:45, Penghao wrote:


--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -403,6 +403,10 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x12d1, 0x15c3), .driver_info =
USB_QUIRK_DISCONNECT_SUSPEND },
  
+	/* Lenovo A630Z TIO build-in usb sound card */

+   { USB_DEVICE9(0x17ef, 0xa012), driver_info =
+   USB_QUIRK_DISCONNECT_SUSPEND },
+
/* SKYMEDI USB_DRIVE */
{ USB_DEVICE(0x1516, 0x8628), .driver_info = USB_QUIRK_RESET_RESUME },
  



This list was sorted in a beautiful ascending order of vid, pid before 
you entered your quirk..


rgds
Lars

Re: [PATCH v2] usb: typec: mux: intel: Fix DP_HPD_LVL bit field

[Lars Melin]

On 5/11/2020 04:39, Prashant Malani wrote:

According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
0.6, the PMC HPD request LVL bit field is bit 4.
Fix the definition here to match the programming guide.

Since this bit field is changing, explicitly define a field for the
HPD_HIGH mode data bit.

Signed-off-by: Prashant Malani 
Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
Reviewed-by: Benson Leung 
---

Changes in v2:
- Fixed bit error in commit message.

  drivers/usb/typec/mux/intel_pmc_mux.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c 
b/drivers/usb/typec/mux/intel_pmc_mux.c
index 67c5139cfa0d..15074aec94eb 100644
--- a/drivers/usb/typec/mux/intel_pmc_mux.c
+++ b/drivers/usb/typec/mux/intel_pmc_mux.c
@@ -63,6 +63,7 @@ enum {
  #define PMC_USB_ALTMODE_DP_MODE_SHIFT 8
  
  /* TBT specific Mode Data bits */

+#define PMC_USB_ALTMODE_HPD_HIGH   BIT(14)
  #define PMC_USB_ALTMODE_TBT_TYPE  BIT(17)
  #define PMC_USB_ALTMODE_CABLE_TYPEBIT(18)
  #define PMC_USB_ALTMODE_ACTIVE_LINK   BIT(20)
@@ -75,7 +76,7 @@ enum {
  
  /* Display HPD Request bits */

  #define PMC_USB_DP_HPD_IRQBIT(5)
-#define PMC_USB_DP_HPD_LVL BIT(6)
+#define PMC_USB_DP_HPD_LVL BIT(4)
  

Please keep the bits sorted


  struct pmc_usb;
  
@@ -158,8 +159,7 @@ pmc_usb_mux_dp(struct pmc_usb_port *port, struct typec_mux_state *state)

 PMC_USB_ALTMODE_DP_MODE_SHIFT;
  
  	if (data->status & DP_STATUS_HPD_STATE)

-   req.mode_data |= PMC_USB_DP_HPD_LVL <<
-PMC_USB_ALTMODE_DP_MODE_SHIFT;
+   req.mode_data |= PMC_USB_ALTMODE_HPD_HIGH;
  
  	return pmc_usb_command(port, (void *), sizeof(req));

  }



Thanks
Lars

Re: [PATCH] USB: serial: option: Add Motorola modem UARTs

[Lars Melin]

On 7/23/2019 21:49, Tony Lindgren wrote:


+#define MOTOROLA_VENDOR_ID 0x22b8
+#define MOTOROLA_PRODUCT_MDM6600   0x2a70
+#define MOTOROLA_PRODUCT_MDM9600   0x2e0a
+#define MOTOROLA_PRODUCT_MDM_RAM_DL0x4281
+#define MOTOROLA_PRODUCT_MDM_QC_DL 0x900e
+


Johan, when he is back from vacation, will tell you to drop those 
defines and instead use the values directly in the list with a comment 
behind reflecting the device model.

Just telling you so you can save time by sending out your v2 early..


best rgds
/Lars

Re: [PATCH v7 0/6] Introduced new Cadence USBSS DRD Driver.

[Lars Melin]

On 6/5/2019 17:03, Pawel Laszczak wrote:

This patch introduces new Cadence USBSS DRD driver to Linux kernel.

The Cadence USBSS DRD Driver is a highly configurable IP Core which
can be instantiated as Dual-Role Device (DRD), Peripheral Only and
Host Only (XHCI)configurations.


The driver is not an IP Core, the hardware device is.


/Lars

Re: [PATCH] option: Improve Quectel EP06 detection

[Lars Melin]

On 9/10/2018 18:39, Kristian Evensen wrote:

Hi,

On Mon, Sep 10, 2018 at 12:30 PM Johan Hovold  wrote:

Please provide the output of usb-devices (or lsusb -v) for both
"configurations". How do you update the configuration by the way?


The configuration is updated using a proprietary AT-command
(AT+QCFG="usbcfg"). The format of the command is as follows:
AT+QCFG="usbcfg".
In other words, you set which interfaces to enable/disable. Based on
my testing, it is only possible to enable/disable diag, rmnet (QMI)
and adb, as well as nmea, at_port and modem together. I.e., it is not
possible to only disable for example nmea.




If I for example disable diag, then the bInterfaceNumber of nmea
changes from 1 to 0, at from 2 to 1, etc., etc.

BR,
Kristian



This also becomes a mess for the qmi-wwan driver which has the rmnet/qmi 
interface hardcoded to 4 so that driver will also need a workaround.
Quectel seems to have completely missed the reason why usb id's should 
be unique and not reused  for a different product or a different 
interface layout, there is already a workaround in qmi-wwan for their 
previous EC-20 card...
My opinion is that the option and qmi-wwan drivers should support EP06 
in the factory delivery configuration and not in a configuration the 
user has selected with a Quectel proprietary AT cmd.
Can you give some good reason for disabling an interface instead of 
letting it stay but not use it if you don't need it?



Thanks
/Lars

Re: [PATCH] option: Improve Quectel EP06 detection

[Lars Melin]

On 9/10/2018 18:39, Kristian Evensen wrote:

Hi,

On Mon, Sep 10, 2018 at 12:30 PM Johan Hovold  wrote:

Please provide the output of usb-devices (or lsusb -v) for both
"configurations". How do you update the configuration by the way?


The configuration is updated using a proprietary AT-command
(AT+QCFG="usbcfg"). The format of the command is as follows:
AT+QCFG="usbcfg".
In other words, you set which interfaces to enable/disable. Based on
my testing, it is only possible to enable/disable diag, rmnet (QMI)
and adb, as well as nmea, at_port and modem together. I.e., it is not
possible to only disable for example nmea.




If I for example disable diag, then the bInterfaceNumber of nmea
changes from 1 to 0, at from 2 to 1, etc., etc.

BR,
Kristian



This also becomes a mess for the qmi-wwan driver which has the rmnet/qmi 
interface hardcoded to 4 so that driver will also need a workaround.
Quectel seems to have completely missed the reason why usb id's should 
be unique and not reused  for a different product or a different 
interface layout, there is already a workaround in qmi-wwan for their 
previous EC-20 card...
My opinion is that the option and qmi-wwan drivers should support EP06 
in the factory delivery configuration and not in a configuration the 
user has selected with a Quectel proprietary AT cmd.
Can you give some good reason for disabling an interface instead of 
letting it stay but not use it if you don't need it?



Thanks
/Lars

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

[Lars Melin]

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:

   * Gobi 1K USB layout:
   * 0: DM/DIAG (use libqcdm from ModemManager for communication)
   * 1: serial port (doesn't respond)
   * 2: AT-capable modem port
   * 3: QMI/net
   */



Ublox, not Quectel..


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.

Thanks,
Johan


Good point, I forgot about the required firmware loading for Gobi1K.
So this device should be handled by the option driver.

/Lars

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

[Lars Melin]

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:

   * Gobi 1K USB layout:
   * 0: DM/DIAG (use libqcdm from ModemManager for communication)
   * 1: serial port (doesn't respond)
   * 2: AT-capable modem port
   * 3: QMI/net
   */



Ublox, not Quectel..


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.

Thanks,
Johan


Good point, I forgot about the required firmware loading for Gobi1K.
So this device should be handled by the option driver.

/Lars

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

[Lars Melin]

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:


  * Gobi 1K USB layout:
  * 0: DM/DIAG (use libqcdm from ModemManager for communication)
  * 1: serial port (doesn't respond)
  * 2: AT-capable modem port
  * 3: QMI/net
  */

/Lars


Ublox, not Quectel..

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

[Lars Melin]

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:


  * Gobi 1K USB layout:
  * 0: DM/DIAG (use libqcdm from ModemManager for communication)
  * 1: serial port (doesn't respond)
  * 2: AT-capable modem port
  * 3: QMI/net
  */

/Lars


Ublox, not Quectel..

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

[Lars Melin]

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:


 * Gobi 1K USB layout:
 * 0: DM/DIAG (use libqcdm from ModemManager for communication)
 * 1: serial port (doesn't respond)
 * 2: AT-capable modem port
 * 3: QMI/net
 */

/Lars

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

[Lars Melin]

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:


 * Gobi 1K USB layout:
 * 0: DM/DIAG (use libqcdm from ModemManager for communication)
 * 1: serial port (doesn't respond)
 * 2: AT-capable modem port
 * 3: QMI/net
 */

/Lars

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

[Lars Melin]

On 4/26/2018 14:09, Johan Hovold wrote:

On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:

This patch adds support for ublox R410M PID 0x90b2 USB modem to option
driver, this module supports LTE Cat M1 / NB1.

Interface layout:
0: QCDM/DIAG
1: ADB
2: AT
3: RMNET

Signed-off-by: SZ Lin (林上智) 
Cc: stable 


Applied, thanks.

Johan


With a Qualcomm Device Management interface, shouldn't this modem be 
driven by qcserial?


/Lars

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

[Lars Melin]

On 4/26/2018 14:09, Johan Hovold wrote:

On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:

This patch adds support for ublox R410M PID 0x90b2 USB modem to option
driver, this module supports LTE Cat M1 / NB1.

Interface layout:
0: QCDM/DIAG
1: ADB
2: AT
3: RMNET

Signed-off-by: SZ Lin (林上智) 
Cc: stable 


Applied, thanks.

Johan


With a Qualcomm Device Management interface, shouldn't this modem be 
driven by qcserial?


/Lars

Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819

[Lars Melin]

On 11/20/2017 16:27, Shrirang Bagul wrote:

Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series modems which will by default boot with vid 0x413c and pid's
0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
qmi_wwan on the usb interface #12.

Signed-off-by: Shrirang Bagul 
---
  drivers/net/usb/qmi_wwan.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8d4a6f7cba61..bdf1fae38af2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1234,6 +1234,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)},   /* Dell Wireless 5811e */
+   {QMI_FIXED_INTF(0x413c, 0x81cf, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d0, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d1, 12)},   /* Dell Wireless 5818 */
+   {QMI_FIXED_INTF(0x413c, 0x81d2, 12)},   /* Dell Wireless 5818 */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */




NAK

413c:81cf and 413c:81d1 do not have a net interface, they only have a 
single serial interface (QDL) for firmware update.
Please do not add usb id's for which you have not confirmed the 
interface composition.


br
Lars

Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819

[Lars Melin]

On 11/20/2017 16:27, Shrirang Bagul wrote:

Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series modems which will by default boot with vid 0x413c and pid's
0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
qmi_wwan on the usb interface #12.

Signed-off-by: Shrirang Bagul 
---
  drivers/net/usb/qmi_wwan.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8d4a6f7cba61..bdf1fae38af2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1234,6 +1234,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)},   /* Dell Wireless 5811e */
+   {QMI_FIXED_INTF(0x413c, 0x81cf, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d0, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d1, 12)},   /* Dell Wireless 5818 */
+   {QMI_FIXED_INTF(0x413c, 0x81d2, 12)},   /* Dell Wireless 5818 */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */




NAK

413c:81cf and 413c:81d1 do not have a net interface, they only have a 
single serial interface (QDL) for firmware update.
Please do not add usb id's for which you have not confirmed the 
interface composition.


br
Lars

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

[Lars Melin]

On 2017-03-25 01:58, Bin Liu wrote:

On Wed, Mar 15, 2017 at 09:08:01AM -0500, Moreno Bartalucci wrote:

With usb-musb port in host mode, when the device
is disconnected, either logically (because of a mode switch) or
physically (by pulling the cable), the USB port should keep
suppling VBUS, with no interruption, to prevent power loss on
USB powered devices.


The usb device has been disconnected, why it still cares about VBUS
power?


Morphing devices (3G dongles, wifi dongles, some printers) boots up in 
install mode, usually only as a virtual cd-rom containing Windows 
drivers and software.

They get switched into functional mode by usb_modeswitch sending them
a ctrl msg which makes the device disappear from the USB bus for a very 
short time after which it re-appears with a different interface 
composition and mostly also a different USB Id.


Cutting the VBUS supply while these devices are in progress of switching 
will inhibit switching, the device will reboot when VBUS is again 
asserted and will come up in initial mode as if no switch ctrl msg had 
ever been sent to it.


The problem has been seen both on host only as well as dual-role port 
configs. Dual-role may be a bit more complicated to solve because of

the role switching VBUS detection circuit but I can not see any reason
why a host only configured port should cut the VBUS supply, it could be 
always on right?



/Lars

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

[Lars Melin]

On 2017-03-25 01:58, Bin Liu wrote:

On Wed, Mar 15, 2017 at 09:08:01AM -0500, Moreno Bartalucci wrote:

With usb-musb port in host mode, when the device
is disconnected, either logically (because of a mode switch) or
physically (by pulling the cable), the USB port should keep
suppling VBUS, with no interruption, to prevent power loss on
USB powered devices.


The usb device has been disconnected, why it still cares about VBUS
power?


Morphing devices (3G dongles, wifi dongles, some printers) boots up in 
install mode, usually only as a virtual cd-rom containing Windows 
drivers and software.

They get switched into functional mode by usb_modeswitch sending them
a ctrl msg which makes the device disappear from the USB bus for a very 
short time after which it re-appears with a different interface 
composition and mostly also a different USB Id.


Cutting the VBUS supply while these devices are in progress of switching 
will inhibit switching, the device will reboot when VBUS is again 
asserted and will come up in initial mode as if no switch ctrl msg had 
ever been sent to it.


The problem has been seen both on host only as well as dual-role port 
configs. Dual-role may be a bit more complicated to solve because of

the role switching VBUS detection circuit but I can not see any reason
why a host only configured port should cut the VBUS supply, it could be 
always on right?



/Lars

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

[Lars Melin]

On 2016-07-19 13:40, Kristian Evensen wrote:


I guess I can match on the VID/PID in usbnet, but won't it be cleaner
to add a new bind() function (in cdc_ether) which matches the two PIDs
and leave usbnet as is? Or am I misunderstanding how to add this
functionality to usbnet?



Matching on the usb id is probably not a great idea, there is more id's
than the two you have found and there is also more than two non-unique 
mac addresses.


Example:

0200FFAA  19d2:1589/1592/1595
020CE70B0102  19d2:1040/1048/1405

You can easily find them by googling them, without colon separators you
will find them in verbose lsusb listings, with colons you will find them 
in dmesg pastings.


I would probably have found more dupes if users had refrained from using 
the stupid usbdevices cmd which removes almost all interesting info from 
device listings in internet foras.


/Lars

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

[Lars Melin]

On 2016-07-19 13:40, Kristian Evensen wrote:


I guess I can match on the VID/PID in usbnet, but won't it be cleaner
to add a new bind() function (in cdc_ether) which matches the two PIDs
and leave usbnet as is? Or am I misunderstanding how to add this
functionality to usbnet?



Matching on the usb id is probably not a great idea, there is more id's
than the two you have found and there is also more than two non-unique 
mac addresses.


Example:

0200FFAA  19d2:1589/1592/1595
020CE70B0102  19d2:1040/1048/1405

You can easily find them by googling them, without colon separators you
will find them in verbose lsusb listings, with colons you will find them 
in dmesg pastings.


I would probably have found more dupes if users had refrained from using 
the stupid usbdevices cmd which removes almost all interesting info from 
device listings in internet foras.


/Lars

Re: [PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade

[Lars Melin]

On 2015-10-24 22:44, Michele Baldessari wrote:

The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order
to have the two distinct joysticks working.

Before the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
jstest: No such file or directory

After the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...

Signed-off-by: Michele Baldessari 
---
  drivers/hid/usbhid/hid-quirks.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 1dff8f0015ba..f69049314a2c 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -150,6 +150,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MULTIPLE_1781, USB_DEVICE_ID_RAPHNET_4NES4SNES_OLD, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES, 
HID_QUIRK_MULTI_INPUT },
+   { USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE, 
HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },

{ 0, 0 }
  };



Sorry but I don't believe that XIN_MO is the owner of the 16c0 VID so 
should not be given that ownership in linux.


/Lars

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

Re: [PATCH] HID: usbhid: Add a quirk for Xin-Mo Dual Arcade

[Lars Melin]

On 2015-10-24 22:44, Michele Baldessari wrote:

The Xin-Mo Dual Arcade controller (16c0:05e1) needs this quirk in order
to have the two distinct joysticks working.

Before the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
jstest: No such file or directory

After the change:
$ jstest /dev/input/js0
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...
$ jstest /dev/input/js1
Joystick (Xin-Mo Xin-Mo Dual Arcade) has 2 axes (X, Y)
...

Signed-off-by: Michele Baldessari 
---
  drivers/hid/usbhid/hid-quirks.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 1dff8f0015ba..f69049314a2c 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -150,6 +150,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MULTIPLE_1781, USB_DEVICE_ID_RAPHNET_4NES4SNES_OLD, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES, 
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES, 
HID_QUIRK_MULTI_INPUT },
+   { USB_VENDOR_ID_XIN_MO, USB_DEVICE_ID_XIN_MO_DUAL_ARCADE, 
HID_QUIRK_NOGET | HID_QUIRK_MULTI_INPUT },

{ 0, 0 }
  };



Sorry but I don't believe that XIN_MO is the owner of the 16c0 VID so 
should not be given that ownership in linux.


/Lars

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

Re: [PATCH] usb: core: hub: Removed some warnings generated by checkpatch.pl

[Lars Melin]

On 2015-08-15 11:41, Chase Metzger wrote:

Removed some checkpatch.pl warnings saying there was an unwanted space between
function names and their arguments.

Signed-off-by: Chase Metzger 
---
  drivers/usb/core/hub.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 38cb6d3..b9cab51 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4218,7 +4218,7 @@ static int hub_enable_device(struct usb_device *udev)
   * but it is still necessary to lock the port.
   */
  static int
-hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,
+hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
int retry_counter)
  {
struct usb_device   *hdev = hub->hdev;
@@ -4522,7 +4522,7 @@ fail:
  }

  static void
-check_highspeed (struct usb_hub *hub, struct usb_device *udev, int port1)
+check_highspeed(struct usb_hub *hub, struct usb_device *udev, int port1)
  {
struct usb_qualifier_descriptor *qual;
int status;
@@ -4530,11 +4530,11 @@ check_highspeed (struct usb_hub *hub, struct usb_device 
*udev, int port1)
if (udev->quirks & USB_QUIRK_DEVICE_QUALIFIER)
return;

-   qual = kmalloc (sizeof *qual, GFP_KERNEL);
+   qual = kmalloc(sizeof *qual, GFP_KERNEL);
if (qual == NULL)
return;

-   status = usb_get_descriptor (udev, USB_DT_DEVICE_QUALIFIER, 0,
+   status = usb_get_descriptor udev, USB_DT_DEVICE_QUALIFIER, 0,
qual, sizeof *qual);


If you had test compiled you would have got an unbalanced parenthesis 
error here. So you didn't test your patch..



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

Re: [PATCH] usb: core: hub: Removed some warnings generated by checkpatch.pl

[Lars Melin]

On 2015-08-15 11:41, Chase Metzger wrote:

Removed some checkpatch.pl warnings saying there was an unwanted space between
function names and their arguments.

Signed-off-by: Chase Metzger chasemetzge...@gmail.com
---
  drivers/usb/core/hub.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 38cb6d3..b9cab51 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4218,7 +4218,7 @@ static int hub_enable_device(struct usb_device *udev)
   * but it is still necessary to lock the port.
   */
  static int
-hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,
+hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
int retry_counter)
  {
struct usb_device   *hdev = hub-hdev;
@@ -4522,7 +4522,7 @@ fail:
  }

  static void
-check_highspeed (struct usb_hub *hub, struct usb_device *udev, int port1)
+check_highspeed(struct usb_hub *hub, struct usb_device *udev, int port1)
  {
struct usb_qualifier_descriptor *qual;
int status;
@@ -4530,11 +4530,11 @@ check_highspeed (struct usb_hub *hub, struct usb_device 
*udev, int port1)
if (udev-quirks  USB_QUIRK_DEVICE_QUALIFIER)
return;

-   qual = kmalloc (sizeof *qual, GFP_KERNEL);
+   qual = kmalloc(sizeof *qual, GFP_KERNEL);
if (qual == NULL)
return;

-   status = usb_get_descriptor (udev, USB_DT_DEVICE_QUALIFIER, 0,
+   status = usb_get_descriptor udev, USB_DT_DEVICE_QUALIFIER, 0,
qual, sizeof *qual);


If you had test compiled you would have got an unbalanced parenthesis 
error here. So you didn't test your patch..



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

Re: [PATCH] usb: option: Add ID for Peiker LTE NAD

[Lars Melin]

On 2014-11-01 23:01, Matthias Klein wrote:

Add ID of the Peiker LTE NAD for legacy serial interface

Signed-off-by: Matthias Klein 
---
  drivers/usb/serial/option.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index d1a3f60..d7f1042 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1091,6 +1091,7 @@ 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, 0x9025)}, /* Peiker LTE NAD */
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
05c6:9025 already has its net interface (#4) supported by the qmi_wwan 
driver so your patch is wrong.
There is also an ADB interface which I don't think should be driven by 
option.



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

Re: [PATCH] usb: option: Add ID for Peiker LTE NAD

[Lars Melin]

On 2014-11-01 23:01, Matthias Klein wrote:

Add ID of the Peiker LTE NAD for legacy serial interface

Signed-off-by: Matthias Klein matthias.kl...@linux.com
---
  drivers/usb/serial/option.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index d1a3f60..d7f1042 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1091,6 +1091,7 @@ 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, 0x9025)}, /* Peiker LTE NAD */
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
05c6:9025 already has its net interface (#4) supported by the qmi_wwan 
driver so your patch is wrong.
There is also an ADB interface which I don't think should be driven by 
option.



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

Re: [PATCH] usb: atm: fix codestyle issues in

[Lars Melin]

On 2014-10-12 00:28, Jonas Brunsgaard wrote:

Could you be more specific, what is it you dislike? After this patch
the checkpatch script only come up with a couple of warnings, all due
to the line length limit, and these warnings are all acceppable as
they improve the ability to grep for user readable strings.
Yes it was the many long lines I had in mind, seems I am the one who 
have to read up on that rule exception.

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

Re: [PATCH] usb: atm: fix codestyle issues in

[Lars Melin]

On 2014-10-11 23:02, Jonas Brunsgaard wrote:

Signed-off-by: Jonas Brunsgaard 
---
  drivers/usb/atm/ueagle-atm.c | 95 
  1 file changed, 42 insertions(+), 53 deletions(-)

diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
index 5a45937..eedb217 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -173,10 +173,10 @@ struct uea_softc {
const struct firmware *dsp_firm;
struct urb *urb_int;
  
-	void (*dispatch_cmv) (struct uea_softc *, struct intr_pkt *);

-   void (*schedule_load_page) (struct uea_softc *, struct intr_pkt *);
-   int (*stat) (struct uea_softc *);
-   int (*send_cmvs) (struct uea_softc *);
+   void (*dispatch_cmv)(struct uea_softc *, struct intr_pkt *);
+   void (*schedule_load_page)(struct uea_softc *, struct intr_pkt *);
+   int (*stat)(struct uea_softc *);
+   int (*send_cmvs)(struct uea_softc *);
  
  	/* keep in sync with eaglectl */

struct uea_stats {
@@ -576,8 +576,7 @@ static int annex[NB_MODEM];
  module_param(debug, uint, 0644);
  MODULE_PARM_DESC(debug, "module debug level (0=off,1=on,2=verbose)");
  module_param_array(altsetting, uint, NULL, 0644);
-MODULE_PARM_DESC(altsetting, "alternate setting for incoming traffic: 0=bulk, "
-"1=isoc slowest, ... , 8=isoc fastest (default)");
+MODULE_PARM_DESC(altsetting, "alternate setting for incoming traffic: 0=bulk, 
1=isoc slowest, ... , 8=isoc fastest (default)");
  module_param_array(sync_wait, bool, NULL, 0644);
  MODULE_PARM_DESC(sync_wait, "wait the synchronisation before starting ATM");
  module_param_array(cmv_file, charp, NULL, 0644);
@@ -686,8 +685,7 @@ static void uea_upload_pre_firmware(const struct firmware 
*fw_entry,
  
  		ret = uea_send_modem_cmd(usb, add, len, pfw + 3);

if (ret < 0) {
-   uea_err(usb, "uploading firmware data failed "
-   "with error %d\n", ret);
+   uea_err(usb, "uploading firmware data failed with error 
%d\n", ret);
goto err;
}
pfw += len + 3;
@@ -829,6 +827,7 @@ static int check_dsp_e4(const u8 *dsp, int len)
for (i = 0; i < E4_MAX_PAGE_NUMBER; i++) {
struct block_index *blockidx;
u8 blockno = p->page_number_to_block_index[i];
+
if (blockno >= E4_NO_SWAPPAGE_HEADERS)
continue;
  
@@ -1040,10 +1039,9 @@ static void __uea_load_page_e4(struct uea_softc *sc, u8 pageno, int boot)

bi.dwAddress = cpu_to_be32(le32_to_cpu(blockidx->PageAddress));
  
  		uea_dbg(INS_TO_USBDEV(sc),

-   "sending block %u for DSP page "
-   "%u size %u address %x\n",
-   blockno, pageno, blocksize,
-   le32_to_cpu(blockidx->PageAddress));
+   "sending block %u for DSP page %u size %u address 
%x\n",
+   blockno, pageno, blocksize,
+   le32_to_cpu(blockidx->PageAddress));
  
  		/* send block info through the IDMA pipe */

if (uea_idma_write(sc, , E4_BLOCK_INFO_SIZE))
@@ -1060,7 +1058,6 @@ static void __uea_load_page_e4(struct uea_softc *sc, u8 
pageno, int boot)
  
  bad:

uea_err(INS_TO_USBDEV(sc), "sending DSP block %u failed\n", blockno);
-   return;
  }
  
  static void uea_load_page_e4(struct work_struct *work)

@@ -1084,8 +1081,7 @@ static void uea_load_page_e4(struct work_struct *work)
  
  	p = (struct l1_code *) sc->dsp_firm->data;

if (pageno >= le16_to_cpu(p->page_header[0].PageNumber)) {
-   uea_err(INS_TO_USBDEV(sc), "invalid DSP "
-   "page %u requested\n", pageno);
+   uea_err(INS_TO_USBDEV(sc), "invalid DSP page %u requested\n", 
pageno);
return;
}
  
@@ -1180,8 +1176,8 @@ static int uea_cmv_e1(struct uea_softc *sc,

int ret;
  
  	uea_enters(INS_TO_USBDEV(sc));

-   uea_vdbg(INS_TO_USBDEV(sc), "Function : %d-%d, Address : %c%c%c%c, "
-   "offset : 0x%04x, data : 0x%08x\n",
+   uea_vdbg(INS_TO_USBDEV(sc),
+   "Function : %d-%d, Address : %c%c%c%c, offset : 0x%04x, data 
: 0x%08x\n",
E1_FUNCTION_TYPE(function),
E1_FUNCTION_SUBTYPE(function),
E1_GETSA1(address), E1_GETSA2(address),
@@ -1220,10 +1216,10 @@ static int uea_cmv_e4(struct uea_softc *sc,
uea_enters(INS_TO_USBDEV(sc));
memset(, 0, sizeof(cmv));
  
-	uea_vdbg(INS_TO_USBDEV(sc), "Function : %d-%d, Group : 0x%04x, "

-"Address : 0x%04x, offset : 0x%04x, data : 0x%08x\n",
-E4_FUNCTION_TYPE(function), E4_FUNCTION_SUBTYPE(function),
-group, address, offset, data);
+   

Re: [PATCH] usb: serial: Fix indentation style issue

[Lars Melin]

On 2014-10-11 21:20, Greg KH wrote:

On Sat, Oct 11, 2014 at 03:49:43PM +0200, Philip Munksgaard wrote:

Fix a style issue

Signed-off-by: Philip Munksgaard 
---
  drivers/usb/serial/option.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index d1a3f60..d88998d 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1616,7 +1616,7 @@ 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)_g_w14_blacklist
-   },
+   },

Why not fix the same 'space' issue on the line before this at the same
time?


Why put the closing brace on a new line?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: serial: Fix indentation style issue

[Lars Melin]

On 2014-10-11 21:20, Greg KH wrote:

On Sat, Oct 11, 2014 at 03:49:43PM +0200, Philip Munksgaard wrote:

Fix a style issue

Signed-off-by: Philip Munksgaard pmunksga...@gmail.com
---
  drivers/usb/serial/option.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index d1a3f60..d88998d 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1616,7 +1616,7 @@ 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
-   },
+   },

Why not fix the same 'space' issue on the line before this at the same
time?


Why put the closing brace on a new line?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: atm: fix codestyle issues in

[Lars Melin]

On 2014-10-11 23:02, Jonas Brunsgaard wrote:

Signed-off-by: Jonas Brunsgaard jonas.brunsga...@gmail.com
---
  drivers/usb/atm/ueagle-atm.c | 95 
  1 file changed, 42 insertions(+), 53 deletions(-)

diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
index 5a45937..eedb217 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -173,10 +173,10 @@ struct uea_softc {
const struct firmware *dsp_firm;
struct urb *urb_int;
  
-	void (*dispatch_cmv) (struct uea_softc *, struct intr_pkt *);

-   void (*schedule_load_page) (struct uea_softc *, struct intr_pkt *);
-   int (*stat) (struct uea_softc *);
-   int (*send_cmvs) (struct uea_softc *);
+   void (*dispatch_cmv)(struct uea_softc *, struct intr_pkt *);
+   void (*schedule_load_page)(struct uea_softc *, struct intr_pkt *);
+   int (*stat)(struct uea_softc *);
+   int (*send_cmvs)(struct uea_softc *);
  
  	/* keep in sync with eaglectl */

struct uea_stats {
@@ -576,8 +576,7 @@ static int annex[NB_MODEM];
  module_param(debug, uint, 0644);
  MODULE_PARM_DESC(debug, module debug level (0=off,1=on,2=verbose));
  module_param_array(altsetting, uint, NULL, 0644);
-MODULE_PARM_DESC(altsetting, alternate setting for incoming traffic: 0=bulk, 
-1=isoc slowest, ... , 8=isoc fastest (default));
+MODULE_PARM_DESC(altsetting, alternate setting for incoming traffic: 0=bulk, 
1=isoc slowest, ... , 8=isoc fastest (default));
  module_param_array(sync_wait, bool, NULL, 0644);
  MODULE_PARM_DESC(sync_wait, wait the synchronisation before starting ATM);
  module_param_array(cmv_file, charp, NULL, 0644);
@@ -686,8 +685,7 @@ static void uea_upload_pre_firmware(const struct firmware 
*fw_entry,
  
  		ret = uea_send_modem_cmd(usb, add, len, pfw + 3);

if (ret  0) {
-   uea_err(usb, uploading firmware data failed 
-   with error %d\n, ret);
+   uea_err(usb, uploading firmware data failed with error 
%d\n, ret);
goto err;
}
pfw += len + 3;
@@ -829,6 +827,7 @@ static int check_dsp_e4(const u8 *dsp, int len)
for (i = 0; i  E4_MAX_PAGE_NUMBER; i++) {
struct block_index *blockidx;
u8 blockno = p-page_number_to_block_index[i];
+
if (blockno = E4_NO_SWAPPAGE_HEADERS)
continue;
  
@@ -1040,10 +1039,9 @@ static void __uea_load_page_e4(struct uea_softc *sc, u8 pageno, int boot)

bi.dwAddress = cpu_to_be32(le32_to_cpu(blockidx-PageAddress));
  
  		uea_dbg(INS_TO_USBDEV(sc),

-   sending block %u for DSP page 
-   %u size %u address %x\n,
-   blockno, pageno, blocksize,
-   le32_to_cpu(blockidx-PageAddress));
+   sending block %u for DSP page %u size %u address 
%x\n,
+   blockno, pageno, blocksize,
+   le32_to_cpu(blockidx-PageAddress));
  
  		/* send block info through the IDMA pipe */

if (uea_idma_write(sc, bi, E4_BLOCK_INFO_SIZE))
@@ -1060,7 +1058,6 @@ static void __uea_load_page_e4(struct uea_softc *sc, u8 
pageno, int boot)
  
  bad:

uea_err(INS_TO_USBDEV(sc), sending DSP block %u failed\n, blockno);
-   return;
  }
  
  static void uea_load_page_e4(struct work_struct *work)

@@ -1084,8 +1081,7 @@ static void uea_load_page_e4(struct work_struct *work)
  
  	p = (struct l1_code *) sc-dsp_firm-data;

if (pageno = le16_to_cpu(p-page_header[0].PageNumber)) {
-   uea_err(INS_TO_USBDEV(sc), invalid DSP 
-   page %u requested\n, pageno);
+   uea_err(INS_TO_USBDEV(sc), invalid DSP page %u requested\n, 
pageno);
return;
}
  
@@ -1180,8 +1176,8 @@ static int uea_cmv_e1(struct uea_softc *sc,

int ret;
  
  	uea_enters(INS_TO_USBDEV(sc));

-   uea_vdbg(INS_TO_USBDEV(sc), Function : %d-%d, Address : %c%c%c%c, 
-   offset : 0x%04x, data : 0x%08x\n,
+   uea_vdbg(INS_TO_USBDEV(sc),
+   Function : %d-%d, Address : %c%c%c%c, offset : 0x%04x, data 
: 0x%08x\n,
E1_FUNCTION_TYPE(function),
E1_FUNCTION_SUBTYPE(function),
E1_GETSA1(address), E1_GETSA2(address),
@@ -1220,10 +1216,10 @@ static int uea_cmv_e4(struct uea_softc *sc,
uea_enters(INS_TO_USBDEV(sc));
memset(cmv, 0, sizeof(cmv));
  
-	uea_vdbg(INS_TO_USBDEV(sc), Function : %d-%d, Group : 0x%04x, 

-Address : 0x%04x, offset : 0x%04x, data : 0x%08x\n,
-E4_FUNCTION_TYPE(function), E4_FUNCTION_SUBTYPE(function),
-group, address, offset, data);
+   

Re: [PATCH] usb: atm: fix codestyle issues in

[Lars Melin]

On 2014-10-12 00:28, Jonas Brunsgaard wrote:

Could you be more specific, what is it you dislike? After this patch
the checkpatch script only come up with a couple of warnings, all due
to the line length limit, and these warnings are all acceppable as
they improve the ability to grep for user readable strings.
Yes it was the many long lines I had in mind, seems I am the one who 
have to read up on that rule exception.

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

Re: [PATCH] usb: gadget: f_rndis: fix usb_interface_descriptor for rndis

[Lars Melin]

On 2014-09-29 19:11, Heiko Schocher wrote:

Hello Lars,

sorry for my late answer ...

Am 24.09.2014 16:22, schrieb Lars Melin:

On 2014-09-24 20:12, Heiko Schocher wrote:

Hello Lars,

Am 24.09.2014 14:25, schrieb Lars Melin:

On 2014-09-24 13:48, Heiko Schocher wrote:

use the values for RNDIS over Ethernet as defined in
http://www.usb.org/developers/defined_class
(search for RDNIS):

- baseclass: 0xef (miscellaneous)
- subclass: 0x04
- protocol: 0x01

That is usb class, it is not the same thing as communication device 
class.

--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -12,6 +12,7 @@
#include 
#define USB_CDC_SUBCLASS_ACM 0x02
+#define USB_CDC_SUBCLASS_RNDIS 0x04

No, no, no.
There is no CDC_SUBCLASS_RNDIS and you can not define one over an 
already used cdc subclass number, 0x04 is Multi-Channel Control Model


Ah, ok, so I have to define this values in a new header file, as there
is no current file for the USB_CLASS_MISC defines? Or is there a proper
place for them?

BTW: where do I find the "cdc subclass number, 0x04 is Multi-Channel
Control Model" define?

bye,
Heiko


You can still find the original specification usbcdc11.pdf on the net 
if you google for it, it has been pulled from usb.org where you could 
download it until a few years ago.

It is old but covers a lot of what you need to know.


Hmm.. maybe I am to dummy for finding this docment...

http://www.usb.org/results?q=usbcdc11.pdf=Search

does not find this document ... could you send me a direct link?

I found with the above search:

http://www.usb.org/developers/defined_class


I don't know if it is a good idea to provide a link here to a document 
which usb.org has made unavailable, I told you to google for the file 
name , not to search for it on usb.org

and this site, exactly describes the values for RNDIS over ethernet,
as my patch changes [1]

Linux has afaik only the cdc.h definition file, everything else is 
coded by class/subclass in respectively drivers when needed.


why not in header files? I thought, magical values are not welcome
in source code ...



I was wrong, usb class definitions are included in 
../include/uapi/linux/usb/ch9.h

As for the is_rndis() function case, this function is defined in
2 places:

- drivers/net/usb/cdc_ether.c
- drivers/usb/core/generic.c

Has this a special reason? This seems suboptimal to me ...
Yes it has, but the core driver is not an interface driver so it is not 
of relevance in this case.
cdc_ether handles interfaces of device connected to the usb bus, not 
interfaces of gadget devices

created by linux.

I got from a customer this patch (in a similiar version) and
he did tests with [3] and saw, that a board which runs linux,
is seen in [3] with the values [2] ... so he changed the
values in drivers/usb/gadget/function/f_rndis.c to the
values [1], which are documented in [4] and with them
the test [3] is happy ... and the file
"Documentation/usb/linux.inf" is not longer needed on the
windows pc!

The patch from your customer removed  the most common rndis interface 
attributes and substituted them
with one of many other interface attributes which Microsoft uses, this 
is not the right way of doing it.
Why did he patch  ../core/generic.c  and ../net/usb/cdc_ether.c  if he 
wants to change the interface attributes of g_rndis?



Lars



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

Re: [PATCH] usb: gadget: f_rndis: fix usb_interface_descriptor for rndis

[Lars Melin]

On 2014-09-29 19:11, Heiko Schocher wrote:

Hello Lars,

sorry for my late answer ...

Am 24.09.2014 16:22, schrieb Lars Melin:

On 2014-09-24 20:12, Heiko Schocher wrote:

Hello Lars,

Am 24.09.2014 14:25, schrieb Lars Melin:

On 2014-09-24 13:48, Heiko Schocher wrote:

use the values for RNDIS over Ethernet as defined in
http://www.usb.org/developers/defined_class
(search for RDNIS):

- baseclass: 0xef (miscellaneous)
- subclass: 0x04
- protocol: 0x01

That is usb class, it is not the same thing as communication device 
class.

--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -12,6 +12,7 @@
#include linux/types.h
#define USB_CDC_SUBCLASS_ACM 0x02
+#define USB_CDC_SUBCLASS_RNDIS 0x04

No, no, no.
There is no CDC_SUBCLASS_RNDIS and you can not define one over an 
already used cdc subclass number, 0x04 is Multi-Channel Control Model


Ah, ok, so I have to define this values in a new header file, as there
is no current file for the USB_CLASS_MISC defines? Or is there a proper
place for them?

BTW: where do I find the cdc subclass number, 0x04 is Multi-Channel
Control Model define?

bye,
Heiko


You can still find the original specification usbcdc11.pdf on the net 
if you google for it, it has been pulled from usb.org where you could 
download it until a few years ago.

It is old but covers a lot of what you need to know.


Hmm.. maybe I am to dummy for finding this docment...

http://www.usb.org/results?q=usbcdc11.pdfsubmit=Search

does not find this document ... could you send me a direct link?

I found with the above search:

http://www.usb.org/developers/defined_class


I don't know if it is a good idea to provide a link here to a document 
which usb.org has made unavailable, I told you to google for the file 
name , not to search for it on usb.org

and this site, exactly describes the values for RNDIS over ethernet,
as my patch changes [1]

Linux has afaik only the cdc.h definition file, everything else is 
coded by class/subclass in respectively drivers when needed.


why not in header files? I thought, magical values are not welcome
in source code ...



I was wrong, usb class definitions are included in 
../include/uapi/linux/usb/ch9.h

As for the is_rndis() function case, this function is defined in
2 places:

- drivers/net/usb/cdc_ether.c
- drivers/usb/core/generic.c

Has this a special reason? This seems suboptimal to me ...
Yes it has, but the core driver is not an interface driver so it is not 
of relevance in this case.
cdc_ether handles interfaces of device connected to the usb bus, not 
interfaces of gadget devices

created by linux.

I got from a customer this patch (in a similiar version) and
he did tests with [3] and saw, that a board which runs linux,
is seen in [3] with the values [2] ... so he changed the
values in drivers/usb/gadget/function/f_rndis.c to the
values [1], which are documented in [4] and with them
the test [3] is happy ... and the file
Documentation/usb/linux.inf is not longer needed on the
windows pc!

The patch from your customer removed  the most common rndis interface 
attributes and substituted them
with one of many other interface attributes which Microsoft uses, this 
is not the right way of doing it.
Why did he patch  ../core/generic.c  and ../net/usb/cdc_ether.c  if he 
wants to change the interface attributes of g_rndis?



Lars



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

Re: [PATCH] usb: gadget: f_rndis: fix usb_interface_descriptor for rndis

[Lars Melin]

On 2014-09-24 20:12, Heiko Schocher wrote:

Hello Lars,

Am 24.09.2014 14:25, schrieb Lars Melin:

On 2014-09-24 13:48, Heiko Schocher wrote:

use the values for RNDIS over Ethernet as defined in
http://www.usb.org/developers/defined_class
(search for RDNIS):

- baseclass: 0xef (miscellaneous)
- subclass: 0x04
- protocol: 0x01

That is usb class, it is not the same thing as communication device 
class.

--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -12,6 +12,7 @@
#include 
#define USB_CDC_SUBCLASS_ACM 0x02
+#define USB_CDC_SUBCLASS_RNDIS 0x04

No, no, no.
There is no CDC_SUBCLASS_RNDIS and you can not define one over an 
already used cdc subclass number, 0x04 is Multi-Channel Control Model


Ah, ok, so I have to define this values in a new header file, as there
is no current file for the USB_CLASS_MISC defines? Or is there a proper
place for them?

BTW: where do I find the "cdc subclass number, 0x04 is Multi-Channel
Control Model" define?

bye,
Heiko


You can still find the original specification usbcdc11.pdf on the net if 
you google for it, it has been pulled from usb.org where you could 
download it until a few years ago.

It is old but covers a lot of what you need to know.

Linux has afaik only the cdc.h definition file, everything else is coded 
by class/subclass in respectively drivers when needed.
02/02/ff  or  e0/01/03  are the most common interface attribute for 
rndis,  both of them together with a data interface with attributes 
0a/00/00.
Please check the whitelisting in drivers/net/usb/rndis_host.c  and also 
blacklistings in other net drivers under the same path, it should give 
you an idea how to bind an interface to a specific driver by interface 
attributes and/or usb vid:pid.

You should be able to do the same for your particular device.

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

Re: [PATCH] usb: gadget: f_rndis: fix usb_interface_descriptor for rndis

[Lars Melin]

On 2014-09-24 13:48, Heiko Schocher wrote:

use the values for RNDIS over Ethernet as defined in
http://www.usb.org/developers/defined_class
(search for RDNIS):

- baseclass: 0xef (miscellaneous)
- subclass: 0x04
- protocol: 0x01


That is usb class, it is not the same thing as communication device class.

--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -12,6 +12,7 @@
  #include 
  
  #define USB_CDC_SUBCLASS_ACM			0x02

+#define USB_CDC_SUBCLASS_RNDIS 0x04

No, no, no.
There is no CDC_SUBCLASS_RNDIS and you can not define one over an 
already used cdc subclass number,  0x04 is  Multi-Channel Control Model


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

Re: [PATCH] usb: gadget: f_rndis: fix usb_interface_descriptor for rndis

[Lars Melin]

On 2014-09-24 13:48, Heiko Schocher wrote:

use the values for RNDIS over Ethernet as defined in
http://www.usb.org/developers/defined_class
(search for RDNIS):

- baseclass: 0xef (miscellaneous)
- subclass: 0x04
- protocol: 0x01


That is usb class, it is not the same thing as communication device class.

--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -12,6 +12,7 @@
  #include linux/types.h
  
  #define USB_CDC_SUBCLASS_ACM			0x02

+#define USB_CDC_SUBCLASS_RNDIS 0x04

No, no, no.
There is no CDC_SUBCLASS_RNDIS and you can not define one over an 
already used cdc subclass number,  0x04 is  Multi-Channel Control Model


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

Re: [PATCH] usb: gadget: f_rndis: fix usb_interface_descriptor for rndis

[Lars Melin]

On 2014-09-24 20:12, Heiko Schocher wrote:

Hello Lars,

Am 24.09.2014 14:25, schrieb Lars Melin:

On 2014-09-24 13:48, Heiko Schocher wrote:

use the values for RNDIS over Ethernet as defined in
http://www.usb.org/developers/defined_class
(search for RDNIS):

- baseclass: 0xef (miscellaneous)
- subclass: 0x04
- protocol: 0x01

That is usb class, it is not the same thing as communication device 
class.

--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -12,6 +12,7 @@
#include linux/types.h
#define USB_CDC_SUBCLASS_ACM 0x02
+#define USB_CDC_SUBCLASS_RNDIS 0x04

No, no, no.
There is no CDC_SUBCLASS_RNDIS and you can not define one over an 
already used cdc subclass number, 0x04 is Multi-Channel Control Model


Ah, ok, so I have to define this values in a new header file, as there
is no current file for the USB_CLASS_MISC defines? Or is there a proper
place for them?

BTW: where do I find the cdc subclass number, 0x04 is Multi-Channel
Control Model define?

bye,
Heiko


You can still find the original specification usbcdc11.pdf on the net if 
you google for it, it has been pulled from usb.org where you could 
download it until a few years ago.

It is old but covers a lot of what you need to know.

Linux has afaik only the cdc.h definition file, everything else is coded 
by class/subclass in respectively drivers when needed.
02/02/ff  or  e0/01/03  are the most common interface attribute for 
rndis,  both of them together with a data interface with attributes 
0a/00/00.
Please check the whitelisting in drivers/net/usb/rndis_host.c  and also 
blacklistings in other net drivers under the same path, it should give 
you an idea how to bind an interface to a specific driver by interface 
attributes and/or usb vid:pid.

You should be able to do the same for your particular device.

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

Re: [PATCH] net: qmi_wwan: Add ID for Telewell TW-LTE 4G v2

[Lars Melin]

On 2014-07-02 02:01, Bernd Wachter wrote:

There's a new version of the Telewell 4G modem working with, but not
recognized by this driver.

Signed-off-by: Bernd Wachter 
---
--- linux-3.15.3/drivers/net/usb/qmi_wwan.c.orig2014-07-01 
21:31:07.0 +0300
+++ linux-3.15.3/drivers/net/usb/qmi_wwan.c 2014-07-01 20:39:30.0 
+0300
@@ -741,6 +741,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x19d2, 0x1424, 2)},
{QMI_FIXED_INTF(0x19d2, 0x1425, 2)},
{QMI_FIXED_INTF(0x19d2, 0x1426, 2)},/* ZTE MF91 */
+   {QMI_FIXED_INTF(0x19d2, 0x1428, 2)},/* Telewell TW-LTE 4G v2 */
{QMI_FIXED_INTF(0x19d2, 0x2002, 4)},/* ZTE (Vodafone) K3765-Z */
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)},/* Sierra Wireless MC7700 */
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)},/* Sierra Wireless MC7750 */

--
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
For completeness (full device support) please create a patch for the 
serial interfaces in the option driver, see the entry for ZTE pid 1426 
in option.c as example.

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

Re: [PATCH] net: qmi_wwan: Add ID for Telewell TW-LTE 4G v2

[Lars Melin]

On 2014-07-02 02:01, Bernd Wachter wrote:

There's a new version of the Telewell 4G modem working with, but not
recognized by this driver.

Signed-off-by: Bernd Wachter bernd.wach...@jolla.com
---
--- linux-3.15.3/drivers/net/usb/qmi_wwan.c.orig2014-07-01 
21:31:07.0 +0300
+++ linux-3.15.3/drivers/net/usb/qmi_wwan.c 2014-07-01 20:39:30.0 
+0300
@@ -741,6 +741,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x19d2, 0x1424, 2)},
{QMI_FIXED_INTF(0x19d2, 0x1425, 2)},
{QMI_FIXED_INTF(0x19d2, 0x1426, 2)},/* ZTE MF91 */
+   {QMI_FIXED_INTF(0x19d2, 0x1428, 2)},/* Telewell TW-LTE 4G v2 */
{QMI_FIXED_INTF(0x19d2, 0x2002, 4)},/* ZTE (Vodafone) K3765-Z */
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)},/* Sierra Wireless MC7700 */
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)},/* Sierra Wireless MC7750 */

--
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
For completeness (full device support) please create a patch for the 
serial interfaces in the option driver, see the entry for ZTE pid 1426 
in option.c as example.

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