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
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
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
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
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 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
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 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, 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/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, 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 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 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:
> > 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, 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, 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
> >
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, 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
> >> >>
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,
>
> 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 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
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 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
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
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
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
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
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:
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
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
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
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,
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 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,
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);
>> >
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,
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
>> ---
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 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
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
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 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
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
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
45 matches
Mail list logo
