Re: [PATCH] usb: gadget: functions: add ftrace export over USB
Hi Felipe,
[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Felipe-Balbi/usb-gadget-functions-add-ftrace-export-over-USB/20170610-060059
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha
All error/warnings (new ones prefixed by >>):
>> drivers/usb/gadget/function/f-trace.c:25:22: error: field 'ftrace' has
>> incomplete type
struct trace_export ftrace;
^~
In file included from include/linux/list.h:8:0,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from drivers/usb/gadget/function/f-trace.c:12:
drivers/usb/gadget/function/f-trace.c: In function 'ftrace_write':
include/linux/kernel.h:854:48: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
>> drivers/usb/gadget/function/f-trace.c:38:29: note: in expansion of macro
>> 'container_of'
#define ftrace_to_trace(f) (container_of((f), struct usb_ftrace, ftrace))
^~~~
>> drivers/usb/gadget/function/f-trace.c:174:30: note: in expansion of macro
>> 'ftrace_to_trace'
struct usb_ftrace *trace = ftrace_to_trace(ftrace);
^~~
include/linux/kernel.h:854:48: note: (near initialization for 'trace')
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
>> drivers/usb/gadget/function/f-trace.c:38:29: note: in expansion of macro
>> 'container_of'
#define ftrace_to_trace(f) (container_of((f), struct usb_ftrace, ftrace))
^~~~
>> drivers/usb/gadget/function/f-trace.c:174:30: note: in expansion of macro
>> 'ftrace_to_trace'
struct usb_ftrace *trace = ftrace_to_trace(ftrace);
^~~
drivers/usb/gadget/function/f-trace.c: In function 'ftrace_bind':
>> drivers/usb/gadget/function/f-trace.c:294:8: error: implicit declaration of
>> function 'register_ftrace_export' [-Werror=implicit-function-declaration]
ret = register_ftrace_export(&trace->ftrace);
^~
drivers/usb/gadget/function/f-trace.c: In function 'ftrace_unbind':
>> drivers/usb/gadget/function/f-trace.c:322:2: error: implicit declaration of
>> function 'unregister_ftrace_export' [-Werror=implicit-function-declaration]
unregister_ftrace_export(&trace->ftrace);
^~~~
cc1: some warnings being treated as errors
vim +/ftrace +25 drivers/usb/gadget/function/f-trace.c
6 *
7 * This program is free software; you can redistribute it and/or
8 * modify it under the terms of the GNU General Public License v2 as
9 * published by the Free Software Foundation.
10 */
11
> 12 #include
13 #include
14 #include
15 #include
16 #include
17 #include
18 #include
19 #include
20 #include
21 #include
22 #include
23
24 struct usb_ftrace {
> 25 struct trace_export ftrace;
26 struct usb_function function;
27 struct work_struct queue_work;
28 spinlock_t lock;
29
30 struct list_head list;
31 struct list_head pending;
32 struct list_head queued;
33
34 struct usb_ep *in;
35
36 u8 intf_id;
37 };
> 38 #define ftrace_to_trace(f) (container_of((f), struct usb_ftrace,
ftrace))
39 #define work_to_trace(w)(container_of((w), struct usb_ftrace,
queue_work))
40 #define to_trace(f) (container_of((f), struct usb_ftrace,
function))
41
42 #define FTRACE_REQUEST_QUEUE_LENGTH 250
43
44 static inline struct usb_request *next_request(struct list_head *list)
45 {
46 return list_first_entry_or_null(list, struct usb_request, list);
47 }
48
49 struct usb_ftrace_opts {
50 struct usb_function_instance func_inst;
51 };
52
Re: [PATCH v1] usb: misc: usbsevseg: Use __sysfs_match_string() helper
Hi Andy,
[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/usb-misc-usbsevseg-Use-__sysfs_match_string-helper/20170610-055240
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: x86_64-randconfig-b0-06101036 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/usb/misc/usbsevseg.c: In function 'set_attr_textmode':
>> drivers/usb/misc/usbsevseg.c:307: warning: passing argument 1 of
>> '__sysfs_match_string' from incompatible pointer type
include/linux/string.h:146: note: expected 'const char * const*' but
argument is of type 'char **'
vim +/__sysfs_match_string +307 drivers/usb/misc/usbsevseg.c
291 strcat(buf, " ");
292 }
293 }
294 strcat(buf, "\n");
295
296
297 return strlen(buf);
298 }
299
300 static ssize_t set_attr_textmode(struct device *dev,
301 struct device_attribute *attr, const char *buf, size_t count)
302 {
303 struct usb_interface *intf = to_usb_interface(dev);
304 struct usb_sevsegdev *mydev = usb_get_intfdata(intf);
305 int i;
306
> 307 i = __sysfs_match_string(display_textmodes, -1, buf);
308 if (i < 0)
309 return i;
310
311 mydev->textmode = i;
312 update_display_visual(mydev, GFP_KERNEL);
313 return count;
314 }
315
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] usb: gadget: functions: add ftrace export over USB
Hi Felipe, [auto build test ERROR on balbi-usb/next] [also build test ERROR on v4.12-rc4 next-20170609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Felipe-Balbi/usb-gadget-functions-add-ftrace-export-over-USB/20170610-060059 base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/usb/gadget/function/f-trace.c: In function 'ftrace_bind': >> drivers/usb/gadget/function/f-trace.c:271:22: error: assignment from >> incompatible pointer type [-Werror=incompatible-pointer-types] trace->ftrace.write = ftrace_write; ^ cc1: some warnings being treated as errors vim +271 drivers/usb/gadget/function/f-trace.c 265 goto err0; 266 trace->in = ep; 267 268 ftrace_hs_in_desc.bEndpointAddress = ftrace_fs_in_desc.bEndpointAddress; 269 ftrace_ss_in_desc.bEndpointAddress = ftrace_fs_in_desc.bEndpointAddress; 270 > 271 trace->ftrace.write = ftrace_write; 272 273 spin_lock_init(&trace->lock); 274 INIT_WORK(&trace->queue_work, ftrace_queue_work); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v2 2/2] usb: typec: ucsi: Add ACPI driver
On 06/05/2017 07:30 AM, Heikki Krogerus wrote:
Driver for ACPI UCSI interface method. This driver replaces
the previous UCSI driver drivers/usb/misc/ucsi.c.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/misc/Kconfig | 26 --
drivers/usb/misc/Makefile | 1 -
drivers/usb/misc/ucsi.c| 478 -
drivers/usb/misc/ucsi.h| 215 -
drivers/usb/typec/ucsi/Kconfig | 16 ++
drivers/usb/typec/ucsi/Makefile| 2 +
drivers/usb/typec/ucsi/ucsi_acpi.c | 158
7 files changed, 176 insertions(+), 720 deletions(-)
delete mode 100644 drivers/usb/misc/ucsi.c
delete mode 100644 drivers/usb/misc/ucsi.h
create mode 100644 drivers/usb/typec/ucsi/ucsi_acpi.c
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1d1d70d62a19..0f9f25db9163 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,29 +275,3 @@ config USB_CHAOSKEY
To compile this driver as a module, choose M here: the
module will be called chaoskey.
-
-config UCSI
- tristate "USB Type-C Connector System Software Interface driver"
- depends on ACPI
- help
- UCSI driver is meant to be used as a convenience tool for desktop and
- server systems that are not equipped to handle USB in device mode. It
- will always select USB host role for the USB Type-C ports on systems
- that provide UCSI interface.
-
- USB Type-C Connector System Software Interface (UCSI) is a
- specification for an interface that allows the Operating System to
- control the USB Type-C ports on a system. Things the need controlling
- include the USB Data Role (host or device), and when USB Power
- Delivery is supported, the Power Role (source or sink). With USB
- Type-C connectors, when two dual role capable devices are attached
- together, the data role is selected randomly. Therefore it is
- important to give the OS a way to select the role. Otherwise the user
- would have to unplug and replug in order in order to attempt to swap
- the data and power roles.
-
- The UCSI specification can be downloaded from:
-
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
-
- To compile the driver as a module, choose M here: the module will be
- called ucsi.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index f6ac6c99a6e6..7fdb45fc976f 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -27,7 +27,6 @@ obj-$(CONFIG_USB_HUB_USB251XB)+= usb251xb.o
obj-$(CONFIG_USB_HSIC_USB3503)+= usb3503.o
obj-$(CONFIG_USB_HSIC_USB4604)+= usb4604.o
obj-$(CONFIG_USB_CHAOSKEY)+= chaoskey.o
-obj-$(CONFIG_UCSI) += ucsi.o
obj-$(CONFIG_USB_SISUSBVGA) += sisusbvga/
obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
diff --git a/drivers/usb/misc/ucsi.c b/drivers/usb/misc/ucsi.c
deleted file mode 100644
index 07397bddefa3..
--- a/drivers/usb/misc/ucsi.c
+++ /dev/null
@@ -1,478 +0,0 @@
-/*
- * USB Type-C Connector System Software Interface driver
- *
- * Copyright (C) 2016, Intel Corporation
- * Author: Heikki Krogerus
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-
-#include "ucsi.h"
-
-/* Double the time defined by MIN_TIME_TO_RESPOND_WITH_BUSY */
-#define UCSI_TIMEOUT_MS 20
-
-enum ucsi_status {
- UCSI_IDLE = 0,
- UCSI_BUSY,
- UCSI_ERROR,
-};
-
-struct ucsi_connector {
- int num;
- struct ucsi *ucsi;
- struct work_struct work;
- struct ucsi_connector_capability cap;
-};
-
-struct ucsi {
- struct device *dev;
- struct ucsi_data __iomem *data;
-
- enum ucsi_status status;
- struct completion complete;
- struct ucsi_capability cap;
- struct ucsi_connector *connector;
-
- /* device lock */
- spinlock_t dev_lock;
-
- /* PPM Communication lock */
- struct mutex ppm_lock;
-
- /* PPM communication flags */
- unsigned long flags;
-#define EVENT_PENDING 0
-#define COMMAND_PENDING1
-};
-
-static int ucsi_acpi_cmd(struct ucsi *ucsi, struct ucsi_control *ctrl)
-{
- uuid_le uuid = UUID_LE(0x6f8398c2, 0x7ca4, 0x11e4,
- 0xad, 0x36, 0x63, 0x10, 0x42, 0xb5, 0x00, 0x8f);
- union acpi_object *obj;
-
- ucsi->data->ctrl.raw_cmd = ctrl->raw_cmd;
-
- obj = acpi_evaluate_dsm(ACPI_HANDLE(ucsi->dev), uuid.b, 1, 1, NULL);
- if (!obj) {
- dev_err(ucsi->dev, "%s: failed to evaluate _DSM\n", __func__);
- re
Re: [PATCH v2 1/2] usb: typec: Add support for UCSI interface
On 06/05/2017 07:30 AM, Heikki Krogerus wrote: UCSI - USB Type-C Connector System Software Interface - is a specification that defines set of registers and data structures for controlling the USB Type-C ports. It's designed for systems where an embedded controller (EC) is in charge of the USB Type-C PHY or USB Power Delivery controller. It is designed for systems with EC, but it is not limited to them, and for example some USB Power Delivery controllers will use it as their direct control interface. With UCSI the EC (or USB PD controller) acts as the port manager, implementing all USB Type-C and Power Delivery state machines. The OS can use the interfaces for reading the status of the ports and controlling basic operations like role swapping. The UCSI specification highlights the fact that it does not define the interface method (PCI/I2C/ACPI/etc.). Therefore the driver is implemented as library and every supported interface method needs its own driver. Driver for ACPI is provided in separate patch following this one. The initial driver includes support for all required features from UCSI specification version 1.0 (getting connector capabilities and status, and support for power and data role swapping), but none of the optional UCSI features (alternate modes, power source capabilities, and cable capabilities). Signed-off-by: Heikki Krogerus --- drivers/usb/typec/Kconfig | 2 + drivers/usb/typec/Makefile | 1 + drivers/usb/typec/ucsi/Kconfig | 22 ++ drivers/usb/typec/ucsi/Makefile | 7 + drivers/usb/typec/ucsi/debug.h | 64 drivers/usb/typec/ucsi/trace.c | 2 + drivers/usb/typec/ucsi/trace.h | 143 drivers/usb/typec/ucsi/ucsi.c | 790 drivers/usb/typec/ucsi/ucsi.h | 330 + 9 files changed, 1361 insertions(+) create mode 100644 drivers/usb/typec/ucsi/Kconfig create mode 100644 drivers/usb/typec/ucsi/Makefile create mode 100644 drivers/usb/typec/ucsi/debug.h create mode 100644 drivers/usb/typec/ucsi/trace.c create mode 100644 drivers/usb/typec/ucsi/trace.h create mode 100644 drivers/usb/typec/ucsi/ucsi.c create mode 100644 drivers/usb/typec/ucsi/ucsi.h diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig index dfcfe459b7cf..bc1b7745f1d4 100644 --- a/drivers/usb/typec/Kconfig +++ b/drivers/usb/typec/Kconfig @@ -19,4 +19,6 @@ config TYPEC_WCOVE To compile this driver as module, choose M here: the module will be called typec_wcove +source "drivers/usb/typec/ucsi/Kconfig" + endmenu diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile index b9cb862221af..bc214f15f1b5 100644 --- a/drivers/usb/typec/Makefile +++ b/drivers/usb/typec/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_TYPEC) += typec.o obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o +obj-$(CONFIG_TYPEC_UCSI) += ucsi/ diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig new file mode 100644 index ..679ba6648396 --- /dev/null +++ b/drivers/usb/typec/ucsi/Kconfig @@ -0,0 +1,22 @@ +config TYPEC_UCSI + tristate "USB Type-C Connector System Software Interface driver" + select TYPEC + help + USB Type-C Connector System Software Interface (UCSI) is a + specification for an interface that allows the operating system to + control the USB Type-C ports. On UCSI system the USB Type-C ports + function autonomously by default, but in order to get the status of + the ports and support basic operations like role swapping, the driver + is required. UCSI is available on most of the new Intel based systems + that are equipped with Embedded Controller and USB Type-C ports. + + UCSI specification does not define the interface method, so depending + on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this + driver only provides the core part, and separate drivers are needed + for every supported interface method. + + The UCSI specification can be downloaded from: + http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html + + To compile the driver as a module, choose M here: the module will be + called typec_ucsi. diff --git a/drivers/usb/typec/ucsi/Makefile b/drivers/usb/typec/ucsi/Makefile new file mode 100644 index ..87dd6ee6c9f3 --- /dev/null +++ b/drivers/usb/typec/ucsi/Makefile @@ -0,0 +1,7 @@ +CFLAGS_trace.o := -I$(src) + +obj-$(CONFIG_TYPEC_UCSI) += typec_ucsi.o + +typec_ucsi-y := ucsi.o + +typec_ucsi-$(CONFIG_FTRACE)+= trace.o diff --git a/drivers/usb/typec/ucsi/debug.h b/drivers/usb/typec/ucsi/debug.h new file mode 100644 index ..87d0cd20597a --- /dev/null +++ b/drivers/usb/typec/ucsi/debug.h @@ -0,0 +1,64 @@ +#ifndef __UCSI_DEBUG_H +#define __UCSI_DEBUG_H + +#include "ucsi.h" + +static const ch
Re: [PATCH v1] usb: misc: usbsevseg: Use __sysfs_match_string() helper
Hi Andy,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/usb-misc-usbsevseg-Use-__sysfs_match_string-helper/20170610-055240
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/usb/misc/usbsevseg.c: In function 'set_attr_textmode':
>> drivers/usb/misc/usbsevseg.c:307:27: error: passing argument 1 of
>> '__sysfs_match_string' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
i = __sysfs_match_string(display_textmodes, -1, buf);
^
In file included from include/linux/bitmap.h:8:0,
from include/linux/cpumask.h:11,
from arch/x86/include/asm/cpumask.h:4,
from arch/x86/include/asm/msr.h:10,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:37,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:80,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from drivers/usb/misc/usbsevseg.c:15:
include/linux/string.h:146:5: note: expected 'const char * const*' but
argument is of type 'char **'
int __sysfs_match_string(const char * const *array, size_t n, const char
*s);
^~~~
cc1: some warnings being treated as errors
vim +/__sysfs_match_string +307 drivers/usb/misc/usbsevseg.c
301 struct device_attribute *attr, const char *buf, size_t count)
302 {
303 struct usb_interface *intf = to_usb_interface(dev);
304 struct usb_sevsegdev *mydev = usb_get_intfdata(intf);
305 int i;
306
> 307 i = __sysfs_match_string(display_textmodes, -1, buf);
308 if (i < 0)
309 return i;
310
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH net-next 00/11] r8152: minor adjustment
From: Hayes Wang Date: Fri, 9 Jun 2017 17:11:37 +0800 > Adjust some code to make it reasonable or satisfy the suggestion from > the engineers. Series applied, thank you. -- 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/gadget: potential deadlock in gadgetfs_suspend
On Fri, 9 Jun 2017, Andrey Konovalov wrote:
> On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov
> wrote:
> > Hi,
> >
> > I'm getting some hangs while fuzzing the kernel with syzkaller.
> >
> > Possibly it happens during the execution of the following syzkaller program:
> >
> > mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
> > 0x, 0x0)
> > r0 =
> > open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
> > 0xc002, 0x0)
> > r1 =
> > open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
> > 0x1, 0x102)
> > write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
> > 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
I don't understand these large constants. They're supposed to be __u8
values. Do they get truncated to the least significant byte?
> > 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
> > 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
> > 0x31)
> >
> > I haven't managed to get the exact same stack trace (or any at all
> > actually) while trying to reproduce the bug with this program, but the
> > kernel definitely hangs.
Can you get a usbmon trace for the test? And can you enable debugging
for the usbcore module?
echo "module usbcore =p" >/sys/kernel/debug/dynamic_debug/control
> > On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
> > Alan's patch applied.
> >
> > gadgetfs: bound to dummy_udc driver
> > gadgetfs: suspended from state 2
> > INFO: rcu_sched detected stalls on CPUs/tasks:
> > 1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706
> > fqs=5250
> > (detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
> > Sending NMI from CPU 2 to CPUs 1:
> > NMI backtrace for cpu 1
> > CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> > Workqueue: usb_hub_wq hub_event
> > task: 88003ebfb640 task.stack: c900024fc000
> > RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
> > RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
> > RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
> > RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0
> > kernel/locking/qspinlock.c:421
> > RSP: 0018:c900024ff9f0 EFLAGS: 0002
> > RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
> > RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
> > RBP: c900024ff9f0 R08: 0006 R09: 0020
> > R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
> > R13: R14: R15: 82cfc5a0
> > FS: () GS:88003ed0() knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
> > Call Trace:
> > __raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
> > _raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
> > spin_lock include/linux/spinlock.h:299 [inline]
> > gadgetfs_suspend+0x32/0x90 drivers/usb/gadget/legacy/inode.c:1684
Looks like it's waiting for the spinlock in gadgetfs_suspend. Nothing
else should be holding that lock.
Were any other tasks stalled?
> > set_link_state+0x39c/0x440 drivers/usb/gadget/udc/dummy_hcd.c:455
> > dummy_hub_control+0x3e7/0x650 drivers/usb/gadget/udc/dummy_hcd.c:2074
> > rh_call_control drivers/usb/core/hcd.c:689 [inline]
> > rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
> > usb_hcd_submit_urb+0x327/0xcf0 drivers/usb/core/hcd.c:1650
> > usb_submit_urb+0x355/0x6f0 drivers/usb/core/urb.c:542
> > usb_start_wait_urb+0x5f/0x110 drivers/usb/core/message.c:56
> > usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
> > usb_control_msg+0xd9/0x120 drivers/usb/core/message.c:151
> > usb_clear_port_feature+0x46/0x60 drivers/usb/core/hub.c:412
> > hub_port_disable+0x65/0x1d0 drivers/usb/core/hub.c:4177
> > hub_port_init+0x10a/0xee0 drivers/usb/core/hub.c:4648
> > hub_port_connect drivers/usb/core/hub.c:4826 [inline]
> > hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
> > port_event drivers/usb/core/hub.c:5105 [inline]
> > hub_event+0xa0b/0x16e0 drivers/usb/core/hub.c:5189
> > process_one_work+0x1fb/0x4c0 kernel/workqueue.c:2097
> > process_scheduled_works kernel/workqueue.c:2157 [inline]
> > worker_thread+0x2ab/0x4c0 kernel/workqueue.c:2233
> > kthread+0x140/0x160 kernel/kthread.c:231
> > ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:424
> > Code: 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 ba
> > 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90
> > ec 81 fe 00 01 00 00 0f 84 92 00 00 00 41 b8 01 01 00 00 b9
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 major
Re: [PATCH 11/11] USB: usbip: convert to use DRIVER_ATTR_RW
On 06/09/2017 03:03 AM, Greg Kroah-Hartman wrote:
> We are trying to get rid of DRIVER_ATTR(), and the usbip driver
> attribute can be trivially changed to use DRIVER_ATTR_RW().
>
> Cc: Valentina Manea
> Cc: Shuah Khan
> Cc:
> Signed-off-by: Greg Kroah-Hartman
Looks good to me.
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> drivers/usb/usbip/stub_main.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
> index 44ab43fc4fcc..e74fbb7f4a32 100644
> --- a/drivers/usb/usbip/stub_main.c
> +++ b/drivers/usb/usbip/stub_main.c
> @@ -134,7 +134,7 @@ int del_match_busid(char *busid)
> return ret;
> }
>
> -static ssize_t show_match_busid(struct device_driver *drv, char *buf)
> +static ssize_t match_busid_show(struct device_driver *drv, char *buf)
> {
> int i;
> char *out = buf;
> @@ -149,7 +149,7 @@ static ssize_t show_match_busid(struct device_driver
> *drv, char *buf)
> return out - buf;
> }
>
> -static ssize_t store_match_busid(struct device_driver *dev, const char *buf,
> +static ssize_t match_busid_store(struct device_driver *dev, const char *buf,
>size_t count)
> {
> int len;
> @@ -181,8 +181,7 @@ static ssize_t store_match_busid(struct device_driver
> *dev, const char *buf,
>
> return -EINVAL;
> }
> -static DRIVER_ATTR(match_busid, S_IRUSR | S_IWUSR, show_match_busid,
> -store_match_busid);
> +static DRIVER_ATTR_RW(match_busid);
>
> static ssize_t rebind_store(struct device_driver *dev, const char *buf,
>size_t count)
>
--
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] usb: gadget: functions: add ftrace export over USB
On Fri, 09 Jun 2017 17:05:52 +0300 Felipe Balbi wrote: > Hi, > > Steven Rostedt writes: > > On Fri, 9 Jun 2017 09:13:27 +0300 > > Felipe Balbi wrote: > > > >> Allow for ftrace data to be exported over a USB Gadget > >> Controller. With this, we have a potentially very fast pipe for > >> transmitting ftrace data to a Host PC for further analysis. > >> > >> Note that in order to decode the data, one needs access to kernel > >> symbols in order to convert binary data into function names and what > >> not. > >> > > > > Can you please explain what this is in a bit more detail. I have no > > idea what you are trying to accomplish. > > this is just another ftrace export. Just like STM > (drivers/hwtracing/stm/ftrace.c), but I'm making use of a USB Peripheral > Controller that may be available. > > > Also, do you mean ftrace as the internal Linux tracer (which should > > only be called "ftrace" or sometimes "Ftrace" but not "f_trace" or > > "FTrace", that just leads to more confusion. > > heh, internal linux ftrace ;-) The driver name (f-trace.c) is just to > follow the convention of USB functions being name f_*.c or f-*.c. I > could call it f-ftrace.c, but seemed unnecessary. OK, looking at the other files and functions in drivers/usb/gadget/function, I see that F there is part of usb process. OK, although it does make it somewhat confusing. -- Steve -- 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/gadget: potential deadlock in gadgetfs_suspend
On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov wrote:
> Hi,
>
> I'm getting some hangs while fuzzing the kernel with syzkaller.
>
> Possibly it happens during the execution of the following syzkaller program:
>
> mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
> 0x, 0x0)
> r0 =
> open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
> 0xc002, 0x0)
> r1 =
> open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
> 0x1, 0x102)
> write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
> 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
> 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
> 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
> 0x31)
>
> I haven't managed to get the exact same stack trace (or any at all
> actually) while trying to reproduce the bug with this program, but the
> kernel definitely hangs.
>
> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
> Alan's patch applied.
>
> gadgetfs: bound to dummy_udc driver
> gadgetfs: suspended from state 2
> INFO: rcu_sched detected stalls on CPUs/tasks:
> 1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706
> fqs=5250
> (detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
> Sending NMI from CPU 2 to CPUs 1:
> NMI backtrace for cpu 1
> CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> task: 88003ebfb640 task.stack: c900024fc000
> RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
> RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
> RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
> RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0 kernel/locking/qspinlock.c:421
> RSP: 0018:c900024ff9f0 EFLAGS: 0002
> RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
> RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
> RBP: c900024ff9f0 R08: 0006 R09: 0020
> R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
> R13: R14: R15: 82cfc5a0
> FS: () GS:88003ed0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
> Call Trace:
> __raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
> _raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
> spin_lock include/linux/spinlock.h:299 [inline]
> gadgetfs_suspend+0x32/0x90 drivers/usb/gadget/legacy/inode.c:1684
> set_link_state+0x39c/0x440 drivers/usb/gadget/udc/dummy_hcd.c:455
> dummy_hub_control+0x3e7/0x650 drivers/usb/gadget/udc/dummy_hcd.c:2074
> rh_call_control drivers/usb/core/hcd.c:689 [inline]
> rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
> usb_hcd_submit_urb+0x327/0xcf0 drivers/usb/core/hcd.c:1650
> usb_submit_urb+0x355/0x6f0 drivers/usb/core/urb.c:542
> usb_start_wait_urb+0x5f/0x110 drivers/usb/core/message.c:56
> usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
> usb_control_msg+0xd9/0x120 drivers/usb/core/message.c:151
> usb_clear_port_feature+0x46/0x60 drivers/usb/core/hub.c:412
> hub_port_disable+0x65/0x1d0 drivers/usb/core/hub.c:4177
> hub_port_init+0x10a/0xee0 drivers/usb/core/hub.c:4648
> hub_port_connect drivers/usb/core/hub.c:4826 [inline]
> hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
> port_event drivers/usb/core/hub.c:5105 [inline]
> hub_event+0xa0b/0x16e0 drivers/usb/core/hub.c:5189
> process_one_work+0x1fb/0x4c0 kernel/workqueue.c:2097
> process_scheduled_works kernel/workqueue.c:2157 [inline]
> worker_thread+0x2ab/0x4c0 kernel/workqueue.c:2233
> kthread+0x140/0x160 kernel/kthread.c:231
> ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:424
> Code: 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 ba
> 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90
> ec 81 fe 00 01 00 00 0f 84 92 00 00 00 41 b8 01 01 00 00 b9
Here are a few similar reports:
gadgetfs: bound to dummy_udc driver
gadgetfs: suspended from state 2
BUG: spinlock bad magic on CPU#3, kworker/3:1/222
lock: 0x88003cdb9a70, .magic: dead4ead, .owner: /-1, .owner_cpu: -1
CPU: 3 PID: 222 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x8e/0xcd lib/dump_stack.c:52
spin_dump+0x73/0xd0 kernel/locking/spinlock_debug.c:67
spin_bug kernel/locking/spinlock_debug.c:75 [inline]
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x6d/0xb0 kernel/locking/spinlock_debug.c:112
__raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
_raw_spin
Re: [PATCH 0/3] USB: add API for interface driver to vote for autosuspend
On Thu, 8 Jun 2017, Yueyao Zhu wrote: > From: Yueyao Zhu > > Currently, if a USB driver would like to enable autosuspend on the USB > device, usb_enable_autosuspend() seems to be the only option. However, > this acts on the device level, and other interfaces might not desire > to autosuspend the USB device. > > For example, for the usb digital audio driver to enable autosuspend on > a device, calling usb_enable_autosuspend() from the interface driver > might not be a good idea as the USB device might have a keyboard HID > interface which generally doesn't handle autosupend very well. > > This patch series introduces an API for interface driver to vote > for autosuspend on the interface, and when all interfaces agree to > it, autosuspend can then be enabled on the usb device. The whole idea of this seems questionable. USB interface drivers are generally not supposed to enable or disable autosuspend -- that is a policy decision left up to userspace. There are a few exceptions for things like hubs, but this is generally true. Why should the USB digital audio driver want to enable autosuspend? 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: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller
On Fri, 9 Jun 2017, Kai-Heng Feng wrote:
> As Alan Stern points out [1], the PME signal is not enabled when
> controller is in D3, therefore it's not being woken up when new deivces
> get plugged in.
>
> Workaround this bug by preventing the controller enters D3 power state.
>
> [1] https://www.spinics.net/lists/linux-usb/msg157462.html
>
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/usb/host/ehci-pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
> index 93326974ff4b..616685f83954 100644
> --- a/drivers/usb/host/ehci-pci.c
> +++ b/drivers/usb/host/ehci-pci.c
> @@ -181,6 +181,8 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
> if (pdev->device == 0x7808) {
> ehci->use_dummy_qh = 1;
> ehci_info(ehci, "applying AMD SB700/SB800/Hudson-2/3
> EHCI dummy qh workaround\n");
> +
> + pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
> }
> break;
> case PCI_VENDOR_ID_VIA:
Is this really the right solution? Maybe it would be better to allow
the controller to go into D3 provided no wakeup signal is needed. You
could do:
device_set_wakeup_capable(&pdev->dev, 0);
Another alternative is to put the controller into D2 instead of D3, but
(1) I don't know how to do that, and (2) we don't know if wakeup
signalling works any better in D2 than it does in D3.
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: Continuous, infinite warm reset attempts in Chipidea HDRC on multiple connect-disconects
On Fri, 9 Jun 2017, lingareddy praneethreddy wrote: > Thanks Alan. I understand and agree. > > It is a legacy platform that we are supporting and I needed to address > this issue on 3.10.17. We are in the process of migrating to 4.1.x > this coming week to check on this behavior. Until then can you help us > with the one thing i.e. can you point me to where in the latest kernel > code is the warm reset initiated? Thanks again. You might try looking at check_port_resume_type() in hub.c, together with the routines that it calls and the routines that call it. 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: [PATCH] HID: let generic driver yield control iff specific driver has been enabled (was Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works)
Hi,
On 09-06-17 13:25, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
From: Jiri Kosina
Subject: [PATCH] HID: let generic driver yield control iff specific driver has
been enabled
There are many situations where generic HID driver provides some basic level
of support for certain device, but later this support (usually by implementing
vendor-specific extensions of HID protocol) is extended and the support moved
over to a separate (usually per-vendor) specific driver.
This might bring a rather unpleasant suprise for users, as all of a sudden
there is a new config option they have to enable in order to get any support
for their device whatsoever, although previous kernel versions provided basic
support through the generic driver. Which is rightfully seen as a regression.
Fix this by including the entry for a particular device in
hid_have_special_driver[] iff the specific config option has been specified,
and let generic driver handle the device otherwise.
Also make the behavior of hid_scan_report() (where the same decision is being
taken on a per-report level) consistent.
While at it, reshuffle the hid_have_special_driver[] a bit to restore the
alphabetical ordering (first order by config option, and within those
sections order by VID).
This is considered a short-term solution, before generic way of giving
precedence to special drivers and falling back to generic driver is
figured out.
Signed-off-by: Jiri Kosina
So I've decided to just go ahead and give this patch a second pair
of eyes, it is mostly good, but I did find some issues, comments
inline.
---
drivers/hid/hid-core.c | 260 ++---
1 file changed, 205 insertions(+), 55 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 04cee65531d7..8571a46e41ea 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -826,11 +826,35 @@ static int hid_scan_report(struct hid_device *hid)
* hid-rmi should take care of them,
* not hid-generic
*/
- if (IS_ENABLED(CONFIG_HID_RMI))
- hid->group = HID_GROUP_RMI;
+ hid->group = HID_GROUP_RMI;
break;
}
+ /* fall back to generic driver in case specific driver doesn't exist */
+ switch (hid->group) {
+ case HID_GROUP_MULTITOUCH_WIN_8:
+ /* fall-through */
+ case HID_GROUP_MULTITOUCH:
+ if (!IS_ENABLED(CONFIG_HID_MULTITOUCH))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_SENSOR_HUB:
+ if (!IS_ENABLED(CONFIG_HID_SENSOR_HUB))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_RMI:
+ if (!IS_ENABLED(CONFIG_HID_RMI))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_WACOM:
+ if (!IS_ENABLED(CONFIG_HID_WACOM))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_LOGITECH_DJ_DEVICE:
+ if (!IS_ENABLED(CONFIG_HID_LOGITECH_DJ))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ }
vfree(parser);
return 0;
}
@@ -1763,15 +1787,23 @@ EXPORT_SYMBOL_GPL(hid_disconnect);
* used as a driver. See hid_scan_report().
*/
static const struct hid_device_id hid_have_special_driver[] = {
+#if IS_ENABLED(CONFIG_HID_A4TECH)
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_RP_649) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ACCUTOUCH)
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ACRUX)
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ALPS)
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_ALPS_JP,
HID_DEVICE_ID_ALPS_U1_DUAL) },
+#endif
+#if IS_ENABLED(CONFIG_HID_APPLE)
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE)
},
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICMOUSE) },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICTRACKPAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO)
},
{ HID_
Re: Gadget driver & virtual hub
On Fri, 9 Jun 2017, Benjamin Herrenschmidt wrote: > On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote: > > On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote: > > > > > Another question ... > > > > > > Do i need to support dequeue() on EP0 ? > > > > Yes. I don't know if any drivers ever dequeue requests from ep0, but > > it should be supported. > > Talking of which... what is the expected "semantic" of dequeue of > an active request ? (Either on EP0 or another EP, but on EP0 a queued > request becomes active pretty much right away). > > By active I mean the request has started transferring. > > I assume I should interrupt it on a packet boundary... do I also need > to finish with a short packet for a IN request or leave the pipe alone > in whatever half-baked state it is ? This is unspecified in the API. You can do pretty much whatever you want; a transfer that gets cancelled in the middle is going to need some sort of error recovery on the host side no matter what. 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: [PATCH] usb: gadget: functions: add ftrace export over USB
Hi, Steven Rostedt writes: > On Fri, 9 Jun 2017 09:13:27 +0300 > Felipe Balbi wrote: > >> Allow for ftrace data to be exported over a USB Gadget >> Controller. With this, we have a potentially very fast pipe for >> transmitting ftrace data to a Host PC for further analysis. >> >> Note that in order to decode the data, one needs access to kernel >> symbols in order to convert binary data into function names and what >> not. >> > > Can you please explain what this is in a bit more detail. I have no > idea what you are trying to accomplish. this is just another ftrace export. Just like STM (drivers/hwtracing/stm/ftrace.c), but I'm making use of a USB Peripheral Controller that may be available. > Also, do you mean ftrace as the internal Linux tracer (which should > only be called "ftrace" or sometimes "Ftrace" but not "f_trace" or > "FTrace", that just leads to more confusion. heh, internal linux ftrace ;-) The driver name (f-trace.c) is just to follow the convention of USB functions being name f_*.c or f-*.c. I could call it f-ftrace.c, but seemed unnecessary. > Or is this to do with http://www.ftrace.com/en/gb, a way to trace > produce ;-) heh :-) unlikely -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: gadget: functions: add ftrace export over USB
On Fri, 9 Jun 2017 09:13:27 +0300
Felipe Balbi wrote:
> Allow for ftrace data to be exported over a USB Gadget
> Controller. With this, we have a potentially very fast pipe for
> transmitting ftrace data to a Host PC for further analysis.
>
> Note that in order to decode the data, one needs access to kernel
> symbols in order to convert binary data into function names and what
> not.
>
Can you please explain what this is in a bit more detail. I have no
idea what you are trying to accomplish.
Also, do you mean ftrace as the internal Linux tracer (which should
only be called "ftrace" or sometimes "Ftrace" but not "f_trace" or
"FTrace", that just leads to more confusion.
Or is this to do with http://www.ftrace.com/en/gb, a way to trace
produce ;-)
-- Steve
> Signed-off-by: Felipe Balbi
> ---
>
> I wanted to take this through the gadget tree, but there is a
> dependency with a previous patch of mine adding and extra argument to
> the ->write() function. Hoping someone else will take it.
>
> drivers/usb/gadget/Kconfig| 15 ++
> drivers/usb/gadget/function/Makefile | 2 +
> drivers/usb/gadget/function/f-trace.c | 400
> ++
> 3 files changed, 417 insertions(+)
> create mode 100644 drivers/usb/gadget/function/f-trace.c
>
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index c164d6b788c3..617921f19b5e 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -188,6 +188,9 @@ config USB_F_MASS_STORAGE
> config USB_F_FS
> tristate
>
> +config USB_F_TRACE
> + tristate
> +
> config USB_F_UAC1
> tristate
>
> @@ -362,6 +365,18 @@ config USB_CONFIGFS_F_FS
> implemented in kernel space (for instance Ethernet, serial or
> mass storage) and other are implemented in user space.
>
> +config USB_CONFIGFS_F_TRACE
> + bool "Linux FTrace Export Over USB"
> + depends on USB_CONFIGFS
> + select USB_F_TRACE
> + help
> + The Linux FTrace Export Over USB lets one export ftrace buffer
> + over a USB cable to a host computer for further processing.
> +
> + If you want support for that, say Y or M here. Otherwise say N.
> +
> + If unsure, say N.
> +
> config USB_CONFIGFS_F_UAC1
> bool "Audio Class 1.0"
> depends on USB_CONFIGFS
> diff --git a/drivers/usb/gadget/function/Makefile
> b/drivers/usb/gadget/function/Makefile
> index cb8c225e8549..1433e8ad7675 100644
> --- a/drivers/usb/gadget/function/Makefile
> +++ b/drivers/usb/gadget/function/Makefile
> @@ -46,3 +46,5 @@ usb_f_printer-y := f_printer.o
> obj-$(CONFIG_USB_F_PRINTER) += usb_f_printer.o
> usb_f_tcm-y := f_tcm.o
> obj-$(CONFIG_USB_F_TCM) += usb_f_tcm.o
> +usb_f_trace-y:= f-trace.o
> +obj-$(CONFIG_USB_F_TRACE)+= usb_f_trace.o
> diff --git a/drivers/usb/gadget/function/f-trace.c
> b/drivers/usb/gadget/function/f-trace.c
> new file mode 100644
> index ..7de92950c0e7
> --- /dev/null
> +++ b/drivers/usb/gadget/function/f-trace.c
> @@ -0,0 +1,400 @@
> +/*
> + * f_trace.c -- USB FTrace Export
> + *
> + * Copyright (C) 2017 Intel Corporation
> + * Author: Felipe Balbi
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License v2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct usb_ftrace {
> + struct trace_export ftrace;
> + struct usb_function function;
> + struct work_struct queue_work;
> + spinlock_t lock;
> +
> + struct list_head list;
> + struct list_head pending;
> + struct list_head queued;
> +
> + struct usb_ep *in;
> +
> + u8 intf_id;
> +};
> +#define ftrace_to_trace(f) (container_of((f), struct usb_ftrace, ftrace))
> +#define work_to_trace(w) (container_of((w), struct usb_ftrace,
> queue_work))
> +#define to_trace(f) (container_of((f), struct usb_ftrace, function))
> +
> +#define FTRACE_REQUEST_QUEUE_LENGTH 250
> +
> +static inline struct usb_request *next_request(struct list_head *list)
> +{
> + return list_first_entry_or_null(list, struct usb_request, list);
> +}
> +
> +struct usb_ftrace_opts {
> + struct usb_function_instance func_inst;
> +};
> +#define to_opts(fi) (container_of((fi), struct usb_ftrace_opts, func_inst))
> +
> +static struct usb_interface_descriptor ftrace_intf_desc = {
> + .bLength= USB_DT_INTERFACE_SIZE,
> + .bDescriptorType= USB_DT_INTERFACE,
> +
> + .bAlternateSetting = 0,
> + .bNumEndpoints = 1,
> + .bInterfaceClass= USB_CLASS_VENDOR_SPEC,
> + .bInterfaceSubClass = USB_SUBCLASS_VENDOR_SPEC,
> +};
> +
> +/* Super-Speed Support */
> +static struct usb_endpoint_descriptor ftrac
Re: Possible bug in usb_gadget_ep_match_desc()
Hi,
Benjamin Herrenschmidt writes:
> Another one popped to my eyes.
>
> The following test in usb_gadget_ep_match_desc()
> (in udc core.c)
>
> /* "high bandwidth" works only at high speed */
> if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
> return 0;
seems like this was left out when I introduced usb_endpoint_maxp_mult()
> If you look at the definition of usb_endpoint_maxp() however:
>
> static inline int usb_endpoint_maxp(const struct usb_endpoint_descriptor *epd)
> {
> return __le16_to_cpu(epd->wMaxPacketSize) & USB_ENDPOINT_MAXP_MASK;
> }
>
> And we have:
>
> #define USB_ENDPOINT_MAXP_MASK0x07ff
>
> I suspect the test should have been:
>
> /* "high bandwidth" works only at high speed */
> if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp_mult(desc) > 1)
> return 0;
>
> But I'm not completely certain as I'm not very familiar with USB3, so
> I'll let you guys figure that out :-)
care to send this as a proper patch?
--
balbi
signature.asc
Description: PGP signature
Possible bug in usb_gadget_ep_match_desc()
Another one popped to my eyes.
The following test in usb_gadget_ep_match_desc()
(in udc core.c)
/* "high bandwidth" works only at high speed */
if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
return 0;
If you look at the definition of usb_endpoint_maxp() however:
static inline int usb_endpoint_maxp(const struct usb_endpoint_descriptor *epd)
{
return __le16_to_cpu(epd->wMaxPacketSize) & USB_ENDPOINT_MAXP_MASK;
}
And we have:
#define USB_ENDPOINT_MAXP_MASK 0x07ff
I suspect the test should have been:
/* "high bandwidth" works only at high speed */
if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp_mult(desc) > 1)
return 0;
But I'm not completely certain as I'm not very familiar with USB3, so
I'll let you guys figure that out :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] New driver for UCSI (USB Type-C)
On 06/09/2017 04:03 AM, Heikki Krogerus wrote: Hi Guenter, On Mon, Jun 05, 2017 at 05:30:22PM +0300, Heikki Krogerus wrote: Hi, This moves the current ucsi driver from drivers/usb/misc/ucsi.c to the new USB Type-C class (drivers/usb/typec/). That allows us to finally do role swapping. The driver is now split into core library part, and ACPI driver. That should make it easy to add support for other interface methods (first most likely being I2C) later if needed. Changes since v1: - Added separate flag from pending ACK. Some new platforms generate "command complete" event on top of the normal "ACK complete" event with ACK commands. In such cases the driver has to be able to basically ignore the command completion in case of ACK and only finish acknowledge routine when the actual ACK complete event is received. Otherwise a new command may be queued to the PPM before the previous has fully completed. - Added an explanation why we are handling the PPM initialization in a work as suggested by Guenter. - Fixed ucsi_reset_ppm() by removing possibility of returning -ETIMEDOUT in case of success right before the time expires. Suggested by Guenter. - Replaced useless "goto err;" with "break;" in ucsi_run_command() as suggested by Guenter. - Removed traceback in case of failure from ucsi_run_command() which is not necessary as suggested by Guenter. - Highlighting the fact that the timeouts are in milliseconds by using _MS ending with the definition (UCSI_TIMEOUT_MS and UCSI_SWAP_TIMEOUT_MS) as suggested by Guenter. - Including also in ucsi.h as suggested by Guenter. - In ucsi_acpi.c, explicitly pointing out in the comment that we can not use devm_ioremap_resource() as suggested by Guenter. Heikki Krogerus (2): usb: typec: Add support for UCSI interface usb: typec: ucsi: Add ACPI driver Gentle ping. Are these OK now? I am far behind, sorry :-(. I'll try to get to it today or during the weekend. Guenter -- 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] HID: let generic driver yield control iff specific driver has been enabled (was Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works)
Hi,
On 09-06-17 15:00, Benjamin Tissoires wrote:
On Jun 09 2017 or thereabouts, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
From: Jiri Kosina
Subject: [PATCH] HID: let generic driver yield control iff specific driver has
been enabled
There are many situations where generic HID driver provides some basic level
of support for certain device, but later this support (usually by implementing
vendor-specific extensions of HID protocol) is extended and the support moved
over to a separate (usually per-vendor) specific driver.
This might bring a rather unpleasant suprise for users, as all of a sudden
there is a new config option they have to enable in order to get any support
for their device whatsoever, although previous kernel versions provided basic
support through the generic driver. Which is rightfully seen as a regression.
Fix this by including the entry for a particular device in
hid_have_special_driver[] iff the specific config option has been specified,
and let generic driver handle the device otherwise.
Also make the behavior of hid_scan_report() (where the same decision is being
taken on a per-report level) consistent.
While at it, reshuffle the hid_have_special_driver[] a bit to restore the
alphabetical ordering (first order by config option, and within those
sections order by VID).
This is considered a short-term solution, before generic way of giving
precedence to special drivers and falling back to generic driver is
figured out.
Signed-off-by: Jiri Kosina
---
Thanks for the quick band-aid.
Same as Hans: I started checking the VID/PID with the drivers
association, and got bored after a few.
Thinking a bit more about this I've actually decided that it would be good to do
a manual check, I've already started with that and I've found some issues, I'm
still
going though the entire list, I will send out a reply with all issues found when
I've finished the entire list (I just completed reviewing the logitech entries).
Regards,
Hans
I _think_ you automated the thing with some script, so the association
should be correct.
Acked-By: Benjamin Tissoires
Cheers,
Benjamin
drivers/hid/hid-core.c | 260 ++---
1 file changed, 205 insertions(+), 55 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 04cee65531d7..8571a46e41ea 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -826,11 +826,35 @@ static int hid_scan_report(struct hid_device *hid)
* hid-rmi should take care of them,
* not hid-generic
*/
- if (IS_ENABLED(CONFIG_HID_RMI))
- hid->group = HID_GROUP_RMI;
+ hid->group = HID_GROUP_RMI;
break;
}
+ /* fall back to generic driver in case specific driver doesn't exist */
+ switch (hid->group) {
+ case HID_GROUP_MULTITOUCH_WIN_8:
+ /* fall-through */
+ case HID_GROUP_MULTITOUCH:
+ if (!IS_ENABLED(CONFIG_HID_MULTITOUCH))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_SENSOR_HUB:
+ if (!IS_ENABLED(CONFIG_HID_SENSOR_HUB))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_RMI:
+ if (!IS_ENABLED(CONFIG_HID_RMI))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_WACOM:
+ if (!IS_ENABLED(CONFIG_HID_WACOM))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_LOGITECH_DJ_DEVICE:
+ if (!IS_ENABLED(CONFIG_HID_LOGITECH_DJ))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ }
vfree(parser);
return 0;
}
@@ -1763,15 +1787,23 @@ EXPORT_SYMBOL_GPL(hid_disconnect);
* used as a driver. See hid_scan_report().
*/
static const struct hid_device_id hid_have_special_driver[] = {
+#if IS_ENABLED(CONFIG_HID_A4TECH)
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_RP_649) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ACCUTOUCH)
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ACRUX)
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ALPS)
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY
Re: usb/gadget: potential deadlock in gadgetfs_suspend
On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov wrote:
> Hi,
>
> I'm getting some hangs while fuzzing the kernel with syzkaller.
>
> Possibly it happens during the execution of the following syzkaller program:
>
> mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
> 0x, 0x0)
> r0 =
> open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
> 0xc002, 0x0)
> r1 =
> open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
> 0x1, 0x102)
> write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
> 0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
> 0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
> 0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
> 0x31)
>
> I haven't managed to get the exact same stack trace (or any at all
> actually) while trying to reproduce the bug with this program, but the
> kernel definitely hangs.
Never mind, this program is unrelated to the hang.
>
> On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
> Alan's patch applied.
>
> gadgetfs: bound to dummy_udc driver
> gadgetfs: suspended from state 2
> INFO: rcu_sched detected stalls on CPUs/tasks:
> 1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706
> fqs=5250
> (detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
> Sending NMI from CPU 2 to CPUs 1:
> NMI backtrace for cpu 1
> CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> task: 88003ebfb640 task.stack: c900024fc000
> RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
> RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
> RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
> RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0 kernel/locking/qspinlock.c:421
> RSP: 0018:c900024ff9f0 EFLAGS: 0002
> RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
> RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
> RBP: c900024ff9f0 R08: 0006 R09: 0020
> R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
> R13: R14: R15: 82cfc5a0
> FS: () GS:88003ed0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
> Call Trace:
> __raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
> _raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
> spin_lock include/linux/spinlock.h:299 [inline]
> gadgetfs_suspend+0x32/0x90 drivers/usb/gadget/legacy/inode.c:1684
> set_link_state+0x39c/0x440 drivers/usb/gadget/udc/dummy_hcd.c:455
> dummy_hub_control+0x3e7/0x650 drivers/usb/gadget/udc/dummy_hcd.c:2074
> rh_call_control drivers/usb/core/hcd.c:689 [inline]
> rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
> usb_hcd_submit_urb+0x327/0xcf0 drivers/usb/core/hcd.c:1650
> usb_submit_urb+0x355/0x6f0 drivers/usb/core/urb.c:542
> usb_start_wait_urb+0x5f/0x110 drivers/usb/core/message.c:56
> usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
> usb_control_msg+0xd9/0x120 drivers/usb/core/message.c:151
> usb_clear_port_feature+0x46/0x60 drivers/usb/core/hub.c:412
> hub_port_disable+0x65/0x1d0 drivers/usb/core/hub.c:4177
> hub_port_init+0x10a/0xee0 drivers/usb/core/hub.c:4648
> hub_port_connect drivers/usb/core/hub.c:4826 [inline]
> hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
> port_event drivers/usb/core/hub.c:5105 [inline]
> hub_event+0xa0b/0x16e0 drivers/usb/core/hub.c:5189
> process_one_work+0x1fb/0x4c0 kernel/workqueue.c:2097
> process_scheduled_works kernel/workqueue.c:2157 [inline]
> worker_thread+0x2ab/0x4c0 kernel/workqueue.c:2233
> kthread+0x140/0x160 kernel/kthread.c:231
> ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:424
> Code: 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 ba
> 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90
> ec 81 fe 00 01 00 00 0f 84 92 00 00 00 41 b8 01 01 00 00 b9
--
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] HID: let generic driver yield control iff specific driver has been enabled (was Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works)
On Jun 09 2017 or thereabouts, Jiri Kosina wrote:
> On Fri, 9 Jun 2017, Jiri Kosina wrote:
>
> > This is something I've been wanting to fix for ages, but never really got
> > to it. So let's take this as the final impulse to do it.
>
> So I'd suggest to go with something like the below for 4.12-rc. Hmm?
>
>
>
> From: Jiri Kosina
> Subject: [PATCH] HID: let generic driver yield control iff specific driver
> has been enabled
>
> There are many situations where generic HID driver provides some basic level
> of support for certain device, but later this support (usually by implementing
> vendor-specific extensions of HID protocol) is extended and the support moved
> over to a separate (usually per-vendor) specific driver.
>
> This might bring a rather unpleasant suprise for users, as all of a sudden
> there is a new config option they have to enable in order to get any support
> for their device whatsoever, although previous kernel versions provided basic
> support through the generic driver. Which is rightfully seen as a regression.
>
> Fix this by including the entry for a particular device in
> hid_have_special_driver[] iff the specific config option has been specified,
> and let generic driver handle the device otherwise.
> Also make the behavior of hid_scan_report() (where the same decision is being
> taken on a per-report level) consistent.
>
> While at it, reshuffle the hid_have_special_driver[] a bit to restore the
> alphabetical ordering (first order by config option, and within those
> sections order by VID).
>
> This is considered a short-term solution, before generic way of giving
> precedence to special drivers and falling back to generic driver is
> figured out.
>
> Signed-off-by: Jiri Kosina
> ---
Thanks for the quick band-aid.
Same as Hans: I started checking the VID/PID with the drivers
association, and got bored after a few.
I _think_ you automated the thing with some script, so the association
should be correct.
Acked-By: Benjamin Tissoires
Cheers,
Benjamin
> drivers/hid/hid-core.c | 260
> ++---
> 1 file changed, 205 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 04cee65531d7..8571a46e41ea 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -826,11 +826,35 @@ static int hid_scan_report(struct hid_device *hid)
>* hid-rmi should take care of them,
>* not hid-generic
>*/
> - if (IS_ENABLED(CONFIG_HID_RMI))
> - hid->group = HID_GROUP_RMI;
> + hid->group = HID_GROUP_RMI;
> break;
> }
>
> + /* fall back to generic driver in case specific driver doesn't exist */
> + switch (hid->group) {
> + case HID_GROUP_MULTITOUCH_WIN_8:
> + /* fall-through */
> + case HID_GROUP_MULTITOUCH:
> + if (!IS_ENABLED(CONFIG_HID_MULTITOUCH))
> + hid->group = HID_GROUP_GENERIC;
> + break;
> + case HID_GROUP_SENSOR_HUB:
> + if (!IS_ENABLED(CONFIG_HID_SENSOR_HUB))
> + hid->group = HID_GROUP_GENERIC;
> + break;
> + case HID_GROUP_RMI:
> + if (!IS_ENABLED(CONFIG_HID_RMI))
> + hid->group = HID_GROUP_GENERIC;
> + break;
> + case HID_GROUP_WACOM:
> + if (!IS_ENABLED(CONFIG_HID_WACOM))
> + hid->group = HID_GROUP_GENERIC;
> + break;
> + case HID_GROUP_LOGITECH_DJ_DEVICE:
> + if (!IS_ENABLED(CONFIG_HID_LOGITECH_DJ))
> + hid->group = HID_GROUP_GENERIC;
> + break;
> + }
> vfree(parser);
> return 0;
> }
> @@ -1763,15 +1787,23 @@ EXPORT_SYMBOL_GPL(hid_disconnect);
> * used as a driver. See hid_scan_report().
> */
> static const struct hid_device_id hid_have_special_driver[] = {
> +#if IS_ENABLED(CONFIG_HID_A4TECH)
> { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
> { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
> { HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_RP_649) },
> +#endif
> +#if IS_ENABLED(CONFIG_HID_ACCUTOUCH)
> + { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
> +#endif
> +#if IS_ENABLED(CONFIG_HID_ACRUX)
> { HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
> { HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
> +#endif
> +#if IS_ENABLED(CONFIG_HID_ALPS)
> { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_ALPS_JP,
> HID_DEVICE_ID_ALPS_U1_DUAL) },
> +#endif
> +#if IS_ENABLED(CONFIG_HID_APPLE)
> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE)
> },
> - { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
> USB_DEVICE_ID_APPLE_MAGICMOUSE) },
>
Re: [PATCH v2 2/2] phy: tusb1210: implement ->set_mode()
Hi, Kishon Vijay Abraham I writes: > On Friday 09 June 2017 03:50 PM, Felipe Balbi wrote: >> ->set_mode() can be used to tell PHY to prepare itself to enter USB >> Host/Peripheral mode and that's very important for DRD >> configurations. >> >> Signed-off-by: Felipe Balbi >> >> changes since v1: >> - rebase on PHY -next > > removed this changelog and merged, off-by-1(line) error ;-) thanks -- balbi signature.asc Description: PGP signature
Re: More dynamic EP allocation
On Fri, 2017-06-09 at 14:08 +0300, Felipe Balbi wrote: > > I was originally thinking of having some device-tree construct > > assigning fixed number of EPs from the pool to the various devices, but > > that sucks... > > > > I'm trying to figure out if I can do something more dynamic. > > > > My idea is to not put the EPs in the gadget ep_list at first, but > > provide a match_ep() callback that effectively "allocates" an EP from > > the pool. > > but that's how the framework is implemented. Endpoints are kept in the > ep_list but they aren't allocated until an endpoint match happens. I think you didn't understand the structure of the HW, let me try to explain better: The HW provides a "top level" virtual hub with its own EP0 and EP1 (EP1 is partially HW managed, it's the hub status change interrupts). It then provide 5 "devices" (ie, gadget slots if you want) each with its own EP0. So I my driver effectively creates 5 gadgets. However those share a single global pool of "generic" EPs for all the non-0 endpoints. Those generic EPs can be of any type (bulk, iso, int), any direction, and can be assigned to any EP number (EP address) of any of the 5 devices. Thus I have 5 different EP lists, and I can't link my EPs to more than one at a time :) So I want to be able to "assign" (or "allocate") EPs from that global pool to the gadgets based on the needs of the functions bound to them, roughtly at bind() time since that's a good place to fail if necessary (much better than doing it at endpoint enable()). My idea is to override match_ep (which is easy since my endpoints support all types) so that it picks up an EP from the generic pool, and returns it after adding it to that gadget's list. > > It looks from a cursory glance at the code that it might work, with a > > reasonable failure mode since running out of EPs would typically make > > functions fail at bind() time. > > > > However we're missing a "free" :-) > > We don't need a free. Once a function is unbound, endpoints *must* be > free. No, I need it in order to return the EP to the global pool (and take it out of the gadget's list). > > I *think* (please correct me if I'm wrong) that adding a callback for > > that and plumbing it this way would work, let me know what you think. > > I'm not entirely sure you need it. How else can I deal with my issue ? Cheers, Ben. -- 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
usb/gadget: potential deadlock in gadgetfs_suspend
Hi,
I'm getting some hangs while fuzzing the kernel with syzkaller.
Possibly it happens during the execution of the following syzkaller program:
mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,
0x, 0x0)
r0 = open$usb(&(0x7f001000)="2f6465762f6761646765742f64756d6d795f75646300",
0xc002, 0x0)
r1 = open$usb(&(0x7f002000)="2f6465762f6761646765742f64756d6d795f75646300",
0x1, 0x102)
write$usb(r1, &(0x7f003000)={0x0, {0x9, 0x2, 0x1b, 0x0, 0x5, 0x0,
0x80, 0x8, 0x9, 0x4, 0x1000, 0xfef9, 0x1, 0xff, 0x0,
0x8, 0x80, [{0x9, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}]}, {0x12, 0x1,
0x0, 0x0, 0x4b5, 0x7c, 0x0, 0x3, 0x4, 0x0, 0x8, 0xd686, 0x0, 0x1}},
0x31)
I haven't managed to get the exact same stack trace (or any at all
actually) while trying to reproduce the bug with this program, but the
kernel definitely hangs.
On commit b29794ec95c6856b316c2295904208bf11ffddd9 (4.12-rc4+) with
Alan's patch applied.
gadgetfs: bound to dummy_udc driver
gadgetfs: suspended from state 2
INFO: rcu_sched detected stalls on CPUs/tasks:
1-...: (0 ticks this GP) idle=966/140/0 softirq=37706/37706 fqs=5250
(detected by 2, t=21002 jiffies, g=26575, c=26574, q=183)
Sending NMI from CPU 2 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 1394 Comm: kworker/1:2 Not tainted 4.12.0-rc4+ #24
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 88003ebfb640 task.stack: c900024fc000
RIP: 0010:rep_nop arch/x86/include/asm/processor.h:619 [inline]
RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:624 [inline]
RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:63 [inline]
RIP: 0010:queued_spin_lock_slowpath+0x20/0x1a0 kernel/locking/qspinlock.c:421
RSP: 0018:c900024ff9f0 EFLAGS: 0002
RAX: 7d72e420 RBX: 88007d72e768 RCX: 0001
RDX: 0001 RSI: 7d72e420 RDI: 88007d72e768
RBP: c900024ff9f0 R08: 0006 R09: 0020
R10: c900024ffa50 R11: 00d52301 R12: 88007da9c298
R13: R14: R15: 82cfc5a0
FS: () GS:88003ed0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f728a487000 CR3: 371e6000 CR4: 06e0
Call Trace:
__raw_spin_lock include/asm-generic/qspinlock.h:103 [inline]
_raw_spin_lock+0x1c/0x20 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:299 [inline]
gadgetfs_suspend+0x32/0x90 drivers/usb/gadget/legacy/inode.c:1684
set_link_state+0x39c/0x440 drivers/usb/gadget/udc/dummy_hcd.c:455
dummy_hub_control+0x3e7/0x650 drivers/usb/gadget/udc/dummy_hcd.c:2074
rh_call_control drivers/usb/core/hcd.c:689 [inline]
rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
usb_hcd_submit_urb+0x327/0xcf0 drivers/usb/core/hcd.c:1650
usb_submit_urb+0x355/0x6f0 drivers/usb/core/urb.c:542
usb_start_wait_urb+0x5f/0x110 drivers/usb/core/message.c:56
usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
usb_control_msg+0xd9/0x120 drivers/usb/core/message.c:151
usb_clear_port_feature+0x46/0x60 drivers/usb/core/hub.c:412
hub_port_disable+0x65/0x1d0 drivers/usb/core/hub.c:4177
hub_port_init+0x10a/0xee0 drivers/usb/core/hub.c:4648
hub_port_connect drivers/usb/core/hub.c:4826 [inline]
hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
port_event drivers/usb/core/hub.c:5105 [inline]
hub_event+0xa0b/0x16e0 drivers/usb/core/hub.c:5189
process_one_work+0x1fb/0x4c0 kernel/workqueue.c:2097
process_scheduled_works kernel/workqueue.c:2157 [inline]
worker_thread+0x2ab/0x4c0 kernel/workqueue.c:2233
kthread+0x140/0x160 kernel/kthread.c:231
ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:424
Code: 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 ba
01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90
ec 81 fe 00 01 00 00 0f 84 92 00 00 00 41 b8 01 01 00 00 b9
--
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] usb: gadget: f_mass_storage: Fix the logic to iterate all common->luns
On Fri, Jun 09 2017, Axel Lin wrote:
> It is wrong to do --i in the for loop.
>
> Fixes: dd02ea5a3305 ("usb: gadget: mass_storage: Use static array for luns")
> Signed-off-by: Axel Lin
Acked-by: Michal Nazarewicz
> ---
> drivers/usb/gadget/function/f_mass_storage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/f_mass_storage.c
> b/drivers/usb/gadget/function/f_mass_storage.c
> index 74d57d6..5742813 100644
> --- a/drivers/usb/gadget/function/f_mass_storage.c
> +++ b/drivers/usb/gadget/function/f_mass_storage.c
> @@ -2572,7 +2572,7 @@ static int fsg_main_thread(void *common_)
> int i;
>
> down_write(&common->filesem);
> - for (i = 0; i < ARRAY_SIZE(common->luns); --i) {
> + for (i = 0; i < ARRAY_SIZE(common->luns); i++) {
> struct fsg_lun *curlun = common->luns[i];
> if (!curlun || !fsg_lun_is_open(curlun))
> continue;
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
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 v1] usb: misc: usbsevseg: Use __sysfs_match_string() helper
Use __sysfs_match_string() helper instead of open coded variant.
Cc: Greg Kroah-Hartman
Signed-off-by: Andy Shevchenko
---
drivers/usb/misc/usbsevseg.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/misc/usbsevseg.c b/drivers/usb/misc/usbsevseg.c
index a0ba5298160c..1a8dc093b330 100644
--- a/drivers/usb/misc/usbsevseg.c
+++ b/drivers/usb/misc/usbsevseg.c
@@ -304,15 +304,13 @@ static ssize_t set_attr_textmode(struct device *dev,
struct usb_sevsegdev *mydev = usb_get_intfdata(intf);
int i;
- for (i = 0; display_textmodes[i]; i++) {
- if (sysfs_streq(display_textmodes[i], buf)) {
- mydev->textmode = i;
- update_display_visual(mydev, GFP_KERNEL);
- return count;
- }
- }
+ i = __sysfs_match_string(display_textmodes, -1, buf);
+ if (i < 0)
+ return i;
- return -EINVAL;
+ mydev->textmode = i;
+ update_display_visual(mydev, GFP_KERNEL);
+ return count;
}
static DEVICE_ATTR(textmode, S_IRUGO | S_IWUSR, show_attr_textmode,
set_attr_textmode);
--
2.11.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: mtu3: Handle return value of clk_prepare_enable
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav
---
drivers/usb/mtu3/mtu3_plat.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 42550c7..0d3ebb3 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -458,6 +458,7 @@ static int __maybe_unused mtu3_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct ssusb_mtk *ssusb = platform_get_drvdata(pdev);
+ int ret;
dev_dbg(dev, "%s\n", __func__);
@@ -465,12 +466,28 @@ static int __maybe_unused mtu3_resume(struct device *dev)
return 0;
ssusb_wakeup_disable(ssusb);
- clk_prepare_enable(ssusb->sys_clk);
- clk_prepare_enable(ssusb->ref_clk);
- ssusb_phy_power_on(ssusb);
+ ret = clk_prepare_enable(ssusb->sys_clk);
+ if (ret)
+ goto err_sys_clk;
+
+ ret = clk_prepare_enable(ssusb->ref_clk);
+ if (ret)
+ goto err_ref_clk;
+
+ ret = ssusb_phy_power_on(ssusb);
+ if (ret)
+ goto err_power_on;
+
ssusb_host_enable(ssusb);
return 0;
+
+err_power_on:
+ clk_disable_unprepare(ssusb->ref_clk);
+err_ref_clk:
+ clk_disable_unprepare(ssusb->sys_clk);
+err_sys_clk:
+ return ret;
}
static const struct dev_pm_ops mtu3_pm_ops = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] phy: tusb1210: implement ->set_mode()
On Friday 09 June 2017 03:50 PM, Felipe Balbi wrote:
> ->set_mode() can be used to tell PHY to prepare itself to enter USB
> Host/Peripheral mode and that's very important for DRD
> configurations.
>
> Signed-off-by: Felipe Balbi
>
> changes since v1:
> - rebase on PHY -next
removed this changelog and merged,
Thanks
Kishon
>
>
> ---
> drivers/phy/ti/phy-tusb1210.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
> index 5dbb9a7b4945..b8ec39ac4dfc 100644
> --- a/drivers/phy/ti/phy-tusb1210.c
> +++ b/drivers/phy/ti/phy-tusb1210.c
> @@ -11,6 +11,7 @@
> */
> #include
> #include
> +#include
> #include
> #include
>
> @@ -52,9 +53,43 @@ static int tusb1210_power_off(struct phy *phy)
> return 0;
> }
>
> +static int tusb1210_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct tusb1210 *tusb = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = ulpi_read(tusb->ulpi, ULPI_OTG_CTRL);
> + if (ret < 0)
> + return ret;
> +
> + switch (mode) {
> + case PHY_MODE_USB_HOST:
> + ret |= (ULPI_OTG_CTRL_DRVVBUS_EXT
> + | ULPI_OTG_CTRL_ID_PULLUP
> + | ULPI_OTG_CTRL_DP_PULLDOWN
> + | ULPI_OTG_CTRL_DM_PULLDOWN);
> + ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
> + ret |= ULPI_OTG_CTRL_DRVVBUS;
> + break;
> + case PHY_MODE_USB_DEVICE:
> + ret &= ~(ULPI_OTG_CTRL_DRVVBUS
> + | ULPI_OTG_CTRL_DP_PULLDOWN
> + | ULPI_OTG_CTRL_DM_PULLDOWN);
> + ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
> + ret &= ~ULPI_OTG_CTRL_DRVVBUS_EXT;
> + break;
> + default:
> + /* nothing */
> + return 0;
> + }
> +
> + return ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
> +}
> +
> static const struct phy_ops phy_ops = {
> .power_on = tusb1210_power_on,
> .power_off = tusb1210_power_off,
> + .set_mode = tusb1210_set_mode,
> .owner = THIS_MODULE,
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] phy: tusb1210: add support for TUSB1211
On Friday 09 June 2017 03:50 PM, Felipe Balbi wrote:
> TUSB1211 is software compatible with TUSB1210 and as such we don't
> need an entire new driver to control it. Let's add its product ID to
> the existing TUSB1210 driver instead.
>
> Signed-off-by: Felipe Balbi
merged this series, thanks!
-Kishon
> ---
>
> changes since v1:
> - rebase on PHY -next
>
> drivers/phy/ti/phy-tusb1210.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
> index bb3fb031c478..5dbb9a7b4945 100644
> --- a/drivers/phy/ti/phy-tusb1210.c
> +++ b/drivers/phy/ti/phy-tusb1210.c
> @@ -124,7 +124,8 @@ static void tusb1210_remove(struct ulpi *ulpi)
> #define TI_VENDOR_ID 0x0451
>
> static const struct ulpi_device_id tusb1210_ulpi_id[] = {
> - { TI_VENDOR_ID, 0x1507, },
> + { TI_VENDOR_ID, 0x1507, }, /* TUSB1210 */
> + { TI_VENDOR_ID, 0x1508, }, /* TUSB1211 */
> { },
> };
> MODULE_DEVICE_TABLE(ulpi, tusb1210_ulpi_id);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: xhci: Fix USB 3.1 supported protocol parsing
From: YD Tseng
xHCI host controllers can have both USB 3.1 and 3.0 extended speed
protocol lists. If the USB3.1 speed is parsed first and 3.0 second then
the minor revision supported will be overwritten by the 3.0 speeds and
the USB3 roothub will only show support for USB 3.0 speeds.
This was the case with a xhci controller with the supported protocol
capability listed below.
In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set as 0x10. And then USB 3.0 is parsed. However, the min_rev of
usb3_rhub will be changed to 0x00. If USB 3.1 device is connected behind
this host controller, the speed of USB 3.1 device just reports 5G speed
using lsusb.
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
This patch fixes the issue by only owerwriting the minor revision if
it is higher than the existing one.
[reword commit message -Mathias]
Cc:
Signed-off-by: YD Tseng
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-mem.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1f1687e..fddf273 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2119,11 +2119,12 @@ static void xhci_add_in_port(struct xhci_hcd *xhci,
unsigned int num_ports,
{
u32 temp, port_offset, port_count;
int i;
- u8 major_revision;
+ u8 major_revision, minor_revision;
struct xhci_hub *rhub;
temp = readl(addr);
major_revision = XHCI_EXT_PORT_MAJOR(temp);
+ minor_revision = XHCI_EXT_PORT_MINOR(temp);
if (major_revision == 0x03) {
rhub = &xhci->usb3_rhub;
@@ -2137,7 +2138,9 @@ static void xhci_add_in_port(struct xhci_hcd *xhci,
unsigned int num_ports,
return;
}
rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
- rhub->min_rev = XHCI_EXT_PORT_MINOR(temp);
+
+ if (rhub->min_rev < minor_revision)
+ rhub->min_rev = minor_revision;
/* Port offset and count in the third dword, see section 7.2 */
temp = readl(addr + 2);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk
From: Corentin Labbe When plugging an USB webcam I see the following message: [106385.615559] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [106390.583860] handle_tx_event: 913 callbacks suppressed With this patch applied, I get no more printing of this message. Cc: Signed-off-by: Corentin Labbe Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index fcf1f3f..1bcf971 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -201,6 +201,9 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && pdev->device == 0x1042) xhci->quirks |= XHCI_BROKEN_STREAMS; + if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA && + pdev->device == 0x1142) + xhci->quirks |= XHCI_TRUST_TX_LENGTH; if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241) xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_7; -- 1.9.1 -- 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 0/2] xhci fixes for usb-linus
Hi Greg A couple more small xhci fixes for usb-linus. -mathias Corentin Labbe (1): usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk YD Tseng (1): usb: xhci: Fix USB 3.1 supported protocol parsing drivers/usb/host/xhci-mem.c | 7 +-- drivers/usb/host/xhci-pci.c | 3 +++ 2 files changed, 8 insertions(+), 2 deletions(-) -- 1.9.1 -- 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] HID: let generic driver yield control iff specific driver has been enabled (was Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works)
Hi,
On 09-06-17 13:25, Jiri Kosina wrote:
On Fri, 9 Jun 2017, Jiri Kosina wrote:
This is something I've been wanting to fix for ages, but never really got
to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
Looks good to me. Note I've *not* checked that all the VID:PID pairs in
the hid_have_special_driver[] list are in the right #if IS_ENABLED
block, with that caveat this patch is:
Acked-by: Hans de Goede
If you want I can make some time to double check that all the VID:PID
pairs in the hid_have_special_driver[] list are in the right #if IS_ENABLED
block, so if you want an extra pair of eyes to double-check let me know
and I will get on this right away.
Regards,
Hans
From: Jiri Kosina
Subject: [PATCH] HID: let generic driver yield control iff specific driver has
been enabled
There are many situations where generic HID driver provides some basic level
of support for certain device, but later this support (usually by implementing
vendor-specific extensions of HID protocol) is extended and the support moved
over to a separate (usually per-vendor) specific driver.
This might bring a rather unpleasant suprise for users, as all of a sudden
there is a new config option they have to enable in order to get any support
for their device whatsoever, although previous kernel versions provided basic
support through the generic driver. Which is rightfully seen as a regression.
Fix this by including the entry for a particular device in
hid_have_special_driver[] iff the specific config option has been specified,
and let generic driver handle the device otherwise.
Also make the behavior of hid_scan_report() (where the same decision is being
taken on a per-report level) consistent.
While at it, reshuffle the hid_have_special_driver[] a bit to restore the
alphabetical ordering (first order by config option, and within those
sections order by VID).
This is considered a short-term solution, before generic way of giving
precedence to special drivers and falling back to generic driver is
figured out.
Signed-off-by: Jiri Kosina
---
drivers/hid/hid-core.c | 260 ++---
1 file changed, 205 insertions(+), 55 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 04cee65531d7..8571a46e41ea 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -826,11 +826,35 @@ static int hid_scan_report(struct hid_device *hid)
* hid-rmi should take care of them,
* not hid-generic
*/
- if (IS_ENABLED(CONFIG_HID_RMI))
- hid->group = HID_GROUP_RMI;
+ hid->group = HID_GROUP_RMI;
break;
}
+ /* fall back to generic driver in case specific driver doesn't exist */
+ switch (hid->group) {
+ case HID_GROUP_MULTITOUCH_WIN_8:
+ /* fall-through */
+ case HID_GROUP_MULTITOUCH:
+ if (!IS_ENABLED(CONFIG_HID_MULTITOUCH))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_SENSOR_HUB:
+ if (!IS_ENABLED(CONFIG_HID_SENSOR_HUB))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_RMI:
+ if (!IS_ENABLED(CONFIG_HID_RMI))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_WACOM:
+ if (!IS_ENABLED(CONFIG_HID_WACOM))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_LOGITECH_DJ_DEVICE:
+ if (!IS_ENABLED(CONFIG_HID_LOGITECH_DJ))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ }
vfree(parser);
return 0;
}
@@ -1763,15 +1787,23 @@ EXPORT_SYMBOL_GPL(hid_disconnect);
* used as a driver. See hid_scan_report().
*/
static const struct hid_device_id hid_have_special_driver[] = {
+#if IS_ENABLED(CONFIG_HID_A4TECH)
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_RP_649) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ACCUTOUCH)
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ACRUX)
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ALPS)
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_ALPS_JP,
HID_DEVICE_ID_ALPS_U1_DUAL) },
+#endif
+#if IS_ENABLED(CONFIG_HID_APPLE)
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE)
},
- { HID_BLUETOOTH_DEVICE
[PATCH] HID: let generic driver yield control iff specific driver has been enabled (was Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works)
On Fri, 9 Jun 2017, Jiri Kosina wrote:
> This is something I've been wanting to fix for ages, but never really got
> to it. So let's take this as the final impulse to do it.
So I'd suggest to go with something like the below for 4.12-rc. Hmm?
From: Jiri Kosina
Subject: [PATCH] HID: let generic driver yield control iff specific driver has
been enabled
There are many situations where generic HID driver provides some basic level
of support for certain device, but later this support (usually by implementing
vendor-specific extensions of HID protocol) is extended and the support moved
over to a separate (usually per-vendor) specific driver.
This might bring a rather unpleasant suprise for users, as all of a sudden
there is a new config option they have to enable in order to get any support
for their device whatsoever, although previous kernel versions provided basic
support through the generic driver. Which is rightfully seen as a regression.
Fix this by including the entry for a particular device in
hid_have_special_driver[] iff the specific config option has been specified,
and let generic driver handle the device otherwise.
Also make the behavior of hid_scan_report() (where the same decision is being
taken on a per-report level) consistent.
While at it, reshuffle the hid_have_special_driver[] a bit to restore the
alphabetical ordering (first order by config option, and within those
sections order by VID).
This is considered a short-term solution, before generic way of giving
precedence to special drivers and falling back to generic driver is
figured out.
Signed-off-by: Jiri Kosina
---
drivers/hid/hid-core.c | 260 ++---
1 file changed, 205 insertions(+), 55 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 04cee65531d7..8571a46e41ea 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -826,11 +826,35 @@ static int hid_scan_report(struct hid_device *hid)
* hid-rmi should take care of them,
* not hid-generic
*/
- if (IS_ENABLED(CONFIG_HID_RMI))
- hid->group = HID_GROUP_RMI;
+ hid->group = HID_GROUP_RMI;
break;
}
+ /* fall back to generic driver in case specific driver doesn't exist */
+ switch (hid->group) {
+ case HID_GROUP_MULTITOUCH_WIN_8:
+ /* fall-through */
+ case HID_GROUP_MULTITOUCH:
+ if (!IS_ENABLED(CONFIG_HID_MULTITOUCH))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_SENSOR_HUB:
+ if (!IS_ENABLED(CONFIG_HID_SENSOR_HUB))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_RMI:
+ if (!IS_ENABLED(CONFIG_HID_RMI))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_WACOM:
+ if (!IS_ENABLED(CONFIG_HID_WACOM))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ case HID_GROUP_LOGITECH_DJ_DEVICE:
+ if (!IS_ENABLED(CONFIG_HID_LOGITECH_DJ))
+ hid->group = HID_GROUP_GENERIC;
+ break;
+ }
vfree(parser);
return 0;
}
@@ -1763,15 +1787,23 @@ EXPORT_SYMBOL_GPL(hid_disconnect);
* used as a driver. See hid_scan_report().
*/
static const struct hid_device_id hid_have_special_driver[] = {
+#if IS_ENABLED(CONFIG_HID_A4TECH)
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_RP_649) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ACCUTOUCH)
+ { HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_ACCUTOUCH_2216) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ACRUX)
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
+#endif
+#if IS_ENABLED(CONFIG_HID_ALPS)
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_ALPS_JP,
HID_DEVICE_ID_ALPS_U1_DUAL) },
+#endif
+#if IS_ENABLED(CONFIG_HID_APPLE)
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE)
},
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICMOUSE) },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICTRACKPAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI)
},
@@ -1792,11 +1824,6 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VE
Re: [RFC] usb-phy-generic: Add support to SMSC USB3315
Hi Peter On Fri, 2017-06-09 at 08:26 +, Peter Chen wrote: > > > > > I have a look at your patches > > (http://www.spinics.net/lists/linux-usb/msg157134.html) > > and I wonder if power sequence is applicable only on hub node? > > No, power sequence can be used for any devices which needs to carry out power > on > before probe. > > > hub are probed too > > late (after ci_ulpi_init). Do you think it is possible to read a power > > sequence in dts > > from ci_ulpi_init? > > > > I think the suitable place for power sequence is at ulpi_of_register, some > ULPI PHYs > need to carry out power on before reading ID. > I do some test to verify that ulpi_of_register is called before hw_phymode_configure but it is not the case. Can you confirm that ULPI phys works with IMX6? It seems that IMX53 and IMX6 use the same chipidea controller and should have the same behaviour. So I wonder if the issue I encounter can be a SOC issue. Thanks > Peter -- 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] usb: gadget: functions: add ftrace export over USB
Felipe Balbi writes:
> Felipe Balbi writes:
>
>> Allow for ftrace data to be exported over a USB Gadget
>> Controller. With this, we have a potentially very fast pipe for
>> transmitting ftrace data to a Host PC for further analysis.
>>
>> Note that in order to decode the data, one needs access to kernel
>> symbols in order to convert binary data into function names and what
>> not.
>>
>> Signed-off-by: Felipe Balbi
>> ---
>>
>> I wanted to take this through the gadget tree, but there is a
>> dependency with a previous patch of mine adding and extra argument to
>> the ->write() function. Hoping someone else will take it.
>
> just as an extra note here. In order for this to be really useful, it
> would be nice to be able to control what is going to be traced over USB
> as well, but that means exporting a few extra functions to GPL drivers.
>
> Would that be okay? I could have a set of vendor-specific control
> requests to set buffer size and to read/write ftrace filter functions.
>
> The idea is that things like e.g. Android SDK could rely on this on
> debug builds and the SDK itself would make sure to keep a copy of
> vmlinux around to processing of the data coming through USB.
something along these lines (although I think trace buffer size doesn't
matter for trace export, but it serves well enough to illustrate a
point):
modified drivers/usb/gadget/function/f-trace.c
@@ -33,6 +33,8 @@ struct usb_ftrace {
struct usb_ep *in;
+ u32 buffer_size;
+ u16 version;
u8 intf_id;
};
#define ftrace_to_trace(f) (container_of((f), struct usb_ftrace, ftrace))
@@ -40,6 +42,12 @@ struct usb_ftrace {
#define to_trace(f)(container_of((f), struct usb_ftrace, function))
#define FTRACE_REQUEST_QUEUE_LENGTH250
+#define FTRACE_VERSION 0x0100 /* bcd 1.00 */
+
+/* FTrace vendor-specific requests */
+#define USB_FTRACE_GET_VERSION 0x00
+#define USB_FTRACE_GET_TRACE_BUF_SIZE 0x01
+#define USB_FTRACE_SET_TRACE_BUF_SIZE 0x02
static inline struct usb_request *next_request(struct list_head *list)
{
@@ -142,6 +150,13 @@ static void ftrace_complete(struct usb_ep *ep, struct
usb_request *req)
list_move_tail(&req->list, &trace->list);
}
+static void ftrace_set_trace_buf_size_complete(struct usb_ep *ep, struct
usb_request *req)
+{
+ struct usb_ftrace *trace = req->context;
+
+ trace_set_buf_size(le32_to_cpu(trace->buffer_size));
+}
+
static void ftrace_queue_work(struct work_struct *work)
{
struct usb_ftrace *trace = work_to_trace(work);
@@ -237,6 +252,71 @@ static int ftrace_set_alt(struct usb_function *f, unsigned
intf, unsigned alt)
return -EINVAL;
}
+extern unsigned long trace_get_buf_size(void);
+
+static int ftrace_setup(struct usb_function *f, const struct usb_ctrlrequest
*ctrl)
+{
+ struct usb_configuration*c = f->config;
+ struct usb_request *req = c->cdev->req;
+ struct usb_ftrace *trace = to_trace(f);
+
+ int ret;
+
+ u16 index = le16_to_cpu(ctrl->wIndex);
+ u16 value = le16_to_cpu(ctrl->wValue);
+ u16 length = le16_to_cpu(ctrl->wLength);
+
+ if (value != 0 || index != 0)
+ return -EINVAL;
+
+ switch (ctrl->bRequest) {
+ case USB_FTRACE_GET_VERSION:
+ if (ctrl->bRequestType != (USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_INTERFACE))
+ return -EINVAL;
+
+ if (length != 2)
+ return -EINVAL;
+
+ req->zero = 0;
+ req->length = 2;
+ req->buf = &trace->version;
+ break;
+ case USB_FTRACE_GET_TRACE_BUF_SIZE:
+ if (ctrl->bRequestType != (USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_INTERFACE))
+ return -EINVAL;
+
+ if (length != 2)
+ return -EINVAL;
+
+ trace->buffer_size = cpu_to_le32(trace_get_buf_size());
+
+ req->zero = 0;
+ req->length = 2;
+ req->buf = &trace->buffer_size;
+ break;
+ case USB_FTRACE_SET_TRACE_BUF_SIZE:
+ if (ctrl->bRequestType != (USB_DIR_OUT | USB_TYPE_VENDOR |
+ USB_RECIP_INTERFACE))
+ return -EINVAL;
+
+ if (length != 4)
+ return -EINVAL;
+
+ req->zero = 0;
+ req->length = 4;
+ req->context = trace;
+ req->complete = ftrace_set_trace_buf_size_complete;
+ req->buf = &trace->buffer_size;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return usb_ep_queue
Re: More dynamic EP allocation
On Fri, 2017-06-09 at 21:00 +1000, Benjamin Herrenschmidt wrote:
> Hi !
>
> So for the aspeed virtual hub, I'm in a situation where I have up to 5
> devices sharing a pool of 15 "generic" endpoints (not counting EP0's,
> those have dedicated HW).
>
> I was originally thinking of having some device-tree construct
> assigning fixed number of EPs from the pool to the various devices, but
> that sucks...
>
> I'm trying to figure out if I can do something more dynamic.
>
> My idea is to not put the EPs in the gadget ep_list at first, but
> provide a match_ep() callback that effectively "allocates" an EP from
> the pool.
>
> It looks from a cursory glance at the code that it might work, with a
> reasonable failure mode since running out of EPs would typically make
> functions fail at bind() time.
>
> However we're missing a "free" :-)
>
> I *think* (please correct me if I'm wrong) that adding a callback for
> that and plumbing it this way would work, let me know what you think.
>
> If you agree with the approach (and it ends up working once I'm done
> coding), I'll submit it as a pre-req patch to the driver.
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index e4516e9..f8d2135 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -307,6 +307,7 @@ struct usb_gadget_ops {
> struct usb_ep *(*match_ep)(struct usb_gadget *,
> struct usb_endpoint_descriptor *,
> struct usb_ss_ep_comp_descriptor *);
> + void(*release_ep)(struct usb_gadget *, struct usb_ep *);
> };
Or rather in the ep->ops as we don't always have the struct usb_gadget
around when releasing, but you get the idea...
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More dynamic EP allocation
Hi,
Benjamin Herrenschmidt writes:
> Hi !
>
> So for the aspeed virtual hub, I'm in a situation where I have up to 5
> devices sharing a pool of 15 "generic" endpoints (not counting EP0's,
> those have dedicated HW).
>
> I was originally thinking of having some device-tree construct
> assigning fixed number of EPs from the pool to the various devices, but
> that sucks...
>
> I'm trying to figure out if I can do something more dynamic.
>
> My idea is to not put the EPs in the gadget ep_list at first, but
> provide a match_ep() callback that effectively "allocates" an EP from
> the pool.
but that's how the framework is implemented. Endpoints are kept in the
ep_list but they aren't allocated until an endpoint match happens.
> It looks from a cursory glance at the code that it might work, with a
> reasonable failure mode since running out of EPs would typically make
> functions fail at bind() time.
>
> However we're missing a "free" :-)
We don't need a free. Once a function is unbound, endpoints *must* be
free.
> I *think* (please correct me if I'm wrong) that adding a callback for
> that and plumbing it this way would work, let me know what you think.
I'm not entirely sure you need it.
> If you agree with the approach (and it ends up working once I'm done
> coding), I'll submit it as a pre-req patch to the driver.
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index e4516e9..f8d2135 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -307,6 +307,7 @@ struct usb_gadget_ops {
> struct usb_ep *(*match_ep)(struct usb_gadget *,
> struct usb_endpoint_descriptor *,
> struct usb_ss_ep_comp_descriptor *);
> + void(*release_ep)(struct usb_gadget *, struct usb_ep *);
> };
>
> /**
> --- a/drivers/usb/gadget/epautoconf.c
> +++ b/drivers/usb/gadget/epautoconf.c
> @@ -185,6 +185,9 @@ void usb_ep_autoconfig_release(struct usb_ep *ep)
> {
> ep->claimed = false;
> ep->driver_data = NULL;
> +
> + if (gadget->ops->release_ep)
> + gadget->relase->release_ep(gadget, ep);
> }
> EXPORT_SYMBOL_GPL(usb_ep_autoconfig_release);
>
> @@ -201,10 +204,8 @@ void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
> {
> struct usb_ep *ep;
>
> - list_for_each_entry (ep, &gadget->ep_list, ep_list) {
> - ep->claimed = false;
> - ep->driver_data = NULL;
> - }
> + list_for_each_entry_safe (ep, &gadget->ep_list, ep_list)
> + usb_ep_autoconfig_release(ep);
> gadget->in_epnum = 0;
> gadget->out_epnum = 0;
> }
I really don't see the difference.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v2 0/3] New driver for UCSI (USB Type-C)
Hi Guenter, On Mon, Jun 05, 2017 at 05:30:22PM +0300, Heikki Krogerus wrote: > Hi, > > This moves the current ucsi driver from drivers/usb/misc/ucsi.c to the > new USB Type-C class (drivers/usb/typec/). That allows us to finally do > role swapping. > > The driver is now split into core library part, and ACPI driver. That > should make it easy to add support for other interface methods (first > most likely being I2C) later if needed. > > Changes since v1: > - Added separate flag from pending ACK. Some new platforms generate "command > complete" event on top of the normal "ACK complete" event with ACK commands. > In such cases the driver has to be able to basically ignore the command > completion in case of ACK and only finish acknowledge routine when the > actual > ACK complete event is received. Otherwise a new command may be queued to the > PPM before the previous has fully completed. > - Added an explanation why we are handling the PPM initialization in a work as > suggested by Guenter. > - Fixed ucsi_reset_ppm() by removing possibility of returning -ETIMEDOUT in > case > of success right before the time expires. Suggested by Guenter. > - Replaced useless "goto err;" with "break;" in ucsi_run_command() as > suggested > by Guenter. > - Removed traceback in case of failure from ucsi_run_command() which is not > necessary as suggested by Guenter. > - Highlighting the fact that the timeouts are in milliseconds by using _MS > ending with the definition (UCSI_TIMEOUT_MS and UCSI_SWAP_TIMEOUT_MS) as > suggested by Guenter. > - Including also in ucsi.h as suggested by Guenter. > - In ucsi_acpi.c, explicitly pointing out in the comment that we can not use > devm_ioremap_resource() as suggested by Guenter. > > > Heikki Krogerus (2): > usb: typec: Add support for UCSI interface > usb: typec: ucsi: Add ACPI driver Gentle ping. Are these OK now? Thanks, -- heikki -- 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
More dynamic EP allocation
Hi !
So for the aspeed virtual hub, I'm in a situation where I have up to 5
devices sharing a pool of 15 "generic" endpoints (not counting EP0's,
those have dedicated HW).
I was originally thinking of having some device-tree construct
assigning fixed number of EPs from the pool to the various devices, but
that sucks...
I'm trying to figure out if I can do something more dynamic.
My idea is to not put the EPs in the gadget ep_list at first, but
provide a match_ep() callback that effectively "allocates" an EP from
the pool.
It looks from a cursory glance at the code that it might work, with a
reasonable failure mode since running out of EPs would typically make
functions fail at bind() time.
However we're missing a "free" :-)
I *think* (please correct me if I'm wrong) that adding a callback for
that and plumbing it this way would work, let me know what you think.
If you agree with the approach (and it ends up working once I'm done
coding), I'll submit it as a pre-req patch to the driver.
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e4516e9..f8d2135 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -307,6 +307,7 @@ struct usb_gadget_ops {
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
+ void(*release_ep)(struct usb_gadget *, struct usb_ep *);
};
/**
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -185,6 +185,9 @@ void usb_ep_autoconfig_release(struct usb_ep *ep)
{
ep->claimed = false;
ep->driver_data = NULL;
+
+ if (gadget->ops->release_ep)
+ gadget->relase->release_ep(gadget, ep);
}
EXPORT_SYMBOL_GPL(usb_ep_autoconfig_release);
@@ -201,10 +204,8 @@ void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
{
struct usb_ep *ep;
- list_for_each_entry (ep, &gadget->ep_list, ep_list) {
- ep->claimed = false;
- ep->driver_data = NULL;
- }
+ list_for_each_entry_safe (ep, &gadget->ep_list, ep_list)
+ usb_ep_autoconfig_release(ep);
gadget->in_epnum = 0;
gadget->out_epnum = 0;
}
Cheers,
Ben.
--
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: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
Bjørn Mork writes: > But I should probably go google now, before I repeat too mcuh of the > previous discussions ;-) I guess this is the previous proposal: https://lwn.net/Articles/121227/ and discussion: http://lkml.iu.edu/hypermail/linux/kernel/0502.1/index.html#0438 The proposal is slightly different, but some of the objections are definitely relevant. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: xhci: Issue stop EP command only when the EP state is running
On 09.06.2017 12:44, Shyam Sundar S K wrote: On 6/7/2017 4:45 PM, Mathias Nyman wrote: Hi The internal variable is just what xhci spec recommends as it says the output context is not immediately updated for example at endpoint doorbell ring. It's to make sure we don't read stale values from the output context. The race Alan refers to is a different case. The endpoint might be halted just before the stop endpoint command is handled by hardware, there is no way of tracking this from output contexts or local variables. Working controllers will just give a context state error if we try to stop a halted endpoint. Agreed. In case of the linux xhci driver, two times stop EP commands are queued up. one within the loop: xhci_queue_stop_endpoint(xhci, command, slot_id, i, suspend); and another out of the loop: xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend); I could not comprehend what is the actual need to have two stop endpoint command queued up. within the loop stop active endpoints from LAST_EP_INDEX to 1 (30,29,28,27...3,2,1). We don't wait for these stop endpoint commands to complete. After the loop we stop endpoint 0 (default control endpoint) and wait for its completion. We don't stop the same endpoint twice. In our case, when we send the first stop endpoint command it is returning with Context State Error and for the next stop EP HW additionally marks EP to Flow control state in HW which is RTL bug. I did some experiments to see the impact of not queuing the first stop EP command i.e. xhci_queue_stop_endpoint(xhci, command, slot_id, i, suspend); the one which is inside the loop Looks like not queuing this command does not have any impact on the functionality on the connected hub. So, based on this; I have pushed the v2 patch which guards the first stop EP command. Also, for the first stop EP command, while allocation we do not set the 'allocate_completion' flag to true. command = xhci_alloc_command(xhci, false, false, GFP_NOWAIT); So, ideally we cannot check its completion state with command->status. Atleast for this SNPS IP issue, we need to prevent this first stop EP command, either by checking the ep_state or by adding a quirk specific to this revision of IP from SNPS so that it does not hit the internal RTL bug. Kindly let me know your thoughts. I think it's valid to check if the endpoint is already stopped from the endpoint context, and not queue a stop endpoint command for a already stopped endpoint. Especially as your hardware can't handle it. That code makes sense. I also think you got a bit confused what the current code does. It does not stop same endpoint twice. It stops endpoints 30-1 in a loop, and then endpoint 0 after the loop. Then I think yo need to consider the race Alan was talking about. Let me try to clarify that race case again. Even after checking the endpoint state from endpoint context the following could happen: -- xhci driver, in xhci_stop_device() --- 1. driver checks endpoint x context shows endpoint is running 2. driver queues a stop endpoint command for endpoint x on command ring -- xhci hardware -- 3. endpoint x is till running, 4. xhci hardware gets a STALL packet on endpoint x from the device. 5. xhci hardware sets endpoint x to HALT state 6. xhci hardware takes stop endpoint command from command ring and start executing it 7. xhci hardware tries to stop endpoint x which is in HALTED state -> possible RTL bug! After all this we need to take into account that xhci spec say that there can be be a small delay before actual endpoint state is updated to the endpoint context. The spec recommends that the driver keeps track of latest endpoint state changes. Like when ringing a doorbell it will start the endpoint, but endpoint context state is updated to running with a small delay -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: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
Greg KH writes: > On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote: >> Greg KH writes: >> >> > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote: >> >> Longer-term, we'd ideally make 'generic' driver special and let it attach >> >> as a 'last resort driver' if none of the specific driver picked the >> >> device >> >> up during probe. But I don't think our current driver model allows this >> >> easily ... or is there way I am not seeing? >> > >> > Nope, the driver model does not provide a way for this, sorry, it's been >> > a complaint from the very beginning that we don't really know how to >> > handle, except to make sure the order of the drivers loaded are the >> > priority list, and that's not really a solution at all. >> >> Add a 'priority' field to struct device_driver and sort the list by this >> field instead of load order? > > We've been over this before :) OK, I have to google that. > What happens when a new module is loaded, are you supposed to then > disconnect a device from an existing driver, recan all of the existing > drivers, and then bind the "correct" one then? You don't have to touch any bound device unless it matches the new driver, which hopefully only will be the rare cases where that driver actually *is* a better alternative. But yes, there are many issues which needs to be resolved. What if you unbind from an existing driver and the new driver fails probing? What if the user manually bound the device to the existing driver? What if different devices want different driver priorities? Can we make module loading follow the priority to avoid bind/unbind bouncing for the common case? Etc. Lots of work, but I still think it's the way to go. Just look at what we have today: Inflexible build time priorities implemented as paired blacklists and whitelists. Even if you get all the IS_ENABLED ifdefs right, you will fail if the user blacklists or removes one of the modules at runtime. And when you have two alternative drivers for a device, possibly with different feature sets [1], there is no way to switch between drivers without rebuilding. And you have a number of class drivers with long lists of apparently redundant device IDs. Until you look at the source and discover that these devices are actually blacklisted. Ugly and confusing. I was a bit unsure if I should dare mention this since it is one of the uglier constructs I know about, and I am responsible, but what the h...: The cdc_ncm vs cdc_mbim is particularily bad. It has its own "priority" flag implemented as a module parameter in the cdc_ncm driver. This was done because both drivers had to match NCM interfaces, since these are allowed to transform into MBIM interfaces depending on altsetting. I still don't see any way to support that without priorities. I only wish I had tried to push generic driver priorities instead of making it specific to cdc_ncm/cdc_mbim. But I should probably go google now, before I repeat too mcuh of the previous discussions ;-) [1] there are real examples of this. r8152 vs cdc_ether is one. Bjørn -- 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] usb: gadget: functions: add ftrace export over USB
Felipe Balbi writes: > Allow for ftrace data to be exported over a USB Gadget > Controller. With this, we have a potentially very fast pipe for > transmitting ftrace data to a Host PC for further analysis. > > Note that in order to decode the data, one needs access to kernel > symbols in order to convert binary data into function names and what > not. > > Signed-off-by: Felipe Balbi > --- > > I wanted to take this through the gadget tree, but there is a > dependency with a previous patch of mine adding and extra argument to > the ->write() function. Hoping someone else will take it. just as an extra note here. In order for this to be really useful, it would be nice to be able to control what is going to be traced over USB as well, but that means exporting a few extra functions to GPL drivers. Would that be okay? I could have a set of vendor-specific control requests to set buffer size and to read/write ftrace filter functions. The idea is that things like e.g. Android SDK could rely on this on debug builds and the SDK itself would make sure to keep a copy of vmlinux around to processing of the data coming through USB. -- balbi signature.asc Description: PGP signature
[PATCH v2 2/2] phy: tusb1210: implement ->set_mode()
->set_mode() can be used to tell PHY to prepare itself to enter USB
Host/Peripheral mode and that's very important for DRD
configurations.
Signed-off-by: Felipe Balbi
changes since v1:
- rebase on PHY -next
---
drivers/phy/ti/phy-tusb1210.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
index 5dbb9a7b4945..b8ec39ac4dfc 100644
--- a/drivers/phy/ti/phy-tusb1210.c
+++ b/drivers/phy/ti/phy-tusb1210.c
@@ -11,6 +11,7 @@
*/
#include
#include
+#include
#include
#include
@@ -52,9 +53,43 @@ static int tusb1210_power_off(struct phy *phy)
return 0;
}
+static int tusb1210_set_mode(struct phy *phy, enum phy_mode mode)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+ int ret;
+
+ ret = ulpi_read(tusb->ulpi, ULPI_OTG_CTRL);
+ if (ret < 0)
+ return ret;
+
+ switch (mode) {
+ case PHY_MODE_USB_HOST:
+ ret |= (ULPI_OTG_CTRL_DRVVBUS_EXT
+ | ULPI_OTG_CTRL_ID_PULLUP
+ | ULPI_OTG_CTRL_DP_PULLDOWN
+ | ULPI_OTG_CTRL_DM_PULLDOWN);
+ ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
+ ret |= ULPI_OTG_CTRL_DRVVBUS;
+ break;
+ case PHY_MODE_USB_DEVICE:
+ ret &= ~(ULPI_OTG_CTRL_DRVVBUS
+| ULPI_OTG_CTRL_DP_PULLDOWN
+| ULPI_OTG_CTRL_DM_PULLDOWN);
+ ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
+ ret &= ~ULPI_OTG_CTRL_DRVVBUS_EXT;
+ break;
+ default:
+ /* nothing */
+ return 0;
+ }
+
+ return ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
+}
+
static const struct phy_ops phy_ops = {
.power_on = tusb1210_power_on,
.power_off = tusb1210_power_off,
+ .set_mode = tusb1210_set_mode,
.owner = THIS_MODULE,
};
--
2.11.0.295.gd7dffce1ce
--
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 1/2] phy: tusb1210: add support for TUSB1211
TUSB1211 is software compatible with TUSB1210 and as such we don't
need an entire new driver to control it. Let's add its product ID to
the existing TUSB1210 driver instead.
Signed-off-by: Felipe Balbi
---
changes since v1:
- rebase on PHY -next
drivers/phy/ti/phy-tusb1210.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
index bb3fb031c478..5dbb9a7b4945 100644
--- a/drivers/phy/ti/phy-tusb1210.c
+++ b/drivers/phy/ti/phy-tusb1210.c
@@ -124,7 +124,8 @@ static void tusb1210_remove(struct ulpi *ulpi)
#define TI_VENDOR_ID 0x0451
static const struct ulpi_device_id tusb1210_ulpi_id[] = {
- { TI_VENDOR_ID, 0x1507, },
+ { TI_VENDOR_ID, 0x1507, }, /* TUSB1210 */
+ { TI_VENDOR_ID, 0x1508, }, /* TUSB1211 */
{ },
};
MODULE_DEVICE_TABLE(ulpi, tusb1210_ulpi_id);
--
2.11.0.295.gd7dffce1ce
--
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 1/5] phy: tusb1210: add support for TUSB1211
Hi, Kishon Vijay Abraham I writes: >> Kishon Vijay Abraham I writes: >>> On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote: TUSB1211 is software compatible with TUSB1210 and as such we don't need an entire new driver to control it. Let's add its product ID to the existing TUSB1210 driver instead. Signed-off-by: Felipe Balbi --- drivers/phy/phy-tusb1210.c | 3 ++- >>> >>> The directory structure in phy has changed a bit. phy-tusb1210.c is now in >>> drivers/phy/ti/. >> >> Not in mainline yet? I can either resend after v4.13-rc1 or rebase on >> whatever branch you may have. What do you prefer? > > If you can rebase it on linux-phy -next, I can pick it up. will do. Keep in mind that I'm taking the dwc3 bits through my tree though :-) I'll re-send only drivers/phy bits shortly. -- balbi signature.asc Description: PGP signature
Re: [PATCH 1/5] phy: tusb1210: add support for TUSB1211
Hi, On Friday 09 June 2017 03:27 PM, Felipe Balbi wrote: > > Hi, > > Kishon Vijay Abraham I writes: >> On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote: >>> TUSB1211 is software compatible with TUSB1210 and as such we don't >>> need an entire new driver to control it. Let's add its product ID to >>> the existing TUSB1210 driver instead. >>> >>> Signed-off-by: Felipe Balbi >>> --- >>> drivers/phy/phy-tusb1210.c | 3 ++- >> >> The directory structure in phy has changed a bit. phy-tusb1210.c is now in >> drivers/phy/ti/. > > Not in mainline yet? I can either resend after v4.13-rc1 or rebase on > whatever branch you may have. What do you prefer? If you can rebase it on linux-phy -next, I can pick it up. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] phy: tusb1210: add support for TUSB1211
Hi, Kishon Vijay Abraham I writes: > On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote: >> TUSB1211 is software compatible with TUSB1210 and as such we don't >> need an entire new driver to control it. Let's add its product ID to >> the existing TUSB1210 driver instead. >> >> Signed-off-by: Felipe Balbi >> --- >> drivers/phy/phy-tusb1210.c | 3 ++- > > The directory structure in phy has changed a bit. phy-tusb1210.c is now in > drivers/phy/ti/. Not in mainline yet? I can either resend after v4.13-rc1 or rebase on whatever branch you may have. What do you prefer? -- balbi signature.asc Description: PGP signature
Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
On Jun 09 2017 or thereabouts, Greg KH wrote: > On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote: > > Greg KH writes: > > > > > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote: > > >> Longer-term, we'd ideally make 'generic' driver special and let it > > >> attach > > >> as a 'last resort driver' if none of the specific driver picked the > > >> device > > >> up during probe. But I don't think our current driver model allows this > > >> easily ... or is there way I am not seeing? > > > > > > Nope, the driver model does not provide a way for this, sorry, it's been > > > a complaint from the very beginning that we don't really know how to > > > handle, except to make sure the order of the drivers loaded are the > > > priority list, and that's not really a solution at all. > > > > Add a 'priority' field to struct device_driver and sort the list by this > > field instead of load order? > > We've been over this before :) I can imagine :) > > What happens when a new module is loaded, are you supposed to then > disconnect a device from an existing driver, recan all of the existing > drivers, and then bind the "correct" one then? This particular case might be slightly different than a generic solution across the tree. HID devices are supposed to behave properly out of the box and are expected to be reprobed by design (most input devices have a special boot mode to be accessed to some extend by the UEFI, and then you have the shiny proprietary driver that takes over it under windows). So I don't think it would be an issue to "bind" a generic handling of a device, and somehow retrigger a probe when the actual hid-specific driver comes in (and we know we are using the default, non ideal, handling). The current driver model won't allow this by design, but I'll try to work around this if it is possible in the hid tree as a specific case. Cheers, Benjamin > > sorry, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: xhci: Issue stop EP command only when the EP state is running
On 6/7/2017 4:45 PM, Mathias Nyman wrote: > Hi > > The internal variable is just what xhci spec recommends as it says the output > context is not immediately > updated for example at endpoint doorbell ring. It's to make sure we don't > read stale values from the output context. > > The race Alan refers to is a different case. > The endpoint might be halted just before the stop endpoint command is handled > by hardware, there is no way > of tracking this from output contexts or local variables. > > Working controllers will just give a context state error if we try to stop a > halted endpoint. Agreed. In case of the linux xhci driver, two times stop EP commands are queued up. one within the loop: xhci_queue_stop_endpoint(xhci, command, slot_id, i, suspend); and another out of the loop: xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend); I could not comprehend what is the actual need to have two stop endpoint command queued up. In our case, when we send the first stop endpoint command it is returning with Context State Error and for the next stop EP HW additionally marks EP to Flow control state in HW which is RTL bug. I did some experiments to see the impact of not queuing the first stop EP command i.e. xhci_queue_stop_endpoint(xhci, command, slot_id, i, suspend); the one which is inside the loop Looks like not queuing this command does not have any impact on the functionality on the connected hub. So, based on this; I have pushed the v2 patch which guards the first stop EP command. Also, for the first stop EP command, while allocation we do not set the 'allocate_completion' flag to true. command = xhci_alloc_command(xhci, false, false, GFP_NOWAIT); So, ideally we cannot check its completion state with command->status. Atleast for this SNPS IP issue, we need to prevent this first stop EP command, either by checking the ep_state or by adding a quirk specific to this revision of IP from SNPS so that it does not hit the internal RTL bug. Kindly let me know your thoughts. > > I tried to ask about this in the first patch revision: > > "I'm talking about the in xhci spec 4.6.9:" > > " A Busy endpoint may asynchronously transition from the Running to the > Halted or Error state due > to error conditions detected while processing TRBs. A possible race > condition may occur if > software, thinking an endpoint is in the Running state, issues a Stop > Endpoint Command however > at the same time the xHC asynchronously transitions the endpoint to the > Halted or Error state. In > this case, a Context State Error may be generated for the command > completion. Software may > verify that this case occurred by inspecting the EP State for Halted or > Error when a Stop Endpoint > Command results in a Context State Error." > I think this scenario is true even with and without this patch. Correct ? > In addition to this patch you probably need to work around that issues as > well. > > -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
[PATCH net-next 00/11] r8152: minor adjustment
Adjust some code to make it reasonable or satisfy the suggestion from the engineers. Hayes Wang (11): r8152: add r8153_phy_status function r8152: adjust lpm settings for RTL8153 r8152: adjust the settings about MAC clock speed down for RTL8153 r8152: move the setting of rx aggregation r8152: adjust rtl8153_runtime_enable function r8152: adjust U2P3 for RTL8153 r8152: move the default coalesce setting for RTL8153 r8152: move the initialization to reset_resume function r8152: check if disabling ALDPS is finished r8152: avoid rx queue more than 1000 packets r8152: replace napi_complete with napi_complete_done drivers/net/usb/r8152.c | 181 ++-- 1 file changed, 130 insertions(+), 51 deletions(-) -- 2.7.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
[PATCH net-next 01/11] r8152: add r8153_phy_status function
Use r8153_phy_status() to check phy status of RTL8153.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 37 +
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index fd31fab..9239dfb 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -394,6 +394,7 @@
/* OCP_PHY_STATUS */
#define PHY_STAT_MASK 0x0007
+#define PHY_STAT_EXT_INIT 2
#define PHY_STAT_LAN_ON3
#define PHY_STAT_PWRDN 5
@@ -2452,6 +2453,28 @@ static void r8153_u2p3en(struct r8152 *tp, bool enable)
ocp_write_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL, ocp_data);
}
+static u16 r8153_phy_status(struct r8152 *tp, u16 desired)
+{
+ u16 data;
+ int i;
+
+ for (i = 0; i < 500; i++) {
+ data = ocp_reg_read(tp, OCP_PHY_STATUS);
+ data &= PHY_STAT_MASK;
+ if (desired) {
+ if (data == desired)
+ break;
+ } else if (data == PHY_STAT_LAN_ON || data == PHY_STAT_PWRDN ||
+ data == PHY_STAT_EXT_INIT) {
+ break;
+ }
+
+ msleep(20);
+ }
+
+ return data;
+}
+
static void r8153_power_cut_en(struct r8152 *tp, bool enable)
{
u32 ocp_data;
@@ -3420,12 +3443,7 @@ static void r8153_init(struct r8152 *tp)
msleep(20);
}
- for (i = 0; i < 500; i++) {
- ocp_data = ocp_reg_read(tp, OCP_PHY_STATUS) & PHY_STAT_MASK;
- if (ocp_data == PHY_STAT_LAN_ON || ocp_data == PHY_STAT_PWRDN)
- break;
- msleep(20);
- }
+ data = r8153_phy_status(tp, 0);
if (tp->version == RTL_VER_03 || tp->version == RTL_VER_04 ||
tp->version == RTL_VER_05)
@@ -3437,12 +3455,7 @@ static void r8153_init(struct r8152 *tp)
r8152_mdio_write(tp, MII_BMCR, data);
}
- for (i = 0; i < 500; i++) {
- ocp_data = ocp_reg_read(tp, OCP_PHY_STATUS) & PHY_STAT_MASK;
- if (ocp_data == PHY_STAT_LAN_ON)
- break;
- msleep(20);
- }
+ data = r8153_phy_status(tp, PHY_STAT_LAN_ON);
usb_disable_lpm(tp->udev);
r8153_u2p3en(tp, false);
--
2.7.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
[PATCH net-next 02/11] r8152: adjust lpm settings for RTL8153
Enable lpm after r8153_init() and remove other enable/disable lpm.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 9239dfb..b8c904f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2263,7 +2263,6 @@ static int rtl8153_enable(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, &tp->flags))
return -ENODEV;
- usb_disable_lpm(tp->udev);
set_tx_qlen(tp);
rtl_set_eee_plus(tp);
r8153_set_rx_early_timeout(tp);
@@ -3003,7 +3002,6 @@ static void rtl8153_disable(struct r8152 *tp)
rtl_disable(tp);
rtl_reset_bmu(tp);
r8153_aldps_en(tp, true);
- usb_enable_lpm(tp->udev);
}
static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u16 speed, u8
duplex)
@@ -3127,7 +3125,6 @@ static void rtl8153_up(struct r8152 *tp)
r8153_aldps_en(tp, true);
r8153_u2p3en(tp, true);
r8153_u1u2en(tp, true);
- usb_enable_lpm(tp->udev);
}
static void rtl8153_down(struct r8152 *tp)
@@ -3457,7 +3454,6 @@ static void r8153_init(struct r8152 *tp)
data = r8153_phy_status(tp, PHY_STAT_LAN_ON);
- usb_disable_lpm(tp->udev);
r8153_u2p3en(tp, false);
if (tp->version == RTL_VER_04) {
@@ -3517,6 +3513,7 @@ static void r8153_init(struct r8152 *tp)
r8153_power_cut_en(tp, false);
r8153_u1u2en(tp, true);
+ usb_enable_lpm(tp->udev);
/* MAC clock speed down */
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, 0);
--
2.7.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
[PATCH net-next 04/11] r8152: move the setting of rx aggregation
Move the setting from r8153_first_init() to r8153_init(). It only needs to be set once. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 9a794db..e569c48 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -2961,11 +2961,6 @@ static void r8153_first_init(struct r8152 *tp) ocp_write_word(tp, MCU_TYPE_PLA, PLA_RXFIFO_CTRL2, RXFIFO_THR3_NORMAL); /* TX share fifo free credit full threshold */ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TXFIFO_CTRL, TXFIFO_THR_NORMAL2); - - /* rx aggregation */ - ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL); - ocp_data &= ~(RX_AGG_DISABLE | RX_ZERO_EN); - ocp_write_word(tp, MCU_TYPE_USB, USB_USB_CTRL, ocp_data); } static void r8153_enter_oob(struct r8152 *tp) @@ -3544,6 +3539,10 @@ static void r8153_init(struct r8152 *tp) r8153_mac_clk_spd(tp, false); usb_enable_lpm(tp->udev); + /* rx aggregation */ + ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL); + ocp_data &= ~(RX_AGG_DISABLE | RX_ZERO_EN); + ocp_write_word(tp, MCU_TYPE_USB, USB_USB_CTRL, ocp_data); rtl_tally_reset(tp); r8153_u2p3en(tp, true); -- 2.7.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
[PATCH net-next 06/11] r8152: adjust U2P3 for RTL8153
Use another way to keep disabling the U2P3 for both RTL_VER_03 and
RTL_VER_04.
Move enabling U2P3 from r8153_init() to r8153_hw_phy_cfg(). The
engineer ask the setting should be done after PHY settings.
Disable U2P3 first in rtl8153_up().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 41 +
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 32e83fd..565ac5b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2468,7 +2468,7 @@ static void r8153_u2p3en(struct r8152 *tp, bool enable)
u32 ocp_data;
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL);
- if (enable && tp->version != RTL_VER_03 && tp->version != RTL_VER_04)
+ if (enable)
ocp_data |= U2P3_ENABLE;
else
ocp_data &= ~U2P3_ENABLE;
@@ -2559,7 +2559,18 @@ static void rtl8153_runtime_enable(struct r8152 *tp,
bool enable)
} else {
rtl_runtime_suspend_enable(tp, false);
r8153_mac_clk_spd(tp, false);
- r8153_u2p3en(tp, true);
+
+ switch (tp->version) {
+ case RTL_VER_03:
+ case RTL_VER_04:
+ break;
+ case RTL_VER_05:
+ case RTL_VER_06:
+ default:
+ r8153_u2p3en(tp, true);
+ break;
+ }
+
r8153_u1u2en(tp, true);
}
}
@@ -2898,6 +2909,17 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
+ switch (tp->version) {
+ case RTL_VER_03:
+ case RTL_VER_04:
+ break;
+ case RTL_VER_05:
+ case RTL_VER_06:
+ default:
+ r8153_u2p3en(tp, true);
+ break;
+ }
+
set_bit(PHY_RESET, &tp->flags);
}
@@ -3143,10 +3165,22 @@ static void rtl8153_up(struct r8152 *tp)
return;
r8153_u1u2en(tp, false);
+ r8153_u2p3en(tp, false);
r8153_aldps_en(tp, false);
r8153_first_init(tp);
r8153_aldps_en(tp, true);
- r8153_u2p3en(tp, true);
+
+ switch (tp->version) {
+ case RTL_VER_03:
+ case RTL_VER_04:
+ break;
+ case RTL_VER_05:
+ case RTL_VER_06:
+ default:
+ r8153_u2p3en(tp, true);
+ break;
+ }
+
r8153_u1u2en(tp, true);
}
@@ -3545,7 +3579,6 @@ static void r8153_init(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_USB, USB_USB_CTRL, ocp_data);
rtl_tally_reset(tp);
- r8153_u2p3en(tp, true);
}
static int rtl8152_pre_reset(struct usb_interface *intf)
--
2.7.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
[PATCH net-next 05/11] r8152: adjust rtl8153_runtime_enable function
Adjust the order of rtl8153_runtime_enable() according to the
suggestion from the engineer.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e569c48..32e83fd 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2551,13 +2551,13 @@ static void rtl_runtime_suspend_enable(struct r8152
*tp, bool enable)
static void rtl8153_runtime_enable(struct r8152 *tp, bool enable)
{
- rtl_runtime_suspend_enable(tp, enable);
-
if (enable) {
r8153_u1u2en(tp, false);
r8153_u2p3en(tp, false);
r8153_mac_clk_spd(tp, true);
+ rtl_runtime_suspend_enable(tp, true);
} else {
+ rtl_runtime_suspend_enable(tp, false);
r8153_mac_clk_spd(tp, false);
r8153_u2p3en(tp, true);
r8153_u1u2en(tp, true);
--
2.7.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
[PATCH net-next 07/11] r8152: move the default coalesce setting for RTL8153
Only RTL8153 could set coalesce, so move the default setting for
rtl8152_probe() to r8153_init().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 565ac5b..f78111c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3579,6 +3579,19 @@ static void r8153_init(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_USB, USB_USB_CTRL, ocp_data);
rtl_tally_reset(tp);
+
+ switch (tp->udev->speed) {
+ case USB_SPEED_SUPER:
+ case USB_SPEED_SUPER_PLUS:
+ tp->coalesce = COALESCE_SUPER;
+ break;
+ case USB_SPEED_HIGH:
+ tp->coalesce = COALESCE_HIGH;
+ break;
+ default:
+ tp->coalesce = COALESCE_SLOW;
+ break;
+ }
}
static int rtl8152_pre_reset(struct usb_interface *intf)
@@ -4524,19 +4537,6 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->mii.reg_num_mask = 0x1f;
tp->mii.phy_id = R8152_PHY_ID;
- switch (udev->speed) {
- case USB_SPEED_SUPER:
- case USB_SPEED_SUPER_PLUS:
- tp->coalesce = COALESCE_SUPER;
- break;
- case USB_SPEED_HIGH:
- tp->coalesce = COALESCE_HIGH;
- break;
- default:
- tp->coalesce = COALESCE_SLOW;
- break;
- }
-
tp->autoneg = AUTONEG_ENABLE;
tp->speed = tp->mii.supports_gmii ? SPEED_1000 : SPEED_100;
tp->duplex = DUPLEX_FULL;
--
2.7.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
[PATCH net-next 08/11] r8152: move the initialization to reset_resume function
Move tp->rtl_ops.init() from rtl8152_resume() to rtl8152_reset_resume().
The initialization is only necessary for reset_resume().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f78111c..f43b7a8 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3776,11 +3776,8 @@ static int rtl8152_resume(struct usb_interface *intf)
mutex_lock(&tp->control);
- if (!test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
- tp->rtl_ops.init(tp);
- queue_delayed_work(system_long_wq, &tp->hw_phy_work, 0);
+ if (!test_bit(SELECTIVE_SUSPEND, &tp->flags))
netif_device_attach(netdev);
- }
if (netif_running(netdev) && netdev->flags & IFF_UP) {
if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
@@ -3826,6 +3823,10 @@ static int rtl8152_reset_resume(struct usb_interface
*intf)
struct r8152 *tp = usb_get_intfdata(intf);
clear_bit(SELECTIVE_SUSPEND, &tp->flags);
+ mutex_lock(&tp->control);
+ tp->rtl_ops.init(tp);
+ queue_delayed_work(system_long_wq, &tp->hw_phy_work, 0);
+ mutex_unlock(&tp->control);
return rtl8152_resume(intf);
}
--
2.7.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
[PATCH net-next 09/11] r8152: check if disabling ALDPS is finished
Use PLA 0xe000 bit 8 to check if disabling ALDPS is finished.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f43b7a8..204f4b2 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2836,9 +2836,15 @@ static void r8153_aldps_en(struct r8152 *tp, bool enable)
data |= EN_ALDPS;
ocp_reg_write(tp, OCP_POWER_CFG, data);
} else {
+ int i;
+
data &= ~EN_ALDPS;
ocp_reg_write(tp, OCP_POWER_CFG, data);
- msleep(20);
+ for (i = 0; i < 20; i++) {
+ usleep_range(1000, 2000);
+ if (ocp_read_word(tp, MCU_TYPE_PLA, 0xe000) & 0x0100)
+ break;
+ }
}
}
--
2.7.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
[PATCH net-next 10/11] r8152: avoid rx queue more than 1000 packets
Stop queuing rx packets if it is more than 1000. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 204f4b2..fa29583 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1813,6 +1813,10 @@ static int rx_bottom(struct r8152 *tp, int budget) unsigned int pkt_len; struct sk_buff *skb; + /* limite the skb numbers for rx_queue */ + if (unlikely(skb_queue_len(&tp->rx_queue) >= 1000)) + break; + pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK; if (pkt_len < ETH_ZLEN) break; -- 2.7.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
[PATCH net-next 11/11] r8152: replace napi_complete with napi_complete_done
Change from using napi_complete to napi_complete_done to allow for the
use of gro_flush_timeout in tuning network processing.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index fa29583..5a02053 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1938,7 +1938,8 @@ static int r8152_poll(struct napi_struct *napi, int
budget)
bottom_half(tp);
if (work_done < budget) {
- napi_complete(napi);
+ if (!napi_complete_done(napi, work_done))
+ goto out;
if (!list_empty(&tp->rx_done))
napi_schedule(napi);
else if (!skb_queue_empty(&tp->tx_queue) &&
@@ -1946,6 +1947,7 @@ static int r8152_poll(struct napi_struct *napi, int
budget)
napi_schedule(napi);
}
+out:
return work_done;
}
--
2.7.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
[PATCH net-next 03/11] r8152: adjust the settings about MAC clock speed down for RTL8153
The MAC clock speed down could be enabled if the U1/U2 is disabled.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b8c904f..9a794db 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2428,6 +2428,29 @@ static void __rtl_set_wol(struct r8152 *tp, u32 wolopts)
device_set_wakeup_enable(&tp->udev->dev, false);
}
+static void r8153_mac_clk_spd(struct r8152 *tp, bool enable)
+{
+ /* MAC clock speed down */
+ if (enable) {
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL,
+ ALDPS_SPDWN_RATIO);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2,
+ EEE_SPDWN_RATIO);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
+ PKT_AVAIL_SPDWN_EN | SUSPEND_SPDWN_EN |
+ U1U2_SPDWN_EN | L1_SPDWN_EN);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4,
+ PWRSAVE_SPDWN_EN | RXDV_SPDWN_EN | TX10MIDLE_EN |
+ TP100_SPDWN_EN | TP500_SPDWN_EN | EEE_SPDWN_EN |
+ TP1000_SPDWN_EN);
+ } else {
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, 0);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, 0);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, 0);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4, 0);
+ }
+}
+
static void r8153_u1u2en(struct r8152 *tp, bool enable)
{
u8 u1u2[8];
@@ -2533,7 +2556,9 @@ static void rtl8153_runtime_enable(struct r8152 *tp, bool
enable)
if (enable) {
r8153_u1u2en(tp, false);
r8153_u2p3en(tp, false);
+ r8153_mac_clk_spd(tp, true);
} else {
+ r8153_mac_clk_spd(tp, false);
r8153_u2p3en(tp, true);
r8153_u1u2en(tp, true);
}
@@ -2881,6 +2906,7 @@ static void r8153_first_init(struct r8152 *tp)
u32 ocp_data;
int i;
+ r8153_mac_clk_spd(tp, false);
rxdy_gated_en(tp, true);
r8153_teredo_off(tp);
@@ -2947,6 +2973,8 @@ static void r8153_enter_oob(struct r8152 *tp)
u32 ocp_data;
int i;
+ r8153_mac_clk_spd(tp, true);
+
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
ocp_data &= ~NOW_IS_OOB;
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL, ocp_data);
@@ -3513,13 +3541,9 @@ static void r8153_init(struct r8152 *tp)
r8153_power_cut_en(tp, false);
r8153_u1u2en(tp, true);
+ r8153_mac_clk_spd(tp, false);
usb_enable_lpm(tp->udev);
- /* MAC clock speed down */
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL, 0);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL2, 0);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, 0);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4, 0);
rtl_tally_reset(tp);
r8153_u2p3en(tp, true);
--
2.7.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
[PATCH 11/11] USB: usbip: convert to use DRIVER_ATTR_RW
We are trying to get rid of DRIVER_ATTR(), and the usbip driver
attribute can be trivially changed to use DRIVER_ATTR_RW().
Cc: Valentina Manea
Cc: Shuah Khan
Cc:
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/usbip/stub_main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index 44ab43fc4fcc..e74fbb7f4a32 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -134,7 +134,7 @@ int del_match_busid(char *busid)
return ret;
}
-static ssize_t show_match_busid(struct device_driver *drv, char *buf)
+static ssize_t match_busid_show(struct device_driver *drv, char *buf)
{
int i;
char *out = buf;
@@ -149,7 +149,7 @@ static ssize_t show_match_busid(struct device_driver *drv,
char *buf)
return out - buf;
}
-static ssize_t store_match_busid(struct device_driver *dev, const char *buf,
+static ssize_t match_busid_store(struct device_driver *dev, const char *buf,
size_t count)
{
int len;
@@ -181,8 +181,7 @@ static ssize_t store_match_busid(struct device_driver *dev,
const char *buf,
return -EINVAL;
}
-static DRIVER_ATTR(match_busid, S_IRUSR | S_IWUSR, show_match_busid,
- store_match_busid);
+static DRIVER_ATTR_RW(match_busid);
static ssize_t rebind_store(struct device_driver *dev, const char *buf,
size_t count)
--
2.13.1
--
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: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
On Fri, Jun 09, 2017 at 10:52:42AM +0200, Bjørn Mork wrote: > Greg KH writes: > > > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote: > >> Longer-term, we'd ideally make 'generic' driver special and let it attach > >> as a 'last resort driver' if none of the specific driver picked the device > >> up during probe. But I don't think our current driver model allows this > >> easily ... or is there way I am not seeing? > > > > Nope, the driver model does not provide a way for this, sorry, it's been > > a complaint from the very beginning that we don't really know how to > > handle, except to make sure the order of the drivers loaded are the > > priority list, and that's not really a solution at all. > > Add a 'priority' field to struct device_driver and sort the list by this > field instead of load order? We've been over this before :) What happens when a new module is loaded, are you supposed to then disconnect a device from an existing driver, recan all of the existing drivers, and then bind the "correct" one then? sorry, 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: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
Hi, On 09-06-17 10:52, Bjørn Mork wrote: Greg KH writes: On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote: Longer-term, we'd ideally make 'generic' driver special and let it attach as a 'last resort driver' if none of the specific driver picked the device up during probe. But I don't think our current driver model allows this easily ... or is there way I am not seeing? Nope, the driver model does not provide a way for this, sorry, it's been a complaint from the very beginning that we don't really know how to handle, except to make sure the order of the drivers loaded are the priority list, and that's not really a solution at all. Add a 'priority' field to struct device_driver and sort the list by this field instead of load order? It is not that easy, e.g. with the HID use-case in question the generic HID driver will typically be built-in where as the vendor specific drivers will be modules, so you don't know if a higher priority driver may show up later... TBH I think that just adding a bunch of #ifdef's to the hid_have_special_driver array may be best (esp. for 4.12) Regards, Hans -- 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: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
Greg KH writes: > On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote: >> Longer-term, we'd ideally make 'generic' driver special and let it attach >> as a 'last resort driver' if none of the specific driver picked the device >> up during probe. But I don't think our current driver model allows this >> easily ... or is there way I am not seeing? > > Nope, the driver model does not provide a way for this, sorry, it's been > a complaint from the very beginning that we don't really know how to > handle, except to make sure the order of the drivers loaded are the > priority list, and that's not really a solution at all. Add a 'priority' field to struct device_driver and sort the list by this field instead of load order? Bjørn -- 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 1/5] phy: tusb1210: add support for TUSB1211
Hi Felipe, On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote: > TUSB1211 is software compatible with TUSB1210 and as such we don't > need an entire new driver to control it. Let's add its product ID to > the existing TUSB1210 driver instead. > > Signed-off-by: Felipe Balbi > --- > drivers/phy/phy-tusb1210.c | 3 ++- The directory structure in phy has changed a bit. phy-tusb1210.c is now in drivers/phy/ti/. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_mass_storage: Fix the logic to iterate all common->luns
On 06/09/2017 10:18 AM, Axel Lin wrote:
It is wrong to do --i in the for loop.
Fixes: dd02ea5a3305 ("usb: gadget: mass_storage: Use static array for luns")
Signed-off-by: Axel Lin
---
drivers/usb/gadget/function/f_mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 74d57d6..5742813 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2572,7 +2572,7 @@ static int fsg_main_thread(void *common_)
int i;
down_write(&common->filesem);
- for (i = 0; i < ARRAY_SIZE(common->luns); --i) {
+ for (i = 0; i < ARRAY_SIZE(common->luns); i++) {
OMG... Totally right. I have no idea how I could wrote sth like this.
Reviewed-by: Krzysztof Opasiak
Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote: > Longer-term, we'd ideally make 'generic' driver special and let it attach > as a 'last resort driver' if none of the specific driver picked the device > up during probe. But I don't think our current driver model allows this > easily ... or is there way I am not seeing? Nope, the driver model does not provide a way for this, sorry, it's been a complaint from the very beginning that we don't really know how to handle, except to make sure the order of the drivers loaded are the priority list, and that's not really a solution at all. 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: [RFC] usb-phy-generic: Add support to SMSC USB3315
> >I have a look at your patches >(http://www.spinics.net/lists/linux-usb/msg157134.html) >and I wonder if power sequence is applicable only on hub node? No, power sequence can be used for any devices which needs to carry out power on before probe. > hub are probed too >late (after ci_ulpi_init). Do you think it is possible to read a power >sequence in dts >from ci_ulpi_init? > I think the suitable place for power sequence is at ulpi_of_register, some ULPI PHYs need to carry out power on before reading ID. Peter
Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
On Fri, 9 Jun 2017, Hans de Goede wrote: > Right, so this is not really a problem with this specific patch, but > with how the hid_have_special_driver array works in general currently it > has very few #if IS_ENABLED(CONFIG_FOO) guards around all the devices it > blacklists the generic HID driver for. This is something I've been wanting to fix for ages, but never really got to it. So let's take this as the final impulse to do it. > I think this is on purpose to stop things becoming one big #ifdef party, > but as you rightfully say this means that people may end up with not > having a driver at all. Yeah, ifdef-hell is currently hardly avoidable, but I don't really see too many better options, at least as a short-term solution. I'll come up with something and send it out ASAP for 4.12-rc still. Longer-term, we'd ideally make 'generic' driver special and let it attach as a 'last resort driver' if none of the specific driver picked the device up during probe. But I don't think our current driver model allows this easily ... or is there way I am not seeing? Thanks, -- Jiri Kosina SUSE Labs -- 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: gadget: f_mass_storage: Fix the logic to iterate all common->luns
It is wrong to do --i in the for loop.
Fixes: dd02ea5a3305 ("usb: gadget: mass_storage: Use static array for luns")
Signed-off-by: Axel Lin
---
drivers/usb/gadget/function/f_mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 74d57d6..5742813 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2572,7 +2572,7 @@ static int fsg_main_thread(void *common_)
int i;
down_write(&common->filesem);
- for (i = 0; i < ARRAY_SIZE(common->luns); --i) {
+ for (i = 0; i < ARRAY_SIZE(common->luns); i++) {
struct fsg_lun *curlun = common->luns[i];
if (!curlun || !fsg_lun_is_open(curlun))
continue;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works
Hi,
First of all lets add the HID subsys maintainers to the To list (done).
On 08-06-17 22:17, Linus Torvalds wrote:
On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote:
So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans
to straighten this out.
No, I think the main problem is that the hid_have_special_driver[]
array change is garbage.
It adds the ASUS ID, regardless of whether the special driver exists or not.
We *really* shouldn't do that. We had a very similar regression wrt
the "improved" synaptics RMI handling in commit 279967a65b32.
If you didn't have HID_RMI enabled at all, that commit made the
regular HID driver not take care of the device, and without an RMI
driver there was nothing else that took care of it either.
So when you add things like "don't react to this device", you damn
well should make sure that something else *does* react to the device
instead.
So those ASUSTEK entries that get disabled in hid-core.c should be
protected by something like
#if IS_ENABLED(CONFIG_HID_ASUS)
...
#endif
exactly so that the core HID subsystem doesn't ignore them when
nothing else picks up the slack.
I note that *some* cases do do that. Too few, apparently.
PLEASE STOP THIS MINDLESS "DISABLE GENERIC DEVICE DISCOVERY" CRAP!
It's only ok to disable a generic device if you actually have a real
working fallback that is actually enabled!
So that commit 76dd1fbebbae ("HID: asus: Add support for T100
keyboard") is actively buggy, because it incorrectly assumes a
particular config.
Right, so this is not really a problem with this specific patch,
but with how the hid_have_special_driver array works in general
currently it has very few #if IS_ENABLED(CONFIG_FOO) guards
around all the devices it blacklists the generic HID driver for.
I think this is on purpose to stop things becoming one big
#ifdef party, but as you rightfully say this means that people
may end up with not having a driver at all.
Some device-specific drivers have this in their Kconfig:
default !EXPERT
Which the HID_ASUS entry lacks.
Jiri, Benjamin, how do you want to solve this ?
Regards,
Hans
--
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: host: ehci: workaround PME bug on AMD EHCI controller
As Alan Stern points out [1], the PME signal is not enabled when
controller is in D3, therefore it's not being woken up when new deivces
get plugged in.
Workaround this bug by preventing the controller enters D3 power state.
[1] https://www.spinics.net/lists/linux-usb/msg157462.html
Signed-off-by: Kai-Heng Feng
---
drivers/usb/host/ehci-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 93326974ff4b..616685f83954 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -181,6 +181,8 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
if (pdev->device == 0x7808) {
ehci->use_dummy_qh = 1;
ehci_info(ehci, "applying AMD SB700/SB800/Hudson-2/3
EHCI dummy qh workaround\n");
+
+ pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
}
break;
case PCI_VENDOR_ID_VIA:
--
2.13.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: Continuous, infinite warm reset attempts in Chipidea HDRC on multiple connect-disconects
Hi, lingareddy praneethreddy writes: >>> Until then can you help us with the one thing i.e. can you point me to >>> where in the latest kernel code is the warm reset initiated? Thanks >>> again. >> >> You have the full source tree, it's easier for you to search for it :) >> >> Good luck! >> >> greg k-h > > Sure Greg, I will locate that. I will suspend this discussion till > we reproduce the issue on newer kernel i.e. 4.1.15. 4.1.15 is already really old. tag v4.1.15 Tagger: Greg Kroah-Hartman Date: Mon Dec 14 21:24:57 2015 -0800 Why don't you try v4.11.4 or or v4.12-rc4? -- balbi signature.asc Description: PGP signature
Re: Continuous, infinite warm reset attempts in Chipidea HDRC on multiple connect-disconects
On Fri, Jun 9, 2017 at 12:19 PM, Greg KH wrote: > On Fri, Jun 09, 2017 at 11:57:23AM +0530, lingareddy praneethreddy wrote: >> On Wed, Jun 7, 2017 at 9:09 PM, Alan Stern wrote: >> > On Wed, 7 Jun 2017, lingareddy praneethreddy wrote: >> > >> >> On Tue, Jun 6, 2017 at 7:38 PM, Alan Stern >> >> wrote: >> >> >>On Tue, 6 Jun 2017, lingareddy praneethreddy wrote: >> >> >> >> >> >> I am using Chipidea HDRC on imx6sl platform. On connecting USB stick >> >> >> (sometimes) and Android/ Apple phone (frequent) to ci-hdrc multiple >> >> >> time it is seen that hub (ehci_hub_control()) reports continuous >> >> >> USB_PORT_FEAT_C_RESET (infinitely) before a disconnect-connect caused >> >> >> USB_PORT_FEAT_C_OVER_CURRENT. >> >> > >> >> > Can you post a debugging log? Do: >> >> > >> >> > echo 'module usbcore =p' >> >> > >/sys/kernel/debug/dynamic_debug/control >> >> > >> >> > before plugging in the device, and then copy the dmesg output. >> >> Thanks Alan. I have attached the full log. What I see is repeated calls >> >> like >> >> >> >> [ 42.984214] hub 1-0:1.0: port 1, status 0109, change 0003, 12 Mb/s >> >> [ 43.144120] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms >> >> status 0x109 >> >> [ 43.204151] hub 1-0:1.0: state 7 ports 1 chg evt 0002 >> >> [ 43.204190] hub 1-0:1.0: port 1, status 0109, change 0003, 12 Mb/s >> >> [ 43.364118] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms >> >> status 0x109 >> > >> > All those 0109 and 0108 port status values in the log indicate that the >> > port's over-current status bit is turned on. Nothing will work >> > properly until you fix that. >> > >> >> Let me know if you want working logs. I can attach that as well. >> >> > >> >> >> I have two queries: >> >> >> 1. Can we avoid the continuous warm reset ( USB_PORT_FEAT_C_RESET ) >> >> >> i.e. can we force hub to initialize again and enumerate the device >> >> >> again? >> >> > >> >> > Reset _does_ initialize and enumerate the device again. >> >> > >> >> >> 2. Do we need to initialize both controller and hub i.e. we >> >> >> initialized controller (calling ehci_setup() and ehci_run()) but the >> >> >> hub continued the resets until the overcurrent bit was set. >> >> > >> >> > I don't understand this question. But remember, the hardware does not >> >> > decide when to issue a reset. That decision is made by the driver >> >> > software in the kernel. >> >> > >> >> > >> >> >> >> I meant.. can we stop this continuous warm reset in the driver? >> > >> > The log shows you are using kernel version 3.10.17. You wouldn't >> > believe how out of date that kernel is. What happens if you use a 4.11 >> > kernel? >> > >> >> I was unable to >> >> pinpoint in the code where the warm reset is initiated again if the >> >> device is >> >> connected but no valid device is found. Can you help me pinpoint the code >> >> that reinitiates the warm reset? Thanks. >> > >> > I can't help unless you use an up-to-date kernel. >> > >> > Alan Stern >> > >> >> Thanks Alan. I understand and agree. >> >> It is a legacy platform that we are supporting and I needed to address >> this issue on 3.10.17. We are in the process of migrating to 4.1.x >> this coming week to check on this behavior. > > 4.1.x or 4.11.x? They are a very different :) > >> Until then can you help us with the one thing i.e. can you point me to >> where in the latest kernel code is the warm reset initiated? Thanks >> again. > > You have the full source tree, it's easier for you to search for it :) > > Good luck! > > greg k-h Sure Greg, I will locate that. I will suspend this discussion till we reproduce the issue on newer kernel i.e. 4.1.15. Thanks all. -- Thanks&Regards Praneeth Reddy L 8123739792 -- 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
