| Age | Commit message (Collapse) | Author |
|---|
|
Commit 473be51142ad ("thermal: int340x: processor_thermal: Add RFIM
driver")' added rfi_restriction_data_rate_base string, mmio details and
documentation, but missed adding attribute to sysfs.
Add missing sysfs attribute.
Fixes: 473be51142ad ("thermal: int340x: processor_thermal: Add RFIM driver")
Cc: 5.11+ <stable@vger.kernel.org> # v5.11+
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more thermal control updates from Rafael Wysocki:
"These are updates of assorted thermal drivers, mostly for ARM
platforms, generally isolated and fairly straightforward, and the
recent Intel HFI driver fix for systems without HFI support.
Specifics:
- Avoid clearing the HFI status bit on systems without HFI support
which triggers unchecked MSR access errors (Srinivas Pandruvada)
- Add sm8450 and sm8550 QCom compatible string to DT bindings (Luca
Weiss, Neil Armstrong)
- Use devm_platform_get_and_ioremap_resource on the ST platform to
group two calls into a single one (Minghao Chi)
- Use GENMASK instead of bitmaps and validate the temperature after
reading it in the imx8mm_thermal driver (Marcus Folkesson)
- Convert generic-adc-thermal to DT schema (Rob Herring)
- Fix debug print message with inverted logic in the k3_j72xx_bandgap
driver (Keerthy)
- Fix memory leak on thermal_of_zone_register() failure (Ido
Schimmel)
- Add support for IPQ8074 in the tsens thermal driver along with the
DT bindings (Robert Marko)
- Fix and rework the debugfs code in the tsens driver (Christian
Marangi)
- Add calibration and DT documentation for the imx8mm driver (Marek
Vasut)
- Add DT bindings and compatible for the Mediatek SoCs mt7981 and
mt7983 (Daniel Golle)
- Don't show an error message if it happens at probe time while it
will be deferred on the QCom SPMI ADC driver (Johan Hovold)
- Add HWMon support for the imx8mm board (Alexander Stein)
- Remove pointless include from the power allocator governor
(Christophe JAILLET)
- Add interrupt DT bindings for QCom SoCs SC8280XP, SM6350 and SM8450
(Krzysztof Kozlowski)
- Fix inaccurate warning message for the QCom tsens gen2 (Luca Weiss)
- Demote error log of thermal zone register to debug in the tsens
QCom driver (Manivannan Sadhasivam)
- Consolidate the the efuse values and the errata handling in the TI
Bandgap driver (Bryan Brattlof)
- Document Renesas RZ/Five as compatible with RZ/G2UL in the DT
bindings (Lad Prabhakar)
- Fix the irq handler return value in the LMh driver (Bjorn
Andersson)
- Delete empty platform remove callback from imx_sc_thermal (Uwe
Kleine-König)"
* tag 'thermal-6.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (35 commits)
thermal/drivers/imx_sc_thermal: Drop empty platform remove function
thermal/drivers/qcom/lmh: Fix irq handler return value
dt-bindings: thermal: qcom-tsens: Add compatible for sm8550
thermal/drivers/st: Use devm_platform_get_and_ioremap_resource()
dt-bindings: thermal: rzg2l-thermal: Document RZ/Five SoC
dt-bindings: thermal: k3-j72xx: conditionally require efuse reg range
dt-bindings: thermal: k3-j72xx: elaborate on binding description
thermal/drivers/k3_j72xx_bandgap: Map fuse_base only for erratum workaround
thermal/drivers/k3_j72xx_bandgap: Remove fuse_base from structure
thermal/drivers/k3_j72xx_bandgap: Use bool for i2128 erratum flag
thermal/drivers/k3_j72xx_bandgap: Simplify k3_thermal_get_temp() function
thermal/drivers/qcom: Demote error log of thermal zone register to debug
thermal/drivers/qcom/temp-alarm: Fix inaccurate warning for gen2
dt-bindings: thermal: qcom-tsens: narrow interrupts for SC8280XP, SM6350 and SM8450
thermal/core/power allocator: Remove a useless include
thermal/drivers/imx8mm: Add hwmon support
thermal: qcom-spmi-adc-tm5: suppress probe-deferral error message
dt-bindings: thermal: mediatek: add compatible string for MT7986 and MT7981 SoC
thermal: ti-soc-thermal: Drop comma after SoC match table sentinel
thermal/drivers/imx: Add support for loading calibration data from OCOTP
...
|
|
When CPU doesn't support HFI (Hardware Feedback Interface), don't include
BIT 26 in the mask to prevent clearing. otherwise this results in:
unchecked MSR access error: WRMSR to 0x1b1
(tried to write 0x0000000004000aa8)
at rIP: 0xffffffff8b8559fe (throttle_active_work+0xbe/0x1b0)
Fixes: 6fe1e64b6026 ("thermal: intel: Prevent accidental clearing of HFI status")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control updates from Rafael Wysocki:
"These include thermal core fixes to protect thermal device operations
against thermal device removal, other thermal core fixes and updates
of Intel thermal control drivers.
Specifics:
- Fix race conditions related to thermal device operations that are
not protected against thermal device removal (Guenter Roeck)
- Fix error code in __thermal_cooling_device_register() (Dan
Carpenter)
- Validate new cooling device state (coming from user space) in
cur_state_store() and reuse the max_state value from cooling device
structure in the sysfs interface (Viresh Kumar)
- Fix some possible name leaks in error paths in the thermal control
core code (Yang Yingliang)
- Detect TCC lock bit set in the intel_tcc_cooling driver and make it
refuse to update the TCC offset in that case (Zhang Rui)
- Add TCC cooling support for RaptorLake-S (Zhang Rui)
- Prevent accidental clearing of HFI status by one of the other
drivers using the same status register (Srinivas Pandruvada)
- Protect clearing of thermal status bits in Intel thermal control
drivers (Srinivas Pandruvada)
- Allow the HFI thermal control driver to ACK an HFI event for the
previously observed timestamp (Srinivas Pandruvada)
- Remove a pointless die_id check from the HFI thermal driver and
adjust the definition a data structure used by it (Ricardo Neri)"
* tag 'thermal-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: intel: hfi: Remove a pointless die_id check
thermal: core: fix some possible name leaks in error paths
thermal: intel: hfi: ACK HFI for the same timestamp
thermal: intel: Protect clearing of thermal status bits
thermal: intel: Prevent accidental clearing of HFI status
thermal/core: Protect thermal device operations against thermal device removal
thermal/core: Remove thermal_zone_set_trips()
thermal/core: Protect sysfs accesses to thermal operations with thermal zone mutex
thermal/core: Protect hwmon accesses to thermal operations with thermal zone mutex
thermal/core: Introduce locked version of thermal_zone_device_update
thermal/core: Move parameter validation from __thermal_zone_get_temp to thermal_zone_get_temp
thermal/core: Ensure that thermal device is registered in thermal_zone_get_temp
thermal/core: Delete device under thermal device zone lock
thermal/core: Destroy thermal zone device mutex in release function
thermal: intel: intel_tcc_cooling: Add TCC cooling support for RaptorLake-S
thermal: intel: intel_tcc_cooling: Detect TCC lock bit
thermal: intel: hfi: Improve the type of hfi_features::nr_table_pages
thermal/core: fix error code in __thermal_cooling_device_register()
thermal: sysfs: Reuse cdev->max_state
thermal: Validate new state in cur_state_store()
|
|
die_id is an u16 quantity. On single-die systems the default value of
die_id is 0. No need to check for negative values.
Plus, removing this check makes Coverity happy.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Some processors issue more than one HFI interrupt with the same
timestamp. Each interrupt must be acknowledged to let the hardware issue
new HFI interrupts. But this can't be done without some additional flow
modification in the existing interrupt handling.
For background, the HFI interrupt is a package level thermal interrupt
delivered via a LVT. This LVT is common for both the CPU and package
level interrupts. Hence, all CPUs receive the HFI interrupts. But only
one CPU should process interrupt and others simply exit by issuing EOI
to LAPIC.
The current HFI interrupt processing flow:
1. Receive Thermal interrupt
2. Check if there is an active HFI status in MSR_IA32_THERM_STATUS
3. Try and get spinlock, one CPU will enter spinlock and others
will simply return from here to issue EOI.
(Let's assume CPU 4 is processing interrupt)
4. Check the stored time-stamp from the HFI memory time-stamp
5. if same
6. ignore interrupt, unlock and return
7. Copy the HFI message to local buffer
8. unlock spinlock
9. ACK HFI interrupt
10. Queue the message for processing in a work-queue
It is tempting to simply acknowledge all the interrupts even if they
have the same timestamp. This may cause some interrupts to not be
processed.
Let's say CPU5 is slightly late and reaches step 4 while CPU4 is
between steps 8 and 9.
Currently we simply ignore interrupts with the same timestamp. No
issue here for CPU5. When CPU4 acknowledges the interrupt, the next
HFI interrupt can be delivered.
If we acknowledge interrupts with the same timestamp (at step 6), there
is a race condition. Under the same scenario, CPU 5 will acknowledge
the HFI interrupt. This lets hardware generate another HFI interrupt,
before CPU 4 start executing step 9. Once CPU 4 complete step 9, it
will acknowledge the newly arrived HFI interrupt, without actually
processing it.
Acknowledge the interrupt when holding the spinlock. This avoids
contention of the interrupt acknowledgment.
Updated flow:
1. Receive HFI Thermal interrupt
2. Check if there is an active HFI status in MSR_IA32_THERM_STATUS
3. Try and get spin-lock
Let's assume CPU 4 is processing interrupt
4.1 Read MSR_IA32_PACKAGE_THERM_STATUS and check HFI status bit
4.2 If hfi status is 0
4.3 unlock spinlock
4.4 return
4.5 Check the stored time-stamp from the HFI memory time-stamp
5. if same
6.1 ACK HFI Interrupt,
6.2 unlock spinlock
6.3 return
7. Copy the HFI message to local buffer
8. ACK HFI interrupt
9. unlock spinlock
10. Queue the message for processing in a work-queue
To avoid taking the lock unnecessarily, intel_hfi_process_event() checks
the status of the HFI interrupt before taking the lock. If CPU5 is late,
when it starts processing the interrupt there are two scenarios:
a) CPU4 acknowledged the HFI interrupt before CPU5 read
MSR_IA32_THERM_STATUS. CPU5 exits.
b) CPU5 reads MSR_IA32_THERM_STATUS before CPU4 has acknowledged the
interrupt. CPU5 will take the lock if CPU4 has released it. It then
re-reads MSR_IA32_THERM_STATUS. If there is not a new interrupt,
the HFI status bit is clear and CPU5 exits. If a new HFI interrupt
was generated it will find that the status bit is set and it will
continue to process the interrupt. In this case even if timestamp
is not changed, the ACK can be issued as this is a new interrupt.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Tested-by: Arshad, Adeel<adeel.arshad@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The clearing of the package thermal status is done by Read-Modify-Write
operation. This may result in clearing of some new status bits which are
being or about to be processed.
For example, while clearing of HFI status, after read of thermal status
register, a new thermal status bit is set by the hardware. But during
write back, the newly generated status bit will be set to 0 or cleared.
So, it is not safe to do read-modify-write.
Since thermal status Read-Write bits can be set to only 0 not 1, it is
safe to set all other bits to 1 which are not getting cleared.
Create a common interface for clearing package thermal status bits. Use
this interface to replace existing code to clear thermal package status
bits.
It is safe to call from different CPUs without protection as there is no
read-modify-write. Also wrmsrl results in just single instruction. For
example while CPU 0 and CPU 3 are clearing bit 1 and 3 respectively. If
CPU 3 wins the race, it will write 0x4000aa2, then CPU 1 will write
0x4000aa8. The bits which are not part of clear are set to 1. The default
mask for bits, which can be written here is 0x4000aaa.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When there is a package thermal interrupt with PROCHOT log, it will be
processed and cleared. It is possible that there is an active HFI event
status, which is about to get processed or getting processed. While
clearing PROCHOT log bit, it will also clear HFI status bit. This means
that hardware is free to update HFI memory.
When clearing a package thermal interrupt, some processors will generate
a "general protection fault" when any of the read only bit is set to 1.
The driver maintains a mask of all read-write bits which can be set.
This mask doesn't include HFI status bit. This bit will also be cleared,
as it will be assumed read-only bit. So, add HFI status bit 26 to the
mask.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
For bus-based driver, device removal is implemented as:
1 device_remove()->
2 bus->remove()->
3 driver->remove()
Driver core needs no inform from callee(bus driver) about the
result of remove callback. In that case, commit fc7a6209d571
("bus: Make remove callback return void") forces bus_type::remove
be void-returned.
Now we have the situation that both 1 & 2 of calling chain are
void-returned, so it does not make much sense for 3(driver->remove)
to return non-void to its caller.
So the basic idea behind this change is making remove() callback of
any bus-based driver to be void-returned.
This change, for itself, is for device drivers based on acpi-bus.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dawei Li <set_pte_at@outlook.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for drivers/platform/surface/*
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add RaptorLake to the list of processor models supported by the Intel
TCC cooling driver.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When MSR_IA32_TEMPERATURE_TARGET is locked, TCC Offset can not be
updated even if the PROGRAMMABE Bit is set.
Yield the driver on platforms with MSR_IA32_TEMPERATURE_TARGET locked.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
A Coverity static code scan raised a potential overflow_before_widen
warning when hfi_features::nr_table_pages is used as an argument to
memcpy in intel_hfi_process_event().
Even though the overflow can never happen (the maximum number of pages of
the HFI table is 0x10 and 0x10 << PAGE_SHIFT = 0x10000), using size_t as
the data type of hfi_features::nr_table_pages makes Coverity happy and
matches the data type of the argument 'size' of memcpy().
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit 68b99e94a4a2 ("thermal: intel_powerclamp: Use get_cpu() instead
of smp_processor_id() to avoid crash") fixed an issue related to using
smp_processor_id() in preemptible context by replacing it with a pair
of get_cpu()/put_cpu(), but what is needed there really is any online
CPU and not necessarily the one currently running the code. Arguably,
getting the one that's running the code in there is confusing.
For this reason, simply give the control CPU role to the first online
one which automatically will be CPU0 if it is online, so one check
can be dropped from the code for an added benefit.
Link: https://lore.kernel.org/linux-pm/20221011113646.GA12080@duo.ucw.cz/
Fixes: 68b99e94a4a2 ("thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
|
|
Since PCI provides helper macro module_pci_driver(), the
module_init/exit code can be replaced with it.
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is a static variable "idle_wakeup_counter", which accounts for
number of wake ups because of IRQs and take actions to compensate idle
injection. This is now read and reset to 0, but never incremented.
So all the usage of this counter for idle injection has no use.
Also another static variable "reduce_irq", which depends on
"idle_wakeup_counter", so remove usage of "reduce_irq" also.
Commit feb6cd6a0f9f ("thermal/intel_powerclamp: stop sched tick in
forced idle") replaced the local use of "mwait_idle_with_hints" with
play_idle(). This removed possibility of updating "idle_wakeup_counter"
without change in play_idle(). This change was made in Linux 4.10.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
avoid crash
When CPU 0 is offline and intel_powerclamp is used to inject
idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687
caller is debug_smp_processor_id+0x17/0x20
CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x63
dump_stack+0x10/0x16
check_preemption_disabled+0xdd/0xe0
debug_smp_processor_id+0x17/0x20
powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]
...
...
Here CPU 0 is the control CPU by default and changed to the current CPU,
if CPU 0 offlined. This check has to be performed under cpus_read_lock(),
hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
Suggested-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
It is sufficient to check priv->data_vault once in the error code path
of int3400_thermal_probe(), so do that.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.
[ 71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value in data_vault.
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add Alder Lake-N and Raptor Lake-P to the list of processor models
supported by the Intel TCC cooling driver.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
If ACPI_FADT_LOW_POWER_S0 is not set, this doesn't mean that low-power
S0 idle is not usable. It merely means that using S3 on the given
system is more beneficial from the energy saving perspective than using
low-power S0 idle, as long as S3 is supported.
Suspend-to-idle is still a valid suspend mode if ACPI_FADT_LOW_POWER_S0
is not set and the pm_suspend_via_firmware() check in pch_wpt_suspend()
is sufficient to distinguish suspend-to-idle from S3, so drop the
confusing ACPI_FADT_LOW_POWER_S0 check.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
|
|
There is an unexpected word 'is' in a comments that need to be dropped
file: ./drivers/thermal/intel/x86_pkg_temp_thermal.c
line: 108
* tj-max is is interesting because threshold is set relative to this
changed to:
* tj-max is interesting because threshold is set relative to this
Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fix from Rafael Wysocki:
"Add a new CPU ID to the list of supported processors in the
intel_tcc_cooling driver (Sumeet Pawnikar)"
* tag 'thermal-5.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: intel_tcc_cooling: Add TCC cooling support for RaptorLake
|
|
Add RaptorLake to the list of processor models supported by the Intel
TCC cooling driver.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
[ rjw: Subject edits, new changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull additional thermal control update from Rafael Wysocki:
"Add Meteor Lake PCI device ID to the int340x thermal control driver
(Sumeet Pawnikar)"
* tag 'thermal-5.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: int340x: Add Meteor Lake PCI device ID
|
|
Add Meteor Lake PCI ID for processor thermal device.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add Meteor Lake ACPI IDs for DPTF devices.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Merge int340x thermal driver updates, PCH thermal driver updates and
miscellaneous thermal control updates for 5.19-rc1:
- Clean up _OSC handling in int340x (Davidlohr Bueso).
- Improve overheat condition handling during suspend-to-idle in the
Intel PCH thermal driver (Zhang Rui).
- Use local ops instead of global ops in devfreq_cooling (Kant Fan).
- Switch hisi_termal from CONFIG_PM_SLEEP guards to pm_sleep_ptr()
(Hesham Almatary)
* thermal-int340x:
thermal: int340x: Clean up _OSC context init
thermal: int340x: Consolidate freeing of acpi_buffer pointer
thermal: int340x: Clean up unnecessary acpi_buffer pointer freeing
* thermal-pch:
thermal: intel: pch: improve the cooling delay log
thermal: intel: pch: enhance overheat handling
thermal: intel: pch: move cooling delay to suspend_noirq phase
PM: wakeup: expose pm_wakeup_pending to modules
* thermal-misc:
thermal: devfreq_cooling: use local ops instead of global ops
thermal: hisi_termal: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr()
|
|
|
|
Previously, during suspend, intel_pch_thermal driver logs for every
cooling iteration, about the current PCH temperature and number of cooling
iterations that have been tried, like below
[ 100.955526] intel_pch_thermal 0000:00:14.2: CPU-PCH current temp [53C] higher than the threshold temp [50C], sleep 1 times for 100 ms duration
[ 101.064156] intel_pch_thermal 0000:00:14.2: CPU-PCH current temp [53C] higher than the threshold temp [50C], sleep 2 times for 100 ms duration
After changing the default delay_cnt to 600, in practice, it is common to
see tens of the above messages if the system is suspended when PCH
overheats. Thus, change this log message from dev_warn to dev_dbg because
it is only useful when we want to check the temperature trend.
At the same time, there is always a one-line message given by the driver
with the patch applied, with below four possibilities.
1. PCH is cool, no cooling delay needed
[ 1791.902853] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [48C]
2. PCH overheats and becomes cool after the cooling delays
[ 1475.511617] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [49C] after 30700 ms delay
3. PCH still overheats after the overall cooling timeout
[ 2250.157487] intel_pch_thermal 0000:00:12.0: CPU-PCH is hot [60C] after 60000 ms delay. S0ix might fail
4. PCH aborts cooling because of wakeup event detected during the delay
[ 1933.639509] intel_pch_thermal 0000:00:12.0: Wakeup event detected, abort cooling
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit ef63b043ac86 ("thermal: intel: pch: fix S0ix failure due to PCH
temperature above threshold") introduces delay loop mechanism that allows
PCH temperature to go down below threshold during suspend so it won't
block S0ix. And the default overall delay timeout is 1 second.
However, in practice, we found that the time it takes to cool the PCH down
below threshold highly depends on the initial PCH temperature when the
delay starts, as well as the ambient temperature.
And in some cases, the 1 second delay is not sufficient. As a result, the
system stays in a shallower power state like PCx instead of S0ix, and
drains the battery power, without user' notice.
To make sure S0ix is not blocked by the PCH overheating, we
1. expand the default overall timeout to 60 seconds.
2. make sure the temperature is below threshold rather than equal to it.
At the same time, as the cooling delay can be much longer and many wakeup
events (ACPI Power Button press, USB mouse move, etc) becomes valid in the
suspend_noirq phase, add detection of wakeup event so that the driver
does not delay blindly when the system suspend is likely to abort soon.
This patch may introduce longer suspend time, but only in the cases when
the system overheats and Linux used to enter a shallower S2idle state,
say, PCx instead of S0ix.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Move the PCH Thermal driver suspend callback to suspend_noirq to do
cooling while the system is more quiescent.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
container_of() will never return NULL, so remove useless code.
Signed-off-by: Haowen Bai <baihaowen@meizu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
With the new OS handshake introduced by commit: "c7ff29763989 ("thermal:
int340x: Update OS policy capability handshake")", the "enabled" thermal
zone mode doesn't work in the same way as previously.
The "enabled" mode fails with -EINVAL when the new handshake is used.
To address this issue, when the new OS UUID mask is set:
- When the mode is "enabled", return 0 as the firmware already has the
latest policy mask.
- When the mode is "disabled", update the firmware with the UUID mask
of zero.
This way, the firmware can take over the thermal control.
Also reset the OS UUID mask, which allows user space to update with new
set of policies.
Fixes: c7ff29763989 ("thermal: int340x: Update OS policy capability handshake")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Changelog edits, removed unneeded parens ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
Control Flow Integrity (CFI) instrumentation of the kernel noticed that
the caller, dev_attr_show(), and the callback, odvp_show(), did not have
matching function prototypes, which would cause a CFI exception to be
raised. Correct the prototype by using struct device_attribute instead
of struct kobj_attribute.
Reported-and-tested-by: Joao Moreira <joao@overdrivepizza.com>
Link: https://lore.kernel.org/lkml/067ce8bd4c3968054509831fa2347f4f@overdrivepizza.com/
Fixes: 006f006f1e5c ("thermal/int340x_thermal: Export OEM vendor variables")
Cc: 5.8+ <stable@vger.kernel.org> # 5.8+
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Now that the UUID is already sanitized by the caller,
lets trivially clean up some of the context arming.
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Acked-by: Zhang Rui <rui.zhang@intel.com>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Introduce a single point of freeing/exit after ensuring no error in
int3400_setup_gddv().
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
It is the caller's responsibility to free only upon ACPI_SUCCESS.
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Acked-by: Zhang Rui <rui.zhang@intel.com>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Merge Intel Hardware Feedback Interface (HFI) thermal driver for
5.18-rc1 and update the intel-speed-select utility to support that
driver.
* thermal-hfi:
tools/power/x86/intel-speed-select: v1.12 release
tools/power/x86/intel-speed-select: HFI support
tools/power/x86/intel-speed-select: OOB daemon mode
thermal: intel: hfi: INTEL_HFI_THERMAL depends on NET
thermal: netlink: Fix parameter type of thermal_genl_cpu_capability_event() stub
thermal: intel: hfi: Notify user space for HFI events
thermal: netlink: Add a new event to notify CPU capabilities change
thermal: intel: hfi: Enable notification interrupt
thermal: intel: hfi: Handle CPU hotplug events
thermal: intel: hfi: Minimally initialize the Hardware Feedback Interface
x86/cpu: Add definitions for the Intel Hardware Feedback Interface
x86/Documentation: Describe the Intel Hardware Feedback Interface
|
|
Merge powerclamp thermal driver changes, int340x thermal driver changes
and thermal documentation changes for 5.18-rc1:
- Don't use bitmap_weight() in end_power_clamp() in the powerclamp
driver (Yury Norov).
- Update the OS policy capabilities handshake in the int340x thermal
driver (Srinivas Pandruvada).
- Increase the policies bitmap size in int340x (Srinivas Pandruvada).
- Replace acpi_bus_get_device() with acpi_fetch_acpi_dev() in the
int340x thermal driver (Rafael Wysocki).
- Check for NULL after calling kmemdup() in int340x (Jiasheng Jiang).
- Add Intel Dynamic Power and Thermal Framework (DPTF) kernel interface
documentation (Srinivas Pandruvada).
- Fix bullet list warning in the thermal documentation (Randy Dunlap).
* thermal-powerclamp:
thermal: intel_powerclamp: don't use bitmap_weight() in end_power_clamp()
* thermal-int340x:
thermal: int340x: Update OS policy capability handshake
thermal: int340x: Increase bitmap size
thermal: Replace acpi_bus_get_device()
thermal: int340x: Check for NULL after calling kmemdup()
* thermal-docs:
Documentation: thermal: DPTF Documentation
thermal: fix Documentation bullet list warning
|
|
Update the firmware with OS supported policies mask, so that firmware can
relinquish its internal controls. Without this update several Tiger Lake
laptops gets performance limited with in few seconds of executing in
turbo region.
The existing way of enumerating firmware policies via IDSP method and
selecting policy by directly writing those policy UUIDS via _OSC method
is not supported in newer generation of hardware.
There is a new UUID "B23BA85D-C8B7-3542-88DE-8DE2FFCFD698" is defined for
updating policy capabilities. As part of ACPI _OSC method:
Arg0 - UUID: B23BA85D-C8B7-3542-88DE-8DE2FFCFD698
Arg1 - Rev ID: 1
Arg2 - Count: 2
Arg3 - Capability buffers: Array of Arg2 DWORDS
DWORD1: As defined in the ACPI 5.0 Specification
- Bit 0: Query Flag
- Bits 1-3: Always 0
- Bits 4-31: Reserved
DWORD2 and beyond:
- Bit0: set to 1 to indicate Intel(R) Dynamic Tuning is active, 0 to
indicate it is disabled and legacy thermal mechanism should
be enabled.
- Bit1: set to 1 to indicate Intel(R) Dynamic Tuning is controlling
active cooling, 0 to indicate bios shall enable legacy thermal
zone with active trip point.
- Bit2: set to 1 to indicate Intel(R) Dynamic Tuning is controlling
passive cooling, 0 to indicate bios shall enable legacy thermal
zone with passive trip point.
- Bit3: set to 1 to indicate Intel(R) Dynamic Tuning is handling
critical trip point, 0 to indicate bios shall enable legacy
thermal zone with critical trip point.
- Bits 4:31: Reserved
From sysfs interface, there is an existing interface to update policy
UUID using attribute "current_uuid". User space can write the same UUID
for ACTIVE, PASSIVE and CRITICAL policy. Driver converts these UUIDs to
DWORD2 Bit 1 to Bit 3. When any of the policy is activated by user
space it is assumed that dynamic tuning is active.
For example
$cd /sys/bus/platform/devices/INTC1040:00/uuids
To support active policy
$echo "3A95C389-E4B8-4629-A526-C52C88626BAE" > current_uuid
To support passive policy
$echo "42A441D6-AE6A-462b-A84B-4A8CE79027D3" > current_uuid
To support critical policy
$echo "97C68AE7-15FA-499c-B8C9-5DA81D606E0A" > current_uuid
To check all the supported policies
$cat current_uuid
3A95C389-E4B8-4629-A526-C52C88626BAE
42A441D6-AE6A-462b-A84B-4A8CE79027D3
97C68AE7-15FA-499c-B8C9-5DA81D606E0A
To match the bit format for DWORD2, rearranged enum int3400_thermal_uuid
and int3400_thermal_uuids[] by swapping current INT3400_THERMAL_ACTIVE
and INT3400_THERMAL_PASSIVE_1.
If the policies are enumerated via IDSP method then legacy method is
used, if not the new method is used to update policy support.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The number of policies are 10, so can't be supported by the bitmap size
of u8.
Even though there are no platfoms with these many policies, but
for correctness increase to u32.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Fixes: 16fc8eca1975 ("thermal/int340x_thermal: Add additional UUIDs")
Cc: 5.1+ <stable@vger.kernel.org> # 5.1+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
|
|
It is easy to hit the below memory leaks in my TigerLake platform:
unreferenced object 0xffff927c8b91dbc0 (size 32):
comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)
hex dump (first 32 bytes):
4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The
72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.
backtrace:
[<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0
[<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0
[<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70
[<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal]
[<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71
[<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30
[<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0
[<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0
[<ffffffff9c2cb4dd>] kthread+0xfd/0x130
[<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30
Fix it by calling kfree() accordingly.
Fixes: 38e44da59130 ("thermal: int3400_thermal: process "thermal table changed" event")
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
THERMAL_NETLINK depends on NET and since 'select' does not follow
any dependency chain, INTEL_HFI_THERMAL also should depend on NET.
Fix one Kconfig warning and 48 subsequent build errors:
WARNING: unmet direct dependencies detected for THERMAL_NETLINK
Depends on [n]: THERMAL [=y] && NET [=n]
Selected by [y]:
- INTEL_HFI_THERMAL [=y] && THERMAL [=y] && (X86 [=y] || X86_INTEL_QUARK [=n] || COMPILE_TEST [=y]) && CPU_SUP_INTEL [=y] && X86_THERMAL_VECTOR [=y]
Fixes: bd30cdfd9bd7 ("thermal: intel: hfi: Notify user space for HFI events")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Replace acpi_bus_get_device() that is going to be dropped with
acpi_fetch_acpi_dev().
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Don't call bitmap_weight() if the following code can get by
without it.
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
As the potential failure of the allocation, kmemdup() may return NULL.
Then, 'bin_attr_data_vault.private' will be NULL, but
'bin_attr_data_vault.size' is not 0, which is not consistent.
Therefore, it is better to check the return value of kmemdup() to
avoid the confusion.
Fixes: 0ba13c763aac ("thermal/int340x_thermal: Export GDDV")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When the hardware issues an HFI event, relay a notification to user space.
This allows user space to respond by reading performance and efficiency of
each CPU and take appropriate action.
For example, when the performance and efficiency of a CPU is 0, user space
can either offline the CPU or inject idle. Also, if user space notices a
downward trend in performance, it may proactively adjust power limits to
avoid future situations in which performance drops to 0.
To avoid excessive notifications, the rate is limited by one HZ per event.
To limit the netlink message size, send parameters for up to 16 CPUs in a
single message. If there are more than 16 CPUs, issue as many messages as
needed to notify the status of all CPUs.
In the HFI specification, both performance and efficiency capabilities are
defined in the [0, 255] range. The existing implementations of HFI hardware
do not scale the maximum values to 255. Since userspace cares about
capability values that are either 0 or show a downward/upward trend, this
fact does not matter much. Relative changes in capabilities are enough. To
comply with the thermal netlink ABI, scale both performance and efficiency
capabilities to the [0, 1023] interval.
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>
|
