- 13 Dec, 2023 3 commits
-
-
Mark Brown authored
The cap11xx devices have three hardware identification registers which are currently marked as volatile, preventing caching of those registers. This is not ideal since the registers should never change at runtime, we should be able to cache the value after the first read. Stop marking the registers as volatile, we don't have register defaults specified in the driver so this will result in reading from the hardware on first use. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20231001-input-maple-v1-1-ed3716051431@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Jiri Valek - 2N authored
Add support for advanced sensitivity settings that allows more precise tunig of touch buttons. Input-treshold allows to set the sensitivity for each channel separately. Also add signal guard feature for CAP129x chips. Signed-off-by: Jiri Valek - 2N <jiriv@axis.com> Link: https://lore.kernel.org/r/20231121155250.613242-3-jiriv@axis.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Jiri Valek - 2N authored
Add support for advanced sensitivity settings and signal guard feature. Signed-off-by: Jiri Valek - 2N <jiriv@axis.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231121155250.613242-2-jiriv@axis.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 12 Dec, 2023 2 commits
-
-
Christophe JAILLET authored
ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). This is less verbose. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/a3e30e30f18cc5d6f032c8013ce9d900c8e223e5.1702228806.git.christophe.jaillet@wanadoo.frSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Andreas Kemnade authored
According to SWPU235AB, table 26-6, fclk is required to generate events at least on OMAP4460, so keep fclk enabled all the time the device is opened. Suggested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231211221757.517427-1-andreas@kemnade.infoSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 10 Dec, 2023 1 commit
-
-
Marcus Folkesson authored
Use the guard(mutex) macro for handle mutex lock/unlocks. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20231202-pxrc-guard-v3-1-2ca8bc8cf689@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 08 Dec, 2023 1 commit
-
-
Anshul Dalal authored
Convert device tree binding documentation for GPIO attached mouse to json-schema. Signed-off-by: Anshul Dalal <anshulusr@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231208075037.114598-1-anshulusr@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 30 Nov, 2023 2 commits
-
-
Tony Lindgren authored
Some SoCs have a separate dedicated wake-up interrupt controller that can be used to wake up the system from deeper idle states. We already support configuring a separate interrupt for a gpio-keys button to be used with a gpio line. However, we are lacking support system suspend for cases where a separate interrupt needs to be used in deeper sleep modes. Because of it's nature, gpio-keys does not know about the runtime PM state of the button gpios, and may have several gpio buttons configured for each gpio-keys device instance. Implementing runtime PM support for gpio-keys does not help, and we cannot use drivers/base/power/wakeirq.c support. We need to implement custom wakeirq support for gpio-keys. For handling a dedicated wakeirq for system suspend, we enable and disable it with gpio_keys_enable_wakeup() and gpio_keys_disable_wakeup() that we already use based on device_may_wakeup(). Some systems may have a dedicated wakeirq that can also be used as the main interrupt, this is already working for gpio-keys. Let's add some wakeirq related comments while at it as the usage with a gpio line and separate interrupt line may not be obvious. Tested-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231129110618.27551-2-tony@atomide.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Tony Lindgren authored
Allow configuring an optional dedicated wakeirq for gpio-keys that some SoCs have. Let's use the common interrupt naming "irq" and "wakeup" that we already have in use for some drivers and subsystems like i2c framework. Note that the gpio-keys interrupt property is optional. If only a gpio property is specified, the driver tries to translate the gpio into an interrupt. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231129110618.27551-1-tony@atomide.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 29 Nov, 2023 2 commits
-
-
Rob Herring authored
The example for the Mediatek PMIC keys is incomplete as the binding is the full PMIC, not just the sub-functions. It is preferred for MFD examples to be complete in the top-level MFD device binding rather than piecemeal in each sub-function binding. This also fixes an undocumented (by schema) compatible warning for "mediatek,mt6397". Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231128214816.3975893-1-robh@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Rob Herring authored
The example for the Spreadtrum SC27xx PMIC vibrator is incomplete as the binding is the full PMIC, not just the sub-functions. It is preferred for MFD examples to be complete in the top-level MFD device binding rather than piecemeal in each sub-function binding. This also fixes an undocumented (by schema) compatible warning for "sprd,sc2731". Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231128214809.3975719-1-robh@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 17 Nov, 2023 1 commit
-
-
Jiri Valek - 2N authored
Separate IRQ parsing is not necessary, I2C core do the job. Signed-off-by: Jiri Valek - 2N <jiriv@axis.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 15 Nov, 2023 1 commit
-
-
Krzysztof Kozlowski authored
Convert Samsung S6SY761 touchscreen controller bindings to DT schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231111143221.55452-1-krzysztof.kozlowski@linaro.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 29 Oct, 2023 3 commits
-
-
Li Zetao authored
Use the module_parport_driver macro to simplify the code, which is the same as declaring with module_init() and module_exit(). Signed-off-by: Li Zetao <lizetao1@huawei.com> Link: https://lore.kernel.org/r/20230815080107.1089401-1-lizetao1@huawei.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dan Carpenter authored
The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this. Fixes: 24d28e4f ("Input: synaptics-rmi4 - convert irq distribution to irq_domain") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/706efd36-7561-42f3-adfa-dd1d0bd4f5a1@moroto.mountainSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Fabio Estevam authored
The SCU Key controller can be used as a system wakeup source. Document the 'wakeup-source' property. This fixes the following schema warning: system-controller: keys: 'wakeup-source' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/firmware/fsl,scu.yaml#Signed-off-by: Fabio Estevam <festevam@denx.de> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230926122957.341094-1-festevam@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 27 Oct, 2023 2 commits
-
-
Lin, Meng-Bo authored
The Cypress touchscreen controllers are often used with external pull-up for the interrupt line and the I2C lines, so we might need to enable a regulator to bring the lines into usable state. Otherwise, this might cause spurious interrupts and reading from I2C will fail. Implement support for a "vddio-supply" that is enabled by the cyttsp5 driver so that the regulator gets enabled when needed. Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com> Acked-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20221117190507.87535-3-linmengbo0689@protonmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Lin, Meng-Bo authored
The Samsung touchscreen controllers are often used with external pull-up for the interrupt line and the I2C lines, so we might need to enable a regulator to bring the lines into usable state. Otherwise, this might cause spurious interrupts and reading from I2C will fail. Document support for a "vddio-supply" that is enabled by the cyttsp5 driver so that the regulator gets enabled when needed. Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20221117190507.87535-2-linmengbo0689@protonmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 14 Oct, 2023 2 commits
-
-
Rob Herring authored
Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20231006224432.442709-1-robh@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct ff_device. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20231006201739.work.350-kees@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 30 Sep, 2023 5 commits
-
-
Justin Stitt authored
This code is doing more work than it needs to. Before handing off `val_str` to `kstrtouint()` we are eagerly removing any trailing newline which requires copying `buf`, validating it's length and checking/replacing any potential newlines. kstrtouint() handles this implicitly: kstrtouint -> kstrotoull -> (documentation) | /** | * kstrtoull - convert a string to an unsigned long long | * @s: The start of the string. The string must be null-terminated, and may also | * include a single newline before its terminating null. The first character | ... Let's remove the redundant functionality and let kstrtouint handle it. Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230925-strncpy-drivers-input-misc-axp20x-pek-c-v2-1-ff7abe8498d6@google.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct input_mt. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocciSigned-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230922175036.work.762-kees@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct input_leds. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocciSigned-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230922175031.work.467-kees@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct evdev_client. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocciSigned-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230922175027.work.563-kees@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1] Let's use memcpy() as the bounds have already been checked and this decays into a simple byte copy from one buffer to another removing any ambiguity that strncpy has. Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230921-strncpy-drivers-input-rmi4-rmi_f34-c-v1-1-4aef2e84b8d2@google.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 24 Sep, 2023 15 commits
-
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230920125829.1478827-53-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230920125829.1478827-52-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-51-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20230920125829.1478827-50-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-49-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-48-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-47-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-46-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-45-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-44-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20230920125829.1478827-43-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-42-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-41-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-40-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
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 ignored (apart from emitting a warning) 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. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230920125829.1478827-39-u.kleine-koenig@pengutronix.deSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-