Re: Bug 196559: xhci_hcd: kernel panic using thunderbolt dell dock TB16 on 4.12.4

Hi, I found a way to reliably trigger this bug: - Boot laptop - Plug in dock (with external display connected to dock) - Send output to external display - Suspend I did a bisect between 4.12.3 and 4.12.4 and here is the result: 5cc9b698a494827b15f74ef70a31d7911d00e52a is the first bad commit

Debugging USB 3.0 Speeds

I've added a USB 3.0 card that should support super speed to a server I have, but it's not working at super-speed speeds for the external hard drives I connect, and a having a hard time diagnosing why (hardware issue/quirk? driver issue?) Before installing the card, xhci wasn't ever used,

Re: [PATCH] usb: Increase quirk delay for USB devices

On Tue, Sep 05, 2017 at 11:40:56AM +0300, Dmitry Fleytman wrote: > Commit e0429362ab15 > ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e") > introduced quirk to workaround an issue with some Logitech webcams. > > The workaround is introducing delay for some USB operations. > >

[PATCH v2 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

The Intel cherrytrail xhci controller has an extended cap mmio-range which contains registers to control the muxing to the xhci (host mode) or the dwc3 (device mode) and vbus-detection for the otg usb-phy. Having a mux driver included in the xhci code (or under drivers/usb/host) is not desirable.

[PATCH v2 02/11] mux: core: Add support for getting a mux controller on a non DT platform

On non DT platforms we cannot get the mux_chip by pnode. Other subsystems (regulator, clock, pwm) have the same problem and solve this by allowing platform / board-setup code to add entries to a lookup table and then use this table to look things up. This commit adds support for getting a mux

[PATCH v2 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems

Hi All, Here is v2 of my USB / Type-C mux series, addressing various comments from the reviews of v1. See the per patch changelogs for details. For reference here the cover letter of v1: This series consists of 4 parts: 1) Core mux changes to add support for getting mux-controllers on non

[PATCH v2 05/11] mux: Add Intel Cherrytrail USB mux driver

Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port USB data lines between the xHCI host controller and the dwc3 gadget controller. On some Cherrytrail systems this mux is controlled through AML code reacting on a GPIO IRQ connected to the USB OTG id pin (through an _AIE ACPI

[PATCH v2 08/11] staging: typec: tcpm: Set mux to device mode when configured as such

Setting the mux to TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT when the data-role is device is not correct. Plenty of devices support operating as USB device through a (separate) USB device controller. So this commit instead splits out TYPEC_MUX_USB into TYPEC_MUX_USB_HOST and TYPEC_MUX_USB_DEVICE

[PATCH v2 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver

Add a driver for the Pericom PI3USB30532 Type-C cross switch / mux chip found on some devices with a Type-C port. Signed-off-by: Hans de Goede --- Changes in v2: -Adjust for new MUX_TYPEC_foo state defines -Add MAINTAINERS entry -Various code-style fixes --- MAINTAINERS

[PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create() to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us. Also document the mux-names used by the generic tcpc_mux_dev code in our devicetree bindings. Cc: Rob Herring Cc: Mark Rutland

[PATCH v2 09/11] staging: typec: Add Generic TCPC mux driver using the mux subsys

So far the mux functionality of the tcpm code has not been hooked up in any tcpc drivers. This commit adds a generic TCPC mux driver using the mux subsys, which tcpc drivers can use to provide mux functionality in cases where an external my is used. Signed-off-by: Hans de Goede

[PATCH v2 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port

We need to add mappings for the mux subsys to be able to find the muxes for the fusb302 driver to be able to control the PI3USB30532 Type-C mux and the device/host mux integrated in the CHT SoC. Signed-off-by: Hans de Goede Acked-by: Andy Shevchenko

[PATCH v2 01/11] mux: core: Add of_mux_control_get helper function

Currently the mux_control_get implementation only deals with getting mux controllers on DT platforms. This commit renames the current implementation to of_mux_control_get to reflect this and makes mux_control_get a wrapper around of_mux_control_get. This is a preparation patch for adding support

[PATCH v2 03/11] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants

Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by USB device/host, resp. Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning of the mux_control_select() state argument. Signed-off-by: Hans de Goede ---

[PATCH 24/25 v2] net/cdc_ncm: Replace tasklet with softirq hrtimer

From: Thomas Gleixner The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in softirq context. This can be also achieved without the tasklet but with CLOCK_MONOTONIC_SOFT as hrtimer base. Signed-off-by: Thomas Gleixner Signed-off-by:

[PATCH V3] usb: host: xhci-plat: allow sysdev to inherit from ACPI

Commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration") updated the method determining DMA for XHCI from sysdev. However, this patch broke the ability to enumerate the FWNODE from parent ACPI devices from the child plat XHCI device. Currently, xhci_plat is not set up properly

Re: [PATCH V2] usb: host: xhci-plat: allow sysdev to inherit from ACPI

On Tue, Sep 05, 2017 at 10:38:03AM -0400, Adam Wallis wrote: > On 9/5/2017 10:31 AM, Greg Kroah-Hartman wrote: > > On Tue, Sep 05, 2017 at 10:25:19AM -0400, Adam Wallis wrote: > >> On 9/5/2017 10:16 AM, Greg Kroah-Hartman wrote: > >>> On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote: >

Re: [PATCH V2] usb: host: xhci-plat: allow sysdev to inherit from ACPI

On 9/5/2017 10:31 AM, Greg Kroah-Hartman wrote: > On Tue, Sep 05, 2017 at 10:25:19AM -0400, Adam Wallis wrote: >> On 9/5/2017 10:16 AM, Greg Kroah-Hartman wrote: >>> On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote: Currently, xhci_plat is not set up properly when the parent device

Re: [PATCH V2] usb: host: xhci-plat: allow sysdev to inherit from ACPI

On Tue, Sep 05, 2017 at 10:25:19AM -0400, Adam Wallis wrote: > On 9/5/2017 10:16 AM, Greg Kroah-Hartman wrote: > > On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote: > >> Currently, xhci_plat is not set up properly when the parent device is an > >> ACPI node. The conditions that

Re: [PATCH] usb: gadget: dummy: fix nonsensical comparisons

On Tue, 5 Sep 2017, Arnd Bergmann wrote: > gcc-8 points out two comparisons that are clearly bogus > and almost certainly not what the author intended to write: > > drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed': > drivers/usb/gadget/udc/dummy_hcd.c:379:31: error:

Re: [PATCH v5 0/6] usb: xhci: Handle USB transaction error on address command

On 01.09.2017 04:41, Lu Baolu wrote: Hi Mathias, Xhci driver handles USB transaction errors on transfer events, but transaction errors are possible on address device command completion events as well. The xHCI specification (section 4.6.5) says: A USB Transaction Error Completion Code for an

Re: [PATCH V2] usb: host: xhci-plat: allow sysdev to inherit from ACPI

On 9/5/2017 10:16 AM, Greg Kroah-Hartman wrote: > On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote: >> Currently, xhci_plat is not set up properly when the parent device is an >> ACPI node. The conditions that xhci_plat_probe should satisfy are >> >> 1. xhci_plat comes from firmware >>

[PATCH 1/2] USB: musb: fix late external abort on suspend

The musb delayed irq work was never flushed on suspend, something which since 4.9 can lead to an external abort if the work is scheduled after the grandparent's clock has been disabled: PM: Suspending system (mem) PM: suspend of devices complete after 125.224 msecs PM: suspend devices took 0.132

[PATCH 2/2] USB: musb: fix session-bit runtime-PM quirk

The current session-bit quirk implementation does not prevent the retry counter from underflowing, something which could break runtime PM and keep the device active for a very long time (about 2^32 seconds) after a disconnect. This notably breaks the B-device timeout case, but could potentially

[PATCH 0/2] USB: musb: PM fixes

These patches fix a couple of bugs introduced by the recent runtime-PM work. Note that the external abort was due to the irq work never being flushed on suspend, and that we may need similar fixes for the delayed reset and resume work which are likewise never cancelled on suspend. Johan Johan

Re: [PATCH V2] usb: host: xhci-plat: allow sysdev to inherit from ACPI

On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote: > Currently, xhci_plat is not set up properly when the parent device is an > ACPI node. The conditions that xhci_plat_probe should satisfy are > > 1. xhci_plat comes from firmware > 2. xhci_plat is child of a device from firmware

[PATCH V2] usb: host: xhci-plat: allow sysdev to inherit from ACPI

Currently, xhci_plat is not set up properly when the parent device is an ACPI node. The conditions that xhci_plat_probe should satisfy are 1. xhci_plat comes from firmware 2. xhci_plat is child of a device from firmware (dwc3-plat) 3. xhci_plat is grandchild of a pci device (dwc3-pci) Case 2 is

Re: [PATCH] usb: host: xhci-plat: allow sysdev to inherit from ACPI

On 31.08.2017 20:54, Adam Wallis wrote: Currently, xhci_plat is not set up properly when the parent device is an ACPI node. The conditions that xhci_plat_probe should satisfy are 1. xhci_plat comes from firmware 2. xhci_plat is child of a device from firmware (dwc3-plat) 3. xhci_plat is

Re: [PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device

On 24.08.2017 05:53, Thang Q. Nguyen wrote: On Sat, Aug 19, 2017 at 10:43 AM, Thang Q. Nguyen wrote: From: "Thang Q. Nguyen" For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration"), sysdev points to devices known to the system firmware

Re: [PATCH 05/11] mux: Add Intel Cherrytrail USB mux driver

Hi, On 04-09-17 13:19, Peter Rosin wrote: Hi! Some comments inline... On 2017-09-01 23:48, Hans de Goede wrote: Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port USB data lines between the xHCI host controller and the dwc3 gadget controller. On some Cherrytrail systems

Re: [PATCH 02/11] mux: core: Add support for getting a mux controller on a non DT platform

Hi, On 04-09-17 13:19, Peter Rosin wrote: Hi! Some comments inline... On 2017-09-01 23:48, Hans de Goede wrote: On non DT platforms we cannot get the mux_chip by pnode. Other subsystems (regulator, clock, pwm) have the same problem and solve this by allowing platform / board-setup code to

Re: [PATCH 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems

Hi Peter, On 04-09-17 13:18, Peter Rosin wrote: On 2017-09-01 23:48, Hans de Goede wrote: Hi All, This series consists of 4 parts: 1) Core mux changes to add support for getting mux-controllers on non DT platforms and to add some standardised state values for USB 2) Add Intel CHT USB

Re: [PATCH 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

Hi, On 04-09-17 09:31, Heikki Krogerus wrote: Hi, On Fri, Sep 01, 2017 at 11:48:38PM +0200, Hans de Goede wrote: The Intel cherrytrail xhci controller has an extended cap mmio-range which contains registers to control the muxing to the xhci (host mode) or the dwc3 (device mode) and

[PATCH] usb: Increase quirk delay for USB devices

Commit e0429362ab15 ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e") introduced quirk to workaround an issue with some Logitech webcams. The workaround is introducing delay for some USB operations. According to our testing, delay introduced by original commit is not long

[PATCH] usb: gadget: dummy: fix nonsensical comparisons

gcc-8 points out two comparisons that are clearly bogus and almost certainly not what the author intended to write: drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed': drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false

Re: [PATCH 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver

On 2017-09-04 13:19, Peter Rosin wrote: > Hi! > > One comment inline... Oh, and one more small nit, I think you should do s/pi3usb30532_mux/pi3usb30532/g to shorten the identifiers a bit. The _mux suffix (or infix) is kind of selfevident from where the file lives anyway.

Re: ASM1153 detected as ASM1051 and breaking UAS

On Tue, 2017-08-29 at 10:57 +0200, Massimo Burcheri wrote: > Thanks for the patch. I applied that to 4.12.0-pf7: > > # rmmod uas > # patch -p1 < 0001-USB-uas-force-UAS-probing-for-ASMedia-1153.patch > patching file drivers/usb/storage/uas-detect.h > # make > # make modules_install > # modprobe