Harald Mommer [Thu, 24 Jul 2025 14:36:53 +0000 (16:36 +0200)]
gpio: virtio: Fix config space reading.
Quote from the virtio specification chapter 4.2.2.2:
"For the device-specific configuration space, the driver MUST use 8 bit
wide accesses for 8 bit wide fields, 16 bit wide and aligned accesses
for 16 bit wide fields and 32 bit wide and aligned accesses for 32 and
64 bit wide fields."
Jonas Karlman [Wed, 23 Jul 2025 08:56:43 +0000 (08:56 +0000)]
dt-bindings: gpio: rockchip: Allow use of a power-domain
The GPIO controllers in most Rockchip SoCs are part of power domains
that are always powered on, i.e. PD_BUS or PD_PMU. These always powered
on power domains have typically not been described in the device tree.
Because these power domains have been left out of the device tree there
has not been any real need to properly describe the GPIO controllers
power domain.
On RK3528 the GPIO controllers are spread out among the described
PD_RKVENC, PD_VO and PD_VPU power domains. However, one GPIO controller
belong to an undescribed always powered on power domain.
Add support to describe an optional power-domains for the GPIO
controllers in Rockchip SoCs.
Andrei Lalaev [Mon, 21 Jul 2025 15:57:37 +0000 (17:57 +0200)]
gpiolib: of: add forward declaration for struct device_node
Commit 08a149c40bdb ("gpiolib: Clean up headers") added a forward
declaration for struct device.
Later, commit 07445ae1c263 ("gpiolib: of: change of_find_gpio() to
accept device node") changed the function signature to accept a struct
device_node instead of a struct device.
Replace forward declaration of struct device with struct device_node to
match the updated function signature.
Hector Martin [Tue, 10 Jun 2025 15:29:48 +0000 (15:29 +0000)]
power: reset: macsmc-reboot: Add driver for rebooting via Apple SMC
This driver implements the reboot/shutdown support exposed by the SMC
on Apple Silicon machines, such as Apple M1 Macs.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250610-smc-6-15-v7-7-556cafd771d3@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
Hector Martin [Tue, 10 Jun 2025 15:29:47 +0000 (15:29 +0000)]
gpio: Add new gpio-macsmc driver for Apple Macs
This driver implements the GPIO service on top of the SMC framework
on Apple Mac machines. In particular, these are the GPIOs present in the
PMU IC which are used to control power to certain on-board devices.
Although the underlying hardware supports various pin config settings
(input/output, open drain, etc.), this driver does not implement that
functionality and leaves it up to the firmware to configure things
properly. We also don't yet support interrupts/events. This is
sufficient for device power control, which is the only thing we need to
support at this point. More features will be implemented when needed.
To our knowledge, only Apple Silicon Macs implement this SMC feature.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20250610-smc-6-15-v7-6-556cafd771d3@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
Sven Peter [Tue, 10 Jun 2025 15:29:46 +0000 (15:29 +0000)]
mfd: Add Apple Silicon System Management Controller
The System Management Controller (SMC) on Apple Silicon machines is a
piece of hardware that exposes various functionalities such as
temperature sensors, voltage/power meters, shutdown/reboot handling,
GPIOs and more.
Communication happens via a shared mailbox using the RTKit protocol
which is also used for other co-processors. The SMC protocol then allows
reading and writing many different keys which implement the various
features. The MFD core device handles this protocol and exposes it
to the sub-devices.
Some of the sub-devices are potentially also useful on pre-M1 Apple
machines and support for SMCs on these machines can be added at a later
time.
Co-developed-by: Hector Martin <marcan@marcan.st> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250610-smc-6-15-v7-5-556cafd771d3@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
Add support for the TI TPS65214 PMIC with the addition of an id_table,
separate TPS65214 template_chip, and device-specific _change_direction
functions.
- Use platform_get_device_id() to assign dev-specific information.
- Use different change_direction() functions since TPS65214's GPIO
configuration bits are changeable during device operation through bit
GPIO_CONFIG in GENERAL_CONFIG register.
- Remove MODULE_ALIAS since it is now generated by MODULE_DEVICE_TABLE.
Reviewed-by: Jonathan Cormier <jcormier@criticallink.com> Tested-by: Jonathan Cormier <jcormier@criticallink.com> Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> Link: https://lore.kernel.org/r/20250722181609.1541739-3-s-ramamoorthy@ti.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
TPS65215 and TPS65219 are overlapping PMIC devices. While their regulator
features differe, the GPIO features are the same. In the TPS65219 MFD
driver, the 2 PMICs share the same "tps65219-gpio" compatible string to
limit support for TPS65215 in this GPIO driver to comments.
The TPS6521X_GPIO0_IDX and TPS6521X_GPIO0_OFFSET macro name prefixes are
updated to indicate these macros apply to both PMICs.
Dan Carpenter [Fri, 18 Jul 2025 21:22:15 +0000 (16:22 -0500)]
gpio: sysfs: Fix an end of loop test in gpiod_unexport()
The test for "if (!desc_data)" does not work correctly because the list
iterator in a list_for_each_entry() loop is always non-NULL. If we don't
exit via a break, then it points to invalid memory. Instead, use a tmp
variable for the list iterator and only set the "desc_data" when we have
found a match.
The fsl,mpc8349-gpio, fsl,mpc8572-gpio, and fsl,mpc8610-gpio compatibles
are already documented in fsl,qoriq-gpio.yaml. Add the additional
compatibles that use fsl,mpc8349-gpio as a fallback. With that,
the 8xxx_gpio.txt binding document is redundant and can be removed.
Many simple GPIO controllers without interrupt capability have the same
schema other than their compatible value. Combine all these bindings
into a single schema. The criteria to be included here is must use 2
cells, have no interrupt capability, have 0 or 1 "reg" entries, and
have no other resources (like clocks).
Note that "ngpios" is now allowed in some cases it wasn't before and
constraints on it have been dropped.
gpio: xilinx: convert set_multiple() to the new API as well
The patch converting the driver to using new GPIO line value setters
only converted the set() callback and missed set_multiple(). Fix it now.
Fixes: 1919ea19a4ff ("gpio: xilinx: use new GPIO line value setter callbacks") Acked-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20250717131116.53878-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
As of commit 92ac7de3175e3 ("gpiolib: don't allow setting values on input
lines"), the GPIO core makes sure values cannot be set on input lines.
Remove the unnecessary check.
Add the interrupt enable register offset (inten_offset) so that GPIO
interrupts can be enabled normally on more models.
According to the latest interface specifications, the definition of GPIO
interrupts in ACPI is similar to that in FDT. The GPIO interrupts are
listed one by one according to the GPIO number, and the corresponding
interrupt number can be obtained directly through the GPIO number
specified by the consumer.
gpio: sysfs: allow disabling the legacy parts of the GPIO sysfs interface
Add a Kconfig switch allowing to disable the legacy parts of the GPIO
sysfs interface. This means that even though we keep the
/sys/class/gpio/ directory, it no longer contains the global
export/unexport attribute pair (instead, the user should use the
per-chip export/unpexport) nor the gpiochip$BASE entries. This option
default to y if GPIO sysfs is enabled but we'll default it to n at some
point in the future.
gpio: sysfs: export the GPIO directory locally in the gpiochip<id> directory
As a way to allow the user-space to stop referring to GPIOs by their
global numbers, introduce a parallel group of line attributes for
exported GPIO that live inside the GPIO chip class device and are
referred to by their HW offset within their parent chip.
gpio: sysfs: don't look up exported lines as class devices
In preparation for adding a parallel, per-chip attribute group for
exported GPIO lines, stop using class device APIs to refer to it in the
code. When unregistering the chip, don't call class_find_device() but
instead store exported lines in a linked list inside the GPIO chip data
object and look it up there.
gpio: sysfs: don't use driver data in sysfs callbacks for line attributes
Currently each exported GPIO is represented in sysfs as a separate class
device. This allows us to simply use dev_get_drvdata() to retrieve the
pointer passed to device_create_with_groups() from sysfs ops callbacks.
However, we're preparing to add a parallel set of per-line sysfs
attributes that will live inside the associated gpiochip group. They are
not registered as class devices and so have the parent device passed as
argument to their callbacks (the GPIO chip class device).
Put the attribute structs inside the GPIO descriptor data and
dereference the relevant ones using container_of() in the callbacks.
This way, we'll be able to reuse the same code for both the legacy and
new GPIO attributes.
gpio: sysfs: rename the data variable in gpiod_(un)export()
In preparation for future commits which will make use of descriptor AND
GPIO-device data in the same functions rename the former from data to
desc_data separately which will make future changes smaller and easier
to read.
gpio: sysfs: pass gpiod_data directly to internal GPIO sysfs functions
We don't use any fields from struct device in gpio_sysfs_request_irq(),
gpio_sysfs_free_irq() and gpio_sysfs_set_active_low(). We only use the
dev argument to get the associated struct gpiod_data pointer with
dev_get_drvdata().
To make the transition to not using dev_get_drvdata() across line
callbacks for sysfs attributes easier, pass gpiod_data directly to
these functions instead of having it wrapped in struct device.
gpio: sysfs: only get the dirent reference for the value attr once
There's no reason to retrieve the reference to the sysfs dirent every
time we request an interrupt, we can as well only do it once when
exporting the GPIO.
gpio: sysfs: add a parallel class device for each GPIO chip using device IDs
In order to enable moving away from the global GPIO numberspace-based
exporting of lines over sysfs: add a parallel, per-chip entry under
/sys/class/gpio/ for every registered GPIO chip, denoted by device ID
in the file name and not its base GPIO number.
Compared to the existing chip group: it does not contain the "base"
attribute as the goal of this change is to not refer to GPIOs by their
global number from user-space anymore. It also contains its own,
per-chip export/unexport attribute pair which allow to export lines by
their hardware offset within the chip.
Caveat #1: the new device cannot be a link to (or be linked to by) the
existing "gpiochip<BASE>" entry as we cannot create links in
/sys/class/xyz/.
Caveat #2: the new entry cannot be named "gpiochipX" as it could
conflict with devices whose base is statically defined to a low number.
Let's go with "chipX" instead.
While at it: the chip label is unique so update the untrue statement
when extending the docs.
gpio: sysfs: use gpiod_is_equal() to compare GPIO descriptors
We have a dedicated comparator for GPIO descriptors that performs
additional checks and hides the implementation detail of whether the
same GPIO can be associated with two separate struct gpio_desc objects.
Use it in sysfs code
Hugo Villeneuve [Mon, 14 Jul 2025 13:37:30 +0000 (09:37 -0400)]
gpio: pca953x: use regmap_update_bits() to improve performance
Using regmap_update_bits() allows to reduce the number of I2C transfers
when updating bits that haven't changed on non-volatile registers.
For example on a PCAL6416, when changing a GPIO direction from input to
output, the number of I2C transfers can be reduced from 4 to just 1 if
the pull resistors configuration hasn't changed and the output value
is the same as before.
GPIO core already makes sure that offsets higher than the number of GPIOs
are never passed to controller callbacks. We can remove the unnecessary
check.
gpio: wcd934x: check the return value of regmap_update_bits()
regmap_update_bits() can fail so check its return value in
wcd_gpio_direction_output() for consistency with the rest of the code
and propagate any errors.
gpiolib: don't use GPIO global numbers in debugfs output
One of the users of global GPIO numbers in the kernel are the debugfs
callbacks in GPIO drivers. Before converting any custom .dbg_show()
callbacks in individual modules, let's first make GPIO core stop using
GPIO base in debugfs output. Use hardware offsets instead.
Convert the Renesas R-Car GPIO driver from SIMPLE_DEV_PM_OPS() to
DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr(). This lets us drop the
check for CONFIG_PM_SLEEP, and reduces kernel size in case CONFIG_PM or
CONFIG_PM_SLEEP is disabled, while increasing build coverage.
gpio: sim: allow to mark simulated lines as invalid
Add a new line-level, boolean property to the gpio-sim configfs
interface called 'valid'. It's set by default and the user can unset it
to make the line be included in the standard `gpio-reserved-ranges`
property when the chip is registered with GPIO core. This allows users
to specify which lines should not be available for requesting as GPIOs.
Maria Garcia [Thu, 3 Jul 2025 20:57:40 +0000 (22:57 +0200)]
gpio: pca953x: Add support for TI TCA6418
The TI TCA6418 is a 18-channel I2C I/O expander. It is slightly
different to other models from the same family, such as TCA6416,
but has enough in common with them to make it work with just a
few tweaks, which are explained in the code's documentation.
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
GPIO core can handle output-only chips that don't implement the get()
and direction_input() callbacks. There's no need to provide dummy
implementation of the latter in the driver so drop it.
GPIO core can handle output-only chips that don't implement the get()
and direction_input() callbacks. There's no need to provide dummy
implementation of the latter in the driver so drop it.
gpio: tegra186: don't call the set() callback directly
Drivers should not dereference GPIO chip callbacks directly. Move the
module's set() function higher to make it available to the
direction_output() callback and call it instead.
projects / thirdparty / linux.git / log
