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