Message-ID: <1cbaa7a3-e26a-4f8e-a7e0-8f148d516b75@kernel.org>
Date: Tue, 10 Dec 2024 12:47:50 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Krishna Kurapati <quic_kriskura@...cinc.com>,
 Uttkarsh Aggarwal <quic_uaggarwa@...cinc.com>,
 Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: Krzysztof Kozlowski <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Felipe Balbi <balbi@...nel.org>, linux-usb@...r.kernel.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
 quic_ppratap@...cinc.com, quic_jackp@...cinc.com
Subject: Re: [PATCH v2 1/2] dt-bindings: usb: snps,dwc3: Add
 snps,filter-se0-fsls-eop quirk

On 10/12/2024 11:12, Krishna Kurapati wrote:
> 
> 
> On 11/20/2024 2:53 PM, Krishna Kurapati wrote:
>>
>>
>> On 11/7/2024 3:25 PM, Krzysztof Kozlowski wrote:
>>> On 07/11/2024 07:17, Krishna Kurapati wrote:
>>>>
>>>>
>>>> On 10/18/2024 11:57 AM, Krzysztof Kozlowski wrote:
>>>>> On Thu, Oct 17, 2024 at 05:10:54PM +0530, Uttkarsh Aggarwal wrote:
>>>>>> Adding a new 'snps,filter-se0-fsls-eop quirk' DT quirk to dwc3 core 
>>>>>> to set
>>>>>> GUCTL1 BIT 29. When set, controller will ignore single SE0 glitch 
>>>>>> on the
>>>>>> linestate during transmission. Only two or more SE0 is considered as
>>>>>> valid EOP on FS/LS port. This bit is applicable only in FS in 
>>>>>> device mode
>>>>>> and FS/LS mode of operation in host mode.
>>>>>
>>>>> Why this is not device/compatible specific? Just like all other quirks
>>>>> pushed last one year.
>>>>
>>>> Hi Krzysztof,
>>>>
>>>>    Apologies for a late reply from our end.
>>>>
>>>>    In DWC3 core/dwc3-qcom atleast, there have been no compatible 
>>>> specific
>>>> quirks added.
>>>
>>
>> Sorry again for late reply.
>>
>>> Nothing stops from adding these, I think.
>>>>
>> Agree, we can take that approach of adding soc specific compatibles to 
>> dwc3 driver instead of adding through bindings.
>>
>>>> Also since this is a property of the Synopsys controller
>>>> hardware and not QC specific one, can we add it in bindings itself.
>>>> Because this is a property other vendors might also use and adding it
>>>> via compatible might not be appropriate.
>>>
>>> This does no answer my question. I don't see how this is not related to
>>> one specific piece of SoC.
>>>
>>> If you claim this is board-related, not SoC, give some arguments.
>>> Repeating the same is just no helping.
>>>
>>
>> But my point was that although the issue was found only on some QC 
>> SoC's, the solution still lies in some bits being set in controller 
>> register space and it is part of Synopsys IP. So wouldn't officially we 
>> add that support in bindings and then enable/disable the feature via DT 
>> like we did for other quirks ? If many SoC's need it in future, the 
>> driver needs to add a long list of compatible specific data which 
>> otherwise might be quirks in DT.
>>
> 
> Hi Krzysztof,
> 
>   Gentle ping to provide your feedback on the last comment.
You got clear comments yet you still do not accept them. Nothing
changed, this is implied by compatible. The only reason this is not
compatible implied is that this is board specific. I asked for arguments
for this. Did you provide them? No. Instead we keep discussing same over
and over again.

You bring downstream arguments - one compatible and hundreds of
properties - and it is tiring to discuss over and over. There were
already multiple guidelines written and multiple comments for multiple
patches on the exact same topic.

I don't find nice being pushed over this and pinged for every little
disagreement with standard Devicetree rules and guidelines.


Best regards,
Krzysztof

Powered by blists - more mailing lists