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. M. -- Without deviation from the norm, progress is not possible.
