lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <19bdc074-7f48-4df4-87c0-117f4cff54f0@kernel.org>
Date: Tue, 8 Oct 2024 14:59:28 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Joy Chakraborty <joychakr@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Thinh Nguyen
 <Thinh.Nguyen@...opsys.com>, Felipe Balbi <balbi@...nel.org>,
 linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: usb: dwc3: Add binding for USB Gen2
 de-emphasis

On 08/10/2024 14:40, Joy Chakraborty wrote:
> On Tue, Oct 8, 2024 at 5:40 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On 08/10/2024 13:59, Joy Chakraborty wrote:
>>>>>
>>>>>>
>>>>>>> +    description: When set core will set Tx de-emphasis for USB Gen2
>>>>>>
>>>>>> And why it cannot be implied by compatible?
>>>>>
>>>>> As per my understanding these are tuning coefficients for de-emphasis
>>>>> particular to a platform and not the dwc3 controller, hence should not
>>>>> be a controller compatible.
>>>>
>>>> Platforms must have specific compatible, so this should be implied by
>>>> compatible.
>>>
>>> Maybe I am using the word "platform" incorrectly here, what I
>>> understand is that the same controller(in a chip) when used on 2
>>> different physical form factors might need different deemphasis
>>
>> You mean boards? This is board-level property?
> 
> Yes, the USB controller can be paired with different phys in a SoC and

That's not board specific, but SoC.

> used on different board layouts where we should be able to drive
> different de-emphasis coefficients to the phy as per the link
> equalization requirements is my understanding.

You keep mixing different stories, so I am not convinced.

> 
>>
>>> coefficient values to be passed to its Phy. Someone could correct me
>>> from the USB link stand point if I am mistaken here.
>>>
>>
>> Then please point me to the upstream DTS boards using these properties.
>> Lore link is enough, if board or DTS change is being upstreamed.
>>
> 
> The DTS change is not being upstreamed currently.

Why do we want code without any user?

> But this change would help bring up a new or development board where
> USB compliance is being run and this parameter needs tuning,  hence
> being able to upstream this would help.

To me whatever Google or any other vendor is doing downstream does not
matter, just "does not exist".

Upstream the DTS so we can verify how this is exactly used.

To me it looks so far as SoC specific and your earlier comment about
pairing USB controller with phy is confirming this.

That's a common practice from Google (but not Chromium folks, they are
awesome!) and few other vendors to upstream whatever they have in their
GKI downstream, regardless whether it is right or not, whether it
follows rules or not, whether there is any user or not (and again: users
are upstream). Rationale for all this is the same - "we have downstream
some crap thus we want it".

Nah, upstream your stuff to be considered as a user.

That's a NAK, sorry.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