Skip to content

Commit

Permalink
docs: usb: convert documents to ReST
Browse files Browse the repository at this point in the history
Convert USB documents to ReST, in order to prepare for adding it
to the kernel API book, as most of the stuff there are driver or
subsystem-related.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  • Loading branch information
Mauro Carvalho Chehab authored and Greg Kroah-Hartman committed Apr 16, 2019
1 parent 5f9be5f commit d80b500
Show file tree
Hide file tree
Showing 23 changed files with 1,663 additions and 1,239 deletions.
56 changes: 37 additions & 19 deletions Documentation/usb/WUSB-Design-overview.txt
Original file line number Diff line number Diff line change
@@ -1,7 +1,9 @@

================================
Linux UWB + Wireless USB + WiNET
================================

Copyright (C) 2005-2006 Intel Corporation

(C) 2005-2006 Intel Corporation
Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>

This program is free software; you can redistribute it and/or
Expand Down Expand Up @@ -29,6 +31,7 @@ drivers for the USB based UWB radio controllers defined in the
Wireless USB 1.0 specification (including Wireless USB host controller
and an Intel WiNET controller).

.. Contents
1. Introduction
1. HWA: Host Wire adapters, your Wireless USB dongle

Expand All @@ -51,7 +54,8 @@ and an Intel WiNET controller).
4. Glossary


Introduction
Introduction
============

UWB is a wide-band communication protocol that is to serve also as the
low-level protocol for others (much like TCP sits on IP). Currently
Expand Down Expand Up @@ -93,7 +97,8 @@ The different logical parts of this driver are:
do the actual WUSB.


HWA: Host Wire adapters, your Wireless USB dongle
HWA: Host Wire adapters, your Wireless USB dongle
-------------------------------------------------

WUSB also defines a device called a Host Wire Adaptor (HWA), which in
mere terms is a USB dongle that enables your PC to have UWB and Wireless
Expand Down Expand Up @@ -125,7 +130,8 @@ The HWA itself is broken in two or three main interfaces:
their type and kick into gear.


DWA: Device Wired Adaptor, a Wireless USB hub for wired devices
DWA: Device Wired Adaptor, a Wireless USB hub for wired devices
---------------------------------------------------------------

These are the complement to HWAs. They are a USB host for connecting
wired devices, but it is connected to your PC connected via Wireless
Expand All @@ -137,7 +143,8 @@ code with the HWA-RC driver; there is a bunch of factorization work that
has been done to support that in upcoming releases.


WHCI: Wireless Host Controller Interface, the PCI WUSB host adapter
WHCI: Wireless Host Controller Interface, the PCI WUSB host adapter
-------------------------------------------------------------------

This is your usual PCI device that implements WHCI. Similar in concept
to EHCI, it allows your wireless USB devices (including DWAs) to connect
Expand All @@ -148,15 +155,17 @@ There is still no driver support for this, but will be in upcoming
releases.


The UWB stack
The UWB stack
=============

The main mission of the UWB stack is to keep a tally of which devices
are in radio proximity to allow drivers to connect to them. As well, it
provides an API for controlling the local radio controllers (RCs from
now on), such as to start/stop beaconing, scan, allocate bandwidth, etc.


Devices and hosts: the basic structure
Devices and hosts: the basic structure
--------------------------------------

