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 DWC3_EP_STALL is set or not, preven
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") adds a check to return
>> early depending on D
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 COMMON_C
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
> ---
> drivers/usb/dwc3/core.h | 6 +---
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: A
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
> some parent devices di
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
>>> config: x86_64-randcon
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 the code simpler.
>>
>> Signed-off-by: Felipe Balbi
>> ---
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 their
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 their
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)
>> >> >>flush_work(&gadget->work);
>> >
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 using power/control in sy
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 the transfer. This issue is s
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 mem
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 suspend/resume
>>> xHCI. Also call pm_runtime_forbid() in probe
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] xh
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 durin
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
Signed-off-by:
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.
>
> Signed-off-by: Janusz Dzi
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.
>>
>> Signed-off-by: Janusz Dziedzic
>> Sign
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 t
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 Scra
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 overwrite contents of req->buf.
>>>
>>> This cau
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.
This caused problems with RNDIS gadget.
Si
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
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 the device after receiving
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 are
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 usb_del_gadget_udc(struct usb_gadget
> >> >>
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.
Signed-of
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 results in intermittent hangs
> >
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 a
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():
>
>
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
> > barri
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 usi
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 th
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 transfer and the host will
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 cas
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 get invoked again? Is this,
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 wake
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 _w
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:
dwc3: gadget: skip Set/Clear Halt when invalid"
On 10 April 2017 at 20:43, John Youn wrote:
> 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 thi
On 04/10/2017 11:17 PM, Janusz Dziedzic wrote:
> On 10 April 2017 at 20:43, John Youn wrote:
>> 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 befo
Hi Shuah,
Could you please take a look at these patches? I got more patches
that sit on these to send out.
Thanks,
Yuyang
On Thu, Apr 06, 2017 at 06:03:24AM +0800, Yuyang Du wrote:
> If we get nonpositive number of ports, there is no sense to
> continue, then fail gracefully.
>
> In addition, t
Hi,
John Youn writes:
>>> Yes it will re-assert. The interrupt line will remain asserted as long
>>> events remain in the buffer and it is not masked. So when we
>>> eventually unmask, the interrupt will be reasserted again immediately.
>>>
BTW, other option here could be using (like Baolin
45 matches
Mail list logo
