Age | Commit message (Collapse) | Author | Files | Lines |
|
This improves PCI config register filter so that it can be reused
by PCI virtual device in subsequent patch:
* First argument to pci_cfg_reg_func() is changed to "void *".
It allows to accept variable data types including PCI virtual
device in future.
* Return value from pci_cfg_reg_func() to be used by PCI virtual
device in future.
* Shortened name of function phb3_pcicfg_filter_rc_pref_window().
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>
|
|
Throughout skiboot (and the kernel) PE numbers are named "pe_no",
"pe_num" and "pe_number", and sized as 16, 32 and 64bit uints depending
on where you look. This is annoying and potentially misleading in cases
such as the OPAL API, where different calls have different int sizes
even though the PE number they want is the same.
Fix this by making *everything* uint64_t pe_number. In doing this, there
are some whitespace fixes and mve_number gets dragged into this as well
for cases like set_msi_{32/64} where they essentially mean the same thing.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The capi initialization sequence was revised in a circumvention
document when a 'link down' error was converted from fatal to Endpoint
Recoverable. Other, non-capi, register setup was corrected even before
the initial open-source release of skiboot, but a few capi-related
registers were not updated then, so this patch fixes it.
The point is that a link-down error detected by the UTL logic will
lead to an AIB fence, so that the CAPP unit can detect the error.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This allows a given source to provide per-interrupt attributes
such as whether it targets OPAL or Linux and it's estimated
frequency.
The former allows to get rid of the double set of ops used to
decide which interrupts go where on some modules like the PHBs
and the latter will be eventually used to implement smart
caching of the source lookups.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When enabling CAPI in DMA mode, set the AIB TX command credits for channel
2 (DMA read) to 28, rather than 1. This significantly improves DMA read
performance in CAPI DMA mode.
Fixes: 5477148a439f ("phb3: Add support for CAPP DMA mode")
Reported-by: John Walthour <jwalthour@us.ibm.com>
Reported-by: Ricardo Mata <ricmata@us.ibm.com>
Reported-by: Michael Perez <perezma@us.ibm.com>
Cc: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This makes irq_source public, and change all irq_source_ops to take
the source pointer as a first argument (they can still dig the void *
data out of that).
This will allow us to embed/wrap it for XIVE later on.
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 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>
|
|
Found by smatch static analysis (http://smatch.sourceforge.net/):
hw/phb3.c:2331 capp_load_ucode() warn: inconsistent indenting
hw/phb3.c:3444 phb3_set_capi_mode() warn: inconsistent indenting
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>
|
|
The UTL outbound discard error (bit#12) in UTL_PCIE_PORT_IRQ_EN
(offset: 0x558) isn't set in initial setup. It's set wrongly after
a reset on root port. With this bit set, frozen (all) error was
observed on the PHB to which a LPFC adapter is connected directly.
This removes the bit in reset handler to avoid the unexpected
frozen (all) error.
BZ: 142877
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@in.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
While reviewing the Debian packaging, codespell found those.
Most proposed fixes are based on codespell's default dictionnary.
Signed-off-by: Frederic Bonnard <frediz@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The patch refactors functions used for PHB slot management for
PHB3. Also, PHB slots are created before platform's PHB setup
hook (platform.pci_setup_phb()). That means the platforms can
override the properties or methods of the PHB slot if necessary.
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>
|
|
This removes the useless comments as the I2C based power managment
is covered by this series of patches and the left items in the FIXUP
aren't needed any more.
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>
|
|
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>
|
|
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>
|
|
The XSL incorrectly sends out PTE updates with nodal scope instead of
group scope, which causes a system checkstop. This is exacerbated by the
fact that recent Linux kernels do not set the R bit in the hashed page
tables, requiring the XSL to write them back to set that bit. Work
around this issue by forcing all commands to be unlimited scope.
This might have a slight performance impact, but it is expected to be
negligible since the XSL is only used for translations, not for block
data transfers. To avoid impacting other cards, tie it off the use of
DMA mode, as only the XSL based Mellanox CX4 card uses this mode and is
affected.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The XSL used in the Mellanox CX4 card uses a DMA mode of CAPI, which
requires a few registers configured specially. In addition to enabling
the mode,
- The CAPP only owns some of the PHB read buffers, and must be
configured to use the correct ones, and the self-snoop configured for
the same ones.
- The tve needs to be configured to allow the card to access all kernel
memory as it uses DMA accesses to read the scheduled process area from
the kernel, among other things.
These cannot be configured unconditionally, as doing so will break
existing CAPI devices that do not use DMA mode. This adds a new mode to
the OPAL_PCI_SET_PHB_CAPI_MODE API to enable CAPI in DMA mode.
Since the snoop on/off modes write to the capi snoop configuration
register, which is configured differently in DMA mode, it uses the
redundant bits from the apc master powerbus control register to
determine if it should configure the register for DMA mode rather than
requiring any more permutations of the mode parameter.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The phb3_set_capi_mode function was getting a little long, and the
enable procedure will need to be parameterised to support CAPP DMA mode,
so split it out into it's own function in preparation for this. Also
replace the multiple if (mode == xxx) cases with an equivalent switch
construct since it will shortly gain yet another case.
No functional changes.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
[stewart@linux.vnet.ibm.com: enabled The Oatmeal apostrophe compatibility mode]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This FIR bit is informational and should not take the system down.
Signed-off-by: Ian Munsie <imunsie@au1.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>
|
|
I can't keep all the PCI vendor IDs in my head, so use some text
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
On P8+ Garrison platform, the root port's pref window register might
be not writable and we have to emulate the window because of hardware
defect. In order to detect that, we read the register content, write
inversed value and read the register content again. The register is
regarded as read-only if the values from the two continuous read are
same. However, the original register content isn't written back and
it causes corruption on pref window register if it's writable.
This fixes the above issue by writing the original content back to
the register at the end.
Fixes: d40160f6 ("PHB3: Emulate root complex pref 64-bits window")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Naples has two capp units. The address of the PE Secure CAPP Enable
register for capp unit 1 is equal to the address for capp unit 0 + 0x40.
This patch introduces and uses the macro PE_REG_OFFSET, that returns
0x40 for the capp unit 1 on Naples, and 0x0 otherwise.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Naples has two capp units. Probe both units to identify the card in
error. Use the xscom register offset to operate on the right unit.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Naples has two capp units. In chiptod_capp_timebase_sync, call
PHB3_CAPP_REG_OFFSET(p) to get the xscom register address offset,
an operate on the right capp unit.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Naples has two capp units. In phb3_init_capp_regs and phb3_set_capi_mode,
call PHB3_CAPP_REG_OFFSET(p) to get the xscom register address offset,
and operate on the right capp unit.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Venice and Murano have only one capp unit, that can be mapped to phb0,
phb1 or phb2. Naples has two capp units, that are statically mapped,
capp unit 0 on phb0 and capp unit 1 on phb1. The capp ucode must be
loaded once onto each capp unit.
This patch replaces the boolean chip->capp_ucode_loaded by a bitmap,
and sets the bit corresponding to the phb index to indicate that ucode
has been loaded. The macro CAPP_UCODE_LOADED(chip, phb) returns the value
of the phb index bit.
The xscom register addresses of capp unit 0 are identical to the register
addresses of the single capp unit of Venice and Murano. The addresses of
the Naples capp unit 1 are equal to the addresses of capp unit 0 + 0x180.
This patch introduces the macro PHB3_CAPP_REG_OFFSET(p), that returns the
following xscom register address offsets:
0x0 for the Venice capp unit
0x0 for the Murano capp unit
0x0 for Naples capp unit 0
0x180 for Naples capp unit 1
The offset is added to the register address at each xscom_write, in order
to operate on the right capp unit.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Merge PHB3 race fix
|
|
When we mask an interrupt, we may race with another interrupt coming
in from the hardware. If this occurs, the P and/or Q bit may end up
being set but we never EOI/clear them. This could result in a lost
interrupt or the next interrupt that comes in after re-enabling never
being presented.
This patch ensures that when masking an interrupt, any pending P/Q
bits are cleared.
This fixes a bug seen with some CAPI workloads which have lots of
interrupt masking at the same time as high interrupt load. The fix is
not specific to CAPI though.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When we EOI we need to clear the present (P) bit in the Interrupt
Vector Cache (IVC). We must clear P ensuring that any additional
interrupts that come in aren't lost while also maintaining coherency
with the Interrupt Vector Table (IVT).
To do this, the hardware provides a conditional update bit in the
IVC. This bit ensures that generation counts between the IVT and the
IVC updates are synchronised.
Unfortunately we never set this the bit to conditionally update the P
bit in the IVC based on the generation count. Also, we didn't set
what we wanted the new generation count to be if the update was
successful.
This patch fixes sets both of these. It also reworks and documents
the code so that mortals may eventually be able to understand this
process.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
When doing an MSI EOI, we update the P and Q bits in the IVE. That causes
the corresponding cache line to be dirty in the L3 which will cause a
subsequent update by the PHB (upon recieving the next MSI) to get a few
retries until it gets flushed.
We can improve the situation (and thus performance) by doing a dcbf
instruction to force a flush of the update we do in SW.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
hw/phb3.c:1067:11: warning: Value stored to 'end' during its initialization is never read
uint64_t end = pci_start_addr + pci_mem_size;
^~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Remove duplicated code block for checking CAPP_ERR_STATUS_CTRL in
phb3_set_capi_mode(), which appears to have been inadvertently added as a
result of a merge/rebase issue. No functional change.
Fixes: 5aa2331ff590 ("phb3/capi: Add capp recovery to phb3")
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This removes below unnecessary message in phb3_sm_fundamental_reset()
as there already has on subsequent message indicating the situation.
Performing PERST...
Also, this decreases the outputing level of all messages in this
function to DEBUG.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When issuing fundamental reset on below IPR adapter that seats
behind root complex, there is 50% possibility that the link
fails to come up after the reset. In that case, the adapter's
config space is blocked and it's not usable.
host# lspci -ns 0004:01:00.0
0004:01:00.0 0104: 1014:034a (rev 01)
host# lspci -s 0004:01:00.0
0004:01:00.0 RAID bus controller: IBM PCI-E IPR SAS Adapter
(ASIC) (rev 01)
This introduces another PHB3 state (PHB3_STATE_FRESET_START)
allowing to redo fundamental reset if the link doesn't come up
in time at the first attempt, to improve the robustness of PHB's
fundamental reset. If the link comes up after the first reset,
the 2nd reset won't be issued at all.
Reported-by: Paul Nguyen <nguyenp@us.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
On Naples, the prefetchable 64-bits window on root complex can't
be altered. However, Linux kernel depends on that to detect the
window properly. Otherwise, the PCI device BARs that should be
covered by PHB's M64 window are allocated from M32. It leads to
unworkable CAPI card on Linux side.
This checks if the root complex's prefechable 64-bits window
can be changed or not. If not, a PCI config register filter for
it is registered to emulate the behaviour.
Reported-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We have to provide the emulated result for PCI config register
access on some devices to eleminate the gap between hardware and
software. One example would be the 0x28 (prefetchable memory window
upper 32-bits) of the root complex on Naples isn't writable. Linux
kernel relies on that to detect 64-bits window successfully.
This introduces config register filter to PCI device to eleminate
above gap. Each PCI device maintains a list of filters, which are
populated when the PCI device is initialized. When PCI config space
is accessed, the filter is searched to override the result from user
(write) or hardware (read) if necessary.
Reported-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Interrupts on P8 are currently hard-coded using macros in
include/interrupts.h. The new P8NVL processor has an extra PHB meaning
it supports 4 PHBs in total which leads to the following assert fail
when booting P8NVL based systems:
[6614913194,3] register IRQ source overlap !
[6620562844,3] new: 2000..27f7 old: 2000..27f7
[6870377440,0] Assert fail: core/interrupts.c:67:0
This patch converts the existing macros to function calls so that
different platforms can support extra PHBs at the expense of a reduced
maximum number of chips.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
On P8, we calculate the OPAL ID of the PHB as a function of the physical
chip number and PHB index on that chip. P7 continues using "allocated"
numbers for now.
We also consistently print the PHB ID as a 4-digit hex number which
facilitates decoding it, and print the chip:index location in the probe
code to make it easier to correlate log entries.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[stewart@linux.vnet.ibm.com: use next_chip rather than get_chip]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This issue was found on SRIOV VFs initially and then I checked
with Chad Larson who put much efforts to sort it out. As more
experiments I did, the issue isn't limited to SRIOV VFs. That
means the isue can be seen on non-SRIOV adapter as well: Firstly,
I ensure that outbound request discard interrupt (bit#12) is
enabled in PCI Express Port Interrupt Enable Register (offset:
0x558). Then injecting error to root complex by PAPR Error
Injection Registers with PCI config read. Eventually, all (256)
PEs are frozen. After clearing the bit, the target PE#0 is frozen
as expected. As Chad pointed, the interrupt ("outbound request
discard") is always raised during the error injection, which is
translated to UTL's primary interrupt to freeze all (256) PEs.
This drops bit#12 of PCI Express Port Interrupt Enable Register
to avoid the UTL's primary interrupt caused by outbound request
discard, in order to avoid freezing all (256) PEs during error
injection via PCI config read.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This removes below unnecessary message in phb3_sm_fundamental_reset()
as there already has on subsequent message indicating the situation.
Performing PERST...
Also, this decreases the outputing level of all messages in this
function to DEBUG.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When issuing fundamental reset on below IPR adapter that seats
behind root complex, there is 50% possibility that the link
fails to come up after the reset. In that case, the adapter's
config space is blocked and it's not usable.
host# lspci -ns 0004:01:00.0
0004:01:00.0 0104: 1014:034a (rev 01)
host# lspci -s 0004:01:00.0
0004:01:00.0 RAID bus controller: IBM PCI-E IPR SAS Adapter
(ASIC) (rev 01)
This introduces another PHB3 state (PHB3_STATE_FRESET_START)
allowing to redo fundamental reset if the link doesn't come up
in time at the first attempt, to improve the robustness of PHB's
fundamental reset. If the link comes up after the first reset,
the 2nd reset won't be issued at all.
Reported-by: Paul Nguyen <nguyenp@us.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When struct phb3::has_link is set to true, the downstream link of
root port is up, not down. This fixes the incorrect comments.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We disallow to inject error to reserved PE#, which is 255 instead
of 0 on PHB3. Otherwise, error OPAL_PARAM is returned when injecting
error to PE#0.
This fixes above issue by checking against the correct PE number 255.
Reported-by: Pradeep Ramanna <pramann2@in.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
merge in CAPI fixes from Ian and Daniel
|
|
If the PHB is fenced during phb3_pci_msi_check_q, it can get stuck in an
infinite loop waiting to lock the FFI. Further, as the phb lock is held
during this function it will prevent any other CPUs from dealing with
the fence, leading to the entire system hanging.
If the PHB_FFI_LOCK returns all Fs, return immediately to allow the
fence to be dealt with.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|