/* * This supports simple USB network links that don't require any special * framing or hardware control operations. The protocol used here is a * strict subset of CDC Ethernet, with three basic differences reflecting * the goal that almost any hardware should run it: * * - Minimal runtime control: one interface, no altsettings, and * no vendor or class specific control requests. If a device is * configured, it is allowed to exchange packets with the host. * Fancier models would mean not working on some hardware. * * - Minimal manufacturing control: no IEEE "Organizationally * Unique ID" required, or an EEPROMs to store one. Each host uses * one random "locally assigned" Ethernet address instead, which can * of course be overridden using standard tools like "ifconfig". * (With 2^46 such addresses, same-net collisions are quite rare.) * * - There is no additional framing data for USB. Packets are written * exactly as in CDC Ethernet, starting with an Ethernet header and * terminated by a short packet. However, the host will never send a * zero length packet; some systems can't handle those robustly. * * Anything that can transmit and receive USB bulk packets can implement * this protocol. That includes both smart peripherals and quite a lot * of "host-to-host" USB cables (which embed two devices back-to-back). * * Note that although Linux may use many of those host-to-host links * with this "cdc_subset" framing, that doesn't mean there may not be a * better approach. Handling the "other end unplugs/replugs" scenario * well tends to require chip-specific vendor requests. Also, Windows * peers at the other end of host-to-host cables may expect their own * framing to be used rather than this "cdc_subset" model.
*/
/*------------------------------------------------------------------------- * * ALi M5632 driver ... does high speed * * NOTE that the MS-Windows drivers for this chip use some funky and * (naturally) undocumented 7-byte prefix to each packet, so this is a * case where we don't currently interoperate. Also, once you unplug * one end of the cable, you need to replug the other end too ... since * chip docs are unavailable, there's no way to reset the relevant state * short of a power cycle. *
*-------------------------------------------------------------------------*/
/*------------------------------------------------------------------------- * * AnchorChips 2720 driver ... http://www.cypress.com * * This doesn't seem to have a way to detect whether the peer is * connected, or need any reset handshaking. It's got pretty big * internal buffers (handles most of a frame's worth of data). * Chip data sheets don't describe any vendor control messages. *
*-------------------------------------------------------------------------*/
staticconststruct driver_info an2720_info = {
.description = "AnchorChips/Cypress 2720",
.flags = FLAG_POINTTOPOINT, // no reset available! // no check_connect available!
.in = 2, .out = 2, // direction distinguishes these
};
#endif/* CONFIG_USB_AN2720 */
#ifdef CONFIG_USB_BELKIN #define HAVE_HARDWARE
/*------------------------------------------------------------------------- * * Belkin F5U104 ... two NetChip 2280 devices + Atmel AVR microcontroller * * ... also two eTEK designs, including one sold as "Advance USBNET" *
*-------------------------------------------------------------------------*/
/*------------------------------------------------------------------------- * * EPSON USB clients * * This is the same idea as Linux PDAs (below) except the firmware in the * device might not be Tux-powered. Epson provides reference firmware that * implements this interface. Product developers can reuse or modify that * code, such as by using their own product and vendor codes. * * Support was from Juro Bystricky <bystricky.juro@erd.epson.com> *
*-------------------------------------------------------------------------*/
/*------------------------------------------------------------------------- * * Intel's SA-1100 chip integrates basic USB support, and is used * in PDAs like some iPaqs, the Yopy, some Zaurus models, and more. * When they run Linux, arch/arm/mach-sa1100/usb-eth.c may be used to * network using minimal USB framing data. * * This describes the driver currently in standard ARM Linux kernels. * The Zaurus uses a different driver (see later). * * PXA25x and PXA210 use XScale cores (ARM v5TE) with better USB support * and different USB endpoint numbering than the SA1100 devices. The * mach-pxa/usb-eth.c driver re-uses the device ids from mach-sa1100 * so we rely on the endpoint descriptors. *
*-------------------------------------------------------------------------*/
#ifdef CONFIG_USB_ARMLINUX /* * SA-1100 using standard ARM Linux kernels, or compatible. * Often used when talking to Linux PDAs (iPaq, Yopy, etc). * The sa-1100 "usb-eth" driver handles the basic framing. * * PXA25x or PXA210 ... these use a "usb-eth" driver much like * the sa1100 one, but hardware uses different endpoint numbers. * * Or the Linux "Ethernet" gadget on hardware that can't talk * CDC Ethernet (e.g., no altsettings), in either of two modes: * - acting just like the old "usb-eth" firmware, though * the implementation is different * - supporting RNDIS as the first/default configuration for * MS-Windows interop; Linux needs to use the other config
*/
{ // 1183 = 0x049F, both used as hex values? // Compaq "Itsy" vendor/product id
USB_DEVICE (0x049F, 0x505A), // usb-eth, or compatible
.driver_info = (unsignedlong) &linuxdev_info,
}, {
USB_DEVICE (0x0E7E, 0x1001), // G.Mate "Yopy"
.driver_info = (unsignedlong) &yopy_info,
}, {
USB_DEVICE (0x8086, 0x07d3), // "blob" bootloader
.driver_info = (unsignedlong) &blob_info,
}, {
USB_DEVICE (0x1286, 0x8001), // "blob" bootloader
.driver_info = (unsignedlong) &blob_info,
}, { // Linux Ethernet/RNDIS gadget, mostly on PXA, second config // e.g. Gumstix, current OpenZaurus, ... or anything else // that just enables this gadget option.
USB_DEVICE (0x0525, 0xa4a2),
.driver_info = (unsignedlong) &linuxdev_info,
}, #endif
{ }, // END
};
MODULE_DEVICE_TABLE(usb, products);
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung und die Messung sind noch experimentell.