Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo, On 01/26/2017 03:19 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Fair enough. >> >> USB connection is stable enough, unless the user unplugs the >> USB cable during debugging. > What does the hardware do in this case? The XHCI registers are in the host >

Re: Fwd: Regression: Line6 Toneport stops working on 4.10-rc5

On Thu, Jan 26, 2017 at 10:35:25AM +0300, Igor Zinovev wrote: > Hello! This is essentially a replay of > https://bugzilla.kernel.org/show_bug.cgi?id=193221 but sent to this > mailing list as recommended by Greg Kroah-Hartman. Please let me know > if I have missed something in this report. > > So

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

* Lu Baolu wrote: > > Hi, > > On 01/25/2017 10:38 PM, Peter Zijlstra wrote: > > On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote: > >> In my driver, udelay() is mostly used to handle time out. > >> > >> Xdbc hides most USB things in its firmware. Early printk

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

* Lu Baolu wrote: > Fair enough. > > USB connection is stable enough, unless the user unplugs the > USB cable during debugging. What does the hardware do in this case? The XHCI registers are in the host hardware, so they won't disappear, right? Is there some cable

RE: [PATCH net v3 0/4] r8152: fix scheduling napi

David Miller [mailto:da...@davemloft.net] > Sent: Thursday, January 26, 2017 11:48 AM [...] > Series applied. Thank you very much. I would try to find better way, too. Best Regards, Hayes -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to

Re: [PATCH net v3 0/4] r8152: fix scheduling napi

From: Hayes Wang Date: Thu, 26 Jan 2017 09:38:30 +0800 > v3: > simply the argument for patch #3. Replace >napi with napi. > > v2: > Add smp_mb__after_atomic() for patch #1. > > v1: > Scheduling the napi during the following periods would let it be ignored. > And the

Re: [PATCH net v2 0/4] r8152: fix scheduling napi

From: Hayes Wang Date: Thu, 26 Jan 2017 03:04:45 + > May you apply these patches first, until I find another way to replace > current one? Yes, I will. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi, On 01/26/2017 12:16 AM, Peter Zijlstra wrote: > On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote: > >>> What is timeout and why? >> Put it in simple: >> >> The driver sets the RUN bit in control register and polls READY >> bit in status register for the successful USB device

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi Ingo, On 01/25/2017 05:23 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >>> Hiding essentially an early udelay() implementation in an early-printk >>> driver is >>> ugly and counterproductive. >> Sure. How about below change? >> >> diff --git

RE: [PATCH net v2 0/4] r8152: fix scheduling napi

David Miller [mailto:da...@davemloft.net] > Sent: Thursday, January 26, 2017 3:31 AM [...] > I think the fundamental issue is that since you can't stop URBs from > queueing up, you cannot properly synchronize NAPI and schedule polling > properly. > > From my perspective what happened here is you

RE: NAPI on USB network drivers

Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Wednesday, January 25, 2017 10:13 PM [...] > You also could use napi_complete_done() instead of napi_complete(), as > it allows users to tune the performance vs latency for GRO. > > Looking at this driver, I do not see any limitation on the

