* [PATCH v3] gpio: shared: make the voting mechanism adaptable
From: Bartosz Golaszewski @ 2026-06-30 14:28 UTC (permalink / raw)
To: Marek Vasut, Arnd Bergmann, Bartosz Golaszewski,
Greg Kroah-Hartman, Srinivas Kandagatla, Linus Walleij,
Viacheslav Bocharov
Cc: linux-kernel, linux-gpio, Bartosz Golaszewski
The current voting mechanism in GPIO shared proxy assumes that "low" is
always the default value and users can only vote for driving the GPIO
"high" in which case it will remain high as long as there's at least one
user voting.
This makes it impossible to use the automatic sharing management for
certain use-cases such as the write-protect GPIOs of EEPROMs which are
requested "high" and driven "low" to enable writing. In this case, if
the WP GPIO is shared by multiple EEPROMs, and at least one of them
wants to enable writing, the pin must be set to "low".
Modify the voting heuristic to assume the value set by the first user on
request to be the "default" and subseqent calls to gpiod_set_value()
will constitute votes for a change of the value to the opposite. In the
wp-gpios case it will mean that the nvmem core requests the GPIO as
"out-high" for all EEPROMs sharing the pin, and when one of them wants
to write, the pin will be driven low, enabling it.
Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
Reported-by: Marek Vasut <marex@nabladev.com>
Closes: https://lore.kernel.org/all/20260511163518.51104-1-marex@nabladev.com/
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v3:
- Rebase on top of locking changes in gpio-shared-proxy.c
- Link to v2: https://patch.msgid.link/20260528-gpio-shared-dynamic-voting-v2-1-820837ce8cd2@oss.qualcomm.com
Changes in v2:
- Rebased on top of current linux-next which contains a fix for the
shared GPIO proxy release path
- Link to v1: https://patch.msgid.link/20260513-gpio-shared-dynamic-voting-v1-1-8e1c49961b7d@oss.qualcomm.com
---
drivers/gpio/gpio-shared-proxy.c | 66 +++++++++++++++++++---------------------
drivers/gpio/gpiolib-shared.h | 3 +-
2 files changed, 34 insertions(+), 35 deletions(-)
diff --git a/drivers/gpio/gpio-shared-proxy.c b/drivers/gpio/gpio-shared-proxy.c
index 10ca2ef77ef3410b7be46a6657ebea8cd80c4491..52a366f0ec4de71e9d6b8f88ef77ef007b660c88 100644
--- a/drivers/gpio/gpio-shared-proxy.c
+++ b/drivers/gpio/gpio-shared-proxy.c
@@ -22,7 +22,7 @@ struct gpio_shared_proxy_data {
struct gpio_chip gc;
struct gpio_shared_desc *shared_desc;
struct device *dev;
- bool voted_high;
+ bool voted_change;
};
static int
@@ -34,52 +34,54 @@ gpio_shared_proxy_set_unlocked(struct gpio_shared_proxy_data *proxy, int value)
lockdep_assert_held(&shared_desc->mutex);
- if (value) {
- /* User wants to set value to high. */
- if (proxy->voted_high)
- /* Already voted for high, nothing to do. */
+ if (value != shared_desc->def_val) {
+ /* User wants to vote for a value change. */
+ if (proxy->voted_change)
+ /* Already voted for a change, nothing to do. */
goto out;
- /* Haven't voted for high yet. */
- if (!shared_desc->highcnt) {
+ /* Haven't voted for a value change yet. */
+ if (!shared_desc->votecnt) {
/*
- * Current value is low, need to actually set value
- * to high.
+ * Current value is default, need to actually set value
+ * to the opposite.
*/
- ret = gpiod_set_value_cansleep(desc, 1);
+ ret = gpiod_set_value_cansleep(desc, value);
if (ret)
goto out;
}
- shared_desc->highcnt++;
- proxy->voted_high = true;
+ shared_desc->votecnt++;
+ proxy->voted_change = true;
goto out;
}
- /* Desired value is low. */
- if (!proxy->voted_high)
- /* We didn't vote for high, nothing to do. */
+ /* Desired value is the default. */
+ if (!proxy->voted_change)
+ /* We didn't vote for change previously, nothing to do. */
goto out;
- /* We previously voted for high. */
- if (shared_desc->highcnt == 1) {
- /* This is the last remaining vote for high, set value to low. */
- ret = gpiod_set_value_cansleep(desc, 0);
+ /* We previously voted for change. */
+ if (shared_desc->votecnt == 1) {
+ /* This is the last remaining vote for change, set value to default. */
+ ret = gpiod_set_value_cansleep(desc, shared_desc->def_val);
if (ret)
goto out;
}
- shared_desc->highcnt--;
- proxy->voted_high = false;
+ shared_desc->votecnt--;
+ proxy->voted_change = false;
out:
- if (shared_desc->highcnt)
+ if (shared_desc->votecnt)
dev_dbg(proxy->dev,
- "Voted for value '%s', effective value is 'high', number of votes for 'high': %u\n",
- str_high_low(value), shared_desc->highcnt);
+ "Voted for value '%s', effective value is '%s', number of votes: %u\n",
+ str_high_low(value), str_high_low(!shared_desc->def_val),
+ shared_desc->votecnt);
else
- dev_dbg(proxy->dev, "Voted for value 'low', effective value is 'low'\n");
+ dev_dbg(proxy->dev, "Voted for value '%s', effective value is '%s'\n",
+ str_high_low(value), str_high_low(shared_desc->def_val));
return ret;
}
@@ -107,8 +109,8 @@ static void gpio_shared_proxy_free(struct gpio_chip *gc, unsigned int offset)
guard(mutex)(&shared_desc->mutex);
- if (proxy->voted_high) {
- ret = gpio_shared_proxy_set_unlocked(proxy, 0);
+ if (proxy->voted_change) {
+ ret = gpio_shared_proxy_set_unlocked(proxy, shared_desc->def_val);
if (ret)
dev_err(proxy->dev,
"Failed to unset the shared GPIO value on release: %d\n", ret);
@@ -197,13 +199,9 @@ static int gpio_shared_proxy_direction_output(struct gpio_chip *gc,
if (ret)
return ret;
- if (value) {
- proxy->voted_high = true;
- shared_desc->highcnt = 1;
- } else {
- proxy->voted_high = false;
- shared_desc->highcnt = 0;
- }
+ shared_desc->def_val = value;
+ shared_desc->votecnt = 0;
+ proxy->voted_change = false;
return 0;
}
diff --git a/drivers/gpio/gpiolib-shared.h b/drivers/gpio/gpiolib-shared.h
index bbdc0ab7b647a44fca714bed0a7ff75101da7460..618756f6c6aafd087df267a4a32732ccc03af38e 100644
--- a/drivers/gpio/gpiolib-shared.h
+++ b/drivers/gpio/gpiolib-shared.h
@@ -41,7 +41,8 @@ struct gpio_shared_desc {
struct gpio_desc *desc;
unsigned long cfg;
unsigned int usecnt;
- unsigned int highcnt;
+ unsigned int votecnt;
+ int def_val;
struct mutex mutex; /* serializes all proxy operations on this descriptor */
};
---
base-commit: efecde8a254d1f207b75c5ebcfba2c51f4c771d9
change-id: 20260512-gpio-shared-dynamic-voting-9aab4689f5e9
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue write commands
From: Konrad Dybcio @ 2026-06-30 14:28 UTC (permalink / raw)
To: Fenglin Wu, Dmitry Baryshkov, Mark Brown
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: <c0478a3b-dcc0-44e0-abfd-2c86f24db733@oss.qualcomm.com>
On 6/18/26 8:39 AM, Fenglin Wu wrote:
>
> On 6/12/2026 8:27 AM, Dmitry Baryshkov wrote:
>> On Thu, Jun 11, 2026 at 12:36:43PM +0200, Konrad Dybcio wrote:
>>> On 6/9/26 3:28 AM, Fenglin Wu wrote:
>>>> 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.
>>> I was thinking about other ways to solve it.. maybe someting like:
>>>
>>> &pmh0101_gpios {
>>> pmh0101_ls_pins1_2: foo-bar {
>>> pins = "gpio1", "gpio2";
>>> // appropriate pinctrl config
>>> };
>>> };
>>>
>>> &rpmh_rsc {
>>> // should this be a gpio controller? a mux provider?
>>> // is there another class that would better suit this?
>>> rpmh_level_shifter: rpmh-foo-bar {
>>> pinctrl-0 = <&>;
>>> pinctrl-names = "default";
>>> };
>>> };
>>>
>>> // but where would it make sense to describe?
>>> // fixed-regulator or something akin to that?
>>> &some_consumer {
>>> someclass = <&rpmh_level_shifter 1>;
>>> };
>>>
>>> i.e. the "rpmh level shifter" driver would consume a reference to the
>>> pins, configure them as necessary (just like any other pinctrl consumer)
>>> upon request
>> SGTM.
> Thanks for the suggestion, Konrad and Dmitry!
> Using the pinctrl state in the new driver to disable GPIO pairs is a good idea. I’ve been considering which class would best support the PMIC level-shifter, especially since we’re moving it to a new driver and it’s no longer restricted by the pinctrl framework. Functionally, the 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).
>
> I see flaws in each of the following approaches and haven’t decided which to use:
> 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.
(keeping all the context above)
+Mark, would you accept not-quite-a-regulator driver?
Otherwise, I don't really have a good idea either, perhaps the mux
maintainers could be open to adding refcounting for 'shared muxes'
Konrad
>
> Please let me know your thoughts. If there isn’t a suitable approach for supporting the PMIC level-shifter right now, I’ll stop chasing on this until there is a better idea.
>
> Thanks
>
>
>>> Konrad
^ permalink raw reply
* Re: [PATCH v3 0/8] x1e80100: Enable PDC wake GPIOs and deepest idle state
From: Thomas Gleixner @ 2026-06-30 14:34 UTC (permalink / raw)
To: Linus Walleij, Maulik Shah, Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-kernel, devicetree, linux-gpio,
Sneh Mankad, Stephan Gerhold
In-Reply-To: <CAD++jLk5qmiCTebaor1h4MSRX0mM-oKH-CdbZU9SKq=f3aQVug@mail.gmail.com>
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.
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: qcom: Drop unnecessary bitmap_fill() call
From: Bartosz Golaszewski @ 2026-06-30 14:34 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Hans de Goede
Cc: Bartosz Golaszewski, linux-arm-msm, linux-gpio
In-Reply-To: <20260623122732.6439-1-johannes.goede@oss.qualcomm.com>
On Tue, 23 Jun 2026 14:27:31 +0200, Hans de Goede wrote:
> Drop an unnecessary bitmap_fill() call from msm_gpio_irq_init_valid_mask(),
> this is unnecessary because gpiochip_allocate_mask() already does this.
>
>
Applied, thanks!
[1/2] pinctrl: qcom: Drop unnecessary bitmap_fill() call
https://git.kernel.org/brgl/c/72323d7dc5118f5c7c269ff67797d342ed9effc7
[2/2] pinctrl: qcom: Drop unused irq_data argument from msm_gpio_update_dual_edge_pos()
https://git.kernel.org/brgl/c/e417d51c7f2ee08361b57a97869a2870bb417782
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/4] gpio: mt7621: address Sashiko complains and other cleanups
From: Bartosz Golaszewski @ 2026-06-30 14:37 UTC (permalink / raw)
To: linux-gpio, Sergio Paracuellos
Cc: Bartosz Golaszewski, linusw, brgl, vicencb, linux-kernel
In-Reply-To: <20260626060112.2498324-1-sergio.paracuellos@gmail.com>
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,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue write commands
From: Mark Brown @ 2026-06-30 14:37 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Fenglin Wu, 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: <88b5d0e1-4b78-4b79-b9aa-d6438eeced9c@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
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?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/8] irqchip/qcom-pdc: restructure version support
From: Thomas Gleixner @ 2026-06-30 14:38 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad,
Maulik Shah
In-Reply-To: <20260616-hamoa_pdc_v3-v3-1-4d8e1504ea75@oss.qualcomm.com>
On Tue, Jun 16 2026 at 14:55, Maulik Shah wrote:
> @@ -336,7 +418,8 @@ static int pdc_setup_pin_mapping(struct device_node *np)
> return -EINVAL;
>
> pdc_region_cnt = n / 3;
> - pdc_region = kzalloc_objs(*pdc_region, pdc_region_cnt);
> + pdc_region = devm_kcalloc(dev, pdc_region_cnt, sizeof(*pdc_region),
> + GFP_KERNEL);
No line break required. You have 100 characters
Other than that nit, this looks sane now.
^ permalink raw reply
* Re: [PATCH v3 2/8] irqchip/qcom-pdc: Move all statics to struct pdc_desc
From: Thomas Gleixner @ 2026-06-30 14:46 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad,
Maulik Shah
In-Reply-To: <20260616-hamoa_pdc_v3-v3-2-4d8e1504ea75@oss.qualcomm.com>
On Tue, Jun 16 2026 at 14:55, Maulik Shah wrote:
> - for (i = 0; i < pdc_region[n].cnt; i++)
> - __pdc_enable_intr(i + pdc_region[n].pin_base, 0);
> + for (int i = 0; i < pdc->region[n].cnt; i++)
> + pdc->enable_intr(i + pdc->region[n].pin_base, 0);
This needs a guard(raw_spinlock_irqsave)() when invoking
pdc->enable_intr(). The probe function is only invoked
with interrupts disabled during early boot. If it's called later, then
this still works, but lockdep will be rightfully upset.
^ permalink raw reply
* [PATCH] gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe
From: Vladimir Zapolskiy @ 2026-06-30 14:51 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski; +Cc: Richard Röjfors, linux-gpio
Out of memory situation on driver's probe is expected to be reported to
the driver's framework with a proper -ENOMEM error code.
Fixes: 35570ac6039e ("gpio: add GPIO driver for the Timberdale FPGA")
Signed-off-by: Vladimir Zapolskiy <vz@kernel.org>
---
drivers/gpio/gpio-timberdale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-timberdale.c b/drivers/gpio/gpio-timberdale.c
index 78fe133f5d32..ec378a4220a7 100644
--- a/drivers/gpio/gpio-timberdale.c
+++ b/drivers/gpio/gpio-timberdale.c
@@ -228,7 +228,7 @@ static int timbgpio_probe(struct platform_device *pdev)
tgpio = devm_kzalloc(dev, sizeof(*tgpio), GFP_KERNEL);
if (!tgpio)
- return -EINVAL;
+ return -ENOMEM;
gc = &tgpio->gpio;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v3] pinctrl: qcom: Unconditionally mark gpio as wakeup enable
From: Bartosz Golaszewski @ 2026-06-30 14:52 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Neil Armstrong,
Krzysztof Kozlowski, Sneh Mankad
Cc: Bartosz Golaszewski, linux-arm-msm, linux-gpio, linux-kernel,
stable, Maulik Shah
In-Reply-To: <20260616-enable_wakeup_capable_gpios-v3-1-fb59647d89cb@oss.qualcomm.com>
On Tue, 16 Jun 2026 17:24:53 +0530, Sneh Mankad wrote:
> GPIO interrupts that are wakeup capable need to be forwarded to wakeup
> capable parent irqchip. This is done via writing to it's wakeup_enable bit.
>
> Currently the bit is set only for PDC irqchip by checking skip_wake_irqs.
> skip_wake_irqs is set to differentiate between parent irqchips MPM and
> PDC. It is set when the parent irqchip is PDC to inform pinctrl about
> skipping the IRQ setting up at TLMM.
>
> [...]
Applied, thanks!
[1/1] pinctrl: qcom: Unconditionally mark gpio as wakeup enable
https://git.kernel.org/brgl/c/859e02a369ab328a77dfcabf59562100e55f9c5c
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 4/8] irqchip/qcom-pdc: Differentiate between direct SPI and GPIO as SPI
From: Thomas Gleixner @ 2026-06-30 14:57 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad,
Maulik Shah
In-Reply-To: <20260616-hamoa_pdc_v3-v3-4-4d8e1504ea75@oss.qualcomm.com>
On Tue, Jun 16 2026 at 14:55, Maulik Shah wrote:
> Before commit 4dc70713dc24 ("irqchip/qcom-pdc: Kill non-wakeup irqdomain")
> there are separate domains for direct SPIs and GPIO used as SPIs. Separate
s/are/were/
> domains can be useful in case irqchip want to differentiate both of them.
the irqchip wants
> Since commit unified both the domains there is no way to differentiate.
Since the commit.
> In preparation to add the second level interrupt controller support where
> GPIO interrupts get latched at PDC (but not direct SPIs) there is a need to
> differentiate between SPIs and GPIOs as SPIs. Reverting above commit do not
does not
> seem a good option either which leads to waste of resources.
'either which leads' is not a parseable sentence.
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Thomas Gleixner @ 2026-06-30 15:07 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad,
Maulik Shah
In-Reply-To: <20260616-hamoa_pdc_v3-v3-5-4d8e1504ea75@oss.qualcomm.com>
On Tue, Jun 16 2026 at 14:55, Maulik Shah wrote:
> All PDC irqchip supports pass through mode in which both Direct SPIs and
All PDC variants support pass .. ??
> GPIO IRQs (as SPIs) are sent to GIC without latching at PDC.
>
> Newer PDCs (v3.0 onwards) also support additional secondary controller mode
> where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs
latches the GPIO interrupts and sends them to GIC as level type interrupts.
> still works same as pass through mode without latching at PDC even in
SPIs .. work the same as pass-through mode ....
> secondary controller mode.
>
> All the SoCs so far default uses pass through mode with the exception of
SoCs ... use pass-through
> x1e. x1e PDC may be set to secondary controller mode for builds on CRD
> boards whereas it may be set to pass through mode for IoT-EVK boards.
> The mode configuration is done in firmware and initially shipped windows
> firmware did not have SCM interface to read or modify the PDC mode.
> Later only write access is opened up for non secure world.
.. for the non-secure ..
> +/**
> + * qcom_pdc_gic_set_type: Configure PDC for the interrupt
> + *
> + * @d: the interrupt data
> + * @type: the interrupt type
https://docs.kernel.org/process/maintainer-tip.html#struct-declarations-and-initializers
I'm sure I pointed you to that document before.
> + *
> + * All @type are forwarded as Level type to parent GIC
> + */
> +static int qcom_pdc_gic_secondary_set_type(struct irq_data *d, unsigned int type)
> +{
> + enum pdc_irq_config_bits pdc_type;
> + enum pdc_irq_config_bits old_pdc_type;
Chapter before the above ...
> @@ -449,8 +628,13 @@ static int pdc_setup_pin_mapping(struct device *dev, struct device_node *np)
> if (ret)
> return ret;
>
> - for (int i = 0; i < pdc->region[n].cnt; i++)
> - pdc->enable_intr(i + pdc->region[n].pin_base, 0);
> + for (int i = 0; i < pdc->region[n].cnt; i++) {
> + if (pdc_pin_is_gpio(i + pdc->region[n].pin_base) &&
> + pdc->mode == PDC_SECONDARY_MODE)
> + pdc->clear_gpio(i + pdc->region[n].pin_base);
> +
Requires guard(irqsave)(...)
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Thomas Gleixner @ 2026-06-30 15:09 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad,
Maulik Shah
In-Reply-To: <87echoqd7d.ffs@fw13>
On Tue, Jun 30 2026 at 17:07, Thomas Gleixner wrote:
> On Tue, Jun 16 2026 at 14:55, Maulik Shah wrote:
>> + for (int i = 0; i < pdc->region[n].cnt; i++) {
>> + if (pdc_pin_is_gpio(i + pdc->region[n].pin_base) &&
>> + pdc->mode == PDC_SECONDARY_MODE)
>> + pdc->clear_gpio(i + pdc->region[n].pin_base);
>> +
>
> Requires guard(irqsave)
before
>>+ pdc->enable_intr(i + pdc->region[n].pin_base, false);
obviously.
^ permalink raw reply
* Re: [PATCH v12 2/6] pinctrl: s32cc: remove inline specifiers
From: Frank Li @ 2026-06-30 15:22 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: <20260630125403.546375-3-khristineandreea.barbulescu@oss.nxp.com>
On Tue, Jun 30, 2026 at 02:53:59PM +0200, Khristine Andreea Barbulescu wrote:
> Remove unnecessary inline specifiers from static functions.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/pinctrl/nxp/pinctrl-s32cc.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pinctrl/nxp/pinctrl-s32cc.c b/drivers/pinctrl/nxp/pinctrl-s32cc.c
> index 2a32df932d8a..8c5ec6a76a1f 100644
> --- a/drivers/pinctrl/nxp/pinctrl-s32cc.c
> +++ b/drivers/pinctrl/nxp/pinctrl-s32cc.c
> @@ -131,13 +131,13 @@ s32_get_region(struct pinctrl_dev *pctldev, unsigned int pin)
> return NULL;
> }
>
> -static inline int s32_check_pin(struct pinctrl_dev *pctldev,
> - unsigned int pin)
> +static int s32_check_pin(struct pinctrl_dev *pctldev,
> + unsigned int pin)
> {
> return s32_get_region(pctldev, pin) ? 0 : -EINVAL;
> }
>
> -static inline int s32_regmap_read(struct pinctrl_dev *pctldev,
> +static int s32_regmap_read(struct pinctrl_dev *pctldev,
> unsigned int pin, unsigned int *val)
> {
> struct s32_pinctrl_mem_region *region;
> @@ -153,7 +153,7 @@ static inline int s32_regmap_read(struct pinctrl_dev *pctldev,
> return regmap_read(region->map, offset, val);
> }
>
> -static inline int s32_regmap_write(struct pinctrl_dev *pctldev,
> +static int s32_regmap_write(struct pinctrl_dev *pctldev,
> unsigned int pin,
> unsigned int val)
> {
> @@ -171,7 +171,7 @@ static inline int s32_regmap_write(struct pinctrl_dev *pctldev,
>
> }
>
> -static inline int s32_regmap_update(struct pinctrl_dev *pctldev, unsigned int pin,
> +static int s32_regmap_update(struct pinctrl_dev *pctldev, unsigned int pin,
> unsigned int mask, unsigned int val)
> {
> struct s32_pinctrl_mem_region *region;
> @@ -484,8 +484,8 @@ static int s32_get_slew_regval(int arg)
> return -EINVAL;
> }
>
> -static inline void s32_pin_set_pull(enum pin_config_param param,
> - unsigned int *mask, unsigned int *config)
> +static void s32_pin_set_pull(enum pin_config_param param,
> + unsigned int *mask, unsigned int *config)
> {
> switch (param) {
> case PIN_CONFIG_BIAS_DISABLE:
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v12 1/6] pinctrl: s32cc: add/fix some comments
From: Frank Li @ 2026-06-30 15:24 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: <20260630125403.546375-2-khristineandreea.barbulescu@oss.nxp.com>
On Tue, Jun 30, 2026 at 02:53:58PM +0200, Khristine Andreea Barbulescu wrote:
> Add/fix some comments and print statements.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/pinctrl/nxp/pinctrl-s32cc.c | 20 ++++++++++++++------
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pinctrl/nxp/pinctrl-s32cc.c b/drivers/pinctrl/nxp/pinctrl-s32cc.c
> index 56be6e8d624e..2a32df932d8a 100644
> --- a/drivers/pinctrl/nxp/pinctrl-s32cc.c
> +++ b/drivers/pinctrl/nxp/pinctrl-s32cc.c
> @@ -60,6 +60,12 @@ static u32 get_pin_func(u32 pinmux)
> return pinmux & GENMASK(3, 0);
> }
>
> +/*
> + * struct s32_pinctrl_mem_region - memory region for a set of SIUL2 registers
> + * @map: regmap used for this range
> + * @pin_range: the pins controlled by these registers
> + * @name: name of the current range
> + */
> struct s32_pinctrl_mem_region {
> struct regmap *map;
> const struct s32_pin_range *pin_range;
> @@ -67,7 +73,7 @@ struct s32_pinctrl_mem_region {
> };
>
> /*
> - * Holds pin configuration for GPIO's.
> + * struct gpio_pin_config - holds pin configuration for GPIO's
> * @pin_id: Pin ID for this GPIO
> * @config: Pin settings
> * @list: Linked list entry for each gpio pin
> @@ -79,20 +85,22 @@ struct gpio_pin_config {
> };
>
> /*
> - * Pad config save/restore for power suspend/resume.
> + * struct s32_pinctrl_context - pad config save/restore for suspend/resume
> + * @pads: saved values for the pards
> */
> struct s32_pinctrl_context {
> unsigned int *pads;
> };
>
> /*
> + * struct s32_pinctrl - private driver data
> * @dev: a pointer back to containing device
> * @pctl: a pointer to the pinctrl device structure
> * @regions: reserved memory regions with start/end pin
> * @info: structure containing information about the pin
> - * @gpio_configs: Saved configurations for GPIO pins
> - * @gpiop_configs_lock: lock for the `gpio_configs` list
> - * @s32_pinctrl_context: Configuration saved over system sleep
> + * @gpio_configs: saved configurations for GPIO pins
> + * @gpio_configs_lock: lock for the `gpio_configs` list
> + * @saved_context: configuration saved over system sleep
> */
> struct s32_pinctrl {
> struct device *dev;
> @@ -970,7 +978,7 @@ int s32_pinctrl_probe(struct platform_device *pdev,
> ipctl);
> if (IS_ERR(ipctl->pctl))
> return dev_err_probe(&pdev->dev, PTR_ERR(ipctl->pctl),
> - "could not register s32 pinctrl driver\n");
> + "Could not register s32 pinctrl driver\n");
>
> #ifdef CONFIG_PM_SLEEP
> saved_context = &ipctl->saved_context;
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH 05/11] pinctrl: freescale: IMXRT: Remove NOMMU platform support
From: Rob Herring (Arm) @ 2026-06-30 15:37 UTC (permalink / raw)
To: Frank.Li
Cc: Piotr Wojtaszczyk, Krzysztof Kozlowski, Kees Cook,
linux-arm-kernel, linux-gpio, Gustavo A. R. Silva, Jacky Bai,
Dong Aisheng, Michael Turquette, Brian Masney, Sascha Hauer,
Stefan Agner, imx, Pengutronix Kernel Team, Abel Vesa, Frank Li,
Peng Fan, Stephen Boyd, linux-hardening, Arnd Bergmann,
NXP S32 Linux Team, Fabio Estevam, devicetree, Linus Walleij,
linux-clk, linux-kernel, Vladimir Zapolskiy, Conor Dooley,
Russell King
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-5-0101795a2662@nxp.com>
On Fri, 19 Jun 2026 11:41:02 -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Commercial users and hardware vendors migrated to Zephyr or other RTOS
> solutions years ago, leaving the NOMMU platform support effectively
> unused and unmaintained.
>
> Remove the obsolete support to reduce maintenance burden and simplify the
> i.MX platform code.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../devicetree/bindings/pinctrl/fsl,imxrt1050.yaml | 79 -----
> .../devicetree/bindings/pinctrl/fsl,imxrt1170.yaml | 77 -----
> drivers/pinctrl/freescale/Kconfig | 16 -
> drivers/pinctrl/freescale/Makefile | 2 -
> drivers/pinctrl/freescale/pinctrl-imxrt1050.c | 309 ------------------
> drivers/pinctrl/freescale/pinctrl-imxrt1170.c | 349 ---------------------
> 6 files changed, 832 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Geert Uytterhoeven @ 2026-06-30 16:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, open list:GPIO SUBSYSTEM, dri-devel, linux-i2c,
linux-iio, linux-input, linux-mmc @ vger . kernel . org,
linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <ff4d7043-1929-4fa1-ba5e-f28403ad6fcc@app.fastmail.com>
Hi Arnd,
On Mon, 29 Jun 2026 at 19:54, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
> > On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
> >> From: Arnd Bergmann <arnd@arndb.de>
> >>
> >> Most remaining users of desc_to_gpio() only call it for printing debug
> >> information.
> >>
> >> Replace this with a new gpiod_name() helper that returns the
> >> gpio_desc->name string after checking the gpio_desc pointer.
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> --- a/drivers/gpio/gpio-aggregator.c
> >> +++ b/drivers/gpio/gpio-aggregator.c
> >> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
> >>
> >> fwd->descs[offset] = desc;
> >>
> >> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
> >> - desc_to_gpio(desc), gpiod_to_irq(desc));
> >> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
> >> + gpiod_name(desc), gpiod_to_irq(desc));
> >>
> >> return 0;
> >> }
> >
> > Before, this printed:
> >
> > gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
> > gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
> >
> > After, this prints:
> >
> > gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
> > gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
> >
> > Same results for instantiation using sysfs or configfs[1], although
> > the latter does have optional support for specifying the name.
>
> I wonder how many of the other instances have the same problem
> then. Would it be appropriate for gpiochip_fwd_desc_add() to set
> a name itself to address this one?
I don't think it would be appropriate for the GPIO aggregator to set
that name. What we want to print here (for debugging) is the physical
GPIO that an aggregator's GPIO is mapped to, not some consumer or line
name (which is not guaranteed to be unique).
E.g. "<chip-name>.<offset>" would be fine. As gpiod_name() can only
return a fixed string or an existing string, it can't return such a
formatted string, though. And consumers don't have access to chip info?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: (subset) [PATCH v2 0/4] gpio: mt7621: address Sashiko complains and other cleanups
From: Sergio Paracuellos @ 2026-06-30 17:33 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-gpio, linusw, brgl, vicencb, linux-kernel
In-Reply-To: <178283020836.36519.12213594335592775087.b4-ty@oss.qualcomm.com>
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>
^ permalink raw reply
* Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces
From: Sean Christopherson @ 2026-06-30 18:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Arnd Bergmann, Juergen Gross, linux-kernel, linux-pm,
linux-edac@vger.kernel.org, x86, linux-acpi, kvm, linux-coco,
linux-pci, virtualization, linux-ide, dri-devel, linux-fbdev,
linux-crypto, open list:GPIO SUBSYSTEM, linux-hyperv, linux-hwmon,
linux-perf-users, linux-mtd, platform-driver-x86,
Rafael J . Wysocki, Daniel Lezcano, Zhang Rui,
lukasz.luba@arm.com, Jason Baron, Borislav Petkov, Tony Luck,
Yazen Ghannam, Len Brown, Pavel Machek, Thomas Gleixner,
Ingo Molnar, Dave Hansen, H. Peter Anvin, Paolo Bonzini,
Kirill A. Shutemov, Rick Edgecombe, Pu Wen, Bjorn Helgaas,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Viresh Kumar, Reinette Chatre, Dave Martin, James Morse,
Babu Moger, Tony W Wang-oc, Damien Le Moal, Niklas Cassel,
Dave Airlie, Helge Deller, linux-geode, Olivia Mackall,
Herbert Xu, Linus Walleij, Bartosz Golaszewski,
Greg Kroah-Hartman, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Guenter Roeck, Peter Zijlstra,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Josh Poimboeuf, Pawan Gupta, Vitaly Kuznetsov,
Andy Lutomirski, Boris Ostrovsky, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, srinivas.pandruvada@linux.intel.com,
Artem Bityutskiy, Artem Bityutskiy, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, Ashok Raj, Hans de Goede,
Ilpo Järvinen, Rajneesh Bhardwaj, David E Box, xen-devel
In-Reply-To: <akJUz0kYkEBdLSZ3@gmail.com>
On Mon, Jun 29, 2026, Ingo Molnar wrote:
> * Arnd Bergmann <arnd@arndb.de> wrote:
>
> > >>> Note that most patches of this series are independent from each other.
> > >>> Only the patches removing a specific interface (patches 7, 15, 26 and
> > >>> 30) and the last two patches of the series depend on all previous
> > >>> patches.
> > >>
> > >> It looks like you are touching most files twice or more here, to
> > >> first convert from rdmsr to rdmsrq and then to change the
> > >> two-argument rdmsrq() macro to a single-argument inline. If you
> > >> introduce the inline version of rdmsrq() first, you should be
> > >> able to skip the second step (patch 31) as they could be able
> > >> to coexist.
> > >
> > > I've discussed how to structure the series with Ingo Molnar before [1]. The
> > > current approach was his preference.
> >
> > Ok.
>
> Note that the individual patches are IMO significantly easier to review
> through the actual 32-bit => 64-bit variable assignment changes done
> in isolation (which sometimes include minor cleanups), while
> the Coccinelle semantic patch:
>
> { a(b,c) => c = a(b) }
>
> which changes both the function signature and the order of terms as
> well, is just a single add-on treewide patch.
Is the plan for subsystem maintainers to pick up the relevant patches, and then
do the treewide change one release cycle later?
^ permalink raw reply
* [brgl:gpio/for-current] BUILD SUCCESS 9a6c0b6ea12746d50cf53d59a7e05fd83f974bda
From: kernel test robot @ 2026-06-30 20:23 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-gpio
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git gpio/for-current
branch HEAD: 9a6c0b6ea12746d50cf53d59a7e05fd83f974bda gpio-f7188x: Add support for NCT6126D version B
elapsed time: 729m
configs tested: 325
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc haps_hs_defconfig gcc-16.1.0
arc randconfig-001 clang-23
arc randconfig-001-20260630 clang-23
arc randconfig-001-20260701 gcc-12.5.0
arc randconfig-002 clang-23
arc randconfig-002-20260630 clang-23
arc randconfig-002-20260701 gcc-12.5.0
arm allnoconfig clang-17
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm randconfig-001 clang-23
arm randconfig-001-20260630 clang-23
arm randconfig-001-20260701 gcc-12.5.0
arm randconfig-002 clang-23
arm randconfig-002-20260630 clang-23
arm randconfig-002-20260701 gcc-12.5.0
arm randconfig-003 clang-23
arm randconfig-003-20260630 clang-23
arm randconfig-003-20260701 gcc-12.5.0
arm randconfig-004 clang-23
arm randconfig-004-20260630 clang-23
arm randconfig-004-20260701 gcc-12.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260630 clang-23
arm64 randconfig-001-20260701 gcc-12.5.0
arm64 randconfig-002-20260630 clang-23
arm64 randconfig-002-20260701 gcc-12.5.0
arm64 randconfig-003-20260630 clang-23
arm64 randconfig-003-20260701 gcc-12.5.0
arm64 randconfig-004-20260630 clang-23
arm64 randconfig-004-20260701 gcc-12.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260630 clang-23
csky randconfig-001-20260701 gcc-12.5.0
csky randconfig-002-20260630 clang-23
csky randconfig-002-20260701 gcc-12.5.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260630 clang-18
hexagon randconfig-001-20260701 clang-23
hexagon randconfig-002-20260630 clang-18
hexagon randconfig-002-20260701 clang-23
i386 allmodconfig clang-22
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001 clang-22
i386 buildonly-randconfig-001-20260630 clang-22
i386 buildonly-randconfig-001-20260701 clang-22
i386 buildonly-randconfig-002 clang-22
i386 buildonly-randconfig-002-20260630 clang-22
i386 buildonly-randconfig-002-20260701 clang-22
i386 buildonly-randconfig-003 clang-22
i386 buildonly-randconfig-003-20260630 clang-22
i386 buildonly-randconfig-003-20260701 clang-22
i386 buildonly-randconfig-004 clang-22
i386 buildonly-randconfig-004-20260630 clang-22
i386 buildonly-randconfig-004-20260701 clang-22
i386 buildonly-randconfig-005 clang-22
i386 buildonly-randconfig-005-20260630 clang-22
i386 buildonly-randconfig-005-20260701 clang-22
i386 buildonly-randconfig-006 clang-22
i386 buildonly-randconfig-006-20260630 clang-22
i386 buildonly-randconfig-006-20260701 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260630 clang-22
i386 randconfig-002-20260630 clang-22
i386 randconfig-003-20260630 clang-22
i386 randconfig-004-20260630 clang-22
i386 randconfig-005-20260630 clang-22
i386 randconfig-006-20260630 clang-22
i386 randconfig-007-20260630 clang-22
i386 randconfig-011 gcc-12
i386 randconfig-011-20260630 gcc-12
i386 randconfig-011-20260701 gcc-14
i386 randconfig-012 gcc-12
i386 randconfig-012-20260630 gcc-12
i386 randconfig-012-20260701 gcc-14
i386 randconfig-013 gcc-12
i386 randconfig-013-20260630 gcc-12
i386 randconfig-013-20260701 gcc-14
i386 randconfig-014 gcc-12
i386 randconfig-014-20260630 gcc-12
i386 randconfig-014-20260701 gcc-14
i386 randconfig-015 gcc-12
i386 randconfig-015-20260630 gcc-12
i386 randconfig-015-20260701 gcc-14
i386 randconfig-016 gcc-12
i386 randconfig-016-20260630 gcc-12
i386 randconfig-016-20260701 gcc-14
i386 randconfig-017 gcc-12
i386 randconfig-017-20260630 gcc-12
i386 randconfig-017-20260701 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260630 clang-18
loongarch randconfig-001-20260701 clang-23
loongarch randconfig-002-20260630 clang-18
loongarch randconfig-002-20260701 clang-23
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips malta_kvm_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001-20260630 clang-18
nios2 randconfig-001-20260701 clang-23
nios2 randconfig-002-20260630 clang-18
nios2 randconfig-002-20260701 clang-23
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260630 clang-22
parisc randconfig-001-20260701 clang-17
parisc randconfig-002-20260630 clang-22
parisc randconfig-002-20260701 clang-17
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc randconfig-001-20260630 clang-22
powerpc randconfig-001-20260701 clang-17
powerpc randconfig-002-20260630 clang-22
powerpc randconfig-002-20260701 clang-17
powerpc64 randconfig-001-20260630 clang-22
powerpc64 randconfig-001-20260701 clang-17
powerpc64 randconfig-002-20260630 clang-22
powerpc64 randconfig-002-20260701 clang-17
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-9.5.0
riscv randconfig-001-20260630 gcc-9.5.0
riscv randconfig-002 gcc-9.5.0
riscv randconfig-002-20260630 gcc-9.5.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-9.5.0
s390 randconfig-001-20260630 gcc-9.5.0
s390 randconfig-002 gcc-9.5.0
s390 randconfig-002-20260630 gcc-9.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001 gcc-9.5.0
sh randconfig-001-20260630 gcc-9.5.0
sh randconfig-002 gcc-9.5.0
sh randconfig-002-20260630 gcc-9.5.0
sh se7750_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001 clang-17
sparc randconfig-001-20260630 clang-17
sparc randconfig-001-20260701 gcc-13.4.0
sparc randconfig-002 clang-17
sparc randconfig-002-20260630 clang-17
sparc randconfig-002-20260701 gcc-13.4.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 clang-17
sparc64 randconfig-001-20260630 clang-17
sparc64 randconfig-001-20260701 gcc-13.4.0
sparc64 randconfig-002 clang-17
sparc64 randconfig-002-20260630 clang-17
sparc64 randconfig-002-20260701 gcc-13.4.0
um allmodconfig clang-17
um allnoconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 clang-17
um randconfig-001-20260630 clang-17
um randconfig-001-20260701 gcc-13.4.0
um randconfig-002 clang-17
um randconfig-002-20260630 clang-17
um randconfig-002-20260701 gcc-13.4.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 clang-22
x86_64 buildonly-randconfig-001-20260630 clang-22
x86_64 buildonly-randconfig-001-20260701 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260630 clang-22
x86_64 buildonly-randconfig-002-20260630 gcc-14
x86_64 buildonly-randconfig-002-20260701 clang-22
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260630 clang-22
x86_64 buildonly-randconfig-003-20260701 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260630 clang-22
x86_64 buildonly-randconfig-004-20260701 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260630 clang-22
x86_64 buildonly-randconfig-005-20260701 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260630 clang-22
x86_64 buildonly-randconfig-006-20260701 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 gcc-14
x86_64 randconfig-001-20260630 gcc-14
x86_64 randconfig-001-20260701 gcc-14
x86_64 randconfig-002 gcc-14
x86_64 randconfig-002-20260630 gcc-14
x86_64 randconfig-002-20260701 gcc-14
x86_64 randconfig-003 gcc-14
x86_64 randconfig-003-20260630 gcc-14
x86_64 randconfig-003-20260701 gcc-14
x86_64 randconfig-004 gcc-14
x86_64 randconfig-004-20260630 gcc-14
x86_64 randconfig-004-20260701 gcc-14
x86_64 randconfig-005 gcc-14
x86_64 randconfig-005-20260630 gcc-14
x86_64 randconfig-005-20260701 gcc-14
x86_64 randconfig-006 gcc-14
x86_64 randconfig-006-20260630 gcc-14
x86_64 randconfig-006-20260701 gcc-14
x86_64 randconfig-011-20260630 gcc-14
x86_64 randconfig-011-20260701 gcc-14
x86_64 randconfig-012-20260630 gcc-14
x86_64 randconfig-012-20260701 gcc-14
x86_64 randconfig-013-20260630 gcc-14
x86_64 randconfig-013-20260701 gcc-14
x86_64 randconfig-014-20260630 gcc-14
x86_64 randconfig-014-20260701 gcc-14
x86_64 randconfig-015-20260630 gcc-14
x86_64 randconfig-015-20260701 gcc-14
x86_64 randconfig-016-20260630 gcc-14
x86_64 randconfig-016-20260701 gcc-14
x86_64 randconfig-071 gcc-13
x86_64 randconfig-071-20260630 clang-22
x86_64 randconfig-071-20260630 gcc-13
x86_64 randconfig-071-20260630 gcc-14
x86_64 randconfig-071-20260701 gcc-14
x86_64 randconfig-072 gcc-13
x86_64 randconfig-072-20260630 clang-22
x86_64 randconfig-072-20260630 gcc-13
x86_64 randconfig-072-20260630 gcc-14
x86_64 randconfig-072-20260701 gcc-14
x86_64 randconfig-073 gcc-13
x86_64 randconfig-073-20260630 clang-22
x86_64 randconfig-073-20260630 gcc-13
x86_64 randconfig-073-20260701 gcc-14
x86_64 randconfig-074 gcc-13
x86_64 randconfig-074-20260630 clang-22
x86_64 randconfig-074-20260630 gcc-13
x86_64 randconfig-074-20260701 gcc-14
x86_64 randconfig-075 gcc-13
x86_64 randconfig-075-20260630 clang-22
x86_64 randconfig-075-20260630 gcc-13
x86_64 randconfig-075-20260630 gcc-14
x86_64 randconfig-075-20260701 gcc-14
x86_64 randconfig-076 gcc-13
x86_64 randconfig-076-20260630 clang-22
x86_64 randconfig-076-20260630 gcc-13
x86_64 randconfig-076-20260701 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001 clang-17
xtensa randconfig-001-20260630 clang-17
xtensa randconfig-001-20260701 gcc-13.4.0
xtensa randconfig-002 clang-17
xtensa randconfig-002-20260630 clang-17
xtensa randconfig-002-20260701 gcc-13.4.0
xtensa smp_lx200_defconfig gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 00/32] x86/msr: Drop 32-bit MSR interfaces
From: H. Peter Anvin @ 2026-06-30 20:06 UTC (permalink / raw)
To: Arnd Bergmann, Juergen Gross, linux-kernel, linux-pm,
linux-edac@vger.kernel.org, x86, linux-acpi, kvm, linux-coco,
linux-pci, virtualization, linux-ide, dri-devel, linux-fbdev,
linux-crypto, open list:GPIO SUBSYSTEM, linux-hyperv, linux-hwmon,
linux-perf-users, linux-mtd, platform-driver-x86
Cc: Rafael J . Wysocki, Daniel Lezcano, Zhang Rui,
lukasz.luba@arm.com, Jason Baron, Borislav Petkov, Tony Luck,
Yazen Ghannam, Len Brown, Pavel Machek, Thomas Gleixner,
Ingo Molnar, Dave Hansen, Sean Christopherson, Paolo Bonzini,
Kirill A. Shutemov, Rick Edgecombe, Pu Wen, Bjorn Helgaas,
Ajay Kaher, Alexey Makhalov, Broadcom internal kernel review list,
Viresh Kumar, Reinette Chatre, Dave Martin, James Morse,
Babu Moger, Tony W Wang-oc, Damien Le Moal, Niklas Cassel,
Dave Airlie, Helge Deller, linux-geode, Olivia Mackall,
Herbert Xu, Linus Walleij, Bartosz Golaszewski,
Greg Kroah-Hartman, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Guenter Roeck, Peter Zijlstra,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Josh Poimboeuf, Pawan Gupta, Vitaly Kuznetsov,
Andy Lutomirski, Boris Ostrovsky, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, srinivas.pandruvada@linux.intel.com,
Artem Bityutskiy, Artem Bityutskiy, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, Ashok Raj, Hans de Goede,
Ilpo Järvinen, Rajneesh Bhardwaj, David E Box, xen-devel
In-Reply-To: <d315e0a8-e4e9-4f7e-80a9-7c236849eabd@app.fastmail.com>
On 2026-06-29 01:38, Arnd Bergmann wrote:
>>
>> There is no RDMSRQ instruction on any x86 CPU. Are you mixing this up with
>> WRMSRNS/RDMSR using an immediate for addressing the MSR?
>
> Yes, I was just confused about the exact definition here and assumed
> the single-register output version was actually called rdmsrq.
>
So just to be clear:
There are three instructions(*):
wrmsr - implicit form only
wrmsrns - implicit or immediate
rdmsr - implicit or immediate
The implicit form are the same on 32 and 64 bits (and, in fact, 16 bits): they
take a MSR register address in %ecx and the data as two 32-bit words in
%edx:%eax. This interface predates x86-64 by about a decade, and the Linux MSR
interfaces were designed when Linux was 32-bit only, so it made sense at the
time to treat them as two halves, especially since MSRs often are various
kinds of bitfields. It didn't help that gcc at the time was extremely
inefficient in its handling of multiword arithmetic (it is much better now),
so using a u64 would have made for much worse code.
The immediate forms are 64-bit only and use a single arbitrary 64-bit
register; the MSR address is kept in an immediate in the instruction, just
like they are for most other register types. The only thing that is "special"
there is that the possible register address space is very large (2^32)
although in practice a very small fraction of that is (currently) used.
The immediate forms are expected to be faster, and provide for further
performance improvements in future microarchitectures. This is important,
because it provides a fine-grain uniform architecture for supervisor-only
state, instead of having to give a bulk ISA (XSAVES/XRSTORS) that is different
from the fine-grained architecture, and still get good performance. This gives
the kernel very fine level control over the context switch flows, for one thing.
WRMSRNS is a non-serializing form of WRMSR, which is defined as an
architecturally hard-serializing instruction, although some MSRs have been
retconned as non-serializing (and the set is different between vendors.) We
want to switch that over to the model where the kernel explicitly opts in to
nonserialization, but that means using alternatives since not all CPUs have
the WRMSRNS instruction.
Furthermore, we want to use alternatives so we can make use of the
immediate-format instructions when the MSR address is known at compile time,
which it is in *nearly* all cases. If we are smart about it we can also use
this to let the tracing framework be specific about what MSRs to trace, since
some MSRs are frequently accessed, but many are set at startup and then
rarely, if ever, touched.
(*) There are actually two more instructions:
RDMSRLIST
WRMSRLIST
... which are bulk versions of RDMSR and WRMSRNS respectively. They can be
useful to save and restore entire groups of MSRs in one shot, such as
performance counter configurations. By architecturally allowing the memory
operations and MSR operations to operate asynchronously, they give some of the
pipeline benefits of the immediate MSR operations without requiring the MSR
set to have been set at compile time or code to be dynamically generated.
However, they expose an entirely different programming model, whereas the
immediate- and -NS instruction choices can be entirely hidden at the C level.
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Linus Walleij @ 2026-06-30 21:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, 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, 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-1-arnd@kernel.org>
On Mon, Jun 29, 2026 at 3:26 PM Arnd Bergmann <arnd@kernel.org> 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.
>
> All patches in this series can get applied independently, so my
> preference would be for each subsystem maintainer to apply these
> directly, with the rest going into the gpio tree at some point.
>
> The final patch here obviously needs to wait for all the others
> to get merged first.
This is helpful.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 03/13] mips: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 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-4-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/mips/alchemy/board-xxs1500.c | 2 +-
> arch/mips/alchemy/devboards/db1000.c | 2 +-
> arch/mips/alchemy/devboards/db1200.c | 2 +-
> arch/mips/alchemy/devboards/db1550.c | 2 +-
> arch/mips/bcm47xx/workarounds.c | 2 +-
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 1 +
> arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h | 2 +-
> arch/mips/txx9/rbtx4927/setup.c | 2 +-
> 8 files changed, 8 insertions(+), 7 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 04/13] sh: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 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-5-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> linux/gpio/legacy.h for the sh boards using the legacy interfaces,
> or remove it where it is not needed at all.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/sh/boards/board-magicpanelr2.c | 2 +-
> arch/sh/boards/board-sh7757lcr.c | 2 +-
> arch/sh/boards/board-urquell.c | 2 +-
> arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> arch/sh/boards/mach-highlander/pinmux-r7785rp.c | 2 +-
> arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 2 +-
> arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
> arch/sh/boards/mach-migor/lcd_qvga.c | 2 +-
> arch/sh/boards/mach-migor/setup.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7203.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7269.c | 1 -
> arch/sh/boards/mach-se/7724/setup.c | 2 +-
> arch/sh/include/mach-common/mach/magicpanelr2.h | 2 --
> arch/sh/kernel/cpu/sh4a/setup-shx3.c | 2 +-
> 15 files changed, 13 insertions(+), 16 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* 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
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