- 22 Apr, 2023 40 commits
-
-
Bhupesh Sharma authored
Add devicetree binding for watchdog present on Qualcomm SM6115 SoC. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230314051351.1754321-1-bhupesh.sharma@linaro.orgSigned-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org>
-
Krzysztof Kozlowski authored
Required properties should be listed in "required:" block. Since interrupts are already there, the dependency of interrupt-names on the interrupts can be simplified. Signed-off-by:
Sander Vanheule <sander@svanheule.net> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Krzysztof Kozlowski authored
Allow generic watchdog properties by using unevaluatedProperties: false. Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Reviewed-by:
-
Krzysztof Kozlowski authored
Allow generic watchdog properties by using unevaluatedProperties: false. Signed-off-by:
-
Krzysztof Kozlowski authored
There is no need to specify minItems when they are equal to maxItems, because it is implied by maxItems. Signed-off-by:
-
Krzysztof Kozlowski authored
Two conversions to DT schema of GPIO watchdog binding happened and came through different trees. Merge them into one: 1. Combine maintainers, 2. Use more descriptive property descriptions and constraints from gpio-wdt.yaml, 3. Switch to unevaluatedProperties:false, to allow generic watchdog properties. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230415095112.51257-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Yassine Oudjana authored
Add a DT binding for the MT6735 top reset generation unit/watchdog timer. Signed-off-by:
Yassine Oudjana <y.oudjana@protonmail.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
-
Xingyu Wu authored
Add watchdog driver for the StarFive JH7100 and JH7110 SoC. Signed-off-by:
Xingyu Wu <xingyu.wu@starfivetech.com> Reviewed-by:
Emil Renner Berthing <emil.renner.berthing@canonical.com> Reviewed-by:
-
Xingyu Wu authored
Add bindings to describe the watchdog for the StarFive JH7100/JH7110 SoC. And Use JH7100 as first StarFive SoC with watchdog. Signed-off-by:
-
Krzysztof Kozlowski authored
Minor cleanup without functional impact: 1. Indent DTS examples to preferred four-spaces (more readable for DTS), 2. Drop unneeded quotes, 3. Add/drop blank lines to make the code readable. Signed-off-by:
Sergio Paracuellos <sergio.paracuellos@gmail.com> Acked-by:
Justin Chen <justinpopo6@gmail.com> Acked-by:
Neil Armstrong <neil.armstrong@linaro.org> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
-
William Breathitt Gray authored
The current maintainer no longer has access to the device for testing, the original user of this driver indicates that they have moved on to another device, and the manufacturer WINSYSTEMS does not appear interested in taking over support for this code. Signed-off-by:
William Breathitt Gray <william.gray@linaro.org> Reviewed-by:
-
Alexandre Mergnat authored
Add binding description for mediatek,mt8365-wdt Acked-by:
Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by:
Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by:
-
Konrad Dybcio authored
Document the QCM2290 KPSS watchdog. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by:
-
Kathiravan T authored
Add a compatible for the IPQ5332 platform's APSS watchdog. Reviewed-by:
Kathiravan T <quic_kathirav@quicinc.com> Reviewed-by:
-
Shreeya Patel authored
Add rockchip,rk3588-wdt compatible string. Signed-off-by:
Shreeya Patel <shreeya.patel@collabora.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Acked-by:
-
Jakob Koschel authored
If potentially no valid element is found, 'p' would contain an invalid pointer past the iterator loop. To ensure 'p' is valid under any circumstances, the kfree() should be within the loop body. Additionally, Linus proposed to avoid any use of the list iterator variable after the loop, in the attempt to move the list iterator variable declaration into the macro to avoid any potential misuse after the loop [1]. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] Signed-off-by:
Jakob Koschel <jkl820.git@gmail.com> Reviewed-by:
-
Tom Rix authored
clang with W=1 reports drivers/watchdog/s3c2410_wdt.c:311:35: error: unused function 'freq_to_wdt' [-Werror,-Wunused-function] static inline struct s3c2410_wdt *freq_to_wdt(struct notifier_block *nb) ^ drivers/watchdog/s3c2410_wdt.c:446:19: error: unused function 's3c2410wdt_is_running' [-Werror,-Wunused-function] static inline int s3c2410wdt_is_running(struct s3c2410_wdt *wdt) ^ These functions are not used, so remove them. Signed-off-by:Tom Rix <trix@redhat.com> Reviewed-by:
Andi Shyti <andi.shyti@kernel.org> Reviewed-by:
-
Krzysztof Kozlowski authored
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). drivers/watchdog/aspeed_wdt.c:56:34: error: ‘aspeed_wdt_of_table’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Gregory Oakes authored
The watchdog countdown is supposed to begin when the device file is opened. Instead, it would begin countdown upon the first write to or close of the device file. Now, the ping operation is called within the start operation which ensures the countdown begins. From experimenation, it does not appear possible to do this with a single write including both the start bit and the trigger bit. So, it is done as two distinct writes. Signed-off-by:
Gregory Oakes <gregory.oakes@amd.com> Reviewed-by:
-
Sergio Paracuellos authored
Ralink RT2880 Watchdog bindings used text format, so migrate them to YAML. There are some additions to the binding that were not in the original txt file. This binding is used in RT2880, RT3050, RT3352, RT3883, RT5350, and MT7620 SoCs. To properly align binding with driver code we need to add to the schema 'clocks' and 'resets' properties. Signed-off-by:
-
Sergio Paracuellos authored
Instead of declare 'reg' variable in read and write operations as a bare 'unsigned' type prefer to declate it as 'unsigned int'. Signed-off-by:
-
Sergio Paracuellos authored
Instead of using static global definitions in driver code, refactor code introducing a new watchdog driver data structure and use it along the code. Signed-off-by:
-
Christophe JAILLET authored
The devm_clk_get_enabled() helper: - calls devm_clk_get() - calls clk_prepare_enable() and registers what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code and avoids the need of a dedicated function used with devm_add_action_or_reset(). Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Christophe JAILLET authored
The devm_clk_get_enabled() helper: - calls devm_clk_get() - calls clk_prepare_enable() and registers what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code and avoids the need of a dedicated function used with devm_add_action_or_reset(). Signed-off-by: -
Uwe Kleine-König authored
Make use of dev_err_probe() also for error paths that don't have to handle -EPROBE_DEFER. While the code handing -EPROBE_DEFER isn't used for these error paths, it still simpler as it cares for pretty printing the error code and usually needs one code line less as it combines message emitting and error returning. This also unifies the format of the error messages. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
Uwe Kleine-König authored
This is a preparation for making more use of dev_err_probe(). The idea is that s3c2410_get_wdt_drv_data() (as it's called only by .probe()) can make effective use of dev_err_probe() only if it returns an int. For that the assignment to wdt->drv_data has to happen in the function. The caller can then just pass on the return value in the error case. This seems to be nicer for the compiler: bloatometer reports for an ARCH=arm s3c6400_defconfig build: add/remove: 1/1 grow/shrink: 0/1 up/down: 4/-64 (-60) Function old new delta __initcall__kmod_s3c2410_wdt__209_821_s3c2410wdt_driver_init6 - 4 +4 __initcall__kmod_s3c2410_wdt__209_819_s3c2410wdt_driver_init6 4 - -4 s3c2410wdt_probe 1332 1272 -60 There is no semantical change. (Just one minor difference: Before this patch wdt->drv_data was always assigned, now that only happens in the non-error case. That doesn't matter however as *wdt is freed in the error case.) Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the .remove() function as it only exists to unregister the watchdog device which is now done in a callback registered by devm_watchdog_register_device(). Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230307070404.2256308-4-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
This allows to drop the .remove() function as it only exists to unregister the watchdog device which is now done in a callback registered by devm_watchdog_register_device(). Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the .remove() function as it only exists to unregister the watchdog device which is now done in a callback registered by devm_watchdog_register_device(). Signed-off-by:
-
Wang Wensheng authored
If the sbsa_gwdt is enabled by BIOS, the kernel set WDOG_HW_RUNNING bit and keep it alive before anyone else would open it. When system suspend, the sbsa_gwdt would not be disabled because WDOG_ACTIVE is not set. Then the sbsa_gwdt would reach timeout since no one touch it during system suspend. To solve this, just test WDOG_HW_RUNNING bit in suspend and disable the sbsa_gwdt if the bit is set, then reopen it accordingly in resume process. Signed-off-by:
Wang Wensheng <wangwensheng4@huawei.com> Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
