Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On Tue, May 3, 2016 at 2:16 PM, Dean Jenkins wrote: > > [ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header > synchronisation was lost, remaining 988 > > This error message consistently shows the remaining value to be 988, at > least for the 3 examples

xhci_handle_command_timeout and wait_for_completion

Hello Mathias, In c311e391a7ef "xhci: rework command timeout and cancellation," xHCI command timeouts were refactored to flow through xhci_handle_command_timeout. We've seen a few instances of hangs/crashes with upstream and RHEL7.2 kernels where someone gets stuck on

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On 2016-05-04 03:58, Dean Jenkins wrote: On 04/05/16 01:28, David B. Robins wrote: Here is the code snippet from the patch with my annotations between # #, I will try to explain my intentions. Feel free to point out any flaws: if (rx->remaining && (rx->remaining + sizeof(u32) <=

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On Tue, May 3, 2016 at 2:16 PM, Dean Jenkins wrote: > A good test would be to run "ping -c 1 -s $packet_length $ip_address" inside > a script which has a loop with an increasing payload length $packet_length > with a small delay between ping calls. This will show whether

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On Fri, May 6, 2016 at 8:00 AM, Dean Jenkins wrote: > My conclusion is that your USB to Ethernet Adaptor is not running at high > speed (480Mbps) mode which is causing a partial loss (corruption) of > Ethernet frames across the USB link. A USB Protocol Analyser or

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On Thu, May 5, 2016 at 1:11 AM, Dean Jenkins wrote: > On 05/05/16 00:45, John Stultz wrote: >> >> Just as a sample point, I have managed to reproduce exactly this issue >> on an x86_64 system by simply scp'ing a large file. > > Please tell us the x86_64 kernel version

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On 06/05/16 16:27, Andrew Lunn wrote: In other words, the full-speed hub is restricting the USB to Ethernet Adaptor to a 12Mbps (half-duplex) bandwidth to support Ethernet 100Mbps (full-duplex) traffic. That is not going to work very well because Ethernet frames (perhaps partial Ethernet frames)

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

> In other words, the full-speed hub is restricting the USB to > Ethernet Adaptor to a 12Mbps (half-duplex) bandwidth to support > Ethernet 100Mbps (full-duplex) traffic. That is not going to work > very well because Ethernet frames (perhaps partial Ethernet frames) > need to be discarded within

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On 05/05/16 13:19, Guodong Xu wrote: Hi, Dean I am not sure why do you insist 'not full speed'. Actually, the tests I run on ARM-64bit is at USB full speed mode. I pasted my log here: http://paste.ubuntu.com/16236442/ , which includes the information you requested above, ifconfig, dmesg. The

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

Hello Heikki, On 05/06/2016 01:29 AM, Heikki Krogerus wrote: On Fri, May 06, 2016 at 01:05:05AM -0700, Guenter Roeck wrote: [ ... ] I know there has been a lengthy discussion about the patch set, but I may have missed the conclusion. Is there some reason to _not_ advance it that I may have

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

On 05/06/2016 01:08 AM, Heikki Krogerus wrote: Hi, On Wed, May 04, 2016 at 08:05:44PM -0700, Guenter Roeck wrote: On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote: Hi, The OS, or more precisely the user space, needs to be able to control a few things regarding USB Type-C

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

On Fri, May 6, 2016 at 1:10 AM, Krzysztof Kozlowski wrote: > On 05/06/2016 12:42 AM, Rob Herring wrote: >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >>> Hi, >>> >>> This is a different, second try to fix usb3503+lan on Odroid U3 board >>> if it

Re: USB gadgets with configfs hang reboot

On Monday 18 April 2016 10:02:57 Ivaylo Dimitrov wrote: > > > On 8.04.2016 23:13, Ivaylo Dimitrov wrote: > >Hi, > > > >On 16.01.2016 12:40, Ivaylo Dimitrov wrote: > >>Hi, > >> > >>On 16.01.2016 00:48, Tony Lindgren wrote: > >>>Hi all, > >>> > >>>Looks like there's some issue with the USB

RE: MUSB driver on AM3352 dropping USB packets

> From: Bin Liu [mailto:b-...@ti.com] > On Thu, May 05, 2016 at 04:02:55PM +, Andrew Goodbody wrote: > > > From: Bin Liu [mailto:b-...@ti.com] > > > On Thu, May 05, 2016 at 03:12:00PM +, Andrew Goodbody wrote: > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > On Thu,

Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface

On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote: > The OTG core will use struct otg_hcd_ops to interface > with the HCD controller. > > The main purpose of this interface is to avoid directly > calling HCD APIs from the OTG core as they > wouldn't be defined in the built-in symbol

Re: [PATCH v7 01/14] usb: hcd: Initialize hcd->flags to 0

On Mon, May 02, 2016 at 03:18:44PM +0300, Roger Quadros wrote: > When using the OTG/drd library we can call hcd_add/remove > consecutively without calling usb_put_hcd/usb_create_hcd in between > so hcd->flags can be stale. > > If the HC dies due to whatever reason then without this > patch we get

Re: [PATCH v7 11/14] usb: otg: use dev_dbg() instead of VDBG()

On Mon, May 02, 2016 at 03:18:54PM +0300, Roger Quadros wrote: > Now that we have a device reference in struct usb_otg > let's use dev_dbg() for debug messages. > > Signed-off-by: Roger Quadros > --- > drivers/usb/common/usb-otg-fsm.c | 19 +++ > 1 file changed, 7

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

On Fri, May 06, 2016 at 01:05:05AM -0700, Guenter Roeck wrote: > Felipe, > > On 05/05/2016 11:50 PM, Felipe Balbi wrote: > > > > Hi Guenter, > > > > Guenter Roeck writes: > > > On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote: > > > > Hi, > > > > > > > > The

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

On Fri, May 06, 2016 at 09:50:00AM +0300, Felipe Balbi wrote: > > Hi Guenter, > > Guenter Roeck writes: > > On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote: > >> Hi, > >> > >> The OS, or more precisely the user space, needs to be able to control > >> a few

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

Hi, On Wed, May 04, 2016 at 08:05:44PM -0700, Guenter Roeck wrote: > On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote: > > Hi, > > > > The OS, or more precisely the user space, needs to be able to control > > a few things regarding USB Type-C ports. The first thing that must be >

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

Felipe, On 05/05/2016 11:50 PM, Felipe Balbi wrote: Hi Guenter, Guenter Roeck writes: On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote: Hi, The OS, or more precisely the user space, needs to be able to control a few things regarding USB Type-C ports. The

Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup

Hi, John Youn writes: > As you mentioned this is handled in the soft_disconnect sysfs. Why > shouldn't usb_gadget_disconnect() do the same thing, if not the gadget because there might be cases where we don't need/want the gadget to know about this

Re: [PATCH v3] usb: host: xhci-rcar: Avoid long wait in xhci_reset()

Hi, Yoshihiro Shimoda writes: > The firmware of R-Car USB 3.0 host controller will control the reset. > So, if the xhci driver doesn't do firmware downloading (e.g. kernel > configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR > is not set), the

Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup

Hi, Peter Chen writes: >> Peter Chen writes: >> >> "Du, Changbin" writes: >> >> > Hi, Balbi, >> >> > >> >> > The step to reproduce this issue is: >> >> > 1) connect device to a host and wait its enumeration. >> >> > 2)

Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup

