| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
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>
|
|
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>
|
|
hw/fsp/fsp-sensor.c:425:3: warning: Value stored to 'sensor_buf_ptr' is never read
sensor_buf_ptr = (uint32_t *)((uint8_t *)sensor_buffer +
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
hw/fsp/fsp-sensor.c:748:4: warning: Value stored to 'sensor_buf_ptr' is never read
sensor_buf_ptr = (uint32_t *)((uint8_t *)sensor_buffer
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Since skiboot is all BE, no built code changes
hw/fsp/fsp-mem-err.c:215:35: warning: invalid assignment: |=
hw/fsp/fsp-mem-err.c:215:35: left side has type restricted beint16_t
hw/fsp/fsp-mem-err.c:215:35: right side has type int
hw/fsp/fsp-mem-err.c:228:57: warning: incorrect type in assignment (different base types)
hw/fsp/fsp-mem-err.c:228:57: expected restricted beint64_t [addressable] [assigned] [usertype] physical_address_start
hw/fsp/fsp-mem-err.c:228:57: got unsigned long long [unsigned] [usertype] paddr
hw/fsp/fsp-mem-err.c:229:55: warning: incorrect type in assignment (different base types)
hw/fsp/fsp-mem-err.c:229:55: expected restricted beint64_t [addressable] [assigned] [usertype] physical_address_end
hw/fsp/fsp-mem-err.c:229:55: got unsigned long long
hw/fsp/fsp-mem-err.c:269:65: warning: incorrect type in assignment (different base types)
hw/fsp/fsp-mem-err.c:269:65: expected restricted beint64_t [usertype] physical_address_end
hw/fsp/fsp-mem-err.c:269:65: got unsigned long long [unsigned] [usertype] paddr_end
hw/fsp/fsp-mem-err.c:318:58: warning: incorrect type in assignment (different base types)
hw/fsp/fsp-mem-err.c:318:58: expected restricted beint64_t [addressable] [assigned] [usertype] physical_address_start
hw/fsp/fsp-mem-err.c:318:58: got unsigned long long [unsigned] [usertype] paddr_start
hw/fsp/fsp-mem-err.c:319:56: warning: incorrect type in assignment (different base types)
hw/fsp/fsp-mem-err.c:319:56: expected restricted beint64_t [addressable] [assigned] [usertype] physical_address_end
hw/fsp/fsp-mem-err.c:319:56: got unsigned long long [unsigned] [usertype] paddr_end
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No code changes in skiboot due to being BE
hw/fsp/fsp-mem-err.c:162:44: warning: restricted beint64_t degrades to integer
hw/fsp/fsp-mem-err.c:263:45: warning: restricted beint64_t degrades to integer
hw/fsp/fsp-mem-err.c:266:52: warning: restricted beint64_t degrades to integer
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No generated code change for skiboot, as is BE
hw/fsp/fsp-dump.c:422:31: warning: invalid assignment: +=
hw/fsp/fsp-dump.c:422:31: left side has type signed long long
hw/fsp/fsp-dump.c:422:31: right side has type restricted beint64_t
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
hw/fsp/fsp-attn.c:104:30: warning: incorrect type in assignment (different base types)
hw/fsp/fsp-attn.c:104:30: expected restricted beint32_t <noident>
hw/fsp/fsp-attn.c:104:30: got unsigned int [unsigned] [usertype] <noident>
No generated code change for skiboot as we're BE
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
hdata/spira.c:94:25: warning: incorrect type in initializer (different base types)
hdata/spira.c:94:25: expected unsigned long long [unsigned] [usertype] addr
hdata/spira.c:94:25: got restricted beint64_t [usertype] <noident>
hdata/spira.c:95:25: warning: incorrect type in initializer (different base types)
hdata/spira.c:95:25: expected unsigned int [unsigned] [usertype] type
hdata/spira.c:95:25: got restricted beint32_t [usertype] <noident>
hdata/spira.c:96:25: warning: incorrect type in initializer (different base types)
hdata/spira.c:96:25: expected unsigned int [unsigned] [usertype] size
hdata/spira.c:96:25: got restricted beint32_t [usertype] <noident>
hdata/spira.c:99:25: warning: incorrect type in initializer (different base types)
hdata/spira.c:99:25: expected unsigned long long [unsigned] [usertype] addr
hdata/spira.c:99:25: got restricted beint64_t [usertype] <noident>
hdata/spira.c:100:25: warning: incorrect type in initializer (different base types)
hdata/spira.c:100:25: expected unsigned int [unsigned] [usertype] type
hdata/spira.c:100:25: got restricted beint32_t [usertype] <noident>
hdata/spira.c:101:25: warning: incorrect type in initializer (different base types)
hdata/spira.c:101:25: expected unsigned int [unsigned] [usertype] size
hdata/spira.c:101:25: got restricted beint32_t [usertype] <noident>
This also means we use proper conversions in fsp-mdst-table.c
This means no actual change for skiboot as it's BE.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch makes below code improvements in DPO driver
for FSP based systems:
1. Improves code logic at few places.
2. Improves logging by changing PR_TRACE severity to
PR_INFO for log messages and adding new log messages.
3. Removes unused header files.
4. Replaces Sapphire word with OPAL in comments.
Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fixes: 8f433d6cd4f92b4f878e5ddc414e2800a2fb7140
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
This bug has originated since day 1 (of public release), what was going on
was that we were incorrectly using PSI_DMA_LOC_COD_BUF as the *address*
to write to for the FSP to read rather than using that purely as the
TCE table.
What we *should* have been doing (and this patch now does), is allocating
some (aligned) memory and using it.
With this patch, we no longer write over some poor random memory location
that could be being used by the host OS for something important, for example,
in the (internal) bug report of this, it was futex_hash_bucket in Linux
being replaced with our structure for replying to FSP_CMD_GET_LED_LIST (which
is around 4kb) and Linux doesn't like it when you replace a bunch of lock
data structures with essentially garbage.
Since this is FSP LED code specific, this only affects FSP based systems.
Reported-by: Dionysius d. Bell <belldi@us.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch makes below changes in chiptod code to improve quality
Changes in hw/chiptod.c
- Uses pr_fmt macro for tagging log messages
- Simplifies if conditions
- Removes extra write spaces
Changes in hw/fsp/fsp-chiptod.c
- Uses pr_fmt macro for tagging log messages
Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The patch fixes an illegal access to the memory which has been
freed.
Fixes Coverity defect # 101858
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently abort() call sets up HID0, triggers attention and finally
calls infinite for loop. FSP takes care of collecting required logs
and reboots the system. This sequence is specific to FSP machine
and it will not work on BMC based machine. Hence move FSP specific
code to hw/fsp/fsp-attn.c.
Note that this patch adds new parameter to abort call. Hence replaced
_abort() by abort() in exception.c so that we can capture file info
as well.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In the event that we had no IO paths up, we could index -1 into the
array of iopaths, no doubt causing casual amounts of fun.
Although, since this is in early boot code only, the possibility of
this being a problem is quite slim.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Instead just print a PR_TRACE notice as (by design), this is an okay thing.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
See https://github.com/lucasdemarchi/codespel
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Initialized variable rc to 0, to fix uninitialized value
issue.
Fixes Coverity defect#101857.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Acked-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If chiptod_adjust_topology returned true, rc would be uninitialised and the
message type passed to fsp_mkmsg would be undefined.
This also changes chiptod_adjust_topology to return true/false instead
of -1 and 0.
hw/fsp/fsp-chiptod.c:45:7: error: variable 'rc' is used uninitialized whenever
'if' condition is false [-Werror,-Wsometimes-uninitialized]
if (chiptod_adjust_topology(topo, action) < 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hw/fsp/fsp-chiptod.c:48:50: note: uninitialized use occurs here
resp = fsp_mkmsg(FSP_RSP_TOPO_ENABLE_DISABLE | rc, 0);
^~
hw/fsp/fsp-chiptod.c:45:3: note: remove the 'if' if its condition is always true
if (chiptod_adjust_topology(topo, action) < 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hw/fsp/fsp-chiptod.c:30:12: note: initialize the variable 'rc' to silence this
warning
uint8_t rc;
^
= '\0'
Signed-off-by: Joel Stanley <joel@jms.id.au>
foo
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
There are now no users of the call_out parameter and future users should
use the log_append_msg() and log_append_data() functions, so remove all
references to call_out.
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Remove the callback functionality from log_error() and replace it with
the ability to append to a user data section, or add addtional user
data sections to an error log.
For multiline or otherwise complex logging the convention is now to call
opal_elog_create() to obtain a errorlog buffer and use log_append_msg()
and log_append_data() to append to the user data section. Additional
user data sections can be added to the error log via log_add_section().
The caller is then responsible for calling log_commit().
For simple logs log_simple_error() takes care of creating and committing
the error log as before.
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Ideally service processor shouldn't request OPAL for SAI state...as this
LED is controlled by service processor itself.
But of some reason its asking OPAL to provide state. Hence handle this
request until FSP team fixes it.
Sample log without this patch:
[77884350335,3] FSPLED: Could not find the location code LC=U8246.L2C.060377A
[77942662287,8] FSPLED: FSP_CMD_GET_LED_LIST command received
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We added led-loc property.. which contains LED location information.
But this property was never used. Also we can make out LED location
(enclosure/component) based on location code (if location code doesn't
contain "-" means its enclosure location code).
As Ben suggested [1], removing this property.
Present code is included in skiboot skiboot-5.0 release..But we don't
have any consumer yet. Hence I think its fine to make this changes.
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-June/130433.html
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
FSP implements the IPMI commands support that can be accessed over
the mailbox interface from the host. The host needs to provide and
receive the message/data bytes of the IPMI command in the TCE space
in the KCS (Keyboard Controller Style) format.
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Acked-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Whenever FSP makes any changes to backup topology as part of either
routine hardware maintenance or fixing failed backup topology configuration,
it sends out mailbox command xE6, s/c 0x06, mod 0, to enable/disable
the backup topology. OPAL layer should keep itself up-to-date with accurate
details of current topology configurations. This will help OPAL layer to
successfully handle any TOD failover in future.
The FSP can only request that the currently inactive (backup) topology be
disabled or enabled. If the requested topology is currently the active
topology, then fail this request with a 0xB8 (TOD topology in use) status
as return code.
For disable request, set the backup topology status as disabled.
For enable request, scan all the available chips and find the new backup
master chip by looking at TOD status register of each chip.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Updated opal-messages.txt with description of OPAL EPOW and DPO messages
Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
struct led_set_cmd cmd is zalloc. While doing strncpy of
loc_code to cmd->loc_code, there are chances of cmd->loc_code
being unterminated. Fix the issue by copying LOC_CODE_SIZE - 1.
Fixes Coverity defect #100249.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
NULL terminate and truncate size of copy into char buffer to the right size.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
... instead of potentially unbounded src buffer size
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Safety check...
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Safety check...
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
There is one instance of fsp_surv_state that is accessed without
the surveillance lock. Fix it.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch performs below cleanup:
* Removes processing for SPCN bits as SPCN events don't cause any EPOW
* Removes code to do a panel status query again after receiving mbox
panel status notification which already has EPOW info present.
* Edits some debug prints and comments.
* Removes extra header files included.
Current OPAL EPOW driver would be parsing mbox panel status notifications
for EPOW info and sending OPAL_MSG_EPOW notification once EPOW is detected.
System on UPS power, abnormal ambient or internal temp EPOW conditions are
covered by driver.
Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
