Re: [PATCH 0/2] Allow xhci-plat using a second clock

On 18.04.2018 17:20, Gregory CLEMENT wrote: Hi Mathias, On mer., févr. 14 2018, Gregory CLEMENT wrote: Hello, The purpose of this series is to allow xhci-plat using a second clock. It is needed on the Armada 7K/8K but could be used by other SoCs. The first patch is just a fix found whi

[RESEND v8 1/2] usb/gadget: Constify usb_gadget_get_string "table" argument

The table is never modified by the function. This allows us to use it on a statically defined table that is marked const. Signed-off-by: Benjamin Herrenschmidt --- drivers/usb/gadget/usbstring.c | 2 +- include/linux/usb/gadget.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff

[RESEND v8 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

The Aspeed BMC SoCs support a "virtual hub" function. It provides some HW support for a top-level USB2 hub behind which sit 5 gadget "ports". This driver adds support for the full functionality, emulating the hub standard requests and exposing 5 UDC gadget drivers corresponding to the ports. The

[PATCH] USB: Increment wakeup count on remote wakeup.

On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a wake

[PATCH 3/3] usb: musb: host: fix potential NULL pointer dereference

musb_start_urb() doesn't check the 3rd pass-in parameter if it is NULL. But in musb_bulk_nak_timeout() the parameter passed to musb_start_urb() is returned from first_qh(), which could be NULL. So wrap the musb_start_urb() call here with a if condition check to avoid the potential NULL pointer der

[PATCH 1/3] usb: musb: gadget: fix to_musb_request() to not return NULL

The gadget function drivers should ensure the usb_request parameter passed in is not NULL. UDC core doesn't check if it is NULL, so MUSB driver shouldn't have to check it either. Convert to_musb_request() to a simple macro to not directly return NULL to avoid warnings from code static analysis too

[PATCH 2/3] usb: musb: gadget: fix to_musb_ep() to not return NULL

UDC core ensures the usb_ep parameter passed in is not NULL, so checking if (ep != NULL) is pointless. Convert to_musb_ep() to a simple macro to not directly return NULL to avoid warnings from code static analysis tools. Signed-off-by: Bin Liu --- drivers/usb/musb/musb_gadget.h | 5 + 1 fil

[PATCH usb v6 4/6] usb: core: phy: make it a no-op if CONFIG_GENERIC_PHY is disabled

If the generic PHY support is disabled the stub of devm_of_phy_get_by_index returns ENOSYS. This corner case isn't handled properly by usb_phy_roothub_add_phy and at least breaks USB support on Raspberry Pi (bcm2835_defconfig): dwc2 2098.usb: dwc2_hcd_init() FAILED, returning -38 dwc2:

[PATCH usb v6 3/6] usb: core: use phy_exit during suspend if wake up is not supported

If the USB controller can wake up the system (which is the case for example with the Mediatek USB3 IP) then we must not call phy_exit during suspend to ensure that the USB controller doesn't have to re-enumerate the devices during resume. However, if the USB controller cannot wake up the system (wh

[PATCH usb v6 0/6] usb/core/phy fixes for v4.17

This is a follow-up to my previous series "initialize (multiple) PHYs for a HCD": [0]. Roger Quadros reported [1] that it "is breaking low power cases on TI SoCs when USB is in host mode". He further explains that "Not doing the phy_exit() here [when entering suspend] leaves the clocks enabled on

[PATCH usb v6 6/6] usb: core: phy: add the SPDX-License-Identifier and include guard

This clarifies the license of the code. While here also add an include guard to the header file. Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD") Suggested-by: Masahiro Yamada Signed-off-by: Martin Blumenstingl --- drivers/usb/core/phy.h | 12 1 file c

[PATCH usb v6 5/6] usb: core: phy: add missing forward declaration for "struct device"

Currently hcd.c is the only consumer of the usb_phy_roothub logic. This already includes the required header files so struct device is known. However, future consumers might not know about struct device. Add a forward declaration for struct device to fix potential future consumers which don't inclu

[PATCH usb v6 2/6] usb: core: split usb_phy_roothub_{init,alloc}

Before this patch usb_phy_roothub_init served two purposes (from a caller's point of view - like hcd.c): - parsing the PHYs and allocating the list entries - calling phy_init on each list entry While this worked so far it has one disadvantage: if we need to call phy_init for each PHY instance then

[PATCH usb v6 1/6] usb: core: phy: fix return value of usb_phy_roothub_exit()

usb_phy_roothub_exit() should return the error code from the phy_exit() call if exiting the PHY failed. However, since a wrong variable is used usb_phy_roothub_exit() currently always returns 0, even if one of the phy_exit calls returned an error. Clang also reports this bug: kernel/drivers/usb/cor

Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

Hi Johan, On Fri, Apr 13, 2018 at 5:15 PM, Johan Hovold wrote: > I've been carrying a patch out-of-tree since my work on improving the > USB device-tree support which is needed to be able to describe USB > topologies for musb based controllers. > > This patch, which associates the platform contro

Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

On Wed, Apr 18, 2018 at 08:46:40PM +0200, Johan Hovold wrote: > On Wed, Apr 18, 2018 at 11:20:15AM -0500, Bin Liu wrote: > > Johan, > > > > On Fri, Apr 13, 2018 at 05:15:02PM +0200, Johan Hovold wrote: > > > I've been carrying a patch out-of-tree since my work on improving the > > > USB device-tre

Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

On Wed, Apr 18, 2018 at 11:20:15AM -0500, Bin Liu wrote: > Johan, > > On Fri, Apr 13, 2018 at 05:15:02PM +0200, Johan Hovold wrote: > > I've been carrying a patch out-of-tree since my work on improving the > > USB device-tree support which is needed to be able to describe USB > > topologies for mu

NULL pointer dereference in xhci_suspend

Hi everyone, I'm running a VM using libvirt on kernel 4.15 (Ubuntu 18.04). ASMedia USB 3.1 Gen 2 controller is assigned to VM like this:                     Occasionally VM start fails with following error and I'm unable to start a VM anymore until reboot: [40061.976

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

On Thu, Apr 05, 2018 at 09:11:02PM +0200, Greg KH wrote: >On Thu, Apr 05, 2018 at 04:42:46PM +, Sasha Levin wrote: >> Hi. >> >> [This is an automated email] > >Why are you running this against patches that are not yet in Linus's >tree? That feels odd. Only about 1/3 of the patches posted end

Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

Johan, On Fri, Apr 13, 2018 at 05:15:02PM +0200, Johan Hovold wrote: > I've been carrying a patch out-of-tree since my work on improving the > USB device-tree support which is needed to be able to describe USB > topologies for musb based controllers. > > This patch, which associates the platform

Re: [PATCH v2 2/3] lan78xx: Read LED states from Device Tree

On Wed, Apr 18, 2018 at 04:45:22PM +0100, Phil Elwell wrote: > Add support for DT property "microchip,led-modes", a vector of zero > to four cells (u32s) in the range 0-15, each of which sets the mode > for one of the LEDs. Some possible values are: > > 0=link/activity 1=link1000/acti

[PATCH v2 2/3] lan78xx: Read LED states from Device Tree

Add support for DT property "microchip,led-modes", a vector of zero to four cells (u32s) in the range 0-15, each of which sets the mode for one of the LEDs. Some possible values are: 0=link/activity 1=link1000/activity 2=link100/activity 3=link10/activity 4=link100/1000/

[PATCH v2 3/3] dt-bindings: Document the DT bindings for lan78xx

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. Document the supported properties in

[PATCH v2 1/3] lan78xx: Read MAC address from DT if present

There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell --- dr

[PATCH v2 0/3] lan78xx: Read configuration from Device Tree

The Microchip LAN78XX family of devices are Ethernet controllers with a USB interface. Despite being discoverable devices it can be useful to be able to configure them from Device Tree, particularly in low-cost applications without an EEPROM or programmed OTP. This patch set adds support for readi

Re: Bluetooth controller falling off USB bus after an hour of continuous BT headset usage

On Thursday, 15 March 2018 at 16:53, Dominik 'Rathann' Mierzejewski wrote: [...] > Could you give me any pointers for debugging this? I cannot trigger > this on-demand, but when I'm in a conference call, it occurs within > an hour or two of continuous usage of my BT headset in HFP mode. > > I orig

Re: [PATCH] net: qmi_wwan: add Wistron Neweb D19Q1

Pawel Dembicki writes: > This modem is embedded on dlink dwr-960 router. > The oem configuration states: > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 > D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=1435 ProdID=d191 Rev=ff.ff > S: Manufacturer=Androi

Re: [PATCH 09/11] usb: musb: break the huge isr musb_stage0_irq() into small functions

On Wed, Apr 18, 2018 at 05:14:05PM +0300, Dan Carpenter wrote: > On Wed, Apr 18, 2018 at 08:33:52AM -0500, Bin Liu wrote: > > Hi Dan, > > > > I appreciate you scaning the patches and reporting the issues. The report is valuable! > > > > These are kbuild stuff so I basically just forward them.

Re: [PATCH 0/2] Allow xhci-plat using a second clock

Hi Mathias, On mer., févr. 14 2018, Gregory CLEMENT wrote: > Hello, > > The purpose of this series is to allow xhci-plat using a second > clock. It is needed on the Armada 7K/8K but could be used by other > SoCs. > > The first patch is just a fix found while I was working on this > feature. I

Re: sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

On Wed, 18 Apr 2018, Cristian wrote: > Hello, > > Open bug in launchpad.net > https://bugs.launchpad.net/bugs/1765043 > > > dmesg: > [ 4228.290628] sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE > [ 4228.290638] sr 6:0:0:0: [sr0] tag#0 Sense Key : Illegal Reque

Re: [PATCH 09/11] usb: musb: break the huge isr musb_stage0_irq() into small functions

On Wed, Apr 18, 2018 at 08:33:52AM -0500, Bin Liu wrote: > Hi Dan, > > I appreciate you scaning the patches and reporting the issues. > These are kbuild stuff so I basically just forward them. It's no effort. > On Wed, Apr 18, 2018 at 10:25:34AM +0300, Dan Carpenter wrote: > > Hi Bin, > > >

Re: [RFT/PATCH 00/38] usb: dwc3: gadget: Rework & Refactoring

On Wed, Apr 18, 2018 at 08:20:28AM +0300, Felipe Balbi wrote: > > Hi Bin, > > Bin Liu writes: > > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote: > >> Hi guys, > >> > >> I've been working on this series for a while now. I feels like after > >> this series the transfer management c

[PATCH] net: qmi_wwan: add Wistron Neweb D19Q1

This modem is embedded on dlink dwr-960 router. The oem configuration states: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1435 ProdID=d191 Rev=ff.ff S: Manufacturer=Android S: Product=Android S: SerialNumber=0

sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Hello, Open bug in launchpad.net https://bugs.launchpad.net/bugs/1765043 dmesg: [ 4228.290628] sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 4228.290638] sr 6:0:0:0: [sr0] tag#0 Sense Key : Illegal Request [current] [ 4228.290645] sr 6:0:0:0: [sr0] tag#0 Add. S

Re: [PATCH 09/11] usb: musb: break the huge isr musb_stage0_irq() into small functions

Hi Dan, I appreciate you scaning the patches and reporting the issues. On Wed, Apr 18, 2018 at 10:25:34AM +0300, Dan Carpenter wrote: > Hi Bin, > > I love your patch! Perhaps something to improve: > > [auto build test WARNING on balbi-usb/next] > [also build test WARNING on v4.17-rc1 next-2018

[PATCH 1/2] usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

If the I2C adapter that the PD controller is attached to does not support SMBus protocol, the driver needs to handle block reads separately. The first byte returned in block read protocol will show the total number of bytes. It needs to be stripped away. This is handled separately in the driver on

[PATCH 0/2] usb: typec: fixes

Hi, I got two separate fixes here. First one will fix an issue with ucsi where the driver may timeout if EC is under heavy load, and the second an issue with tps6598x when used with plain I2C adapters. Thanks, Heikki Krogerus (2): usb: typec: tps6598x: handle block reads separately with plai

[PATCH 2/2] usb: typec: ucsi: Increase command completion timeout value

On some boards, under heavy load, the EC firmware is unable to complete commands even in one second. Increasing the command completion timeout value to five seconds. Reported-by: Quanxian Wang Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: Signed-off-by: Heikki Krogerus

Re: [PATCH RFC] usb: typec: tcpm: remove operating_snk_mw for rdo

Hi, On 17-04-18 08:01, Li Jun wrote: This patch is a further update for rdo based on [1], which removed max_snk_ma/mv/mw but kept operating_snk_mw. operating_snk_mw is only used to judge capability mismatch, per PD spec, we can achieve this via compare the selected source PDO and matching sink P

[PATCH v2 4/6] USB: musb: omap2430: drop non-DT support

Drop support for non-DT systems, which hasn't been used by a mainline kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Specifically, since that commit usb_get_phy_dev() have always returned -ENODEV when looking up a legacy phy, something which in turn w

[PATCH v2 0/6] USB: legacy-phy spring cleaning

When investigating an issue related to the recent addition of generic-phy support to USB core, I happened to take a closer look at the legacy-phy support in usb_add_hcd() as well. Turns out this code hasn't been used since 2016 when OMAP dropped support for non-DT boot. Specifically, the interface

[PATCH v2 2/6] USB: core: hcd: drop support for legacy phys

Drop support for looking up and initialising legacy phys in USB core, something which hasn't been used by a mainline kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Specifically, since that commit usb_get_phy_dev() have always returned -ENODEV and cons

[PATCH v2 3/6] USB: ehci-omap: drop unused legacy phy support

Drop support for looking up legacy phys defined by board files, something which hasn't been used by a mainline kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Specifically, since that commit usb_get_phy_dev() have always returned -ENODEV and consequent

[PATCH v2 5/6] USB: renesas_usbhs: drop unused legacy-phy support

Drop support for legacy phys for rcar2 which hasn't been used with a mainline kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Specifically, since that commit usb_get_phy_dev() have always returned -ENODEV and consequently this code has not been used.

[PATCH v2 1/6] USB: phy: drop unused legacy controller-phy bind helper

Drop the unused legacy usb_bind_phy() helper whose last user was removed in 2016 when OMAP moved to device-tree boot (9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c platform init code")). Note that this means that for the last couple of years the phy_bind_list has been empty (when using main

[PATCH v2 6/6] USB: phy: drop legacy board-file support

The legacy interface for associating controllers with phys from board files and platform code has been unused since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c platform init code"). Since then, all calls to usb_get_phy_dev() and its devres version have been returning -ENODEV. Now t

Re: [PATCH 5/6] USB: renesas_usbhs: drop support for legacy phys

On Wed, Apr 18, 2018 at 08:50:10AM +, Yoshihiro Shimoda wrote: > Hi, > > > From: Johan Hovold, Sent: Wednesday, April 18, 2018 5:42 PM > > How about > > > > USB: renesas_usbhs: drop unused legacy-phy support > > > > and then I amend the commit message with a note about the legacy API >

RE: [PATCH 5/6] USB: renesas_usbhs: drop support for legacy phys

Hi, > From: Johan Hovold, Sent: Wednesday, April 18, 2018 5:42 PM > > On Wed, Apr 18, 2018 at 04:22:31AM +, Yoshihiro Shimoda wrote: > > Hi, > > > > > From: Johan Hovold, Sent: Saturday, April 14, 2018 10:06 PM > > > > > > Drop support for legacy phys which hasn't been used with a mainline >

Re: [PATCH/RFC 08/11] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

Hi Shimoda-san, On Wed, Apr 18, 2018 at 10:10 AM, Yoshihiro Shimoda wrote: > This patch adds role switch support for R-Car SoCs. Some R-Car SoCs > (e.g. R-Car H3) have USB 3.0 dual-role device controller which has > the USB 3.0 xHCI host and Renesas USB 3.0 peripheral. > > Unfortunately, the mode

Re: [PATCH 5/6] USB: renesas_usbhs: drop support for legacy phys

On Wed, Apr 18, 2018 at 04:22:31AM +, Yoshihiro Shimoda wrote: > Hi, > > > From: Johan Hovold, Sent: Saturday, April 14, 2018 10:06 PM > > > > Drop support for legacy phys which hasn't been used with a mainline > > kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c > > p

[PATCH/RFC 03/11] dt-bindings: usb: add Renesas R-Car USB 3.0 role switch driver

This patch adds a new documentation for Renesas R-Car USB 3.0 role switch driver. Signed-off-by: Yoshihiro Shimoda --- .../bindings/usb/renesas,rcar-usb3-role-sw.txt | 56 ++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/renes

[PATCH/RFC 02/11] dt-bindings: usb: add usb role switch driver

This patch adds a new documentation for a usb role switch driver. The usb role switch framework will parse this to get each device pointer by using each remote-endpoint. Signed-off-by: Yoshihiro Shimoda --- .../devicetree/bindings/usb/usb-role-switch.txt| 42 ++ 1 file ch

[PATCH/RFC 11/11] arm64: dts: renesas: r8a7795: salvator-xs: add OF graph for usb role switch

This patch adds OF graph properties for usb role switch. TODO: - Each node should be in salvator-common.dtsi. Signed-off-by: Yoshihiro Shimoda --- .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 28 ++ 1 file changed, 28 insertions(+) diff --git a/arch/arm64/boot/dts/

[PATCH/RFC 08/11] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

This patch adds role switch support for R-Car SoCs. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0 dual-role device controller which has the USB 3.0 xHCI host and Renesas USB 3.0 peripheral. Unfortunately, the mode change register contains the USB 3.0 peripheral controller side only. So, the USB 3.0

[PATCH/RFC 05/11] usb: common: roles: add fwnode graph parsing

This patch adds fwnode graph parsing to set usb[23]_port and udc into the usb_role_switch structure by usb_role_switch_register(). Signed-off-by: Yoshihiro Shimoda --- drivers/usb/common/roles.c | 40 +++- 1 file changed, 39 insertions(+), 1 deletion(-) diff

[PATCH/RFC 00/11] add support for R-Car USB3.0 role switch

This patch set is based on v4.17-rc1. In last week, I submitted a patch as v1 [1]. But, the v1 patch doesn't use graphs to get usb host device pointer. So, I modified some frameworks for it. Since the patch 4 "of: platform: add device connection parsing" has TODOs, I marked this patch set as "RFC"

[PATCH/RFC 09/11] usb: gadget: udc: renesas_usb3: add support for a usb role switch

This patch adds support for a usb role switch driver. And then, this driver uses the usb role switch APIs instead of hardware access to initialize usb host side at specific timings. Signed-off-by: Yoshihiro Shimoda --- drivers/usb/gadget/udc/Kconfig| 1 + drivers/usb/gadget/udc/renesas_

[PATCH/RFC 07/11] usb: common: roles: add getting device pointer APIs

This patch adds APIs that a role switch driver can get device pointer of USB 2.0/3.0 and udc. Signed-off-by: Yoshihiro Shimoda --- drivers/usb/common/roles.c | 36 include/linux/usb/role.h | 4 2 files changed, 40 insertions(+) diff --git a/drivers/u

[PATCH/RFC 04/11] of: platform: add device connection parsing

This patch adds device connection parsing in of_platform_populate(). TODO: - How to free the devcon memories? - How to remove the devcon instances? Signed-off-by: Yoshihiro Shimoda --- drivers/of/platform.c | 66 +++ include/linux/of.h| 1 +

[PATCH/RFC 01/11] Documentation: of: Add device-connection-id property

This patch adds a new property for device connection framework. Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/graph.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/gr

[PATCH/RFC 10/11] arm64: dts: renesas: r8a7795: add OF graph for usb role switch

This patch adds OF graph properties for usb role switch in r8a7795. Signed-off-by: Yoshihiro Shimoda --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 44 1 file changed, 44 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/

[PATCH/RFC 06/11] usb: common: roles: Allow if the parent dev_name matches

THis patch adds a condition in __switch_match() to allow if the parent dev_name matches. Otherwise, OF environment cannot match the usb role switch devices because the usb role switch framework adds the names of a new child device as the parent dev_name with "-role-switch". Signed-off-by: Yoshihir

Re: [PATCH 09/11] usb: musb: break the huge isr musb_stage0_irq() into small functions

Hi Bin, I love your patch! Perhaps something to improve: [auto build test WARNING on balbi-usb/next] [also build test WARNING on v4.17-rc1 next-20180417] [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/

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

On 2018-04-17 12:03, Tushar Nimkar wrote: On 2018-04-16 20:03, Oliver Neukum wrote: Am Montag, den 16.04.2018, 10:23 -0400 schrieb Alan Stern: > > > > [57246.701096] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 > > > > inflight: CMD IN > > > > [57246.701130] sd 1:0:0:0: tag#0 CDB: opcode=

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

On 2018-04-17 18:04, Mathias Nyman wrote: On 17.04.2018 09:23, Tushar Nimkar wrote: On 2018-04-16 18:46, Mathias Nyman wrote: On 16.04.2018 13:20, Tushar Nimkar wrote: On 2018-04-05 11:31, Felipe Balbi wrote: Hi, it would help if you would Cc XHCI's maintainer :-) tnim...@codeaurora.org wri

Re: refine xhci-plat-Fix-xhci_plat-shutdown-sequence

On Wed, Apr 18, 2018 at 01:41:45PM +0800, lei...@codeaurora.org wrote: > On 2018-04-17 18:32, Greg KH wrote: > > On Tue, Apr 17, 2018 at 11:32:42AM +0800, lei...@codeaurora.org wrote: > > > > > > xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE > > > before accessing any register. T