* Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue write commands
From: Fenglin Wu @ 2026-06-09 1:28 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: 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: <vmk6b6cd4jolhisfphgai35eznr5d5uwrhx2qktdwd2qayxwm5@fb2js7bw4dca>
On 6/8/2026 5:21 AM, Dmitry Baryshkov wrote:
> On Thu, Jun 04, 2026 at 10:02:43AM +0800, Fenglin Wu wrote:
>> On 6/2/2026 3:29 PM, Fenglin Wu wrote:
>>> On 6/1/2026 9:37 PM, Dmitry Baryshkov wrote:
>>>> On Thu, May 28, 2026 at 06:05:35PM -0700, Fenglin Wu wrote:
>>>>> Currently, the RPMH driver only allows child devices of the RPMH
>>>>> controller to issue commands, as it assumes dev->parent points to the
>>>>> RSC device.
>>>>>
>>>>> There is a possibility that certain devices which are not children of
>>>>> the RPMH controller want to send commands for special control at the
>>>>> RPMH side. For example, in PMH0101 PMICs, there are bidirectional
>>>>> level shifter (LS) peripherals, and each LS works with a pair of PMIC
>>>>> GPIOs. The control of the LS, which is combined with the GPIO
>>>>> configuration, is handled by RPMH firmware for sharing the resource
>>>>> between different subsystems. From a hardware point of view, the LS
>>>>> functionality is tied to a pair of PMIC GPIOs, so its control is more
>>>>> suitable to be added in the pinctrl-spmi-gpio driver by adding the
>>>>> level-shifter function. However, the pinctrl-spmi-gpio device is a
>>>>> child device of the SPMI controller, not the RPMH controller.
>>>> This replicates the story of the PMIC regulators. There are two drivers,
>>>> one SPMI and one RPMh. Why don't we add a separate, RPMh-based GPIO
>>>> driver targeting only those paired GPIOs (and we don't even need to
>>>> represent them as a pair, it might be just one pin).
>>> Thanks for the suggestion.
>>>
>>> I agree that adding a separate, RPMh-based GPIO driver would be more
>>> straightforward from RPMh control perspective. It makes the new device
>>> as a child of the RSC device then it can naturally use the APIs for RPMh
>>> commands. The main challenge here is, we need to make the level-shifter
>>> mutually exclusive with other GPIO functions when the GPIO pairs are
>>> used in level-shifter function, which means we need to write SPMI
>>> commands to disable the associated GPIO modules. I am not sure if AOP
>>> already handles this; as far as I know, AOP only manages the
>>> BIDIR_LVL_SHIFTER module registers. Let me double check on this
>>> internally, if the GPIO modules could be controlled along
>>> with BIDIR_LVL_SHIFTER module registers at AOP side, and get back.
>>>
>> I checked on this internally, AOP only handles BIDIR_LVL_SHIFTER module
>> registers, it doesn't disable the associated GPIO modules. Also, I still
>> have no idea how could we make the "level-shifter" function to be mutually
>> exclusive with other GPIO functions after moved it into a separate driver.
>> Do you have further suggestions?
> So, for my understanding, we still need to write SPMI registers to
> configure the pins and only then AOP can handle the level shifter?
>
> I was thinking of using gpio-reserved-ranges to prevent those GPIOs from
> being used by the normal SPMI driver.
More background: "level-shifter" module is actually an independent
hardware which is not part of the GPIO module. However, they are sharing
the physical pins. Which means, from PMIC chip perspective, these pins
can be configured to either a GPIO function or the "level-shifter"
function. So in PMIC base dtsi file, for example, pmh0101.dtsi, these
pins should not be restricted in the GPIO nodes in "gpio-reserved-ranges".
Also, we need to make the GPIO modules are disabled when the
"level-shifter" is enabled, to ensure that the "level-shifter" circuitry
is not impacted by the GPIO modules internal circuitry. So it is
supposed to write GPIO EN_CTL register (offset 0x46) to 0 through SPMI
bus when the "level-shifter" is enabled.
That's why we have the requirement to access both RPMh and SPMI bus in
the same driver.
^ permalink raw reply
* [PATCH] gpio: mockup: reject invalid gpio_mockup_ranges widths
From: Samuel Moelius @ 2026-06-09 0:45 UTC (permalink / raw)
To: Bamvor Jian Zhang
Cc: Samuel Moelius, Linus Walleij, Bartosz Golaszewski,
open list:GPIO MOCKUP DRIVER, open list
gpio-mockup validates only that each second gpio_mockup_ranges value is
non-negative before creating the mock chips. The fixed-base form uses
the second value as the first GPIO number after the range, while the
dynamic-base form uses it as the number of GPIOs.
gpio_mockup_register_chip() stores the resulting number of GPIOs in a
u16 and passes it through a PROPERTY_ENTRY_U16("nr-gpios", ...). Values
greater than U16_MAX therefore truncate silently. For example,
gpio_mockup_ranges=-1,65537 creates a one-line mock GPIO chip instead of
rejecting the invalid request.
Reject zero-width, reversed, and over-U16 ranges before registering any
mock chip.
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
---
drivers/gpio/gpio-mockup.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index a7d69f3835c1..91ff789c4fa6 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -17,6 +17,7 @@
#include <linux/irq.h>
#include <linux/irq_sim.h>
#include <linux/irqdomain.h>
+#include <linux/limits.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/platform_device.h>
@@ -578,7 +579,7 @@ static int __init gpio_mockup_register_chip(int idx)
static int __init gpio_mockup_init(void)
{
- int i, num_chips, err;
+ int i, num_chips, err, base, ngpio;
if ((gpio_mockup_num_ranges % 2) ||
(gpio_mockup_num_ranges > GPIO_MOCKUP_MAX_RANGES))
@@ -592,8 +593,19 @@ static int __init gpio_mockup_init(void)
* always be greater than 0.
*/
for (i = 0; i < num_chips; i++) {
- if (gpio_mockup_range_ngpio(i) < 0)
+ base = gpio_mockup_range_base(i);
+ ngpio = gpio_mockup_range_ngpio(i);
+
+ if (ngpio <= 0)
return -EINVAL;
+
+ if (base < 0) {
+ if (ngpio > U16_MAX)
+ return -EINVAL;
+ } else {
+ if (ngpio <= base || ngpio - base > U16_MAX)
+ return -EINVAL;
+ }
}
gpio_mockup_dbg_dir = debugfs_create_dir("gpio-mockup", NULL);
--
2.43.0
^ permalink raw reply related
* Re: [GIT PULL] pinctrl: renesas: Updates for v7.2 (take three)
From: Linus Walleij @ 2026-06-08 23:00 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-gpio, linux-renesas-soc
In-Reply-To: <cover.1780909189.git.geert+renesas@glider.be>
On Mon, Jun 8, 2026 at 11:01 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> The following changes since commit 80538a53978bb9788080caea6e5ee3393dfb6a72:
>
> pinctrl: renesas: rzg2l: Use tab instead of spaces (2026-05-28 15:07:29 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git tags/renesas-pinctrl-for-v7.2-tag3
>
> for you to fetch changes up to 14270179806b876fecefcbf35905e512b56a5867:
>
> pinctrl: renesas: rzg2l: Use raw_spinlock_irqsave() on power source update (2026-06-05 11:44:54 +0200)
Pulled in, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/7] gpio: move ppc4xx driver to drivers/gpio and modernize
From: Linus Walleij @ 2026-06-08 22:59 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-gpio, Madhavan Srinivasan, chleroy, Michael Ellerman,
Nicholas Piggin, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <CAKxU2N_LhgDj-+-gd0_N9gQOzCddq7dypYhayFQ_09zggpor6Q@mail.gmail.com>
On Tue, Jun 9, 2026 at 12:20 AM Rosen Penev <rosenp@gmail.com> wrote:
> > I guess we should provide some slack so someone from the PPC
> > camp can test it, and if they don't test it, then it is abandoned and
> > we should then just apply it anyway.
> Hmm? I have the hardware. It works fine.
I missed it because it's only mentioned briefly in patch 3.
But sounds all solid then!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: PINCTRL_STMFX should depend on CONFIG_OF
From: Linus Walleij @ 2026-06-08 22:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: Bartosz Golaszewski, linux-gpio, amelie.delaunay
In-Reply-To: <20260602211116.2033792-1-ttabi@nvidia.com>
On Tue, Jun 2, 2026 at 11:11 PM Timur Tabi <ttabi@nvidia.com> wrote:
> Commit e785c990adcc ("pinctrl: Kconfig: drop unneeded dependencies
> on OF_GPIO") removed a redundant dependecy on CONFIG_OF_GPIO for
> several pinctrl drivers, but this change also removed a dependency
> on CONFIG_OF for some of those drivers.
>
> Normally, this wouldn't be a problem, but PINCTRL_STMFX also selected
> MFD_STMFX, which does depend on CONFIG_OF. This conflict allows
> MFD_STMFX to be enabled even if CONFIG_OF is disabled.
>
> Fix this by also having PINCTRL_STMFX depend on CONFIG_OF. This is
> okay because the pinctrl-stmfx driver actually does depend on CONFIG_OF
> functions.
>
> Fixes: e785c990adcc ("pinctrl: Kconfig: drop unneeded dependencies on OF_GPIO")
> Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: pinctrl: realtek,rtd1625: Fix input voltage property name
From: Linus Walleij @ 2026-06-08 22:47 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: robh, krzk+dt, conor+dt, tychang, linux-gpio, devicetree,
linux-kernel, cy.huang, stanley_chang, james.tai
In-Reply-To: <20260601075229.2936513-1-eleanor.lin@realtek.com>
On Mon, Jun 1, 2026 at 9:52 AM Yu-Chun Lin <eleanor.lin@realtek.com> wrote:
> The property 'input-voltage-microvolt' is a typo. Rename it to
> 'input-threshold-voltage-microvolt' to align with the standard pin
> configuration defined in pincfg-node.yaml and parsed by pinconf-generic.c.
>
> Fixes: f6ea7004e926 ("dt-bindings: pinctrl: realtek: Add RTD1625 pinctrl binding")
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: pinctrl: mediatek: mt6795: document the slew-rate property
From: Linus Walleij @ 2026-06-08 22:46 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Sean Wang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260601152707.29039-1-l.scorcia@gmail.com>
On Mon, Jun 1, 2026 at 5:27 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> The driver for MT6795 pinctrl already supports the slew-rate property.
> Add its description to the documentation.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] serial: max310x: implement gpio_chip::get_direction()
From: Linus Walleij @ 2026-06-08 22:45 UTC (permalink / raw)
To: Tapio Reijonen
Cc: Greg Kroah-Hartman, Jiri Slaby, Bartosz Golaszewski,
Alexander Shiyan, linux-kernel, linux-serial, linux-gpio
In-Reply-To: <20260602-b4-serial-max310x-gpio-get-direction-v1-1-23bf84e8ee14@vaisala.com>
On Tue, Jun 2, 2026 at 12:02 PM Tapio Reijonen
<tapio.reijonen@vaisala.com> wrote:
> It's strongly recommended for GPIO drivers to always implement the
> .get_direction() callback - even when the direction is tracked in
> software. The GPIO core emits a warning when the callback is missing
> and a user reads the direction of a line, e.g. via
> /sys/kernel/debug/gpio.
>
> The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit
> selects output), which the existing direction_input/output callbacks
> already program, so the current direction can be read back directly.
>
> Fixes: f65444187a66 ("serial: New serial driver MAX310X")
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/5] pinctrl: qcom: Add gp_mn mux function for QCS8300, SA8775P and SC7280
From: Linus Walleij @ 2026-06-08 22:43 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Richard Cochran,
Konrad Dybcio, Ajit Pandey, Imran Shaik, Jagadeesh Kona,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-gpio,
netdev
In-Reply-To: <20260602-pdm_clk_gp_mnd_v1-v1-3-1522662b6c53@oss.qualcomm.com>
On Tue, Jun 2, 2026 at 5:22 PM Taniya Das <taniya.das@oss.qualcomm.com> wrote:
> Add the gp_mn pin mux function to the TLMM pin controllers for the
> QCS8300, SA8775P and SC7280 SoCs. This function exposes the GP M/N
> divider clock output on a dedicated GPIO pin, allowing the clock signal
> to be routed externally.
>
> - QCS8300: gpio32
> - SA8775P: gpio35
> - SC7280: gpio60
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
This looks all right and no-one is saying anything about it, should
I just apply this one patch to the pin control tree? It doesn't seem
to have any dependencies.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v9 6/7] pinctrl: s32cc: implement GPIO functionality
From: Linus Walleij @ 2026-06-08 22:33 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: 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,
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
In-Reply-To: <48494e7b-4cba-4372-9090-f40240d820c4@oss.nxp.com>
Hi Khristine,
On Tue, Jun 2, 2026 at 10:05 AM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
> The new version (v10) has been updated to use gpio-regmap, with a virtual
> regmap bridge dispatching GPIO accesses to the underlying SIUL2 register
> blocks.
>
> I am not fully convinced this is the cleanest model, though.
> SIUL2 does not expose GPIO as one regular register space: direction is in
> MSCR, input values are read from PGPDI, and output values are written through
> PGPDO. These are backed by separate regmaps in the driver, while gpio-regmap
> expects a single regmap.
OK I did miss that detail earlier, I definitely thought it was using a single
regmap.
> So the current path becomes:
> gpio-regmap -> virtual regmap -> MSCR/PGPDI/PGPDO regmap
>
> The version was updated this way so we can review the approach on top of the
> current code. If this is still the preferred direction, it can be polished
> further. Otherwise, I think direct gpio_chip callbacks using the existing regmap
> helpers might be a simpler fit for this hardware.
>
> What do you think would be the preferred direction for the next revision?
I'm pretty much happy with either version.
I see your point as to why you don't want to use gpio-regmap.
I also think the virtual regmap thing looks pretty OK, it's complex
but the driver is complex anyway.
What could make the gpio-regmap approach is that it will probably
get extended with get/set_multiple() at some point and then you
will get that improvement for free.
But I think you are the best person to choose what to use here,
if you don't think the virtual regmap looks good, then trust your
intuition and go back to the old design.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 2/2] pinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver
From: Linus Walleij @ 2026-06-08 22:23 UTC (permalink / raw)
To: wangjia
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260608-ultrarisc-pinctrl-v3-2-30a09ed74275@ultrarisc.com>
Hi Jia,
thanks for your patch!
On Mon, Jun 8, 2026 at 9:50 AM Jia Wang via B4 Relay
<devnull+wangjia.ultrarisc.com@kernel.org> wrote:
> From: Jia Wang <wangjia@ultrarisc.com>
>
> Add support for the pin controller on the UltraRISC DP1000 SoC.
>
> The controller provides mux selection for pins in ports A, B, C, D, and
> LPC. Ports A-D default to GPIO and support peripheral muxing. LPC pins
> can be switched to eSPI, but are not available as GPIOs. Basic pin
> configuration controls such as drive strength, pull-up, and pull-down
> are also supported.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Overall this looks very good, some things to fix up below but nothing
major!
(...)
> +config PINCTRL_ULTRARISC
> + tristate
> + depends on OF
> + depends on ARCH_ULTRARISC || COMPILE_TEST
> + select GENERIC_PINCTRL
> + select PINMUX
> + select GPIOLIB
Why GPIOLIB? You don't implement any GPIO chips...
> + raw_spin_lock_irqsave(&pctrl->lock, flags);
> + val = readl_relaxed(reg);
> + val = (val & ~mask) | field_prep(mask, conf);
> + writel_relaxed(val, reg);
> + raw_spin_unlock_irqrestore(&pctrl->lock, flags);
Have you thought about using a scoped guard for this lock?
It will make the code easier to read.
(Applies everywhere.)
> +static int ur_find_group_route(struct ur_pinctrl *pctrl,
> + const char *function,
> + u64 group_mask,
> + const struct ur_func_route **route_out)
> +{
> + const struct ur_func_route *match = NULL;
> +
> + for (u32 i = 0; i < pctrl->data->num_routes; i++) {
> + const struct ur_func_route *route = &pctrl->data->routes[i];
> +
> + if (strcmp(route->function, function))
> + continue;
> +
> + if ((route->valid_pins & group_mask) != group_mask)
> + continue;
> +
> + if (match) {
> + dev_err(pctrl->dev,
> + "ambiguous route for function %s group_mask=%#llx\n",
> + function, (unsigned long long)group_mask);
> + return -EINVAL;
> + }
> +
> + match = route;
> + }
> +
> + if (match) {
> + *route_out = match;
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
This routing function needs some kind of comment before it explaining
what is going on and what constraints you are trying to resolve with this.
> +static bool ur_function_is_gpio(struct pinctrl_dev *pctldev,
> + unsigned int selector)
Neat that you implement this!
> +static const struct pinctrl_ops ur_pinctrl_ops = {
> + .get_groups_count = pinctrl_generic_get_group_count,
> + .get_group_name = pinctrl_generic_get_group_name,
> + .get_group_pins = pinctrl_generic_get_group_pins,
> + .dt_node_to_map = pinctrl_generic_pins_function_dt_node_to_map,
> + .dt_free_map = pinconf_generic_dt_free_map,
> +};
Good use of generic helpers!
> +static const struct pinmux_ops ur_pinmux_ops = {
> + .get_functions_count = pinmux_generic_get_function_count,
> + .get_function_name = pinmux_generic_get_function_name,
> + .get_function_groups = pinmux_generic_get_function_groups,
> + .function_is_gpio = ur_function_is_gpio,
> + .set_mux = ur_set_mux,
> + .gpio_request_enable = ur_gpio_request_enable,
> + .strict = true,
> +};
Here too.
> +static const struct pinconf_ops ur_pinconf_ops = {
> + .pin_config_get = ur_pin_config_get,
> + .pin_config_set = ur_pin_config_set,
> + .pin_config_group_get = ur_pin_config_group_get,
> + .pin_config_group_set = ur_pin_config_group_set,
> +#ifdef CONFIG_GENERIC_PINCONF
> + .is_generic = true,
> + .pin_config_config_dbg_show = pinconf_generic_dump_config,
> +#endif
Why ifdef:ed? Just select it in your Kconfig and rely on it?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/7] gpio: move ppc4xx driver to drivers/gpio and modernize
From: Rosen Penev @ 2026-06-08 22:20 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-gpio, Madhavan Srinivasan, chleroy, Michael Ellerman,
Nicholas Piggin, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <CAD++jLmk3jMFS0DD0GGTV9AWu-oHJAoxymcyOKQycVFqKCRnzA@mail.gmail.com>
On Mon, Jun 8, 2026 at 3:10 PM Linus Walleij <linusw@kernel.org> wrote:
>
> Hi Rosen,
>
> On Tue, Jun 2, 2026 at 7:01 AM Rosen Penev <rosenp@gmail.com> wrote:
>
> > This series moves the ppc4xx GPIO driver from arch/powerpc to
> > drivers/gpio, converts it to be a proper platform driver using
> > generic MMIO helpers, drops architecture-specific accessors, and
> > prepares it for module build and COMPILE_TEST.
> >
> > Patches 1-4 move the driver and convert it to standard platform
> > driver infrastructure. Patch 5 switches to generic MMIO helpers.
> > Patch 6 drops PPC-specific IO accessors and enables COMPILE_TEST.
> > Patch 7 adds the missing MODULE metadata so the driver can actually
> > be built as a module.
> >
> > Rosen Penev (7):
> > gpio: move ppc4xx gpio driver from arch/powerpc to drivers/gpio
> > gpio: ppc44x: Use module platform driver helper for GPIO
> > gpio: ppc44x: Set GPIO chip firmware node
> > gpio: ppc44x: Use platform resource helper for GPIO MMIO
> > gpio: ppc44x: Convert GPIO to generic MMIO
> > gpio: ppc44x: drop PPC-specific IO helpers and rename to ppc44x
> > gpio: ppc44x: add MODULE info
>
> Overall a very nice patch series and happy to see that AI can
> assist with this kind of refactoring!
>
> I guess we should provide some slack so someone from the PPC
> camp can test it, and if they don't test it, then it is abandoned and
> we should then just apply it anyway.
Hmm? I have the hardware. It works fine.
>
> The series:
> Reviewed-by: Linus Walleij <linusw@kernel.org>
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/7] gpio: move ppc4xx driver to drivers/gpio and modernize
From: Linus Walleij @ 2026-06-08 22:10 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-gpio, Madhavan Srinivasan, chleroy, Michael Ellerman,
Nicholas Piggin, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260602050131.856789-1-rosenp@gmail.com>
Hi Rosen,
On Tue, Jun 2, 2026 at 7:01 AM Rosen Penev <rosenp@gmail.com> wrote:
> This series moves the ppc4xx GPIO driver from arch/powerpc to
> drivers/gpio, converts it to be a proper platform driver using
> generic MMIO helpers, drops architecture-specific accessors, and
> prepares it for module build and COMPILE_TEST.
>
> Patches 1-4 move the driver and convert it to standard platform
> driver infrastructure. Patch 5 switches to generic MMIO helpers.
> Patch 6 drops PPC-specific IO accessors and enables COMPILE_TEST.
> Patch 7 adds the missing MODULE metadata so the driver can actually
> be built as a module.
>
> Rosen Penev (7):
> gpio: move ppc4xx gpio driver from arch/powerpc to drivers/gpio
> gpio: ppc44x: Use module platform driver helper for GPIO
> gpio: ppc44x: Set GPIO chip firmware node
> gpio: ppc44x: Use platform resource helper for GPIO MMIO
> gpio: ppc44x: Convert GPIO to generic MMIO
> gpio: ppc44x: drop PPC-specific IO helpers and rename to ppc44x
> gpio: ppc44x: add MODULE info
Overall a very nice patch series and happy to see that AI can
assist with this kind of refactoring!
I guess we should provide some slack so someone from the PPC
camp can test it, and if they don't test it, then it is abandoned and
we should then just apply it anyway.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/6] leds: is31fl319x: Fix shutdown GPIO initial state and remove redundant startup pulse
From: Linus Walleij @ 2026-06-08 22:03 UTC (permalink / raw)
To: Jun Yan
Cc: dmitry.baryshkov, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Bartosz Golaszewski, Vincent Knecht, Grant Feng, Andre Przywara,
Geert Uytterhoeven, Viresh Kumar, Florian Fainelli, Robert Marko,
Pavel Machek, Krzysztof Kozlowski, Shawn Guo, Michal Simek,
Heiko Stuebner, linux-leds, devicetree, linux-kernel,
linux-arm-msm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260525144629.498630-3-jerrysteve1101@gmail.com>
Hi Jun,
thanks for your patch!
On Mon, May 25, 2026 at 4:47 PM Jun Yan <jerrysteve1101@gmail.com> wrote:
> - is31->shutdown_gpio = devm_gpiod_get_optional(dev, "shutdown", GPIOD_OUT_HIGH);
> + /* Driving this GPIO line low (in fact high) takes the chip out of shutdown,
> + * as it is flagged as GPIO_ACTIVE_LOW in provider (such as the device tree).
> + */
> + is31->shutdown_gpio = devm_gpiod_get_optional(dev, "shutdown", GPIOD_OUT_LOW);
This is fine but only if you also add a quirk to
drivers/gpio/gpiolib-of.c in of_gpio_try_fixup_polarity()
that will enforce the GPIOD_OUT_LOW property on the line.
Follow the examples.
This solves the API breakage.
It should probably be part of the same patch for bisectability.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins 34-39
From: Linus Walleij @ 2026-06-08 21:56 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Fabien Parent, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260531162340.5326-1-l.scorcia@gmail.com>
On Sun, May 31, 2026 at 6:23 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> The correct Schmitt trigger register offset for pins 34-39 is 0xA00. Value
> was verified with SoC data sheet.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Fixes: 82d70627e94a ("pinctrl: mediatek: Add MT8167 Pinctrl driver")
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins 34-39
From: Linus Walleij @ 2026-06-08 21:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Fabien Parent, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260531162237.5290-1-l.scorcia@gmail.com>
On Sun, May 31, 2026 at 6:23 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> The correct Schmitt trigger register offset for pins 34-39 is 0xA00.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Fixes: 264667112ef0 ("pinctrl: mediatek: Add MT8516 Pinctrl driver")
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] gpiolib: handle gpio-hogs only once
From: Daniel Drake @ 2026-06-08 21:01 UTC (permalink / raw)
To: linusw, brgl; +Cc: linux-gpio, linux-arm-kernel, Daniel Drake
Commit d1d564ec49929 ("gpio: move hogs into GPIO core") introduced a
behaviour change that breaks boot on Raspberry Pi 5 when using the
firmware-supplied device tree:
gpiochip_add_data_with_key: GPIOs 544..575
(/soc@107c000000/gpio@7d517c00) failed to register, -22
brcmstb-gpio 107d517c00.gpio: Could not add gpiochip for bank 1
brcmstb-gpio 107d517c00.gpio: probe with driver brcmstb-gpio failed
with error -22
gpio-brcmstb registers two gpio_chips against the device tree
node gpio@7d517c00, one for each bank. The firmware-supplied DT includes
a gpio-hog on RP1 RUN, and this gpio-hog is attempted to be applied to
*both* gpio_chips. This succeeds against bank 0 (which hosts the GPIO)
and fails for bank 1 (which does not).
In the previous implementation, failures to apply gpio-hogs were
quietly ignored. In the new code, the error code propagates and causes
probe to fail.
Closely approximate the previous behaviour by using the OF_POPULATED flag
to ensure that each gpio-hog is processed only once. The flag was
previously being set before the gpio-hogs were processed, so as part
of this change, the flag now gets set only after the gpio-hog is actioned.
The handling of gpio-hogs on a DT node with multiple gpio_chips remains a
bit incomplete/unclear, but this at least retains the ability to apply
hogs to the first gpio_chip per node.
Signed-off-by: Daniel Drake <dan@reactivated.net>
---
drivers/gpio/gpiolib-of.c | 5 -----
drivers/gpio/gpiolib.c | 8 ++++++++
2 files changed, 8 insertions(+), 5 deletions(-)
v2: move OF_POPULATED flag setting to happen after the gpio-hog has
been applied (otherwise all hogs were considered already-applied
and never applied at all, oops!)
This bug is only exposed by the RPi5 firmware-provided DT that has the
gpio-hog. The DT shipped in the mainline kernel does not have the hog
here. I'm not sure to what extent Linux cares about supporting the
downstream firmware DT.
I'm also happy to consider other approaches. This multi-gpiochip setup is
a bit weird and gpio-brcmstb could perhaps be converted to register only a
single gpio_chip covering all banks. I verified that the other drivers
that obviously follow this same multiple-gpiochip pattern
(pinctrl-amlogic-a4, pinctrl-st and pinctrl-stm32) do not seem to be used by
any board DTs that include gpio-hogs.
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 2c923d17541f..813dbcb91f6f 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -1066,11 +1066,6 @@ int of_gpiochip_add(struct gpio_chip *chip)
of_node_get(np);
- for_each_available_child_of_node_scoped(np, child) {
- if (of_property_read_bool(child, "gpio-hog"))
- of_node_set_flag(child, OF_POPULATED);
- }
-
return ret;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1e6dce430dca..b02d711289d0 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1031,9 +1031,17 @@ static int gpiochip_hog_lines(struct gpio_chip *gc)
if (!fwnode_property_present(fwnode, "gpio-hog"))
continue;
+ /* The hog may have been handled by another gpio_chip on the same fwnode */
+ if (is_of_node(fwnode) &&
+ of_node_check_flag(to_of_node(fwnode), OF_POPULATED))
+ continue;
+
ret = gpiochip_add_hog(gc, fwnode);
if (ret)
return ret;
+
+ if (is_of_node(fwnode))
+ of_node_set_flag(to_of_node(fwnode), OF_POPULATED);
}
return 0;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v8 6/6] pinctrl: mediatek: Add MT6735 pinctrl driver
From: Linus Walleij @ 2026-06-08 19:41 UTC (permalink / raw)
To: Yassine Oudjana
Cc: Sean Wang, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Andy Teng,
Yassine Oudjana, linux-mediatek, linux-gpio, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260530145800.1029920-7-y.oudjana@protonmail.com>
Hi Yassine,
thanks for your patch!
On Sat, May 30, 2026 at 4:58 PM Yassine Oudjana
<yassine.oudjana@gmail.com> wrote:
> From: Yassine Oudjana <y.oudjana@protonmail.com>
>
> Add a driver for the MediaTek MT6735 SoC pin controller. This driver
> also supports the pin controller on MT6735M, which lacks 6 physical
> pins (198-203) used for MSDC2 on MT6735.
>
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
Sashiko has good comments on this driver, look into them!
> +config PINCTRL_MT6735
> + bool "MediaTek MT6735(M) pin control"
> + depends on OF
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK_PARIS
There are in-flight patches to make MTK drivers tristate for
the Android GKI. Do you want to use tristate for this driver too?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/3] pinctrl: qcom: Correct MSM_PULL_MASK and fix resolving TLMM register address.
From: Linus Walleij @ 2026-06-08 19:31 UTC (permalink / raw)
To: Sneh Mankad
Cc: Bjorn Andersson, Yuanjie Yang, linux-arm-msm, linux-gpio,
linux-kernel
In-Reply-To: <20260529-tlmm_test_changes-v1-0-88bfdccb4369@oss.qualcomm.com>
Hi Sneh,
thanks for your patches!
On Fri, May 29, 2026 at 2:56 PM Sneh Mankad
<sneh.mankad@oss.qualcomm.com> wrote:
> Modify MSM_PULL_MASK to accurately represent the hardware configuration.
> Also fix the register address resolution when 'reg-names' property is
> not present in device node.
>
> Also avoid assigning thread_op_remain in unthreaded test since it is
> only used by threaded IRQ handler.
>
> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
> ---
> Sneh Mankad (3):
> pinctrl: qcom: Modify MSM_PULL_MASK to accurately represent PULL bits
> pinctrl: qcom: Fix resolving register base address from device node
Patches 1 & 2 applied since they are ACKed and look good.
> pinctrl: qcom: Avoid assigning thread_op_remain in unthreaded test
There are comments on this one so revise and resend this one only.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/2] pinctrl: mediatek: Enable MT8189 as loadable module
From: Linus Walleij @ 2026-06-08 19:29 UTC (permalink / raw)
To: Justin Yeh
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260529100308.51271-1-justin.yeh@mediatek.com>
On Fri, May 29, 2026 at 12:04 PM Justin Yeh <justin.yeh@mediatek.com> wrote:
> This series enables PINCTRL_MT8189 to be built as a loadable kernel
> module, which is required for GKI (Generic Kernel Image) + vendor_dlkm
> deployments where vendor-specific drivers must be kept separate from
> the GKI vmlinux.
Maybe tell us that this is for Android?
> Patch 1 restores the tristate option that was recently changed to bool,
No the driver was merged with tristate.
See
commit a3fe1324c3c5c292ec79bd756497c1c44ff247d2 (tag: pinctrl-v6.17-1)
"pinctrl: mediatek: Add pinctrl driver for mt8189"
> preventing module builds. Patch 2 adds the missing MODULE_LICENSE macro
> that's required when building as a module.
So that should be squashed into one patch or it will not bisect.
> Together these changes allow MT8189 pinctrl to be properly packaged as
> a vendor kernel module while maintaining the existing built-in option.
So why do we change this only for MT8189 and not for all
Mediatek pinctrl drivers?
I would just add this tristate option and license to all of them while
you're at it or I will get like 20 identical patches and it's a waste
of time for me.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] gpio: mt7621: fix interrupt banks mapping on gpio chips
From: Vicente Bergas @ 2026-06-08 19:21 UTC (permalink / raw)
To: Sergio Paracuellos
Cc: Bartosz Golaszewski, linusw, tglx, grant.likely, linux-kernel,
linux-gpio
In-Reply-To: <CAMhs-H-dnR7KjOZYv+rSt=n4MwPd5O1g9kfoP99uA7TQASf0WQ@mail.gmail.com>
On Mon, Jun 8, 2026 at 4:27 PM Sergio Paracuellos
<sergio.paracuellos@gmail.com> wrote:
>
> On Mon, Jun 8, 2026 at 4:02 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >
> > On Mon, 8 Jun 2026 11:40:57 +0200, Sergio Paracuellos
> > <sergio.paracuellos@gmail.com> said:
> > > Hi,
> > >
> > > On Mon, Jun 8, 2026 at 11:05 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > >>
> > >> On Tue, 2 Jun 2026 16:25:13 +0200, Sergio Paracuellos
> > >> <sergio.paracuellos@gmail.com> said:
> > >> > The GPIO controller's registers are organized as sets of eight 32-bit
> > >> > registers with each set controlling a bank of up to 32 pins. A single
> > >> > interrupt is shared for all of the banks handled by the controller.
> > >> > The driver implements this using three gpio chip instances every one
> > >> > with its own irq chip. Every single pin can generate interrupts having
> > >> > a total of 96 possible interrupts here. It looks like there is a problem
> > >> > with interrupts being properly mapped to the gpio bank using this solution.
> > >> > This problem report is in the following lore's link [0].
> > >> >
> > >> > Device tree is using two cells for this, so only the interrupt pin and the
> > >> > interrupt type are described there. Changing to have three cells to setup
> > >> > also the bank and implement 'of_node_instance_match()' would also work but
> > >> > this would be an ABI breakage and also a bit incoherent since gpios itself
> > >> > are also using two cells and properly mapped in desired bank using through
> > >> > its pin number on 'of_xlate()'.
> > >> >
> > >> > That said, register a linear IRQ domain of the total of 96 interrupts shared
> > >> > with the three gpio chip instances so the bank and the interrupt is properly
> > >> > decoded and devices using gpio IRQs properly work.
> > >> >
> > >> > [0]: https://lore.kernel.org/linux-gpio/CAAMcf8C_A9dJ_v4QRKtb9eGNOpJ7BZNOGsFP4i2WFOZxOVBPnQ@mail.gmail.com/T/#u
> > >> >
> > >> > Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
> > >> > Co-developed-by: Vicente Bergas <vicencb@gmail.com>
> > >> > Signed-off-by: Vicente Bergas <vicencb@gmail.com>
> > >> > Tested-by: Vicente Bergas <vicencb@gmail.com>
> > >> > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
> > >> > ---
> > >>
> > >> Hi!
> > >>
> > >> Can you look at the sashiko review? Especially the bit about tracking the
> > >> GPIOD_FLAG_IRQ_IS_ENABLED flag looks correct.
> > >
> > > I got rid of those two calls (gpiochip_enable_irq() and
> > > gpiochip_disable_irq()) because the driver "gpio-brcmstb" which is the
> > > one I based my changes on was not used them at all. We have not found
> > > anything weird related with that on testing. I do believe that since
> > > we are using our own callbacks for 'irq_request_resources()' and
> > > 'irq_release_resources()' we are safe here. Regarding the others I am
> > > not sure, but the introduction of the remove stuff for the irq domain
> > > is because there are no devm_* functions for that. Other resources in
> > > driver are using devm versions so I think the changes are ok as they
> > > are...
> > >
> >
> > It's about GPIO core: a GPIO that appears as "free" (users can request it) but
> > was earlier enabled for interrupts cannot be requested in output mode - only
> > input works. Without this flag set, gpiod_direction_output_nonotify() will allow
> > you to set direction to output.
>
> I see. I need Vicente to re-test without removing
> gpiochip_enable_irq() and gpiochip_disable_irq() to see if everything
> is still ok.
>
> Vicente, would you mind to test the following change on top of this v2 PATCH?
>
> diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> index c36aa0abd0c6..a814885ccd5d 100644
> --- a/drivers/gpio/gpio-mt7621.c
> +++ b/drivers/gpio/gpio-mt7621.c
> @@ -144,6 +144,8 @@ mediatek_gpio_irq_unmask(struct irq_data *d)
> u32 mask = mt7621_gpio_hwirq_to_offset(d->hwirq, rg);
> u32 rise, fall, high, low;
>
> + gpiochip_enable_irq(gc, mask);
> +
> guard(gpio_generic_lock_irqsave)(&rg->chip);
>
> rise = mtk_gpio_r32(rg, GPIO_REG_REDGE);
> @@ -174,6 +176,8 @@ mediatek_gpio_irq_mask(struct irq_data *d)
> mtk_gpio_w32(rg, GPIO_REG_HLVL, high & ~BIT(mask));
> mtk_gpio_w32(rg, GPIO_REG_LLVL, low & ~BIT(mask));
> }
> +
> + gpiochip_disable_irq(gc, mask);
> }
>
> Thanks,
> Sergio Paracuellos
Hi Sergio, test successful.
I tested the buttons and touch and it still works.
I did _not_ test if the irqs are disallowed to be used as gpios in output mode.
Regards,
Vicente.
^ permalink raw reply
* Re: [PATCH RFC 1/2] pinctrl: qcom: eliza: Fix HDMI_RCV_DET function slot
From: Alexander Koskovich @ 2026-06-08 18:41 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Linus Walleij, linux-arm-msm, linux-gpio,
linux-kernel
In-Reply-To: <109ad54c-f17f-49ea-9d7f-54e13dd367da@oss.qualcomm.com>
On Monday, June 8th, 2026 at 7:55 AM, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> On 5/28/26 7:24 PM, Alexander Koskovich wrote:
> > On Thursday, April 23rd, 2026 at 7:08 PM, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> >
> >> On 4/23/26 6:51 AM, Alexander Koskovich wrote:
> >>> The hdmi_rcv_det function was placed at alt function slot 2, but the
> >>> correct mux value for this function on GPIO 19 is slot 3. Move it
> >>> accordingly and leave slot 2 unassigned.
> >>
> >> No, 2 is the desired one per docs
> >>
> >> 0 -> GPIO
> >> 1 -> QUP2_SE5_L3
> >> 2 -> HDMI_RCV_DET
> >
> > Is it possible that CQ7790S is a special case? The pin assignment I have for it
> > here is:
> >
> > 0 -> GPIO
> > 1 -> QUP2_SE5_L3
> > 2 -> N/A
> > 3 -> GP_PDM_MIRA[0]/HDMI_RCV_DET
>
> I was reassured that my source has the latest information
>
> For reference, does your reference doc have any 80-xxxx-xx-like number?
Yes, the document I am referencing is 80-97791-1A, though since you've double
checked likely just means this is is incorrect?
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: pinctrl: Add UltraRISC DP1000 pinctrl controller
From: Conor Dooley @ 2026-06-08 17:17 UTC (permalink / raw)
To: wangjia
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260608-ultrarisc-pinctrl-v3-1-30a09ed74275@ultrarisc.com>
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
On Mon, Jun 08, 2026 at 03:50:48PM +0800, Jia Wang via B4 Relay wrote:
> From: Jia Wang <wangjia@ultrarisc.com>
>
> Add doc for the pinctrl controllers on the UltraRISC DP1000 RISC-V SoC.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> .../bindings/pinctrl/ultrarisc,dp1000-pinctrl.yaml | 131 +++++++++++++++++++++
> MAINTAINERS | 6 +
> .../dt-bindings/pinctrl/ultrarisc,dp1000-pinctrl.h | 63 ++++++++++
The driver never uses this file, so just stick it as a header in
arch/riscv/boot/dts/ultrarisc instead of making it a binding.
Otherwise, I think this is okay. With the file moved,
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: changes-requested
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: tegra238: add missing AON pin groups
From: Conor Dooley @ 2026-06-08 17:08 UTC (permalink / raw)
To: Prathamesh Shete
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Jonathan Hunter, Arnd Bergmann, linux-gpio,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260608094122.1245189-1-pshete@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 16/18] pinctrl: airoha: an7583: remove an7583 prefix from variable names
From: Bartosz Golaszewski @ 2026-06-08 16:17 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-17-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:52 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> We have only an7583 specific code in the pinctrl-an7583 kernel module,
> so 'an75831_' prefix is not necessary anymore. Remove it.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
page: next (older)
- 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