| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
|
A driver for USB ADSL modems based on the ADI eagle chipset using the
usb_atm infrastructure.
The managing part was taken from bsd ueagle driver, other parts were
written from scratch.
The driver uses the in-kernel firmware loader :
- to load a first usb firmware when the modem is in pre-firmware state
- to load the dsp firmware that are swapped in host memory.
- to load CMV (configuration and management variables) when the modem
boot. (We can't use options or sysfs for this as there many possible
values. See
https://mail.gna.org/public/eagleusb-dev/2005-04/msg00031.html for a
description of some)
- to load fpga code for 930 chipset.
The device had 4 endpoints :
* 2 for data (use by usbatm). The incoming
endpoint could be iso or bulk. The modem seems buggy and produce lot's
of atm errors when using it in bulk mode for speed > 3Mbps, so iso
endpoint is need for speed > 3Mbps. At the moment iso endpoint need a
patched usbatm library and for this reason is not included in this patch.
* One bulk endpoint for uploading dsp firmware
* One irq endpoint that notices the driver
- if we need to upload a page of the dsp firmware
- an ack for read or write CMV and the value (for the read case).
If order to make the driver cleaner, we design synchronous
(read|write)_cmv :
-send a synchronous control message to the modem
-wait for an ack or a timeout
-return the value if needed.
In order to run these synchronous usb messages we need a kernel thread.
The driver has been tested with sagem fast 800 modems with different
eagle chipset revision and with ADI 930 since April 2005.
Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Makefile and Kconfig entries for the new drivers.
Signed-off-by: Duncan Sands <baldrick@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
