aboutsummaryrefslogtreecommitdiff
path: root/hw/fsp/fsp-leds.c
AgeCommit message (Collapse)AuthorFilesLines
2020-03-12Re-license IBM written files as Apache 2.0 OR GPLv2+Stewart Smith1-1/+1
SPDX makes it a simpler diff. I have audited the commit history of each file to ensure that they are exclusively authored by IBM and thus we have the right to relicense. The motivation behind this is twofold: 1) We want to enable experiments with coreboot, which is GPLv2 licensed 2) An upcoming firmware component wants to incorporate code from skiboot and code from the Linux kernel, which is GPLv2 licensed. I have gone through the IBM internal way of gaining approval for this. The following files are not exclusively authored by IBM, so are *not* included in this update (I will be seeking approval from contributors): core/direct-controls.c core/flash.c core/pcie-slot.c external/common/arch_flash_unknown.c external/common/rules.mk external/gard/Makefile external/gard/rules.mk external/opal-prd/Makefile external/pflash/Makefile external/xscom-utils/Makefile hdata/vpd.c hw/dts.c hw/ipmi/ipmi-watchdog.c hw/phb4.c include/cpu.h include/phb4.h include/platform.h libflash/libffs.c libstb/mbedtls/sha512.c libstb/mbedtls/sha512.h platforms/astbmc/barreleye.c platforms/astbmc/garrison.c platforms/astbmc/mihawk.c platforms/astbmc/nicole.c platforms/astbmc/p8dnu.c platforms/astbmc/p8dtu.c platforms/astbmc/p9dsu.c platforms/astbmc/vesnin.c platforms/rhesus/ec/config.h platforms/rhesus/ec/gpio.h platforms/rhesus/gpio.c platforms/rhesus/rhesus.c platforms/astbmc/talos.c platforms/astbmc/romulus.c Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [oliver: fixed up the drift] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-12-16fsp: endian conversionsNicholas Piggin1-51/+56
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-12-16opal-msg: endian fixes for opal-msg.c and opal_queue_msg callersNicholas Piggin1-1/+3
Reported-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-26SPDX-ify all skiboot codeStewart Smith1-17/+3
Use Software Package Data Exchange (SPDX) to indicate license for each file that is unique to skiboot. At the same time, ensure the (C) who and years are correct. See https://spdx.org/ Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [oliver: Added a few missing files] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-05-15fsp/leds: improve string operations bounds checkingNicholas Piggin1-14/+17
The current code has a few possible issues with string handling, and gcc flags a number of string / buffer warnings when enabling more checking. Some of the issues in the file: - Mixing of null-terminated arrays (in most cases), and non-null in the input/output buffer format. memcpy generally should be used when the length is known. - Lack of input data length bounds checking. Malformed input could cause overruns. - String copying from same sized source and destination array sizes, where the source is a NUL terminated string, so the strncpy copies the string without its NUL terminator, which becomes NUL terminated at the zeroed destination array. Compiler does not like this, and it only works if the destination has been zeroed, so not a great pattern. - Attemping to NUL terminate string using strcat, which will overwrite a byte past the end of the array if the string length is at maximum, or worse if the input was malformed. This patch fixes several of these issues and fixes a number of compiler warnings. In general, the buffer and string handling could probably benefit from a more in-depth audit. Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2018-05-24check for NULL input string in is_sai_loc_codeBalbir singh1-2/+5
Caught by scan-build, also constant-ify the input parameter. Signed-off-by: Balbir singh <bsingharora@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2017-03-10fsp-leds: add missing \n in duplicate loc code error msgStewart Smith1-1/+1
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-10-17Fast reboot for P8Benjamin Herrenschmidt1-0/+3
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>
2016-06-24fsp-leds: Add FWTS annotations for some errorsStewart Smith1-0/+34
Only the major ones at this point in time. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-11-10llvm-scan-build: fix dead assignment in fsp-leds.cStewart Smith1-2/+0
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>
2015-10-13Merge branch 'stable': FSP leds fix and skiboot 5.1.7 release notesStewart Smith1-1/+12
2015-10-09Merge branch 'update-2.1.1.1' into stableStewart Smith1-1/+12
2015-10-09hw/fsp/fsp-leds.c: use allocated buffer for FSP_CMD_GET_LED_LIST responseStewart Smith1-2/+11
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>
2015-08-26Fix spelling mistakesStewart Smith1-4/+4
See https://github.com/lucasdemarchi/codespel Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-07-31errorlog: Deprecate elog callback parameterSamuel Mendoza-Jonas1-5/+5
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>
2015-07-17FSP/LEDS: Add support to handle SAI state request from service processorVasant Hegde1-25/+30
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>
2015-07-17FSP/LEDS: Remove led-loc propertyVasant Hegde1-7/+0
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>
2015-06-24queue_led_state_change() - Fix unterminated string warningKamalesh Babulal1-1/+1
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>
2015-06-19Use destination buffer size as bound for strncpyAnanth N Mavinakayanahalli1-1/+1
... 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>
2015-05-12Add pr_fmt to do printf/prlog prefixing automagicallyStewart Smith1-125/+86
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-07FSP/LED: Handle SA indicator update notificationVasant Hegde1-0/+30
FSP sends SA indicator update notification via sys param update. Use that info to update cached indicator state. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-07FSP/LED: Add system attention indicator supportVasant Hegde1-1/+176
SAI is controlled by FSP. This patch adds support to get/set this indicator. Also update OPAL interface so that playload can read/set this indicator. During init, we read this indicator state using MBOX command. OPAL uses MBOX interface to update this SAI. FSP sends update notification whenever there is change in SAI state (except for OPAL initiates updates). We use the notification to update cached SAI state. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-07FSP/LED: Get SAI location code from device treeVasant Hegde1-11/+59
SAI information is available in device tree. This patch parses device tree to get SAI location code information. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-07FSP/LED: Use LED mode informationVasant Hegde1-2/+15
Lets use the LED mode information populated by previous patch. We don't support fault indicator in 'Guiding Light' mode. So don't expose fault indicator to playload in Guiding Light mode. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-07FSP/LED: Validate before creating led nodeVasant Hegde1-3/+4
We get SAI indicator via HDAT. So we have to create led node while parsing HDAT itself. Lets get led node from device tree. Note that LED DT creation fails until next commit...which creates LED device tree node. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-07FSP/LED: Define macro instead of hardcoding led typeVasant Hegde1-5/+8
Define macors for LED related device tree property and its values. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-07FSP/LED: Move led header file to include directoryVasant Hegde1-2/+1
We want to refer leds header file in hdata. Hence move header file to include directory. No functionality changes. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-04-01Remove redundant includes of opal-api.hMichael Ellerman1-1/+0
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>
2015-03-26FSP/LED: Validate before creating LED nodesskiboot-5.0-rc1Vasant Hegde1-0/+7
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>
2015-03-26FSP/LED: Continue processing LED update request in error pathVasant Hegde1-4/+6
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>
2015-03-20FSP/LEDS: Roll back exclusive bit in case FSP command queuing failsVasant Hegde1-18/+22
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>
2015-03-20FSP/LEDS: Add OPAL interfaces for accessing or modifying the LED statesVasant Hegde1-6/+224
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>
2015-03-20FSP/LEDS: Handle failure cases in set LED MBOX commandVasant Hegde1-69/+58
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>
2015-03-20FSP/LEDS: Roll back LED state update in case FSP command queuing failsAnshuman Khandual1-0/+2
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>
2015-03-20FSP/LEDS: Serialize the entire LED state change code and it's callbackAnshuman Khandual1-2/+10
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>
2015-03-20FSP/LEDS: Modify handling of SPCN based LED commandsAnshuman Khandual1-10/+19
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>
2015-03-20FSP/LEDS: Move checkpoint status variable to led_set_cmd structureVasant Hegde1-18/+17
"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>
2015-03-20FSP/LEDS: Add device tree nodesVasant Hegde1-0/+60
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>
2015-02-26sparse: led_support can be staticCédric Le Goater1-1/+1
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> Acked-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-17FSP/LEDS: Implement a set LED SPCN command queueVasant Hegde1-28/+113
Simultaneous FSP async commands and OPAL requests to change various LED states will generate multiple SPCN commands back to back before their callback get processed. With this, some of the SPCN requests might get overridden with the newer ones and hence will be lost. This patch implements a set LED SPCN command queue which will serialize multiple SPCN commands generated either through FSP async or OPAL requests. All new requests are added to the queue when any previous SPCN command completion is still pending. These requests would be de-queued and then processed inside the SPCN command callback function sequentially. This ensures completion of all the generated LED state change requests without any loss. 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: s/spcn_cmd_cmplt/spcn_cmd_complete/] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Track LED list read statusVasant Hegde1-8/+25
We are going to expose LED list to host via device tree. We want to make sure 'query LED list' MBOX command is completed before populating the device tree. fsp_led_init initiates async MBOX command to retrieve list of LEDs. And towards the end of OPAL init path we will come back to LED driver and populate device tree. We can reuse existing led_support variable to check the status before populating device tree. But this doesn't guarantee that LED list read request is completed. Hence modify led_support to have multiple state. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Remove redundant log messageVasant Hegde1-2/+0
There may be other drivers which are registered for same MCLASS. Hence don't log warning message in default case.. Just return false. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Check FSP response statusVasant Hegde1-7/+4
Presently we check only selected status from SPCN passthrough command. So if MBOX command fails for any other reason then we endup considering that as success...which is not correct. This patch considers all response status except success as fail. Also removes unnecessary variable (fail). Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Validate fsp msg allocationVasant Hegde1-0/+2
Validate fsp msg allocation before using. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Remove redundant variable declarationVasant Hegde1-3/+1
Remove redundant variable declaration Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Do not expose driver specific functionsVasant Hegde1-4/+4
Don't expose functions which are not used outside LED driver. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Use consistent prefixVasant Hegde1-40/+47
Presently errors logged into FSP starts with prefix "LED" and rest starts with FSPLED. Lets use consistent prefix (FSPLED). No change in functionality. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Check for FSP presenceVasant Hegde1-0/+3
Check for FSP presence before initializing LED driver. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Remove unnecessary forward declarationVasant Hegde1-2/+1
Remove unnecessary forward declaration. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-13FSP/LEDS: Remove unnecessary header filesVasant Hegde1-8/+1
Remove enthusiastic use of #includes in FSP/LEDS code. ...like hdata.h which is not expected to be used outside hdata dir. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
generated by cgit v1.1 at 2024-10-20 01:17:48 +0000