* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Kiryl Shutsemau @ 2026-06-29 16:53 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <akKVKhOsv6EJVFv4@arm.com>
On Mon, Jun 29, 2026 at 04:54:18PM +0100, Catalin Marinas wrote:
> Have you tried SDEI_EVENT_COMPLETE_AND_RESUME instead? Just COMPLETE
> won't return to the kernel. We have sdei_handler_abort() to complete the
> event and, hopefully, you can continue with the CPU_OFF. It's a work
> around the TF-A non-compliance but I think this is useful even if you
> don't issue the CPU_OFF (e.g. no CPU hotplug, just the park loop).
Tried it. The result is the opposite of what I expected, and it argues
against doing the complete at all under QEMU's TF-A.
Same A/B harness as before -- a CPU wedged with interrupts masked is
stopped via the SDEI rung; I only vary how its handler ends. kdump
capture kernel boot under QEMU:
- park, event left uncompleted (current series): boots to a shell
- sdei_handler_abort() then CPU_OFF: hangs at SDEI re-init
- sdei_handler_abort() then park (no CPU_OFF): hangs at SDEI re-init
- CPU_OFF, event left uncompleted: hangs at SDEI re-init
The third line is the surprising one: completing the event via
sdei_handler_abort() and then just parking -- no CPU_OFF at all -- breaks
the capture kernel too, at the same point as CPU_OFF does. The only
variant that boots is the one that leaves the event uncompleted and
parks. So here it's completing the event that the capture kernel trips
over, not the dangling dispatch -- backwards from the non-compliance
theory, where completing should be the safe thing and "useful even
without CPU_OFF".
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Bartosz Golaszewski @ 2026-06-29 16:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Magnus Damm, Maxime Ripard, Christophe Roullier, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <CAMuHMdVUBgG0EFB16OxHisbxx-sBvDKvBPNZdpyDnmBrnX4ptQ@mail.gmail.com>
On Mon, Jun 29, 2026 at 4:58 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Bartosz,
>
> On Mon, 29 Jun 2026 at 16:07, Bartosz Golaszewski <brgl@kernel.org> wrote:
> > On Mon, 29 Jun 2026 15:51:31 +0200, Geert Uytterhoeven
> > <geert@linux-m68k.org> said:
> > > On Mon, 29 Jun 2026 at 13:29, Bartosz Golaszewski
> > > <bartosz.golaszewski@oss.qualcomm.com> wrote:
> > >> Describe the SGMII/SerDes PHY present on the Qualcomm sa8255p platforms.
> > >> This is essentially the same hardware as sa8775p rev3 but the PHY is
> > >> managed by firmware over SCMI.
> > >
> > > So why can't it be reuse the DT bindings, and be compatible with
> > > qcom,sa8775p-dwmac-sgmii-phy?
> > >
> > >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > >
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-dwmac-sgmii-phy.yaml
> > >
> > >> + power-domains:
> > >> + maxItems: 1
> > >> +
> > >> + power-domain-names:
> > >> + items:
> > >> + - const: serdes
> > >
> > >> +examples:
> > >> + - |
> > >> + phy@8901000 {
> > >> + compatible = "qcom,sa8255p-dwmac-sgmii-phy";
> > >> + reg = <0x08901000 0xe10>;
> > >> + #phy-cells = <0>;
> > >> + power-domains = <&scmi7_dvfs 0>;
> > >> + power-domain-names = "serdes";
> > >
> > > Ah, this uses power-domains, while the existing bindings for
> > > qcom,sa8775p-dwmac-sgmii-phy use a clock.
> > > I guess the clock is the correct hardware description?
> > >
> > > Adding to my list of examples for backing a hardware-to-SCMI remapping
> > > driver...
> > >
> >
> > Russell King asked me to put the PHY logic for SCMI pm domains into the PHY
> > driver instead of the MAC driver where it was previously. Instead of cramming
> > both HLOS and firmware handling into the same driver, I figured it makes more
> > sense to have a dedicated, cleaner driver as the two share very little code (if
> > any).
>
> I think you are mixing up DT bindings and driver implementation?
>
Ah indeed, but the bindings don't share a lot of content either.
Bartosz
^ permalink raw reply
* Re: [PATCH] soc: ti: knav_dma: remove debugfs file on teardown
From: Nishanth Menon @ 2026-06-29 16:54 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: Santosh Shilimkar, linux-kernel, linux-arm-kernel
In-Reply-To: <20260615091200.2373-1-pengpeng@iscas.ac.cn>
On 17:12-20260615, Pengpeng Hou wrote:
> knav_dma_probe() creates the global knav_dma debugfs file whose show
> callback walks the global kdev list. knav_dma_remove() tears down the DMA
> instances and runtime PM but leaves that debugfs file and global ready
> state behind.
>
> Save the debugfs dentry, remove it before destroying the DMA state, and
> clear the global ready pointer state during remove.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/soc/ti/knav_dma.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
> index e5f5e3142fc4..9277c525ac21 100644
> --- a/drivers/soc/ti/knav_dma.c
> +++ b/drivers/soc/ti/knav_dma.c
> @@ -125,6 +125,7 @@ struct knav_dma_chan {
> ch->channel : ch->flow)
>
> static struct knav_dma_pool_device *kdev;
> +static struct dentry *knav_dma_debugfs;
Similar comment as previous patch to consider moving this to
knav_dma_pool_device.
>
> static bool device_ready;
> bool knav_dma_device_ready(void)
> @@ -740,8 +741,9 @@ static int knav_dma_probe(struct platform_device *pdev)
> goto err_put_sync;
> }
>
> - debugfs_create_file("knav_dma", S_IFREG | S_IRUGO, NULL, NULL,
> - &knav_dma_debug_fops);
> + knav_dma_debugfs = debugfs_create_file("knav_dma", 0444,
0444 is worth mentioning in the commit message.
> + NULL, NULL,
> + &knav_dma_debug_fops);
>
> device_ready = true;
> return ret;
> @@ -758,6 +760,10 @@ static void knav_dma_remove(struct platform_device *pdev)
> {
> struct knav_dma_device *dma;
>
> + device_ready = false;
> + debugfs_remove(knav_dma_debugfs);
> + knav_dma_debugfs = NULL;
> +
> list_for_each_entry(dma, &kdev->list, list) {
> if (atomic_dec_return(&dma->ref_count) == 0)
> knav_dma_hw_destroy(dma);
> @@ -765,6 +771,7 @@ static void knav_dma_remove(struct platform_device *pdev)
>
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> + kdev = NULL;
Also worth stating in the commit message.
> }
>
> static struct of_device_id of_match[] = {
> --
> 2.50.1 (Apple Git-155)
>
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
From: Frank.Li @ 2026-06-29 16:54 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel
Cc: Frank Li, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260611-imx8mp-frdm-hdmi-ddc-v1-1-b4e4c9bb0729@pengutronix.de>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 11 Jun 2026 10:18:59 +0200, Philipp Zabel wrote:
> Configure HDMI DDC SCL/SDA pins to support reading EDID.
Applied, thanks!
[1/1] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
commit: d701830f981856dd41149182c5d98ba996bf2d68
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v1] MAINTAINERS: Add git tree for TI K3 ARCHITECTURE
From: Nishanth Menon @ 2026-06-29 16:57 UTC (permalink / raw)
To: Vignesh Raghavendra, Tero Kristo, linux-arm-kernel, linux-kernel,
Francesco Dolcini
Cc: Nishanth Menon, Francesco Dolcini
In-Reply-To: <20260615132640.161584-1-francesco@dolcini.it>
Hi Francesco Dolcini,
On Mon, 15 Jun 2026 15:26:38 +0200, Francesco Dolcini wrote:
> Add git tree for TI K3 architecture.
I have applied the following to branch ti-k3-maintainer-next on [1].
Thank you!
[1/1] MAINTAINERS: Add git tree for TI K3 ARCHITECTURE
commit: 4fb6763ec70d49f592cc6e684bfc5f17a7db7133
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH] firmware: ti_sci: undo list publication on populate failure
From: Nishanth Menon @ 2026-06-29 16:57 UTC (permalink / raw)
To: Tero Kristo, Santosh Shilimkar, linux-arm-kernel, linux-kernel,
Pengpeng Hou
Cc: Nishanth Menon
In-Reply-To: <20260616004741.1726-1-pengpeng@iscas.ac.cn>
Hi Pengpeng Hou,
On Tue, 16 Jun 2026 08:47:41 +0800, Pengpeng Hou wrote:
> ti_sci_probe() publishes the controller on the global ti_sci_list before
> creating child devices. If of_platform_populate() fails after creating
> some children, the probe error path leaves the children around and leaves
> the failed controller visible through ti_sci_get_handle().
>
> Depopulate any children created by the failed populate call and remove
> the controller from the global list before returning the probe error.
>
> [...]
I have applied the following to branch ti-drivers-soc-next on [1].
Thank you!
[1/1] firmware: ti_sci: undo list publication on populate failure
commit: f52ddaf5e771c753663a719834848fde92b219f8
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v4] arm64: dts: imx94: Add Root Port node and PERST property
From: Frank Li @ 2026-06-29 16:59 UTC (permalink / raw)
To: hongxing.zhu
Cc: sherry.sun, robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam,
kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
In-Reply-To: <20260616072334.1107262-1-hongxing.zhu@oss.nxp.com>
On Tue, Jun 16, 2026 at 03:23:34PM +0800, hongxing.zhu@oss.nxp.com wrote:
> From: Richard Zhu <hongxing.zhu@nxp.com>
>
> Since describing the PCIe PERST# property under Host Bridge node is now
> deprecated, it is recommended to add it to the Root Port node, so
> creating the Root Port node and add the reset-gpios property in Root
> Port.
> Move the regulator to Root Port nodes as well, because that the PCI
> pwrctrl framework had been integrated into pci-imx6 driver.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Reviewed-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx94.dtsi | 11 +++++++++++
> arch/arm64/boot/dts/freescale/imx943-evk.dts | 14 ++++++++++----
> arch/arm64/boot/dts/freescale/imx943.dtsi | 11 +++++++++++
use two patch, one patch only change chip's dtsi, the other one update
boards's dts
Frank
> 3 files changed, 32 insertions(+), 4 deletions(-)
> ---
> Changes in v4:
> Add the description of regualtor changes into commit message too.
>
> Changes in v3:
> - Move the regulator to Root Port node as well, since [2] had been
> settled.
> - Collect Reviewed-by tag issued by Sherry.
>
> Changes in v2:
> - Delete reset-gpio properties in PCIe bridge node.
> - Correct the "reset-gpio" property to "reset-gpios".
>
> Since the patch-set [1] issued by Sherry had been landed. Add according
> changes on i.MX943 board too.
> [1] https://lkml.org/lkml/2026/6/1/1461
> [2] https://lore.kernel.org/imx/20260520084904.2424253-1-sherry.sun@oss.nxp.com/
>
> diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
> index 1f9035e6cf159..dfbb73603cb24 100644
> --- a/arch/arm64/boot/dts/freescale/imx94.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
> @@ -1411,6 +1411,17 @@ pcie0: pcie@4c300000 {
> power-domains = <&scmi_devpd IMX94_PD_HSIO_TOP>;
> fsl,max-link-speed = <3>;
> status = "disabled";
> +
> + pcie0_port0: pcie@0 {
> + compatible = "pciclass,0604";
> + device_type = "pci";
> + reg = <0x0 0x0 0x0 0x0 0x0>;
> + bus-range = <0x01 0xff>;
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges;
> + };
> };
>
> pcie0_ep: pcie-ep@4c300000 {
> diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> index 7cfd424689507..674410e541cba 100644
> --- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> @@ -1034,12 +1034,15 @@ &pcie0 {
> <&pcie_ref_clk>;
> clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
> "ref", "extref";
> - reset-gpio = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
> - vpcie3v3aux-supply = <®_m2_wlan>;
> supports-clkreq;
> status = "okay";
> };
>
> +&pcie0_port0 {
> + reset-gpios = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
> + vpcie3v3aux-supply = <®_m2_wlan>;
> +};
> +
> &pcie0_ep {
> pinctrl-0 = <&pinctrl_pcie0>;
> pinctrl-names = "default";
> @@ -1058,12 +1061,15 @@ &pcie1 {
> <&pcie_ref_clk>;
> clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
> "ref", "extref";
> - reset-gpio = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
> - vpcie3v3aux-supply = <®_slot_pwr>;
> supports-clkreq;
> status = "okay";
> };
>
> +&pcie1_port0 {
> + reset-gpios = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
> + vpcie3v3aux-supply = <®_slot_pwr>;
> +};
> +
> &pcie1_ep {
> pinctrl-0 = <&pinctrl_pcie1>;
> pinctrl-names = "default";
> diff --git a/arch/arm64/boot/dts/freescale/imx943.dtsi b/arch/arm64/boot/dts/freescale/imx943.dtsi
> index cf5b3dbb47ff7..01152fd0efa5e 100644
> --- a/arch/arm64/boot/dts/freescale/imx943.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx943.dtsi
> @@ -255,6 +255,17 @@ pcie1: pcie@4c380000 {
> power-domains = <&scmi_devpd IMX94_PD_HSIO_TOP>;
> fsl,max-link-speed = <3>;
> status = "disabled";
> +
> + pcie1_port0: pcie@0 {
> + compatible = "pciclass,0604";
> + device_type = "pci";
> + reg = <0x0 0x0 0x0 0x0 0x0>;
> + bus-range = <0x01 0xff>;
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges;
> + };
> };
>
> pcie1_ep: pcie-ep@4c380000 {
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH V1] arm64: dts: imx8mq-evk: add uart3 and bluetooth node
From: Frank.Li @ 2026-06-29 17:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam,
Sherry Sun (OSS)
Cc: Frank Li, imx, devicetree, linux-arm-kernel, linux-kernel,
sherry.sun
In-Reply-To: <20260616105201.3214395-1-sherry.sun@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 16 Jun 2026 18:52:00 +0800, Sherry Sun (OSS) wrote:
> Add uart3 and bluetooth node.
Applied, thanks!
[1/1] arm64: dts: imx8mq-evk: add uart3 and bluetooth node
commit: 4f36d5cd0dce934994da4b4be5776abd74c837ab
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v1] ARM: imx: avic: Fix OF node reference leaks
From: Frank.Li @ 2026-06-29 17:05 UTC (permalink / raw)
To: Sascha Hauer, Russell King, Pengutronix Kernel Team, Yuho Choi
Cc: Frank Li, Fabio Estevam, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20260615174535.701013-1-dbgh9129@gmail.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 15 Jun 2026 13:45:35 -0400, Yuho Choi wrote:
> of_find_compatible_node() returns a device node with its reference count
> incremented. mxc_init_irq() looks up the i.MX25 CCM node for of_iomap()
> and the AVIC node for irq_domain_create_legacy(), but does not release
> either temporary reference.
>
> of_iomap() does not consume the node reference, and
> irq_domain_create_legacy() takes its own fwnode reference for the domain.
> Drop the temporary OF node references after each use.
>
> [...]
Applied, thanks!
[1/1] ARM: imx: avic: Fix OF node reference leaks
commit: b24c12e1bad863d27141e4e9c19d25eebd68c4a6
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Bartosz Golaszewski @ 2026-06-29 17:06 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260625115718.1678991-2-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:17 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
> runtime from the underlying chip's can_sleep:
>
> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
>
> can_sleep describes only the value path (->get/->set). Under the same
> lock, however, the proxy may call gpiod_set_config() and
> gpiod_direction_*(), which can reach pinctrl paths that take a mutex
> (e.g. gpiod_set_config() -> gpiochip_generic_config() ->
> pinctrl_gpio_set_config()), independent of can_sleep. On a controller
> with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
> the sleeping pinctrl call ran from atomic context. Reproduced on an
> Amlogic A113X board with the workaround from commit 28f240683871
> ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
> original Khadas VIM3 report hit the same path:
>
> BUG: sleeping function called from invalid context
> __mutex_lock
> pinctrl_get_device_gpio_range
> pinctrl_gpio_set_config
> gpiochip_generic_config
> gpiod_set_config
> gpio_shared_proxy_set_config <- voting spinlock held
> ...
> mmc_pwrseq_simple_probe
>
> The spinlock existed to take the value vote from atomic context, but the
> vote and the (possibly sleeping) control operations share the same state
> and lock, so this scheme cannot serialize config under a mutex and still
> offer atomic value access. Always serialize the shared descriptor with a
> mutex instead and mark the proxy a sleeping gpiochip, driving the
> underlying GPIO through the cansleep value accessors: those are valid
> for both sleeping and non-sleeping chips, so value access keeps working
> on fast controllers, at the cost of no longer being atomic.
>
> This is observable: consumers gating on gpiod_cansleep() take their
> sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
> emergency-restart reset handler; its normal reset is unaffected), and
> consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
> fail to probe. Such atomic users do not share a pin through the proxy,
> whose purpose is voting on shared reset/enable lines. The same narrowing
> already applies on Amlogic since that workaround, and rockchip
> addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
> rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
> addresses the locking error once, for every controller.
>
> The lock type was added by commit a060b8c511ab ("gpiolib: implement
> low-level, shared GPIO support"); the sleeping call under it arrived with
> the proxy driver.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
> ---
> v1 -> v2: open-code the descriptor mutex; drop the gpio_shared_desc_lock
> guard and the gpio_shared_lockdep_assert() helper, use
> guard(mutex) and lockdep_assert_held() directly; move the
> mutex rationale from the header to the can_sleep assignment in
> probe.
>
> v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-2-v@baodeep.com/
>
> drivers/gpio/gpio-shared-proxy.c | 66 +++++++++++++-------------------
> drivers/gpio/gpiolib-shared.c | 9 +----
> drivers/gpio/gpiolib-shared.h | 28 +-------------
> 3 files changed, 29 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpio/gpio-shared-proxy.c b/drivers/gpio/gpio-shared-proxy.c
> index 6941e4be6cf1..0cd52015b731 100644
> --- a/drivers/gpio/gpio-shared-proxy.c
> +++ b/drivers/gpio/gpio-shared-proxy.c
> @@ -9,8 +9,10 @@
> #include <linux/err.h>
> #include <linux/gpio/consumer.h>
> #include <linux/gpio/driver.h>
> +#include <linux/lockdep.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/mutex.h>
> #include <linux/string_choices.h>
> #include <linux/types.h>
>
> @@ -32,7 +34,7 @@ gpio_shared_proxy_set_unlocked(struct gpio_shared_proxy_data *proxy,
I was about to apply it but then realized that it can be simplified further.
The set_func() argument in gpio_shared_proxy_set_unlocked() is no longer
needed and can be replaced with a direct call to gpiod_set_value_cansleep().
Would you mind sending a v3 with that included?
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v3] clk: mvebu: ap-cpu: fix missing clk_put() in ap_cpu_clock_probe()
From: Brian Masney @ 2026-06-29 17:14 UTC (permalink / raw)
To: Wentao Liang
Cc: andrew, gregory.clement, sebastian.hesselbarth, mturquette, sboyd,
linux-arm-kernel, linux-clk, linux-kernel
In-Reply-To: <20260617014126.1716291-1-vulab@iscas.ac.cn>
Hi Wentao,
On Wed, Jun 17, 2026 at 01:41:26AM +0000, Wentao Liang wrote:
> The function ap_cpu_clock_probe() calls of_clk_get() to obtain a
> reference to the parent clock for each CPU cluster, but it never
> releases it with clk_put(). The returned clk is used only to read
> the parent's name via __clk_get_name(), and the reference is leaked
> on every successful cluster initialization as well as on the error
> path when devm_clk_hw_register() fails.
>
> Rather than adding clk_put() calls, replace the of_clk_get() +
> __clk_get_name() pattern with of_clk_get_parent_name(), which is
> the intended API for this use case and handles the reference
> counting internally. This matches the pattern already used by the
> sibling drivers clk-cpu.c and clk-corediv.c.
>
> Fixes: f756e362d9384 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> v3: Replace incorrect Fixes tag.
> v2: Replace of_clk_get() + __clk_get_name() with of_clk_get_parent_name()
> as suggested by Brian Masney, instead of adding clk_put() calls.
> Also correct the Fixes: tag to point to the original commit that
> introduced the leak.
> ---
> drivers/clk/mvebu/ap-cpu-clk.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/mvebu/ap-cpu-clk.c b/drivers/clk/mvebu/ap-cpu-clk.c
> index a8175908e353..1cf63c7a0bc3 100644
> --- a/drivers/clk/mvebu/ap-cpu-clk.c
> +++ b/drivers/clk/mvebu/ap-cpu-clk.c
> @@ -288,7 +288,6 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
> char *clk_name = "cpu-cluster-0";
> struct clk_init_data init;
> const char *parent_name;
> - struct clk *parent;
> u64 cpu;
>
> cpu = of_get_cpu_hwid(dn, 0);
> @@ -304,13 +303,12 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
> if (ap_cpu_data->hws[cluster_index])
> continue;
>
> - parent = of_clk_get(np, cluster_index);
> - if (IS_ERR(parent)) {
> - dev_err(dev, "Could not get the clock parent\n");
> + parent_name = of_clk_get_parent_name(np, cluster_index);
> + if (!parent_name) {
> + dev_err(dev, "Could not get the clock parent name\n");
> of_node_put(dn);
> return -EINVAL;
> }
> - parent_name = __clk_get_name(parent);
> clk_name[12] += cluster_index;
> ap_cpu_clk[cluster_index].clk_name =
> ap_cp_unique_name(dev, np->parent, clk_name);
> @@ -328,11 +326,9 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
> ret = devm_clk_hw_register(dev, &ap_cpu_clk[cluster_index].hw);
> if (ret) {
> of_node_put(dn);
> - clk_put(parent);
> return ret;
> }
> ap_cpu_data->hws[cluster_index] = &ap_cpu_clk[cluster_index].hw;
> - clk_put(parent);
> }
This doesn't apply against Linus's latest tree. It looks like it's just
this last chunk that's the issue. What version of the kernel did you develop
this against? The last change to this driver upstream was from me in August
2025.
Please submit a new version that applies cleanly upstream.
Brian
^ permalink raw reply
* Re: [PATCH v2 06/13] KVM: arm64: dirty_bit: Add base FEAT_HACDBS cleaning routine
From: Oliver Upton @ 2026-06-29 17:36 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Jonathan Cameron,
Chengwen Feng, Kees Cook, Mikołaj Lenczewski, James Morse,
Zeng Heng, mrigendrachaubey, Thomas Huth, Ryan Roberts,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark, Fuad Tabba,
Raghavendra Rao Ananta, Lorenzo Pieralisi, Sascha Bischoff,
Anshuman Khandual, Tian Zheng, linux-arm-kernel, linux-kernel,
kvmarm, linux-acpi, acpica-devel, kvm
In-Reply-To: <20260629111820.1873540-7-leo.bras@arm.com>
On Mon, Jun 29, 2026 at 12:17:54PM +0100, Leonardo Bras wrote:
> Introduce the basic cleaning routine that is going to be used for both
> dirty-bitmap and dirty-ring routines.
>
> It sets the required registers with the input buffer, and wait for
> HACDBSIRQ to happen, which means either the task is done, or there was some
> error during processing.
>
> It is ran with preemption disabled, as a task being scheduled in could
> change the translation registers used by HACDBS and end up corrupting the
> current dirty-bit tracking and the sched-in task's S2 pagetables.
>
> Signed-off-by: Leonardo Bras <leo.bras@arm.com>
> ---
> arch/arm64/kvm/dirty_bit.c | 81 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 81 insertions(+)
>
> diff --git a/arch/arm64/kvm/dirty_bit.c b/arch/arm64/kvm/dirty_bit.c
> index 789da8712b1b..e4283828b780 100644
> --- a/arch/arm64/kvm/dirty_bit.c
> +++ b/arch/arm64/kvm/dirty_bit.c
> @@ -1,36 +1,117 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> * Copyright (C) 2026 ARM Ltd.
> * Author: Leonardo Bras <leo.bras@arm.com>
> */
>
> #include <asm/kvm_dirty_bit.h>
> +#include <asm/kvm_mmu.h>
> #include <linux/kconfig.h>
> #include <linux/acpi.h>
>
> DEFINE_PER_CPU(struct hacdbs, hacdbs_pcp) = {
> .status = HACDBS_OFF,
> .size = 0,
> };
>
> /* HDBSS entry field definitions */
> #define HDBSS_ENTRY_VALID BIT(0)
> #define HDBSS_ENTRY_TTWL_SHIFT (1)
> #define HDBSS_ENTRY_TTWL_MASK (GENMASK(3, 1))
> #define HDBSS_ENTRY_TTWL(x) \
> (((x) << HDBSS_ENTRY_TTWL_SHIFT) & HDBSS_ENTRY_TTWL_MASK)
> #define HDBSS_ENTRY_TTWL_RESV HDBSS_ENTRY_TTWL(-4)
> #define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
>
> static __ro_after_init int hacdbsirq = -1;
>
> +static void hacdbs_start(u64 *hw_entries, int size)
> +{
> + u64 br;
> + /* Each entry is 8 bytes */
> + int size_b = size * sizeof(hw_entries[0]);
> + int size_p2 = max(roundup_pow_of_two(size_b), PAGE_SIZE);
> +
> + /* If not using the full size of the array, put a stop entry at the end */
> + if (size_b < size_p2)
> + hw_entries[size] = HDBSS_ENTRY_VALID | HDBSS_ENTRY_TTWL_RESV;
> +
> + sysreg_clear_set_s(SYS_HACDBSCONS_EL2,
> + HACDBSCONS_EL2_ERR_REASON | HACDBSCONS_EL2_INDEX, 0);
> +
> + br = (virt_to_phys(hw_entries) & HACDBSBR_EL2_BADDR_MASK) |
> + FIELD_PREP(HACDBSBR_EL2_SZ, ilog2(size_p2) - 12) |
> + FIELD_PREP(HACDBSBR_EL2_EN, 1);
> +
> + this_cpu_write(hacdbs_pcp.status, HACDBS_RUNNING);
> + this_cpu_write(hacdbs_pcp.size, size);
> + write_sysreg_s(br, SYS_HACDBSBR_EL2);
> + isb();
> +}
> +
> +static int hacdbs_stop(void)
> +{
> + write_sysreg_s(0, SYS_HACDBSBR_EL2);
> + isb();
> +
> + if (this_cpu_read(hacdbs_pcp.status) == HACDBS_ERROR) {
> + /* In case of error, HACDBSCONS_EL2.INDEX should point the faulty entry */
> + u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
> + int idx = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
> +
> + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> +
> + return idx;
> + }
> +
> + return this_cpu_read(hacdbs_pcp.size);
> +}
> +
> +/*
> + * Clears dirty-bits for an array of pages (hw_entries) using HACDBS
> + * Returns the number of items cleaned from the array. If returns value < size,
> + * there was an error in the processing.
> + */
> +static int dirty_bit_clear(struct kvm *kvm, u64 *hw_entries, int size)
> +{
> + u64 hcr_el2;
> + int ret;
> +
> + preempt_disable();
> +
> + hcr_el2 = read_sysreg(HCR_EL2);
> + write_sysreg(hcr_el2 | HCR_EL2_VM, HCR_EL2);
sysreg_clear_set_hcr(). I'm pretty sure all the speculative AT errata
depend on HCR_EL2.VM being set _after_ the stage-2 MMU has been loaded.
> + __load_stage2(&kvm->arch.mmu);
Pretty sure you need an ISB here to ensure loading the MMU is ordered
with enabling HACDBS.
> + hacdbs_start(hw_entries, size);
> +
> + do {
> + wfi();
> + } while (this_cpu_read(hacdbs_pcp.status) == HACDBS_RUNNING);
This is exactly why I said you should just poll hardware instead. It is
entirely possible that the IRQ arrives before you WFI.
> + ret = hacdbs_stop();
> +
> + write_sysreg(hcr_el2, HCR_EL2);
write_sysreg_hcr()
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH v2 05/13] KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ
From: Oliver Upton @ 2026-06-29 17:22 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Jonathan Cameron,
Chengwen Feng, Kees Cook, Mikołaj Lenczewski, James Morse,
Zeng Heng, mrigendrachaubey, Thomas Huth, Ryan Roberts,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark, Fuad Tabba,
Raghavendra Rao Ananta, Lorenzo Pieralisi, Sascha Bischoff,
Anshuman Khandual, Tian Zheng, linux-arm-kernel, linux-kernel,
kvmarm, linux-acpi, acpica-devel, kvm
In-Reply-To: <20260629111820.1873540-6-leo.bras@arm.com>
On Mon, Jun 29, 2026 at 12:17:53PM +0100, Leonardo Bras wrote:
> Find via ACPI [1] the Id for HACDBSIRQ, initialize it as a per-cpu IRQ
> and make sure any cpu able to run virtualization has it active.
>
> Introduce a per-cpu structure used by the HACDBSIRQ handler to keep track
> of entries size and the status of HACDBS. Size is used to detect end of
> processing in case the number of entries being processed is different of
> the supported entries size.
>
> Status may look easily replaceable by checking HACDBS registers now, but
> will make the OFF/IDLE detection easier in next patches.
>
> Signed-off-by: Leonardo Bras <leo.bras@arm.com>
>
> [1] https://github.com/tianocore/edk2/issues/12409
Reference the ACPI specification instead please. Any link you want to
include in a changelog should use the Link: footer, the linkage to the
inline citation will be obvious.
If we need to initialize the IRQ I'd really like to see device tree
bindings for HACDBSIRQ as well. Pretty much any system us plebs can get
our hands on is gonna be DT anyway.
> +static irqreturn_t hacdbsirq_handler(int irq, void *pcpu)
> +{
> + u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
> + unsigned long err = FIELD_GET(HACDBSCONS_EL2_ERR_REASON, cons);
> +
> + switch (err) {
> + case HACDBSCONS_EL2_ERR_REASON_NOF:
> + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> + break;
> + case HACDBSCONS_EL2_ERR_REASON_IPAHACF:
> + /* When size not a power of two >= 4k, exit with reserved TTLW */
> + int index = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
> +
> + if (index >= this_cpu_read(hacdbs_pcp.size)) {
> + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> + break;
> + }
> + fallthrough;
> + case HACDBSCONS_EL2_ERR_REASON_STRUCTF:
> + case HACDBSCONS_EL2_ERR_REASON_IPAF:
> + this_cpu_write(hacdbs_pcp.status, HACDBS_ERROR);
> + break;
> + }
> +
> + return IRQ_HANDLED;
> +}
I have a pretty extreme distaste for creating a state machine between
the callsite and the IRQ handler. The callsite should poll HACDBS for
completion. The thread has nothing better to do anyway.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH] arm64: Clarify ARM64_WORKAROUND_REPEAT_TLBI semantics
From: Vladimir Murzin @ 2026-06-29 18:05 UTC (permalink / raw)
To: Mark Rutland, linux-arm-kernel; +Cc: catalin.marinas, will
In-Reply-To: <20260629100953.385435-1-mark.rutland@arm.com>
Hi Mark,
On 6/29/26 11:09, Mark Rutland wrote:
> Will notes that the ARM64_WORKAROUND_REPEAT_TLBI name is potentially
> misleading, and that it would be nice to rename that and add some
> documentation. See:
>
> https://lore.kernel.org/linux-arm-kernel/ajKn_Pt50CmOUrsP@willie-the-truck/
>
> To that end, I've renamed the Kconfig symbol and hwcap from:
>
> [CONFIG_]ARM64_WORKAROUND_REPEAT_TLBI
>
> ... to:
>
> [CONFIG_]ARM64_WORKAROUND_REPEAT_TLBI_SYNC
>
> ... and I've added some rationale alongside the Kconfig. As the Kconfig
> symbol isn't user selectable, the usual 'help' section won't appear in
> menuconfig, so I've added this as a comment.
>
Although it won't appear in menuconfig, 3rd party tools that
index config symbols may still consume the help section.
I'm not sure how much we care about such tools...
Cheers
Vladimir
^ permalink raw reply
* Re: [PATCH v2] MAINTAINERS: Update Xilinx AMS driver maintainers
From: Jonathan Cameron @ 2026-06-29 18:08 UTC (permalink / raw)
To: Michal Simek
Cc: Sai Krishna Potthuri, Conall O'Griofa, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <0e4fc27a-9bef-4a78-9cc8-4d9c69c87773@amd.com>
On Mon, 29 Jun 2026 16:10:42 +0200
Michal Simek <michal.simek@amd.com> wrote:
> On 6/29/26 16:06, Sai Krishna Potthuri wrote:
> > Salih Erim is no longer with AMD to maintain the Xilinx AMS driver.
> > Replace Salih Erim with Sai Krishna Potthuri in the Xilinx AMS driver
> > MAINTAINERS entry for continued development and maintenance of the driver.
> >
> > Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> > ---
> > v2:
> > - Replaced Salih Erim with Sai Krishna Potthuri.
> >
> > MAINTAINERS | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 6b4560681b51..d8591066f182 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -29458,7 +29458,7 @@ F: include/uapi/linux/dqblk_xfs.h
> > F: include/uapi/linux/fsmap.h
> >
> > XILINX AMS DRIVER
> > -M: Salih Erim <salih.erim@amd.com>
> > +M: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> > M: Conall O'Griofa <conall.ogriofa@amd.com>
> > L: linux-iio@vger.kernel.org
> > S: Maintained
>
> Acked-by: Michal Simek <michal.simek@amd.com>
Applied. I also picked up Conall's tag from v1
Thanks for taking over Sai and thanks to Salih for work
on this driver in the past.
Jonathan
>
> Thanks,
> Michal
^ permalink raw reply
* Re: [PATCH v3 0/2] regulator: Rework i2c_device_id initialisation
From: Mark Brown @ 2026-06-29 18:10 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Liam Girdwood, Laurent Pinchart, Woodrow Douglass, linux-kernel,
Michael Hennerich, Support Opensource, Ivaylo Ivanov,
Claudiu Beznea, Saravanan Sekar, Matthias Brugger,
AngeloGioacchino Del Regno, Jagan Teki, Icenowy Zheng,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1781888370.git.u.kleine-koenig@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On Fri, Jun 19, 2026 at 07:17:07PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello,
>
> v2 is available at https://lore.kernel.org/lkml/cover.1779184320.git.u.kleine-koenig@baylibre.com .
>
> The only change is that I rebased to next-20260619 and dropped the
> adaptions to the of_regulator_match arrays that Laurent pointed out to
> not belong into this patch set.
This needs rebasing against current code.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1 0/2] arm64: dts: imx8mm-var-som-symphony: minor board updates
From: Frank.Li @ 2026-06-29 18:20 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel, Stefano Radaelli
Cc: Frank Li, pierluigi.p, Stefano Radaelli, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <cover.1780527068.git.stefano.r@variscite.com>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 04 Jun 2026 00:53:58 +0200, Stefano Radaelli wrote:
> This series contains minor updates for the Variscite Symphony carrier
> board based on the current hardware configuration.
>
> It updates the RGB_SEL handling and marks the relevant input devices as
> wakeup sources.
>
> Stefano Radaelli (2):
> arm64: dts: imx8mm-var-som-symphony: add wakeup sources
> arm64: dts: imx8mm-var-som-symphony: keep RGB_SEL low
>
> [...]
Applied, thanks!
[1/2] arm64: dts: imx8mm-var-som-symphony: add wakeup sources
commit: b376fc7db933785a5a89446ed0748ebb7709c1c6
[2/2] arm64: dts: imx8mm-var-som-symphony: keep RGB_SEL low
commit: 7294b6214493075806a032227691781a2df94fc9
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v5 06/14] arm64: dts: imx8mp-var-som-symphony: enable PCIe
From: Frank Li @ 2026-06-29 18:25 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <akKf_akO7IZ2ltHd@Lord-Beerus.station>
On Mon, Jun 29, 2026 at 06:40:29PM +0200, Stefano Radaelli wrote:
> Hi Frank,
>
> On Mon, Jun 29, 2026 at 12:30:09PM -0400, Frank Li wrote:
> >
> > You have to provide all clocks, otherwise, whole clocks and clock-names will
> > by overwrite with one clock "ref".
> >
> > suppose CHECK_DTBS should report warning about clocks items.
> >
> > Frank
> >
>
> thanks for checking.
>
> In this case the SoC dtsi does not provide any clocks or clock-names for
> the PCIe PHY node, so this is not overriding an existing clock list. It
> only adds the external reference clock used by the board.
>
> This follows the same pattern used by the i.MX8MP EVK, where the PCIe
> PHY node only provides the external "ref" clock together with
> fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>.
>
> This is also why CHECK_DTBS does not report any warnings for this node.
Oh! I missed think it is pcie node.
Frank
>
> $: sed -n '/^&pcie_phy {/,/^};/p' arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> &pcie_phy {
> fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> clocks = <&pcie0_refclk>;
> clock-names = "ref";
> status = "okay";
> };
>
> Thanks,
> Stefano
^ permalink raw reply
* RE: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shenwei Wang (OSS) @ 2026-06-29 18:26 UTC (permalink / raw)
To: Andrew Davis, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Shenwei Wang, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn,
Bartosz Golaszewski
In-Reply-To: <655ef1d6-08fd-43a9-8507-c2d478c058d8@ti.com>
> -----Original Message-----
> From: Andrew Davis <afd@ti.com>
> Sent: Thursday, June 25, 2026 3:32 PM
...
> Subject: Re: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
> > + Say yes here to support the generic GPIO functions over the RPMSG
> > + bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
> > + i.MX9x.
>
> The support would depend on if the right firmware is loaded/running on the given
> remote core. Also if you want to make this generic, then any vendor should be
> able to make a firmware that implements this protocol and make use of this
> driver.
> Suggest dropping this NXP specific device list.
>
Agree.
> > +
> > + If unsure, say N.
> > +
> > +endmenu
> > +
> > menu "SPI GPIO expanders"
> > depends on SPI_MASTER
> >
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
> > b267598b517d..ee75c0e65b8b 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X) += gpio-
...
> > +
> > +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev) {
> > + struct device *dev = &rpdev->dev;
> > + struct device_node *np;
> > + const char *rproc_name;
> > + int idx;
> > +
> > + idx = rpmsg_get_gpio_index(rpdev->id.name, CHAN_NAME_PREFIX);
> > + if (idx < 0)
> > + return -EINVAL;
> > +
> > + if (!dev->of_node) {
> > + np = rpmsg_get_channel_ofnode(rpdev, GPIO_COMPAT_STR, idx);
> > + if (!np)
> > + return -ENODEV;
>
> This seems to imply that DT nodes are required. RPMSG is a discoverable bus
> with a nameservice that can bind/probe new devices. While then optionally
> binding to a DT node when available so sub-devices can be described in DT is fine,
> I don't see why it should be required.
>
First, a GPIO node typically acts as a provider for other devices.
Second, by requiring a DT node, we can ensure that only explicitly enabled GPIO resources are managed and accessible.
> > +static struct rpmsg_driver rpmsg_gpio_channel_client = {
> > + .callback = rpmsg_gpio_channel_callback,
> > + .id_table = rpmsg_gpio_channel_id_table,
> > + .probe = rpmsg_gpio_channel_probe,
> > + .drv = {
> > + .name = KBUILD_MODNAME,
> > + .of_match_table = rpmsg_gpio_dt_ids,
>
> Does this line actually do anything anymore? Maybe it did when this was a
> platform_driver, but this is a rpmsg_driver and will probe though .id_table
> matches.
>
Yes, it can be removed because the driver will find the dt node on its own.
Thanks,
Shenwei
> Andrew
>
> > + },
> > +};
> > +module_rpmsg_driver(rpmsg_gpio_channel_client);
> > +
> > +MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
> > +MODULE_DESCRIPTION("generic rpmsg gpio driver");
> > +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH v3 4/8] arm64: dts: qcom: shikra: Add Adreno SMMU node
From: Akhil P Oommen @ 2026-06-29 18:40 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Imran Shaik,
Komal Bajaj, Rob Clark, Sean Paul, Konrad Dybcio,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Marijn Suijten,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson
In-Reply-To: <3ac0279b-105c-403a-90e8-822c28a6dcfc@oss.qualcomm.com>
On 6/29/2026 2:16 PM, Konrad Dybcio wrote:
> On 6/28/26 8:23 PM, Akhil P Oommen wrote:
>> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>
>> Add the Adreno GPU IOMMU (adreno_smmu) node for the Shikra SoC.
>>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
>
> Drop the sign-offs that don't apply (presumably applied as part
> of shuffling around the handlers of the patch in the in-flight
> tree OR missing c-d-b)
Ack. Thanks.
-Akhil.
>
>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>> ---
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
^ permalink raw reply
* Re: (subset) [PATCH V3 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Frank Li @ 2026-06-29 19:07 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, lpieralisi,
kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach,
Sherry Sun (OSS)
Cc: Frank Li, imx, linux-pci, linux-arm-kernel, devicetree,
linux-kernel, sherry.sun
In-Reply-To: <178274988899.2274593.17371952702316181859.b4-ty@b4>
On Mon, Jun 29, 2026 at 12:18:15PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
>
> On Wed, 20 May 2026 16:48:56 +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > This series integrates the PCI pwrctrl framework into the pci-imx6
> > driver and updates i.MX EVK board device trees to support it.
> >
> > Patches 2-8 update device trees for i.MX EVK boards which maintained
> > by NXP to move power supply properties from the PCIe controller node
> > to the Root Port child node, which is required for pwrctrl framework.
> > Affected boards:
> > - i.MX6Q/DL SABRESD
> > - i.MX6SX SDB
> > - i.MX8MM EVK
> > - i.MX8MP EVK
> > - i.MX8MQ EVK
> > - i.MX8DXL/QM/QXP EVK
> > - i.MX95 15x15/19x19 EVK
> >
> > [...]
>
> Applied, thanks!
>
> [2/8] arm: dts: imx6qdl-sabresd: Move power supply property to Root Port node
> commit: 6ae623838bba6b1d7dab2164bd12a166eae670b7
> [3/8] arm: dts: imx6sx-sdb: Move power supply property to Root Port node
> commit: 090ca78c5f5b8b475d51d729a7b79c5b7d8bbc47
Patches dropped since CHECK_DTBS warnings.
Frank
>
> Best regards,
> --
> Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: (subset) [PATCH v5 00/14] arm64: dts: imx8mp-var-som-symphony: align DTS with hardware revision
From: Frank.Li @ 2026-06-29 19:27 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel, Stefano Radaelli
Cc: Frank Li, pierluigi.p, Stefano Radaelli, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 08 Jun 2026 16:41:01 +0200, Stefano Radaelli wrote:
> This series updates the i.MX8MP VAR-SOM and Symphony device trees to
> better align them with the current hardware configuration.
>
> It adds the missing board peripherals and completes the related pinctrl,
> GPIO and bus configuration.
>
> v4->v5:
> - Add the SION (Software Input On) bit for the I2C recovery pins
> - Remove regulator-always-on and duplicated vddio node
>
> [...]
Applied, thanks!
[06/14] arm64: dts: imx8mp-var-som-symphony: enable PCIe
commit: dd7858bbdfa84beddf7d08bb82eacc8010221493
[07/14] arm64: dts: imx8mp-var-som-symphony: add HDMI support
commit: dfee5fefc3ecd29794c79b3f5284d759cfdc869e
[08/14] arm64: dts: imx8mp-var-som-symphony: add capacitive touchscreen
commit: 6651fb350bff74652edf8fdd2193ad33d69a968d
[09/14] arm64: dts: imx8mp-var-som-symphony: enable ECSPI2
commit: c0cb98e3230fd5959bb8075e059fef60d0477698
[10/14] arm64: dts: imx8mp-var-som-symphony: keep RGB_SEL low
commit: a062ace84151ca83d39e6470c0a23c51c0d343df
[11/14] arm64: dts: imx8mp-var-som-symphony: enable PWM1
commit: 2558c810a6d28614a8b076123762ff53f4acef5e
[12/14] arm64: dts: imx8mp-var-som-symphony: enable CAN
commit: 8d7fc066c18a99cd95226a660f4ddcf353d91bd8
[13/14] arm64: dts: imx8mp-var-som-symphony: add second Ethernet port
commit: 0bfd9e56f4868b66bdafed6a9f867629899bc199
[14/14] arm64: dts: freescale: imx8mp-var-som: add I2C1 bus recovery GPIOs
commit: 417b121ab93cd5a0929a663b9dc5da5595e290d3
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] media: dt-bindings: nxp,imx8mq-mipi-csi2: Fix example endpoint label typo
From: Frank.Li @ 2026-06-29 19:31 UTC (permalink / raw)
To: Robby Cai, Martin Kepplinger-Novakovic, Martin Kepplinger,
Rui Miguel Silva, Purism Kernel Team, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Laurent Pinchart
Cc: Frank Li, imx, linux-media, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260519113824.91533-1-laurent.pinchart@ideasonboard.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 19 May 2026 13:38:23 +0200, Laurent Pinchart wrote:
> The example in imx8mq-mipi-csi2.yaml uses imx8mm_mipi_csi_{in,out}
> endpoint labels, which is confusing for an i.MX8MQ binding. The labels
> could be removed as they are not functionally required in the example,
> but they have a documentation purpose that brings value to the reader.
> Rename them mipi_csi_{in,out} to avoid the confusion.
>
>
> [...]
Applied, thanks!
[1/1] media: dt-bindings: nxp,imx8mq-mipi-csi2: Fix example endpoint label typo
commit: 733394c59684b8d16c5e4d26d6bf021a3a2d4bed
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/2] media: nxp: imx8-isi: Add virtual channel and frame descriptor support
From: Frank.Li @ 2026-06-29 19:42 UTC (permalink / raw)
To: Laurent Pinchart, Mauro Carvalho Chehab, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guoniu Zhou
Cc: Frank Li, Aisheng Dong, linux-media, imx, linux-arm-kernel,
linux-kernel, Guoniu Zhou
In-Reply-To: <20260521-isi_vc-v5-0-a38eb4fcd58e@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 21 May 2026 17:10:03 +0800, Guoniu Zhou wrote:
> This patch series enhances the i.MX ISI driver's with virtual channel
> support and adds frame descriptor capabilities to the crossbar subdevice.
Applied, thanks!
[1/2] media: imx8-isi: crossbar: Add get_frame_desc operation
commit: 3e15a3510908c990ee352aa206d5f9c23d4b216e
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
From: Andrew Davis @ 2026-06-29 19:22 UTC (permalink / raw)
To: Shenwei Wang (OSS), Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Shenwei Wang, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn,
Bartosz Golaszewski
In-Reply-To: <DB8PR04MB712990DF9806BBCF36B1076DC8E82@DB8PR04MB7129.eurprd04.prod.outlook.com>
On 6/29/26 1:26 PM, Shenwei Wang (OSS) wrote:
>
>
>> -----Original Message-----
>> From: Andrew Davis <afd@ti.com>
>> Sent: Thursday, June 25, 2026 3:32 PM
>
> ...
>> Subject: Re: [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver
>>> + Say yes here to support the generic GPIO functions over the RPMSG
>>> + bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
>>> + i.MX9x.
>>
>> The support would depend on if the right firmware is loaded/running on the given
>> remote core. Also if you want to make this generic, then any vendor should be
>> able to make a firmware that implements this protocol and make use of this
>> driver.
>> Suggest dropping this NXP specific device list.
>>
>
> Agree.
>
>>> +
>>> + If unsure, say N.
>>> +
>>> +endmenu
>>> +
>>> menu "SPI GPIO expanders"
>>> depends on SPI_MASTER
>>>
>>> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
>>> b267598b517d..ee75c0e65b8b 100644
>>> --- a/drivers/gpio/Makefile
>>> +++ b/drivers/gpio/Makefile
>>> @@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X) += gpio-
>
> ...
>>> +
>>> +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev) {
>>> + struct device *dev = &rpdev->dev;
>>> + struct device_node *np;
>>> + const char *rproc_name;
>>> + int idx;
>>> +
>>> + idx = rpmsg_get_gpio_index(rpdev->id.name, CHAN_NAME_PREFIX);
>>> + if (idx < 0)
>>> + return -EINVAL;
>>> +
>>> + if (!dev->of_node) {
>>> + np = rpmsg_get_channel_ofnode(rpdev, GPIO_COMPAT_STR, idx);
>>> + if (!np)
>>> + return -ENODEV;
>>
>> This seems to imply that DT nodes are required. RPMSG is a discoverable bus
>> with a nameservice that can bind/probe new devices. While then optionally
>> binding to a DT node when available so sub-devices can be described in DT is fine,
>> I don't see why it should be required.
>>
>
> First, a GPIO node typically acts as a provider for other devices.
Not necessarily, there is a userspace API for interacting with GPIOs.
And there are ways to get/attach GPIO lines to other devices without DT.
> Second, by requiring a DT node, we can ensure that only explicitly enabled GPIO resources are managed and accessible.
Not sure I follow here, you have a firmware that provides GPIOs to Linux,
Linux should register those with the GPIO framework. Not sure why DT
is required to be involved. Some systems don't do DT, but they have
firmware and GPIOs.
I'm not saying if the system does use DT and has a node specifically
for this firmware/gpio then we shouldn't bind to that and use it,
just questioning making that "required".
Andrew
>
>>> +static struct rpmsg_driver rpmsg_gpio_channel_client = {
>>> + .callback = rpmsg_gpio_channel_callback,
>>> + .id_table = rpmsg_gpio_channel_id_table,
>>> + .probe = rpmsg_gpio_channel_probe,
>>> + .drv = {
>>> + .name = KBUILD_MODNAME,
>>> + .of_match_table = rpmsg_gpio_dt_ids,
>>
>> Does this line actually do anything anymore? Maybe it did when this was a
>> platform_driver, but this is a rpmsg_driver and will probe though .id_table
>> matches.
>>
>
> Yes, it can be removed because the driver will find the dt node on its own.
>
> Thanks,
> Shenwei
>
>> Andrew
>>
>>> + },
>>> +};
>>> +module_rpmsg_driver(rpmsg_gpio_channel_client);
>>> +
>>> +MODULE_AUTHOR("Shenwei Wang <shenwei.wang@nxp.com>");
>>> +MODULE_DESCRIPTION("generic rpmsg gpio driver");
>>> +MODULE_LICENSE("GPL");
>>
>
^ 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