Re: [PATCH 1/2] dt-bindings: usb: xhci: add xhci-no-soft-retry-quirk

[Krzysztof Kozlowski]

On 28/08/2026 15:18, Matt Eaton wrote:
> On Fri, Aug 28, 2026 at 2:39 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>>
>> On 28/08/2026 14:37, Matt Eaton via B4 Relay wrote:
>>> From: Matt Eaton <linux@xxxxxxxxxxxxxx>
>>>
>>> Document the xhci-no-soft-retry-quirk property, added in the
>>> following patch.
>>>
>>> snps,dwc3-common.yaml refs usb-xhci.yaml for every dr_mode other than
>>> peripheral, so a host-mode dwc3 node inherits it and dt_binding_check
>>> accepts it there.
>>
>> I do not understand how this sentence is relevant. Please describe the
>> hardware needing this.
> 
> I came across this while porting the UniFi Travel Router (IPQ4018),
> the stock Qualcomm kernel is 4.4.60 which predates the soft retry
> code. The command ring hangs if you disconnect the device while it's
> transmitting. Reproducible consistently when using USB to tether to a
> phone.
> 
>>>
>>> Signed-off-by: Matt Eaton <linux@xxxxxxxxxxxxxx>
>>> ---
>>>  Documentation/devicetree/bindings/usb/usb-xhci.yaml | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.yaml b/Documentation/devicetree/bindings/usb/usb-xhci.yaml
>>> index 4238ae896ef6..5d67a41658f7 100644
>>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.yaml
>>> @@ -25,6 +25,10 @@ properties:
>>>      description: Set if the controller has broken port disable mechanism
>>>      type: boolean
>>>
>>> +  xhci-no-soft-retry-quirk:
>>> +    description: Set if the controller cannot perform xHCI Soft Retry correctly
>>
>> Why isn't this implied by compatible? Looks like controller's property.
> 
> The xhci device is created by dwc3 core as a child device, and so
> xhci_plat_probe() is used. I think a DT property is the right
> approach, similar to quirk-broken-port-ped, but to set
> XHCI_NO_SOFT_RETRY.

Linux driver behavior should not matter here. DT property for telling
Linux what to do is not the right approach. As I said, it's implied by
compatible unless you bring hardware reasons why it is not. Driver
reasons don't matter.

Best regards,
Krzysztof