On 24/08/2023 16:54, Daniel Lezcano wrote: > > 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. OK, if this is supposed to be also accessed before user-space or even before kernel, then it makes sense in DT. > >>> Good idea. I will introduce a module_param() then. >> >> Module params are usually discouraged > > Why? Because they don't scale with number of devices, are poorly documented and have general limitations comparing to sysfs. You can ask Greg for more details: https://lore.kernel.org/all/2023071135-opt-choosing-51dd@gregkh/ > >> 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 So patch solved? Best regards, Krzysztof