The main building block here is the UWB device (struct uwb_dev). For
each device that pops up in radio presence (ie: the UWB host receives a
Expand Down Expand Up @@ -187,7 +196,8 @@ the USB connected HWA. Eventually, drivers/whci-rc.c will do the same
for the PCI connected WHCI controller.


Host Controller life cycle
Host Controller life cycle
--------------------------

So let's say we connect a dongle to the system: it is detected and
firmware uploaded if needed [for Intel's i1480
Expand All @@ -209,7 +219,8 @@ When a dongle is disconnected, /drivers/uwb/hwa-rc.c:hwarc_disconnect()/
takes time of tearing everything down safely (or not...).


On the air: beacons and enumerating the radio neighborhood
On the air: beacons and enumerating the radio neighborhood
----------------------------------------------------------

So assuming we have devices and we have agreed for a channel to connect
on (let's say 9), we put the new RC to beacon:
Expand All @@ -235,12 +246,14 @@ are received in some time, the device is considered gone and wiped out
the beacon cache of dead devices].


Device lists
Device lists
------------

All UWB devices are kept in the list of the struct bus_type uwb_bus_type.


Bandwidth allocation
Bandwidth allocation
--------------------

The UWB stack maintains a local copy of DRP availability through
processing of incoming *DRP Availability Change* notifications. This
Expand All @@ -260,7 +273,8 @@ completion. [Note: The bandwidth reservation work is in progress and
subject to change.]


Wireless USB Host Controller drivers
Wireless USB Host Controller drivers
====================================

*WARNING* This section needs a lot of work!

Expand Down Expand Up @@ -296,7 +310,8 @@ starts sending MMCs.

Now it all depends on external stimuli.

*New device connection*
New device connection
---------------------

A new device pops up, it scans the radio looking for MMCs that give out
the existence of Wireless USB channels. Once one (or more) are found,
Expand All @@ -322,7 +337,8 @@ has seen the port status changes, as we have been toggling them. It will
start enumerating and doing transfers through usb_hcd->urb_enqueue() to
read descriptors and move our data.

*Device life cycle and keep alives*
Device life cycle and keep alives
---------------------------------

Every time there is a successful transfer to/from a device, we update a
per-device activity timestamp. If not, every now and then we check and
Expand All @@ -340,7 +356,8 @@ device list looking for whom needs refreshing.
If the device wants to disconnect, it will either die (ugly) or send a
/DN_Disconnect/ that will prompt a disconnection from the system.

*Sending and receiving data*
Sending and receiving data
--------------------------

Data is sent and received through /Remote Pipes/ (rpipes). An rpipe is
/aimed/ at an endpoint in a WUSB device. This is the same for HWAs and
Expand Down Expand Up @@ -394,7 +411,8 @@ finalize the transfer.
For IN xfers, we only issue URBs for the segments we want to read and
then wait for the xfer result data.

*URB mapping into xfers*
URB mapping into xfers
^^^^^^^^^^^^^^^^^^^^^^

This is done by hwahc_op_urb_[en|de]queue(). In enqueue() we aim an
rpipe to the endpoint where we have to transmit, create a transfer
Expand All @@ -407,7 +425,8 @@ and not yet done and when all that is done, the xfer callback will be
called--this will call the URB callback.


Glossary
Glossary
========

*DWA* -- Device Wire Adapter

Expand Down Expand Up @@ -436,4 +455,3 @@ the host.

Design-overview.txt-1.8 (last edited 2006-11-04 12:22:24 by
InakyPerezGonzalez)

164 changes: 84 additions & 80 deletions Documentation/usb/acm.txt
Original file line number Diff line number Diff line change
@@ -1,127 +1,131 @@
Linux ACM driver v0.16
(c) 1999 Vojtech Pavlik <vojtech@suse.cz>
Sponsored by SuSE
----------------------------------------------------------------------------
======================
Linux ACM driver v0.16
======================

Copyright (c) 1999 Vojtech Pavlik <vojtech@suse.cz>

Sponsored by SuSE

0. Disclaimer
~~~~~~~~~~~~~
This program is free software; you can redistribute it and/or modify it
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.

This program is distributed in the hope that it will be useful, but
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.

You should have received a copy of the GNU General Public License along
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place, Suite 330, Boston, MA 02111-1307 USA

Should you need to contact me, the author, you can do so either by e-mail
- mail your message to <vojtech@suse.cz>, or by paper mail: Vojtech Pavlik,
Should you need to contact me, the author, you can do so either by e-mail -
mail your message to <vojtech@suse.cz>, or by paper mail: Vojtech Pavlik,
Ucitelska 1576, Prague 8, 182 00 Czech Republic

For your convenience, the GNU General Public License version 2 is included
For your convenience, the GNU General Public License version 2 is included
in the package: See the file COPYING.

1. Usage
~~~~~~~~
The drivers/usb/class/cdc-acm.c drivers works with USB modems and USB ISDN terminal
The drivers/usb/class/cdc-acm.c drivers works with USB modems and USB ISDN terminal
adapters that conform to the Universal Serial Bus Communication Device Class
Abstract Control Model (USB CDC ACM) specification.

Many modems do, here is a list of those I know of:
Many modems do, here is a list of those I know of:

3Com OfficeConnect 56k
3Com Voice FaxModem Pro
3Com Sportster
MultiTech MultiModem 56k
Zoom 2986L FaxModem
Compaq 56k FaxModem
ELSA Microlink 56k
- 3Com OfficeConnect 56k
- 3Com Voice FaxModem Pro
- 3Com Sportster
- MultiTech MultiModem 56k
- Zoom 2986L FaxModem
- Compaq 56k FaxModem
- ELSA Microlink 56k

I know of one ISDN TA that does work with the acm driver:
I know of one ISDN TA that does work with the acm driver:

3Com USR ISDN Pro TA
- 3Com USR ISDN Pro TA

Some cell phones also connect via USB. I know the following phones work:
Some cell phones also connect via USB. I know the following phones work:

SonyEricsson K800i
- SonyEricsson K800i

Unfortunately many modems and most ISDN TAs use proprietary interfaces and
Unfortunately many modems and most ISDN TAs use proprietary interfaces and
thus won't work with this drivers. Check for ACM compliance before buying.

To use the modems you need these modules loaded:
To use the modems you need these modules loaded::

usbcore.ko
uhci-hcd.ko ohci-hcd.ko or ehci-hcd.ko
cdc-acm.ko

After that, the modem[s] should be accessible. You should be able to use
After that, the modem[s] should be accessible. You should be able to use
minicom, ppp and mgetty with them.

2. Verifying that it works
~~~~~~~~~~~~~~~~~~~~~~~~~~
The first step would be to check /sys/kernel/debug/usb/devices, it should look
like this:

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB UHCI Root Hub
S: SerialNumber=6800
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2
P: Vendor=04c1 ProdID=008f Rev= 2.07
S: Manufacturer=3Com Inc.
S: Product=3Com U.S. Robotics Pro ISDN TA
S: SerialNumber=UFT53A49BVT7
C: #Ifs= 1 Cfg#= 1 Atr=60 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=acm
E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms
C:* #Ifs= 2 Cfg#= 2 Atr=60 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm
E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms

The first step would be to check /sys/kernel/debug/usb/devices, it should look
like this::

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB UHCI Root Hub
S: SerialNumber=6800
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2
P: Vendor=04c1 ProdID=008f Rev= 2.07
S: Manufacturer=3Com Inc.
S: Product=3Com U.S. Robotics Pro ISDN TA
S: SerialNumber=UFT53A49BVT7
C: #Ifs= 1 Cfg#= 1 Atr=60 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=acm
E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms
C:* #Ifs= 2 Cfg#= 2 Atr=60 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm
E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms

The presence of these three lines (and the Cls= 'comm' and 'data' classes)
is important, it means it's an ACM device. The Driver=acm means the acm
driver is used for the device. If you see only Cls=ff(vend.) then you're out
of luck, you have a device with vendor specific-interface.

D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm
I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm

In the system log you should see:

usb.c: USB new device connect, assigned device number 2
usb.c: kmalloc IF c7691fa0, numif 1
usb.c: kmalloc IF c7b5f3e0, numif 2
usb.c: skipped 4 class/vendor specific interface descriptors
usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3
usb.c: USB device number 2 default language ID 0x409
Manufacturer: 3Com Inc.
Product: 3Com U.S. Robotics Pro ISDN TA
SerialNumber: UFT53A49BVT7
acm.c: probing config 1
acm.c: probing config 2
ttyACM0: USB ACM device
acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0
acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7
usb.c: acm driver claimed interface c7b5f3e0
usb.c: acm driver claimed interface c7b5f3f8
usb.c: acm driver claimed interface c7691fa0
of luck, you have a device with vendor specific-interface::

D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=acm
I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=acm

In the system log you should see::

usb.c: USB new device connect, assigned device number 2
usb.c: kmalloc IF c7691fa0, numif 1
usb.c: kmalloc IF c7b5f3e0, numif 2
usb.c: skipped 4 class/vendor specific interface descriptors
usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3
usb.c: USB device number 2 default language ID 0x409
Manufacturer: 3Com Inc.
Product: 3Com U.S. Robotics Pro ISDN TA
SerialNumber: UFT53A49BVT7
acm.c: probing config 1
acm.c: probing config 2
ttyACM0: USB ACM device
acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0
acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7
usb.c: acm driver claimed interface c7b5f3e0
usb.c: acm driver claimed interface c7b5f3f8
usb.c: acm driver claimed interface c7691fa0

If all this seems to be OK, fire up minicom and set it to talk to the ttyACM
device and try typing 'at'. If it responds with 'OK', then everything is
Expand Down
Loading

0 comments on commit d80b500

Please sign in to comment.