[PATCH v2] xhci: Bad Ethernet performance plugged in ASM1042A host

v2 : fix coding format When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO image). It is known limitation of ASM1042A that is not compatible with driver scheduling, As a workaround we can modify flow

Re: Gadget driver & virtual hub

On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote: > On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote: > > > Another question ... > > > > Do i need to support dequeue() on EP0 ? > > Yes.  I don't know if any drivers ever dequeue requests from ep0, but > it should be supported. Talking of

Re: Gadget driver & virtual hub

On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote: > On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote: > > > Another question ... > > > > Do i need to support dequeue() on EP0 ? > > Yes.  I don't know if any drivers ever dequeue requests from ep0, but > it should be supported. > > There is

Re: [PATCH 2/6] USB / PCI / PM: Allow the PCI core to do the resume cleanup

On Thursday, June 08, 2017 11:24:55 AM Alan Stern wrote: > On Thu, 8 Jun 2017, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > hcd_pci_resume_noirq() used as a universal _resume_noirq handler for > > PCI USB controllers calls pci_back_from_sleep()

[PATCH 2/3] HID: usbhid: enable autosuspend for devices whose ...

From: Yueyao Zhu usage pages only points to CONSUMER. This allows autosuspend to be enabled and thus power saved on CONSUMER hid devices. Yet hid devices use other usage pages are not affected, e.g. keyboard, mouse. Signed-off-by: Yueyao Zhu ---

[PATCH 0/3] USB: add API for interface driver to vote for autosuspend

From: Yueyao Zhu Currently, if a USB driver would like to enable autosuspend on the USB device, usb_enable_autosuspend() seems to be the only option. However, this acts on the device level, and other interfaces might not desire to autosuspend the USB device. For example, for

[PATCH 1/3] USB: add API for interface driver to vote for autosuspend

From: Yueyao Zhu An interface driver can allow/disallow autosuspend power control for an interface, and if all the interfaces of the active configuration are allowed for autosuspend, autosuspend should be enabled on the usb device. Signed-off-by: Yueyao Zhu

[PATCH 3/3] sound: usb: allow interfaces that the driver claims to autosuspend

From: Yueyao Zhu Instead of calling usb_enable_autosuspend() to change the configuration of a USB device as an interface driver, enable autosuspend for every interfaces that the driver claims. Signed-off-by: Yueyao Zhu --- sound/usb/card.c | 3 +++ 1 file

Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote: > > So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans > to straighten this out. No, I think the main problem is that the hid_have_special_driver[] array change is garbage. It adds the ASUS ID,

Re: [PATCH] usb: gadget: dummy: implement ->udc_set_speed()

On Thu, 8 Jun 2017, Felipe Balbi wrote: > > Any results on testing the new memory barrier and exception handling > > patches for f_mass_storage? > > Oh, I couldn't reproduce anymore. I thought I had told ya. Hopefully, > this will be the last we hear from this problem :-s Does that mean you

Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

On Thu, 8 Jun 2017, Alan Cox wrote: > > Normally in this situation I'd recommend bisection. However, this case > > may be simple enough for a usbmon trace to provide the answer. > > With a shared file system between the T100TA and a big machine it's not > too hard to do some builds: > > commit

Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

> Normally in this situation I'd recommend bisection. However, this case > may be simple enough for a usbmon trace to provide the answer. With a shared file system between the T100TA and a big machine it's not too hard to do some builds: commit 76dd1fbebbaebab294dc09230960238746b883b1 is the

Re: [PATCH] usb: gadget: dummy: implement ->udc_set_speed()

Hi, Alan Stern writes: > On Thu, 8 Jun 2017, Felipe Balbi wrote: > >> Hi Alan, >> >> Alan Stern writes: >> > On Wed, 7 Jun 2017, Felipe Balbi wrote: >> > >> >> Move the code which was part of pullup() to the newly introduced >> >> method.

[PATCH] USB: gadget: fix GPF in gadgetfs

A NULL-pointer dereference bug in gadgetfs was uncovered by syzkaller: > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > Modules linked in: > CPU: 2 PID: 4820 Comm:

Re: usb/gadget: another GPF in usb_gadget_unregister_driver

On Thu, Jun 8, 2017 at 5:55 PM, Alan Stern wrote: > On Thu, 8 Jun 2017, Andrey Konovalov wrote: > >> On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern >> wrote: >> > On Wed, 7 Jun 2017, Andrey Konovalov wrote: >> > >> >> On Wed, Jun 7, 2017 at

[PATCH V5 2/2] usb: core: read USB ports from DT in the usbport LED trigger driver

From: Rafał Miłecki This uses DT info to read relation description of LEDs and USB ports. If DT has properly described LEDs, trigger will know when to turn them on. Signed-off-by: Rafał Miłecki --- V2: Update to use "led-triggers" V3: Update to use

[EXAMPLE V5 3/2] ARM: BCM53573: Specify ports for USB LED for Tenda AC9

From: Rafał Miłecki Signed-off-by: Rafał Miłecki --- This patch *should not* be applied. It's only an EXAMPLE and that's why it uses that weird 3/2 number. It's a proof of concept, it was tested & will be submitted through ARM tree if previous patches get

[PATCH V5 1/2] dt-bindings: leds: document new trigger-sources property

From: Rafał Miłecki Some LEDs can be related to a specific device(s) described in the DT. This property allows specifying such relations. E.g. USB LED should usually be used to indicate some USB port(s) state. Please note this binding is designed to be generic and not

[PATCH V5 0/2] usb: introduce "trigger-sources" DT property for usbport trigger

From: Rafał Miłecki This version of my patchset (V5) differs by renaming #source-cells to the #trigger-source-cells and documenting it in the leds/common.txt. I'd epxect both patches to go through Greg's usb.git if accepted. For a reference (and before someome comes with

Re: usb/gadget: another GPF in usb_gadget_unregister_driver

On Thu, 8 Jun 2017, Andrey Konovalov wrote: > On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern wrote: > > On Wed, 7 Jun 2017, Andrey Konovalov wrote: > > > >> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern > >> wrote: > >> > On Wed, 7 Jun 2017,

Re: [PATCH] usb: gadget: dummy: implement ->udc_set_speed()

On Thu, 8 Jun 2017, Felipe Balbi wrote: > Hi Alan, > > Alan Stern writes: > > On Wed, 7 Jun 2017, Felipe Balbi wrote: > > > >> Move the code which was part of pullup() to the newly introduced > >> method. > > > > Comments inline... > > thanks for your comments. I

Re: [BUG/PATCH] (Or I'm missing something) in hcd.h definition of Endpoint{out}Request

On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote: > This looks wrong: > > #define EndpointRequest \ > ((USB_DIR_IN|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8) > #define EndpointOutRequest \ > ((USB_DIR_OUT|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8) > > Shouldn't it be

Re: Gadget driver & virtual hub

On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote: > Another question ... > > Do i need to support dequeue() on EP0 ? Yes. I don't know if any drivers ever dequeue requests from ep0, but it should be supported. There is one other special requirement for ep0. When a new setup packet arrives,

Re: [PATCH 2/6] USB / PCI / PM: Allow the PCI core to do the resume cleanup

On Thu, 8 Jun 2017, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > hcd_pci_resume_noirq() used as a universal _resume_noirq handler for > PCI USB controllers calls pci_back_from_sleep() which is unnecessary > and may become problematic. > > It is

Re: Gadget driver & virtual hub

On Thu, Jun 08, 2017 at 07:39:15PM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2017-06-08 at 08:12 +0200, Greg KH wrote: > > On Thu, Jun 08, 2017 at 04:04:43PM +1000, Benjamin Herrenschmidt wrote: > > > And another one :-) > > > > > > So the virtual hub needs a vendor/device ID. > > > > > >

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

Hi Peter I have a look at your patches (http://www.spinics.net/lists/linux-usb/msg157134.html) and I wonder if power sequence is applicable only on hub node? hub are probed too late (after ci_ulpi_init). Do you think it is possible to read a power sequence in dts from ci_ulpi_init? Thanks

Re: [PATCH 0/6] ACPI / PM: Suspend-to-idle rework to deal with spurious ACPI wakeups

On Thursday, June 08, 2017 10:42:02 AM Dominik Brodowski wrote: > Rafael, > > On Thu, Jun 08, 2017 at 02:00:40AM +0200, Rafael J. Wysocki wrote: > > Hi All, > > > > This series is a replacement for commit eed4d47efe95 (ACPI / sleep: Ignore > > spurious SCI wakeups from suspend-to-idle) which is

[PATCH 4/5] phy: tusb1210: implement ->set_mode()

->set_mode() can be used to tell PHY to prepare itself to enter USB Host/Peripheral mode and that's very important for DRD configurations. Signed-off-by: Felipe Balbi --- drivers/phy/phy-tusb1210.c | 35 +++ 1 file changed, 35

[PATCH 5/5] usb: dwc3: core: program PHY for proper DRD modes

If PHY is entering Host mode, we need to enable VBUS. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/core.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index

[PATCH 2/5] usb: dwc3: ulpi: conditionally resume ULPI PHY

If PHY is suspended by the time we want to issue ULPI transfers, we will observe timeouts on the ULPI interface. In order to avoid such issue, let's make sure PHY is resumed before issuing a ULPI transfer. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/ulpi.c |

[PATCH 3/5] usb: dwc3: core: initialize ULPI before trying to get the PHY

If don't reorder initialization like this, we will never be able to get a reference to ULPI PHYs. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/core.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/core.c

[PATCH 1/5] phy: tusb1210: add support for TUSB1211

TUSB1211 is software compatible with TUSB1210 and as such we don't need an entire new driver to control it. Let's add its product ID to the existing TUSB1210 driver instead. Signed-off-by: Felipe Balbi --- drivers/phy/phy-tusb1210.c | 3 ++- 1 file changed, 2

Re: usb/gadget: another GPF in usb_gadget_unregister_driver

On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern wrote: > On Wed, 7 Jun 2017, Andrey Konovalov wrote: > >> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern wrote: >> > On Wed, 7 Jun 2017, Andrey Konovalov wrote: >> > >> >> Hi, >> >> >> >> I've got the

[PATCH] usb: dwc3: ep0: make sure wValue is 0 on GetStatus()

We don't (yet) support PTM_STATUS messages so let's not reply to them erroneously. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/ep0.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index

Re: Gadget driver & virtual hub

On Thu, 2017-06-08 at 08:12 +0200, Greg KH wrote: > On Thu, Jun 08, 2017 at 04:04:43PM +1000, Benjamin Herrenschmidt wrote: > > And another one :-) > > > > So the virtual hub needs a vendor/device ID. > > > > What is the policy here ? Can I get one from LF for it ? > > Yes, just ask me and I'll

Re: [PATCH] usb: gadget: dummy: implement ->udc_set_speed()

Hi Alan, Alan Stern writes: > On Wed, 7 Jun 2017, Felipe Balbi wrote: > >> Move the code which was part of pullup() to the newly introduced >> method. > > Comments inline... thanks for your comments. I think I've fixed them all.

Re: [PATCH 0/6] ACPI / PM: Suspend-to-idle rework to deal with spurious ACPI wakeups

Rafael, On Thu, Jun 08, 2017 at 02:00:40AM +0200, Rafael J. Wysocki wrote: > Hi All, > > This series is a replacement for commit eed4d47efe95 (ACPI / sleep: Ignore > spurious SCI wakeups from suspend-to-idle) which is still there in 4.12-rc4 > but > will be reverted shortly, because it

Re: Gadget driver & virtual hub

On Thu, Jun 08, 2017 at 06:38:40PM +1000, Benjamin Herrenschmidt wrote: > Alan, do you know the process to get one of the LF IDs ? Is that a > reasonable request ? Again, just ask me for one, I'm the one that give them out :) thanks, greg k-h -- To unsubscribe from this list: send the line

Re: Gadget driver & virtual hub

On Thu, 2017-06-08 at 10:18 +0200, Bjørn Mork wrote: > Benjamin Herrenschmidt writes: > > > And another one :-) > > > > So the virtual hub needs a vendor/device ID. > > > > What is the policy here ? Can I get one from LF for it ? Or should the > > HW vendor provide

[BUG/PATCH] (Or I'm missing something) in hcd.h definition of Endpoint{out}Request

This looks wrong: #define EndpointRequest \ ((USB_DIR_IN|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8) #define EndpointOutRequest \ ((USB_DIR_OUT|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8) Shouldn't it be USB_RECIP_ENDPOINT ? If I'm right, we had issues with some of the set/clear

Re: Gadget driver & virtual hub

Benjamin Herrenschmidt writes: > And another one :-) > > So the virtual hub needs a vendor/device ID. > > What is the policy here ? Can I get one from LF for it ? Or should the > HW vendor provide one here ? (I'm not sure they have one, I will have > to ask). > > I will

Re: [PATCH 2/2] HID: usbhid: Add HID_QUIRK_NO_INIT_REPORTS for Oculus Rift CV1

On Jun 08 2017 or thereabouts, Philipp Zabel wrote: > Hi Benjamin, > > On Wed, Jun 7, 2017 at 9:11 AM, Benjamin Tissoires > wrote: > > Hi Philip, > > > > On Jun 07 2017 or thereabouts, Philipp Zabel wrote: > [...] > > 2 things: > > - the 2 patches should be

Re: [PATCH 0/6] ACPI / PM: Suspend-to-idle rework to deal with spurious ACPI wakeups

Hi, On 08-06-17 02:00, Rafael J. Wysocki wrote: Hi All, This series is a replacement for commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) which is still there in 4.12-rc4 but will be reverted shortly, because it triggered issues on quite a few systems. The

Re: [PATCH 2/2] HID: usbhid: Add HID_QUIRK_NO_INIT_REPORTS for Oculus Rift CV1

Hi Benjamin, On Wed, Jun 7, 2017 at 9:11 AM, Benjamin Tissoires wrote: > Hi Philip, > > On Jun 07 2017 or thereabouts, Philipp Zabel wrote: [...] > 2 things: > - the 2 patches should be squashed together. There is no point having a > single patch for just 2

Re: Gadget driver & virtual hub

On Thu, Jun 08, 2017 at 04:04:43PM +1000, Benjamin Herrenschmidt wrote: > And another one :-) > > So the virtual hub needs a vendor/device ID. > > What is the policy here ? Can I get one from LF for it ? Yes, just ask me and I'll give you one. I just need to know exactly what this device is

Re: Gadget driver & virtual hub

And another one :-) So the virtual hub needs a vendor/device ID. What is the policy here ? Can I get one from LF for it ? Or should the HW vendor provide one here ? (I'm not sure they have one, I will have to ask). I will provide a way to override it but I need a sane default. Cheers, Ben. --