Re: USB resume issue

On Tue, 1 Dec 2015, Alan Cooper wrote: > On Tue, Dec 1, 2015 at 2:35 PM, Alan Stern wrote: > >> I'm now sure the host in "non-compliant". > > > > It is non-compliant if it turns off Vbus power during suspend. But > > that may be caused by the platform more than by the

Re: [PATCH 1/2] extcon: add driver for Intel USB mux

Hi Heikki, Follow my comments below. On Tue, Dec 01, 2015 at 03:32:37PM +0200, Heikki Krogerus wrote: > Several Intel PCHs and SOCs have an internal mux that is > used to share one USB port between USB Device Controller and > xHCI. The mux is normally handled by System FW/BIOS, but not > always.

Re: [PATCH 1/2] extcon: add driver for Intel USB mux

Hi Felipe, On Tue, Dec 01, 2015 at 02:34:34PM -0600, Felipe Balbi wrote: [snip] > > +EXPORT_SYMBOL_GPL(intel_usb_mux_register); > > + > > +void intel_usb_mux_unregister(struct intel_usb_mux *mux) > > +{ > > + extcon_unregister_notifier(>edev, EXTCON_USB_HOST, >nb); > > +

Re: [PATCH v3 5/6] usb: bcma: add USB 3.0 support

On 25/10/15 15:52, Hauke Mehrtens wrote: > On 10/24/2015 12:40 AM, Florian Fainelli wrote: >> On 23/10/15 14:37, Hauke Mehrtens wrote: >>> From: Rafał Miłecki >>> >>> Signed-off-by: Rafał Miłecki >>> Signed-off-by: Hauke Mehrtens >>> --- >>

Re: USB resume issue

On Tue, Dec 1, 2015 at 2:35 PM, Alan Stern wrote: >> I'm now sure the host in "non-compliant". > > It is non-compliant if it turns off Vbus power during suspend. But > that may be caused by the platform more than by the controller itself. > I wasn't able to find any

Re: [PATCH 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC

Hi, Heikki Krogerus writes: > Intel Braswell/Cherrytrail has an internal mux that shares > one USB port between USB Device Controller and xHCI. The > same mux is found on several SOCs from Intel, but only on > a few Cherrytrail based platforms the OS is expected

Re: [PATCH v5 2/2] USB: quirks: Apply ALWAYS_POLL to all ELAN devices

On Tue, Dec 01, 2015 at 11:09:23PM +0100, Jiri Kosina wrote: > On Tue, 1 Dec 2015, Adrien Vergé wrote: > > > All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use > > this quirk for all devices from this vendor, rather than maintaining a > > list of all its known product IDs. > >

Re: [PATCH v3 0/6] usb: bcma: add USB 3.0 support

On Fri, Oct 23, 2015 at 11:36:56PM +0200, Hauke Mehrtens wrote: > This patch adds support for the USB 3.0 controller in the bcm53xx Northstar > SoC. > These patches are based on top of usb-next. > > This also adds a fake doorbell quirk which is needed for this controller > > changes since: >

Re: [PATCH] usb: host: pci_quirks: fix memory leak, by adding iounmap

On Fri, Nov 06, 2015 at 05:46:30PM +0530, Saurabh Sengar wrote: > added iounmap inorder to free memory mapped to base before returning > > Signed-off-by: Saurabh Sengar > --- > drivers/usb/host/pci-quirks.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >

Re: [PATCH 1/2] extcon: add driver for Intel USB mux

Hi, David Cohen writes: > Hi Felipe, > > On Tue, Dec 01, 2015 at 02:34:34PM -0600, Felipe Balbi wrote: > > [snip] > >> > +EXPORT_SYMBOL_GPL(intel_usb_mux_register); >> > + >> > +void intel_usb_mux_unregister(struct intel_usb_mux *mux) >> > +{ >> > +

Re: Infrastructure for zerocopy I/O

On Mon, Nov 30, 2015 at 12:14:59PM -0500, Alan Stern wrote: > As I recall, Markus's original patch took care of this by checking to > see whether the transfer buffer was in one of the mmap'ed areas. If it > was then the transfer would be zerocopy; otherwise it would be normal. > That seems like

Re: [PATCH 1/2] extcon: add driver for Intel USB mux

Hi, Heikki Krogerus writes: > Several Intel PCHs and SOCs have an internal mux that is > used to share one USB port between USB Device Controller and > xHCI. The mux is normally handled by System FW/BIOS, but not > always. For those platforms where the FW does

Re: [PATCH v5 2/2] USB: quirks: Apply ALWAYS_POLL to all ELAN devices

On Tue, 1 Dec 2015, Adrien Vergé wrote: > All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use > this quirk for all devices from this vendor, rather than maintaining a > list of all its known product IDs. > > Tested-by: Adrien Vergé > Signed-off-by:

Re: 4.3.0: AUKEY CB-H16 13+2port USB3 VIA812 hub does not recognize Prolific-based USB3-SATA dongle

Mathias Nyman wrote: Hi There are some xhci resume related issues which might be related to this. Host and device initiated resume functions race, and we end up with this similar output: Nov 26 02:24:18 vostro kernel: xhci_hcd :0b:00.0: suspend failed because a port is resuming Nov 26

[no subject]

subscribe -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] hid: usbhid: hid-core: fix recursive deadlock

Hi Jiri, On Tue, Dec 1, 2015 at 8:36 AM, Jiri Kosina wrote: > On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote: > >> The critical section protected by usbhid->lock in hid_ctrl() is too >> big and because of this it causes a recursive deadlock. "Too big" means >> the case statement

Re: [PATCH v3 0/6] usb: bcma: add USB 3.0 support

On 1 December 2015 at 23:28, Greg KH wrote: > On Fri, Oct 23, 2015 at 11:36:56PM +0200, Hauke Mehrtens wrote: >> This patch adds support for the USB 3.0 controller in the bcm53xx Northstar >> SoC. >> These patches are based on top of usb-next. >> >> This also adds a

Re: [PATCH v3 0/6] usb: bcma: add USB 3.0 support

On Tue, Dec 01, 2015 at 11:44:19PM +0100, Rafał Miłecki wrote: > On 1 December 2015 at 23:28, Greg KH wrote: > > On Fri, Oct 23, 2015 at 11:36:56PM +0200, Hauke Mehrtens wrote: > >> This patch adds support for the USB 3.0 controller in the bcm53xx > >> Northstar SoC.

Re: Linux as a USB hub?

On Wed, Dec 02, 2015 at 02:14:48AM +0200, Rogan Dawes wrote: > Hi folks, > > I'm wondering if it is possible/reasonable to try to turn a linux > device with host and OTG ports into something that looks and acts like > a USB hub? Nope, go spend $10 and buy a USB hub, it's cheaper and will work

Re: [PATCH] Documentation: nousb is a module parameter

On Tue, Dec 01, 2015 at 03:52:54PM +0100, Oliver Neukum wrote: > The documentation wrongly implied that it is a core parameter. > That is not true. If usbcore is compiled as a module, a module > parameter needs a prefix. > > Signed-off-by: Oliver Neukum > --- >

Re: [PATCH v3 5/6] usb: bcma: add USB 3.0 support

On 12/1/2015 2:34 PM, Florian Fainelli wrote: On 25/10/15 15:52, Hauke Mehrtens wrote: On 10/24/2015 12:40 AM, Florian Fainelli wrote: On 23/10/15 14:37, Hauke Mehrtens wrote: From: Rafał Miłecki Signed-off-by: Rafał Miłecki Signed-off-by: Hauke

Re: USB resume issue

On Tue, Dec 1, 2015 at 4:48 PM, Alan Stern wrote: > On Tue, 1 Dec 2015, Alan Cooper wrote: > >> On Tue, Dec 1, 2015 at 2:35 PM, Alan Stern wrote: >> >> I'm now sure the host in "non-compliant". >> > >> > It is non-compliant if it turns off

Linux as a USB hub?

Hi folks, I'm wondering if it is possible/reasonable to try to turn a linux device with host and OTG ports into something that looks and acts like a USB hub? The objective is to allow me to monitor the USB traffic from a Windows host to facilitate writing a device emulator on the Linux device.

Re: [PATCH][usbutils] .gitmodules: change URL of usbhid-dump (to github)

On Sat, Apr 04, 2015 at 01:44:58PM +0200, Stefan Tauner wrote: > Signed-off-by: Stefan Tauner > --- > > Hi Greg, > > I think DIGImend has eventually moved their code to github so > git submodule update --init for usbutils fails: > Cloning into 'usbhid-dump'... > fatal:

Re: [PATCH v2 1/1] lsusb: Added support for Billboard Capability descriptor

On Wed, Oct 14, 2015 at 01:16:37AM +0530, Muthu M wrote: > Added support for Billboard Capability descriptor as per Universal > Serial Bus Device Class Definition for Billboard Devices Revision 1.1 > > Signed-off-by: Muthu M > Reviewed-by: Felipe Balbi > --- >

Re: Linux as a USB hub?

On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote: > Thanks Greg. > > At a high level, what is needed to implement a new type of USB device gadget, > such as a display link device? A lot of work :) > I assume there is a small kernel portion that simply relays data to user > space, >

Re: [PATCH] usb: interface: allow drivers declare number of endpoints they need

On Tue, Dec 01, 2015 at 08:53:57AM +0100, Oliver Neukum wrote: > On Mon, 2015-11-30 at 17:09 -0800, Greg Kroah-Hartman wrote: > > > that would loop through endpoints so that drivers do not have to > > > open-code the loop and we indeed need to fix the drivers that > > blindly > > > grab endpoints

Re: USB resume issue

On Tue, Dec 1, 2015 at 11:07 AM, Alan Stern wrote: > On Tue, 1 Dec 2015, Oliver Neukum wrote: > >> On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote: >> > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a >> > > CONNECTED retry for a different reason

Re: [GIT PULL] USB-serial fixes for v4.4-rc3

On Thu, Nov 26, 2015 at 09:24:23AM +0100, Johan Hovold wrote: > Hi Greg, > > Some minor device-id fixes for v4.4-rc3. Note that I included the patch > that blacklists the flash-loader device in cdc-acm. > > Thanks, > Johan > > > The following changes since commit

Regression, was [PATCH 4/4] USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe

Hi! Alexandre Belloni wrote: > ohci_hcd_at91_drv_probe() has four at91_for_each_port. They can be merged > into two loops without changing the driver behaviour. Not so much, I bisected the following panic to the commit matching this patch (e4df92279fd9e01532f65e5ba397877799ed6252). Reverting

Re: [GIT PULL] USB fixes for v4.4-rc3

On Mon, Nov 23, 2015 at 10:47:27AM -0600, Felipe Balbi wrote: > Hi Greg, > > Here's my second round of fixes for current -rc as promissed. > > Let me know if you want anything to be changed, but response > may be slow. > > 'vacation-mode' is a major mode which prevents emacs from being > used

[PATCH v6 3/3] usb: gadget: f_midi: pre-allocate IN requests

This patch introduces pre-allocation of IN endpoint USB requests. This improves on latency (requires no usb request allocation on transmit) and avoid several potential probles on allocating too many usb requests (which involves DMA pool allocation problems). This implementation also handles

[PATCH v6 1/3] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

This avoids duplication of USB requests for OUT endpoint and re-enabling endpoints. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_midi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/function/f_midi.c

[PATCH v6 2/3] usb: gadget: f_midi: fail if set_alt fails to allocate requests

This ensures that the midi function will only work if the proper number of IN and OUT requrests are allocated. Otherwise the function will work with less requests then what the user wants. Signed-off-by: Felipe F. Tonello --- drivers/usb/gadget/function/f_midi.c | 3 ++-

[PATCH v6 0/3] USB MIDI Gadget improvements and bug fixes

Fixed all comments suggested by the linux-usb list. changes in v6: - Removed patches already applied in Balbi's tree - Cleanups on pre-allocation usb requrests patch - Fixed indentention on patch 1 - Added patch which fails set_alt if a failure happened while allocating usb requests

Re: [PATCH v3 1/2] cdc_acm: Ignore Infineon Flash Loader utility

On Mon, Nov 23, 2015 at 10:28:25AM +0100, Johan Hovold wrote: > On Sun, Nov 22, 2015 at 11:47:17AM +0100, Jonas Jonsson wrote: > > Some modems, such as the Telit UE910, are using an Infineon Flash Loader > > utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC > > Data). The

