Age | Commit message (Collapse) | Author | Files | Lines |
|
Add a function dt_find_by_name_before_addr() that returns the child node if
it matches till first occurrence at "@" of a given name, otherwise NULL.
This is helpful for cases with node name like: "name@addr". In
scenarios where nodes are added with "name@addr" format and if the
value of "addr" is not known, that node can't be matched with node
name or addr. Hence matching with substring as node name will return
the expected result. Patch adds dt_find_by_name_before_addr() function
and testcase for the same in core/test/run-device.c
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
[arbab: Refactor the loop to fix possible memory leak]
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Last BMC firmware is available with a complete PLDM support on Rainier
system.
This patch allows initially to:
- Initialize the MCTP core.
- Enable the mctp binding over LPC bus interface and new wrappers to send
and receive PLDM messages over the mctp library.
- Retrieve all needed PLDM data.
- "Virtualize" the content of a BMC flash based on lid files.
Then, others mandatory support (watchdog, opal rtc, opal ipmi) are enabled.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
backend apis to support partially:
OPAL_IPMI_SEND: send an IPMI message to the service processor
OPAL_IPMI_RECV: read an ipmi message of type ``ipmi_msg`` from ipmi message
queue ``msgq`` into host OS structure ``opal_ipmi_msg``
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
OPAL_RTC_READ/WRITE are used to retrieve and write the time. PLDM stack
provides GetBiosDateTimeReq and SetBiosDateTimeReq commands to exercise.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
PLDM Event Messages are PLDM monitoring and control messages that are used
by a PLDM terminus to synchronously or asynchronously report PLDM events
to a central party called the PLDM Event Receiver.
This patch allows to send a:
- generic sensor events (events related to PLDM numeric and state sensors).
- boot progress sensor event.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetFRURecordTable command is used to get the FRU Record Table data.
This command is defined to allow the FRU Record Table data to be
transferred using a sequence of one or more command/response messages.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetFRURecordTableMetadata command is used to get the FRU Record
Table metadata information that includes the FRU Record major version,
the FRU Record minor version, the size of the largest FRU Record data,
total length of the FRU Record Table, total number of FRU Record Data
structures, and the integrity checksum on the FRU Record Table data.
Add an "IBM, skiboot" FRU Record product requested by the BMC.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetPDR command is used to retrieve individual PDRs from a PDR
repository. The record is identified by the PDR recordHandle value
that is passed in the request.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The boot progress record will be used to report Opal's progress to the BMC
during the boot.
The Terminus Locator PDR forms the association between a TID and PLDM
Terminus Handle for a terminus.
This patch allows to add terminus locator record in the repository.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Encode the platform PDR repository change event message request that tells
the BMC that a specific PDR entry has changed.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Add a wrapper for the libpldm api: pldm_pdr_find_record()
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The SetStateEffecterStates command is used to set the state of one or more
effecters within a PLDM State Effecter.
The field comp_effecter_count indicates the number of individual sets of
state effecter information that are accessed by this command.
The Event Receiver acknowledges receiving the PLDM Event Message in the
response to this command.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetStateSensorReadings command can return readings for multiple state
sensors (a PLDM State Sensor that returns more than one set of state
information is called a composite state sensor).
The Event Receiver acknowledges receiving the PLDM Event Message in the
response to this command.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
PLDM Event Messages are sent as PLDM request messages to the Event Receiver
using the PlatformEventMessage command.
The Event Receiver acknowledges receiving the PLDM Event Message in the
response to this command.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The SetEventReceiver command is used to set the address of the Event
Receiver into a terminus that generates event messages. It is also used to
globally enable or disable whether event messages are generated from the
terminus.
For the time being, only the following global event message is supported:
PLDM_EVENT_MESSAGE_GLOBAL_ENABLE_ASYNC_KEEP_ALIVE.
The Event Receiver acknowledges receiving the PLDM Event Message in the
response to this command.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Encode a PLDM platform event message to send the heartbeat to the BMC.
Watchdog is "armed" when a
PLDM_EVENT_MESSAGE_GLOBAL_ENABLE_ASYNC_KEEP_ALIVE is received.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
In the same way that ipmi-hiomap implements the PNOR access control
protocol, this patch allows to "virtualize" the content of a BMC flash
based on lid files.
Previously, flash PNOR partitions were viewed this way:
partitionXX=NAME, start address, end address, flags
The content of each partition is now stored in a lid file. In order to
continue to use the libflash library, we manually fill in the contents of
a fake flash header when accessing offset 0. This reproduces the behavior
via ipmi-hiomap of reading the flash header on the BMC.
For the reading and writing of BMC lids files, we convert the virtual
addresses of these 'fake' partitions by identifying: lid id.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This patch parses the "hb_lid_ids" string from bios tables and complete
the global list of lid files. Each entry in the list contains the name,
the id, the length of the lid file and the virtual address start access.
This virtual address is used for for PNOR Resource Provider operations.
16 MB of VMM address are reserved space per section.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Retrieve the file handle and file length based on attribute name.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Send/receive a PLDM WriteFile request message.
Due to maximum transfer size for PLDM protocol, we have to send several
write requests, if necessary.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Send/receive a PLDM ReadFile request message.
Due to maximum transfer size for PLDM protocol, we have to send several
read requests, if necessary.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The ibm/libpldm library implements IBM OEM commands support for PLDM and
specially encode and decode APIs for in-band readFile and writeFile
commands.
The GetFileTable request message is used to retrieve the file table which
contains the list of lid files available and their attributes.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Use the GetFruRecordByOptionReq command to retrieve the bmc information
with: "FRU Field Type": Version
"FRU Record Set Identifier": 1,
"FRU Record Type": "General(1)"
and update the "bmc-firmware-version" device-tree field.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Specification, defines a FRU data format that provides platform asset
information including part number, serial number and manufacturer.
Use the GetFruRecordByOptionReq command to get specific FRU (Field
Replaceable Unit) record according the Record Set Identifier, the Record
Type and the field Type.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This specification defines the data structures and messages for
communicating BIOS settings, BIOS attributes, boot configurations, and
boot order settings.
Use the GetBIOSTable command to get STRING, Attribute and Attribute values
tables from the BIOS.
The contents of these tables are needed to read/write the desired lid
files located on the BMC.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This specification defines the data structures and messages for
communicating BIOS settings, BIOS attributes, boot configurations, and
boot order settings.
Use the GetBIOSTable command to get STRING, Attribute and Attribute values
tables from the BIOS.
The content of these tables is useful to read/write the lid files located
on the BMC.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Set the state information of the PLDM effecter identified by:
the entity type (PLDM_ENTITY_SYSTEM_CHASSIS) and the state set
PLDM_STATE_SET_SYSTEM_POWER_STATE with the effecter state:
PLDM_STATE_SET_SYS_POWER_STATE_OFF_SOFT_GRACEFUL to request a platform off.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Set the state information of the PLDM effecter identified by:
the entity type (PLDM_ENTITY_SYS_FIRMWARE) and the state set
PLDM_STATE_SET_SW_TERMINATION_STATUS with the effecter state:
PLDM_SW_TERM_GRACEFUL_RESTART_REQUESTED to request a platform restart.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
PLDM effecters provide a general mechanism for controlling or configuring a
state or numeric setting of an entity.
The entity state and numeric setting values are written into an effecter.
PLDM commands are specified for writing the state or numeric setting to an
effecter. Effecters are identified by and accessed using an EffecterID that
is unique for each effecter within a given terminus.
PLDM State Effecters provide a regular command structure for setting state
information in order to change the state of an entity.
The SetStateEffecterStates command is used to set the state of one or more
effecters within a PLDM State Effecter.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This specification defines the functions and data structures used for
discovering, describing, initializing, and accessing sensors and effecters
within the management controllers and management devices of a platform
management subsystem using PLDM messaging.
A PDR (Platform Descriptor Record) is a set of data that is used to
provide semantic information about sensors, effecters, monitored or
controller entities, and functions and services within a PLDM
implementation.
PDRs are mostly used to support PLDM monitoring and control and platform
events.
The PDRs for a PLDM subsystem are collected into a single, central PDR
Repository. A central repository provides a single place from which PDR
information can be retrieved.
The GetPDR command is used to retrieve individual PDRs from a PDR
Repository. The record is identified by the PDR recordHandle value that is
passed in the request.
The patch dump all the PDRs within a PDR Repository.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Implement a way for sending PLDM requests for specific PLDM commands.
Send a PLDM request message. Wait for corresponding response message,
which once received, is returned to the caller.
If there's data available, return success only if data is a PLDM response
message that matches instance, pldm_type and command code.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetPLDMVersion command can be used to retrieve the PLDM base
specification versions that the PLDM terminus supports, as well as the
PLDM Type specification versions supported for each PLDM Type.
The reported version for Type 0 (PLDMbase) shall be encoded as 0xF1F1F000.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetPLDMCommands command can be used to discover the PLDM command
capabilities supported by a PLDM terminus for a specific PLDM Type and
version as a responder.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetPLDMTypes command can be used to discover the PLDM type capabilities
supported by a PLDM terminus and to get a list of the PLDM types that are
supported.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
A PLDM Terminus is defined as the point of communication termination for
PLDM messages and the PLDM functions associated with those messages.
Given a PLDM terminus, a mechanism is required that can uniquely identify
each terminus so that the semantic information can be bound to that
identification.
The Terminus ID (TID) is a value that identifies a PLDM terminus.
TIDs are used in PLDM messages when it is necessary to identify the PLDM
terminus that is the source of the PLDM Message.
The GetTID command is used to retrieve the present Terminus ID (TID)
setting for a PLDM Terminus.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
PLDM defines data representations and commands that abstract the platform
management hardware.
A PLDM Terminus (or responder) is defined as the point of communication
termination for PLDM messages and the PLDM functions associated with those
messages.
A PLDM terminus is not required to process more than one request at a time
(that is, it can be "single threaded" and does not have to accept and act
on new requests until it has finished responding to any previous request).
Some PLDM control and discovery requests (PLDM_TYPE = PLDM_BASE) are
mandatory a PLDM terminus has to answer.
These following mandatory PLDM command codes for PLDM messaging control
and discovery will be defined in next patches.
GetTID 0x02
GetPLDMVersion 0x03
GetPLDMTypes 0x04
GetPLDMCommands 0x05
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Enable the mctp binding over LPC bus interface and new wrappers to send
and receive PLDM messages over the mctp library.
PLDM is supported as a message type over MCTP. PLDM over MCTP binding
defines the format of PLDM over MCTP messages.
An MCTP Endpoint is the terminus for MCTP communication. A physical device
that supports MCTP may provide one or more MCTP Endpoints. Endpoints are
addressed using a logical address called the Endpoint ID, or EID. EIDs in
MCTP are analogous to IP Addresses in Internet Protocol networking.
The BMC EID default is 8.
First byte of the PLDM over MCTP Message Fields identifies the MCTP
message as carrying a PLDM message:
Message Type (7 bits) PLDM = 0x01 (000_0001b).
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
To retrieve specific log traces from the external library: libmctp, we
need to export the logging api.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
These callbacks were used by the p7ioc code that was removed a long time
ago. Add them to the list of removed calls and delete the dead code.
Linux has removed the code that called these functions in v6.5-rc1.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Compiling hmi.c with GCC 13.1.1 results in following error
core/hmi.c:860:25: error: ‘pau’ may be used uninitialized [-Werror=maybe-uninitialized]
860 | pau_opencapi_dump_scoms(pau);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix this by initializing variable 'pau' with NULL when defined in
npu_fir_errors(). Variable 'pau' is only assigned/referenced in switch-case
blocks when phb_type == phb_type_pau_opencapi. Hence this patch shouldn't
introduce any behavioral changes.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
There is a QEMU model for ChipTOD (not yet upstream) that provides
enough to get through skiboot's sync sequence.
So run the chiptod init when running under QEMU, if it is being
provided in the device tree. If not, don't crash because the QEMU
patch has not been merged yet...
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
There doesn't seem to be any reason to call opal_mpipl_init so late,
after sleep, traps, interrupts, machine checks, watchdog, etc., are
all disabled. Move it earlier.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This code hasn't been enabled, remove it.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Bring ipmi to a consistent state before booting a kernel by flushing
all outstanding messages. The OS may not start kicking the IPMI state
machine for some time.
For example, without this change, when booting in QEMU, the IPMI command
issued by ipmi_wdt_final_reset() to disable the watchdog is not sent to
the BMC before the OS boots, effectively leaving the watchdog enabled
until the OS begins to drive OPAL pollers.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Stewart Smith <stewart@flamingspork.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Current gcc with -Os happens to generate code that re-loads the variable
in the loop, but that could change without notice, and with -O2 it does
infinite loop if sync_msg is !NULL, because it is not declared volatile
and there is no compiler barrier in the loop.
Add the usual cpu_relax() there to provide the compiler barrier.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Stewart Smith <stewart@flamingspork.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Print a message if free or realloc are called on memory outside the
skiboot heap. Freeing is skipped to give the best chance of avoiding
a crash.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This allows memory to be allocated with local_alloc() to be freed.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Timer facility HMIs are reported with TB error reason set in the TFMR
register. With help from reason set in TFMR register, OPAL hmi handler
carry out appropriate recovery procedure to successfully recover from Timer
facility HMIs.
However, On p10, in a very rare situation when core is waking up from stop2
or higher stop state, timer facility goes into error state due to Missing
step, causing an HMI with no error reason set in TFMR register other than
TFMR[41]=0 (tb_valid) and TFMR[28:31]=9 (tbst_encoded). Ideally, "Missing
step" error should be reported in TFMR[44]=1. It looks like in this rare
case, while generating HMI, HW fails to sync up the TFMR register with the
core which is waking up from stop2. Hence, in absence of proper error
reason, OPAL fails to recover from this unusual HMI, resulting in system
panic/crash.
In order to recover from this HMI it needs to reset the core level error
"Missing step". Handle this as special case by treating this as TFMR
corrupt error (TFMR[60]) which will then force reset core level errors
including Missing step.
Reported-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
When looking for which interrupts are serviced by opal, we scan all
sources and query every single interrupt to know if it's for linux or
opal. An optimization was made so that if the source doesn't have an
'interrupt' op (=the handler) or an 'attributes' op (to do the
query), then we can skip the source. That's all good.
However, when xive was introduced, the 'irq_source' defining those ops
was wrapped in a 'xive_src' source which adds a level of indirection
for those 'attributes' and 'interrupt' ops. So the previous
optimization no longer works: the 'attributes' and 'interrupt' ops are
defined from the wrapper, but if we could look past the indirection,
we would realize they are not.
That is getting problematic for the rather large generic IPIs
source. We have 8 million such interrupts defined per chip on P10 and
because the above optimization is no longer kicking in, we are now
querying every single one of them to know if it is for opal. Real
hardware swallows it without much difficulty, but simulators
don't. Running qemu on my laptop, the full scan takes ~12 seconds per
chip!
This patch adds a callback for an interrupt source to report whether
it has opal interrupts. If the source doesn't define it, then we
fallback to looking at the 'interrupt' and 'attributes' ops, like
before, as it is still useful on P8. We can then define that new
callback on the xive sources, allowing to look past the indirection
level and skip scanning the source when appropriate.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|