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
