On Mon, Mar 14, 2022 at 9:34 AM Marc Zyngier <maz@xxxxxxxxxx> wrote: > > On Mon, 14 Mar 2022 15:15:15 +0000, > Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > > > On Tue, Dec 14, 2021 at 6:59 AM Vladimir Oltean <vladimir.oltean@xxxxxxx> wrote: > > > Therefore, the premise of the patch being reverted here is invalid. > > > It doesn't matter whether the driver, in its non-standard use of the > > > property, complies to the standard format or not, since this property > > > isn't expected to be used for interrupt translation by the core. > > > > I disagree. The non-standard part is that 'interrupt-map' translation > > is not transparent. 'interrupt-map' that can't be parsed in the > > standard way is just wrong, and I imagine was never the intention > > here. We simply cannot have platforms defining their own format for > > standard properties. > > That ship sailed a long while ago. We have a list of offenders, and we > can make sure we don't get additional ones. > > > Reverting this will cause dtc warnings now (IIRC) and just kicks the > > can down the road. Reverting is fine for now (I gave Arnd the okay on > > IRC), but I think the parsing will need to be updated to honor > > #address-cells and detect an old DT (probably by looking at the total > > size of 'interrupt-map') and mark that change for stable. That would > > only leave a new dt with an old kernel without stable updates broken. > > Seems unlikely a device is getting firmware updates, but not OS > > updates. > > Being able to rollback firmware and OS independently is important. The > tooling can be taught about the broken instances, which should be > enough. Adding to the parsing only makes things harder to maintain, > for no real gain. It's up to individual platforms to care about that. If they don't, then compatibility has been broken multiple times most certainly because in general there is 0 testing for it. Why make our lives more complicated in those cases? Rob
