| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Cc: Ilya Kuznetsov <ilya@yadro.com>
Cc: Artem Senichev <artemsen@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Use Software Package Data Exchange (SPDX) to indicate license for each
file that is unique to skiboot.
At the same time, ensure the (C) who and years are correct.
See https://spdx.org/
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
[oliver: Added a few missing files]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
System vendor may build systems with large PCIe tree with
deeper switch topologies. Currenlty downstream ports slot
creation is limited to first switch. Patch allows to use any.
Signed-off-by: Ilya Kuznetsov <ilya@yadro.com>
[oliver: added pci-slot prefix]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Exiting early in the power off case makes sense since we can't disable
slot power (or assert PERST) for suprise hotplug slots. However, we
should not exit early in the power-on case since it's possible slot
power may have been disabled (or just not enabled at boot time).
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Working out what was actually going on here took forever.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
For some reason we look at the power control indicator and use that to
determine if the slot is "off" rather than the power control flag that
is used to power down the slot.
While we're here change the default behaviour so that the slot is
assumed to be powered on if there's no slot capability, or if there's
no power control available.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
If the power state is already the required value, return
OPAL_SUCCESS rather than OPAL_PARAMETER to avoid spurrious
errors during boot.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-By: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Coverity has found a senario where there could be a NULL dereference,
it is likely that in practice we wouldn't hit this. Coverity does point
out that all other callers of pcie_slot_create() do check for the NULL
return, as such it makes sense to add a check.
Fixes: CID 173756
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
PCI slot pfreset() operation is obsoleted as nobody uses it. This
removes it and the related PCI slot states. No functional changes
introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This claims PCIe surprise hotplug capability through device node's
property "ibm,slot-surprise-pluggable". The slot has the capability
when surprise hotplug is supported in its slot's capability bits or
link state change reporting is supported in PCIe link capability bits.
In order for link state events to be properly raised during surprise
hotplug, the power supply to the slot should be always on. The slot's
power state should be switched accordingly during fundamental reset.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We should return cached power state instead of retrieving it from
hardware, meaning we're allowed to have the situation: the power
is off in software, but it's on in hardware when the built-in
power control functionality is ignored for some reasons (e.g.
surprise hotplug support). Otherwise, the adapter behind the
slot won't be probed in PCI hot add path.
This returns the cached power state so that OS sees synchronised
power and PCI slot hotplug state (added/removed).
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We can have PCI slots where the mandatory power functionality isn't
supported. On those PCI slots, we should update (cache) the slot's
power state unconditionally because the power state reflects slot's
hotplug state (added or removed). Without this fix, the power and
slot's hotplug state are mismatched on openPower machines. FSP-based
machines don't have the issue.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This returns error (OPAL_PARAMETER) when having invalid power state
transition requests. The invalid requests include: ON to ON, OFF to
OFF.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The initial PCIe slot power state should be retrieved from the PCIe
Slot Control register (offset: +0x18), instead of having the fixed
state (power-off) wrongly. Otherwise, we possibly have mismatched
states by software and hardware. One side-effect is PCIe slot can
not be powered off from hardware for the first time.
This fixes above issue by fetching the initial PCIe slot power state
from hardware (PCIe Slot Control register) if the power control is
supported on the slot. Otherwise, it doesn't matter on what we have
for the initial PCIe slot power state.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: use PCI_SLOT_POWER_ON|OFF rather than 1/0]
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>
|
