- 09 Oct, 2023 4 commits
-
-
Bartosz Golaszewski authored
With no more users, we can remove acpi_get_and_request_gpiod(). Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by:
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com>
-
Bartosz Golaszewski authored
Merge tag 'platform-drivers-x86-ib-int3472-v6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into gpio/for-next Immutable branch between pdx86 int3472 branch and GPIO due for the v6.7 merge window. platform-drivers-x86-ib-int3472-v6.7: v6.6-rc1 + platform-drivers-x86-int3472 for merging into the GPIO subsystem for v6.7.
-
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> Signed-off-by:
-
Peng Fan authored
i.MX8ULP and i.MX93 legacy compatible strings use dual regs, while new compatible strings use one reg. The "support old compatible strings" is not clear to reflect the fact, so update it. Suggested-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
-
- 06 Oct, 2023 4 commits
-
-
Hans de Goede authored
Switch to devm_get_gpiod() for discrete GPIOs for clks / regulators / LEDs and let devm do the cleanup for us. Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
Use the new skl_int3472_gpiod_get_from_temp_lookup() helper to get a gpio to pass to register_gpio_clock(), skl_int3472_register_regulator() and skl_int3472_register_pled(). This removes all use of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. Suggested-by:
-
Bartosz Golaszewski authored
Add a new skl_int3472_gpiod_get_from_temp_lookup() helper. This is a preparation patch for removing usage of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. [hdegoede@redhat.com] use the new skl_int3472_fill_gpiod_lookup() helper Signed-off-by:
-
Hans de Goede authored
Add a new skl_int3472_fill_gpiod_lookup() helper. This is a preparation patch for removing usage of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions. Reviewed-by:
-
- 05 Oct, 2023 5 commits
-
-
Peng Fan authored
All of_device_id entries has valid data, so code simplified a bit by dropping the data check. Signed-off-by:
-
Peng Fan authored
i.MX8ULP/93 GPIO supports similar feature as i.MX7ULP GPIO, but i.MX8ULP is actually not hardware compatible with i.MX7ULP. i.MX8ULP only has one register base, not two bases. i.MX8ULP and i.MX93 actually has two interrupts for each gpio controller, one for Trustzone non-secure world, one for secure world. Although the Linux Kernel driver gpio-vf610.c could work with fsl,imx7ulp-gpio compatible, it is based on some tricks did in device tree with some offset added to base address. Add a new of_device_id entry for i.MX8ULP. But to make the driver could also support old bindings, check the compatible string first, before check the device data. Signed-off-by:
-
Peng Fan authored
Add i.MX95 compatible string which is compatible with i.MX8ULP Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Peng Fan authored
i.MX8ULP and i.MX93 actually has two interrupts for each gpio controller, one for Trustzone non-secure world, one for secure world. And they has one register based, not two as i.MX7ULP or VF610. Although the Linux Kernel driver gpio-vf610.c could work with fsl,imx7ulp-gpio compatible, it is based on some tricks did in device tree with some offset added to base address. So actually i.MX8ULP/i.MX93 is not compatible with i.MX7ULP. Last, i.MX93 is directly derived from i.MX8ULP, so make i.MX93 GPIO compatible with i.MX8ULP Reviewed-by:
-
Peng Fan authored
i.MX93 supports four gpio-ranges at max. To fix below issue: "gpio@43820080: gpio-ranges: [[30, 0, 84, 8], [30, 8, 66, 18], [30, 26, 34, 2], [30, 28, 0, 4]] is too long" Update the gpio-ranges property Acked-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 04 Oct, 2023 14 commits
-
-
Bartosz Golaszewski authored
gpiochip_find() is going away as it's not hot-unplug safe. This platform is not affected by any of the related problems as this GPIO controller cannot really go away but in order to finally remove this function, we need to convert it to using gpio_device_find() as well. Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by:
Tony Lindgren <tony@atomide.com>
-
Linus Walleij authored
Optional GPIOLIB as in not depended on or selected by a driver should NOT use any *_optional() calls, this becomes paradoxical. Signed-off-by:
-
Bartosz Golaszewski authored
We have removed all callers of gpiochip_find() so don't mention it in gpiolib-sysfs.c. Signed-off-by:
-
Bartosz Golaszewski authored
We're porting all users of gpiochip_find() to using gpio_device_find(). Update the swnode GPIO code. Signed-off-by:
-
Bartosz Golaszewski authored
We're porting all users of gpiochip_find() to using gpio_device_find(). Update the ACPI GPIO code. Signed-off-by:
-
Bartosz Golaszewski authored
We're porting all users of gpiochip_find() to using gpio_device_find(). Update the OF GPIO code. Signed-off-by:
-
Bartosz Golaszewski authored
Remove all remaining uses of find_chip_by_name() (and subsequently: gpiochip_find()) from gpiolib.c and use the new gpio_device_find_by_label() instead. Signed-off-by:
-
Bartosz Golaszewski authored
The process of converting all unauthorized users of struct gpio_chip to using dedicated struct gpio_device function will be long so in the meantime we must provide a way of retrieving the pointer to struct gpio_chip from a GPIO device. Signed-off-by:
-
Bartosz Golaszewski authored
Getting the GPIO descriptor directly from the gpio_chip struct is dangerous as we don't take the reference to the underlying GPIO device. In order to start working towards removing gpiochip_get_desc(), let's provide a safer variant that works with an existing reference to struct gpio_device. Signed-off-by:
-
Bartosz Golaszewski authored
By far the most common way of looking up GPIO devices is using their label. Provide a helpers for that to avoid every user implementing their own matching function. Signed-off-by:
-
Bartosz Golaszewski authored
gpiochip_find() is wrong and its kernel doc is misleading as the function doesn't return a reference to the gpio_chip but just a raw pointer. The chip itself is not guaranteed to stay alive, in fact it can be deleted at any point. Also: other than GPIO drivers themselves, nobody else has any business accessing gpio_chip structs. Provide a new gpio_device_find() function that returns a real reference to the opaque gpio_device structure that is guaranteed to stay alive for as long as there are active users of it. Signed-off-by:
-
Bartosz Golaszewski authored
As the few users that need to get the reference to the GPIO device often release it right after inspecting its properties, let's add support for the automatic reference release to struct gpio_device. Signed-off-by:
-
Bartosz Golaszewski authored
In order to start migrating away from accessing struct gpio_chip by users other than their owners, let's first make the reference management functions for the opaque struct gpio_device public in the driver.h header. Signed-off-by:
-
Linus Walleij authored
The OMAP GPIO driver hardcodes the MPIO chip base, but there is no point: we have already moved all consumers over to using descriptor look-ups. Drop the MPUIO GPIO base and use dynamic assignment. Root out the unused instances of the OMAP_MPUIO() macro and delete the unused OMAP_GPIO_IS_MPUIO() macro. Signed-off-by:
-
- 02 Oct, 2023 13 commits
-
-
Bartosz Golaszewski authored
There are two places in the code where we retrieve a lookup table using gpiod_find_lookup_table() (which protects the table list with the lookup table lock) and then use it after the lock is released. We need to keep the lookup table mutex locked the entire time we're using the tables. Remove the locking from gpiod_find_lookup_table() and use guards to protect the code actually using the table objects. Signed-off-by:
-
Bartosz Golaszewski authored
We use size_t, ssize_t, bool and some other types defined in linux/types.h so include it in the driver. Signed-off-by: -
Linus Walleij authored
The "trigger-sources" phandle used for LED triggers are special: the DT bindings mandate that such triggers have the same phandle references no matter what the trigger is. A GPIO is just another kind of device that can trigger a LED. Signed-off-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Andy Shevchenko <andy@kernel.org> Signed-off-by:
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. 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 <u.kleine-koenig@pengutronix.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:
Shubhrajyoti Datta <shubhrajyoti.datta@amd.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 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:
Florian Fainelli <florian.fainelli@broadcom.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 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:
-