[PATCH net v3 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit() from calling napi_schedule() directly during runtime suspend. After calling napi_disable() or clearing the flag of WORK_ENABLE, scheduling the napi is useless. Signed-off-by: Hayes Wang ---

[PATCH net v3 3/4] r8152: re-schedule napi for tx

Re-schedule napi after napi_complete() for tx, if it is necessay. In r8152_poll(), if the tx is completed after tx_bottom() and before napi_complete(), the scheduling of napi would be lost. Then, no one handles the next tx until the next napi_schedule() is called. Signed-off-by: Hayes Wang

[PATCH net v3 4/4] r8152: check rx after napi is enabled

Schedule the napi after napi_enable() for rx, if it is necessary. If the rx is completed when napi is disabled, the sheduling of napi would be lost. Then, no one handles the rx packet until next napi is scheduled. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 7

[PATCH net v3 0/4] r8152: fix scheduling napi

v3: simply the argument for patch #3. Replace >napi with napi. v2: Add smp_mb__after_atomic() for patch #1. v1: Scheduling the napi during the following periods would let it be ignored. And the events wouldn't be handled until next napi_schedule() is called. 1. after napi_disable and before

[PATCH net v3 2/4] r8152: avoid start_xmit to schedule napi when napi is disabled

Stop the tx when the napi is disabled to prevent napi_schedule() is called. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index

RE: [PATCH net v2 3/4] r8152: re-schedule napi for tx

Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Wednesday, January 25, 2017 9:57 PM [...] > > napi_complete(napi); > > if (!list_empty(>rx_done)) > > napi_schedule(napi); > > + else if (!skb_queue_empty(>tx_queue) && > > +

Re: [PATCH v2] usb: dwc3: handle DWC_USB3_NUM == DWC_USB3_NUM_IN_EPS

On 1/24/2017 3:14 PM, Bryan O'Donoghue wrote: > > > On 24/01/17 19:25, John Youn wrote: >> On 1/24/2017 3:05 AM, Bryan O'Donoghue wrote: >>> On 23/01/17 22:34, John Youn wrote: On 1/23/2017 2:10 PM, Alan Stern wrote: > On Mon, 23 Jan 2017, John Youn wrote: > >> On 1/22/2017 5:29

Re: [PATCH v2] usb: dwc2: fix "iomem 0x00000000" message

On 1/25/2017 2:14 PM, Heiner Kallweit wrote: > Set the iomem parameters in the usb_hcd to fix this misleading > message during driver load: > dwc2 c910.usb: irq 22, io mem 0x > > Signed-off-by: Heiner Kallweit > --- > v2: > - get info from hsotg->dev instead of

Re: [PATCH] usb: dwc2: eliminate irq parameter from dwc2_hcd_init

On 1/25/2017 2:14 PM, Heiner Kallweit wrote: > The irq is available in hsotg already, so there's no need to > pass it as separate function parameter. > > Signed-off-by: Heiner Kallweit > --- > drivers/usb/dwc2/core.h | 2 +- > drivers/usb/dwc2/hcd.c | 4 ++-- >

[PATCH v8 2/3] phy: Add support for Qualcomm's USB HSIC phy

The HSIC USB controller on qcom SoCs has an integrated all digital phy controlled via the ULPI viewport. Cc: Kishon Vijay Abraham I Acked-by: Rob Herring Cc: Signed-off-by: Stephen Boyd ---

[PATCH v8 0/3] Support qcom's HSIC USB and rewrite USB2 HS support

This patch series continues the usb chipidea rewrite for Qualcommm platforms. I've dropped the patches that were applied to Peter's tree for chipidea. Now the phy drivers are left, along with the patch to call phy_set_mode() at the right place. I've left the HSIC phy driver here, because it

[PATCH v8 1/3] usb: chipidea: Configure phy for appropriate mode

When the qcom chipidea controller is used with an extcon, we need to signal device mode or host mode to the phy so it can configure itself for the correct mode. This should be done after the phy is powered up, so that the register writes work correctly. Add in the appropriate phy_set_mode() call

[PATCH] usb: phy: ab8500: remove unused ab8500_eyediagram_workaroud()

The only caller of this function is gone, so now we get a warning: drivers/usb/phy/phy-ab8500-usb.c:1026:17: error: 'ab8500_eyediagram_workaroud' defined but not used [-Werror=unused-function] It is possible that we should in fact still call the function from somewhere else, but I don't see

[PATCH] usb: dwc2: eliminate irq parameter from dwc2_hcd_init

The irq is available in hsotg already, so there's no need to pass it as separate function parameter. Signed-off-by: Heiner Kallweit --- drivers/usb/dwc2/core.h | 2 +- drivers/usb/dwc2/hcd.c | 4 ++-- drivers/usb/dwc2/hcd.h | 2 +- drivers/usb/dwc2/platform.c

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

Am 25.01.2017 um 22:28 schrieb John Youn: > On 1/15/2017 12:37 PM, Heiner Kallweit wrote: >> Set the iomem parameters in the usb_hcd to fix this misleading >> message during driver load: >> dwc2 c910.usb: irq 22, io mem 0x >> >> Signed-off-by: Heiner Kallweit >>

[PATCH v2] usb: dwc2: fix "iomem 0x00000000" message

Set the iomem parameters in the usb_hcd to fix this misleading message during driver load: dwc2 c910.usb: irq 22, io mem 0x Signed-off-by: Heiner Kallweit --- v2: - get info from hsotg->dev instead of adding a function parameter --- drivers/usb/dwc2/hcd.c | 7

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

On 1/15/2017 12:37 PM, Heiner Kallweit wrote: > Set the iomem parameters in the usb_hcd to fix this misleading > message during driver load: > dwc2 c910.usb: irq 22, io mem 0x > > Signed-off-by: Heiner Kallweit > --- > drivers/usb/dwc2/core.h | 3 ++- >

Re: [PATCH] usb: musb: constify musb_hdrc_config structures

On Wed, Jan 25, 2017 at 10:58:15AM -0600, Bin Liu wrote: > On Wed, Jan 25, 2017 at 12:52:22AM +0530, Bhumika Goyal wrote: > > Declare musb_hdrc_config structures as const as they are only stored in > > the config field of a musb_hdrc_platform_data structure. This field is of > > type const, so

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

On 1/25/2017 12:37 PM, Heiner Kallweit wrote: > Am 24.01.2017 um 09:46 schrieb Felipe Balbi: >> >> Hi, >> >> John Youn writes: John Youn writes: > @@ -1229,7 +1229,8 @@ static inline void dwc2_hcd_connect(struct > dwc2_hsotg

Re: [PATCH 2/2] USB: serial: drop unused ASYNC flags

On Wed, Jan 25, 2017 at 06:22:54PM +0100, Johan Hovold wrote: > Do not report ASYNC_SKIP_TEST or ASYNC_AUTO_IRQ as being set in > TIOCGSERIAL handlers as these flags are not supported and do not really > make any sense for USB serial devices in the first place. > > Signed-off-by: Johan Hovold

Re: [PATCH 1/2] USB: serial: ftdi_sio: clean up ioctl handler

On Wed, Jan 25, 2017 at 06:22:53PM +0100, Johan Hovold wrote: > Clean up the ioctl handler and make sure to pass an unsigned-int rather > than serial_struct pointer to the TIOCSERGETLSR helper as this it what > the user argument really is. > > Signed-off-by: Johan Hovold > ---

[PATCH] usb: gadget: udc: fsl: Add missing complete function.

Commit 304f7e5e1d08 ("usb: gadget: Refactor request completion") removed check if req->req.complete is non-NULL, resulting in a NULL pointer derefence and a kernel panic. This patch adds an empty complete function instead of re-introducing the req->req.complete check. Fixes: 304f7e5e1d08 ("usb:

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/25/2017 10:03 AM, Rafał Miłecki wrote: > On 21 January 2017 at 22:42, Jacek Anaszewski > wrote: >> On 01/21/2017 05:24 PM, Rafał Miłecki wrote: >>> On 20 January 2017 at 23:35, Jacek Anaszewski >>> wrote: On 01/20/2017 10:56 PM,

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/25/2017 10:08 AM, Rafał Miłecki wrote: > On 01/23/2017 05:45 PM, Rob Herring wrote: >> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote: >>> Hi Rafał, >>> >>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote: From: Rafał Miłecki Some LEDs can be

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/25/2017 10:18 AM, Rafał Miłecki wrote: > On 01/23/2017 09:51 PM, Jacek Anaszewski wrote: >> On 01/23/2017 05:45 PM, Rob Herring wrote: >>> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote: Hi Rafał, On 01/20/2017 10:56 PM, Rafał Miłecki wrote: > From: Rafał

Re: NAPI on USB network drivers

On Wed, Jan 25, 2017 at 5:33 AM, Oliver Hartkopp wrote: > On 01/25/2017 10:39 AM, Hayes Wang wrote: >> >> Oliver Neukum [mailto:oneu...@suse.com] >>> >>> Sent: Wednesday, January 25, 2017 5:35 PM >> >> [...] >>> >>> looking at r8152 I noticed that it uses NAPI. I never

[PATCH v6] USB: serial: Add uPD78F0730 USB to Serial Adaptor Driver

The adaptor can be found on development boards for 78k, RL78 and V850 microcontrollers produced by Renesas Electronics Corporation. This is not a full-featured USB to serial converter, however it allows basic communication and simple control which is enough for programming of on-board flash and

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

Am 24.01.2017 um 09:46 schrieb Felipe Balbi: > > Hi, > > John Youn writes: >>> John Youn writes: @@ -1229,7 +1229,8 @@ static inline void dwc2_hcd_connect(struct dwc2_hsotg *hsotg) {} static inline void

[RESEND][PATCH] media/usb: Fix pctv452e

I sent this 9 days ago but got no answer. Is anything wrong with this patch? Commit 73d5c5c864f40 made sure that media/usb drivers don't do DMA on stack. That made pctv452e oops while initialising: [...] BUG: unable to handle kernel NULL pointer dereference at (null) [...] [

Re: NAPI on USB network drivers

From: Oliver Neukum Date: Wed, 25 Jan 2017 10:34:41 +0100 > looking at r8152 I noticed that it uses NAPI. I never considered > this for the generic USB networking code as you cannot disable > interrupts for USB. Is it still worth it? What are the benefits? I think it's not a

Re: [PATCH net v2 0/4] r8152: fix scheduling napi

From: Hayes Wang Date: Wed, 25 Jan 2017 16:13:17 +0800 > v2: > Add smp_mb__after_atomic() for patch #1. > > v1: > Scheduling the napi during the following periods would let it be ignored. > And the events wouldn't be handled until next napi_schedule() is called. > > 1.

Re: [PATCH v5] USB: Add uPD78F0730 USB to Serial Adaptor Driver

Hi Johan, > You made some further changes than what I suggested but forgot to > document those. Often better to explicitly list the changes made rather > than refer to review comments this way. Sorry for that, I'll try to describe changes more verbosely. > > + if (res < 0) > > +

Re: [PATCH -next] usb: chipidea: msm: Fix return value check in ci_hdrc_msm_probe()

Quoting Wei Yongjun (2017-01-25 06:02:48) > From: Wei Yongjun > > In case of error, the function devm_ioremap_resource() returns ERR_PTR() > and never returns NULL. The NULL test in the return value check should > be replaced with IS_ERR(). > > Fixes: 2fc305be364e ("usb:

Re: [PATCHv15 2/3] usb: USB Type-C connector class

On Mon, Jan 23, 2017 at 04:44:23PM +0200, Felipe Balbi wrote: > > Hi, > > Heikki Krogerus writes: > > +static void typec_report_identity(struct device *dev) > > +{ > > + sysfs_notify(>kobj, "identity", "id_header"); > > + sysfs_notify(>kobj, "identity",

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

Hi Krzysztof, On 25 January 2017 at 19:47, Krzysztof Kozlowski wrote: > On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski > wrote: >> Hi Krzysztof, >> >> On 2017-01-25 08:55, Krzysztof Kozlowski wrote: >>> >>> On Wed, Jan 25, 2017 at 7:51 AM, Anand

Re: [PATCH net-next] r8152: fix the wrong spelling

From: Hayes Wang Date: Wed, 25 Jan 2017 13:41:45 +0800 > Replace rumtime with runtime. > > Signed-off-by: Hayes Wang Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to

[PATCH i-g-t v7 0/1] usb: xhci: plat: Enable runtime PM

This series enables runtime PM and asynchronous resume/suspend support for xhci-plat devices. Due to Baolin Wangs series[1] part 1/2 of this series is now dropped. [1] https://lkml.org/lkml/2016/12/13/32 Andrew Bresticker (1): usb: xhci: plat: Enable async suspend/resume

[PATCH i-g-t v7 1/1] usb: xhci: plat: Enable async suspend/resume

From: Andrew Bresticker USB host controllers can take a significant amount of time to suspend and resume, adding several hundred miliseconds to the kernel resume time. Since the XHCI controller has no outside dependencies (other than clocks, which are suspended

Re: [PATCH v5 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume

Looks good to me. Feel free to add my r-b. Rob. On 2016-12-13 02:49 AM, Baolin Wang wrote: For some mobile devices with strict power management, we also want to suspend the host when the slave is detached for power saving. Thus we add the host suspend/resume functions to support this

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

Looks good to me. Feel free to add my r-b. On 2016-12-13 02:49 AM, Baolin Wang wrote: Enable the xhci plat runtime PM for parent device to suspend/resume xhci. Also call pm_runtime_get_noresume() in probe() function in case the parent device doesn't call suspend/resume callback by runtime PM

[PATCH 1/2] USB: serial: ftdi_sio: clean up ioctl handler

Clean up the ioctl handler and make sure to pass an unsigned-int rather than serial_struct pointer to the TIOCSERGETLSR helper as this it what the user argument really is. Signed-off-by: Johan Hovold --- drivers/usb/serial/ftdi_sio.c | 19 +++ 1 file changed, 7

[PATCH 2/2] USB: serial: drop unused ASYNC flags

Do not report ASYNC_SKIP_TEST or ASYNC_AUTO_IRQ as being set in TIOCGSERIAL handlers as these flags are not supported and do not really make any sense for USB serial devices in the first place. Signed-off-by: Johan Hovold --- drivers/usb/serial/io_edgeport.c | 1 -

[PATCH] USB: cdc-acm: fix TIOCGSERIAL flags

The driver reports that it always uses a low-latency mode by returning the ASYNC_LOW_LATENCY flag through TIOCGSERIAL. Even if this behaviour could not be changed, this may have made some sense prior to 7a9a65ced11e ("cdc-acm: Fix long standing abuse of tty->low_latency") which removed the

Re: [PATCH] usb: musb: constify musb_hdrc_config structures

On Wed, Jan 25, 2017 at 12:52:22AM +0530, Bhumika Goyal wrote: > Declare musb_hdrc_config structures as const as they are only stored in > the config field of a musb_hdrc_platform_data structure. This field is of > type const, so musb_hdrc_config structures having this property can be > made const

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote: > > What is timeout and why? > > Put it in simple: > > The driver sets the RUN bit in control register and polls READY > bit in status register for the successful USB device enumeration. > As the USB device enumeration might fail and the

Re: [PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

On Wed, Jan 25, 2017 at 04:42:01PM +0100, Greg Kroah-Hartman wrote: > On Wed, Jan 25, 2017 at 04:14:36PM +0100, Johan Hovold wrote: > > On Wed, Jan 25, 2017 at 04:06:47PM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Jan 25, 2017 at 03:35:20PM +0100, Johan Hovold wrote: > > > > Since commit

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi, On 01/25/2017 10:38 PM, Peter Zijlstra wrote: > On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote: >> In my driver, udelay() is mostly used to handle time out. >> >> Xdbc hides most USB things in its firmware. Early printk driver only needs >> to setup the registers/data structures

Re: [PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

On Wed, Jan 25, 2017 at 04:14:36PM +0100, Johan Hovold wrote: > On Wed, Jan 25, 2017 at 04:06:47PM +0100, Greg Kroah-Hartman wrote: > > On Wed, Jan 25, 2017 at 03:35:20PM +0100, Johan Hovold wrote: > > > Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY > > > flag") the FTDI driver

RE: [PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

From: Johan Hovold > Sent: 25 January 2017 14:35 > Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY > flag") the FTDI driver has been using a receive latency-timer value of > 1 ms instead of the device default of 16 ms. > > The latency timer is used to periodically empty a

Re: [PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

On Wed, Jan 25, 2017 at 04:06:47PM +0100, Greg Kroah-Hartman wrote: > On Wed, Jan 25, 2017 at 03:35:20PM +0100, Johan Hovold wrote: > > Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY > > flag") the FTDI driver has been using a receive latency-timer value of > > 1 ms instead of

Re: [PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

On Wed, Jan 25, 2017 at 03:35:20PM +0100, Johan Hovold wrote: > Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY > flag") the FTDI driver has been using a receive latency-timer value of > 1 ms instead of the device default of 16 ms. > > The latency timer is used to periodically

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote: > In my driver, udelay() is mostly used to handle time out. > > Xdbc hides most USB things in its firmware. Early printk driver only needs > to setup the registers/data structures and wait until link ready or time out. > Without udelay(),

[PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag") the FTDI driver has been using a receive latency-timer value of 1 ms instead of the device default of 16 ms. The latency timer is used to periodically empty a non-full receive buffer, but a status header is always sent when

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski wrote: > Hi Krzysztof, > > On 2017-01-25 08:55, Krzysztof Kozlowski wrote: >> >> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon wrote: >>> >>> On 24 January 2017 at 19:18, Richard Genoud

Re: NAPI on USB network drivers

On Wed, 2017-01-25 at 09:39 +, Hayes Wang wrote: > Oliver Neukum [mailto:oneu...@suse.com] > > Sent: Wednesday, January 25, 2017 5:35 PM > [...] > > looking at r8152 I noticed that it uses NAPI. I never considered > > this for the generic USB networking code as you cannot disable > >

[PATCH -next] usb: chipidea: msm: Fix return value check in ci_hdrc_msm_probe()

From: Wei Yongjun In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 2fc305be364e ("usb: chipidea: msm: Mux over secondary phy at the right

Re: [PATCH net v2 3/4] r8152: re-schedule napi for tx

On Wed, 2017-01-25 at 16:13 +0800, Hayes Wang wrote: > Re-schedule napi after napi_complete() for tx, if it is necessay. > > In r8152_poll(), if the tx is completed after tx_bottom() and before > napi_complete(), the scheduling of napi would be lost. Then, no > one handles the next tx until the

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

Hi Krzysztof, On 2017-01-25 08:55, Krzysztof Kozlowski wrote: On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon wrote: On 24 January 2017 at 19:18, Richard Genoud wrote: Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"), the

Re: NAPI on USB network drivers

On 01/25/2017 10:39 AM, Hayes Wang wrote: Oliver Neukum [mailto:oneu...@suse.com] Sent: Wednesday, January 25, 2017 5:35 PM [...] looking at r8152 I noticed that it uses NAPI. I never considered this for the generic USB networking code as you cannot disable interrupts for USB. Is it still

Re: [PATCH 1/2] usb: musb: Fix host mode error -71 regression

On Wed, Jan 25, 2017 at 02:17:11PM +0100, Greg KH wrote: > On Wed, Jan 25, 2017 at 06:59:47AM -0600, Bin Liu wrote: > > On Wed, Jan 25, 2017 at 11:01:30AM +0100, Greg KH wrote: > > > On Tue, Jan 24, 2017 at 09:18:57AM -0600, Bin Liu wrote: > > > > From: Tony Lindgren > > > > >

Re: [PATCH 1/2] usb: musb: Fix host mode error -71 regression

On Wed, Jan 25, 2017 at 06:59:47AM -0600, Bin Liu wrote: > On Wed, Jan 25, 2017 at 11:01:30AM +0100, Greg KH wrote: > > On Tue, Jan 24, 2017 at 09:18:57AM -0600, Bin Liu wrote: > > > From: Tony Lindgren > > > > > > Commit 467d5c980709 ("usb: musb: Implement session bit based

Re: [PATCH 1/2] usb: musb: Fix host mode error -71 regression

On Wed, Jan 25, 2017 at 11:01:30AM +0100, Greg KH wrote: > On Tue, Jan 24, 2017 at 09:18:57AM -0600, Bin Liu wrote: > > From: Tony Lindgren > > > > Commit 467d5c980709 ("usb: musb: Implement session bit based runtime PM for > > musb-core") started implementing musb generic

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi, On 01/25/2017 05:57 PM, Peter Zijlstra wrote: > On Wed, Jan 25, 2017 at 10:23:55AM +0100, Ingo Molnar wrote: >> * Lu Baolu wrote: >> Hiding essentially an early udelay() implementation in an early-printk driver is ugly and counterproductive. >> Yeah

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi, On 01/25/2017 05:23 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >>> Hiding essentially an early udelay() implementation in an early-printk >>> driver is >>> ugly and counterproductive. >> Sure. How about below change? >> >> diff --git

[PATCH v3] ARM: davinci: Make the usb20 clock available to PM runtime

Since USB20 subsystem uses just one clock, there is no need of a con_id, so we are using NULL. Signed-off-by: Alexandre Bailon Suggested-by: Sekhar Nori --- arch/arm/mach-davinci/da830.c | 2 +- arch/arm/mach-davinci/da850.c | 2 +-

RE: [PATCH v2 28/37] usb: host: xhci: combine event TRB completion debugging messages

From: Janusz Dziedzic > Sent: 24 January 2017 12:06 > On 23 January 2017 at 13:20, Mathias Nyman > wrote: > > From: Felipe Balbi > > > > If we just provide a helper to convert completion code to string, we can > > combine all debugging

Re: usb: gadget: Kernel panic (NULL pointer dereference) when using fsl_udc2_core on i.MX31 PDK

Hi, Magnus Lilja writes: > I tried the fsl_udc_core gadget driver on the i.MX31 PDK board and > got a > kernel panic (NULL pointer dereference) when connecting the USB > cable. I > had the g_serial module loaded as well.

Re: [PATCHv15 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

Hi, Heikki Krogerus writes: >> Heikki Krogerus writes: >> >> > + wcove->cap.prefer_role = TYPEC_NO_PREFERRED_ROLE; >> >> >> >> we have a slight problem here that affects users of this particular >> >> driver. Well, more

[PATCH v3] usb: dwc3: gadget: read IN ep FIFO size from HW

Instead of assuming all IN endpoints support 1024 bytes, let's read the actual value from HW and pass that to gadget API. Signed-off-by: Felipe Balbi --- changes since v2: - Actually commit "ret" variable :-s changes since v1: - Fix a bug where we

Re: [PATCHv15 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

On Wed, Jan 25, 2017 at 12:27:28PM +0200, Felipe Balbi wrote: > > Hi, > > Heikki Krogerus writes: > >> > +wcove->cap.prefer_role = TYPEC_NO_PREFERRED_ROLE; > >> > >> we have a slight problem here that affects users of this particular > >> driver. Well,

Re: [PATCH v3 00/24] usb: dwc2: Rework params, FIFO, and other changes

Hi, John Youn writes: > On 1/23/2017 2:52 PM, John Youn wrote: >> Hi Felipe, >> >> This is a consolidation, rebase, and resend of several dwc2 patch >> series that were submitted to this list in the past month or so. See >> v2 [1] of this series for a summary. >> >> This

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

Hi, Vincent Pelletier writes: > Hello, > > On Tue, 24 Jan 2017 11:02:10 +0200, Felipe Balbi > wrote: >> that's correct. Maybe I should always set bulk capability. Thanks for >> catching that, I'll send v2 shortly. > > I just tested v2 from

[PATCH v2] usb: dwc3: gadget: read IN ep FIFO size from HW

Instead of assuming all IN endpoints support 1024 bytes, let's read the actual value from HW and pass that to gadget API. Signed-off-by: Felipe Balbi --- changes since v1: - Fix a bug where we weren't setting endpoints.ops nor addding EP to

[PATCH v5 0/5] usb: musb: da8xx: Add DMA support

This series update MUSB driver to add DMA support to DA8xx. It should be applied on top of "[PATCH v3 0/3] usb: musb: cppi41: Add a way to manage DMA irq" but "[PATCH v3 0/3] dmaengine: cppi41: Add dma support to da8xx" and "[PATCH] arm: davinci: Make the usb20 clock available to PM runtime" are

[PATCH v5 1/5] usb: musb: da8xx: Remove CPPI 3.0 quirk and methods

DA8xx driver is registering and using the CPPI 3.0 DMA controller but actually, the DA8xx has a CPPI 4.1 DMA controller. Remove the CPPI 3.0 quirk and methods. Fixes: f8e9f34f80a2 ("usb: musb: Fix up DMA related macros") Fixes: 7f6283ed6fe8 ("usb: musb: Set up function pointers for DMA")

[PATCH v5 2/5] usb: musb: Use shared irq

In the DA8xx, USB and CPPI 4.1 are sharing the same interrupt line. Update the driver to request a shared irq. Signed-off-by: Alexandre Bailon --- drivers/usb/musb/musb_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_core.c

[PATCH v5 4/5] usb: musb: musb_cppi41: Workaround DMA stall issue during teardown

The DMA may hang up if a teardown is initiated while an endpoint is still active (Advisory 2.3.27 of DA8xx errata). To workaround this issue, add a delay before to initiate the teardown. Signed-off-by: Alexandre Bailon --- drivers/usb/musb/da8xx.c | 2 +-

[PATCH v5 3/5] usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx

Currently, only the PIO mode is supported. This add support of CPPI 4.1 to DA8xx. As the In DA8xx the CPPI 4.1 DMA is a part of the USB. Create the CPPI 4.1 device as a child of USB. Signed-off-by: Alexandre Bailon --- drivers/usb/musb/Kconfig | 4 ++--

[PATCH v5 5/5] usb: musb: da8xx: Add a primary support of PM runtime

Currently, MUSB DA8xx glue driver doesn't have PM runtime support. Because the CPPI 4.1 is using the same clock as MUSB DA8xx and CPPI 4.1 is a child of MUSB DA8xx glue, add support of PM runtime to the DA8xx glue driver in order to let the CPPI 4.1 driver manage the clock by using PM runtime.

Re: [PATCHv15 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

Hi, Heikki Krogerus writes: >> > + wcove->cap.prefer_role = TYPEC_NO_PREFERRED_ROLE; >> >> we have a slight problem here that affects users of this particular >> driver. Well, more specifically, it affects Intel Joule. >> >> Because of the way ASL was written

[PATCH v5 2/6] usb: musb: cppi41: Detect aborted transfers in cppi41_dma_callback()

Update cppi41_dma_callback() to detect an aborted transfer. This was not required before because cppi41_dma_callback() was only invoked on transfer completion. In order to make CPPI 4.1 driver more generic, cppi41_dma_callback() will be invoked after a transfer abort in order to let the MUSB

[PATCH v5 1/6] usb: musb: dma: Add a DMA completion platform callback

Currently, the CPPI 4.1 driver is not completely generic and only works on DSPS. This is because of IRQ management. Add a callback to dma_controller that could be invoked on DMA completion to acknowledge the IRQ. Signed-off-by: Alexandre Bailon ---

[PATCH v5 4/6] usb: musb: cppi_dma: Clean up cppi41_dma_controller structure

A pointer to musb is now present in the dma_controller structure. Remove the one present in cppi41_dma_controller structure. Signed-off-by: Alexandre Bailon --- drivers/usb/musb/musb_cppi41.c | 29 + 1 file changed, 13 insertions(+), 16

[PATCH v5 5/6] usb: musb: cppi_dma: Clean up tusb_omap_dma structure

A pointer to musb is now present in the dma_controller structure. Remove the one present in tusb_omap_dma structure. Signed-off-by: Alexandre Bailon --- drivers/usb/musb/tusb6010_omap.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[PATCH v5 3/6] usb: musb: cppi_dma: Clean up cppi structure

A pointer to musb is now present in the dma_controller structure. Remove the one present in cppi structure. Signed-off-by: Alexandre Bailon --- drivers/usb/musb/cppi_dma.c | 26 +- drivers/usb/musb/cppi_dma.h | 1 - 2 files changed, 13

[PATCH v5 0/6] usb: musb: cppi41: Add a way to manage DMA irq

This series was "dmaengine: cppi41: Make the driver more generic". I have tried to separate as munch I could CPPI 4.1 MUSB driver changes. Currently, the DMA interrupt is managed by the CPPI 4.1 driver. The issue here is the CPPI 4.1 driver must access to MUSB glue registers to manage its

[PATCH v5 6/6] usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPS

Despite the CPPI 4.1 is a generic DMA, it is tied to USB. On the DSPS, CPPI 4.1 interrupt's registers are in USBSS (the MUSB glue). Currently, to enable / disable and clear interrupts, the CPPI 4.1 driver maps and accesses to USBSS's register, which making CPPI 4.1 driver not really generic. Move

Re: [PATCH 1/2] usb: musb: Fix host mode error -71 regression

On Tue, Jan 24, 2017 at 09:18:57AM -0600, Bin Liu wrote: > From: Tony Lindgren > > Commit 467d5c980709 ("usb: musb: Implement session bit based runtime PM for > musb-core") started implementing musb generic runtime PM support by > introducing devctl register session bit based

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

On Wed, Jan 25, 2017 at 10:23:55AM +0100, Ingo Molnar wrote: > > * Lu Baolu wrote: > > > > Hiding essentially an early udelay() implementation in an early-printk > > > driver is > > > ugly and counterproductive. > Yeah - so could we do this in a more generic

  1   2   >