Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly

2019-09-30 Thread Yegor Yefremov
On Sat, Sep 28, 2019 at 6:09 PM Yegor Yefremov wrote: > > On Fri, Sep 27, 2019 at 5:57 PM Tony Lindgren wrote: > > > > * Tony Lindgren [190927 15:20]: > > > * Yegor Yefremov [190927 12:31]: > > > > On Fri, Sep 27, 2019 at 10:18 AM Yegor Yefremov > > > > wrote: > > > > > > > > > > I was porting

Re: [PATCH 1/1] usb: host: xhci: update event ring dequeue pointer on purpose

2019-09-30 Thread Mathias Nyman
On 27.9.2019 10.03, Peter Chen wrote: On 19-09-26 13:25:39, Mathias Nyman wrote: On 24.9.2019 11.35, Peter Chen wrote: On some situations, the software handles TRB events slower than adding TRBs, then xhci_handle_event can't return zero long time, the xHC will consider the event ring is full, a

Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly

2019-09-30 Thread Yegor Yefremov
On Mon, Sep 30, 2019 at 8:59 AM Yegor Yefremov wrote: > > On Sat, Sep 28, 2019 at 6:09 PM Yegor Yefremov > wrote: > > > > On Fri, Sep 27, 2019 at 5:57 PM Tony Lindgren wrote: > > > > > > * Tony Lindgren [190927 15:20]: > > > > * Yegor Yefremov [190927 12:31]: > > > > > On Fri, Sep 27, 2019 at

Re: [PATCH v2 1/1] usb: host: xhci: update event ring dequeue pointer on purpose

2019-09-30 Thread Mathias Nyman
On 29.9.2019 9.07, Peter Chen wrote: On some situations, the software handles TRB events slower than adding TRBs, then xhci_handle_event can't return zero long time, the xHC will consider the event ring is full, and trigger "Event Ring Full" error, but in fact, the software has already finished l

RE: [PATCH v2 1/1] usb: host: xhci: update event ring dequeue pointer on purpose

2019-09-30 Thread Peter Chen
> On 29.9.2019 9.07, Peter Chen wrote: > > On some situations, the software handles TRB events slower than adding > > TRBs, then xhci_handle_event can't return zero long time, the xHC will > > consider the event ring is full, and trigger "Event Ring Full" error, > > but in fact, the software has

NULL-deref in xhci_clear_tt_buffer_complete()

2019-09-30 Thread Johan Hovold
Hi Mathias, I hit this NULL-deref in xhci_clear_tt_buffer_complete() with usb-next after an external HS hub with a connected FS device got into some weird state this morning: [ 66.833702] usb 2-2.4: USB disconnect, device number 5 [ 66.834756] usblcd 2-2.4:1.0: USB LCD #144 now disconnected

[no subject]

2019-09-30 Thread Juergen Spagolla
Heeft u een persoonlijke lening, een zakelijke lening of projectfinanciering / investeringslening nodig. Wij bieden deze en nog veel meer financieringsdiensten tegen een vaste rentevoet van 3% per jaar. Neem voor meer informatie contact met ons op via e-mail: sigmafinance...@gmail.com stuur e-ma

[PATCH V2] usb: gadget: composite: Fix possible double free memory bug

2019-09-30 Thread Chandana Kishori Chiluveru
composite_dev_cleanup call from the failure of configfs_composite_bind frees up the cdev->os_desc_req and cdev->req. If the previous calls of bind and unbind is successful these will carry stale values. Consider the below sequence of function calls: configfs_composite_bind() composite_dev_

Re: [chipidea] continuous USB resets on NXP i.MX 6ULL device

2019-09-30 Thread Igor Opaniuk
Hi Peter, On Wed, Sep 25, 2019 at 3:44 AM Peter Chen wrote: > > > > > > Hi Fabio, Peter, Stefan, > > > > I've incidentally discovered your last year discussion in ML [1] (I hope it > > rings the > > bell) regarding the issue I'm still observing on the same device with the > > mainline > > kerne

Re: NULL-deref in xhci_clear_tt_buffer_complete()

2019-09-30 Thread Mathias Nyman
On 30.9.2019 13.31, Johan Hovold wrote: Hi Mathias, I hit this NULL-deref in xhci_clear_tt_buffer_complete() with usb-next after an external HS hub with a connected FS device got into some weird state this morning: [ 66.833702] usb 2-2.4: USB disconnect, device number 5 [ 66.834756] usblcd

[PATCH] usb: gadget: Quieten gadget config message