Re: [PATCH v4 2/2] USB: quirks: Apply ALWAYS_POLL to all ELAN devices

On Tue, Nov 24, 2015 at 04:02:05PM +0100, Adrien Vergé wrote: > All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use > this quirk for all devices from this vendor, rather than maintaining a > list of all its known product IDs. > > Tested-by: Adrien Vergé >

Re: USB resume issue

On Tue, Dec 1, 2015 at 12:12 PM, Alan Cooper wrote: > On Tue, Dec 1, 2015 at 11:07 AM, Alan Stern wrote: >> On Tue, 1 Dec 2015, Oliver Neukum wrote: >> >>> On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote: >>> > > A recent patch,

[PATCH v5 12/12] usb: doc: add document for xHCI DbC driver

Add Documentation/usb/xhci-dbc.txt. This document includes development status and user guide for USB3 debug port. Signed-off-by: Lu Baolu --- Documentation/usb/xhci-dbc.txt | 350 + MAINTAINERS| 1 +

[PATCH v5 11/12] usb: serial: usb_debug: add support for dbc debug device

This patch add dbc debug device support in usb_debug driver. Signed-off-by: Lu Baolu Acked-by: Johan Hovold --- drivers/usb/serial/usb_debug.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git

[PATCH v5 10/12] usb: xhci: dbc: add handshake between debug target and host

