Re: [PATCH] usb: core: add support for USB_REQ_SET_ISOCH_DELAY

Hi, Greg Kroah-Hartman writes: > On Thu, Nov 09, 2017 at 03:41:54PM +0200, Felipe Balbi wrote: >> USB SS and SSP hubs provide wHubDelay values on their hub descriptor >> which we should inform the USB Device about. >> >> The USB Specification 3.0 explains, on

Re: Multiple g_zero gadgets

Hi, Alan Stern writes: >> Hinko Kocevar writes: >> >> The way dummy was written, it can only instantiate one gadget. You >> >> either need a real USB peripheral controller, or you need to patch dummy >> >> to instantiate more than one gadget. >>

RE: MX25 USB timeout on ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB

> >> > >> Seems that I can not come out from the reset. I have tried all the > >> kernels and having the same problem. Only the 2.6.x from freescale is > >> not affected but this is not helping me. > >> > >> Do you have any suggestion? > >> > > > > Would you try to dump USB registers between two

Re: [PATCH] usb: core: message: remember to reset 'ret' to 0 when necessary

Works in APL platform. Tested-by: Kuppuswamy Sathyanarayanan On 11/09/2017 02:59 AM, Felipe Balbi wrote: usb_control_msg() will return the amount of bytes transferred, if that amount matches what we wanted to transfer, we need to reset 'ret' to 0

Re: NULL pointer dereference in usb_ifnum_to_if

Hi, 2017-11-09 3:40 GMT+09:00 Alan Stern : > On Wed, 8 Nov 2017, Philipp Kern wrote: > >> > If the bad access occurred because the uvc driver tried to access a >> > device that had been removed 5 seconds earlier, the most likely >> > explanation is a reference-counting

[PATCH 4/8] dt-bindings: usb: document hub and host-controller properties

Hub nodes and host-controller nodes with child nodes must specify values for #address-cells (1) and #size-cells (0). Also make the definition of the related reg property a bit more stringent, and add comments to the example source. Signed-off-by: Johan Hovold ---

[PATCH 5/8] dt-bindings: usb: add interface binding

Add a new binding for USB interface nodes, which are child nodes of USB device nodes and addressed by interface number and configuration value tuples. Also add a new binding for USB combined nodes, which are special case nodes for simple USB devices for which they replace the device and interface

[PATCH 1/8] dt-bindings: usb: fix example hub node name

According to the OF Recommended Practice for USB, hub nodes shall be named "hub", but the example had mixed up the label and node names. Fix the node name and drop the redundant label. While at it, remove a newline and add a missing semicolon to the example source. Signed-off-by: Johan Hovold

[PATCH 8/8] USB: of: clean up device-node helper

Clean up the USB device-node helper that is used to look up a device node given a parent hub device and a port number. Also pass in a struct usb_device as first argument to provide some type checking. Give the helper the more descriptive name usb_of_get_device_node(), which matches the new

[PATCH 0/8] USB: add device-tree support for interfaces

This series adds support for representing USB interfaces in device tree by implementing support for "interface nodes" and "combined nodes" from the OF specification. This is needed to be able to describe non-discoverable properties of permanently attached USB devices and their interfaces such as

[PATCH 7/8] USB: ledtrig-usbport: fix of-node leak

This code looks up a USB device node from a given parent USB device but never dropped its reference to the returned node. As only the address of the node is used for a later matching, the reference can be dropped immediately. Note that this trigger implementation confuses the description of the

[PATCH 2/8] dt-bindings: usb: fix reg-property port-number range

The USB hub port-number range for USB 2.0 is 1-255 and not 1-31 which reflects an arbitrary limit set by the current Linux implementation. Note that for USB 3.1 hubs the valid range is 1-15. Increase the documented valid range in the binding to 255, which is the maximum allowed by the

[PATCH 6/8] USB: add device-tree support for interfaces

