summaryrefslogtreecommitdiffstats
path: root/core/pci.c
Commit message (Collapse)AuthorAgeFilesLines
* pci-iov: free memory across fast-rebootStewart Smith2017-10-101-3/+11
| | | | | | | | | | | | | | pci_set_cap needs a callback to free data and we need to call that when we're doing __pci_reset() We also need to free pcrf entries. In the future, __pci_reset() and pci_remove_bus() need to come together to be one canonical place on how to free a PCI device rather than the two we have now. This patch *purely* focuses on the problem of not leaking memory across fast-reboot. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Make pci_wait_crs() globalMichael Neuling2017-09-121-1/+1
| | | | | | | We are going need pci_wait_crs() in the PHB4 code so make it global. Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Wait for CRS and switch link when restoring bus numbersRussell Currey2017-08-211-13/+38
| | | | | | | | | | | | | | | | | | | | When a complete reset occurs, after the PHB recovers it propagates a reset down the wire to every device. At the same time, skiboot talks to every device in order to restore the state of devices to what they were before the reset. In some situations, such as devices that recovered slowly and/or were behind a switch, skiboot attempted to access config space of the device before the link was up and the device could respond. Fix this by retrying CRS until the device responds correctly, and for devices behind a switch, making sure the switch has its link up first. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Russell Currey <ruscur@russell.cc> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Tested-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Trivial typo fixesRussell Currey2017-08-211-2/+2
| | | | | | Signed-off-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>
* pci: Track whether a PCI device is a virtual functionRussell Currey2017-08-211-0/+1
| | | | | | | | | | This can be checked from config space, but we will need to know this when restoring the PCI topology, and it is not always safe to access config space during this period. Signed-off-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>
* core/pci: Fix mem-leak on fast-rebootMatt Brown2017-07-201-0/+1
| | | | | | | | | | | Fast-reboot has a memory leak which causes the system to crash after about 250 fast-reboots. The patch fixes the memory leak. The cause of the leak was the pci_device's being freed, without freeing the pci_slot within it. Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Add ability to trace timingMichael Neuling2017-07-131-0/+1
| | | | | | | | | PCI link training is responsible for a huge chunk of the skiboot boot time, so add the ability to trace it waiting in the main state machine. Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Print resetting PHB notice at higher log levelMichael Neuling2017-07-131-1/+1
| | | | | | | | | | | | Currently during boot there a long delay while we wait for the PHBs to be reset and train. During this time, there is no output from skiboot and the last message doesn't give an indication of what's happening. This boosts the PHB reset message from info to notice so users can see what's happening during this long period of waiting. Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Big log level reduction...Benjamin Herrenschmidt2017-06-261-1/+1
| | | | | | | | | | | | | 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>
* core/pci: Use PCI slot's power facality in pci_enable_bridge()Gavin Shan2017-06-161-158/+242
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* core/pci: Make the conditions for device type quirk obviousGavin Shan2017-06-151-3/+2
| | | | | | | | | | | | | | 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>
* core/pci: Use macro as vendor ID register offsetGavin Shan2017-06-151-4/+4
| | | | | | | | | 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>
* core/pci: Use cached vendor/device IDs in quirksGavin Shan2017-06-151-1/+1
| | | | | | | | | | | 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>
* phb4: Activate shared PCI slot on witherspoonFrederic Barrat2017-06-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* PCI: only wait 20ms for PHB logic to settle if we detected any PHBsStewart Smith2017-06-071-1/+6
| | | | | | | | 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>
* pci: Wait 20ms before checking presence detect on PCIeBenjamin Herrenschmidt2017-06-061-0/+5
| | | | | | | | 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>
* phb4: Block D-state power management on direct slotsBenjamin Herrenschmidt2017-06-061-0/+10
| | | | | | | | 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>
* pci: Make handling of config filters genericBenjamin Herrenschmidt2017-06-061-1/+23
| | | | | | | 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>
* pci: Add bitmap to know if a pci device has cfg reg filtersBenjamin Herrenschmidt2017-06-061-0/+10
| | | | | | | | 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>
* core/pci: Rename pci_slot_op poll to run_smMichael Neuling2017-05-311-2/+2
| | | | | | | | | | | | | | | 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>
* core/pci.c: Don't reserve PCI slots for non-pluggable slotsAlistair Popple2017-05-101-6/+9
| | | | | | | | | | 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>
* core/pci: Add phb->ops->device_removeGavin Shan2017-03-311-0/+3
| | | | | | | | | | 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>
* core/pci: Fix lost NVMe adapter behind PMC 8546 switchGavin Shan2017-03-311-6/+22
| | | | | | | | | | | | | | | | | | | | | 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>
* fast-reboot: creset PHBs on fast rebootAndrew Donnellan2017-03-201-0/+21
| | | | | | | | | | | 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>
* core/pci: remove misleading fast reboot commentAndrew Donnellan2017-03-201-2/+0
| | | | | | | | 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>
* pci: Add a framework for quirksRussell Currey2017-03-031-0/+3
| | | | | | | | | | | | | | | | | | 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>
* core/pci: Support SRIOV VFsGavin Shan2017-02-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* core/pci: Allow associating parameter with capabilityGavin Shan2017-02-161-2/+2
| | | | | | | | | | 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>
* core/pci: Initialize AER capability in PCI coreGavin Shan2017-02-161-0/+13
| | | | | | | | | | | | | | | | 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>
* core/pci: Introduce separate function to initialize PCIe capabilityGavin Shan2017-02-161-53/+66
| | | | | | | | | | | | | | | | | | | | | 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>
* pci: Always print PHB and PE numbers as hexadecimalRussell Currey2016-12-141-2/+2
| | | | | | | | | | | 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>
* pci: Check power state before powering off slotGavin Shan2016-10-241-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* core/pci: Reserve PCI buses for RC's slotGavin Shan2016-10-171-2/+21
| | | | | | | | | | | | | | 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>
* core/pci: Get PCI slot before applying quirkGavin Shan2016-10-171-12/+10
| | | | | | | | | | | | | | | 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>
* Fast reboot for P8Benjamin Herrenschmidt2016-10-171-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* core/pci: Print CRS retry timesGavin Shan2016-10-111-2/+2
| | | | | | | | | | 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>
* core/pci: Fix the power-off timeout in pci_slot_power_off()Gavin Shan2016-09-221-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* interrupts: Use a #interrupt-cells of 2 for XICS interruptsBenjamin Herrenschmidt2016-07-121-6/+10
| | | | | | | | 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>
* pci: When restoring bus numbers after a reset, also restore device cacheBenjamin Herrenschmidt2016-07-081-1/+7
| | | | | | | | | 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>
* pci: get_reserved_pe_number() needs to take the PHB as argumentBenjamin Herrenschmidt2016-07-081-1/+1
| | | | | | | | 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>
* core/pci: Power off empty hotpluggable slotGavin Shan2016-06-141-1/+55
| | | | | | | | | | 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>
* core/pci: Use PCI slot in enumerationGavin Shan2016-06-141-141/+38
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* core/pci: Support PCI slotGavin Shan2016-06-141-23/+54
| | | | | | | | | | | | | | | | | | | 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>
* core/pci: Return value for struct phb_ops::device_initGavin Shan2016-06-141-1/+1
| | | | | | | | | | 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>
* core/pci: Extend pci_restore_bridge_buses() for PCI slotGavin Shan2016-06-141-2/+2
| | | | | | | | | | | | 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>
* core/pci: Extend pci_walk_dev() for PCI slotGavin Shan2016-06-141-4/+8
| | | | | | | | | | | 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>
* core/pci: Fix wrong reserved PE# in enumerationGavin Shan2016-06-141-3/+12
| | | | | | | | | | | | | | | 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>
* Fixup whitespace and build warning/errorStewart Smith2016-06-091-4/+4
| | | | | Fixes: f46c1e506d199332b0f9741278c8ec35b3e39135 Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Do a dummy config write to devices to establish bus numberBenjamin Herrenschmidt2016-06-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* PCI: Introduce phb_ops->phb_final_fixup()Gavin Shan2016-05-031-15/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
OpenPOWER on IntegriCloud