After DbC setup, debug target needs to wait until tty driver and application (e.g. mincom) on debug taget start. Otherwise, out messages might be ignored. This patch adds a ping/pong mechanism between debug target and host. Debug target will be waiting there until user presses 'Y' or 'y' in the

[PATCH v5 07/12] usb: xhci: dbc: handle dbc-configured exit

DbC might exit configured state in some cases (refer to 7.6.4.4 in xHCI spec 1.1). Software needs detect and clear this situation by clearing DCCTRL.DCR and wait until the DbC configured before read or write oprations. Signed-off-by: Lu Baolu ---

[PATCH v5 06/12] usb: xhci: dbc: add bulk out and bulk in interfaces

This patch adds interfaces for bulk out and bulk in ops. These interfaces could be used to implement early printk bootconsole or hook to various system debuggers. Signed-off-by: Lu Baolu --- drivers/usb/early/xhci-dbc.c | 373 +++

[PATCH v5 05/12] usb: xhci: dbc: add debug buffer

"printk" is not suitable for dbc debugging especially when console is in usage. This patch adds a debug buffer in dbc driver and puts the debug messages in this local buffer. The debug buffer could be dumped whenever the console is not in use. This part of code will not be visible unless DBC_DEBUG

[PATCH v5 09/12] x86: early_printk: add USB3 debug port earlyprintk support

