| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
All current users of mem_reserve are actually wanting HW_RESERVED
memory; these reservations are for memory initialised pre-skiboot.
This change marks these regions as REGION_HW_RESERVED instead of
REGION_RESERVED. We also rename mem_reserve to mem_reserve_hw to reflect
this change.
This fixes an issue where the PRD daemon cannot find reserved ranges
(eg, the homer image) that have been created by skiboot itself.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The kernel is only accessing part of struct opal_prd_msg, and doesn't
need to know about the rest. This change moves the "internal" parts of
opal_prd_msg to a separate header.
In order for the kernel to pass full messages between userspace and
firmware, it needs the total size of the struct. We put this in the
header for the kernel to access.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently, the prd reserved ranges are present in the reserved-ranges
nodes in the device tree. While this works, it's difficult to filter the
actual PRD ranges from general reserved memory.
This change links the prd ranges into the /reserved-memory nodes, by
adding ibm,prd-label properties to those used for PRD.
This change adds a prd node to the ibm,opal node too, to giver kernel &
userspace information about the prd infrastructure provided by OPAL.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
his primarily checks whether the caller already holds the corresponding
locks to avoid re-entrancy in some of the deep error path such as when
XSCOM itself triggers an error log. It will be extended in the case of
LPC to also handle known HW error states.
We use them to avoid queuing/polling in the BT driver and to discard
characters in the UART driver.
Note: This will not normally involve a loss of log to the UART as the
UART driver is also protected by the console suspend mechanism. So
this is a safety mechanism only.
This fixes issues where the generation of error logs inside the LPC or
XSCOM drivers could cause a re-entrancy (via the BT interface)
causing deadlocks. Now, the error logs IPMI messages will be queued up
and delivered later on the next poll handler.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Nothing should be using it nowadays and it's dangerous.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We'll need to leave the FSI presentation bits clear, to allow OCCs to
handle the checkstop interrupt.
This modifies the PRD code to only touch the host presentation bits,
both on init, and in response to incoming PRD actions.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Commit a5ee9d40 does unlock/lock of flash_lock in fsp_code_update_wait_vpd().
This function is called during init as well (where we enter this function
without lock). And in corner cases (CUPD init is not completed) when we
entered this function (in init path) then we hit lock error.
Also remove redundant lock from fsp_flash_firmware...which solves possible
poller lock issue.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
There is a bug (most likely on the bmc) that causes some bt messages to be
ignored. The message data is still in the bt fifo and the message read
pointers still appear to be valid so we can attempt a resend by just
setting the appropriate status flag.
A single retry seems to fix the problem most of the time, however this
should be regarded as a temporary fix. If unlucky we could encounter
the same bug resetting the flag so the message could still get
dropped.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Experiments determined that we need to set the assertion bits as well as
the event data bytes.
To verify the sensor is being set on your BMC, use ipmitool to query the
SEL logs:
$ ipmitool sel list
System Firmware Progress #0x05 | Motherboard initialization | Asserted
System Firmware Progress #0x05 | Memory initialization | Asserted
System Firmware Progress #0x05 | System boot initiated | Asserted
Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In commit e077676 the nx CI's were changed to just use the chip id.
That works fine, except CI 0 is reserved, so if there is a chip id
of 0, the CI is set to 0, which is invalid. This doesn't currently
affect the kernel driver, as it just uses the reserved CI of 0 for
all requests, as CI == 0 tells the hw to auto-select which CI to
send the request to. However, valid CI's should be assigned; we can
use the chip id + 1 to ensure a valid CI.
This commit fixes the CI assignment by setting each CI to the chip
id + 1.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Now that opal.h includes opal-api.h, there are a bunch of files that
include both but don't need to.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
commit c789772 introduced an asynchronous mechanism to load LID resource for
FSP systems. But after this change some of the FSP based system failed
to load/boot petitboot kernel.
While fetching LID resource in multiple chunks, we depend on return
status from FSP whether there is more data available to fetch or not.
As per FSP mailbox documentation, fetch cmd returns status=2 which means,
there is more data pending, and status=0 means we have reached end-of-file.
But in reality FSP don't behave as per the document. It looks like we
always get status=0 irrespective of whether end of file is reached or not.
The old implementation (fsp_sync_msg) used to rely on (wlen < chunk) check
to decide whether we reached end of file or not.
Ideally, FSP folks should be fix their code as per documentation. But until
they do, adding the old check back here again.
Without this patch some system won't be able to boot into petitboot kernel.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Simplify the NX 842 config logic by using the global proc_gen to
conditionally apply P8-specific configuration values, instead of
passing the proc gen in a function parameter.
No functional change here, it just simplifies the code.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Remove the counters for each NX engine that are used to assign a unique
Coprocessor Instance (CI) to each engine, and instead just use the chip
id for the CI.
Originally I created the counter to avoid the possibility of assigning
a CI that was out of the defined range for each engine's CI, but I did
not check then what the max chip id was. Since MAX_CHIPS is 64, which
is less than all the engine's max CI value, the chip id can be safely
used for the engine CI.
Additionally, add a BUILD_ASSERT in each engine's setup to verify that
MAX_CHIPS is <= the engine's max CI.
While this changes the CI numbers that are visible to the kernel driver,
the CI values can't be relied on by the kernel to be any specific number,
so this has no effect from an API perspective. The kernel will simply
use whatever CI values are provided (technically, the current kernel
driver uses the special "0" CI value to allow the hw to select which
instance to use for each request, and it does nothing with the actual
CI values).
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Set the NX crb input queues to be used by 842 only, by not reserving any input
queue slots for the sym or asym engines. This allows the maximum number of
842 crb requests to be queued up, to (hopefully) improve 842 performance.
This patch isn't critical, as the default is no extra input queue locations
for asym, and only 1 extra input queue location for sym, so this only takes
sym's extra location for use by 842.
There is 1 each dedicated input queue location for asym and sym (and 842), so
this patch won't prevent them from working if support is ever added for them.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This is an attempt to make it clearer how to use the sensor set ipmi
command, and to do the correct thing to our BMC.
The boot count was using the incorrect set mask and type. It now confirms
to what the AMI BMC expects.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If FSP messes up SLCA data then attention location code points
to some other location code and its possible that we may endup
in duplicate LED location code :-(
Better to continue with partial LED list than crashing OPAL because
of duplicate node in device tree.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: prlog(PR_WARNING) on duplicate found]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently if fsp_msg_set_led_state() fails then we don't continue
processing remaining LED update request...which is not correct.
Also free spcn_cmd in one place rather than freeing at every failure
block.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
memboot uses bmc system memory instead of a real flash chip. This
patch adds a flash backend for bmc system memory to allow use of the
memboot tool (in external/memboot) to boot the system.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In case of split core, some of the Timer facility errors needs cleanup to be
done before we proceed with the error recovery.
Certain TB/HDEC errors leaves dirty data in timebase and HDEC registers,
which need to cleared before we initiate clear_tb_errors through TFMR[24].
The cleanup has to be done by any one thread from core or subcore.
In split core mode, it is required to clear the dirty data from TB/HDEC
register by all subcores (active partitions) before we clear tb errors
through TFMR[24]. The HMI recovery would fail even if one subcore do
not cleanup the respective TB/HDEC register. Dirty data can be cleaned by
writing zero's to TB/HDEC register.
For un-split core, any one thread can do the cleanup.
For split core, any one thread from each subcore can do the cleanup.
Errors that required pre-recovery cleanup:
- SPR_TFMR_TB_RESIDUE_ERR
- SPR_TFMR_HDEC_PARITY_ERROR
This patch implements pre-recovery steps to clean dirty data from TB/HDEC
register for above mentioned timer facility errors.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Recovery process for SPURR/PURR parity error:
- Set SPURR/PURR Register with valid value or zero
- Reset TFMR SPURR/PURR parity error bit.
To inject TFMR PURR parity error issue:
$ putscom pu.ex 10013281 0004080000000000 -all
To inject TFMR SPURR parity error issue:
$ putscom pu.ex 10013281 0005080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Recovery process for TFMR DEC parity error:
- Set DEC Register with all ones.
- Reset TFMR DEC parity error bit.
To inject TFMR DEC parity error issue:
$ putscom pu.ex 10013281 0006080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Recovery process for HDEC parity error:
- Reset HDEC Register.
- Reset TFMR HDEC parity error bit.
To inject HDEC parity error issue:
$ putscom pu.ex 10013281 0002080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Handle TFMR parity errors reported through HMER[bit 5] and TFMR bit 60
i.e tx_tfmr_corrupt. For recovery, write '1' to TFMR bit 60 to clear it.
Once we clear this error, check for timebase machine state in TFMR [28:31]
and clear TB errors if timebase machine state is in error (9) state. Once
we reset the timebase machine state continue loading TOD into core TB.
To inject TFMR parity error issue:
$ putscom pu.ex 10013281 0001080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Handle TFMR firmware control error reported through HMER[bit 5] and TFMR bit
46 and 27. There are three reason for this error:
1. TFMR command was received but the state machine was in the wrong state
for that command. e.g. TFMR move_chip_tod_to_tb command was received
while in state 0 (RESET state).
2. Two tfmr commands were set which should be mutually exclusive.
e.g. move_chip_tod_to_tb and load_tod_mod
3. Cycle counter used by the PURR overflows due to missing TB59 step.
When we get this error TB is in not-valid state (corrupted - TFMR bit 27)
and has stopped running. To recover, clear tb errors by writing 1 to TFMR
bit 46, 27 and 24. This will reset the time machine state. And then
fall through existing code which takes TB through correct states and
reloads it with valid TOD value.
To inject TFMR firmware control error set TFMR bit 16 and 18 at the same
time.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Handle TB residue error reported through HMER[bit 5] and TFMR bit 45
i.e tb_residu_err. For recovery, reset TB register with all zeros and
then clear tb errors by writing 1 to TFMR bit 45 and 24. Clearing TB error
bits from TFMR would set the time state machine to RESET state and then
fall through existing code path which reloads the TB with TOD value and
get TB running.
To inject TB parity error issue:
$ putscom pu.ex 10013281 0003080000000000 -all
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The current implementation invokes chiptod_reset_tb_errors() function that
force write 1 to all the TB errors irrespective of whether those error
occurred or not. Refactor this code to detect individual TB error and reset
them. This change does not affect the recovery of tb errors that we handle as
of today and has been verified by running regression tests. Instead this
change introduces a better way to handle individual TB errors that we handle
currently and in subsequent patches.
The subsequent patches will recover from more TB and non-TB errors.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This reverts commit 699c433a8c736f44b13b7ba28cc0f9e0ac55840c.
The rest of the patches in this series refactors the code that reset TB
errors for better handling/recovery of individual TB errors. Hence Reverting
old patch that claimed to handle more TFAC errors, but did not.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The memory buffer chips (Centaur) have DTS very similar to the
ones we find on the cores.
Only available on open power machines for the moment.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch adds a couple of properties in the device tree for the core
temperatures nodes. It helps the Linux driver to identify the core and
have a "pretty" sensors output, something like the following :
Core 8: +46.0°C
Core 16: +47.0°C
Core 24: +45.0°C
...
Core 112: +42.0°C
Core 120: +44.0°C
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The hwmon framework in Linux needs a type for the sensors it exposes
in userspace through the sysfs interface. This patch gives Linux a hand
on what is dealing with when parsing the sensor device tree.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The Linux driver should use this property to reflect the status as
a hwmon *_alarm or *_fault attribute.
The temperature sensors trip bits are currently always set, so we
brutaly assign the value to nil until we know why.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch simply adds sensors nodes for the core temperatures. It
uses the core PIR as a resource identifier to fit in the sensor model.
The device tree nodes use the new layout.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch adds a new sensor family for Digital Temperature Sensors
and a new resource class to capture the core temperatures.
Each core has four DTS located in different zones (LSU, ISU, FXU, L3).
The max of the four temperatures is computed and returned for the core
as well as a global trip point value. This is based on the meltbox tool.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch introduces an initial framework to define a sensor_read
operation per platform. It also proposes a few helper routines to
work on the sensor 'handler' which identifies a sensor and attribute
in the OPAL_SENSOR_READ call.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This moves away from using fsp_sync_msg in fsp_fetch_data and instead
using the platform hooks for start_preload_resource() to actually queue
up a load and having the plumbing for checking if a resource is loaded yet.
This gets rid of the "pollers called with locks held" warning we got
heaps of previously. You can now boot some FSP systems without getting
this warning at all.
This also sets the stage for starting load of LIDs much earlier to when
they're needed, improving boot time.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional changes in what happens, just have two calls, one for
queueing preload the other for waiting until it has loaded.
future patches will introduce platform specific queueing.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently we update enclosure exclusive bit before making LED update
SPCN passthrough command and not reverting if this command fails. So
we endup having wrong state if SPCN passthrough command fails.
This patch fixes above described issue.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch adds and registers the following two new OPAL interfaces
for the LED subsystem. With the help of these new OPAL calls, the
host will be able to set or query the state of various LEDs on the
system at any given location code (as passed in the device tree).
As of now, it supports two kinds of LEDs on the same location code
one is "Identify LED" and the other being the "Fault LED".
(1) OPAL_LEDS_GET_INDICATOR fsp_opal_leds_get_ind
(2) OPAL_LEDS_SET_INDICATOR fsp_opal_leds_set_ind
The signtaure of these OPAL interfaces are like the following
(1) fsp_opal_leds_get_ind(loc_code, led_mask, led_value, led_max_type)
The host will pass the location code of the LED (loc_code) and
maximum number of LED types it understands (led_max_type). Sapphire
updates the led_mask with set bits pointing to LED types whose status
is availbale and updates the led_value with actual status. Sapphire
checks the led_max_type to understand whether host is newer or older
compared to itself. In the case where the Sapphire is newer compared
to host (Sapphire's led_max_type > host's led_max_type), it will update
led_mask and led_value according to led_max_type requested by the host.
When the host is newer compared to the Sapphire (host's led_max_type >
Sapphire's led_max_type), Sapphire updates led_max_type to the maximum
number of LED type it understands and updates led_mask, led_value based
on that maximum value.
(2) fsp_opal_leds_set_ind(loc_code, led_mask, led_value, led_max_type)
The host will pass the location code of the LED types, mask,
value and maximum number of LED types it understands. Sapphire will
update LED status for all the LED types mentioned in the mask with
their value mentioned. Sapphire checks the 'led_max_type' to understand
whether the host is newer or older compared to itself. In case where
the Sapphire is newer compared to the host (Sapphire's led_max_type >
host's led_max_type), it updates LED status based on led_max_type
requested from the host. When the host is newer compared to the Sapphire
(host's led_max_type > Sapphire's led_max_type), Sapphire updates
'led_max_type' to the maximum number of LED type it understands and
then it updates LED status based on that updated maximum value of LED
types. Host needs to check the returned updated value of led_max_type
to figure out which part of it's request got served and which ones got
ignored.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If set LED mbox command fails then we have to respond to FSP
with apropriate status code.
Moved MBOX response code to separate function so that we can
just call that with different status code.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The LED local state gets updated before queuing the FSP command.
If the command returns in error state, the state gets rolled back
in the function callback. But in case where the FSP command queue
it self fails, it does not get rolled back. This patch fixes this
scenario by rolling back the state change in case the FSP command
queuing itself fails.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch increase the scope of the lock to cover all data structure
manipulation and SPCN command queuing to change the LED state. It also
locks the corresponding sections in the function callback.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
OPAL queues up asynchronous SPCN command to change the state of any
given LED with a function call back. After receiving the call back, it
sends acknowledgement message to the FSP for the previous command. But
in case of OPAL interface initiated LED state changes, no ack message
needs to be sent to the FSP, instead we might want to enable some flags
for OPAL indicating the success of the previous LED request thus making
the OPAL interface ready for subsequent commands from the host. This
creates a need to distinguish between SPCN based LED commands generated
because of FSP async interface compared to that of OPAL interface. This
patch achieves the classification and other needfull changes in this
regard. These changes will be necessary and used by OPAL interface in
subsequent patches in this series.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
"fsp_led_data" structure contains ckpt_status variable which keeps
current LED state before updating and if LED update fails then we
use this to revert the LED state.
We have introduced new structure (led_set_cmd) to queue up LED update
requests. It make sense to move checkpoint status variable to this
new structure.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch creates a parent LED device node called 'led' under the root
'opal' device node. This also creates child device nodes under 'led'
corresponding to all individual LEDs on the system whether it is an enclosure
type or a descendant type with their location code as name. The location code
information will be used by the host to enlist and access all the individual
LEDs present on the system. The child LED device nodes also have the properties
'led-types' and 'led-loc' representing what kind of LEDs present on the same
loation code and whether it is an enclosure type LED or a descendant type LED.
Sample device tree output:
ibm,opal {
..
..
led {
compatible = "ibm,opal-v3-led";
phandle = <0x1000006b>;
linux,phandle = <0x1000006b>;
U78C9.001.RST0027-P1-C1 {
led-types = "identify", "fault";
led-loc = "descendent";
phandle = <0x1000006f>;
linux,phandle = <0x1000006f>;
};
<snip>
};
};
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: Move create_led_device_nodes to FSP platform.exit]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
During Reset/Reload, we currently enable FSP interrupts on PSIHBCR
even before the DISR handshake is complete. Fix that.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add NX config register values for P7+. Remove "P8" from all register
defines, where the define is common to P7+ and P8. For values new to P8
(specifically 842 prefeching), only enable on P8.
This should correctly setup the NX coprocessors on P7+ systems.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
..which will result lock error in OPAL.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
