| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
90% of what we print isn't useful to a normal user. This
dramatically reduces the amount of messages printed by
OPAL in normal circumstances.
We still need to add a way to bump the log level at boot
based on a BMC scratch register or some HDAT property.
Signed-off-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>
|
|
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>
|
|
The device type should be fixed to downstream port when it seats
behinds behind a upstream port, which is connected to root port
directly and its VDID is 0x874810b5.
This reorders the conditions to make it a bit obvious: parent,
parent's device type, device's VDID and device type in sequence.
No logicial changes.
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>
|
|
This uses macro as PCI config register (vendor ID) offset because
it's more indicative.
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 PCI device vendor/device IDs have been cached to pd->vdid, no
need to pass them in pci_handle_quirk(). This also introduces two
macros to extract vendor/device fields and they are useful afterwards.
No logical changes introduced.
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>
|
|
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>
|
|
Otherwise, in simulators such as Mambo, we needlessly wait 20ms, which
takes much longer than 20ms to do, because simulator.
Fixes: 41b14f9452c25f3dd74a8304763a3cc58bff019f
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
As the PHB presence logic has a debounce timer that can take
a while to settle.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
As current revisions of PHB4 don't properly handle the resulting
L1 link transition.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Move phb3_pcicfg_filter() to pci.c, rename it to pci_handle_cfg_filters()
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This avoids doing a search through the list of all devices on
every config space access to every device under a PHB.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This renames the "poll" op to "run_sm" (short for run state machine).
I think this is a better name since the function does a bunch of
things like reseting the slot. Also it avoids confusion with the
"poll_link" op which does something different (and can even be called
from run_sm).
No functional change.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
PHB and PE numbers are sometimes printed as decimal and sometimes as
hexadecimal, which is confusing. Standardise on hexadecimal.
This is especially useful now that PHB numbers in Linux always match
their OPAL ID.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
I made the inappropriate assumption: PCI slot's power state is
always on from the beginning. We don't check the slot's power
state before turning it off in PCI enumeration path when there
are no PCI adapters behind the slot. The PCI slot's power might
have been turned off and we needn't power it off again. Otherwise,
the below (not harmful) message is raised:
[ 47.243635711,5] SkiBoot skiboot-5.4.0-rc1 starting...
:
[ 13.239871630,5] PHB#0001:02:01.0 Error -1 powering off slot
This checks power state and avoid turning it off again if it's
already in off state. Flag PCI_SLOT_FLAG_BOOTUP is also removed
after the requested operation is completed as the flag should
be used at skiboot booting stage.
Cc: stable # 5.3.0+
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When RC's downstream link is down, we need reserve spare PCI buses
if it has an associated PCI hotplug slot. Otherwise, the adapter
behind it can't be probed successfully in PCI hot add scenario.
This reserves all available buses (to 255) for RC's hotplug slot
when its downstream is down so that PCI adapter can be hot added
to the slot afterwards.
Cc: stable # 5.3.0+
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We might need know the associated PCI slot before applying the chip
level quirk (phb->ops->device_init()) so that special configuration
on the specific PCI slot can be applied.
This moves the logic of creating PCI slot, applying the quirk and
linking the newly probed device to parent's child list to function
pci_scan_one(). Also, the PCI slot is created prior to applying the
quirk.
Cc: stable # 5.3.0+
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This is an experimental patch that implements "Fast reboot" on P8
machines.
The basic idea is that when the OS calls OPAL reboot, we gather all
the threads in the system using a combination of patching the reset
vector and soft-resetting them, then cleanup a few bits of hardware
(we do re-probe PCIe for example), and reload & restart the bootloader.
For Trusted Boot, this means we *add* measurements to the TPM, so you
will get *different* PCR values as compared to a full IPL. This makes
sense as if you want to be sure you are running something known then,
well, do a full IPL as soft reset should never be trusted to clear any
malicious code.
This is very experimental and needs a lot of testing and also auditing
code for other bits of HW that might need to be cleaned up.
BenH TODO: I also need to check if we are properly PERST'ing PCI devices.
This is partially based on old code I had to do that on P7. I only
support it on P8 though as there are issues with the PSI interrupts
on P7 that cannot be reliably solved.
Even though this should be considered somewhat experimental, we've had
a lot of success on a variety of machines. Dozens/hundreds of reboots
across Tuleta, Garrison and Habanero.
Currently, we've hidden it behind a NVRAM config option, which *is*
liable to change in the future (to ensure that only those who know
what they're doing enable it)
You can enable the experimental support via nvram option:
nvram -p ibm,skiboot --update-config experimental-fast-reset=feeling-lucky
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[stewart@linux.vnet.ibm.com: hide behind nvram option, include Mambo fixes
from Mikey]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
It's useful to know the CRS retry times before the PCI device is
detected successfully. In PCI hot add case, it usually indicates
time consumed for the adapter's firmware to be partially ready
(responsive PCI config space).
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The timeout should be 1000ms instead of 1000 ticks while powering
off PCI slot in pci_slot_power_off(). Otherwise, it's likely to
hit timeout powering off the PCI slot as below skiboot logs reveal:
[47912590456,5] SkiBoot skiboot-5.3.6 starting...
:
[5399532365,7] PHB#0005:02:11.0 Bus 0f..ff scanning...
[5399540804,7] PHB#0005:02:11.0 No card in slot
[5399576870,5] PHB#0005:02:11.0 Timeout powering off slot
[5401431782,3] FIRENZE-PCI: Wrong state 00000000 on slot 8000000002880005
This replaces time_wait() with time_wait_ms() to resolve the issue.
Fixes: 358b4d654f100cfdfcba939cae012099a851b3bc
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This is more compliant with PAPR, it will also allow us to
use the second cell for other attributes on P9.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
PCIe devices cache the bus number on the first config write, make sure
we restore them when at the same time
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The value might be different for different PHB instances
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This powers off the empty hotpluggable slot during PCI enumeration
for two purpose: power saving and initialize the slot to starting
(power-off) state.
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>
|
|
During PCI enumeration, the root complex's link and fundamental
reset are carried out by PHB's callbacks which are replaced by
the corresponding PCI slot's callbacks. Also, the hotplug related
device node properties are populated based on the PCI slot info
that is included in PCI slot now.
This uses PCI slot in enumeration:
* Use PCI slot's callbacks for fundamental reset and link status
retrieval in PCI enumeration.
* Simplify the code by removing traditional PCI/PCI-x related
logic as we don't have PCI/PCI-X root complex.
* Replace pci_add_slot_properties() with pci_slot_add_properties()
to populate PCI slot properties in device-tree.
* PHB is always not hotpluggable. No hotpluggable properties in
its device node are needed.
* Remove "struct pci_slot_info" definition as its info is included
in "struct pci_slot".
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>
|
|
Every PCIE bridge port or PHB is expected to be bound with PCI slot
, to which various PCI slot's functionalities are attached (e.g. power,
link, reset). This supports PCI slot:
* PCI slot is reprsented by "struct pci_slot".
* "struct pci_slot_ops" represents the functions supported on the
PCI slot. It's initialized by PCI slot core at the beginning and
allowed to be overrided by platform partially or completely.
* On PCI hot plugging event, the PCI devices behind the slot are
enumarated. Device sub-tree is populated and sent to OS by OPAL
message.
* On PCI hot unplugging event, the PCI devices behind the slot are
destroyed. Device sub-tree is removed and the slot is powered off.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds @data argument and "int" return value for struct phb_ops::
device_init() so that it can be called in pci_walk_dev() directly to
reinitialize the PCI devices behind the specified slot in subsequent
patches.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently, pci_restore_bridge_buses() restores the assigned bus
ranges for all PCI bridges behind the specified PHB. This extends
the function and allows doing same thing for the PCI bridges behind
the specified slot. The extended functionality is going to be used
by PCI hotplug logic in the subsequent patches.
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, pci_walk_dev() iterates all PCI devices behind the
specified PHB. This extends the function to allow iteration
on PCI devices behind the specified PCI slot so that it can
be used by PCI hotplug logic in the subsequent patches.
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 scanning to non-existing PCI device, EEH (frozen) error is
usually happening. We clear the unexpected frozen PE state after
it. The reserved PE number is assumed to be 0 wrongly. So the
frozen state on the reserved PE number isn't cleared properly.
This introduces struct phb_ops::get_reserved_pe_number() to
retrieve the reserved PE number from platforms. Then the EEH
frozen state checking and clearing are applied to the reserved
PE number.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fixes: f46c1e506d199332b0f9741278c8ec35b3e39135
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
On PCI Express, devices need to know their own bus number in order
to provide the correct source identification (aka RID) in upstream
packets they might send, such as error messages or DMAs.
However while devices know (and hard wire) their own device and
function number, they know nothing about bus numbers by default, those
are decoded by bridges for routing. All they know is that if their
parent bridge sends a "type 0" configuration access, they should decode
it provided the device and function numbers match.
The PCIe spec thus defines that when a device receive such a configuration
access and it's a write, it should "capture" the bus number in the source
field of the packet, and re-use as the originator bus number of all
subsequent outgoing requests.
In order to ensure that a device has this bus number firmly established
before it's likely to send error packets upstream, we should thus do a
dummy configuration write to it as soon as possible after probing.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: fix Evolution broken patch, write vdid rather than &vdid as per Gavin suggestion]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
phb_ops->device_node_fixup() was introduced for NPU1 so that the
chip backend can bind the emulated NPU device with the GPU device
and fixes the device-tree node accordingly. There're couple of
issues as I can image:
* In pci_fixup_nodes(), one PHB has only one level of device
depth in the hierarchy tree. It's true for NPU PHBs, but
false for other PHBs. That indicates the function can be
called for NPU PHBs.
* The callback name indicates the specific work to be done
there. That doesn't make sense. We need another name without
indicating the specific work to do. It will give the backend
on chip level more freedom. Similarly, the callback is called
on basis of PCI device. It's hard for backend to manuplate
the PHB. More freedom the backend will get with more bold
granularity.
This fixes above issues by replacing phb_ops->device_node_fixup()
with phb_ops->phb_final_fixup(). More freedom will be received in
the backends.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
All kinds of PHBs are maintaining a spinlock. At mean while, the
spinlock is acquired or released by backends for phb_ops->lock()
or phb_ops->unlock(). There're no difference of the logic on all
kinds of PHBs. So it's reasonable to maintain the lock in the
generic layer (struct phb).
This moves lock from specific PHB to generic one. The spinlock is
initialized when the generic PHB is registered in pci_register_phb().
Also, two inline functions phb_{lock, unlock}() are introduced to
acquire/release it. No logical changes introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Similar to for_each_cpu, adding a for_each_phb makes PHB traversal easy.
Suggested-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
Currently skiboot adds an empty ranges property for each PCI bridge,
representing a 1:1 mapping, which the kernel can later update if needed.
However this does not appear to be the case, which leads to an issue in
the kernel where the translation of assigned-addresses properties is
mishandled and prematurely drops the PCI memory flags (ie. the first
cell of an address).
Instead, explicitly describe a 1:1 mapping in each bridge's ranges
property, allowing assigned-addresses to be properly handled.
Signed-off-by: Sam Mendoza-Jonas <sam@mendozajonas.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional change, but static analysis showed up the oddity of
something that is generally unsigned (opal_id) having a signed
value assigned to it.
Took the opportunity to use a define to increase readability.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
the DT
Commit 75e9440 (PCI: Trace device node from PCI device) introduced the
ability for PCI devices to do fixups based on information added to the
device tree as part of device initialisation.
However that patch called the fixups during device initialisation
meaning not all devices present in the system had been added to the
device tree. Depending on device initialisation order this means some
devices were not detected by the fixup code.
This patch moves the calls to the fixup code until after all PCI
devices have been added to the device tree.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When nvLink and nVida's GPU included in PCI topology, we have the
emulated PCI devices to represent nvLinks, which is associated with
the real GPU PCI device with help of device-tree. The patch introduces
one more field "dn" to "struct pci_device" to make the job easier.
The patch also adds one more PHB operations "device_node_fixup", which
is to be called when populating PCI device node so that we have chance
to link the emulated PCI device and the real GPU device through device
tree.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The patch caches IDs (vendor, device, sub-vendor, sub-device and
class) for PCI devices. Those IDs could be used to identify one
specific PCI device later.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
