- 22 Apr, 2023 40 commits
-
-
Kathiravan T authored
Add a compatible for the IPQ5332 platform's APSS watchdog. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Kathiravan T <quic_kathirav@quicinc.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230320104530.30411-2-quic_kathirav@quicinc.comSigned-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org>
-
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 <sergio.paracuellos@gmail.com> Reviewed-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:
-
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:
-
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:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
-
