[PATCH v2] usb: chipidea: reuse the platform_data to store the ci info

From: Rong Wang Chipidea puts ci information to drvdata, but this overwrites the drvdata placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this from codes like ehci-sysfs.c: static ssize_t show_companion(struct device *dev,

Re: [PATCH V2] dummy_hcd: replace timeval with timespec64

On Thursday 17 September 2015 11:09:49 WEN Pingbo wrote: > The millisecond of the last second will be normal if tv_sec is > overflowed. But for y2038 consistency and demonstration purpose, > and avoiding further risks, we need to remove 'timeval' in this > driver, to avoid similair problems. > >

Re: [PATCH 2/2] mmc: vub300: Remove unneded semicolons

On 16 September 2015 at 11:30, Javier Martinez Canillas wrote: > They aren't needed and are just creating null statements so remove it. > > Signed-off-by: Javier Martinez Canillas Thanks, applied for next! Kind regards Uffe > > --- > >

Re: [PATCH v1 1/1] xhci: replace custom implementation of readq / writeq

On Thu, 2015-08-27 at 12:39 +0300, Andy Shevchenko wrote: > The readq() and writeq() helpers are available in the > asm-generic/io-64-nonatomic-hi-lo.h and asm-generic/io-64-nonatomic > -lo-hi.h > headers. Replace custom implementation by the generic helpers. > Mathias, any comments on this one?

Re: [PATCH V2] dummy_hcd: replace timeval with timespec64

WEN Pingbo wrote: > +++ b/drivers/usb/gadget/udc/dummy_hcd.c > @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = { > /* there are both host and device side versions of this call ... */ > static int dummy_g_get_frame(struct usb_gadget *_gadget) > { > - struct timeval tv; >

Re: [PATCH v1 1/1] xhci: replace custom implementation of readq / writeq

On 17.09.2015 12:23, Andy Shevchenko wrote: On Thu, 2015-08-27 at 12:39 +0300, Andy Shevchenko wrote: The readq() and writeq() helpers are available in the asm-generic/io-64-nonatomic-hi-lo.h and asm-generic/io-64-nonatomic -lo-hi.h headers. Replace custom implementation by the generic helpers.

Re: [PATCH V2] dummy_hcd: replace timeval with timespec64

On Thursday, September 17, 2015 05:59 PM, Peter Stuge wrote: > WEN Pingbo wrote: >> +++ b/drivers/usb/gadget/udc/dummy_hcd.c >> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = { >> /* there are both host and device side versions of this call ... */ >> static int

Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings

Hi Julia, W dniu 17.09.2015 o 10:57, Julia Lawall pisze: Coccinelle suggests the following patch. But the code is curious. Is the function expected to always return a failure value? Thank you for catching this. The function is not expected to always return a failure value. Fortunately it

Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings

> Fortunately it does not matter anyway because the return value > of the drop_link() operation is silently ignored by its caller in > fs/configfs/symlink.c, functions configfs_symlink() and configfs_unlink(). Should such an implementation detail be also reconsidered once more? Regards, Markus

RE: First kernel patch (optimization)

From: Jaime Arrocha > Sent: 17 September 2015 02:50 .. > One interesting observation I found was that in O0 and O2, it does make > a call to strlen while in O1 it calculates > the length of the string using: > You want an 'xor %rcx,%rcx' here. > repnz scas%es:(%rdi),%al > not

Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings

Coccinelle suggests the following patch. But the code is curious. Is the function expected to always return a failure value? thanks, julia On Thu, 17 Sep 2015, kbuild test robot wrote: > TO: Andrzej Pietrasiewicz > CC: kbuild-...@01.org > CC: Felipe Balbi

Re: Applying Patch to Change Max Packet Size for Device

On Wed, 16 Sep 2015, Todd Efflam wrote: > We were using EHCI with the 2.6.35 kernel. When disabling XHCI in > 3.14 and using EHCI the device still doesn't work however. > > The reason we are stuck with 3.14 is we use the Yocto build system and > their latest support is for 3.14. If the problem

[GIT PULL] USB-serial fixes for v4.3-rc2

Hi Greg, Here are a few new device IDs for v4.3-rc2. Thanks, Johan The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) are available in the git repository at:

Re: [GIT PULL] USB-serial fixes for v4.3-rc2

On Thu, Sep 17, 2015 at 06:08:55PM +0200, Johan Hovold wrote: > Hi Greg, > > Here are a few new device IDs for v4.3-rc2. > > Thanks, > Johan > > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in

Re: [PATCH 1/3] usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued

On Thu, Sep 17, 2015 at 11:42:38AM -0500, Felipe Balbi wrote: > Instead of clearing DWC3_PENDING_REQUEST when > we start transfer, let's do it when the request > is actually queued, that way we know for sure > that we're clearing in the right time. > > Signed-off-by: Felipe Balbi

[PATCH RESEND 2/4] usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued

Instead of clearing DWC3_PENDING_REQUEST when we start transfer, let's do it when the request is actually queued, that way we know for sure that we're clearing in the right time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+),

[PATCH RESEND 1/4] usb: dwc3: gadget: start requests as soon as they come

In an attempt to make dwc3 slightly faster, let's start usb_requests as soon as they come as that will let us avoid a XFER_NOT_READY event and save a little bit of time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 16 1 file changed, 16

Re: xhci woes continued

On Thu, 17 Sep 2015, Eugen Rogoza wrote: > > Also removing the XHCI_LPM_SUPPORT flag should do the trick, for example > > for Intel hosts: > > > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > > index 2be1b7b..8f2eafb 100644 > > --- a/drivers/usb/host/xhci-pci.c > >

[PATCH 2/3] usb: dwc3: gadget: improve ep_queue's error reporting

We shouldn't return -EBUSY, that's used only internally when the core still has transfers in flight on a given endpoint. Also, combine the error reporting so that we don't have to duplicate it. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 31

[PATCH 3/3] usb: gadget: mass_storage: allow for deeper queue lengths

Instead of allowing a range of 2 to 4 requests, let's allow the user choose up to 32 requests as that will give us a better chance of keeping controller busy. We still maintain default of 2 so users shouldn't be affected. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/Kconfig

[PATCH 1/3] usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued

Instead of clearing DWC3_PENDING_REQUEST when we start transfer, let's do it when the request is actually queued, that way we know for sure that we're clearing in the right time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+),

[PATCH RESEND 4/4] usb: gadget: mass_storage: allow for deeper queue lengths

Instead of allowing a range of 2 to 4 requests, let's allow the user choose up to 32 requests as that will give us a better chance of keeping controller busy. We still maintain default of 2 so users shouldn't be affected. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/Kconfig

[PATCH RESEND 3/4] usb: dwc3: gadget: improve ep_queue's error reporting

We shouldn't return -EBUSY, that's used only internally when the core still has transfers in flight on a given endpoint. Also, combine the error reporting so that we don't have to duplicate it. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 31

[PATCH v8 2/3] usb: Add support for ACPI identification to xhci-platform

Provide the methods to let ACPI identify the need to use xhci-platform. Change the Kconfig files so the xhci-plat.o file is selectable during kernel config. This has been tested on an ARM64 machine with platform XHCI, an x86_64 machine with XHCI, and an x86_64 machine without XHCI. There were no

[PATCH v8 3/3] usb: xhci: configure 32-bit DMA if the controller does not support 64-bit DMA

This change avoids DMA error in the cases where dma_mask and coherent_dma_mask of a 32-bit controller get configured as DMA_BIT_MASK(64) when running on a 64-bit system. Signed-off-by: Duc Dang --- drivers/usb/host/xhci.c | 10 ++ 1 file changed, 10 insertions(+) diff

[PATCH v8 1/3] usb: make xhci platform driver use 64 bit or 32 bit DMA

The xhci platform driver needs to work on systems that either only support 64-bit DMA or only support 32-bit DMA. Attempt to set a coherent dma mask for 64-bit DMA, and attempt again with 32-bit DMA if that fails. [dhdang: regenerate the patch over v4.3-rc1 and address new comments]

[PATCH v8 0/3] usb: xhci-platform: Configure 64-bit DMA mask if the platform is capable

The xhci platform driver does not work with system that only supports 64-bit DMA as it requests 32-bit DMA mask during driver initialization. This patch set addresses this issue and also adds XHCI-compliant USB Controller ACPI identification into xhci-platform driver. Changes from v7: -

Re: [PATCH v8 1/3] usb: make xhci platform driver use 64 bit or 32 bit DMA

On Thursday 17 September 2015 11:19:46 Duc Dang wrote: > The xhci platform driver needs to work on systems that > either only support 64-bit DMA or only support 32-bit DMA. > Attempt to set a coherent dma mask for 64-bit DMA, and > attempt again with 32-bit DMA if that fails. > > [dhdang:

Re: Applying Patch to Change Max Packet Size for Device

On Wed, Sep 16, 2015 at 8:27 PM, Todd Efflam wrote: > We were using EHCI with the 2.6.35 kernel. When disabling XHCI in > 3.14 and using EHCI the device still doesn't work however. > > The reason we are stuck with 3.14 is we use the Yocto build system and > their latest

Re: [PATCH v8 1/3] usb: make xhci platform driver use 64 bit or 32 bit DMA

On Thu, Sep 17, 2015 at 12:51 PM, Arnd Bergmann wrote: > On Thursday 17 September 2015 11:19:46 Duc Dang wrote: >> The xhci platform driver needs to work on systems that >> either only support 64-bit DMA or only support 32-bit DMA. >> Attempt to set a coherent dma mask for 64-bit

Re: [PATCH v1 02/32] usb: dwc2: host: create a function to handle port_resume

Hi, On Thu, Sep 17, 2015 at 12:41 PM, Doug Anderson wrote: >> + spin_unlock_irqrestore(>lock, flags); >> + >> + msleep(USB_RESUME_TIMEOUT); >> + >> + spin_lock_irqsave(>lock, flags); >> + hprt0 &= ~HPRT0_RES; >> + writel(hprt0, hsotg->regs +

Re: Applying Patch to Change Max Packet Size for Device

Thanks everyone. Here are some responses: On Wed, Sep 16, 2015 at 4:33 PM, Greg KH wrote: > Really? I thought you said the error was in the xhci driver, not ehci, > for 3.14. We tested with both and it failed with both, sorry for not being clear. > Can't you just plug your

Re: [PATCH v1 03/32] usb: dwc2: host: add flag to reflect bus state

Hi, On Wed, Sep 9, 2015 at 3:20 AM, Mian Yousaf Kaukab wrote: > /* Update lx_state */ > - hsotg->lx_state = DWC2_L2; > + hsotg->bus_suspended = 1; /* Update comment */ -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in

Re: Applying Patch to Change Max Packet Size for Device

On Thu, 17 Sep 2015, Todd Efflam wrote: > On Thu, Sep 17, 2015 at 8:49 AM, Alan Stern wrote: > > If the problem affects both the EHCI and xHCI controllers, why do you > > want to work around by changing only xhci-hcd? Wouldn't it be better > > to change the USB core?

Re: [PATCH v1 02/32] usb: dwc2: host: create a function to handle port_resume

Hi, On Wed, Sep 9, 2015 at 3:20 AM, Mian Yousaf Kaukab wrote: > From: Gregory Herrero > > port resume sequence may be used in different places. Create a > function to handle it. Moreover, make hprt0 read-modify-write atomic. > > Signed-off-by:

Re: [PATCH V5 1/1] usb:serial add Fintek F81532/534 driver

Johan Hovold 於 2015/9/14 下午 09:33 寫道: > On Tue, Jul 21, 2015 at 09:58:19AM +0800, Peter Hung wrote: >> This driver is for Fintek F81532/F81534 USB to Serial Ports IC. >> > So as I mentioned above, always accept data if there's room in the fifo. > Then kick of a write urb, if TX_EMPTY is set for

[PATCH V3] dummy_hcd: replace timeval with timespec64

The millisecond of the last second will be normal if tv_sec is overflowed. But for y2038 consistency and demonstration purpose, and avoiding further risks, we need to remove 'timeval' in this driver, to avoid similair problems. Signed-off-by: Pingbo Wen Reviewed-by: Arnd

Re: [PATCH v1 27/32] usb: dwc2: gadget: kill ep0 requests before reinitializing core

On 9/9/2015 3:21 AM, Mian Yousaf Kaukab wrote: > Make sure there are no requests pending on ep0 before reinitializing > core. Otherwise, dwc2_hsotg_enqueue_setup will fail afterwards. > > Signed-off-by: Mian Yousaf Kaukab > Tested-by: Robert Baldyga

Re: First kernel patch (optimization)

On Wed, Sep 16, 2015 at 01:26:51PM -0400, Josh Boyer wrote: > > That isn't true. It helps the submitter understand the workflow and > expectations. What you meant to say is that it doesn't help you. The problem is that workflow isn't the hard part. It's the part that can be taught most

Re: [PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

On Wed, Sep 16, 2015 at 08:54:25AM -0500, Rob Herring wrote: > On 09/15/2015 08:49 PM, Peter Chen wrote: > > Some SoCs needs three clock to let controller work, but others only > > need one, add one property to differentiate this. > > A given licensed IP block is going to have the same number of

Re: [PATCH v2] USB: EHCI: fix dereference of ERR_PTR

On Wed, Sep 16, 2015 at 12:54:03PM -0400, Alan Stern wrote: > On Wed, 16 Sep 2015, Sudip Mukherjee wrote: > > > On error find_tt() returns either a NULL pointer or the error value in > > ERR_PTR. But we were dereferencing it directly without even checking if > > find_tt() returned a valid pointer