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>
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 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: a9e3fbfaa0 ("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>
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>
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
...
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>
SCMI fix for v4.17
A single patch to ensure that the scmi device is not used for setting up
scmi handle after it's freed(fixes use after free).
* tag 'scmi-fixes-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Use after free in scmi_create_protocol_device()
Signed-off-by: Olof Johansson <olof@lixom.net>
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>
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>
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>
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>
Just after the initial patches were queued, Jonathan Cameron mentioned
that scmi_one_xfer_{get_put} were not very clear and suggested to use
scmi_xfer_{alloc,free}. While I agree to some extent, the reason not to
have alloc/free as these are preallocated buffers and these functions
just returns a reference to free slot in that preallocated array.
However it was agreed to drop "_one" as it's implicit that we are always
dealing with one slot anyways.
This patch updates the name accordingly dropping "_one" in both {get,put}
functions. Also scmi_one_xfer_init is renamed as scmi_xfer_get_init to
reflect the fact that it gets the free slots and then initialise it.
Reported-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Most of the scmi code follows the suggestion from Greg KH on a totally
different thread[0] to have the subsystem name first, followed by the
noun and finally the verb with couple of these exceptions.
This patch fixes them so that all the functions names are aligned to
that practice.
[0] https://www.spinics.net/lists/arm-kernel/msg583673.html
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
There are few missing descriptions for function parameters and structure
members along with certain instances where excessive function parameters
or structure members are described.
This patch fixes all of those warnings.
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
By using FIELD_{FIT,GET,PREP} and GENMASK macro accessors we can avoid
some clumpsy custom shifting and masking macros and also improve the
code better readability.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
We need to return here instead of setting up the freed sdev device as a
transport.
Fixes: 907b6d1491 ("firmware: arm_scmi: add per-protocol channels support using idr objects")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The null check on clk->name is redundant since name is a char array
and can never be null, so the check is always true. Remove it.
Detected by CoverityScan, CID#1466117 ("Array compared against 0")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
gcc-5.3 and earlier warns that rate_discrete maybe-uninitialized
../drivers/firmware/arm_scmi/clock.c:185:5: warning: 'rate_discrete'
may be used uninitialized in this function [-Wmaybe-uninitialized]
if (rate_discrete)
^
../drivers/firmware/arm_scmi/clock.c:128:7: note:
'rate_discrete' was declared here
bool rate_discrete;
^
This patch fixing the warning by initialising rate_discrete and also using
goto label for the error path.
Fixes: 5f6c6430e9 ("firmware: arm_scmi: add initial support for clock protocol")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
[sudeep.holla: added one line description to the commit message]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
This patch hooks up the support for device power domain provided by
SCMI using the Linux generic power domain infrastructure.
Cc: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In order to maintain the channel information per protocol, we need
some sort of list or hashtable to hold all this information. IDR
provides sparse array mapping of small integer ID numbers onto arbitrary
pointers. In this case the arbitrary pointers can be pointers to the
channel information.
This patch adds support for per-protocol channels using those idr
objects.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In order to support per-protocol channels if available, we need to
factor out all the mailbox channel information(Tx/Rx payload and
channel handle) out of the main SCMI instance information structure.
This patch refactors the existing channel information into a separate
chan_info structure.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In order to implement fast CPU DVFS switching, we need to perform all
DVFS operations atomically. Since SCMI transfer already provide option
to choose between pooling vs interrupt driven(default), we can opt for
polling based transfers for set,get performance domain operations.
This patch adds option to choose between polling vs interrupt driven
SCMI transfers for set,get performance level operations.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
It would be useful to have options to perform some SCMI transfers
atomically by polling for the completion flag instead of interrupt
driven. The SCMI specification has option to disable the interrupt and
poll for the completion flag in the shared memory.
This patch adds support for polling based SCMI transfers using that
option. This might be used for uninterrupted/atomic DVFS operations
from the scheduler context.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Now that we have basic support for all the protocols in the
specification, let's probe them individually and initialise them.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The sensor protocol provides functions to manage platform sensors, and
provides the commands to describe the protocol version and the various
attribute flags. It also provides commands to discover various sensors
implemented and managed by the platform, read any sensor synchronously
or asynchronously as allowed by the platform, program sensor attributes
and/or configurations, if applicable.
This patch adds support for most of the above features.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>