2019-09-30 Thread Joel Stanley
On a system that often re-configures a USB gadget device the kernel log is filled with: configfs-gadget gadget: high-speed config #1: c Reduce the verbosity of this print to debug. Signed-off-by: Joel Stanley --- drivers/usb/gadget/composite.c | 6 +++--- 1 file changed, 3 insertions(+), 3 d

Re: [PATCH] Check for changed device descriptors when a connection-change occurs before validating the connection.

2019-09-30 Thread Alan Stern
On Mon, 30 Sep 2019, David Heinzelmann wrote: > Hi, > > I adjusted the patch. Any comments? If it's okay, I will re-sent the patch > to the mailing list. > > Here is the second version: > > > From dc78b8add72168215b8295e01ce3e2599b4998f7 Mon Sep 17 00:00:00 2001 > From: David Heinzelmann > D

Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly

2019-09-30 Thread Tony Lindgren
* Yegor Yefremov [190930 08:20]: > On Mon, Sep 30, 2019 at 8:59 AM Yegor Yefremov > wrote: > > > > On Sat, Sep 28, 2019 at 6:09 PM Yegor Yefremov > > wrote: > > > > > > On Fri, Sep 27, 2019 at 5:57 PM Tony Lindgren wrote: > > > > Looks like I'm unable to reproduce this with bbb and FT232R > > >

Re: WARNING in _chaoskey_fill/usb_submit_urb

2019-09-30 Thread syzbot
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: INFO: task hung in chaoskey_disconnect INFO: task kworker/0:0:5 blocked for more than 143 seconds. Not tainted 5.3.0+ #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworke

Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly

2019-09-30 Thread Tony Lindgren
* Tony Lindgren [190930 14:57]: > * Yegor Yefremov [190930 08:20]: > > On Mon, Sep 30, 2019 at 8:59 AM Yegor Yefremov > > wrote: > > > > > > On Sat, Sep 28, 2019 at 6:09 PM Yegor Yefremov > > > wrote: > > > > > > > > On Fri, Sep 27, 2019 at 5:57 PM Tony Lindgren wrote: > > > > > Looks like I'm

depmod warning: unknown symbol usb_stor_sense_invalidCDB in 5.4-rc1

2019-09-30 Thread Stefan Wahren
Hi, during make modules_install for arm/multi_v7_defconfig on current Linux 5.4-rc1, i'm getting the following warnings: depmod: WARNING: /media/stefan/rootfs//lib/modules/5.4.0-rc1-6-g4a80125-dirty/kernel/drivers/usb/storage/uas.ko needs unknown symbol usb_stor_sense_invalidCDB depmod: WARNI

Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly

2019-09-30 Thread Sebastian Reichel
Hi, On Mon, Sep 30, 2019 at 08:23:30AM -0700, Tony Lindgren wrote: > * Tony Lindgren [190930 14:57]: > > * Yegor Yefremov [190930 08:20]: > > > On Mon, Sep 30, 2019 at 8:59 AM Yegor Yefremov > > > wrote: > > > > > > > > On Sat, Sep 28, 2019 at 6:09 PM Yegor Yefremov > > > > wrote: > > > > > >

Re: Moschip 7703 USB to serial free to a good home

2019-09-30 Thread Aaron Thompson
On Mon, Sep 23, 2019 at 11:58 PM Bjørn Mork wrote: > > Aaron Thompson writes: > > > I have a Moschip 7703 USB to single serial port adapter that I'm not > > using primarily because it doesn't have an in-tree driver, so I'd be > > happy to send it to anyone who would like to add support for it. It

KASAN: slab-out-of-bounds Read in hiddev_ioctl_usage

2019-09-30 Thread syzbot
Hello, syzbot found the following crash on: HEAD commit:2994c077 usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=15170f6d60 kernel config: https://syzkaller.appspot.com/x/.

Re: [PATCH 1/4] dt-bindings: usb: usb251xb: add documentation for voltage supply

2019-09-30 Thread Rob Herring
On Tue, 17 Sep 2019 16:44:46 +0200, Marco Felsch wrote: > Add the optional voltage supply documentation. If not specified the > dummy-regulator is used. > > Signed-off-by: Marco Felsch > --- > Documentation/devicetree/bindings/usb/usb251xb.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by

Re: [PATCH V2] usb: gadget: composite: Fix possible double free memory bug

2019-09-30 Thread Felipe Balbi
Hi, Chandana Kishori Chiluveru writes: > composite_dev_cleanup call from the failure of configfs_composite_bind > frees up the cdev->os_desc_req and cdev->req. If the previous calls of > bind and unbind is successful these will carry stale values. > > Consider the below sequence of function call