linux-kernel - Re: [PATCH 1/6] dt-bindings: usb: dwc3: Clean up hs_phy

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ef315412-99c7-4179-9e96-80eaf2e25f26@linaro.org>
Date:   Thu, 30 Nov 2023 09:08:52 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>,
        Johan Hovold <johan@...nel.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, quic_wcheng@...cinc.com,
        linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        quic_ppratap@...cinc.com, quic_jackp@...cinc.com
Subject: Re: [PATCH 1/6] dt-bindings: usb: dwc3: Clean up hs_phy_irq in
 bindings

On 29/11/2023 11:50, Krishna Kurapati PSSNV wrote:
> 
> 
> On 11/29/2023 3:46 PM, Johan Hovold wrote:
>> On Wed, Nov 29, 2023 at 10:28:25AM +0100, Krzysztof Kozlowski wrote:
>>> On 28/11/2023 12:32, Krishna Kurapati PSSNV wrote:
>>>>
>>>>>
>>>>> So back to my initial proposal, with a slight modification moving
>>>>> pwr_event first (e.g. as it is not a wakeup interrupt):
>>>>>
>>>>> qusb2-:
>>>>>
>>>>> 	- const: pwr_event
>>>>> 	- const: qusb2_phy
>>>>> 	- const: ss_phy_irq	(optional)
>>>>>
>>>>> qusb2:
>>>>>
>>>>> 	- const: pwr_event
>>>>> 	- const: hs_phy_irq
>>>>> 	- const: qusb2_phy
>>>>> 	- const: ss_phy_irq	(optional)
>>>>>
>>>>> femto-:
>>>>> 	- const: pwr_event
>>>>> 	- const: dp_hs_phy_irq
>>>>> 	- const: dm_hs_phy_irq
>>>>> 	- const: ss_phy_irq	(optional)
>>>>>
>>>>> femto:
>>>>> 	- const: pwr_event
>>>>> 	- const: hs_phy_irq
>>>>> 	- const: dp_hs_phy_irq
>>>>> 	- const: dm_hs_phy_irq
>>>>> 	- const: ss_phy_irq	(optional)
>>>
>>> I did not follow entire thread and I do not know whether you change the
>>> order in existing bindings, but just in case: the entries in existing
>>> bindings cannot change the order. That's a strict ABI requirement
>>> recently also discussed with Bjorn, because we want to have stable DTB
>>> for laptop platforms. If my comment is not relevant, then please ignore.
>>
>> Your comment is relevant, but I'm not sure I agree.
>>
>> The Qualcomm bindings are a complete mess of DT snippets copied from
>> vendor trees and which have not been sanitised properly before being
>> merged upstream (partly due to there not being any public documentation
>> available).
>>
>> This amounts to an unmaintainable mess which is reflected in the
>> binding schemas which similarly needs to encode every random order which
>> the SoC happened to use when being upstreamed. That makes the binding
>> documentation unreadable too, and the next time a new SoC is upstreamed
>> there is no clear hints of what the binding should look like, and we end
>> up with yet another permutation.
>>
>> As part of this exercise, we've also determined that some of the
>> devicetrees that are already upstream are incorrect as well as
>> incomplete.
>>
>> I really see no alternative to ripping of the plaster and cleaning this
>> up once and for all even if it "breaks" some imaginary OS which (unlike
>> Linux) relies on the current random order of these interrupts.
>>
>> [ If there were any real OSes actually relying on the order, then that
>> would be a different thing of course. ]
>>
> 
> Hi Krzysztof, Johan,
> 
>    We are modifying all the DT's in accordance to bindings as well. 
> Still it would be breaking ABI ?

Yes, how can you modify DTB stored in firmware on the customer board?

Best regards,
Krzysztof