On Fri, May 06, 2016 at 10:01:20AM +0300, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > >> "Du, Changbin" writes: > >> > Hi, Balbi, > >> > > >> > The step to reproduce this issue is: > >> > 1) connect device to a host and wait its

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

On Fri, May 06, 2016 at 08:12:24AM +0200, Krzysztof Kozlowski wrote: > On 05/06/2016 07:44 AM, Peter Chen wrote: > > On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote: > >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: > >>> Hi, > >>> > >>> This is a different,

Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup

Hi, Peter Chen writes: >> "Du, Changbin" writes: >> > Hi, Balbi, >> > >> > The step to reproduce this issue is: >> > 1) connect device to a host and wait its enumeration. >> > 2) trigger software disconnect by calling function >> >

Re: [PATCH] usb: gadget: Fix binding to UDC via configfs interface

Hi, Krzysztof Opasiak writes: > By default user could store only valid UDC name in configfs UDC > attr by doing: > > echo $UDC_NAME > UDC > > Commit (855ed04 "usb: gadget: udc-core: independent registration of > gadgets and gadget drivers") broke this behavior and allowed

Re: [PATCH] usb: misc: usbtest: fix pattern tests for scatterlists.

Hi, Alan Stern writes: > On Wed, 4 May 2016, Felipe Balbi wrote: > >> > multiple of 512 bytes and the maxpacket size is 1024. Then you either >> >> that's not common case for testusb. One of the test cases (see below) >> exercises exactly small sg entries: >> >>

Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

