Wesley Cheng wrote:
>
>
> On 4/15/2021 12:28 PM, Thinh Nguyen wrote:
>> Thinh Nguyen wrote:
>>> Wesley Cheng wrote:
>>>>
>>>>
>>>> On 4/14/2021 11:26 PM, Felipe Balbi wrote:
>>>>> Wesley Cheng writes:
>>>>
Thinh Nguyen wrote:
> Wesley Cheng wrote:
>>
>>
>> On 4/14/2021 11:26 PM, Felipe Balbi wrote:
>>> Wesley Cheng writes:
>>>
>>>> If an error is received when issuing a start or update transfer
>>>> command, the error handler will s
Wesley Cheng wrote:
>
>
> On 4/14/2021 11:26 PM, Felipe Balbi wrote:
>> Wesley Cheng writes:
>>
>>> If an error is received when issuing a start or update transfer
>>> command, the error handler will stop all active requests (including
>>> the current USB request), and call
o the endpoint's cancelled_list.
> */
> -static inline void dwc3_gadget_move_cancelled_request(struct dwc3_request
> *req)
> +static inline void dwc3_gadget_move_cancelled_request(struct dwc3_request
> *req,
> + unsigned int reason)
> {
> struct dwc3_ep *dep = req->dep;
>
> - req->status = DWC3_REQUEST_STATUS_CANCELLED;
> + req->status = reason;
> list_move_tail(>list, >cancelled_list);
> }
>
>
Reviewed-by: Thinh Nguyen
Thanks for the patch,
Thinh
Wesley Cheng wrote:
>
>
> On 3/6/2021 3:39 PM, Thinh Nguyen wrote:
>> Wesley Cheng wrote:
>>>
>>> On 1/7/2021 5:51 PM, John Stultz wrote:
>>>> In reviewing the previous patch, Thinh Nguyen pointed out that
>>>> the DRD mode change seque
Hi Ray,
Ray Chi wrote:
> Currently, when dwc3 handles request cancelled, dwc3 just returns
> -ECONNRESET for all requests. It will cause USB function drivers
> can't know if the requests are cancelled by other reasons.
>
> This patch will replace DWC3_REQUEST_STATUS_CANCELLED with the
> reasons
Felipe Balbi wrote:
> Hi,
>
> Ray Chi writes:
>> diff --git a/drivers/usb/dwc3/gadget.h b/drivers/usb/dwc3/gadget.h
>> index 0cd281949970..a23e85bd3933 100644
>> --- a/drivers/usb/dwc3/gadget.h
>> +++ b/drivers/usb/dwc3/gadget.h
>> @@ -56,6 +56,12 @@ struct dwc3;
>>
>> /* Frame/Microframe
Hi Ray,
Ray Chi wrote:
> Currently, when dwc3 handles request cancelled, dwc3 just returns
> -ECONNRESET for all requests. It will cause USB class drivers can't
class drivers -> gadget driver or function driver.
> know if the requests are cancelled by other reasons.
>
> This patch will add the
Wesley Cheng wrote:
> Hi Thinh,
>
>
> On 3/19/2021 7:01 PM, Thinh Nguyen wrote:
>> Wesley Cheng wrote:
>>>
>>>
>>> On 3/19/2021 5:40 PM, Thinh Nguyen wrote:
>>>> Hi,
>>>>
>>>> Wesley Cheng wrote:
>>>&
Thinh Nguyen wrote:
> Wesley Cheng wrote:
>>
>>
>> On 3/19/2021 5:40 PM, Thinh Nguyen wrote:
>>> Hi,
>>>
>>> Wesley Cheng wrote:
>>>> The current dwc3_gadget_reset_interrupt() will stop any active
>>>> transfers, but
Wesley Cheng wrote:
>
>
> On 3/19/2021 5:40 PM, Thinh Nguyen wrote:
>> Hi,
>>
>> Wesley Cheng wrote:
>>> The current dwc3_gadget_reset_interrupt() will stop any active
>>> transfers, but only addresses blocking of EP queuing for while we are
>&g
Hi,
Wesley Cheng wrote:
> The current dwc3_gadget_reset_interrupt() will stop any active
> transfers, but only addresses blocking of EP queuing for while we are
> coming from a disconnected scenario, i.e. after receiving the disconnect
> event. If the host decides to issue a bus reset on the
Wesley Cheng wrote:
>
>
> On 3/8/2021 10:33 PM, Wesley Cheng wrote:
>>
>>
>> On 3/8/2021 7:05 PM, Thinh Nguyen wrote:
>>> Wesley Cheng wrote:
>>>>
>>>> On 3/6/2021 3:41 PM, Thinh Nguyen wrote:
>>>>> Wes
Wesley Cheng wrote:
> In the situations where the DWC3 gadget stops active transfers, once
> calling the dwc3_gadget_giveback(), there is a chance where a function
> driver can queue a new USB request in between the time where the dwc3
> lock has been released and re-aquired. This occurs after
Wesley Cheng wrote:
>
> On 3/6/2021 3:41 PM, Thinh Nguyen wrote:
>> Wesley Cheng wrote:
>>> On 1/8/2021 4:44 PM, Thinh Nguyen wrote:
>>>> Hi,
>>>>
>>>> John Stultz wrote:
>>>>> On Fri, Jan 8, 2021 at 4:26 AM Felipe Balbi wr
Wesley Cheng wrote:
>
> On 1/8/2021 4:44 PM, Thinh Nguyen wrote:
>> Hi,
>>
>> John Stultz wrote:
>>> On Fri, Jan 8, 2021 at 4:26 AM Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> John Stultz writes:
>>>>> From: Yu Chen
Wesley Cheng wrote:
>
> On 1/7/2021 5:51 PM, John Stultz wrote:
>> In reviewing the previous patch, Thinh Nguyen pointed out that
>> the DRD mode change sequence should be like the following when
>> switching from host -> device according to the programming guide
>&g
Wesley Cheng wrote:
>
> On 1/26/2021 12:43 PM, Thinh Nguyen wrote:
>> Wesley Cheng wrote:
>>> On 1/22/2021 4:15 PM, Thinh Nguyen wrote:
>>>> Hi,
>>>>
>>>> Wesley Cheng wrote:
>>>>> Some devices have USB compositions which ma
Wesley Cheng wrote:
>
> On 1/22/2021 4:15 PM, Thinh Nguyen wrote:
>> Hi,
>>
>> Wesley Cheng wrote:
>>> Some devices have USB compositions which may require multiple endpoints
>>> that support EP bursting. HW defined TX FIFO sizes may not alway
Hi,
Wesley Cheng wrote:
> Some devices have USB compositions which may require multiple endpoints
> that support EP bursting. HW defined TX FIFO sizes may not always be
> sufficient for these compositions. By utilizing flexible TX FIFO
> allocation, this allows for endpoints to request the
Hi,
Daehwan Jung wrote:
> Sometimes dwc3_gadget_pullup and dwc3_gadget_set_speed are called after
> entering suspend. That's why it needs to check whether suspend
>
> 1. dwc3 sends disconnect uevent and turn off. (suspend)
> 2. Platform side causes pullup or set_speed(e.g., adbd closes ffs node)
>>
>>> We had seen occasional initialization failures with older
>>> kernels but with recent 5.x era kernels it seemed to be becoming
>>> much more common, so I dug back through some older trees and
>>> realized I dropped this quirk from Yu Chen during ups
gre...@linuxfoundation.org wrote:
> On Fri, Jan 08, 2021 at 02:19:30AM +0000, Thinh Nguyen wrote:
>> Hi Wesley,
>>
>> Felipe Balbi wrote:
>>> Hi,
>>>
>>> Wesley Cheng writes:
>>>> +void composite_reset(struct usb_gadget *gadget)
>
Jack Pham wrote:
> Hi Thinh,
>
> On Fri, Jan 08, 2021 at 02:19:30AM +0000, Thinh Nguyen wrote:
>> Hi Wesley,
>>
>> Felipe Balbi wrote:
>>> Hi,
>>>
>>> Wesley Cheng writes:
>>>> +void composite_reset(struct usb_gadget *gadget)
>
Hi Wesley,
Felipe Balbi wrote:
> Hi,
>
> Wesley Cheng writes:
>> +void composite_reset(struct usb_gadget *gadget)
>> +{
>> +/*
>> + * Section 1.4.13 Standard Downstream Port of the USB battery charging
>> + * specification v1.2 states that a device connected on a SDP shall only
>> +
Hi,
Felipe Balbi wrote:
> Hi,
>
> Thinh Nguyen writes:
>> John Stultz wrote:
>>> static void __dwc3_set_mode(struct work_struct *work)
>>> {
>>> struct dwc3 *dwc = work_to_dwc(work);
>>> unsigned long flags;
>>> + int hw
Wesley Cheng wrote:
>
> On 10/28/2020 5:43 PM, Thinh Nguyen wrote:
>> Hi,
>>
>> Wesley Cheng wrote:
>>> The USB gadget/UDC driver can restrict the DWC3 controller speed using
>>> dwc3_gadget_set_speed(). Store this setting into a variable, in or
Thinh Nguyen wrote:
> Wesley Cheng wrote:
>> On 10/28/2020 5:43 PM, Thinh Nguyen wrote:
>>> Hi,
>>>
>>> Wesley Cheng wrote:
>>>> The USB gadget/UDC driver can restrict the DWC3 controller speed using
>>>> dwc3_gadget_set_speed(). Store
Hi,
Wesley Cheng wrote:
> The USB gadget/UDC driver can restrict the DWC3 controller speed using
> dwc3_gadget_set_speed(). Store this setting into a variable, in order for
> this setting to persist across controller resets due to runtime PM.
Why do we need to do this? DCFG should persist
didn't
> seem to be necessary. I now realize I was wrong.
>
> After resubmitting the quirk Thinh Nguyen pointed out that it
> shouldn't be a quirk and it is actually mentioned in the
> programming guide that it should be done when switching modes
> in DRD.
>
> So, to avoid these
k in the DesignWare USB3 DRD Core of
> Hisilicon Kirin SoCs, this patch adds a quirk flag which
> executes a GCTL soft reset when we switch modes.
>
> Cc: Felipe Balbi
> Cc: Tejas Joglekar
> Cc: Yang Fei
> Cc: YongQin Liu
> Cc: Andrzej Pietrasiewicz
> Cc: Thinh Nguye
Dejin Zheng wrote:
> According to Synopsys Programming Guide chapter 2.2 Register Resets,
> it cannot reset the DCTL register by setting DCTL.CSFTRST for core soft
> reset, if DWC3 controller as a slave device and stay connected with a usb
> host, then, while rebooting linux, it will fail to
Felipe Balbi wrote:
> Hi,
>
> Mauro Carvalho Chehab writes:
I tested here, together with the Hikey 970 phy RFC patches I sent
last week.
Without this patch, the USB HID driver receives -EPROTO from
submitted URBs, causing it to enter into an endless reset cycle
on
v_buf->lpos = (dwc->ev_buf->lpos + count) %
> + dwc->ev_buf->length;
> + }
> + }
> +
> ret = dwc3_gadget_run_stop(dwc, is_on, false);
> spin_unlock_irqrestore(>lock, flags);
> + enable_irq(dwc->irq_gadget);
>
> return ret;
> }
> @@ -3100,6 +3145,8 @@ static void dwc3_gadget_reset_interrupt(struct dwc3
> *dwc)
> }
>
> dwc3_reset_gadget(dwc);
> + /* Stop any active/pending transfers when receiving bus reset */
> + dwc3_stop_active_transfers(dwc);
>
> reg = dwc3_readl(dwc->regs, DWC3_DCTL);
> reg &= ~DWC3_DCTL_TSTCTRL_MASK;
Looks good to me.
Reviewed-by: Thinh Nguyen
Thanks,
Thinh
Wesley Cheng wrote:
>
> On 9/1/2020 3:14 PM, Wesley Cheng wrote:
>>
>> On 8/29/2020 2:35 PM, Thinh Nguyen wrote:
>>> Wesley Cheng wrote:
>>>> In the DWC3 databook, for a device initiated disconnect or bus reset, the
>>>> driver is required to
Wesley Cheng wrote:
> In the DWC3 databook, for a device initiated disconnect or bus reset, the
> driver is required to send dependxfer commands for any pending transfers.
> In addition, before the controller can move to the halted state, the SW
> needs to acknowledge any pending events. If the
Wesley Cheng wrote:
> On 8/19/2020 2:42 PM, Thinh Nguyen wrote:
>> Hi,
>>
>> Wesley Cheng wrote:
>>> In the DWC3 databook, for a device initiated disconnect, the driver is
>>> required to send dependxfer commands for any pending transfers.
>>
Hi,
Wesley Cheng wrote:
> In the DWC3 databook, for a device initiated disconnect, the driver is
> required to send dependxfer commands for any pending transfers.
> In addition, before the controller can move to the halted state, the SW
> needs to acknowledge any pending events. If the
Hi,
Thinh Nguyen wrote:
> Hi,
>
> Chunfeng Yun wrote:
>> The maximum_speed will be USB_SPEED_SUPER_PLUS, but the
>> maximum_speed check for usb2.0-only core doesn't consider it,
>> so fix it, and move the ckeck into dwc3_check_params().
>>
>> Sign
Hi,
Chunfeng Yun wrote:
> The maximum_speed will be USB_SPEED_SUPER_PLUS, but the
> maximum_speed check for usb2.0-only core doesn't consider it,
> so fix it, and move the ckeck into dwc3_check_params().
>
> Signed-off-by: Chunfeng Yun
> ---
> Note:
>
> When I look at the code, find that this
Thinh Nguyen wrote:
> Jun Li wrote:
>> Hi
>>
>>> -Original Message-
>>> From: Thinh Nguyen
>>> Sent: 2020年5月19日 14:46
>>> To: Jun Li ; Felipe Balbi ; Jun Li
>>>
>>> Cc: John Stultz ; lkml
>>> ; Yu
>>
Jun Li wrote:
> Hi
>
>> -Original Message-----
>> From: Thinh Nguyen
>> Sent: 2020年5月19日 14:46
>> To: Jun Li ; Felipe Balbi ; Jun Li
>>
>> Cc: John Stultz ; lkml
>> ; Yu
>> Chen ; Greg Kroah-Hartman ;
>> Rob
>> Herring ; Ma
Thinh Nguyen wrote:
> Jun Li wrote:
>>> -Original Message-
>>> From: Felipe Balbi On Behalf Of Felipe Balbi
>>> Sent: 2020年5月16日 19:57
>>> To: Jun Li ; Thinh Nguyen ; Jun
>>> Li
>>>
>>> Cc: John Stultz ; lkml
>>&g
Jun Li wrote:
>> -Original Message-
>> From: Felipe Balbi On Behalf Of Felipe Balbi
>> Sent: 2020年5月16日 19:57
>> To: Jun Li ; Thinh Nguyen ; Jun Li
>>
>> Cc: John Stultz ; lkml
>> ; Yu
>> Chen ; Greg Kroah-Hartman ;
>> Rob
>&
ShuFan Lee
>> ; Heikki Krogerus ;
>> Suzuki K Poulose ; Chunfeng Yun
>> ; Hans de Goede ; Andy
>> Shevchenko
>> ; Valentin Schneider ;
>> Jack Pham ; Linux USB List
>> ; open
>> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
>> ;
>
Hi,
Anurag Kumar Vulisha wrote:
> Hi Claus,
>
>> -Original Message-
>> From: Claus H. Stovgaard [mailto:c...@phaseone.com]
>> Sent: Tuesday, May 07, 2019 2:28 AM
>> To: Thinh Nguyen ; Anurag Kumar Vulisha
>> ; Greg Kroah-Hartman ; Rob
>> Herring ;
Hi Anurag,
Anurag Kumar Vulisha wrote:
> Gadget applications may have a requirement to disable the U1 and U2
> entry based on the usecase. For example, when performing performance
> benchmarking on mass storage gadget the U1 and U2 entries can be disabled.
> Another example is when periodic
Thinh Nguyen wrote:
> Bjorn Helgaas wrote:
>> On Tue, Feb 05, 2019 at 08:38:58PM +0000, Thinh Nguyen wrote:
>>> Hi Bjorn,
>>>
>>> Bjorn Helgaas wrote:
>>>> On Fri, Feb 01, 2019 at 08:27:00PM +, Thinh Nguyen wrote:
>>>>> Lukas Wunne
Bjorn Helgaas wrote:
> On Tue, Feb 05, 2019 at 08:38:58PM +0000, Thinh Nguyen wrote:
>> Hi Bjorn,
>>
>> Bjorn Helgaas wrote:
>>> On Fri, Feb 01, 2019 at 08:27:00PM +, Thinh Nguyen wrote:
>>>> Lukas Wunner wrote:
>>>>> On
Hi Bjorn,
Bjorn Helgaas wrote:
> On Fri, Feb 01, 2019 at 08:27:00PM +0000, Thinh Nguyen wrote:
>> Lukas Wunner wrote:
>>> On Thu, Jan 31, 2019 at 11:46:23PM +, Thinh Nguyen wrote:
>>>> --- a/drivers/pci/quirks.c
>>>> +++ b/drivers/pci/qui
John Stultz wrote:
> On Fri, Feb 1, 2019 at 4:46 PM Thinh Nguyen wrote:
>> John Stultz wrote:
>>> On Fri, Feb 1, 2019 at 4:18 PM John Stultz wrote:
>>> Bisecting the changes down, it seems like its due to commit
>>> fec9095bdef4e ("us
Hi John,
John Stultz wrote:
> On Fri, Feb 1, 2019 at 4:18 PM John Stultz wrote:
>> Hey all,
>> Since the 5.0 merge window opened, I've been tripping on frequent
>> dwc3 crashes on reboot and suspend, which I've added an example to the
>> bottom of this mail.
>>
>> I've dug in a little bit and
Hi John,
John Stultz wrote:
> Hey all,
> Since the 5.0 merge window opened, I've been tripping on frequent
> dwc3 crashes on reboot and suspend, which I've added an example to the
> bottom of this mail.
>
> I've dug in a little bit and sort of have a sense of whats going on.
>
> In
Hi Lukas,
Lukas Wunner wrote:
> On Thu, Jan 31, 2019 at 11:46:23PM +0000, Thinh Nguyen wrote:
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -629,6 +629,9 @@ static void quirk_synopsys_haps(struct pci_dev *pdev)
>> {
>>
Hi Lukas,
Lukas Hartmann wrote:
> Hi Thinh,
>
> this is in a taped out i.MX6QP 1.2GHz SoC, I also confirmed it with the
> 1.0GHz version, it has the same 0xabcd device id integrated.
I see.
> I will try your patch ASAP.
Thank you.
Thinh
>
>> On 1. Feb 2019, at 00
Hi Lukas,
Thinh Nguyen wrote:
> Bjorn Helgaas wrote:
>> [+cc linux-pci, linux-kernel]
>>
>> On Thu, Jan 31, 2019 at 11:21 AM Lukas F. Hartmann wrote:
>>> Hi Thinh,
>>>
>>> I'm writing you because you're the author in this commit:
>
Hi Lukas,
Bjorn Helgaas wrote:
> [+cc linux-pci, linux-kernel]
>
> On Thu, Jan 31, 2019 at 11:21 AM Lukas F. Hartmann wrote:
>> Hi Thinh,
>>
>> I'm writing you because you're the author in this commit:
>>
Hi Zengtao,
On 12/16/2018 5:45 PM, Zengtao (B) wrote:
>> If it's a busy system, some times when we start an isoc transfer,
>> the framenumber get from the event buffer may be already elasped,
>> in this case, we will get all the packets dropped due to miss isoc.
>> And we turn
Hi Zengtao,
On 12/14/2018 3:24 AM, Felipe Balbi wrote:
> Hi,
>
> "Zengtao (B)" writes:
>>> -Original Message-
>>> From: Felipe Balbi [mailto:ba...@kernel.org]
>>> Sent: Friday, December 14, 2018 4:52 PM
>>> To: Zengtao (B)
>>> Cc: liangshengjun ; Zengtao (B)
>>> ; Greg Kroah-Hartman
>>>
59 matches
Mail list logo
