summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/arm_scmi
Commit message (Collapse)AuthorAgeFilesLines
* drivers: firmware: scmi: Extend SCMI transport layer by trace eventsLukasz Luba2019-12-302-0/+20
| | | | | | | | | | | | | | | | | The SCMI transport layer communicates via mailboxes and shared memory with firmware running on a microcontroller. It is platform specific how long it takes to pass a SCMI message. The most sensitive requests are coming from CPUFreq subsystem, which might be used by the scheduler. Thus, there is a need to measure these delays and capture anomalies. This change introduces trace events wrapped around transfer code. According to Jim's suggestion a unique transfer_id is to distinguish similar entries which might have the same message id, protocol id and sequence. This is a case then there are some timeouts in transfers. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Skip protocol initialisation for additional devicesSudeep Holla2019-12-241-0/+9
| | | | | | | | | | | | | | The scmi bus now supports adding multiple devices per protocol, and since scmi_protocol_init is called for each scmi device created, we must avoid allocating protocol private data and initialising the protocol itself if it is already initialised. In order to achieve the same, we can simple replace the idr pointer from protocol initialisation function to a dummy function. Suggested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Stash version in protocol init functionsSudeep Holla2019-12-245-0/+10
| | | | | | | | | | In order to avoid querying the individual protocol versions multiple time with more that one device created for each protocol, we can simple store the copy in the protocol specific private data and use them whenever required. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Match scmi device by both name and protocol idSudeep Holla2019-12-241-1/+1
| | | | | | | | | | | | | | The scmi bus now has support to match the driver with devices not only based on their protocol id but also based on their device name if one is available. This was added to cater the need to support multiple devices and drivers for the same protocol. Let us add the name "genpd" to scmi_device_id table in the driver so that in matches only with device with the same name and protocol id SCMI_PROTOCOL_POWER. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add versions and identifier attributes using dev_groupsSudeep Holla2019-12-241-0/+47
| | | | | | | | | | | | | Platform drivers now have the option to have the platform core create and remove any needed sysfs attribute files. Using the same, let's add the scmi firmware and protocol version attributes as well as vendor and sub-vendor identifiers to sysfs. It helps to identify the firmware details from the sysfs entries similar to ARM SCPI implementation. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add names to scmi devices createdSudeep Holla2019-12-241-1/+35
| | | | | | | | | | Now that scmi bus provides option to create named scmi device, let us create the default devices with names. This will help to add names for matching to respective drivers and eventually to add multiple devices and drivers per protocol. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Skip scmi mbox channel setup for addtional devicesSudeep Holla2019-12-241-0/+5
| | | | | | | | | | Now that the scmi bus supports adding multiple devices per protocol, and since scmi_create_protocol_device calls scmi_mbox_chan_setup, we must avoid allocating and initialising the mbox channel if it is already initialised. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add support for multiple device per protocolSudeep Holla2019-12-242-6/+20
| | | | | | | | | | | | | | | Currently only one scmi device is created for each protocol enumerated. However, there is requirement to make use of some procotols by multiple kernel subsystems/frameworks. One such example is SCMI PERFORMANCE protocol which can be used by both cpufreq and devfreq drivers. Similarly, SENSOR protocol may be used by hwmon and iio subsystems, and POWER protocol may be used by genpd and regulator drivers. In order to achieve that, let us extend the scmi bus to match based not only protocol id but also the scmi device name if one is available. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Avoid double free in error flowWen Yang2019-11-261-4/+4
| | | | | | | | | | | | | If device_register() fails, both put_device() and kfree() are called, ending with a double free of the scmi_dev. Calling kfree() is needed only when a failure happens between the allocation of the scmi_dev and its registration, so move it to there and remove it from the error flow. Fixes: 46edb8d1322c ("firmware: arm_scmi: provide the mandatory device release callback") Signed-off-by: Wen Yang <wenyang@linux.alibaba.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Fix doorbell ring logic for !CONFIG_64BITSudeep Holla2019-11-141-1/+1
| | | | | | | | | | | | | | | | | | | The logic to ring the scmi performance fastchannel ignores the value read from the doorbell register in case of !CONFIG_64BIT. This bug also shows up as warning with '-Wunused-but-set-variable' gcc flag: drivers/firmware/arm_scmi/perf.c: In function scmi_perf_fc_ring_db: drivers/firmware/arm_scmi/perf.c:323:7: warning: variable val set but not used [-Wunused-but-set-variable] Fix the same by aligning the logic with CONFIG_64BIT as used in the macro SCMI_PERF_FC_RING_DB(). Fixes: 823839571d76 ("firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol") Reported-by: Hulk Robot <hulkci@huawei.com> Reported-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_resetSudeep Holla2019-09-181-1/+1
| | | | | | | | | Fix the copy paste typo that incorrectly assigns domain_id with the passed 'state' parameter instead of reset_state. Fixes: 95a15d80aa0d ("firmware: arm_scmi: Add RESET protocol in SCMI v2.0") Reported-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add RESET protocol in SCMI v2.0Sudeep Holla2019-08-122-1/+232
| | | | | | | | | | | | | | | | | | | | | SCMIv2.0 adds a new Reset Management Protocol to manage various reset states a given device or domain can enter. Device(s) that can be collectively reset through a common reset signal constitute a reset domain for the firmware. A reset domain can be reset autonomously or explicitly through assertion and de-assertion of the signal. When autonomous reset is chosen, the firmware is responsible for taking the necessary steps to reset the domain and to subsequently bring it out of reset. When explicit reset is chosen, the caller has to specifically assert and then de-assert the reset signal by issuing two separate RESET commands. Add the basic SCMI reset infrastructure that can be used by Linux reset controller driver. Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocolSudeep Holla2019-08-121-4/+99
| | | | | | | | | | | | | | | | | | SCMI v2.0 adds support for "FastChannel" which do not use a message header as they are specialized for a single message. Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET} commands are supported over fastchannels. As they are optional, they need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command. Further {LIMIT,LEVEL}_SET commands can have optional doorbell support. Add support for making use of these fastchannels. Cc: Ionela Voinescu <Ionela.Voinescu@arm.com> Cc: Chris Redpath <Chris.Redpath@arm.com> Cc: Quentin Perret <Quentin.Perret@arm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannelsSudeep Holla2019-08-121-4/+149
| | | | | | | | | | | | | | | | | | | | SCMI v2.0 adds support for "FastChannel", a lightweight unidirectional channel that is dedicated to a single SCMI message type for controlling a specific platform resource. They do not use a message header as they are specialized for a single message. Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET} commands are supported over fastchannels. As they are optional, they need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command. Further {LIMIT,LEVEL}_SET commands can have optional doorbell support. Add support for discovery of these fastchannels. Cc: Ionela Voinescu <Ionela.Voinescu@arm.com> Cc: Chris Redpath <Chris.Redpath@arm.com> Cc: Quentin Perret <Quentin.Perret@arm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessorsSudeep Holla2019-08-126-27/+20
| | | | | | | | | | | Instead of type-casting the {tx,rx}.buf all over the place while accessing them to read/write __le{32,64} from/to the firmware, let's use the existing {get,put}_unaligned_le{32,64} accessors to hide all the type cast ugliness. Suggested-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possibleSudeep Holla2019-08-121-3/+16
| | | | | | | | | | | | | | | | CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum number of pending asynchronous clock rate changes supported by the platform. If it's non-zero, then we should be able to use asynchronous clock rate set for any clocks until the maximum limit is reached. Tracking the current count of pending asynchronous clock set rate requests, we can decide if the incoming/new request for clock set rate can be handled asynchronously or not until the maximum limit is reached. Cc: linux-clk@vger.kernel.org Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Drop config flag in clk_ops->rate_setSudeep Holla2019-08-121-2/+2
| | | | | | | | | | | | | | | CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum number of pending asynchronous clock rate changes supported by the platform. If it's non-zero, then we should be able to use asynchronous clock rate set for any clocks until the maximum limit is reached. In order to add that support, let's drop the config flag passed to clk_ops->rate_set and handle the asynchronous requests dynamically. Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add asynchronous sensor read if it supportsSudeep Holla2019-08-121-8/+22
| | | | | | | | | | | SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor supports asynchronous read. We can read that flag and use asynchronous reads for any sensors with that attribute set. Let's use the new scmi_do_xfer_with_response to support asynchronous sensor reads. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Drop async flag in sensor_ops->reading_getSudeep Holla2019-08-121-2/+2
| | | | | | | | | | | | | | SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor supports asynchronous read. Ideally we should be able to read that flag and use asynchronous reads for any sensors with that attribute set. In order to add that support, let's drop the async flag passed to sensor_ops->reading_get and dynamically switch between sync and async flags based on the attributes as provided by the firmware. Cc: linux-hwmon@vger.kernel.org Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add support for asynchronous commands and delayed responseSudeep Holla2019-08-122-3/+46
| | | | | | | | | | | | | | | | | | | | | | | Messages that are sent to platform, also known as commands and can be: 1. Synchronous commands that block the channel until the requested work has been completed. The platform responds to these commands over the same channel and hence can't be used to send another command until the previous command has completed. 2. Asynchronous commands on the other hand, the platform schedules the requested work to complete later in time and returns almost immediately freeing the channel for new commands. The response indicates the success or failure in the ability to schedule the requested work. When the work has completed, the platform sends an additional delayed response message. Using the same transmit buffer used for sending the asynchronous command even for the delayed response corresponding to it simplifies handling of the delayed response. It's the caller of asynchronous command that is responsible for allocating the completion flag that scmi driver can complete to indicate the arrival of delayed response. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add mechanism to unpack message headersSudeep Holla2019-08-121-0/+18
| | | | | | | | In order to identify the message type when a response arrives, we need a mechanism to unpack the message header similar to packing. Let's add one. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Separate out tx buffer handling and prepare to add rxSudeep Holla2019-08-121-13/+27
| | | | | | | | | | | | | | | | Currently we pre-allocate transmit buffers only and use the first free slot in that pre-allocated buffer for transmitting any new message that are generally originated from OS to the platform firmware. Notifications or the delayed responses on the other hand are originated from the platform firmware and consumes by the OS. It's better to have separate and dedicated pre-allocated buffers to handle the notifications. We can still use the transmit buffers for the delayed responses. In addition, let's prepare existing scmi_xfer_{get,put} for acquiring and releasing a slot to identify the right(tx/rx) buffers. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add receive channel support for notificationsSudeep Holla2019-08-121-4/+26
| | | | | | | | | | | | With scmi_mbox_chan_setup enabled to identify and setup both Tx and Rx, let's consolidate setting up of both the channels under the function scmi_mbox_txrx_setup. Since some platforms may opt not to support notifications or delayed response, they may not need support for Rx. Hence Rx is optional and failure of setting one up is not considered fatal. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Segregate tx channel handling and prepare to add rxSudeep Holla2019-08-121-18/+23
| | | | | | | | | | | | | The transmit(Tx) channels are specified as the first entry and the receive(Rx) channels are the second entry as per the device tree bindings. Since we currently just support Tx, index 0 is hardcoded at all required callsites. In order to prepare for adding Rx support, let's remove those hardcoded index and add boolean parameter to identify Tx/Rx channels when setting them up. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Reorder some functions to avoid forward declarationsSudeep Holla2019-08-121-90/+90
| | | | | | | | | | | Re-shuffling few functions to keep definitions and their usages close. This is also needed to avoid too many unnecessary forward declarations while adding new features(delayed response and notifications). Keeping this separate to avoid mixing up of these trivial change that doesn't affect functionality into the ones that does. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Check if platform has released shmem before usingSudeep Holla2019-08-121-0/+8
| | | | | | | | | | | | | | | | | | | | | Sometimes platfom may take too long to respond to the command and OS might timeout before platform transfer the ownership of the shared memory region to the OS with the response. Since the mailbox channel associated with the channel is freed and new commands are dispatch on the same channel, OS needs to wait until it gets back the ownership. If not, either OS may end up overwriting the platform response for the last command(which is fine as OS timed out that command) or platform might overwrite the payload for the next command with the response for the old. The latter is problematic as platform may end up interpretting the response as the payload. In order to avoid such race, let's wait until the OS gets back the ownership before we prepare the shared memory with the payload for the next command. Reported-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Use the term 'message' instead of 'command'Sudeep Holla2019-08-122-8/+8
| | | | | | | | | | | In preparation to adding support for other two types of messages that SCMI specification mentions, let's replace the term 'command' with the correct term 'message'. As per the specification the messages are of 3 types: commands(synchronous or asynchronous), delayed responses and notifications. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Fix few trivial typos in commentsSudeep Holla2019-08-121-2/+2
| | | | | | | | | While adding new comments found couple of typos that are better fixed. s/informfation/information/ s/statues/status/ Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Remove extra check for invalid length message responsesSudeep Holla2019-08-121-6/+0
| | | | | | | | | | | | | | scmi_xfer_get_init ensures both transmit and receive buffer lengths are within the maximum limits. If receive buffer length is not supplied by the caller, it's set to the maximum limit value. Receive buffer length is never modified after that. So there's no need for the extra check when receive transmit completion for a command essage. Further, if the response header length is greater than the prescribed receive buffer length, the response buffer is truncated to the latter. Reported-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Align few names in sensors protocol with SCMI specificationSudeep Holla2019-08-121-13/+15
| | | | | | | | | | | | Looks like more code developed during the draft versions of the specification slipped through and they don't match the final released version. This seem to have happened only with sensor protocol. Renaming few command and function names here to match exactly with the released version of SCMI specification for ease of maintenance. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* Merge tag 'armsoc-drivers' of ↵Linus Torvalds2019-07-192-2/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC-related driver updates from Olof Johansson: "Various driver updates for platforms and a couple of the small driver subsystems we merge through our tree: - A driver for SCU (system control) on NXP i.MX8QXP - Qualcomm Always-on Subsystem messaging driver (AOSS QMP) - Qualcomm PM support for MSM8998 - Support for a newer version of DRAM PHY driver for Broadcom (DPFE) - Reset controller support for Bitmain BM1880 - TI SCI (System Control Interface) support for CPU control on AM654 processors - More TI sysc refactoring and rework" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (84 commits) reset: remove redundant null check on pointer dev soc: rockchip: work around clang warning dt-bindings: reset: imx7: Fix the spelling of 'indices' soc: imx: Add i.MX8MN SoC driver support soc: aspeed: lpc-ctrl: Fix probe error handling soc: qcom: geni: Add support for ACPI firmware: ti_sci: Fix gcc unused-but-set-variable warning firmware: ti_sci: Use the correct style for SPDX License Identifier soc: imx8: Use existing of_root directly soc: imx8: Fix potential kernel dump in error path firmware/psci: psci_checker: Park kthreads before stopping them memory: move jedec_ddr.h from include/memory to drivers/memory/ memory: move jedec_ddr_data.c from lib/ to drivers/memory/ MAINTAINERS: Remove myself as qcom maintainer soc: aspeed: lpc-ctrl: make parameter optional soc: qcom: apr: Don't use reg for domain id soc: qcom: fix QCOM_AOSS_QMP dependency and build errors memory: tegra: Fix -Wunused-const-variable firmware: tegra: Early resume BPMP soc/tegra: Select pinctrl for Tegra194 ...
| * Merge tag 'scmi-updates-5.3' of ↵Olof Johansson2019-06-172-2/+10
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/drivers ARM SCMI updates/fixes for v5.3 1. Correction to ARM document ID referred in SCMI protocol binding 2. Fix to correct bitfield definitions for SENSOR_DESC attributes which otherwise will calculate sensor values on wrong scale 3. Adds the missing rate_discrete flag setting so that discrete clocks are handled correctly. Without this fix it assumes continuous range which is incorrect 4. Adds support to read and scale the sensor values based on the factor read from the firmware * tag 'scmi-updates-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: hwmon: scmi: Scale values to target desired HWMON units firmware: arm_scmi: fetch and store sensor scale firmware: arm_scmi: update rate_discrete in clock_describe_rates_get firmware: arm_scmi: fix bitfield definitions for SENSOR_DESC attributes dt-bindings: arm: fix the document ID for SCMI protocol documentation Signed-off-by: Olof Johansson <olof@lixom.net>
| | * firmware: arm_scmi: fetch and store sensor scaleFlorian Fainelli2019-06-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for dealing with scales within the SCMI HWMON driver, fetch and store the sensor unit scale into the scmi_sensor_info structure. In order to simplify computations for upper layer, take care of sign extending the scale to a full 8-bit signed value. Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> [sudeep.holla: update bitfield values as per specification] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| | * firmware: arm_scmi: update rate_discrete in clock_describe_rates_getPeng Fan2019-06-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The boolean rate_discrete needs to be assigned to clk->rate_discrete, so that clock driver can distinguish between the continuous range and discrete rates. It uses this in scmi_clk_round_rate could get the rounded value if it's a continuous range. Fixes: 5f6c6430e904 ("firmware: arm_scmi: add initial support for clock protocol") Signed-off-by: Peng Fan <peng.fan@nxp.com> [sudeep.holla: updated commit message] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| | * firmware: arm_scmi: fix bitfield definitions for SENSOR_DESC attributesSudeep Holla2019-06-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per the SCMI specification the bitfields for SENSOR_DESC attributes are as follows: attributes_low [7:0] Number of trip points supported attributes_high [15:11] The power-of-10 multiplier in 2's-complement format that is applied to the sensor units Looks like the code developed during the draft versions of the specification slipped through and are wrong with respect to final released version. Fix them by adjusting the bitfields appropriately. Fixes: 5179c523c1ea ("firmware: arm_scmi: add initial support for sensor protocol") Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* | | firmware: arm_scmi: Use the correct style for SPDX License IdentifierNishad Kamdar2019-06-191-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corrects the SPDX License Identifier style in header file related to Firmware Drivers for ARM SCMI Message Protocol. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* / treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner2019-05-211-0/+1
|/ | | | | | | | | | | | | | Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: arm_scmi: replace of_match_device->data with ↵Aditya Pakki2019-04-121-1/+3
| | | | | | | | | | | | | | | | of_device_get_match_data() of_match_device can return NULL if no matching device is found though it's highly unlikely to happen in scmi_probe as it's called only if a valid match is found. However we can use of_device_get_match_data() instead of of_match_device()->data to handle NULL pointer checks and return -EINVAL in such a scenario. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Aditya Pakki <pakki001@umn.edu> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: fix of_node leak in scmi_mailbox_checkSteven Price2019-04-121-3/+1
| | | | | | | | | | | | | of_parse_phandle_with_args() requires the caller to call of_node_put() on the returned args->np pointer. Otherwise the reference count will remain incremented. However, in this case, since we don't actually use the returned pointer, we can simply pass in NULL. Fixes: aa4f886f3893f ("firmware: arm_scmi: add basic driver infrastructure for SCMI") Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: provide the mandatory device release callbackSudeep Holla2019-01-301-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The device/driver model clearly mandates that bus driver that discover and allocate the device must set the release callback. This callback will be used to free the device after all references have gone away. scmi bus driver is missing the obvious callback which will result in the following warning if the device is unregistered: Device 'scmi_dev.1' does not have a release() function, it is broken and must be fixed. See Documentation/kobject.txt. WARNING at drivers/base/core.c:922 device_release+0x8c/0xa0 Hardware name: ARM LTD Juno Development Platform BIOS EDK II Jan 21 2019 Workqueue: events deferred_probe_work_func pstate: 60000005 (nZCv daif -PAN -UAO) pc : device_release+0x8c/0xa0 lr : device_release+0x8c/0xa0 Call trace: device_release+0x8c/0xa0 kobject_put+0x8c/0x208 device_unregister+0x30/0x78 scmi_device_destroy+0x28/0x50 scmi_probe+0x354/0x5b0 platform_drv_probe+0x58/0xa8 really_probe+0x2c4/0x3e8 driver_probe_device+0x12c/0x148 __device_attach_driver+0xac/0x150 bus_for_each_drv+0x78/0xd8 __device_attach+0xe0/0x168 device_initial_probe+0x24/0x30 bus_probe_device+0xa0/0xa8 deferred_probe_work_func+0x8c/0xe0 process_one_work+0x1f0/0x478 worker_thread+0x22c/0x450 kthread+0x134/0x138 ret_from_fork+0x10/0x1c ---[ end trace 420bdb7f6af50937 ]--- Fix the issue by providing scmi_device_release callback. We have everything required for device release already in scmi_device_destroy, so we just need to move freeing of the device to scmi_device_release. Fixes: 933c504424a2 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Cc: stable@vger.kernel.org # 4.17+ Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* firmware: arm_scmi: add a getter for power of performance statesQuentin Perret2018-09-101-0/+28
| | | | | | | | | | | | | The SCMI protocol can be used to get power estimates from firmware corresponding to each performance state of a device. Although these power costs are already managed by the SCMI firmware driver, they are not exposed to any external subsystem yet. Fix this by adding a new get_power() interface to the exisiting perf_ops defined for the SCMI protocol. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: use strlcpy to ensure NULL-terminated stringsSudeep Holla2018-09-105-5/+5
| | | | | | | | | | | | | Replace all the memcpy() for copying name strings from the firmware with strlcpy() to make sure we are bounded by the source buffer size and we also always have NULL-terminated strings. This is needed to avoid out of bounds accesses if the firmware returns a non-terminated string. Reported-by: Olof Johansson <olof@lixom.net> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: fix divide by zero when sustained_perf_level is zeroSudeep Holla2018-09-061-1/+7
| | | | | | | | | | | | | | | Firmware can provide zero as values for sustained performance level and corresponding sustained frequency in kHz in order to hide the actual frequencies and provide only abstract values. It may endup with divide by zero scenario resulting in kernel panic. Let's set the multiplication factor to one if either one or both of them (sustained_perf_level and sustained_freq) are set to zero. Fixes: a9e3fbfaa0ff ("firmware: arm_scmi: add initial support for performance protocol") Reported-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
* firmware: arm_scmi: remove some unnecessary checksDan Carpenter2018-07-091-5/+0
| | | | | | | | | The "pi->dom_info" buffer is allocated in init() and it can't be NULL here. These tests are sort of weird as well because if "pi->dom_info" was NULL but "domain" was non-zero then it would lead to an Oops. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* Merge tag 'armsoc-drivers' of ↵Linus Torvalds2018-06-118-143/+151
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC driver updates from Olof Johansson: "This contains platform-related driver updates for ARM and ARM64. Highlights: - ARM SCMI (System Control & Management Interface) driver cleanups - Hisilicon support for LPC bus w/ ACPI - Reset driver updates for several platforms: Uniphier, - Rockchip power domain bindings and hardware descriptions for several SoCs. - Tegra memory controller reset improvements" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (59 commits) ARM: tegra: fix compile-testing PCI host driver soc: rockchip: power-domain: add power domain support for px30 dt-bindings: power: add binding for px30 power domains dt-bindings: power: add PX30 SoCs header for power-domain soc: rockchip: power-domain: add power domain support for rk3228 dt-bindings: power: add binding for rk3228 power domains dt-bindings: power: add RK3228 SoCs header for power-domain soc: rockchip: power-domain: add power domain support for rk3128 dt-bindings: power: add binding for rk3128 power domains dt-bindings: power: add RK3128 SoCs header for power-domain soc: rockchip: power-domain: add power domain support for rk3036 dt-bindings: power: add binding for rk3036 power domains dt-bindings: power: add RK3036 SoCs header for power-domain dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions memory: tegra: Remove Tegra114 SATA and AFI reset definitions memory: tegra: Register SMMU after MC driver became ready soc: mediatek: remove unneeded semicolon soc: mediatek: add a fixed wait for SRAM stable soc: mediatek: introduce a CAPS flag for scp_domain_data soc: mediatek: reuse regmap_read_poll_timeout helpers ...
| * Merge tag 'scmi-updates-4.18' of ↵Olof Johansson2018-05-158-143/+151
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers SCMI cleanups for v4.18 This contains all of the trivial review comments that were not addressed as the series was already queued up for v4.17 and were not critical to go as fixes. They generally just improve code readability, fix kernel-docs, remove unused/unnecessary code, follow standard function naming and simplifies certain exit paths. * tag 'scmi-updates-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: simplify exit path by returning on error firmware: arm_scmi: improve exit paths and code readability firmware: arm_scmi: remove unnecessary bitmap_zero firmware: arm_scmi: drop unused `con_priv` structure member firmware: arm_scmi: rename scmi_xfer_{init,get,put} firmware: arm_scmi: rename get_transition_latency and add_opps_to_device firmware: arm_scmi: fix kernel-docs documentation firmware: arm_scmi: improve code readability using bitfield accessor macros Signed-off-by: Olof Johansson <olof@lixom.net>
| | * firmware: arm_scmi: simplify exit path by returning on errorSudeep Holla2018-05-101-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | Yet another nasty indentation left out during code restructuring. It's must simpler to return on error instead of having unnecessary indentation. Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| | * firmware: arm_scmi: improve exit paths and code readabilitySudeep Holla2018-05-101-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing code intends the good path to reduce the code which is so uncommon. It's obvious to have more readable code with a goto used for the error path. This patch adds more appropriate error paths and makes code more readable. It also moves a error logging outside the scope of locking. Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| | * firmware: arm_scmi: remove unnecessary bitmap_zeroSudeep Holla2018-05-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | kcalloc zeros the memory and it's totally unnecessary to zero the bitmap again using bitmap_zero. This patch just drops the unnecessary use of the bitmap_zero in the context. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| | * firmware: arm_scmi: drop unused `con_priv` structure memberSudeep Holla2018-05-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initially con_priv was supposedly used for transport specific data when the SCMI driver had an abstraction to communicate with different mailbox controllers. But after some discussions, the idea was dropped but this variable slipped through the cracks. This patch gets rid of this unused variable. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-21 17:17:25 +0000