Re: xhci_hcd crash on linux 4.7.0
Hi, (please avoid top-posting, see: http://daringfireball.net/2007/07/on_top) Alex Damian writes: > Forgot to mention, I just reproduced it on the mainline 4.8.1 kernel. > > On Wed, Oct 12, 2016 at 5:13 PM, Alex Damian wrote: >> Hello, >> >> To follow up on the original bug report. I am still experiencing >> memory corruption problems in the xhci stack. >> >> One thing I noticed is that the corruption always occur on a secondary >> CPU (ie. the stack trace starts on cpu_startup_entry) and it is always >> going on when trying to handle an intrerrupt. >> >> Seems to me that a mutex or something similar is not correctly locked, >> but I don't have any experience with the code around this part, so I >> have no idea where to look. >> >> Pointers, ideas, suggestions ? How about we start with Mathias' suggestion to enable xhci debugging messages? Quoting it again here: >>> Enabling xhci debug could reveal something. >>> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control (keeping context below) >> On Thu, Aug 25, 2016 at 2:22 PM, Mathias Nyman >> wrote: >>> On 29.07.2016 17:41, Alex Damian wrote: On Fri, Jul 29, 2016 at 2:53 PM, Greg KH wrote: > > On Fri, Jul 29, 2016 at 10:58:03AM +0100, Alex Damian wrote: >> >> Hi Greg, >> >> I managed to reproduce with a untainted kernel, see dmesg paste below. >> The stack seemed corrupted as well ? >> >> I refered to it as a crash since after a couple of these issues, the >> machine hard freezes - I set up a serial console via a USB cable, but >> I don't get the kernel oops out of the machine. The network is also >> dead before getting any data. I could not think of any other way to >> get a console out of a Macbook - any ideas ? >> >> There is a progressive level of deterioration going on below, this is >> why I'm adding multiple pastes. See the obviously invalid pointer >> 0001 in 3rd paste below. Also, see the protection fault in >> the last paste. To me, something is trampling all over memory, and it >> is usb-related. > > > Not good, thanks for reproducing it without the closed kernel drivers. > > If you disable the list debug kernel option, do you have any problems > with the machine? We aren't having any other reports of issues like > this at the moment, which makes me worry that it's something unique to > your situation/hardware. I strongly suspect it's related to the macbook 12,1 hardware. I haven't been able to reproduce this with other machines, including other macbook versions with the same peripherals. This machine has never been stable in this particular peripheral configuration. I had Apple run all HW diagnostics on the machine, I ran the memcheck to verify that the RAM is ok - all results are clean. The machine is very stable under Mac OSX. > And you don't know that it's a USB problem, only that USB is the one > that is showing the issue. Anyone could be writing over memory. True. However it seems particularly related to the USB mouse - that's how I manage to reproduce the error. > > Also, any chance you can use 'git bisect' to track down an offending > commit? I'm assuming that this used to work properly and something > recently caused the issue, correct? The earliest kernels I've tested are in the 3.3 range. All kernels before 4.7 just lock up. 4.7 is the first kernel where I have meaningful dmesg errors before locking up. As such, there is very little that I can do to bisect :(. >>> >>> Going through xhci related issues that occurred during my vacation. >>> >>> There is one command list related issue fixed in 4.8-rc3, any chance you >>> could try it? >>> Alternatively just add the following patch added to 4.7: >>> 33be126 xhci: always handle "Command Ring Stopped" events >>> >>> Enabling xhci debug could reveal something. >>> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control >>> >>> -Mathias >>> > -- > 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 -- balbi signature.asc Description: PGP signature
Re: Interactive whiteboards
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Oct 13, 2016 at 07:37:33AM +0200, María Cano wrote: > Thanks for your interest in this matter. > If it's ok, I will update in this document collected related > information about interactive whiteboards: > > https://docs.google.com/document/d/18028I8M8el_iJGb3hk3WDxQ8m642Li_yeLeuwD1lL1E/edit?usp=sharing No, please post it here so that _everyone_ can review it and work on it. Putting it at some random url isn't going to help us out. 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: Interactive whiteboards
Thanks for your interest in this matter. If it's ok, I will update in this document collected related information about interactive whiteboards: https://docs.google.com/document/d/18028I8M8el_iJGb3hk3WDxQ8m642Li_yeLeuwD1lL1E/edit?usp=sharing 2016-10-11 8:49 GMT+02:00 Greg KH : > On Mon, Oct 10, 2016 at 10:54:07PM +0200, María Cano wrote: >> The Linux kernel supports many devices and each day more and more are >> included, but there is a device that looks completely abandoned: >> whiteboards. In my immediate environment a lot of interactive >> whiteboards do not work under linux. Except some Smartboards, all >> other lack support (Multiclass, Promethean, eBeam, iQBoard, Hitachi >> Starboard, etc...). If you're lucky the manufacturer takes some sort >> of proprietary module for a specific kernel version and does not >> update more, leaving it :-( >> Please, could someone get their hands on this? I do not know >> programming in C, but I'm experienced linux user and I have at my >> disposal a large number of interactive whiteboards of many different >> brands to test, give information and try anything. > > I thought these were "just" HID devices? What does the output of > cat /sys/kernel/debug/usb/devices > say with the devices plugged in? > > 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
[PATCH v12 6/9] usbip: exporting devices: modifications to attach and detach
Refactoring to attach and detatch operation. Common parts to new
application(vhci)-side daemon are moved to libsrc/vhci_driver.c.
Signed-off-by: Nobuo Iwata
---
tools/usb/usbip/libsrc/vhci_driver.c | 99
tools/usb/usbip/libsrc/vhci_driver.h | 6 +-
tools/usb/usbip/src/usbip_attach.c | 50 ++
tools/usb/usbip/src/usbip_detach.c | 13 ++--
4 files changed, 100 insertions(+), 68 deletions(-)
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c
b/tools/usb/usbip/libsrc/vhci_driver.c
index ad92047..d2221c5 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
#include
#include
+#include
+#include
#include "sysfs_utils.h"
#undef PROGNAME
@@ -215,6 +218,25 @@ static int read_record(int rhport, char *host, unsigned
long host_len,
return 0;
}
+#define OPEN_HC_MODE_FIRST 0
+#define OPEN_HC_MODE_REOPEN1
+
+static int open_hc_device(int mode)
+{
+ if (mode == OPEN_HC_MODE_REOPEN)
+ udev_device_unref(vhci_driver->hc_device);
+
+ vhci_driver->hc_device =
+ udev_device_new_from_subsystem_sysname(udev_context,
+ USBIP_VHCI_BUS_TYPE,
+ USBIP_VHCI_DRV_NAME);
+ if (!vhci_driver->hc_device) {
+ err("udev_device_new_from_subsystem_sysname failed");
+ return -1;
+ }
+ return 0;
+}
+
/* -- */
int usbip_vhci_driver_open(void)
@@ -227,28 +249,21 @@ int usbip_vhci_driver_open(void)
vhci_driver = calloc(1, sizeof(struct usbip_vhci_driver));
- /* will be freed in usbip_driver_close() */
- vhci_driver->hc_device =
- udev_device_new_from_subsystem_sysname(udev_context,
- USBIP_VHCI_BUS_TYPE,
- USBIP_VHCI_DRV_NAME);
- if (!vhci_driver->hc_device) {
- err("udev_device_new_from_subsystem_sysname failed");
- goto err;
- }
+ if (open_hc_device(OPEN_HC_MODE_FIRST))
+ goto err_free_driver;
vhci_driver->nports = get_nports();
dbg("available ports: %d", vhci_driver->nports);
if (refresh_imported_device_list())
- goto err;
+ goto err_unref_device;
return 0;
-err:
+err_unref_device:
udev_device_unref(vhci_driver->hc_device);
-
+err_free_driver:
if (vhci_driver)
free(vhci_driver);
@@ -277,7 +292,8 @@ void usbip_vhci_driver_close(void)
int usbip_vhci_refresh_device_list(void)
{
-
+ if (open_hc_device(OPEN_HC_MODE_REOPEN))
+ goto err;
if (refresh_imported_device_list())
goto err;
@@ -409,3 +425,58 @@ int usbip_vhci_imported_device_dump(struct
usbip_imported_device *idev)
return 0;
}
+
+#define MAX_BUFF 100
+int usbip_vhci_create_record(char *host, char *port, char *busid, int rhport)
+{
+ int fd;
+ char path[PATH_MAX+1];
+ char buff[MAX_BUFF+1];
+ int ret;
+
+ ret = mkdir(VHCI_STATE_PATH, 0700);
+ if (ret < 0) {
+ /* if VHCI_STATE_PATH exists, then it better be a directory */
+ if (errno == EEXIST) {
+ struct stat s;
+
+ ret = stat(VHCI_STATE_PATH, &s);
+ if (ret < 0)
+ return -1;
+ if (!(s.st_mode & S_IFDIR))
+ return -1;
+ } else
+ return -1;
+ }
+
+ snprintf(path, PATH_MAX, VHCI_STATE_PATH"/port%d", rhport);
+
+ fd = open(path, O_WRONLY|O_CREAT|O_TRUNC, 0700);
+ if (fd < 0)
+ return -1;
+
+ snprintf(buff, MAX_BUFF, "%s %s %s\n",
+ host, port, busid);
+
+ ret = write(fd, buff, strlen(buff));
+ if (ret != (ssize_t) strlen(buff)) {
+ close(fd);
+ return -1;
+ }
+
+ close(fd);
+
+ return 0;
+}
+
+int usbip_vhci_delete_record(int rhport)
+{
+ char path[PATH_MAX+1];
+
+ snprintf(path, PATH_MAX, VHCI_STATE_PATH"/port%d", rhport);
+
+ remove(path);
+ rmdir(VHCI_STATE_PATH);
+
+ return 0;
+}
diff --git a/tools/usb/usbip/libsrc/vhci_driver.h
b/tools/usb/usbip/libsrc/vhci_driver.h
index fa2316c..f955ada 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.h
+++ b/tools/usb/usbip/libsrc/vhci_driver.h
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2005-2007 Takahiro Hirofuchi
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2005-
[PATCH v12 8/9] usbip: exporting devices: change to usbip_list.c
Correction to wording inconsistency around import and export in
usbip_list.c.
Please, see also cover letter about wording.
Signed-off-by: Nobuo Iwata
---
tools/usb/usbip/src/usbip_list.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/tools/usb/usbip/src/usbip_list.c b/tools/usb/usbip/src/usbip_list.c
index f1b38e8..37f9afa 100644
--- a/tools/usb/usbip/src/usbip_list.c
+++ b/tools/usb/usbip/src/usbip_list.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2011 matt mooney
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2011 matt mooney
* 2005-2007 Takahiro Hirofuchi
* Copyright (C) 2015-2016 Samsung Electronics
* Igor Kotrasinski
@@ -42,9 +43,9 @@
#include "usbip.h"
static const char usbip_list_usage_string[] =
- "usbip list [-p|--parsable] \n"
+ "usbip list \n"
"-p, --parsable Parsable list format\n"
- "-r, --remote=List the exportable USB devices on \n"
+ "-r, --remote=List the importable USB devices on \n"
"-l, --localList the local USB devices\n";
void usbip_list_usage(void)
@@ -52,7 +53,7 @@ void usbip_list_usage(void)
printf("usage: %s", usbip_list_usage_string);
}
-static int get_exported_devices(char *host, int sockfd)
+static int get_importable_devices(char *host, int sockfd)
{
char product_name[100];
char class_name[100];
@@ -82,14 +83,14 @@ static int get_exported_devices(char *host, int sockfd)
return -1;
}
PACK_OP_DEVLIST_REPLY(0, &reply);
- dbg("exportable devices: %d\n", reply.ndev);
+ dbg("importable devices: %d\n", reply.ndev);
if (reply.ndev == 0) {
- info("no exportable devices found on %s", host);
+ info("no importable devices found on %s", host);
return 0;
}
- printf("Exportable USB devices\n");
+ printf("Importable USB devices\n");
printf("==\n");
printf(" - %s\n", host);
@@ -134,7 +135,7 @@ static int get_exported_devices(char *host, int sockfd)
return 0;
}
-static int list_exported_devices(char *host)
+static int list_importable_devices(char *host)
{
int rc;
int sockfd;
@@ -147,9 +148,10 @@ static int list_exported_devices(char *host)
}
dbg("connected to %s:%s", host, usbip_port_string);
- rc = get_exported_devices(host, sockfd);
+ rc = get_importable_devices(host, sockfd);
if (rc < 0) {
err("failed to get device list from %s", host);
+ close(sockfd);
return -1;
}
@@ -351,7 +353,7 @@ int usbip_list(int argc, char *argv[])
parsable = true;
break;
case 'r':
- ret = list_exported_devices(optarg);
+ ret = list_importable_devices(optarg);
goto out;
case 'l':
ret = list_devices(parsable);
--
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 v12 9/9] usbip: exporting devices: chage to documenattion
This patch adds function and usage of new connect operation, disconnect operation and application(vhci)-side daemon to README and manuals. At this point, the wording, 'server' and 'client' are ambiguous in several place. 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 (machine)' and 'application side (machine)' are used instead of 'client' and 'server' as needed. Please, see also diagrams in the cover letter. Signed-off-by: Nobuo Iwata --- tools/usb/usbip/Makefile.am | 2 +- tools/usb/usbip/README | 70 -- tools/usb/usbip/doc/usbip.8 | 136 --- tools/usb/usbip/doc/usbipa.8 | 78 tools/usb/usbip/doc/usbipd.8 | 38 +- 5 files changed, 263 insertions(+), 61 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 +# Copyright (C) 2015 Nobuo Iwata +# 2011 matt mooney # 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 + - Bind usbip-host.ko to the device with . + - The USB device with is now exportable to other hosts! + - Use `usbip unbind --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 +app:# usbip list --remote - List exported USB devices on the . -client:# usbip attach --remote --busid 1-2 +app:# usbip attach --remote --busid - Connect the remote USB device. -client:# usbip port +app:# usbip port - Show virtual port status. -client:# usbip detach --port +app:# usbip detach --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 --busid + - Bind usbip-host.ko to the device with . + - The USB device of is connected to remote host! + +dev:# usbip disconnect --remote --busid + - The USB device with 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 att
[PATCH v12 4/9] usbip: exporting devices: new disconnect operation
New disconnect operation.
Signed-off-by: Nobuo Iwata
---
tools/usb/usbip/src/Makefile.am| 2 +-
tools/usb/usbip/src/usbip.c| 6 +
tools/usb/usbip/src/usbip.h| 2 +
tools/usb/usbip/src/usbip_disconnect.c | 215 +
4 files changed, 224 insertions(+), 1 deletion(-)
diff --git a/tools/usb/usbip/src/Makefile.am b/tools/usb/usbip/src/Makefile.am
index 0947476..42760c3 100644
--- a/tools/usb/usbip/src/Makefile.am
+++ b/tools/usb/usbip/src/Makefile.am
@@ -7,6 +7,6 @@ sbin_PROGRAMS := usbip usbipd
usbip_SOURCES := usbip.h utils.h usbip.c 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_connect.c usbip_disconnect.c
usbipd_SOURCES := usbip_network.h usbipd.c usbip_network.c
diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
index 584d7d5..f0e9e06 100644
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -83,6 +83,12 @@ static const struct command cmds[] = {
.usage = usbip_connect_usage
},
{
+ .name = "disconnect",
+ .fn= usbip_disconnect,
+ .help = "Disconnect a USB device from a remote computer",
+ .usage = usbip_disconnect_usage
+ },
+ {
.name = "list",
.fn= usbip_list,
.help = "List exportable or local USB devices",
diff --git a/tools/usb/usbip/src/usbip.h b/tools/usb/usbip/src/usbip.h
index f365353..a8cbd16 100644
--- a/tools/usb/usbip/src/usbip.h
+++ b/tools/usb/usbip/src/usbip.h
@@ -32,6 +32,7 @@ int usbip_bind(int argc, char *argv[]);
int usbip_unbind(int argc, char *argv[]);
int usbip_port_show(int argc, char *argv[]);
int usbip_connect(int argc, char *argv[]);
+int usbip_disconnect(int argc, char *argv[]);
void usbip_attach_usage(void);
void usbip_detach_usage(void);
@@ -39,6 +40,7 @@ void usbip_list_usage(void);
void usbip_bind_usage(void);
void usbip_unbind_usage(void);
void usbip_connect_usage(void);
+void usbip_disconnect_usage(void);
int usbip_bind_device(char *busid);
int usbip_unbind_device(char *busid);
diff --git a/tools/usb/usbip/src/usbip_disconnect.c
b/tools/usb/usbip/src/usbip_disconnect.c
new file mode 100644
index 000..8155384
--- /dev/null
+++ b/tools/usb/usbip/src/usbip_disconnect.c
@@ -0,0 +1,215 @@
+/*
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2011 matt mooney
+ * 2005-2007 Takahiro Hirofuchi
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH v12 7/9] usbip: exporting devices: new application-side daemon
New application(vhci)-side daemon.
Signed-off-by: Nobuo Iwata
---
tools/usb/usbip/libsrc/vhci_driver.c | 19 +++
tools/usb/usbip/libsrc/vhci_driver.h | 1 +
tools/usb/usbip/src/Makefile.am | 7 +-
tools/usb/usbip/src/usbipd.c | 12 +-
tools/usb/usbip/src/usbipd_app.c | 242 +++
5 files changed, 279 insertions(+), 2 deletions(-)
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c
b/tools/usb/usbip/libsrc/vhci_driver.c
index d2221c5..3fe92ff 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -314,6 +314,25 @@ int usbip_vhci_get_free_port(void)
return -1;
}
+struct usbip_imported_device *usbip_vhci_find_device(char *host, char *busid)
+{
+ int ret;
+ char rhost[NI_MAXHOST] = "unknown host";
+ char rserv[NI_MAXSERV] = "unknown port";
+ char rbusid[SYSFS_BUS_ID_SIZE];
+
+ for (int i = 0; i < vhci_driver->nports; i++) {
+ ret = read_record(vhci_driver->idev[i].port, rhost, NI_MAXHOST,
+ rserv, NI_MAXSERV, rbusid);
+ if (!ret &&
+ !strncmp(host, rhost, NI_MAXHOST) &&
+ !strncmp(busid, rbusid, SYSFS_BUS_ID_SIZE)) {
+ return vhci_driver->idev + i;
+ }
+ }
+ return NULL;
+}
+
int usbip_vhci_attach_device2(uint8_t port, int sockfd, uint32_t devid,
uint32_t speed) {
char buff[200]; /* what size should be ? */
diff --git a/tools/usb/usbip/libsrc/vhci_driver.h
b/tools/usb/usbip/libsrc/vhci_driver.h
index f955ada..acb427d 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.h
+++ b/tools/usb/usbip/libsrc/vhci_driver.h
@@ -46,6 +46,7 @@ int usbip_vhci_refresh_device_list(void);
int usbip_vhci_get_free_port(void);
+struct usbip_imported_device *usbip_vhci_find_device(char *host, char *busid);
int usbip_vhci_attach_device2(uint8_t port, int sockfd, uint32_t devid,
uint32_t speed);
diff --git a/tools/usb/usbip/src/Makefile.am b/tools/usb/usbip/src/Makefile.am
index 1aa5156..8fdebce 100644
--- a/tools/usb/usbip/src/Makefile.am
+++ b/tools/usb/usbip/src/Makefile.am
@@ -2,11 +2,16 @@ AM_CPPFLAGS = -I$(top_srcdir)/libsrc
-DUSBIDS_FILE='"@USBIDS_DIR@/usb.ids"'
AM_CFLAGS = @EXTRA_CFLAGS@
LDADD = $(top_builddir)/libsrc/libusbip.la
-sbin_PROGRAMS := usbip usbipd
+sbin_PROGRAMS := usbip usbipd usbipa
usbip_SOURCES := usbip.h utils.h usbip.c 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
+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) -DUSBIP_DAEMON_APP
diff --git a/tools/usb/usbip/src/usbipd.c b/tools/usb/usbip/src/usbipd.c
index 4b15bb1..5f6b040 100644
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -64,11 +64,13 @@ static const char usbipd_help_string[] =
" -6, --ipv6\n"
" Bind to IPv6. Default is both.\n"
"\n"
+#ifndef USBIP_DAEMON_APP
" -e, --device\n"
" Run in device mode.\n"
" Rather than drive an attached device, create\n"
" a virtual UDC to bind gadgets to.\n"
"\n"
+#endif
" -D, --daemon\n"
" Run as a daemon process.\n"
"\n"
@@ -404,7 +406,9 @@ int main(int argc, char *argv[])
{ "ipv6", no_argument, NULL, '6' },
{ "daemon", no_argument, NULL, 'D' },
{ "debug",no_argument, NULL, 'd' },
+#ifndef USBIP_DAEMON_APP
{ "device", no_argument, NULL, 'e' },
+#endif
{ "pid", optional_argument, NULL, 'P' },
{ "tcp-port", required_argument, NULL, 't' },
{ "help", no_argument, NULL, 'h' },
@@ -433,7 +437,11 @@ int main(int argc, char *argv[])
cmd = cmd_standalone_mode;
usbip_init_driver();
for (;;) {
- opt = getopt_long(argc, argv, "46DdeP::t:hv", longopts, NULL);
+ opt = getopt_long(argc, argv, "46Dd"
+#ifndef USBIP_DAEMON_APP
+ "e"
+#endif
+ "P::t:hv", longopts, NULL);
if (opt == -1)
break;
@@ -463,9 +471,11 @@ int main(int argc, char *argv[])
case 'v':
cmd = cmd_version;
break;
+#ifndef USBIP_DAEMON_APP
case 'e':
usbip_update_driver();
break;
+#endif
case '?':
usbipd_help();
[PATCH v12 5/9] usbip: exporting devices: modifications to daemon
Refactoring to the daemon.
usbipd_dev.c is device-side specific code extracted from usbipd.c.
usbipd.c is left as common parts for both device(stub)-side and
application(vhci)-side daemon.
usbip_net_set_nodelay() is the middle of device side daemon operation
and it does not make mush sence. In the client operation, it's in right
after connect(). So, in daemon, it is moved to right after accept() to
affect it both device and application side.
Signed-off-by: Nobuo Iwata
---
tools/usb/usbip/src/Makefile.am | 2 +-
tools/usb/usbip/src/usbipd.c | 246 --
tools/usb/usbip/src/usbipd.h | 39 +
tools/usb/usbip/src/usbipd_dev.c | 252 +++
4 files changed, 319 insertions(+), 220 deletions(-)
diff --git a/tools/usb/usbip/src/Makefile.am b/tools/usb/usbip/src/Makefile.am
index 42760c3..1aa5156 100644
--- a/tools/usb/usbip/src/Makefile.am
+++ b/tools/usb/usbip/src/Makefile.am
@@ -9,4 +9,4 @@ usbip_SOURCES := usbip.h utils.h usbip.c utils.c
usbip_network.c \
usbip_bind.c usbip_unbind.c usbip_port.c \
usbip_connect.c usbip_disconnect.c
-usbipd_SOURCES := usbip_network.h usbipd.c usbip_network.c
+usbipd_SOURCES := usbip_network.h usbipd.c usbipd_dev.c usbip_network.c
diff --git a/tools/usb/usbip/src/usbipd.c b/tools/usb/usbip/src/usbipd.c
index a0972de..4b15bb1 100644
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2011 matt mooney
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2011 matt mooney
* 2005-2007 Takahiro Hirofuchi
* Copyright (C) 2015-2016 Samsung Electronics
* Igor Kotrasinski
@@ -43,25 +44,19 @@
#include
#include
-#include "usbip_host_driver.h"
-#include "usbip_host_common.h"
-#include "usbip_device_driver.h"
#include "usbip_common.h"
#include "usbip_network.h"
+#include "usbipd.h"
#include "list.h"
-#undef PROGNAME
-#define PROGNAME "usbipd"
#define MAXSOCKFD 20
#define MAIN_LOOP_TIMEOUT 10
-#define DEFAULT_PID_FILE "/var/run/" PROGNAME ".pid"
-
static const char usbip_version_string[] = PACKAGE_STRING;
static const char usbipd_help_string[] =
- "usage: usbipd [options]\n"
+ "usage: %s [options]\n"
"\n"
" -4, --ipv4\n"
" Bind to IPv4. Default is both.\n"
@@ -82,7 +77,7 @@ static const char usbipd_help_string[] =
"\n"
" -PFILE, --pid FILE\n"
" Write process id to FILE.\n"
- " If no FILE specified, use " DEFAULT_PID_FILE "\n"
+ " If no FILE specified, use %s.\n"
"\n"
" -tPORT, --tcp-port PORT\n"
" Listen on TCP/IP port PORT.\n"
@@ -93,198 +88,9 @@ static const char usbipd_help_string[] =
" -v, --version\n"
" Show version.\n";
-static struct usbip_host_driver *driver;
-
static void usbipd_help(void)
{
- printf("%s\n", usbipd_help_string);
-}
-
-static int recv_request_import(int sockfd)
-{
- struct op_import_request req;
- struct usbip_exported_device *edev;
- struct usbip_usb_device pdu_udev;
- struct list_head *i;
- int found = 0;
- int error = 0;
- int rc;
-
- memset(&req, 0, sizeof(req));
-
- rc = usbip_net_recv(sockfd, &req, sizeof(req));
- if (rc < 0) {
- dbg("usbip_net_recv failed: import request");
- return -1;
- }
- PACK_OP_IMPORT_REQUEST(0, &req);
-
- list_for_each(i, &driver->edev_list) {
- edev = list_entry(i, struct usbip_exported_device, node);
- if (!strncmp(req.busid, edev->udev.busid, SYSFS_BUS_ID_SIZE)) {
- info("found requested device: %s", req.busid);
- found = 1;
- break;
- }
- }
-
- if (found) {
- /* should set TCP_NODELAY for usbip */
- usbip_net_set_nodelay(sockfd);
-
- /* export device needs a TCP/IP socket descriptor */
- rc = usbip_export_device(edev, sockfd);
- if (rc < 0)
- error = 1;
- } else {
- info("requested device not found: %s", req.busid);
- error = 1;
- }
-
- rc = usbip_net_send_op_common(sockfd, OP_REP_IMPORT,
- (!error ? ST_OK : ST_NA));
- if (rc < 0) {
- dbg("usbip_net_send_op_common failed: %#0x", OP_REP_IMPORT);
- return -1;
- }
-
- if (error) {
- dbg("import request busid %s: failed", req.busid);
- return -1;
- }
-
- memcpy(&pdu_udev, &edev->udev, sizeof(pdu_udev));
- usbip_net_pack_usb_device(1, &pdu_udev);
-
- rc = usbip_net_send(sockfd, &pdu_udev, sizeof(pdu_udev));
- if (rc < 0) {
- dbg("usb
[PATCH v12 3/9] usbip: exporting devices: new connect operation
New connect operation.
Signed-off-by: Nobuo Iwata
---
tools/usb/usbip/src/Makefile.am | 3 +-
tools/usb/usbip/src/usbip.c | 9 +-
tools/usb/usbip/src/usbip.h | 5 +-
tools/usb/usbip/src/usbip_connect.c | 228
4 files changed, 242 insertions(+), 3 deletions(-)
diff --git a/tools/usb/usbip/src/Makefile.am b/tools/usb/usbip/src/Makefile.am
index e81a4eb..0947476 100644
--- a/tools/usb/usbip/src/Makefile.am
+++ b/tools/usb/usbip/src/Makefile.am
@@ -6,6 +6,7 @@ sbin_PROGRAMS := usbip usbipd
usbip_SOURCES := usbip.h utils.h usbip.c utils.c usbip_network.c \
usbip_attach.c usbip_detach.c usbip_list.c \
-usbip_bind.c usbip_unbind.c usbip_port.c
+usbip_bind.c usbip_unbind.c usbip_port.c \
+usbip_connect.c
usbipd_SOURCES := usbip_network.h usbipd.c usbip_network.c
diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
index d7599d9..584d7d5 100644
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -2,7 +2,8 @@
* command structure borrowed from udev
* (git://git.kernel.org/pub/scm/linux/hotplug/udev.git)
*
- * Copyright (C) 2011 matt mooney
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2011 matt mooney
* 2005-2007 Takahiro Hirofuchi
*
* This program is free software: you can redistribute it and/or modify
@@ -76,6 +77,12 @@ static const struct command cmds[] = {
.usage = usbip_detach_usage
},
{
+ .name = "connect",
+ .fn= usbip_connect,
+ .help = "Connect a USB device to a remote computer",
+ .usage = usbip_connect_usage
+ },
+ {
.name = "list",
.fn= usbip_list,
.help = "List exportable or local USB devices",
diff --git a/tools/usb/usbip/src/usbip.h b/tools/usb/usbip/src/usbip.h
index c296910..f365353 100644
--- a/tools/usb/usbip/src/usbip.h
+++ b/tools/usb/usbip/src/usbip.h
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2011 matt mooney
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2011 matt mooney
* 2005-2007 Takahiro Hirofuchi
*
* This program is free software: you can redistribute it and/or modify
@@ -30,12 +31,14 @@ int usbip_list(int argc, char *argv[]);
int usbip_bind(int argc, char *argv[]);
int usbip_unbind(int argc, char *argv[]);
int usbip_port_show(int argc, char *argv[]);
+int usbip_connect(int argc, char *argv[]);
void usbip_attach_usage(void);
void usbip_detach_usage(void);
void usbip_list_usage(void);
void usbip_bind_usage(void);
void usbip_unbind_usage(void);
+void usbip_connect_usage(void);
int usbip_bind_device(char *busid);
int usbip_unbind_device(char *busid);
diff --git a/tools/usb/usbip/src/usbip_connect.c
b/tools/usb/usbip/src/usbip_connect.c
new file mode 100644
index 000..bbecc7e
--- /dev/null
+++ b/tools/usb/usbip/src/usbip_connect.c
@@ -0,0 +1,228 @@
+/*
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2011 matt mooney
+ * 2005-2007 Takahiro Hirofuchi
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH v12 1/9] usbip: exporting devices: modifications to network header
Modification to export and un-export response in tools/usb/usbip/src/usbip_network.h. It just changes return code type from int to uint32_t as same as other responses. Added export and un-export request/response to Documentation/usb/usbip_protocol.txt. Signed-off-by: Nobuo Iwata --- Documentation/usb/usbip_protocol.txt | 204 --- tools/usb/usbip/src/usbip_network.h | 5 +- 2 files changed, 184 insertions(+), 25 deletions(-) diff --git a/Documentation/usb/usbip_protocol.txt b/Documentation/usb/usbip_protocol.txt index 16b6fe2..d4be5b6 100644 --- a/Documentation/usb/usbip_protocol.txt +++ b/Documentation/usb/usbip_protocol.txt @@ -1,20 +1,26 @@ PRELIMINARY DRAFT, MAY CONTAIN MISTAKES! 28 Jun 2011 +MODIFIED FOR CONNECT AND DISCONNECT OPERARION. +07 March 2016 -The USB/IP protocol follows a server/client architecture. The server exports the -USB devices and the clients imports them. The device driver for the exported -USB device runs on the client machine. +The USB/IP protocol follows a server/client architecture between two computers +one has USB devices and the other runs application using the devices. There are +two ways for initiation. -The client may ask for the list of the exported USB devices. To get the list the -client opens a TCP/IP connection towards the server, and sends an OP_REQ_DEVLIST -packet on top of the TCP/IP connection (so the actual OP_REQ_DEVLIST may be sent -in one or more pieces at the low level transport layer). The server sends back -the OP_REP_DEVLIST packet which lists the exported USB devices. Finally the -TCP/IP connection is closed. +The first way is to import devices from application-side. In this way, the +server runs in device-side and the client runs in application-side. In device +side user makes devices importable with 'bind' operation. +The client may ask for the list of the importable USB devices. To get the list +the client opens a TCP/IP connection towards the server, and sends an +OP_REQ_DEVLIST packet on top of the TCP/IP connection (so the actual +OP_REQ_DEVLIST may be sent in one or more pieces at the low level transport +layer). The server sends back the OP_REP_DEVLIST packet which lists the +importable USB devices. Finally the TCP/IP connection is closed. + + application-sidedevice-side virtual host controller usb host - "client" "server" - (imports USB devices) (exports USB devices) + "client" (lists importable devices)"server" | | | OP_REQ_DEVLIST | | --> | @@ -23,18 +29,13 @@ TCP/IP connection is closed. | <-- | | | -Once the client knows the list of exported USB devices it may decide to use one -of them. First the client opens a TCP/IP connection towards the server and -sends an OP_REQ_IMPORT packet. The server replies with OP_REP_IMPORT. If the -import was successful the TCP/IP connection remains open and will be used -to transfer the URB traffic between the client and the server. The client may -send two types of packets: the USBIP_CMD_SUBMIT to submit an URB, and -USBIP_CMD_UNLINK to unlink a previously submitted URB. The answers of the -server may be USBIP_RET_SUBMIT and USBIP_RET_UNLINK respectively. +Once the client knows the list of importable USB devices it may decide to use +one of them. First the client opens a TCP/IP connection towards the server and +sends an OP_REQ_IMPORT packet. The server replies with OP_REP_IMPORT. + application-sidedevice-side virtual host controller usb host - "client" "server" - (imports USB devices) (exports USB devices) + "client" (imports a USB device) "server" | | | OP_REQ_IMPORT | | --> | @@ -42,6 +43,32 @@ server may be USBIP_RET_SUBMIT and USBIP_RET_UNLINK respectively. | OP_REP_IMPORT | | <-- | | | + +The second way is to export devices from device-side. In this way, the server +runs in application-side and the client runs in device-side. The client binds a +device to export, opens a TCP/IP connection towards the server and sends an +OP_REQ_EXPORT packet. The server replies with OP_REP_EXPORT. + + application-side
[PATCH v12 2/9] usbip: exporting devices: modifications to host side libraries
usbip_get_device() method in usbip_host_driver_ops was not used. It is
modified as a function to find an exported device for new operations
'connect' and 'disconnect'.
bind and unbind function are exported for the new operations.
Signed-off-by: Nobuo Iwata
---
tools/usb/usbip/libsrc/usbip_host_common.c | 6 ++
tools/usb/usbip/libsrc/usbip_host_common.h | 8
tools/usb/usbip/src/usbip.h| 3 +++
tools/usb/usbip/src/usbip_bind.c | 7 ---
tools/usb/usbip/src/usbip_unbind.c | 7 ---
5 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c
b/tools/usb/usbip/libsrc/usbip_host_common.c
index 9d41522..6a98d6c 100644
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -256,17 +256,15 @@ int usbip_export_device(struct usbip_exported_device
*edev, int sockfd)
}
struct usbip_exported_device *usbip_generic_get_device(
- struct usbip_host_driver *hdriver, int num)
+ struct usbip_host_driver *hdriver, char *busid)
{
struct list_head *i;
struct usbip_exported_device *edev;
- int cnt = 0;
list_for_each(i, &hdriver->edev_list) {
edev = list_entry(i, struct usbip_exported_device, node);
- if (num == cnt)
+ if (!strncmp(busid, edev->udev.busid, SYSFS_BUS_ID_SIZE))
return edev;
- cnt++;
}
return NULL;
diff --git a/tools/usb/usbip/libsrc/usbip_host_common.h
b/tools/usb/usbip/libsrc/usbip_host_common.h
index a64b803..f9a9def 100644
--- a/tools/usb/usbip/libsrc/usbip_host_common.h
+++ b/tools/usb/usbip/libsrc/usbip_host_common.h
@@ -38,7 +38,7 @@ struct usbip_host_driver_ops {
void (*close)(struct usbip_host_driver *hdriver);
int (*refresh_device_list)(struct usbip_host_driver *hdriver);
struct usbip_exported_device * (*get_device)(
- struct usbip_host_driver *hdriver, int num);
+ struct usbip_host_driver *hdriver, char *busid);
int (*read_device)(struct udev_device *sdev,
struct usbip_usb_device *dev);
@@ -86,11 +86,11 @@ static inline int usbip_refresh_device_list(struct
usbip_host_driver *hdriver)
}
static inline struct usbip_exported_device *
-usbip_get_device(struct usbip_host_driver *hdriver, int num)
+usbip_get_device(struct usbip_host_driver *hdriver, char *busid)
{
if (!hdriver->ops.get_device)
return NULL;
- return hdriver->ops.get_device(hdriver, num);
+ return hdriver->ops.get_device(hdriver, busid);
}
/* Helper functions for implementing driver backend */
@@ -99,6 +99,6 @@ void usbip_generic_driver_close(struct usbip_host_driver
*hdriver);
int usbip_generic_refresh_device_list(struct usbip_host_driver *hdriver);
int usbip_export_device(struct usbip_exported_device *edev, int sockfd);
struct usbip_exported_device *usbip_generic_get_device(
- struct usbip_host_driver *hdriver, int num);
+ struct usbip_host_driver *hdriver, char *busid);
#endif /* __USBIP_HOST_COMMON_H */
diff --git a/tools/usb/usbip/src/usbip.h b/tools/usb/usbip/src/usbip.h
index 84fe66a..c296910 100644
--- a/tools/usb/usbip/src/usbip.h
+++ b/tools/usb/usbip/src/usbip.h
@@ -37,4 +37,7 @@ void usbip_list_usage(void);
void usbip_bind_usage(void);
void usbip_unbind_usage(void);
+int usbip_bind_device(char *busid);
+int usbip_unbind_device(char *busid);
+
#endif /* __USBIP_H */
diff --git a/tools/usb/usbip/src/usbip_bind.c b/tools/usb/usbip/src/usbip_bind.c
index fa46141..1c09338 100644
--- a/tools/usb/usbip/src/usbip_bind.c
+++ b/tools/usb/usbip/src/usbip_bind.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2011 matt mooney
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2011 matt mooney
* 2005-2007 Takahiro Hirofuchi
*
* This program is free software: you can redistribute it and/or modify
@@ -139,7 +140,7 @@ static int unbind_other(char *busid)
return status;
}
-static int bind_device(char *busid)
+int usbip_bind_device(char *busid)
{
int rc;
struct udev *udev;
@@ -200,7 +201,7 @@ int usbip_bind(int argc, char *argv[])
switch (opt) {
case 'b':
- ret = bind_device(optarg);
+ ret = usbip_bind_device(optarg);
goto out;
default:
goto err_out;
diff --git a/tools/usb/usbip/src/usbip_unbind.c
b/tools/usb/usbip/src/usbip_unbind.c
index a4a496c..cc1ff26 100644
--- a/tools/usb/usbip/src/usbip_unbind.c
+++ b/tools/usb/usbip/src/usbip_unbind.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2011 matt mooney
+ * Copyright (C) 2015 Nobuo Iwata
+ * 2011 matt mooney
* 2005-2007 Takahiro Hirofuchi
*
* This program is free software: you can redistribute it and/or modi
[PATCH v12 0/9] usbip: exporting devices
d disconnect execute bind and unbind internally. With vUDC, they do not execute bind and unbind. They are done by UDC interface. 4. Security consideration Daemons accept following requests form network : EXISTING) 'list --remote' and 'attach' NEW) 'connect' and 'desconnect' TCP wrappers allows and/or denies network access. It is enabled when the daemons are compiled with ./configure --with-tcp-wrappers. When the daemons are running with SSL or Secure WebSocket tunneling proxy, the proxy can use client authentication with certificate files. 5. Mixed usage Both existing and new way work in same machines simultaneously. Status of devices and ports are controlled in stub and vhci driver. 6. Wording Adding the new operation, some inconsistnecies in wording are appeared in documentation, function name, etc. If needed, they are fixed. 'export' is used for bind and 'exported' is used for bound. They are changed to 'make importable' and 'imported' respectively. The words not new. For example, in the output of port operation, 'imported devices' is already used. They are sorted out. 'client' and 'server' are switched between existing and new operation. So, words 'device-side' and 'application-side' are used in documentations as needed for clarity. --- Version information This series is divided from "USB/IP over WebSocket" patch set. Rest of the set will be sent as another series. v12) # Recreated based on linux-next 20161012. # Fixed checkpatch a warning about symbolic permission. # Fixed checkpatch warnings about traling space in a document. v11) # Corrected program name of each daemon which are used in version string, info messages and daemon name for tcp wrappers. # Added description about tcp wrappers in security consideration of cover letter. # Added security consideration for existing requests in contradistinction to new requests. # Recreated based on linux-next 20160928. v10) # Recreated based on linux-next 20160810. v9) # Moved a set_nodelay() from usbipd_dev.c to usbipd.c to affect both device side and application side daemon. # Removed redundant blank line at the end of files. v8) # Divided into smaller patches. # Excluded low-related patches. # Improved change log. # Changed info level logs in usbip_ux.c to debug level logs. # Added options to vUDC. # Tested with vUDC. v7) # Removed userspace transmission and WebSocket command/daemon. # Fixed checkpatch errors and warnings. v6) # Added __rcu annotation to a RCU pointer to clear sparse warnings. # Corrected a copy to RCU pointer with rcu_rcu_assign_pointer(). # Added __user annotations to arguments of read/write method. # Added static to some functions which are not called from other files. # Removed unnecessary EXPORT_SYMBOLs. v5) # Added vendor/pruduct name conversion to port command. # Put initial value to pool_head in name.c. # Fixed list command exception when host option is omitted. # Fixed exception in case gai_strerror() returns NULL. # Fixed WebSocket connection close via proxy. # Fixed to stop WebSocket ping-pong on connection close. # Removed redundant usbipd daemon option. # Removed redundant SSL code had not been deleted. # Removed an unused local variable in WebSocket code. # Modified C++ reserved word in names.c as same as headers. v4) # Fixed regression of usbip list --remote v3) # Coding style for goto err labels are fixed. # Defined magic numbers for open_hc_device() argument. # Corrected include .../uapi/linux/usbip_ux.h as . # Modified parameter notation in manuals not to use '='. # Fixed inappropriate version definition in tools/.../websocket/configure.ac. # Remved unnecessary COPYING and AUTHORS fil from tools/.../websocket/. # Added -version-info to libraries in tools/.../src. 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. Thank you, Nobuo Iwata // *** BLURB HERE *** Nobuo Iwata (9): usbip: exporting devices: modifications to network header usbip: exporting devices: modifications to host side libraries usbip: exporting devices: new connect operation usbip: exporting devices: new disconnect operation usbip: exporting devices: modifications to daemon usbip: exporting devices: modifications to attach and detach usbip: exporting devices: new application-side daemon usbip: exporting devices: change to usbip_list.c usbip: exporting devices: chage to documenattion Documentation/usb/usbip_protocol.txt | 204 ++-- tools/usb/usbip/Makefile.am| 2 +- tools/usb/usbip/README | 70 -- tools/usb/usbip/doc/usbip.8| 136 +-- tools/usb/usbip/doc/u
[PATCH v1 1/1] usbip: fix possibility of dereference by NULLL pointer in vhci_hcd.c
This patch fixes possibility of dereference by NULLL pointer in "[PATCH
v5 1/3] usbip: vhci extension: modifications to vhci driver" which has
been merged to 4.9-rc1. It occurs when a URB with pointer to invalid
USB/IP device is enqueued in race condition against detach operation.
A pointer was passed to vdev_to_vhci() before NULL check.
In vdev_to_vhci(), there's a dereference by the pointer.
This patch moves vdev_to_vhci() after NULL check of the pointer.
Signed-off-by: Nobuo Iwata
---
drivers/usb/usbip/vhci_hcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 03eccf2..c4724fb 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -460,13 +460,14 @@ static void vhci_tx_urb(struct urb *urb)
{
struct vhci_device *vdev = get_vdev(urb->dev);
struct vhci_priv *priv;
- struct vhci_hcd *vhci = vdev_to_vhci(vdev);
+ struct vhci_hcd *vhci;
unsigned long flags;
if (!vdev) {
pr_err("could not get virtual device");
return;
}
+ vhci = vdev_to_vhci(vdev);
priv = kzalloc(sizeof(struct vhci_priv), GFP_ATOMIC);
if (!priv) {
--
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] usb: dwc3: Add support for device L1 exit
For the usb31 IP and from version 2.90a of the usb3 IP, the core
supports HW exit from L1 in HS. Enable it, otherwise the controller may
never exit from LPM to do a transfer.
Signed-off-by: John Youn
---
drivers/usb/dwc3/core.c | 10 ++
drivers/usb/dwc3/core.h | 4
2 files changed, 14 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7287a76..61fac40 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -766,6 +766,16 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
+ /*
+* Enable hardware control of sending remote wakeup in HS when
+* the device is in the L1 state.
+*/
+ if (dwc->revision >= DWC3_REVISION_290A) {
+ reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+ reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
+ dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
+ }
+
return 0;
err4:
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 6b60e42..5b1ab37 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -198,6 +198,9 @@
#define DWC3_GCTL_GBLHIBERNATIONEN (1 << 1)
#define DWC3_GCTL_DSBLCLKGTNG (1 << 0)
+/* Global User Control 1 Register */
+#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW (1 << 24)
+
/* Global USB2 PHY Configuration Register */
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
#define DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS (1 << 30)
@@ -909,6 +912,7 @@ struct dwc3 {
#define DWC3_REVISION_260A 0x5533260a
#define DWC3_REVISION_270A 0x5533270a
#define DWC3_REVISION_280A 0x5533280a
+#define DWC3_REVISION_290A 0x5533290a
#define DWC3_REVISION_300A 0x5533300a
#define DWC3_REVISION_310A 0x5533310a
--
2.10.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 v7 2/8] power: add power sequence library
On Wed, Oct 12, 2016 at 12:30:29PM +0200, Heiko Stuebner wrote:
> Hi,
>
> Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen:
> > We have an well-known problem that the device needs to do some power
> > sequence before it can be recognized by related host, the typical
> > example like hard-wired mmc devices and usb devices.
> >
> > This power sequence is hard to be described at device tree and handled by
> > related host driver, so we have created a common power sequence
> > library to cover this requirement. The core code has supplied
> > some common helpers for host driver, and individual power sequence
> > libraries handle kinds of power sequence for devices.
> >
> > pwrseq_generic is intended for general purpose of power sequence, which
> > handles gpios and clocks currently, and can cover regulator and pinctrl
> > in future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence is needed, else call of_pwrseq_on_list
> > /of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > Signed-off-by: Peter Chen
> > Tested-by Joshua Clayton
> > Reviewed-by: Matthias Kaehlcke
> > Tested-by: Matthias Kaehlcke
>
> first of all, glad to see this move forward. I've only some qualms with the
> static number of allocated power sequences below.
>
Thanks for commenting it, the preallocate way is not a good way, but I
can't find suitable way. See below comments.
> > +static int __init pwrseq_generic_register(void)
> > +{
> > + struct pwrseq_generic *pwrseq_gen;
> > + int i;
> > +
> > + for (i = 0; i < CONFIG_PWRSEQ_GENERIC_INSTANCE_NUMBER; i++) {
> > + pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> > + if (!pwrseq_gen)
> > + return -ENOMEM;
> > +
> > + pwrseq_gen->pwrseq.pwrseq_of_match_table = generic_id_table;
> > + pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> > + pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> > + pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> > + pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> > + pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> > +
> > + pwrseq_register(&pwrseq_gen->pwrseq);
> > + }
> > +
> > + return 0;
> > +}
> > +postcore_initcall(pwrseq_generic_register)
>
> I see that you need to have it preallocated for the compatible matching, but
> wouldn't it also work to either just register the type and allocate
> dynamically or otherwise just allocate a new spare everytime
> pwrseq_generic_get() picks up the previous spare?
Before compatible matching, the host driver doesn't know which pwrseq type
for its child node, then doesn't know which pwrseq instance needs to be
allocated. From dts, we don't know which pwrseq type for the node.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: dwc3: remove unused struct member dwc3->mem
Member @mem in struct dwc3 is not used in any places. Clean up it.
Signed-off-by: Lu Baolu
---
drivers/usb/dwc3/core.c | 1 -
drivers/usb/dwc3/core.h | 3 ---
2 files changed, 4 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7287a76..3dc535a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -941,7 +941,6 @@ static int dwc3_probe(struct platform_device *pdev)
return -ENOMEM;
dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1);
- dwc->mem = mem;
dwc->dev = dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 6b60e42..2544a9c 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -784,7 +784,6 @@ struct dwc3_scratchpad_array {
* @ep0state: state of endpoint zero
* @link_state: link state
* @speed: device speed (super, high, full, low)
- * @mem: points to start of memory which is used for this struct.
* @hwparams: copy of hwparams registers
* @root: debugfs root folder pointer
* @regset: debugfs pointer to regdump file
@@ -934,8 +933,6 @@ struct dwc3 {
u8 num_out_eps;
u8 num_in_eps;
- void*mem;
-
struct dwc3_hwparamshwparams;
struct dentry *root;
struct debugfs_regset32 *regset;
--
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
Re: [PATCH/RFT 07/12] USB: ohci-da8xx: Request gpios and handle interrupt in the driver
On 10/12/2016 10:01 AM, Axel Haslam wrote: I agree that we should use a regulator for the vbus power. i will make that change. However, im not so sure about using the regulator for the overcurrent handling. There seems to be no other driver doing this, and as you mention, we would need to change the regulator framework, which might not be justifiable. I think there is not another way to handle the over current notification other than powering the port off. The regulator framework has REGULATOR_EVENT_OVER_CURRENT already. Perhaps this could be of some use? For example you could extend the existing gpio-regulator driver with an optional overcurrent gpio pin. how about using regulator for vbus, but keeping gpio for overcurrent notifications? See the suggestion above about extending the gpio-regulator driver. For the usersapce handling you describe above, maybe we should be able to listen for an usb overcurrent uevent in userspace? it seems this question was asked a couple of years back[1], but im not sure what the conclusion was. In any case, we could have DT and non-DT based ohci-da8xx working, And could work on a uevent notification for the scenario you describe above which i think is not specific to the ohci-da8xx. [1]http://linux-usb.vger.kernel.narkive.com/SjcUB5hk/how-best-to-get-over-current-notification-to-user-application Thanks for the link. Too bad it seems nothing ever became of this. I guess it will be up to me to bring up the discussion again if I really want it. -- 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
Schnelle Darlehen
Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns für weitere Informationen. -- 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: USB hot-plug not working (ASUS TP301UA-C4028T)
On Wed, 12 Oct 2016, Pierre de Villemereuil wrote: > Hi! > > I'm sorry, I'm not savvy enough to know what to do with this (I know > basics on how to code and compile, but I'm no dev). Could someone > guide me through it? > > I gather this patch needs to be applied to some kernel module code > which needs to be compiled and reloaded into my current kernel, > right? More likely you'll have to rebuild an entire new kernel, not just a single module. Search the support site for the distribution you are using. It ought to contain reasonably thorough instructions on how to build and install your own version of their kernel. Once you know how to do all that, I can tell you how the patch should be applied -- that's the easy part. 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: [alsa-devel] Jack sensing in snd_usb_audio ?
On Wed, 2016-10-12 at 18:06 +0200, Clemens Ladisch wrote: > Bastien Nocera wrote: > > On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote: > > > Bastien Nocera wrote: > > > > " > > > > A change of state in the audio function is most often caused by > > > > a > > > > certain event that takes place. An event can either be user- > > > > initiated > > > > or device-initiated. User-initiated jack insertion or removal > > > > is a > > > > typical example of a user-initiated event. > > > > " > > > > > > > > > There are not many USB Audio 2.0 devices, and I'm not aware of > > > any > > > that actually implements this. > > > > > > I guess I would see whether there are events if I captured the USB > > traffic even without special handling/turning on a feature in the > > drivers, right? > > > Most devices do not even have the status endpoint (see "lsusb -v"). > To check what events arrive, you can add logging to the > snd_usb_mixer_interrupt() function. I'm guessing it doesn't support it then (see attached log) I also checked the input device output when plugging in something, with evtest, and no feedback either. Bus 003 Device 035: ID 1b3f:2008 Generalplus Technology Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1b3f Generalplus Technology Inc. idProduct 0x2008 bcdDevice1.00 iManufacturer 1 GeneralPlus iProduct2 USB Audio Device iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 253 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 100 bInCollection 2 baInterfaceNr( 0) 1 baInterfaceNr( 1) 2 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 4 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x0001 Left Front (L) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 6 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 2 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 9 iTerminal 0 AudioControl Interface Descriptor: bLength 7 bDescriptorType36 bDescriptorSubtype 5 (SELECTOR_UNIT) bUnitID 9 bNrInPins 1 baSource( 0)5 iSelector 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 6 bSourceID 8 bControlSize1 bmaControls( 0) 0x01 Mute Control bmaControls( 1) 0x02 Volume Control bmaControls( 2) 0x02 Volume Control iFeature0 AudioControl Interface
Re: xhci_hcd crash on linux 4.7.0
Forgot to mention, I just reproduced it on the mainline 4.8.1 kernel. On Wed, Oct 12, 2016 at 5:13 PM, Alex Damian wrote: > Hello, > > To follow up on the original bug report. I am still experiencing > memory corruption problems in the xhci stack. > > One thing I noticed is that the corruption always occur on a secondary > CPU (ie. the stack trace starts on cpu_startup_entry) and it is always > going on when trying to handle an intrerrupt. > > Seems to me that a mutex or something similar is not correctly locked, > but I don't have any experience with the code around this part, so I > have no idea where to look. > > Pointers, ideas, suggestions ? > > Cheers, > Alex > > On Thu, Aug 25, 2016 at 2:22 PM, Mathias Nyman > wrote: >> On 29.07.2016 17:41, Alex Damian wrote: >>> >>> On Fri, Jul 29, 2016 at 2:53 PM, Greg KH wrote: On Fri, Jul 29, 2016 at 10:58:03AM +0100, Alex Damian wrote: > > Hi Greg, > > I managed to reproduce with a untainted kernel, see dmesg paste below. > The stack seemed corrupted as well ? > > I refered to it as a crash since after a couple of these issues, the > machine hard freezes - I set up a serial console via a USB cable, but > I don't get the kernel oops out of the machine. The network is also > dead before getting any data. I could not think of any other way to > get a console out of a Macbook - any ideas ? > > There is a progressive level of deterioration going on below, this is > why I'm adding multiple pastes. See the obviously invalid pointer > 0001 in 3rd paste below. Also, see the protection fault in > the last paste. To me, something is trampling all over memory, and it > is usb-related. Not good, thanks for reproducing it without the closed kernel drivers. If you disable the list debug kernel option, do you have any problems with the machine? We aren't having any other reports of issues like this at the moment, which makes me worry that it's something unique to your situation/hardware. >>> >>> >>> I strongly suspect it's related to the macbook 12,1 hardware. I >>> haven't been able >>> to reproduce this with other machines, including other macbook >>> versions with the same peripherals. >>> >>> This machine has never been stable in this particular peripheral >>> configuration. >>> I had Apple run all HW diagnostics on the machine, I ran the memcheck >>> to verify that >>> the RAM is ok - all results are clean. The machine is very stable under >>> Mac OSX. >>> And you don't know that it's a USB problem, only that USB is the one that is showing the issue. Anyone could be writing over memory. >>> >>> >>> True. However it seems particularly related to the USB mouse - that's >>> how I manage >>> to reproduce the error. >>> Also, any chance you can use 'git bisect' to track down an offending commit? I'm assuming that this used to work properly and something recently caused the issue, correct? >>> >>> >>> The earliest kernels I've tested are in the 3.3 range. All kernels >>> before 4.7 just lock up. >>> 4.7 is the first kernel where I have meaningful dmesg errors before >>> locking up. As such, >>> there is very little that I can do to bisect :(. >>> >> >> Going through xhci related issues that occurred during my vacation. >> >> There is one command list related issue fixed in 4.8-rc3, any chance you >> could try it? >> Alternatively just add the following patch added to 4.7: >> 33be126 xhci: always handle "Command Ring Stopped" events >> >> Enabling xhci debug could reveal something. >> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control >> >> -Mathias >> -- 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: xhci_hcd crash on linux 4.7.0
Hello, To follow up on the original bug report. I am still experiencing memory corruption problems in the xhci stack. One thing I noticed is that the corruption always occur on a secondary CPU (ie. the stack trace starts on cpu_startup_entry) and it is always going on when trying to handle an intrerrupt. Seems to me that a mutex or something similar is not correctly locked, but I don't have any experience with the code around this part, so I have no idea where to look. Pointers, ideas, suggestions ? Cheers, Alex On Thu, Aug 25, 2016 at 2:22 PM, Mathias Nyman wrote: > On 29.07.2016 17:41, Alex Damian wrote: >> >> On Fri, Jul 29, 2016 at 2:53 PM, Greg KH wrote: >>> >>> On Fri, Jul 29, 2016 at 10:58:03AM +0100, Alex Damian wrote: Hi Greg, I managed to reproduce with a untainted kernel, see dmesg paste below. The stack seemed corrupted as well ? I refered to it as a crash since after a couple of these issues, the machine hard freezes - I set up a serial console via a USB cable, but I don't get the kernel oops out of the machine. The network is also dead before getting any data. I could not think of any other way to get a console out of a Macbook - any ideas ? There is a progressive level of deterioration going on below, this is why I'm adding multiple pastes. See the obviously invalid pointer 0001 in 3rd paste below. Also, see the protection fault in the last paste. To me, something is trampling all over memory, and it is usb-related. >>> >>> >>> Not good, thanks for reproducing it without the closed kernel drivers. >>> >>> If you disable the list debug kernel option, do you have any problems >>> with the machine? We aren't having any other reports of issues like >>> this at the moment, which makes me worry that it's something unique to >>> your situation/hardware. >> >> >> I strongly suspect it's related to the macbook 12,1 hardware. I >> haven't been able >> to reproduce this with other machines, including other macbook >> versions with the same peripherals. >> >> This machine has never been stable in this particular peripheral >> configuration. >> I had Apple run all HW diagnostics on the machine, I ran the memcheck >> to verify that >> the RAM is ok - all results are clean. The machine is very stable under >> Mac OSX. >> >>> And you don't know that it's a USB problem, only that USB is the one >>> that is showing the issue. Anyone could be writing over memory. >> >> >> True. However it seems particularly related to the USB mouse - that's >> how I manage >> to reproduce the error. >> >>> >>> Also, any chance you can use 'git bisect' to track down an offending >>> commit? I'm assuming that this used to work properly and something >>> recently caused the issue, correct? >> >> >> The earliest kernels I've tested are in the 3.3 range. All kernels >> before 4.7 just lock up. >> 4.7 is the first kernel where I have meaningful dmesg errors before >> locking up. As such, >> there is very little that I can do to bisect :(. >> > > Going through xhci related issues that occurred during my vacation. > > There is one command list related issue fixed in 4.8-rc3, any chance you > could try it? > Alternatively just add the following patch added to 4.7: > 33be126 xhci: always handle "Command Ring Stopped" events > > Enabling xhci debug could reveal something. > echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control > > -Mathias > -- 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: [alsa-devel] Jack sensing in snd_usb_audio ?
Bastien Nocera wrote: > On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote: >> Bastien Nocera wrote: >>> " >>> A change of state in the audio function is most often caused by a >>> certain event that takes place. An event can either be user- >>> initiated >>> or device-initiated. User-initiated jack insertion or removal is a >>> typical example of a user-initiated event. >>> " >> >> There are not many USB Audio 2.0 devices, and I'm not aware of any >> that actually implements this. > > I guess I would see whether there are events if I captured the USB > traffic even without special handling/turning on a feature in the > drivers, right? Most devices do not even have the status endpoint (see "lsusb -v"). To check what events arrive, you can add logging to the snd_usb_mixer_interrupt() function. Regards, Clemens -- 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: [alsa-devel] Jack sensing in snd_usb_audio ?
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote: > Bastien Nocera wrote: > > Looks like whether or not jack sensing works depends on the device > > itself, but there is a mechanism to propagate the change in setup > > in > > the USB Audio 2.0 spec > > > Some recent Windows 10 beta added partial support for USB Audio 2.0. > Earlier Windowses implement only USB Audio 1.0, which does not > mention > jacks. > > > " > > A change of state in the audio function is most often caused by a > > certain event that takes place. An event can either be user- > > initiated > > or device-initiated. User-initiated jack insertion or removal is a > > typical example of a user-initiated event. > > " > > > There are not many USB Audio 2.0 devices, and I'm not aware of any > that actually implements this. I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right? -- 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/RFT 07/12] USB: ohci-da8xx: Request gpios and handle interrupt in the driver
Hi David On Tue, Oct 11, 2016 at 1:18 AM, David Lechner wrote: > On 10/07/2016 11:42 AM, ahas...@baylibre.com wrote: >> >> From: Axel Haslam >> >> Currently requesting the vbus and overcurrent gpio is handled on >> the board specific file. But this does not play well moving to >> device tree. >> >> In preparation to migrate to a device tree boot, handle requesting >> gpios and overcurrent interrupt on the usb driver itself, thus avoiding >> callbacks to arch/mach* >> > > Instead of using gpios, it seems like it would be better to use a regulator > here. I don't know of any real-life cases, but who is to say someone > not design a board that uses a regulator controlled by I2C instead of gpios > or something like that. > > Then, boards that don't have gpios can just use a fixed regulator (or you > can make the regulator optional). Using a regulator would also allow users > to decide how to respond to overcurrent events (by supplying their own > regulator driver) instead of the behavior being dictated by the ohci driver. I agree that we should use a regulator for the vbus power. i will make that change. However, im not so sure about using the regulator for the overcurrent handling. There seems to be no other driver doing this, and as you mention, we would need to change the regulator framework, which might not be justifiable. I think there is not another way to handle the over current notification other than powering the port off. > > In my particular area of interest (LEGO MINDSTORMS EV3), the 5V (hardware) > regulator for VBUS does use gpios, but the 5V is also shared with the LEGO > input and output ports. So what I would ultimately like to be able to do is > have userspace notified of an overcurrent event and let userspace decided > when to turn the vbus back on. For example, someone might plug something > into one of the LEGO input or output ports that causes a short circuit. I > would like to display a notification to the user and wait for them to > correct the problem and then press a button to turn the power back on. > how about using regulator for vbus, but keeping gpio for overcurrent notifications? For the usersapce handling you describe above, maybe we should be able to listen for an usb overcurrent uevent in userspace? it seems this question was asked a couple of years back[1], but im not sure what the conclusion was. In any case, we could have DT and non-DT based ohci-da8xx working, And could work on a uevent notification for the scenario you describe above which i think is not specific to the ohci-da8xx. [1]http://linux-usb.vger.kernel.narkive.com/SjcUB5hk/how-best-to-get-over-current-notification-to-user-application Regards Axel > This will require some modifications to the regulator subsystem though. I > actually started work on this a while back, but haven't had the time to > pursue it any farther. > > Here are my WIP patches in case there is any interest: > * > https://github.com/dlech/ev3dev-kernel/commit/541a42b3b8ed639e95bbc835df3292f80190c789 > * > https://github.com/dlech/ev3dev-kernel/commit/2ba99b1ad6a06c944dd33a073f54044e71b75ae6 > * > https://github.com/dlech/ev3dev-kernel/commit/cdb03caa50e64931d4f2836c648739aa4385ed3b > * > https://github.com/dlech/ev3dev-kernel/commit/9d6b50cde34b51309c74d97c26b1430c7ff6aa0f -- 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: Jack sensing in snd_usb_audio ?
Hi Bastien, On 12/10/16 12:58, Bastien Nocera wrote: > On Wed, 2016-10-12 at 19:36 +0900, Takashi Sakamoto wrote: >> On Oct 12 2016 14:10, Bastien Nocera wrote: >>> My questions are: >>> - does the USB audio driver support jack sensing? >>> - is this something standard that's just not implemented yet? In >>> which >>> case, I'd be up for at least trying, given specs. >>> - or is it something that depends on the device, and in which case, >>> how >>> would I find out? >> >> >> In ALSA usb-related codes, there's no functions calls for >> snd_jack_*(), >> thus none of ALSA drivers for USB support Jack sense feature of ALSA >> control interface. >> >> The requirement of Jack sense feature is whether hardwares support >> it. >> For example, some hardware codecs such as HDA codecs generates >> signals >> when plugs are insert to jacks connected to the codecs. Corresponding >> ALSA drivers catch the signals, then tell it to user land. >> >> If your hardware performs like it, you have a probability to add >> support >> for jack sense feature to ALSA drivers for USB. But I don't know >> exactly >> that USB related specifications such as USB Audio Device Class >> 1.0/2.0/3.0 supports the feature. > > Looks like whether or not jack sensing works depends on the device > itself, but there is a mechanism to propagate the change in setup in > the USB Audio 2.0 spec, in the "Interrupts" section: > " > A change of state in the audio function is most often caused by a > certain event that takes place. An event can either be user-initiated > or device-initiated. User-initiated jack insertion or removal is a > typical example of a user-initiated event. > " snd_usb_audio doesn't support control interrupts yet. It's a nice feature to work on. -- Felipe 0x92698E6A.asc Description: application/pgp-keys
Re: [alsa-devel] Jack sensing in snd_usb_audio ?
Bastien Nocera wrote: > Looks like whether or not jack sensing works depends on the device > itself, but there is a mechanism to propagate the change in setup in > the USB Audio 2.0 spec Some recent Windows 10 beta added partial support for USB Audio 2.0. Earlier Windowses implement only USB Audio 1.0, which does not mention jacks. > " > A change of state in the audio function is most often caused by a > certain event that takes place. An event can either be user-initiated > or device-initiated. User-initiated jack insertion or removal is a > typical example of a user-initiated event. > " There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this. Regards, Clemens -- 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: dwc3: gadget: Wait for end transfer complete before free irq
When we change the USB function with configfs frequently, sometimes it will
hang the system to crash. The reason is the gadget driver can not hanle the
end transfer complete event after free the gadget irq (since the xHCI will
share the same interrupt number with gadget, thus when free the gadget irq,
it will not shutdown this gadget irq line), which will trigger the interrupt
all the time.
Thus we should check if we need wait for the end transfer command completion
before free gadget irq.
Signed-off-by: Baolin Wang
---
Changes since v1:
- Simply the operation of cleaning the dep flags.
---
drivers/usb/dwc3/core.h |3 ++
drivers/usb/dwc3/gadget.c | 73 +++--
2 files changed, 73 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 9128725..f01d8fd 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -537,6 +537,7 @@ struct dwc3_ep {
#define DWC3_EP_BUSY (1 << 4)
#define DWC3_EP_PENDING_REQUEST(1 << 5)
#define DWC3_EP_MISSED_ISOC(1 << 6)
+#define DWC3_EP_CMDCMPLT_BUSY (1 << 7)
/* This last one is specific to EP0 */
#define DWC3_EP0_DIR_IN(1 << 31)
@@ -746,6 +747,7 @@ struct dwc3_scratchpad_array {
* @ep0_bounce_addr: dma address of ep0_bounce
* @scratch_addr: dma address of scratchbuf
* @ep0_in_setup: One control transfer is completed and enter setup phase
+ * @cmd_complete: endpoint command completion
* @lock: for synchronizing
* @dev: pointer to our struct device
* @xhci: pointer to our xHCI child
@@ -845,6 +847,7 @@ struct dwc3 {
dma_addr_t scratch_addr;
struct dwc3_request ep0_usb_req;
struct completion ep0_in_setup;
+ struct completion cmd_complete;
/* device lock */
spinlock_t lock;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index fef023a..32e3d4d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -573,6 +573,7 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep,
dep->comp_desc = comp_desc;
dep->type = usb_endpoint_type(desc);
dep->flags |= DWC3_EP_ENABLED;
+ dep->flags &= ~DWC3_EP_CMDCMPLT_BUSY;
reg = dwc3_readl(dwc->regs, DWC3_DALEPENA);
reg |= DWC3_DALEPENA_EP(dep->number);
@@ -650,7 +651,7 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
dep->endpoint.desc = NULL;
dep->comp_desc = NULL;
dep->type = 0;
- dep->flags = 0;
+ dep->flags &= DWC3_EP_CMDCMPLT_BUSY;
return 0;
}
@@ -1732,6 +1733,54 @@ static void __dwc3_gadget_stop(struct dwc3 *dwc)
__dwc3_gadget_ep_disable(dwc->eps[1]);
}
+static void dwc3_wait_command_complete(struct dwc3 *dwc)
+{
+ u32 epnum, epstart = 2;
+ int ret, wait_cmd_complete = 0;
+ unsigned long flags;
+
+check_next:
+ spin_lock_irqsave(&dwc->lock, flags);
+ /*
+* If the gadget has been in suspend state, then don't
+* need to wait for the end transfer complete event.
+*/
+ if (pm_runtime_suspended(dwc->dev)) {
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ return;
+ }
+
+ for (epnum = epstart; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
+ struct dwc3_ep *dep;
+
+ dep = dwc->eps[epnum];
+ if (!dep)
+ continue;
+
+ if (dep->flags & DWC3_EP_CMDCMPLT_BUSY) {
+ reinit_completion(&dwc->cmd_complete);
+ epstart = epnum + 1;
+ wait_cmd_complete = 1;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&dwc->lock, flags);
+
+ /*
+* Wait for 500ms to complete the end transfer command before free irq.
+*/
+ if (wait_cmd_complete) {
+ wait_cmd_complete = 0;
+ ret = wait_for_completion_timeout(&dwc->cmd_complete,
+ msecs_to_jiffies(500));
+ if (ret == 0)
+ dev_warn(dwc->dev,
+"timeout to wait for command complete.\n");
+
+ goto check_next;
+ }
+}
+
static int dwc3_gadget_stop(struct usb_gadget *g)
{
struct dwc3 *dwc = gadget_to_dwc(g);
@@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
dwc->gadget_driver = NULL;
spin_unlock_irqrestore(&dwc->lock, flags);
+ /*
+* Since the xHCI will share the same interrupt with gadget, thus when
+* free the gadget irq, it will not shutdown this gadget irq line. Then
+* the gadget driver can not handle the end transfer command complete
+* event after free the gadget irq, which will hang the system to crash.
+*
Re: usbip: vhci extension: modifications to vhci driver
On Wed, Oct 12, 2016 at 05:24:31AM +, fx IWATA NOBUO wrote: > Hello, > > I will send a patch to clear this warning. > > The current behavior is as following: > vdev_to_vhci() is inline of container_of(). > A pointer (struct vhci_hcd *vhci) may be container_of() from NULL for a > while. > If it is container_of() from NULL, it will not be referenced because of > NULL check of source pointer of the container_of(). Are you looking at linux-next? vdev_to_vhci() derefernces "vdev" to get vdev->rhport so this is a bug and not a false positive. Smatch sometimes does have false positives because it thinks foo->array is a dereference when really we're taking the address of the array. I should fix that... But it understands that container_of(NULL) is ok. regards, dan carpenter -- 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: Jack sensing in snd_usb_audio ?
On Wed, 2016-10-12 at 19:36 +0900, Takashi Sakamoto wrote: > On Oct 12 2016 14:10, Bastien Nocera wrote: > > My questions are: > > - does the USB audio driver support jack sensing? > > - is this something standard that's just not implemented yet? In > > which > > case, I'd be up for at least trying, given specs. > > - or is it something that depends on the device, and in which case, > > how > > would I find out? > > > In ALSA usb-related codes, there's no functions calls for > snd_jack_*(), > thus none of ALSA drivers for USB support Jack sense feature of ALSA > control interface. > > The requirement of Jack sense feature is whether hardwares support > it. > For example, some hardware codecs such as HDA codecs generates > signals > when plugs are insert to jacks connected to the codecs. Corresponding > ALSA drivers catch the signals, then tell it to user land. > > If your hardware performs like it, you have a probability to add > support > for jack sense feature to ALSA drivers for USB. But I don't know > exactly > that USB related specifications such as USB Audio Device Class > 1.0/2.0/3.0 supports the feature. Looks like whether or not jack sensing works depends on the device itself, but there is a mechanism to propagate the change in setup in the USB Audio 2.0 spec, in the "Interrupts" section: " A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user-initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. " I guess I should probably test in another operating system to check whether the hardware I have supports this to start with, and go from there. Cheers -- 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: Jack sensing in snd_usb_audio ?
On Oct 12 2016 14:10, Bastien Nocera wrote: > My questions are: > - does the USB audio driver support jack sensing? > - is this something standard that's just not implemented yet? In which > case, I'd be up for at least trying, given specs. > - or is it something that depends on the device, and in which case, how > would I find out? In ALSA usb-related codes, there's no functions calls for snd_jack_*(), thus none of ALSA drivers for USB support Jack sense feature of ALSA control interface. The requirement of Jack sense feature is whether hardwares support it. For example, some hardware codecs such as HDA codecs generates signals when plugs are insert to jacks connected to the codecs. Corresponding ALSA drivers catch the signals, then tell it to user land. If your hardware performs like it, you have a probability to add support for jack sense feature to ALSA drivers for USB. But I don't know exactly that USB related specifications such as USB Audio Device Class 1.0/2.0/3.0 supports the feature. Regards Takashi Sakamoto -- 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 v7 2/8] power: add power sequence library
Hi,
Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> Signed-off-by: Peter Chen
> Tested-by Joshua Clayton
> Reviewed-by: Matthias Kaehlcke
> Tested-by: Matthias Kaehlcke
first of all, glad to see this move forward. I've only some qualms with the
static number of allocated power sequences below.
[...]
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 000..dff5e35
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,45 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> + bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> + bool "Generic power sequence control"
> + depends on OF
> + select POWER_SEQUENCE
> + help
> +It is used for drivers which needs to do power sequence
> +(eg, turn on clock, toggle reset gpio) before the related
> +devices can be found by hardware. This generic one can be
> +used for common power sequence control.
> +
> +config PWRSEQ_GENERIC_INSTANCE_NUMBER
> + int "Number of Generic Power Sequence Instance"
> + depends on PWRSEQ_GENERIC
> + range 1 10
> + default 2
> + help
> +Usually, there are not so many devices needs power sequence, we set
> two
> +as default value.
limiting this to some arbitary compile-time number somehow seems crippling for
the single-image approach. I.e. a distribution might select something and
during its lifetime the board requiring n+1 power-sequences appears and thus
needs a different kernel version just to support that additional sequence.
Also, board designers are creative, and there were already complex examples
mentioned elsewhere, so nothing keeps people from inventing something even
more complex.
[...]
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c
> b/drivers/power/pwrseq/pwrseq_generic.c new file mode 100644
> index 000..bcd16c3
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
[...]
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq
> *pwrseq) +{
> + struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> + enum of_gpio_flags flags;
> + int reset_gpio, clk, ret = 0;
> +
> + for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> + pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> + if (IS_ERR(pwrseq_gen->clks[clk])) {
> + ret = PTR_ERR(pwrseq_gen->clks[clk]);
> + if (ret != -ENOENT)
> + goto err_put_clks;
> + pwrseq_gen->clks[clk] = NULL;
> + break;
> + }
> + }
> +
> + reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> + if (gpio_is_valid(reset_gpio)) {
> + unsigned long gpio_flags;
> +
> + if (flags & OF_GPIO_ACTIVE_LOW)
> + gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> + else
> + gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> + ret = gpio_request_one(reset_gpio, gpio_flags,
> + "pwrseq-reset-gpios");
> + if (ret)
> + goto err_put_clks;
> +
> + pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> + of_property_read_u32(np, "reset-duration-us",
> + &pwrseq_gen->duration_us);
> + } else {
> + if (reset_gpio == -ENOENT)
> + return 0;
> +
> + ret = reset_gpio;
> + pr_err("Failed to get reset gpio on %s, err = %d\n",
> + np->full_name, reset_gpio);
> + goto err_put_clks;
> + }
> +
> + return ret;
> +
> +err_put_clks:
> + while (--clk >= 0)
> + clk_put(pwrseq_gen->clks[clk]);
> + return ret;
> +}
> +
> +static const struct of_device_id generic_id_table[] = {
> + { .compatible = "generic",},
> + { /* sentinel */ }
> +};
> +
> +static int __init pwrseq_generic_register(void)
> +{
> + struct pwrseq
Re: Jack sensing in snd_usb_audio ?
On Wed, 2016-10-12 at 11:14 +0200, Felipe Ferreri Tonello wrote: > > What you need is PulseAudio server instead. PulseAudio supports this > via > kcontrol for quite some time. > > Jack is supposed to be a low-latency audio server for audio > applications, not for normal desktop usage. I'm not talking about jackd but about jack sensing. -- 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: Jack sensing in snd_usb_audio ?
Hi Bastien, On 12/10/16 07:10, Bastien Nocera wrote: > Hey, > > I recently bought some cheap USB soundcards for a computer that doesn't > have any audio output other than through the HDMI output, and the > screen I'm attaching doesn't have an audio output. > > So I'm looking to plug in 2 of those USB soundcards, and switch between > them depending on whether I'm using headphones, or want to use the > standalone speaker. > > Obviously, it would be so much nicer if I didn't have to switch between > the outputs by hand, and ignored the "headphones" sound card when not > plugged in. > > My questions are: > - does the USB audio driver support jack sensing? > - is this something standard that's just not implemented yet? In which > case, I'd be up for at least trying, given specs. > - or is it something that depends on the device, and in which case, how > would I find out? What you need is PulseAudio server instead. PulseAudio supports this via kcontrol for quite some time. Jack is supposed to be a low-latency audio server for audio applications, not for normal desktop usage. > > Some details about the device itself below. > > Cheers > > /proc/asound/cards: > 4 [Device ]: USB-Audio - USB Audio Device > GeneralPlus USB Audio Device at usb-:00:14.0-9, > full speed > > $ amixer -c 4 > Simple mixer control 'Speaker',0 > Capabilities: pvolume pswitch pswitch-joined > Playback channels: Front Left - Front Right > Limits: Playback 0 - 30 > Mono: > Front Left: Playback 16 [53%] [-21.00dB] [on] > Front Right: Playback 16 [53%] [-21.00dB] [on] > Simple mixer control 'Mic',0 > Capabilities: pvolume pvolume-joined cvolume cvolume-joined pswitch > pswitch-joined cswitch cswitch-joined > Playback channels: Mono > Capture channels: Mono > Limits: Playback 0 - 14 Capture 0 - 30 > Mono: Playback 1 [7%] [-10.50dB] [off] Capture 26 [87%] [27.00dB] > [on] > Simple mixer control 'Auto Gain Control',0 > Capabilities: pswitch pswitch-joined > Playback channels: Mono > Mono: Playback [off] > -- > 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 > -- Felipe 0x92698E6A.asc Description: application/pgp-keys
RE: usbip: vhci extension: modifications to vhci driver
Hello, > vdev_to_vhci() derefernces "vdev" to get vdev->rhport Yes, you are right. Sorry about my misreading. I'm creating the patch and will send later. Thank you for your help, n.iwata // > -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Wednesday, October 12, 2016 5:57 PM > To: fx IWATA NOBUO > Cc: linux-usb@vger.kernel.org > Subject: Re: usbip: vhci extension: modifications to vhci driver > > On Wed, Oct 12, 2016 at 05:24:31AM +, fx IWATA NOBUO wrote: > > Hello, > > > > I will send a patch to clear this warning. > > > > The current behavior is as following: > > vdev_to_vhci() is inline of container_of(). > > A pointer (struct vhci_hcd *vhci) may be container_of() from NULL for > > a while. > > If it is container_of() from NULL, it will not be referenced because > > of NULL check of source pointer of the container_of(). > > Are you looking at linux-next? vdev_to_vhci() derefernces "vdev" to get > vdev->rhport so this is a bug and not a false positive. > > Smatch sometimes does have false positives because it thinks foo->array > is a dereference when really we're taking the address of the array. I should > fix that... But it understands that container_of(NULL) is ok. > > regards, > dan carpenter -- 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 v7 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Mon, Oct 10, 2016 at 3:39 PM, Martyn Welch wrote: > This patch adds support for the GPIO found on the CP2105. Unlike the GPIO > provided by some of the other devices supported by the cp210x driver, the > GPIO on the CP2015 is muxed on pins otherwise used for serial control > lines. The GPIO have been configured in 2 separate banks as the choice to > configure the pins for GPIO is made separately for pins shared with each > of the 2 serial ports this device provides, though the choice is made for > all pins associated with that port in one go. The choice of whether to use > the pins for GPIO or serial is made by adding configuration to a one-time > programable PROM in the chip and can not be changed at runtime. The device > defaults to GPIO. > > This device supports either push-pull or open-drain modes, it doesn't > provide an explicit input mode, though the state of the GPIO can be read > when used in open-drain mode. Like with pin use, the mode is configured in > the one-time programable PROM and can't be changed at runtime. > > Signed-off-by: Martyn Welch (...) > V7: - Using GPIO private data for GPIO bits. > - Adding limited .set_single_ended() and direction support. > - Simplifying attach() and removing release() as it's no longer required. >From a GPIO point of view: Reviewed-by: Linus Walleij Yours, Linus Walleij -- 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
[bug report] usb: gadget: f_fs: handle control requests not directed to interface or endpoint
Hello Felix Hädicke,
The patch 54dfce6d07b0: "usb: gadget: f_fs: handle control requests
not directed to interface or endpoint" from Jun 22, 2016, leads to
the following static checker warning:
drivers/usb/gadget/function/f_fs.c:3152 ffs_func_req_match()
warn: always true condition '(((creq->wIndex)) >= 0) => (0-u16max >= 0)'
drivers/usb/gadget/function/f_fs.c
3140 static bool ffs_func_req_match(struct usb_function *f,
3141 const struct usb_ctrlrequest *creq,
3142 bool config0)
3143 {
3144 struct ffs_function *func = ffs_func_from_usb(f);
3145
3146 if (config0 && !(func->ffs->user_flags &
FUNCTIONFS_CONFIG0_SETUP))
3147 return false;
3148
3149 switch (creq->bRequestType & USB_RECIP_MASK) {
3150 case USB_RECIP_INTERFACE:
3151 return ffs_func_revmap_intf(func,
3152 le16_to_cpu(creq->wIndex)
>= 0);
^
3153 case USB_RECIP_ENDPOINT:
3154 return ffs_func_revmap_ep(func,
3155le16_to_cpu(creq->wIndex) >=
0);
^^
This doesn't work, but it's not even clear to me what we are trying to
do here.
3156 default:
3157 return (bool) (func->ffs->user_flags &
3158 FUNCTIONFS_ALL_CTRL_RECIP);
3159 }
3160 }
regards,
dan carpenter
--
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
