* Re: [PATCH v2 0/2] upboard pinctrl support for device id INTC1055
From: Andy Shevchenko @ 2026-06-15 14:07 UTC (permalink / raw)
To: Linus Walleij
Cc: GaryWang, Mika Westerberg, Andy Shevchenko, Thomas Richard,
Daniele Cleri, JunYingLai, Louis Chen, linux-gpio, linux-kernel
In-Reply-To: <CAD++jLmFKz19CRp-E=JcUnNkxNzKtSow6T8_9jDpR-wTrs9Ptw@mail.gmail.com>
On Mon, Jun 15, 2026 at 02:32:51PM +0200, Linus Walleij wrote:
> On Fri, Jun 12, 2026 at 12:13 PM GaryWang <is0124@gmail.com> wrote:
>
> > Add missing groups and functions in Tigerlake's pinctrl driver for INTC1055.
> > Add support "UP Xtreme i12", "UP Squared Pro 7000", "UP Squared i12", "UP 7000" boards.
> >
> > The pinctrl-upboard is provide additional driving power & pin mux function
> > through native SOC pins -> FPGA/CPLD -> hat pins for flexable board level
> > applications. it's probe from ACPI device id AANT0F01 & AANT0F04.
> >
> > Signed-off-by: GaryWang <is0124@gmail.com>
>
> LGTM
> Acked-by: Linus Walleij <linusw@kernel.org>
>
> Since these touch Tigerlake, I expect Andy to queue and send me
> the patches from his tree.
Yes, this is the idea, but first I want to hear form Gary about Up 7000, which
seems doesn't work with this.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [06/11] pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function
From: Wayen Yan @ 2026-06-15 13:23 UTC (permalink / raw)
To: mikhail.kshevetskiy; +Cc: linux-gpio, lorenzo
In-Reply-To: <20260606020342.1256509-7-mikhail.kshevetskiy@iopsys.eu>
On 2026-06-06, Mikhail Kshevetskiy wrote:
> phy4_led1 pin function maps led incorrectly. It uses the same map as
> phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
>
> Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Hi Mikhail,
Thanks for this fix series. I noticed that the same MAP(2) bug also
exists in the EN7581 phy4_led1 table, not just AN7583.
In drivers/pinctrl/mediatek/pinctrl-airoha.c:
EN7581 phy4_led1_func_group[] also uses LAN*_PHY_LED_MAP(2) — identical
to phy3_led1. Should be MAP(3) following the PHY{X} -> MAP(X-1) rule:
AIROHA_PINCTRL_PHY_LED1("gpio43", ..., LAN0_PHY_LED_MAP(2)), // EN7581
AIROHA_PINCTRL_PHY_LED1("gpio44", ..., LAN1_PHY_LED_MAP(2)), // EN7581
AIROHA_PINCTRL_PHY_LED1("gpio45", ..., LAN2_PHY_LED_MAP(2)), // EN7581
AIROHA_PINCTRL_PHY_LED1("gpio46", ..., LAN3_PHY_LED_MAP(2)), // EN7581
Could you include EN7581 in this fix as well?
Regards,
Wayen
^ permalink raw reply
* Re: [PATCH] pinctrl: Export pinctrl_get_group_selector()
From: Linus Walleij @ 2026-06-15 13:01 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Bartosz Golaszewski, Jia Wang, linux-gpio, Nathan Chancellor,
kernel test robot
In-Reply-To: <ai_0i2cicHHzwIXj@monoceros>
On Mon, Jun 15, 2026 at 2:49 PM Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
> On Mon, Jun 15, 2026 at 02:27:59PM +0200, Linus Walleij wrote:
> > On Mon, Jun 15, 2026 at 12:16 PM Uwe Kleine-König
> > <u.kleine-koenig@baylibre.com> wrote:
> > > Checkpatch criticises:
> > >
> > > WARNING: Reported-by: should be immediately followed by Closes: or Link: with a URL to the report
> > > #9:
> > > Reported-by: Nathan Chancellor <nathan@kernel.org>
> > > Reported-by: kernel test robot <lkp@intel.com>
> >
> > Now that is just checkpatch being silly, because what in in next looks
> > like this:
> >
> > Reported-by: Nathan Chancellor <nathan@kernel.org>
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202606130210.ytVPxHlm-lkp@intel.com/
> > Fixes: cb7037924836 ("pinctrl: ultrarisc: Add UltraRISC DP1000
> > pinctrl driver")
> > Signed-off-by: Linus Walleij <linusw@kernel.org>
>
> Yeah, so the kernel test robot report has a Closes, but Nathan's
> doesn't.
Ah OK I'll put the Link: to Nathans report as a Closes: instead.
Thanks!
Linus Walleij
^ permalink raw reply
* Re: [PATCH RFC 0/2] pinctrl: Add support gpiod_to_irq
From: Linus Walleij @ 2026-06-15 12:59 UTC (permalink / raw)
To: Xianwei Zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <2bb2c0e8-29e1-444b-851b-a9932f547c6a@amlogic.com>
On Mon, Jun 15, 2026 at 5:17 AM Xianwei Zhao <xianwei.zhao@amlogic.com> wrote:
> On 2026/6/11 20:51, Linus Walleij wrote:
> > Hi Xianwei,
> >
> > thanks for your patches!
> >
> > On Thu, Jun 11, 2026 at 9:54 AM Xianwei Zhao via B4 Relay
> > <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
> >
> >> Some users need to obtain an IRQ directly from a GPIO descriptor through gpiod_to_irq().
> >> Add the required DT binding and implementation to support this use case.
> >> Since this introduces a new DT property, the property is kept optional to
> >> maintain compatibility with existing SoCs and DTS files.
> > To me it looks like you have just re-implemented hierarchical
> > irqs.
> >
> > Look into the section "Infrastructure helpers for GPIO irqchips"
> > in Documentation/driver-api/gpio/driver.rst, especially towards
> > the end.
> >
> > Solve this by using GPIOLIB_IRQCHIP and a custom
> > child_to_parent_hwirq() callback to translate the GPIO into
> > an IRQ.
> >
> > To just implement gpiod_to_irq() without any irqchip abstraction
> > is also broken: you can't force all users to just use this way
> > to get an IRQ it's excessively restricting.
> >
> > Add
> >
> > interrupt-controller: true
> >
> > "#interrupt-cells":
> > const: 2
> >
> > to the pinctrl node as well so that DT users can simply request
> > the IRQ from the irqchip inside of the pin controller. It will
> > be hierarchical and lightweight but an irqchip nevertheless.
> >
> > The GPIOLIB_IRQCHIP approach will help you to get this
> > right.
> >
>
> I read the document (Documentation/driver-api/gpio/driver.rst) you
> pointed me to and found that the corresponding implementation has
> already been added in this file:
>
> https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-meson-gpio.c
That is the parent interrupt controller to the pinctrl+gpio isn't it.
It will be even clearer once you use interrupts = <>; instead of
the hwirq = <>; hack.
> However, it is implemented as a standalone irqchip and is not integrated
> with the GPIO controller.
Right, so it is the parent. Of course it it stand alone.
> In this patch, I implemented the GPIO-to-IRQ conversion through
> gpiod_to_irq(). Users can still obtain the interrupt directly through
> the interrupt property, for example:
>
> interrupts-extended = <&gpio_intc 16 1>;
>
> The purpose of this change is to make GPIO-to-IRQ conversion easier for
> users who do not want to know the actual interrupt number. The interrupt
> mapping is not fixed and varies between different SoCs, so users should
> not need to handle the hardware interrupt allocation details.
This is not why gpiod_to_irq() exists. It is not a convenience function
that is voluntary to implement.
If you implement gpiod_to_irq() you implement an entire
irqchip otherwise it is a bug.
If the pin control + GPIO driver should serve IRQ numbers in any
shape or form, you need to go the whole way and provide a
hierarchical irqchip.
It doesn't matter if you don't need to set a single bit in the
pinctrl + GPIO hardware for these IRQs, the fact that they are
routed internally on the SoC out through the pin control and
GPIO block by definition makes it hierarchical.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/8] irqchip/qcom-pdc: restructure version support
From: Maulik Shah (mkshah) @ 2026-06-15 12:55 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <e159fc1f-d4ca-4064-8c0a-17b75988f451@oss.qualcomm.com>
On 6/11/2026 4:18 PM, Konrad Dybcio wrote:
> On 5/26/26 12:54 PM, Maulik Shah wrote:
>> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
>> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
>> as below on various SoCs.
>
> [...]
>
>> +static const struct pdc_cfg pdc_cfg_v3_2 = {
>> + .irq_enable = GENMASK(3, 3),
>
> BIT(3)
Ack.
Stephan also gave same comment, i had kept GENMASK() to have uniformity but will replace with BIT() in v3.
>
> [...]
>
>
>> + pdc->base = ioremap(res.start, res_size);
>
> Can we use devm_ioremap() here?
We can. I will use devm_ioremap() and also replacing kzalloc() with devm_kzalloc() to remove the goto fail path.
>
> [...]
>
>> if (of_device_is_compatible(node, "qcom,x1e80100-pdc")) {
>> - pdc_prev_base = ioremap(res.start - PDC_DRV_SIZE, IRQ_ENABLE_BANK_MAX);
>> - if (!pdc_prev_base) {
>> + pdc->prev_base = ioremap(res.start - PDC_DRV_SIZE,
>> + pdc->regs->irq_en_reg + IRQ_ENABLE_BANK_MAX);
>
> likewise
>
Ack.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH] pinctrl: Export pinctrl_get_group_selector()
From: Uwe Kleine-König @ 2026-06-15 12:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Jia Wang, linux-gpio, Nathan Chancellor,
kernel test robot
In-Reply-To: <CAD++jLm+rv+Tm-WxvD51ynKeDUrPMAG=nfTNxRbf8FvSNy+dGQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
On Mon, Jun 15, 2026 at 02:27:59PM +0200, Linus Walleij wrote:
> On Mon, Jun 15, 2026 at 12:16 PM Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> > Checkpatch criticises:
> >
> > WARNING: Reported-by: should be immediately followed by Closes: or Link: with a URL to the report
> > #9:
> > Reported-by: Nathan Chancellor <nathan@kernel.org>
> > Reported-by: kernel test robot <lkp@intel.com>
>
> Now that is just checkpatch being silly, because what in in next looks
> like this:
>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606130210.ytVPxHlm-lkp@intel.com/
> Fixes: cb7037924836 ("pinctrl: ultrarisc: Add UltraRISC DP1000
> pinctrl driver")
> Signed-off-by: Linus Walleij <linusw@kernel.org>
Yeah, so the kernel test robot report has a Closes, but Nathan's
doesn't.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] MAINTAINERS: Add entry for Samsung Exynos8855 SoC
From: Linus Walleij @ 2026-06-15 12:39 UTC (permalink / raw)
To: Alim Akhtar
Cc: krzk, peter.griffin, robh, conor+dt, linux-samsung-soc,
linux-kernel, devicetree, linux-gpio, hajun.sung
In-Reply-To: <007a01dcfc9d$aa94dd60$ffbe9820$@samsung.com>
Hi Alim,
On Mon, Jun 15, 2026 at 10:05 AM Alim Akhtar <alim.akhtar@samsung.com> wrote:
> > On Fri, Jun 12, 2026 at 6:11 PM Alim Akhtar <alim.akhtar@samsung.com>
> > wrote:
> > > +F: arch/arm64/boot/dts/exynos/exynos8855*
^ Actually what I am requesting...
> > If you really want to single out a single platform like this (and I don't even
> > know if that is a good idea... how do you keep the big picture in mind?) you
> > should probably want to also add a wildcard for all the
> > 8855 device tree files.
> >
> I am also not sure, just followed what was done historically, other Exynos8855 file will get added once they
> are posted for review, e.g. clock driver.
> Let me discuss with Krzk during OSS (Mumbai) and see how do we handle this or any other better ways.
I just misread the patch, dunno why, probably too little coffee.
Sorry for the fuzz.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: pisosr: Read "ngpios" as u32
From: Linus Walleij @ 2026-06-15 12:37 UTC (permalink / raw)
To: Rob Herring (Arm); +Cc: Bartosz Golaszewski, linux-gpio, linux-kernel
In-Reply-To: <CAD++jLkEm5Pk2SOULp4GePwPCPO=xe_4pFvxOhZ8VQadhaYv+Q@mail.gmail.com>
On Sat, Jun 13, 2026 at 12:23 AM Linus Walleij <linusw@kernel.org> wrote:
> On Fri, Jun 12, 2026 at 11:52 PM Rob Herring (Arm) <robh@kernel.org> wrote:
>
> > The generic "ngpios" property is encoded as a normal uint32 cell. The
> > pisosr driver stores it in the gpio_chip field, but reading it with a
> > u16 helper does not match the DT property encoding.
> >
> > Read "ngpios" as u32 and keep the existing assignment to the chip
> > field.
> >
> > Assisted-by: Codex:gpt-5-5
> > Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
>
> Patch applied.
Oh no I don't. That's GPIO. Bartosz will look into it, I dropped it
from my tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: mvebu: fail probe if gpiochip registration fails
From: Linus Walleij @ 2026-06-15 12:35 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: Bartosz Golaszewski, linux-gpio, linux-kernel
In-Reply-To: <20260615092120.54741-1-pengpeng@iscas.ac.cn>
On Mon, Jun 15, 2026 at 11:21 AM Pengpeng Hou <pengpeng@iscas.ac.cn> wrote:
> The MVEBU GPIO probe path ignores the return value from
> devm_gpiochip_add_data(). If gpiochip registration fails, probe still
> continues into optional PWM and IRQ-domain setup as if the GPIO provider
> had been registered successfully.
>
> Propagate the gpiochip registration error and stop probing in that case.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
(...)
> - devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
> + err = devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
> + if (err)
> + return err;
Can't you use dev_err_probe() here like in the other patch
you sent?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: mlxbf3: fail probe if gpiochip registration fails
From: Linus Walleij @ 2026-06-15 12:34 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: Bartosz Golaszewski, linux-gpio, linux-kernel
In-Reply-To: <20260615091918.43333-1-pengpeng@iscas.ac.cn>
On Mon, Jun 15, 2026 at 11:19 AM Pengpeng Hou <pengpeng@iscas.ac.cn> wrote:
> mlxbf3_gpio_probe() logs a devm_gpiochip_add_data() failure but still
> returns success. That leaves the platform device bound even though the
> GPIO chip was not registered.
>
> Return the registration error so probe failure matches the missing
> gpiochip state.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 0/2] upboard pinctrl support for device id INTC1055
From: Linus Walleij @ 2026-06-15 12:32 UTC (permalink / raw)
To: GaryWang
Cc: Mika Westerberg, Andy Shevchenko, Thomas Richard, Daniele Cleri,
JunYingLai, Louis Chen, linux-gpio, linux-kernel
In-Reply-To: <20260612-upboard-pinctrl-add-upboard-intc1055-support-v2-0-4111b256c840@gmail.com>
On Fri, Jun 12, 2026 at 12:13 PM GaryWang <is0124@gmail.com> wrote:
> Add missing groups and functions in Tigerlake's pinctrl driver for INTC1055.
> Add support "UP Xtreme i12", "UP Squared Pro 7000", "UP Squared i12", "UP 7000" boards.
>
> The pinctrl-upboard is provide additional driving power & pin mux function
> through native SOC pins -> FPGA/CPLD -> hat pins for flexable board level
> applications. it's probe from ACPI device id AANT0F01 & AANT0F04.
>
> Signed-off-by: GaryWang <is0124@gmail.com>
LGTM
Acked-by: Linus Walleij <linusw@kernel.org>
Since these touch Tigerlake, I expect Andy to queue and send me
the patches from his tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: Export pinctrl_get_group_selector()
From: Linus Walleij @ 2026-06-15 12:27 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Bartosz Golaszewski, Jia Wang, linux-gpio, Nathan Chancellor,
kernel test robot
In-Reply-To: <ai_QMNydoXXoOFmB@monoceros>
On Mon, Jun 15, 2026 at 12:16 PM Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
> On Sat, Jun 13, 2026 at 10:02:30PM +0200, Linus Walleij wrote:
> > The recently added UltraRISC DP1000 is using this symbol, and in
> > a reasonable way as well, so export it.
> >
> > Reported-by: Nathan Chancellor <nathan@kernel.org>
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202606130210.ytVPxHlm-lkp@intel.com/
> > Fixes: cb7037924836 ("pinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver")
> > Signed-off-by: Linus Walleij <linusw@kernel.org>
>
> I stumbled over this one, too, and see that
>
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git for-next
>
> already has that patch. Checkpatch criticises:
>
> WARNING: Reported-by: should be immediately followed by Closes: or Link: with a URL to the report
> #9:
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Reported-by: kernel test robot <lkp@intel.com>
Now that is just checkpatch being silly, because what in in next looks
like this:
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606130210.ytVPxHlm-lkp@intel.com/
Fixes: cb7037924836 ("pinctrl: ultrarisc: Add UltraRISC DP1000
pinctrl driver")
Signed-off-by: Linus Walleij <linusw@kernel.org>
Certainly it doesn't matter which order the tags are in.
(And if it does, I don't feel it's important...)
> . Not sure if you consider this relevant to fix (i.e. add:
>
> Link: https://lore.kernel.org/linux-gpio/20260613164847.GA3152104@ax162/
>
> ), but if you do, feel free to also add:
>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
I added it, the more the merrier!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] Revert "i2c: designware: defer probe if child GpioInt controllers are not bound"
From: Linus Walleij @ 2026-06-15 12:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: Andi Shyti, Andy Shevchenko, Hardik Prakash, linux-i2c,
linux-gpio, wsa, mario.limonciello, brgl, basavaraj.natikar,
nathan, chaitanya.kumar.borah
In-Reply-To: <ai_d4eIId8Ml9g7I@ninjato>
On Mon, Jun 15, 2026 at 1:11 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > > $ git tag --contains ef76a3a28c79b6288
> > > next-20260601
> > > next-20260602
> > > next-20260603
> > > next-20260604
> > > next-20260605
> > > next-20260608
> > > next-20260609
> > > next-20260610
> > > next-20260611
> >
> > Yes, but I'm not finding out how it got there. I only see it in
> > one of Wolfram's branches, but I don't think it came in that way.
>
> IIRC I asked Linus Walleij to handle this via the GPIO tree because the
> proper fix landed there and the I2C addition was a mere cleanup from a
> previous attempt to fix the issue.
So this revert is not in my tree because it isn't needed: I never
sent the patch it is reverting to Torvalds to begin with. I even mentioned
this in my pull request to him: by being so lazy in sending my fixes
upstream I avoided the whole ordeal. Maybe I should always be lazy.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] Revert "i2c: designware: defer probe if child GpioInt controllers are not bound"
From: Linus Walleij @ 2026-06-15 12:21 UTC (permalink / raw)
To: Andi Shyti
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, andriy.shevchenko,
mario.limonciello, brgl, basavaraj.natikar, nathan,
chaitanya.kumar.borah
In-Reply-To: <ai8jhK9hUGHpojB5@zenone.zhora.eu>
On Sun, Jun 14, 2026 at 11:57 PM Andi Shyti <andi.shyti@kernel.org> wrote:
> On Wed, Jun 10, 2026 at 02:07:01PM +0530, Hardik Prakash wrote:
> > This reverts commit ef76a3a28c79b628890431aa344af633e892035b.
>
> Is this in your branch?
Nope. It was too late for me to handle as fix, what was merged for fixes was
this:
commit 3f786abd23951f3f600a62fef42469d9200d5f52
Author: Hardik Prakash <hardikprakash.official@gmail.com>
Date: Fri May 29 15:38:36 2026 +0530
Revert "pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo
Yoga 7 14AGP11"
This reverts commit 3812a9e84265a5cdd90d29fe8d97a023e91fb945.
This needs to go through the i2c tree at this point.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v13 17/22] media: i2c: maxim-serdes: add MAX96724 driver
From: Dan Carpenter @ 2026-06-15 12:19 UTC (permalink / raw)
To: Niklas Söderlund
Cc: dumitru.ceclan, Tomi Valkeinen, Mauro Carvalho Chehab,
Sakari Ailus, Laurent Pinchart, Julien Massot, Rob Herring,
Greg Kroah-Hartman, mitrutzceclan, linux-media, linux-kernel,
devicetree, linux-staging, linux-gpio, Martin Hecht,
Cosmin Tanislav, Cory Keitz
In-Reply-To: <ail9bHXL_NV2DZK5@stanley.mountain>
On Wed, Jun 10, 2026 at 06:06:20PM +0300, Dan Carpenter wrote:
> On Wed, Jun 10, 2026 at 04:42:42PM +0200, Niklas Söderlund wrote:
> > Hi,
> >
> > Thanks for your work.
> >
> > This patch gives me new compiler warnings, can they be avoided?
> >
> > .../max96724.c:402 max96724_log_phy_status() warn: subtract is higher precedence than shift
> > .../max96724.c:409 max96724_log_phy_status() warn: subtract is higher precedence than shift
> > .../max96724.c:588 max96724_init_phy() warn: subtract is higher precedence than shift
> > .../max96724.c:756 max96724_set_pipe_remap() warn: subtract is higher precedence than shift
> > .../max96724.c:796 max96724_set_pipe_phy() warn: subtract is higher precedence than shift
> > .../max96724.c:818 max96724_set_pipe_stream_id() warn: subtract is higher precedence than shift
> > .../max96724.c:830 max96724_set_pipe_link() warn: subtract is higher precedence than shift
> > .../max96724.c:942 max96724_set_link_version() warn: subtract is higher precedence than shift
> >
>
> These are Smatch warnings. I appologize for them. I know about them
> but I haven't looked at them. I'll fix them by the end of the week.
I've pushed a fix for these to the devel branch of Smatch.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: upboard: add device id INTC1055 based UP boards support
From: Thomas Richard @ 2026-06-15 12:13 UTC (permalink / raw)
To: GaryWang
Cc: Mika Westerberg, Andy Shevchenko, Linus Walleij, Daniele Cleri,
JunYingLai, Louis Chen, linux-gpio, linux-kernel
In-Reply-To: <CANYHO6qQituEPwAgb6YNRmsK0PbPxzKvSqSEHJApVw5xAzuHbg@mail.gmail.com>
On 6/15/26 1:23 PM, GaryWang wrote:
> On Mon, 15 Jun 2026 at 17:37, Thomas Richard <thomas.richard@bootlin.com> wrote:
>>
>> Gary,
>>
>> On 6/15/26 10:01 AM, Thomas Richard wrote:
>>> Hello Gary,
>>>
>>> On 6/12/26 12:13 PM, GaryWang wrote:
>>>> Add support "UP Xtreme i12", "UP Squared Pro 7000", "UP Squared i12",
>>>> "UP 7000" boards and I2C/PWM/UART/SPI pins mapping data.
>>>>
>>> Reviewed-by: Thomas Richard <thomas.richard@bootlin.com>
>>>
>>> Best Regards,
>>> Thomas
>>
>> I did test your series on UP Squared Pro 7000 and pinctrl driver does
>> not probe. Pinctrl device INTC1055:00 does not exist on this board.
>>
>> [ 12.818773] upboard-pinctrl upboard-pinctrl: unknown pinctrl device
>> INTC1055:00 in map entry, deferring probe
>> [ 12.818795] upboard-pinctrl upboard-pinctrl: error -EPROBE_DEFER:
>> Failed to select pinctrl
>> [ 12.818801] upboard-pinctrl upboard-pinctrl: Driver upboard-pinctrl
>> requests probe deferral
>> [ 12.818834] platform upboard-pinctrl: Added to deferred list
>> [ 12.818894] platform upboard-pinctrl: deferred probe pending:
>> upboard-pinctrl: Failed to select pinctrl
>>
>> Did you test your series on all boards?
>>
> Let me know your BIOS version, we;ll check internally, thanks.
So I tested all boards of the series. It is okay for "UP Xtreme i12" and
"UP Squared i12".
For "UP 7000" and "UP Squared Pro 7000" I have the same error,
INTC1055:00 does not exist. Pinctrl device is INTC1057:00.
Please find BIOS version for both boards below.
UP 7000:
# cat /sys/devices/virtual/dmi/id/bios_version
UPASAM10
# cat /sys/devices/virtual/dmi/id/bios_release
5.26
# cat /sys/devices/virtual/dmi/id/bios_date
04/23/2024
UP Squared Pro 7000:
# cat /sys/devices/virtual/dmi/id/bios_version
UNADAM21
# cat /sys/devices/virtual/dmi/id/bios_release
5.26
# cat /sys/devices/virtual/dmi/id/bios_date
04/18/2023
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: upboard: add device id INTC1055 based UP boards support
From: GaryWang @ 2026-06-15 11:23 UTC (permalink / raw)
To: Thomas Richard
Cc: Mika Westerberg, Andy Shevchenko, Linus Walleij, Daniele Cleri,
JunYingLai, Louis Chen, linux-gpio, linux-kernel
In-Reply-To: <cb694725-b3f3-40a3-94c7-0c1606aaea94@bootlin.com>
On Mon, 15 Jun 2026 at 17:37, Thomas Richard <thomas.richard@bootlin.com> wrote:
>
> Gary,
>
> On 6/15/26 10:01 AM, Thomas Richard wrote:
> > Hello Gary,
> >
> > On 6/12/26 12:13 PM, GaryWang wrote:
> >> Add support "UP Xtreme i12", "UP Squared Pro 7000", "UP Squared i12",
> >> "UP 7000" boards and I2C/PWM/UART/SPI pins mapping data.
> >>
> > Reviewed-by: Thomas Richard <thomas.richard@bootlin.com>
> >
> > Best Regards,
> > Thomas
>
> I did test your series on UP Squared Pro 7000 and pinctrl driver does
> not probe. Pinctrl device INTC1055:00 does not exist on this board.
>
> [ 12.818773] upboard-pinctrl upboard-pinctrl: unknown pinctrl device
> INTC1055:00 in map entry, deferring probe
> [ 12.818795] upboard-pinctrl upboard-pinctrl: error -EPROBE_DEFER:
> Failed to select pinctrl
> [ 12.818801] upboard-pinctrl upboard-pinctrl: Driver upboard-pinctrl
> requests probe deferral
> [ 12.818834] platform upboard-pinctrl: Added to deferred list
> [ 12.818894] platform upboard-pinctrl: deferred probe pending:
> upboard-pinctrl: Failed to select pinctrl
>
> Did you test your series on all boards?
>
Let me know your BIOS version, we;ll check internally, thanks.
> Best Regards,
> Thomas
^ permalink raw reply
* Re: [PATCH] Revert "i2c: designware: defer probe if child GpioInt controllers are not bound"
From: Wolfram Sang @ 2026-06-15 11:11 UTC (permalink / raw)
To: Andi Shyti
Cc: Andy Shevchenko, Hardik Prakash, linux-i2c, linux-gpio, wsa,
mario.limonciello, brgl, basavaraj.natikar, linusw, nathan,
chaitanya.kumar.borah
In-Reply-To: <ai_cAd41W3iX1ic-@zenone.zhora.eu>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
> > $ git tag --contains ef76a3a28c79b6288
> > next-20260601
> > next-20260602
> > next-20260603
> > next-20260604
> > next-20260605
> > next-20260608
> > next-20260609
> > next-20260610
> > next-20260611
>
> Yes, but I'm not finding out how it got there. I only see it in
> one of Wolfram's branches, but I don't think it came in that way.
IIRC I asked Linus Walleij to handle this via the GPIO tree because the
proper fix landed there and the I2C addition was a mere cleanup from a
previous attempt to fix the issue.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] Revert "i2c: designware: defer probe if child GpioInt controllers are not bound"
From: Andi Shyti @ 2026-06-15 11:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, mario.limonciello,
brgl, basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah
In-Reply-To: <ai_PwNWnMZB01AYU@ashevche-desk.local>
Hi Andy,
> > > This reverts commit ef76a3a28c79b628890431aa344af633e892035b.
> >
> > Is this in your branch?
>
> $ git tag --contains ef76a3a28c79b6288
> next-20260601
> next-20260602
> next-20260603
> next-20260604
> next-20260605
> next-20260608
> next-20260609
> next-20260610
> next-20260611
Yes, but I'm not finding out how it got there. I only see it in
one of Wolfram's branches, but I don't think it came in that way.
I can merge this revert as well, but only after the original
patch hits mainline.
Andi
^ permalink raw reply
* Re: [PATCH 05/10] [v2] mips: select legacy gpiolib interfaces where used
From: Thomas Bogendoerfer @ 2026-06-15 10:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, linux-kernel, Arnd Bergmann, Christian Lamparter,
Johannes Berg, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, John Paul Adrian Glaubitz,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Lee Jones, Pavel Machek, Matti Vaittinen,
Florian Fainelli, Jonas Gorski, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-wireless, linux-omap, linux-arm-kernel, linux-mips,
linux-sh, linux-input, linux-leds, netdev, Bartosz Golaszewski
In-Reply-To: <20260520183815.2510387-6-arnd@kernel.org>
On Wed, May 20, 2026 at 08:38:10PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> A few old machines have not been converted away from the old-style
> gpiolib interfaces. Make these select the new CONFIG_GPIOLIB_LEGACY
> symbol so the code still works where it is needed but can be left
> out otherwise.
>
> This is the list of all gpio_request() calls in mips:
>
> arch/mips/alchemy/devboards/db1000.c: gpio_request(19, "sd0_cd");
> arch/mips/alchemy/devboards/db1000.c: gpio_request(20, "sd1_cd");
> arch/mips/alchemy/devboards/db1200.c: gpio_request(215, "otg-vbus");
> arch/mips/bcm47xx/workarounds.c: err = gpio_request_one(usb_power, GPIOF_OUT_INIT_HIGH, "usb_power");
> arch/mips/bcm63xx/boards/board_bcm963xx.c: gpio_request_one(board.ephy_reset_gpio,
> arch/mips/txx9/rbtx4927/setup.c: gpio_request(15, "sio-dtr");
>
> Most of these should be easy enough to change to modern gpio descriptors
> or remove if they are no longer in use.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: no changes. There was no discussion on this, but the patch
> has so far not made it into the linux-mips tree, so I'm including
> it for completeness.
> ---
> arch/mips/Kconfig | 5 +++++
> arch/mips/alchemy/Kconfig | 1 -
> arch/mips/txx9/Kconfig | 1 +
> 3 files changed, 6 insertions(+), 1 deletion(-)
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH] pinctrl: Export pinctrl_get_group_selector()
From: Uwe Kleine-König @ 2026-06-15 10:16 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Jia Wang, linux-gpio, Nathan Chancellor,
kernel test robot
In-Reply-To: <20260613-export-get-group-selector-v1-1-fc4451a9ff0e@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
Hello,
On Sat, Jun 13, 2026 at 10:02:30PM +0200, Linus Walleij wrote:
> The recently added UltraRISC DP1000 is using this symbol, and in
> a reasonable way as well, so export it.
>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606130210.ytVPxHlm-lkp@intel.com/
> Fixes: cb7037924836 ("pinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver")
> Signed-off-by: Linus Walleij <linusw@kernel.org>
I stumbled over this one, too, and see that
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git for-next
already has that patch. Checkpatch criticises:
WARNING: Reported-by: should be immediately followed by Closes: or Link: with a URL to the report
#9:
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reported-by: kernel test robot <lkp@intel.com>
. Not sure if you consider this relevant to fix (i.e. add:
Link: https://lore.kernel.org/linux-gpio/20260613164847.GA3152104@ax162/
), but if you do, feel free to also add:
Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] Revert "i2c: designware: defer probe if child GpioInt controllers are not bound"
From: Andy Shevchenko @ 2026-06-15 10:11 UTC (permalink / raw)
To: Andi Shyti
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, mario.limonciello,
brgl, basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah
In-Reply-To: <ai8jhK9hUGHpojB5@zenone.zhora.eu>
On Sun, Jun 14, 2026 at 11:56:55PM +0200, Andi Shyti wrote:
> Hi Linus,
>
> On Wed, Jun 10, 2026 at 02:07:01PM +0530, Hardik Prakash wrote:
> > This reverts commit ef76a3a28c79b628890431aa344af633e892035b.
>
> Is this in your branch?
$ git tag --contains ef76a3a28c79b6288
next-20260601
next-20260602
next-20260603
next-20260604
next-20260605
next-20260608
next-20260609
next-20260610
next-20260611
> > The patch causes boot regressions on multiple machines. A NULL pointer
> > dereference occurs when agpio->resource_source.string_ptr is NULL (i.e.
> > when string_length is 0), and a probe deferral loop causes CPU starvation
> > leading to kernel panic on Intel CI machines.
> >
> > The patch needs a proper rewrite addressing these issues before resubmission.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/2] upboard pinctrl support for device id INTC1055
From: Mika Westerberg @ 2026-06-15 9:47 UTC (permalink / raw)
To: GaryWang
Cc: Andy Shevchenko, Linus Walleij, Thomas Richard, Daniele Cleri,
JunYingLai, Louis Chen, linux-gpio, linux-kernel
In-Reply-To: <CANYHO6rT6pPSZAts80YsFmZ8vCNyzmEm94sSheE-0NbUdZ_=OA@mail.gmail.com>
On Mon, Jun 15, 2026 at 03:01:23PM +0800, GaryWang wrote:
> On Mon, 15 Jun 2026 at 12:35, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > Hi,
> >
> > On Fri, Jun 12, 2026 at 06:13:31PM +0800, GaryWang wrote:
> > > Add missing groups and functions in Tigerlake's pinctrl driver for INTC1055.
> > > Add support "UP Xtreme i12", "UP Squared Pro 7000", "UP Squared i12", "UP 7000" boards.
> > >
> > > The pinctrl-upboard is provide additional driving power & pin mux function
> > > through native SOC pins -> FPGA/CPLD -> hat pins for flexable board level
> > > applications. it's probe from ACPI device id AANT0F01 & AANT0F04.
> > >
> > > Signed-off-by: GaryWang <is0124@gmail.com>
> > > ---
> > > Changes in v2:
> > > - Add brief introduction pinctrl-upboard architecture in cover content.
> > > - Add more detail explaining for pinctrl-tigerlake commit message.
> > > - Link to v1: https://lore.kernel.org/r/20260610-upboard-pinctrl-add-upboard-intc1055-support-v1-0-8185d2abbfb1@gmail.com
> > >
> > > ---
> > > GaryWang (2):
> > > pinctrl: tigerlake: add some pin groups and functions for INTC1055
> > > pinctrl: upboard: add device id INTC1055 based UP boards support
> >
> > Both,
> Sorry, I am unclear what Both?
Both patches :)
> >
> > Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: upboard: add device id INTC1055 based UP boards support
From: Thomas Richard @ 2026-06-15 9:37 UTC (permalink / raw)
To: GaryWang, Mika Westerberg, Andy Shevchenko, Linus Walleij
Cc: Daniele Cleri, JunYingLai, Louis Chen, linux-gpio, linux-kernel
In-Reply-To: <d6453a9c-d2f1-4aef-8caf-e351c210d6bb@bootlin.com>
Gary,
On 6/15/26 10:01 AM, Thomas Richard wrote:
> Hello Gary,
>
> On 6/12/26 12:13 PM, GaryWang wrote:
>> Add support "UP Xtreme i12", "UP Squared Pro 7000", "UP Squared i12",
>> "UP 7000" boards and I2C/PWM/UART/SPI pins mapping data.
>>
> Reviewed-by: Thomas Richard <thomas.richard@bootlin.com>
>
> Best Regards,
> Thomas
I did test your series on UP Squared Pro 7000 and pinctrl driver does
not probe. Pinctrl device INTC1055:00 does not exist on this board.
[ 12.818773] upboard-pinctrl upboard-pinctrl: unknown pinctrl device
INTC1055:00 in map entry, deferring probe
[ 12.818795] upboard-pinctrl upboard-pinctrl: error -EPROBE_DEFER:
Failed to select pinctrl
[ 12.818801] upboard-pinctrl upboard-pinctrl: Driver upboard-pinctrl
requests probe deferral
[ 12.818834] platform upboard-pinctrl: Added to deferred list
[ 12.818894] platform upboard-pinctrl: deferred probe pending:
upboard-pinctrl: Failed to select pinctrl
Did you test your series on all boards?
Best Regards,
Thomas
^ permalink raw reply
* [PATCH] gpio: mvebu: fail probe if gpiochip registration fails
From: Pengpeng Hou @ 2026-06-15 9:21 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, linux-gpio, linux-kernel; +Cc: Pengpeng Hou
The MVEBU GPIO probe path ignores the return value from
devm_gpiochip_add_data(). If gpiochip registration fails, probe still
continues into optional PWM and IRQ-domain setup as if the GPIO provider
had been registered successfully.
Propagate the gpiochip registration error and stop probing in that case.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/gpio/gpio-mvebu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index c030d1f00abc..50dc8179cf73 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -1221,7 +1221,9 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
BUG();
}
- devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
+ err = devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
+ if (err)
+ return err;
/* Some MVEBU SoCs have simple PWM support for GPIO lines */
if (IS_REACHABLE(CONFIG_PWM)) {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
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