Add support for early printk by writing debug messages to the USB3 debug port. Users can use this type of early printk by specifying kernel parameter of "earlyprintk=xdbc". This gives users a chance of providing debug output. Signed-off-by: Lu Baolu ---

[PATCH v5 08/12] usb: xhci: dbc: handle endpoint stall

In case of endpoint stall, software is able to detect the situation by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB framework to handle endpoint stall. When software detects endpoint stall situation, it should wait until endpoint is recovered before read or write oprations.

[PATCH v5 03/12] usb: xhci: dbc: probe and setup xhci debug capability

xHCI debug capability (DbC) is an optional functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list in mmio of the host. This patch introduces the code to probe and initialize the debug capability hardware during early

[PATCH v5 01/12] usb: xhci: add sysfs file for xHCI debug port

This patch adds a sysfs file for users to check 1) whether the debug capability is implemented by hardware; 2) if supported, which state does it stay at. With a host that supports debug port, a file named "debug_port_state" will be created under the device sysfs directory. Reading this file will

[PATCH v5 02/12] x86: fixmap: add permanent fixmap for xhci debug port

xHCI compatible USB3 host controller may provide debug capability which enables low-level system debug over USB. In order to probing this debug capability, Linux kernel needs to map and access the mmio of the host controller during early boot. This patch adds permenent fixmap pages in

