Re: [PATCH 2/2] usb: serial: option: add Cellient MPL200 card
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
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
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
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
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
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
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
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
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
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
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
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 *)&req, sizeof(req)); } Thanks Lars
Re: [PATCH] USB: serial: option: Add Motorola modem UARTs
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.
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
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
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
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
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
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
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
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
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
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
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: option: Add ID for Peiker LTE NAD
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: atm: fix codestyle issues in
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
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, &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: serial: Fix indentation style issue
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)&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: gadget: f_rndis: fix usb_interface_descriptor for rndis
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&submit=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
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
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] net: qmi_wwan: Add ID for Telewell TW-LTE 4G v2
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/