Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt

Hi Felipe, On 4/10/2017 12:04 AM, Felipe Balbi wrote: Hi again, Felipe Balbi writes: Thinh Nguyen writes: This patch fixes a commit that causes a hang from device waiting for data with the wrong sequence number. The commit ffb80fc672c3 ("usb:

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On 4/10/2017 12:31 PM, Paul E. McKenney wrote: On Mon, Apr 10, 2017 at 03:00:34PM -0400, Alan Stern wrote: On Mon, 10 Apr 2017, Paul E. McKenney wrote: The ordering with current->state is sadly not relevant because it is only touched if wake_up() actually wakes the process up. Well, it is

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On Mon, Apr 10, 2017 at 03:00:34PM -0400, Alan Stern wrote: > On Mon, 10 Apr 2017, Paul E. McKenney wrote: > > > > > The ordering with current->state is sadly not relevant because it is > > > > only touched if wake_up() actually wakes the process up. > > > > > > Well, it is _written_ only if

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

On 04/09/2017 11:59 PM, Felipe Balbi wrote: > > Hi, > > Thinh Nguyen writes: >> The dwc3 driver can overwite its previous events if its top half IRQ >> handler gets invoked again before processing the events in the cache. We > > interrupts are masked, why would top half

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On Mon, 10 Apr 2017, Paul E. McKenney wrote: > > > The ordering with current->state is sadly not relevant because it is > > > only touched if wake_up() actually wakes the process up. > > > > Well, it is _written_ only if wake_up() actually wakes the process up. > > But it is _read_ in every

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

On 04/08/2017 12:38 PM, Janusz Dziedzic wrote: > 2017-04-08 1:57 GMT+02:00 Thinh Nguyen : >> The dwc3 driver can overwite its previous events if its top half IRQ >> handler gets invoked again before processing the events in the cache. We >> see this as a hang in the file

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On Mon, Apr 10, 2017 at 01:48:13PM -0400, Alan Stern wrote: > On Mon, 10 Apr 2017, Paul E. McKenney wrote: > > > On Mon, Apr 10, 2017 at 12:20:53PM -0400, Alan Stern wrote: > > > On Mon, 10 Apr 2017, Paul E. McKenney wrote: > > > > > > > > But I would like to get this matter settled first. Is

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On Mon, 10 Apr 2017, Paul E. McKenney wrote: > On Mon, Apr 10, 2017 at 12:20:53PM -0400, Alan Stern wrote: > > On Mon, 10 Apr 2017, Paul E. McKenney wrote: > > > > > > But I would like to get this matter settled first. Is the explicit > > > > barrier truly necessary? > > > > > > If you are

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On Mon, Apr 10, 2017 at 12:20:53PM -0400, Alan Stern wrote: > On Mon, 10 Apr 2017, Paul E. McKenney wrote: > > > > But I would like to get this matter settled first. Is the explicit > > > barrier truly necessary? > > > > If you are using wait_event()/wake_up() or friends, the explicit > >

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On Mon, 10 Apr 2017, Paul E. McKenney wrote: > > But I would like to get this matter settled first. Is the explicit > > barrier truly necessary? > > If you are using wait_event()/wake_up() or friends, the explicit > barrier -is- necessary. To see this, look at v4.10's wait_event(): > >

Re: [PATCH 1/1] usb: ehci: put wmb at the end sitd/itd_link memory access

On Mon, 10 Apr 2017, pierre kuo wrote: > hi Alan Hello. > >> > If you need to flush something, wmb() is the wrong primitive. > >> > It merely ensures ordering. It is not guaranteed to flush writes > >> Not guaranteed to flush writes?that makes me curious. > >> As far as I know, wmb() make sure

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On Mon, Apr 10, 2017 at 11:01:59AM -0400, Alan Stern wrote: > On Mon, 10 Apr 2017, Felipe Balbi wrote: > > > Hi, > > > > Thinh Nguyen writes: > > > f_mass_storage has a memorry barrier issue with the sleep and wake > > > functions that can cause a deadlock. This

[PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

Telit LE920A4 uses the same pid 0x1201 of LE920, but modem implementation is different, since it requires DTR to be set for answering to qmi messages. This patch replaces QMI_FIXED_INTF with QMI_QUIRK_SET_DTR: tests on LE920 have been performed in order to verify backward compatibility.

Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

On Mon, 10 Apr 2017, Felipe Balbi wrote: > Hi, > > Alan Stern writes: > > On Wed, 5 Apr 2017, Felipe Balbi wrote: > > > >> >> >> --- a/drivers/usb/gadget/udc/core.c > >> >> >> +++ b/drivers/usb/gadget/udc/core.c > >> >> >> @@ -1273,6 +1273,7 @@ void

Re: [PATCH 1/1] usb: ehci: put wmb at the end sitd/itd_link memory access

hi Alan >> > If you need to flush something, wmb() is the wrong primitive. >> > It merely ensures ordering. It is not guaranteed to flush writes >> Not guaranteed to flush writes?that makes me curious. >> As far as I know, wmb() make sure any write operation before the wmb() >> is completed and

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

On Mon, 10 Apr 2017, Felipe Balbi wrote: > Hi, > > Thinh Nguyen writes: > > f_mass_storage has a memorry barrier issue with the sleep and wake > > functions that can cause a deadlock. This results in intermittent hangs > > during MSC file transfer. The host will reset

Re: [PATCH] smsc95xx: Add comments to the registers definition

Hi Martin > @@ -2032,7 +2032,7 @@ static struct sk_buff *smsc95xx_tx_fixup(struct usbnet > *dev, > skb_push(skb, 4); > tx_cmd_b = (u32)(skb->len - 4); > if (csum) > - tx_cmd_b |= TX_CMD_B_CSUM_ENABLE; > + tx_cmd_b |= TX_CMD_B_CSUM_EN; This changed seems

Re: [PATCH] usb: dwc3: gadget: delay unmap of bounced requests

Hi, Sekhar Nori writes: >> Roger Quadros writes: From: Janusz Dziedzic In the case of bounced ep0 requests, we must delay DMA operation until after ->complete() otherwise we might overwrite contents of req->buf.

Re: [PATCH] usb: dwc3: gadget: delay unmap of bounced requests

Hi Felipe, On Monday 10 April 2017 05:53 PM, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >>> From: Janusz Dziedzic >>> >>> In the case of bounced ep0 requests, we must delay DMA operation until >>> after ->complete() otherwise we might

Re: [PATCH 1/1] usb: host: xhci-mem: allocate zeroed Scratchpad Buffer

On 10.04.2017 14:15, Peter Chen wrote: According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad Buffer needs to be zeroed. ... The following operations take place to allocate Scratchpad Buffers to the xHC: ... b. Software clears the

Re: [PATCH 2/2] usb: host: xhci: using dma pool for scratchpad buffer

On 10.04.2017 14:11, Peter Chen wrote: On Mon, Apr 10, 2017 at 01:13:54PM +0300, Mathias Nyman wrote: On 10.04.2017 05:57, Peter Chen wrote: On Thu, Mar 30, 2017 at 11:29:57AM +0300, Mathias Nyman wrote: the other way around. First you patch dma_alloc_coherent() to dma_zalloc_coherent() and

Re: [PATCH] usb: dwc3: gadget: delay unmap of bounced requests

Hi, Roger Quadros writes: >> From: Janusz Dziedzic >> >> In the case of bounced ep0 requests, we must delay DMA operation until >> after ->complete() otherwise we might overwrite contents of req->buf. >> >> This caused problems with RNDIS gadget. >>

Re: [PATCH] usb: dwc3: gadget: delay unmap of bounced requests

Hi Felipe, On 13/03/17 16:38, Felipe Balbi wrote: > From: Janusz Dziedzic > > In the case of bounced ep0 requests, we must delay DMA operation until > after ->complete() otherwise we might overwrite contents of req->buf. > > This caused problems with RNDIS gadget. >

[PATCH 1/1] usb: host: xhci-mem: allocate zeroed Scratchpad Buffer

According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad Buffer needs to be zeroed. ... The following operations take place to allocate Scratchpad Buffers to the xHC: ... b. Software clears the Scratchpad Buffer to '0' Cc: stable

Re: [PATCH 2/2] usb: host: xhci: using dma pool for scratchpad buffer

On Mon, Apr 10, 2017 at 01:13:54PM +0300, Mathias Nyman wrote: > On 10.04.2017 05:57, Peter Chen wrote: > >On Thu, Mar 30, 2017 at 11:29:57AM +0300, Mathias Nyman wrote: > > the other way around. First you patch dma_alloc_coherent() to > dma_zalloc_coherent() and that could go in

Synopsis XHCI controller lock up

Hi, I'm using a Texas Instruments PCIe XHCI USB card on x86-64 machine running Linux v4.11-rc6 with Ubuntu. I can manage to get the XHCI controller in a unresponsive state with the following message on a device disconnect [ 242.817353] usb 9-3: USB disconnect, device number 9 [ 247.919845]

Re: [PATCH] usb: host: plat: Enable xHCI plat runtime PM

Hi Mathias, On 10 April 2017 at 18:09, Mathias Nyman wrote: > On 10.04.2017 10:57, Baolin Wang wrote: >> >> Hi Mathias, >> >> On 30 March 2017 at 11:26, Baolin Wang wrote: >>> >>> Enable the xHCI plat runtime PM for parent device to

Re: [PATCH 2/2] usb: host: xhci: using dma pool for scratchpad buffer

On 10.04.2017 05:57, Peter Chen wrote: On Thu, Mar 30, 2017 at 11:29:57AM +0300, Mathias Nyman wrote: the other way around. First you patch dma_alloc_coherent() to dma_zalloc_coherent() and that could go in during the -rc and possibly get a stable tag, since spec requires kernel to zero the

Re: [PATCH 3/3] usb: gadget: f_mass_storage: Serialize wake and sleep execution

Hi, Thinh Nguyen writes: > f_mass_storage has a memorry barrier issue with the sleep and wake > functions that can cause a deadlock. This results in intermittent hangs > during MSC file transfer. The host will reset the device after receiving > no response to resume

Re: [PATCH] usb: host: plat: Enable xHCI plat runtime PM

On 10.04.2017 10:57, Baolin Wang wrote: Hi Mathias, On 30 March 2017 at 11:26, Baolin Wang wrote: Enable the xHCI plat runtime PM for parent device to suspend/resume xHCI. Also call pm_runtime_forbid() in probe() function to force users to explicitly enable runtime pm

Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

Hi, Alan Stern writes: > On Wed, 5 Apr 2017, Felipe Balbi wrote: > >> >> >> --- a/drivers/usb/gadget/udc/core.c >> >> >> +++ b/drivers/usb/gadget/udc/core.c >> >> >> @@ -1273,6 +1273,7 @@ void usb_del_gadget_udc(struct usb_gadget >> >> >> *gadget) >> >> >>

[PATCH v2] smsc95xx: Add comments to the registers definition

This chip is used by a lot of embedded devices and also by the Raspberry Pi 1, 2 & 3 which were created to promote the study of computer sciences. Students wanting to learn kernel / network device driver programming through those devices can only rely on the Linux kernel driver source to make

[PATCH] smsc95xx: Add comments to the registers definition

This chip is used by a lot of embedded devices and also by the Raspberry Pi 1, 2 & 3 which were created to promote the study of computer sciences. Students wanting to learn kernel / network device driver programming through those devices can only rely on the Linux kernel driver source to make

Re: [PATCH 3/3] usb: dwc3: ep0: improve handling of unaligned OUT requests

Hi, Janusz Dziedzic writes: > On 7 April 2017 at 13:36, Felipe Balbi wrote: >> Just like we did for all other endpoint types, let's rely on a chained >> TRB pointing to ep0_bounce_addr in order to align transfer size. This >> will make

Re: [balbi-usb:testing/next 46/49] undefined reference to `extcon_get_edev_by_phandle'

Hi, Roger Quadros writes: >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git >>> testing/next >>> head: 9653f750a746d5abc4bc054d818eb32d1351eae9 >>> commit: d5a80bad699c94703a0306edd250f65cfd050580 [46/49] usb: dwc3: Add >>> dual-role support >>>

Re: [PATCH] usb: host: plat: Enable xHCI plat runtime PM

Hi Mathias, On 30 March 2017 at 11:26, Baolin Wang wrote: > Enable the xHCI plat runtime PM for parent device to suspend/resume > xHCI. Also call pm_runtime_forbid() in probe() function to force users > to explicitly enable runtime pm using power/control in sysfs, in case

Re: [balbi-usb:testing/next 46/49] undefined reference to `extcon_get_edev_by_phandle'

On 09/04/17 03:28, Randy Dunlap wrote: > On 04/08/17 09:29, kbuild test robot wrote: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git >> testing/next >> head: 9653f750a746d5abc4bc054d818eb32d1351eae9 >> commit: d5a80bad699c94703a0306edd250f65cfd050580 [46/49] usb: dwc3:

Re: [PATCH 3/3] usb: dwc3: ep0: improve handling of unaligned OUT requests

On 7 April 2017 at 13:36, Felipe Balbi wrote: > Just like we did for all other endpoint types, let's rely on a chained > TRB pointing to ep0_bounce_addr in order to align transfer size. This > will make the code simpler. > > Signed-off-by: Felipe Balbi

Re: [PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

On 2017-04-10 10:52, Kishon Vijay Abraham I wrote: On Friday 07 April 2017 01:37 AM, Vivek Gautam wrote: The driver uses clock provider interface, and therefore it fails to build when enabled for COMPILE_TEST, since COMMON_CLK is not enabled at that time. So, make PHY_QCOM_QMP depend on

Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt

Hi again, Felipe Balbi writes: > Thinh Nguyen writes: >> This patch fixes a commit that causes a hang from device waiting for >> data with the wrong sequence number. The commit ffb80fc672c3 ("usb: >> dwc3: gadget: skip Set/Clear Halt when invalid")

Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt

Hi, Thinh Nguyen writes: > This patch fixes a commit that causes a hang from device waiting for > data with the wrong sequence number. The commit ffb80fc672c3 ("usb: > dwc3: gadget: skip Set/Clear Halt when invalid") adds a check to return > early depending on

Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

Hi, Thinh Nguyen writes: > The dwc3 driver can overwite its previous events if its top half IRQ > handler gets invoked again before processing the events in the cache. We interrupts are masked, why would top half get invoked again? Is this, perhaps, related to DWC3

[PATCH] usb: dwc3: simplify ZLP handling

It's much simpler to just add one extra TRB chained to previous TRB to handle ZLP. This helps us reduce pointless allocations and simplifies the code a little bit. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/core.h | 4 +-- drivers/usb/dwc3/ep0.c| 49