| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
# Conflicts:
# drivers/gpio/gpiolib-kunit.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
# Conflicts:
# drivers/gpio/gpiolib-acpi-quirks.c
|
|
No more users.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260715185112.1323510-8-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
gpiod_request_commit() sets GPIOD_FLAG_REQUESTED, calls ->request() and
only then sets the label. A line in between has no label, so
gpiochip_dup_line_label() passes NULL to kstrdup() and returns
ERR_PTR(-ENOMEM), which for_each_hwgpio() then passes to kfree():
BUG: unable to handle page fault for address: ffcc73074355ffc8
Call Trace:
gpio_sim_dbg_show
gpiolib_seq_show
seq_read_iter
Return NULL for such a line, as for an unrequested one.
Reproduced with gpio-sim: reading /sys/kernel/debug/gpio in a loop while
lines are requested and released oopses within seconds; with this
change, 100000 cycles pass.
Fixes: 35b545332b80 ("gpio: remove gpio_lock")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20261020-gpiolib-chip-removal-v3-0-aambrozewicz@nvidia.com?part=2
Assisted-by: LLM
Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
Link: https://patch.msgid.link/20261022083343.3905973-3-aambrozewicz@nvidia.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio updates from Bartosz Golaszewski:
"Nothing stands out as particularly interesting, it's been a calm
cycle. We have three new drivers, support for more models and lots of
updates across many modules (details are in the signed tag as usual).
There are also some minor changes and additions to the in-kernel GPIO
API.
GPIO core:
- provide a new controller API: gpiochip_generic_get_config()
- return -EOPNOTSUPP instead of -ENODEV to user-space if it requests
hardware timestamping on systems where it's unavailable (no
user-space regressions reported)
New drivers:
- add a driver for ROHM BD73800 PMIC GPIO controller
- add a driver for Axiado AX3005 SGPIO controller
- add a driver for Analog Devices AD7768 GPIO controller
New hardware support:
- extend gpio-rcar with support for R-Car X5H (R8A78000)
- extend gpio-tegra186 with support for Tegra 268
Driver changes:
- refactor and improve gpio-rtd1625: switch to modern or better
fitting interfaces and improve coding style
- improve error handling of return values of
platform_get_irq_optional() in several drivers
- normalize the return value of the gpio_chip::get() callback in
gpio-siox in order to not propagate invalid values up to the GPIO
core
- implement gpio_chip::get_direction() for gpio-pcf857x
- use managed variants of notifier registration functions in several
drivers
- remove legacy gpio_set_value_cansleep() as it has no more users
- add pinctrl support to gpio-realtek-otto
- add runtime PM support to the gpio-regmap helper module
- add more ACPI GPIO quirks for various hardware
- stop needlessly reading gpio_chip::base in gpio-pxa
- add support for tracking of direction of generic GPIO chips with no
direction registers via pinctrl backend to gpio-mmio (use the new
core API: gpiochip_generic_get_config())
- use the "safe" variants of debugfs_create_file() in
gpio-sloppy-analyzer
- use device name as GPIO chip label in gpio-omap
- refactor bit ops in gpio-dln2
- prepare gpio-it87 for upcoming kmalloc_obj() conversion
Devicetree bindings:
- document new model in gpio-pca95xx
- allow the gpio-hogs property in gpio-zynq and fsl,qoriq-gpio
- allow the gpio-ranges property in gpio-realtek-otto
Misc fixes:
- add missing MODULE_ALIAS() to gpio-crystalcove
- fix a comment typo in example GPIO tools
- fix unbalanced brackets in documentation
- add names to regmaps in gpio-mvebu to avoid collisions in debugfs
output
- fix GPIO lookup using relative paths in GPIO ACPI"
* tag 'gpio-updates-for-v7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (63 commits)
gpiolib: acpi: Fix GPIO lookup using relative path
gpio: legacy: Kill gpio_set_value_cansleep()
dt-bindings: gpio: pca95xx: add onnn,pca9655 with nxp,pca9555 fallback
gpiolib: acpi: Ignore GPIO 11 interrupt on Acer Nitro V 16S AI
gpio: pxa: stop reading gpio_chip::base in direction callbacks
gpio: axiado: add AX3005 SGPIO controller support
dt-bindings: gpio: add Axiado AX3005 SGPIO controller
gpiolib: acpi: Add quirk for Lenovo IdeaPad Slim 3 15ABR8
MAINTAINERS: Add ROHM BD73800 PMIC files
gpio: bd73800: Support ROHM BD73800 PMIC GPIOs
clk: bd718x7: Support ROHM BD73800
regulator: bd71828: Support ROHM BD73800
rtc: bd70528: Support RTC on ROHM BD73800
mfd: Support for ROHM BD73800 PMIC core
dt-bindings: mfd: ROHM BD73800 PMIC
dt-bindings: regulator: ROHM BD73800 regulators
dt-bindings: rohm,bd*: Ref common ROHM bindings
dt-bindings: mfd: Common ROHM PMIC properties
gpio: siox: normalize return value of gpio_get()
gpio: dln2: use assign_bit() where applicable
...
|
|
gpiod_set_array_value_complex() ignores errors from the open-drain and
open-source emulation helpers. If a direction change fails,
GPIO_V2_LINE_SET_VALUES_IOCTL still reports success, including when
updating a single line.
Return the first emulation error after freeing the temporary bitmaps.
Keep updates already made to earlier lines and stop processing the
remaining lines, as for errors from gpiochip_set_multiple().
Fixes: 8ce258f62f90 ("gpiolib: make value setters have return values")
Signed-off-by:
Link: https://patch.msgid.link/20261020172601.221861-1-pocj8ur4in@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Add a driver for the GPIO controller embedded in the Toshiba TC9563 PCIe
switch (and the Qualcomm QPS615). The device implements 37 GPIOs using two
register banks: three registers control the first 32 GPIOs and three more
control GPIOs 32-36. GPIOs 20 and 21 are reserved while GPIOs 22-24,
27-28, 31, and 34 are input-only.
Register the driver as an auxiliary device driver. The TC9563 power
controller creates the auxiliary device and provides a regmap that gives
access to the GPIO registers, so use the gpio-regmap helpers to implement
the GPIO chip.
Signed-off-by: Alex Elder <elder@riscstar.com>
Co-developed-by: Daniel Thompson <daniel@riscstar.com>
Signed-off-by: Daniel Thompson <daniel@riscstar.com>
Co-developed-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
[bhelgaas: commit log per https://lore.kernel.org/arQ2mDjqHv4gmoOK@lore-desk]
[bhelgaas: squash Geert Uytterhoeven <geert+renesas@glider.be> Kconfig fix:
https://lore.kernel.org/all/45484c37512a3102495d8b75b6e9f72a141ba42e.1792574560.git.geert+renesas@glider.be,
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260909-pci-tc9563-aux-v5-2-c9b33f56c8d3@oss.qualcomm.com
|
|
In preparation for the constification of configfs attributes, make the
existing instances of struct configfs_attribute in gpio-sim const and
use the new st_attrs_const field of struct config_item_type.
Suggested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Closes: https://lore.kernel.org/all/20261016105712-707634de-c955-4c66-957a-2bdb84bca3e4@linutronix.de/
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20261020-gpio-sim-const-configfs-attrs-v2-1-ca4b79d2624d@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Three IRQ paths ignore the result of reading the direction registers
and then use the destination bitmap. pca953x_read_regs() does not populate
that bitmap when regmap_bulk_read() fails, leaving the callers to use
uninitialized stack data.
This can select incorrect GPIOs for direction changes during IRQ bus
synchronization, corrupt the saved input state during IRQ setup, or
produce incorrect pending interrupt decisions.
Check the read result at all three sites. Release irq_lock without
changing GPIO directions on failure, leave the IRQ history untouched
when pending detection fails, and propagate the error from IRQ setup.
The read helper already logs the error.
Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache")
Cc: stable@vger.kernel.org
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
Link: https://patch.msgid.link/20261018165003.3372368-1-sahaj123.sc@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
pca953x_irq_set_wake() updates wakeup_path before asking the parent
IRQ controller to change its wake state. If irq_set_irq_wake() fails,
the IRQ core rolls back its wake state but the driver's counter remains
changed.
A failed enable can therefore leave the expander marked as part of the
wakeup path when no child IRQ has successfully enabled wakeup. A failed
disable can make the driver stop retaining power even though wakeup is
still enabled. The suspend and resume paths use this counter to decide
whether to disable or enable the regulator.
Update wakeup_path only after the parent operation succeeds, leaving it
unchanged on error.
Fixes: f70fbc15bae2 ("gpio: pca953x: Configure wake-up path when wake-up is enabled")
Cc: stable@vger.kernel.org
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
Fixes: f70fbc15bae2c89f ("gpio: pca953x: Configure wake-up path when wake-up is enabled")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20261018161042.3298045-1-sahaj123.sc@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
davinci_gpio_save_context() saves the registers of each 32-GPIO
register bank, but clears interrupt status only after the loop. At that
point g refers to the last bank, so pending status in all preceding
banks is left uncleared.
Move the interrupt-status write into the per-bank loop so that the
existing suspend-time clearing covers every register bank. Single-bank
controllers retain the same behavior.
Fixes: 0651a730924b ("gpio: davinci: Add support for system suspend/resume PM")
Cc: stable@vger.kernel.org
Signed-off-by: Sahaj Chaudhari <sahaj123.sc@gmail.com>
Link: https://patch.msgid.link/20261018170622.3406158-1-sahaj123.sc@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
If desc_set_label() fails after the chip's request callback succeeds,
gpiod_request_commit() clears GPIOD_FLAG_REQUESTED without calling the
free callback. The caller receives an error and has no GPIO to release,
leaving resources acquired by the request callback held.
Call the chip's free callback, if present, before clearing the requested
bit on label allocation failure. Leave request callback errors on the
existing path to avoid freeing a failed request.
Cc: stable@vger.kernel.org
Fixes: 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU")
Signed-off-by: Baek Kyu, Kim <pocj8ur4in@gmail.com>
Link: https://patch.msgid.link/20261018044456.1259250-1-pocj8ur4in@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Since commit 92ac7de3175e ("gpiolib: don't allow setting values on input
lines"), direction checking is performed by gpiolib core code.
As part of that patch, the now redundant check was removed from uAPI v2
linereq_set_values(), but the corresponding check in uAPI v1 linehandle
set values was left. Remove it.
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Link: https://patch.msgid.link/20261020080646.45985-1-warthog618@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Use the const variant of constainer_of() to access struct
gpio_sim_attribute which wraps the dynamically allocated sysfs
attributes for value and pull of simulated GPIO lines in line with the
currently preferred approach.
Co-developed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20261019-gpio-sim-const-sysfs-attr-v2-1-9ae103b8a680@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Add a kunit test-case for retrieving GPIOs using platform lookup tables.
Link: https://patch.msgid.link/20261013-gpio-kunit-plat-lookup-v3-4-3907f913e964@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Ahead of reusing the existing code in machine lookup test cases, rename
the swnode consumer variables and functions to a more generic "test
consumer".
Link: https://patch.msgid.link/20261013-gpio-kunit-plat-lookup-v3-3-3907f913e964@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
We repeat the same sequence of function calls when waiting synchronously
for a device to probe. Put them into a dedicated helper function and
shrink the test-case code in the process.
Link: https://patch.msgid.link/20261013-gpio-kunit-plat-lookup-v3-2-3907f913e964@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The label of the test GPIO provider is currently set to the consumer
name. Use the provider name instead.
Link: https://patch.msgid.link/20261013-gpio-kunit-plat-lookup-v3-1-3907f913e964@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Some pins can be reconfigured from the BIOS as alternate functions,
which makes the corresponding GPIO lines unusable. Add the
init_valid_mask() operation to mark as valid only the GPIOs which are
usable.
Signed-off-by: Thomas Richard (congatec GmbH) <thomas.richard@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20261016-cgbc-gpio-valid-mask-v1-1-938202276e26@bootlin.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull file table updates from Christian Brauner:
"This annotates struct fdtable's fd array with __counted_by_ptr so
KASAN and the fortified functions can bounds check it against max_fds
and adds a KUnit suite for fdtable. A follow-up uses __struct_size()
in the test since sparse doesn't know __builtin_dynamic_object_size().
FD_PREPARE() is simplified. It was built as an ACQUIRE-style guard on
infrastructure that was never needed. The ACQUIRE machinery and
CLASS_INIT() go away, the variable is declared with __cleanup()
directly, struct fd_prepare loses its err field since the fd either
holds the descriptor or the error, and callers get a const pointer to
the guard behind a UNIQUE_ID() name so they can't shadow it. Code
generation is identical"
* tag 'vfs-7.4-rc1.file' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
file: make struct fd_prepare const and kill its err field
cleanup: remove CLASS_INIT()
file: declare the FD_PREPARE() variable with __cleanup() directly
file: simplify FD_PREPARE()
vfs: use __struct_size() in the fdtable KUnit test
vfs: Add KUnit tests for fdtable
vfs: Annotate struct fdtable's fd field with __counted_by_ptr
|
|
When a line is requested or reconfigured through the v2 uAPI,
gpio_v2_line_config_flags_to_desc_flags() copies the requested
configuration into the descriptor flags, GPIOD_FLAG_IS_OUT included,
before gpiod_direction_input_nonotify() or
gpiod_direction_output_nonotify() asks the driver for the direction.
If the driver refuses, for instance with -EOPNOTSUPP from
.direction_input() for a line that can only be an output, the ioctl
fails but the flag keeps the refused direction. gpiod_free_commit()
does not touch GPIOD_FLAG_IS_OUT, so this outlives the failed request,
and GPIO_V2_GET_LINEINFO_IOCTL reports the line as an input while the
hardware still drives it, until a request without direction flags
makes gpiod_request_commit() read the direction back from the driver:
GPIO_V2_GET_LINE_IOCTL, line 0, input: -EOPNOTSUPP
GPIO_V2_GET_LINEINFO_IOCTL, line 0: input
GPIO_V2_GET_LINE_IOCTL, line 0, no direction: ok
GPIO_V2_GET_LINEINFO_IOCTL, line 0: output
GPIO_V2_LINE_SET_CONFIG_IOCTL updates the flags in the same order.
There the line stays requested, and since commit 92ac7de3175e
("gpiolib: don't allow setting values on input lines")
GPIO_V2_LINE_SET_VALUES_IOCTL on it then fails with -EPERM, though the
line is still an output. A line whose driver refuses to make it an
output is likewise reported as one.
gpiod_direction_input_nonotify() and gpiod_direction_output_nonotify()
set or clear GPIOD_FLAG_IS_OUT themselves once the driver has accepted
the direction, emulated open drain and open source included, and
nothing between the copy and those calls reads the flag. Leave it to
them, as the v1 uAPI already does.
The other flags that the helper copies stay as they are. Active low,
drive and bias are what gpiod_direction_*() applies, drive and bias
possibly before the driver refuses the direction; edges and event
clock are the character device's own. None of them is read back from
the driver, so there is no earlier state that is more accurate to go
back to. A failed request releases the line, which clears them, and a
failed reconfiguration leaves the line, like the lines before it, with
what was applied up to the failure.
Reproduced under QEMU with a test GPIO chip whose line 0 refuses input
and line 1 refuses output: both refused requests and both refused
reconfigurations leave the line info with the refused direction, and
setting the value of the reconfigured output fails with -EPERM. With
this change the line info shows the direction of the hardware in all
four cases and setting the value works. First seen on real hardware
with v6.12.
Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
Reviewed-by: Kent Gibson <warthog618@gmail.com>
Link: https://patch.msgid.link/20261016-gpiolib-cdev-direction-v2-1-aambrozewicz@nvidia.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
gpiod_free_commit() clears the flags that a request sets on a line, but
not GPIOD_FLAG_EVENT_CLOCK_REALTIME and GPIOD_FLAG_EVENT_CLOCK_HTE,
which gpio_v2_line_config_flags_to_desc_flags() sets from the uAPI v2
line config. Once a line requested with
GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME or
GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE is released, GPIO_V2_GET_LINEINFO_IOCTL
and the line info changed events, the "released" one included, keep
reporting that event clock for the free line:
GPIO_V2_GET_LINE_IOCTL, line 1, input, event clock realtime: ok
close()
GPIO_V2_GET_LINEINFO_IOCTL, line 1: input, event clock realtime
The flags are set before edge detection is set up, so a request that
fails in hte_ts_get(), for instance because no HTE provider handles the
line, leaves GPIOD_FLAG_EVENT_CLOCK_HTE behind as well. The next uAPI v2
request rewrites both flags, but requests through uAPI v1, sysfs exports
and in-kernel consumers do not, and the line info then shows the event
clock of an earlier user for them too.
Clear both flags together with the other flags of the request.
Reproduced under QEMU with a test GPIO chip: after a released request
with the realtime event clock, and on a kernel with CONFIG_HTE=y but no
HTE provider after a failed request with the HTE event clock, the line
info of the free line still reports that event clock. With this change
it reports none.
Fixes: 26d060e47e25 ("gpiolib: cdev: allow edge event timestamps to be configured as REALTIME")
Fixes: 2068339a6c35 ("gpiolib: cdev: Add hardware timestamp clock type")
Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
Link: https://patch.msgid.link/20261012-gpiolib-event-clock-v1-1-aambrozewicz@nvidia.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
A drive-by review by Sashiko reports that, where the line has not been
configured as an output, gpiod_set_array_value_complex() can return
without freeing potentially alloced bitmaps, thus leaking memory.
Cleanup the bitmaps before returning.
Fixes: 92ac7de3175e ("gpiolib: don't allow setting values on input lines")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://lore.kernel.org/linux-gpio/sashiko-outbox-168233@kernel.org/
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Link: https://patch.msgid.link/20261016105442.109836-1-warthog618@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The Acer Nitro 16S AI (AN16S-61) has the same problem as the Acer Nitro
V 16S AI: the firmware powers the internal USB camera (0408:4059)
through GPIO 11 of AMDI0030, but also lists that pin in _AEI. Requesting
it as an input cuts the power, so the camera never enumerates. On this
model the same rail also powers the internal microphones, so they do
not work either.
Booting with gpiolib_acpi.ignore_interrupt=AMDI0030:00@11 fixes both
the camera and the microphones. Add a DMI quirk for this family too.
Tested-by: Trijan Koju <trijankoju11@gmail.com>
Assisted-by: LLM
Signed-off-by: Abduvaliy Abdulazizov <abduvaliy.hbai@gmail.com>
Acked-by: Mika Westerberg <westeri@kernel.org>
Link: https://patch.msgid.link/20261007120944.1705014-1-abduvaliy.hbai@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
lpc32xx_gpio_probe() registers each gpio chip with
devm_gpiochip_add_data() but ignores the return value. If registering
a chip fails, probe still returns 0, so the driver binds with a chip
missing and no error is reported.
Check the return value, print an error naming the failing chip and
return the error code. Chips registered earlier in the loop are devm
managed and are removed automatically on failure.
Signed-off-by: Jayaraj Devaraj <jayarajdmit@gmail.com>
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Link: https://patch.msgid.link/20261016154209.23193-1-jayarajdmit@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The ThinkPad L13 Gen 2a firmware declares GPIO 11 as an edge-triggered
interrupt in _AEI, but the EC uses the same GPIO as an output to drive the
Caps Lock LED.
When gpiolib registers the ACPI event, the pin is configured as an input and
firmware writes can no longer control the LED.
Add a DMI quirk to ignore the erroneous interrupt declaration automatically.
Cc: Mark Pearson <mpearson-lenovo@squebb.ca>
Reported-by: Nikodem Sanecki <nikodemsanecki@gmail.com>
Closes: https://lore.kernel.org/linux-gpio/CAAUQFRPW-rbcZV-=qV1NMjF_358sdJTiGvQuRxRqAsehY+J9Qg@mail.gmail.com/
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20261015193924.4081906-1-mario.limonciello@amd.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-next
intel-gpio for v7.3-1
* Support relative path to the GPIO controller in the resources
* Add missing MODULE_ALIAS() to make crystalcove driver autoload
* Ignore interrupts on IdeaPad Slim 3 15ABR8 and Acer Nitro V 16S AI
|
|
devm_gpiochip_add_data() makes the GPIO chip visible to consumers
immediately. Since the chip sets .to_irq = mxc_gpio_to_irq, which calls
irq_find_mapping(port->domain, offset), any to_irq() call between
gpiochip registration and IRQ domain creation will operate on a NULL
domain.
Fix by moving devm_gpiochip_add_data() after the IRQ domain and generic
irq chip are fully initialized, ensuring port->domain and the irq chip
handlers are ready before the chip becomes visible to consumers.
Fixes: d37a65bb4663 ("gpio/mxc: Move Freescale MXC gpio driver to drivers/gpio")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-4-c4d769587d3e@nxp.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
gpio_set_wake_irq() can be called concurrently for different pins on
the same port. The writer-vs-writer race is the concern: two concurrent
gpio_set_wake_irq() calls for different pins on the same port both do
a non-atomic read-modify-write on the same wakeup_pads word. The old
|= and &= compile to separate load/modify/store instructions that can
interleave, losing one CPU's update.
assign_bit() uses an atomic RMW instruction, so concurrent writers to
different bits in the same word are safe.
The reader side (for_each_set_bit in noirq_suspend, wakeup_pads > 0)
runs in noirq context where no concurrent writer can execute, so
reader atomicity is not needed.
wakeup_pads is a u32, while assign_bit() operates on unsigned long
pointers. On 64-bit platforms, this causes an 8-byte read-modify-write
on a 4-byte field, corrupting the adjacent is_pad_wakeup. So change
wakeup_pads to unsigned long and reorder to avoid wasting words.
And fix the enable/disable path unconditionally sets/clears the
wakeup_pads bit even when enable_irq_wake()/disable_irq_wake() fails.
Only update the bit on success.
Fixes: f60c9eac54af ("gpio: mxc: enable pad wakeup on i.MX8x platforms")
Assisted-by: LLM
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-3-c4d769587d3e@nxp.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
gpio_set_irq_type() can be called concurrently for different pins on
the same port. The IRQ core serializes per irq descriptor, but
different pins have different descriptors, so on SMP systems two
concurrent gpio_set_irq_type() calls for pins on the same port run
without mutual exclusion.
The read-modify-write of port->both_edges is performed outside the
port-wide scoped_guard(gpio_generic_lock_irqsave) section, so
concurrent updates for different pins can overwrite each other,
causing missed interrupts or stuck IRQ lines on dual-edge triggered
pins.
The original uniprocessor MXC SoCs were not affected; the race
became reachable on multi-core i.MX7 and i.MX8 SoCs that reuse this
driver.
Convert both_edges from u32 to unsigned long and use set_bit(),
clear_bit(), and test_bit() to make the modifications atomic.
Fixes: 910862ec092c ("mxc: emulate GPIO interrupt on both-edges")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-2-c4d769587d3e@nxp.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
mxc_update_irq_chained_handler() is called before the IRQ domain, the
generic IRQ chip, and the port list entry are set up. If an interrupt
arrives in that window:
- mx3_gpio_irq_handler() calls generic_handle_domain_irq() with
port->domain still NULL.
- mx2_gpio_irq_handler() walks mxc_gpio_ports, but the port has not
been added to the list yet.
Additionally, if any of the subsequent probe steps
(gpio_generic_chip_init(), devm_gpiochip_add_data(),
irq_domain_create_legacy(), or mxc_gpio_init_gc()) fail, the error
paths never unregister the chained handler, leaving a dangling handler
that points at freed memory.
Move the handler installation after all its dependencies are ready and
after list_add_tail(), so the handler is never live while the data
structures it touches are incomplete, and is never installed if probe
fails.
Fixes: 5f6d1998adeb ("gpio: mxc: release the parent IRQ in runtime suspend")
Assisted-by: LLM
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20261013-gpio-mxc-cleanup-v7-1-c4d769587d3e@nxp.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
A drive-by review by Sashiko reports that, after a failed call to
gpiochip_set_multiple(), gpiod_set_array_value() returns abruptly,
bypassing the freeing of possibly alloced bitmaps, potentially leaking
memory. It is an unlikely error path, but is possible.
Defer the return code check until after the bitmap_free() block.
Fixes: 9b407312755f ("gpiolib: rework the wrapper around gpio_chip::set_multiple()")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://lore.kernel.org/linux-gpio/sashiko-outbox-168233@kernel.org/
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Link: https://patch.msgid.link/20261015025749.47039-1-warthog618@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
KUnit aborts the test thread immediately using kthread_exit() so the
variable annotated with __free() never really goes out of scope and the
associated callback is not called. Schedule a kunit action instead.
Fixes: a05cfd98c5ec ("gpio: kunit: add test cases for software node hogs")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20261013-gpio-kunit-plat-lookup-v3-0-3907f913e964%40oss.qualcomm.com?part=1
Link: https://patch.msgid.link/20261014-gpio-kunit-autofree-leak-fix-v1-1-5bfa7be0eb1f@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
We use platform lookup tables for shared GPIOs. This mechanism needs a
struct device to work so fwnode-based lookup with no device associated
currently causes a NULL-pointer deference.
Adding this functionality will require a larger rework and it has never
worked anyway so add a check that allows the kernel to gracefully handle
this situation with an error ahead of implementing that functionality as
a new feature.
Cc: stable@vger.kernel.org
Reported-by: Abel Vesa <abelvesa@kernel.org>
Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")
Link: https://patch.msgid.link/20261014-gpio-shared-fwnode-lookup-v4-2-2253ad645fd6@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The GPIO lookup table can stay alive for longer than the kobject whose
name string's address we're assigning to lookup->dev_id. Fix a potential
UAF by duplicating the string.
Cc: stable@vger.kernel.org
Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20261014-gpio-shared-fwnode-lookup-v4-1-2253ad645fd6@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
ACPI allow to use relative path in resources, pass the device handle
to acpi_get_gpiod() to allow resolving such path.
Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
Acked-by: Mika Westerberg <westeri@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
The GPIO callbacks take a mutex and issue USB transfers, so this GPIO
chip must not be used in atomic context. Change the can_sleep switch in
struct gpio_chip to true.
Fixes: 611a995e8ae1 ("gpio: Add Nuvoton NCT6694 GPIO support")
Signed-off-by: Ming Yu <a0282524688@gmail.com>
Link: https://patch.msgid.link/20261007092102.3768818-2-a0282524688@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
On the Acer Nitro V 16S AI (ANV16S-41) the internal USB camera
(0408:4035) works on Windows but never shows up on Linux.
The firmware drives GPIO 11 of AMDI0030 high to power the camera. The
same pin is listed in \_SB.GPIO._AEI as an edge-triggered, active-low
wake interrupt whose _EVT case only writes a debug code. gpiolib-acpi
requests _AEI pins as inputs, which clears the output enable bit, so
the camera loses power during boot.
After boot the pin register reads 0x00447a00 (output value 1, output
enable 0, line low). With the xHCI controller kept away from Linux
(pci-stub), the camera port shows CSC=1, CCS=0: the camera was
connected during boot and then dropped off.
Booting with gpiolib_acpi.ignore_interrupt=AMDI0030:00@11 keeps the
camera powered; it enumerates and works with uvcvideo. Add a DMI quirk
so this works out of the box, like the existing one for the Acer
Nitro V 14 on the same pin.
Closes: https://lore.kernel.org/linux-usb/CAPGafdkBb49YFV+d0rYjbi4QjifCUr1Wos6C5TZtDQzN6-pn+g@mail.gmail.com/
Assisted-by: LLM
Signed-off-by: Abduvaliy Abdulazizov <abduvaliy.hbai@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
gpio_mpsse_irq_enable() arms the poll worker before publishing it:
schedule_work() runs before the worker is added to priv->workers. If
gpio_mpsse_disconnect() walks the list in that window it misses the
worker, and once disconnect returns, the USB core frees mpsse_priv
while the orphaned gpio_mpsse_poll() work keeps accessing it, causing
a use-after-free.
Fix this by publishing and arming the worker in one irq_spin
critical section. Teardown walks the same list under irq_spin, so a
worker found on the list is guaranteed to be armed, and
cancel_work_sync() handles it whether it is queued or running.
A worker armed after the disconnect walk would still be missed, so
also set a new priv->dying flag under irq_spin before the teardown
walk, and check it in the same critical section, freeing it via
kfree_rcu() instead when the device is going away, since kfree()
would be called with the IRQ core's raw spinlock held and may sleep
on PREEMPT_RT. schedule_work() is safe to call with irq_spin held,
and the next probe gets a fresh mpsse_priv, so the flag never needs
to be cleared.
This issue was found by an in-house static analysis tool.
Fixes: 179ef1127d7a ("gpio: mpsse: ensure worker is torn down")
Cc: stable@vger.kernel.org
Co-developed-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Link: https://patch.msgid.link/20260929093646.18419-1-fanwu01@zju.edu.cn
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
devm_add_action_or_reset() invokes the cleanup action immediately when
registering the action fails. gpio_exar_probe() currently stores the
allocated ID in exar_gpio only after registering the action, so that
failure makes exar_devm_ida_free() release ID 0. If the allocated ID is
nonzero, this leaks that ID and can free ID 0 belonging to another device.
Store the ID before registering the cleanup action so both the immediate
failure path and normal device teardown release the correct allocation.
Fixes: 5300ebb695fa ("gpio: exar: use devm action for freeing the IDA and drop remove()")
Reported-by: Changyul Lee <lcy8047@gmail.com>
Assisted-by: LLM
Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/179070265834.12871.48183786512201899.idr-bug-79@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
__gpio_is_inverted() identifies GPIO86-89 on PXA26x by comparing its
argument against hardware line numbers, and its other callers pass the
hardware index from irqd_to_hwirq(). The direction_input() and
direction_output() callbacks instead pass chip->base + offset.
Pass the offset directly, which is the same conversion that commit
566e684e70cb ("gpio: pxa: use new pinctrl GPIO helpers") made for the
pinctrl calls in these functions.
No functional change: the driver never sets chip->base, which stays
zero because struct pxa_gpio_chip is allocated with devm_kzalloc().
This removes a dependency on gpio_chip::base,
as tracked in drivers/gpio/TODO.
Signed-off-by: Areeb Ul Haq Mirza <auhmirza02@gmail.com>
Link: https://patch.msgid.link/20260924140242.126159-1-auhmirza02@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
pm_runtime_get_sync() leaves the usage counter incremented even when it
fails, and xgpio_request() returns the error without dropping it.
gpiolib does not call ->free() when ->request() fails, so xgpio_free(),
which holds the only matching pm_runtime_put(), never runs. The reference
is leaked and the controller can no longer runtime-suspend, so its clock
stays enabled.
Switch to pm_runtime_resume_and_get(), which only increments the usage
counter on success.
Fixes: 26b04774621e ("gpio: gpio-xilinx: Add support for suspend and resume")
Cc: stable@vger.kernel.org
Signed-off-by: Ridham Khurana <khurana.ridham222@gmail.com>
Link: https://patch.msgid.link/20260923113905.1409290-1-khurana.ridham222@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Add support for the Axiado AX3005 SGPIO controller.
Each SGPIO position provides one input GPIO and one output GPIO with
fixed directions. The driver registers the controller as a gpio_chip,
supports interrupts on input GPIOs, and uses regmap for register access.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
Link: https://patch.msgid.link/20260921-axiado-ax3000-sgpio-controller-v4-2-79c444be7faf@axiado.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into gpio/for-next
Immutable branch between MFD, Clk, GPIO, Regulator and RTC due for the
v7.4 merge window containing the ROHM BD73800 GPIO driver.
|
|
Replace if/else block using regmap_set_bits()/regmap_clear_bits() with
the simpler regmap_assign_bits() call.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
On the Lenovo IdeaPad Slim 3 15ABR8 (82XM), the touchscreen
(GTCH7503:00) GPIO interrupt on pin 10 is armed as a wake source. As
soon as the system enters s2idle suspend the interrupt fires, causing
an immediate spurious resume, so suspend is unusable.
Disabling wakeup for the device via sysfs or booting with
gpiolib_acpi.ignore_wake=GTCH7503:00@10 avoids the problem, so add
a DMI quirk that ignores wakeup on that pin.
Signed-off-by: Mateo Borda <mateob226@gmail.com>
Acked-by: Mika Westerberg <westeri@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
GPIO_LINE_DIRECTION_OUT and GPIO_LINE_DIRECTION_IN have the values 0
and 1, respectively, while the TPS65214 GPIO_CONFIG field is BIT(1).
regmap_update_bits() masks the supplied value, so passing either
direction value clears the field and selects input mode.
Translate the GPIO direction to the register encoding used by
tps65214_gpio_get_direction(), setting GPIO_CONFIG for output and
clearing it for input.
Fixes: 1b6ab07c0c80 ("gpio: tps65219: Add support for TI TPS65214 PMIC")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260919171100.90430-4-kmehltretter@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
The TPS65214 template installs its own get_direction callback because
its direction bit is in GENERAL_CONFIG. The shared get and direction
callbacks nevertheless call tps65219_gpio_get_direction() directly and
interpret the unrelated TPS65219 MFP bit.
On TPS65214 this can reject reads from an input and skip the change from
input to output. Call the callback selected by the gpio_chip template
instead.
Fixes: 1b6ab07c0c80 ("gpio: tps65219: Add support for TI TPS65214 PMIC")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260919171100.90430-3-kmehltretter@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
