powerpc/64s: Save FSCR to init_task.thread.fscr after feature init
authorMichael Ellerman <mpe@ellerman.id.au>
Wed, 27 May 2020 14:58:42 +0000 (00:58 +1000)
committerMichael Ellerman <mpe@ellerman.id.au>
Tue, 2 Jun 2020 10:59:18 +0000 (20:59 +1000)
commit912c0a7f2b5daa3cbb2bc10f303981e493de73bd
tree0e2f1fd0cdd19960104f845f6755f6ebd0943ac4
parent993e3d96fd08c3ebf7566e43be9b8cd622063e6d
powerpc/64s: Save FSCR to init_task.thread.fscr after feature init

At boot the FSCR is initialised via one of two paths. On most systems
it's set to a hard coded value in __init_FSCR().

On newer skiboot systems we use the device tree CPU features binding,
where firmware can tell Linux what bits to set in FSCR (and HFSCR).

In both cases the value that's configured at boot is not propagated
into the init_task.thread.fscr value prior to the initial fork of init
(pid 1), which means the value is not used by any processes other than
swapper (the idle task).

For the __init_FSCR() case this is OK, because the value in
init_task.thread.fscr is initialised to something sensible. However it
does mean that the value set in __init_FSCR() is not used other than
for swapper, which is odd and confusing.

The bigger problem is for the device tree CPU features case it
prevents firmware from setting (or clearing) FSCR bits for use by user
space. This means all existing kernels can not have features
enabled/disabled by firmware if those features require
setting/clearing FSCR bits.

We can handle both cases by saving the FSCR value into
init_task.thread.fscr after we have initialised it at boot. This fixes
the bug for device tree CPU features, and will allow us to simplify
the initialisation for the __init_FSCR() case in a future patch.

Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features")
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200527145843.2761782-3-mpe@ellerman.id.au
arch/powerpc/kernel/prom.c