Re: [PATCH v2 01/22] tmplcvt: make the tool more robust
Em Sun, 2 Apr 2017 15:32:31 -0600 Jonathan Corbet escreveu: > On Thu, 30 Mar 2017 07:45:35 -0300 > Mauro Carvalho Chehab wrote: > > > Currently, the script just assumes to be called at > > Documentation/sphinx/. Change it to work on any directory, > > and make it abort if something gets wrong. > > > > Also, be sure that both parameters are specified. > > > > That should avoid troubles like this: > > > > $ Documentation/sphinx/tmplcvt Documentation/DocBook/writing_usb_driver.tmpl > > sed: couldn't open file convert_template.sed: No such file or directory > > What's the status of this patch set? I saw that Jani had one comment > that, I think, hasn't been addressed? I'm resending it today, rebased on the top of docs-next. I'll send the last patch in separate, as it is unrelated to the doc conversion. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/21] writing_usb_driver.rst: Enrich its ReST representation
The pandoc conversion is not perfect. Do handwork in order to:
- add a title to this chapter;
- adjust function and struct references;
- use monospaced fonts for C code names;
- some other minor adjustments to make it better to read in
text mode and in html.
Signed-off-by: Mauro Carvalho Chehab
---
.../driver-api/usb/writing_usb_driver.rst | 182 ++---
1 file changed, 82 insertions(+), 100 deletions(-)
diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst
b/Documentation/driver-api/usb/writing_usb_driver.rst
index c18dbd74152b..69f077dcdb78 100644
--- a/Documentation/driver-api/usb/writing_usb_driver.rst
+++ b/Documentation/driver-api/usb/writing_usb_driver.rst
@@ -1,3 +1,5 @@
+.. _writing-usb-driver:
+
==
Writing USB Device Drivers
==
@@ -48,25 +50,23 @@ The first thing a Linux USB driver needs to do is register
itself with
the Linux USB subsystem, giving it some information about which devices
the driver supports and which functions to call when a device supported
by the driver is inserted or removed from the system. All of this
-information is passed to the USB subsystem in the usb_driver structure.
-The skeleton driver declares a usb_driver as:
-
-::
+information is passed to the USB subsystem in the :c:type:`usb_driver`
+structure. The skeleton driver declares a :c:type:`usb_driver` as::
static struct usb_driver skel_driver = {
-.name= "skeleton",
-.probe = skel_probe,
-.disconnect = skel_disconnect,
-.fops= &skel_fops,
-.minor = USB_SKEL_MINOR_BASE,
-.id_table= skel_table,
+ .name= "skeleton",
+ .probe = skel_probe,
+ .disconnect = skel_disconnect,
+ .fops= &skel_fops,
+ .minor = USB_SKEL_MINOR_BASE,
+ .id_table= skel_table,
};
The variable name is a string that describes the driver. It is used in
informational messages printed to the system log. The probe and
disconnect function pointers are called when a device that matches the
-information provided in the id_table variable is either seen or
+information provided in the ``id_table`` variable is either seen or
removed.
The fops and minor variables are optional. Most USB drivers hook into
@@ -76,78 +76,70 @@ subsystem, and any user-space interactions are provided
through that
interface. But for drivers that do not have a matching kernel subsystem,
such as MP3 players or scanners, a method of interacting with user space
is needed. The USB subsystem provides a way to register a minor device
-number and a set of file_operations function pointers that enable this
-user-space interaction. The skeleton driver needs this kind of
+number and a set of :c:type:`file_operations` function pointers that enable
+this user-space interaction. The skeleton driver needs this kind of
interface, so it provides a minor starting number and a pointer to its
-file_operations functions.
+:c:type:`file_operations` functions.
-The USB driver is then registered with a call to usb_register, usually
-in the driver's init function, as shown here:
-
-::
+The USB driver is then registered with a call to :c:func:`usb_register`,
+usually in the driver's init function, as shown here::
static int __init usb_skel_init(void)
{
-int result;
+ int result;
-/* register this driver with the USB subsystem */
-result = usb_register(&skel_driver);
-if (result < 0) {
-err("usb_register failed for the "__FILE__ "driver."
-"Error number %d", result);
-return -1;
-}
+ /* register this driver with the USB subsystem */
+ result = usb_register(&skel_driver);
+ if (result < 0) {
+ err("usb_register failed for the "__FILE__ "driver."
+ "Error number %d", result);
+ return -1;
+ }
-return 0;
+ return 0;
}
module_init(usb_skel_init);
When the driver is unloaded from the system, it needs to deregister
-itself with the USB subsystem. This is done with the usb_deregister
-function:
-
-::
+itself with the USB subsystem. This is done with the :c:func:`usb_deregister`
+function::
static void __exit usb_skel_exit(void)
{
-/* deregister this driver with the USB subsystem */
-usb_deregister(&skel_driver);
+ /* deregister this driver with the USB subsystem */
+ usb_deregister(&skel_driver);
}
module_exit(usb_skel_exit);
To enable the linux-hotplug system to load the driver automatically when
-the device is plugged in, you need
[PATCH v2 05/21] gadget.rst: Enrich its ReST representation and add kernel-doc tag
The pandoc conversion is not perfect. Do handwork in order to: - add a title to this chapter; - use the proper warning and note markups; - use kernel-doc to include Kernel header and c files; - remove legacy notes with regards to DocBook; - some other minor adjustments to make it better to read in text mode and in html. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/usb/gadget.rst | 127 +--- 1 file changed, 52 insertions(+), 75 deletions(-) diff --git a/Documentation/driver-api/usb/gadget.rst b/Documentation/driver-api/usb/gadget.rst index 52b299b1ca6d..3e8a3809c0b8 100644 --- a/Documentation/driver-api/usb/gadget.rst +++ b/Documentation/driver-api/usb/gadget.rst @@ -38,7 +38,7 @@ address a number of important problems, including: resources. Most Linux developers will not be able to use this API, since they have -USB "host" hardware in a PC, workstation, or server. Linux users with +USB ``host`` hardware in a PC, workstation, or server. Linux users with embedded systems are more likely to have USB peripheral hardware. To distinguish drivers running inside such hardware from the more familiar Linux "USB device drivers", which are host side proxies for the real USB @@ -64,7 +64,7 @@ Structure of Gadget Drivers A system running inside a USB peripheral normally has at least three layers inside the kernel to handle USB protocol processing, and may have -additional layers in user space code. The "gadget" API is used by the +additional layers in user space code. The ``gadget`` API is used by the middle layer to interact with the lowest level (which directly handles hardware). @@ -143,13 +143,13 @@ In Linux, from the bottom up, these layers are: *Additional Layers* Other layers may exist. These could include kernel layers, such as network protocol stacks, as well as user mode applications building -on standard POSIX system call APIs such as *open()*, *close()*, -*read()* and *write()*. On newer systems, POSIX Async I/O calls may +on standard POSIX system call APIs such as ``open()``, ``close()``, +``read()`` and ``write()``. On newer systems, POSIX Async I/O calls may be an option. Such user mode code will not necessarily be subject to the GNU General Public License (GPL). OTG-capable systems will also need to include a standard Linux-USB host -side stack, with *usbcore*, one or more *Host Controller Drivers* +side stack, with ``usbcore``, one or more *Host Controller Drivers* (HCDs), *USB Device Drivers* to support the OTG "Targeted Peripheral List", and so forth. There will also be an *OTG Controller Driver*, which is visible to gadget and device driver developers only indirectly. @@ -174,24 +174,20 @@ combined, to implement composite devices. Kernel Mode Gadget API == -Gadget drivers declare themselves through a *struct -usb_gadget_driver*, which is responsible for most parts of enumeration -for a *struct usb_gadget*. The response to a set_configuration usually -involves enabling one or more of the *struct usb_ep* objects exposed by -the gadget, and submitting one or more *struct usb_request* buffers to +Gadget drivers declare themselves through a struct +:c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration +for a struct :c:type:`usb_gadget`. The response to a set_configuration usually +involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by +the gadget, and submitting one or more struct :c:type:`usb_request` buffers to transfer data. Understand those four data types, and their operations, and you will understand how this API works. -**Note** +.. Note:: -This documentation was prepared using the standard Linux kernel -``docproc`` tool, which turns text and in-code comments into SGML -DocBook and then into usable formats such as HTML or PDF. Other than -the "Chapter 9" data types, most of the significant data types and -functions are described here. +Other than the "Chapter 9" data types, most of the significant data +types and functions are described here. -However, docproc does not understand all the C constructs that are -used, so some relevant information is likely omitted from what you +However, some relevant information is likely omitted from what you are reading. One example of such information is endpoint autoconfiguration. You'll have to read the header file, and use example source code (such as that for "Gadget Zero"), to fully @@ -199,10 +195,10 @@ and you will understand how this API works. The part of the API implementing some basic driver capabilities is specific to the version of the Linux kernel that's in use. The 2.6 -kernel includes a *driver model* framework that has no analogue on -earlier kernels; so those parts of the gadget API are n
[PATCH v2 11/21] usb/power-management.txt: convert to ReST and add to driver-api book
This document describe some USB core functions. Add it to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/usb/index.rst | 1 +
.../usb/power-management.rst} | 404 +++--
2 files changed, 214 insertions(+), 191 deletions(-)
rename Documentation/{usb/power-management.txt =>
driver-api/usb/power-management.rst} (69%)
diff --git a/Documentation/driver-api/usb/index.rst
b/Documentation/driver-api/usb/index.rst
index 441c5dacdf27..23c76c17fc19 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -9,6 +9,7 @@ Linux USB API
anchors
bulk-streams
callbacks
+ power-management
writing_usb_driver
writing_musb_glue_layer
diff --git a/Documentation/usb/power-management.txt
b/Documentation/driver-api/usb/power-management.rst
similarity index 69%
rename from Documentation/usb/power-management.txt
rename to Documentation/driver-api/usb/power-management.rst
index 00e706997130..c068257f6d27 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/driver-api/usb/power-management.rst
@@ -1,10 +1,12 @@
- Power Management for USB
+.. _usb-power-management:
-Alan Stern
-
- Last-updated: February 2014
+Power Management for USB
+
+:Author: Alan Stern
+:Date: Last-updated: February 2014
+..
Contents:
-
* What is Power Management?
@@ -25,14 +27,14 @@
* Suggested Userspace Port Power Policy
- What is Power Management?
- -
+What is Power Management?
+-
Power Management (PM) is the practice of saving energy by suspending
parts of a computer system when they aren't being used. While a
-component is "suspended" it is in a nonfunctional low-power state; it
+component is ``suspended`` it is in a nonfunctional low-power state; it
might even be turned off completely. A suspended component can be
-"resumed" (returned to a functional full-power state) when the kernel
+``resumed`` (returned to a functional full-power state) when the kernel
needs to use it. (There also are forms of PM in which components are
placed in a less functional but still usable state instead of being
suspended; an example would be reducing the CPU's clock rate. This
@@ -44,22 +46,25 @@ device is turned off while the system as a whole remains
running, we
call it a "dynamic suspend" (also known as a "runtime suspend" or
"selective suspend"). This document concentrates mostly on how
dynamic PM is implemented in the USB subsystem, although system PM is
-covered to some extent (see Documentation/power/*.txt for more
+covered to some extent (see ``Documentation/power/*.txt`` for more
information about system PM).
-System PM support is present only if the kernel was built with CONFIG_SUSPEND
-or CONFIG_HIBERNATION enabled. Dynamic PM support for USB is present whenever
-the kernel was built with CONFIG_PM enabled.
+System PM support is present only if the kernel was built with
+``CONFIG_SUSPEND`` or ``CONFIG_HIBERNATION`` enabled. Dynamic PM support
+
+for USB is present whenever
+the kernel was built with ``CONFIG_PM`` enabled.
[Historically, dynamic PM support for USB was present only if the
-kernel had been built with CONFIG_USB_SUSPEND enabled (which depended on
-CONFIG_PM_RUNTIME). Starting with the 3.10 kernel release, dynamic PM support
-for USB was present whenever the kernel was built with CONFIG_PM_RUNTIME
-enabled. The CONFIG_USB_SUSPEND option had been eliminated.]
+kernel had been built with ``CONFIG_USB_SUSPEND`` enabled (which depended on
+``CONFIG_PM_RUNTIME``). Starting with the 3.10 kernel release, dynamic PM
+support for USB was present whenever the kernel was built with
+``CONFIG_PM_RUNTIME`` enabled. The ``CONFIG_USB_SUSPEND`` option had been
+eliminated.]
- What is Remote Wakeup?
- --
+What is Remote Wakeup?
+--
When a device has been suspended, it generally doesn't resume until
the computer tells it to. Likewise, if the entire computer has been
@@ -76,8 +81,8 @@ event. Examples include a suspended keyboard resuming when a
key is
pressed, or a suspended USB hub resuming when a device is plugged in.
- When is a USB device idle?
- --
+When is a USB device idle?
+--
A device is idle whenever the kernel thinks it's not busy doing
anything important and thus is a candidate for being suspended. The
@@ -92,11 +97,11 @@ If a USB device has no driver, its usbfs file isn't open,
and it isn't
being accessed through sysfs, then it definitely is idle.
- Forms of dynamic PM
- ---
+Forms of dynamic PM
+---
[PATCH v2 07/21] writing_musb_glue_layer.rst: Enrich its ReST representation
This file is actually quite complex, and required several
manual handwork:
- add a title for the document;
- use the right tags for monospaced fonts;
- use c references where needed;
- adjust cross-reference to writing_usb_driver.rst
- hightlight cross-referenced lines.
With regards to C code snippet line highlights, the better would be
to use :linenos: for the C code snippets that are referenced by
the line number. However, at least with Sphinx 1.4.9, enabling
it cause the line number to be misaligned with the code,
making it even more confusing. So, instead, let's use
:emphasize-lines: tag to mark the lines that are referenced
at the text.
Signed-off-by: Mauro Carvalho Chehab
---
.../driver-api/usb/writing_musb_glue_layer.rst | 598 ++---
1 file changed, 292 insertions(+), 306 deletions(-)
diff --git a/Documentation/driver-api/usb/writing_musb_glue_layer.rst
b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
index 52700c7031f9..e90e8fa95600 100644
--- a/Documentation/driver-api/usb/writing_musb_glue_layer.rst
+++ b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
@@ -1,6 +1,6 @@
-==
-Writing an MUSB Glue Layer
-==
+=
+Writing a MUSB Glue Layer
+=
:Author: Apelete Seketeli
@@ -21,10 +21,12 @@ design.
As a self-taught exercise I have written an MUSB glue layer for the
Ingenic JZ4740 SoC, modelled after the many MUSB glue layers in the
kernel source tree. This layer can be found at
-drivers/usb/musb/jz4740.c. In this documentation I will walk through the
-basics of the jz4740.c glue layer, explaining the different pieces and
+``drivers/usb/musb/jz4740.c``. In this documentation I will walk through the
+basics of the ``jz4740.c`` glue layer, explaining the different pieces and
what needs to be done in order to write your own device glue layer.
+.. _musb-basics:
+
Linux MUSB Basics
=
@@ -39,33 +41,30 @@ USB Device Drivers documentation (again, see Resources).
Linux USB stack is a layered architecture in which the MUSB controller
hardware sits at the lowest. The MUSB controller driver abstract the
-MUSB controller hardware to the Linux USB stack.
+MUSB controller hardware to the Linux USB stack::
-::
-
-
- | | <--- drivers/usb/gadget
- | Linux USB Core Stack | <--- drivers/usb/host
- | | <--- drivers/usb/core
-
- ⬍
- --
- || <-- drivers/usb/musb/musb_gadget.c
- | MUSB Controller driver | <-- drivers/usb/musb/musb_host.c
- || <-- drivers/usb/musb/musb_core.c
- --
- ⬍
+
+ | | <--- drivers/usb/gadget
+ | Linux USB Core Stack | <--- drivers/usb/host
+ | | <--- drivers/usb/core
+
+⬍
+--
+|| <-- drivers/usb/musb/musb_gadget.c
+| MUSB Controller driver | <-- drivers/usb/musb/musb_host.c
+|| <-- drivers/usb/musb/musb_core.c
+--
+⬍
-
| MUSB Platform Specific Driver |
| | <-- drivers/usb/musb/jz4740.c
| aka "Glue Layer"|
-
- ⬍
+⬍
-
| MUSB Controller Hardware|
-
-
As outlined above, the glue layer is actually the platform specific code
sitting in between the controller driver and the controller hardware.
@@ -78,37 +77,32 @@ about an embedded controller chip here, so no insertion or
removal at
run-time.
All of this information is passed to the MUSB controller driver through
-a platform_driver structure defined in the glue layer as:
-
-::
+a :c:type:`platform_driver` structure defined in the glue layer as::
static struct platform_driver jz4740_driver = {
-.probe = jz4740_probe,
-.remove = jz4740_remove,
-.driver = {
-.name = "musb-jz4740",
-},
+ .probe = jz4740_probe,
+ .remove = jz4740_remove,
+ .driver = {
+ .name = "musb-jz4740",
+ },
};
-
The probe and remove function pointers are called when a matching device
is detected and, respectively, released. The name string describes the
device supported by this glue laye
[PATCH v2 16/21] usb/URB.txt: convert to ReST and update it
The URB doc describes the Kernel mechanism that do USB transfers.
While the functions are already described at urb.h, there are a
number of concepts and theory that are important for USB driver
developers.
Convert it to ReST and use C ref links to point to the places
at usb.h where each function and struct is located.
A few of those descriptions were incomplete. While here, update
to reflect the current API status.
Signed-off-by: Mauro Carvalho Chehab
---
.../{usb/URB.txt => driver-api/usb/URB.rst}| 221 -
Documentation/driver-api/usb/index.rst | 1 +
Documentation/driver-api/usb/usb.rst | 2 +
3 files changed, 127 insertions(+), 97 deletions(-)
rename Documentation/{usb/URB.txt => driver-api/usb/URB.rst} (50%)
diff --git a/Documentation/usb/URB.txt b/Documentation/driver-api/usb/URB.rst
similarity index 50%
rename from Documentation/usb/URB.txt
rename to Documentation/driver-api/usb/URB.rst
index 50da0d455444..c4a141f29477 100644
--- a/Documentation/usb/URB.txt
+++ b/Documentation/driver-api/usb/URB.rst
@@ -1,28 +1,35 @@
-Revised: 2000-Dec-05.
-Again: 2002-Jul-06
-Again: 2005-Sep-19
+USB Request Block (URB)
+~~~
-NOTE:
+:Revised: 2000-Dec-05
+:Again: 2002-Jul-06
+:Again: 2005-Sep-19
+:Again: 2017-Mar-29
-The USB subsystem now has a substantial section in "The Linux Kernel API"
-guide (in Documentation/DocBook), generated from the current source
-code. This particular documentation file isn't particularly current or
-complete; don't rely on it except for a quick overview.
+.. note::
-1.1. Basic concept or 'What is an URB?'
+The USB subsystem now has a substantial section at :ref:`usb-hostside-api`
+section, generated from the current source code.
+This particular documentation file isn't complete and may not be
+updated to the last version; don't rely on it except for a quick
+overview.
-The basic idea of the new driver is message passing, the message itself is
-called USB Request Block, or URB for short.
+Basic concept or 'What is an URB?'
+==
-- An URB consists of all relevant information to execute any USB transaction
- and deliver the data and status back.
+The basic idea of the new driver is message passing, the message itself is
+called USB Request Block, or URB for short.
-- Execution of an URB is inherently an asynchronous operation, i.e. the
- usb_submit_urb(urb) call returns immediately after it has successfully
+- An URB consists of all relevant information to execute any USB transaction
+ and deliver the data and status back.
+
+- Execution of an URB is inherently an asynchronous operation, i.e. the
+ :c:func:`usb_submit_urb` call returns immediately after it has successfully
queued the requested action.
-- Transfers for one URB can be canceled with usb_unlink_urb(urb) at any time.
+- Transfers for one URB can be canceled with :c:func:`usb_unlink_urb`
+ at any time.
- Each URB has a completion handler, which is called after the action
has been successfully completed or canceled. The URB also contains a
@@ -35,53 +42,55 @@ called USB Request Block, or URB for short.
of data to (or from) devices when using periodic transfer modes.
-1.2. The URB structure
+The URB structure
+=
-Some of the fields in an URB are:
+Some of the fields in struct :c:type:`urb` are::
-struct urb
-{
-// (IN) device and pipe specify the endpoint queue
+ struct urb
+ {
+ // (IN) device and pipe specify the endpoint queue
struct usb_device *dev; // pointer to associated USB device
unsigned int pipe; // endpoint information
- unsigned int transfer_flags;// ISO_ASAP, SHORT_NOT_OK, etc.
+ unsigned int transfer_flags;// URB_ISO_ASAP, URB_SHORT_NOT_OK, etc.
-// (IN) all urbs need completion routines
+ // (IN) all urbs need completion routines
void *context; // context for completion routine
- void (*complete)(struct urb *); // pointer to completion routine
+ usb_complete_t complete;// pointer to completion routine
-// (OUT) status after each completion
+ // (OUT) status after each completion
int status; // returned status
-// (IN) buffer used for data transfers
+ // (IN) buffer used for data transfers
void *transfer_buffer; // associated data buffer
- int transfer_buffer_length; // data buffer length
+ u32 transfer_buffer_length; // data buffer length
int number_of_packets; // size of iso_frame_desc
-// (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
- int actual_length; // actual data buffer length
+ // (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
+ u32 actual_length;
[PATCH v2 00/21] Convert USB documentation to ReST format
Currently, there are several USB core documents that are at either
written in plain text or in DocBook format. Convert them to ReST
and add to the driver-api book.
Mauro Carvalho Chehab (21):
tmplcvt: make the tool more robust
driver-api/basics.rst: add device table header
docs-rst: convert usb docbooks to ReST
usb.rst: Enrich its ReST representation
gadget.rst: Enrich its ReST representation and add kernel-doc tag
writing_usb_driver.rst: Enrich its ReST representation
writing_musb_glue_layer.rst: Enrich its ReST representation
usb/anchors.txt: convert to ReST and add to driver-api book
usb/bulk-streams.txt: convert to ReST and add to driver-api book
usb/callbacks.txt: convert to ReST and add to driver-api book
usb/power-management.txt: convert to ReST and add to driver-api book
usb/dma.txt: convert to ReST and add to driver-api book
error-codes.rst: convert to ReST and add to driver-api book
usb/hotplug.txt: convert to ReST and add to driver-api book
usb/persist.txt: convert to ReST and add to driver-api book
usb/URB.txt: convert to ReST and update it
usb.rst: get rid of some Sphinx errors
usb: get rid of some ReST doc build errors
usb: composite.h: fix two warnings when building docs
usb: gadget.h: be consistent at kernel doc macros
docs-rst: fix usb cross-references
Documentation/ABI/stable/sysfs-bus-usb | 2 +-
Documentation/DocBook/Makefile | 7 +-
Documentation/DocBook/gadget.tmpl | 793 ---
Documentation/DocBook/writing_musb_glue_layer.tmpl | 873 -
Documentation/DocBook/writing_usb_driver.tmpl | 412 --
Documentation/driver-api/basics.rst| 6 +
Documentation/driver-api/index.rst | 2 +-
.../{usb/URB.txt => driver-api/usb/URB.rst}| 223 +++---
.../anchors.txt => driver-api/usb/anchors.rst} | 36 +-
.../usb/bulk-streams.rst} | 13 +-
.../callbacks.txt => driver-api/usb/callbacks.rst} | 65 +-
.../{usb/dma.txt => driver-api/usb/dma.rst}| 51 +-
Documentation/driver-api/usb/error-codes.rst | 207 +
Documentation/driver-api/usb/gadget.rst| 510
.../hotplug.txt => driver-api/usb/hotplug.rst} | 66 +-
Documentation/driver-api/usb/index.rst | 26 +
.../persist.txt => driver-api/usb/persist.rst} | 22 +-
.../usb/power-management.rst} | 404 +-
Documentation/driver-api/{ => usb}/usb.rst | 222 +++---
.../driver-api/usb/writing_musb_glue_layer.rst | 723 +
.../driver-api/usb/writing_usb_driver.rst | 326
Documentation/power/swsusp.txt | 2 +-
Documentation/sphinx/tmplcvt | 13 +-
Documentation/usb/error-codes.txt | 175 -
drivers/staging/most/hdm-usb/hdm_usb.c | 2 +-
drivers/usb/core/Kconfig | 2 +-
drivers/usb/core/message.c | 1 +
include/linux/usb/composite.h | 6 +-
include/linux/usb/gadget.h | 2 +-
29 files changed, 2417 insertions(+), 2775 deletions(-)
delete mode 100644 Documentation/DocBook/gadget.tmpl
delete mode 100644 Documentation/DocBook/writing_musb_glue_layer.tmpl
delete mode 100644 Documentation/DocBook/writing_usb_driver.tmpl
rename Documentation/{usb/URB.txt => driver-api/usb/URB.rst} (50%)
rename Documentation/{usb/anchors.txt => driver-api/usb/anchors.rst} (75%)
rename Documentation/{usb/bulk-streams.txt => driver-api/usb/bulk-streams.rst}
(94%)
rename Documentation/{usb/callbacks.txt => driver-api/usb/callbacks.rst} (76%)
rename Documentation/{usb/dma.txt => driver-api/usb/dma.rst} (79%)
create mode 100644 Documentation/driver-api/usb/error-codes.rst
create mode 100644 Documentation/driver-api/usb/gadget.rst
rename Documentation/{usb/hotplug.txt => driver-api/usb/hotplug.rst} (76%)
create mode 100644 Documentation/driver-api/usb/index.rst
rename Documentation/{usb/persist.txt => driver-api/usb/persist.rst} (94%)
rename Documentation/{usb/power-management.txt =>
driver-api/usb/power-management.rst} (69%)
rename Documentation/driver-api/{ => usb}/usb.rst (85%)
create mode 100644 Documentation/driver-api/usb/writing_musb_glue_layer.rst
create mode 100644 Documentation/driver-api/usb/writing_usb_driver.rst
delete mode 100644 Documentation/usb/error-codes.txt
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 20/21] usb: gadget.h: be consistent at kernel doc macros
There's one value that use spaces instead of tabs to ident.
That causes the following warning:
./include/linux/usb/gadget.h:193: ERROR: Unexpected indentation.
Signed-off-by: Mauro Carvalho Chehab
---
include/linux/usb/gadget.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e4516e9ded0f..fbc22a39e7bc 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -188,7 +188,7 @@ struct usb_ep_caps {
* @caps:The structure describing types and directions supported by endoint.
* @maxpacket:The maximum packet size used on this endpoint. The initial
* value can sometimes be reduced (hardware allowing), according to
- * the endpoint descriptor used to configure the endpoint.
+ * the endpoint descriptor used to configure the endpoint.
* @maxpacket_limit:The maximum packet size value which can be handled by this
* endpoint. It's set once by UDC driver when endpoint is initialized, and
* should not be changed. Should not be confused with maxpacket.
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/21] usb/persist.txt: convert to ReST and add to driver-api book
This document describe some USB core features. Add it to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/usb/index.rst | 1 +
.../persist.txt => driver-api/usb/persist.rst} | 22 +-
2 files changed, 14 insertions(+), 9 deletions(-)
rename Documentation/{usb/persist.txt => driver-api/usb/persist.rst} (94%)
diff --git a/Documentation/driver-api/usb/index.rst
b/Documentation/driver-api/usb/index.rst
index 43f0a8b72b11..3f08cb5d5feb 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -12,6 +12,7 @@ Linux USB API
dma
power-management
hotplug
+ persist
error-codes
writing_usb_driver
writing_musb_glue_layer
diff --git a/Documentation/usb/persist.txt
b/Documentation/driver-api/usb/persist.rst
similarity index 94%
rename from Documentation/usb/persist.txt
rename to Documentation/driver-api/usb/persist.rst
index 35d70eda9ad6..ea1b43f0559e 100644
--- a/Documentation/usb/persist.txt
+++ b/Documentation/driver-api/usb/persist.rst
@@ -1,11 +1,12 @@
- USB device persistence during system suspend
+USB device persistence during system suspend
+
- Alan Stern
+:Author: Alan Stern
+:Date: September 2, 2006 (Updated February 25, 2008)
- September 2, 2006 (Updated February 25, 2008)
-
- What is the problem?
+What is the problem?
+
According to the USB specification, when a USB bus is suspended the
bus must continue to supply suspend current (around 1-5 mA). This
@@ -63,7 +64,8 @@ suspended -- but it will crash as soon as it wakes up, which
isn't
much better.)
- What is the solution?
+What is the solution?
+=
The kernel includes a feature called USB-persist. It tries to work
around these issues by allowing the core USB device data structures to
@@ -99,7 +101,7 @@ now a good and happy place.
Note that the "USB-persist" feature will be applied only to those
devices for which it is enabled. You can enable the feature by doing
-(as root):
+(as root)::
echo 1 >/sys/bus/usb/devices/.../power/persist
@@ -110,7 +112,8 @@ doesn't even exist, so you only have to worry about setting
it for
devices where it really matters.
- Is this the best solution?
+Is this the best solution?
+==
Perhaps not. Arguably, keeping track of mounted filesystems and
memory mappings across device disconnects should be handled by a
@@ -130,7 +133,8 @@ just mass-storage devices. It might turn out to be equally
useful for
other device types, such as network interfaces.
- WARNING: USB-persist can be dangerous!!
+WARNING: USB-persist can be dangerous!!
+===
When recovering an interrupted power session the kernel does its best
to make sure the USB device hasn't been changed; that is, the same
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/21] usb/callbacks.txt: convert to ReST and add to driver-api book
This document describe some USB core functions. Add it to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
.../callbacks.txt => driver-api/usb/callbacks.rst} | 61 +++---
Documentation/driver-api/usb/index.rst | 1 +
2 files changed, 43 insertions(+), 19 deletions(-)
rename Documentation/{usb/callbacks.txt => driver-api/usb/callbacks.rst} (78%)
diff --git a/Documentation/usb/callbacks.txt
b/Documentation/driver-api/usb/callbacks.rst
similarity index 78%
rename from Documentation/usb/callbacks.txt
rename to Documentation/driver-api/usb/callbacks.rst
index 9e85846bdb98..93a8d53e27e7 100644
--- a/Documentation/usb/callbacks.txt
+++ b/Documentation/driver-api/usb/callbacks.rst
@@ -1,3 +1,6 @@
+USB core callbacks
+~~
+
What callbacks will usbcore do?
===
@@ -11,30 +14,42 @@ The callbacks defined in the driver structure are:
1. Hotplugging callbacks:
- * @probe: Called to see if the driver is willing to manage a particular
- * interface on a device.
- * @disconnect: Called when the interface is no longer accessible, usually
- * because its device has been (or is being) disconnected or the
- * driver module is being unloaded.
+ - @probe:
+ Called to see if the driver is willing to manage a particular
+ interface on a device.
+
+ - @disconnect:
+ Called when the interface is no longer accessible, usually
+ because its device has been (or is being) disconnected or the
+ driver module is being unloaded.
2. Odd backdoor through usbfs:
- * @ioctl: Used for drivers that want to talk to userspace through
- * the "usbfs" filesystem. This lets devices provide ways to
- * expose information to user space regardless of where they
- * do (or don't) show up otherwise in the filesystem.
+ - @ioctl:
+ Used for drivers that want to talk to userspace through
+ the "usbfs" filesystem. This lets devices provide ways to
+ expose information to user space regardless of where they
+ do (or don't) show up otherwise in the filesystem.
3. Power management (PM) callbacks:
- * @suspend: Called when the device is going to be suspended.
- * @resume: Called when the device is being resumed.
- * @reset_resume: Called when the suspended device has been reset instead
- * of being resumed.
+ - @suspend:
+ Called when the device is going to be suspended.
+
+ - @resume:
+ Called when the device is being resumed.
+
+ - @reset_resume:
+ Called when the suspended device has been reset instead
+ of being resumed.
4. Device level operations:
- * @pre_reset: Called when the device is about to be reset.
- * @post_reset: Called after the device has been reset
+ - @pre_reset:
+ Called when the device is about to be reset.
+
+ - @post_reset:
+ Called after the device has been reset
The ioctl interface (2) should be used only if you have a very good
reason. Sysfs is preferred these days. The PM callbacks are covered
@@ -58,7 +73,9 @@ an interface. A driver's bond to an interface is exclusive.
The probe() callback
-int (*probe) (struct usb_interface *intf,
+::
+
+ int (*probe) (struct usb_interface *intf,
const struct usb_device_id *id);
Accept or decline an interface. If you accept the device return 0,
@@ -75,7 +92,9 @@ initialisation that doesn't take too long is a good idea here.
The disconnect() callback
-
-void (*disconnect) (struct usb_interface *intf);
+::
+
+ void (*disconnect) (struct usb_interface *intf);
This callback is a signal to break any connection with an interface.
You are not allowed any IO to a device after returning from this
@@ -93,7 +112,9 @@ Device level callbacks
pre_reset
-
-int (*pre_reset)(struct usb_interface *intf);
+::
+
+ int (*pre_reset)(struct usb_interface *intf);
A driver or user space is triggering a reset on the device which
contains the interface passed as an argument. Cease IO, wait for all
@@ -107,7 +128,9 @@ are in atomic context.
post_reset
--
-int (*post_reset)(struct usb_interface *intf);
+::
+
+ int (*post_reset)(struct usb_interface *intf);
The reset has completed. Restore any saved device state and begin
using the device again.
diff --git a/Documentation/driver-api/usb/index.rst
b/Documentation/driver-api/usb/index.rst
index 6fe7611f7332..441c5dacdf27 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -8,6 +8,7 @@ Linux USB API
gadget
anchors
bulk-streams
+ callbacks
writing_usb_driver
writing_musb_glue_layer
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/21] usb/hotplug.txt: convert to ReST and add to driver-api book
This document describe some USB core features. Add it to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
.../hotplug.txt => driver-api/usb/hotplug.rst} | 66 --
Documentation/driver-api/usb/index.rst | 1 +
2 files changed, 37 insertions(+), 30 deletions(-)
rename Documentation/{usb/hotplug.txt => driver-api/usb/hotplug.rst} (76%)
diff --git a/Documentation/usb/hotplug.txt
b/Documentation/driver-api/usb/hotplug.rst
similarity index 76%
rename from Documentation/usb/hotplug.txt
rename to Documentation/driver-api/usb/hotplug.rst
index 5b243f315b2c..79663e653ca1 100644
--- a/Documentation/usb/hotplug.txt
+++ b/Documentation/driver-api/usb/hotplug.rst
@@ -1,4 +1,9 @@
-LINUX HOTPLUGGING
+USB hotplugging
+~~~
+
+Linux Hotplugging
+=
+
In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
into the bus with power on. In most cases, users expect the devices to become
@@ -30,11 +35,11 @@ Because some of those actions rely on information about
drivers (metadata)
that is currently available only when the drivers are dynamically linked,
you get the best hotplugging when you configure a highly modular system.
+Kernel Hotplug Helper (``/sbin/hotplug``)
+=
-KERNEL HOTPLUG HELPER (/sbin/hotplug)
-
-There is a kernel parameter: /proc/sys/kernel/hotplug, which normally
-holds the pathname "/sbin/hotplug". That parameter names a program
+There is a kernel parameter: ``/proc/sys/kernel/hotplug``, which normally
+holds the pathname ``/sbin/hotplug``. That parameter names a program
which the kernel may invoke at various times.
The /sbin/hotplug program can be invoked by any subsystem as part of its
@@ -51,26 +56,26 @@ Hotplug software and other resources is available at:
Mailing list information is also available at that site.
---
+USB Policy Agent
+
-
-USB POLICY AGENT
-
-The USB subsystem currently invokes /sbin/hotplug when USB devices
+The USB subsystem currently invokes ``/sbin/hotplug`` when USB devices
are added or removed from system. The invocation is done by the kernel
hub workqueue [hub_wq], or else as part of root hub initialization
(done by init, modprobe, kapmd, etc). Its single command line parameter
is the string "usb", and it passes these environment variables:
-ACTION ... "add", "remove"
-PRODUCT ... USB vendor, product, and version codes (hex)
-TYPE ... device class codes (decimal)
-INTERFACE ... interface 0 class codes (decimal)
+==
+ACTION ``add``, ``remove``
+PRODUCTUSB vendor, product, and version codes (hex)
+TYPE device class codes (decimal)
+INTERFACE interface 0 class codes (decimal)
+==
If "usbdevfs" is configured, DEVICE and DEVFS are also passed. DEVICE is
the pathname of the device, and is useful for devices with multiple and/or
alternate interfaces that complicate driver selection. By design, USB
-hotplugging is independent of "usbdevfs": you can do most essential parts
+hotplugging is independent of ``usbdevfs``: you can do most essential parts
of USB device setup without using that filesystem, and without running a
user mode daemon to detect changes in system configuration.
@@ -79,19 +84,20 @@ modules, and can invoke driver-specific setup scripts. The
newest ones
leverage USB module-init-tools support. Later agents might unload drivers.
-USB MODUTILS SUPPORT
+USB Modutils Support
+
-Current versions of module-init-tools will create a "modules.usbmap" file
-which contains the entries from each driver's MODULE_DEVICE_TABLE. Such
+Current versions of module-init-tools will create a ``modules.usbmap`` file
+which contains the entries from each driver's ``MODULE_DEVICE_TABLE``. Such
files can be used by various user mode policy agents to make sure all the
right driver modules get loaded, either at boot time or later.
-See for full information about such table entries; or look
+See ``linux/usb.h`` for full information about such table entries; or look
at existing drivers. Each table entry describes one or more criteria to
be used when matching a driver to a device or class of devices. The
specific criteria are identified by bits set in "match_flags", paired
with field values. You can construct the criteria directly, or with
-macros such as these, and use driver_info to store more information.
+macros such as these, and use driver_info to store more information::
USB_DEVICE (vendorId, productId)
... matching devices with specified vendor and product ids
@@ -103,7 +109,7 @@ macros such as these, and use driver_info to store more
information.
[PATCH v2 01/21] tmplcvt: make the tool more robust
Currently, the script just assumes to be called at Documentation/sphinx/. Change it to work on any directory, and make it abort if something gets wrong. Also, be sure that both parameters are specified. That should avoid troubles like this: $ Documentation/sphinx/tmplcvt Documentation/DocBook/writing_usb_driver.tmpl sed: couldn't open file convert_template.sed: No such file or directory Signed-off-by: Mauro Carvalho Chehab --- Documentation/sphinx/tmplcvt | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/Documentation/sphinx/tmplcvt b/Documentation/sphinx/tmplcvt index 909a73065e0a..6848f0a26fa5 100755 --- a/Documentation/sphinx/tmplcvt +++ b/Documentation/sphinx/tmplcvt @@ -7,13 +7,22 @@ # fix \_ # title line? # +set -eu + +if [ "$#" != "2" ]; then + echo "$0 " + exit +fi + +DIR=$(dirname $0) in=$1 rst=$2 tmp=$rst.tmp cp $in $tmp -sed --in-place -f convert_template.sed $tmp +sed --in-place -f $DIR/convert_template.sed $tmp pandoc -s -S -f docbook -t rst -o $rst $tmp -sed --in-place -f post_convert.sed $rst +sed --in-place -f $DIR/post_convert.sed $rst rm $tmp +echo "book writen to $rst" -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 18/21] usb: get rid of some ReST doc build errors
We need an space before a numbered list to avoid those warnings: ./drivers/usb/core/message.c:478: ERROR: Unexpected indentation. ./drivers/usb/core/message.c:479: WARNING: Block quote ends without a blank line; unexpected unindent. ./include/linux/usb/composite.h:455: ERROR: Unexpected indentation. ./include/linux/usb/composite.h:456: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab --- drivers/usb/core/message.c| 1 + include/linux/usb/composite.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c index 2184ef40a82a..4c38ea41ae96 100644 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -474,6 +474,7 @@ EXPORT_SYMBOL_GPL(usb_sg_init); * significantly improve USB throughput. * * There are three kinds of completion for this function. + * * (1) success, where io->status is zero. The number of io->bytes * transferred is as requested. * (2) error, where io->status is a negative errno value. The number diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h index 4616a49a1c2e..30a063e98c19 100644 --- a/include/linux/usb/composite.h +++ b/include/linux/usb/composite.h @@ -451,6 +451,7 @@ static inline struct usb_composite_driver *to_cdriver( * sure doing that won't hurt too much. * * One notion for how to handle Wireless USB devices involves: + * * (a) a second gadget here, discovery mechanism TBD, but likely * needing separate "register/unregister WUSB gadget" calls; * (b) updates to usb_gadget to include flags "is it wireless", -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 19/21] usb: composite.h: fix two warnings when building docs
By definition, we use /* private: */ tag when we won't be documenting
a parameter. However, those two parameters are documented:
./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef
member 'setup_pending' description in 'usb_composite_dev'
./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef
member 'os_desc_pending' description in 'usb_composite_dev'
So, we need to use /* public: */ to avoid a warning.
Signed-off-by: Mauro Carvalho Chehab
---
include/linux/usb/composite.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 30a063e98c19..f665d2ceac20 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -504,8 +504,9 @@ struct usb_composite_dev {
/* protects deactivations and delayed_status counts*/
spinlock_t lock;
- unsignedsetup_pending:1;
- unsignedos_desc_pending:1;
+ /* public: */
+ unsigned intsetup_pending:1;
+ unsigned intos_desc_pending:1;
};
extern int usb_string_id(struct usb_composite_dev *c);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 17/21] usb.rst: get rid of some Sphinx errors
Get rid of those warnings: Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_type". Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_dir". Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_recip". Documentation/driver-api/usb/usb.rst:679: ERROR: Unknown target name: "usbdevfs_urb_type". Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/usb/usb.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst index d15ab8ae5239..5ebaf669704c 100644 --- a/Documentation/driver-api/usb/usb.rst +++ b/Documentation/driver-api/usb/usb.rst @@ -615,8 +615,8 @@ USBDEVFS_CONTROL The first eight bytes of this structure are the contents of the SETUP packet to be sent to the device; see the USB 2.0 specification for details. The bRequestType value is composed by combining a -USB_TYPE_\* value, a USB_DIR_\* value, and a USB_RECIP_\* -value (from **). If wLength is nonzero, it describes +``USB_TYPE_*`` value, a ``USB_DIR_*`` value, and a ``USB_RECIP_*`` +value (from ``linux/usb.h``). If wLength is nonzero, it describes the length of the data buffer, which is either written to the device (USB_DIR_OUT) or read from the device (USB_DIR_IN). @@ -678,7 +678,7 @@ the blocking is separate. These requests are packaged into a structure that resembles the URB used by kernel device drivers. (No POSIX Async I/O support here, sorry.) It -identifies the endpoint type (USBDEVFS_URB_TYPE_\*), endpoint +identifies the endpoint type (``USBDEVFS_URB_TYPE_*``), endpoint (number, masked with USB_DIR_IN as appropriate), buffer and length, and a user "context" value serving to uniquely identify each request. (It's usually a pointer to per-request data.) Flags can modify requests -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/21] usb/dma.txt: convert to ReST and add to driver-api book
This document describe some USB core features. Add it to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
.../{usb/dma.txt => driver-api/usb/dma.rst}| 51 --
Documentation/driver-api/usb/index.rst | 1 +
2 files changed, 28 insertions(+), 24 deletions(-)
rename Documentation/{usb/dma.txt => driver-api/usb/dma.rst} (79%)
diff --git a/Documentation/usb/dma.txt b/Documentation/driver-api/usb/dma.rst
similarity index 79%
rename from Documentation/usb/dma.txt
rename to Documentation/driver-api/usb/dma.rst
index 444651e70d95..59d5aee89e37 100644
--- a/Documentation/usb/dma.txt
+++ b/Documentation/driver-api/usb/dma.rst
@@ -1,16 +1,19 @@
+USB DMA
+~~~
+
In Linux 2.5 kernels (and later), USB device drivers have additional control
over how DMA may be used to perform I/O operations. The APIs are detailed
in the kernel usb programming guide (kerneldoc, from the source code).
-
-API OVERVIEW
+API overview
+
The big picture is that USB drivers can continue to ignore most DMA issues,
though they still must provide DMA-ready buffers (see
-Documentation/DMA-API-HOWTO.txt). That's how they've worked through
-the 2.4 (and earlier) kernels.
+``Documentation/DMA-API-HOWTO.txt``). That's how they've worked through
+the 2.4 (and earlier) kernels, or they can now be DMA-aware.
-OR: they can now be DMA-aware.
+DMA-aware usb drivers:
- New calls enable DMA-aware drivers, letting them allocate dma buffers and
manage dma mappings for existing dma-ready buffers (see below).
@@ -20,15 +23,15 @@ OR: they can now be DMA-aware.
drivers must not use it.)
- "usbcore" will map this DMA address, if a DMA-aware driver didn't do
- it first and set URB_NO_TRANSFER_DMA_MAP. HCDs
+ it first and set ``URB_NO_TRANSFER_DMA_MAP``. HCDs
don't manage dma mappings for URBs.
- There's a new "generic DMA API", parts of which are usable by USB device
drivers. Never use dma_set_mask() on any USB interface or device; that
would potentially break all devices sharing that bus.
-
-ELIMINATING COPIES
+Eliminating copies
+==
It's good to avoid making CPUs copy data needlessly. The costs can add up,
and effects like cache-trashing can impose subtle penalties.
@@ -41,7 +44,7 @@ and effects like cache-trashing can impose subtle penalties.
For those specific cases, USB has primitives to allocate less expensive
memory. They work like kmalloc and kfree versions that give you the right
kind of addresses to store in urb->transfer_buffer and urb->transfer_dma.
- You'd also set URB_NO_TRANSFER_DMA_MAP in urb->transfer_flags:
+ You'd also set ``URB_NO_TRANSFER_DMA_MAP`` in urb->transfer_flags::
void *usb_alloc_coherent (struct usb_device *dev, size_t size,
int mem_flags, dma_addr_t *dma);
@@ -49,15 +52,15 @@ and effects like cache-trashing can impose subtle penalties.
void usb_free_coherent (struct usb_device *dev, size_t size,
void *addr, dma_addr_t dma);
- Most drivers should *NOT* be using these primitives; they don't need
+ Most drivers should **NOT** be using these primitives; they don't need
to use this type of memory ("dma-coherent"), and memory returned from
- kmalloc() will work just fine.
+ :c:func:`kmalloc` will work just fine.
The memory buffer returned is "dma-coherent"; sometimes you might need to
force a consistent memory access ordering by using memory barriers. It's
not using a streaming DMA mapping, so it's good for small transfers on
systems where the I/O would otherwise thrash an IOMMU mapping. (See
- Documentation/DMA-API-HOWTO.txt for definitions of "coherent" and
+ ``Documentation/DMA-API-HOWTO.txt`` for definitions of "coherent" and
"streaming" DMA mappings.)
Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
@@ -75,15 +78,15 @@ and effects like cache-trashing can impose subtle penalties.
way to expose these capabilities ... and in any case, HIGHMEM is mostly a
design wart specific to x86_32. So your best bet is to ensure you never
pass a highmem buffer into a USB driver. That's easy; it's the default
- behavior. Just don't override it; e.g. with NETIF_F_HIGHDMA.
+ behavior. Just don't override it; e.g. with ``NETIF_F_HIGHDMA``.
This may force your callers to do some bounce buffering, copying from
high memory to "normal" DMA memory. If you can come up with a good way
to fix this issue (for x86_32 machines with over 1 GByte of memory),
feel free to submit patches.
-
-WORKING WITH EXISTING BUFFERS
+Working with existing buffers
+=
Existing buffers aren't usable for DMA without first being mapped into the
DMA address space of the device. H
[PATCH v2 04/21] usb.rst: Enrich its ReST representation
- use the proper warning and note markups;
- add references for parts of the document that will be
cross-referenced on other USB docs;
- some minor adjustments to make it better to read in
text mode and in html.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/usb/usb.rst | 48 +---
1 file changed, 17 insertions(+), 31 deletions(-)
diff --git a/Documentation/driver-api/usb/usb.rst
b/Documentation/driver-api/usb/usb.rst
index b856abb3200e..7e820768ee4f 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -102,6 +102,8 @@ disconnect testing (while the device is active) with each
different host
controller driver, to make sure drivers don't have bugs of their own as
well as to make sure they aren't relying on some HCD-specific behavior.
+.. _usb_chapter9:
+
USB-Standard Types
==
@@ -112,6 +114,8 @@ USB, and in APIs including this host side API, gadget APIs,
and usbfs.
.. kernel-doc:: include/linux/usb/ch9.h
:internal:
+.. _usb_header:
+
Host-Side Data Types and Macros
===
@@ -209,7 +213,7 @@ library that wraps it. Such libraries include
`libusb <http://libusb.sourceforge.net>`__ for C/C++, and
`jUSB <http://jUSB.sourceforge.net>`__ for Java.
-**Note**
+.. note::
This particular documentation is incomplete, especially with respect
to the asynchronous mode. As of kernel 2.5.66 the code and this
@@ -319,9 +323,7 @@ files. For information about the current format of this
file, see the
sources.
This file, in combination with the poll() system call, can also be used
-to detect when devices are added or removed:
-
-::
+to detect when devices are added or removed::
int fd;
struct pollfd pfd;
@@ -407,9 +409,7 @@ The ioctl() Requests
To use these ioctls, you need to include the following headers in your
-userspace program:
-
-::
+userspace program::
#include
#include
@@ -458,9 +458,7 @@ USBDEVFS_CLAIMINTERFACE
USBDEVFS_CONNECTINFO
Says whether the device is lowspeed. The ioctl parameter points to a
-structure like this:
-
-::
+structure like this::
struct usbdevfs_connectinfo {
unsigned int devnum;
@@ -477,9 +475,7 @@ USBDEVFS_CONNECTINFO
USBDEVFS_GETDRIVER
Returns the name of the kernel driver bound to a given interface (a
string). Parameter is a pointer to this structure, which is
-modified:
-
-::
+modified::
struct usbdevfs_getdriver {
unsigned int interface;
@@ -490,9 +486,7 @@ USBDEVFS_GETDRIVER
USBDEVFS_IOCTL
Passes a request from userspace through to a kernel driver that has
-an ioctl entry in the *struct usb_driver* it registered.
-
-::
+an ioctl entry in the *struct usb_driver* it registered::
struct usbdevfs_ioctl {
int ifno;
@@ -534,7 +528,7 @@ USBDEVFS_RELEASEINTERFACE
the number of the interface (bInterfaceNumber from descriptor); File
modification time is not updated by this request.
- **Warning**
+.. warning::
*No security check is made to ensure that the task which made
the claim is the one which is releasing it. This means that user
@@ -574,9 +568,7 @@ a time.
USBDEVFS_BULK
Issues a bulk read or write request to the device. The ioctl
-parameter is a pointer to this structure:
-
-::
+parameter is a pointer to this structure::
struct usbdevfs_bulktransfer {
unsigned int ep;
@@ -606,9 +598,7 @@ USBDEVFS_CLEAR_HALT
USBDEVFS_CONTROL
Issues a control request to the device. The ioctl parameter points
-to a structure like this:
-
-::
+to a structure like this::
struct usbdevfs_ctrltransfer {
__u8 bRequestType;
@@ -638,7 +628,7 @@ USBDEVFS_RESET
the reset, this rebinds all device interfaces. File modification
time is not updated by this request.
- **Warning**
+.. warning::
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
@@ -646,9 +636,7 @@ USBDEVFS_RESET
USBDEVFS_SETINTERFACE
Sets the alternate setting for an interface. The ioctl parameter is
-a pointer to a structure like this:
-
-::
+a pointer to a structure like this::
struct usbdevfs_setinterface {
unsigned int interface;
@@ -669,7 +657,7 @@ USBDEVFS_SETCONFIGURATION
configuration (bConfigurationValue from descriptor). File
modification time is not updated by this request.
- **Warning**
+.. warning::
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
@@ -702,9 +690,7 @@ When usbfs returns these urbs, the status value is updated,
and the
buffer
[PATCH v2 02/21] driver-api/basics.rst: add device table header
The structs there at device table are used by other documentation at the Kernel. So, add it to the driver API. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/basics.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst index 935b9b8d456c..472e7a664d13 100644 --- a/Documentation/driver-api/basics.rst +++ b/Documentation/driver-api/basics.rst @@ -7,6 +7,12 @@ Driver Entry and Exit points .. kernel-doc:: include/linux/init.h :internal: +Driver device table +--- + +.. kernel-doc:: include/linux/mod_devicetable.h + :internal: + Atomic and pointer manipulation --- -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/21] usb/bulk-streams.txt: convert to ReST and add to driver-api book
This document describe some USB core functions. Add it to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
.../bulk-streams.txt => driver-api/usb/bulk-streams.rst}| 13 +
Documentation/driver-api/usb/index.rst | 1 +
2 files changed, 10 insertions(+), 4 deletions(-)
rename Documentation/{usb/bulk-streams.txt => driver-api/usb/bulk-streams.rst}
(94%)
diff --git a/Documentation/usb/bulk-streams.txt
b/Documentation/driver-api/usb/bulk-streams.rst
similarity index 94%
rename from Documentation/usb/bulk-streams.txt
rename to Documentation/driver-api/usb/bulk-streams.rst
index ffc02021863e..99b515babdeb 100644
--- a/Documentation/usb/bulk-streams.txt
+++ b/Documentation/driver-api/usb/bulk-streams.rst
@@ -1,3 +1,6 @@
+USB bulk streams
+
+
Background
==
@@ -25,7 +28,9 @@ time.
Driver implications
===
-int usb_alloc_streams(struct usb_interface *interface,
+::
+
+ int usb_alloc_streams(struct usb_interface *interface,
struct usb_host_endpoint **eps, unsigned int num_eps,
unsigned int num_streams, gfp_t mem_flags);
@@ -53,7 +58,7 @@ controller driver, and may change in the future.
Picking new Stream IDs to use
-
+=
Stream ID 0 is reserved, and should not be used to communicate with devices.
If
usb_alloc_streams() returns with a value of N, you may use streams 1 though N.
@@ -68,9 +73,9 @@ Clean up
If a driver wishes to stop using streams to communicate with the device, it
-should call
+should call::
-void usb_free_streams(struct usb_interface *interface,
+ void usb_free_streams(struct usb_interface *interface,
struct usb_host_endpoint **eps, unsigned int num_eps,
gfp_t mem_flags);
diff --git a/Documentation/driver-api/usb/index.rst
b/Documentation/driver-api/usb/index.rst
index 5dfb04b2d730..6fe7611f7332 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -7,6 +7,7 @@ Linux USB API
usb
gadget
anchors
+ bulk-streams
writing_usb_driver
writing_musb_glue_layer
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/21] usb/anchors.txt: convert to ReST and add to driver-api book
This document describe some USB core functions. Add it to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
.../anchors.txt => driver-api/usb/anchors.rst} | 36 --
Documentation/driver-api/usb/index.rst | 1 +
2 files changed, 21 insertions(+), 16 deletions(-)
rename Documentation/{usb/anchors.txt => driver-api/usb/anchors.rst} (75%)
diff --git a/Documentation/usb/anchors.txt
b/Documentation/driver-api/usb/anchors.rst
similarity index 75%
rename from Documentation/usb/anchors.txt
rename to Documentation/driver-api/usb/anchors.rst
index fe6a99a32bbd..4b248e691bd6 100644
--- a/Documentation/usb/anchors.txt
+++ b/Documentation/driver-api/usb/anchors.rst
@@ -1,3 +1,6 @@
+USB Anchors
+~~~
+
What is anchor?
===
@@ -13,7 +16,7 @@ Allocation and Initialisation
=
There's no API to allocate an anchor. It is simply declared
-as struct usb_anchor. init_usb_anchor() must be called to
+as struct usb_anchor. :c:func:`init_usb_anchor` must be called to
initialise the data structure.
Deallocation
@@ -26,52 +29,53 @@ Association and disassociation of URBs with anchors
===
An association of URBs to an anchor is made by an explicit
-call to usb_anchor_urb(). The association is maintained until
+call to :c:func:`usb_anchor_urb`. The association is maintained until
an URB is finished by (successful) completion. Thus disassociation
is automatic. A function is provided to forcibly finish (kill)
all URBs associated with an anchor.
-Furthermore, disassociation can be made with usb_unanchor_urb()
+Furthermore, disassociation can be made with :c:func:`usb_unanchor_urb`
Operations on multitudes of URBs
-usb_kill_anchored_urbs()
-
+:c:func:`usb_kill_anchored_urbs`
+
This function kills all URBs associated with an anchor. The URBs
are called in the reverse temporal order they were submitted.
This way no data can be reordered.
-usb_unlink_anchored_urbs()
---
+:c:func:`usb_unlink_anchored_urbs`
+--
+
This function unlinks all URBs associated with an anchor. The URBs
are processed in the reverse temporal order they were submitted.
-This is similar to usb_kill_anchored_urbs(), but it will not sleep.
+This is similar to :c:func:`usb_kill_anchored_urbs`, but it will not sleep.
Therefore no guarantee is made that the URBs have been unlinked when
the call returns. They may be unlinked later but will be unlinked in
finite time.
-usb_scuttle_anchored_urbs()
+:c:func:`usb_scuttle_anchored_urbs`
+---
All URBs of an anchor are unanchored en masse.
-usb_wait_anchor_empty_timeout()
+:c:func:`usb_wait_anchor_empty_timeout`
+---
This function waits for all URBs associated with an anchor to finish
or a timeout, whichever comes first. Its return value will tell you
whether the timeout was reached.
-usb_anchor_empty()
---
+:c:func:`usb_anchor_empty`
+--
Returns true if no URBs are associated with an anchor. Locking
is the caller's responsibility.
-usb_get_from_anchor()
--
+:c:func:`usb_get_from_anchor`
+-
Returns the oldest anchored URB of an anchor. The URB is unanchored
and returned with a reference. As you may mix URBs to several
diff --git a/Documentation/driver-api/usb/index.rst
b/Documentation/driver-api/usb/index.rst
index cf2fa2e8d236..5dfb04b2d730 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -6,6 +6,7 @@ Linux USB API
usb
gadget
+ anchors
writing_usb_driver
writing_musb_glue_layer
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 21/21] docs-rst: fix usb cross-references
As some USB documentation files got moved, adjust their cross-references to their new place. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/sysfs-bus-usb| 2 +- Documentation/driver-api/usb/URB.rst | 2 ++ Documentation/driver-api/usb/callbacks.rst| 4 ++-- Documentation/driver-api/usb/error-codes.rst | 2 ++ Documentation/driver-api/usb/persist.rst | 2 ++ Documentation/driver-api/usb/power-management.rst | 2 +- Documentation/driver-api/usb/usb.rst | 4 ++-- Documentation/power/swsusp.txt| 2 +- drivers/staging/most/hdm-usb/hdm_usb.c| 2 +- drivers/usb/core/Kconfig | 2 +- 10 files changed, 15 insertions(+), 9 deletions(-) diff --git a/Documentation/ABI/stable/sysfs-bus-usb b/Documentation/ABI/stable/sysfs-bus-usb index 831f15d9672f..b832eeff 100644 --- a/Documentation/ABI/stable/sysfs-bus-usb +++ b/Documentation/ABI/stable/sysfs-bus-usb @@ -9,7 +9,7 @@ Description: hubs this facility is always enabled and their device directories will not contain this file. - For more information, see Documentation/usb/persist.txt. + For more information, see Documentation/driver-api/usb/persist.rst. What: /sys/bus/usb/devices/.../power/autosuspend Date: March 2007 diff --git a/Documentation/driver-api/usb/URB.rst b/Documentation/driver-api/usb/URB.rst index c4a141f29477..61a54da9fce9 100644 --- a/Documentation/driver-api/usb/URB.rst +++ b/Documentation/driver-api/usb/URB.rst @@ -1,3 +1,5 @@ +.. _usb-urb: + USB Request Block (URB) ~~~ diff --git a/Documentation/driver-api/usb/callbacks.rst b/Documentation/driver-api/usb/callbacks.rst index 93a8d53e27e7..2b80cf54bcc3 100644 --- a/Documentation/driver-api/usb/callbacks.rst +++ b/Documentation/driver-api/usb/callbacks.rst @@ -8,7 +8,7 @@ Usbcore will call into a driver through callbacks defined in the driver structure and through the completion handler of URBs a driver submits. Only the former are in the scope of this document. These two kinds of callbacks are completely independent of each other. Information on the -completion callback can be found in Documentation/usb/URB.txt. +completion callback can be found in :ref:`usb-urb`. The callbacks defined in the driver structure are: @@ -53,7 +53,7 @@ The callbacks defined in the driver structure are: The ioctl interface (2) should be used only if you have a very good reason. Sysfs is preferred these days. The PM callbacks are covered -separately in Documentation/usb/power-management.txt. +separately in :ref:`usb-power-management`. Calling conventions === diff --git a/Documentation/driver-api/usb/error-codes.rst b/Documentation/driver-api/usb/error-codes.rst index 9c11a0fd16cb..a3e84bfac776 100644 --- a/Documentation/driver-api/usb/error-codes.rst +++ b/Documentation/driver-api/usb/error-codes.rst @@ -1,3 +1,5 @@ +.. _usb-error-codes: + USB Error codes ~~~ diff --git a/Documentation/driver-api/usb/persist.rst b/Documentation/driver-api/usb/persist.rst index ea1b43f0559e..08cafc6292c1 100644 --- a/Documentation/driver-api/usb/persist.rst +++ b/Documentation/driver-api/usb/persist.rst @@ -1,3 +1,5 @@ +.. _usb-persist: + USB device persistence during system suspend diff --git a/Documentation/driver-api/usb/power-management.rst b/Documentation/driver-api/usb/power-management.rst index c068257f6d27..79beb807996b 100644 --- a/Documentation/driver-api/usb/power-management.rst +++ b/Documentation/driver-api/usb/power-management.rst @@ -328,7 +328,7 @@ possible to work around the hibernation-forces-disconnect problem by using the USB Persist facility.) The ``reset_resume`` method is used by the USB Persist facility (see -``Documentation/usb/persist.txt``) and it can also be used under certain +:ref:`usb-persist`) and it can also be used under certain circumstances when ``CONFIG_USB_PERSIST`` is not enabled. Currently, if a device is reset during a resume and the driver does not have a ``reset_resume`` method, the driver won't receive any notification about diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst index 5ebaf669704c..6824089ef4c8 100644 --- a/Documentation/driver-api/usb/usb.rst +++ b/Documentation/driver-api/usb/usb.rst @@ -424,8 +424,8 @@ header. Unless noted otherwise, the ioctl requests described here will update the modification time on the usbfs file to which they are applied (unless they fail). A return of zero indicates success; otherwise, a -standard USB error code is returned. (These are documented in -``Documentation/usb/error-codes.txt`` in your kernel sources.) +standard USB error code is returned (These are documented in +:ref:`usb-error-codes`). Each of these files multiplexes access to several I/O st
[PATCH v2 13/21] error-codes.rst: convert to ReST and add to driver-api book
This document describe some USB core features. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/usb/error-codes.rst | 205 +++ Documentation/driver-api/usb/index.rst | 1 + Documentation/usb/error-codes.txt| 175 --- 3 files changed, 206 insertions(+), 175 deletions(-) create mode 100644 Documentation/driver-api/usb/error-codes.rst delete mode 100644 Documentation/usb/error-codes.txt diff --git a/Documentation/driver-api/usb/error-codes.rst b/Documentation/driver-api/usb/error-codes.rst new file mode 100644 index ..9c11a0fd16cb --- /dev/null +++ b/Documentation/driver-api/usb/error-codes.rst @@ -0,0 +1,205 @@ +USB Error codes +~~~ + +:Revised: 2004-Oct-21 + +This is the documentation of (hopefully) all possible error codes (and +their interpretation) that can be returned from usbcore. + +Some of them are returned by the Host Controller Drivers (HCDs), which +device drivers only see through usbcore. As a rule, all the HCDs should +behave the same except for transfer speed dependent behaviors and the +way certain faults are reported. + + +Error codes returned by :c:func:`usb_submit_urb` + + +Non-USB-specific: + + +=== === +0 URB submission went fine + +``-ENOMEM``no memory for allocation of internal structures +=== === + +USB-specific: + +=== === +``-EBUSY`` The URB is already active. + +``-ENODEV``specified USB-device or bus doesn't exist + +``-ENOENT``specified interface or endpoint does not exist or + is not enabled + +``-ENXIO`` host controller driver does not support queuing of + this type of urb. (treat as a host controller bug.) + +``-EINVAL``a) Invalid transfer type specified (or not supported) + b) Invalid or unsupported periodic transfer interval + c) ISO: attempted to change transfer interval + d) ISO: ``number_of_packets`` is < 0 + e) various other cases + +``-EXDEV`` ISO: ``URB_ISO_ASAP`` wasn't specified and all the + frames the URB would be scheduled in have already + expired. + +``-EFBIG`` Host controller driver can't schedule that many ISO + frames. + +``-EPIPE`` The pipe type specified in the URB doesn't match the + endpoint's actual type. + +``-EMSGSIZE`` (a) endpoint maxpacket size is zero; it is not usable + in the current interface altsetting. + (b) ISO packet is larger than the endpoint maxpacket. + (c) requested data transfer length is invalid: negative + or too large for the host controller. + +``-ENOSPC``This request would overcommit the usb bandwidth reserved + for periodic transfers (interrupt, isochronous). + +``-ESHUTDOWN`` The device or host controller has been disabled due to + some problem that could not be worked around. + +``-EPERM`` Submission failed because ``urb->reject`` was set. + +``-EHOSTUNREACH`` URB was rejected because the device is suspended. + +``-ENOEXEC`` A control URB doesn't contain a Setup packet. +=== === + +Error codes returned by ``in urb->status`` or in ``iso_frame_desc[n].status`` (for ISO) +=== + +USB device drivers may only test urb status values in completion handlers. +This is because otherwise there would be a race between HCDs updating +these values on one CPU, and device drivers testing them on another CPU. + +A transfer's actual_length may be positive even when an error has been +reported. That's because transfers often involve several packets, so that +one or more packets could finish before an error stops further endpoint I/O. + +For isochronous URBs, the urb status value is non-zero only if the URB is +unlinked, the device is removed, the host controller is disabled, or the total +transferred length is less than the requested length and the +``URB_SHORT_NOT_OK`` flag is set. Completion handlers for isochronous URBs +should only see ``urb->status`` set to zero, ``-ENOENT``, ``-ECONNRESET``, +``-ESHUTDOWN``, or ``-EREMOTEIO``. Individual frame de
[PATCH v3] usb: document that URB transfer_buffer should be aligned
Several host controllers, commonly found on ARM, like dwc2, require buffers that are CPU-word aligned for they to work. Failing to do that will cause buffer overflows at the caller drivers, with could cause data corruption. Such data corruption was found, in practice, with the uvcdriver. Document it. Signed-off-by: Mauro Carvalho Chehab --- Note: this patch is based on my previous patch series with converts URB.txt to ReST: Subject: [PATCH v2 00/21] Convert USB documentation to ReST format Date: Wed, 5 Apr 2017 10:22:54 -0300 https://marc.info/?l=linux-doc&m=149139868231095&w=2 This patch, together with the ones above can be found on this tree: https://git.linuxtv.org/mchehab/experimental.git/log/?h=usb-docs-v2 Documentation/driver-api/usb/URB.rst | 12 drivers/usb/core/message.c | 15 +++ include/linux/usb.h | 12 3 files changed, 39 insertions(+) diff --git a/Documentation/driver-api/usb/URB.rst b/Documentation/driver-api/usb/URB.rst index 61a54da9fce9..8d3f362fbe82 100644 --- a/Documentation/driver-api/usb/URB.rst +++ b/Documentation/driver-api/usb/URB.rst @@ -271,6 +271,18 @@ If you specify your own start frame, make sure it's several frames in advance of the current frame. You might want this model if you're synchronizing ISO data with some other event stream. + .. warning:: + + Several host drivers have a 32-bits or 64-bits DMA transfer word size, + with usually matches the CPU word. Due to such restriction, you should + warrant that the @transfer_buffer is DWORD aligned, on 32 bits system, or + QDWORD aligned, on 64 bits system. You should also ensure that the + buffer has enough space for PAD bits. + + This condition is satisfied if you pass a buffer directly allocated by + kmalloc(), but this may not be the case if the driver allocates a bigger + buffer and point to a random place inside it. + How to start interrupt (INT) transfers? === diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c index 4c38ea41ae96..1662a4446475 100644 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -128,6 +128,21 @@ static int usb_internal_control_msg(struct usb_device *usb_dev, * make sure your disconnect() method can wait for it to complete. Since you * don't have a handle on the URB used, you can't cancel the request. * + * .. note:: + * + * Several host drivers require that the @data buffer to be aligned + * with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits). + * It is up to USB drivers should ensure that they'll only pass buffers + * with such alignments. + * + * Please also notice that, due to such restriction, the host driver + * may also override PAD bytes at the end of the @data buffer, up to the + * size of the CPU word. + * + * Such word alignment condition is normally ensured if the buffer is + * allocated with kmalloc(), but this may not be the case if the driver + * allocates a bigger buffer and point to a random place inside it. + * * Return: If successful, the number of bytes transferred. Otherwise, a negative * error number. */ diff --git a/include/linux/usb.h b/include/linux/usb.h index 7e68259360de..5739d4422343 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -1373,6 +1373,18 @@ typedef void (*usb_complete_t)(struct urb *); * capable, assign NULL to it, so that usbmon knows not to use the value. * The setup_packet must always be set, so it cannot be located in highmem. * + * .. warning:: + * + * Several host drivers have a 32-bits or 64-bits DMA transfer word size, + * with usually matches the CPU word. Due to such restriction, you should + * warrant that the @transfer_buffer is DWORD aligned, on 32 bits system, or + * QDWORD aligned, on 64 bits system. You should also ensure that the + * buffer has enough space for PAD bits. + * + * This condition is satisfied if you pass a buffer directly allocated by + * kmalloc(), but this may not be the case if the driver allocates a bigger + * buffer and point to a random place inside it. + * * Initialization: * * All URBs submitted must initialize the dev, pipe, transfer_flags (may be -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
Em Tue, 11 Apr 2017 16:58:40 +0200 Greg Kroah-Hartman escreveu: > On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote: > > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote: > > > On Wed, 5 Apr 2017 10:22:54 -0300 > > > Mauro Carvalho Chehab wrote: > > > > > > > Currently, there are several USB core documents that are at either > > > > written in plain text or in DocBook format. Convert them to ReST > > > > and add to the driver-api book. > > > > > > Greg, do you see any reason not to apply these for 4.12? A few of them > > > touch comments outside of Documentation/; I'm happy to carry those or > > > leave them to you, as you prefer. > > > > I'll queue them up in the next few days, thanks! > > Nope, they don't apply to my tree, it was probably based on yours. And > the first two are ones I shouldn't be taking. Yeah, I based it at the docs-next tree. If you prefer, I can rebase on your tree, but I guess that the docbook conversion patches would likely conflict with some patches at docs-next, because of the Makefile changes. > So, feel free to take all of these with a: > Acked-by: Greg Kroah-Hartman > for the USB-related patches (2-21). > > thanks, > > greg k-h Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] docs-rst/usb: usb/devices is now at /sys/kernel/debug/
The /proc/bus/usb/devices got moved to sysfs. It is now
sitting at:
/sys/kernel/debug/usb/devices
Fix the old references at the USB documentation
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/usb/usb.rst | 14 +++---
Documentation/usb/acm.txt| 2 +-
Documentation/usb/gadget_serial.txt | 4 ++--
Documentation/usb/proc_usb_info.txt | 20 ++--
4 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/Documentation/driver-api/usb/usb.rst
b/Documentation/driver-api/usb/usb.rst
index 6824089ef4c8..036e77038d42 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -233,7 +233,7 @@ What files are in "usbfs"?
Conventionally mounted at ``/proc/bus/usb``, usbfs features include:
-- ``/proc/bus/usb/devices`` ... a text file showing each of the USB
+- ``/sys/kernel/debug/usb/devices`` ... a text file showing each of the USB
devices on known to the kernel, and their configuration descriptors.
You can also poll() this to learn about new devices.
@@ -299,23 +299,23 @@ invocations of *mount*, are:
0)
*listgid*\ =N
-Controls the GID used for the /proc/bus/usb/devices and drivers
+Controls the GID used for the /sys/kernel/debug/usb/devices and drivers
files. (Default: 0)
*listmode*\ =MMM
-Controls the file mode used for the /proc/bus/usb/devices and
+Controls the file mode used for the /sys/kernel/debug/usb/devices and
drivers files. (Default: 0444)
*listuid*\ =N
-Controls the UID used for the /proc/bus/usb/devices and drivers
+Controls the UID used for the /sys/kernel/debug/usb/devices and drivers
files. (Default: 0)
Note that many Linux distributions hard-wire the mount options for usbfs
in their init scripts, such as ``/etc/rc.d/rc.sysinit``, rather than
making it easy to set this per-system policy in ``/etc/fstab``.
-/proc/bus/usb/devices
--
+/sys/kernel/debug/usb/devices
+-
This file is handy for status viewing tools in user mode, which can scan
the text format and ignore most of it. More detailed device status
@@ -330,7 +330,7 @@ to detect when devices are added or removed::
int fd;
struct pollfd pfd;
-fd = open("/proc/bus/usb/devices", O_RDONLY);
+fd = open("/sys/kernel/debug/usb/devices", O_RDONLY);
pfd = { fd, POLLIN, 0 };
for (;;) {
/* The first time through, this call will return immediately. */
diff --git a/Documentation/usb/acm.txt b/Documentation/usb/acm.txt
index 17f5c2e1a570..903abca10517 100644
--- a/Documentation/usb/acm.txt
+++ b/Documentation/usb/acm.txt
@@ -64,7 +64,7 @@ minicom, ppp and mgetty with them.
2. Verifying that it works
~~
- The first step would be to check /proc/bus/usb/devices, it should look
+ 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
diff --git a/Documentation/usb/gadget_serial.txt
b/Documentation/usb/gadget_serial.txt
index 6b4a88a8c8e3..d1def3186782 100644
--- a/Documentation/usb/gadget_serial.txt
+++ b/Documentation/usb/gadget_serial.txt
@@ -189,7 +189,7 @@ Once the gadget serial driver is loaded and the USB device
connected
to the Linux host with a USB cable, the host system should recognize
the gadget serial device. For example, the command
- cat /proc/bus/usb/devices
+ cat /sys/kernel/debug/usb/devices
should show something like this:
@@ -221,7 +221,7 @@ Once the gadget serial driver is loaded and the USB device
connected
to the Linux host with a USB cable, the host system should recognize
the gadget serial device. For example, the command
- cat /proc/bus/usb/devices
+ cat /sys/kernel/debug/usb/devices
should show something like this:
diff --git a/Documentation/usb/proc_usb_info.txt
b/Documentation/usb/proc_usb_info.txt
index 98be91982677..06d7960e9ae6 100644
--- a/Documentation/usb/proc_usb_info.txt
+++ b/Documentation/usb/proc_usb_info.txt
@@ -4,7 +4,7 @@
The usbfs filesystem for USB devices is traditionally mounted at
-/proc/bus/usb. It provides the /proc/bus/usb/devices file, as well as
+/proc/bus/usb. It provides the /sys/kernel/debug/usb/devices file, as well as
the /proc/bus/usb/BBB/DDD files.
In many modern systems the usbfs filesystem isn't used at all. Instead
@@ -24,7 +24,7 @@ USB device nodes are created under /dev/usb/ or someplace
similar. The
none /proc/bus/usb usbfs defaults 0 0
to /etc/fstab. This will mount usbfs at each reboot.
- You can then issue `cat /proc/bus/usb/devices` to extract
+ You can then issue `cat /sys/kernel/debug/usb/devices` to extract
USB device information, and user mode drivers can use usbfs
to interact with USB devices.
@@ -60,7 +60,7 @@ descriptors are in b
[PATCH 1/3] zr364xx.rst: usb/devices is now at /sys/kernel/debug/
The /proc/bus/usb/devices got moved to sysfs. It is now sitting at: /sys/kernel/debug/usb/devices Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/v4l-drivers/zr364xx.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/media/v4l-drivers/zr364xx.rst b/Documentation/media/v4l-drivers/zr364xx.rst index f5280e366826..3d193f01d8bb 100644 --- a/Documentation/media/v4l-drivers/zr364xx.rst +++ b/Documentation/media/v4l-drivers/zr364xx.rst @@ -30,7 +30,7 @@ You can try the experience changing the vendor/product ID values (look at the source code). You can get these values by looking at /var/log/messages when you plug -your camera, or by typing : cat /proc/bus/usb/devices. +your camera, or by typing : cat /sys/kernel/debug/usb/devices. If you manage to use your cam with this code, you can send me a mail (roy...@zerezo.com) with the name of your cam and a patch if needed. -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] docs-rst: usb: update old usbfs-related documentation
There's no usbfs anymore. The old features are now either
exported to /dev/bus/usb or via debugfs.
Update documentation accordingly, pointing to the new
places where the character devices and usb/devices are
now placed.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/usb/usb.rst | 180 ---
Documentation/usb/acm.txt| 2 +-
Documentation/usb/gadget_serial.txt | 4 +-
Documentation/usb/proc_usb_info.txt | 20 ++--
4 files changed, 73 insertions(+), 133 deletions(-)
diff --git a/Documentation/driver-api/usb/usb.rst
b/Documentation/driver-api/usb/usb.rst
index 6824089ef4c8..a98f78c91ab6 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -111,7 +111,8 @@ USB-Standard Types
In you will find the USB data types defined in
chapter 9 of the USB specification. These data types are used throughout
-USB, and in APIs including this host side API, gadget APIs, and usbfs.
+USB, and in APIs including this host side API, gadget APIs, usb character
+devices and debugfs interfaces.
.. kernel-doc:: include/linux/usb/ch9.h
:internal:
@@ -204,40 +205,32 @@ significantly reduce hcd-specific behaviors.
.. kernel-doc:: drivers/usb/core/buffer.c
:internal:
-The USB Filesystem (usbfs)
-==
+The USB character device nodes
+==
-This chapter presents the Linux *usbfs*. You may prefer to avoid writing
-new kernel code for your USB driver; that's the problem that usbfs set
-out to solve. User mode device drivers are usually packaged as
-applications or libraries, and may use usbfs through some programming
-library that wraps it. Such libraries include
+This chapter presents the Linux character device nodes. You may prefer
+to avoid writing new kernel code for your USB driver. User mode device
+drivers are usually packaged as applications or libraries, and may use
+character devices through some programming library that wraps it.
+Such libraries include
`libusb <http://libusb.sourceforge.net>`__ for C/C++, and
`jUSB <http://jUSB.sourceforge.net>`__ for Java.
.. note::
-This particular documentation is incomplete, especially with respect
-to the asynchronous mode. As of kernel 2.5.66 the code and this
-(new) documentation need to be cross-reviewed.
+ - They were used to be implemented via *usbfs*, but this is not part of
+the sysfs debug interface.
-Configure usbfs into Linux kernels by enabling the *USB filesystem*
-option (CONFIG_USB_DEVICEFS), and you get basic support for user mode
-USB device drivers. Until relatively recently it was often (confusingly)
-called *usbdevfs* although it wasn't solving what *devfs* was. Every USB
-device will appear in usbfs, regardless of whether or not it has a
-kernel driver.
+ - This particular documentation is incomplete, especially with respect
+ to the asynchronous mode. As of kernel 2.5.66 the code and this
+ (new) documentation need to be cross-reviewed.
-What files are in "usbfs"?
---
+What files are in "devtmpfs"?
+-
-Conventionally mounted at ``/proc/bus/usb``, usbfs features include:
+Conventionally mounted at ``/dev/bus/usb/``, usbfs features include:
-- ``/proc/bus/usb/devices`` ... a text file showing each of the USB
- devices on known to the kernel, and their configuration descriptors.
- You can also poll() this to learn about new devices.
-
-- ``/proc/bus/usb/BBB/DDD`` ... magic files exposing the each device's
+- ``/dev/bus/usb//BBB/DDD`` ... magic files exposing the each device's
configuration descriptors, and supporting a series of ioctls for
making device requests, including I/O to devices. (Purely for access
by programs.)
@@ -252,100 +245,7 @@ them. HID and networking devices expose these stable IDs,
so that for
example you can be sure that you told the right UPS to power down its
second server. "usbfs" doesn't (yet) expose those IDs.
-Mounting and Access Control
-
-There are a number of mount options for usbfs, which will be of most
-interest to you if you need to override the default access control
-policy. That policy is that only root may read or write device files
-(``/proc/bus/BBB/DDD``) although anyone may read the ``devices`` or
-``drivers`` files. I/O requests to the device also need the
-CAP_SYS_RAWIO capability,
-
-The significance of that is that by default, all user mode device
-drivers need super-user privileges. You can change modes or ownership in
-a driver setup when the device hotplugs, or maye just start the driver
-right then, as a privileged server (or some activity within one). That's
-the most secure approach for multi-user systems, but for single user
-systems ("trusted" by that user) it's more convenient just to grant
-everyon
[PATCH v3 2/3] usb: fix some references for /proc/bus/usb
Since when we got rid of usbfs, the /proc/bus/usb is now
elsewhere. Fix references for it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/pwc/philips.txt | 2 +-
drivers/usb/class/Kconfig | 2 +-
drivers/usb/class/usblp.c | 2 +-
drivers/usb/core/devices.c | 4 ++--
drivers/usb/storage/unusual_devs.h | 2 +-
include/linux/usb.h| 2 +-
tools/usb/usbip/README | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/pwc/philips.txt
b/drivers/media/usb/pwc/philips.txt
index d38dd791511e..be8c80eff374 100644
--- a/drivers/media/usb/pwc/philips.txt
+++ b/drivers/media/usb/pwc/philips.txt
@@ -140,7 +140,7 @@ dev_hint
A camera is specified by its type (the number from the camera model,
like PCA645, PCVC750VC, etc) and optionally the serial number (visible
- in /proc/bus/usb/devices). A hint consists of a string with the following
+ in /sys/kernel/debug/usb/devices). A hint consists of a string with the
following
format:
[type[.serialnumber]:]node
diff --git a/drivers/usb/class/Kconfig b/drivers/usb/class/Kconfig
index bb8b73682a70..971385fe9abc 100644
--- a/drivers/usb/class/Kconfig
+++ b/drivers/usb/class/Kconfig
@@ -12,7 +12,7 @@ config USB_ACM
Please read for details.
If your modem only reports "Cls=ff(vend.)" in the descriptors in
- /proc/bus/usb/devices, then your modem will not work with this
+ /sys/kernel/debug/usb/devices, then your modem will not work with this
driver.
To compile this driver as a module, choose M here: the
diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index cc61055fb9be..16e889a545e1 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -294,7 +294,7 @@ static int usblp_ctrl_msg(struct usblp *usblp, int request,
int type, int dir, i
/*
* See the description for usblp_select_alts() below for the usage
- * explanation. Look into your /proc/bus/usb/devices and dmesg in
+ * explanation. Look into your /sys/kernel/debug/usb/devices and dmesg in
* case of any trouble.
*/
static int proto_bias = -1;
diff --git a/drivers/usb/core/devices.c b/drivers/usb/core/devices.c
index f2987ddb1cde..55dea2e7828f 100644
--- a/drivers/usb/core/devices.c
+++ b/drivers/usb/core/devices.c
@@ -24,7 +24,7 @@
* /devices contains USB topology, device, config, class,
* interface, & endpoint data.
*
- * I considered using /proc/bus/usb/devices/device# for each device
+ * I considered using /dev/bus/usb/device# for each device
* as it is attached or detached, but I didn't like this for some
* reason -- maybe it's just too deep of a directory structure.
* I also don't like looking in multiple places to gather and view
@@ -40,7 +40,7 @@
* Converted the whole proc stuff to real
* read methods. Now not the whole device list needs to fit
* into one page, only the device list for one bus.
- * Added a poll method to /proc/bus/usb/devices, to wake
+ * Added a poll method to /sys/kernel/debug/usb/devices, to wake
* up an eventual usbd
* 2000-01-04: Thomas Sailer
* Turned into its own filesystem
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index 16cc18369111..a5f3e7d687f7 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -42,7 +42,7 @@
* - a patch that adds the entry for your device, including your
* email address right above the entry (plus maybe a brief
* explanation of the reason for the entry),
- * - a copy of /proc/bus/usb/devices with your device plugged in
+ * - a copy of /sys/kernel/debug/usb/devices with your device plugged in
* running with this patch.
* Send your submission to either Phil Dibowitz or
* Alan Stern , and don't forget to CC: the
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 7e68259360de..84bc5741d626 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -248,7 +248,7 @@ void usb_put_intf(struct usb_interface *intf);
* struct usb_interface (which persists only as long as its configuration
* is installed). The altsetting arrays can be accessed through these
* structures at any time, permitting comparison of configurations and
- * providing support for the /proc/bus/usb/devices pseudo-file.
+ * providing support for the /sys/kernel/debug/usb/devices pseudo-file.
*/
struct usb_interface_cache {
unsigned num_altsetting;/* number of alternate settings */
diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README
index 5eb2b6c7722b..7844490fc603 100644
--- a/tools/usb/usbip/README
+++ b/tools/usb/usbip/README
@@ -244,7 +244,7 @@ Detach the imported device:
- See 'Debug Tips' on the project wiki.
- http://usbip.wiki.sourceforge.net/how-to-debug-usbip
- usbip-host.ko must be bound to the target dev
[PATCH v3 1/3] docs-rst: usb: update old usbfs-related documentation
There's no usbfs anymore. The old features are now either
exported to /dev/bus/usb or via debugfs.
Update documentation accordingly, pointing to the new
places where the character devices and usb/devices are
now placed.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/usb/usb.rst | 180 --
Documentation/networking/cdc_mbim.txt | 2 +-
Documentation/usb/acm.txt | 2 +-
Documentation/usb/gadget_serial.txt | 4 +-
Documentation/usb/proc_usb_info.txt | 20 ++--
5 files changed, 74 insertions(+), 134 deletions(-)
diff --git a/Documentation/driver-api/usb/usb.rst
b/Documentation/driver-api/usb/usb.rst
index 6824089ef4c8..a98f78c91ab6 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -111,7 +111,8 @@ USB-Standard Types
In you will find the USB data types defined in
chapter 9 of the USB specification. These data types are used throughout
-USB, and in APIs including this host side API, gadget APIs, and usbfs.
+USB, and in APIs including this host side API, gadget APIs, usb character
+devices and debugfs interfaces.
.. kernel-doc:: include/linux/usb/ch9.h
:internal:
@@ -204,40 +205,32 @@ significantly reduce hcd-specific behaviors.
.. kernel-doc:: drivers/usb/core/buffer.c
:internal:
-The USB Filesystem (usbfs)
-==
+The USB character device nodes
+==
-This chapter presents the Linux *usbfs*. You may prefer to avoid writing
-new kernel code for your USB driver; that's the problem that usbfs set
-out to solve. User mode device drivers are usually packaged as
-applications or libraries, and may use usbfs through some programming
-library that wraps it. Such libraries include
+This chapter presents the Linux character device nodes. You may prefer
+to avoid writing new kernel code for your USB driver. User mode device
+drivers are usually packaged as applications or libraries, and may use
+character devices through some programming library that wraps it.
+Such libraries include
`libusb <http://libusb.sourceforge.net>`__ for C/C++, and
`jUSB <http://jUSB.sourceforge.net>`__ for Java.
.. note::
-This particular documentation is incomplete, especially with respect
-to the asynchronous mode. As of kernel 2.5.66 the code and this
-(new) documentation need to be cross-reviewed.
+ - They were used to be implemented via *usbfs*, but this is not part of
+the sysfs debug interface.
-Configure usbfs into Linux kernels by enabling the *USB filesystem*
-option (CONFIG_USB_DEVICEFS), and you get basic support for user mode
-USB device drivers. Until relatively recently it was often (confusingly)
-called *usbdevfs* although it wasn't solving what *devfs* was. Every USB
-device will appear in usbfs, regardless of whether or not it has a
-kernel driver.
+ - This particular documentation is incomplete, especially with respect
+ to the asynchronous mode. As of kernel 2.5.66 the code and this
+ (new) documentation need to be cross-reviewed.
-What files are in "usbfs"?
---
+What files are in "devtmpfs"?
+-
-Conventionally mounted at ``/proc/bus/usb``, usbfs features include:
+Conventionally mounted at ``/dev/bus/usb/``, usbfs features include:
-- ``/proc/bus/usb/devices`` ... a text file showing each of the USB
- devices on known to the kernel, and their configuration descriptors.
- You can also poll() this to learn about new devices.
-
-- ``/proc/bus/usb/BBB/DDD`` ... magic files exposing the each device's
+- ``/dev/bus/usb//BBB/DDD`` ... magic files exposing the each device's
configuration descriptors, and supporting a series of ioctls for
making device requests, including I/O to devices. (Purely for access
by programs.)
@@ -252,100 +245,7 @@ them. HID and networking devices expose these stable IDs,
so that for
example you can be sure that you told the right UPS to power down its
second server. "usbfs" doesn't (yet) expose those IDs.
-Mounting and Access Control
-
-There are a number of mount options for usbfs, which will be of most
-interest to you if you need to override the default access control
-policy. That policy is that only root may read or write device files
-(``/proc/bus/BBB/DDD``) although anyone may read the ``devices`` or
-``drivers`` files. I/O requests to the device also need the
-CAP_SYS_RAWIO capability,
-
-The significance of that is that by default, all user mode device
-drivers need super-user privileges. You can change modes or ownership in
-a driver setup when the device hotplugs, or maye just start the driver
-right then, as a privileged server (or some activity within one). That's
-the most secure approach for multi-user systems, but for single user
-systems ("trusted" by that user) i
Re: [PATCH 2/3] docs-rst/usb: usb/devices is now at /sys/kernel/debug/
Em Sun, 16 Apr 2017 10:39:58 -0400 (EDT) Alan Stern escreveu: > On Sun, 16 Apr 2017, Mauro Carvalho Chehab wrote: > > > The /proc/bus/usb/devices got moved to sysfs. It is now > > sitting at: > > /sys/kernel/debug/usb/devices > > > > Fix the old references at the USB documentation > > Many of the things you changed are still out of date. > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > Documentation/driver-api/usb/usb.rst | 14 +++--- > > Documentation/usb/acm.txt| 2 +- > > Documentation/usb/gadget_serial.txt | 4 ++-- > > Documentation/usb/proc_usb_info.txt | 20 ++-- > > 4 files changed, 20 insertions(+), 20 deletions(-) > > > > diff --git a/Documentation/driver-api/usb/usb.rst > > b/Documentation/driver-api/usb/usb.rst > > index 6824089ef4c8..036e77038d42 100644 > > --- a/Documentation/driver-api/usb/usb.rst > > +++ b/Documentation/driver-api/usb/usb.rst > > @@ -233,7 +233,7 @@ What files are in "usbfs"? > > > > Conventionally mounted at ``/proc/bus/usb``, usbfs features include: > > This whole section is highly misleading. usbfs no longer exists as a > filesystem. Instead, the files which used to be part of usbfs have > either moved to debugfs (/sys/kernel/debug/usb/devices) or are > character device nodes managed by systemctl/udev and typically created > under /dev/bus/usb. > > > @@ -299,23 +299,23 @@ invocations of *mount*, are: > > 0) > > > > *listgid*\ =N > > -Controls the GID used for the /proc/bus/usb/devices and drivers > > +Controls the GID used for the /sys/kernel/debug/usb/devices and drivers > > files. (Default: 0) > > > > *listmode*\ =MMM > > -Controls the file mode used for the /proc/bus/usb/devices and > > +Controls the file mode used for the /sys/kernel/debug/usb/devices and > > drivers files. (Default: 0444) > > > > *listuid*\ =N > > -Controls the UID used for the /proc/bus/usb/devices and drivers > > +Controls the UID used for the /sys/kernel/debug/usb/devices and drivers > > files. (Default: 0) > > > > Note that many Linux distributions hard-wire the mount options for usbfs > > in their init scripts, such as ``/etc/rc.d/rc.sysinit``, rather than > > making it easy to set this per-system policy in ``/etc/fstab``. > > This is all totally out of date. usbfs is no longer a filesystem that > can be mounted. True. Sent already a new patchset covering it, and other places where /proc/bus/bus are mentioned. Besides the stuff already fixed, there are still a few other bits to address: Documentation/usb/proc_usb_info.txt:/proc/bus/usb filesystem output Documentation/usb/proc_usb_info.txt:/proc/bus/usb. It provides the /sys/kernel/debug/usb/devices file, as well as Documentation/usb/proc_usb_info.txt:the /proc/bus/usb/BBB/DDD files. Documentation/usb/proc_usb_info.txt:**NOTE**: If /proc/bus/usb appears empty, and a host controller Documentation/usb/proc_usb_info.txt: mount -t usbfs none /proc/bus/usb Documentation/usb/proc_usb_info.txt: none /proc/bus/usb usbfs defaults 0 0 Documentation/usb/proc_usb_info.txt:THE /proc/bus/usb/BBB/DDD FILES: Documentation/usb/proc_usb_info.txt:devices. You would open the /proc/bus/usb/BBB/DDD file read/write, This should likely be merged at usb.rst file or fully reworked. include/uapi/linux/capability.h:/* Allow sending USB messages to any device via /proc/bus/usb */ include/uapi/linux/usb/ch9.h: * not other descriptors) are read from usbfs (i.e. /proc/bus/usb/BBB/DDD); I'll address this on a version 4. sound/usb/usx2y/us122l.c: sprintf(hw->name, "/proc/bus/usb/%03d/%03d/hwdeppcm", sound/usb/usx2y/usX2Yhwdep.c: sprintf(hw->name, "/proc/bus/usb/%03d/%03d", device->bus->busnum, device->devnum); sound/usb/usx2y/usx2yhwdeppcm.c:sprintf(hw->name, "/proc/bus/usb/%03d/%03d/hwdeppcm", dev->bus->busnum, dev->devnum); Not sure about the above. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/6] usb: fix some references for /proc/bus/usb
Since when we got rid of usbfs, the /proc/bus/usb is now
elsewhere. Fix references for it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/pwc/philips.txt | 2 +-
drivers/usb/class/Kconfig | 2 +-
drivers/usb/class/usblp.c | 2 +-
drivers/usb/core/devices.c | 4 ++--
drivers/usb/storage/unusual_devs.h | 2 +-
include/linux/usb.h| 2 +-
include/uapi/linux/capability.h| 2 +-
include/uapi/linux/usb/ch9.h | 3 ++-
tools/usb/usbip/README | 2 +-
9 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/pwc/philips.txt
b/drivers/media/usb/pwc/philips.txt
index d38dd791511e..be8c80eff374 100644
--- a/drivers/media/usb/pwc/philips.txt
+++ b/drivers/media/usb/pwc/philips.txt
@@ -140,7 +140,7 @@ dev_hint
A camera is specified by its type (the number from the camera model,
like PCA645, PCVC750VC, etc) and optionally the serial number (visible
- in /proc/bus/usb/devices). A hint consists of a string with the following
+ in /sys/kernel/debug/usb/devices). A hint consists of a string with the
following
format:
[type[.serialnumber]:]node
diff --git a/drivers/usb/class/Kconfig b/drivers/usb/class/Kconfig
index bb8b73682a70..971385fe9abc 100644
--- a/drivers/usb/class/Kconfig
+++ b/drivers/usb/class/Kconfig
@@ -12,7 +12,7 @@ config USB_ACM
Please read for details.
If your modem only reports "Cls=ff(vend.)" in the descriptors in
- /proc/bus/usb/devices, then your modem will not work with this
+ /sys/kernel/debug/usb/devices, then your modem will not work with this
driver.
To compile this driver as a module, choose M here: the
diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index cc61055fb9be..16e889a545e1 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -294,7 +294,7 @@ static int usblp_ctrl_msg(struct usblp *usblp, int request,
int type, int dir, i
/*
* See the description for usblp_select_alts() below for the usage
- * explanation. Look into your /proc/bus/usb/devices and dmesg in
+ * explanation. Look into your /sys/kernel/debug/usb/devices and dmesg in
* case of any trouble.
*/
static int proto_bias = -1;
diff --git a/drivers/usb/core/devices.c b/drivers/usb/core/devices.c
index f2987ddb1cde..55dea2e7828f 100644
--- a/drivers/usb/core/devices.c
+++ b/drivers/usb/core/devices.c
@@ -24,7 +24,7 @@
* /devices contains USB topology, device, config, class,
* interface, & endpoint data.
*
- * I considered using /proc/bus/usb/devices/device# for each device
+ * I considered using /dev/bus/usb/device# for each device
* as it is attached or detached, but I didn't like this for some
* reason -- maybe it's just too deep of a directory structure.
* I also don't like looking in multiple places to gather and view
@@ -40,7 +40,7 @@
* Converted the whole proc stuff to real
* read methods. Now not the whole device list needs to fit
* into one page, only the device list for one bus.
- * Added a poll method to /proc/bus/usb/devices, to wake
+ * Added a poll method to /sys/kernel/debug/usb/devices, to wake
* up an eventual usbd
* 2000-01-04: Thomas Sailer
* Turned into its own filesystem
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index 16cc18369111..a5f3e7d687f7 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -42,7 +42,7 @@
* - a patch that adds the entry for your device, including your
* email address right above the entry (plus maybe a brief
* explanation of the reason for the entry),
- * - a copy of /proc/bus/usb/devices with your device plugged in
+ * - a copy of /sys/kernel/debug/usb/devices with your device plugged in
* running with this patch.
* Send your submission to either Phil Dibowitz or
* Alan Stern , and don't forget to CC: the
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 7e68259360de..84bc5741d626 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -248,7 +248,7 @@ void usb_put_intf(struct usb_interface *intf);
* struct usb_interface (which persists only as long as its configuration
* is installed). The altsetting arrays can be accessed through these
* structures at any time, permitting comparison of configurations and
- * providing support for the /proc/bus/usb/devices pseudo-file.
+ * providing support for the /sys/kernel/debug/usb/devices pseudo-file.
*/
struct usb_interface_cache {
unsigned num_altsetting;/* number of alternate settings */
diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 49bc06295398..6fe14d001f68 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -205,7 +205,7 @@ struct vfs_cap_data {
#define CAP_SYS_MODULE 16
/* Allow ioper
[PATCH v4 5/6] zr364xx.rst: usb/devices is now at /sys/kernel/debug/
The /proc/bus/usb/devices got moved to sysfs. It is now sitting at: /sys/kernel/debug/usb/devices Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/v4l-drivers/zr364xx.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/media/v4l-drivers/zr364xx.rst b/Documentation/media/v4l-drivers/zr364xx.rst index f5280e366826..3d193f01d8bb 100644 --- a/Documentation/media/v4l-drivers/zr364xx.rst +++ b/Documentation/media/v4l-drivers/zr364xx.rst @@ -30,7 +30,7 @@ You can try the experience changing the vendor/product ID values (look at the source code). You can get these values by looking at /var/log/messages when you plug -your camera, or by typing : cat /proc/bus/usb/devices. +your camera, or by typing : cat /sys/kernel/debug/usb/devices. If you manage to use your cam with this code, you can send me a mail (roy...@zerezo.com) with the name of your cam and a patch if needed. -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/6] docs-rst: usb: update old usbfs-related documentation
There's no usbfs anymore. The old features are now either
exported to /dev/bus/usb or via debugfs.
Update documentation accordingly, pointing to the new
places where the character devices and usb/devices are
now placed.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/driver-api/usb/usb.rst | 180 --
Documentation/networking/cdc_mbim.txt | 2 +-
Documentation/usb/acm.txt | 2 +-
Documentation/usb/gadget_serial.txt | 4 +-
Documentation/usb/proc_usb_info.txt | 20 ++--
5 files changed, 74 insertions(+), 134 deletions(-)
diff --git a/Documentation/driver-api/usb/usb.rst
b/Documentation/driver-api/usb/usb.rst
index 6824089ef4c8..a98f78c91ab6 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -111,7 +111,8 @@ USB-Standard Types
In you will find the USB data types defined in
chapter 9 of the USB specification. These data types are used throughout
-USB, and in APIs including this host side API, gadget APIs, and usbfs.
+USB, and in APIs including this host side API, gadget APIs, usb character
+devices and debugfs interfaces.
.. kernel-doc:: include/linux/usb/ch9.h
:internal:
@@ -204,40 +205,32 @@ significantly reduce hcd-specific behaviors.
.. kernel-doc:: drivers/usb/core/buffer.c
:internal:
-The USB Filesystem (usbfs)
-==
+The USB character device nodes
+==
-This chapter presents the Linux *usbfs*. You may prefer to avoid writing
-new kernel code for your USB driver; that's the problem that usbfs set
-out to solve. User mode device drivers are usually packaged as
-applications or libraries, and may use usbfs through some programming
-library that wraps it. Such libraries include
+This chapter presents the Linux character device nodes. You may prefer
+to avoid writing new kernel code for your USB driver. User mode device
+drivers are usually packaged as applications or libraries, and may use
+character devices through some programming library that wraps it.
+Such libraries include
`libusb <http://libusb.sourceforge.net>`__ for C/C++, and
`jUSB <http://jUSB.sourceforge.net>`__ for Java.
.. note::
-This particular documentation is incomplete, especially with respect
-to the asynchronous mode. As of kernel 2.5.66 the code and this
-(new) documentation need to be cross-reviewed.
+ - They were used to be implemented via *usbfs*, but this is not part of
+the sysfs debug interface.
-Configure usbfs into Linux kernels by enabling the *USB filesystem*
-option (CONFIG_USB_DEVICEFS), and you get basic support for user mode
-USB device drivers. Until relatively recently it was often (confusingly)
-called *usbdevfs* although it wasn't solving what *devfs* was. Every USB
-device will appear in usbfs, regardless of whether or not it has a
-kernel driver.
+ - This particular documentation is incomplete, especially with respect
+ to the asynchronous mode. As of kernel 2.5.66 the code and this
+ (new) documentation need to be cross-reviewed.
-What files are in "usbfs"?
---
+What files are in "devtmpfs"?
+-
-Conventionally mounted at ``/proc/bus/usb``, usbfs features include:
+Conventionally mounted at ``/dev/bus/usb/``, usbfs features include:
-- ``/proc/bus/usb/devices`` ... a text file showing each of the USB
- devices on known to the kernel, and their configuration descriptors.
- You can also poll() this to learn about new devices.
-
-- ``/proc/bus/usb/BBB/DDD`` ... magic files exposing the each device's
+- ``/dev/bus/usb//BBB/DDD`` ... magic files exposing the each device's
configuration descriptors, and supporting a series of ioctls for
making device requests, including I/O to devices. (Purely for access
by programs.)
@@ -252,100 +245,7 @@ them. HID and networking devices expose these stable IDs,
so that for
example you can be sure that you told the right UPS to power down its
second server. "usbfs" doesn't (yet) expose those IDs.
-Mounting and Access Control
-
-There are a number of mount options for usbfs, which will be of most
-interest to you if you need to override the default access control
-policy. That policy is that only root may read or write device files
-(``/proc/bus/BBB/DDD``) although anyone may read the ``devices`` or
-``drivers`` files. I/O requests to the device also need the
-CAP_SYS_RAWIO capability,
-
-The significance of that is that by default, all user mode device
-drivers need super-user privileges. You can change modes or ownership in
-a driver setup when the device hotplugs, or maye just start the driver
-right then, as a privileged server (or some activity within one). That's
-the most secure approach for multi-user systems, but for single user
-systems ("trusted" by that user) i
[PATCH v4 4/6] usb.rst: move documentation from proc_usb_info.txt to USB ReST book
The contents of proc_usb_info.txt complements what's there at driver-api usb book. Yet, it is outdated, as it still refers to the USB character devices as usbfs. So, move the contents to usb.rst, adjusting it to point to the right places. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/usb/usb.rst | 437 --- Documentation/usb/proc_usb_info.txt | 390 --- 2 files changed, 404 insertions(+), 423 deletions(-) delete mode 100644 Documentation/usb/proc_usb_info.txt diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst index a98f78c91ab6..dba0f876b36f 100644 --- a/Documentation/driver-api/usb/usb.rst +++ b/Documentation/driver-api/usb/usb.rst @@ -212,9 +212,14 @@ This chapter presents the Linux character device nodes. You may prefer to avoid writing new kernel code for your USB driver. User mode device drivers are usually packaged as applications or libraries, and may use character devices through some programming library that wraps it. -Such libraries include -`libusb <http://libusb.sourceforge.net>`__ for C/C++, and -`jUSB <http://jUSB.sourceforge.net>`__ for Java. +Such libraries include: + + - `libusb <http://libusb.sourceforge.net>`__ for C/C++, and + - `jUSB <http://jUSB.sourceforge.net>`__ for Java. + +Some old information about it can be seen at the "USB Device Filesystem" +section of the USB Guide. The latest copy of the USB Guide can be found +at http://www.linux-usb.org/ .. note:: @@ -230,45 +235,80 @@ What files are in "devtmpfs"? Conventionally mounted at ``/dev/bus/usb/``, usbfs features include: -- ``/dev/bus/usb//BBB/DDD`` ... magic files exposing the each device's +- ``/dev/bus/usb/BBB/DDD`` ... magic files exposing the each device's configuration descriptors, and supporting a series of ioctls for making device requests, including I/O to devices. (Purely for access by programs.) -Each bus is given a number (BBB) based on when it was enumerated; within -each bus, each device is given a similar number (DDD). Those BBB/DDD +Each bus is given a number (``BBB``) based on when it was enumerated; within +each bus, each device is given a similar number (``DDD``). Those ``BBB/DDD`` paths are not "stable" identifiers; expect them to change even if you always leave the devices plugged in to the same hub port. *Don't even think of saving these in application configuration files.* Stable identifiers are available, for user mode applications that want to use them. HID and networking devices expose these stable IDs, so that for example you can be sure that you told the right UPS to power down its -second server. "usbfs" doesn't (yet) expose those IDs. +second server. Pleast note that it doesn't (yet) expose those IDs. -/dev/bus/usb//BBB/DDD -- +/dev/bus/usb/BBB/DDD + Use these files in one of these basic ways: -*They can be read,* producing first the device descriptor (18 bytes) and -then the descriptors for the current configuration. See the USB 2.0 spec -for details about those binary data formats. You'll need to convert most -multibyte values from little endian format to your native host byte -order, although a few of the fields in the device descriptor (both of -the BCD-encoded fields, and the vendor and product IDs) will be -byteswapped for you. Note that configuration descriptors include -descriptors for interfaces, altsettings, endpoints, and maybe additional -class descriptors. +- *They can be read,* producing first the device descriptor (18 bytes) and + then the descriptors for the current configuration. See the USB 2.0 spec + for details about those binary data formats. You'll need to convert most + multibyte values from little endian format to your native host byte + order, although a few of the fields in the device descriptor (both of + the BCD-encoded fields, and the vendor and product IDs) will be + byteswapped for you. Note that configuration descriptors include + descriptors for interfaces, altsettings, endpoints, and maybe additional + class descriptors. + +- *Perform USB operations* using *ioctl()* requests to make endpoint I/O + requests (synchronously or asynchronously) or manage the device. These + requests need the ``CAP_SYS_RAWIO`` capability, as well as filesystem + access permissions. Only one ioctl request can be made on one of these + device files at a time. This means that if you are synchronously reading + an endpoint from one thread, you won't be able to write to a different + endpoint from another thread until the read completes. This works for + *half duplex* protocols, but otherwise you'd use asynchronous i/o + requests. + +Each connected USB device has one file. The ``BBB`` indicates the bus +number. The ``DDD`` indicates the device address
[PATCH v4 6/6] sound: replace /proc/bus/usb by /dev/bus/usb
The /proc/bus/usb devices don't exist anymore, since when we
got rid of usbfs. Those devices are now seen at
/dev/bus/usb.
Signed-off-by: Mauro Carvalho Chehab
---
sound/usb/usx2y/us122l.c| 2 +-
sound/usb/usx2y/usX2Yhwdep.c| 2 +-
sound/usb/usx2y/usx2yhwdeppcm.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/usb/usx2y/us122l.c b/sound/usb/usx2y/us122l.c
index cf45bf1f7ee0..e118bdca983d 100644
--- a/sound/usb/usx2y/us122l.c
+++ b/sound/usb/usx2y/us122l.c
@@ -472,7 +472,7 @@ static int usb_stream_hwdep_new(struct snd_card *card)
hw->ops.mmap = usb_stream_hwdep_mmap;
hw->ops.poll = usb_stream_hwdep_poll;
- sprintf(hw->name, "/proc/bus/usb/%03d/%03d/hwdeppcm",
+ sprintf(hw->name, "/dev/bus/usb/%03d/%03d/hwdeppcm",
dev->bus->busnum, dev->devnum);
return 0;
}
diff --git a/sound/usb/usx2y/usX2Yhwdep.c b/sound/usb/usx2y/usX2Yhwdep.c
index 605e1047c01d..f4b3cda412fc 100644
--- a/sound/usb/usx2y/usX2Yhwdep.c
+++ b/sound/usb/usx2y/usX2Yhwdep.c
@@ -258,7 +258,7 @@ int usX2Y_hwdep_new(struct snd_card *card, struct
usb_device* device)
hw->ops.mmap = snd_us428ctls_mmap;
hw->ops.poll = snd_us428ctls_poll;
hw->exclusive = 1;
- sprintf(hw->name, "/proc/bus/usb/%03d/%03d", device->bus->busnum,
device->devnum);
+ sprintf(hw->name, "/dev/bus/usb/%03d/%03d", device->bus->busnum,
device->devnum);
return 0;
}
diff --git a/sound/usb/usx2y/usx2yhwdeppcm.c b/sound/usb/usx2y/usx2yhwdeppcm.c
index f95164b91152..d51c7fd7835b 100644
--- a/sound/usb/usx2y/usx2yhwdeppcm.c
+++ b/sound/usb/usx2y/usx2yhwdeppcm.c
@@ -723,7 +723,7 @@ int usX2Y_hwdep_pcm_new(struct snd_card *card)
hw->ops.release = snd_usX2Y_hwdep_pcm_release;
hw->ops.mmap = snd_usX2Y_hwdep_pcm_mmap;
hw->exclusive = 1;
- sprintf(hw->name, "/proc/bus/usb/%03d/%03d/hwdeppcm", dev->bus->busnum,
dev->devnum);
+ sprintf(hw->name, "/dev/bus/usb/%03d/%03d/hwdeppcm", dev->bus->busnum,
dev->devnum);
err = snd_pcm_new(card, NAME_ALLCAPS" hwdep Audio", 2, 1, 1, &pcm);
if (err < 0) {
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/6] [media] convert philips.txt to ReST and add to media docs
The philips.txt file were at the wrong place: it should be, instead, at Documentation/media. Move and convert it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/v4l-drivers/index.rst | 1 + .../media/v4l-drivers/philips.rst | 21 +++-- 2 files changed, 16 insertions(+), 6 deletions(-) rename drivers/media/usb/pwc/philips.txt => Documentation/media/v4l-drivers/philips.rst (95%) diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst index a606d1cdac13..90fe22a6414a 100644 --- a/Documentation/media/v4l-drivers/index.rst +++ b/Documentation/media/v4l-drivers/index.rst @@ -45,6 +45,7 @@ For more details see the file COPYING in the source distribution of Linux. meye omap3isp omap4_camera + philips pvrusb2 pxa_camera radiotrack diff --git a/drivers/media/usb/pwc/philips.txt b/Documentation/media/v4l-drivers/philips.rst similarity index 95% rename from drivers/media/usb/pwc/philips.txt rename to Documentation/media/v4l-drivers/philips.rst index be8c80eff374..f7fd6b8ae4f3 100644 --- a/drivers/media/usb/pwc/philips.txt +++ b/Documentation/media/v4l-drivers/philips.rst @@ -1,8 +1,12 @@ +Philips webcams (pwc driver) + + This file contains some additional information for the Philips and OEM webcams. E-mail: web...@smcc.demon.nlLast updated: 2004-01-19 Site: http://www.smcc.demon.nl/webcam/ As of this moment, the following cameras are supported: + * Philips PCA645 * Philips PCA646 * Philips PCVC675 @@ -89,7 +93,8 @@ power_save compression (only useful with the plugin) With this option you can control the compression factor that the camera uses to squeeze the image through the USB bus. You can set the - parameter between 0 and 3: + parameter between 0 and 3:: + 0 = prefer uncompressed images; if the requested mode is not available in an uncompressed format, the driver will silently switch to low compression. @@ -109,11 +114,11 @@ compression (only useful with the plugin) leds This settings takes 2 integers, that define the on/off time for the LED (in milliseconds). One of the interesting things that you can do with - this is let the LED blink while the camera is in use. This: + this is let the LED blink while the camera is in use. This:: leds=500,500 - will blink the LED once every second. But with: + will blink the LED once every second. But with:: leds=0,0 @@ -141,7 +146,7 @@ dev_hint A camera is specified by its type (the number from the camera model, like PCA645, PCVC750VC, etc) and optionally the serial number (visible in /sys/kernel/debug/usb/devices). A hint consists of a string with the following - format: + format:: [type[.serialnumber]:]node @@ -150,7 +155,7 @@ dev_hint would be rather pointless). The serialnumber is separated from the type by a '.'; the node number by a ':'. - This somewhat cryptic syntax is best explained by a few examples: + This somewhat cryptic syntax is best explained by a few examples:: dev_hint=3,5 The first detected cam gets assigned /dev/video3, the second /dev/video5. Any @@ -170,6 +175,7 @@ dev_hint through /dev/video6. Some points worth knowing: + - Serialnumbers are case sensitive and must be written full, including leading zeroes (it's treated as a string). - If a device node is already occupied, registration will fail and @@ -189,8 +195,10 @@ trace If you want to trace something, look up the bit value(s) in the table below, add the values together and supply that to the trace variable. + == === === Value Value Description Default (dec) (hex) + == === === 10x1 Module initialization; this will log messages On while loading and unloading the module @@ -208,6 +216,7 @@ trace 64 0x40 Show viewport and image sizes Off 128 0x80 PWCX debugging Off + == === === For example, to trace the open() & read() functions, sum 8 + 4 = 12, so you would supply trace=12 during insmod or modprobe. If @@ -216,7 +225,7 @@ trace -Example: +Example:: # modprobe pwc size=cif fps=15 power_save=1 -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/6] Get rid of usbfs leftovers
When we got rid of usbfs, the old /proc/bus/usb stuff got moved to two different places: usb/devices is now at /sys/kernel/debug /proc/bus/usb/BBB/DDD are not at /dev/bus/usb/BBB/DDD However, the documentation and a few other places at the source tree still points to the old location. Get rid of those leftovers. This patch series is based on docs next branch. PS.: There are some left overs also at xpad documentation. As this file was converted to ReST at the input tree, I'm submitting the patches to it on a separate patch series. Jon, There are two patches here that are for the stuff under media. Those patches shouldn't conflict with the stuff I have on my tree. So, feel free to merge them via your tree (or if you prefer, I can merge them myself). Mauro Carvalho Chehab (6): docs-rst: usb: update old usbfs-related documentation usb: fix some references for /proc/bus/usb [media] convert philips.txt to ReST and add to media docs usb.rst: move documentation from proc_usb_info.txt to USB ReST book zr364xx.rst: usb/devices is now at /sys/kernel/debug/ sound: replace /proc/bus/usb by /dev/bus/usb Documentation/driver-api/usb/usb.rst | 609 - Documentation/media/v4l-drivers/index.rst | 1 + .../media/v4l-drivers/philips.rst | 23 +- Documentation/media/v4l-drivers/zr364xx.rst| 2 +- Documentation/networking/cdc_mbim.txt | 2 +- Documentation/usb/acm.txt | 2 +- Documentation/usb/gadget_serial.txt| 4 +- Documentation/usb/proc_usb_info.txt| 390 - drivers/usb/class/Kconfig | 2 +- drivers/usb/class/usblp.c | 2 +- drivers/usb/core/devices.c | 4 +- drivers/usb/storage/unusual_devs.h | 2 +- include/linux/usb.h| 2 +- include/uapi/linux/capability.h| 2 +- include/uapi/linux/usb/ch9.h | 3 +- sound/usb/usx2y/us122l.c | 2 +- sound/usb/usx2y/usX2Yhwdep.c | 2 +- sound/usb/usx2y/usx2yhwdeppcm.c| 2 +- tools/usb/usbip/README | 2 +- 19 files changed, 495 insertions(+), 563 deletions(-) rename drivers/media/usb/pwc/philips.txt => Documentation/media/v4l-drivers/philips.rst (94%) delete mode 100644 Documentation/usb/proc_usb_info.txt -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] Get rid of usbfs leftovers
Em Thu, 20 Apr 2017 15:32:44 -0600 Jonathan Corbet escreveu: > On Sun, 16 Apr 2017 21:51:05 -0300 > Mauro Carvalho Chehab wrote: > > > When we got rid of usbfs, the old /proc/bus/usb stuff got moved > > to two different places: > > usb/devices is now at /sys/kernel/debug > > /proc/bus/usb/BBB/DDD are not at /dev/bus/usb/BBB/DDD > > > > However, the documentation and a few other places at the > > source tree still points to the old location. > > > > Get rid of those leftovers. > > > > This patch series is based on docs next branch. > > > > PS.: There are some left overs also at xpad documentation. > > As this file was converted to ReST at the input tree, I'm > > submitting the patches to it on a separate patch series. > > > > Jon, > > > > There are two patches here that are for the stuff under > > media. Those patches shouldn't conflict with the stuff > > I have on my tree. So, feel free to merge them via your > > tree (or if you prefer, I can merge them myself). > > OK, I've applied everything except parts 2 (taken by Greg) and 6 (taken > by Takashi). Hopefully I've managed to keep everything straight... Thanks! Yeah, that looks right. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/13] usb: fix the comment with regards to DocBook
The USB gadget documentation is not at DocBook anymore. The main file was converted to ReST, and stored at Documentation/driver-api/usb/gadget.rst, but there are still several plain text files related to gadget under Documentation/usb. So, be generic and just mention documentation without specifying where it is. Signed-off-by: Mauro Carvalho Chehab --- drivers/usb/gadget/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index c164d6b788c3..b3c879b75a39 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -41,7 +41,7 @@ menuconfig USB_GADGET don't have this kind of hardware (except maybe inside Linux PDAs). For more information, see <http://www.linux-usb.org/gadget> and - the kernel DocBook documentation for this API. + the kernel documentation for this API. if USB_GADGET -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 51/53] usb: fix the comment with regards to DocBook
The USB gadget documentation is not at DocBook anymore. The main file was converted to ReST, and stored at Documentation/driver-api/usb/gadget.rst, but there are still several plain text files related to gadget under Documentation/usb. So, be generic and just mention documentation without specifying where it is. Signed-off-by: Mauro Carvalho Chehab --- drivers/usb/gadget/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index c164d6b788c3..b3c879b75a39 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -41,7 +41,7 @@ menuconfig USB_GADGET don't have this kind of hardware (except maybe inside Linux PDAs). For more information, see <http://www.linux-usb.org/gadget> and - the kernel DocBook documentation for this API. + the kernel documentation for this API. if USB_GADGET -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More than one isoc transfers with usb 2.0 hardware
On Fri, 8 Feb 2008 10:48:54 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > On Fri, 8 Feb 2008, Mauro Carvalho Chehab wrote: > > > Hi Guys, > > > > There's currently an issue with isoc transfers made by em28xx driver[1] and > > ehcd_hci. If I try to start isoc transfers on more than one hardware, the > > second hardware fails at usb_submit_urb() with -ENOSPC. > > ENOSPC means that you are attempting to use more bandwidth than the bus > allows. A high-speed isochronous transfer of length 3072 requires 41% > of the total bandwidth (according to Table 5-5 in the USB 2.0 spec), > and periodic transfers (isochronous and interrupt) on a high-speed bus > are limited to no more than 80% of the total bandwidth. > > Performing transfers to two devices would require 82% of the bandwidth; > hence it isn't allowed. Thanks! I'll try to decrease the transfer length, using an alternative setting. > > urb->transfer_flags = URB_ISO_ASAP; > > Since you have set urb->transfer_dma, you also need to set > URB_NO_TRANSFER_DMA_MAP in urb->flags. Added, thanks. > > > urb->interval = 1; > > urb->transfer_buffer = dev->transfer_buffer[i]; > > urb->complete = em28xx_isocIrq; > > urb->number_of_packets = 40; > > urb->transfer_buffer_length = size; > > for (j = 0; j < 40; j++) > > urb->iso_frame_desc[j].offset = j * max_pkt_size; > > Where do you set urb->iso_frame_desc[i].length? I've accidentally removed the code when cleaning the e-mail. The real code is doing: urb->iso_frame_desc[j].offset = max_pkt_size; > You may need to put your two devices on separate USB buses. Thanks. The tests I'm doing are on a notebook. Unfortunately, all 4 usb ports shares the same USB host. I'll repeat the tests on a device with separate usb hosts. Cheers, Mauro - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
More than one isoc transfers with usb 2.0 hardware
Hi Guys,
There's currently an issue with isoc transfers made by em28xx driver[1] and
ehcd_hci. If I try to start isoc transfers on more than one hardware, the
second hardware fails at usb_submit_urb() with -ENOSPC.
The current code that initializes isoc transfers looks like this (I've removed
error handling and replaced some constants to make it cleaner to read):
max_pkt_size = 3072;
size = 40 * max_pkt_size;
for (i = 0; i < 5; i++) {
urb = usb_alloc_urb(40, GFP_KERNEL);
dev->transfer_buffer[i] = usb_buffer_alloc(usb_dev, size,
GFP_KERNEL, &urb->transfer_dma);
memset(dev->transfer_buffer[i], 0, size);
urb->dev = usb_udev;
urb->context = v4l_dev;
urb->pipe = usb_rcvisocpipe(usb_dev, 0x82);
urb->transfer_flags = URB_ISO_ASAP;
urb->interval = 1;
urb->transfer_buffer = dev->transfer_buffer[i];
urb->complete = em28xx_isocIrq;
urb->number_of_packets = 40;
urb->transfer_buffer_length = size;
for (j = 0; j < 40; j++)
urb->iso_frame_desc[j].offset = j * max_pkt_size;
dev->urb[i] = urb;
}
for (i = 0; i < 5; i++)
usb_submit_urb(dev->urb[i], GFP_KERNEL);
Any ideas on how this could work?
[1] The complete code is at:
http://linuxtv.org/hg/v4l-dvb/file/3be355e3e327/linux/drivers/media/video/em28xx/em28xx-core.c
Cheers,
Mauro
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More than one isoc transfers with usb 2.0 hardware
On Sat, 9 Feb 2008 11:34:35 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > On Sat, 9 Feb 2008, David Brownell wrote: > > > On Friday 08 February 2008, Alan Stern wrote: > > > > > > > There's currently an issue with isoc transfers made by em28xx driver[1] > > > > and > > > > ehcd_hci. If I try to start isoc transfers on more than one hardware, > > > > the > > > > second hardware fails at usb_submit_urb() with -ENOSPC. > > > > > > ENOSPC means that you are attempting to use more bandwidth than the bus > > > allows. A high-speed isochronous transfer of length 3072 requires 41% > > > of the total bandwidth (according to Table 5-5 in the USB 2.0 spec), > > > and periodic transfers (isochronous and interrupt) on a high-speed bus > > > are limited to no more than 80% of the total bandwidth. > > > > > > Performing transfers to two devices would require 82% of the bandwidth; > > > hence it isn't allowed. > > > > Well, the USB 2.0 spec is internally inconsistent on that point. > > > > And when I've asked the USB-IF for resolution on that, or maybe > > issuance of an erratum, they've been silent. (Greg, maybe you > > can do something about that now? The issue's been reported for > > quite a few years now.) > > > > See table 5.5, at the bottom (section 5.6). Somehow it thinks > > that twice 41% is below the 80% limit (listed in section 5.6.4, > > paragraph 2). Similarly, table 5.8, at the bottom (section 5.7) > > which again repeats the 80% limit (para 1 of section 5.7.4). > > The 80% limit is referenced section 5.10 too. > > Wow, I never noticed that. Although thinking back, I probably did see > other mistakes in those tables... > > > Somebody at USB-IF was refusing to do some basic math, or has > > been ignoring this obvious spec bug. Either both those tables > > are wrong, or the three references to an 80% limit are wrong. > > There are no other resolutions to this bug. > > I'm inclined to believe that the USB-IF meant the 80% limit to apply as > stated and the tables are wrong. As a simple example, let's consider a > high-speed Isochronous transfer of 3072 bytes. This actually goes on > the wire as three transactions, each of length 1024. According to the > bus-transaction-time formulas in section 5.11.3, each transaction > uses (in nanoseconds): > > (38 * 8 * 2.083) + (2.083 * Floor(3.167 + BitStuffTime(Data_bc))) + > Host_Delay > > Here Data_bc is 1024 and Host_Delay is unknown, assumed to be 0. The > BitStuffTime formula is: (1.1667*8*Data_bc). Doing the calculation > yields a total of 3 * 20546.7 ns = 61640.1 ns = 49.3% of a uframe -- > not 41%. Even the single-transaction 1024-byte case comes out to 16.4%, > not 14% as the table says. > > If you subtract out the overhead due to the SOF packet, it's even > worse. So clearly the tables are wrong. My tests here were receiving a video stream whose resolution is 720x480x30fps, 16 bits/pixel. That means a 20.736 MB/s (about 166 Mbps) stream rate (without USB oveheads). A cat /proc/bus/usb shows this: B: Alloc=480/800 us (60%), #Int= 0, #Iso= 2 > > > I'd be tempted to accept a patch teaching EHCI that the limit > > is really 82%, or whatever ... but I also think it's overdue > > for the USB-IF to correct their spec. > > Indeed. > > Alan Stern > Cheers, Mauro - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Magewell Gen 2935:0001 USB annoyances
Em Mon, 14 Jan 2019 13:10:25 +0800 Kai Hendry escreveu: > Archlinux user here. It doesn't matter whether I'm running LTS kernel > 4.19.14-1-lts or 4.20.1.arch1-1, I get these very annoying USB issues with my > Magewell XI100DUSB-HDMI. Most of the time it doesn't work. I seemingly have > better chances of getting it working after a reboot. > > I don't know if this is a UVC issue or a USB issue on my Gen8 Thinkpad T480s. > All I can say for a fact is that plugging this device into my Macbook Pro > running MacOS via a USB-C dongle, is more reliable. I've had the same "plug > in" issues admittedly on previous Thinkpad hardware and kernel versions. > > Another annoying aspect, is that it also seems to drop USB speeds when hot > plugging. I need USB 3 else it won't be able to get 60fps at 1080p. (adding c/c to linux-usb) If the image is not compressed, a 640x480 image with 16 bits per pixel and 30 frames per second eats 60% of the USB 2.0 maximum number of ISOC frames with em28xx driver[1]. [1] The actual value is driver/device specific, as it depends on the maximum frame size. So, I'm pretty sure that you won't be able to get 60fps at 1080p if it doesn't enable USB 3.0 SuperSpeed mode. That's said, it is up to the USB stack to detect the device as an USB 3.0. If this is not working well, it could either be a hardware problem or some issue at the USB host driver. > https://s.natalian.org/2019-01-14/1547438681_2548x1398.png > > It's a crazy ritual with accompanying dance when I get USB3 and my > /dev/video2 actually working. > > This is what dmesg looks like when it's flailing. > > [ 71.896534] usb 2-2: Disable of device-initiated U1 failed. > [ 71.900554] usb 2-2: Disable of device-initiated U2 failed. > [ 71.909474] usb 2-2: Set SEL for device-initiated U1 failed. > [ 72.691371] usb 2-2: USB disconnect, device number 6 > [ 73.041273] usb 1-2: new high-speed USB device number 10 using xhci_hcd > [ 73.620177] usb 1-2: New USB device found, idVendor=2935, idProduct=0001, > bcdDevice= 0.00 > [ 73.620180] usb 1-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 73.620182] usb 1-2: Product: XI100DUSB-HDMI > [ 73.620183] usb 1-2: Manufacturer: Magewell > [ 73.620185] usb 1-2: SerialNumber: C021150326019 > [ 76.920993] usb 2-2: Set SEL for device-initiated U2 failed. Everything here happens at USB host driver and USB subsystem. > [ 76.923341] uvcvideo: Found UVC 1.00 device XI100DUSB-HDMI (2935:0001) > [ 76.925324] uvcvideo 1-2:1.0: Entity type for entity Processing 2 was not > initialized! > [ 76.925327] uvcvideo 1-2:1.0: Entity type for entity Camera 1 was not > initialized! The above is at uvcvideo, and seems OK to my eyes. > [ 76.925413] input: XI100DUSB-HDMI: XI100DUSB-HDMI as > /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/input/input25 > [ 76.928710] usbhid 1-2:1.4: couldn't find an input interrupt endpoint This is related to input/evdev probing. Also unrelated to media. > [ 91.516482] usb 1-2: USB disconnect, device number 10 This is also at USB subsystem. Usually, it indicates a bad contact at the USB cable. > Is there any workarounds or ideas to make my capture device less annoying? > Thank you in advance, I would try to buy a high quality USB 3.0 cable, and see if things improve. You should remember that a USB 3.0 data transfer will use higher frequency signals, making the cable more susceptible to interference. So, a cable with a good shield can make a difference, specially if you're passing it close to other cables. Thanks, Mauro
[PATCH 09/14] media: usb: fix several typos
Use codespell to fix lots of typos over frontends.
Manually verified to avoid false-positives.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/au0828/au0828-core.c| 2 +-
drivers/media/usb/au0828/au0828.h | 2 +-
drivers/media/usb/cx231xx/cx231xx-avcore.c| 2 +-
drivers/media/usb/cx231xx/cx231xx-pcb-cfg.h | 2 +-
drivers/media/usb/cx231xx/cx231xx.h | 2 +-
drivers/media/usb/dvb-usb-v2/dvb_usb.h| 2 +-
drivers/media/usb/dvb-usb-v2/lmedm04.c| 8
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 4 ++--
drivers/media/usb/dvb-usb/af9005.c| 2 +-
drivers/media/usb/dvb-usb/cinergyT2-fe.c | 2 +-
drivers/media/usb/dvb-usb/cxusb.c | 2 +-
drivers/media/usb/dvb-usb/dvb-usb-init.c | 2 +-
drivers/media/usb/dvb-usb/dvb-usb.h | 2 +-
drivers/media/usb/dvb-usb/pctv452e.c | 4 ++--
drivers/media/usb/em28xx/em28xx-i2c.c | 4 ++--
drivers/media/usb/em28xx/em28xx-reg.h | 2 +-
drivers/media/usb/gspca/Kconfig | 2 +-
drivers/media/usb/gspca/autogain_functions.c | 2 +-
drivers/media/usb/gspca/benq.c| 4 ++--
drivers/media/usb/gspca/mr97310a.c| 10 +-
drivers/media/usb/gspca/ov519.c | 4 ++--
drivers/media/usb/gspca/pac_common.h | 2 +-
drivers/media/usb/gspca/sn9c20x.c | 2 +-
drivers/media/usb/gspca/sonixb.c | 4 ++--
drivers/media/usb/gspca/sonixj.c | 2 +-
drivers/media/usb/gspca/spca501.c | 2 +-
drivers/media/usb/gspca/sq905.c | 2 +-
drivers/media/usb/gspca/sunplus.c | 4 ++--
drivers/media/usb/gspca/t613.c| 2 +-
drivers/media/usb/gspca/touptek.c | 4 ++--
drivers/media/usb/gspca/w996Xcf.c | 2 +-
drivers/media/usb/gspca/zc3xx-reg.h | 2 +-
drivers/media/usb/gspca/zc3xx.c | 8
drivers/media/usb/hdpvr/hdpvr.h | 2 +-
drivers/media/usb/pwc/pwc-dec23.c | 4 ++--
drivers/media/usb/pwc/pwc-if.c| 2 +-
drivers/media/usb/pwc/pwc-misc.c | 2 +-
drivers/media/usb/siano/smsusb.c | 2 +-
drivers/media/usb/stk1160/stk1160-core.c | 4 ++--
drivers/media/usb/stk1160/stk1160-reg.h | 4 ++--
drivers/media/usb/stkwebcam/stk-webcam.c | 2 +-
drivers/media/usb/tm6000/tm6000-alsa.c| 2 +-
drivers/media/usb/tm6000/tm6000-core.c| 4 ++--
drivers/media/usb/tm6000/tm6000-dvb.c | 2 +-
drivers/media/usb/tm6000/tm6000-i2c.c | 2 +-
drivers/media/usb/tm6000/tm6000-stds.c| 2 +-
drivers/media/usb/tm6000/tm6000-video.c | 2 +-
drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c | 2 +-
drivers/media/usb/ttusb-dec/ttusb_dec.c | 2 +-
drivers/media/usb/usbvision/usbvision-core.c | 8
drivers/media/usb/usbvision/usbvision.h | 8
drivers/media/usb/uvc/uvc_video.c | 2 +-
drivers/media/usb/zr364xx/zr364xx.c | 2 +-
53 files changed, 81 insertions(+), 81 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-core.c
b/drivers/media/usb/au0828/au0828-core.c
index 1fdb1601dc65..3f8c92a70116 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -234,7 +234,7 @@ static void au0828_media_graph_notify(struct media_entity
*new,
if (!new) {
/*
* Called during au0828 probe time to connect
-* entites that were created prior to registering
+* entities that were created prior to registering
* the notify handler. Find mixer and decoder.
*/
media_device_for_each_entity(entity, dev->media_dev) {
diff --git a/drivers/media/usb/au0828/au0828.h
b/drivers/media/usb/au0828/au0828.h
index 004eadef55c7..425c35d16057 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -52,7 +52,7 @@
#define AU0828_INTERLACED_DEFAULT 1
-/* Defination for AU0828 USB transfer */
+/* Definition for AU0828 USB transfer */
#define AU0828_MAX_ISO_BUFS12 /* maybe resize this value in the future */
#define AU0828_ISO_PACKETS_PER_URB 128
diff --git a/drivers/media/usb/cx231xx/cx231xx-avcore.c
b/drivers/media/usb/cx231xx/cx231xx-avcore.c
index fdd3c221fa0d..3374888b3021 100644
--- a/drivers/media/usb/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/usb/cx231xx/cx231xx-avcore.c
@@ -2987,7 +2987,7 @@ int cx231xx_gpio_i2c_write_ack(struct cx231xx *dev)
{
int status = 0;
- /* set SDA to ouput */
+ /* set SDA to output */
dev->gpio_dir |= 1
Re: [RESUBMIT] [PATCH] Replace mentions of "list_struct" to "list_head"
Em Thu, 13 Nov 2014 20:48:41 -0500 Steven Rostedt escreveu: > On Fri, 14 Nov 2014 05:09:55 +0400 > Andrey Utkin wrote: > > > There's no such thing as "list_struct". > > I guess there isn't. Indeed ;) > > > > > Signed-off-by: Andrey Utkin > > Acked-by: Steven Rostedt Acked-by: Mauro Carvalho Chehab > > -- Steve > > > --- > > drivers/gpu/drm/radeon/mkregtable.c | 24 > > drivers/media/pci/cx18/cx18-driver.h | 2 +- > > include/linux/list.h | 34 > > +- > > include/linux/plist.h| 10 +- > > include/linux/rculist.h | 8 > > scripts/kconfig/list.h | 6 +++--- > > tools/usb/usbip/libsrc/list.h| 2 +- > > 7 files changed, 43 insertions(+), 43 deletions(-) > > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb drivers: use BUG_ON() instead of if () BUG
Some USB drivers have a logic at the VB buffer handling like:
if (in_interrupt())
BUG();
Use, instead:
BUG_ON(in_interrupt());
Btw, this logic looks weird on my eyes. We should convert them
to use VB2, in order to avoid those crappy things.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c
b/drivers/media/usb/cx231xx/cx231xx-417.c
index 855a708387c6..47a98a2014a5 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -1249,8 +1249,7 @@ static void free_buffer(struct videobuf_queue *vq, struct
cx231xx_buffer *buf)
struct cx231xx *dev = fh->dev;
unsigned long flags = 0;
- if (in_interrupt())
- BUG();
+ BUG_ON(in_interrupt());
spin_lock_irqsave(&dev->video_mode.slock, flags);
if (dev->USE_ISO) {
diff --git a/drivers/media/usb/cx231xx/cx231xx-vbi.c
b/drivers/media/usb/cx231xx/cx231xx-vbi.c
index 80261ac40208..a08014d20a5c 100644
--- a/drivers/media/usb/cx231xx/cx231xx-vbi.c
+++ b/drivers/media/usb/cx231xx/cx231xx-vbi.c
@@ -192,8 +192,7 @@ static void free_buffer(struct videobuf_queue *vq, struct
cx231xx_buffer *buf)
struct cx231xx_fh *fh = vq->priv_data;
struct cx231xx *dev = fh->dev;
unsigned long flags = 0;
- if (in_interrupt())
- BUG();
+ BUG_ON(in_interrupt());
/* We used to wait for the buffer to finish here, but this didn't work
because, as we were keeping the state as VIDEOBUF_QUEUED,
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c
b/drivers/media/usb/cx231xx/cx231xx-video.c
index af44f2d1c0a1..c6ff8968286a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -749,8 +749,7 @@ static void free_buffer(struct videobuf_queue *vq, struct
cx231xx_buffer *buf)
struct cx231xx *dev = fh->dev;
unsigned long flags = 0;
- if (in_interrupt())
- BUG();
+ BUG_ON(in_interrupt());
/* We used to wait for the buffer to finish here, but this didn't work
because, as we were keeping the state as VIDEOBUF_QUEUED,
diff --git a/drivers/media/usb/tm6000/tm6000-video.c
b/drivers/media/usb/tm6000/tm6000-video.c
index 77ce9efe1f24..26b6ae8d04da 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -714,8 +714,7 @@ static void free_buffer(struct videobuf_queue *vq, struct
tm6000_buffer *buf)
struct tm6000_core *dev = fh->dev;
unsigned long flags;
- if (in_interrupt())
- BUG();
+ BUG_ON(in_interrupt());
/* We used to wait for the buffer to finish here, but this didn't work
because, as we were keeping the state as VIDEOBUF_QUEUED,
diff --git a/drivers/media/usb/zr364xx/zr364xx.c
b/drivers/media/usb/zr364xx/zr364xx.c
index ca850316d379..7433ba5c4bad 100644
--- a/drivers/media/usb/zr364xx/zr364xx.c
+++ b/drivers/media/usb/zr364xx/zr364xx.c
@@ -377,8 +377,7 @@ static void free_buffer(struct videobuf_queue *vq, struct
zr364xx_buffer *buf)
{
_DBG("%s\n", __func__);
- if (in_interrupt())
- BUG();
+ BUG_ON(in_interrupt());
videobuf_vmalloc_free(&buf->vb);
buf->vb.state = VIDEOBUF_NEEDS_INIT;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] cx88: use pci_set_dma_mask insted of pci_dma_supported
Hi Christoph,
Em Sat, 3 Oct 2015 17:19:29 +0200
Christoph Hellwig escreveu:
> This ensures the dma mask that is supported by the driver is recorded
> in the device structure.
For this and the other patches touching at drivers/media:
Acked-by: Mauro Carvalho Chehab
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/media/pci/cx88/cx88-alsa.c | 2 +-
> drivers/media/pci/cx88/cx88-mpeg.c | 2 +-
> drivers/media/pci/cx88/cx88-video.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/pci/cx88/cx88-alsa.c
> b/drivers/media/pci/cx88/cx88-alsa.c
> index 7f8dc60..0703a81 100644
> --- a/drivers/media/pci/cx88/cx88-alsa.c
> +++ b/drivers/media/pci/cx88/cx88-alsa.c
> @@ -890,7 +890,7 @@ static int snd_cx88_create(struct snd_card *card, struct
> pci_dev *pci,
> return err;
> }
>
> - if (!pci_dma_supported(pci,DMA_BIT_MASK(32))) {
> + if (!pci_set_dma_mask(pci,DMA_BIT_MASK(32))) {
> dprintk(0, "%s/1: Oops: no 32bit PCI DMA ???\n",core->name);
> err = -EIO;
> cx88_core_put(core, pci);
> diff --git a/drivers/media/pci/cx88/cx88-mpeg.c
> b/drivers/media/pci/cx88/cx88-mpeg.c
> index 34f5057..9b3b565 100644
> --- a/drivers/media/pci/cx88/cx88-mpeg.c
> +++ b/drivers/media/pci/cx88/cx88-mpeg.c
> @@ -393,7 +393,7 @@ static int cx8802_init_common(struct cx8802_dev *dev)
> if (pci_enable_device(dev->pci))
> return -EIO;
> pci_set_master(dev->pci);
> - if (!pci_dma_supported(dev->pci,DMA_BIT_MASK(32))) {
> + if (!pci_set_dma_mask(dev->pci,DMA_BIT_MASK(32))) {
> printk("%s/2: Oops: no 32bit PCI DMA ???\n",dev->core->name);
> return -EIO;
> }
> diff --git a/drivers/media/pci/cx88/cx88-video.c
> b/drivers/media/pci/cx88/cx88-video.c
> index 400e5ca..f12af31 100644
> --- a/drivers/media/pci/cx88/cx88-video.c
> +++ b/drivers/media/pci/cx88/cx88-video.c
> @@ -1311,7 +1311,7 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
> dev->pci_lat,(unsigned long long)pci_resource_start(pci_dev,0));
>
> pci_set_master(pci_dev);
> - if (!pci_dma_supported(pci_dev,DMA_BIT_MASK(32))) {
> + if (!pci_set_dma_mask(pci_dev,DMA_BIT_MASK(32))) {
> printk("%s/0: Oops: no 32bit PCI DMA ???\n",core->name);
> err = -EIO;
> goto fail_core;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