[PATCH v5 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

On Intel platforms, if the debug target is connected with debug host, enabling DCE bit in command register leads to a port hung state. In the hung state, the host system will not see a port connected status bit set. Hence debug target fails to be probed. The state could be resolved by performing

[PATCH v5 00/12] usb: early: add support for early printk through USB3 debug port

Hi, This patch series adds support for early printk through USB3 debug port. USB3 debug port is described in xHCI specification as an optional extended capability. The first patch adds a file in sysfs, through which users can check whether the debug capability is supported by a specific host

Re: [PATCH] usb: udc: lpc32xx: fix warnings caused by enabling unprepared clock

Hi Felipe, On 17.10.2015 22:24, Vladimir Zapolskiy wrote: > If common clock framework is configured, the driver generates warnings, > which is fixed by this change: > > WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:728 > clk_core_enable+0x2c/0xf0() > Modules linked in: > CPU: 0 PID: 1

[PATCH V7 1/1] usb:serial: Add Fintek F81532/534 driver

This driver is for Fintek F81532/F81534 USB to Serial Ports IC. Features: 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC 2. Support Baudrate from B50 to B150 (excluding B100). 3. The RTS signal can be transformed their behavior with configuration by ioctl TIOCGRS485/TIOCSRS485

Re: [PATCH 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC

On 12/01/2015 09:32 PM, Heikki Krogerus wrote: > Intel Braswell/Cherrytrail has an internal mux that shares > one USB port between USB Device Controller and xHCI. The > same mux is found on several SOCs from Intel, but only on > a few Cherrytrail based platforms the OS is expected to > configure

Re: [PATCH] usb: host: pci_quirks: fix memory leak, by adding iounmap

On 2 December 2015 at 04:05, Greg KH wrote: > On Fri, Nov 06, 2015 at 05:46:30PM +0530, Saurabh Sengar wrote: >> added iounmap inorder to free memory mapped to base before returning >> >> Signed-off-by: Saurabh Sengar >> --- >>

[PATCH v5 1/2] USB: quirks: Fix another ELAN touchscreen

Like other buggy models that had their fixes [1], the touchscreen with id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier quirk. Otherwise, it fails to respond, blocks the boot for a random amount of time and pollutes dmesg with: [ 2887.373196] usb 1-5: new full-speed USB device

[PATCH v5 2/2] USB: quirks: Apply ALWAYS_POLL to all ELAN devices

All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use this quirk for all devices from this vendor, rather than maintaining a list of all its known product IDs. Tested-by: Adrien Vergé Signed-off-by: Adrien Vergé ---

[PATCH v5 0/2] Fixes for ELAN touchscreens

This is the fifth version of a patchset which originally aimed to fix a buggy touchscreen from ELAN Microelectronics. Changes since v4: - Cast HID_ANY_ID to an __u16 so to keep gcc happy on AVR32 arch. Changes since v3: - Use HID_ANY_ID to define a vendor-ID-global quirk, as suggested by

Re: USB resume issue

On Tue, 1 Dec 2015, Alan Cooper wrote: > On Tue, Dec 1, 2015 at 11:07 AM, Alan Stern wrote: > > On Tue, 1 Dec 2015, Oliver Neukum wrote: > > > >> On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote: > >> > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf,

Re: [PATCH] usb: interface: allow drivers declare number of endpoints they need

On Mon, Nov 30, 2015 at 7:47 PM, Dmitry Torokhov wrote: > On Mon, Nov 30, 2015 at 3:36 PM, Greg Kroah-Hartman > wrote: >> On Mon, Nov 30, 2015 at 02:56:09PM -0800, Dmitry Torokhov wrote: >>> On Mon, Nov 30, 2015 at 2:18 PM, Greg

Re: [PATCH] usb: interface: allow drivers declare number of endpoints they need

On Tue, Dec 1, 2015 at 11:46 AM, Josh Boyer wrote: > On Mon, Nov 30, 2015 at 7:47 PM, Dmitry Torokhov > wrote: >> On Mon, Nov 30, 2015 at 3:36 PM, Greg Kroah-Hartman >> wrote: >>> On Mon, Nov 30, 2015 at

[PATCH] usb: core : hub: Fix BOS 'NULL pointer' kernel panic

When a USB 3.0 mass storage device is disconnected in transporting state, storage device driver may handle it as a transport error and reset the device by invoking usb_reset_and_verify_device() and following could happen: in usb_reset_and_verify_device(): udev->bos = NULL; For U1/U2 enabled

Re: [PATCHv3 00/14] Equivalent of tcm_usb_gadget with configfs

Hi Nicholas, W dniu 29.11.2015 o 07:16, Nicholas A. Bellinger pisze: Hi Andrzej & Co, On Mon, 2015-11-23 at 09:22 +0100, Andrzej Pietrasiewicz wrote: W dniu 15.11.2015 o 00:27, Nicholas A. Bellinger pisze: Hi Andrzej & Co, Ok, I've added both series into target-pending/queue-next so

Bug 103411 - Ethernet frames get broken for g_ether / g_cdc

Hi all, following from bugzilla.kernel.org I'm now writing to this group. The short summary is, that I'm trying to get the USB- gadget running with a ARM device. In my case it's the Arietta G25 (Atmel AT91SAM9G25 SoC) from ACME: http://www.acmesystems.it/arietta Everything seems to work at the

Re: Bug 103411 - Ethernet frames get broken for g_ether / g_cdc

On Tue, 2015-12-01 at 10:41 +0100, Alexander Krause wrote: > Messages on the host are: > [44685.879438] usb 3-1.2: new high-speed USB device number 83 using > xhci_hcd > [44685.979721] usb 3-1.2: config 1 interface 0 altsetting 0 endpoint > 0x83 has an invalid bInterval 32, changing to 9 >

[TESTPATCH v2] xhci: fix usb2 resume timing and races.

usb2 ports need to signal resume for 20ms before moving to U0 state. Both device and host can initiate resume. On host initated resume port is set to resume state, sleep 20ms, and finally set port to U0 state. On device initated resume a port status interrupt with a port in resume state in

Re: [PATCH V4] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

On Tue, Nov 03, 2015 at 09:51:11PM -0600, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > > On Tue, Nov 03, 2015 at 07:56:55AM -0600, Felipe Balbi wrote: > >> > >> Hi, > >> > >> Nathan Sullivan writes: > >> > The USB OTG support

Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.

Hi, Mathias Nyman writes: > On 01.12.2015 16:32, Felipe Balbi wrote: >> >> Hi, >> >> Mathias Nyman writes: >>> usb2 ports need to signal resume for 20ms before moving to U0 state. >> >> at least 20ms ;-) Recently, we decided to

Re: [PATCH] usb: core : hub: Fix BOS 'NULL pointer' kernel panic

On Tue, 1 Dec 2015, Hans Yang wrote: > When a USB 3.0 mass storage device is disconnected in transporting > state, storage device driver may handle it as a transport error and > reset the device by invoking usb_reset_and_verify_device() > and following could happen: > > in

Re: USB resume issue

On Mon, 30 Nov 2015, Alan Cooper wrote: > I'm seeing a problem that looks like an issue in the USB-Persist > feature. I'm finding that all my 3.0 thumb drives are torn down and > brought back up (fail USB-Persist) during resume from "suspend to > memory" if they are plugged into a 2.0 EHCI/OHCI

Re: USB resume issue

On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote: > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a > > CONNECTED retry for a different reason and I could simply increase > > this retry time. Any thoughts? > > I don't know. You've got a non-compliant host combined with an

Re: [TESTPATCH] xhci: fix usb2 resume timing and races.

On Mon, 30 Nov 2015, Mathias Nyman wrote: > usb2 ports need to signal resume for 20ms before moving to U0 state. > Both device and host can initiate resume. > > On host initated resume port is set to resume state, sleep 20ms, > and finally set port to U0 state. That's an odd approach. The

Re: [linux-sunxi] [PATCH v3 2/2] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

On Wed, 2015-11-25 at 17:50 +0100, Hans de Goede wrote: > From: Reinder de Haan > > Note this commit only adds support for phys 1-3, phy 0, the otg phy, > is > not yet (fully) supported after this commit. > > Signed-off-by: Reinder de Haan >

Re: 4.3.0: AUKEY CB-H16 13+2port USB3 VIA812 hub does not recognize Prolific-based USB3-SATA dongle

Hi There are some xhci resume related issues which might be related to this. Host and device initiated resume functions race, and we end up with this similar output: Nov 26 02:24:18 vostro kernel: xhci_hcd :0b:00.0: suspend failed because a port is resuming Nov 26 02:24:18 vostro

Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.

Hi, Mathias Nyman writes: > usb2 ports need to signal resume for 20ms before moving to U0 state. at least 20ms ;-) Recently, we decided to drive resume for 40ms to support devices with broken FW. > Both device and host can initiate resume. > > On host initated

