Re: [PATCH 2/4] usb: host: ohci-platform: Add support for omap3 and later

On 18/05/17 01:59, Tony Lindgren wrote: > With the runtime PM implemented for ohci-platform driver, we can > now support omap3 and later OHCI by adding one device tree > property. > > Cc: Hans de Goede > Cc: Rob Herring > Cc: Roger Quadros >

[PATCH resend v3 0/4] usb: usbip: Fix ports and port status

From: Yuyang Du The commit 0775a9cbc694e8c7 ("usbip: vhci extension: modifications to vhci driver") introduced several bugs relating to the number of ports amd the port status. In addition, a small improvement is made to the vhci_hcd module. resend: - Remove already picked

[PATCH resend v3 1/4] usb: usbip tool: Check the return of get_nports()

From: Yuyang Du If we get nonpositive number of ports, there is no sense to continue, then fail gracefully. In addition, the commit 0775a9cbc694e8c72 ("usbip: vhci extension: modifications to vhci driver") introduced configurable numbers of controllers and ports, but we

[PATCH resend v3 4/4] usb: usbip tool: Fix parse_status()

From: Yuyang Du In parse_status(), all nports number of idev's are initiated to 0 by memset(), it is simply wrong, because parse_status() reads the status sys file one by one, therefore, it can only update the according vhci_driver->idev's for it to parse. Reviewed-by:

[PATCH] usb: xhci: add quirk flag for broken stop command on AMD platforms

on AMD platforms with SNPS 3.1 USB controller has an issue if the stop EP command is issued when the controller is not in running state. If issued, it is leading to a critical RTL bug because of which controller goes into irrecoverable state. This patch adds a appropriate checks to make sure that

Re: [PATCH] usb: xhci: add quirk flag for broken stop command on AMD platforms

Hi, On 18/05/17 11:53, Shyam Sundar S K wrote: > on AMD platforms with SNPS 3.1 USB controller has an issue > if the stop EP command is issued when the controller is not > in running state. If issued, it is leading to a critical RTL bug > because of which controller goes into irrecoverable state.

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

Am Mittwoch, den 17.05.2017, 02:36 -0700 schrieb Guenter Roeck: > On 05/17/2017 12:34 AM, Oliver Neukum wrote: > > > > Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan > > Sridharan: > > > > Hi, > > > > > > > > "Two independent set of mechanisms are defined to allow a USB Type-C >

