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
