linux.git/arch/powerpc/kernel/prom_init.c, branch v4.4.24

powerpc/prom: Fix sub-processor option passed to ibm, client-architecture-support

2016-10-07T13:23:46+00:00

commit 66443efa83dc73775100b7442962ce2cb0d4472e upstream.

When booting from an OpenFirmware which supports it, we use the
"ibm,client-architecture-support" firmware call to communicate
our capabilities to firmware.

The format of the structure we pass to firmware is specified in
PAPR (Power Architecture Platform Requirements), or the public version
LoPAPR (Linux on Power Architecture Platform Reference).

Referring to table 244 in LoPAPR v1.1, option vector 5 contains a 4 byte
field at bytes 17-20 for the "Platform Facilities Enable". This is
followed by a 1 byte field at byte 21 for "Sub-Processor Represenation
Level".

Comparing to the code, there we have the Platform Facilities
options (OV5_PFO_*) at byte 17, but we fail to pad that field out to its
full width of 4 bytes. This means the OV5_SUB_PROCESSORS option is
incorrectly placed at byte 18.

Fix it by adding zero bytes for bytes 18, 19, 20, and comment the bytes
to hopefully make it clearer in future.

As far as I'm aware nothing actually consumes this value at this time,
so the effect of this bug is nil in practice.

It does mean we've been incorrectly setting bit 15 of the "Platform
Facilities Enable" option for the past ~3 1/2 years, so we should avoid
allocating that bit to anything else in future.

Fixes: df77c7992029 ("powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8")
Signed-off-by: Michael Ellerman 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: Fix IBM_ARCH_VEC_NRCORES_OFFSET since POWER8NVL was added

2016-07-27T16:47:28+00:00

commit 2c2a63e301fd19ccae673e79de59b30a232ff7f9 upstream.

The recent commit 7cc851039d64 ("powerpc/pseries: Add POWER8NVL support
to ibm,client-architecture-support call") added a new PVR mask & value
to the start of the ibm_architecture_vec[] array.

However it missed the fact that further down in the array, we hard code
the offset of one of the fields, and then at boot use that value to
patch the value in the array. This means every update to the array must
also update the #define, ugh.

This means that on pseries machines we will misreport to firmware the
number of cores we support, by a factor of threads_per_core.

Fix it for now by updating the #define.

Fixes: 7cc851039d64 ("powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call")
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call

2016-06-24T17:18:20+00:00

commit 7cc851039d643a2ee7df4d18177150f2c3a484f5 upstream.

If we do not provide the PVR for POWER8NVL, a guest on this system
currently ends up in PowerISA 2.06 compatibility mode on KVM, since QEMU
does not provide a generic PowerISA 2.07 mode yet. So some new
instructions from POWER8 (like "mtvsrd") get disabled for the guest,
resulting in crashes when using code compiled explicitly for
POWER8 (e.g. with the "-mcpu=power8" option of GCC).

Fixes: ddee09c099c3 ("powerpc: Add PVR for POWER8NVL processor")
Signed-off-by: Thomas Huth 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

vTPM: get the buffer allocated for event log instead of the actual log

2015-10-18T23:01:23+00:00

The OS should ask Power Firmware (PFW) for the size of the buffer
allocated for the event log, instead of the size of the actual
event log.  It then passes the buffer adddress and size to PFW in
the handover process, into which PFW copies the log.

Signed-off-by: Hon Ching(Vicky) Lo 
Signed-off-by: Peter Huewe

vTPM: reformat event log to be byte-aligned

2015-10-18T23:01:23+00:00

The event log generated by OpenFirmware in PowerPC is 4-byte aligned.
This patch reformats the log to be byte-aligned for the Linux client.

Signed-off-by: Hon Ching(Vicky) Lo 
Signed-off-by: Peter Huewe

vTPM: fix searching for the right vTPM node in device tree

2015-10-18T23:01:22+00:00

Replace all occurrences of '/ibm,vtpm' with '/vdevice/vtpm',
as only the latter is guanranteed to be available for the client OS.
The '/ibm,vtpm' node should only be used by Open Firmware, which
is susceptible to changes.

Signed-off-by: Hon Ching(Vicky) Lo 
Signed-off-by: Peter Huewe

powerpc: Add macros for the ibm_architecture_vec[] lengths

2015-07-13T05:46:04+00:00

The encoding of the lengths in the ibm_architecture_vec array is
"interesting" to say the least. It's non-obvious how the number of bytes
we provide relates to the length value.

In fact we already got it wrong once, see 11e9ed43ca8a "Fix up
ibm_architecture_vec definition".

So add some macros to make it (hopefully) clearer. These at least have
the property that the integer present in the code is equal to the number
of bytes that follows it.

Signed-off-by: Michael Ellerman 
Reviewed-by: Stewart Smith

PCI: Remove unnecessary #includes of

2015-06-08T12:56:09+00:00

In include/linux/pci.h, we already #include , so we don't need
to include  directly.

Remove the unnecessary includes.  All the files here already include
.

Signed-off-by: Bjorn Helgaas 
Acked-by: Simon Horman 	# sh
Acked-by: Ralf Baechle

powerpc: Reword the "returning from prom_init" message

2015-04-10T10:02:48+00:00

We get way too many bug reports that say "the kernel is hung in
prom_init", which stems from the fact that the last piece of output
people see is "returning from prom_init".

The kernel is almost never hung in prom_init(), it's just that it's
crashed somewhere after prom_init() but prior to the console coming up.

The existing message should give a clue to that, ie. "returning from"
indicates that prom_init() has finished, but it doesn't seem to work.
Let's try something different.

This prints:

  Quiescing Open Firmware ...
  Booting Linux via __start() ...

Which hopefully makes it clear that prom_init() is not the problem, and
although __start() probably isn't either, it's at least the right place
to begin looking.

Signed-off-by: Michael Ellerman 
Wistfully-Acked-by: Jeremy Kerr

powerpc/powernv: Remove OPAL v1 takeover

2014-06-25T03:10:47+00:00

In commit 27f4488872d9 "Add OPAL takeover from PowerVM" we added support
for "takeover" on OPAL v1 machines.

This was a mode of operation where we would boot under pHyp, and query
for the presence of OPAL. If detected we would then do a special
sequence to take over the machine, and the kernel would end up running
in hypervisor mode.

OPAL v1 was never a supported product, and was never shipped outside
IBM. As far as we know no one is still using it.

Newer versions of OPAL do not use the takeover mechanism. Although the
query for OPAL should be harmless on machines with newer OPAL, we have
seen a machine where it causes a crash in Open Firmware.

The code in early_init_devtree() to copy boot_command_line into cmd_line
was added in commit 817c21ad9a1f "Get kernel command line accross OPAL
takeover", and AFAIK is only used by takeover, so should also be
removed.

Signed-off-by: Michael Ellerman 
Signed-off-by: Benjamin Herrenschmidt