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 section 9.4.11, how to
>> calculate
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.
>> >>
>> >> --
>> >> balbi
>> >
>> > By dummy - are
> >>
> >> 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
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
from usb_get_status().
Fixes: 2e43f0fe379c
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 error of some sort.
>>
>> Th
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
---
Documentation/devicetree/bindin
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
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
--
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 usb_of_
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 a
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
U
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 specificati
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:
&usb1 { /* host controller */
dev1: device@1 { /* device at port 1 */
compat
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 deletions(-)
diff --g
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
> > to avoid out-of-bounds ac
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 descript
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
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.
Signed-o
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
> wor
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
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.
> >>
> >> --
> >> balbi
> >
>
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 the usb devices getting reset
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 ho
* 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.
Regards,
Tony
> diff --git a/drivers/usb/core/message.c b/dr
* 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 Lindgren
> Fixes: 2e43f0fe379c ("
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..
-hink
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 yester
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.
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 is
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:
> >
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 lo
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 (Defau
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 i
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 writes:
>> I have followed the
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
>> > git://git.kernel.org/pub/scm/linux/kerne
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" is run and inter
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
> fu
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 of dummy_hcd?
Okay, we
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 th
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 I get:
>
> # Testing wi
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
Signed-off-by: Felipe Balbi
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 Lindgren wrote:
> Hi Felipe & Greg,
>
> Looks like in next-20171108 USB hub is spamming console about once a
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
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 next-20171108 USB hub is spamming console about once a
second after commit 7dfd74fd128 ("
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 after commit 7dfd74fd128 ("Merge remote-tracking branch
>>> '
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 in
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
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
>> 'usb/usb-next'").
>>
>> Any ideas
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 leg
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 capable to manage only f
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
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 us
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
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 ru
54 matches
Mail list logo
