| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Presence detection is not part of the opencapi specification. So each
platform may choose to implement it the way it wants.
All current platforms implement it through an i2c device where we can
query a pin to know if a device is connected or not. ZZ and Zaius have
a similar design and even use the same i2c information and pin
numbers.
However, presence detection on older ZZ planar (older than v4) doesn't
work, so we don't activate it for now, until our lab systems are
upgraded and it's better tested.
Presence detection on witherspoon is still being worked on. It's
shaping up to be quite different, so we may have to revisit the topic
in a later patch.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
P9 onwards OPAL is building device tree for BMC based system using
HDAT. We are populating bmc/compatible node with bmc version. Hence
do not delete this property.
CC: Jeremy Kerr <jk@ozlabs.org>
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 0x3a OEM command is for IBM commands, while 0x32 was for AMI ones.
Sometime in the P8 timeframe, AMI BMCs were changed to listen for our
commands on either 0x32 or 0x3a. Since 0x3a is the direction forward,
we'll use that, as P9 machines with AMI BMCs probably also want these
to work, and let's not bet that 0x32 will continue to be okay.
Suggested-by: Joseph Reynolds <jrey@us.ibm.com>
Suggested-by: Maury Zipse <zipse@us.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out this is the IBM way to do this and we (OPAL) were just
never really told about the change.
So, with the best public docs that are available being Hostboot
source, let's make the change!
See https://github.com/open-power/hostboot/blob/8e05a4399b/src/include/usr/ipmi/ipmiif.H#L115
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the slot table init happens twice in both probe and init
functions due to the variant detection logic called with in-correct
condition check.
Fixes: d32ddea9 ("p9dsu: detect p9dsu variant even when hostboot
doesn't tell us")
Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
[stewart: renanem variant-detected to p9dsu-riser-detected]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BMC Get device ID command gives BMC firmware version details. Lets add this
to device tree. User space tools will use this information to display BMC
version details.
Stewart,
I have added bmc information under /ibm,firmware-version node as its firmware
version. But may be we should add new node (/bmc/firmware). So that we can
keep BMC related information separately. Let me know your thoughts on this.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SuperMicro BMC can tell us what riser type we have, which dictates
the PCI slot tables. Usually, in an environment that a customer would
experience, Hostboot will do the query with an SMC specific patch
(not upstream as there's no platform specific code in hostboot)
and skiboot knows what variant it is based on the compatible string.
However, if you're using upstream hostboot, you only get the bare
'p9dsu' compatible type. We can work around this by asking the BMC
ourselves and setting the slot table appropriately. We do this
syncronously in platform init so that we don't start probing
PCI before we setup the slot table.
This adds a bit of funky logic in the p9dsu platform file, but on
the whole makes things simpler.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Jim Yuan <jim.yuan@supermicro.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
| |
Signed-off-by: Jim Yuan <jim.yuan@supermicro.com>
[stewart: remove trailing whitespace, incorrect BMC comment]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Jim Yuan <jim.yuan@supermicro.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Jim Yuan <jim.yuan@supermicro.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Add support for sourcing power limit information from either the DT slot
heirachy or the slot table.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Add slot tables for romulus. Hopefully they won't be needed in THE
FUTURE!
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Add some helper macros for the common case of a slot, or builtin
device directly under a PHB or switch port.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
matching slots"
This reverts commit bda7cc4d0354eb3f66629d410b2afc08c79f795f.
Ben says:
It's on purpose that we do NOT compare the bus numbers,
they are always 0 in the slot table
we do a hierarchical walk of the tree, matching only the
devfn's along the way bcs the bus numbering isn't fixed
this breaks all slot naming etc... stuff on anything using
the "skiboot" slot tables (P8 opp typically)
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Artem Senichev <a.senichev@yadro.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add OpenCAPI platform data for the zaius and zz platforms, as well as the
generic platform that's used for BML boots. Currently, all three platforms
are identical, but that won't always be the case (e.g. Witherspoon).
Additionally, for Zaius, hardcode link information and the I2C bus that's
required to reset OpenCAPI devices, because this currently can't be
extracted from HDAT. Eventually this will go away once Hostboot adds the
relevant data in HDAT. A later patch will add this for ZZ once we've done
more testing.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes to build system to use thin archives rather than
incremental linking for built-in.o, similar to recent change to Linux.
built-in.o is renamed to built-in.a, and is created as a thin archive
with no index, for speed and size. All built-in.a are aggregated into
a skiboot.tmp.a which is a thin archive built with an index, making it
suitable or linking. This is input into the final link.
The advantags of build size and linker code placement flexibility are
not as great with skiboot as a bigger project like Linux, but it's a
conceptually better way to build, and is more compatible with link
time optimisation in toolchains which might be interesting for skiboot
particularly for size reductions.
Size of build tree before this patch is 34.4MB, afterwards 23.1MB.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support to read u64 sensor values. This also adds
changes to the core and the backend implementation code to make this
API as the base call. Host can use this new API to read sensors
upto 64bits.
This adds a list to store the pointer to the kernel u32 buffer, for
older kernels making async sensor u32 reads.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
There are userspace tools that update the planar VPD via the sysfs
interface. Currently we do not get correct information from hostboot
about the exact type of the EEPROM so we need to manually fix it up
here. This needs to be done as a platform specific fix since there is
not standardised VPD EEPROM type.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An old Witherspoon platform definition was added to aid the transition from
versions of Hostboot which didn't have the correct NVLink HDAT information
available and/or planar VPD. These system should now be updated so remove
the possibly incorrect default assumption.
This may disable NVLink on old out-dated systems but it can easily be
restored with the appropriate FW and/or VPD updates. In any case there is a
a 50% chance the existing default behaviour was incorrect as it only
supports 6 GPU systems. Using an incorrect platform definition leads to
undefined behaviour which is more difficult to detect/debug than not
creating the NVLink devices so remove the possibly incorrect default
behaviour.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Witherspoon introduced a new concept where one physical slot is shared
between two PHBs. Making a slot aware of its peer enables syncing
between them where necessary.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
See 696d378d7b7295366e115e89a785640bf72a5043 for all the details.
Suggested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had a race condition between FSP Reset/Reload and powering down
the system from the host:
Roughly:
FSP Host
--- ----
Power on
Power on
(inject EPOW)
(trigger FSP R/R)
Processes EPOW event, starts shutting down
calls OPAL_CEC_POWER_DOWN
(is still in R/R)
gets OPAL_INTERNAL_ERROR, spins in opal_poll_events
(FSP comes back)
spinning in opal_poll_events
(thinks host is running)
The call to OPAL_CEC_POWER_DOWN is only made once as the reset/reload
error path for fsp_sync_msg() is to return -1, which means we give
the OS OPAL_INTERNAL_ERROR, which is fine, except that our own API
docs give us the opportunity to return OPAL_BUSY when trying again
later may be successful, and we're ambiguous as to if you should retry
on OPAL_INTERNAL_ERROR.
For reference, the linux code looks like this:
>static void __noreturn pnv_power_off(void)
>{
> long rc = OPAL_BUSY;
>
> pnv_prepare_going_down();
>
> while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
> rc = opal_cec_power_down(0);
> if (rc == OPAL_BUSY_EVENT)
> opal_poll_events(NULL);
> else
> mdelay(10);
> }
> for (;;)
> opal_poll_events(NULL);
>}
Which means that *practically* our only option is to return OPAL_BUSY
or OPAL_BUSY_EVENT.
We choose OPAL_BUSY_EVENT for FSP systems as we do want to ensure we're
running pollers to communicate with the FSP and do the final bits of
Reset/Reload handling before we power off the system.
Additionally, we really should update our documentation to point all
of these return codes and what action an OS should take.
CC: stable
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DECLARE_PLATFORM macro takes the supplied platform name and adds "_platform"
to it when defining the platform struct.
Remove the _platform from the platform name for zaius and romulus so we have
"zaius_platform" rather than "zaius_platform_platform", for consistency's
sake...
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
In the future we will always create the npu nodes based on what's in the
HDAT. For now we seperate witherspoon into an old and new platform where
the old platform will assume a sequoia planar and create the relevant
NPU nodes for that planar. If you have a redbud system this will be
broken, but this should be fine for most cases.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Add the other PCIe devices to the witherspoon slot tables. This provides
a fall back for systems without IOSLOT information in the HDAT. This is
mainly to allow DD1 systems to continue being useful.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Move this out of the astbmc specific part into a generic helper. This
allows us to use it more commonly.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
astbmc has some code to handle devices that are behind a "slot" on a
riser card that can't be added to the static slot tables for a system.
We probably want to use this code outside the slot table handling so
move it somewhere generic and rework it so slot table specifics aren't
buried inside it.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
PHB4_SHARED_SLOT_IDX_WITHERSPOON is the index of the PHB which the
shared slot is connected to rather than the index of the shared slot
which the name suggests. This is confusing at best so this patch
replaces the only usages of this macro with just the PHB number
and a comment.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In P8, hostboot provides mini device tree. It contains /ibm,firmware-versions
node which has various firmware component version details.
In P9, OPAL is building device tree. This patch adds support to parse VERSION
section of PNOR and create "/ibm,firmware-versions" device tree node.
Sample output:
/sys/firmware/devicetree/base/ibm,firmware-versions # lsprop .
occ "6a00709"
skiboot "v5.7-rc1-p344fb62"
buildroot "2017.02.2-7-g23118ce"
capp-ucode "9c73e9f"
petitboot "v1.4.3-p98b6d83"
sbe "02021c6"
open-power "witherspoon-v1.17-128-gf1b53c7-dirty"
....
....
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
OPAL currently doesn't know about the 2s2u zz. It recognizes such a
box as a generic BMC machine and fails to boot. Add the 2s2u as a
supported platform.
There will subsequently be a 2s2u-L system which may have a different
compatible property, which will need to be handled later.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenBMC stack added IPMI OEM extension to log eSEL events.
Lets enable eSEL logging from OPAL side.
See: https://github.com/openbmc/openpower-host-ipmi-oem/blob/d9296050bcece5c2eca5ede0932d944b0ced66c9/oemhandler.cpp#L142
(yes, that is the documentation)
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: remove pnor access request, add link to OpenBMC doc]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
For NVLink2 to function PCIe devices need to be associated with the right
NVLinks. This association is supposed to be passed down to Skiboot via HDAT but
those fields are still not correctly filled out. To work around this we add slot
tables for the NVLinks similar to what we have for P8+.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
When matching devices on multiple down stream PLX busses we need to compare more
than just the device-id of the PCIe BDFN, so increase the mask to do so.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The platform isn't compatible with palmetto until the root device-tree
node's "model" property is NULL or "palmetto". However, we could have
"TN71-BP012" for the property on palmetto.
linux# cat /proc/device-tree/model
TN71-BP012
This skips the validation on root device-tree node's "model" property
on palmetto, meaning we check the "compatible" property only.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implmentation has incorrect assumptions: there is
always a PCI slot associated with root port and PCIe switch
downstream port and all of them are capable to change its
power state by register PCICAP_EXP_SLOTCTL. Firstly, there
might not a PCI slot associated with the root port or PCIe
switch downstream port. Secondly, the power isn't controlled
by standard config register (PCICAP_EXP_SLOTCTL). There are
I2C slave devices used to control the power states on Tuleta.
In order to use the PCI slot's methods to manage the power
states, this does:
* Introduce PCI_SLOT_FLAG_ENFORCE, indicates the request operation
is enforced to be applied.
* pci_enable_bridge() is split into 3 functions: pci_bridge_power_on()
to power it on; pci_enable_bridge() as a place holder and
pci_bridge_wait_link() to wait the downstream link to come up.
* In pci_bridge_power_on(), the PCI slot's specific power management
methods are used if there is a PCI slot associated with the PCIe
switch downstream port or root port.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This refactors firenze_pci_setup_power_mgt() and no logicial changes
introduced:
* Avoid nested if block;
* Remove the local variable @buddy. The information is retrieved
directly from struct firenze_pci_slot_info::buddy;
* Comments to explain the fixed register offset (0x69) for slot's
power control and shared power state between local slot and its
buddy.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces another data struct to describe the PCI slot fixup
information. With that, the PCI slot fixup information table is
decoupled from the PCI slot information table, to make the code
easier to be maintained. In the meanwhile, the PCI slot information
struct, which has been complexed, is simplified. It shouldn't
introduce any functional changes.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When powering off the PCI slot, the corresponding bits should
be set to 0bxx00xx00 instead of 0bxx11xx11. Otherwise, the
specified PCI slot can't be put into power-off state. Fortunately,
it didn't introduce any side-effects so far.
Cc: stable # 5.3.0+
Fixes: 6884fe63ba1e ("platforms/ibm-fsp: Support PCI slot")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
In P9 FSP box, OCC image is pre-loaded. So do not handle the load
command and send SUCCESS to FSP on recieving OCC_LOAD mbox message.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Witherspoon systems come with a 'shared' PCI slot: physically, it
looks like a x16 slot, but it's actually two x8 slots connected to two
PHBs of two different chips. Taking advantage of it requires some
logic on the PCI adapter. Only the Mellanox CX5 adapter is known to
support it at the time of this writing.
This patch enables support for the shared slot on witherspoon if a x16
adapter is detected. Each x8 slot has a presence bit, so both bits
need to be set for the activation to take place. Slot sharing is
activated through a gpio.
Note that there's no easy way to be sure that the card is indeed a
shared-slot compatible PCI adapter and not a normal x16 card. Plugging
a normal x16 adapter on the shared slot should be avoided on
witherspoon, as the link won't train on the second slot, resulting in
a timeout and a longer boot time. Only the first slot is usable and
the x16 adapter will end up using only half the lines.
If the PCI card plugged on the physical slot is only x8 (or less),
then the presence bit of the second slot is not set, so this patch
does nothing. The x8 (or less) adapter should work like on any other
physical slot.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: re-org code, move into platform file]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out GCC7 adds a useful warning and does fancy things like
parsing your comments to work out that you intended to do the fallthrough.
There's a few places where we don't match the regex. Fix them, as it's
harmless to do so.
Found by building on Fedora Rawhide in Travis.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Previously the PRD tooling ran on the FSP, but it was moved into
userspace on the host for OpenPower systems. For P9 this system
was adopted for FSP systems too.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
Add p9dsu platform (AKA Boston).
Signed-off-by: Jim Yuan <jim.yuan@supermicro.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
|
|
|
|
|
|
|
|
|
| |
This function is specific to how Skiboot's P8 PSIHB driver. For P9 the
PSIHB driver has been reworked completely and this doesn't do anything.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Acked-By: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|