- 02 Oct, 2023 20 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> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
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 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 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 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:
Heiko Stuebner <heiko@sntech.de> 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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:
-
- 27 Sep, 2023 5 commits
-
-
Bartosz Golaszewski authored
We have a special place for OF polarity quirks in gpiolib-of.c. Let's move this over there so that it doesn't pollute the driver. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Andy Shevchenko <andy@kernel.org>
-
Fabio Estevam authored
fsl,imx25-gpio and fsl,imx27-gpio are not documented, causing schema warnings. fsl,imx25-gpio is compatible with fsl,imx35-gpio and fsl,imx27-gpio is compatible with fsl,imx21-gpio. Document them accordingly. Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Yinbo Zhu authored
This patch was to add loongson 2k0500, 2k2000 and 3a5000 gpio chip driver support and define inten_offset attibute to enable gpio chip interrupt. Signed-off-by:
Yinbo Zhu <zhuyinbo@loongson.cn> Reviewed-by:
-
Yinbo Zhu authored
This patch was to add loongson 2k0500, 2k2000 and 3a5000 gpio chip dt-bindings support in yaml file. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Linus Walleij authored
This rewrites the IXP4xx GPIO bindings to use YAML schema, and adds two new properties to enable fixed clock output on pins 14 and 15. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 25 Sep, 2023 2 commits
-
-
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 linereq. Additionally, since the element count member must be set before accessing the annotated flexible array member, move its initialization earlier. [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> Reviewed-by:
-
Bartosz Golaszewski authored
Variables managed with __free() should typically be initialized where they are declared so that the __free() callback is paired with its counterpart resource allocator. Fix the second instance of using __free() in gpio-sim to follow this pattern. Fixes: 3faf89f2 ("gpio: sim: simplify code with cleanup helpers") Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- 18 Sep, 2023 1 commit
-
-
Bartosz Golaszewski authored
We're using various ERR macros from linux/err.h but the include is missing. Add it. Fixes: cb8c474e ("gpio: sim: new testing module") Signed-off-by:
-
- 13 Sep, 2023 2 commits
-
-
Bartosz Golaszewski authored
Instead of dereferencing pdev everywhere, just store the address of the underlying struct device in a local variable. Signed-off-by:
Baolin Wang <baolin.wang@linux.alibaba.com>
-
Bartosz Golaszewski authored
This is a tristate module, it can be unloaded. We need to cleanup properly and unregister from the interrupt notifier on driver detach. Fixes: b3241565 ("gpio: eic-sprd: use atomic notifiers to notify all chips about irqs") Signed-off-by:
-
- 12 Sep, 2023 5 commits
-
-
Bartosz Golaszewski authored
gpiochip_get_desc() now lives in linux/gpio/driver.h and there is no longer any need to include GPIOLIB's private header. Signed-off-by:
-
Bartosz Golaszewski authored
It makes sense for a GPIO driver to want to get its own descriptor without requesting it. After all, the driver knows that it'll still be valid. Let's move this helper to linux/gpio/driver.h. Signed-off-by:
-
Bartosz Golaszewski authored
gpiod_is_active_low() is defined in linux/gpio/consumer.h. It's only because we're pulling in the gpiolib.h private header that we get this declaration implicitly but let's fix it as that is going away soon. Signed-off-by:
-
Bartosz Golaszewski authored
We access internals of struct gpio_device and struct gpio_desc because it's easier but it can actually be avoided and we're working towards a better encapsulation of GPIO data structures across the kernel so let's start at home. Instead of checking gpio_desc flags, let's just track the requests of GPIOs in the driver. We also already store the information about direction of simulated lines. For kobjects needed by sysfs callbacks: we can iterate over the children devices of the top-level platform device and compare their fwnodes against the one passed to the init function from probe. While at it: fix one line break and remove the untrue part about configfs callbacks using dev_get_drvdata() from a comment. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Bartosz Golaszewski authored
Merge tag 'platform-drivers-x86-ib-x86-android-tablets-v6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into gpio/for-next Immutable branch between pdx86 android tablets branch and GPIO due for the v6.7 merge window ib-x86-android-tablets-v6.7: v6.6-rc1 + ib-pdx86-android-tablets for merging into the GPIO subsystem for v6.7.
-
- 11 Sep, 2023 5 commits
-
-
Hans de Goede authored
The "linux,power-supply-name" property is a left-over from an earlier attempt to allow properties to specify the power_supply class-device name. The patch to read this property never made it upstream (and is no longer necessary). Drop the unused property. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Hans de Goede authored
Use the new x86-android-tablets platform-device as gpio-keys parent to make it clear that this gpio-keys device was instantiated by the x86-android-tablets driver. Signed-off-by:
-
Hans de Goede authored
Refactor x86_android_tablet_get_gpiod() to no longer use gpiolib private functions like gpiochip_find(). As a bonus this allows specifying that the GPIO is active-low, like the /CE (charge enable) pin on the bq25892 charger on the Lenovo Yoga Tablet 3. Reported-by:
Bartosz Golaszewski <brgl@bgdev.pl> Closes: https://lore.kernel.org/platform-driver-x86/20230905185309.131295-12-brgl@bgdev.pl/Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
-
Hans de Goede authored
Create a platform_device from module_init() and change x86_android_tablet_init() / cleanup() into platform_device probe() and remove() functions. This is a preparation patch for refactoring x86_android_tablet_get_gpiod() to no longer use gpiolib private functions like gpiochip_find(). Signed-off-by:
-
Hans de Goede authored
x86_dev_info.invalid_aei_gpiochip is no longer used by any boards and the x86-android-tablets code should not use the gpiolib private acpi_gpiochip_free_interrupts() function. Reported-by:
-