Re: [PATCH 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

Hi, On Wed, May 17, 2017 at 03:59:21PM -0700, Tony Lindgren wrote: > We can't just remove ohci-omap3 as that could make some people's > systems unusable for keyboard and mouse. Let's print a warning for > now, and then remove the driver in a year or so. > > Cc: Hans de Goede

Re: [PATCH 1/4] usb: host: ohci-platform: Add basic runtime PM support

On 18/05/17 01:59, Tony Lindgren wrote: > This is needed in preparation of adding support for omap3 and > later OHCI. The runtime PM will only do something on platforms > that implement it. > > Cc: devicet...@vger.kernel.org > Cc: Hans de Goede > Cc: Rob Herring

Re: [PATCH 4/4] ARM: dts: Add remote-wakeup-connected for omap OHCI

On 18/05/17 01:59, Tony Lindgren wrote: > Add remote-wakeup-connected for omap OHCI as that's needed by > ehci-platform driver. > > Cc: devicet...@vger.kernel.org > Cc: Hans de Goede > Cc: Rob Herring > Cc: Roger Quadros > Cc: Yoshihiro

[PATCH resend v3 2/4] usb: usbip tool: Add ncontrollers in vhci_driver structure

From: Yuyang Du A new field ncontrollers is added to the vhci_driver structure. And this field is stored by scanning the vhci_hcd* dirs in the platform udev. Suggested-and-reviewed-by: Krzysztof Opasiak Signed-off-by: Yuyang Du

[PATCH resend v3 3/4] usb: usbip tool: Fix refresh_imported_device_list()

From: Yuyang Du The commit 0775a9cbc694e8c7 ("usbip: vhci extension: modifications to vhci driver") introduced multiple controllers, but the status of the ports are only extracted from the first status file, fix it. Reviewed-by: Krzysztof Opasiak

Re: Microchip USB Hub Driver Harmonization

On Thu, May 18, 2017 at 7:33 AM, Richard Leitner wrote: >>> 2. What would be a good prefix for common headers/functions/macros/etc.? >>> I thought of "mcusbhub"... Would that be OK? Or are there any >>> conventions/better proposals on that? >> >> >> If you are going to develop

Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

Am Mittwoch, den 17.05.2017, 14:18 -0400 schrieb David Miller: > From: Bjørn Mork > Date: Tue, 16 May 2017 20:24:10 +0200 > > > Jim Baxter writes: > > > >> The CDC-NCM driver can require large amounts of memory to create > >> skb's and this can be a

[PATCH v2 8/9] usbip: vhci-hcd: Add USB3 port status bits

From: Yuyang Du As USB3 has (slightly) different bit meanings in the port status. Add a new status bit array for USB3. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci_hcd.c | 56 +++- 1 file changed, 50

[PATCH v2 6/9] usbip: vhci-hcd: Add USB3 SuperSpeed support

From: Yuyang Du This patch adds a USB3 HCD to an existing USB2 HCD and provides the support of SuperSpeed, in case the device can only be enumerated with SuperSpeed. The bulk of the added code in usb3_bos_desc and hub_control to support SuperSpeed is borrowed from the

[PATCH v2 5/9] usbip: vhci-hcd: Set the vhci structure up to work

From: Yuyang Du This patch enables the new vhci structure. Its lock protects both the USB2 hub and the shared USB3 hub. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci.h | 2 - drivers/usb/usbip/vhci_hcd.c | 206

[PATCH v2 2/9] usbip: vhci-hcd: Add vhci struct

From: Yuyang Du In order to support SuperSpeed devices, a USB3 HCD is added to share the USB2 HCD. As a result, a VHCI is composed of two vhci_hcds associated with the two HCDs respectively. So we add another level of abstraction, vhci, and thus this vhci structure.

[PATCH v2 9/9] usbip: vhci-hcd: Clean up the code by adding a new macro

From: Yuyang Du Each vhci has 2*VHCI_HC_PORTS ports, in which VHCI_HC_PORTS ports are HighSpeed (or below), and VHCI_HC_PORTS are SuperSpeed. This new macro VHCI_PORTS reflects this configuration. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci.h

[PATCH v2 1/9] usbip: vhci-hcd: Rename function names to reflect their struct names

From: Yuyang Du These helper function names are renamed to have their full struct names to avoid confusion: - hcd_to_vhci() -> hcd_to_vhci_hcd() - vhci_to_hcd() -> vhci_hcd_to_hcd() - vdev_to_vhci() -> vdev_to_vhci_hcd() Signed-off-by: Yuyang Du

[PATCH v2 3/9] usbip: vhci-hcd: Move VHCI platform device into vhci struct

From: Yuyang Du Every VHCI is a platform device, so move the platform_device struct into the VHCI struct. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci.h | 3 ++- drivers/usb/usbip/vhci_hcd.c | 17 -

[PATCH v2 4/9] usbip: vhci-hcd: Rework vhci_hcd_init

From: Yuyang Du A vhci struct is added as the platform-specific data to the vhci platform device, in order to get the vhci by its platform device. This is done in vhci_hcd_init(). Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci_hcd.c | 51

[PATCH v2 0/9] usbip: Enable USB3 SuperSpeed

Hi Shuah, SuperSpeed (only) USB devices cannot be shared via usbip. This patch series attempts to fix it. The first 5 patches refactors the existing code to prepare for the SuperSpeed addition. With this series, our SuperSpeed device works fine. Many thanks to Greg and Krzysztof for their

[PATCH v2 7/9] usbip: Add USB_SPEED_SUPER as valid arg

From: Yuyang Du With this patch, USB_SPEED_SUPER is a valid speed when attaching a USB3 SuperSpeed device. Signed-off-by: Yuyang Du --- drivers/usb/usbip/vhci_sysfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/usbip/vhci_sysfs.c

Re: [PATCH] usb: xhci: add quirk flag for broken stop command on AMD platforms

On Thu, 18 May 2017, Shyam Sundar S K wrote: > on AMD platforms with SNPS 3.1 USB controller has an issue > if the stop EP command is issued when the controller is not > in running state. If issued, it is leading to a critical RTL bug > because of which controller goes into irrecoverable state. >

uas failing on multiple disk access on a jmicron JMS567 bridge

Hi, I have seen several reports around the internet regarding failing io on USB-SATA bridges. However, these reports seem to be partially old and/or fixes proposed are implemented in my kernel but don’t fix things. Therefore I thought I report here again. If this is know/duplicate please

[PATCH] r8152: Remove unused function usb_ocp_read()

The function is not used, removing it fixes the following warning when building with clang: drivers/net/usb/r8152.c:825:5: error: unused function 'usb_ocp_read' [-Werror,-Wunused-function] Signed-off-by: Matthias Kaehlcke --- drivers/net/usb/r8152.c | 6 -- 1 file

Re: [PATCH 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

On Wed, 17 May 2017, Tony Lindgren wrote: > We can't just remove ohci-omap3 as that could make some people's > systems unusable for keyboard and mouse. Let's print a warning for > now, and then remove the driver in a year or so. > > Cc: Hans de Goede > Cc: Rob Herring

dwc2: g-tx-fifo-size configuration on bcm2835

Hi, since the dwc2 should be able to properly setup its fifos, i want to enable otg mode for Raspberry Pi Zero (BCM2835). According to the BCM2835 datasheet [1] it has 7 device EPs with a max FIFO depth for EP1..5 = 512 and EP6,7 = 768. This makes in sum 4096, which also seems to be okay

Re: [PATCH 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

Hi, On Thu, May 18, 2017 at 07:08:58AM -0700, Tony Lindgren wrote: > * Sebastian Reichel [170518 02:18]: > > On Wed, May 17, 2017 at 03:59:21PM -0700, Tony Lindgren wrote: > > > We can't just remove ohci-omap3 as that could make some people's > > > systems unusable for keyboard

Re: [PATCH 1/4] usb: host: ohci-platform: Add basic runtime PM support

On Wed, 17 May 2017, Tony Lindgren wrote: > This is needed in preparation of adding support for omap3 and > later OHCI. The runtime PM will only do something on platforms > that implement it. > @@ -51,6 +52,10 @@ static int ohci_platform_power_on(struct platform_device > *dev) > struct

Re: [PATCH 2/4] usb: host: ohci-platform: Add support for omap3 and later

* Alan Stern [170518 08:41]: > On Wed, 17 May 2017, Tony Lindgren wrote: > > > With the runtime PM implemented for ohci-platform driver, we can > > now support omap3 and later OHCI by adding one device tree > > property. ... > > diff --git

Re: [PATCH 4/4] ARM: dts: Add remote-wakeup-connected for omap OHCI

On Wed, 17 May 2017, Tony Lindgren wrote: > Add remote-wakeup-connected for omap OHCI as that's needed by > ehci-platform driver. This should be "ohci", not "ehci". Otherwise, Acked-by: Alan Stern > Cc: devicet...@vger.kernel.org > Cc: Hans de Goede

[PATCH] net1080: Remove unused function nc_dump_ttl()

The function is not used, removing it fixes the following warning when building with clang: drivers/net/usb/net1080.c:271:20: error: unused function 'nc_dump_ttl' [-Werror,-Wunused-function] Also remove the definition of TTL_THIS, which is only used in nc_dump_ttl() Signed-off-by: Matthias

Re: [PATCH 1/4] usb: host: ohci-platform: Add basic runtime PM support

* Alan Stern [170518 08:28]: > On Wed, 17 May 2017, Tony Lindgren wrote: > > > This is needed in preparation of adding support for omap3 and > > later OHCI. The runtime PM will only do something on platforms > > that implement it. > > This patch isn't correct. See

Re: [PATCH] net1080: Mark nc_dump_ttl() as __maybe_unused

Hi David, El Thu, May 18, 2017 at 10:48:08AM -0400 David Miller ha dit: > From: Matthias Kaehlcke > Date: Wed, 17 May 2017 15:17:08 -0700 > > > The function is not used, but it looks useful for debugging. Adding the > > attribute fixes the following clang warning: > > > >

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

On Thu, May 18, 2017 at 11:13:51AM +0200, Oliver Neukum wrote: > Am Mittwoch, den 17.05.2017, 02:36 -0700 schrieb Guenter Roeck: > > On 05/17/2017 12:34 AM, Oliver Neukum wrote: > > > > > > Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan > > > Sridharan: > > > > > > Hi, > > > > >

Re: [PATCH 1/4] usb: host: ohci-platform: Add basic runtime PM support

On Wed, 17 May 2017, Tony Lindgren wrote: > This is needed in preparation of adding support for omap3 and > later OHCI. The runtime PM will only do something on platforms > that implement it. This patch isn't correct. See below. > Cc: devicet...@vger.kernel.org > Cc: Hans de Goede

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

On Thu, May 18, 2017 at 04:30:02PM +0200, Christoph Gohle wrote: > Hi, > > I have seen several reports around the internet regarding failing io > on USB-SATA bridges. However, these reports seem to be partially old > and/or fixes proposed are implemented in my kernel but don’t fix > things.

RE: [PATCH v2 6/9] usb: dwc3: debug: remove static char buffer from dwc3_decode_event()

From: Felipe Balbi > Sent: 17 May 2017 14:06 > Instead, we can require caller to pass a buffer for the function to > use. This cleans things quite a bit. This is 2017 not 1982, you just can't pass an unsized char[] through to code that is (presumably) going to do an sprint() into it. You could

Re: [PATCH resend v3 1/4] usb: usbip tool: Check the return of get_nports()

Hello! On 05/18/2017 12:50 PM, Yuyang Du wrote: From: Yuyang Du If we get nonpositive number of ports, there is no sense to Negative? continue, then fail gracefully. In addition, the commit 0775a9cbc694e8c72 ("usbip: vhci extension: modifications to vhci driver")

[PATCH v4 6/9] usb: musb: tusb6010_omap: Allocate DMA channels upfront

Instead of requesting the DMA channel in tusb_omap_dma_allocate() do it when the controller is created and in runtime work from the DMA channel pool. This change is needed for the DMAengine conversion of the driver since the tusb_omap_dma_allocate() is called in interrupt context which might lead

[PATCH v4 5/9] usb: musb: tusb6010_omap: Create new struct for DMA data/parameters

For the DMA we have ch (channel), dmareq and sync_dev parameters both within the tusb_omap_dma_ch and tusb_omap_dma struct. By creating a common struct the code can be simplified when selecting between the shared or multichannel DMA parameters. Signed-off-by: Peter Ujfalusi

[PATCH v4 8/9] ARM: OMAP2+: DMA: Add slave map entries for 24xx external request lines

The external request lines are used by tusb6010 on OMAP24xx platforms. Update the map so the driver can use dmaengine API to request the DMA channel. At the same time add temporary map containing only the external DMA request numbers for DT booted case on omap24xx since the tusb6010 stack is not

Re: resolving issue by: USB_AUTOSUSPEND=0

On Thu, May 18, 2017 at 03:14:56PM +0200, Daniel Duris wrote: > Issue can be resolved by setting: > > USB_AUTOSUSPEND=0 What issue? > See details here: > > https://bugzilla.kernel.org/show_bug.cgi?id=117811 I don't understand, is a patch needed? > (also, isn't refusing HTML emails kind of

Re: [PATCH 2/4] usb: host: ohci-platform: Add support for omap3 and later

On Wed, 17 May 2017, Tony Lindgren wrote: > With the runtime PM implemented for ohci-platform driver, we can > now support omap3 and later OHCI by adding one device tree > property. > > Cc: Hans de Goede > Cc: Rob Herring > Cc: Roger Quadros

Re: [PATCH] net1080: Mark nc_dump_ttl() as __maybe_unused

From: Matthias Kaehlcke Date: Wed, 17 May 2017 15:17:08 -0700 > The function is not used, but it looks useful for debugging. Adding the > attribute fixes the following clang warning: > > drivers/net/usb/net1080.c:271:20: error: unused function > 'nc_dump_ttl'

Re: [PATCH 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

* Sebastian Reichel [170518 02:18]: > On Wed, May 17, 2017 at 03:59:21PM -0700, Tony Lindgren wrote: > > We can't just remove ohci-omap3 as that could make some people's > > systems unusable for keyboard and mouse. Let's print a warning for > > now, and then remove the driver in

[PATCH v4 1/9] dmaengine: omap-dma: port_window support correction for both direction

When the port_window support was verified it was done on setup where only the MEM_TO_DEV direction was enabled. This got un-noticed and thus only this direction worked. Now that I have managed to get a setup to verify both direction it turned out that the setup was incorrect: omap_desc members

[PATCH v4 9/9] usb: musb: tusb6010_omap: Convert to DMAengine API

With the port_window support in DMAengine and the sDMA driver we can convert the driver to DMAengine. Signed-off-by: Peter Ujfalusi Tested-by: Tony Lindgren --- drivers/usb/musb/tusb6010_omap.c | 201 --- 1 file

[PATCH v4 7/9] usb: musb: tusb6010: Handle DMA TX completion in DMA callback as well

Handle the DMA TX in a similar way as we do for the RX: in the DMA completion callback. Since we are no longer using DMA completion interrupt for the TX we can as wall keep these interrupts disabled, but keep the handler for debug purposes. Signed-off-by: Peter Ujfalusi

[PATCH v4 0/9] usb: musb: tusb6010_omap: Convert to DMAengine

Hi, Changes since v3: - typos in commit message of patch 3 and 5 fixed - long line fixed in patch 5 - Ack from Vinod is added to the first patch - The series depends on: http://marc.info/?l=linux-omap=149459699415599=2 Changes since v2: - patch 5 from the v1 has been sent separately (usb: musb:

Re: [PATCH 0/2] musb fixes for v4.12-rc2

On Wed, May 17, 2017 at 11:23:09AM -0500, Bin Liu wrote: > Hi Greg, > > Here are the couple musb fixes for v4.12-rc2. One fixes an regression caused > in > the runtime PM refactoring in musb since v4.9, and the other fixes a register > cross-talk between rx and tx in tusb6010 since the beginning

Re: [PATCH 0/2] musb fixes for v4.12-rc2

On Thu, May 18, 2017 at 03:21:06PM +0200, Greg KH wrote: > On Wed, May 17, 2017 at 11:23:09AM -0500, Bin Liu wrote: > > Hi Greg, > > > > Here are the couple musb fixes for v4.12-rc2. One fixes an regression > > caused in > > the runtime PM refactoring in musb since v4.9, and the other fixes a >

Re: resolving issue by: USB_AUTOSUSPEND=0

This issue that I have reported earlier - makes use of any external adapaters pain the ass as it often ends with USB "hanging" and it need sto be disconnected/reconnected to make it work again: repeating every few minutes and this causes network restarts (if ping is running in the background,

Re: [PATCH net,stable] qmi_wwan: add another Lenovo EM74xx device ID

From: Bjørn Mork Date: Wed, 17 May 2017 16:31:41 +0200 > In their infinite wisdom, and never ending quest for end user frustration, > Lenovo has decided to use a new USB device ID for the wwan modules in > their 2017 laptops. The actual hardware is still the Sierra Wireless >

[PATCH v4 2/9] usb: musb: Add quirk to avoid skb reserve in gadget mode

For tusb6010 the DMA functionality only possible if the buffer is 32bit aligned (SYNC access to FIFO) since with ASYNC access the TX/RX offset registers will corrupt eventually. The MUSB_G_NO_SKB_RESERVE will set the quirk_avoids_skb_reserve flag in usb_gadget struct to provide correctly aligned

[PATCH v4 4/9] usb: musb: tusb6010_omap: Use one musb_ep_select call in tusb_omap_dma_program

Having one musb_ep_select() instead the two calls in if/else is the same thing, but makes the code a bit simpler to follow. Signed-off-by: Peter Ujfalusi Tested-by: Tony Lindgren --- drivers/usb/musb/tusb6010_omap.c | 3 +-- 1 file changed, 1

resolving issue by: USB_AUTOSUSPEND=0

Issue can be resolved by setting: USB_AUTOSUSPEND=0 See details here: https://bugzilla.kernel.org/show_bug.cgi?id=117811 (also, isn't refusing HTML emails kind of backward in 2017, since HTML is default in most of the clients? You are effectively limiting general accessibility of your mailing

[PATCH v4 3/9] usb: musb: tusb6010: Add MUSB_G_NO_SKB_RESERVE to quirks

When using the g_ncm for networking this flag will make sure that the buffer is aligned to 32bit so the DMA can be used to offload the data movement. Signed-off-by: Peter Ujfalusi Tested-by: Tony Lindgren --- drivers/usb/musb/tusb6010.c | 3 ++- 1 file

Re: [PATCH] usb: chipidea: debug: check before accessing ci_role

On Thu, May 18, 2017 at 04:14:14PM +0200, Michael Thalmeier wrote: > ci_role BUGs when the role is >= CI_ROLE_END. > > Signed-off-by: Michael Thalmeier > --- > drivers/usb/chipidea/debug.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH] usb: chipidea: debug: check before accessing ci_role

On Thu, May 18, 2017 at 04:14:14PM +0200, Michael Thalmeier wrote: > ci_role BUGs when the role is >= CI_ROLE_END. > > Signed-off-by: Michael Thalmeier > --- > drivers/usb/chipidea/debug.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git

[uwb-i1480] question about value overwrite

Hello everybody, While looking into Coverity ID 1226913 I ran into the following piece of code at drivers/uwb/i1480/dfu/phy.c:99: 99static 100int i1480_mpi_read(struct i1480 *i1480, u8 *data, u16 srcaddr, size_t size) 101{ 102int result; 103struct i1480_cmd_mpi_read *cmd =

Re: [PATCH resend v3 1/4] usb: usbip tool: Check the return of get_nports()

On Thu, May 18, 2017 at 03:53:04PM +0300, Sergei Shtylyov wrote: > >From: Yuyang Du > > > >If we get nonpositive number of ports, there is no sense to > >Negative? Negative and zero. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of

Re: [PATCH v2 2/2] usb: gadget: f_mass_storage: Serialize wake and sleep execution

Hi Felipe, On 5/11/2017 5:27 PM, Thinh Nguyen wrote: > f_mass_storage has a memorry barrier issue with the sleep and wake > functions that can cause a deadlock. This results in intermittent hangs > during MSC file transfer. The host will reset the device after receiving > no response to resume

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

On Thu, May 18, 2017 at 9:51 AM, Guenter Roeck wrote: > On Thu, May 18, 2017 at 11:13:51AM +0200, Oliver Neukum wrote: >> Am Mittwoch, den 17.05.2017, 02:36 -0700 schrieb Guenter Roeck: >> > On 05/17/2017 12:34 AM, Oliver Neukum wrote: >> > > >> > > Am Mittwoch, den

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

Not Sure whether my previous response was sent properly. So re-sending. On Thu, May 18, 2017 at 2:08 PM, Badhri Jagan Sridharan wrote: > On Thu, May 18, 2017 at 9:51 AM, Guenter Roeck wrote: >> On Thu, May 18, 2017 at 11:13:51AM +0200, Oliver Neukum wrote:

Re: [v1 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM

On Sat, May 13, 2017 at 07:13:14AM +0700, Thang Q. Nguyen wrote: > XHCI specification 1.1 does not require xHCI 1.0 compliant controllers > to always enable hardware USB2 LPM. > However, the current xHCI driver always enable it by setting HLE=1 when > seeing HLC=1. This makes certain xHCI

Re: [PATCH] net1080: Remove unused function nc_dump_ttl()

From: Matthias Kaehlcke Date: Thu, 18 May 2017 10:57:19 -0700 > The function is not used, removing it fixes the following warning when > building with clang: > > drivers/net/usb/net1080.c:271:20: error: unused function > 'nc_dump_ttl' [-Werror,-Wunused-function] > > Also

Re: [PATCH] r8152: Remove unused function usb_ocp_read()

From: Matthias Kaehlcke Date: Thu, 18 May 2017 10:45:33 -0700 > The function is not used, removing it fixes the following warning when > building with clang: > > drivers/net/usb/r8152.c:825:5: error: unused function 'usb_ocp_read' > [-Werror,-Wunused-function] > >

Re: [v1 1/1] usb:host:xhci support option to disable xHCI 1.0 USB2 HW LPM

On Fri, May 19, 2017 at 5:30 AM, Rob Herring wrote: > On Sat, May 13, 2017 at 07:13:14AM +0700, Thang Q. Nguyen wrote: >> XHCI specification 1.1 does not require xHCI 1.0 compliant controllers >> to always enable hardware USB2 LPM. >> However, the current xHCI driver always

[PATCH] usb: chipidea: debug: check before accessing ci_role

ci_role BUGs when the role is >= CI_ROLE_END. Signed-off-by: Michael Thalmeier --- drivers/usb/chipidea/debug.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c index 6d23eed..1c31e8a

Runtime PM enabled EHCI does not respond to device plugging.

Hi, This issue happens on Carrizo AMD laptops, only EHCI is affected, XHCI works fine on the same machine. I can see lots of USB wakeup and resume messages showed every two seconds. Plug USB devices to the EHCI port does not change anything. dmesg with ehci-hcd, ehci-pci and usbcore dynamic

Re: [uwb-i1480] question about value overwrite

On Thu, May 18, 2017 at 06:00:06PM -0500, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1226913 I ran into the following piece of > code at drivers/uwb/i1480/dfu/phy.c:99: > > 99static > 100int i1480_mpi_read(struct i1480 *i1480, u8 *data, u16 srcaddr,

Re: [REGRESSION] Failed network caused by: xhci: switch to pci_alloc_irq_vectors

On Thu, May 18, 2017 at 11:42:34PM -0400, Steven Rostedt wrote: > > One of my the configs I use to test ftrace with (configs that have > caused failures in the past), has lots of irq issues and fails to > initialize the network of my box. I bisected the problem down to a > single commit, and when