lkml.org 
[lkml]   [2023]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/6] dt-bindings: usb: dwc3: Clean up hs_phy_irq in bindings
From


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 ?

Regards,
Krishna,

\
 
 \ /
  Last update: 2023-11-29 11:51    [W:0.074 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site