aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2021-06-30hw/imc: Use the xscom macros for IMC based on platformAnju T Sudhakar1-34/+61
The xscom macros defined in the skiboot are platform specific. IMC opal APIs use these xscom definitions, to read and write to scom ports. Cleanup the code to pick the appropriate xscom macro definition based on the running platform. Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-06-30hw/imc: Cleanup code to define scom addr for IMC at run timeAnju T Sudhakar1-2/+32
Currently scom addresses for IMC are defined at compile time. The scom addresses may vary for different processor generations. So clean up the code to pick the right scom addresses, based on the processor version at run time. Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-06-30hw/p8-i2c: Make OCCFLG register base address configurable at runtimeOliver O'Halloran1-9/+15
Prepare for POWER10 support which changes the OCCFLG register base address. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> [Replaced perror with prlog - Vasant] Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-06-30hw/p8-i2c: Add buses at runtimeOliver O'Halloran1-8/+75
When booting skiboot we initialise any I2C masters after probing the platform, but before initialising the platform (or NVRAM). Due to this we need to ensure that all the I2C masters we might want to use are in the DT before the platform is initialised. This causes problems since we might want to add another master (e.g. on witherspoon we might need to add a port for the I2C OpenCAPI I2C bus). It's possible to hack around this by adding a new node in the probe function, but the probe function runs very early before many essential services are initialised (e.g. LPC). We might want to add another I2C bus after learning that we have a riser card installed and it's not possible to do that until later in boot. To accommodate those use cases we can add support for adding a new bus at runtime. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-06-30hw/p8-i2c: Move port init into a separate functionOliver O'Halloran1-48/+45
Move it out in preparation for adding the ability to add new ports on the fly. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-06-30hw/p8-i2c: Set poll interval from the current portOliver O'Halloran1-16/+7
The rate at which we need to poll the master depends on the speed of the bus. Faster I2C buses will require more frequent polling so it doesn't make a whole lot of sense to set this on a per-master basis. This patch sets the master's polling interval to a per-port setting calculated from the port speed. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-06-30hw/p8-i2c: Print interrupt status per masterOliver O'Halloran1-11/+5
Whether I2C interrupts work or not depends on the type of master. Currently we print a single message to indicate whether IRQs work or not, but this will be wrong if we have I2C interrupts on the host and we happen to probe a Centaur I2C master first. Fix this by adding a message to the per-master print indicating whether the master has an interrupt or not. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-06-30hw/p8-i2c: Add p8_i2c_find_bus_by_port()Oliver O'Halloran1-0/+26
Adds a way to find the struct i2c_bus for a given chip ID, engine ID, and port ID. HDAT indicates which I2C master is relevant using this information so it comes up a fair bit. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-06-30VAS: Define p9_get_rma_bar()Haren Myneni1-54/+65
Setting the Remote Memory Access BAR address is used in a couple of places which should be defined as a common function. On p10, paste base address format is changed (using primary topology index instead of node/chip IDs). This patch adds p9_get_rma_bar() for P9. Whereas get_rma_bar() on P10 and future processors which will be added in later patches. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-05-28uart: Give SIMICS some more timeCédric Le Goater1-0/+3
Increase timeout introduced in commit 6bf21350da32 ("uart: Drop console write data if BMC becomes unresponsive") when running under SIMICS. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-05-13hw/imc: Disable only nest_imc devices if pause_microcode() failsMadhavan Srinivasan1-2/+16
During opal boot, in imc_init(), 24x7/IMC microcode state is checked and if it is not in running or pause state, currently all the imc devices are removed from device tree. Instead, remove only the nest imc devices. Core/Thread/Trace imc devices are not related to 24x7 microcode. Patch adds a function to remove specific imc device type and the same is used, when pause_microcode() fails, to remove nest imc device types from the device tree. Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-04-07hw/ipmi: Fix misleading-indentation failuresVasant Hegde1-1/+1
Hitting below issue on recent distro (fedora-rawhide). sample failure: --------------- [ HOSTCC ] hw/ipmi/test/run-fru.c In file included from hw/ipmi/test/run-fru.c:10: hw/ipmi/test/../ipmi-fru.c: In function 'fru_fill_product_info': hw/ipmi/test/../ipmi-fru.c:80:17: error: this 'if' clause does not guard... [-Werror=misleading-indentation] 80 | if (rc < 1) return OPAL_PARAMETER; rc; }) | ^~ hw/ipmi/test/../ipmi-fru.c:102:18: note: in expansion of macro 'FRU_INSERT_STRING' 102 | index += FRU_INSERT_STRING(&buf[index], info->manufacturer); | ^~~~~~~~~~~~~~~~~ hw/ipmi/test/../ipmi-fru.c:80:52: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if' 80 | if (rc < 1) return OPAL_PARAMETER; rc; }) | ^~ hw/ipmi/test/../ipmi-fru.c:102:18: note: in expansion of macro 'FRU_INSERT_STRING' 102 | index += FRU_INSERT_STRING(&buf[index], info->manufacturer); | ^~~~~~~~~~~~~~~~~ Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Reviewed-by: Dan Horák <dan@danny.cz>
2021-03-31phb4: Avoid MMIO load freeze escalation on every chipMahesh Salgaonkar1-1/+5
The commit f397cc30bdf8 ("phb4: Only escalate freezes on MMIO load where necessary") introduced a change to restrict escalation to the chips that actually need it. However it missed one case which still causes the escalation on every chip. This affects EEH recovery to cause full PHB reset on some chips which is not necessary. This patch fixes that. Also, add a check for p9 chip in phb4_escalation_required() function. Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-02-12phb4/5: Fix printing of device secondary status register.Mahesh Salgaonkar1-1/+1
The commit e73cf72d1f97 ("phb4: make endian-clean") accidently missed printing correct value for PCI device secondary status register. [ 1654.399387394,3] PHB#0033[3:3]: devCmdStatus = 00100107 [ 1654.399389575,3] PHB#0033[3:3]: devSecStatus = 00100107 after this patch: [ 1620.415289504,3] PHB#0033[3:3]: devCmdStatus = 00100107 [ 1620.415291622,3] PHB#0033[3:3]: devSecStatus = 00002000 Fixes: e73cf72d ("phb4: make endian-clean") Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-02-04phb4: Disable TCE cache line bufferFrederic Barrat1-0/+1
This patch implements a circumvention for HW557787. It disables the TCE cache line buffer as, under heavy loads, there's a possibility of an entry being re-allocated incorrectly. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-02-04hw/phb4: Use inclusive language, replace the word 'whitelist'Philippe Mathieu-Daudé1-10/+10
Follow the inclusive terminology from the "Conscious Language in your Open Source Projects" guidelines [*] and replace the word "whitelist" appropriately. [*] https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-01-14Fix lock error when BT IRQ preempt BT timerlixg1-3/+5
BT IRQ may preempt BT timer if BMC response host when bt msg timeout. When BT IRQ preempt BT timer, the infight_bt_msg did not protected by bt.lock very well. And we will see the following log: [29006114.163785853,3] BT: seq 0x81 netfn 0x0a cmd 0x23: Timeout sending message [29006114.288029290,3] BT: seq 0x81 netfn 0x0b cmd 0x23: Timeout sending message [29006114.288917798,3] IPMI: Incorrect netfn 0x0b in response It may cause 'CPU Hardlock UP', 'memory refree', 'kernel crash' or something else... Signed-off-by: lixg <867314078@qq.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-01-05SBE: Account cancelled timer requestVasant Hegde1-0/+3
Currently we are not accounting cancelled timer request. So in some corner cases we may schedule new timer request with new-timer-value > inflight-timer-value. Lets explicit check new_target value with inflight timer value. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-12-18SBE: Rate limit timer requestsVasant Hegde1-0/+22
We schedule timer and wait for `timer expiry` interrupt from SBE. If we get new timer request which is lesser than inflight timer expiry value we can update timer (essentially sending new timer chip-op and SBE takes care of stoping inflight timer and scheduling new one). SBE runs at much slower speed than host CPU. If we do continuous timer update like below then SBE will be busy with handling PSU side timer message and will not get time to handle FIFO side requests. send timer chip-op -> Got ACK -> send timer chip-op Hence this patch limits number of continuous timer update and we will restart sending timer request as soon as we get timer expiry interrupt. Rate limit value (2) is suggested by SBE team. With this patch: If our timer requests are : 2ms, 1500us, 1000us and 800us (and requests are coming after sending each message) We will schedule timer for 2ms and then update timer for 1500us and 1000us (These update happens after getting ACK interrupt from SBE) We will not send 800us request. At 1000us we get `timer expiry` and we are good to send next timer requests (At this stage both 1000us and 800us timeout happens. We will schedule next timer request with timeout value 500us (1500-1000)). Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-12-18SBE: Check timer state before scheduling timerVasant Hegde1-2/+4
Timer flow: - OPAL sends timer chip-op to SBE and waits for ACK - Until we get ACK interrupt from SBE we will not schedule any new timer - Once we get ACK either we wait for timer expiry -OR- schedule new one if new-timer-request < inflight-timer-timeout value. - If we get new timer request while processing current one p9_sbe_update_timer_expiry code sets `has_new_target` and we schedule it in ACK path (p9_sbe_timer_resp()). p9_sbe_timer_resp() is callback handler and its called without lock. It does not check whether timer message is busy or not (timer_ctrl_msg). So in theory we may hit below scenario and corrupt msg_list. CPU 1 -> Timer ACK (callback handler) -- its not holding any lock CPU 2 -> Grabbed sbe_timer_lock -> scheduled timer --> done CPU 3 -> p9_sbe_update_timer_expiry() -> see timer is busy -> sets has_new_timer -> done CPU 1 -> gets chance to grab sbe_timer_lock -> saw has_new_timer -> Called p9_sbe_timer_schedule() --> List corrupted ! This patch adds timer message busy check in p9_sbe_timer_resp(). Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-12-15Revert "mowgli: Limit slot1 to Gen3 by default"LuluTHSu1-20/+0
This reverts commit 5262cdd1b99f77bca5951fc8132f9795ef0c2b87. When link reset/retrain, this method cannot maintain the max-link-speed limit, so remove it. Signed-off-by: LuluTHSu <Lulu_Su@wistron.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-12-15xscom: Fix xscom error logging caused due to xscom OPAL callGautham R. Shenoy1-2/+19
Commit 80fd2e963bd4 ("xscom: Don't log xscom errors caused by OPAL calls") ensured that xscom errors caused due to XSCOM read/write OPAL calls aren't logged in the error-log since the caller of the OPAL call is expected to handle it. However we are continuing to print the prerror() in the OPAL log regarding the same. This patch reduces the severity of the log from PR_ERROR to PR_INFO for the xscom read and write made via OPAL calls. Tested-by: Pavaman Subramaniyam <pavsubra@in.ibm.com> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Print info only for xscom read/writes made via opal calls Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-12-15xive/p9: Remove assert from xive_eq_for_target()Cédric Le Goater1-1/+1
XIVE VPs are structures describing the vCPUs of guests. When starting a guest, these are allocated and enabled and some checks are done on the location of the associated ENDs, which describe the event queues. If the block of the VP and the block of the ENDs do not match, the XIVE driver asserts. Unfortunately, there is no way to check that a VP identifier is part of a VP block that was previously allocated and it is relatively easy to crash the host with a bogus VP id. That can be done with a QEMU hack on a machine using vsmt. Simply remove the assert, the OS should gracefully handle the error. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reported-by: Greg Kurz <groug@kaod.org> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-12-15hw/ocmb: Fix log messageVasant Hegde1-3/+2
Fix log message and convert perror to prlog. Also reduce message severity as its informational message, not error. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-12-15hw/ocmb: Clear top bit from offset before searching addr rangeVasant Hegde1-1/+2
Looks like HBRT sets top bit in pcbaddress before making OCMB SCOM request. We have to clear that bit so that we can find proper address range for SCOM operation. Sample failure: [ 2578.156011925,3] OCMB: no matching address range! [ 2578.156044481,3] scom_read: to 80000028 off: 8006430d4008c000 rc = -26 Also move HRMOR_BIT macro to common include file (hdata/spira.h -> skiboot.h). Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-11-27xive/p9: Add a retry counter when updating the cache watchCédric Le Goater1-1/+9
Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-11-27xive/p9: Introduce XIVE_ESB_PAGE_SIZECédric Le Goater1-8/+8
Rename XIVE_ESB_SIZE to XIVE_ESB_PAGE_SIZE in the xive/p9 driver to be consistent with the xive2/p10 driver. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-11-27psi/p9: mask all sources at initCédric Le Goater1-0/+13
Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-11-27xive/p9: Use local_alloc() to allocate the XIVE bitmapsCédric Le Goater1-3/+7
These bitmaps are big (128K). On systems with multiple sockets, we will run out of heap. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-11-02phb4: Finish removing P9 DD1 workaround on LSIsCédric Le Goater1-4/+1
Commit ad7e9a67c4e4 ("xive/p9: obsolete OPAL_XIVE_IRQ_SHIFT_BUG flags") forgot to remove the internal flag. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-11-02mowgli: Limit slot1 to Gen3 by defaultLuluTHSu1-0/+21
Refer to the spec. of mowgli, limit the slot to Gen3 speed. For mowgli platform spec. Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: LuluTHSu <Lulu_Su@wistron.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-21FSP/NVRAM: Do not assert in vNVRAM statistics callVasant Hegde1-2/+1
`msg` is valid pointer here. I don't recall why I added assert here :-( This is not correct. We shouldn't call assert here. Also we are not using `msg`. Hence convert it to `__unused`. Fixes: 19d4f98e ('FSP/NVRAM: Handle "get vNVRAM statistics" command') Cc: skiboot-stable@lists.ozlabs.org # v5.4.x + Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-28fsp/dump: Handle non-MPIPL scenarioVasant Hegde1-4/+4
If MPIPL is not enabled then we will not create `/ibm,opal/dump` node and we should continue to parse/retrieve SYSDUMP. I missed this scenario when I fixed similar issue last time :-( Fixes: 92b7968 (fsp: Skip sysdump retrieval only in MPIPL boot) Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-28hw/phb4: Verify AER support before initialising AER regsOliver O'Halloran1-0/+3
Check the AER capability offset pointer is non-zero before enabling the AER messages. If the device doesn't support AER we end up writing garbage to config offset 0x0 + PCIECAP_AER_CAPCTL, or 0x18. For a normal device this is one of the BARs so this doesn't do much, but for a bridge this results in overriding: 0x18 - The primary bus number 0x19 - The secondary bus number 0x1A - The subordinate bus number 0x1B - The latency timer 0x1B is hardwired to zero for PCIe devices, but overwriting the bus number register can cause issues with routing of config space accesses. It's worth pointing out that we write actual values for the secondary and subordinate bus numbers before scanning the secondary bus, but the primary bus number is never restored. Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-28hw/phb4: Actually enable error reportingOliver O'Halloran1-0/+1
PHB3 had an errata about correctable errors and when Ben was doing the initial PHB4 port he deleted the corresponding config write to DEVCTL. Whoops. Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07imc: Use pir_to_core_id() rather than cpu_get_core_index()Benjamin Herrenschmidt1-4/+4
The IMC HW targets HW ECs, not fused cores on P9 Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07slw: Limit fused cores P9 to STOP0/1/2Benjamin Herrenschmidt1-1/+81
FROM: Benjamin Herrenschmidt <benh@kernel.crashing.org> Linux doesn't know how to properly restore state on "both halves" of a fused core, so limit ourselves to STOP states that don't require HV state restore for bare metal kernels (KVM is still broken) until we add a new representation for STOP states. The new representation will have per-state versioning so that we can control their individual enablement based on whether the OS has the necessary workarounds to make them work. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07xive: Set the fused core mode properlyBenjamin Herrenschmidt1-0/+4
Set or clear the fused core mode bit in the XIVE inits properly. While HostBoot is supposed to do it, I prefer not depending on it doing the right thing, since we already configure that register ourselves anyway. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Add basic P9 fused core supportRyan Grimm1-1/+1
P9 cores can be configured into fused core mode where two core chiplets function as an 8-threaded, single core. So, bump four to eight in boot_entry when in fused core mode and cpu_thread_count in init_boot_cpu. The HID, AMOR, TSCR, RPR require the first active thread on that core chiplet to load the copy for that core chiplet. So, send thread 1 of a fused core to init_shared_sprs in boot_entry. The code checks for fused core mode in the core thead state register and puts a field in struct cpu_thread. This flag is checked when updating the HID and in XIVE code when setting the special bar. For XSCOM, the core ID is the non-fused EX. So, create macros to arrange the bits. It's fairly verbose but somewhat readable. This was tested on a P9 ZZ with 16 fused cores and ran HTX for over 24 hours. Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07xive/p9: Enforce thread enablement before TIMA accessesCédric Le Goater1-0/+15
To activate the HW thread context ring, and its associated thread interrupt registers, a thread needs to raise the VT bit in word2. This requires access to the TIMA and this access is only granted if the thread was first enabled at the XIVE IC level. This is done in a sequence in xive_cpu_callin() but there is a chance that the accesses done on the TIMA do not see the update of the enable register. To make sure that the enablement has completed, add an extra load on the PC_THREAD_EN_REGx register. This guarantees that the TIMA accesses will see the latest state of the enable register. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07xive: Fix typos in commentsGustavo Romero1-2/+2
Fix a typo in comment about Presentation Controller Base Address Register and another typo about code to configure the queue overflows. Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07hw/psi-p9: Configure IRQ offset before XIVE notifyOliver O'Halloran1-10/+10
When configuring the XIVE notification address any currently pending interrupts will be delivered once the the valid bit in the BAR is set. Currently we enable the notify BAR before we've configured the global interrupt number offset for the PSI interrupts. If any PSI interrupt is pending at this point we'll send an interrupt trigger notification for the wrong interrupt vector. This can potentially cause a checkstop since there may not be an EAS / IVT configure for that vector. Fix this by fixing the ordering so we setup the offset before the XIVE notification address. Cc: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-07-02fsp: Skip sysdump retrieval only in MPIPL bootVasant Hegde1-3/+11
It seems we should continue to retrieval SYSDUMP except in MPIPL boot. Fixes: d6eb510 (fsp: Ignore platform dump notification on P9) Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-30xive: Fix two typos in commentsGustavo Romero1-2/+2
This commit fixes two typos in XIVE comments about how to handle an escalation event. Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-30prd: Do not assert if HBRT makes unsupported callVasant Hegde1-13/+29
There are few PRD function which are specific to FSP/BMC. If HBRT accidently makes those call we are asserting today.. which is not good. This function replaces those assert()'s with OPAL_UNSUPPORTED return value. Suggested-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-30mpipl: Move opal_mpipl_save_crashing_pir() call to platform specific codeVasant Hegde2-0/+7
Commit 34664746 moved opal_mpipl_save_crashing_pir() function call from platform specific code to generic assert() path. I completely missed to take care of all terminate path :-( This resulted in breaking `opalcore` on Linux kernel initiated MPIPL. As : - Linux initiated MPIPL calls platform termination function directly - ELF core format needs crashing CPU details to generate proper code Hence I think it makes sense to move this back to platform specific terminate handler code. Today we have two ways to trigger MPIPL based on service processor. - On BMC system we call SBE S0 interrupt - On FSP system we call `attn` instruction In future if we add new ways to trigger MPIPL then we have to add platform specific support code anyway. That way its fine to move this to platform sepcific code. One alternative is to make this call in all code path before making platform.terminate call... which makes it more complicated than above approach. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-30mpipl: Delay MPIPL registration until OPAL init is completeVasant Hegde1-1/+1
If OPAL boot fails after MPIPL init (opal_mpipl_init()) then we call MPIPL boot instead of reboot. BMC is not aware of MPIPL. Hence it may result in continuous MPIPL loop (boot -> crash -> MPIPL -> boot). If OPAL boot fails (before loading kernel) then its better to call reboot. So that BMC can detect `n` number of boot failures (generally n = 3) and stop booting. That way we can avoid continuous loop. This patch moves MPIPL init to the end of init process (just before starting kernel). So that if we fail to boot OPAL we call normal reboot. Also this patch introduces new function to detect MPIPL is enabled or not (is_mpipl_enabled()). And in assert() path we check for this function instead of `dump` DT node. So that it will make sure we will not call MPIPL until opal_mpipl_init is complete. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-30uart: Actually swallow data if LPC is not workingVasant Hegde1-1/+1
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-30dt: Set new property length in dt_resize_property()Thiago Jung Bauermann3-3/+0
All callers of dt_resize_property() need to set the new property length after calling it. append_chip_id() wasn't doing it, which caused this assert when booting my machine: [ 136.387213258,3] Unable to use memory range 0 from MSAREA 0 [ 136.387356677,3] Unable to use memory range 0 from MSAREA 2 [ 136.387408390,3] *********************************************** [ 136.387454272,3] < assert failed at core/device.c:605 > [ 136.387493225,3] . [ 136.387512799,3] . [ 136.387534056,3] . [ 136.387550294,3] OO__) [ 136.387579530,3] <"__/ [ 136.387605086,3] ^ ^ [ 136.387719329,3] Fatal TRAP at 0000000030028a18 .dt_property_set_cell+0x34 MSR 9000000000021002 [ 136.387801707,3] CFAR : 00000000300bfd3c MSR : 9000000000001000 [ 136.387847032,3] SRR0 : 0000000030028a18 SRR1 : 9000000000021002 [ 136.387893119,3] HSRR0: 0000000030012524 HSRR1: 9000000000001000 [ 136.387936830,3] DSISR: 40000000 DAR : 00000002019df000 [ 136.387983570,3] LR : 00000000300bfd40 CTR : 0000000000000000 [ 136.388046031,3] CR : 20004202 XER : 00000000 [ 136.388094553,3] GPR00: 00000000300bfd40 GPR16: 0000000000000001 [ 136.388139862,3] GPR01: 0000000031e536e0 GPR17: 00000000300ca3c9 [ 136.388181131,3] GPR02: 0000000030121200 GPR18: 0000000030103e1c [ 136.388224105,3] GPR03: 000000003053fc60 GPR19: 0000000000000008 [ 136.388270356,3] GPR04: 0000000000000001 GPR20: 000000003053fba0 [ 136.388313950,3] GPR05: 0000000000000008 GPR21: 0000000000000001 [ 136.388363021,3] GPR06: 0000000031e50060 GPR22: 0000000000000001 [ 136.388416754,3] GPR07: 0000000000000000 GPR23: 0000000000000000 [ 136.388465729,3] GPR08: 0000000000000000 GPR24: 0000000000000000 [ 136.388508156,3] GPR09: 0000000000000004 GPR25: 0000000031204060 [ 136.388556203,3] GPR10: 0000000000000008 GPR26: 000000003120402c [ 136.388599076,3] GPR11: 0000000000000000 GPR27: 0000000030010000 [ 136.388642108,3] GPR12: 0000000040004204 GPR28: 0000000000000002 [ 136.388694064,3] GPR13: 0000000031e50000 GPR29: 0000000031203ee0 [ 136.388743298,3] GPR14: 00000000300cbf03 GPR30: 0000000031202e80 [ 136.388797131,3] GPR15: 00000000300cc01c GPR31: 0000000030103a33 CPU 0048 Backtrace: S: 0000000031e539e0 R: 0000000030028874 .dt_resize_property+0x28 S: 0000000031e53a60 R: 00000000300bfd40 .memory_parse+0xd84 S: 0000000031e53c40 R: 00000000300bc4d8 .parse_hdat+0xed0 S: 0000000031e53e30 R: 000000003001504c .main_cpu_entry+0x1ac S: 0000000031e53f00 R: 0000000030002760 boot_entry+0x1b0 Avoid further appearances of the unidentified animal of doom by making dt_resize_property() do the length updating itself, freeing its callers from that need. Suggested-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-30xive/P9: Use NUM_INT_PRIORITIES in xive_reset()Cédric Le Goater1-1/+1
Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
generated by cgit v1.1 at 2024-09-08 22:10:39 +0000