| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This adds a global map for allocating physical memory address. This
centralises physical memory space allocations into one location rather
than spread through, PHB, XIVE, NX etc.
This adds a new call phys_map_get() which takes a chip, type and index
and returns a address and size for the region to be used.
An error in a call to this function crashes skiboot. This is done
since bogus calls here are going to be hit by developers not users and
they need to be fixed.
Currently only P9 is implemented but other chips should be easy to
add. On P9 BARs are generally set by skiboot. On P8 this was done by
hostboot so this is not needed there.
This just adds the infrastructure. User (PHB4, XIVE etc) will be
migrated in subsequent patches.
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If a downstream PCIe link is down we currently reserve a number of
busses for hot pluggable devices. However we do not need to do this
when we know a slot is not hotplug capable.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Trigging a Host Initiated Reset (when the host detects the FSP has gone
out to lunch and should be rebooted), would cause "Unknown Command" messages
to appear in the OPAL log.
This patch implements those messages
How to trigger FSP RR(HIR):
$ putmemproc 300000f8 0x00000000deadbeef
s1 k0:n0:s0:p00
ecmd_ppc putmemproc 300000f8 0x00000000deadbeef
Log showing unknown command:
/ # cat /sys/firmware/opal/msglog | grep -i ,3
[ 110.232114723,3] FSP: fsp_trigger_reset() entry
[ 188.431793837,3] FSP #0: Link down, starting R&R
[ 464.109239162,3] FSP #0: Got XUP with no pending message !
[ 466.340598554,3] FSP-DPO: Unknown command 0xce0900
[ 466.340600126,3] FSP: Unhandled message ce0900
The message we need to handle is "Get PLID after host initiated FipS
reset/reload". When the FSP comes back from HIR, it asks "hey, so, which
error log explains why you rebooted me?". So, we tell it.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This sets up the per chip RNG MMIO BAR and points the per core DARN
BAR at it.
This is needed on P9 to enabled the DARN instruction (otherwise it'll
cause a xstop).
This includes a minor rework of some #defines to abstract MMIO
definitions.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds two new nvram options to set the console log level for the
driver/uart and in memory. These are called log-level-memory and
log-level-driver.
These are only set once we have nvram inited.
To set them you do:
nvram -p ibm,skiboot --update-config log-level-memory=9
nvram -p ibm,skiboot --update-config log-level-driver=9
You can also use the named versions of emerg, alert, crit, err,
warning, notice, printf, info, debug, trace or insane. ie.
nvram -p ibm,skiboot --update-config log-level-driver=insane
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This will be used by subsequent XIVE reset improvements
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
|
|
Adds two helper functions that allow device nodes to be found via
their name and unit address. One will take an integer address and
format it to a hex string while the other looks up the unit based
a user supplied string. This is handy in a few places inside the
HDAT parser.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The names of the properties under /ibm,opal/firmware/exports are used
directly by Linux to create files in sysfs. To remain consistent with
the existing naming of OPAL sysfs files, use '_' as the separator.
In particular for the symbol map which is already exported separately,
it's cleaner for the two files to have the same name, eg:
/sys/firmware/opal/exports/symbol_map
/sys/firmware/opal/symbol_map
Fixes: 9ffbfe269ec6 ("core/init: Add hdat-map property to OPAL node")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds another PHB callback (device_remove()), corresponding to
device_init(). With it, the PHB3 layer can receive notification
upon PCI topology changes. This functionality will be used by the
subsequent patches.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The NVMe adapter in below PCI topology is lost. The root cause is
the presence bit on its PCI slot is missed, but the PCIe link has
been up. The PCI core doesn't probe the adapter behind the slot,
leading to lost NVMe adapter in the particular case.
PHB3 root port
PLX switch 8748 (10b5:8748)
PLX swich 9733 (10b5:9733)
PMC 8546 swtich (11f8:8546)
NVMe adapter (1c58:0023)
This fixes the issue by overriding the PCI slot presence bit with
PCIe link state bit.
Reported-by: Mark E Schreiter <markes@us.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Mark E Schreiter <markes@us.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We are creating PCI slot on root port, where the PCI slot isn't
supported from hardware. For this case, the surprised hotplug
functionality shouldn't be enabled even the link state change
reporting is supported in hardware.
This disables surprise hotplug if PCI slot isn't supported in
hardware.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We are creating PCI slot on root port, where the PCI slot isn't
supported from hardware. For this case, we shouldn't read the PCI
slot capability from hardware. When bogus data returned from the
hardware, we will attempt to the PCI slot's power state or enable
surprise hotplug functionality. All of them can't be accomplished
without hardware support.
This leaves the PCI slot's capability list 0 if PCICAP_EXP_CAP_SLOT
isn't set in hardware (pcie_cap + 0x2). Otherwise, the PCI slot's
capability list is retrieved from hardware (pcie_cap + 0x14).
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
NVLink2 is a new feature introduced on POWER9 systems. It is an
evolution of of the NVLink1 feature included in POWER8+ systems but
adds several new features including support for GPU address
translation using the Nest MMU and cache coherence.
Similar to NVLink1 the functionality is exposed to the OS as a series
of virtual PCIe devices. However the actual hardware interfaces are
significantly different which limits the amount of common code that
can be shared between implementations in the firmware.
This patch adds basic hardware initialisation and exposure of the
virtual NVLink2 PCIe devices to the running OS.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds an nvram parameter pcie-max-link-speed to configure the max
speed of the pcie link. This can be set from the petitboot prompt
using:
nvram -p ibm,skiboot --update-config pcie-max-link-speed=4
This takes preference over anything set in the device tree and is
global to all PHBs.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Exports the HDAT heap to the OS. This allows the OS to view the HDAT heap
directly. This allows us to view the HDAT area without having to use
getmemproc.
Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Now that we can handle disabling CAPI mode on PHBs, we don't need to
disable fast reboot if there's a CAPI mode PHB.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
On fast reboot, perform a creset of all PHBs. This ensures that any PHBs
that are fenced will be working after the reboot.
A later patch will disable CAPI mode during cresets - as such, PHBs in CAPI
mode will return to regular PCIe mode during a fast reboot.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We have fast reboot now, so pci_reset() is no longer a "remnant" thereof.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When diagnosing or debugging CAPP errors, it's rather useful to have the
CAPP FIR, which often provides very helpful information.
Print the CAPP FIR to the log when we handle a Malfunction Alert HMI for a
CAPP error.
Cc: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
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>
|
|
The logic in decode_malfunction() is rather tricky to follow. Refactor the
code to make it easier to follow.
No functional change.
Cc: Russell Currey <ruscur@russell.cc>
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Cc: Ryan Grimm <grimm@linux.vnet.ibm.com>
Cc: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Cc: Daniel Axtens <dja@axtens.net>
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
For the most part, this gets us somewhere on some OpenPOWER systems
before there's a platform file for that machine.
Useful in bringup only, and marked as such with scary looking log
messages.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The console logging tests use a memcmp and strlen() with string literal
arguments. Unfortunately the strings were updated at some point and not
kept in sync. strcmp() should be fine here so use that instead.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This reduces 'make check' run time by ~10 seconds on my laptop,
and just the run-trace test itself takes 15 seconds less (under valgrind).
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently this is implemented by calling dt_get_address() which only
works when a device is a child of the root node. This patch implements
the functionality to work with nested nodes when all parent nodes have
an appropriate "ranges" property.
This implementation only works for up to 64 bit addresses. Properly
supporting larger addressing schemes is a fair amount of (probably
pointless) work, so I'm leaving supporting that until we have an
actual a need for it.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Tested-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Adding these properties enables the kernel to function in the same way
that it would if it could no longer access BMC configuration registers
through a backdoor, which may become the default in future.
The comments describe how isolating the host from the BMC could be
achieved in skiboot, assuming all kernels that the system boots
support this. Isolating the BMC and the host from each other is
important if they are owned by different parties; for example, a cloud
provider renting machines "bare metal".
Acked-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In future we may want to be able to do fixups for specific PCI devices in
skiboot, so add a small framework for doing this.
This is not intended for the same purposes as quirks in the Linux kernel,
as the PCI devices that quirks can match for in skiboot are not properly
configured. This is intended to enable having a custom path to make
changes that don't directly interact with the PCI device, for example
adding device tree entries.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: fix 0 vs NULL sparse warning, (C) date]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Each LPC interrupt can be routed to one of 4 lines to the PSI
bridge which represent 4 different system interrupts. This
allows LPC clients to request as specific target (Linux or OPAL)
and makes the LPC core pick a route and configure it appropriately.
The UART is updated to properly forward interrupts to Linux
if necessary
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
All callers of buddy_create() are correctly checking return value.
Found by static analysis
Fixes: 8594b9c5bd456205255ea2241ba224f47480efad
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Simplifies the flushing logic so that we only call into
con_driver->write() once. The existing implementation splits the
function into a normal path and a separate path when the in memory
console has wrapped. The logic is the same in both branches and
__flush_console() has enough bizarre crap happening with it's
not-a-lock-but-actually-a-lock flag variable.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Spelling-corrected-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
NVRAM formats are always BE, so let's use the sparse annotation to catch
any issues (and correct said issues).
On LE platforms, the test was erroneously passing as with building the
nvram-format code on LE we were produces an incorrect NVRAM image.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We has to support surprise hotplug on PCI slots that don't support
it on hardware. So we're fully utilizing the PCIe link state change
event to detect the events (hot-remove and hot-add). The PDC (Presence
Detection Change) event isn't reliable for the purpose. For example,
PEX8718 on superMicro's machines.
This adds another PCI slot property "ibm,slot-broken-pdc" in the
device-tree, to indicate the PDC isn't reliable on those (software
claimed) surprise pluggable slots.
Reported-by: Hank Chang <hankmax0000@gmail.com>
Signed-off-by: Gavin Shan <gwhsan@linux.vnet.ibm.com>
Tested-by: Willie Liauw <williel@supermicro.com.tw>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This issue is reported from superMicro's "p8dnu" platform. PEX9733
is connected to PHB direct slot. We create dynamic PCI slots for
its (5) downstream ports and all of them support surprise hotplug
capability. The problem is power supply lost on hot-remove and it
isn't turned on automatically on hot-add. It means the PCIe link
behind the slot isn't up and the PCI adapter behind the slot can't
be probed successfully.
This fixes the issue by forcing to turn on the power supply on
hardware when user (kernel) requests to do so. Those PCI slots
are identified by additional flag (PCI_SLOT_FLAG_FORCE_POWERON).
Reported-by: Hank Chang <hankmax0000@gmail.com>
Signed-off-by: Gavin Shan <gwhsan@linux.vnet.ibm.com>
Tested-by: Willie Liauw <williel@supermicro.com.tw>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The PCI device and its PCIe capability offset should be valid in
pcie_slot_create(). No need to validate them. This removes the
validation logic to make the function simpler. No functional changes
introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In surprise hot-add path, the power state isn't changed on hardware.
Instead, we set the cached power state (@slot->power_state) and
return OPAL_SUCCESS. The upper layer starts the PCI probing immediately
when receiving OPAL_SUCCESS. However, the PCIe link behind the PCI
slot is likely down. Nothing will be probed from the PCI slot even
we do have PCI adpater connected to the slot.
This fixes the issue by returning OPAL_ASYNC_COMPLETION to force
upper layer to poll the PCIe link before probing the PCI devices
behind the slot in surprise and managed hot-add paths.
Cc: stable # 5.4.0+
Fixes: 51931bad325 ("core/pci: Claim surprise hotplug capability")
Reported-by: Hank Chang <hankmax0000@gmail.com>
Signed-off-by: Gavin Shan <gwhsan@linux.vnet.ibm.com>
Tested-by: Willie Liauw <williel@supermicro.com.tw>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
According to PCIe spec, the presence bit is hardcoded to 1 if PCIe
switch downstream port doesn't support slot capability. The register
used for the check in pcie_slot_get_presence_state() is wrong. It
should be PCIe capability register instead of PCIe slot capability
register. Otherwise, we always have present bit on the PCI topology.
The issue is found on Supermicro's p8dtu2u machine:
# lspci -t
-+-[0022:00]---00.0-[01-08]----00.0-[02-08]--+-01.0-[03]----00.0
| \-02.0-[04-08]--
# cat /sys/bus/pci/slots/S002204/adapter
1
# lspci -vvs 0022:02:02.0
# lspci -vvs 0022:02:02.0
0022:02:02.0 PCI bridge: PLX Technology, Inc. PEX 8718 16-Lane, \
5-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ab) (prog-if 00 [Normal decode])
:
Capabilities: [68] Express (v2) Downstream Port (Slot+), MSI 00
:
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
This fixes the issue by checking the correct register (PCIe capability).
Also, the register's value is cached in advance as we did for slot and
link capability.
Fixes: bc66fb67aee ("core/pci: Support PCI slot")
Cc: stable # 5.3.0+
Signed-off-by: Gavin Shan <gwhsan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The power control bit (SLOT_CTL, offset: PCIe cap + 0x18) isn't
reliable enough to reflect the PCI slot's power state. Instead,
the power indication bits are more reliable comparatively. This
leads to mismatch between the cached power state and PCI slot's
presence state, resulting in the hotplug driver in kernel refuses
to unplug the devices properly on the request. The issue was
found on below NVMe card on "supermicro,p8dtu2u" machine. We don't
have this issue on the integrated PLX 8718 switch.
# lspci
0022:01:00.0 PCI bridge: PLX Technology, Inc. PEX 9733 33-lane, \
9-port PCI Express Gen 3 (8.0 GT/s) Switch (rev aa)
0022:02:01.0 PCI bridge: PLX Technology, Inc. PEX 9733 33-lane, \
9-port PCI Express Gen 3 (8.0 GT/s) Switch (rev aa)
0022:02:04.0 PCI bridge: PLX Technology, Inc. PEX 9733 33-lane, \
9-port PCI Express Gen 3 (8.0 GT/s) Switch (rev aa)
0022:02:05.0 PCI bridge: PLX Technology, Inc. PEX 9733 33-lane, \
9-port PCI Express Gen 3 (8.0 GT/s) Switch (rev aa)
0022:02:06.0 PCI bridge: PLX Technology, Inc. PEX 9733 33-lane, \
9-port PCI Express Gen 3 (8.0 GT/s) Switch (rev aa)
0022:02:07.0 PCI bridge: PLX Technology, Inc. PEX 9733 33-lane, \
9-port PCI Express Gen 3 (8.0 GT/s) Switch (rev aa)
0022:17:00.0 Non-Volatile memory controller: Device 19e5:0123 (rev 45)
This updates the cached PCI slot's power state using the power
indication bits instead of power control bit, to fix above issue.
Cc: stable #5.4.0+
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The ibm,opal node is normally created by Skiboot either in the HDAT parser
or after the input FDT has been unflattened. However, in order to supply
the /ibm,opal/power-mgt/enabled-stop-states property FDT we to tolerate
/ibm,opal/ existing in the input tree.
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>
|
|
Commit 5ac71c9 ("pci: Avoid hot resets at boot time") missed to
avoid hot reset after fundamental reset for PCIe common slots.
This fixes it.
Cc: stable # 5.3.x
Reported-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently, skiboot can't see SRIOV VFs. It introduces some troubles
as I can see: The device initialization logic (phb->ops->device_init())
isn't applied to VFs, meaning we have to maintain same and duplicated
mechanism in kernel for VFs only. It introduces difficulty to code
maintaining and prone to lose sychronization.
This was motivated by bug reported by Carol: The VF's Max Payload
Size (MPS) isn't matched with PF's on Mellanox's adapter even kernel
tried to make them same. It's caused by readonly PCIECAP_EXP_DEVCTL
register on VFs. The skiboot would be best place to emulate this bits
to eliminate the gap as I can see.
This supports SRIOV VFs. When the PF's SRIOV capability is populated,
the number of maximal VFs (struct pci_device) are instanciated, but
but not usable yet. In the mean while, PCI config register filter is
registered against PCIECAP_SRIOV_CTRL_VFE to capture the event of
enabling or disabling VFs. The VFs are initialized, put into the PF's
children list (pd->children), populate its PCI capabilities, and
register PCI config register filter against PCICAP_EXP_DEVCTL. The
filter's handler caches what is written to MPS field and returns
the cached value on read, to eliminate the gap mentioned as above.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When we start to support SRIOV capability in subsequent patches,
a data struct will be instantiated and associated with the SRIOV
capability. This extends the current implementation for that.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently, AER capability is initialized in phb_ops->device_init()
which is called after the device is instantiated by PCI core, or
reinitializing the device after reset in EEH recovery path. It
means we are maintaining similar sets of codes for P7IOC, PHB3
and PHB4.
This moves the logic initializing AER capability from P7IOC, PHB3
and PHB4 to PCI core, thus the duplicated codes can be dropped.
No functional changes introduced by this.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The logic initializing device's PCIe capability is resident in the
function pci_scan_one() from day one. It's because information
(e.g. vendor/device IDs) aren't stored into PCI device instance in
old days. Now, the PCI device instance contains all information
required to initialize its PCIe capability and others.
This moves the logic initializing PCIe capability from pci_scan_one()
to separate functions, pci_init_capabilities() and pci_init_pcie_cap().
pci_scan_one() is simplified to make code maintaining a bit easier.
Also, it will allow us to intorduce separate functions to initialize other
capabilities as we're doing for PCIe capability.
This also exports pci_init_capabilities() so that it can be reused by
SRIOV VFs in future. No logical changes introduced by this.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Provide an experimental option to compile using ELFv2 ABI even on big
endian builds. ELFv2 + BE is not officially supported by the toolchain,
but it works quite well. It may be useful as a small step toward a
little-endian build.
This saves about 200kB of text/data.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Handle the OSYS record on OPP machines in stead of VSYS
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fixes: 539487bae4b77
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The bmc_platform pointer is set to NULL by default and on non-AMI BMC
platforms. As a result a few places in hw/ipmi/ipmi-sel.c will blindly
dereference a NULL pointer.
This patch sets the default value for bmc_platform to generic_bmc to
avoid this.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Adds a function to check whether a blob is a valid IBM ASCII keyword
VPD blob. This allows us to recognise when we do and do not have a VPD
blob and act accordingly.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
[stewart@linux.vnet.ibm.com: check if initial 0x84 exists. Spotted by Vasant]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This is similar to dt_new(), but if the node already exists it will
return the existing node. This is useful because some init code depends
on the presence of certain nodes, but where the node is actually created
is unimportant.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
