2019-05-19 21:51:43 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-09-01 00:53:58 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2002 Pavel Machek <pavel@ucw.cz>
|
|
|
|
* Copyright (C) 2002-2005 by David Brownell
|
|
|
|
*/
|
|
|
|
|
|
|
|
// #define DEBUG // error path messages, extra info
|
|
|
|
// #define VERBOSE // more; success messages
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/ethtool.h>
|
|
|
|
#include <linux/workqueue.h>
|
|
|
|
#include <linux/mii.h>
|
|
|
|
#include <linux/crc32.h>
|
|
|
|
#include <linux/usb.h>
|
2006-06-14 00:57:47 +08:00
|
|
|
#include <linux/usb/cdc.h>
|
2008-01-26 06:51:45 +08:00
|
|
|
#include <linux/usb/usbnet.h>
|
2005-09-01 00:53:58 +08:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* All known Zaurii lie about their standards conformance. At least
|
|
|
|
* the earliest SA-1100 models lie by saying they support CDC Ethernet.
|
|
|
|
* Some later models (especially PXA-25x and PXA-27x based ones) lie
|
|
|
|
* and say they support CDC MDLM (for access to cell phone modems).
|
|
|
|
*
|
|
|
|
* There are non-Zaurus products that use these same protocols too.
|
|
|
|
*
|
|
|
|
* The annoying thing is that at the same time Sharp was developing
|
|
|
|
* that annoying standards-breaking software, the Linux community had
|
|
|
|
* a simple "CDC Subset" working reliably on the same SA-1100 hardware.
|
|
|
|
* That is, the same functionality but not violating standards.
|
|
|
|
*
|
|
|
|
* The CDC Ethernet nonconformance points are troublesome to hosts
|
|
|
|
* with a true CDC Ethernet implementation:
|
|
|
|
* - Framing appends a CRC, which the spec says drivers "must not" do;
|
|
|
|
* - Transfers data in altsetting zero, instead of altsetting 1;
|
|
|
|
* - All these peripherals use the same ethernet address.
|
|
|
|
*
|
|
|
|
* The CDC MDLM nonconformance is less immediately troublesome, since all
|
|
|
|
* MDLM implementations are quasi-proprietary anyway.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static struct sk_buff *
|
2005-10-21 15:21:58 +08:00
|
|
|
zaurus_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
|
2005-09-01 00:53:58 +08:00
|
|
|
{
|
|
|
|
int padlen;
|
|
|
|
struct sk_buff *skb2;
|
|
|
|
|
|
|
|
padlen = 2;
|
|
|
|
if (!skb_cloned(skb)) {
|
|
|
|
int tailroom = skb_tailroom(skb);
|
|
|
|
if ((padlen + 4) <= tailroom)
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
skb2 = skb_copy_expand(skb, 0, 4 + padlen, flags);
|
|
|
|
dev_kfree_skb_any(skb);
|
|
|
|
skb = skb2;
|
|
|
|
if (skb) {
|
|
|
|
u32 fcs;
|
|
|
|
done:
|
|
|
|
fcs = crc32_le(~0, skb->data, skb->len);
|
|
|
|
fcs = ~fcs;
|
|
|
|
|
networking: add and use skb_put_u8()
Joe and Bjørn suggested that it'd be nicer to not have the
cast in the fairly common case of doing
*(u8 *)skb_put(skb, 1) = c;
Add skb_put_u8() for this case, and use it across the code,
using the following spatch:
@@
expression SKB, C, S;
typedef u8;
identifier fn = {skb_put};
fresh identifier fn2 = fn ## "_u8";
@@
- *(u8 *)fn(SKB, S) = C;
+ fn2(SKB, C);
Note that due to the "S", the spatch isn't perfect, it should
have checked that S is 1, but there's also places that use a
sizeof expression like sizeof(var) or sizeof(u8) etc. Turns
out that nobody ever did something like
*(u8 *)skb_put(skb, 2) = c;
which would be wrong anyway since the second byte wouldn't be
initialized.
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 20:29:24 +08:00
|
|
|
skb_put_u8(skb, fcs & 0xff);
|
|
|
|
skb_put_u8(skb, (fcs >> 8) & 0xff);
|
|
|
|
skb_put_u8(skb, (fcs >> 16) & 0xff);
|
|
|
|
skb_put_u8(skb, (fcs >> 24) & 0xff);
|
2005-09-01 00:53:58 +08:00
|
|
|
}
|
|
|
|
return skb;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int zaurus_bind(struct usbnet *dev, struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
/* Belcarra's funky framing has other options; mostly
|
|
|
|
* TRAILERS (!) with 4 bytes CRC, and maybe 2 pad bytes.
|
|
|
|
*/
|
|
|
|
dev->net->hard_header_len += 6;
|
|
|
|
dev->rx_urb_size = dev->net->hard_header_len + dev->net->mtu;
|
|
|
|
return usbnet_generic_cdc_bind(dev, intf);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* PDA style devices are always connected if present */
|
|
|
|
static int always_connected (struct usbnet *dev)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct driver_info zaurus_sl5x00_info = {
|
|
|
|
.description = "Sharp Zaurus SL-5x00",
|
usbnet: use eth%d name for known ethernet devices
The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.
Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().
Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.
The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two. The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.
Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Tested-by: Andy Green <andy.green@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-04-02 11:12:02 +08:00
|
|
|
.flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
|
2005-09-01 00:53:58 +08:00
|
|
|
.check_connect = always_connected,
|
|
|
|
.bind = zaurus_bind,
|
|
|
|
.unbind = usbnet_cdc_unbind,
|
2006-05-13 10:24:34 +08:00
|
|
|
.tx_fixup = zaurus_tx_fixup,
|
2005-09-01 00:53:58 +08:00
|
|
|
};
|
|
|
|
#define ZAURUS_STRONGARM_INFO ((unsigned long)&zaurus_sl5x00_info)
|
|
|
|
|
|
|
|
static const struct driver_info zaurus_pxa_info = {
|
|
|
|
.description = "Sharp Zaurus, PXA-2xx based",
|
usbnet: use eth%d name for known ethernet devices
The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.
Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().
Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.
The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two. The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.
Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Tested-by: Andy Green <andy.green@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-04-02 11:12:02 +08:00
|
|
|
.flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
|
2005-09-01 00:53:58 +08:00
|
|
|
.check_connect = always_connected,
|
|
|
|
.bind = zaurus_bind,
|
|
|
|
.unbind = usbnet_cdc_unbind,
|
2006-05-13 10:24:34 +08:00
|
|
|
.tx_fixup = zaurus_tx_fixup,
|
2005-09-01 00:53:58 +08:00
|
|
|
};
|
|
|
|
#define ZAURUS_PXA_INFO ((unsigned long)&zaurus_pxa_info)
|
|
|
|
|
|
|
|
static const struct driver_info olympus_mxl_info = {
|
|
|
|
.description = "Olympus R1000",
|
usbnet: use eth%d name for known ethernet devices
The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.
Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().
Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.
The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two. The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.
Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Tested-by: Andy Green <andy.green@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-04-02 11:12:02 +08:00
|
|
|
.flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
|
2005-09-01 00:53:58 +08:00
|
|
|
.check_connect = always_connected,
|
|
|
|
.bind = zaurus_bind,
|
|
|
|
.unbind = usbnet_cdc_unbind,
|
2006-05-13 10:24:34 +08:00
|
|
|
.tx_fixup = zaurus_tx_fixup,
|
2005-09-01 00:53:58 +08:00
|
|
|
};
|
|
|
|
#define OLYMPUS_MXL_INFO ((unsigned long)&olympus_mxl_info)
|
|
|
|
|
|
|
|
|
|
|
|
/* Some more recent products using Lineo/Belcarra code will wrongly claim
|
|
|
|
* CDC MDLM conformance. They aren't conformant: data endpoints live
|
|
|
|
* in the control interface, there's no data interface, and it's not used
|
|
|
|
* to talk to a cell phone radio. But at least we can detect these two
|
|
|
|
* pseudo-classes, rather than growing this product list with entries for
|
|
|
|
* each new nonconformant product (sigh).
|
|
|
|
*/
|
|
|
|
static const u8 safe_guid[16] = {
|
|
|
|
0x5d, 0x34, 0xcf, 0x66, 0x11, 0x18, 0x11, 0xd6,
|
|
|
|
0xa2, 0x1a, 0x00, 0x01, 0x02, 0xca, 0x9a, 0x7f,
|
|
|
|
};
|
|
|
|
static const u8 blan_guid[16] = {
|
|
|
|
0x74, 0xf0, 0x3d, 0xbd, 0x1e, 0xc1, 0x44, 0x70,
|
|
|
|
0xa3, 0x67, 0x71, 0x34, 0xc9, 0xf5, 0x54, 0x37,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int blan_mdlm_bind(struct usbnet *dev, struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
u8 *buf = intf->cur_altsetting->extra;
|
|
|
|
int len = intf->cur_altsetting->extralen;
|
|
|
|
struct usb_cdc_mdlm_desc *desc = NULL;
|
|
|
|
struct usb_cdc_mdlm_detail_desc *detail = NULL;
|
|
|
|
|
|
|
|
while (len > 3) {
|
|
|
|
if (buf [1] != USB_DT_CS_INTERFACE)
|
|
|
|
goto next_desc;
|
|
|
|
|
|
|
|
/* use bDescriptorSubType, and just verify that we get a
|
|
|
|
* "BLAN" (or "SAFE") descriptor.
|
|
|
|
*/
|
|
|
|
switch (buf [2]) {
|
|
|
|
case USB_CDC_MDLM_TYPE:
|
|
|
|
if (desc) {
|
|
|
|
dev_dbg(&intf->dev, "extra MDLM\n");
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
desc = (void *) buf;
|
|
|
|
if (desc->bLength != sizeof *desc) {
|
|
|
|
dev_dbg(&intf->dev, "MDLM len %u\n",
|
|
|
|
desc->bLength);
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
/* expect bcdVersion 1.0, ignore */
|
2009-12-03 15:58:21 +08:00
|
|
|
if (memcmp(&desc->bGUID, blan_guid, 16) &&
|
|
|
|
memcmp(&desc->bGUID, safe_guid, 16)) {
|
2005-09-01 00:53:58 +08:00
|
|
|
/* hey, this one might _really_ be MDLM! */
|
|
|
|
dev_dbg(&intf->dev, "MDLM guid\n");
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case USB_CDC_MDLM_DETAIL_TYPE:
|
|
|
|
if (detail) {
|
|
|
|
dev_dbg(&intf->dev, "extra MDLM detail\n");
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
detail = (void *) buf;
|
|
|
|
switch (detail->bGuidDescriptorType) {
|
|
|
|
case 0: /* "SAFE" */
|
|
|
|
if (detail->bLength != (sizeof *detail + 2))
|
|
|
|
goto bad_detail;
|
|
|
|
break;
|
|
|
|
case 1: /* "BLAN" */
|
|
|
|
if (detail->bLength != (sizeof *detail + 3))
|
|
|
|
goto bad_detail;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
goto bad_detail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* assuming we either noticed BLAN already, or will
|
|
|
|
* find it soon, there are some data bytes here:
|
|
|
|
* - bmNetworkCapabilities (unused)
|
|
|
|
* - bmDataCapabilities (bits, see below)
|
|
|
|
* - bPad (ignored, for PADAFTER -- BLAN-only)
|
|
|
|
* bits are:
|
|
|
|
* - 0x01 -- Zaurus framing (add CRC)
|
|
|
|
* - 0x02 -- PADBEFORE (CRC includes some padding)
|
|
|
|
* - 0x04 -- PADAFTER (some padding after CRC)
|
|
|
|
* - 0x08 -- "fermat" packet mangling (for hw bugs)
|
|
|
|
* the PADBEFORE appears not to matter; we interop
|
|
|
|
* with devices that use it and those that don't.
|
|
|
|
*/
|
|
|
|
if ((detail->bDetailData[1] & ~0x02) != 0x01) {
|
2006-03-28 17:56:53 +08:00
|
|
|
/* bmDataCapabilities == 0 would be fine too,
|
2005-09-01 00:53:58 +08:00
|
|
|
* but framing is minidriver-coupled for now.
|
|
|
|
*/
|
|
|
|
bad_detail:
|
|
|
|
dev_dbg(&intf->dev,
|
|
|
|
"bad MDLM detail, %d %d %d\n",
|
|
|
|
detail->bLength,
|
|
|
|
detail->bDetailData[0],
|
|
|
|
detail->bDetailData[2]);
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
2006-05-13 10:24:34 +08:00
|
|
|
|
|
|
|
/* same extra framing as for non-BLAN mode */
|
|
|
|
dev->net->hard_header_len += 6;
|
|
|
|
dev->rx_urb_size = dev->net->hard_header_len
|
|
|
|
+ dev->net->mtu;
|
2005-09-01 00:53:58 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
next_desc:
|
|
|
|
len -= buf [0]; /* bLength */
|
|
|
|
buf += buf [0];
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!desc || !detail) {
|
|
|
|
dev_dbg(&intf->dev, "missing cdc mdlm %s%sdescriptor\n",
|
|
|
|
desc ? "" : "func ",
|
|
|
|
detail ? "" : "detail ");
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* There's probably a CDC Ethernet descriptor there, but we can't
|
|
|
|
* rely on the Ethernet address it provides since not all vendors
|
|
|
|
* bother to make it unique. Likewise there's no point in tracking
|
|
|
|
* of the CDC event notifications.
|
|
|
|
*/
|
|
|
|
return usbnet_get_endpoints(dev, intf);
|
|
|
|
|
|
|
|
bad_desc:
|
|
|
|
dev_info(&dev->udev->dev, "unsupported MDLM descriptors\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct driver_info bogus_mdlm_info = {
|
|
|
|
.description = "pseudo-MDLM (BLAN) device",
|
usbnet: use eth%d name for known ethernet devices
The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.
Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().
Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.
The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two. The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.
Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Tested-by: Andy Green <andy.green@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-04-02 11:12:02 +08:00
|
|
|
.flags = FLAG_POINTTOPOINT | FLAG_FRAMING_Z,
|
2005-09-01 00:53:58 +08:00
|
|
|
.check_connect = always_connected,
|
2006-05-13 10:24:34 +08:00
|
|
|
.tx_fixup = zaurus_tx_fixup,
|
2005-09-01 00:53:58 +08:00
|
|
|
.bind = blan_mdlm_bind,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct usb_device_id products [] = {
|
|
|
|
#define ZAURUS_MASTER_INTERFACE \
|
|
|
|
.bInterfaceClass = USB_CLASS_COMM, \
|
|
|
|
.bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET, \
|
|
|
|
.bInterfaceProtocol = USB_CDC_PROTO_NONE
|
|
|
|
|
2024-06-12 13:13:20 +08:00
|
|
|
#define ZAURUS_FAKE_INTERFACE \
|
|
|
|
.bInterfaceClass = USB_CLASS_COMM, \
|
|
|
|
.bInterfaceSubClass = USB_CDC_SUBCLASS_MDLM, \
|
|
|
|
.bInterfaceProtocol = USB_CDC_PROTO_NONE
|
|
|
|
|
2005-09-01 00:53:58 +08:00
|
|
|
/* SA-1100 based Sharp Zaurus ("collie"), or compatible. */
|
|
|
|
{
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x8004,
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = ZAURUS_STRONGARM_INFO,
|
|
|
|
},
|
|
|
|
|
|
|
|
/* PXA-2xx based models are also lying-about-cdc. If you add any
|
|
|
|
* more devices that claim to be CDC Ethernet, make sure they get
|
|
|
|
* added to the blacklist in cdc_ether too.
|
|
|
|
*
|
|
|
|
* NOTE: OpenZaurus versions with 2.6 kernels won't use these entries,
|
|
|
|
* unlike the older ones with 2.4 "embedix" kernels.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x8005, /* A-300 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = ZAURUS_PXA_INFO,
|
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x8006, /* B-500/SL-5600 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = ZAURUS_PXA_INFO,
|
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x8007, /* C-700 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = ZAURUS_PXA_INFO,
|
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x9031, /* C-750 C-760 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = ZAURUS_PXA_INFO,
|
2012-02-21 01:28:13 +08:00
|
|
|
}, {
|
|
|
|
/* C-750/C-760/C-860/SL-C3000 PDA in MDLM mode */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x04DD, 0x9031, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long) &bogus_mdlm_info,
|
2005-09-01 00:53:58 +08:00
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x9032, /* SL-6000 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = ZAURUS_PXA_INFO,
|
2024-06-12 13:13:20 +08:00
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x9032, /* SL-6000 */
|
|
|
|
ZAURUS_FAKE_INTERFACE,
|
|
|
|
.driver_info = (unsigned long)&bogus_mdlm_info,
|
2005-09-01 00:53:58 +08:00
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
/* reported with some C860 units */
|
|
|
|
.idProduct = 0x9050, /* C-860 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = ZAURUS_PXA_INFO,
|
|
|
|
},
|
|
|
|
{
|
2012-03-26 12:11:46 +08:00
|
|
|
/* Motorola Rokr E6 */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x6027, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long) &bogus_mdlm_info,
|
|
|
|
}, {
|
2009-02-25 02:42:48 +08:00
|
|
|
/* Motorola MOTOMAGX phones */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x6425, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long) &bogus_mdlm_info,
|
2005-09-01 00:53:58 +08:00
|
|
|
},
|
|
|
|
|
|
|
|
/* Olympus has some models with a Zaurus-compatible option.
|
|
|
|
* R-1000 uses a FreeScale i.MXL cpu (ARMv4T)
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x07B4,
|
|
|
|
.idProduct = 0x0F02, /* R-1000 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = OLYMPUS_MXL_INFO,
|
|
|
|
},
|
2012-02-21 21:06:00 +08:00
|
|
|
|
|
|
|
/* Logitech Harmony 900 - uses the pseudo-MDLM (BLAN) driver */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x046d, 0xc11f, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long) &bogus_mdlm_info,
|
|
|
|
},
|
2005-09-01 00:53:58 +08:00
|
|
|
{ }, // END
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(usb, products);
|
|
|
|
|
|
|
|
static struct usb_driver zaurus_driver = {
|
|
|
|
.name = "zaurus",
|
|
|
|
.id_table = products,
|
|
|
|
.probe = usbnet_probe,
|
|
|
|
.disconnect = usbnet_disconnect,
|
|
|
|
.suspend = usbnet_suspend,
|
|
|
|
.resume = usbnet_resume,
|
2012-04-24 01:08:51 +08:00
|
|
|
.disable_hub_initiated_lpm = 1,
|
2005-09-01 00:53:58 +08:00
|
|
|
};
|
|
|
|
|
2011-11-19 01:44:20 +08:00
|
|
|
module_usb_driver(zaurus_driver);
|
2005-09-01 00:53:58 +08:00
|
|
|
|
|
|
|
MODULE_AUTHOR("Pavel Machek, David Brownell");
|
|
|
|
MODULE_DESCRIPTION("Sharp Zaurus PDA, and compatible products");
|
|
|
|
MODULE_LICENSE("GPL");
|