Peng Fan [Fri, 9 May 2025 04:45:36 +0000 (12:45 +0800)]
gpio: davinci: Update irq chip data
Use "struct davinci_gpio_controller *chips" as irq chip data to prepare
for immutable irq chip, then it will be easy to get gpio_chip pointer in
irq mask/unmask.
Ahmad Fatoum [Wed, 7 May 2025 17:28:01 +0000 (19:28 +0200)]
gpio: TODO: add item about GPIO drivers reading struct gpio_chip::base
drivers/pinctrl/pinctrl-at91.c uses struct gpio_chip::base to find out
which bit to set in a register:
dev_dbg(npct->dev, "enable pin %u as GPIO\n", offset);
mask = 1 << (offset - chip->base);
This adds a non-obvious dependency on the global numberspace from the
GPIO driver itself, even if all consumers use the descriptor API.
More such instances may exist and will need to be fixed in the quest for
removal of the global numberspace, so add a reminder about it to the
TODO list.
Ahmad Fatoum [Wed, 7 May 2025 13:07:25 +0000 (15:07 +0200)]
gpio: mxc: configure dynamic GPIO base for CONFIG_GPIO_SYSFS=n
i.MX GPIO numbering has been deterministic since commit 7e6086d9e54a
("gpio/mxc: specify gpio base for device tree probe"), a year after
device tree support was first added back in 2011.
Reverting to dynamically allocated GPIO base now would break most
systems making use of the sysfs API. These systems will be eventually
broken by the removal of the sysfs API, but that would result in GPIO
scripts not working instead of essentially toggling at random according
to probe order, which would happen if we unconditionally set base to -1.
Yet, the warning is annoying and has resulted in many rejected attempts
to remove it over the years[1][2][3].
As the i.MX GPIO driver is device tree only, GPIO_SYSFS is the only
consumer of the deterministic GPIO numbering. Let's therefore restrict the
static base and the warning that comes with it to configurations
with CONFIG_GPIO_SYSFS enabled.
André Draszik [Fri, 9 May 2025 13:22:41 +0000 (14:22 +0100)]
nvmem: max77759: Add Maxim MAX77759 NVMEM driver
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
This driver exposes the non volatile memory using the platform device
registered by the core MFD driver.
André Draszik [Fri, 9 May 2025 13:22:40 +0000 (14:22 +0100)]
gpio: max77759: Add Maxim MAX77759 gpio driver
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
This driver supports the GPIO functions using the platform device
registered by the core MFD driver.
André Draszik [Fri, 9 May 2025 13:22:39 +0000 (14:22 +0100)]
mfd: max77759: Add Maxim MAX77759 core driver
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
Fuel Gauge and TCPC have separate and independent I2C addresses,
register maps, and interrupt lines and are therefore excluded from the
MFD core device driver here.
The GPIO and NVMEM interfaces are accessed via specific commands to the
built-in microprocessor. This driver implements an API that client
drivers can use for accessing those.
André Draszik [Tue, 25 Mar 2025 08:27:04 +0000 (08:27 +0000)]
dt-bindings: mfd: Add max77759 binding
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
André Draszik [Tue, 25 Mar 2025 08:27:03 +0000 (08:27 +0000)]
dt-bindings: nvmem: Add max77759 binding
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
André Draszik [Tue, 25 Mar 2025 08:27:02 +0000 (08:27 +0000)]
dt-bindings: gpio: Add max77759 binding
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and
includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C
Port Controller (TCPC), NVMEM, and a GPIO expander.
Arnd Bergmann [Fri, 2 May 2025 20:37:07 +0000 (22:37 +0200)]
gpio: blzp1600: remove incorrect pf_match_ptr()
The blzp1600_gpio_of_match is defined unconditionally and can always be referenced
by the driver, so don't use of_match_ptr() and avoid this warning:
drivers/gpio/gpio-blzp1600.c:263:34: error: 'blzp1600_gpio_of_match' defined but not used [-Werror=unused-const-variable=]
263 | static const struct of_device_id blzp1600_gpio_of_match[] = {
Andy Shevchenko [Thu, 20 Feb 2025 16:20:27 +0000 (18:20 +0200)]
devres: Add devm_is_action_added() helper
In some code we would like to know if the action in device managed resources
was added by devm_add_action() family of calls. Introduce a helper for that.
Andy Shevchenko [Thu, 20 Feb 2025 16:20:26 +0000 (18:20 +0200)]
devres: Move devm_*_action*() APIs to devres.h
We have a newly created header linux/device/devres.h that gathers
device managed APIs, so users won't need to include entire device.h
for only these ones. Move devm_*_action*() APIs to devres.h as well.
Potin Lai [Wed, 9 Apr 2025 15:37:30 +0000 (23:37 +0800)]
gpio: pca953x: Add support for level-triggered interrupts
Adds support for level-triggered interrupts in the PCA953x GPIO
expander driver. Previously, the driver only supported edge-triggered
interrupts, which could lead to missed events in scenarios where an
interrupt condition persists until it is explicitly cleared.
By enabling level-triggered interrupts, the driver can now detect and
respond to sustained interrupt conditions more reliably.
Support for building it as a module for use on the Android platform,
because the Android kernel(GKI) doesn't contain board-specific drivers,
it requires that these drivers be built as a module and loaded into the
system.
gpio: Restrict GPIO_ICH to compile testing with HAS_IOPORT
When building gpio-ich.c for a platform that does not have IO port
access like s390, there are several errors due to the use of inl() and
outl() throughout the driver:
drivers/gpio/gpio-ich.c: In function 'ichx_read_bit':
include/asm-generic/io.h:578:14: error: call to '_inl' declared with attribute error: inl() requires CONFIG_HAS_IOPORT
Only allow compile testing when the targeted platform selects HAS_IOPORT
so that there are no compile time errors.
Fixes: f3592d252f77 ("gpio: ich: enable building with COMPILE_TEST=y") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202504171941.g1yXja0j-lkp@intel.com/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250418-gpio-ich-fix-build-without-ioport-v1-1-83fc753438ec@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Andy Shevchenko [Wed, 16 Apr 2025 09:55:15 +0000 (12:55 +0300)]
gpiolib: Reuse return variable in gpiod_to_irq()
There are two variables for the same used in the gpiod_to_irq().
Replace the second by reusing the function top-level one.
While at it, refactor the branch to have less lines of code.
Andy Shevchenko [Wed, 16 Apr 2025 09:55:09 +0000 (12:55 +0300)]
gpiolib: Make taking gpio_lookup_lock consistent
There are two ways to take a lock: plain call to the mutex_lock()
or using guard()() / scoped_guard(). The driver inconsistently uses
both. Make taking gpio_lookup_lock consistent.
Yixun Lan [Fri, 11 Apr 2025 23:31:29 +0000 (07:31 +0800)]
gpio: spacemit: add support for K1 SoC
Implement GPIO functionality which capable of setting pin as
input, output. Also, each pin can be used as interrupt which
support rising, falling, or both edge type trigger.
Yixun Lan [Fri, 11 Apr 2025 23:31:28 +0000 (07:31 +0800)]
dt-bindings: gpio: spacemit: add support for K1 SoC
The GPIO controller of K1 support basic functions as input/output,
all pins can be used as interrupt which route to one IRQ line,
trigger type can be select between rising edge, falling edge, or both.
There are four GPIO banks, each consisting of 32 pins.
Use the generic boolean device property getter instead of the
OF-specific variant. This allows us to stop pulling in linux/of.h. While
at it: drop the of_irq.h inclusion as none of its symbols are used in
this driver.
The Blaize BLZP1600 GPIO controller is only present on BLaize BLZP1600
SoCs. Hence add a dependency on ARCH_BLAIZE, to prevent asking the user
about this driver when configuring a kernel without Blaize platform
support.
Koichiro Den [Sat, 12 Apr 2025 15:01:19 +0000 (00:01 +0900)]
selftests: gpio: gpio-aggregator: add a test case for _sysfs prefix reservation
The kernel doc for gpio-aggregator configfs interface, which was recently
added, states that users should not be able to create an aggregator with a
name prefixed by "_sysfs" via configfs. However, it was found that this
guard does not function as expected (thanks to Dan Carpenter for
identifying and fixing the issue).
Dan Carpenter [Sat, 12 Apr 2025 10:15:16 +0000 (13:15 +0300)]
gpio: aggregator: Return an error if there are no GPIOs in gpio_aggregator_parse()
The error handling in gpio_aggregator_parse() was re-written. It now
returns success if there are no GPIOs. Restore the previous behavior
and return -EINVAL instead.
Koichiro Den [Mon, 7 Apr 2025 04:30:17 +0000 (13:30 +0900)]
gpio: aggregator: cancel deferred probe for devices created via configfs
For aggregators initialized via configfs, write 1 to 'live' waits for
probe completion and returns an error if the probe fails, unlike the
legacy sysfs interface, which is asynchronous.
Since users control the liveness of the aggregator device and might be
editing configurations while 'live' is 0, deferred probing is both
unnatural and unsafe.
Cancel deferred probe for purely configfs-based aggregators when probe
fails.
Koichiro Den [Mon, 7 Apr 2025 04:30:16 +0000 (13:30 +0900)]
gpio: aggregator: expose aggregator created via legacy sysfs to configfs
Expose settings for aggregators created using the sysfs 'new_device'
interface to configfs. Once written to 'new_device', an "_sysfs.<N>" path
appears in the configfs regardless of whether the probe succeeds.
Consequently, users can no longer use that prefix for custom GPIO
aggregator names. The 'live' attribute changes to 1 when the probe
succeeds and the GPIO forwarder is instantiated.
Note that the aggregator device created via sysfs is asynchronous, i.e.
writing into 'new_device' returns without waiting for probe completion,
and the probe may succeed, fail, or eventually succeed via deferred
probe. Thus, the 'live' attribute may change from 0 to 1 asynchronously
without notice. So, editing key/offset/name while it's waiting for
deferred probe is prohibited.
The configfs auto-generation relies on create_default_group(), which
inherently prohibits rmdir(2). To align with the limitation, this commit
also prohibits mkdir(2) for them. When users want to change the number
of lines for an aggregator initialized via 'new_device', they need to
tear down the device using 'delete_device' and reconfigure it from
scratch. This does not break previous behavior; users of legacy sysfs
interface simply gain additional almost read-only configfs exposure.
Still, users can write to the 'live' attribute to toggle the device
unless it's waiting for deferred probe. So once probe succeeds, they can
deactivate it in the same manner as the devices initialized via
configfs.
Koichiro Den [Mon, 7 Apr 2025 04:30:15 +0000 (13:30 +0900)]
gpio: aggregator: rename 'name' to 'key' in gpio_aggregator_parse()
Rename the local variable 'name' in gpio_aggregator_parse() to 'key'
because struct gpio_aggregator_line now uses the 'name' field for the
custom line name and the local variable actually represents a 'key'.
This change prepares for the next but one commit.
The existing sysfs 'new_device' interface has several limitations:
* No way to determine when GPIO aggregator creation is complete.
* No way to retrieve errors when creating a GPIO aggregator.
* No way to trace a GPIO line of an aggregator back to its
corresponding physical device.
* The 'new_device' echo does not indicate which virtual gpiochip<N>
was created.
* No way to assign names to GPIO lines exported through an aggregator.
Introduce the new configfs interface for gpio-aggregator to address
these limitations. It provides a more streamlined, modern, and
extensible configuration method. For backward compatibility, the
'new_device' interface and its behavior is retained for now.
Basic setup flow is:
1. Create a directory for a GPIO aggregator.
2. Create subdirectories for each line you want to instantiate.
3. In each line directory, configure the key and offset.
The key/offset semantics are as follows:
* If offset is >= 0:
- key specifies the name of the chip this GPIO belongs to
- offset specifies the line offset within that chip.
* If offset is <0:
- key needs to specify the GPIO line name.
4. Return to the aggregator's root directory and write '1' to the live
attribute.
For example, the command in the existing kernel doc:
Prepare for the upcoming configfs interface. These functions will be
used by both the existing sysfs interface and the new configfs
interface, reducing code duplication.
Koichiro Den [Mon, 7 Apr 2025 04:30:12 +0000 (13:30 +0900)]
gpio: aggregator: unify function naming
Unify function names to use gpio_aggregator_ prefix (except GPIO
forwarder implementations, which remain unchanged in subsequent
commits). While at it, rename the pre-existing gpio_aggregator_free() to
gpio_aggregator_destory(), since that name will be used by new
alloc/free functions introduced in the next commit, for which the name
is more appropriate.
Koichiro Den [Mon, 7 Apr 2025 04:30:11 +0000 (13:30 +0900)]
gpio: aggregator: reorder functions to prepare for configfs introduction
Reorder functions in drivers/gpio/gpio-aggregator.c to prepare for the
configfs-based interface additions in subsequent commits. Arrange the
code so that the configfs implementations will appear above the existing
sysfs-specific code, since the latter will partly depend on the configfs
interface implementations when it starts to expose the settings to
configfs.
The order in drivers/gpio/gpio-aggregator.c will be as follows:
There are users in the kernel that directly compare raw GPIO descriptor
pointers in order to determine whether they refer to the same physical
GPIO pin. This accidentally works like this but is not guaranteed by any
API contract. Let's provide a comparator function that hides the actual
logic.
Yixun Lan [Tue, 8 Apr 2025 15:11:20 +0000 (23:11 +0800)]
gpiolib: support parsing gpio three-cell interrupts scheme
gpio irq which using three-cell scheme should always call
instance_match() function to find the correct irqdomain.
The select() function will be called with !DOMAIN_BUS_ANY,
so for specific gpio irq driver, it need to set bus token
explicitly, something like:
irq_domain_update_bus_token(girq->domain, DOMAIN_BUS_WIRED);
projects / thirdparty / kernel / linux.git / log