Add OF device-tree support for USB interfaces. USB "interface nodes" are children of USB "device nodes" and are identified by an interface number and a configuration value: { /* host controller */ dev1: device@1 { /* device at port 1 */ compatible

[PATCH 3/8] dt-bindings: usb: clean up compatible property

Add quotation marks around the compatible string to avoid ambiguity due to following punctuation, and define the VID and PID components. Signed-off-by: Johan Hovold --- Documentation/devicetree/bindings/usb/usb-device.txt | 10 +- 1 file changed, 5 insertions(+), 5

Re: [PATCH] USB: core: Add type-specific length check of BOS descriptors

On Thu, 9 Nov 2017 17:47:01 +0100 Greg KH wrote: > On Fri, Nov 10, 2017 at 01:25:50AM +0900, Masakazu Mokuno wrote: > > > > As most of BOS descriptors are longer in length than their header > > 'struct usb_dev_cap_header', comparing solely with it is not sufficient

[PATCH] usb: f_fs: Drop check on Reserved1 field on OS_DESC_EXT_COMPAT

This check has gone through several incompatible variations in commits 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT"), 354bc45bf329 ("usb: gadget: f_fs: Fix ExtCompat descriptor validation") and 3ba534df815f ("Revert "usb: gadget: f_fs: Fix ExtCompat

Re: [PATCH] USB: core: Add type-specific length check of BOS descriptors

On Fri, Nov 10, 2017 at 01:25:50AM +0900, Masakazu Mokuno wrote: > > As most of BOS descriptors are longer in length than their header > 'struct usb_dev_cap_header', comparing solely with it is not sufficient > to avoid out-of-bounds access to BOS descriptors. > > This patch adds descriptor type

[PATCH] USB: core: Add type-specific length check of BOS descriptors

As most of BOS descriptors are longer in length than their header 'struct usb_dev_cap_header', comparing solely with it is not sufficient to avoid out-of-bounds access to BOS descriptors. This patch adds descriptor type specific length check in usb_get_bos_descriptor() to fix the issue.

Re: [PATCH v2] usb: hub: Cycle HUB power when initialization fails

On Thu, 9 Nov 2017, Mike Looijmans wrote: > Sometimes the USB device gets confused about the state of the initialization > and > the connection fails. In particular, the device thinks that it's already set > up > and running while the host thinks the device still needs to be configured. To >

Re: WARNING in usb_submit_urb

On Thu, 9 Nov 2017, Oliver Neukum wrote: > Am Donnerstag, den 09.11.2017, 13:19 +0100 schrieb Andrey Konovalov: > > > > This isn't the "BOGUS urb xfer" warning, this is "BOGUS urb flags". So > > 2 means the URB_ISO_ASAP flag, which is passed in urb->transfer_flags > > but not allowed. And as far

Re: Multiple g_zero gadgets

On Thu, 9 Nov 2017, Felipe Balbi wrote: > > Hi, > > Hinko Kocevar writes: > >> The way dummy was written, it can only instantiate one gadget. You > >> either need a real USB peripheral controller, or you need to patch dummy > >> to instantiate more than one gadget. > >> >

Re: Suspend to disk with usb connected fails to detect usb(reset) during resume

On 11/08/2017 06:29 AM, Ivid Suvarna wrote: > On Tue, Nov 7, 2017 at 9:19 PM, Alan Stern wrote: >> On Tue, 7 Nov 2017, Ivid Suvarna wrote: >> >>> Hi, >>> >>> I am trying to support suspend to disk(hibernate) on Hikey with 4.4 >>> kernel. During suspend, I could see

Re: [PATCH] USB: usbfs: compute urb->actual_length for isochronous

On Thu, 9 Nov 2017, Minas Harutyunyan wrote: > Hi Alan, > > On 11/8/2017 9:23 PM, Alan Stern wrote: > > The USB kerneldoc says that the actual_length field "is read in > > non-iso completion functions", but the usbfs driver uses it for all > > URB types in processcompl(). Since not all of the

Re: USB regression in next-20171108 with hub spamming

* Felipe Balbi [171109 11:01]: > Felipe Balbi writes: > > Okay, found it. Testing a patch. > > Here's the patch, I'll send it formally shortly. Thanks yeah that fixes the issue for me, replied to your formal patch with a tested by.

Re: [PATCH] usb: core: message: remember to reset 'ret' to 0 when necessary

* Felipe Balbi [171109 11:01]: > usb_control_msg() will return the amount of bytes transferred, if that > amount matches what we wanted to transfer, we need to reset 'ret' to 0 > from usb_get_status(). Thanks that fixes the issue I was seeing: Tested-by: Tony

Re: Multiple g_zero gadgets

Thanks for explaining! I've resorted to creating a dummy_hcd2.c and zero2.c from corresponding existing sources, tweaked source and Makefiles a bit, compiled and loaded four modules. As a result I get two dummy buses and two zero gadgets, one on each bus.. perfect! Now to see if is usable..

Re: next/master boot: 264 boots: 62 failed, 199 passed with 3 conflicts (next-20171109)

On Thu, Nov 09, 2017 at 01:47:13PM +, Mark Brown wrote: > On Thu, Nov 09, 2017 at 01:45:02PM +, Mark Brown wrote: > > On Thu, Nov 09, 2017 at 04:14:26AM -0800, kernelci.org bot wrote: > > > > Today's -next fails to boot a bcm2836-rpi-2-b on any config in kernelci, > > it was working

Re: [PATCH] usb: core: add support for USB_REQ_SET_ISOCH_DELAY

On Thu, Nov 09, 2017 at 03:41:54PM +0200, Felipe Balbi wrote: > USB SS and SSP hubs provide wHubDelay values on their hub descriptor > which we should inform the USB Device about. > > The USB Specification 3.0 explains, on section 9.4.11, how to > calculate the value and how to issue the request.

Re: [PATCH] video: udlfb: Fix read EDID timeout

On Thursday, November 02, 2017 12:02:16 PM Ladislav Michl wrote: > While usb_control_msg function expects timeout in miliseconds, a value > of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error > message which looks like: > udlfb: Read EDID byte 78 failed err ff92 > as error

Re: next/master boot: 264 boots: 62 failed, 199 passed with 3 conflicts (next-20171109)

On Thu, Nov 09, 2017 at 01:45:02PM +, Mark Brown wrote: > On Thu, Nov 09, 2017 at 04:14:26AM -0800, kernelci.org bot wrote: > > Today's -next fails to boot a bcm2836-rpi-2-b on any config in kernelci, > it was working yesterday: > > > bcm2835_defconfig: > > bcm2836-rpi-2-b: > >

Re: next/master boot: 264 boots: 62 failed, 199 passed with 3 conflicts (next-20171109)

On Thu, Nov 09, 2017 at 04:14:26AM -0800, kernelci.org bot wrote: Today's -next fails to boot a bcm2836-rpi-2-b on any config in kernelci, it was working yesterday: > bcm2835_defconfig: > bcm2836-rpi-2-b: > lab-collabora: new failure (last pass: next-20171107) The boot

[PATCH] usb: core: add support for USB_REQ_SET_ISOCH_DELAY

USB SS and SSP hubs provide wHubDelay values on their hub descriptor which we should inform the USB Device about. The USB Specification 3.0 explains, on section 9.4.11, how to calculate the value and how to issue the request. Note that a USB_REQ_SET_ISOCH_DELAY is valid on all device states

Re: WARNING in usb_submit_urb

Am Donnerstag, den 09.11.2017, 13:19 +0100 schrieb Andrey Konovalov: > > This isn't the "BOGUS urb xfer" warning, this is "BOGUS urb flags". So > 2 means the URB_ISO_ASAP flag, which is passed in urb->transfer_flags > but not allowed. And as far as I understand, it gets set because uurb > (which

Re: xhci_hcd WARN Event TRB for slot ep with no TDs queued?

The problem is in Arch Linux (and derivatives) exclusively. It fails too with Manjaro but no with OpenSuse Tumbleweed. I don't think is a kernel problem. Thanks. Regards. 2017-11-06 16:29 GMT+01:00 Felipe Balbi : > > Hi, > > (please avoid top-posting) > > Juan Simón

Re: WARNING in usb_submit_urb

On Tue, Nov 7, 2017 at 6:58 PM, Alan Stern wrote: > On Tue, 7 Nov 2017, Greg KH wrote: > >> On Tue, Nov 07, 2017 at 08:11:13AM -0800, syzbot wrote: >> > Hello, >> > >> > syzkaller hit the following crash on >> > 36ef71cae353f88fd6e095e2aaa3e5953af1685d >> >

Re: [PATCH] usb: gadget: f_fs: Fix use-after-free in ffs_free_inst

Greg KH writes: > On Wed, Nov 08, 2017 at 10:13:15AM -0700, Andrew Gabbasov wrote: >> KASAN enabled configuration reports an error >> >> BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ... >> Write of size 8 by task ... >> >> This is observed after "ffs-test"

Re: [PATCH] usb: gadget: f_fs: Fix use-after-free in ffs_free_inst

On Wed, Nov 08, 2017 at 10:13:15AM -0700, Andrew Gabbasov wrote: > KASAN enabled configuration reports an error > > BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ... > Write of size 8 by task ... > > This is observed after "ffs-test" is run and interrupted. If after that >

Re: Multiple g_zero gadgets

Hi, Hinko Kocevar writes: >> The way dummy was written, it can only instantiate one gadget. You >> either need a real USB peripheral controller, or you need to patch dummy >> to instantiate more than one gadget. >> >> -- >> balbi > > By dummy - are you referring to g_zero

Re: Multiple g_zero gadgets

Hi Felipe, > > The way dummy was written, it can only instantiate one gadget. You > either need a real USB peripheral controller, or you need to patch dummy > to instantiate more than one gadget. > > -- > balbi By dummy - are you referring to g_zero of dummy_hcd? /hinko -- .. the more I see

Re: Multiple g_zero gadgets

Hi, Hinko Kocevar writes: > I'm using g_zero and dummy_hcd to test my userspace software dealing > with USB device I currently do not have. > Works great! > But for single g_zero instance ... is it possible to have two g_zero > devices seen in the system? > > Here is what

[PATCH] usb: core: message: remember to reset 'ret' to 0 when necessary

usb_control_msg() will return the amount of bytes transferred, if that amount matches what we wanted to transfer, we need to reset 'ret' to 0 from usb_get_status(). Fixes: 2e43f0fe379c ("usb: core: add a 'type' parameter to usb_get_status()") Reported-by: Tony Lindgren

Re: USB regression in next-20171108 with hub spamming

Hi, Felipe Balbi writes: > Felipe Balbi writes: > >> Felipe Balbi writes: >> >>> Hi, >>> >>> Greg Kroah-Hartman writes: On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony

Multiple g_zero gadgets

Hi, I'm using g_zero and dummy_hcd to test my userspace software dealing with USB device I currently do not have. Works great! But for single g_zero instance ... is it possible to have two g_zero devices seen in the system? Here is what I get: # Testing with dummy USB device Get kernel sources

Re: USB regression in next-20171108 with hub spamming

Felipe Balbi writes: > Felipe Balbi writes: > >> Hi, >> >> Greg Kroah-Hartman writes: >>> On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote: Hi Felipe & Greg, Looks like in

Re: USB regression in next-20171108 with hub spamming

Felipe Balbi writes: > Hi, > > Greg Kroah-Hartman writes: >> On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote: >>> Hi Felipe & Greg, >>> >>> Looks like in next-20171108 USB hub is spamming console about once a >>> second

Re: [PATCH v2] USB: add SPDX identifiers to all remaining files in drivers/usb/

On Thu 2017-11-09 11:40:28, Greg Kroah-Hartman wrote: > On Thu, Nov 09, 2017 at 10:51:48AM +0100, Pavel Machek wrote: > > Hi! > > > > > It's good to have SPDX identifiers in all files to make it easier to > > > audit the kernel tree for correct licenses. > > > > > > Update the drivers/usb/ and

Re: [PATCH v2] USB: add SPDX identifiers to all remaining files in drivers/usb/

On Thu, Nov 09, 2017 at 10:51:48AM +0100, Pavel Machek wrote: > Hi! > > > It's good to have SPDX identifiers in all files to make it easier to > > audit the kernel tree for correct licenses. > > > > Update the drivers/usb/ and include/linux/usb* files with the correct > > SPDX license identifier

Re: USB regression in next-20171108 with hub spamming

Hi, Greg Kroah-Hartman writes: > On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote: >> Hi Felipe & Greg, >> >> Looks like in next-20171108 USB hub is spamming console about once a >> second after commit 7dfd74fd128 ("Merge remote-tracking branch >>

Re: [PATCH v2] USB: add SPDX identifiers to all remaining files in drivers/usb/

Hi! > It's good to have SPDX identifiers in all files to make it easier to > audit the kernel tree for correct licenses. > > Update the drivers/usb/ and include/linux/usb* files with the correct > SPDX license identifier based on the license text in the file itself. > The SPDX identifier is a

Re: MX25 USB timeout on ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB

Hi On Thu, Nov 9, 2017 at 10:29 AM, Peter Chen wrote: > On Wed, Nov 08, 2017 at 11:41:28AM +0100, Michael Nazzareno Trimarchi wrote: >> Hi Alan >> >> I'm working on IMX25 platform where I have a USB251xBi family >> connected to the ehci full speed serial port. >> IMX25 is

Re: [PATCH RFC] usb: chipidea: imx: make over-current polarity configurable for i.MX25

On Tue, Oct 24, 2017 at 10:57:29AM +0200, Uwe Kleine-König wrote: > In commit 9dba516ed282 ("usb: chipidea: imx: set over current polarity > per dts setting") i.MX6 and i.MX7 learned the dt property > "over-current-active-high". The difference compared to i.MX25 is that on > the latter the default

Re: MX25 USB timeout on ID 0951:1665 Kingston Technology Digital DataTraveler SE9 64GB

On Wed, Nov 08, 2017 at 11:41:28AM +0100, Michael Nazzareno Trimarchi wrote: > Hi Alan > > I'm working on IMX25 platform where I have a USB251xBi family > connected to the ehci full speed serial port. > IMX25 is capable to manage only full speed port using internal > transceiver. Now we found a

Re: [PATCH] USB: usbfs: compute urb->actual_length for isochronous

Hi Alan, On 11/8/2017 9:23 PM, Alan Stern wrote: > The USB kerneldoc says that the actual_length field "is read in > non-iso completion functions", but the usbfs driver uses it for all > URB types in processcompl(). Since not all of the host controller > drivers set actual_length for isochronous

Re: USB regression in next-20171108 with hub spamming

On Wed, Nov 08, 2017 at 03:05:11PM -0800, Tony Lindgren wrote: > Hi Felipe & Greg, > > Looks like in next-20171108 USB hub is spamming console about once a > second after commit 7dfd74fd128 ("Merge remote-tracking branch > 'usb/usb-next'"). > > Any ideas? See the log below. Any chance you can