Re: Bug 103411 - Ethernet frames get broken for g_ether / g_cdc

Dear Oliver, I applied your patch and recompiled my kernel (4.2.3) on the host. However I'm not getting more debug info. How can I enable the output of netdev_dbg ? I've enabled debug-support in my kernel and changed the loglevel: # cat /proc/sys/kernel/printk 8 4 1 7 Also

Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.

On 01.12.2015 16:32, Felipe Balbi wrote: Hi, Mathias Nyman writes: usb2 ports need to signal resume for 20ms before moving to U0 state. at least 20ms ;-) Recently, we decided to drive resume for 40ms to support devices with broken FW. True, but specs talk

[PATCH 2/3] usb: make "nousb" a clear module parameter

It shouldn't matter how usbcore is compiled. As it is a subsystem, the correct way to use nousb should be usbcore.nousb Signed-off-by: Oliver Neukum --- drivers/usb/core/usb.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/usb/core/usb.c

[PATCH 3/3] xhci: refuse loading if nousb is used

The module should fail to load. Signed-off-by: Oliver Neukum CC: sta...@kernel.org --- drivers/usb/host/xhci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 6bbe3c3..1efb1f8 100644 --- a/drivers/usb/host/xhci.c

[PATCH] Documentation: nousb is a module parameter

