Re: NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.

[Scott Wood <oss@buserror.net>]

On Mon, 2018-07-09 at 09:38 +0100, Tim Small wrote:
> On 06/07/18 19:41, Scott Wood wrote:
> > > My openwrt patch
> > > just does a:
> > > 
> > > /delete-node/  crypto@30000;
> > > 
> > > after the p1010si-post.dtsi include.
> > 
> > U-Boot should already be removing the node on non-E chips -- see
> > ft_cpu_setup() in arch/powerpc/cpu/mpc85xx/fdt.c
> 
> 
> Hi Scott,
> 
> Thanks for your email.  The device in question ships an old uboot (a 
> vendor fork of U-Boot 2010.12-svn15934).

This was added by commit 6b70ffb9d1b2e, committed in July 2008... maybe
there's a problem with the old U-Boot finding the crypto node on this
particular chip?

> I am right in saying that the right fix is to either:
> 
> Use a bootloader (such as current upstream uboot) which adjusts the 
> device tree properly...
> 
> or:
> 
> In the case (such as OpenWRT) where the preferred installation method is 
> to retain the vendor bootloader, then the distro kernel should handle 
> the device tree fixup itself?

The NXP PPC device trees in the kernel are meant to be completed by U-Boot
(years ago I repeatedly suggested that the trees be moved into the U-Boot
source to reflect this, but nobody seemed interested).  Generally that is
mainline and  NXP SDK U-Boot, but a board dts file might cater to some other
U-Boot fork (or   other bootloader) if that's what ships on the board.  Does
this hardware have a board dts file in mainline Linux?

-Scott