aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/ABI/testing/sysfs-bus-usb15
-rw-r--r--Documentation/devicetree/bindings/usb/isp1301.txt25
-rw-r--r--Documentation/devicetree/bindings/usb/lpc32xx-udc.txt28
-rw-r--r--Documentation/devicetree/bindings/usb/ohci-nxp.txt24
-rw-r--r--Documentation/devicetree/bindings/usb/spear-usb.txt39
-rw-r--r--Documentation/usb/functionfs.txt67
6 files changed, 198 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index 7c22a532fdf..6ae9fec8e07 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -135,6 +135,17 @@ Description:
135 for the device and attempt to bind to it. For example: 135 for the device and attempt to bind to it. For example:
136 # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id 136 # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
137 137
138 Reading from this file will list all dynamically added
139 device IDs in the same format, with one entry per
140 line. For example:
141 # cat /sys/bus/usb/drivers/foo/new_id
142 8086 10f5
143 dead beef 06
144 f00d cafe
145
146 The list will be truncated at PAGE_SIZE bytes due to
147 sysfs restrictions.
148
138What: /sys/bus/usb-serial/drivers/.../new_id 149What: /sys/bus/usb-serial/drivers/.../new_id
139Date: October 2011 150Date: October 2011
140Contact: linux-usb@vger.kernel.org 151Contact: linux-usb@vger.kernel.org
@@ -157,6 +168,10 @@ Description:
157 match the driver to the device. For example: 168 match the driver to the device. For example:
158 # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id 169 # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
159 170
171 Reading from this file will list the dynamically added
172 device IDs, exactly like reading from the entry
173 "/sys/bus/usb/drivers/.../new_id"
174
160What: /sys/bus/usb/device/.../avoid_reset_quirk 175What: /sys/bus/usb/device/.../avoid_reset_quirk
161Date: December 2009 176Date: December 2009
162Contact: Oliver Neukum <oliver@neukum.org> 177Contact: Oliver Neukum <oliver@neukum.org>
diff --git a/Documentation/devicetree/bindings/usb/isp1301.txt b/Documentation/devicetree/bindings/usb/isp1301.txt
new file mode 100644
index 00000000000..5405d99d9aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/isp1301.txt
@@ -0,0 +1,25 @@
1* NXP ISP1301 USB transceiver
2
3Required properties:
4- compatible: must be "nxp,isp1301"
5- reg: I2C address of the ISP1301 device
6
7Optional properties of devices using ISP1301:
8- transceiver: phandle of isp1301 - this helps the ISP1301 driver to find the
9 ISP1301 instance associated with the respective USB driver
10
11Example:
12
13 isp1301: usb-transceiver@2c {
14 compatible = "nxp,isp1301";
15 reg = <0x2c>;
16 };
17
18 usbd@31020000 {
19 compatible = "nxp,lpc3220-udc";
20 reg = <0x31020000 0x300>;
21 interrupt-parent = <&mic>;
22 interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
23 transceiver = <&isp1301>;
24 status = "okay";
25 };
diff --git a/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt b/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt
new file mode 100644
index 00000000000..29f12a533f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt
@@ -0,0 +1,28 @@
1* NXP LPC32xx SoC USB Device Controller (UDC)
2
3Required properties:
4- compatible: Must be "nxp,lpc3220-udc"
5- reg: Physical base address of the controller and length of memory mapped
6 region.
7- interrupts: The USB interrupts:
8 * USB Device Low Priority Interrupt
9 * USB Device High Priority Interrupt
10 * USB Device DMA Interrupt
11 * External USB Transceiver Interrupt (OTG ATX)
12- transceiver: phandle of the associated ISP1301 device - this is necessary for
13 the UDC controller for connecting to the USB physical layer
14
15Example:
16
17 isp1301: usb-transceiver@2c {
18 compatible = "nxp,isp1301";
19 reg = <0x2c>;
20 };
21
22 usbd@31020000 {
23 compatible = "nxp,lpc3220-udc";
24 reg = <0x31020000 0x300>;
25 interrupt-parent = <&mic>;
26 interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
27 transceiver = <&isp1301>;
28 };
diff --git a/Documentation/devicetree/bindings/usb/ohci-nxp.txt b/Documentation/devicetree/bindings/usb/ohci-nxp.txt
new file mode 100644
index 00000000000..71e28c1017e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-nxp.txt
@@ -0,0 +1,24 @@
1* OHCI controller, NXP ohci-nxp variant
2
3Required properties:
4- compatible: must be "nxp,ohci-nxp"
5- reg: physical base address of the controller and length of memory mapped
6 region.
7- interrupts: The OHCI interrupt
8- transceiver: phandle of the associated ISP1301 device - this is necessary for
9 the UDC controller for connecting to the USB physical layer
10
11Example (LPC32xx):
12
13 isp1301: usb-transceiver@2c {
14 compatible = "nxp,isp1301";
15 reg = <0x2c>;
16 };
17
18 ohci@31020000 {
19 compatible = "nxp,ohci-nxp";
20 reg = <0x31020000 0x300>;
21 interrupt-parent = <&mic>;
22 interrupts = <0x3b 0>;
23 transceiver = <&isp1301>;
24 };
diff --git a/Documentation/devicetree/bindings/usb/spear-usb.txt b/Documentation/devicetree/bindings/usb/spear-usb.txt
new file mode 100644
index 00000000000..f8a464a2565
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/spear-usb.txt
@@ -0,0 +1,39 @@
1ST SPEAr SoC USB controllers:
2-----------------------------
3
4EHCI:
5-----
6
7Required properties:
8- compatible: "st,spear600-ehci"
9- interrupt-parent: Should be the phandle for the interrupt controller
10 that services interrupts for this device
11- interrupts: Should contain the EHCI interrupt
12
13Example:
14
15 ehci@e1800000 {
16 compatible = "st,spear600-ehci", "usb-ehci";
17 reg = <0xe1800000 0x1000>;
18 interrupt-parent = <&vic1>;
19 interrupts = <27>;
20 };
21
22
23OHCI:
24-----
25
26Required properties:
27- compatible: "st,spear600-ohci"
28- interrupt-parent: Should be the phandle for the interrupt controller
29 that services interrupts for this device
30- interrupts: Should contain the OHCI interrupt
31
32Example:
33
34 ohci@e1900000 {
35 compatible = "st,spear600-ohci", "usb-ohci";
36 reg = <0xe1800000 0x1000>;
37 interrupt-parent = <&vic1>;
38 interrupts = <26>;
39 };
diff --git a/Documentation/usb/functionfs.txt b/Documentation/usb/functionfs.txt
new file mode 100644
index 00000000000..eaaaea019fc
--- /dev/null
+++ b/Documentation/usb/functionfs.txt
@@ -0,0 +1,67 @@
1*How FunctionFS works*
2
3From kernel point of view it is just a composite function with some
4unique behaviour. It may be added to an USB configuration only after
5the user space driver has registered by writing descriptors and
6strings (the user space program has to provide the same information
7that kernel level composite functions provide when they are added to
8the configuration).
9
10This in particular means that the composite initialisation functions
11may not be in init section (ie. may not use the __init tag).
12
13From user space point of view it is a file system which when
14mounted provides an "ep0" file. User space driver need to
15write descriptors and strings to that file. It does not need
16to worry about endpoints, interfaces or strings numbers but
17simply provide descriptors such as if the function was the
18only one (endpoints and strings numbers starting from one and
19interface numbers starting from zero). The FunctionFS changes
20them as needed also handling situation when numbers differ in
21different configurations.
22
23When descriptors and strings are written "ep#" files appear
24(one for each declared endpoint) which handle communication on
25a single endpoint. Again, FunctionFS takes care of the real
26numbers and changing of the configuration (which means that
27"ep1" file may be really mapped to (say) endpoint 3 (and when
28configuration changes to (say) endpoint 2)). "ep0" is used
29for receiving events and handling setup requests.
30
31When all files are closed the function disables itself.
32
33What I also want to mention is that the FunctionFS is designed in such
34a way that it is possible to mount it several times so in the end
35a gadget could use several FunctionFS functions. The idea is that
36each FunctionFS instance is identified by the device name used
37when mounting.
38
39One can imagine a gadget that has an Ethernet, MTP and HID interfaces
40where the last two are implemented via FunctionFS. On user space
41level it would look like this:
42
43$ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid
44$ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp
45$ ( cd /dev/ffs-mtp && mtp-daemon ) &
46$ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid
47$ ( cd /dev/ffs-hid && hid-daemon ) &
48
49On kernel level the gadget checks ffs_data->dev_name to identify
50whether it's FunctionFS designed for MTP ("mtp") or HID ("hid").
51
52If no "functions" module parameters is supplied, the driver accepts
53just one function with any name.
54
55When "functions" module parameter is supplied, only functions
56with listed names are accepted. In particular, if the "functions"
57parameter's value is just a one-element list, then the behaviour
58is similar to when there is no "functions" at all; however,
59only a function with the specified name is accepted.
60
61The gadget is registered only after all the declared function
62filesystems have been mounted and USB descriptors of all functions
63have been written to their ep0's.
64
65Conversely, the gadget is unregistered after the first USB function
66closes its endpoints.
67