The documentation wrongly implied that it is a core parameter. That is not true. If usbcore is compiled as a module, a module parameter needs a prefix. Signed-off-by: Oliver Neukum --- Documentation/kernel-parameters.txt | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH 3/3] usb: musb: remove redundant stack buffer

Hi, Rasmus Villemoes writes: > aRevision is only used once, so we might as well do the formatting as > part of the pr_debug. This eliminates the stack buffer, and avoids > doing the formatting at all when pr_debug is compiled out. > > Signed-off-by: Rasmus Villemoes

[PATCHv4 08/11] usb: gadget: f_tcm: remove compatibility layer

There are no old function interface users left. Signed-off-by: Andrzej Pietrasiewicz --- drivers/usb/gadget/function/f_tcm.c | 87 +++-- 1 file changed, 6 insertions(+), 81 deletions(-) diff --git a/drivers/usb/gadget/function/f_tcm.c

[PATCHv4 09/11] usb: gadget: f_tcm: remove redundant singleton

The only instance is guaranteed with TPG_INSTANCES defined to 1. Signed-off-by: Andrzej Pietrasiewicz --- drivers/usb/gadget/function/f_tcm.c | 9 - drivers/usb/gadget/function/tcm.h | 2 -- 2 files changed, 11 deletions(-) diff --git

[PATCHv4 07/11] usb: gadget: tcm: convert to use new function registration interface

Convert the only user of old tcm function interface so that the old interface can be removed. Signed-off-by: Andrzej Pietrasiewicz --- drivers/usb/gadget/legacy/Kconfig | 1 + drivers/usb/gadget/legacy/tcm_usb_gadget.c | 62 +- 2

[PATCHv4 05/11] usb: gadget: tcm: factor out f_tcm

Prepare for converting tcm to new function registration interface. Signed-off-by: Andrzej Pietrasiewicz --- drivers/usb/gadget/function/f_tcm.c| 2151 drivers/usb/gadget/function/tcm.h | 132 ++

[PATCHv4 00/11] Equivalent of tcm_usb_gadget with configfs

Dear All, This series adds support to tcm usb gadget for composing it with configfs. @target-devel folks: You might be wondering why add configfs for something which already supports configfs. In tcm_usb_gadget configfs has beeen used for configuring the SCSI target part, but the usb gadget part

[PATCH 0/2] extcon: driver for Intel USB MUX

Hi, This is a driver for an internal mux which is available on most modern Intel platforms that shares an USB port between USB Device Controller and xHCI. Normally BIOS or ACPI take care of it, but on some platforms that is not possible, and the OS has to control it. When the mux needs to be

[PATCH 1/2] extcon: add driver for Intel USB mux

