| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a new structure that contains the implementations of the various
OPAL console handlers. This is intended to replace the existing ad-hoc
mechanism where the OPAL call handlers are overwritten in the OPAL
console driver's init function.
Currently this just moves the site where the OPAL call handlers are
overwritten to inside of console.c, but it is intended to give us a
mechanism for implementing features such as pointer validation for the
OPAL console calls without having to manually update each driver.
This also helps to clarify differences between the internal (skiboot)
console and the external (OPAL) console.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Adds a separate structure to house the operations for the OPAL console.
This is used to define a new API for dealing with the OPAL console in
the next patch.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
The creation of /ibm,skiboot/console/serial@<xyz> nodes is pretty much
identical across the various OPAL console drivers. This patch moves it
into a helper function as a cleanup.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
There is only one use of this function outside of console.c and that
usage is broken. As the name suggests this is an internal function that
is only safe when the console lock held is held. flush_console() will
acquire the lock for the caller so that should be used instead.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we are hijacking the last bit of the resource field of the
sensor handler to differentiate the sensor families and route the
opal_sensor_read() call to the appropriate component.
Let's reserve the last 3bits and provide an API to set the sensor
family for current use and future use. This gives us a maximum of 8
families and 32 resource classes. The FSP uses 15, so we should be
fine for a while.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
If we were to terminate in a poller, we'd call op_display() which
called pollers which hit the recursive poller warning, which ended
in not much fun at all.
This patch will skip the running of pollers and instead run
the FSP poller to set the op-panel display before attn.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
elog_reject_head() routine makes the state 'elog_read_from_fsp_head_state'
either 'ELOG_STATE_REJECTED' or 'ELOG_STATE_NONE' depending on the current
state of 'elog_read_from_fsp_head_state'.
We can remove this elog_reject_head() from 'opal_kexec_elog_notify()' as just
after that it is called inside 'fsp_opal_resend_pending_logs()'. So, it is
redundant inside opal_kexec_elog_notify() routine.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use 'elog_enabled' flag to check whether host OS is ready to receive
error log or not. This is nothing to do with reading error log from
service processor.
This patch is to remove the check and keep this 'elog_enabled' free from
FSP specific code and move it into core/errorlog.c in later upcoming patches.
With this changes, in some corner cases we may endup reading same error
log twice from FSP. It happens as we call 'elog_reject_head' inside
'fsp_opal_resend_pending_logs' which makes the state either
'ELOG_STATE_REJECTED' or 'ELOG_STATE_NONE'. So, a call to
'fsp_elog_check_and_fetch_head' routine ends up reading the error
log from FSP which was already read. This case happens twice in a reboot
as whenever 'fsp_opal_resend_pending_logs' gets called.
So, we can ignore it.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Some modifications related to typo errors, alignment, case letter mismatch to add
more clarity to the code.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
[stewart@linux.vnet.ibm.com: unlock before return (suggested by Mahesh/Andrew),
disable only on non-cancelling fsp codeupdate call (suggested by Vasant)]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an experimental patch that implements "Fast reboot" on P8
machines.
The basic idea is that when the OS calls OPAL reboot, we gather all
the threads in the system using a combination of patching the reset
vector and soft-resetting them, then cleanup a few bits of hardware
(we do re-probe PCIe for example), and reload & restart the bootloader.
For Trusted Boot, this means we *add* measurements to the TPM, so you
will get *different* PCR values as compared to a full IPL. This makes
sense as if you want to be sure you are running something known then,
well, do a full IPL as soft reset should never be trusted to clear any
malicious code.
This is very experimental and needs a lot of testing and also auditing
code for other bits of HW that might need to be cleaned up.
BenH TODO: I also need to check if we are properly PERST'ing PCI devices.
This is partially based on old code I had to do that on P7. I only
support it on P8 though as there are issues with the PSI interrupts
on P7 that cannot be reliably solved.
Even though this should be considered somewhat experimental, we've had
a lot of success on a variety of machines. Dozens/hundreds of reboots
across Tuleta, Garrison and Habanero.
Currently, we've hidden it behind a NVRAM config option, which *is*
liable to change in the future (to ensure that only those who know
what they're doing enable it)
You can enable the experimental support via nvram option:
nvram -p ibm,skiboot --update-config experimental-fast-reset=feeling-lucky
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[stewart@linux.vnet.ibm.com: hide behind nvram option, include Mambo fixes
from Mikey]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Allocate an irq number for each hvc console and set its interrupt-parent
property so that Linux can use the opal irqchip instead of the
OPAL_EVENT_CONSOLE_INPUT interface.
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Presently we set timeout value as soon as we add elog to queue. If
we have multiple elogs to write, it doesn't consider queue wait time.
Instead set timeout value when we are actually sending elog to FSP.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OPAL gets elog notification from service processor which contains log
information. Once we get notification we start reading log data and
change elog state to ELOG_STATE_FETCHING.
Hence we don't need ELOG_STATE_FETCHED_INFO state. Lets remove this
variable.
Also in some places we have used this state after sending event information
to host. Replace such usage with better state (ELOG_STATE_HOST_INFO).
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
I was only ever set to true
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue is one of the corner case, which is related to recent change
went upstream and only observed in the petitboot prompt, where we see
only one error log instead of getting all error log in
/sys/firmware/opal/elog.
Below is snippet of the code, where elog module in the kernel
initialised.
{
..
...
rc = request_threaded_irq(irq, NULL, elog_event, =<=======
IRQF_TRIGGER_HIGH | IRQF_ONESHOT, "opal-elog", NULL); |
if (rc) { |
pr_err("%s: Can't request OPAL event irq (%d)\n", |
__func__, rc); |
return rc; |
} |
/* We are now ready to pull error logs from opal. */ |
if (opal_check_token(OPAL_ELOG_RESEND)) |
opal_resend_pending_logs(); =<=======
}
Scenario:
While elog_enabled is true, OPAL_EVENT_ERROR_LOG_AVAIL will be set from
OPAL, whenever it has error logs that are waiting to be fetched from the
kernel.
Race occurs between the code arrowed above, as soon as kernel registers
error log handler, it sees OPAL_EVENT_ERROR_LOG_AVAIL is set, so it
schedule the handler. Which makes 'opal_get_elog_size'(kernel) call on
the error log set the state from ELOG_STATE_FETCHED_DATA to
ELOG_STATE_FETCHED_INFO and clears OPAL_EVENT_ERROR_LOG_AVAIL. During
the same time 'opal_resend_pending_logs'(kernel) call which will set the
state machine from ELOG_STATE_FETCHED_INFO to ELOG_STATE_NONE in OPAL.
Because of that, read call from the kernel, which was to be made after
the 'opal_get_elog_size' ends up failing. But, the elog kobject was
created for the particular error log.
Further in the resend routine in the OPAL, we make opal_commit_elog_in_host()
call that sets OPAL_EVENT_ERROR_LOG_AVAIL. So, Kernel again makes
'opal_get_elog_size' which results in getting the error log info of the
same error log which was fetched earlier. It also changes the state
machine to ELOG_STATE_FETCHED_INFO and clears OPAL_EVENT_ERROR_LOG_AVAIL.
Below is the snippet from the elog_event registered handler call
{
...
...
/* we may get notified twice, let's handle
* that gracefully and not create two conflicting
* entries.
*/
if (kset_find_obj(elog_kset, name))
return IRQ_HANDLED;
...
...
}
In the kernel, we search kobject for the error log whether it already
exist. So kobject is found and it returns without reading error log
data.
So, this patch makes the flag which was true during initialisation
to false. And that solves the race.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
We have used TCE_MASK value (4095) instead of TCE_PSIZE (4096) to align memory
source address. In some corner cases (like source memory size = 4097) we may
endup doing wrong mapping and corrupting part of SYSDUMP.
This patch uses ALIGN_UP macro with TCE_PSIZE value for alignining memory.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Fix resend logic in opal_resend_pending_logs, so that it actually
restarts sending remaining logs.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some corner cases host may send acknowledgement without
reading actual data (fsp_opal_elog_info -> fsp_opal_elog_ack).
Because of this elog_read_from_fsp_head_state may be stuck in
wrong state (ELOG_STATE_HOST_INFO) and not able to send remaining
ELOG's to host. Hence reset ELOG state and start sending remaining
ELOG's.
Also in normal case we will ACK the logs which are already processed
(elog_read_processed). Hence rearrange the code such that we go
through elog_read_processed first.
Finally return OPAL_PARAMETER if we are not able to find ELOG ID.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: spelling fix]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Chances of elog_read_pending inconsistent state is very very
less. Just to be on safer side, disable notification if list
is not in consistent state.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ELOG enables event notification once new log is available. And this
will be disabled after host completes reading logs (it has to complete
both fsp_opal_elog_info and fsp_opal_elog_read).
Ideally we should disable notification as soon as host consumes event
(after fsp_opal_elog_info). Also if host fails to call fsp_opal_elog_read
(ex: situations like duplicate event), then we endup keeping notification
forever.
This patch introduces new ELOG state (ELOG_STATE_HOST_INFO). As soon
as host consumes event elog will move to this new state so that event
notification is disabled.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use elog notifier to notify logs from multiple sources (FSP generated
logs - fsp-elog-read.c and OPAL generated logs - fsp-elog-write.c).
OPAL generated logs sets elog event bit whenever it has new logs to send
to host. But it relies on fsp-elog-read.c to disable the event bit..which
is wrong!
This patch creates common function to enable/disable event notification.
It will enable event notification if any of the source is ready to send
error log to host and disables notification once it completes sending
all errors to host.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ELOG enables event notification once new log is available. And this
will be disabled after host completes reading logs (it has to complete
both fsp_opal_elog_info and fsp_opal_elog_read).
In some corner cases like kexec, host may endup reading same ELOG id twice
(calling fsp_opal_elog_info twice because of resend request). Host finds it
as duplicate and it will not read actual log (fsp_opal_elog_read()). In such
situations we fails to disable event notification :-(
Scenario :
OPAL Host
-------------------------------------
OPAL_EVENT_ELOG_AVAIL --> kexec
OPAL_EVENT_ELOG_AVAIL --> elog client registered
<-- read ELOG (id=x)
<-- resend elog (opal_resend_pending_logs())
resend all ELOG --> read ELOG (id=x) -- Duplicate ELOG !
bhoom!!
kernel call trace:
------------------
[ 28.055923] CPU: 10 PID: 20 Comm: irq/29-opal-elo Not tainted 4.4.0-24-generic #43-Ubuntu
[ 28.056012] task: c0000000ef982a20 ti: c0000000efa38000 task.ti: c0000000efa38000
[ 28.056100] NIP: c000000008010a24 LR: c000000008010a24 CTR: 0000000030033758
[ 28.056188] REGS: c0000000efa3b9c0 TRAP: 0901 Not tainted (4.4.0-24-generic)
[ 28.056274] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 22000844 XER: 20000000
[ 28.056499] CFAR: c000000008009958 SOFTE: 1
GPR00: c000000008131e8c c0000000efa3bc40 c0000000095b4200 0000000000000900
GPR04: c0000000094a63c8 0000000000000001 9000000100009033 0000000000000062
GPR08: 0000000000000000 0000000000000000 c0000000ef960400 9000000100001003
GPR12: c00000000806de48 c00000000fb45f00
[ 28.057042] NIP [c000000008010a24] arch_local_irq_restore+0x74/0x90
[ 28.057117] LR [c000000008010a24] arch_local_irq_restore+0x74/0x90
[ 28.057189] Call Trace:
[ 28.057221] [c0000000efa3bc40] [c0000000f108a980] 0xc0000000f108a980 (unreliable)
[ 28.057326] [c0000000efa3bc60] [c000000008131e8c] irq_finalize_oneshot.part.2+0xbc/0x250
[ 28.057429] [c0000000efa3bcb0] [c000000008132170] irq_thread_fn+0x80/0xa0
[ 28.057519] [c0000000efa3bcf0] [c00000000813263c] irq_thread+0x1ac/0x280
[ 28.057609] [c0000000efa3bd80] [c0000000080e61e0] kthread+0x110/0x130
[ 28.057698] [c0000000efa3be30] [c000000008009538] ret_from_kernel_thread+0x5c/0xa4
[ 28.057799] Instruction dump:
[ 28.057844] 994d02ca 2fa30000 409e0024 e92d0020 61298000 7d210164 38210020 e8010010
[ 28.057995] 7c0803a6 4e800020 60420000 4bff17ad <60000000> 4bffffe4 60420000 e92d0020
This patch adds kexec notifier client. It will disable event notification
during kexec. Once host is ready to receive ELOG's again it will call
fsp_opal_resend_pending_logs(). This call re-enables ELOG notication.
It will fix above issue. I will add follow up patch to improve event state.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux kernels from v4.1 onwards will try to request an irq for each hvc
console using OPAL_EVENT_CONSOLE_INPUT, however because the IRQF_SHARED
flag is not set any console after the first will fail. If there is data
on one of these failed consoles OPAL will set OPAL_EVENT_CONSOLE_INPUT
every time fsp_console_read is called, leading to RCU stalls in the
kernel.
As a workaround for unpatched kernels, cease setting
OPAL_EVENT_CONSOLE_INPUT for consoles that we have noticed are not being
read.
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
We don't need to validate msg->resp message as its always
allocated.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
fsp_allocmsg() returns true even if msg->resp memory allocation fails.
Validate msg->resp memory allocation as well.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the function __opal_write_oppanel() coverity complains about an out
of bounds array access. While the pointer is never actually dereferenced,
this isn't immediately obvious from the code. Additionally the number and
length of the lines on the operator panel display are hard coded into
the function. While we are here we might as well move these into a #define
statement.
Rework the code in __opal_write_oppanel() where the message is copied into
the buffer so that coverity won't complain about an out of bounds array
access and so that it is line number and length agnostic (now relying on
the #defined values).
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
| |
Only the major ones at this point in time.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
These errors are essentially assert()s - something has gone wrong and
it's likely because of a bug somewhere. Things we should *never* it
regards to inconsistency, so have FWTS throw warnings on them.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
This changes trigger_attn() to also enable attn via HID0, so callers
don't have to do it themselves.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|\ |
|
| |\
| | |
| | |
| | | |
Merge PHB3 race fix
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem Description:
During FSP termination/reset, FSP received mbox command from OPAL for
"Fetching platform management function data". As FSP is in termination
state DMAE operation failed to write memory data to hypervisor,
so FSP sent mbox command with response status as 0x24 to OPAL and
OPAL committed a predictive log with SRC BB822411 and sent back
response status as 0xFE, which FSP IPMI will not understand the
failure at the Host and IPMI will log the error.
Fix:This patch is to fix when OPAL receives a bad response from FSP 0x24
due to DMAE error, commit informational log and return response status
as SUCCESS and for all other bad status response commit predictive log.
Signed-off-by: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
Removes the redundant header file fsp-elog.h from hw/fsp/fsp-codeupdate.c
and hw/p8-i2c.c
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Acked-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current code in OPAL exposing the FSP sensors in the device tree
is very SPCN-centric which makes it difficult to add new sensors
fitting with the ibmpowernv Linux driver. This patch proposes some
improvements on the way the device tree is created.
The logic behind the node creation is preserved. The DMA sensor buffer
is parsed, looping on the PRS command modifiers and entries while
nodes are being created under the "ibm,opal/sensors/" directory. The
code now splits the creation under separate routines, one for each
modifier, and use the same old pattern for names :
<resource class name>#<index>-attribute/
Each resource node is compatible with :
"ibm,opal-sensor-<resource classname>"
There is a mapping to be done between the attributes of a same
resource and the PRS command used to collect them. This adds some
complexity in the code when creating the node and when building a
request for the FSP.
For instance, the status of a FSP sensor which can be returned by one
or more PRS command modifiers. For power supply and fans, we choose
the PRS modifier (and not DATA) to return the AC_FAULTED bit. For the
ambient temperature, there is no other choice than to use the DATA
modifier. The status bits being :
PRS PARAM/DATA
Modifier Modifier
0x0010 ON SUPPORTED
0x0008 ON
0x0004 AC FAULTED EM ALERT
0x0002 FAULTED FAULTED
0x0001 PRESENT PRESENT
we only keep bits[1-2] to reflect the fault status to Linux.
Another significant change is that the power consumption is now
reported for each power supply and not as a whole like before. A Tuleta
can have up to four distinct power supplies so it seems an interesting
resource to report independently.
Currently, we handle the "power-supply", "cooling-fan" and "amb-temp"
resource classes. More exist in the specs but they have not showed up
on the Tuleta I used.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|\ \
| |/ |
|
| |
| |
| |
| |
| | |
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since we are anyway on the way to standby and apparently the other
hypervisor also does this.
Tested-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we got FSP_STATUS_TOD_RESET or similar, we would return OPAL_BUSY
which would cause the Linux OPAL RTC driver to retry in a loop until
we didn't say we're busy.
The problem with this is that some errors, such as FSP_STATUS_TOD_RESET
are, in fact, permanent until we (say) set the time explicitly, so no
matter how hard that little linux driver tries, it's never going to
break out of that loop.
This fix is to fix our use of the state machine introduced way back in
6cf8b663e7d7cb1e827b6d9c90e694ea583f6f87 so that we return an error code
to linux.
Reported-by: Cédric Le Goater <clg@fr.ibm.com>
Fixes: 6cf8b663e7d7cb1e827b6d9c90e694ea583f6f87
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Cédric Le Goater <clg@fr.ibm.com>
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In a scenario where the DPO has been initiated, but the FSP then went into
reset before the CEC power down came in, OPAL may not give up the link since
it may never see the PSI interrupt. So, if we are in dpo_pending and an FSP
reset is detected via the DISR, give up the PSI link voluntarily.
Tested-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
| |
| |
| |
| | |
Fixes: 8f433d6cd4f92b4f878e5ddc414e2800a2fb7140
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Simple fix as bytes_sent is assigned in the following line.
hw/fsp/fsp-leds.c:817:3: warning: Value stored to 'bytes_sent' is never read
bytes_sent = 0;
^ ~
hw/fsp/fsp-leds.c:830:4: warning: Value stored to 'bytes_sent' is never read
bytes_sent = 0;
^ ~
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|