[PATCH 29/38] powerpc: Move 32-bit probe() machine to later in the boot process

Gerhard Pircher gerhard_pircher at gmx.net
Tue Jun 28 06:42:18 AEST 2016


Am 2016-06-27 um 13:29 schrieb Benjamin Herrenschmidt:
> This converts all the 32-bit platforms to use the expanded device-tree
> which is a pretty mechanical change. Unlike 64-bit, the 32-bit kernel
> didn't rely on platform initializations to setup the MMU since it
> sets it up entirely before probe_machine() so the move has comparatively
> less consequences though it's a bigger patch.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh at kernel.crashing.org>

[...]

> diff --git a/arch/powerpc/platforms/amigaone/setup.c b/arch/powerpc/platforms/amigaone/setup.c
> index 2fe1204..a030d3b 100644
> --- a/arch/powerpc/platforms/amigaone/setup.c
> +++ b/arch/powerpc/platforms/amigaone/setup.c
> @@ -143,9 +143,7 @@ void amigaone_restart(char *cmd)
>  
>  static int __init amigaone_probe(void)
>  {
> -	unsigned long root = of_get_flat_dt_root();
> -
> -	if (of_flat_dt_is_compatible(root, "eyetech,amigaone")) {
> +	if (of_machine_is_compatible("eyetech,amigaone")) {
>  		/*
>  		 * Coherent memory access cause complete system lockup! Thus
>  		 * disable this CPU feature, even if the CPU needs it.
This patch series reminds me of a long-standing issue with the
AmigaOne platform code, which would have to clear the coherence
(M) flag for every memory mapping to avoid lockups (especially
on G4 CPUs) - as you can read in the comment below your patch
above.

Now the follow-up code in amigaone/setup.c to clear the
corresponding CPU feature flag is essentially dead code (it used
to work with a second call of do_feature_fixups() before the
handling of the CPU_FTR_NEED_COHERENT flag was changed/inverted
somewhere around v2.6.30). Also it doesn't seem to fix all
deadlocks, as e.g. KVM virtual machines can still inject memory
mappings with the M flag set AFAICT.

Now I wonder, if there is a reasonably clean way to clear the M
flag in all hardware page table and BAT entries without defacing
generic kernel code too much. Any ideas?

BR,
Gerhard


More information about the Linuxppc-dev mailing list