Several Intel PCHs and SOCs have an internal mux that is used to share one USB port between USB Device Controller and xHCI. The mux is normally handled by System FW/BIOS, but not always. For those platforms where the FW does not take care of the mux, this driver is needed. Signed-off-by: Heikki

Re: Bug 103411 - Ethernet frames get broken for g_ether / g_cdc

Oliver Neukum writes: > On Tue, 2015-12-01 at 10:41 +0100, Alexander Krause wrote: > >> Messages on the host are: >> [44685.879438] usb 3-1.2: new high-speed USB device number 83 using >> xhci_hcd >> [44685.979721] usb 3-1.2: config 1 interface 0 altsetting 0 endpoint >> 0x83

Re: Bug 103411 - Ethernet frames get broken for g_ether / g_cdc

On Tue, 2015-12-01 at 14:44 +0100, Bjørn Mork wrote: > Oliver Neukum writes: > > > On Tue, 2015-12-01 at 10:41 +0100, Alexander Krause wrote: > > > >> Messages on the host are: > >> [44685.879438] usb 3-1.2: new high-speed USB device number 83 using > >> xhci_hcd > >>

[PATCHv4 06/11] usb: gadget: f_tcm: convert to new function interface with backward compatibility

Converting tcm to the new function interface requires converting USB tcm's function code and its users. This patch converts the f_tcm.c to the new function interface. The file can be now compiled into a separate module usb_f_tcm.ko. The old function interface is provided by means of

[PATCHv4 10/11] usb: gadget: f_tcm: use usb_gstrings_attach

Do not directly use file static strings definitions in instances of f_tcm. Instead use usb_gstrings_attach. Signed-off-by: Andrzej Pietrasiewicz --- drivers/usb/gadget/function/f_tcm.c | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git

[PATCHv4 03/11] usb: gadget: tcm: use strtobool for a boolean value

Simplify the function. Signed-off-by: Andrzej Pietrasiewicz --- drivers/usb/gadget/legacy/tcm_usb_gadget.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c

Re: [PATCHv4 00/11] Equivalent of tcm_usb_gadget with configfs

v3..v4: - rebased onto current Nicholas' tree (b1c06ebadd277421c3f59569708ed356eb5dded5, tcm_usb_gadget: Fix enabled attribute failure) The commit hash-id onto which the series is rebased should be: 1cc92aed7192caa8987bba0f88226f57e9b4ed73 Sorry for confusion, AP -- To unsubscribe from

[PATCHv4 01/11] usb: gadget: tcm: split string definitions into function and device

Prepare for factoring out f_tcm from a legacy gadget. Signed-off-by: Andrzej Pietrasiewicz --- drivers/usb/gadget/legacy/tcm_usb_gadget.c | 25 + drivers/usb/gadget/legacy/tcm_usb_gadget.h | 3 +-- 2 files changed, 22 insertions(+), 6 deletions(-)

Re: [PATCH V4] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

Hi Li, Li Jun writes: >> > I am sorry I did not consider the legacy OTG design, this patch should >> > be dropped. >> >> there is no "legacy" OTG design. OTG requires a bus suspend to enter >> HNP, and that's achieved by stopping all transfers and avoid new URB >>

[PATCHv4 04/11] usb: gadget: tcm: simplify attribute store function

Simplify function code. Signed-off-by: Andrzej Pietrasiewicz --- drivers/usb/gadget/legacy/tcm_usb_gadget.c | 22 +++--- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c

[PATCHv4 11/11] usb: gadget: f_tcm: add configfs support

Allow using the tcm function as a component of a gadget composed with ConfigFS. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/ABI/testing/configfs-usb-gadget-tcm | 6 ++ drivers/usb/gadget/Kconfig| 14 +

[PATCH 2/2] usb: pci-quirks: register USB mux found on Cherrytrail SOC

Intel Braswell/Cherrytrail has an internal mux that shares one USB port between USB Device Controller and xHCI. The same mux is found on several SOCs from Intel, but only on a few Cherrytrail based platforms the OS is expected to configure it. Normally BIOS takes care of it. The driver for the

Re: USB resume issue

On Tue, 1 Dec 2015, Oliver Neukum wrote: > On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote: > > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a > > > CONNECTED retry for a different reason and I could simply increase > > > this retry time. Any thoughts? > > > > I don't

  1   2   >