Hi Guenter, Guenter Roeck writes: > On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote: >> Hi, >> >> The OS, or more precisely the user space, needs to be able to control >> a few things regarding USB Type-C ports. The first thing that must be >> allowed to be

Re: [PATCH 02/10] usb: musb: Fix idling after host mode by increasing autosuspend delay

Hi, Bin Liu writes: >> Does the current 200 ms autosuspend timeout relate to anything real >> other than what I found out with my measurements? > > Not sure, I didn't checkk where the 200ms comes from. It was an arbitrary number from when runtime PM was first added by Hema. I

Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

Hi Jim, Jim Lin writes: > On 2016年05月04日 18:37, Felipe Balbi wrote: >> * PGP Signed by an unknown key >> >> >> Hi, >> >> Jim Lin writes: >> >> >> > In f_fs.c > " > static int __ffs_data_do_os_desc(enum ffs_os_desc_type type, >

Re: [RFC v2 13/13] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3

On 05/05/2016 10:16 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> On Odroid U3 (Exynos4412-based) board if USB was initialized by >> bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503) >> and LAN (smsc95xx) after

Re: [RFC v2 11/13] usb: port: Parse pwrseq phandle from Device Tree

On 05/05/2016 10:10 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq >> device. The pwrseq device will be used by USB hub to cycle the power >> before activating

Re: [RFC v2 09/13] power: pwrseq: Add support for USB hubs with external power

On 05/05/2016 09:52 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> Some USB devices on embedded boards have external power supply which has >> to be reset in certain conditions. Add pwrseq interface for this. >> >> Signed-off-by:

Re: [RFC v2 07/13] power: pwrseq: simple: Add support for toggling regulator

On 05/05/2016 09:31 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> Some devices need real hard-reset by cutting the power. During power >> sequence turn off and on the regulator, if it is provided. >> >> Signed-off-by: Krzysztof

[PATCH v3] usb: host: xhci-rcar: Avoid long wait in xhci_reset()

The firmware of R-Car USB 3.0 host controller will control the reset. So, if the xhci driver doesn't do firmware downloading (e.g. kernel configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR is not set), the reset of USB 3.0 host controller doesn't work correctly. Then, the host

Re: [RFC v2 05/13] power: pwrseq: Remove mmc prefix from mmc_pwrseq

On 05/05/2016 09:09 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> The "mmc" prefix is no longer needed after moving the pwrseq core code >> from mmc/ to power/. >> >> Signed-off-by: Krzysztof Kozlowski >>

Re: [RFC v2 02/13] power/mmc: Move pwrseq drivers to power/pwrseq

On 05/05/2016 08:44 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> The MMC power sequence drivers are useful also outside of MMC world: for >> USB devices needed a hard-reset before probing. Before extending and >> re-using pwrseq

Re: [RFC v2 01/13] usb: misc: usb3503: Clean up on driver unbind

On 05/05/2016 08:32 PM, Javier Martinez Canillas wrote: > Hello Krzysztof > > Patch looks good to me, I just have a trivial comment below. > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> The driver should clean up after itself by unpreparing the clock when it >> is unbound. >> >>

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

On 05/06/2016 07:44 AM, Peter Chen wrote: > On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote: >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >>> Hi, >>> >>> This is a different, second try to fix usb3503+lan on Odroid U3 board >>> if it was initialized by

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

On 05/06/2016 12:42 AM, Rob Herring wrote: > On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >> Hi, >> >> This is a different, second try to fix usb3503+lan on Odroid U3 board >> if it was initialized by bootloader (e.g. for TFTP boot). >> >> First version: >>