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

On Thu, Nov 11, 2021 at 2:20 AM Marc Zyngier [off-list ref] wrote:

On Thu, 11 Nov 2021 07:47:08 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

quoted

On Thu, 11 Nov 2021 05:24:52 +0000,
Christian Zigotzky [off-list ref] wrote:

quoted

Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.

quoted

We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

    M.

I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.

Thanks for that. The DT looks absolutely bonkers, no wonder that
things break with something like that.

But Darren's comments made me jump a bit, and I quote them here for
everyone to see:

<quote>
[...]

The dtb passed by the CFE firmware has a number of issues, which up till
now have been fixed by use of patches applied to the mainline kernel.
This occasionally causes problems with changes made to mainline.

[...]
</quote>

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.



-Olof