On Thu, Nov 11, 2021 at 02:21:46PM -0800, Olof Johansson wrote: > On Thu, Nov 11, 2021 at 2:20 AM Marc Zyngier <maz@xxxxxxxxxx> wrote: > > Am I right in understanding that the upstream kernel does not support > > the machine out of the box, and that you actually have to apply out of > > tree patches to make it work? That these patches have to do with the > > IRQ routing? > > To my knowledge that has never been needed -- that the base platform > support is all there. > > This is an old platform, and just like with the power macs, the > devicetree is indeed supplied from firmware, and as such not easily > patchable like with ARM platforms. > > Last time this was an issue (to my memory) was when they enabled > automatic little endian switching in the boot path, that caused some > issues with a (bad) phandle pointer that had gone undiscovered for 10+ > years. > > > If so, I wonder why upstream should revert a patch to work on a system > > that isn't supported upstream the first place. I will still try and > > come up with a solution for you. But asking for the revert of a patch > > on these grounds is not, IMHO, acceptable. Also, please provide these > > patches on the list so that I can help you to some extend (and I mean > > *on the list*, not on a random forum that collects my information). > > Early fixups of DT is the way to go here, if needed -- we do it on > some other platforms. That can happen in-kernel, and keep the new > functionality. For that we'd need to figure out what's actually wrong > with the DT as such right now. Yup. The scheme we have now (copy all info from OF, and then take over everything at once) is not ideal at all, but treating OF systems just like "bare" systems has advantages as well, including making it easier to fix up the device tree if it has problems. This is much superior to changing all consumers (drivers etc.) to deal with the broken device trees, so we should do it much more often :-) Segher
