Hi Krzysztof,
On 24/08/2023 14:38, Krzysztof Kozlowski wrote:
On 24/08/2023 12:53, Fabio Estevam wrote:
Hi Daniel,
On Thu, Aug 24, 2023 at 7:35 AM Daniel Lezcano
<daniel.lezcano@xxxxxxxxxx> wrote:
I will try a different approach by introducing a Kconfig option.
Alternatively, the 'chosen' DT node could be used, no ?
Any DT property would be a problem, because I don't think it is static
configuration. For example board with the same DTS once should reboot
(during development) and once shutdown (some customer wants to be sure
it will stay shutdown after critical condition). It's runtime feature.
Fabio described the feature as a firmware feature where the board does
not boot until the temperature goes below a certain temperature.
That does not look a runtime feature but a platform specific one.
From my POV, if the firmware wants to take over the thermal boot of the
board, it is probably for a good reason (eg. the board will overheat
between the boot and the kernel puts in place the mitigation framework).
Letting the user to change that behavior can be dangerous.
Good idea. I will introduce a module_param() then.
Module params are usually discouraged
Why?
and it also does not allow any
runtime configuration. I think you need sysfs ABI.
There is already the sysfs ABI with module params
/sys/module/<name>/parameters/reboot_on_critical
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
