* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: Philippe Mathieu-Daudé @ 2026-06-30 22:09 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-14-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> After all other drivers have converted to linux/gpio/consumer.h
> or linux/gpio/legacy.h, remove the final leftover bits here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> MAINTAINERS | 1 -
> drivers/gpio/TODO | 4 +---
> drivers/gpio/gpiolib-cdev.c | 2 +-
> drivers/gpio/gpiolib-legacy.c | 3 +--
> drivers/gpio/gpiolib.c | 2 +-
> include/linux/gpio.h | 22 ----------------------
> 6 files changed, 4 insertions(+), 30 deletions(-)
> delete mode 100644 include/linux/gpio.h
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Linus Walleij @ 2026-06-30 22:31 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Viacheslav Bocharov, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Marek Szyprowski, Robin Murphy,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <CAMRc=MfpXEFreGynUtAJfvW+27OgKiTOEZvkddt5U0+QG4cYeQ@mail.gmail.com>
On Fri, Jun 26, 2026 at 5:02 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
> This looks good to me. Linus: do you want me to take patch 2/2 as well? I'll
> send it for v7.2-rc2.
Yep that's the best, I'll add my tag.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: meson: restore non-sleeping GPIO access
From: Linus Walleij @ 2026-06-30 22:31 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Bartosz Golaszewski, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Marek Szyprowski, Robin Murphy,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260625115718.1678991-3-v@baodeep.com>
On Thu, Jun 25, 2026 at 1:58 PM Viacheslav Bocharov <v@baodeep.com> wrote:
> Commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
> sleeping") set gpio_chip.can_sleep = true to work around
> gpio-shared-proxy holding a spinlock across a sleeping pinctrl config
> path. That locking bug is now fixed in the shared-proxy itself ("gpio:
> shared-proxy: always serialize with a sleeping mutex"), so the
> controller-wide workaround is no longer needed; the meson GPIO
> controller does not sleep.
>
> meson_gpio_get/set/direction_* access MMIO through regmap. The
> regmap_mmio bus uses fast I/O (spinlock) locking, so these value
> callbacks do not contain sleeping operations. Since gpio_chip.can_sleep
> describes the get/set value path, restore can_sleep = false.
>
> Marking the controller sleeping also broke atomic value consumers such
> as w1-gpio (1-Wire bitbang): w1_io.c runs its read time slot under
> local_irq_save() and uses the non-cansleep gpiod_set_value() /
> gpiod_get_value(), which with can_sleep=true trigger WARN_ON(can_sleep)
> in gpiolib on every transferred bit (from w1_gpio_write_bit() /
> w1_gpio_read_bit() via w1_reset_bus() and w1_search()). The printk and
> stack dump inside the IRQs-off, microsecond-scale time slot destroy the
> bit timing, so reset/presence detection and ROM search fail: the bus
> master registers but w1_master_slave_count stays at 0 and no devices
> are found. Verified on an Amlogic A113X board (DS18B20 on GPIOA_14):
> with can_sleep restored to false the warnings are gone and the sensor
> is detected and read again.
>
> This must not be applied or backported without the shared-proxy locking
> fix above; otherwise the original Khadas VIM3 splat returns on boards
> that genuinely share a meson GPIO.
>
> Fixes: 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping")
> Link: https://lore.kernel.org/all/20260105150509.56537-1-bartosz.golaszewski@oss.qualcomm.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: patchwork-bot+netdevbpf @ 2026-07-01 0:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, arnd, brgl, andrew, sebastian.hesselbarth,
gregory.clement, Frank.Li, robert.jarzmik, krzk, gerg, tsbogend,
hauke, zajec5, ysato, glaubitz, linusw, dmitry.torokhov, kuba,
pabeni, linux, linux-kernel, linux-arm-kernel, linux-samsung-soc,
patches, linux-m68k, linux-mips, linux-sh, linux-input,
linux-media, netdev, linux-sunxi, linux-phy, linux-rockchip,
linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 15:26:20 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> [...]
Here is the summary with links:
- [01/13] ARM: replace linux/gpio.h inclusions
(no matching commit)
- [02/13] m68k/coldfire: replace linux/gpio.h inclusions
(no matching commit)
- [03/13] mips: replace linux/gpio.h inclusions
(no matching commit)
- [04/13] sh: replace linux/gpio.h inclusions
(no matching commit)
- [05/13] mfd: replace linux/gpio.h inclusions
(no matching commit)
- [06/13,net-next] net: replace linux/gpio.h inclusions
https://git.kernel.org/netdev/net-next/c/a53d1872f2be
- [07/13] ASoC: replace linux/gpio.h inclusions
(no matching commit)
- [08/13] pcmcia: replace linux/gpio.h inclusions
(no matching commit)
- [09/13] phy: replace linux/gpio.h inclusions
(no matching commit)
- [10/13] media: replace linux/gpio.h inclusions
(no matching commit)
- [11/13] Input: matrix_keyboard - replace linux/gpio.h inclusion
(no matching commit)
- [12/13] gpib: gpio: replace linux/gpio.h inclusion
(no matching commit)
- [13/13] gpiolib: remove linux/gpio.h
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] gpio: pca953x: fix pca953x_irq_bus_sync_unlock regmap lock
From: Mark Tomlinson @ 2026-07-01 1:02 UTC (permalink / raw)
To: linusw, brgl, ian.ray; +Cc: linux-gpio, linux-kernel, Mark Tomlinson
Locking is disabled in the regmap config as this driver uses its own
lock. This means that all calls to regmap functions (read or write) must
hold the i2c_lock. The function pca953x_irq_bus_sync_unlock() did not do
this, and it was therefore possible that multiple threads could cause an
incorrect register to be read/written.
A previous patch partly fixed this, but only protected the write to the
interrupt mask register, and not the read from the direction register.
Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
---
drivers/gpio/gpio-pca953x.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 2ee35e855e4d..9689e3f3c517 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -605,20 +605,27 @@ static int pca953x_read_regs(struct pca953x_chip *chip, int reg, unsigned long *
return 0;
}
-static int pca953x_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+static int _pca953x_gpio_direction_input(struct gpio_chip *gc, unsigned off)
{
struct pca953x_chip *chip = gpiochip_get_data(gc);
u8 dirreg = chip->recalc_addr(chip, chip->regs->direction, off);
u8 bit = pca953x_get_bit_mask(chip, off);
- guard(mutex)(&chip->i2c_lock);
-
if (PCA_CHIP_TYPE(chip->driver_data) == TCA6418_TYPE)
return regmap_update_bits(chip->regmap, dirreg, bit, 0);
return regmap_update_bits(chip->regmap, dirreg, bit, bit);
}
+static int pca953x_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+ struct pca953x_chip *chip = gpiochip_get_data(gc);
+
+ guard(mutex)(&chip->i2c_lock);
+
+ return _pca953x_gpio_direction_input(gc, off);
+}
+
static int pca953x_gpio_direction_output(struct gpio_chip *gc,
unsigned off, int val)
{
@@ -856,9 +863,10 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
DECLARE_BITMAP(reg_direction, MAX_LINE);
int level;
+ guard(mutex)(&chip->i2c_lock);
+
if (chip->driver_data & PCA_PCAL) {
DECLARE_BITMAP(latched_inputs, MAX_LINE);
- guard(mutex)(&chip->i2c_lock);
/* Enable latch on edge-triggered interrupt-enabled inputs */
bitmap_or(latched_inputs, chip->irq_trig_fall, chip->irq_trig_raise, gc->ngpio);
@@ -880,7 +888,7 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
/* Look for any newly setup interrupt */
for_each_andnot_bit(level, irq_mask, reg_direction, gc->ngpio)
- pca953x_gpio_direction_input(&chip->gpio_chip, level);
+ _pca953x_gpio_direction_input(&chip->gpio_chip, level);
mutex_unlock(&chip->irq_lock);
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue write commands
From: Fenglin Wu @ 2026-07-01 2:43 UTC (permalink / raw)
To: Mark Brown, Konrad Dybcio
Cc: Dmitry Baryshkov, linux-arm-msm, Bjorn Andersson, Konrad Dybcio,
Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, Maulik Shah, kernel, linux-kernel, linux-gpio,
devicetree
In-Reply-To: <eb0e7827-2893-44cf-9251-a12747fdc0e2@sirena.org.uk>
On 6/30/2026 10:37 PM, Mark Brown wrote:
> On Tue, Jun 30, 2026 at 04:28:54PM +0200, Konrad Dybcio wrote:
>
>> +Mark, would you accept not-quite-a-regulator driver?
>
> Probably not, but I'm having a hard time telling what the problem is -
> the quoting level is rather deep and multiple levels of it don't use any
> word wrapping within paragraphs so it's all excessively hard to read.
> Frankly I very nearly just deleted the mail unread. Could someone
> summarise what's going on here please?
Hi Mark,
Please see a short summary below:
Qcom PMH0101 includes bi-directional level-shifter (BIDIR_LVL_SHIFTER)
modules that act as open-drain voltage translators, mainly to support
1.2 to 1.8V voltage translation on the I2C bus between the SoC with 1.2V
IOs and other I2C clients with 1.8V IOs. Each module shares two physical
pins with two GPIO modules, and control of the BIDIR_LVL_SHIFTER module
is centralized on the AOP side with 'XOB' resources so it can be shared
between different subsystems.
When a BIDIR_LVL_SHIFTER is enabled, it needs to send RPMh commands to
enable it and SPMI commands to disable the related two GPIO modules, to
make sure their circuitry does not interfere with it. For now, the
suggestion is to write a new driver for BIDIR_LVL_SHIFTER and place it
as a child of the rpmh_rsc device, and refer to pinstate nodes to
disable these two GPIO modules. However, we are now facing a difficulty
in deciding which subsystem the new driver should belong to. We expected
that the new driver should provide following capabilities:
1. Enable and disable the level-shifter at runtime. Consumers, likely
I2C client devices, will enable it when active and disable it when not,
mainly to save power.
2. Allow sharing the level-shifter between multiple consumers, even
across different subsystems (currently managed by AOP).
Following are the approaches that we are considered, and it seems only a
regulator device could satisfy the requirement the best but we want to
check with you if you are fine to put it in the regulator framework.
A. Using the mux subsystem: The level-shifter acts as a switch, so it
fits the mux subsystem physically. It can be enabled/disabled via
‘mux_control_select()’ and ‘mux_control_deselect()’. However, with
multiple consumers, a second call to ‘mux_control_select()’ is blocked
until ‘mux_control_deselect()’ is called, so votes from multiple
consumers are not allowed and can’t be aggregated.
B. Using the GPIO/pinctrl subsystem: After moving to a new driver, the
level-shifter doesn’t fit the GPIO controller or pinctrl device concept.
It has only one pinmux, and each level-shifter works with two pins.
Also, both GPIO and pinctrl frameworks require exclusive control, and
couldn't shared between consumers.
C. Using the regulator framework: The level-shifter is controlled via
the RPMh XOB resource at the AOP side, which was adopted from the idea
of power rails sharing between subsystems. The regulator framework’s
APIs and reference counting fit the requirements for sharing between
multiple consumers. The problem is, the level-shifter isn’t a power rail
so it is conceptually not a regulator.
Thanks
Fenglin Wu
^ permalink raw reply
* Re: [PATCH v6 5/5] watchdog: aaeon: Add watchdog driver for SRG-IMX8P MCU
From: Guenter Roeck @ 2026-07-01 2:50 UTC (permalink / raw)
To: Thomas Perrot (Schneider Electric), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal
In-Reply-To: <20260630-dev-b4-aaeon-mcu-driver-v6-5-d66b5fcbd2f0@bootlin.com>
On 6/30/26 05:51, Thomas Perrot (Schneider Electric) wrote:
> Add watchdog driver for the Aaeon SRG-IMX8P embedded controller.
> This driver provides system monitoring and recovery capabilities
> through the MCU's watchdog timer.
>
> The watchdog supports start, stop, and ping operations with a maximum
> hardware heartbeat of 25 seconds and a default timeout of 240 seconds.
> The software timeout can be changed via the WDIOC_SETTIMEOUT ioctl,
> the DT timeout-sec property, or the watchdog_timeout kernel boot
> parameter.
>
> Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> ---
> MAINTAINERS | 1 +
> drivers/watchdog/Kconfig | 10 +++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/aaeon_mcu_wdt.c | 144 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 156 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2538f8c4bc14..7b92af42c9fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -193,6 +193,7 @@ S: Maintained
> F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
> F: drivers/gpio/gpio-aaeon-mcu.c
> F: drivers/mfd/aaeon-mcu.c
> +F: drivers/watchdog/aaeon_mcu_wdt.c
> F: include/linux/mfd/aaeon-mcu.h
>
> AAEON UPBOARD FPGA MFD DRIVER
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index d3b9df7d466b..f67a0b453316 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -420,6 +420,16 @@ config SL28CPLD_WATCHDOG
>
> # ARM Architecture
>
> +config AAEON_MCU_WATCHDOG
> + tristate "Aaeon MCU Watchdog"
> + depends on MFD_AAEON_MCU
> + select WATCHDOG_CORE
> + help
> + Select this option to enable watchdog timer support for the Aaeon
> + SRG-IMX8P onboard microcontroller (MCU). This driver provides
> + watchdog functionality through the MCU, allowing system monitoring
> + and automatic recovery from system hangs.
> +
> config AIROHA_WATCHDOG
> tristate "Airoha EN7581 Watchdog"
> depends on ARCH_AIROHA || COMPILE_TEST
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index ba52099b1253..2deec425d3ea 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> # ALPHA Architecture
>
> # ARM Architecture
> +obj-$(CONFIG_AAEON_MCU_WATCHDOG) += aaeon_mcu_wdt.o
> obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
> obj-$(CONFIG_ARMADA_37XX_WATCHDOG) += armada_37xx_wdt.o
> diff --git a/drivers/watchdog/aaeon_mcu_wdt.c b/drivers/watchdog/aaeon_mcu_wdt.c
> new file mode 100644
> index 000000000000..347ee8269bfd
> --- /dev/null
> +++ b/drivers/watchdog/aaeon_mcu_wdt.c
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Aaeon MCU Watchdog driver
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#include <linux/mfd/aaeon-mcu.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/watchdog.h>
> +
> +#define AAEON_MCU_PING_WDT 0x73
> +
> +#define AAEON_MCU_WDT_TIMEOUT 240
> +#define AAEON_MCU_WDT_HEARTBEAT_MS 25000
> +#define AAEON_MCU_WDT_MIN_TIMEOUT 1
> +#define AAEON_MCU_WDT_MAX_TIMEOUT 3600
> +
> +static unsigned int timeout;
> +module_param(timeout, uint, 0);
> +MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds");
> +
> +struct aaeon_mcu_wdt {
> + struct watchdog_device wdt;
> + struct regmap *regmap;
> +};
> +
> +static int aaeon_mcu_wdt_cmd(struct aaeon_mcu_wdt *data, u8 opcode, u8 arg)
> +{
> + return regmap_write(data->regmap, AAEON_MCU_REG(opcode, arg), 0);
> +}
> +
> +static int aaeon_mcu_wdt_start(struct watchdog_device *wdt)
> +{
> + struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
> +
> + return aaeon_mcu_wdt_cmd(data, AAEON_MCU_CONTROL_WDT_OPCODE, 0x01);
> +}
> +
> +static int aaeon_mcu_wdt_status(struct watchdog_device *wdt, bool *enabled)
> +{
> + struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
> + unsigned int rsp;
> + int ret;
> +
> + ret = regmap_read(data->regmap,
> + AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT_OPCODE, 0x02),
> + &rsp);
> + if (ret)
> + return ret;
> +
> + *enabled = rsp == 0x01;
> + return 0;
> +}
> +
> +static int aaeon_mcu_wdt_stop(struct watchdog_device *wdt)
> +{
> + struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
> +
> + return aaeon_mcu_wdt_cmd(data, AAEON_MCU_CONTROL_WDT_OPCODE, 0x00);
> +}
> +
> +static int aaeon_mcu_wdt_ping(struct watchdog_device *wdt)
> +{
> + struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
> +
> + return aaeon_mcu_wdt_cmd(data, AAEON_MCU_PING_WDT, 0x00);
> +}
> +
> +static const struct watchdog_info aaeon_mcu_wdt_info = {
> + .identity = "Aaeon MCU Watchdog",
> + .options = WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE | WDIOF_SETTIMEOUT
> +};
> +
> +static const struct watchdog_ops aaeon_mcu_wdt_ops = {
> + .owner = THIS_MODULE,
> + .start = aaeon_mcu_wdt_start,
> + .stop = aaeon_mcu_wdt_stop,
> + .ping = aaeon_mcu_wdt_ping,
> +};
> +
> +static int aaeon_mcu_wdt_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct watchdog_device *wdt;
> + struct aaeon_mcu_wdt *data;
> + bool enabled;
> + int ret;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->regmap = dev_get_regmap(dev->parent, NULL);
> + if (!data->regmap)
> + return -ENODEV;
> +
> + wdt = &data->wdt;
> + wdt->parent = dev;
> + wdt->info = &aaeon_mcu_wdt_info;
> + wdt->ops = &aaeon_mcu_wdt_ops;
> + /*
> + * The MCU firmware has a fixed hardware timeout of 25 seconds that
> + * cannot be changed. The watchdog core handles automatic pinging to
> + * support software timeouts longer than the hardware limit. The default
> + * software timeout of 240 seconds can be overridden via the DT
> + * timeout-sec property or the watchdog_timeout kernel boot parameter.
> + */
> + wdt->timeout = AAEON_MCU_WDT_TIMEOUT;
> + wdt->min_timeout = AAEON_MCU_WDT_MIN_TIMEOUT;
> + wdt->max_timeout = AAEON_MCU_WDT_MAX_TIMEOUT;
> + wdt->max_hw_heartbeat_ms = AAEON_MCU_WDT_HEARTBEAT_MS;
Either max_timeout or max_hw_heartbeat_ms should be set, but not both.
From the include file:
* @max_timeout:The watchdog devices maximum timeout value (in seconds)
* as configurable from user space. Only relevant if
* max_hw_heartbeat_ms is not provided.
In other words, max_timeout is ignored by the watchdog core.
> + watchdog_init_timeout(wdt, timeout, dev);
As pointed out by Sashiko, this will not initialize the timeout from
devicetree. You'll need to either adjust the code or the comment above.
Thanks,
Guenter
> +
> + watchdog_set_drvdata(wdt, data);
> + watchdog_stop_on_reboot(wdt);
> +
> + ret = aaeon_mcu_wdt_status(wdt, &enabled);
> + if (ret)
> + return ret;
> +
> + if (enabled)
> + set_bit(WDOG_HW_RUNNING, &wdt->status);
> +
> + return devm_watchdog_register_device(dev, wdt);
> +}
> +
> +static struct platform_driver aaeon_mcu_wdt_driver = {
> + .driver = {
> + .name = "aaeon-mcu-wdt",
> + },
> + .probe = aaeon_mcu_wdt_probe,
> +};
> +
> +module_platform_driver(aaeon_mcu_wdt_driver);
> +
> +MODULE_ALIAS("platform:aaeon-mcu-wdt");
> +MODULE_DESCRIPTION("Aaeon MCU Watchdog Driver");
> +MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* [PATCH v6 1/7] mfd: nct6694: Move module type macros to shared header
From: a0282524688 @ 2026-07-01 3:50 UTC (permalink / raw)
To: lee, Ming Yu, Linus Walleij, Bartosz Golaszewski, Guenter Roeck,
Andi Shyti, Marc Kleine-Budde, Vincent Mailhol, Alexandre Belloni,
Wim Van Sebroeck
Cc: linux-kernel, Ming Yu, linux-gpio, linux-hwmon, linux-i2c,
linux-can, linux-rtc, linux-watchdog
In-Reply-To: <20260701035025.3082927-1-a0282524688@gmail.com>
From: Ming Yu <a0282524688@gmail.com>
Move NCT6694_XXX_MOD macro definitions from individual sub-device
drivers into the shared header include/linux/mfd/nct6694.h.
This is a prerequisite for supporting multiple transport interfaces
(USB, HIF) without duplicating these definitions.
No functional change.
Signed-off-by: Ming Yu <a0282524688@gmail.com>
---
Changes in v6:
Changes in v5:
- Split from the monolithic v4 patch to follow the single logical change
principle.
drivers/gpio/gpio-nct6694.c | 7 -------
drivers/hwmon/nct6694-hwmon.c | 21 ---------------------
drivers/i2c/busses/i2c-nct6694.c | 7 -------
drivers/net/can/usb/nct6694_canfd.c | 6 ------
drivers/rtc/rtc-nct6694.c | 7 -------
drivers/watchdog/nct6694_wdt.c | 7 -------
include/linux/mfd/nct6694.h | 9 +++++++++
7 files changed, 9 insertions(+), 55 deletions(-)
diff --git a/drivers/gpio/gpio-nct6694.c b/drivers/gpio/gpio-nct6694.c
index a8607f0d9915..53bfc5983648 100644
--- a/drivers/gpio/gpio-nct6694.c
+++ b/drivers/gpio/gpio-nct6694.c
@@ -13,13 +13,6 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-/*
- * USB command module type for NCT6694 GPIO controller.
- * This defines the module type used for communication with the NCT6694
- * GPIO controller over the USB interface.
- */
-#define NCT6694_GPIO_MOD 0xFF
-
#define NCT6694_GPIO_VER 0x90
#define NCT6694_GPIO_VALID 0x110
#define NCT6694_GPI_DATA 0x120
diff --git a/drivers/hwmon/nct6694-hwmon.c b/drivers/hwmon/nct6694-hwmon.c
index 6dcf22ca5018..581451875f2c 100644
--- a/drivers/hwmon/nct6694-hwmon.c
+++ b/drivers/hwmon/nct6694-hwmon.c
@@ -15,13 +15,6 @@
#include <linux/platform_device.h>
#include <linux/slab.h>
-/*
- * USB command module type for NCT6694 report channel
- * This defines the module type used for communication with the NCT6694
- * report channel over the USB interface.
- */
-#define NCT6694_RPT_MOD 0xFF
-
/* Report channel */
/*
* The report channel is used to report the status of the hardware monitor
@@ -38,13 +31,6 @@
#define NCT6694_TIN_STS(x) (0x6A + (x))
#define NCT6694_FIN_STS(x) (0x6E + (x))
-/*
- * USB command module type for NCT6694 HWMON controller.
- * This defines the module type used for communication with the NCT6694
- * HWMON controller over the USB interface.
- */
-#define NCT6694_HWMON_MOD 0x00
-
/* Command 00h - Hardware Monitor Control */
#define NCT6694_HWMON_CONTROL 0x00
#define NCT6694_HWMON_CONTROL_SEL 0x00
@@ -53,13 +39,6 @@
#define NCT6694_HWMON_ALARM 0x02
#define NCT6694_HWMON_ALARM_SEL 0x00
-/*
- * USB command module type for NCT6694 PWM controller.
- * This defines the module type used for communication with the NCT6694
- * PWM controller over the USB interface.
- */
-#define NCT6694_PWM_MOD 0x01
-
/* PWM Command - Manual Control */
#define NCT6694_PWM_CONTROL 0x01
#define NCT6694_PWM_CONTROL_SEL 0x00
diff --git a/drivers/i2c/busses/i2c-nct6694.c b/drivers/i2c/busses/i2c-nct6694.c
index 1413ab6f9462..ef3329f34246 100644
--- a/drivers/i2c/busses/i2c-nct6694.c
+++ b/drivers/i2c/busses/i2c-nct6694.c
@@ -12,13 +12,6 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-/*
- * USB command module type for NCT6694 I2C controller.
- * This defines the module type used for communication with the NCT6694
- * I2C controller over the USB interface.
- */
-#define NCT6694_I2C_MOD 0x03
-
/* Command 00h - I2C Deliver */
#define NCT6694_I2C_DELIVER 0x00
#define NCT6694_I2C_DELIVER_SEL 0x00
diff --git a/drivers/net/can/usb/nct6694_canfd.c b/drivers/net/can/usb/nct6694_canfd.c
index e5f7f8849a73..262b4c26c9d4 100644
--- a/drivers/net/can/usb/nct6694_canfd.c
+++ b/drivers/net/can/usb/nct6694_canfd.c
@@ -18,12 +18,6 @@
#define DEVICE_NAME "nct6694-canfd"
-/* USB command module type for NCT6694 CANfd controller.
- * This defines the module type used for communication with the NCT6694
- * CANfd controller over the USB interface.
- */
-#define NCT6694_CANFD_MOD 0x05
-
/* Command 00h - CAN Setting and Initialization */
#define NCT6694_CANFD_SETTING 0x00
#define NCT6694_CANFD_SETTING_ACTIVE_CTRL1 BIT(0)
diff --git a/drivers/rtc/rtc-nct6694.c b/drivers/rtc/rtc-nct6694.c
index 35401a0d9cf5..c06902f150c9 100644
--- a/drivers/rtc/rtc-nct6694.c
+++ b/drivers/rtc/rtc-nct6694.c
@@ -14,13 +14,6 @@
#include <linux/rtc.h>
#include <linux/slab.h>
-/*
- * USB command module type for NCT6694 RTC controller.
- * This defines the module type used for communication with the NCT6694
- * RTC controller over the USB interface.
- */
-#define NCT6694_RTC_MOD 0x08
-
/* Command 00h - RTC Time */
#define NCT6694_RTC_TIME 0x0000
#define NCT6694_RTC_TIME_SEL 0x00
diff --git a/drivers/watchdog/nct6694_wdt.c b/drivers/watchdog/nct6694_wdt.c
index bc3689bd4b6b..4c06ac105562 100644
--- a/drivers/watchdog/nct6694_wdt.c
+++ b/drivers/watchdog/nct6694_wdt.c
@@ -20,13 +20,6 @@
#define NCT6694_WDT_MAX_DEVS 2
-/*
- * USB command module type for NCT6694 WDT controller.
- * This defines the module type used for communication with the NCT6694
- * WDT controller over the USB interface.
- */
-#define NCT6694_WDT_MOD 0x07
-
/* Command 00h - WDT Setup */
#define NCT6694_WDT_SETUP 0x00
#define NCT6694_WDT_SETUP_SEL(idx) (idx ? 0x01 : 0x00)
diff --git a/include/linux/mfd/nct6694.h b/include/linux/mfd/nct6694.h
index 6eb9be2cd4a0..3c683e317aa3 100644
--- a/include/linux/mfd/nct6694.h
+++ b/include/linux/mfd/nct6694.h
@@ -8,6 +8,15 @@
#ifndef __MFD_NCT6694_H
#define __MFD_NCT6694_H
+#define NCT6694_HWMON_MOD 0x00
+#define NCT6694_PWM_MOD 0x01
+#define NCT6694_I2C_MOD 0x03
+#define NCT6694_CANFD_MOD 0x05
+#define NCT6694_WDT_MOD 0x07
+#define NCT6694_RTC_MOD 0x08
+#define NCT6694_RPT_MOD 0xFF
+#define NCT6694_GPIO_MOD NCT6694_RPT_MOD
+
#define NCT6694_VENDOR_ID 0x0416
#define NCT6694_PRODUCT_ID 0x200B
#define NCT6694_INT_IN_EP 0x81
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151
From: Linus Walleij @ 2026-07-01 7:00 UTC (permalink / raw)
To: Konrad Dybcio, Bartosz Golaszewski
Cc: Bjorn Andersson, Bartosz Golaszewski, linux-arm-msm, linux-gpio,
linux-kernel
In-Reply-To: <20260626-topic-8280_pinctrl_wakeup-v1-1-2ccb267148f5@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 3:08 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
> Pins 143 and 151 were not included in the PDC wakeup map. They are
> normally used for PCIe2A and PCIe3a PERST# respectively, so they're
> unlikely to be excercised in practice, but still add them for the sake
> of completeness.
>
> Fixes: c0e4c71a9e7c ("pinctrl: qcom: Introduce sc8280xp TLMM driver")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
LGTM Bartosz will queue Qualcomm patches, but I see he's
already on CC albeit in the qcom address.
Is this an urgent or a nonurgent fix?
Yours,
Linus Walleij
^ permalink raw reply
* Re: (subset) [PATCH v2 0/4] gpio: mt7621: address Sashiko complains and other cleanups
From: Bartosz Golaszewski @ 2026-07-01 7:04 UTC (permalink / raw)
To: Sergio Paracuellos
Cc: linux-gpio, linusw, brgl, vicencb, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <CAMhs-H8qy9XiYEOjcPPsH4ztejfo0=7_ZSNkvKEFfYNjd7w36w@mail.gmail.com>
On Tue, 30 Jun 2026 19:33:43 +0200, Sergio Paracuellos
<sergio.paracuellos@gmail.com> said:
> On Tue, Jun 30, 2026 at 4:37 PM Bartosz Golaszewski
> <bartosz.golaszewski@oss.qualcomm.com> wrote:
>>
>>
>> On Fri, 26 Jun 2026 08:01:08 +0200, Sergio Paracuellos wrote:
>> > This patchset covers some sashiko complains reported at some point when IRQ
>> > mapping was being fixed for this driver [0].
>> >
>> > I have included 'Fixes' tag and CC to stable for patches 13 since patch 4 is
>> > just a cleanup for naming.
>> >
>> > Thanks in advance for your time.
>> >
>> > [...]
>>
>> Applied, thanks!
>>
>> [1/4] gpio: mt7621: avoid corruption of shared interrupt trigger state
>> https://git.kernel.org/brgl/c/1781172526d1092323af443fa03f00e6de560401
>> [2/4] gpio: mt7621: more robust management of IRQ domain teardown
>> https://git.kernel.org/brgl/c/839738536adabae1a7e98ed3fc332ce9cc991d27
>> [3/4] gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips
>> https://git.kernel.org/brgl/c/0e024f58291dfcb28d98c512002e1a80fad69798
>>
>> Best regards,
>
> Thanks! What about PATCH 4? Are you planning to apply afterwards or
> should I just forget about it?
>
> Best regards,
> Sergio Paracuellos
>> --
>> Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
It's not a fix and it seems to depend on the three above. Once these three are
upstream, I'll pull a mainline tag and apply 4/4. No worries.
Bartosz
^ permalink raw reply
* Re: (subset) [PATCH v2 0/4] gpio: mt7621: address Sashiko complains and other cleanups
From: Sergio Paracuellos @ 2026-07-01 7:13 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-gpio, linusw, vicencb, linux-kernel, Bartosz Golaszewski
In-Reply-To: <CAMRc=Mer12rKJ7r38yoqyw=UQLCp8fo6gV6_D_aU531h_0OeDw@mail.gmail.com>
On Wed, Jul 1, 2026 at 9:04 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Tue, 30 Jun 2026 19:33:43 +0200, Sergio Paracuellos
> <sergio.paracuellos@gmail.com> said:
> > On Tue, Jun 30, 2026 at 4:37 PM Bartosz Golaszewski
> > <bartosz.golaszewski@oss.qualcomm.com> wrote:
> >>
> >>
> >> On Fri, 26 Jun 2026 08:01:08 +0200, Sergio Paracuellos wrote:
> >> > This patchset covers some sashiko complains reported at some point when IRQ
> >> > mapping was being fixed for this driver [0].
> >> >
> >> > I have included 'Fixes' tag and CC to stable for patches 13 since patch 4 is
> >> > just a cleanup for naming.
> >> >
> >> > Thanks in advance for your time.
> >> >
> >> > [...]
> >>
> >> Applied, thanks!
> >>
> >> [1/4] gpio: mt7621: avoid corruption of shared interrupt trigger state
> >> https://git.kernel.org/brgl/c/1781172526d1092323af443fa03f00e6de560401
> >> [2/4] gpio: mt7621: more robust management of IRQ domain teardown
> >> https://git.kernel.org/brgl/c/839738536adabae1a7e98ed3fc332ce9cc991d27
> >> [3/4] gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips
> >> https://git.kernel.org/brgl/c/0e024f58291dfcb28d98c512002e1a80fad69798
> >>
> >> Best regards,
> >
> > Thanks! What about PATCH 4? Are you planning to apply afterwards or
> > should I just forget about it?
> >
> > Best regards,
> > Sergio Paracuellos
> >> --
> >> Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> >
>
> It's not a fix and it seems to depend on the three above. Once these three are
> upstream, I'll pull a mainline tag and apply 4/4. No worries.
Thanks a lot for letting me know.
Best regards,
Sergio Paracuellos
>
> Bartosz
^ permalink raw reply
* Re: [PATCH] gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe
From: Bartosz Golaszewski @ 2026-07-01 7:21 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Vladimir Zapolskiy
Cc: Bartosz Golaszewski, Richard Röjfors, linux-gpio
In-Reply-To: <20260630145148.4081967-1-vz@kernel.org>
On Tue, 30 Jun 2026 17:51:48 +0300, Vladimir Zapolskiy wrote:
> Out of memory situation on driver's probe is expected to be reported to
> the driver's framework with a proper -ENOMEM error code.
>
>
Applied, thanks!
[1/1] gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe
https://git.kernel.org/brgl/c/8d7e62d5e9b2d2ff146f472a9215d7e29c7e2307
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151
From: Bartosz Golaszewski @ 2026-07-01 7:22 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Konrad Dybcio
Cc: Bartosz Golaszewski, linux-arm-msm, linux-gpio, linux-kernel
In-Reply-To: <20260626-topic-8280_pinctrl_wakeup-v1-1-2ccb267148f5@oss.qualcomm.com>
On Fri, 26 Jun 2026 15:08:05 +0200, Konrad Dybcio wrote:
> Pins 143 and 151 were not included in the PDC wakeup map. They are
> normally used for PCIe2A and PCIe3a PERST# respectively, so they're
> unlikely to be excercised in practice, but still add them for the sake
> of completeness.
>
>
Applied, thanks!
[1/1] pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151
https://git.kernel.org/brgl/c/437a8d2aa1aa442c4a176fdf4700a9b3bb0c8794
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151
From: Bartosz Golaszewski @ 2026-07-01 7:24 UTC (permalink / raw)
To: Linus Walleij
Cc: Bjorn Andersson, Bartosz Golaszewski, linux-arm-msm, linux-gpio,
linux-kernel, Konrad Dybcio, Bartosz Golaszewski
In-Reply-To: <CAD++jLneg_hxaBbcH915K8h1aec3L2gHKMhCmmj_eZ3iOs=VJA@mail.gmail.com>
On Wed, 1 Jul 2026 09:00:33 +0200, Linus Walleij <linusw@kernel.org> said:
> On Fri, Jun 26, 2026 at 3:08 PM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>
>> Pins 143 and 151 were not included in the PDC wakeup map. They are
>> normally used for PCIe2A and PCIe3a PERST# respectively, so they're
>> unlikely to be excercised in practice, but still add them for the sake
>> of completeness.
>>
>> Fixes: c0e4c71a9e7c ("pinctrl: qcom: Introduce sc8280xp TLMM driver")
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> LGTM Bartosz will queue Qualcomm patches, but I see he's
> already on CC albeit in the qcom address.
>
> Is this an urgent or a nonurgent fix?
>
Now queued, thanks.
Konrad: I use my kernel.org address for linux develpment as per MAINTAINERS so
may miss email sent to oss.qualcomm.com.
Thanks,
Bart
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: fix pca953x_irq_bus_sync_unlock regmap lock
From: Bartosz Golaszewski @ 2026-07-01 7:26 UTC (permalink / raw)
To: Mark Tomlinson; +Cc: linux-gpio, linux-kernel, linusw, brgl, ian.ray
In-Reply-To: <20260701010228.1605573-1-mark.tomlinson@alliedtelesis.co.nz>
On Wed, 1 Jul 2026 03:02:28 +0200, Mark Tomlinson
<mark.tomlinson@alliedtelesis.co.nz> said:
> Locking is disabled in the regmap config as this driver uses its own
> lock. This means that all calls to regmap functions (read or write) must
> hold the i2c_lock. The function pca953x_irq_bus_sync_unlock() did not do
> this, and it was therefore possible that multiple threads could cause an
> incorrect register to be read/written.
>
> A previous patch partly fixed this, but only protected the write to the
> interrupt mask register, and not the read from the direction register.
>
> Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Plase add Fixes: and Cc: stable.
> ---
> drivers/gpio/gpio-pca953x.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index 2ee35e855e4d..9689e3f3c517 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -605,20 +605,27 @@ static int pca953x_read_regs(struct pca953x_chip *chip, int reg, unsigned long *
> return 0;
> }
>
> -static int pca953x_gpio_direction_input(struct gpio_chip *gc, unsigned off)
> +static int _pca953x_gpio_direction_input(struct gpio_chip *gc, unsigned off)
Please prefer pca953x_gpio_direction_input_unlocked() as it's more verbose
about the purpose.
> {
> struct pca953x_chip *chip = gpiochip_get_data(gc);
> u8 dirreg = chip->recalc_addr(chip, chip->regs->direction, off);
> u8 bit = pca953x_get_bit_mask(chip, off);
>
> - guard(mutex)(&chip->i2c_lock);
> -
> if (PCA_CHIP_TYPE(chip->driver_data) == TCA6418_TYPE)
> return regmap_update_bits(chip->regmap, dirreg, bit, 0);
>
> return regmap_update_bits(chip->regmap, dirreg, bit, bit);
> }
>
> +static int pca953x_gpio_direction_input(struct gpio_chip *gc, unsigned off)
> +{
> + struct pca953x_chip *chip = gpiochip_get_data(gc);
> +
> + guard(mutex)(&chip->i2c_lock);
> +
> + return _pca953x_gpio_direction_input(gc, off);
> +}
> +
> static int pca953x_gpio_direction_output(struct gpio_chip *gc,
> unsigned off, int val)
> {
> @@ -856,9 +863,10 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
> DECLARE_BITMAP(reg_direction, MAX_LINE);
> int level;
>
> + guard(mutex)(&chip->i2c_lock);
> +
> if (chip->driver_data & PCA_PCAL) {
> DECLARE_BITMAP(latched_inputs, MAX_LINE);
> - guard(mutex)(&chip->i2c_lock);
>
> /* Enable latch on edge-triggered interrupt-enabled inputs */
> bitmap_or(latched_inputs, chip->irq_trig_fall, chip->irq_trig_raise, gc->ngpio);
> @@ -880,7 +888,7 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
>
> /* Look for any newly setup interrupt */
> for_each_andnot_bit(level, irq_mask, reg_direction, gc->ngpio)
> - pca953x_gpio_direction_input(&chip->gpio_chip, level);
> + _pca953x_gpio_direction_input(&chip->gpio_chip, level);
>
> mutex_unlock(&chip->irq_lock);
> }
> --
> 2.54.0
>
>
Thanks,
Bartosz
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Bartosz Golaszewski @ 2026-07-01 7:27 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Viacheslav Bocharov
Cc: Bartosz Golaszewski, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Marek Szyprowski, Robin Murphy,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260625115718.1678991-1-v@baodeep.com>
On Thu, 25 Jun 2026 14:57:16 +0300, Viacheslav Bocharov wrote:
> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
> the underlying chip's can_sleep, but under that lock it calls config and
> direction ops that reach sleeping pinctrl paths. On a controller with
> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
> runs from atomic context:
>
> BUG: sleeping function called from invalid context
> ... pinctrl_gpio_set_config <- gpiochip_generic_config
> <- gpio_shared_proxy_set_config (voting spinlock held)
> <- ... <- mmc_pwrseq_simple_probe
>
> [...]
Applied, thanks!
[2/2] pinctrl: meson: restore non-sleeping GPIO access
https://git.kernel.org/brgl/c/9777530157e7b82fd994327ff878c4245dadc931
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v6 3/5] mfd: aaeon: Add SRG-IMX8P MCU driver
From: Bartosz Golaszewski @ 2026-07-01 7:31 UTC (permalink / raw)
To: Thomas Perrot (Schneider Electric)
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
Lee Jones
In-Reply-To: <20260630-dev-b4-aaeon-mcu-driver-v6-3-d66b5fcbd2f0@bootlin.com>
On Tue, 30 Jun 2026 14:51:13 +0200, "Thomas Perrot (Schneider
Electric)" <thomas.perrot@bootlin.com> said:
> Add Multi-Function Device (MFD) driver for the Aaeon SRG-IMX8P
> embedded controller. This driver provides the core I2C communication
> interface and registers child devices (GPIO and watchdog controllers).
>
> The driver implements a custom regmap bus over I2C to match the MCU's
> fixed 3-byte command format [opcode, arg, value]. Register addresses
> are encoded as 16-bit values (opcode << 8 | arg) using the
> AAEON_MCU_REG() macro defined in the shared header. The regmap
> instance is shared with child drivers via dev_get_regmap(). Concurrent
> I2C accesses from child drivers are serialized by regmap's built-in
> locking.
>
> I2C transfers use heap-allocated DMA-safe buffers rather than
> stack-allocated ones, as required by I2C controllers that perform DMA.
>
> Regmap caching is enabled (REGCACHE_MAPLE) with a volatile_reg
> callback that marks GPIO input read registers (opcode 0x72) and the
> watchdog status register (opcode 0x63, arg 0x02) as volatile. All
> other registers written by the driver (GPIO direction,
> GPO state, watchdog control) are stable and can be safely cached.
>
> Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
> ---
> MAINTAINERS | 2 +
> drivers/mfd/Kconfig | 11 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/aaeon-mcu.c | 205 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/aaeon-mcu.h | 40 +++++++++
> 5 files changed, 259 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea9d55f76f35..f91b6a1826d0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -191,6 +191,8 @@ M: Thomas Perrot <thomas.perrot@bootlin.com>
> R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> S: Maintained
> F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
> +F: drivers/mfd/aaeon-mcu.c
> +F: include/linux/mfd/aaeon-mcu.h
>
> AAEON UPBOARD FPGA MFD DRIVER
> M: Thomas Richard <thomas.richard@bootlin.com>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index aace5766b38a..ed5169c7a683 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1561,6 +1561,17 @@ config ABX500_CORE
> remain unchanged when IC changes. Binding of the functions to
> actual register access is done by the IC core driver.
>
> +config MFD_AAEON_MCU
> + tristate "Aaeon SRG-IMX8P MCU Driver"
> + depends on I2C
> + select MFD_CORE
> + select REGMAP
> + help
> + Select this option to enable support for the Aaeon SRG-IMX8P
> + onboard microcontroller (MCU). This driver provides the core
> + functionality to communicate with the MCU over I2C. The MCU
> + provides GPIO and watchdog functionality.
> +
> config AB8500_CORE
> bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
> depends on ABX500_CORE && MFD_DB8500_PRCMU
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index e75e8045c28a..34db5b033584 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
> obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM886_PMIC) += 88pm886.o
> +obj-$(CONFIG_MFD_AAEON_MCU) += aaeon-mcu.o
> obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
> obj-$(CONFIG_MFD_SM501) += sm501.o
> obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
> diff --git a/drivers/mfd/aaeon-mcu.c b/drivers/mfd/aaeon-mcu.c
> new file mode 100644
> index 000000000000..306aaac1bd60
> --- /dev/null
> +++ b/drivers/mfd/aaeon-mcu.c
> @@ -0,0 +1,205 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Aaeon MCU driver
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/mfd/aaeon-mcu.h>
> +#include <linux/mfd/core.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +struct aaeon_mcu {
> + struct i2c_client *client;
> + u8 *cmd; /* DMA-safe 3-byte write buffer [opcode, arg, value] */
> + u8 *response; /* DMA-safe 1-byte read buffer for MCU acknowledgment */
> +};
> +
> +static const struct mfd_cell aaeon_mcu_devs[] = {
> + MFD_CELL_BASIC("aaeon-mcu-wdt", NULL, NULL, 0, 0),
> + MFD_CELL_BASIC("aaeon-mcu-gpio", NULL, NULL, 0, 0),
> +};
> +
> +/* Number of bytes in a MCU command: [opcode, arg, value] */
> +#define AAEON_MCU_CMD_LEN 3
> +
> +/*
> + * Custom regmap bus for the Aaeon MCU I2C protocol.
> + *
> + * The MCU uses a fixed 3-byte command format [opcode, arg, value] followed
> + * by a 1-byte response. It requires a STOP condition between the command
> + * write and the response read, so two separate i2c_transfer() calls are
> + * issued. The regmap lock serialises concurrent accesses from the GPIO
> + * and watchdog child drivers.
> + *
> + * Register addresses are encoded as a 16-bit big-endian value where the
> + * high byte is the opcode and the low byte is the argument, matching the
> + * wire layout produced by regmap for reg_bits=16.
> + */
I would have preferred this implemented as a quirk in the i2c regmap but
won't die on that hill.
> +
> +static int aaeon_mcu_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct aaeon_mcu *mcu = context;
> + struct i2c_client *client = mcu->client;
> + struct i2c_msg write_msg;
> + /* The MCU always sends a response byte after each command; discard it. */
> + struct i2c_msg response_msg;
> + int ret;
> +
> + memcpy(mcu->cmd, data, count);
> +
> + write_msg.addr = client->addr;
> + write_msg.flags = I2C_M_DMA_SAFE;
> + write_msg.buf = mcu->cmd;
> + write_msg.len = count;
> +
> + response_msg.addr = client->addr;
> + response_msg.flags = I2C_M_RD | I2C_M_DMA_SAFE;
> + response_msg.buf = mcu->response;
> + response_msg.len = 1;
> +
> + ret = i2c_transfer(client->adapter, &write_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + ret = i2c_transfer(client->adapter, &response_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int aaeon_mcu_regmap_read(void *context, const void *reg_buf,
> + size_t reg_size, void *val_buf, size_t val_size)
> +{
> + struct aaeon_mcu *mcu = context;
> + struct i2c_client *client = mcu->client;
> + struct i2c_msg write_msg;
> + struct i2c_msg read_msg;
> + int ret;
> +
> + /*
> + * reg_buf holds the 2-byte big-endian register address [opcode, arg].
> + * Append a trailing 0x00 to form the full 3-byte MCU command.
> + */
> + mcu->cmd[0] = ((u8 *)reg_buf)[0];
> + mcu->cmd[1] = ((u8 *)reg_buf)[1];
> + mcu->cmd[2] = 0x00;
> +
> + write_msg.addr = client->addr;
> + write_msg.flags = I2C_M_DMA_SAFE;
> + write_msg.buf = mcu->cmd;
> + write_msg.len = AAEON_MCU_CMD_LEN;
> +
> + read_msg.addr = client->addr;
> + read_msg.flags = I2C_M_RD | I2C_M_DMA_SAFE;
> + read_msg.buf = val_buf;
> + read_msg.len = val_size;
> +
> + ret = i2c_transfer(client->adapter, &write_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + ret = i2c_transfer(client->adapter, &read_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static const struct regmap_bus aaeon_mcu_regmap_bus = {
> + .write = aaeon_mcu_regmap_write,
> + .read = aaeon_mcu_regmap_read,
> +};
> +
> +static bool aaeon_mcu_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /*
> + * GPIO input registers are driven by external signals and can change
> + * at any time without CPU involvement, always read from hardware.
> + *
> + * The watchdog status register reflects hardware state and can change
> + * autonomously.
> + *
> + * All other registers are written by the driver and their values are
> + * stable, so they can be safely cached.
> + */
> + if ((reg >> 8) == AAEON_MCU_READ_GPIO_OPCODE)
> + return true;
> + if (reg == AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT_OPCODE, 0x02))
> + return true;
> + return false;
> +}
> +
> +static const struct regmap_config aaeon_mcu_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 8,
> + .reg_format_endian = REGMAP_ENDIAN_BIG,
> + .max_register = AAEON_MCU_MAX_REGISTER,
> + .volatile_reg = aaeon_mcu_volatile_reg,
> + .cache_type = REGCACHE_MAPLE,
> +};
> +
> +static int aaeon_mcu_probe(struct i2c_client *client)
> +{
> + struct aaeon_mcu *ddata;
> + struct regmap *regmap;
> +
> + ddata = devm_kzalloc(&client->dev, sizeof(*ddata), GFP_KERNEL);
> + if (!ddata)
> + return -ENOMEM;
> +
> + ddata->client = client;
> +
> + ddata->cmd = devm_kzalloc(&client->dev, AAEON_MCU_CMD_LEN * sizeof(*ddata->cmd),
Why not devm_kcalloc()?
> + GFP_KERNEL);
> + if (!ddata->cmd)
> + return -ENOMEM;
> +
> + ddata->response = devm_kzalloc(&client->dev, sizeof(*ddata->response), GFP_KERNEL);
> + if (!ddata->response)
> + return -ENOMEM;
> +
> + regmap = devm_regmap_init(&client->dev, &aaeon_mcu_regmap_bus,
> + ddata, &aaeon_mcu_regmap_config);
> + if (IS_ERR(regmap))
> + return dev_err_probe(&client->dev, PTR_ERR(regmap),
> + "failed to initialize regmap\n");
> +
> + return devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
> + aaeon_mcu_devs, ARRAY_SIZE(aaeon_mcu_devs),
> + NULL, 0, NULL);
> +}
> +
> +static const struct of_device_id aaeon_mcu_of_match[] = {
> + { .compatible = "aaeon,srg-imx8p-mcu" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, aaeon_mcu_of_match);
> +
> +static struct i2c_driver aaeon_mcu_driver = {
> + .driver = {
> + .name = "aaeon-mcu",
> + .of_match_table = aaeon_mcu_of_match,
> + },
> + .probe = aaeon_mcu_probe,
> +};
> +module_i2c_driver(aaeon_mcu_driver);
> +
> +MODULE_DESCRIPTION("Aaeon MCU Driver");
> +MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/aaeon-mcu.h b/include/linux/mfd/aaeon-mcu.h
> new file mode 100644
> index 000000000000..3a1aeec85d60
> --- /dev/null
> +++ b/include/linux/mfd/aaeon-mcu.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Aaeon MCU driver definitions
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#ifndef __LINUX_MFD_AAEON_MCU_H
> +#define __LINUX_MFD_AAEON_MCU_H
> +
> +/*
> + * MCU register address: the high byte is the command opcode, the low
> + * byte is the argument. This matches the 3-byte wire format
> + * [opcode, arg, value] used by the MCU I2C protocol.
> + */
> +#define AAEON_MCU_REG(op, arg) (((op) << 8) | (arg))
> +
> +/*
> + * Opcode for GPIO input reads. These registers are volatile, their values
> + * are driven by external signals and can change without CPU involvement.
> + * Used by the MFD driver's volatile_reg callback to bypass the regmap cache.
> + */
> +#define AAEON_MCU_READ_GPIO_OPCODE 0x72
> +
> +/*
> + * Opcode for watchdog control and status commands.
> + * The status register (arg=0x02) reflects hardware state and is volatile.
> + */
> +#define AAEON_MCU_CONTROL_WDT_OPCODE 0x63
> +
> +/*
> + * Highest register address in the MCU register map.
> + * The WRITE_GPIO opcode (0x77) with the highest GPIO argument (0x0B = 11,
> + * i.e. MAX_GPIOS - 1) produces the largest encoded address.
> + */
> +#define AAEON_MCU_MAX_REGISTER AAEON_MCU_REG(0x77, 0x0B)
> +
> +#endif /* __LINUX_MFD_AAEON_MCU_H */
>
> --
> 2.54.0
>
>
Bart
^ permalink raw reply
* Re: [PATCH v3 0/8] x1e80100: Enable PDC wake GPIOs and deepest idle state
From: Bartosz Golaszewski @ 2026-07-01 7:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-kernel, devicetree, linux-gpio,
Sneh Mankad, Stephan Gerhold, Linus Walleij, Maulik Shah,
Bartosz Golaszewski
In-Reply-To: <87pl18qepk.ffs@fw13>
On Tue, 30 Jun 2026 16:34:47 +0200, Thomas Gleixner <tglx@kernel.org> said:
> On Tue, Jun 30 2026 at 12:42, Linus Walleij wrote:
>> I don't know what to do with this hurdle of pin control and irqchip patches,
>> luckily it will be Bartosz' problem since he's managing Qualcomm pin
>> controllers now :D
>>
>> I'll be fine with brining the irqchip patches through pin control if an
>> irqchip maintainer ACKs them.
>
> The irq chip patches are self contained. So once we have a functional
> version I can apply them on top of rc1, tag the lot and merge it into
> the irqchip branch. Bartosz can then pull the tag into his branch to
> apply the rest.
>
>
Sounds good to me. Thanks.
Bartosz
^ permalink raw reply
* Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map
From: Andy Shevchenko @ 2026-07-01 7:36 UTC (permalink / raw)
To: Miao Wang
Cc: Bartosz Golaszewski, Miao Wang via B4 Relay, Huacai Chen,
Jianmin Lv, WANG Xuerui, Jiaxun Yang, linux-gpio, Yinbo Zhu,
Linus Walleij, Hongchen Zhang, Liu Peibao, Juxin Gao,
Mika Westerberg
In-Reply-To: <B77A4E49-774C-4DB2-9CA6-FFBE14F1EF94@gmail.com>
On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> > 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> >> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> >> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
> >
> >>> This patch adds back the support for gsi_idx_map, which is used in the
> >>> ACPI DSDT table to describe the mapping between the GPIO line number to
> >>> the index of the interrupt number in the declared interrupt resources.
> >>>
> >>> This property was removed in Loongson CPU Universal Specification for
> >>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> >>> 2023, but still in use in firmwares released this year. A sample of
> >>> an affected DSDT entry from a 3C6000 board I'm currently using is:
> >
> > Oh my gosh, can somebody actually try to consult first with the Linux kernel
> > developers before adding non-standard and wrongly named properties, please?
>
> Inferred from the time when gsi_idx_map was removed from the spec, I believe
> that the removal might be because the maintainers suggestion against introducing
> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
But what is the outcome of not using that mapping. Do you have something wrong
or not working?
> >>> Device (GPO1) {
> >>> Name (_HID, "LOON000F")
> >>> Name (_CRS, ResourceTemplate () {
> >>> QWordMemory ( // Omitted, not related
> >>> )
> >>> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> >>> 0x00000010, 0x00000011, 0x00000012, 0x00000013,
> >>> 0x00000014, 0x00000015, 0x00000016, 0x00000017,
> >>> }
> >>> Name (_DSD, Package (0x02) {
> >>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> >>> Package (0x03) {
> >>> Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> >
> > Yes, it's non-standard property. It's a broken one in terms of the style.
> > See DT binding documentation.
>
> To clarify, I agree that this property should be redundant and ignored by
> the driver and global gpio numbers should be assigned dynamically by the
> kernel.
>
> >>> Package (0x02) { "ngpios", 0x20 }
> >>> Package (0x02) { "gsi_idx_map", Package (0x20) {
> >>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>> 0, 1, 2, 3, 4, 5, 6, 7,
> >>> }}
> >>> }
> >>> }
> >>> }
> >>>
> >>> As can be seen in the DSDT entry, the mapping is essential for obtaining
> >>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> >>> for the line numbers largers than 7, it will fail with -ENXIO.
> >
> > This doesn't look good. Why can't we simply hardcode the proper behaviour based
> > on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> > other examples with different mapping?
>
> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> actually embedded into the CPU chip and the interrupt lines are hard wired so
> that all the gpio lines of the gpio controller share in total 8 irqs such that
> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> are fixed. I have no idea about the behavior of other kinds of controllers, which
> should be answered by Loongson personales.
OK.
> So far, there are known to be 2 styles of DSDT entries. One is defined by
> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> number listed in the ResourceTemplate. The former should now be compatible with
> the current implementation of the driver in the kernel, while the later not. I
> believe that although being abandoned by the spec, the later should also be
> considered and supported by the driver, since it is used by the firmwares in the
> wild.
This is clear. What's unclear is the necessity of adding this mapping. Is that
mapping shuffled in an arbitrary way?
Second question, why one can't update firmware to fix this to follow the
specification? From above DSDT I do *not* see the need in this mapping.
Everything can be simply deducted from the number of Interrupt() resources
and ngpios at run-time without touching the property.
> Looking forward to your advice on this.
>
> >>> The code in this patch is mostly picked from the version 5 of Yinbo's
> >>> original patch.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v12 4/6] dt-bindings: pinctrl: s32g2-siul2: describe GPIO and EIRQ resources
From: Bartosz Golaszewski @ 2026-07-01 7:47 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, linux-gpio, linux-kernel,
NXP S32 Linux Team, Pengutronix Kernel Team, Vincent Guittot,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla
In-Reply-To: <20260630125403.546375-5-khristineandreea.barbulescu@oss.nxp.com>
On Tue, 30 Jun 2026 14:54:01 +0200, Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> said:
> Extend the S32G2 SIUL2 pinctrl binding to describe the GPIO data and
> external interrupt resources present in the same SIUL2 hardware block.
>
> Besides the MSCR and IMCR registers used for pin multiplexing and pad
> configuration, SIUL2 also contains PGPDO and PGPDI registers
> for GPIO data and EIRQ registers for external interrupt control.
>
> Add GPIO controller properties because the SIUL2 block also provides
> GPIO functionality, and gpio-ranges are needed to describe the
> mapping between GPIO lines and pin controller pins.
>
> Document the interrupt controller properties. The SIUL2 block
> contains EIRQ hardware as part of the same register space. IRQ support
> itself will be added in a follow-up patch series.
>
> Update the example accordingly to show the complete SIUL2 register
> layout, including the GPIO data and EIRQ register windows.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v12 5/6] pinctrl: s32cc: implement GPIO functionality
From: Bartosz Golaszewski @ 2026-07-01 7:50 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, linux-gpio, linux-kernel,
NXP S32 Linux Team, Pengutronix Kernel Team, Vincent Guittot,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla
In-Reply-To: <20260630125403.546375-6-khristineandreea.barbulescu@oss.nxp.com>
On Tue, 30 Jun 2026 14:54:02 +0200, Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> said:
> From: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
>
> The updated SIUL2 block groups pinctrl, GPIO data access
> and interrupt control within the same hardware unit.
> The SIUL2 driver is therefore structured as a monolithic
> pinctrl/GPIO driver.
>
> GPIO data access and direction handling are implemented using the
> gpio-regmap library backed by a virtual regmap. The virtual regmap
> translates the gpio-regmap register model to the underlying SIUL2
> registers: MSCR for direction, PGPDI for input values and PGPDO for
> output values.
>
> The existing pinctrl GPIO callbacks are used for the request/free path:
> they switch the pad to GPIO mode on request and restore the previous
> MSCR configuration when the GPIO is released.
>
> This change came as a result of upstream review in the
> following series:
> https://lore.kernel.org/linux-gpio/20260120115923.3463866-4-khristineandreea.barbulescu@oss.nxp.com/T/#m543c9edbdde74bdc68b6a2364e8b975356c33043
> https://lore.kernel.org/all/20260504131148.3622697-7-khristineandreea.barbulescu@oss.nxp.com/
>
> Support both SIUL2 DT layouts:
> - legacy pinctrl-only binding
> - extended pinctrl/GPIO/irqchip binding
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v12 6/6] arm64: dts: s32g: describe GPIO and EIRQ resources in SIUL2 pinctrl node
From: Bartosz Golaszewski @ 2026-07-01 7:50 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, linux-gpio, linux-kernel,
NXP S32 Linux Team, Pengutronix Kernel Team, Vincent Guittot,
Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chester Lin, Matthias Brugger,
Ghennadi Procopciuc, Larisa Grigore, Lee Jones, Shawn Guo,
Sascha Hauer, Fabio Estevam, Dong Aisheng, Jacky Bai,
Greg Kroah-Hartman, Rafael J. Wysocki, Srinivas Kandagatla
In-Reply-To: <20260630125403.546375-7-khristineandreea.barbulescu@oss.nxp.com>
On Tue, 30 Jun 2026 14:54:03 +0200, Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> said:
> Update the SIUL2 pinctrl node to describe the additional register
> ranges and DT properties used by the updated SIUL2 driver.
>
> Besides the MSCR and IMCR ranges used for pinmux and pin
> configuration, the SIUL2 block also provides PGPDO and
> PGPDI registers for GPIO output and input operations,
> as well as an EIRQ register window for external interrupt configuration.
>
> The driver supports both legacy pinctrl-only DTs and
> extended DTs with GPIO and IRQ.
>
> Reflect these resources in the SIUL2 pinctrl node by adding:
> - the PGPDO and PGPDI register ranges
> - the EIRQ register range
> - gpio-controller, #gpio-cells and gpio-ranges
> - interrupt-controller, #interrupt-cells and interrupts
>
> Keep the hardware description aligned with the updated SIUL2
> driver, where pinctrl, GPIO data access and the EIRQ register
> block are described under the same device node.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 0/2] pinctrl: qcom: Introduce Pinctrl for the upcoming Maili SoC
From: Bartosz Golaszewski @ 2026-07-01 7:52 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jingyi Wang
Cc: Bartosz Golaszewski, aiqun.yu, tingwei.zhang, trilok.soni,
yijie.yang, linux-arm-msm, linux-gpio, devicetree, linux-kernel,
Krzysztof Kozlowski, Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260622-maili-pinctrl-v3-0-9724e1000471@oss.qualcomm.com>
On Mon, 22 Jun 2026 01:35:31 -0700, Jingyi Wang wrote:
> Introduce Top Level Mode Multiplexer dt-binding and driver for the
> upcoming Qualcomm Maili SoC. Maili is the new mobile SoC, and its DTS
> will be upstreamed later.
>
>
Applied, thanks!
[1/2] dt-bindings: pinctrl: qcom: Describe Maili TLMM block
https://git.kernel.org/brgl/c/e95f2b212c4a8ec422b1627e36e951e778809965
[2/2] pinctrl: qcom: Add the tlmm driver for Maili platform
https://git.kernel.org/brgl/c/251b53103a2e5770658ae106c490cdd2b7512c3a
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map
From: Miao Wang @ 2026-07-01 8:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Miao Wang via B4 Relay, Huacai Chen,
Jianmin Lv, WANG Xuerui, Jiaxun Yang, linux-gpio, Yinbo Zhu,
Linus Walleij, Hongchen Zhang, Liu Peibao, Juxin Gao,
Mika Westerberg
In-Reply-To: <akTDj-YJjuDOBc0i@ashevche-desk.local>
Hi,
> 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>
> On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
>>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
>>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
>>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
>>>
>>>>> This patch adds back the support for gsi_idx_map, which is used in the
>>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
>>>>> the index of the interrupt number in the declared interrupt resources.
>>>>>
>>>>> This property was removed in Loongson CPU Universal Specification for
>>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
>>>>> 2023, but still in use in firmwares released this year. A sample of
>>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
>>>
>>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
>>> developers before adding non-standard and wrongly named properties, please?
>>
>> Inferred from the time when gsi_idx_map was removed from the spec, I believe
>> that the removal might be because the maintainers suggestion against introducing
>> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
>
> But what is the outcome of not using that mapping. Do you have something wrong
> or not working?
Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
number of given interrupts in _CRS does not equal to ngpios. In my example,
ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
clarify, the entry is taken from the firmware I am currently using, and the
firmware is released on February this year.
>>>>> Device (GPO1) {
>>>>> Name (_HID, "LOON000F")
>>>>> Name (_CRS, ResourceTemplate () {
>>>>> QWordMemory ( // Omitted, not related
>>>>> )
>>>>> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
>>>>> 0x00000010, 0x00000011, 0x00000012, 0x00000013,
>>>>> 0x00000014, 0x00000015, 0x00000016, 0x00000017,
>>>>> }
>>>>> Name (_DSD, Package (0x02) {
>>>>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
>>>>> Package (0x03) {
>>>>> Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
>>>
>>> Yes, it's non-standard property. It's a broken one in terms of the style.
>>> See DT binding documentation.
>>
>> To clarify, I agree that this property should be redundant and ignored by
>> the driver and global gpio numbers should be assigned dynamically by the
>> kernel.
>>
>>>>> Package (0x02) { "ngpios", 0x20 }
>>>>> Package (0x02) { "gsi_idx_map", Package (0x20) {
>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
>>>>> 0, 1, 2, 3, 4, 5, 6, 7,
>>>>> }}
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
>>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
>>>>> for the line numbers largers than 7, it will fail with -ENXIO.
>>>
>>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
>>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
>>> other examples with different mapping?
>>
>> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
>> actually embedded into the CPU chip and the interrupt lines are hard wired so
>> that all the gpio lines of the gpio controller share in total 8 irqs such that
>> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
>> are fixed. I have no idea about the behavior of other kinds of controllers, which
>> should be answered by Loongson personales.
>
> OK.
>
>> So far, there are known to be 2 styles of DSDT entries. One is defined by
>> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
>> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
>> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
>> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
>> number listed in the ResourceTemplate. The former should now be compatible with
>> the current implementation of the driver in the kernel, while the later not. I
>> believe that although being abandoned by the spec, the later should also be
>> considered and supported by the driver, since it is used by the firmwares in the
>> wild.
>
> This is clear. What's unclear is the necessity of adding this mapping. Is that
> mapping shuffled in an arbitrary way?
According to the partial information I currently have, I don't think the mapping
would shuffle arbitrarily.
> Second question, why one can't update firmware to fix this to follow the
> specification? From above DSDT I do *not* see the need in this mapping.
> Everything can be simply deducted from the number of Interrupt() resources
> and ngpios at run-time without touching the property.
I have no idea why on the firmware side the spec was not followed for three
years. When ignoring this mapping, there would be a problem if the number
of given Interrupt() resources is less than ngpios. When this mapping is
referred, there will be a ground truth for which irq number a gpio line
belongs to. To be specific, suppose the number of Interrupt() resources
is m and ngpios is n. In the current spec, where m equals to n, such ground
truth also exists. However, when m is less than n and this mapping is
ignored, the mapping will become ambiguous. Should the irq number be i%m
for gpio line i, or i%8 and reject the irq requests when m is less than 8?
Cheers,
Miao Wang
^ permalink raw reply
* Re: [PATCH 24/32] drivers/gpio: Stop using 32-bit MSR interfaces
From: Linus Walleij @ 2026-07-01 8:13 UTC (permalink / raw)
To: Juergen Gross; +Cc: linux-kernel, linux-gpio, Bartosz Golaszewski
In-Reply-To: <20260629060526.3638272-25-jgross@suse.com>
Hi Jürgen,
On Mon, Jun 29, 2026 at 8:07 AM Juergen Gross <jgross@suse.com> wrote:
> The 32-bit MSR interfaces rdmsr() and wrmsr() are planned to be
> removed. Use the related 64-bit variants instead.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Is this something the subsystem maintainera are supposed to apply
directly on a per-subsystem basis? I was under that impression.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox