Re: [PATCH] usb: xhci: Add quirk for Certain failing HP keyboard on reset after resume

On 7/31/2017 9:16 PM, Greg KH wrote: > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > >

[PATCH v2] usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume

From: Sandeep Singh Certain HP keyboards would keep inputting a character automatically which is the wake-up key after S3 resume On some AMD platforms USB host fails to respond (by holding resume-K) to USB device (an HP keyboard) resume request within 1ms (TURSM) and

[PATCH 0/3] ARM: dts: k2g: Add support for USB instances on 66AK2G

Add support for 66AK2G usb instances. However, the driver needs to be updated to support PM_RUNTIME. This update has been validated to work on K2L and boot tested on K2HK and K2E. Franklin S Cooper Jr (2): usb: dwc3: keystone: Add PM_RUNTIME Support to DWC3 Keystone USB driver

[PATCH 2/3] dt-bindings: usb: keystone-usb: Update bindings pm and clocks properties

Update varous properties to properly indicate their requirement depending on the SoC. Signed-off-by: Franklin S Cooper Jr --- Documentation/devicetree/bindings/usb/keystone-usb.txt | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git

[PATCH 3/3] ARM: dts: k2g: Add USB instances

From: Vitaly Andrianov Add nodes for both USB instances supported by 66AK2G. [d-gerl...@ti.com: Add power domain and clock properties] Signed-off-by: Dave Gerlach [fcoo...@ti.com: Update commit message and subject] Signed-off-by: Franklin S Cooper Jr

[PATCH 1/3] usb: dwc3: keystone: Add PM_RUNTIME Support to DWC3 Keystone USB driver

For 66AK2Gx there is a requirement to use PM Runtime to properly manage clocks and the power domains. Therefore, add PM runtime support. Remove legacy clock api's calls since other users of this driver worked without these clock apis calls. Signed-off-by: Franklin S Cooper Jr

usb 3-1: 2:1: cannot get freq at ep 0x1

Hello, dmesg: [6.580403] usb 3-1: 2:1: cannot get freq at ep 0x1 [...] [6.630781] usb 3-1: Warning! Unlikely big volume range (=10361), cval->res is probably wrong. [6.630787] usb 3-1: [11] FU [Sidetone Playback Volume] ch = 1, val = 0/10361/1 [...] [ 12.291407] usb 3-1: 2:1:

RE: [PATCH] usb: gadget: fsl_qe_udc: constify qe_ep0_desc

> -Original Message- > From: Julia Lawall [mailto:julia.law...@lip6.fr] > Sent: Wednesday, August 02, 2017 10:29 AM > To: Leo Li > Cc: kernel-janit...@vger.kernel.org; Felipe Balbi ; Greg > Kroah-Hartman ;

Re: [PATCH 2/2] usb: qmi_wwan: add D-Link DWM-222 device ID

From: Hector Martin Date: Wed, 2 Aug 2017 00:45:44 +0900 > Signed-off-by: Hector Martin Applied. -- 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

Re: [PATCH v2 1/1] usbip: auto retry for concurrent attach

Hi Nobuo Iwata, Sorry for the delay. This one got lost in my Inbox. On 05/28/2017 08:31 PM, Nobuo Iwata wrote: > This patch adds recovery from false busy state on concurrent attach > operation. > > The procedure of attach operation is as below. > > 1) Find an unused port in

Re: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

> Johan Hovold hat am 2. August 2017 um 13:45 geschrieben: > > > On Wed, Aug 02, 2017 at 01:10:33PM +0200, Stefan Wahren wrote: > > Am 02.08.2017 um 09:03 schrieb Hans Verkuil: > > > When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel > > > I discovered that

Re: [PATCH 0/3] FPGA Manager support for FPP via FT232H FT245-FIFO

On Wed, Aug 02, 2017 at 05:30:36PM +0200, Eric Schwarz wrote: > Hello Alan, > > many thanks for your response. > Well, I am following the whole discussion from the very start and for my > taste it is too superficial - don't know whether this is the right wording. > Please get me right. We need

[PATCH] usb: gadget: fsl_qe_udc: constify qe_ep0_desc

qe_ep0_desc is only passed as the second argument to qe_ep_init, which is const, so qe_ep0_desc can be const too. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- I got a lot of warnings when compiling this file, but none seemed to be related to the

Re: [PATCH 0/3] FPGA Manager support for FPP via FT232H FT245-FIFO

Hello Alan, many thanks for your response. Well, I am following the whole discussion from the very start and for my taste it is too superficial - don't know whether this is the right wording. Please get me right. We need some kind of implementation specification or a sample way on how to

Re: Improve `ohci_pci_init()` time

On Wed, 2 Aug 2017, Greg KH wrote: > On Wed, Aug 02, 2017 at 02:17:42PM +0200, Paul Menzel wrote: > > Dear Linux folks, > > > > > > Trying to improve the start-up time of a (slow) ASRock E350M1 which already > > uses coreboot, when instrumenting the time of the Linux Kernel, execution of > >

Re: [PATCH 0/3] FPGA Manager support for FPP via FT232H FT245-FIFO

On Wed, Aug 2, 2017 at 6:36 AM, Eric Schwarz wrote: > Dear all, > > DENX Software Engineering develops and brings this driver to mainline on > behalf of us (ARRI*). > > Since there was a lot of discussion around this patch series I would highly > appreciate if someone

Re: Improve `ohci_pci_init()` time

On Wed, Aug 02, 2017 at 02:17:42PM +0200, Paul Menzel wrote: > Dear Linux folks, > > > Trying to improve the start-up time of a (slow) ASRock E350M1 which already > uses coreboot, when instrumenting the time of the Linux Kernel, execution of > `ohci_pci_init()` takes almost 200 ms. > > ``` >

Re: [PATCH 0/3] FPGA Manager support for FPP via FT232H FT245-FIFO

Dear all, DENX Software Engineering develops and brings this driver to mainline on behalf of us (ARRI*). Since there was a lot of discussion around this patch series I would highly appreciate if someone could sum up what needs to be changed in detail in order to get this driver into the

Improve `ohci_pci_init()` time

Dear Linux folks, Trying to improve the start-up time of a (slow) ASRock E350M1 which already uses coreboot, when instrumenting the time of the Linux Kernel, execution of `ohci_pci_init()` takes almost 200 ms. ``` […] [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-rc3+

[PATCH] usb: gadget: udc: renesas_usb3: Fix usb_gadget_giveback_request() calling

According to the gadget.h, a "complete" function will always be called with interrupts disabled. However, sometimes usb3_request_done() function is called with interrupts enabled. So, this function should be held by spin_lock_irqsave() to disable interruption. Also, this driver has to call

Re: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

On Wed, Aug 02, 2017 at 01:10:33PM +0200, Stefan Wahren wrote: > Am 02.08.2017 um 09:03 schrieb Hans Verkuil: > > When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel > > I discovered that there was no ethernet. After bisecting I got to commit > > 2bf69867 ('USB: of: fix root-hub

Re: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

On 02/08/17 12:10, Stefan Wahren wrote: > Am 02.08.2017 um 09:03 schrieb Hans Verkuil: >> When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel >> I discovered that there was no ethernet. After bisecting I got to commit >> 2bf69867 ('USB: of: fix root-hub device-tree node

Re: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

Am 02.08.2017 um 09:03 schrieb Hans Verkuil: > When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel > I discovered that there was no ethernet. After bisecting I got to commit > 2bf69867 ('USB: of: fix root-hub device-tree node handling'). > > With that commit lsusb outputs: > >

Re: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

On Wed, Aug 02, 2017 at 11:49:00AM +0200, Hans Verkuil wrote: > On 08/02/17 11:39, Johan Hovold wrote: > > On Wed, Aug 02, 2017 at 09:03:43AM +0200, Hans Verkuil wrote: > > Thanks for reporting this. At first glance, I fail to see how setting > > the device-node pointer for the root hub slightly

Re: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

On 08/02/17 11:39, Johan Hovold wrote: > On Wed, Aug 02, 2017 at 09:03:43AM +0200, Hans Verkuil wrote: >> When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel >> I discovered that there was no ethernet. After bisecting I got to commit >> 2bf69867 ('USB: of: fix root-hub device-tree

Re: Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

On Wed, Aug 02, 2017 at 09:03:43AM +0200, Hans Verkuil wrote: > When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel > I discovered that there was no ethernet. After bisecting I got to commit > 2bf69867 ('USB: of: fix root-hub device-tree node handling'). > > With that commit

[PATCH] usb: phy: phy-msm-usb: Fix usage of devm_regulator_bulk_get()

The regulator_bulk_data pointer passed to devm_regulator_bulk_get() is used to store the client handles for the regulators, which is later used by devm_regulator_bulk_release() to free the regulators. Passing a local array as is done here means the memory used to store the handles is freed causing

Rpi3: no ethernet in 4.13: bisected to patch 'USB: of: fix root-hub device-tree node handling'

When testing with my Raspberry Pi 3 and the 4.13-rcX mainline kernel I discovered that there was no ethernet. After bisecting I got to commit 2bf69867 ('USB: of: fix root-hub device-tree node handling'). With that commit lsusb outputs: rpi3: ~ # lsusb Bus 001 Device 001: ID 1d6b:0002 Linux