[PATCH v2 10/11] usbip: added const qualifier to arguments of some functions
This patch adds 'const' qualifier to 'char*' arguments of library
interfaces to make acceptable std::string.c_str(). Essentially, these
qualifiers are better to be used even if not to use C++. Although, I
just added to functions related to previous patch.
Also, it changes C++ reserved words (ie. new and class) in list.h.
Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp
---
tools/usb/usbip/libsrc/list.h | 24 --
tools/usb/usbip/libsrc/usbip_common.c | 16 +++
tools/usb/usbip/libsrc/usbip_common.h | 6 +++---
tools/usb/usbip/libsrc/usbip_host_driver.c | 10 +
tools/usb/usbip/libsrc/usbip_host_driver.h | 2 +-
tools/usb/usbip/libsrc/vhci_driver.c | 11 ++
tools/usb/usbip/libsrc/vhci_driver.h | 6 --
tools/usb/usbip/src/usbip.h| 16 ---
tools/usb/usbip/src/usbip_attach.c | 4 ++--
tools/usb/usbip/src/usbip_bind.c | 6 +++---
tools/usb/usbip/src/usbip_connect.c| 4 ++--
tools/usb/usbip/src/usbip_detach.c | 2 +-
tools/usb/usbip/src/usbip_disconnect.c | 5 +++--
tools/usb/usbip/src/usbip_list.c | 7 +++
tools/usb/usbip/src/usbip_netconn.c| 2 +-
tools/usb/usbip/src/usbip_network.c| 12 +++
tools/usb/usbip/src/usbip_unbind.c | 2 +-
tools/usb/usbip/src/usbipd.c | 4 ++--
tools/usb/usbip/src/usbipd.h | 2 +-
tools/usb/usbip/src/usbipd_app.c | 9
tools/usb/usbip/src/usbipd_dev.c | 2 +-
tools/usb/usbip/src/utils.c| 2 +-
tools/usb/usbip/src/utils.h| 2 +-
23 files changed, 86 insertions(+), 70 deletions(-)
diff --git a/tools/usb/usbip/libsrc/list.h b/tools/usb/usbip/libsrc/list.h
index 5eaaa78..b46a98f 100644
--- a/tools/usb/usbip/libsrc/list.h
+++ b/tools/usb/usbip/libsrc/list.h
@@ -36,14 +36,14 @@ static inline void INIT_LIST_HEAD(struct list_head *list)
* This is only for internal list manipulation where we know
* the prev/next entries already!
*/
-static inline void __list_add(struct list_head *new,
+static inline void __list_add(struct list_head *neo,
struct list_head *prev,
struct list_head *next)
{
- next-prev = new;
- new-next = next;
- new-prev = prev;
- prev-next = new;
+ next-prev = neo;
+ neo-next = next;
+ neo-prev = prev;
+ prev-next = neo;
}
/**
@@ -54,9 +54,9 @@ static inline void __list_add(struct list_head *new,
* Insert a new entry after the specified head.
* This is good for implementing stacks.
*/
-static inline void list_add(struct list_head *new, struct list_head *head)
+static inline void list_add(struct list_head *neo, struct list_head *head)
{
- __list_add(new, head, head-next);
+ __list_add(neo, head, head-next);
}
/*
@@ -73,8 +73,8 @@ static inline void __list_del(struct list_head * prev, struct
list_head * next)
}
#define POISON_POINTER_DELTA 0
-#define LIST_POISON1 ((void *) 0x00100100 + POISON_POINTER_DELTA)
-#define LIST_POISON2 ((void *) 0x00200200 + POISON_POINTER_DELTA)
+#define LIST_POISON1 ((char *) 0x00100100 + POISON_POINTER_DELTA)
+#define LIST_POISON2 ((char *) 0x00200200 + POISON_POINTER_DELTA)
/**
* list_del - deletes entry from list.
@@ -90,8 +90,8 @@ static inline void __list_del_entry(struct list_head *entry)
static inline void list_del(struct list_head *entry)
{
__list_del(entry-prev, entry-next);
- entry-next = LIST_POISON1;
- entry-prev = LIST_POISON2;
+ entry-next = (struct list_head *)LIST_POISON1;
+ entry-prev = (struct list_head *)LIST_POISON2;
}
/**
@@ -120,7 +120,9 @@ static inline void list_del(struct list_head *entry)
for (pos = (head)-next, n = pos-next; pos != (head); \
pos = n, n = pos-next)
+#ifndef offsetof
#define offsetof(TYPE, MEMBER) ((size_t) ((TYPE *)0)-MEMBER)
+#endif
/**
* container_of - cast a member of a structure out to the containing structure
diff --git a/tools/usb/usbip/libsrc/usbip_common.c
b/tools/usb/usbip/libsrc/usbip_common.c
index 54efa10..bf577b7 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -260,29 +260,29 @@ void usbip_names_get_product(char *buff, size_t size,
uint16_t vendor,
snprintf(buff, size, %s : %s (%04x:%04x), vend, prod, vendor,
product);
}
-void usbip_names_get_class(char *buff, size_t size, uint8_t class,
+void usbip_names_get_class(char *buff, size_t size, uint8_t clazz,
uint8_t subclass, uint8_t protocol)
{
const char *c, *s, *p;
- if (class == 0 subclass == 0 protocol == 0) {
- snprintf(buff, size, (Defined at Interface level)
(%02x/%02x/%02x), class, subclass, protocol);
+ if (clazz == 0 subclass == 0 protocol == 0) {
+ snprintf(buff,
[PATCH v2 11/11] usbip: USB over WebSocket
This patch adds utilities transmit packets via WebSocket protocol. WebSocket version of utilities as following. usbws : command usbwsa : application-side daemon usbwsd : device-side daemon The command supports all sub-command (ie. list, connect, disconnect, port, bind, unbind, attach and detach). It uses --url option to specify remote address and port number. Implementation of this patch depends on Poco C++ (http://pocoproject.org/). The tree is shown below. tools +--usb +--usbip +--src : command, daemons and their core libraries +--libsrc : common library for command and daemon +--websocket : new! WebSocket implementations +--poco : new! implementation with Poco C++ Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp --- tools/usb/usbip/websocket/AUTHORS | 1 + tools/usb/usbip/websocket/COPYING | 340 +++ tools/usb/usbip/websocket/INSTALL | 237 ++ tools/usb/usbip/websocket/Makefile.am | 3 + tools/usb/usbip/websocket/README | 184 tools/usb/usbip/websocket/autogen.sh | 9 + tools/usb/usbip/websocket/cleanup.sh | 12 + tools/usb/usbip/websocket/configure.ac| 61 +++ tools/usb/usbip/websocket/doc/usbws.8 | 192 tools/usb/usbip/websocket/doc/usbwsa.8| 101 + tools/usb/usbip/websocket/doc/usbwsd.8| 109 + tools/usb/usbip/websocket/poco/Makefile.am| 18 + .../usb/usbip/websocket/poco/USBWSCommand.cpp | 410 ++ tools/usb/usbip/websocket/poco/USBWSCommand.h | 99 + .../usb/usbip/websocket/poco/USBWSDaemon.cpp | 228 ++ tools/usb/usbip/websocket/poco/USBWSDaemon.h | 80 .../websocket/poco/USBWSRequestHandler.cpp| 90 .../websocket/poco/USBWSRequestHandler.h | 49 +++ .../poco/USBWSRequestHandlerFactory.cpp | 47 ++ .../poco/USBWSRequestHandlerFactory.h | 48 ++ tools/usb/usbip/websocket/poco/USBWSUtil.h| 52 +++ .../usbip/websocket/poco/USBWSWebSocket.cpp | 201 + .../usb/usbip/websocket/poco/USBWSWebSocket.h | 69 +++ 23 files changed, 2640 insertions(+) diff --git a/tools/usb/usbip/websocket/AUTHORS b/tools/usb/usbip/websocket/AUTHORS new file mode 100644 index 000..be60f78 --- /dev/null +++ b/tools/usb/usbip/websocket/AUTHORS @@ -0,0 +1 @@ +Nobuo Iwata diff --git a/tools/usb/usbip/websocket/COPYING b/tools/usb/usbip/websocket/COPYING new file mode 100644 index 000..c5611e4 --- /dev/null +++ b/tools/usb/usbip/websocket/COPYING @@ -0,0 +1,340 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients
[PATCH v2 09/11] usbip: deriving functions as libraries
To utilize core parts of USB/IP to application protocol implementations, this patch derives libraries by exposing some functions of utilities and removing some unnecessary portions. Following functions are exposed. For command: - usbip_attach_device() - usbip_detach_port() - usbip_bind_device() - usbip_unbind_device() - usbip_list_imported_devices() : port command - usbip_list_importable_devices() : list --remote - usbip_list_devices() : list --local - usbip_connect_device() - usbip_disconnect_device() For daemon: - usbip_recv_pdu() - processes accepted a connection - usbip_break_connections() - breaks send/receive threads - usbip_driver_open() - open host or vhci driver - usbip_driver_close() - close host or vhci driver main() and option processing are removed. AS_LIBRARY macro is used to remove option processing. Following libraries are generated. - libusbip.la : for commnad - libusbipa.la : for application-side daemon - libusbipd.la : for device-side daemon Succeeding WebSocket patch uses these libraries. Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp --- tools/usb/usbip/libsrc/Makefile.am | 10 +- tools/usb/usbip/src/Makefile.am| 19 +++- tools/usb/usbip/src/usbip.h| 7 ++ tools/usb/usbip/src/usbip_attach.c | 14 ++- tools/usb/usbip/src/usbip_bind.c | 6 ++ tools/usb/usbip/src/usbip_connect.c| 12 ++- tools/usb/usbip/src/usbip_detach.c | 13 ++- tools/usb/usbip/src/usbip_disconnect.c | 12 ++- tools/usb/usbip/src/usbip_list.c | 68 - tools/usb/usbip/src/usbip_netconn.c| 133 + tools/usb/usbip/src/usbip_network.c| 67 - tools/usb/usbip/src/usbip_port.c | 12 ++- tools/usb/usbip/src/usbip_unbind.c | 6 ++ tools/usb/usbip/src/usbipd.c | 13 +-- tools/usb/usbip/src/usbipd.h | 38 +++ tools/usb/usbip/src/usbipd_app.c | 1 + tools/usb/usbip/src/usbipd_dev.c | 1 + 17 files changed, 306 insertions(+), 126 deletions(-) diff --git a/tools/usb/usbip/libsrc/Makefile.am b/tools/usb/usbip/libsrc/Makefile.am index 5754425..356a6c0 100644 --- a/tools/usb/usbip/libsrc/Makefile.am +++ b/tools/usb/usbip/libsrc/Makefile.am @@ -1,9 +1,9 @@ -libusbip_la_CPPFLAGS = -DUSBIDS_FILE='@USBIDS_DIR@/usb.ids' -libusbip_la_CFLAGS = @EXTRA_CFLAGS@ -libusbip_la_LDFLAGS = -version-info @LIBUSBIP_VERSION@ +libusbiplib_la_CPPFLAGS = -DUSBIDS_FILE='@USBIDS_DIR@/usb.ids' +libusbiplib_la_CFLAGS = @EXTRA_CFLAGS@ +libusbiplib_la_LDFLAGS = -version-info @LIBUSBIP_VERSION@ -lib_LTLIBRARIES := libusbip.la -libusbip_la_SOURCES := names.c names.h usbip_host_driver.c usbip_host_driver.h \ +lib_LTLIBRARIES := libusbiplib.la +libusbiplib_la_SOURCES := names.c names.h usbip_host_driver.c usbip_host_driver.h \ usbip_common.c usbip_common.h vhci_driver.c vhci_driver.h \ usbip_ux.c usbip_ux.h \ sysfs_utils.c sysfs_utils.h diff --git a/tools/usb/usbip/src/Makefile.am b/tools/usb/usbip/src/Makefile.am index f5697c2..bb20cd1 100644 --- a/tools/usb/usbip/src/Makefile.am +++ b/tools/usb/usbip/src/Makefile.am @@ -1,14 +1,29 @@ AM_CPPFLAGS = -I$(top_srcdir)/libsrc -DUSBIDS_FILE='@USBIDS_DIR@/usb.ids' AM_CFLAGS = @EXTRA_CFLAGS@ -LDADD = $(top_builddir)/libsrc/libusbip.la +LDADD = $(top_builddir)/libsrc/libusbiplib.la sbin_PROGRAMS := usbip usbipd usbipa +lib_LTLIBRARIES := libusbip.la libusbipd.la libusbipa.la -usbip_SOURCES := usbip.h utils.h usbip.c utils.c usbip_network.c \ +usbip_SOURCES := usbip.h utils.h usbip.c utils.c \ +usbip_network.c usbip_netconn.c\ usbip_attach.c usbip_detach.c usbip_list.c \ usbip_bind.c usbip_unbind.c usbip_port.c \ usbip_connect.c usbip_disconnect.c +usbip_CFLAGS := $(AM_CFLAGS) usbipd_SOURCES := usbip_network.h usbipd.c usbipd_dev.c usbip_network.c +usbipd_CFLAGS := $(AM_CFLAGS) usbipa_SOURCES := usbip_network.h usbipd.c usbipd_app.c usbip_network.c +usbipa_CFLAGS := $(AM_CFLAGS) + +libusbip_la_SOURCES := utils.h utils.c usbip_network.c \ +usbip_attach.c usbip_detach.c usbip_list.c \ +usbip_bind.c usbip_unbind.c usbip_port.c \ +usbip_connect.c usbip_disconnect.c +libusbip_la_CFLAGS := $(AM_CFLAGS) -DAS_LIBRARY + +libusbipd_la_SOURCES := usbipd_dev.c usbip_network.c + +libusbipa_la_SOURCES := usbipd_app.c usbip_network.c diff --git a/tools/usb/usbip/src/usbip.h b/tools/usb/usbip/src/usbip.h index 0875d15..1d642cc 100644 --- a/tools/usb/usbip/src/usbip.h +++ b/tools/usb/usbip/src/usbip.h @@ -34,8 +34,15 @@ int usbip_port_show(int argc, char *argv[]); int usbip_connect(int argc, char *argv[]); int usbip_disconnect(int argc, char *argv[]); +int usbip_attach_device(char *host, char *port, char *busid); +int usbip_detach_port(char *port); int usbip_bind_device(char *busid); int usbip_unbind_device(char *busid); +int
[PATCH v2 04/11] usbip: kernel module for userspace URBs transmission
Originally, USB/IP transmits requests and response PDUs for preparation to transfer URBs in user space, after the preparation, URBs are transmitted in kernel space. To make easy to introduce application network protocols like WebSocket and so on, the driver, usbip_ux.ko, forwards URBs to USB/IP user space utilities. It's just like fuse driver for user space file system. Then, utilities transfer URBs in user space. To do so, usbip_trx_ops makes send/receive functions pluggable. kernel_sendmsg() and kernel_recvmsg() for kernel mode transfer can be substituted by read/write methods to user space utilities. In the absence of usbip_ux.ko, original kernel space transferring is valid. usbip_ux.ko replaces usbip_trx_ops in its init routine. A) Original - kernel space URBs transfer User+---+ 1) import/export +---+ space |uspipd,||usbip, | |usbip | |usbipa | +---+---+ +---+---+ | | 2)Set sockfd| |2)Set sockfd thru sysfs| | thru sysfs V V Kernel +---+4)URBs+---+ space |usbip ||vhci | |host.ko| |hcd.ko | +---+ +---+ 3)link to kernel trx_ops 3)link to kernel trx_ops B) New - user space URBs transfer User+---+1)import/export +---+ space |uspipd,||usbip, | +---|usbip ||usbipa |---+ 2)Set sockfd|+--+---+6)URBs+---+--+|2)Set sockfd thru ioctl|| ^ ^ || thru ioctl (right) || |5)read/write 5)read/write| || (left) 3)Set sockfd|| +---+ +--+ ||3)Set Sockfd thru sysfs|+---+ | /dev/usbip-ux| +---+| thru sysfs (left)VV V V VV (right) Kernel +---+ +---+ +---+ +---+ space |usbip |-|usbip | |usbip |-|vhci | |host.ko|5)send |ux.ko | |ux.ko |5)send |hcd.ko | +---+ recv +---+ +---+ recv +---+ 4)link to user trx_ops 4)link to user trx_ops Kernel module configuration for the driver will be shown as below. USB/IP support USBIP_CORE +-- USB/IP userspace URB transmission USBIP_UX +-- VHCI hcdUSBIP_HCD +-- Debug messages for USB/IP USBIP_DEBUG The reason why the userspace transmission oter than usbfs is needed. a) Application(vhci_hcd)-side is needed Usbfs provides functions to control device. So it can be applied to device(usbip_host)-side but not to application(vhci_hcd)-side. b) Use existing kernel modules as-is To implement same functionality in userspace with interface like usbfs, almost same code to kernel modules must be copied to userspcae. Also interfaces between kernel modules and utiities (sysfs) should be changed to new one. So utilities must be modified according to the new interface too. Modifications to existing code by this patch is small and usbip_ux.c handles major part of userspace transmission. To get diff include/uapi/linux/usbip_ux.h, I used modified dontdiff.txt. Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp --- drivers/usb/usbip/Kconfig| 10 + drivers/usb/usbip/Makefile | 3 + drivers/usb/usbip/stub_dev.c | 16 +- drivers/usb/usbip/stub_rx.c | 3 +- drivers/usb/usbip/stub_tx.c | 5 +- drivers/usb/usbip/usbip_common.c | 79 +++- drivers/usb/usbip/usbip_common.h | 29 +- drivers/usb/usbip/usbip_ux.c | 602 +++ drivers/usb/usbip/usbip_ux.h | 82 + drivers/usb/usbip/vhci_hcd.c | 9 +- drivers/usb/usbip/vhci_rx.c | 3 +- drivers/usb/usbip/vhci_sysfs.c | 40 +- drivers/usb/usbip/vhci_tx.c | 6 +- include/uapi/linux/usbip_ux.h| 39 ++ 14 files changed, 869 insertions(+), 57 deletions(-) diff --git a/drivers/usb/usbip/Kconfig b/drivers/usb/usbip/Kconfig index bd99e9e..e847d06 100644 --- a/drivers/usb/usbip/Kconfig +++ b/drivers/usb/usbip/Kconfig @@ -14,6 +14,16 @@ config USBIP_CORE If unsure, say N. +config USBIP_UX + tristate USB/IP userspace URB transmission + depends on USBIP_CORE + ---help--- + This moves USB/IP URB transmission to userspace + to apply SSL, WebSocket and etc. + + To compile this driver as a module, choose M here: the + module will be called usbip-ux. + config USBIP_VHCI_HCD tristate VHCI hcd depends on
[PATCH v2 03/11] usbip: safe completion against usb_kill_urb()
stub_shutdown_connection() : drivers/usb/usbip/stub_dev.c
stub_device_cleanup_urbs() : drivers/usb/usbip/stub_main.c
requests to kill pending URBs and clears priv lists.
stub_complete() : drivers/usb/usbip/stub_tx.c might be called with URBs
to have been requested to kill.
To avoid kernel panic, this patch ignores killed URBs linked to cleared
priv lists.
To know the killed URBs in stub_complete(), sdev-ud.tcp_socket which
cleared before stub_device_cleanup_urbs() is checked.
Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp
---
drivers/usb/usbip/stub_tx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index dbcabc9..f19f321 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -97,7 +97,9 @@ void stub_complete(struct urb *urb)
/* link a urb to the queue of tx. */
spin_lock_irqsave(sdev-priv_lock, flags);
- if (priv-unlinking) {
+ if (sdev-ud.tcp_socket == NULL) {
+ dev_info(urb-dev-dev, discard a urb for closed connection);
+ } else if (priv-unlinking) {
stub_enqueue_ret_unlink(sdev, priv-seqnum, urb-status);
stub_free_priv_and_urb(priv);
} else {
--
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
[PATCH v2 02/11] usbip: readme and manuals about exporting devices
This patch adds function and usage of export to README and manuals. The wording, 'server' and 'client' is changed also. For existing attach command, the daemon runs device side machine and attach command is executed in application side machine. Then 'server' is used for device side and 'client' is for application side. For the new connect command, the daemon runs applications side machine and connect command is executed in device side machine. Now, 'server' and 'client' run in different machine than before. So, to avoid confusion, words 'device side' and 'application side' are used instead of 'client' and 'server'. Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp --- tools/usb/usbip/Makefile.am | 2 +- tools/usb/usbip/README | 70 ++-- tools/usb/usbip/doc/usbip.8 | 74 ++ tools/usb/usbip/doc/usbipa.8 | 77 tools/usb/usbip/doc/usbipd.8 | 29 +++--- 5 files changed, 200 insertions(+), 52 deletions(-) diff --git a/tools/usb/usbip/Makefile.am b/tools/usb/usbip/Makefile.am index 66f8bf0..f371ed9 100644 --- a/tools/usb/usbip/Makefile.am +++ b/tools/usb/usbip/Makefile.am @@ -3,4 +3,4 @@ includedir = @includedir@/usbip include_HEADERS := $(addprefix libsrc/, \ usbip_common.h vhci_driver.h usbip_host_driver.h) -dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8) +dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8 usbipa.8) diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README index 831f49f..74f4afb 100644 --- a/tools/usb/usbip/README +++ b/tools/usb/usbip/README @@ -1,7 +1,8 @@ # # README for usbip-utils # -# Copyright (C) 2011 matt mooney m...@muteddisk.com +# Copyright (C) 2015 Nobuo Iwata +# 2011 matt mooney m...@muteddisk.com # 2005-2008 Takahiro Hirofuchi @@ -36,41 +37,70 @@ [Usage] -server:# (Physically attach your USB device.) +Device-side: a machine has USB device(s). +Application-side: a machine runs an application software uses remote USB device. -server:# insmod usbip-core.ko -server:# insmod usbip-host.ko +1) Connect from application-side to device-side. -server:# usbipd -D +dev:# (Physically attach your USB device.) + +dev:# insmod usbip-core.ko +dev:# insmod usbip-host.ko + +dev:# usbipd -D - Start usbip daemon. -server:# usbip list -l - - List driver assignments for USB devices. +dev:# usbip list -l + - List driver assignments for USB devices and their busid. -server:# usbip bind --busid 1-2 - - Bind usbip-host.ko to the device with busid 1-2. - - The USB device 1-2 is now exportable to other hosts! - - Use `usbip unbind --busid 1-2' to stop exporting the device. +dev:# usbip bind --busid busid + - Bind usbip-host.ko to the device with busid. + - The USB device with busid is now exportable to other hosts! + - Use `usbip unbind --busid busid` to stop exporting the device. -client:# insmod usbip-core.ko -client:# insmod vhci-hcd.ko +app:# insmod usbip-core.ko +app:# insmod vhci-hcd.ko -client:# usbip list --remote host +app:# usbip list --remote host - List exported USB devices on the host. -client:# usbip attach --remote host --busid 1-2 +app:# usbip attach --remote host --busid busid - Connect the remote USB device. -client:# usbip port +app:# usbip port - Show virtual port status. -client:# usbip detach --port port +app:# usbip detach --port port - Detach the USB device. +2) Connect from device-side to application-side. + +app:# insmod usbip-core.ko +app:# insmod vhci-hcd.ko + +app:# usbipa -D + - Start usbip daemon. + +dev:# (Physically attach your USB device.) + +dev:# insmod usbip-core.ko +dev:# insmod usbip-host.ko + +dev:# usbip list -l + - List driver assignments for USB devices and their busid. + +dev:# usbip connect --remote host --busid busid + - Bind usbip-host.ko to the device with busid. + - The USB device of busid is connected to remote host! + +dev:# usbip disconnect --remote host --busid busid + - The USB device with busid is disconnected from remote host. + - Unbind usbip-host.ko from the device. + [Example] --- - SERVER SIDE + DEVICE SIDE --- Physically attach your USB devices to this host. @@ -131,7 +161,7 @@ Mark the device of busid 3-3.2 as exportable: ... --- - CLIENT SIDE + APPLICATION SIDE --- First, let's list available remote devices that are marked as exportable on the host. @@ -170,7 +200,7 @@ Attach a remote USB device: deux:# usbip attach --remote 10.0.0.3 --busid 1-1 port 0 attached -Show the devices attached to this client: +Show the devices
[PATCH v2 06/11] usbip: readme about user space URBs transmission
Addition to README regarding user space URBs transmission. Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp --- tools/usb/usbip/README | 22 ++ 1 file changed, 22 insertions(+) diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README index 74f4afb..6b61da5 100644 --- a/tools/usb/usbip/README +++ b/tools/usb/usbip/README @@ -98,6 +98,28 @@ Application-side: a machine runs an application software uses remote USB device. - Unbind usbip-host.ko from the device. +[Userspace Transmission] + +In usage shown above, once USB devices are imported or exported, USP/IP drivers send and receive URBs in kernel space. The usbip_ux.ko kernel module alternates the route to user space by forwarding USBs through USB/IP utilities (ie. usbip, usbipd, usbipa). When userspace transmission enabled, usbip attach and connect will continue executing until usbip detach or disconnect is exeuted. + +app:# insmod usbip-core.ko +app:# insmod usbip-ux.ko +app:# insmod vhci-hcd.ko + +app:# usbipa -D + +dev:# insmod usbip-core.ko +dev:# insmod usbip-ux.ko +dev:# insmod usbip-host.ko + +dev:# usbip connect --remote host --busid busid + - Continue running. + - Until disconnect command is executed in other terminal window. + +dev:# usbip disconnect --remote host --busid busid + - Stops transission, quits connect command and disconnect device. + + [Example] --- DEVICE SIDE -- 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
[PATCH v2 07/11] usbip: letting send and receive replaceable
This patch allows to substitute send, receive and shutdown routines for
both a) request/response PDUs among utilities and b) user space URBs
transmission.
usbip_sock_t is introduced instead of sockfd. it includes function
pointers of send/receive/shutdown routines, an argument for the
routines, and a sockfd. The argument is needed for the routines. The
sockfd is needed to bind connection to USB device.
Succeeding SSL and WebSocket patch use this feature.
Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp
---
tools/usb/usbip/libsrc/usbip_common.c | 14 ++
tools/usb/usbip/libsrc/usbip_common.h | 14 ++
tools/usb/usbip/libsrc/usbip_ux.c | 24 +++---
tools/usb/usbip/libsrc/usbip_ux.h | 4 +-
tools/usb/usbip/src/usbip_attach.c | 30 ++--
tools/usb/usbip/src/usbip_connect.c| 30 ++--
tools/usb/usbip/src/usbip_disconnect.c | 26 +-
tools/usb/usbip/src/usbip_list.c | 26 +-
tools/usb/usbip/src/usbip_network.c| 66 ++
tools/usb/usbip/src/usbip_network.h| 11 +++--
tools/usb/usbip/src/usbipd.c | 8 ++--
tools/usb/usbip/src/usbipd_app.c | 36 +++---
tools/usb/usbip/src/usbipd_dev.c | 40
13 files changed, 199 insertions(+), 130 deletions(-)
diff --git a/tools/usb/usbip/libsrc/usbip_common.c
b/tools/usb/usbip/libsrc/usbip_common.c
index ac73710..dc0712c 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2005-2007 Takahiro Hirofuchi
+ * Copyright (C) 2015 Nobuo Iwata
*/
#include libudev.h
@@ -283,3 +284,16 @@ void usbip_names_get_class(char *buff, size_t size,
uint8_t class,
snprintf(buff, size, %s / %s / %s (%02x/%02x/%02x), c, s, p, class,
subclass, protocol);
}
+
+void usbip_sock_init(usbip_sock_t *sock, int fd, void *arg,
+ ssize_t (*send)(void *arg, void *buf, size_t len),
+ ssize_t (*recv)(void *arg, void *buf, size_t len, int wait_all),
+ void (*shutdown)(void *arg))
+{
+ sock-fd = fd;
+ sock-arg = arg;
+ sock-send = send;
+ sock-recv = recv;
+ sock-shutdown = shutdown;
+}
+
diff --git a/tools/usb/usbip/libsrc/usbip_common.h
b/tools/usb/usbip/libsrc/usbip_common.h
index 15fe792..0dcbd99 100644
--- a/tools/usb/usbip/libsrc/usbip_common.h
+++ b/tools/usb/usbip/libsrc/usbip_common.h
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2005-2007 Takahiro Hirofuchi
+ * Copyright (C) 2015 Nobuo Iwata
*/
#ifndef __USBIP_COMMON_H
@@ -134,4 +135,17 @@ void usbip_names_get_product(char *buff, size_t size,
uint16_t vendor,
void usbip_names_get_class(char *buff, size_t size, uint8_t class,
uint8_t subclass, uint8_t protocol);
+typedef struct usbip_sock {
+ int fd;
+ void *arg;
+ ssize_t (*send)(void *arg, void *buf, size_t len);
+ ssize_t (*recv)(void *arg, void *buf, size_t len, int wait_all);
+ void (*shutdown)(void *arg);
+} usbip_sock_t;
+
+void usbip_sock_init(usbip_sock_t *sock, int fd, void *arg,
+ ssize_t (*send)(void *arg, void *buf, size_t len),
+ ssize_t (*recv)(void *arg, void *buf, size_t len, int wait_all),
+ void (*shutdown)(void *arg));
+
#endif /* __USBIP_COMMON_H */
diff --git a/tools/usb/usbip/libsrc/usbip_ux.c
b/tools/usb/usbip/libsrc/usbip_ux.c
index 183be7c..8c4e691 100644
--- a/tools/usb/usbip/libsrc/usbip_ux.c
+++ b/tools/usb/usbip/libsrc/usbip_ux.c
@@ -57,7 +57,11 @@ static void *usbip_ux_rx(void *arg)
char buf[BLEN];
while(good) {
- received = recv(ux-sockfd, buf, BLEN, 0);
+ if (ux-sock-recv) {
+ received = ux-sock-recv(ux-sock-arg, buf, BLEN, 0);
+ } else {
+ received = recv(ux-sock-fd, buf, BLEN, 0);
+ }
if (received == 0) {
dbg(connection closed on sock:%p, ux-kaddr.sock);
break;
@@ -101,7 +105,11 @@ static void *usbip_ux_tx(void *arg)
break;
}
dump_buff(buf, reads, ux sending);
- sent = send(ux-sockfd, buf, reads, 0);
+ if (ux-sock-send) {
+ sent = ux-sock-send(ux-sock-arg, buf, reads);
+ } else {
+ sent = send(ux-sock-fd, buf, reads, 0);
+ }
if (sent 0) {
dbg(connection closed on sock:%p, ux-kaddr.sock);
break;
@@ -112,7 +120,11 @@ static void *usbip_ux_tx(void *arg)
}
}
dbg(end of ux-tx for sock:%p, ux-kaddr.sock);
- shutdown(ux-sockfd, SHUT_RDWR);
+ if (ux-sock-shutdown) {
+ ux-sock-shutdown(ux-sock-arg);
+ } else {
+ shutdown(ux-sock-fd, SHUT_RDWR);
+ }
return 0;
}
@@ -120,7 +132,7 @@ static void *usbip_ux_tx(void *arg)
[PATCH v2 08/11] usbip: letting connection establishment replaceable
To introduce some application protocols like WebSocket, this patch
allows to substitute connection establishment and termination. In
combination with previous patch, both connection and transmission can
be replaced.
usbip_connection_operations_t includes open and close operation. Open
method returns usbip_sock_t which includes send, receive and close
method. Then, transmission methods are replaced at the same time.
Succeeding WebSocket patch uses this feature.
Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp
---
tools/usb/usbip/libsrc/usbip_common.c | 10 ++
tools/usb/usbip/libsrc/usbip_common.h | 11 +++
tools/usb/usbip/src/usbip.c| 1 +
tools/usb/usbip/src/usbip_attach.c | 6 +++---
tools/usb/usbip/src/usbip_connect.c| 6 +++---
tools/usb/usbip/src/usbip_disconnect.c | 6 +++---
tools/usb/usbip/src/usbip_list.c | 6 +++---
tools/usb/usbip/src/usbip_network.c| 9 +++--
tools/usb/usbip/src/usbip_network.h| 3 +--
9 files changed, 42 insertions(+), 16 deletions(-)
diff --git a/tools/usb/usbip/libsrc/usbip_common.c
b/tools/usb/usbip/libsrc/usbip_common.c
index dc0712c..54efa10 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -297,3 +297,13 @@ void usbip_sock_init(usbip_sock_t *sock, int fd, void *arg,
sock-shutdown = shutdown;
}
+usbip_connection_operations_t usbip_conn_ops = {NULL, NULL};
+
+void usbip_conn_init(
+ usbip_sock_t *(*open)(char *host, char *port),
+ void (*close)(usbip_sock_t *sock))
+{
+ usbip_conn_ops.open = open;
+ usbip_conn_ops.close = close;
+}
+
diff --git a/tools/usb/usbip/libsrc/usbip_common.h
b/tools/usb/usbip/libsrc/usbip_common.h
index 0dcbd99..07c411f 100644
--- a/tools/usb/usbip/libsrc/usbip_common.h
+++ b/tools/usb/usbip/libsrc/usbip_common.h
@@ -148,4 +148,15 @@ void usbip_sock_init(usbip_sock_t *sock, int fd, void *arg,
ssize_t (*recv)(void *arg, void *buf, size_t len, int wait_all),
void (*shutdown)(void *arg));
+typedef struct usbip_connection_operations {
+ usbip_sock_t *(*open)(char *host, char *port);
+ void (*close)(usbip_sock_t *sock);
+} usbip_connection_operations_t;
+
+extern usbip_connection_operations_t usbip_conn_ops;
+
+void usbip_conn_init(
+ usbip_sock_t *(*open)(char *host, char *port),
+ void (*close)(usbip_sock_t *sock));
+
#endif /* __USBIP_COMMON_H */
diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
index 9d1468f..505e384 100644
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -202,6 +202,7 @@ int main(int argc, char *argv[])
argc -= optind;
argv += optind;
optind = 0;
+ usbip_net_tcp_conn_init();
rc = run_command(cmds[i], argc, argv);
goto out;
}
diff --git a/tools/usb/usbip/src/usbip_attach.c
b/tools/usb/usbip/src/usbip_attach.c
index fe037de..e1c298e 100644
--- a/tools/usb/usbip/src/usbip_attach.c
+++ b/tools/usb/usbip/src/usbip_attach.c
@@ -135,7 +135,7 @@ static int attach_device(char *host, char *busid)
int rc;
int rhport;
- sock = usbip_net_tcp_connect(host, usbip_port_string);
+ sock = usbip_conn_ops.open(host, usbip_port_string);
if (!sock) {
err(tcp connect);
goto err0;
@@ -164,13 +164,13 @@ static int attach_device(char *host, char *busid)
usbip_ux_join(ux);
}
usbip_ux_cleanup(ux);
- usbip_net_tcp_close(sock);
+ usbip_conn_ops.close(sock);
return 0;
err2:
usbip_ux_cleanup(ux);
err1:
- usbip_net_tcp_close(sock);
+ usbip_conn_ops.close(sock);
err0:
return -1;
}
diff --git a/tools/usb/usbip/src/usbip_connect.c
b/tools/usb/usbip/src/usbip_connect.c
index 4511990..ae8104b 100644
--- a/tools/usb/usbip/src/usbip_connect.c
+++ b/tools/usb/usbip/src/usbip_connect.c
@@ -150,7 +150,7 @@ static int connect_device(char *host, char *busid)
goto err0;
}
- sock = usbip_net_tcp_connect(host, usbip_port_string);
+ sock = usbip_conn_ops.open(host, usbip_port_string);
if (!sock) {
err(tcp connect);
goto err1;
@@ -174,13 +174,13 @@ static int connect_device(char *host, char *busid)
usbip_unbind_device(busid);
}
usbip_ux_cleanup(ux);
- usbip_net_tcp_close(sock);
+ usbip_conn_ops.close(sock);
return 0;
err3:
usbip_ux_cleanup(ux);
err2:
- usbip_net_tcp_close(sock);
+ usbip_conn_ops.close(sock);
err1:
usbip_unbind_device(busid);
err0:
diff --git a/tools/usb/usbip/src/usbip_disconnect.c
b/tools/usb/usbip/src/usbip_disconnect.c
index 8da1717..1bda962 100644
---
[PATCH v2 05/11] usbip: tools for userspace URBs transmission
Originally, USB/IP transmits requests and response PDUs for preparation
to transfer URBs in user space, after completion of the preparation,
URBs are transmitted in kernel space.
To make easy to introduce application network protocols like WebSocket,
the driver, usbip_ux.ko, forwards URBs to USB/IP user space utilities.
Then, the utilities exchange URBs in userspace.
To do so, tools/usb/usbip/libsrc/usbip_ux.c includes tx/rx threads to
read/wite URBs from usbip_ux.ko and transfer URBs in userspace. When
usbip_ux.ko is installed, /dev/usbip-ux will be found, then the threads
will be started. Otherwise, threads will not be started and original
kernel space transmission is valid.
Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp
---
tools/usb/usbip/libsrc/Makefile.am | 1 +
tools/usb/usbip/libsrc/usbip_ux.c | 244 +
tools/usb/usbip/libsrc/usbip_ux.h | 30 +++
tools/usb/usbip/libsrc/vhci_driver.c | 10 +-
tools/usb/usbip/src/usbip_attach.c | 30 ++-
tools/usb/usbip/src/usbip_connect.c| 18 +-
tools/usb/usbip/src/usbip_disconnect.c | 11 +-
tools/usb/usbip/src/usbipd.c | 5 +-
tools/usb/usbip/src/usbipd_app.c | 14 ++
tools/usb/usbip/src/usbipd_dev.c | 30 ++-
10 files changed, 370 insertions(+), 23 deletions(-)
diff --git a/tools/usb/usbip/libsrc/Makefile.am
b/tools/usb/usbip/libsrc/Makefile.am
index 7c8f8a4..5754425 100644
--- a/tools/usb/usbip/libsrc/Makefile.am
+++ b/tools/usb/usbip/libsrc/Makefile.am
@@ -5,4 +5,5 @@ libusbip_la_LDFLAGS = -version-info @LIBUSBIP_VERSION@
lib_LTLIBRARIES := libusbip.la
libusbip_la_SOURCES := names.c names.h usbip_host_driver.c usbip_host_driver.h
\
usbip_common.c usbip_common.h vhci_driver.c
vhci_driver.h \
+ usbip_ux.c usbip_ux.h \
sysfs_utils.c sysfs_utils.h
diff --git a/tools/usb/usbip/libsrc/usbip_ux.c
b/tools/usb/usbip/libsrc/usbip_ux.c
new file mode 100644
index 000..183be7c
--- /dev/null
+++ b/tools/usb/usbip/libsrc/usbip_ux.c
@@ -0,0 +1,244 @@
+/*
+ * Copyright (C) 2015 Nobuo Iwata
+ *
+ * USB/IP URB transmission in userspace.
+ */
+
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/socket.h
+#include usbip_common.h
+#include usbip_ux.h
+
+#undef PROGNAME
+#define PROGNAME libusbip
+
+#define DEVNAME /dev/ USBIP_UX_DEV_NAME
+
+#define BLEN 1500
+
+#ifdef DEBUG
+void dump_buff(char *buff, size_t bufflen, char *label)
+{
+#define DUMP_BUFF 80
+#define WORK_BUFF 16
+ size_t i = 0, j;
+ char b[DUMP_BUFF];
+ char bb[WORK_BUFF];
+
+ dbg(dump %s for %zd bytes, label, bufflen);
+ for(i=0;ibufflen;i++) {
+ j = i % 16;
+ if (j == 0) {
+ b[0] = 0;
+ sprintf(bb, %04zx %02x, i, *(buff+i) 0xff);
+ } else if (j == 8) {
+ sprintf(bb, %02x, *(buff+i) 0xff);
+ } else {
+ sprintf(bb, %02x, *(buff+i) 0xff);
+ }
+ strncat(b, bb, WORK_BUFF);
+ if (j == 15 || i == bufflen-1) {
+ dbg(%s, b);
+ }
+ }
+}
+#else
+#define dump_buff(buff, bufflen, label) while(0){}
+#endif
+
+static void *usbip_ux_rx(void *arg)
+{
+ usbip_ux_t *ux = (usbip_ux_t*)arg;
+ ssize_t received, written, ret;
+ int good = 1;
+ char buf[BLEN];
+
+ while(good) {
+ received = recv(ux-sockfd, buf, BLEN, 0);
+ if (received == 0) {
+ dbg(connection closed on sock:%p, ux-kaddr.sock);
+ break;
+ } else if (received 0) {
+ dbg(receive error on sock:%p, ux-kaddr.sock);
+ break;
+ }
+ dump_buff(buf, received, ux received);
+ written = 0;
+ while(written received) {
+ ret = write(ux-devfd, buf+written, received-written);
+ if (ret 0) {
+ dbg(write error for sock:%p, ux-kaddr.sock);
+ good = 0;
+ break;
+ }
+ written += ret;
+ }
+ }
+ dbg(end of ux-rx for sock:%p, ux-kaddr.sock);
+ ioctl(ux-devfd, USBIP_UX_IOCINTR);
+ return 0;
+}
+
+static void *usbip_ux_tx(void *arg)
+{
+ usbip_ux_t *ux = (usbip_ux_t*)arg;
+ ssize_t sent, reads;
+ char buf[BLEN];
+
+ for(;;) {
+ reads = read(ux-devfd, buf, BLEN);
+ if (reads == 0) {
+#ifdef DEBUG
+ dbg(end of read on sock:%p continue., ux-kaddr.sock);
+#endif
+ sched_yield();
+ continue;
+ } else if (reads 0) {
+ dbg(read error on
[PATCH v2 01/11] usbip: exporting devices
USB/IP supports a function to import USB devices from application-side
machine by attach command.
The usage is as following.
dev:# (Physically attach your USB device.)
dev:# insmod usbip-core.ko and usbip-host.ko
dev:# usbipd -D
// Start usbip daemon.
dev:# usbip list -l
// List local USB devices and their busid.
dev:# usbip bind --busid busid
// Make a device exportable to other hosts.
app:# insmod usbip-core.ko and vhci-hcd.ko
app:# usbip list --remote host
// List importable USB devices from the host.
app:# usbip attach --remote host --busid busid
// Import a device
By attach command, connection will be established from application-side
to device-side.
This patch introduces a function to export devices form device-side
machine to application-side machine.
The usage is as following.
app:# insmod usbip-core.ko and vhci-hcd.ko
app:# usbipa -D
// Start usbip daemon.
dev:# (Physically attach your USB device.)
dev:# insmod usbip-core.ko and usbip-host.ko
dev:# usbip list -l
// List local USB devices and their busid.
dev:# usbip connect --remote host --busid busid
// Export a device to host.
For this, export function, connection is established from device-side
machine to application-side machine.
Following use cases are supposed for the export function.
1) Server application or cloud service serves distributed ubiquitous
devices.
2) Dedicate devices to server application or cloud service.
To connect to cloud service, it needs to connect from inside of
firewall.
Probably, the export function was planned because the packets have been
defined in a header file (usbip_network.h) but it not yet used.
This patch fixes the defined packet structures (ie. int in reply to
uinit32_t) and use them.
Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp
---
tools/usb/usbip/libsrc/usbip_host_driver.c | 16 ++
tools/usb/usbip/libsrc/usbip_host_driver.h | 1 +
tools/usb/usbip/libsrc/vhci_driver.c | 124 +--
tools/usb/usbip/libsrc/vhci_driver.h | 8 +-
tools/usb/usbip/src/Makefile.am| 9 +-
tools/usb/usbip/src/usbip.c| 17 +-
tools/usb/usbip/src/usbip.h| 11 +-
tools/usb/usbip/src/usbip_attach.c | 49 +---
tools/usb/usbip/src/usbip_bind.c | 7 +-
tools/usb/usbip/src/usbip_connect.c| 214 ++
tools/usb/usbip/src/usbip_detach.c | 13 +-
tools/usb/usbip/src/usbip_disconnect.c | 202 +
tools/usb/usbip/src/usbip_list.c | 22 +-
tools/usb/usbip/src/usbip_network.h| 5 +-
tools/usb/usbip/src/usbip_port.c | 5 +
tools/usb/usbip/src/usbip_unbind.c | 7 +-
tools/usb/usbip/src/usbipd.c | 232 +++
tools/usb/usbip/src/usbipd_app.c | 240
tools/usb/usbip/src/usbipd_dev.c | 247 +
19 files changed, 1132 insertions(+), 297 deletions(-)
diff --git a/tools/usb/usbip/libsrc/usbip_host_driver.c
b/tools/usb/usbip/libsrc/usbip_host_driver.c
index bef08d5..de5541a 100644
--- a/tools/usb/usbip/libsrc/usbip_host_driver.c
+++ b/tools/usb/usbip/libsrc/usbip_host_driver.c
@@ -278,3 +278,19 @@ struct usbip_exported_device *usbip_host_get_device(int
num)
return NULL;
}
+
+struct usbip_exported_device *usbip_host_find_device(char *busid)
+{
+ struct list_head *i;
+ struct usbip_exported_device *edev;
+
+ list_for_each(i, host_driver-edev_list) {
+ edev = list_entry(i, struct usbip_exported_device, node);
+ if (!strncmp(busid, edev-udev.busid, SYSFS_BUS_ID_SIZE)) {
+ return edev;
+ }
+ }
+
+ return NULL;
+}
+
diff --git a/tools/usb/usbip/libsrc/usbip_host_driver.h
b/tools/usb/usbip/libsrc/usbip_host_driver.h
index 2a31f85..69c65a6 100644
--- a/tools/usb/usbip/libsrc/usbip_host_driver.h
+++ b/tools/usb/usbip/libsrc/usbip_host_driver.h
@@ -45,5 +45,6 @@ void usbip_host_driver_close(void);
int usbip_host_refresh_device_list(void);
int usbip_host_export_device(struct usbip_exported_device *edev, int sockfd);
struct usbip_exported_device *usbip_host_get_device(int num);
+struct usbip_exported_device *usbip_host_find_device(char *busid);
#endif /* __USBIP_HOST_DRIVER_H */
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c
b/tools/usb/usbip/libsrc/vhci_driver.c
index ad92047..797949d 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2005-2007 Takahiro Hirofuchi
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2005-2007 Takahiro Hirofuchi
*/
#include usbip_common.h
@@ -7,6 +8,8 @@
#include limits.h
#include netdb.h
#include libudev.h
+#include fcntl.h
+#include errno.h
#include sysfs_utils.h
#undef PROGNAME
@@ -215,6 +218,23 @@ static int read_record(int rhport, char *host, unsigned
long host_len,
return 0;
}
+static int open_hc_device(int reopen)
+{
+
[PATCH v2 00/11] usbip: features to USB over WebSocket
Dear all, This series of patches introduces WebSocket to USB/IP. 0. Version info V2) # Formatted patches from linux-next. # Fixed change log word wrapping. # Removed SSL patches. # Fixed a bug that vendor and product names are not shown by usbws list -l because usbip_names_init() was not called in libusbip.la. 1. Why WebSocket? It allows to use USB/IP in internet. WebSocket is widely used to encapsulate packets in HTTP and to carry them through firewall using HTTP port numbers. Assumed use case is a system that service in internet serves distributes devices in home or office networks. Service may be called as cloud and devices as ubiquitous. Home/SOHO/IntranetInternet ++++ +--+ +--+ |Router, ||Internet| +|device|---|Linux |-|proxy, ||service | |+--+ +--+ |firewall||on Linux| +--+ controller++++ ex) Device Service sensors ... environment analysis cameras ... monitoring, recording ID/biometric readers .. authentication 2. Features included It also includes some independent features effective in themselves. 1) Exporting devices Export request and response PDU had been defined in a header but not been used. Now it works! Also, it supports senarios, for example, connect ubiquetous devices to a Linux based cloud service. In this senario, it's needed to establish connection from a device inside of firewall to a service outside. Exporting is suit for the senario. 2) User space transmission USB/IP transfer URBs in kernel space. It's better for performance but difficult to introduce application protocols. Like fuse for file systems, it allows to transfer URBs in user space. When usbip_ux.ko is loaded, it replaces kernel_sendmsg() and kernel_recvmsg() with user spcace interface. When USB/IP utilities find usbip_ux.ko, they start threads to read/write PDUs from/to usbip_ux.ko and send/recv them. 3) Replaceable protocols Both transmission(send/receive) and connection establishment are replaceable. 4) a WebSocket implementation It's made with Poco C++. DNS and proxy are supported. I published scripts I used while developed the patches. http://linux-usbip-additions.blogspot.jp/2015/03/scripts-to-patch-and-ma ke-locally.html http://linux-usbip-additions.blogspot.jp/2015/03/test-scripts.html Thank you, Nobuo Iwata nobuo.iw...@fujixerox.co.jp // *** BLURB HERE *** Nobuo Iwata (11): usbip: exporting devices usbip: readme and manuals about exporting devices usbip: safe completion against usb_kill_urb() usbip: kernel module for userspace URBs transmission usbip: tools for userspace URBs transmission usbip: readme about user space URBs transmission usbip: letting send and receive replaceable usbip: letting connection establishment replaceable usbip: deriving functions as libraries usbip: added const qualifier to arguments of some functions usbip: USB over WebSocket drivers/usb/usbip/Kconfig | 10 + drivers/usb/usbip/Makefile| 3 + drivers/usb/usbip/stub_dev.c | 16 +- drivers/usb/usbip/stub_rx.c | 3 +- drivers/usb/usbip/stub_tx.c | 9 +- drivers/usb/usbip/usbip_common.c | 79 ++- drivers/usb/usbip/usbip_common.h | 29 +- drivers/usb/usbip/usbip_ux.c | 602 ++ drivers/usb/usbip/usbip_ux.h | 82 +++ drivers/usb/usbip/vhci_hcd.c | 9 +- drivers/usb/usbip/vhci_rx.c | 3 +- drivers/usb/usbip/vhci_sysfs.c| 40 +- drivers/usb/usbip/vhci_tx.c | 6 +- include/uapi/linux/usbip_ux.h | 39 ++ tools/usb/usbip/Makefile.am | 2 +- tools/usb/usbip/README| 92 ++- tools/usb/usbip/doc/usbip.8 | 74 ++- tools/usb/usbip/doc/usbipa.8 | 77 +++ tools/usb/usbip/doc/usbipd.8 | 29 +- tools/usb/usbip/libsrc/Makefile.am| 11 +- tools/usb/usbip/libsrc/list.h | 24 +- tools/usb/usbip/libsrc/usbip_common.c | 38 +- tools/usb/usbip/libsrc/usbip_common.h | 27 +- tools/usb/usbip/libsrc/usbip_host_driver.c| 24 +- tools/usb/usbip/libsrc/usbip_host_driver.h| 1 + tools/usb/usbip/libsrc/usbip_ux.c | 256 tools/usb/usbip/libsrc/usbip_ux.h | 30 + tools/usb/usbip/libsrc/vhci_driver.c | 141 +++- tools/usb/usbip/libsrc/vhci_driver.h | 10 +- tools/usb/usbip/src/Makefile.am | 28 +- tools/usb/usbip/src/usbip.c | 18 +- tools/usb/usbip/src/usbip.h | 20 +-
Re: [PATCH v2] Documentation usb serial: fixed how to provide vendor and product id
On Mon, Apr 13, 2015 at 10:09:27PM +0200, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com While trying to test a Cinterion GSM/GPS/3G module I had reconfigured the USB interface by mistake and therefore needed to run a different USB driver than CDC-ACM. It turned out that I need the usbserial driver. This file is an official description how to use it: Documentation/usb/usb-serial.txt But it is outdated. The parameters vendor= and product= are only available if compiled as a kernel module and have been superseded by a /sys interface. Here was the solution: https://bbs.archlinux.org/viewtopic.php?id=175499 insmod usbserial vendor=0x product=0x becomes (first is vendor, second is product) modprobe usbserial echo /sys/bus/usb-serial/drivers/generic/new_id This patch changes the documentation file to describe the modern variant. Please note that the old one still works (if compiled as module). Signed-off-by: H. Nikolaus Schaller h...@goldelico.com Signed-off-by: Marek Belisko ma...@goldelico.com --- changes from v1: - add modern variant with /sys as preferred but also old one works so keep it in documentation (was removed in first version which was not correct) Thanks for the update. Much better. Documentation/usb/usb-serial.txt | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 947fa62..3f31c96 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -465,12 +465,15 @@ Generic Serial driver device, and does not support any kind of device flow control. All that is required of your device is that it has at least one bulk in endpoint, or one bulk out endpoint. - - To enable the generic driver to recognize your device, build the driver - as a module and load it by the following invocation: - insmod usbserial vendor=0x product=0x + + To enable the generic driver to recognize your device, provide + echo /sys/bus/usb-serial/drivers/generic/new_id where the is replaced with the hex representation of your device's vendor id and product id. Could you use distinct symbols for vendor and product if (e.g. vid and pid) to make it clear which is which? + If the driver is compiled as a module, you can either + modprobe usbserial This isn't needed. + or, you can also provide the parameters directly This could be you can also provide one id when loading the module. + insmod usbserial vendor=0x product=0x Thanks, Johan -- 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] hso: fix refcnt leak in recent patch.
On Tue, 14 Apr 2015 08:50:01 +0200 Olivier Sobrie oliv...@sobrie.be wrote:
Hello Neil,
On Tue, Apr 14, 2015 at 11:03:03AM +1000, NeilBrown wrote:
On Tue, 14 Apr 2015 09:36:34 +1000 NeilBrown ne...@suse.de wrote:
Prior to
commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
hso: fix crash when device disappears while serial port is open
hso_serial_open would always kref_get(serial-parent-ref) before
returning zero.
Since that commit, it only calls kref_get when returning 0 if
serial-port.count was zero.
This results in calls to
kref_put(serial-parent-ref, hso_serial_ref_free);
after hso_serial_ref_free has been called, which dereferences a freed
pointer.
This patch adds the missing kref_get().
Fixes: commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
Cc: sta...@vger.kernel.org (v4.0)
Cc: Olivier Sobrie oliv...@sobrie.be
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 75befc1bd816..6848fc903340 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1299,6 +1299,7 @@ static int hso_serial_open(struct tty_struct *tty,
struct file *filp)
}
} else {
D1(Port was already open);
+ kref_get(serial-parent-ref);
}
usb_autopm_put_interface(serial-parent-interface);
Sorry - that was wrong.
I'm getting crashes which strongly suggest the kref_put is being called
extra
times, but I misunderstood the code and was hasty.
Maybe this instead?
Indeed, if I undestand correctly the code in tty_io.c, cleanup() method
is also called when the open fails while kref_get is only done if the
open succeeds. Sorry for that mess.
I assume you get that crash when hso_start_serial_device() returns
an error?
Yes, that's correct.
At first sight, the patch below looks good to me.
I'll test it in the next days.
Thanks.
NeilBrown
Thank you,
Olivier
Thanks,
NeilBrown
From: NeilBrown n...@brown.name
Date: Tue, 14 Apr 2015 09:33:03 +1000
Subject: [PATCH] hso: fix refcnt leak in recent patch.
Prior to
commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
hso: fix crash when device disappears while serial port is open
a kref_get on serial-parent-ref would be taken on each open,
and it would be kref_put on each close.
Now the kref_put happens when the tty_struct is finally put (via
the 'cleanup') providing tty-driver_data has been set.
So the kref_get must be called exact once when tty-driver_data is
set.
With the current code, if the first open fails the kref_get() is never
called, but the kref_put() is called, leaving to a crash.
So change the kref_get call to happen exactly when -driver_data is
changed from NULL to non-NULL.
Fixes: commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
Cc: sta...@vger.kernel.org (v4.0)
Cc: Olivier Sobrie oliv...@sobrie.be
Signed-off-by: NeilBrown n...@brown.name
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 75befc1bd816..17fd3820263a 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1278,6 +1278,8 @@ static int hso_serial_open(struct tty_struct *tty,
struct file *filp)
D1(Opening %d, serial-minor);
/* setup */
+ if (tty-driver_data == NULL)
+ kref_get(serial-parent-ref);
tty-driver_data = serial;
tty_port_tty_set(serial-port, tty);
@@ -1294,8 +1296,6 @@ static int hso_serial_open(struct tty_struct *tty,
struct file *filp)
if (result) {
hso_stop_serial_device(serial-parent);
serial-port.count--;
- } else {
- kref_get(serial-parent-ref);
}
} else {
D1(Port was already open);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pgpYnt5TgA7PH.pgp
Description: OpenPGP digital signature
[PATCH v2] cdc-acm: prevent infinite loop when parsing CDC headers.
Phil and I found out a problem with commit:
7e860a6e7aa6 (cdc-acm: add sanity checks)
It added some sanity checks to ignore potential garbage in CDC headers but
also introduced a potential infinite loop. This can happen at the first
loop iteration (elength = 0 in that case) if the description isn't a
DT_CS_INTERFACE or later if 'buffer[0]' is zero.
It should also be noted that the wrong length was being added to 'buffer'
in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was
assigned after that check in the loop.
A specially crafted USB device could be used to trigger this infinite loop.
v2:
- Use 12-digits sha1 to reference the offending commit.
- Do not break from the loop and try next byte instead.
- Move the assignment outside the 'if'.
- Add a debug print.
Fixes: 7e860a6e7aa6 (cdc-acm: add sanity checks)
Signed-off-by: Phil Turnbull phil.turnb...@oracle.com
Signed-off-by: Quentin Casasnovas quentin.casasno...@oracle.com
CC: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
CC: Oliver Neukum oneu...@suse.de
CC: Adam Lee adam8...@gmail.com
CC: sta...@vger.kernel.org
---
drivers/usb/class/cdc-acm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 6836177..220c0fd 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1133,11 +1133,16 @@ static int acm_probe(struct usb_interface *intf,
}
while (buflen 0) {
+ elength = buffer[0];
+ if (!elength) {
+ dev_err(intf-dev, skipping garbage byte\n);
+ elength = 1;
+ goto next_desc;
+ }
if (buffer[1] != USB_DT_CS_INTERFACE) {
dev_err(intf-dev, skipping garbage\n);
goto next_desc;
}
- elength = buffer[0];
switch (buffer[2]) {
case USB_CDC_UNION_TYPE: /* we've found it */
--
2.0.5
--
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: Bug: Toggling green led on Olinuxino Maxi, also toggles USB
On Sun, Apr 12, 2015 at 12:06:10PM +0200, Stefan Wahren wrote:
[...]
I think the problem has something to with USB OTG, because GPIO 65
is on the same pin for USB_OTG_ID.
My idea was to set dr_mode in olinuxino dts explicit to host and
it works, but i'm not sure that is the right fix.
Shouldn't chipidea driver complain about missing pinctrl or something
else?
Some controllers have dedicated ID pin which doesn't need to configure
pinctrl registers. If the user would like to use role switch function
and the ID pin can be configured by pinctrl subsystem, it needs to set
pinctrl through dts.
So setting dr_mode to host is the one and only solution for this case?
From my point, yes.
Peter
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH 1/5] usb: xhci: cleanup xhci_hcd allocation
On 13/04/15 15:48, Mathias Nyman wrote: Hi On 09.04.2015 12:22, Roger Quadros wrote: Hi, On 07/04/15 17:23, Mathias Nyman wrote: Hi On 02.04.2015 15:23, Roger Quadros wrote: HCD core allocates memory for HCD private data in usb_create_[shared_]hcd() so make use of that mechanism to allocate the struct xhci_hcd. Introduce struct xhci_driver_overrides to provide the size of HCD private data and hc_driver operation overrides. As of now we only need to override the reset and start methods. Signed-off-by: Roger Quadros rog...@ti.com I'm not sure I fully understand the what's going on, or what the intention of this patch is. The main intention is to have both primary and shared HCDs allocated before calling usb_add_hcd() for the primary hcd. This is so that at the first usb_add_hcd() the OTG core knows the HCD topology (i.e. whether it uses a shared HCD or not). From the OTG perspective we have to prevent the actual usb_add_hcd() till the OTG state machine says so. This means that xhci_gen_setup() won't be necessarily called immediately and so we need to allocate for xhci somewhere else. Ok, thanks for explaining. I now understand the reason behind this. So currently xhci driver manages the allocation and freeing of the xhci_hcd structure. We store a pointer to the xhci_hcd structure in the content of both the primary and shared usb_hcds structures hcd_priv field. With this patch xhci would be part of the usb_hcd structure, starting at hcd_priv[0]. (Like EHCI I think) It allocates enough space to include the xhci_hcd in both the primary and shared usb_hcd, but always only use the one in the primary hcd. precisely. I'm not sure what to do with the space allocated for the shared hcd's hcd_priv field. we just ignore the space allocated for the shared hcd. Ok, not a big loss. This also means that xhci goes away together with the primary hcd. It's possible this has some impact as the xhci driver expects xhci to always exists. Can you please point out where this impact is. I've been testing add/remove HCD extensively and didn't observe any issues after applying these 5 patches. Well there is one issue that comes up but it has nothing to do with xhci not being allocated. It has more to do with command being queued after the HCD has gone away and so getting stuck forever without timing out. I went through the codepaths and you're right, should work fine. My concern wasn't valid. This patchset doesn't even touch the order how primary and shared HCDs are created and added in the PCI case, only for the platform device case. I was not very sure how to do it for the PCI case. usb_hcd_pci_probe() wants to create and add the hcd. We need something else to split the create_hcd() and add_hcd() operations. I'll try it out and send forward once rc1 is out. Thanks. cheers, -roger -- 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: Mouse works with eHCI, fails with xHCI - can't set config #1, error -110
On Mon, Apr 13, 2015 at 04:24:50PM -0400, Alan Stern wrote: On Mon, 13 Apr 2015, Mathias Nyman wrote: Another difference between EHCI and xHCI iss that xHCI needs to reset (the host side) of a control endpoint if it stalled. From xHCI 1.0 4.8.3: A STALL detected on any stage (Setup, Data, or Status) of a Default Control Endpoint request shall transition the Endpoint Context to the Halted state. A Default Control Endpoint STALL condition is cleared by a Reset Endpoint Command which transitions the endpoint from the Halted to the Stopped state. The Default Control Endpoint shall return to the Running state when the Doorbell is rung for the next Setup Stage TD sent to the endpoint. ection 8.5.3.4 of the USB2 spec and section 8.12.2.3 of the USB3 spec state of Control pipes, ?Unlike the case of a functional stall, protocol stall does not indicate an error with the device.? The xHC treats a functional stall and protocol stall identically, by Halting the endpoint and requiring software to clear the condition by issuing a Reset Endpoint Command. That sounds like something the xhci-hcd driver needs to do automatically. Higher-level drivers all assume that a protocol stall does not need to be cleared. Hi Mathias and Alan, As Mathias requested, I've included the usbmon output with the patch applied. It didn't make any difference to the end result, the mouse still fails to initialise correctly (no real surprise, I think), but is getting the same string that Alan reported earlier (Laser 0). I've also included the relevant lines from syslog below. (I also have a pcap file captured with tshark if anyone is interested). As always, thanks for your help, Alistair usbmon output: 8800bc095180 590743316 C Ii:1:001:1 0:2048 2 = 0400 8800bc095180 590743354 S Ii:1:001:1 -115:2048 4 880024c51b40 590743380 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 590743399 C Ci:1:001:0 0 4 = 01030100 880024c51b40 590743408 S Co:1:001:0 s 23 01 0010 0002 0 880024c51b40 590743417 C Co:1:001:0 0 0 880024c51b40 590743423 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 590743431 C Ci:1:001:0 0 4 = 0103 880024c51b40 590773073 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 590773106 C Ci:1:001:0 0 4 = 0103 880024c51b40 590805052 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 590805089 C Ci:1:001:0 0 4 = 0103 880024c51b40 590837037 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 590837077 C Ci:1:001:0 0 4 = 0103 880024c51b40 590869051 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 590869079 C Ci:1:001:0 0 4 = 0103 880024c51b40 590869151 S Co:1:001:0 s 23 03 0004 0002 0 880024c51b40 590869176 C Co:1:001:0 0 0 880024c51b40 590925077 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 590925113 C Ci:1:001:0 0 4 = 03031000 880024c51b40 590981102 S Co:1:001:0 s 23 01 0014 0002 0 880024c51b40 590981134 C Co:1:001:0 0 0 880024c51b40 590981217 S Ci:1:000:0 s 80 06 0100 0040 64 880024c51b40 590981978 C Ci:1:000:0 0 18 = 12011001 0008 58043a00 0102 0001 880024c51b40 590982014 S Co:1:001:0 s 23 03 0004 0002 0 880024c51b40 590982031 C Co:1:001:0 0 0 880024c51b40 591037084 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 591037110 C Ci:1:001:0 0 4 = 1103 880024c51b40 591093083 S Ci:1:001:0 s a3 00 0002 0004 4 880024c51b40 591093108 C Ci:1:001:0 0 4 = 03031000 880024c51b40 591149105 S Co:1:001:0 s 23 01 0014 0002 0 880024c51b40 591149128 C Co:1:001:0 0 0 880024c51b40 591165056 S Ci:1:006:0 s 80 06 0100 0012 18 880024c51b40 591165918 C Ci:1:006:0 0 18 = 12011001 0008 58043a00 0102 0001 880024c51b40 591165954 S Ci:1:006:0 s 80 06 0200 0009 9 880024c51b40 591166545 C Ci:1:006:0 0 9 = 09022200 010100a0 32 880024c51b40 591166579 S Ci:1:006:0 s 80 06 0200 0022 34 880024c51b40 591167857 C Ci:1:006:0 0 34 = 09022200 010100a0 32090400 00010301 02000921 10010001 22340007 05810304 880024c51b40 591167895 S Ci:1:006:0 s 80 06 0300 00ff 255 880024c51b40 591168392 C Ci:1:006:0 0 4 = 04030904 880024c51b40 591168422 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 880024c51b40 591169070 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030 880024c51b40 591169098 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 880024c51b40 591169854 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030 880024c51b40 591169884 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 880024c51b40 591170684 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030 880024c51b40 591170702 S Ci:1:006:0 s 80 06 0302 0409 0002 2 880024c51b40 591171025 C Ci:1:006:0 0 2 = 1803 880024c51b40 591171037 S Ci:1:006:0 s 80 06 0302 0409 0018 24 880024c51b40 591171668 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030
Re: [PATCH] genirq: provide dummy set_irq_wake()
Hi Thomas,
On 30/03/15 16:15, Roger Quadros wrote:
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the dummy irq hook.
(e.g. drivers/gpio/gpio-pcf857x.c)
http://article.gmane.org/gmane.linux.kernel/1879035
Signed-off-by: Roger Quadros rog...@ti.com
Any comments on this patch?
cheers,
-roger
---
kernel/irq/dummychip.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 988dc58..2405d7a 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -32,6 +32,11 @@ static unsigned int noop_ret(struct irq_data *data)
return 0;
}
+static int noop_int_ret(struct irq_data *data, unsigned int val)
+{
+ return 0;
+}
+
/*
* Generic no controller implementation
*/
@@ -57,5 +62,6 @@ struct irq_chip dummy_irq_chip = {
.irq_ack= noop,
.irq_mask = noop,
.irq_unmask = noop,
+ .irq_set_wake = noop_int_ret,
};
EXPORT_SYMBOL_GPL(dummy_irq_chip);
--
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 v3 2/4] extcon: usb-gpio: add support for VBUS detection
On 14/04/15 13:31, Chanwoo Choi wrote: On 04/14/2015 07:02 PM, Roger Quadros wrote: Fixed Kishon's id. On 14/04/15 13:01, Roger Quadros wrote: On 10/04/15 12:18, Chanwoo Choi wrote: On 04/10/2015 05:46 PM, Robert Baldyga wrote: On 04/10/2015 10:10 AM, Chanwoo Choi wrote: On 04/10/2015 04:45 PM, Robert Baldyga wrote: On 04/10/2015 09:17 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 06:24 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 11:07 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 04:57 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 04:12 AM, Chanwoo Choi wrote: Hi Robert, [snip] But, I have one question about case[3] If id is low and vbus is high, this patch will update the state of both USB and USB-HOST cable as attached state. Is it possible that two different cables (both USB and USB-HOST) are connected to one port simultaneously? It's because state of single USB cable connection cannot be completely described using single extcon cable. USB cable state has two bits (VBUS and ID), so we need to use two cables for single cable connection. We use following convention: cable USB = VBUS cable USB-HOST = !ID. I think that extcon provider driver have to update the only one cable state of either USB or USB-HOST because USB and USB-HOST feature can not be used at the same time through one h/w port. If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable at the same time, the extcon consumer driver can not decide what handle either USB or USB-HOST. It can. USB OTG allows for that. Moreover device can be host even if ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so detected cable type is USB host). Devices would need to have complete information about USB cable connection, because OTG state machine needs As I knew, USB OTG port don't send the attached cable of both USB and USB-HOST at the same time. The case3 in your patch update two cable state about one h/w port. It's because simple USB or USB-HOST means nothing for USB OTG machine. It needs to know exact VBUS and ID states, which cannot be concluded basing on cable type only. That's why I have used USB-HOST name together with USB to pass additional information about USB cable connection. I think this method is not proper to support this case. It may cause the confusion about other case using USB/USB-HOST cable state except of you commented case. That's why I finally proposed to use USB-ID and USB-VBUS in parallel with old names. It seems to be simpler solution than adding new mechanism notifying about VBUS and ID states changes. As I commented on previous reply, I don't agree to use 'USB-ID' and 'USB-VBUS'. If we add new strange 'USB-ID' and 'USB-VBUS' name, we would add non-general cable name continuoulsy. I think that extcon core provide the helper API to get the value of VBUS. But I need to consider it. Now it is starting to look like existing extcon states are not suitable for USB/PHY drivers to deliver VBUS and ID information reliably. This is because based on your comments the USB and USB-HOST states look like some fuzzy states and have no direct correspondence with VBUS and ID. The fact that they can't become attached simultaneously makes me conclude that USB and USB-HOST cable states are really capturing only the ID pin state. I can suggest the following options a) let USB and USB-HOST only indicate ID pin status. Add a new cable state for VBUS notification. Maybe call it USB-POWER or something. We must discuss it before using the new cable name such as USB-POWER, USB-ID and USB-VBUS. I didn't say to add USB-ID or USB-VBUS. solution (a) was to have the following USB - attached means ID is high. i.e. Type-B plug attached. USB-HOST - attached means ID is low. i.e. Type-A plug attached. USB-POWER - attached means USB power is present. i.e. VBUS is alive. This way the definition of USB and USB-HOST remain true to their name and avoid further confusions. VBUS state is got through the USB-POWER cable state. What is the appropriate method of following two solution? - Fisrt, use the new cable name USB-*. I explained this above. - Second, use the additional API to get the VBUS state. You keep mentioning additional API for VBUS. But I don't see any such API. Can you please suggest what API you are talking about? cheers, -roger Cheers, Chanwoo Choi NOTE: USB-POWER can become attached simultaneously with USB or USB-HOST. But USB-POWER is now really a different cable like Fast-Charger or Slow-Charger. b) stop using extcon framework for USB VBUS and ID notification. -- 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
[RFC][PATCH v2 03/13] usb: otg-fsm: Prevent build warning VDBG redefined
If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].
Prevent that by moving the VDBG defination into the
usb-otg-fsm.c file where it is used.
Also get rid of MPC_LOC which doesn't seem to be used
by anyone.
[1] - warning fixed by this patch:
In file included from drivers/usb/dwc3/core.h:33,
from drivers/usb/dwc3/ep0.c:33:
include/linux/usb/otg-fsm.h:30:1: warning: VDBG redefined
In file included from drivers/usb/dwc3/ep0.c:31:
include/linux/usb/composite.h:615:1: warning: this is the location of the
previous definition
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 9 +
include/linux/usb/otg-fsm.h | 15 ---
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 0caa37b..35f311a 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,6 +30,15 @@
#include linux/usb/otg.h
#include linux/usb/otg-fsm.h
+#undef VDBG
+
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug([%s] fmt , \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
/* Change USB protocol when there is a protocol change */
static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
{
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 85a9150..73136aa 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -21,21 +21,6 @@
#include linux/mutex.h
#include linux/errno.h
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug([%s] fmt , \
-__func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk(Current Location [%s]:[%d]\n, __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
#define PROTO_UNDEF(0)
#define PROTO_HOST (1)
#define PROTO_GADGET (2)
--
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
[RFC][PATCH v2 10/13] udc-core: fix lock circular dependency on udc_lock
we need to unlock the usb_lock mutex before calling
usb_otg_register_gadget() else it will cause a
circular locking dependency.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/gadget/udc/udc-core.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index ad162e5..6246d09 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -399,6 +399,7 @@ int usb_add_gadget_udc(struct device *parent, struct
usb_gadget *gadget)
}
EXPORT_SYMBOL_GPL(usb_add_gadget_udc);
+/* udc_lock must be held */
static void usb_gadget_remove_driver(struct usb_udc *udc)
{
dev_dbg(udc-dev, unregistering UDC driver [%s]\n,
@@ -407,7 +408,11 @@ static void usb_gadget_remove_driver(struct usb_udc *udc)
kobject_uevent(udc-dev.kobj, KOBJ_CHANGE);
/* If OTG, the otg core ensures UDC is stopped on unregister */
- if (usb_otg_unregister_gadget(udc-gadget)) {
+ if (udc-is_otg) {
+ mutex_unlock(udc_lock);
+ usb_otg_unregister_gadget(udc-gadget);
+ mutex_lock(udc_lock);
+ } else {
usb_gadget_disconnect(udc-gadget);
udc-driver-disconnect(udc-gadget);
usb_gadget_udc_stop(udc);
@@ -445,11 +450,12 @@ found:
dev_vdbg(gadget-dev.parent, unregistering gadget\n);
list_del(udc-list);
- mutex_unlock(udc_lock);
if (udc-driver)
usb_gadget_remove_driver(udc);
+ mutex_unlock(udc_lock);
+
kobject_uevent(udc-dev.kobj, KOBJ_REMOVE);
flush_work(gadget-work);
device_unregister(udc-dev);
@@ -459,6 +465,7 @@ EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
/* - */
+/* udc_lock must be held */
static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver
*driver)
{
int ret;
@@ -475,7 +482,9 @@ static int udc_bind_to_driver(struct usb_udc *udc, struct
usb_gadget_driver *dri
goto err1;
/* If OTG, the otg core starts the UDC when needed */
+ mutex_unlock(udc_lock);
udc-is_otg = !usb_otg_register_gadget(udc-gadget);
+ mutex_lock(udc_lock);
if (!udc-is_otg) {
ret = usb_gadget_udc_start(udc);
if (ret) {
--
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
[RFC][PATCH v2 04/13] usb: gadget: add usb_gadget_start/stop()
The OTG state machine needs a mechanism to start and
stop the gadget controller. Add usb_gadget_start()
and usb_gadget_stop().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/gadget/udc/udc-core.c | 74 +++
include/linux/usb/gadget.h| 3 ++
2 files changed, 77 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 5a81cb0..3aa5dd5 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -187,6 +187,7 @@ EXPORT_SYMBOL_GPL(usb_gadget_udc_reset);
*/
static inline int usb_gadget_udc_start(struct usb_udc *udc)
{
+ dev_dbg(udc-dev, %s\n, __func__);
return udc-gadget-ops-udc_start(udc-gadget, udc-driver);
}
@@ -204,10 +205,83 @@ static inline int usb_gadget_udc_start(struct usb_udc
*udc)
*/
static inline void usb_gadget_udc_stop(struct usb_udc *udc)
{
+ dev_dbg(udc-dev, %s\n, __func__);
udc-gadget-ops-udc_stop(udc-gadget);
}
/**
+ * usb_gadget_start - start the usb gadget controller and connect to bus
+ * @gadget: the gadget device to start
+ *
+ * This is external API for use by OTG core.
+ *
+ * Start the usb device controller and connect to bus (enable pull).
+ */
+int usb_gadget_start(struct usb_gadget *gadget)
+{
+ int ret;
+ struct usb_udc *udc = NULL;
+
+ dev_dbg(gadget-dev, %s\n, __func__);
+ mutex_lock(udc_lock);
+ list_for_each_entry(udc, udc_list, list)
+ if (udc-gadget == gadget)
+ goto found;
+
+ dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+ __func__);
+ mutex_unlock(udc_lock);
+ return -EINVAL;
+
+found:
+ ret = usb_gadget_udc_start(udc);
+ if (ret)
+ dev_err(udc-dev, USB Device Controller didn't start: %d\n,
+ ret);
+ else
+ usb_gadget_connect(udc-gadget);
+
+ mutex_unlock(udc_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_start);
+
+/**
+ * usb_gadget_stop - disconnect from bus and stop the usb gadget
+ * @gadget: The gadget device we want to stop
+ *
+ * This is external API for use by OTG core.
+ *
+ * Disconnect from the bus (disable pull) and stop the
+ * gadget controller.
+ */
+int usb_gadget_stop(struct usb_gadget *gadget)
+{
+ struct usb_udc *udc = NULL;
+
+ dev_dbg(gadget-dev, %s\n, __func__);
+ mutex_lock(udc_lock);
+ list_for_each_entry(udc, udc_list, list)
+ if (udc-gadget == gadget)
+ goto found;
+
+ dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+ __func__);
+ mutex_unlock(udc_lock);
+ return -EINVAL;
+
+found:
+ usb_gadget_disconnect(udc-gadget);
+ udc-driver-disconnect(udc-gadget);
+ usb_gadget_udc_stop(udc);
+ mutex_unlock(udc_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_stop);
+
+/**
* usb_udc_release - release the usb_udc struct
* @dev: the dev member within usb_udc
*
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e2f00fd..7ada7e6 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -922,6 +922,9 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver);
*/
int usb_gadget_unregister_driver(struct usb_gadget_driver *driver);
+int usb_gadget_start(struct usb_gadget *gadget);
+int usb_gadget_stop(struct usb_gadget *gadget);
+
extern int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget
*gadget);
--
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
[RFC][PATCH v2 11/13] usb: add dual-role mode to dr_mode device tree helper
We need to differentiat between otg and dual-role operation.
dual-role means capability to operate as host or device depending
on the ID pin status but no support for any of the OTG features
like SRP, HNP and on the fly role-swap.
The only way to change the role for a dual-role device is to
toggle the ID pin by changing the cable.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/usb/generic.txt | 2 +-
drivers/usb/common/common.c | 1 +
include/linux/usb/otg.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/generic.txt
b/Documentation/devicetree/bindings/usb/generic.txt
index 477d5bb..64438f9 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -8,7 +8,7 @@ Optional properties:
HW capability.
- dr_mode: tells Dual-Role USB controllers that we want to work on a
particular mode. Valid arguments are host,
- peripheral and otg. In case this attribute isn't
+ peripheral, otg, dual-role. In case this
attribute isn't
passed via DT, USB DRD controllers should default to
OTG.
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index b530fd4..faf51fe 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -87,6 +87,7 @@ static const char *const usb_dr_modes[] = {
[USB_DR_MODE_HOST] = host,
[USB_DR_MODE_PERIPHERAL]= peripheral,
[USB_DR_MODE_OTG] = otg,
+ [USB_DR_MODE_DRD] = dual-role,
};
/**
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 52661c5..d6057fb 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -102,6 +102,7 @@ enum usb_dr_mode {
USB_DR_MODE_HOST,
USB_DR_MODE_PERIPHERAL,
USB_DR_MODE_OTG,
+ USB_DR_MODE_DRD,
};
#endif /* __LINUX_USB_OTG_H */
--
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
[RFC][PATCH v2 13/13] ARM: dts: dra7x-evm: Enable dual-role for usb1
Now that we have dual-role support working at USB core,
enable dual-role support for usb1 controller.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 2 +-
arch/arm/boot/dts/dra72-evm.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 746cddb..2f495c9 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -552,7 +552,7 @@
};
usb1 {
- dr_mode = peripheral;
+ dr_mode = dual-role;
pinctrl-names = default;
pinctrl-0 = usb1_pins;
};
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index e0264d0..93cdf89 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -381,7 +381,7 @@
};
usb1 {
- dr_mode = peripheral;
+ dr_mode = dual-role;
pinctrl-names = default;
pinctrl-0 = usb1_pins;
};
--
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
[PATCH] ff-core: use new debug macros
Replace old pr_* with dev_* debugging macros
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/input/ff-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/ff-core.c b/drivers/input/ff-core.c
index f50f6dd..b81c88c 100644
--- a/drivers/input/ff-core.c
+++ b/drivers/input/ff-core.c
@@ -23,8 +23,6 @@
/* #define DEBUG */
-#define pr_fmt(fmt) KBUILD_BASENAME : fmt
-
#include linux/input.h
#include linux/module.h
#include linux/mutex.h
@@ -116,7 +114,7 @@ int input_ff_upload(struct input_dev *dev, struct ff_effect
*effect,
if (effect-type FF_EFFECT_MIN || effect-type FF_EFFECT_MAX ||
!test_bit(effect-type, dev-ffbit)) {
- pr_debug(invalid or not supported effect type in upload\n);
+ dev_dbg(dev-dev, invalid or not supported effect type in
upload\n);
return -EINVAL;
}
@@ -124,7 +122,7 @@ int input_ff_upload(struct input_dev *dev, struct ff_effect
*effect,
(effect-u.periodic.waveform FF_WAVEFORM_MIN ||
effect-u.periodic.waveform FF_WAVEFORM_MAX ||
!test_bit(effect-u.periodic.waveform, dev-ffbit))) {
- pr_debug(invalid or not supported wave form in upload\n);
+ dev_dbg(dev-dev, invalid or not supported wave form in
upload\n);
return -EINVAL;
}
@@ -246,7 +244,7 @@ static int flush_effects(struct input_dev *dev, struct file
*file)
struct ff_device *ff = dev-ff;
int i;
- pr_debug(flushing now\n);
+ dev_dbg(dev-dev, flushing now\n);
mutex_lock(ff-mutex);
@@ -316,7 +314,7 @@ int input_ff_create(struct input_dev *dev, unsigned int
max_effects)
int i;
if (!max_effects) {
- pr_err(cannot allocate device without any effects\n);
+ dev_err(dev-dev, cannot allocate device without any
effects\n);
return -EINVAL;
}
--
2.1.4
--
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
[RFC][PATCH v2 01/13] usb: otg-fsm: Add documentation for struct otg_fsm
struct otg_fsm is the interface to the OTG state machine.
Document the input, output and internal state variables.
Definations are taken from Table 7-2 and Table 7-4 of
the USB OTG EH Specification Rev.2.0
Re-arrange some of the members as per use case for more
clarity.
Signed-off-by: Roger Quadros rog...@ti.com
---
include/linux/usb/otg-fsm.h | 80 +
1 file changed, 73 insertions(+), 7 deletions(-)
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index b6ba1bf..c5b74c5 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -57,37 +57,103 @@ enum otg_fsm_timer {
NUM_OTG_FSM_TIMERS,
};
-/* OTG state machine according to the OTG spec */
+/**
+ * struct otg_fsm - OTG state machine according to the OTG spec
+ *
+ * OTG hardware Inputs
+ *
+ * Common inputs for A and B device
+ * @id:TRUE for B-device, FALSE for A-device.
+ * @adp_change: TRUE when current ADP measurement (n) value, compared to the
+ * ADP measurement taken at n-2, differs by more than CADP_THR
+ * @power_up: TRUE when the OTG device first powers up its USB system and
+ * ADP measurement taken if ADP capable
+ *
+ * A-Device state inputs
+ * @a_srp_det: TRUE if the A-device detects SRP
+ * @a_vbus_vld:TRUE when VBUS voltage is in regulation
+ * @b_conn:TRUE if the A-device detects connection from the B-device
+ * @a_bus_resume: TRUE when the B-device detects that the A-device is signaling
+ * a resume (K state)
+ * B-Device state inputs
+ * @a_bus_suspend: TRUE when the B-device detects that the A-device has put
the bus into suspend
+ * @a_conn:TRUE if the B-device detects a connection from the A-device
+ * @b_se0_srp: TRUE when the line has been at SE0 for more than the minimum
+ * time before generating SRP
+ * @b_ssend_srp: TRUE when the VBUS has been below VOTG_SESS_VLD for more than
+ * the minimum time before generating SRP
+ * @b_sess_vld:TRUE when the B-device detects that the voltage on VBUS
is
+ * above VOTG_SESS_VLD
+ * @test_device: TRUE when the B-device switches to B-Host and detects an OTG
test device
+ * FIXME: must be set by host/hub driver
+ *
+ * Application inputs (A-Device)
+ * @a_bus_drop:TRUE when A-device application needs to power down the
bus
+ * @a_bus_req: TRUE when A-device application wants to use the bus.
+ * FALSE to suspend the bus
+ *
+ * Application inputs (B-Device)
+ * @b_bus_req: TRUE during the time that the Application running on the
+ * B-device wants to use the bus
+ *
+ * Auxilary inputs
+ * @a_sess_vld:??
+ * @b_bus_suspend: ??
+ * @b_bus_resume: ??
+ *
+ * OTG Output status. Read only for users. updated by otg_ops() helpers
+ *
+ * Outputs for Both A and B device
+ * @drv_vbus: TRUE when A-device is driving VBUS
+ * @loc_conn: TRUE when the local device has signaled that it is connected to
the bus
+ * @loc_sof: TRUE when the local device is generating activity on the bus
+ * @adp_prb: TRUE when the local device is in the process of doing ADP
probing
+ *
+ * Outputs for B-device state
+ * @adp_sns: TRUE when the B-device is in the process of carrying out ADP
sensing
+ * @data_pulse: TRUE when the B-device is performing data line pulsing
+ *
+ * Internal Variables
+ *
+ * a_set_b_hnp_en: TRUE when the A-device has successfully set the
b_hnp_enable bit in the B-device.
+ *FIXME: OTG fsm uses otg-host-b_hnp_enable instead
+ * b_srp_done: TRUE when the B-device has completed initiating SRP
+ * b_hnp_enable: TRUE when the B-device has accepted the
SetFeature(b_hnp_enable) B-device
+ * FIXME: OTG fsm uses otg-gadget-b_hnp_enable instead
+ * a_clr_err: Asserted (by application ?) to clear a_vbus_err due to an
overcurrent condition
+ * and causes the A-device to transition to a_wait_vfall
+ */
struct otg_fsm {
/* Input */
int id;
int adp_change;
int power_up;
- int test_device;
- int a_bus_drop;
- int a_bus_req;
int a_srp_det;
int a_vbus_vld;
int b_conn;
int a_bus_resume;
int a_bus_suspend;
int a_conn;
- int b_bus_req;
int b_se0_srp;
int b_ssend_srp;
int b_sess_vld;
+ int test_device;
+ int a_bus_drop;
+ int a_bus_req;
+ int b_bus_req;
+
/* Auxilary inputs */
int a_sess_vld;
int b_bus_resume;
int b_bus_suspend;
/* Output */
- int data_pulse;
int drv_vbus;
int loc_conn;
int loc_sof;
int adp_prb;
int adp_sns;
+ int data_pulse;
/* Internal variables */
int a_set_b_hnp_en;
@@ -95,7 +161,7 @@ struct otg_fsm {
int b_hnp_enable;
int a_clr_err;
- /*
[RFC][PATCH v2 07/13] usb: otg: Add dual-role device (DRD) support
DRD mode is a reduced functionality OTG mode. In this mode
we don't support SRP, HNP and dynamic role-swap.
In DRD operation, the controller mode (Host or Peripheral)
is decided based on the ID pin status. Once a cable plug (Type-A
or Type-B) is attached the controller selects the state
and doesn't change till the cable in unplugged and a different
cable type is inserted.
As we don't need most of the complex OTG states and OTG timers
we implement a lean DRD state machine in usb-otg.c.
The DRD state machine is only interested in 2 hardware inputs
'id' and 'vbus; that are still passed via the origintal struct otg_fsm.
Most of the usb-otg.c functionality remains the same except
adding a new parameter to usb_otg_register() to indicate that
the OTG controller needs to operate in DRD mode.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg.c | 179 ---
include/linux/usb/otg-fsm.h | 8 +-
include/linux/usb/usb-otg.h | 5 +-
3 files changed, 179 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index 860e2e7..6d6da86 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -44,6 +44,7 @@ struct otg_hcd {
struct otg_data {
struct device *dev; /* HCD GCD's parent device */
+ bool drd_only; /* Dual-role only, no OTG features */
struct otg_fsm fsm;
/* HCD, GCD and usb_otg_state are present in otg_fsm-otg
* HCD is bus_to_hcd(fsm-otg-host)
@@ -251,22 +252,172 @@ static int usb_otg_start_gadget(struct otg_fsm *fsm, int
on)
return 0;
}
+/* Change USB protocol when there is a protocol change */
+static int drd_set_protocol(struct otg_fsm *fsm, int protocol)
+{
+ struct otg_data *otgd = container_of(fsm, struct otg_data, fsm);
+ int ret = 0;
+
+ if (fsm-protocol != protocol) {
+ dev_dbg(otgd-dev, drd: changing role fsm-protocol= %d; new
protocol= %d\n,
+ fsm-protocol, protocol);
+ /* stop old protocol */
+ if (fsm-protocol == PROTO_HOST)
+ ret = otg_start_host(fsm, 0);
+ else if (fsm-protocol == PROTO_GADGET)
+ ret = otg_start_gadget(fsm, 0);
+ if (ret)
+ return ret;
+
+ /* start new protocol */
+ if (protocol == PROTO_HOST)
+ ret = otg_start_host(fsm, 1);
+ else if (protocol == PROTO_GADGET)
+ ret = otg_start_gadget(fsm, 1);
+ if (ret)
+ return ret;
+
+ fsm-protocol = protocol;
+ return 0;
+ }
+
+ return 0;
+}
+
+/* Called when entering a DRD state */
+static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
+{
+ struct otg_data *otgd = container_of(fsm, struct otg_data, fsm);
+
+ if (fsm-otg-state == new_state)
+ return;
+
+ fsm-state_changed = 1;
+ dev_dbg(otgd-dev, drd: set state: %s\n,
+ usb_otg_state_string(new_state));
+ switch (new_state) {
+ case OTG_STATE_B_IDLE:
+ drd_set_protocol(fsm, PROTO_UNDEF);
+ break;
+ case OTG_STATE_B_PERIPHERAL:
+ drd_set_protocol(fsm, PROTO_GADGET);
+ break;
+ case OTG_STATE_A_HOST:
+ drd_set_protocol(fsm, PROTO_HOST);
+ break;
+ case OTG_STATE_UNDEFINED:
+ case OTG_STATE_B_SRP_INIT:
+ case OTG_STATE_B_WAIT_ACON:
+ case OTG_STATE_B_HOST:
+ case OTG_STATE_A_IDLE:
+ case OTG_STATE_A_WAIT_VRISE:
+ case OTG_STATE_A_WAIT_BCON:
+ case OTG_STATE_A_SUSPEND:
+ case OTG_STATE_A_PERIPHERAL:
+ case OTG_STATE_A_WAIT_VFALL:
+ case OTG_STATE_A_VBUS_ERR:
+ default:
+ dev_warn(otgd-dev, %s: drd: invalid state: %s\n,
+__func__, usb_otg_state_string(new_state));
+ break;
+ }
+
+ fsm-otg-state = new_state;
+}
+
/**
- * OTG FSM work function
+ * DRD state change judgement
+ *
+ * For DRD we're only interested in some of the OTG states
+ * i.e. OTG_STATE_B_IDLE: both peripheral and host are stopped
+ * OTG_STATE_B_PERIPHERAL: peripheral active
+ * OTG_STATE_A_HOST: host active
+ * we're only interested in the following inputs
+ * fsm-id, fsm-vbus
+ */
+static int drd_statemachine(struct otg_fsm *fsm)
+{
+ struct otg_data *otgd = container_of(fsm, struct otg_data, fsm);
+ enum usb_otg_state state;
+
+ mutex_lock(fsm-lock);
+
+ state = fsm-otg-state;
+
+ switch (state) {
+ case OTG_STATE_UNDEFINED:
+ if (!fsm-id)
+ drd_set_state(fsm, OTG_STATE_A_HOST);
+ else if (fsm-id fsm-vbus)
+ drd_set_state(fsm, OTG_STATE_B_PERIPHERAL);
+
[RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
This is an attempt to centralize OTG/Dual-role functionality in the kernel. As of now I've got Dual-role functionality working pretty reliably on dra7-evm. xhci side of things for OTG/DRD use are fixed in http://thread.gmane.org/gmane.linux.kernel/1923161 Changelog: - v2 - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable the host controller - added dual-role-device (DRD) state machine which is a much simpler mode of operation when compared to OTG. Here we don't support fancy OTG features like HNP, SRP, on the fly role-swap. The mode of operation is determined based on ID pin (cable type) and the role doesn't change till the cable type changes. Why?: Most of the OTG drivers have been dealing with the OTG state machine themselves and there is a scope for code re-use. This has been partly addressed by the usb/common/usb-otg-fsm.c but it still leaves the instantiation of the state machine and OTG timers to the controller drivers. We re-use usb-otg-fsm.c but go one step further by instantiating the state machine and timers thus making it easier for drivers to implement OTG functionality. Newer OTG cores support standard host interface (e.g. xHCI?) so host and gadget functionality are no longer closely knit like older cores. There needs to be a way to co-ordinate the operation of the host and gadget in OTG mode. i.e. to stop and start them from a central location. This central location should be the USB OTG core. Host and gadget controllers might be sharing resources and can't be always running. One has to be stopped for the other to run. This can't be done as of now and can be done from the OTG core. What?: - The OTG core instantiates the OTG/DRD Finite State Machine per OTG controller and manages starting/stopping the host and gadget controllers based on the bus state. It provides APIs for the following - Registering an OTG capable controller struct otg_fsm *usb_otg_register(struct device *parent_dev, struct otg_fsm_ops *fsm_ops, bool drd_only); int usb_otg_unregister(struct device *parent_dev); - Registering Host controllers to OTG core (used by hcd-core) int usb_otg_register_hcd(struct usb_hcd *hcd); int usb_otg_unregister_hcd(struct usb_hcd *hcd); - Registering Gadget controllers to OTG core (used by udc-core) int usb_otg_register_gadget(struct usb_gadget *gadget); int usb_otg_unregister_gadget(struct usb_gadget *gadget); - Providing inputs to and kicking the OTG state machine void usb_otg_sync_inputs(struct otg_fsm *fsm); int usb_otg_kick_fsm(struct device *hcd_gcd_device); 'struct otg_fsm' is the interface to the OTG state machine. It contains inputs to the fsm, status of the fsm and operations for the OTG controller driver. Usage model: --- - The OTG controller device is assumed to be the parent of the host and gadget controller. It must call usb_otg_register() before populating the host and gadget devices so that the OTG core is aware that it is an OTG device before the host gadget register. The OTG controller must provide struct otg_fsm_ops * which will be called by the OTG core depending on OTG bus state. - The host/gadget core stacks are modified to inform the OTG core whenever a new host/gadget device is added. The OTG core then checks if the host/gadget is part of the OTG controller and if yes then prevents the host/gadget from starting till both host and gadget are registered, OTG state machine is running and the USB bus state is appropriate to start host/gadget. For this APIs have been added to host/gadget stacks to start/stop the controllers from the OTG core. - No modification is needed for the host/gadget controller drivers. They must ensure that their start/stop methods can be called repeatedly and any shared resources between host gadget are properly managed. The OTG core ensures that both are not started simultaneously. - The OTG core instantiates one OTG state machine per OTG controller and the necessary OTG timers to manage OTG state timeouts. The state machine is started when both host gadget register and stopped when either of them unregisters. The controllers are started and stopped depending on bus state. - During the lifetime of the OTG state machine, inputs can be provided to it by modifying the appropriate members of 'struct otg_fsm' and calling usb_otg_sync_inputs(). This is typically done by the OTG controller driver that called usb_otg_register() since it is the only external component that has the 'struct otg_fsm' handle. Pending items: - We probably need a otg class. - sysfs interface for application OTG inputs and OTG status information - resolve symbol dependency for module use. -- cheers, -roger Roger Quadros (13): usb: otg-fsm: Add documentation for struct otg_fsm usb: otg-fsm: support multiple instances usb: otg-fsm: Prevent build warning VDBG redefined usb: gadget: add usb_gadget_start/stop() usb: otg: add OTG core
[RFC][PATCH v2 08/13] usb: otg: hub: Notify OTG fsm when A device sets b_hnp_enable
This is the a_set_b_hnp_enable flag in the OTG state machine
diagram and must be set when the A-Host has successfully set
the b_hnp_enable feature of the OTG-B-Peripheral attached to it.
When this bit changes we kick our OTG FSM to make note of the
change and act accordingly.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/core/hub.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d7c3d5a..ab0d498 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -22,6 +22,7 @@
#include linux/usb/hcd.h
#include linux/usb/otg.h
#include linux/usb/quirks.h
+#include linux/usb/usb-otg.h
#include linux/workqueue.h
#include linux/mutex.h
#include linux/random.h
@@ -2270,6 +2271,9 @@ static int usb_enumerate_device_otg(struct usb_device
*udev)
can't set HNP mode: %d\n,
err);
bus-b_hnp_enable = 0;
+ } else {
+ /* notify OTG fsm about
a_set_b_hnp_enable */
+ usb_otg_kick_fsm(udev-bus-controller);
}
}
}
@@ -4244,8 +4248,13 @@ hub_port_init (struct usb_hub *hub, struct usb_device
*udev, int port1,
*/
if (!hdev-parent) {
delay = HUB_ROOT_RESET_TIME;
- if (port1 == hdev-bus-otg_port)
+ if (port1 == hdev-bus-otg_port) {
hdev-bus-b_hnp_enable = 0;
+#ifdef CONFIG_USB_OTG
+ /* notify OTG fsm about a_set_b_hnp_enable change */
+ usb_otg_kick_fsm(hdev-bus-controller);
+#endif
+ }
}
/* Some low speed devices have problems with the quick delay, so */
--
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] cdc-acm: prevent infinite loop when parsing CDC headers.
Hello.
On 4/13/2015 7:20 PM, Sergei Shtylyov wrote:
Phil and I found out a problem with commit:
7e860a6e (cdc-acm: add sanity checks)
It added some sanity checks to ignore potential garbage in CDC headers but
also introduced a potential infinite loop. This can happen at the first
loop iteration (elength = 0 in that case) if the description isn't a
DT_CS_INTERFACE or later if 'buffer[0]' is zero.
It should also be noted that the wrong length was being added to 'buffer'
in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was
assigned after that check in the loop.
A specially crafted USB device could be used to trigger this infinite loop.
Fixes: 7e860a6e (cdc-acm: add sanity checks)
12-digit SHA1 hash is required here.
Signed-off-by: Phil Turnbull phil.turnb...@oracle.com
Signed-off-by: Quentin Casasnovas quentin.casasno...@oracle.com
CC: Oliver Neukum oneu...@suse.de
CC: Adam Lee adam8...@gmail.com
---
drivers/usb/class/cdc-acm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 6836177..1ac4587 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1133,11 +1133,12 @@ static int acm_probe(struct usb_interface *intf,
}
while (buflen 0) {
+if ((elength = buffer[0]) == 0)
Please run your patches thru scripts/checkpatch.pl. Assignments in the
*if* operator are not allowed.
s/operator/statement/, of course. :-)
[...]
WBR, Sergei
--
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 v3 2/4] extcon: usb-gpio: add support for VBUS detection
On 04/14/2015 07:38 PM, Roger Quadros wrote: On 14/04/15 13:31, Chanwoo Choi wrote: On 04/14/2015 07:02 PM, Roger Quadros wrote: Fixed Kishon's id. On 14/04/15 13:01, Roger Quadros wrote: On 10/04/15 12:18, Chanwoo Choi wrote: On 04/10/2015 05:46 PM, Robert Baldyga wrote: On 04/10/2015 10:10 AM, Chanwoo Choi wrote: On 04/10/2015 04:45 PM, Robert Baldyga wrote: On 04/10/2015 09:17 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 06:24 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 11:07 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 04:57 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 04:12 AM, Chanwoo Choi wrote: Hi Robert, [snip] But, I have one question about case[3] If id is low and vbus is high, this patch will update the state of both USB and USB-HOST cable as attached state. Is it possible that two different cables (both USB and USB-HOST) are connected to one port simultaneously? It's because state of single USB cable connection cannot be completely described using single extcon cable. USB cable state has two bits (VBUS and ID), so we need to use two cables for single cable connection. We use following convention: cable USB = VBUS cable USB-HOST = !ID. I think that extcon provider driver have to update the only one cable state of either USB or USB-HOST because USB and USB-HOST feature can not be used at the same time through one h/w port. If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable at the same time, the extcon consumer driver can not decide what handle either USB or USB-HOST. It can. USB OTG allows for that. Moreover device can be host even if ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so detected cable type is USB host). Devices would need to have complete information about USB cable connection, because OTG state machine needs As I knew, USB OTG port don't send the attached cable of both USB and USB-HOST at the same time. The case3 in your patch update two cable state about one h/w port. It's because simple USB or USB-HOST means nothing for USB OTG machine. It needs to know exact VBUS and ID states, which cannot be concluded basing on cable type only. That's why I have used USB-HOST name together with USB to pass additional information about USB cable connection. I think this method is not proper to support this case. It may cause the confusion about other case using USB/USB-HOST cable state except of you commented case. That's why I finally proposed to use USB-ID and USB-VBUS in parallel with old names. It seems to be simpler solution than adding new mechanism notifying about VBUS and ID states changes. As I commented on previous reply, I don't agree to use 'USB-ID' and 'USB-VBUS'. If we add new strange 'USB-ID' and 'USB-VBUS' name, we would add non-general cable name continuoulsy. I think that extcon core provide the helper API to get the value of VBUS. But I need to consider it. Now it is starting to look like existing extcon states are not suitable for USB/PHY drivers to deliver VBUS and ID information reliably. This is because based on your comments the USB and USB-HOST states look like some fuzzy states and have no direct correspondence with VBUS and ID. The fact that they can't become attached simultaneously makes me conclude that USB and USB-HOST cable states are really capturing only the ID pin state. I can suggest the following options a) let USB and USB-HOST only indicate ID pin status. Add a new cable state for VBUS notification. Maybe call it USB-POWER or something. We must discuss it before using the new cable name such as USB-POWER, USB-ID and USB-VBUS. I didn't say to add USB-ID or USB-VBUS. solution (a) was to have the following Right. Robert suggested the USB-ID and USB-VBUS cable name on previous mail in mail thread. USB - attached means ID is high. i.e. Type-B plug attached. USB-HOST - attached means ID is low. i.e. Type-A plug attached. USB-POWER - attached means USB power is present. i.e. VBUS is alive. This way the definition of USB and USB-HOST remain true to their name and avoid further confusions. VBUS state is got through the USB-POWER cable state. There is the same case for MHL cable. Also, MHL cable could be connected to VBUS line. - MHL : attached just MHL cable. - MHL-POWER : attache MHL cable which is connected with VBUS line. We must need the opinion of USB/PHY driver's maintainer. What is the appropriate method of following two solution? - Fisrt, use the new cable name USB-*. I explained this above. - Second, use the additional API to get the VBUS state. You keep mentioning additional API for VBUS. But I don't see any such API. Can you please suggest what API you are talking about? I'm considering following functions for VBUS state. But it is my opinion, If USB/PHY drivers's maintainers don't agree the new cable (USB-POWER),
Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection
On 10/04/15 12:18, Chanwoo Choi wrote: On 04/10/2015 05:46 PM, Robert Baldyga wrote: On 04/10/2015 10:10 AM, Chanwoo Choi wrote: On 04/10/2015 04:45 PM, Robert Baldyga wrote: On 04/10/2015 09:17 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 06:24 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 11:07 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 04:57 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 04:12 AM, Chanwoo Choi wrote: Hi Robert, [snip] But, I have one question about case[3] If id is low and vbus is high, this patch will update the state of both USB and USB-HOST cable as attached state. Is it possible that two different cables (both USB and USB-HOST) are connected to one port simultaneously? It's because state of single USB cable connection cannot be completely described using single extcon cable. USB cable state has two bits (VBUS and ID), so we need to use two cables for single cable connection. We use following convention: cable USB = VBUS cable USB-HOST = !ID. I think that extcon provider driver have to update the only one cable state of either USB or USB-HOST because USB and USB-HOST feature can not be used at the same time through one h/w port. If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable at the same time, the extcon consumer driver can not decide what handle either USB or USB-HOST. It can. USB OTG allows for that. Moreover device can be host even if ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so detected cable type is USB host). Devices would need to have complete information about USB cable connection, because OTG state machine needs As I knew, USB OTG port don't send the attached cable of both USB and USB-HOST at the same time. The case3 in your patch update two cable state about one h/w port. It's because simple USB or USB-HOST means nothing for USB OTG machine. It needs to know exact VBUS and ID states, which cannot be concluded basing on cable type only. That's why I have used USB-HOST name together with USB to pass additional information about USB cable connection. I think this method is not proper to support this case. It may cause the confusion about other case using USB/USB-HOST cable state except of you commented case. That's why I finally proposed to use USB-ID and USB-VBUS in parallel with old names. It seems to be simpler solution than adding new mechanism notifying about VBUS and ID states changes. As I commented on previous reply, I don't agree to use 'USB-ID' and 'USB-VBUS'. If we add new strange 'USB-ID' and 'USB-VBUS' name, we would add non-general cable name continuoulsy. I think that extcon core provide the helper API to get the value of VBUS. But I need to consider it. Now it is starting to look like existing extcon states are not suitable for USB/PHY drivers to deliver VBUS and ID information reliably. This is because based on your comments the USB and USB-HOST states look like some fuzzy states and have no direct correspondence with VBUS and ID. The fact that they can't become attached simultaneously makes me conclude that USB and USB-HOST cable states are really capturing only the ID pin state. I can suggest the following options a) let USB and USB-HOST only indicate ID pin status. Add a new cable state for VBUS notification. Maybe call it USB-POWER or something. NOTE: USB-POWER can become attached simultaneously with USB or USB-HOST. But USB-POWER is now really a different cable like Fast-Charger or Slow-Charger. b) stop using extcon framework for USB VBUS and ID notification. cheers, -roger I don't agree. that. As I wrote, current USB cable names are misleading. It would be better to have USB-VBUS and USB-ID. It is strange cable name. I prefer to use only 'USB' cable name. But, we could support the other method to get the state of whether USB-VBUS or USB-ID by using helper API or others. Ok, so do you have any idea how to do it? Do we want to supply additional API for notifying about VBUS and ID changes? No, we need to consider more standard solution to support this case. Thanks, Robert Baldyga -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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 v3 2/4] extcon: usb-gpio: add support for VBUS detection
Fixed Kishon's id. On 14/04/15 13:01, Roger Quadros wrote: On 10/04/15 12:18, Chanwoo Choi wrote: On 04/10/2015 05:46 PM, Robert Baldyga wrote: On 04/10/2015 10:10 AM, Chanwoo Choi wrote: On 04/10/2015 04:45 PM, Robert Baldyga wrote: On 04/10/2015 09:17 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 06:24 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 11:07 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 04:57 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 04:12 AM, Chanwoo Choi wrote: Hi Robert, [snip] But, I have one question about case[3] If id is low and vbus is high, this patch will update the state of both USB and USB-HOST cable as attached state. Is it possible that two different cables (both USB and USB-HOST) are connected to one port simultaneously? It's because state of single USB cable connection cannot be completely described using single extcon cable. USB cable state has two bits (VBUS and ID), so we need to use two cables for single cable connection. We use following convention: cable USB = VBUS cable USB-HOST = !ID. I think that extcon provider driver have to update the only one cable state of either USB or USB-HOST because USB and USB-HOST feature can not be used at the same time through one h/w port. If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable at the same time, the extcon consumer driver can not decide what handle either USB or USB-HOST. It can. USB OTG allows for that. Moreover device can be host even if ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so detected cable type is USB host). Devices would need to have complete information about USB cable connection, because OTG state machine needs As I knew, USB OTG port don't send the attached cable of both USB and USB-HOST at the same time. The case3 in your patch update two cable state about one h/w port. It's because simple USB or USB-HOST means nothing for USB OTG machine. It needs to know exact VBUS and ID states, which cannot be concluded basing on cable type only. That's why I have used USB-HOST name together with USB to pass additional information about USB cable connection. I think this method is not proper to support this case. It may cause the confusion about other case using USB/USB-HOST cable state except of you commented case. That's why I finally proposed to use USB-ID and USB-VBUS in parallel with old names. It seems to be simpler solution than adding new mechanism notifying about VBUS and ID states changes. As I commented on previous reply, I don't agree to use 'USB-ID' and 'USB-VBUS'. If we add new strange 'USB-ID' and 'USB-VBUS' name, we would add non-general cable name continuoulsy. I think that extcon core provide the helper API to get the value of VBUS. But I need to consider it. Now it is starting to look like existing extcon states are not suitable for USB/PHY drivers to deliver VBUS and ID information reliably. This is because based on your comments the USB and USB-HOST states look like some fuzzy states and have no direct correspondence with VBUS and ID. The fact that they can't become attached simultaneously makes me conclude that USB and USB-HOST cable states are really capturing only the ID pin state. I can suggest the following options a) let USB and USB-HOST only indicate ID pin status. Add a new cable state for VBUS notification. Maybe call it USB-POWER or something. NOTE: USB-POWER can become attached simultaneously with USB or USB-HOST. But USB-POWER is now really a different cable like Fast-Charger or Slow-Charger. b) stop using extcon framework for USB VBUS and ID notification. cheers, -roger I don't agree. that. As I wrote, current USB cable names are misleading. It would be better to have USB-VBUS and USB-ID. It is strange cable name. I prefer to use only 'USB' cable name. But, we could support the other method to get the state of whether USB-VBUS or USB-ID by using helper API or others. Ok, so do you have any idea how to do it? Do we want to supply additional API for notifying about VBUS and ID changes? No, we need to consider more standard solution to support this case. Thanks, Robert Baldyga -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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
[RFC][PATCH v2 05/13] usb: otg: add OTG core
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
TODO:
- sysfs interface to allow application inputs to OTG state machine
- otg class?
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/Makefile | 1 +
drivers/usb/common/Makefile | 1 +
drivers/usb/common/usb-otg.c | 743 +++
drivers/usb/common/usb-otg.h | 71 +
drivers/usb/core/Kconfig | 8 +
include/linux/usb/usb-otg.h | 94 ++
6 files changed, 918 insertions(+)
create mode 100644 drivers/usb/common/usb-otg.c
create mode 100644 drivers/usb/common/usb-otg.h
create mode 100644 include/linux/usb/usb-otg.h
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2f1e2aa..07f59a5 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -60,5 +60,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += renesas_usbhs/
obj-$(CONFIG_USB_GADGET) += gadget/
obj-$(CONFIG_USB_COMMON) += common/
+obj-$(CONFIG_USB_OTG_CORE) += common/
obj-$(CONFIG_USBIP_CORE) += usbip/
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index ca2f8bd..573fc75 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,3 +7,4 @@ usb-common-y += common.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG_CORE) += usb-otg.o
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..e848e08
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,743 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+#include linux/list.h
+#include linux/usb/otg.h
+#include linux/usb/phy.h /* enum usb_otg_state */
+#include linux/usb/gadget.h
+#include linux/usb/usb-otg.h
+#include linux/workqueue.h
+
+#include usb-otg.h
+
+/* to link timer with callback data */
+struct otg_timer {
+ struct hrtimer timer;
+ ktime_t timeout;
+ /* callback data */
+ int *timeout_bit;
+ struct otg_data *otgd;
+};
+
+struct otg_hcd {
+ struct usb_hcd *hcd;
+ unsigned int irqnum;
+ unsigned long irqflags;
+};
+
+struct otg_data {
+ struct device *dev; /* HCD GCD's parent device */
+
+ struct otg_fsm fsm;
+ /* HCD, GCD and usb_otg_state are present in otg_fsm-otg
+* HCD is bus_to_hcd(fsm-otg-host)
+* GCD is fsm-otg-gadget
+*/
+ struct otg_fsm_ops fsm_ops; /* private copy for override */
+ struct usb_otg otg; /* allocator for fsm-otg */
+
+ struct otg_hcd primary_hcd;
+ struct otg_hcd shared_hcd;
+
+ /* saved hooks to OTG device */
+ int (*start_host)(struct otg_fsm *fsm, int on);
+ int (*start_gadget)(struct otg_fsm *fsm, int on);
+
+ struct list_head list;
+
+ struct work_struct work;/* OTG FSM work */
+ struct workqueue_struct *wq;
+
+ struct otg_timer timers[NUM_OTG_FSM_TIMERS];
+
+ bool fsm_running;
+ /* use otg-fsm.lock for serializing access */
+};
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+/**
+ * check if device is in our OTG list and return
+ * otg_data, else NULL.
+ *
+ * otg_list_mutex must be held.
+ */
+static struct otg_data *usb_otg_device_get_otgd(struct device *parent_dev)
+{
+ struct otg_data *otgd;
+
+ list_for_each_entry(otgd, otg_list, list) {
+ if (otgd-dev == parent_dev)
+ return otgd;
+ }
+
+ return NULL;
+}
+
+/**
+ * timer callback to set timeout bit and kick FSM
+ */
+static enum hrtimer_restart set_tmout(struct hrtimer *data)
+{
+ struct otg_timer *otgtimer;
+
+ otgtimer = container_of(data, struct otg_timer, timer);
+ if (otgtimer-timeout_bit)
+ *otgtimer-timeout_bit = 1;
+
+ usb_otg_sync_inputs(otgtimer-otgd-fsm);
+
+ return HRTIMER_NORESTART;
+}
+
+/**
+ * Initialize one OTG timer with callback, timeout and timeout bit
+ */
[RFC][PATCH v2 12/13] usb: dwc3: add dual-role support
Register with the USB OTG core. Since we don't support
OTG yet we just work as a dual-role device even
if device tree says otg.
Use extcon framework to get VBUS/ID cable events and
kick the OTG state machine.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/dwc3/core.c | 146 ++-
drivers/usb/dwc3/core.h | 6 ++
drivers/usb/dwc3/platform_data.h | 1 +
3 files changed, 151 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9f0e209..3e04b96 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -39,6 +39,7 @@
#include linux/usb/gadget.h
#include linux/usb/of.h
#include linux/usb/otg.h
+#include linux/usb/usb-otg.h
#include platform_data.h
#include core.h
@@ -504,7 +505,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
* SOF/ITP Mode Used
*/
if ((dwc-dr_mode == USB_DR_MODE_HOST ||
- dwc-dr_mode == USB_DR_MODE_OTG)
+ dwc-dr_mode == USB_DR_MODE_OTG ||
+ dwc-dr_mode == USB_DR_MODE_DRD)
(dwc-revision = DWC3_REVISION_210A
dwc-revision = DWC3_REVISION_250A))
reg |= DWC3_GCTL_DSBLCLKGTNG | DWC3_GCTL_SOFITPSYNC;
@@ -656,6 +658,119 @@ static int dwc3_core_get_phy(struct dwc3 *dwc)
return 0;
}
+/* - Dual-Role management ---
*/
+
+static void dwc3_drd_fsm_sync(struct dwc3 *dwc)
+{
+ int id, vbus;
+
+ /* get ID */
+ id = extcon_get_cable_state(dwc-edev, USB-HOST);
+ /* Host means ID == 0 */
+ id = !id;
+
+ /* get VBUS */
+ vbus = extcon_get_cable_state(dwc-edev, USB);
+ dev_dbg(dwc-dev, id %d vbus %d\n, id, vbus);
+
+ dwc-fsm-id = id;
+ dwc-fsm-vbus = vbus;
+ usb_otg_sync_inputs(dwc-fsm);
+}
+
+static int dwc3_drd_start_host(struct otg_fsm *fsm, int on)
+{
+ struct device *dev = usb_otg_fsm_to_dev(fsm);
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+
+ dev_dbg(dwc-dev, %s: %d\n, __func__, on);
+ if (on)
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+
+ return 0;
+}
+
+static int dwc3_drd_start_gadget(struct otg_fsm *fsm, int on)
+{
+ struct device *dev = usb_otg_fsm_to_dev(fsm);
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+
+ dev_dbg(dwc-dev, %s: %d\n, __func__, on);
+ if (on) {
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+ dwc3_event_buffers_setup(dwc);
+ }
+
+ return 0;
+}
+
+static struct otg_fsm_ops dwc3_drd_ops = {
+ .start_host = dwc3_drd_start_host,
+ .start_gadget = dwc3_drd_start_gadget,
+};
+
+static int dwc3_drd_notifier(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct dwc3 *dwc = container_of(nb, struct dwc3, otg_nb);
+
+ dwc3_drd_fsm_sync(dwc);
+
+ return NOTIFY_DONE;
+}
+
+static int dwc3_drd_init(struct dwc3 *dwc)
+{
+ int ret, id, vbus;
+
+ if (!dwc-edev) {
+ dev_err(dwc-dev, No extcon device found for OTG mode\n);
+ return -ENODEV;
+ }
+
+ dwc-otg_nb.notifier_call = dwc3_drd_notifier;
+ ret = extcon_register_notifier(dwc-edev, dwc-otg_nb);
+ if (ret 0) {
+ dev_err(dwc-dev, Couldn't register USB cable notifier\n);
+ return -ENODEV;
+ }
+
+ /* sanity check id vbus states */
+ id = extcon_get_cable_state(dwc-edev, USB-HOST);
+ vbus = extcon_get_cable_state(dwc-edev, USB);
+ if (id 0 || vbus 0) {
+ dev_err(dwc-dev, Invalid USB cable state. id %d, vbus %d\n,
+ id, vbus);
+ ret = -ENODEV;
+ goto fail;
+ }
+
+ /* register parent as OTG device with USB core */
+ dwc-fsm = usb_otg_register(dwc-dev, dwc3_drd_ops, true);
+ if (IS_ERR(dwc-fsm)) {
+ dev_err(dwc-dev, Failed to register with OTG core\n);
+ ret = -ENODEV;
+ goto fail;
+ }
+
+ dwc3_drd_fsm_sync(dwc);
+
+ return 0;
+
+fail:
+ extcon_unregister_notifier(dwc-edev, dwc-otg_nb);
+
+ return ret;
+}
+
+static void dwc3_drd_exit(struct dwc3 *dwc)
+{
+ usb_otg_unregister(dwc-dev);
+ extcon_unregister_notifier(dwc-edev, dwc-otg_nb);
+}
+
+/* --
*/
+
static int dwc3_core_init_mode(struct dwc3 *dwc)
{
struct device *dev = dwc-dev;
@@ -679,7 +794,15 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
}
break;
case USB_DR_MODE_OTG:
- dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+ dev_info(dev, otg not implemented, we'll work as dual-role\n);
+ /* fall
[RFC][PATCH v2 02/13] usb: otg-fsm: support multiple instances
Move the state_changed variable into struct otg_fsm
so that we can support multiple instances.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg-fsm.c | 10 --
include/linux/usb/otg-fsm.h | 1 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 1736bbe..0caa37b 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -61,8 +61,6 @@ static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
return 0;
}
-static int state_changed;
-
/* Called when leaving a state. Do state clean up jobs here */
static void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state old_state)
{
@@ -123,7 +121,7 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
usb_otg_state old_state)
/* Called when entering a state */
static int otg_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
{
- state_changed = 1;
+ fsm-state_changed = 1;
if (fsm-otg-state == new_state)
return 0;
VDBG(Set state: %s\n, usb_otg_state_string(new_state));
@@ -255,7 +253,7 @@ int otg_statemachine(struct otg_fsm *fsm)
mutex_lock(fsm-lock);
state = fsm-otg-state;
- state_changed = 0;
+ fsm-state_changed = 0;
/* State machine state change judgement */
switch (state) {
@@ -368,7 +366,7 @@ int otg_statemachine(struct otg_fsm *fsm)
}
mutex_unlock(fsm-lock);
- VDBG(quit statemachine, changed = %d\n, state_changed);
- return state_changed;
+ VDBG(quit statemachine, changed = %d\n, fsm-state_changed);
+ return fsm-state_changed;
}
EXPORT_SYMBOL_GPL(otg_statemachine);
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index c5b74c5..85a9150 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -183,6 +183,7 @@ struct otg_fsm {
/* Current usb protocol used: 0:undefine; 1:host; 2:client */
int protocol;
struct mutex lock;
+ bool state_changed;
};
struct otg_fsm_ops {
--
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
[RFC][PATCH v2 06/13] usb: hcd: Add hcd add/remove functions for OTG use
The existing usb_add/remove_hcd() functionality
remains unchanged for non-OTG devices. For OTG
devices they only register the HCD with the OTG core.
Introduce _usb_add/remove_hcd() for use by OTG core.
These functions actually add/remove the HCD.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/common/usb-otg.c | 14 +++---
drivers/usb/core/hcd.c | 24 ++--
include/linux/usb/hcd.h | 3 +++
3 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index e848e08..860e2e7 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -198,18 +198,18 @@ static int usb_otg_start_host(struct otg_fsm *fsm, int on)
otgd-start_host(fsm, on);
/* start host */
- usb_add_hcd(otgd-primary_hcd.hcd, otgd-primary_hcd.irqnum,
- otgd-primary_hcd.irqflags);
+ _usb_add_hcd(otgd-primary_hcd.hcd, otgd-primary_hcd.irqnum,
+otgd-primary_hcd.irqflags);
if (otgd-shared_hcd.hcd) {
- usb_add_hcd(otgd-shared_hcd.hcd,
- otgd-shared_hcd.irqnum,
- otgd-shared_hcd.irqflags);
+ _usb_add_hcd(otgd-shared_hcd.hcd,
+otgd-shared_hcd.irqnum,
+otgd-shared_hcd.irqflags);
}
} else {
/* stop host */
if (otgd-shared_hcd.hcd)
- usb_remove_hcd(otgd-shared_hcd.hcd);
- usb_remove_hcd(otgd-primary_hcd.hcd);
+ _usb_remove_hcd(otgd-shared_hcd.hcd);
+ _usb_remove_hcd(otgd-primary_hcd.hcd);
/* OTG device operations */
if (otgd-start_host)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 45a915c..9a9c0f7 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -46,6 +46,7 @@
#include linux/usb.h
#include linux/usb/hcd.h
#include linux/usb/phy.h
+#include linux/usb/usb-otg.h
#include usb.h
@@ -2622,7 +2623,7 @@ static void usb_put_invalidate_rhdev(struct usb_hcd *hcd)
* buffers of consistent memory, register the bus, request the IRQ line,
* and call the driver's reset() and start() routines.
*/
-int usb_add_hcd(struct usb_hcd *hcd,
+int _usb_add_hcd(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags)
{
int retval;
@@ -2827,6 +2828,17 @@ err_phy:
}
return retval;
}
+EXPORT_SYMBOL_GPL(_usb_add_hcd);
+
+int usb_add_hcd(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags)
+{
+ /* If OTG device, OTG core takes care of adding HCD */
+ if (usb_otg_register_hcd(hcd, irqnum, irqflags))
+ return _usb_add_hcd(hcd, irqnum, irqflags);
+
+ return 0;
+}
EXPORT_SYMBOL_GPL(usb_add_hcd);
/**
@@ -2837,7 +2849,7 @@ EXPORT_SYMBOL_GPL(usb_add_hcd);
* Disconnects the root hub, then reverses the effects of usb_add_hcd(),
* invoking the HCD's stop() method.
*/
-void usb_remove_hcd(struct usb_hcd *hcd)
+void _usb_remove_hcd(struct usb_hcd *hcd)
{
struct usb_device *rhdev = hcd-self.root_hub;
@@ -2911,6 +2923,14 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_put_invalidate_rhdev(hcd);
}
+EXPORT_SYMBOL_GPL(_usb_remove_hcd);
+
+void usb_remove_hcd(struct usb_hcd *hcd)
+{
+ /* If OTG device, OTG core takes care of stopping HCD */
+ if (usb_otg_unregister_hcd(hcd))
+ _usb_remove_hcd(hcd);
+}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
void
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 68b1e83..7993ae7 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -433,7 +433,10 @@ extern void usb_put_hcd(struct usb_hcd *hcd);
extern int usb_hcd_is_primary_hcd(struct usb_hcd *hcd);
extern int usb_add_hcd(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags);
+extern int _usb_add_hcd(struct usb_hcd *hcd,
+ unsigned int irqnum, unsigned long irqflags);
extern void usb_remove_hcd(struct usb_hcd *hcd);
+extern void _usb_remove_hcd(struct usb_hcd *hcd);
extern int usb_hcd_find_raw_port_number(struct usb_hcd *hcd, int port1);
struct platform_device;
--
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
[RFC][PATCH v2 09/13] usb: gadget: udc: adapt to OTG
Register with OTG core when gadget function driver
is available and unregister when function driver is unbound.
Ignore softconnect sysfs control when we're in OTG
mode as OTG FSM takes care of gadget softconnect using
the b_bus_req mechanism.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/gadget/udc/udc-core.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 3aa5dd5..ad162e5 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
#include linux/usb/ch9.h
#include linux/usb/gadget.h
#include linux/usb.h
+#include linux/usb/usb-otg.h
/**
* struct usb_udc - describes one usb device controller
@@ -35,6 +36,7 @@
* @dev - the child device to the actual controller
* @gadget - the gadget. For use by the class code
* @list - for use by the udc class driver
+ * @is_otg - we're registered with OTG core and it takes care of UDC start/stop
*
* This represents the internal data structure which is used by the UDC-class
* to hold information about udc driver and gadget together.
@@ -44,6 +46,7 @@ struct usb_udc {
struct usb_gadget *gadget;
struct device dev;
struct list_headlist;
+ boolis_otg;
};
static struct class *udc_class;
@@ -403,10 +406,14 @@ static void usb_gadget_remove_driver(struct usb_udc *udc)
kobject_uevent(udc-dev.kobj, KOBJ_CHANGE);
- usb_gadget_disconnect(udc-gadget);
- udc-driver-disconnect(udc-gadget);
+ /* If OTG, the otg core ensures UDC is stopped on unregister */
+ if (usb_otg_unregister_gadget(udc-gadget)) {
+ usb_gadget_disconnect(udc-gadget);
+ udc-driver-disconnect(udc-gadget);
+ usb_gadget_udc_stop(udc);
+ }
+
udc-driver-unbind(udc-gadget);
- usb_gadget_udc_stop(udc);
udc-driver = NULL;
udc-dev.driver = NULL;
@@ -466,12 +473,17 @@ static int udc_bind_to_driver(struct usb_udc *udc, struct
usb_gadget_driver *dri
ret = driver-bind(udc-gadget, driver);
if (ret)
goto err1;
- ret = usb_gadget_udc_start(udc);
- if (ret) {
- driver-unbind(udc-gadget);
- goto err1;
+
+ /* If OTG, the otg core starts the UDC when needed */
+ udc-is_otg = !usb_otg_register_gadget(udc-gadget);
+ if (!udc-is_otg) {
+ ret = usb_gadget_udc_start(udc);
+ if (ret) {
+ driver-unbind(udc-gadget);
+ goto err1;
+ }
+ usb_gadget_connect(udc-gadget);
}
- usb_gadget_connect(udc-gadget);
kobject_uevent(udc-dev.kobj, KOBJ_CHANGE);
return 0;
@@ -583,6 +595,12 @@ static ssize_t usb_udc_softconn_store(struct device *dev,
return -EOPNOTSUPP;
}
+ /* In OTG mode we don't support softconnect, but b_bus_req */
+ if (udc-is_otg) {
+ dev_err(dev, soft-connect not supported in OTG mode\n);
+ return -EOPNOTSUPP;
+ }
+
if (sysfs_streq(buf, connect)) {
usb_gadget_udc_start(udc);
usb_gadget_connect(udc-gadget);
--
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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
On Tuesday 14 April 2015 13:19:34 Greg Kroah-Hartman wrote: On Mon, Apr 13, 2015 at 03:10:46PM -0700, Arun Ramamurthy wrote: Getting phys by index instead of phy names so that we do not have to create a naming scheme when multiple phys are present Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Reviewed-by: Ray Jui r...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com --- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-platform.c | 70 ++-- 2 files changed, 26 insertions(+), 45 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 5ad60e4..563f22d 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -284,6 +284,7 @@ config USB_EHCI_ATH79 config USB_EHCI_HCD_PLATFORM tristate Generic EHCI driver for a platform device + select GENERIC_PHY Configs should never select if at all possible. This is true, but all other drivers do the same for GENERIC_PHY at the moment. If this one gets changed, we should probably apply the same solution to all current users and fix them consistently. We can do one of these two: a) make sure that the framework has 'static inline' stubs that let you build all drivers using it when the framework itself is disabled. b) change the drivers using it to 'depends on', and make GENERIC_PHY itself a hidden option without a Kconfig prompt. Either solution is probably simple enough that it can be done as part of this series. Arnd -- 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 v3 2/4] extcon: usb-gpio: add support for VBUS detection
On 04/14/2015 07:02 PM, Roger Quadros wrote: Fixed Kishon's id. On 14/04/15 13:01, Roger Quadros wrote: On 10/04/15 12:18, Chanwoo Choi wrote: On 04/10/2015 05:46 PM, Robert Baldyga wrote: On 04/10/2015 10:10 AM, Chanwoo Choi wrote: On 04/10/2015 04:45 PM, Robert Baldyga wrote: On 04/10/2015 09:17 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 06:24 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 11:07 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 04:57 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 04:12 AM, Chanwoo Choi wrote: Hi Robert, [snip] But, I have one question about case[3] If id is low and vbus is high, this patch will update the state of both USB and USB-HOST cable as attached state. Is it possible that two different cables (both USB and USB-HOST) are connected to one port simultaneously? It's because state of single USB cable connection cannot be completely described using single extcon cable. USB cable state has two bits (VBUS and ID), so we need to use two cables for single cable connection. We use following convention: cable USB = VBUS cable USB-HOST = !ID. I think that extcon provider driver have to update the only one cable state of either USB or USB-HOST because USB and USB-HOST feature can not be used at the same time through one h/w port. If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable at the same time, the extcon consumer driver can not decide what handle either USB or USB-HOST. It can. USB OTG allows for that. Moreover device can be host even if ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so detected cable type is USB host). Devices would need to have complete information about USB cable connection, because OTG state machine needs As I knew, USB OTG port don't send the attached cable of both USB and USB-HOST at the same time. The case3 in your patch update two cable state about one h/w port. It's because simple USB or USB-HOST means nothing for USB OTG machine. It needs to know exact VBUS and ID states, which cannot be concluded basing on cable type only. That's why I have used USB-HOST name together with USB to pass additional information about USB cable connection. I think this method is not proper to support this case. It may cause the confusion about other case using USB/USB-HOST cable state except of you commented case. That's why I finally proposed to use USB-ID and USB-VBUS in parallel with old names. It seems to be simpler solution than adding new mechanism notifying about VBUS and ID states changes. As I commented on previous reply, I don't agree to use 'USB-ID' and 'USB-VBUS'. If we add new strange 'USB-ID' and 'USB-VBUS' name, we would add non-general cable name continuoulsy. I think that extcon core provide the helper API to get the value of VBUS. But I need to consider it. Now it is starting to look like existing extcon states are not suitable for USB/PHY drivers to deliver VBUS and ID information reliably. This is because based on your comments the USB and USB-HOST states look like some fuzzy states and have no direct correspondence with VBUS and ID. The fact that they can't become attached simultaneously makes me conclude that USB and USB-HOST cable states are really capturing only the ID pin state. I can suggest the following options a) let USB and USB-HOST only indicate ID pin status. Add a new cable state for VBUS notification. Maybe call it USB-POWER or something. We must discuss it before using the new cable name such as USB-POWER, USB-ID and USB-VBUS. What is the appropriate method of following two solution? - Fisrt, use the new cable name USB-*. - Second, use the additional API to get the VBUS state. Cheers, Chanwoo Choi NOTE: USB-POWER can become attached simultaneously with USB or USB-HOST. But USB-POWER is now really a different cable like Fast-Charger or Slow-Charger. b) stop using extcon framework for USB VBUS and ID notification. -- 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] usb: Enable LPM for USB 2.01+ full-speed devices
USB 2.01+ full-speed devices can have extended descriptor as well
and can support LPM.
Signed-off-by: Rupesh Tatiya rtat...@codeaurora.org
---
drivers/usb/core/hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 9ef2d2c..1ed7b5d 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -140,7 +140,7 @@ static int usb_device_supports_lpm(struct usb_device *udev)
/* USB 2.1 (and greater) devices indicate LPM support through
* their USB 2.0 Extended Capabilities BOS descriptor.
*/
- if (udev-speed == USB_SPEED_HIGH) {
+ if (udev-speed == USB_SPEED_HIGH || udev-speed == USB_SPEED_FULL) {
if (udev-bos-ext_cap
(USB_LPM_SUPPORT
le32_to_cpu(udev-bos-ext_cap-bmAttributes)))
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
On Mon, Apr 13, 2015 at 03:10:46PM -0700, Arun Ramamurthy wrote: Getting phys by index instead of phy names so that we do not have to create a naming scheme when multiple phys are present Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Reviewed-by: Ray Jui r...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com --- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-platform.c | 70 ++-- 2 files changed, 26 insertions(+), 45 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 5ad60e4..563f22d 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -284,6 +284,7 @@ config USB_EHCI_ATH79 config USB_EHCI_HCD_PLATFORM tristate Generic EHCI driver for a platform device + select GENERIC_PHY Configs should never select if at all possible. -- 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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
On Tue, Apr 14, 2015 at 03:17:30PM +0200, Arnd Bergmann wrote: On Tuesday 14 April 2015 14:37:37 Greg Kroah-Hartman wrote: On Tue, Apr 14, 2015 at 01:33:08PM +0200, Arnd Bergmann wrote: This is true, but all other drivers do the same for GENERIC_PHY at the moment. If this one gets changed, we should probably apply the same solution to all current users and fix them consistently. We can do one of these two: a) make sure that the framework has 'static inline' stubs that let you build all drivers using it when the framework itself is disabled. Yes, please do that. b) change the drivers using it to 'depends on', and make GENERIC_PHY itself a hidden option without a Kconfig prompt. Then how could GENERIC_PHY ever get set? Right now, every driver that provides a phy uses 'select GENERIC_PHY', and they would have to keep doing that. This is not unlike what we do for other silent symbols like MFD_CORE, REGMAP_I2C, or PINCTRL, and it's not as problematic as 'select' on a user-visible option, or (worst) mixing 'select' and 'depends on'. Ok, that would make more sense, but it would be good for the PHY maintainer to agree to it as well :) thanks, greg k-h -- 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: Linux USB driver failure (Ubutu 14.10 64 Bit) with formerly working HID device.
On Tue, 14 Apr 2015, Graeme Gill wrote: Hi, I have a user reporting a problem with a particular USB HID device on Linux that I suspect is a Linux driver issue, or possibly a failure in my (user mode driver) to handle an unexpected Linux USB response. The device is an X-Rite ColorMunki Display colorimeter (== i1d3). I've not seen any issues with this device in my testing on (older version of) Linux, and can't reproduce the problem: Peter Wiesboeck wrote: On my new computer dispcal dosn't work. OS is Ubutu 14.10 (64 Bit), ArgyllCMS version is 1.6.3 (64Bit-Version). Colorimeter is Colormunki Display. This device works well on my old machine Ubuntu 14.4 (32 Bit) as well as on Win7. I tested different USB-Ports but without any success. Dispcal is started with command `dispcal -v -yl -ql -d1 -D6 -o viewsonic`. Some times it fails on cmd 'GetLockedStatus', some times at cmd 'ReadInternalEEPROM' Attached is the debug output of the ArgyllCMS instrument driver, plus a usbmon trace. One of a couple of transactions returns an error from the Linux USB driver after initially communicating successfully. My (user mode) driver returns an ICOM err 0x100 if the urb.status has a value 0 and it's not -ECONNRESET The Colormunki is on Bus 3 Device 6. The interrupt data read that fails seems to return error -71, EPROTO Does anyone have any insights into the nature and cause of this error ? -71 is a low-level communication error. It generally means that the computer did not receive a reply packet that it was expecting, or the packet it received was corrupted. Two possibilities seem most likely. First, the device itself might be a little flakey. The usbmon trace shows several places where communication errors occurred. The first two were during enumeration, and the system recovered simply by retrying the failed transfers. The third was while the user-mode driver was running (the -71 error you encountered). The driver did not attempt to retry the failed transfer; it just gave up. Second, it's possible that the device isn't interacting well with the xHCI host controller on the computer. People have reported similar behavior in the past: Devices that are a little bit on the edge will work okay with EHCI or OHCI but occasionally fail with xHCI. Alan Stern -- 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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
On 15-04-14 07:21 AM, Kishon Vijay Abraham I wrote: Hi, On Tuesday 14 April 2015 06:57 PM, Greg Kroah-Hartman wrote: On Tue, Apr 14, 2015 at 03:17:30PM +0200, Arnd Bergmann wrote: On Tuesday 14 April 2015 14:37:37 Greg Kroah-Hartman wrote: On Tue, Apr 14, 2015 at 01:33:08PM +0200, Arnd Bergmann wrote: This is true, but all other drivers do the same for GENERIC_PHY at the moment. If this one gets changed, we should probably apply the same solution to all current users and fix them consistently. We can do one of these two: a) make sure that the framework has 'static inline' stubs that let you build all drivers using it when the framework itself is disabled. Yes, please do that. b) change the drivers using it to 'depends on', and make GENERIC_PHY itself a hidden option without a Kconfig prompt. Then how could GENERIC_PHY ever get set? Right now, every driver that provides a phy uses 'select GENERIC_PHY', and they would have to keep doing that. This is not unlike what we do for other silent symbols like MFD_CORE, REGMAP_I2C, or PINCTRL, and it's not as problematic as 'select' on a user-visible option, or (worst) mixing 'select' and 'depends on'. Ok, that would make more sense, but it would be good for the PHY maintainer to agree to it as well :) looking at [1], we should use select only for non-visible symbols and for symbols with no dependencies. As such GENERIC_PHY is not dependent on other symbols but for now it is visible. phy-core has all the stubs already implemented in include/linux/phy/phy.h. So removing select GENERIC_PHY shouldn't be a problem. But then it might break a few platforms where GENERIC_PHY is indirectly enabled by selecting the config of the driver (using default defconfigs in arch/arm/configs). The simplest thing would be to make GENERIC_PHY an invisible option? [1] - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/kconfig-language.txt#n111 Kishon,removing select GENERIC_PHY also breaks the builds for certain architectures (i386 and x84_64). Is the consensus to leave the select but make GENERIC_PHY a invisible option? Thanks Thanks Kishon -- 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: OTG EH test driver
Hi, (always Cc linux-usb) On Mon, Apr 13, 2015 at 11:23:28PM -0500, Linux mail wrote: Hi Felipe, Do you know why this patch is not in the mainline. It seems the ehset.c mainline implementation is not passing the Suspend/Resume test. which patch ? -- balbi signature.asc Description: Digital signature
Re: SanDisk Ultra Fit (32 GB version) unbbotable
On Tue, 14 Apr 2015, frederik.hofe wrote: SanDisk Ultra Fit (32 GB version) USB 3.0 Flash Drive I have this USB stick that works fine when using it with win7 or Linux. But if I try to boot linux from it (Be it a installation image or xubuntu installed on it from another usb stick) then I get errors and the stick gets unresponsive until the machine is hardreseted or the Flash Drive pullet out and in again. I have two machines and it happens on both. -Acer Aspire One (Netbook with usb 2.0) -ASRock Z87 Pro3 + 4670k (this has usb 3.0) Here the output on the Acer Aspire One. Kernel Version on the Xubuntu 14.10 installer image is 3.16.0-23-generic Durring booting there is a ~14 Sec. pause and then I get this kernel errors: usb 1-1: device descriptor read/64, error -110 usb 1-1: device descriptor read/64, error -71 usb 1-1: new high-speed USB device number 3 using ehci-pci usb 1-1: device descriptor read/64, error -71 usb 1-1: device descriptor read/64, error -71 usb 1-1: new high-speed USB device number 4 using ehci-pci usb 1-1: device not accepting address 4, error -71 usb 1-1: new high-speed USB device number 5 using ehci-pci usb 1-1: device not accepting address 5, error -71 usb usb1-port1: unable to enumerate USB device What happens if you unplug the flash drive just after the kernel and initramfs image have been loaded, while the kernel is still initializing? You could then plug it back in while the kernel is searching for the root device. Alan Stern -- 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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
My apologies Alan, I missed that comment I was indeed trying to avoid the 80 column rule. It looks like i will have to resend this patch, so i will reformat the code then. Thanks On 15-04-14 07:41 AM, Alan Stern wrote: On Mon, 13 Apr 2015, Arun Ramamurthy wrote: Getting phys by index instead of phy names so that we do not have to create a naming scheme when multiple phys are present Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Reviewed-by: Ray Jui r...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com You have not responded to the comments I posted earlier: http://marc.info/?l=linux-usbm=142798455925594w=2 Alan Stern -- 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: Bug: Toggling green led on Olinuxino Maxi, also toggles USB
Hi Fabio, Fabio Estevam feste...@gmail.com hat am 14. April 2015 um 16:15 geschrieben: Hi Stefan, On Tue, Apr 14, 2015 at 5:43 AM, Peter Chen peter.c...@freescale.com wrote: So setting dr_mode to host is the one and only solution for this case? From my point, yes. I also agree this could be a good solution. Care to submit a patch with this fix? i will send patch. Since all iMX233-Olinuxino variants have only USB hosts it would be easy. Thanks, Fabio Estevam ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Stefan -- 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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
On Mon, 13 Apr 2015, Arun Ramamurthy wrote: Getting phys by index instead of phy names so that we do not have to create a naming scheme when multiple phys are present Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Reviewed-by: Ray Jui r...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com You have not responded to the comments I posted earlier: http://marc.info/?l=linux-usbm=142798455925594w=2 Alan Stern -- 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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
Hi Arnd, On Tuesday 14 April 2015 06:47 PM, Arnd Bergmann wrote: On Tuesday 14 April 2015 14:37:37 Greg Kroah-Hartman wrote: On Tue, Apr 14, 2015 at 01:33:08PM +0200, Arnd Bergmann wrote: This is true, but all other drivers do the same for GENERIC_PHY at the moment. If this one gets changed, we should probably apply the same solution to all current users and fix them consistently. We can do one of these two: a) make sure that the framework has 'static inline' stubs that let you build all drivers using it when the framework itself is disabled. Yes, please do that. b) change the drivers using it to 'depends on', and make GENERIC_PHY itself a hidden option without a Kconfig prompt. Then how could GENERIC_PHY ever get set? Right now, every driver that provides a phy uses 'select GENERIC_PHY', and they would have to keep doing that. This is not unlike what we do for other silent symbols like MFD_CORE, REGMAP_I2C, or PINCTRL, and it's not as problematic as 'select' on a user-visible option, or (worst) mixing 'select' and 'depends on'. Sorry, didn't get how GENERIC_PHY could be set with option 'b'. Thanks Kishon -- 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: Mouse works with eHCI, fails with xHCI - can't set config #1, error -110
On Tue, 14 Apr 2015, Alistair Grant wrote: Hi Mathias and Alan, As Mathias requested, I've included the usbmon output with the patch applied. It didn't make any difference to the end result, the mouse still fails to initialise correctly (no real surprise, I think), but is getting the same string that Alan reported earlier (Laser 0). I've also included the relevant lines from syslog below. (I also have a pcap file captured with tshark if anyone is interested). As always, thanks for your help, Alistair usbmon output: ... 880024c51b40 591168422 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 880024c51b40 591169070 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030 880024c51b40 591169098 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 880024c51b40 591169854 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030 880024c51b40 591169884 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 880024c51b40 591170684 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030 880024c51b40 591170702 S Ci:1:006:0 s 80 06 0302 0409 0002 2 880024c51b40 591171025 C Ci:1:006:0 0 2 = 1803 880024c51b40 591171037 S Ci:1:006:0 s 80 06 0302 0409 0018 24 880024c51b40 591171668 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030 880024c51b40 591171679 S Ci:1:006:0 s 80 06 0302 0409 0018 24 880024c51b40 591172455 C Ci:1:006:0 -32 15 = 18034c00 61007300 65007200 200030 880024c51b40 591172466 S Ci:1:006:0 s 80 06 0302 0409 0018 24 880024c51b40 596169148 C Ci:1:006:0 -2 0 This is practically identical to the EHCI trace from before, right up to the point where the mouse's firmware crashes. I can't explain the difference in behavior; it must be some very subtle timing-related issue. There doesn't seem to be anything more to try. :-( Alan Stern -- 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: MUSB dual-role on AM335x behaving weirdly
Hi, On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: Hi, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = otg. But since 3.16 it seems to be broken. Still had no time to bisect this. I've been giving a few versions (from v3.15 to Tuesday's linux-next) a try, and I always see the same behaviour now: - Booting as a gadget (ie, with a USB cable plugged in), and swapping the cable for a (real, this time) USB OTG cable with a USB key never works. When the device is plugged, all I get is [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 278.064748] usb 1-1: device descriptor read/64, error -110 Putting in back in gadget results with a load of continuous: [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active - Booting as a host, or with nothing connected to it actually work, up to a few plug-a-device-then-plug-a-host cycles, where you end up with the following logs when disconnecting the device (somehow, it always happens when it is set in host mode). [ 12.969075] CAUTION: musb: Babble Interrupt Occurred [ 12.974445] CAUTION: musb: Babble Interrupt Occurred [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon) [ 12.988498] usb 1-1: USB disconnect, device number 2 [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble Plugging back our USB cable, with the AM335x acting as a device work once. Then, when it switches to the host mode, we end up with the same scenario than in the coldplug as gadget case: USB read error, before then having all the a_wait_vfall messages. I gave it some more testing these two days, with next-20150410, with pretty much the same results. Dumping the DSPS glue registers doesn't get anywhere, in both cases (booting as peripheral and then switching to host, or booting as host) they are identical. However, the musb registers vary greatly. In the first case, we boot as host, switch to peripheral, and then switch back to host, repeatedly until it fails: http://code.bulix.org/p0d964-88211?raw We can see that while it still works, value comes back to their original state when switching back to host, which makes sense. However, when it fails, some registers are not set back to their initial values, including TxMaxPp, TxCSRp, RxMaxPp, ConfigData, DevCtl, TxFIFOadd and RxFIFOadd. Some registers that were not changing while it was working also now have a different value: TxMaxPp, RxMaxPp, MISC, TxFIFOsz and RxFIFOsz. Starting with the device as peripheral, and then switching to host fails instantly, once again with exotic values for the registers compared to the configuration set whenever the host mode is working: http://code.bulix.org/uo8fmu-88210?raw However, the registers values are quite similar to the one we got previously when the host mode was failing after a while, which might indicate that we end up in the same case somehow. Since I've not been able to find the musb datasheet, I'm unfortunately unable to make any deduction from these besides that something looks fishy. I've also did some runs with the musb glue and core compiled with debug options: Booted as host: http://code.bulix.org/97jz3i-88207?raw Booted as peripheral: http://code.bulix.org/vqdqt6-88208?raw I hope it helps... Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
Hi, On Tuesday 14 April 2015 06:57 PM, Greg Kroah-Hartman wrote: On Tue, Apr 14, 2015 at 03:17:30PM +0200, Arnd Bergmann wrote: On Tuesday 14 April 2015 14:37:37 Greg Kroah-Hartman wrote: On Tue, Apr 14, 2015 at 01:33:08PM +0200, Arnd Bergmann wrote: This is true, but all other drivers do the same for GENERIC_PHY at the moment. If this one gets changed, we should probably apply the same solution to all current users and fix them consistently. We can do one of these two: a) make sure that the framework has 'static inline' stubs that let you build all drivers using it when the framework itself is disabled. Yes, please do that. b) change the drivers using it to 'depends on', and make GENERIC_PHY itself a hidden option without a Kconfig prompt. Then how could GENERIC_PHY ever get set? Right now, every driver that provides a phy uses 'select GENERIC_PHY', and they would have to keep doing that. This is not unlike what we do for other silent symbols like MFD_CORE, REGMAP_I2C, or PINCTRL, and it's not as problematic as 'select' on a user-visible option, or (worst) mixing 'select' and 'depends on'. Ok, that would make more sense, but it would be good for the PHY maintainer to agree to it as well :) looking at [1], we should use select only for non-visible symbols and for symbols with no dependencies. As such GENERIC_PHY is not dependent on other symbols but for now it is visible. phy-core has all the stubs already implemented in include/linux/phy/phy.h. So removing select GENERIC_PHY shouldn't be a problem. But then it might break a few platforms where GENERIC_PHY is indirectly enabled by selecting the config of the driver (using default defconfigs in arch/arm/configs). The simplest thing would be to make GENERIC_PHY an invisible option? [1] - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/kconfig-language.txt#n111 Thanks Kishon -- 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 v3 2/4] extcon: usb-gpio: add support for VBUS detection
On Tue, Apr 14, 2015 at 08:29:34PM +0900, Chanwoo Choi wrote: On 04/14/2015 07:38 PM, Roger Quadros wrote: On 14/04/15 13:31, Chanwoo Choi wrote: On 04/14/2015 07:02 PM, Roger Quadros wrote: Fixed Kishon's id. On 14/04/15 13:01, Roger Quadros wrote: On 10/04/15 12:18, Chanwoo Choi wrote: On 04/10/2015 05:46 PM, Robert Baldyga wrote: On 04/10/2015 10:10 AM, Chanwoo Choi wrote: On 04/10/2015 04:45 PM, Robert Baldyga wrote: On 04/10/2015 09:17 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 06:24 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 11:07 AM, Chanwoo Choi wrote: Hi Robert, On 04/09/2015 04:57 PM, Robert Baldyga wrote: Hi Chanwoo, On 04/09/2015 04:12 AM, Chanwoo Choi wrote: Hi Robert, [snip] But, I have one question about case[3] If id is low and vbus is high, this patch will update the state of both USB and USB-HOST cable as attached state. Is it possible that two different cables (both USB and USB-HOST) are connected to one port simultaneously? It's because state of single USB cable connection cannot be completely described using single extcon cable. USB cable state has two bits (VBUS and ID), so we need to use two cables for single cable connection. We use following convention: cable USB = VBUS cable USB-HOST = !ID. I think that extcon provider driver have to update the only one cable state of either USB or USB-HOST because USB and USB-HOST feature can not be used at the same time through one h/w port. If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable at the same time, the extcon consumer driver can not decide what handle either USB or USB-HOST. It can. USB OTG allows for that. Moreover device can be host even if ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so detected cable type is USB host). Devices would need to have complete information about USB cable connection, because OTG state machine needs As I knew, USB OTG port don't send the attached cable of both USB and USB-HOST at the same time. The case3 in your patch update two cable state about one h/w port. It's because simple USB or USB-HOST means nothing for USB OTG machine. It needs to know exact VBUS and ID states, which cannot be concluded basing on cable type only. That's why I have used USB-HOST name together with USB to pass additional information about USB cable connection. I think this method is not proper to support this case. It may cause the confusion about other case using USB/USB-HOST cable state except of you commented case. That's why I finally proposed to use USB-ID and USB-VBUS in parallel with old names. It seems to be simpler solution than adding new mechanism notifying about VBUS and ID states changes. As I commented on previous reply, I don't agree to use 'USB-ID' and 'USB-VBUS'. If we add new strange 'USB-ID' and 'USB-VBUS' name, we would add non-general cable name continuoulsy. I think that extcon core provide the helper API to get the value of VBUS. But I need to consider it. Now it is starting to look like existing extcon states are not suitable for USB/PHY drivers to deliver VBUS and ID information reliably. This is because based on your comments the USB and USB-HOST states look like some fuzzy states and have no direct correspondence with VBUS and ID. The fact that they can't become attached simultaneously makes me conclude that USB and USB-HOST cable states are really capturing only the ID pin state. I can suggest the following options a) let USB and USB-HOST only indicate ID pin status. Add a new cable state for VBUS notification. Maybe call it USB-POWER or something. We must discuss it before using the new cable name such as USB-POWER, USB-ID and USB-VBUS. I didn't say to add USB-ID or USB-VBUS. solution (a) was to have the following Right. Robert suggested the USB-ID and USB-VBUS cable name on previous mail in mail thread. From USB/USB-PHY driver point, it needs to know id and vbus value for their internal logic, so as extcon users, the cable name is better to reflect meaning of id and vbus, like USB-ID and USB-VBUS, if the power is from vbus pin at USB cable, I don't think we need another cable name USB-POWER even the USB/USB-PHY driver don't need it. USB - attached means ID is high. i.e. Type-B plug attached. USB-HOST - attached means ID is low. i.e. Type-A plug attached. USB-POWER - attached means USB power is present. i.e. VBUS is alive. This way the definition of USB and USB-HOST remain true to their name and avoid further confusions. VBUS state is got through the USB-POWER cable state. There is the same case for MHL cable. Also, MHL cable could be connected to VBUS line. - MHL : attached just MHL cable. - MHL-POWER : attache MHL cable which is
Re: [PATCH] genirq: provide dummy set_irq_wake()
Hi Roger,
On 14/04/2015 12:13, Roger Quadros wrote:
Hi Thomas,
On 30/03/15 16:15, Roger Quadros wrote:
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the dummy irq hook.
(e.g. drivers/gpio/gpio-pcf857x.c)
http://article.gmane.org/gmane.linux.kernel/1879035
Signed-off-by: Roger Quadros rog...@ti.com
Any comments on this patch?
I read the url you pointed and I wonder why, at then end, did
you choose to add a dummy set_irq_wake() instead of using
IRQCHIP_SKIP_SET_WAKE ?
Thanks,
Gregory
cheers,
-roger
---
kernel/irq/dummychip.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 988dc58..2405d7a 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -32,6 +32,11 @@ static unsigned int noop_ret(struct irq_data *data)
return 0;
}
+static int noop_int_ret(struct irq_data *data, unsigned int val)
+{
+return 0;
+}
+
/*
* Generic no controller implementation
*/
@@ -57,5 +62,6 @@ struct irq_chip dummy_irq_chip = {
.irq_ack= noop,
.irq_mask = noop,
.irq_unmask = noop,
+.irq_set_wake = noop_int_ret,
};
EXPORT_SYMBOL_GPL(dummy_irq_chip);
--
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
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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: SanDisk Ultra Fit (32 GB version) unbbotable
On Tue, Apr 14, 2015 at 01:46:56AM +0200, frederik.hofe wrote: SanDisk Ultra Fit (32 GB version) USB 3.0 Flash Drive I have this USB stick that works fine when using it with win7 or Linux. But if I try to boot linux from it (Be it a installation image or xubuntu installed on it from another usb stick) then I get errors and the stick gets unresponsive until the machine is hardreseted or the Flash Drive pullet out and in again. I have two machines and it happens on both. -Acer Aspire One (Netbook with usb 2.0) -ASRock Z87 Pro3 + 4670k (this has usb 3.0) Here the output on the Acer Aspire One. Kernel Version on the Xubuntu 14.10 installer image is 3.16.0-23-generic That's a really old kernel version, please ask for help on the ubuntu mailing lists / bugzilla for stuff like this. good luck, greg k-h -- 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: Bug: Toggling green led on Olinuxino Maxi, also toggles USB
Hi Stefan, On Tue, Apr 14, 2015 at 5:43 AM, Peter Chen peter.c...@freescale.com wrote: So setting dr_mode to host is the one and only solution for this case? From my point, yes. I also agree this could be a good solution. Care to submit a patch with this fix? Thanks, Fabio Estevam -- 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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
On Tuesday 14 April 2015 11:05:35 Arun Ramamurthy wrote: [1] - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/kconfig-language.txt#n111 Kishon,removing select GENERIC_PHY also breaks the builds for certain architectures (i386 and x84_64). Is the consensus to leave the select but make GENERIC_PHY a invisible option? Thanks I think the best solution is - make GENERIC_PHY a silent option - change PHY_RCAR_GEN2 to use 'select' instead of 'depends on', so it will still work when all other phy drivers are disabled - change the non-phy drivers that select GENERIC_PHY to either use 'depends on' or no explicit dependency in case they are still functional without the API. Note that drivers/pinctrl/pinctrl-tegra-xusb.c is a phy provider as well, not a consumer, despite being outside of drivers/phy. Arnd -- 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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
On Tuesday 14 April 2015 14:37:37 Greg Kroah-Hartman wrote: On Tue, Apr 14, 2015 at 01:33:08PM +0200, Arnd Bergmann wrote: This is true, but all other drivers do the same for GENERIC_PHY at the moment. If this one gets changed, we should probably apply the same solution to all current users and fix them consistently. We can do one of these two: a) make sure that the framework has 'static inline' stubs that let you build all drivers using it when the framework itself is disabled. Yes, please do that. b) change the drivers using it to 'depends on', and make GENERIC_PHY itself a hidden option without a Kconfig prompt. Then how could GENERIC_PHY ever get set? Right now, every driver that provides a phy uses 'select GENERIC_PHY', and they would have to keep doing that. This is not unlike what we do for other silent symbols like MFD_CORE, REGMAP_I2C, or PINCTRL, and it's not as problematic as 'select' on a user-visible option, or (worst) mixing 'select' and 'depends on'. Arnd -- 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: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
On Tue, Apr 14, 2015 at 01:33:08PM +0200, Arnd Bergmann wrote: On Tuesday 14 April 2015 13:19:34 Greg Kroah-Hartman wrote: On Mon, Apr 13, 2015 at 03:10:46PM -0700, Arun Ramamurthy wrote: Getting phys by index instead of phy names so that we do not have to create a naming scheme when multiple phys are present Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com Reviewed-by: Ray Jui r...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com --- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-platform.c | 70 ++-- 2 files changed, 26 insertions(+), 45 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 5ad60e4..563f22d 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -284,6 +284,7 @@ config USB_EHCI_ATH79 config USB_EHCI_HCD_PLATFORM tristate Generic EHCI driver for a platform device + select GENERIC_PHY Configs should never select if at all possible. This is true, but all other drivers do the same for GENERIC_PHY at the moment. If this one gets changed, we should probably apply the same solution to all current users and fix them consistently. We can do one of these two: a) make sure that the framework has 'static inline' stubs that let you build all drivers using it when the framework itself is disabled. Yes, please do that. b) change the drivers using it to 'depends on', and make GENERIC_PHY itself a hidden option without a Kconfig prompt. Then how could GENERIC_PHY ever get set? Either solution is probably simple enough that it can be done as part of this series. That's fine with me, but please no more selects. thanks, greg k-h -- 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] ff-core: use new debug macros
On Tue, Apr 14, 2015 at 02:06:10PM +0200, Oliver Neukum wrote:
Replace old pr_* with dev_* debugging macros
Not so new anymore ;)
Applied, thank you.
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/input/ff-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/input/ff-core.c b/drivers/input/ff-core.c
index f50f6dd..b81c88c 100644
--- a/drivers/input/ff-core.c
+++ b/drivers/input/ff-core.c
@@ -23,8 +23,6 @@
/* #define DEBUG */
-#define pr_fmt(fmt) KBUILD_BASENAME : fmt
-
#include linux/input.h
#include linux/module.h
#include linux/mutex.h
@@ -116,7 +114,7 @@ int input_ff_upload(struct input_dev *dev, struct
ff_effect *effect,
if (effect-type FF_EFFECT_MIN || effect-type FF_EFFECT_MAX ||
!test_bit(effect-type, dev-ffbit)) {
- pr_debug(invalid or not supported effect type in upload\n);
+ dev_dbg(dev-dev, invalid or not supported effect type in
upload\n);
return -EINVAL;
}
@@ -124,7 +122,7 @@ int input_ff_upload(struct input_dev *dev, struct
ff_effect *effect,
(effect-u.periodic.waveform FF_WAVEFORM_MIN ||
effect-u.periodic.waveform FF_WAVEFORM_MAX ||
!test_bit(effect-u.periodic.waveform, dev-ffbit))) {
- pr_debug(invalid or not supported wave form in upload\n);
+ dev_dbg(dev-dev, invalid or not supported wave form in
upload\n);
return -EINVAL;
}
@@ -246,7 +244,7 @@ static int flush_effects(struct input_dev *dev, struct
file *file)
struct ff_device *ff = dev-ff;
int i;
- pr_debug(flushing now\n);
+ dev_dbg(dev-dev, flushing now\n);
mutex_lock(ff-mutex);
@@ -316,7 +314,7 @@ int input_ff_create(struct input_dev *dev, unsigned int
max_effects)
int i;
if (!max_effects) {
- pr_err(cannot allocate device without any effects\n);
+ dev_err(dev-dev, cannot allocate device without any
effects\n);
return -EINVAL;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dmitry
--
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
