summaryrefslogtreecommitdiff
path: root/drivers/gpio
AgeCommit message (Collapse)Author
2022-05-05Merge branch 'irq/gpio-immutable' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into devel
2022-05-05Merge branch 'irq/gpio-immutable' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into gpio/for-next This pulls in changes improving the handling of immutable irqchips in core gpiolib and several drivers.
2022-05-05gpio: max77620: Make the irqchip immutableJon Hunter
Commit 6c846d026d49 ("gpio: Don't fiddle with irqchips marked as immutable") added a warning to indicate if the gpiolib is altering the internals of irqchips. Following this change the following warning is now observed for the max77620 gpio driver ... WARNING KERN gpio gpiochip0: (max77620-gpio): not an immutable chip, please consider fixing it! Fix the above warning by making the max77620 gpio driver immutable. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-05-05gpio: pca953xx: Add support for pca6408Justin Chen
Add support for pca6408 which is the 8-bit version of the pca6416. https://www.nxp.com/docs/en/data-sheet/PCA6408A.pdf Signed-off-by: Justin Chen <justinpopo6@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-05-05gpio: visconti: Fix fwnode of GPIO IRQNobuhiro Iwamatsu
The fwnode of GPIO IRQ must be set to its own fwnode, not the fwnode of the parent IRQ. Therefore, this sets own fwnode instead of the parent IRQ fwnode to GPIO IRQ's. Fixes: 2ad74f40dacc ("gpio: visconti: Add Toshiba Visconti GPIO support") Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-05-05gpio: max732x: Drop unused support for irq and setup code via platform dataUwe Kleine-König
The only user of max732x_platform_data is arch/arm/mach-pxa/littleton.c and it only uses .gpio_base. So drop the other members from the data struct and simplify the driver accordingly. The motivating side effect of this change is that the .remove() callback cannot return a nonzero error code any more which prepares making i2c remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-05-04gpiolib: cdev: Add hardware timestamp clock typeDipen Patel
This patch adds new clock type for the GPIO controller which can timestamp gpio lines in using hardware means. To expose such functionalities to the userspace, code has been added where during line create or set config API calls, it checks for new clock type and if requested, calls HTE API. During line change event, the HTE subsystem pushes timestamp data to userspace through gpiolib-cdev. Signed-off-by: Dipen Patel <dipenp@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-05-04gpio: tegra186: Add HTE supportDipen Patel
Tegra194 AON GPIO controller with the use of its internal hardware timestamping engine (HTE), also known as GTE, can timestamp GPIO lines through system counter. This patch implements enable/disable callbacks for the GPIO controller. In enable call, it will set timestamp function bit and GPIO line rising/falling edges in the config register. In disable call, it restores the state. Signed-off-by: Dipen Patel <dipenp@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-05-04gpiolib: Add HTE supportDipen Patel
Some GPIO chip can provide hardware timestamp support on its GPIO lines , in order to support that, additional API needs to be added which can talk to both GPIO chip and HTE (hardware timestamping engine) providers if there is any dependencies. This patch introduces optional hooks to enable and disable hardware timestamping related features in the GPIO controller chip. Signed-off-by: Dipen Patel <dipenp@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-05-02gpio: vf610: drop the SOC_VF610 dependency for GPIO_VF610Peng Fan
i.MX7ULP, i.MX8 and i.MX9 use this driver, so drop the SOC_VF610 dependcy to make the driver could be built for i.MX platform. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-05-02Merge tag 'intel-gpio-v5.19-1' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-next intel-gpio for v5.19-1 * Introduce helpers to iterate over GPIO chip nodes and covert some drivers gpiolib: - Introduce a helper to get first GPIO controller node - Introduce gpiochip_node_count() helper - Introduce for_each_gpiochip_node() loop helper pinctrl: - meson: Replace custom code by gpiochip_node_count() call - meson: Enable COMPILE_TEST - meson: Rename REG_* to MESON_REG_* - armada-37xx: Reuse GPIO fwnode in armada_37xx_irqchip_register() - armada-37xx: Switch to use fwnode instead of of_node - samsung: Switch to use for_each_gpiochip_node() helper - samsung: Drop redundant node parameter in samsung_banks_of_node_get() - npcm7xx: Switch to use for_each_gpiochip_node() helper - renesas: rza1: Switch to use for_each_gpiochip_node() helper - renesas: rza1: Replace custom code by gpiochip_node_count() call - stm32: Switch to use for_each_gpiochip_node() helper - stm32: Replace custom code by gpiochip_node_count() call
2022-05-02gpio: mvebu: drop pwm base assignmentBaruch Siach
pwmchip_add() unconditionally assigns the base ID dynamically. Commit f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically") dropped all base assignment from drivers under drivers/pwm/. It missed this driver. Fix that. Fixes: f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically") Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-05-02gpiolib: of: fix bounds check for 'gpio-reserved-ranges'Andrei Lalaev
Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size" because it clears "size" bits starting from the "start" bit in the according bitmap. So it has to use "greater" instead of "greater or equal" when performs bounds check to make sure that GPIOs are in the available range. Previous implementation skipped ranges that include the last GPIO in the range. I wrote the mail to the maintainers (https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u) of the questioned DTSes (because I couldn't understand how the maintainers interpreted this property), but I haven't received a response. Since the questioned DTSes use "gpio-reserved-ranges = <0 4>" (i.e., the beginning of the range), this patch doesn't affect these DTSes at all. TBH this patch doesn't break any existing DTSes because none of them reserve gpios at the end of range. Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property") Signed-off-by: Andrei Lalaev <andrei.lalaev@emlid.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-05-02gpio: syscon: Remove usage of syscon_regmap_lookup_by_compatibleAlexander Shiyan
Since version 5.13, the standard syscon bindings have been added to all clps711x DT nodes, so we can now use the more general syscon_regmap_lookup_by_phandle function to get the syscon pointer. This patch removes the usage of the syscon_regmap_lookup_by_compatible function as it is no longer used in the driver. Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-05-01Merge tag 'v5.18-rc5' into develLinus Walleij
Merge in Linux 5.18-rc5 since new code to the STM32 driver depend in a non-trivial way on the fixes merged in -rc5. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-25gpio: pcf857x: Make teardown callback return voidUwe Kleine-König
All teardown functions return 0. Also there is little sense in returning a negative error code from an i2c remove function as this only results in emitting an error message but the device is removed nevertheless. This patch is a preparation for making i2c remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-25irq/gpio: ixp4xx: Drop boardfile probe pathLinus Walleij
The boardfiles for IXP4xx have been deleted. Delete all the quirks and code dealing with that boot path and rely solely on device tree boot. Fix some missing static keywords that the kernel test robot was complaining about while we're at it. Cc: Bartosz Golaszewski <brgl@bgdev.pl> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-25gpio: use raw spinlock for gpio chip shadowed dataSchspa Shi
In case of PREEMPT_RT, there is a raw_spinlock -> spinlock dependency as the lockdep report shows. __irq_set_handler irq_get_desc_buslock __irq_get_desc_lock raw_spin_lock_irqsave(&desc->lock, *flags); // raw spinlock get here __irq_do_set_handler mask_ack_irq dwapb_irq_ack spin_lock_irqsave(&gc->bgpio_lock, flags); // sleep able spinlock irq_put_desc_busunlock Replace with a raw lock to avoid BUGs. This lock is only used to access registers, and It's safe to replace with the raw lock without bad influence. [ 15.090359][ T1] ============================= [ 15.090365][ T1] [ BUG: Invalid wait context ] [ 15.090373][ T1] 5.10.59-rt52-00983-g186a6841c682-dirty #3 Not tainted [ 15.090386][ T1] ----------------------------- [ 15.090392][ T1] swapper/0/1 is trying to lock: [ 15.090402][ T1] 70ff00018507c188 (&gc->bgpio_lock){....}-{3:3}, at: _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090470][ T1] other info that might help us debug this: [ 15.090477][ T1] context-{5:5} [ 15.090485][ T1] 3 locks held by swapper/0/1: [ 15.090497][ T1] #0: c2ff0001816de1a0 (&dev->mutex){....}-{4:4}, at: __device_driver_lock+0x98/0x104 [ 15.090553][ T1] #1: ffff90001485b4b8 (irq_domain_mutex){+.+.}-{4:4}, at: irq_domain_associate+0xbc/0x6d4 [ 15.090606][ T1] #2: 4bff000185d7a8e0 (lock_class){....}-{2:2}, at: _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090654][ T1] stack backtrace: [ 15.090661][ T1] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.59-rt52-00983-g186a6841c682-dirty #3 [ 15.090682][ T1] Hardware name: Horizon Robotics Journey 5 DVB (DT) [ 15.090692][ T1] Call trace: ...... [ 15.090811][ T1] _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090828][ T1] dwapb_irq_ack+0xb4/0x300 [ 15.090846][ T1] __irq_do_set_handler+0x494/0xb2c [ 15.090864][ T1] __irq_set_handler+0x74/0x114 [ 15.090881][ T1] irq_set_chip_and_handler_name+0x44/0x58 [ 15.090900][ T1] gpiochip_irq_map+0x210/0x644 Signed-off-by: Schspa Shi <schspa@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Doug Berger <opendmb@gmail.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-22gpio: Request interrupts after IRQ is initializedMario Limonciello
Commit 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization") attempted to fix a race condition that lead to a NULL pointer, but in the process caused a regression for _AEI/_EVT declared GPIOs. This manifests in messages showing deferred probing while trying to allocate IRQs like so: amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x0000 to IRQ, err -517 amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x002C to IRQ, err -517 amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x003D to IRQ, err -517 [ .. more of the same .. ] The code for walking _AEI doesn't handle deferred probing and so this leads to non-functional GPIO interrupts. Fix this issue by moving the call to `acpi_gpiochip_request_interrupts` to occur after gc->irc.initialized is set. Fixes: 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization") Link: https://lore.kernel.org/linux-gpio/BL1PR12MB51577A77F000A008AA694675E2EF9@BL1PR12MB5157.namprd12.prod.outlook.com/ Link: https://bugzilla.suse.com/show_bug.cgi?id=1198697 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215850 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1979 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1976 Reported-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Shreeya Patel <shreeya.patel@collabora.com> Tested-By: Samuel Čavoj <samuel@cavoj.net> Tested-By: lukeluk498@gmail.com Link: Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-and-tested-by: Takashi Iwai <tiwai@suse.de> Cc: Shreeya Patel <shreeya.patel@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-04-22gpio/rockchip: handle deferring input-enable pinconfsCaleb Connolly
Add support for deferred PIN_CONFIG_INPUT_ENABLE handling. Signed-off-by: Caleb Connolly <kc@postmarketos.org> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220328005005.72492-4-kc@postmarketos.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-22pinctrl/rockchip: support deferring other gpio paramsCaleb Connolly
Add support for deferring other params like PIN_CONFIG_INPUT_ENABLE. This will be used to add support for PIN_CONFIG_INPUT_ENABLE to the driver. Fixes: e7165b1dff06 ("pinctrl/rockchip: add a queue for deferred pin output settings on probe") Fixes: 59dd178e1d7c ("gpio/rockchip: fetch deferred output settings on probe") Signed-off-by: Caleb Connolly <kc@postmarketos.org> Link: https://lore.kernel.org/r/20220328005005.72492-2-kc@postmarketos.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21gpiolib: of: Introduce hook for missing gpio-rangesStefan Wahren
Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") the device tree nodes of GPIO controller need the gpio-ranges property to handle gpio-hogs. Unfortunately it's impossible to guarantee that every new kernel is shipped with an updated device tree binary. In order to provide backward compatibility with those older DTB, we need a callback within of_gpiochip_add_pin_range() so the relevant platform driver can handle this case. Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-19Merge branch irq/gpio-immutable into irq/irqchip-nextMarc Zyngier
* irq/gpio-immutable: : . : First try at preventing the GPIO subsystem from abusing irq_chip : data structures. The general idea is to have an irq_chip flag : to tell the GPIO subsystem that these structures are immutable, : and to convert drivers one by one. : . Documentation: Update the recommended pattern for GPIO irqchips gpio: Update TODO to mention immutable irq_chip structures pinctrl: amd: Make the irqchip immutable pinctrl: msmgpio: Make the irqchip immutable pinctrl: apple-gpio: Make the irqchip immutable gpio: pl061: Make the irqchip immutable gpio: tegra186: Make the irqchip immutable gpio: Add helpers to ease the transition towards immutable irq_chip gpio: Expose the gpiochip_irq_re[ql]res helpers gpio: Don't fiddle with irqchips marked as immutable Signed-off-by: Marc Zyngier <maz@kernel.org>
2022-04-19gpio: Update TODO to mention immutable irq_chip structuresMarc Zyngier
5 drivers are converted, a few hundred to go. Definitely worth of a TODO entry, in the hope that someone will notice it and do a bulk update. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-10-maz@kernel.org
2022-04-19gpio: pl061: Make the irqchip immutableMarc Zyngier
Prevent gpiolib from messing with the irqchip by advertising the irq_chip structure as immutable, making it const, and adding the various calls that gpiolib relies upon. Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-6-maz@kernel.org
2022-04-19gpio: tegra186: Make the irqchip immutableMarc Zyngier
Prevent gpiolib from messing with the irqchip by advertising the irq_chip structure as immutable, making it const, and adding the various calls that gpiolib relies upon. Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-5-maz@kernel.org
2022-04-19gpio: Expose the gpiochip_irq_re[ql]res helpersMarc Zyngier
The GPIO subsystem has a couple of internal helpers to manage resources on behalf of the irqchip. Expose them so that GPIO drivers can use them directly. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-3-maz@kernel.org
2022-04-19gpio: Don't fiddle with irqchips marked as immutableMarc Zyngier
In order to move away from gpiolib messing with the internals of unsuspecting irqchips, add a flag by which irqchips advertise that they are not to be messed with, and do solemnly swear that they correctly call into the gpiolib helpers when required. Also nudge the users into converting their drivers to the new model. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-2-maz@kernel.org
2022-04-18gpio: ixp4xx: Detect special machines by compatibleLinus Walleij
There are some special clock amendments for two machines formerly detected by their machine_is() boardfile macro. They are now migrated to device tree so use of_machine_is_compatible() instead. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-16Merge tag 'intel-gpio-v5.18-2' of ↵Bartosz Golaszewski
gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-current intel-gpio for v5.18-2 * Couple of fixes related to handling unsigned value of the pin from ACPI gpiolib: - acpi: Convert type for pin to be unsigned - acpi: use correct format characters
2022-04-14gpio: sim: fix setting and getting multiple linesBartosz Golaszewski
We need to take mask into account in the set/get_multiple() callbacks. Use bitmap_replace() instead of bitmap_copy(). Fixes: cb8c474e79be ("gpio: sim: new testing module") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-04-11gpio: realtek-otto: Add RTL931x supportSander Vanheule
The RTL931x SoC series has support for 32 GPIOs, although not all lines may be broken out to a physical pad. The GPIO bank's parent interrupt can be routed to either or both of the SoC's CPU cores by the GIC. Line-by-line IRQ balancing is not possible on these SoCs. Signed-off-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-11gpio: realtek-otto: Add RTL930x supportSander Vanheule
The RTL930x SoC series has support for 24 GPIOs, with the port order reversed compared to RTL838x and RTL839x. The RTL930x series also has two CPUs (VPEs) and can distribute individual GPIO interrupts between them. Signed-off-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-11gpio: realtek-otto: Support per-cpu interruptsSander Vanheule
On SoCs with multiple cores, it is possible that the GPIO interrupt controller supports assigning specific pins to one or more cores. IRQ balancing can be performed on a line-by-line basis if the parent interrupt is routed to all available cores, which is the default upon initialisation. Signed-off-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-11gpio: realtek-otto: Support reversed port layoutsSander Vanheule
The GPIO port layout on the RTL930x SoC series is reversed compared to the RTL838x and RTL839x SoC series. Add new port offset calculator functions to ensure the correct order is used when reading port IRQ data, and ensure bgpio uses the right byte ordering. Signed-off-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-09gpiolib: Extract gpio_chip_get_value() wrapperAndy Shevchenko
In couple of cases we are using the same code to wrap ->get() callback. Extract that code into a helper for the sake of better maintenance. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-09gpiolib: Refactor gpiolib_dbg_show() with help of for_each_gpio_desc()Andy Shevchenko
Use for_each_gpio_desc() and since we would need to touch the entire conditionals, do the following: - rename last occurrence of gdesc to desc - use short ternary operator ?: - join two seq_printf() calls into single one - fix indentation of the seq_printf() parameters Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-09gpiolib: Split out for_each_gpio_desc() macroAndy Shevchenko
In some cases we want to traverse all GPIO descriptors for given chip, let's split out for_each_gpio_desc() macro for such cases. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-09gpiolib: Embed iterator variable into for_each_gpio_desc_with_flag()Andy Shevchenko
The iterator loop is used exclusively to get a descriptor, which in its turn is what is being used by the caller. Embed the iterator variable into the loop in the for_each_gpio_desc_with_flag() macro helper. Suggested-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-09gpiolib: Move error message out of a spinlockAndy Shevchenko
An error path is a slow path, no need to block other CPUs when printing error messages. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-08gpiolib: acpi: Convert type for pin to be unsignedAndy Shevchenko
A pin that comes from ACPI tables is of unsigned type. This also applies to the internal APIs which use unsigned int to store the pin. Convert type for pin to be unsigned in the places where it's not yet true. While at it, add a stub for acpi_get_and_request_gpiod() for the sake of consistency in the APIs. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-04-08gpiolib: acpi: use correct format charactersLinus Torvalds
When compiling with -Wformat, clang emits the following warning: gpiolib-acpi.c:393:4: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat] pin); ^~~ So warning that '%hhX' is paired with an 'int' is all just completely mindless and wrong. Sadly, I can see a different bogus warning reason why people would want to use '%02hhX'. Again, the *sane* thing from a human perspective is to use '%02X. But if the compiler doesn't do any range analysis at all, it could decide that "Oh, that print format could need up to 8 bytes of space in the result". Using '%02hhX' would cut that down to two. And since we use char ev_name[5]; and currently use "_%c%02hhX" as the format string, even a compiler that doesn't notice that "pin <= 255" test that guards this all will go "OK, that's at most 4 bytes and the final NUL termination, so it's fine". While a compiler - like gcc - that only sees that the original source of the 'pin' value is a 'unsigned short' array, and then doesn't take the "pin <= 255" into account, will warn like this: gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt': gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=] sprintf(ev_name, "_%c%02X", ^~~~ gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535] because gcc isn't being very good at that argument range analysis either. In other words, the original use of 'hhx' was bogus to begin with, and due to *another* compiler warning being bad, and we had that bad code being written back in 2016 to work around _that_ compiler warning (commit e40a3ae1f794: "gpio: acpi: work around false-positive -Wstring-overflow warning"). Sadly, two different bad compiler warnings together does not make for one good one. It just makes for even more pain. End result: I think the simplest and cleanest option is simply the proposed change which undoes that '%hhX' change for gcc, and replaces it with just using a slightly bigger stack allocation. It's not like a 5-byte allocation is in any way likely to have saved any actual stack, since all the other variables in that function are 'int' or bigger. False-positive compiler warnings really do make people write worse code, and that's a problem. But on a scale of bad code, I feel that extending the buffer trivially is better than adding a pointless cast that literally makes no sense. At least in this case the end result isn't unreadable or buggy. We've had several cases of bad compiler warnings that caused changes that were actually horrendously wrong. Fixes: e40a3ae1f794 ("gpio: acpi: work around false-positive -Wstring-overflow warning") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2022-04-05gpio: rcar: Add R-Car Gen4 supportGeert Uytterhoeven
R-Car V3U (R8A779A0) was the first member of the R-Car Gen4 family. Generalize the support for R-Car V3U to other SoCs in the R-Car Gen4 family by adding a family-specific compatible value. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-05gpiolib: Get rid of redundant 'else'Andy Shevchenko
In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. In case of IOCTLs use switch-case pattern that seems the usual in such cases. While at it, clarify necessity of else in gpiod_direction_output() by attaching else if to the closing curly brace on a previous line. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-04gpio: Restrict usage of GPIO chip irq members before initializationShreeya Patel
GPIO chip irq members are exposed before they could be completely initialized and this leads to race conditions. One such issue was observed for the gc->irq.domain variable which was accessed through the I2C interface in gpiochip_to_irq() before it could be initialized by gpiochip_add_irqchip(). This resulted in Kernel NULL pointer dereference. Following are the logs for reference :- kernel: Call Trace: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 To avoid such scenarios, restrict usage of GPIO chip irq members before they are completely initialized. Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-04-01Merge tag 'gpio-fixes-for-v5.18-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - grammar and formatting fixes in comments for gpio-ts4900 - correct links in gpio-ts5500 - fix a warning in doc generation for the core GPIO documentation * tag 'gpio-fixes-for-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: ts5500: Fix Links to Technologic Systems web resources gpio: Properly document parent data union gpio: ts4900: Fix comment formatting and grammar
2022-03-31gpio: ts5500: Fix Links to Technologic Systems web resourcesKris Bahnsen
Technologic Systems has rebranded as embeddedTS with the current domain eventually going offline. Update web/doc URLs to correct resource locations. Signed-off-by: Kris Bahnsen <kris@embeddedTS.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-03-31gpio: ts4900: Fix comment formatting and grammarKris Bahnsen
The issues were pointed out after the prior commit was applied. Signed-off-by: Kris Bahnsen <kris@embeddedTS.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-03-28Merge tag 'char-misc-5.18-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc and other driver updates from Greg KH: "Here is the big set of char/misc and other small driver subsystem updates for 5.18-rc1. Included in here are merges from driver subsystems which contain: - iio driver updates and new drivers - fsi driver updates - fpga driver updates - habanalabs driver updates and support for new hardware - soundwire driver updates and new drivers - phy driver updates and new drivers - coresight driver updates - icc driver updates Individual changes include: - mei driver updates - interconnect driver updates - new PECI driver subsystem added - vmci driver updates - lots of tiny misc/char driver updates All of these have been in linux-next for a while with no reported problems" * tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (556 commits) firmware: google: Properly state IOMEM dependency kgdbts: fix return value of __setup handler firmware: sysfb: fix platform-device leak in error path firmware: stratix10-svc: add missing callback parameter on RSU arm64: dts: qcom: add non-secure domain property to fastrpc nodes misc: fastrpc: Add dma handle implementation misc: fastrpc: Add fdlist implementation misc: fastrpc: Add helper function to get list and page misc: fastrpc: Add support to secure memory map dt-bindings: misc: add fastrpc domain vmid property misc: fastrpc: check before loading process to the DSP misc: fastrpc: add secure domain support dt-bindings: misc: add property to support non-secure DSP misc: fastrpc: Add support to get DSP capabilities misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP misc: fastrpc: separate fastrpc device from channel context dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells dt-bindings: nvmem: make "reg" property optional nvmem: brcm_nvram: parse NVRAM content into NVMEM cells nvmem: dt-bindings: Fix the error of dt-bindings check ...
2022-03-25Merge tag 'gpio-updates-for-v5.18' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski: "Relatively few updates for this release cycle. We have a single new driver and some minor changes in drivers, more work on limiting the usage of of_node in drivers and DT updates: - new driver: gpio-en7523 - dt-bindings: convertion of faraday,ftgpio010 to YAML, new compatible string in gpio-vf610 and a bugfix in an example - gpiolib core: several improvements and some code shrink - documentation: convert all public docs into kerneldoc format - set IRQ bus token in gpio-crystalcove (addresses a debugfs issue) - add a missing return value check for kstrdup() in gpio-merrifield - allow gpio-tps68470 to be built as module - more work on limiting usage of of_node in GPIO drivers - several sysfs interface improvements - use SDPX in gpio-ts4900" * tag 'gpio-updates-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: ts4900: Use SPDX header gpiolib: Use list_first_entry()/list_last_entry() gpiolib: sysfs: Simplify edge handling in the code gpiolib: sysfs: Move kstrtox() calls outside of the mutex lock gpiolib: sysfs: Move sysfs_emit() calls outside of the mutex lock gpiolib: make struct comments into real kernel docs dt-bindings: gpio: convert faraday,ftgpio01 to yaml dt-bindings: gpio: gpio-vf610: Add imx93 compatible string gpiolib: Simplify error path in gpiod_get_index() when requesting GPIO gpiolib: Use short form of ternary operator in gpiod_get_index() gpiolib: Introduce for_each_gpio_desc_with_flag() macro gpio: Add support for Airoha EN7523 GPIO controller dt-bindings: arm: airoha: Add binding for Airoha GPIO controller dt-bindings: gpio: fix gpio-hog example gpio: tps68470: Allow building as module gpio: tegra: Get rid of duplicate of_node assignment gpio: altera-a10sr: Switch to use fwnode instead of of_node gpio: merrifield: check the return value of devm_kstrdup() gpio: crystalcove: Set IRQ domain bus token to DOMAIN_BUS_WIRED
generated by cgit v1.2.3 (git 2.46.0) at 2025-07-29 07:22:01 +0000