Messages in this thread | | | Date | Wed, 29 Nov 2023 16:20:16 +0530 | Subject | Re: [PATCH 1/6] dt-bindings: usb: dwc3: Clean up hs_phy_irq in bindings | From | Krishna Kurapati PSSNV <> |
| |
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,
| |