[PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

[Segher Boessenkool]

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 at kernel.org> 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