When building with CONFIG_THERMAL_NETLINK=n, there is a spew of warnings
along the lines of:
In file included from drivers/thermal/thermal_core.c:27:
In file included from drivers/thermal/thermal_core.h:15:
drivers/thermal/thermal_netlink.h:113:71: warning: declaration of 'struct cpu_capability' will not be visible outside of this function [-Wvisibility]
static inline int thermal_genl_cpu_capability_event(int count, struct cpu_capability *caps)
^
1 warning generated.
'struct cpu_capability' is not forward declared anywhere in the header.
As it turns out, this should really be 'struct thermal_genl_cpu_caps',
which silences the warning and makes the parameter types of the stub
match the full function.
Fixes: e4b1eb24ce ("thermal: netlink: Add a new event to notify CPU capabilities change")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add a new netlink event to notify change in CPU capabilities in terms of
performance and efficiency.
Firmware may change CPU capabilities as a result of thermal events in the
system or to account for changes in the TDP (thermal design power) level.
This notification type will allow user space to avoid running workloads
on certain CPUs or proactively adjust power limits to avoid future events.
The netlink message consists of a nested attribute
(THERMAL_GENL_ATTR_CPU_CAPABILITY) with three attributes:
* THERMAL_GENL_ATTR_CPU_CAPABILITY_ID (type u32):
-- logical CPU number
* THERMAL_GENL_ATTR_CPU_CAPABILITY_PERFORMANCE (type u32):
-- Scaled performance from 0-1023
* THERMAL_GENL_ATTR_CPU_CAPABILITY_EFFICIENCY (type u32):
-- Scaled efficiency from 0-1023
Reviewed-by: Len Brown <len.brown@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The slope of the temperature increase or decrease can be high and when
the temperature crosses the trip point, there could be a significant
difference between the trip temperature and the measured temperatures.
That forces the userspace to read the temperature back right after
receiving a trip violation notification.
In order to be efficient, give the temperature which resulted in the
trip violation.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Link: https://lore.kernel.org/r/20211001223323.1836640-1-daniel.lezcano@linaro.org
The initcalls like to play joke. In our case, the thermal-netlink
initcall is called after the thermal-core initcall but this one sends
a notification before the former is initialized. No issue was spotted,
but it could lead to a memory corruption, so instead of relying on the
core_initcall for the thermal-netlink, let's initialize directly from
the thermal-core init routine, so we have full control of the init
ordering.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Link: https://lore.kernel.org/r/20200717164217.18819-1-daniel.lezcano@linaro.org
When the network is not configured, the netlink is disabled on all
the system. The thermal framework assumed the netlink is always
opt-in.
Fix this by adding a Kconfig option for the netlink notification,
defaulting to yes and depending on CONFIG_NET.
As the change implies multiple stubs and in order to not pollute the
internal thermal header, the thermal_nelink.h has been added and
included in the thermal_core.h, so this one regain some kind of
clarity.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Link: https://lore.kernel.org/r/20200707090159.1018-1-daniel.lezcano@linaro.org
Nathan Chancellor