* [PATCH] spi: imx: replace dmaengine_terminate_all with dmaengine_terminate_sync
From: Carlos Song (OSS) @ 2026-05-19 10:46 UTC (permalink / raw)
To: broonie, Frank.Li, s.hauer, kernel, festevam, carlos.song
Cc: linux-spi, imx, linux-arm-kernel, linux-kernel
From: Carlos Song <carlos.song@nxp.com>
The terminate API dmaengine_terminate_all() has been deprecated, improve
driver with dmaengine_terminate_sync().
Fixes: ba9b28652c75 ("spi: imx: enable DMA mode for target operation")
Fixes: a450c8b77f92 ("spi: imx: handle DMA submission errors with dma_submit_error()")
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
drivers/spi/spi-imx.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 480d1e8b281f..ae9912905c67 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1774,8 +1774,8 @@ static int spi_imx_dma_submit(struct spi_imx_data *spi_imx,
transfer_timeout);
if (!time_left) {
dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
- dmaengine_terminate_all(controller->dma_tx);
- dmaengine_terminate_all(controller->dma_rx);
+ dmaengine_terminate_sync(controller->dma_tx);
+ dmaengine_terminate_sync(controller->dma_rx);
return -ETIMEDOUT;
}
@@ -1784,7 +1784,7 @@ static int spi_imx_dma_submit(struct spi_imx_data *spi_imx,
if (!time_left) {
dev_err(&controller->dev, "I/O Error in DMA RX\n");
spi_imx->devtype_data->reset(spi_imx);
- dmaengine_terminate_all(controller->dma_rx);
+ dmaengine_terminate_sync(controller->dma_rx);
return -ETIMEDOUT;
}
} else {
@@ -1793,15 +1793,15 @@ static int spi_imx_dma_submit(struct spi_imx_data *spi_imx,
if (wait_for_completion_interruptible(&spi_imx->dma_tx_completion) ||
READ_ONCE(spi_imx->target_aborted)) {
dev_dbg(spi_imx->dev, "I/O Error in DMA TX interrupted\n");
- dmaengine_terminate_all(controller->dma_tx);
- dmaengine_terminate_all(controller->dma_rx);
+ dmaengine_terminate_sync(controller->dma_tx);
+ dmaengine_terminate_sync(controller->dma_rx);
return -EINTR;
}
if (wait_for_completion_interruptible(&spi_imx->dma_rx_completion) ||
READ_ONCE(spi_imx->target_aborted)) {
dev_dbg(spi_imx->dev, "I/O Error in DMA RX interrupted\n");
- dmaengine_terminate_all(controller->dma_rx);
+ dmaengine_terminate_sync(controller->dma_rx);
return -EINTR;
}
@@ -1818,9 +1818,9 @@ static int spi_imx_dma_submit(struct spi_imx_data *spi_imx,
return 0;
dmaengine_terminate_tx:
- dmaengine_terminate_all(controller->dma_tx);
+ dmaengine_terminate_sync(controller->dma_tx);
dmaengine_terminate_rx:
- dmaengine_terminate_all(controller->dma_rx);
+ dmaengine_terminate_sync(controller->dma_rx);
return -EINVAL;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 2/5] nvmem: Add the Raspberry Pi OTP driver
From: Thomas Weißschuh @ 2026-05-19 10:47 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, linux-hardening
In-Reply-To: <bv4vwmkkjh23lahkrupwclqs7il4vxqeknalgqn52k3wc6ztsg@z5ukn774brtg>
On Tue, May 19, 2026 at 12:20:14PM +0200, Gregor Herburger wrote:
> On Tue, May 19, 2026 at 11:14:28AM +0200, Thomas Weißschuh wrote:
> > On Fri, May 08, 2026 at 04:42:45PM +0200, Gregor Herburger wrote:
> > > +config NVMEM_RASPBERRYPI_OTP
> > > + tristate "Raspberry Pi OTP support"
> > > + depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
> >
> > The '&& !RASPBERRYPI_FIRMWARE' clause looks weird, is it really necessary?
>
> Yes it does looks weird but I think it is necessary. Without this it would be
> possible to build RASPBERRYPI_FIRMWARE=m and NVMEM_RASPBERRYPI_OTP=y which
> results in linker errors.
Fair enough. I would prefer the solution below, though.
It would cleanly solve the issues also for other (future) drivers.
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 17595a96e90b..0efd479ffced 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -188,7 +188,7 @@ struct rpi_otp_driver_data {
int size;
};
-#if IS_ENABLED(CONFIG_RASPBERRYPI_FIRMWARE)
+#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)
int rpi_firmware_property(struct rpi_firmware *fw,
u32 tag, void *data, size_t len);
int rpi_firmware_property_list(struct rpi_firmware *fw,
(...)
> > > +static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
> > > +{
> > > + struct rpi_otp_priv *priv = context;
> > > + struct rpi_otp_header *fwbuf;
> > > + u32 count;
> > > + int ret;
> > > +
> > > + if (!IS_ALIGNED(offset, 4) || !IS_ALIGNED(bytes, 4))
> > > + return -EINVAL;
> >
> > Isn't this already enforced by the nvmem core?
>
> Only for sysfs access through bin_attr_nvmem_read/bin_attr_nvmem_write. But
> there is an in-kernel API nvmem_device_read/nvmem_device_write which does not
> have alignment checks. So I added the check to be more defensive here.
The other drivers don't seem to check this explicitly. It looks like an
accident waiting to happen.
(...)
Thomas
^ permalink raw reply related
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Will Deacon @ 2026-05-19 10:47 UTC (permalink / raw)
To: zhangpengjie (A)
Cc: catalin.marinas, rafael, lenb, robert.moore, beata.michalska,
zhenglifeng1, zhanjie9, sumitg, cuiyunhui, linux-arm-kernel,
linux-kernel, linux-acpi, acpica-devel, linuxarm,
jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5, lihuisong,
yubowen8, wangzhi12, ionela.voinescu, jeremy.linton
In-Reply-To: <aa1284c1-ea26-48ca-a7d7-022027c8228a@huawei.com>
On Thu, Apr 30, 2026 at 06:00:44PM +0800, zhangpengjie (A) wrote:
> Hi all,
>
> Gentle ping on this thread. It has been a while since I posted it.
>
> Could someone please take a look when you have time? If there is anything
> I should revise or any additional information needed, I'd be happy to
> update it.
It's hard to find active folks who have contributed meaningfully to the
cppc_acpi driver... I've added Ionella and Jeremy, in case they can take
a look.
Will
> On 4/10/2026 5:41 PM, Pengjie Zhang wrote:
> > The legacy CPPC feedback-counter path reads the delivered and reference
> > performance counters separately.
> >
> > On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
> > served through a cross-CPU counter read helper. Reading the counters
> > separately therefore widens the sampling window between them and can
> > skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
> > load, the skew is observable as transient values that may exceed the
> > platform maximum, as discussed in [1] and [2].
> >
> > This series adds a small generic hook for architectures that can obtain
> > both FFH feedback counters in one operation, while preserving the
> > existing per-register read path as the fallback.
> >
> > Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
> > Patch 2 implements the hook on arm64 by sampling both AMU counters in a
> > single operation on the target CPU.
> >
> > [1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
> > [2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
> >
> > Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
> >
> > Pengjie Zhang (2):
> > ACPI: CPPC: add paired FFH feedback-counter read hook
> > arm64: topology: read CPPC FFH feedback counters in one operation
> >
> > arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
> > drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
> > include/acpi/cppc_acpi.h | 7 ++++
> > 3 files changed, 127 insertions(+), 13 deletions(-)
> >
^ permalink raw reply
* Re: [PATCH v9 0/7] gpio: siul2-s32g2: add initial GPIO driver
From: Enric Balletbo i Serra @ 2026-05-19 10:50 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, Eric Chanudet, imx,
linux-arm-kernel, linux-gpio, linux-kernel, NXP S32 Linux Team,
Pengutronix Kernel Team, Vincent Guittot
In-Reply-To: <20260504131148.3622697-1-khristineandreea.barbulescu@oss.nxp.com>
Hi,
Thank you to send these patches upstream
On Mon, May 4, 2026 at 3:12 PM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
>
> This patch series adds support for basic GPIO
> operations(set, get, direction_output/input, set_config).
>
> There are two SIUL2 hardware modules: SIUL2_0 and SIUL2_1.
> However, this driver exports both as a single GPIO driver.
> This is because the interrupt registers are located only
> in SIUL2_1, even for GPIOs that are part of SIUL2_0.
>
With gpioinfo I see
> There are two gaps in the GPIO ranges:
> - 102-111(inclusive) are invalid
line 102: unnamed input consumer=kernel
line 103: unnamed input consumer=kernel
line 104: unnamed input consumer=kernel
line 105: unnamed input consumer=kernel
line 106: unnamed input consumer=kernel
line 107: unnamed input consumer=kernel
line 108: unnamed input consumer=kernel
line 109: unnamed input consumer=kernel
line 110: unnamed input consumer=kernel
line 111: unnamed input consumer=kernel
> - 123-143(inclusive) are invalid
>
line 123: "PH_11" input consumer="kernel"
line 124: "PH_12" input consumer="kernel"
line 125: "PH_13" input consumer="kernel"
line 126: "PH_14" input consumer="kernel"
line 127: "PH_15" input consumer="kernel"
line 128: "PI_00" input consumer="kernel"
line 129: "PI_01" input consumer="kernel"
line 130: "PI_02" input consumer="kernel"
line 131: "PI_03" input consumer="kernel"
line 132: "PI_04" input consumer="kernel"
line 133: "PI_05" input consumer="kernel"
line 134: "PI_06" input consumer="kernel"
line 135: "PI_07" input consumer="kernel"
line 136: "PI_08" input consumer="kernel"
line 137: "PI_09" input consumer="kernel"
line 138: "PI_10" input consumer="kernel"
line 139: "PI_11" input consumer="kernel"
line 140: "PI_12" input consumer="kernel"
line 141: "PI_13" input consumer="kernel"
line 142: "PI_14" input consumer="kernel"
line 143: "PI_15" input consumer="kernel"
> Writing and reading GPIO values is done via the PGPDO/PGPDI
> registers(Parallel GPIO Pad Data Output/Input) which are
> 16 bit registers, each bit corresponding to a GPIO.
>
> Note that the PGPDO order is similar to a big-endian grouping
> of two registers:
> PGPDO1, PGPDO0, PGPDO3, PGPDO2, PGPDO5, PGPDO4, gap, PGPDO6.
>
I can also read the correct values from an input pin connected to a
external switch.
]# gpioget "PB_05"
"PB_05"=inactive
]# gpioget "PB_05"
"PB_05"=active
# gpiodetect
gpiochip0 [4009c240.pinctrl] (191 lines)
gpiochip1 [0-0022] (24 lines)
So,
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
> v9 -> v8
> - remove the SIUL2 syscon child nodes from the
> device tree and DT bindings
> - remove syscon child handling from the MFD
> and pinctrl drivers
> - remove the MFD driver and use a single monolithic
> pinctrl/gpio/irqchip driver
> - add a new compatible for the pinctrl+gpio binding
> while keeping the previous compatible for the legacy
> pinctrl-only binding
> - update bindings to include the PGPDO/PGPDI and
> IRQ register regions in the DT node for the
> pinctrl/gpio/irq binding
> - add IRQ-related entries in the bindings to
> document the intended hierarchy; IRQ support
> itself will be added in a future patch series
> - update DT nodes to match the new hierarchy and
> compatible scheme
> - fix dtb warnings
> - reorder commits: bug fixes, API changes, DT bindings,
> driver implementation, DTS changes
> - split commits further to separate minor
> style-only adjustments
>
> v8 -> v7
> - remove all ': true' lines from properties in dt bindings
> - remove NVMEM MFD cell from SIUL2 in dtsi
> - remove NVMEM driver and configs
> - expose SoC information via syscon cells SIUL2_0
> and SIUL2_1 in MFD driver
> - add SIUL2_0 and SIUL2_1 syscon nodes in dtsi
> - add patternProperties for "^siul2_[0-1]$" for syscon nodes
> - update example to include syscon cells with proper format
> - remove `reg` property from pinctrl node in dt binding
> - update Kconfig help text to reflect new syscon structure
> instead of NVMEM for SoC information
> - squash deprecated SIUL2 pinctrl binding with new MFD binding
> - dropped "nxp,s32g3-siul2" from MFD driver match table
> - fixed commit messages
> - fixed dtb warnings
>
> v7 -> v6
> - fixed MAINTAINERS wrong file path
> - add unevaluatedProperties, change siul2 node name, remove
> jtag_pins label in the device tree schema
> - change compatible definition in schema
> - change node name in dtsi
> - mentioned binding deprecation in commit messages
> - split mfd cell conversion commit in two: one for the
> previous refactoring, one for the mfd cell conversion
> - removed Acked-by: Linus Walleij from commit:
> "pinctrl: s32: convert the driver into an mfd cell"
> because of changes to that commit
> - deprecate the nxp,s32g2-siul2-pinctrl binding
> - add NVMEM MFD cell for SIUL2
> - made the GPIO driver not export invalid pins
> (there are some gaps 102-111, 123-143)
> - removed the need for gpio-reserved-ranges
> - force initialized pinctrl_desc->num_custom_params to 0
>
> v6 -> v5
> - removed description for reg in the dt-bindings and added
> maxItems
> - dropped label for example in the dt-bindings
> - simplified the example in the dt-bindings
> - changed dt-bindings filename to nxp,s32g2-siul2.yaml
> - changed title in the dt-bindings
> - dropped minItmes from gpio-ranges/gpio-reserved-ranges
> and added maxItems to gpio-reserved-ranges
> - added required block for -grp[0-9]$ nodes
> - switch to using "" as quotes
> - kernel test robot: fixed frame sizes, added description
> for reg_name, fixed typo in gpio_configs_lock, removed
> uninitialized ret variable usage
> - ordered includes in nxp-siul2.c, switched to dev-err-probe
> added a mention that other commits will add nvmem functionality
> to the mfd driver
> - switched spin_lock_irqsave to scoped_guard statement
> - switched dev_err to dev_err_probe in pinctrl-s32cc in places
> reached during the probing part
>
> v5 -> v4
> - fixed di_div error
> - fixed dt-bindings error
> - added Co-developed-by tags
> - added new MFD driver nxp-siul2.c
> - made the old pinctrl driver an MFD cell
> - added the GPIO driver in the existing SIUL2 pinctrl one
> - Switch from "devm_pinctrl_register" to
> "devm_pinctrl_register_and_init"
>
> v4 -> v3
> - removed useless parentheses
> - added S32G3 fallback compatible
> - fixed comment alignment
> - fixed dt-bindings license
> - fixed modpost: "__udivdi3"
> - moved MAINTAINERS entry to have the new GPIO driver
> together with other files related to S32G
>
> v3 -> v2
> - fix dt-bindings schema id
> - add maxItems to gpio-ranges
> - removed gpio label from dt-bindings example
> - added changelog for the MAINTAINERS commit and
> added separate entry for the SIUL2 GPIO driver
> - added guard(raw_spinlock_irqsave) in
> 'siul2_gpio_set_direction'
> - updated the description for
> 'devm_platform_get_and_ioremap_resource_byname'
>
> v2 -> v1
> dt-bindings:
> - changed filename to match compatible
> - fixed commit messages
> - removed dt-bindings unnecessary properties descriptions
> - added minItems for the interrupts property
> driver:
> - added depends on ARCH_S32 || COMPILE_TEST to Kconfig
> - added select REGMAP_MMIO to Kconfig
> - remove unnecessary include
> - add of_node_put after `siul2_get_gpio_pinspec`
> - removed inline from function definitions
> - removed match data and moved the previous platdata
> definition to the top of the file to be visible
> - replace bitmap_set/clear with __clear_bit/set_bit
> and devm_bitmap_zalloc with devm_kzalloc
> - switched to gpiochip_generic_request/free/config
> - fixed dev_err format for size_t reported by
> kernel test robot
> - add platform_get_and_ioremap_resource_byname wrapper
>
> Andrei Stefanescu (2):
> pinctrl: s32cc: change to "devm_pinctrl_register_and_init"
> pinctrl: s32cc: implement GPIO functionality
>
> Khristine Andreea Barbulescu (5):
> pinctrl: s32cc: use dev_err_probe() and improve error messages
> pinctrl: s32cc: add/fix some comments
> pinctrl: s32cc: remove inline specifiers
> dt-bindings: pinctrl: s32g2-siul2: describe GPIO and EIRQ resources
> arm64: dts: s32g: describe GPIO and EIRQ resources in SIUL2 pinctrl
> node
>
> .../pinctrl/nxp,s32g2-siul2-pinctrl.yaml | 107 ++-
> arch/arm64/boot/dts/freescale/s32g2.dtsi | 26 +-
> arch/arm64/boot/dts/freescale/s32g3.dtsi | 26 +-
> drivers/pinctrl/nxp/pinctrl-s32.h | 15 +-
> drivers/pinctrl/nxp/pinctrl-s32cc.c | 646 ++++++++++++++----
> drivers/pinctrl/nxp/pinctrl-s32g2.c | 25 +-
> 6 files changed, 707 insertions(+), 138 deletions(-)
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 0/2] iommu/arm-smmu: Use FIELD_MODIFY() for bitfield operations
From: Will Deacon @ 2026-05-19 10:51 UTC (permalink / raw)
To: Hans Zhang
Cc: robin.murphy, joro, iommu, linux-arm-msm, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260430164545.49637-1-18255117159@163.com>
On Fri, May 01, 2026 at 12:45:43AM +0800, Hans Zhang wrote:
> Replace open-coded bitfield modifications with the standard FIELD_MODIFY()
> macro. This improves code readability and adds type/range checking without
> functional changes.
Does it _really_ improve the readability? '&=' and '|=' patterns are
pretty idiomatic C code, if you ask me.
> FIELD_MODIFY() internally performs the same mask-clear + set operation but
> eliminates repetitive boilerplate.
>
> ---
> Hi, If the Maintainers think it's not necessary, please ignore it.
I don't really mind the code either way, so I think I'd prefer to leave
it as-is unless somebody wants to convince me otherwise...
Will
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: imx94: fix DDR PMU interrupt number
From: alice.guo @ 2026-05-19 10:55 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel
From: Alice Guo <alice.guo@nxp.com>
The DDR Performance Monitor node was added with incorrect interrupt
number 91, which actually belongs to the wdog4 watchdog. Fix it to the
correct interrupt number 374.
Fixes: e918e5f847b3 ("arm64: dts: imx94: add DDR Perf Monitor node")
Signed-off-by: Alice Guo <alice.guo@nxp.com>
---
arch/arm64/boot/dts/freescale/imx94.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index c460ece6070f..379429b3072a 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -1481,7 +1481,7 @@ netc_emdio: mdio@18,0 {
ddr-pmu@4e090dc0 {
compatible = "fsl,imx94-ddr-pmu", "fsl,imx93-ddr-pmu";
reg = <0x0 0x4e090dc0 0x0 0x200>;
- interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
};
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: freescale: add bootph-all to ULP watchdog nodes for i.MX platforms
From: alice.guo @ 2026-05-19 10:55 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260519105517.3638614-1-alice.guo@oss.nxp.com>
From: Alice Guo <alice.guo@nxp.com>
Add the bootph-all property to ULP watchdog nodes across multiple i.MX
SoC device trees, ensuring the watchdog is available during all boot
phases.
The affected watchdog nodes are:
- imx8ulp: wdog3
- imx91/93: wdog3, wdog4, wdog5
- imx94: wdog3
- imx95: wdog3
- imx952: wdog3
Signed-off-by: Alice Guo <alice.guo@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 1 +
arch/arm64/boot/dts/freescale/imx91_93_common.dtsi | 3 +++
arch/arm64/boot/dts/freescale/imx94.dtsi | 1 +
arch/arm64/boot/dts/freescale/imx95.dtsi | 1 +
arch/arm64/boot/dts/freescale/imx952.dtsi | 1 +
5 files changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 1de3ad60c6aa..df06f03624d6 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -302,6 +302,7 @@ wdog3: watchdog@292a0000 {
assigned-clocks = <&pcc3 IMX8ULP_CLK_WDOG3>;
assigned-clock-parents = <&cgc1 IMX8ULP_CLK_SOSC_DIV2>;
timeout-sec = <40>;
+ bootph-all;
};
cgc1: clock-controller@292c0000 {
diff --git a/arch/arm64/boot/dts/freescale/imx91_93_common.dtsi b/arch/arm64/boot/dts/freescale/imx91_93_common.dtsi
index 46a5d2df074d..a1a7e6a0571b 100644
--- a/arch/arm64/boot/dts/freescale/imx91_93_common.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx91_93_common.dtsi
@@ -525,6 +525,7 @@ wdog3: watchdog@42490000 {
clocks = <&clk IMX93_CLK_WDOG3_GATE>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
};
wdog4: watchdog@424a0000 {
@@ -534,6 +535,7 @@ wdog4: watchdog@424a0000 {
clocks = <&clk IMX93_CLK_WDOG4_GATE>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
};
wdog5: watchdog@424b0000 {
@@ -543,6 +545,7 @@ wdog5: watchdog@424b0000 {
clocks = <&clk IMX93_CLK_WDOG5_GATE>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
};
tpm3: pwm@424e0000 {
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index 379429b3072a..b88975fa7c8d 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -1283,6 +1283,7 @@ wdog3: watchdog@49220000 {
timeout-sec = <40>;
fsl,ext-reset-output;
status = "disabled";
+ bootph-all;
};
};
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 71394871d8dd..8c0b590d6ccf 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -795,6 +795,7 @@ wdog3: watchdog@42490000 {
clocks = <&scmi_clk IMX95_CLK_BUSWAKEUP>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
};
tpm3: pwm@424e0000 {
diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
index b30707837f35..4d8ce92db483 100644
--- a/arch/arm64/boot/dts/freescale/imx952.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
@@ -349,6 +349,7 @@ wdog3: watchdog@420b0000 {
clocks = <&scmi_clk IMX952_CLK_BUSWAKEUP>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
};
tpm3: pwm@42100000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: freescale: add ULP watchdog nodes for i.MX platforms
From: alice.guo @ 2026-05-19 10:55 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260519105517.3638614-1-alice.guo@oss.nxp.com>
From: Alice Guo <alice.guo@nxp.com>
Add new ULP watchdog device tree nodes across multiple i.MX SoC device
trees. These watchdog instances were previously missing from the device
trees. All nodes are added with status disabled by default and include
the bootph-all property.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/freescale/imx94.dtsi | 11 +++++++++++
arch/arm64/boot/dts/freescale/imx95.dtsi | 10 ++++++++++
arch/arm64/boot/dts/freescale/imx952.dtsi | 10 ++++++++++
4 files changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
index 1355feda1aa7..892799e1fe85 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
@@ -325,6 +325,18 @@ smc1: clock-controller@40410000 {
clock-names = "divcore", "hsrun_divcore";
};
+ wdog2: watchdog@40430000 {
+ compatible = "fsl,imx7ulp-wdt";
+ reg = <0x40430000 0x10000>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc2 IMX7ULP_CLK_WDG2>;
+ assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG2>;
+ assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
+ timeout-sec = <40>;
+ status = "disabled";
+ bootph-all；
+ };
+
pcc3: clock-controller@40b30000 {
compatible = "fsl,imx7ulp-pcc3";
reg = <0x40b30000 0x10000>;
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index b88975fa7c8d..190316d2a500 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -1285,6 +1285,17 @@ wdog3: watchdog@49220000 {
status = "disabled";
bootph-all;
};
+
+ wdog4: watchdog@49230000 {
+ compatible = "fsl,imx94-wdt", "fsl,imx93-wdt";
+ reg = <0x49230000 0x10000>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scmi_clk IMX94_CLK_BUSWAKEUP>;
+ timeout-sec = <40>;
+ fsl,ext-reset-output;
+ status = "disabled";
+ bootph-all;
+ };
};
usb3: usb@4c100000 {
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 8c0b590d6ccf..7caacdc819c4 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -798,6 +798,16 @@ wdog3: watchdog@42490000 {
bootph-all;
};
+ wdog4: watchdog@424a0000 {
+ compatible = "fsl,imx93-wdt";
+ reg = <0x424a0000 0x10000>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scmi_clk IMX95_CLK_BUSWAKEUP>;
+ timeout-sec = <40>;
+ status = "disabled";
+ bootph-all;
+ };
+
tpm3: pwm@424e0000 {
compatible = "fsl,imx7ulp-pwm";
reg = <0x424e0000 0x1000>;
diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
index 4d8ce92db483..59f829004000 100644
--- a/arch/arm64/boot/dts/freescale/imx952.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
@@ -352,6 +352,16 @@ wdog3: watchdog@420b0000 {
bootph-all;
};
+ wdog4: watchdog@420c0000 {
+ compatible = "fsl,imx93-wdt";
+ reg = <0x420c0000 0x10000>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scmi_clk IMX952_CLK_BUSWAKEUP>;
+ timeout-sec = <40>;
+ status = "disabled";
+ bootph-all;
+ };
+
tpm3: pwm@42100000 {
compatible = "fsl,imx7ulp-pwm";
reg = <0x42100000 0x1000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 36/37] drm/display: bridge-connector: handle bridge hotplug
From: Luca Ceresoli @ 2026-05-19 10:37 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Inki Dae,
Jagan Teki, Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel, Luca Ceresoli
In-Reply-To: <20260519-drm-bridge-hotplug-v1-0-45e2bdb3dfb4@bootlin.com>
The drm_bridge_connector is nowadays the recommended way to implement DRM
connectors when a chain of bridges is used, and as such it is the ideal
component to implement DRM bridge hotplug. Thus, let the
drm_bridge_connector be created once for the whole drm_encoder lifetime (as
it is now), but make it able of creating and destroying the DRM connector
reacting on bridge hot(un)plug events.
Unfortunately the current drm_bridge_connector_init() API is unable to
support DRM bridge hotplug because it returns a drm_connector, and with
hotplug the connector might start existing only later, and also be
destroyed and recreated multiple times.
So add a new API which is similar but returns a pointer to the
drm_bridge_connector, which is persistent, and supports bridge hotplug by
creating and destroying the drm_connector based on hotplug events.
Because drm_bridge_connector_init() is really a drmm function (it does only
drmm allocations), but without a drmm_ prefix, take this as an opportunity
to call the new function with the same name but a drmm_ prefix:
drmm_bridge_connector_init(). The old API can be replaced over time when
needed to support hotplug, and eventually be removed if unused.
The new drmm_bridge_connector_init() API differs from the old one in a few
aspects in order to support bridge hotplug:
* if the bridge chain is not (yet) complete, returns successfully without
adding a drm_connector (in this case the old API returns an error)
* registers an event notifier block to be able of reacting to events
related to bridge hotplug and create/destroy the drm_connector
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
I'm tempted to let drmm_bridge_connector_init() return int (0 or negative
error) instead of a struct drm_bridge_connector *, but I'm not sure whether
the drm_bridge_connector pointer may be useful in the future to invoke
actions on the bridge_connector after its creation. Opnions about this
would be welcome.
---
drivers/gpu/drm/display/drm_bridge_connector.c | 157 +++++++++++++++++++++++++
include/drm/drm_bridge_connector.h | 2 +
2 files changed, 159 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index b83da529cc7a..2ce6c04e2fc7 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -20,6 +20,7 @@
#include <drm/drm_device.h>
#include <drm/drm_edid.h>
#include <drm/drm_managed.h>
+#include <drm/drm_event_notifier.h>
#include <drm/drm_modeset_helper_vtables.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
@@ -158,6 +159,10 @@ struct drm_bridge_connector {
* destruction
*/
struct mutex dynconn_mutex;
+ /**
+ * @drm_event_nb: notifier to receive DRM hotplug-related events
+ */
+ struct notifier_block drm_event_nb;
};
static struct drm_bridge_connector_dynconn *
@@ -1037,6 +1042,19 @@ static int drm_bridge_connector_init_hdmi_audio_cec(struct drm_bridge_connector_
return 0;
}
+static bool drm_bridge_connector_pipeline_is_complete(struct drm_bridge_connector *bridge_connector)
+{
+ struct drm_bridge *last_bridge __free(drm_bridge_put) =
+ drm_bridge_chain_get_last_bridge(bridge_connector->encoder);
+
+ if (!last_bridge || !drm_bridge_is_tail(last_bridge)) {
+ drm_dbg_driver(bridge_connector->drm, "pipeline not (yet) fully connected");
+ return false;
+ }
+
+ return true;
+}
+
/**
* drm_bridge_connector_add_connector - add the drm_connector
* @bridge_connector: drm_bridge_connector to add the drm_connector to
@@ -1153,6 +1171,79 @@ static int drm_bridge_connector_add_connector(struct drm_bridge_connector *bridg
return ret;
}
+/*
+ * Propagate the attach chain and possibly add a drm_connector after a new
+ * drm_bridge is hot-plugged.
+ *
+ * The connector is added only if the pipeline is now complete. This could
+ * not be the case for various reasons:
+ *
+ * - the new bridge is just unrelated to our encoder
+ * - the new bridge is not be the next one in the pipeline
+ * - the new bridge is the next in the pipeline but the pipeline is not yet
+ * complete
+ *
+ * All these cases are normal, not an error.
+ */
+static void drm_bridge_connector_try_complete(struct drm_bridge_connector *bridge_connector)
+{
+ int err;
+
+ /*
+ * drm_connector already present, the new bridge must be for
+ * another card
+ */
+ if (bridge_connector->dynconn)
+ return;
+
+ /* Propagate the attach call chain to newly hotplugged bridge(s) */
+ struct drm_bridge *last_bridge __free(drm_bridge_put) =
+ drm_bridge_chain_get_last_bridge(bridge_connector->encoder);
+
+ /* Encoder chain empty? */
+ if (!last_bridge)
+ return;
+
+ err = last_bridge->funcs->attach(last_bridge, bridge_connector->encoder,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+ if (err)
+ return;
+
+ /* Add the connector if the pipeline is now complete */
+ if (drm_bridge_connector_pipeline_is_complete(bridge_connector))
+ drm_bridge_connector_add_connector(bridge_connector);
+}
+
+static int drm_bridge_connector_handle_event(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct drm_bridge_connector *bridge_connector =
+ container_of(nb, struct drm_bridge_connector, drm_event_nb);
+
+ switch (event) {
+ case DRM_MIPI_DSI_ATTACHED:
+ /* One or more bridges hot-plugged, try adding the drm_connector */
+ drm_bridge_connector_try_complete(bridge_connector);
+ break;
+ case DRM_BRIDGE_DETACHED:
+ {
+ /*
+ * A bridge was unplugged, remove the drm_connector if it's
+ * part of the same pipeline
+ */
+ struct drm_bridge *bridge = (struct drm_bridge *)data;
+
+ if (bridge_connector->dynconn &&
+ bridge->encoder == bridge_connector->encoder)
+ drm_bridge_connector_dynconn_release(bridge_connector);
+ break;
+ }
+ default:
+ }
+
+ return NOTIFY_DONE;
+}
+
static void drm_bridge_connector_fini(struct drm_device *dev, void *res)
{
struct drm_bridge_connector *bridge_connector = (struct drm_bridge_connector *)res;
@@ -1205,3 +1296,69 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
return &bridge_connector->dynconn->connector;
}
EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
+
+static void drm_bridge_connector_notifier_unregister(struct drm_device *dev, void *res)
+{
+ struct notifier_block *nb = (struct notifier_block *)res;
+
+ drm_event_notifier_unregister(nb);
+}
+
+/**
+ * drmm_bridge_connector_init - Initialise the bridge_connector for a chain
+ * of bridges, with bridge hotplug support
+ * @drm: the DRM device
+ * @encoder: the encoder where the bridge chain starts
+ *
+ * Allocate, initialise and register a &drm_bridge_connector with the @drm
+ * device. The connector is associated with a chain of bridges that starts at
+ * the @encoder. All bridges in the chain shall report bridge operation flags
+ * (&drm_bridge->ops) and bridge output type (&drm_bridge->type), and none of
+ * them may create a DRM connector directly.
+ *
+ * Also adds a drm_connector if the bridge chain is complete, otherwise the
+ * &drm_bridge_connector will still be successfully created but without
+ * adding a drm_connector. In both cases the &drm_bridge_connector will
+ * receive events notifying bridge hot-plug and hot-unplug and add or
+ * destroy the drm_connector accordingly.
+ *
+ * Returns a pointer to the new &drm_bridge_connector on success, or a
+ * negative error pointer otherwise.
+ */
+struct drm_bridge_connector *drmm_bridge_connector_init(struct drm_device *drm,
+ struct drm_encoder *encoder)
+{
+ struct drm_bridge_connector *bridge_connector;
+ int ret;
+
+ bridge_connector = drmm_kzalloc(drm, sizeof(*bridge_connector), GFP_KERNEL);
+ if (!bridge_connector)
+ return ERR_PTR(-ENOMEM);
+
+ mutex_init(&bridge_connector->dynconn_mutex);
+ bridge_connector->drm = drm;
+ bridge_connector->encoder = encoder;
+ bridge_connector->drm_event_nb.notifier_call = drm_bridge_connector_handle_event;
+
+ if (drm_bridge_connector_pipeline_is_complete(bridge_connector)) {
+ ret = drm_bridge_connector_add_connector(bridge_connector);
+ if (ret)
+ return ERR_PTR(ret);
+ }
+
+ ret = drmm_add_action_or_reset(drm, drm_bridge_connector_fini, bridge_connector);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = drm_event_notifier_register(&bridge_connector->drm_event_nb);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = drmm_add_action_or_reset(drm, drm_bridge_connector_notifier_unregister,
+ &bridge_connector->drm_event_nb);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drmm_bridge_connector_init);
diff --git a/include/drm/drm_bridge_connector.h b/include/drm/drm_bridge_connector.h
index 69630815fb09..1c78221c0857 100644
--- a/include/drm/drm_bridge_connector.h
+++ b/include/drm/drm_bridge_connector.h
@@ -10,6 +10,8 @@ struct drm_connector;
struct drm_device;
struct drm_encoder;
+struct drm_bridge_connector *drmm_bridge_connector_init(struct drm_device *drm,
+ struct drm_encoder *encoder);
struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
struct drm_encoder *encoder);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net v2 4/5] net: dsa: mt7530: clear flood flags on bridge leave
From: Paolo Abeni @ 2026-05-19 10:53 UTC (permalink / raw)
To: Daniel Golle, Chester A. Unal, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Matthias Brugger,
AngeloGioacchino Del Regno, DENG Qingfang, Florian Fainelli,
Arınç ÜNAL, Sean Wang, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cc8d2f494dd202304a6f68332f3a90ea0a8a4618.1778766629.git.daniel@makrotopia.org>
On 5/14/26 4:05 PM, Daniel Golle wrote:
> Flood flags set by port_bridge_flags persist after a port leaves the
> bridge, causing unknown unicast to be forwarded to standalone ports.
>
> Clear UNU_FFP, UNM_FFP and BC_FFP in port_bridge_leave so that the
> port returns to its initial state without flooding.
>
> Fixes: 5a30833b9a16 ("net: dsa: mt7530: support MDB and bridge flag operations")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> v2: no changes
>
> drivers/net/dsa/mt7530.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 752ba92b0851..5b58e42bfda9 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -1767,6 +1767,11 @@ mt7530_port_bridge_leave(struct dsa_switch *ds, int port,
> mt7530_rmw(priv, MT7530_PCR_P(port), PCR_PORT_VLAN_MASK,
> MT7530_PORT_MATRIX_MODE);
>
> + /* Clear flood flags so they don't persist across bridge leave */
> + mt7530_clear(priv, MT753X_MFC,
> + UNU_FFP(BIT(port)) | UNM_FFP(BIT(port)) |
> + BC_FFP(BIT(port)));
I think sashiko has a point here:
---
Will these cleared flags be immediately overwritten by the DSA core?
When a port leaves a bridge, the DSA core's dsa_port_bridge_leave()
broadcasts the DSA_NOTIFIER_BRIDGE_LEAVE event, which triggers this
callback and clears the bits.
However, immediately after the broadcast returns,
dsa_port_bridge_leave() unconditionally calls
dsa_port_switchdev_unsync_attrs(), which calls
dsa_port_clear_brport_flags().
This explicitly configures standalone ports to flood everything by
setting the BR_FLOOD, BR_MCAST_FLOOD, and BR_BCAST_FLOOD flags to 1, and
then invokes the driver's port_bridge_flags callback.
As a result, mt7530_port_bridge_flags() processes this call and executes
mt7530_rmw() to turn the UNU_FFP, UNM_FFP, and BC_FFP bits right back to
1 for the port.
Does this leave the isolation bug unfixed since the register clearing is
reverted before the DSA bridge leave sequence fully completes?
---
Since the other fixes are independent, I'm applying them.
/P
^ permalink raw reply
* Re: [PATCH net v2 0/5] net: dsa: mt7530: assorted fixes
From: patchwork-bot+netdevbpf @ 2026-05-19 11:00 UTC (permalink / raw)
To: Daniel Golle
Cc: chester.a.unal, andrew, olteanv, davem, edumazet, kuba, pabeni,
matthias.bgg, angelogioacchino.delregno, dqfext, f.fainelli,
arinc.unal, sean.wang, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <cover.1778766629.git.daniel@makrotopia.org>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 14 May 2026 15:04:06 +0100 you wrote:
> A batch of small, independent fixes for the MediaTek MT7530 family DSA
> driver, addressing long-standing correctness issues that surface on
> hardware with bridge VLAN filtering enabled, on link-local frame
> reception, and during bridge join/leave transitions.
> ---
> Changes since v1:
> - rework patch 1/5 following up Paolo Abeni and Sashiko reviews
>
> [...]
Here is the summary with links:
- [net,v2,1/5] net: dsa: mt7530: fix FDB entries not aging out with short timeout
https://git.kernel.org/netdev/net/c/e824e40d0e84
- [net,v2,2/5] net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
https://git.kernel.org/netdev/net/c/3ac85bcfd404
- [net,v2,3/5] net: dsa: mt7530: fix CPU port VLAN not being reset to unaware
https://git.kernel.org/netdev/net/c/2c4c76cacc9d
- [net,v2,4/5] net: dsa: mt7530: clear flood flags on bridge leave
(no matching commit)
- [net,v2,5/5] net: dsa: mt7530: untag VLAN-aware bridge PVID
https://git.kernel.org/netdev/net/c/4cb3cd670b2a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] arm64/mm: Rename ptdesc_t
From: David Hildenbrand (Arm) @ 2026-05-19 11:02 UTC (permalink / raw)
To: Will Deacon, Mike Rapoport
Cc: Anshuman Khandual, linux-arm-kernel, Catalin Marinas, linux-efi,
linux-kernel
In-Reply-To: <agw_Ih69WYh7NDWZ@willie-the-truck>
On 5/19/26 12:44, Will Deacon wrote:
> On Thu, Apr 30, 2026 at 09:51:46AM +0200, Mike Rapoport wrote:
>> Hi Anshuman,
>>
>> On Thu, Apr 30, 2026 at 04:49:33AM +0100, Anshuman Khandual wrote:
>>> ptdesc_t sounds very similar to the core MM struct ptdesc which is actually
>>> the memory descriptor for page table allocations. Hence rename this typedef
>>> element as pxxval_t instead for better clarity and separation.
>>
>> Maybe we should keep the "pt" prefix and make it "ptval_t"?
>
> Yeah, the 'pxx' prefix really hurts my eyes. Please use something else!
Fine with me as long as we don't call it something with "pte" in it.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] spi: aspeed: Replace VLA parameter with flat pointer in calibration helper
From: Mark Brown @ 2026-05-19 11:03 UTC (permalink / raw)
To: Chin-Ting Kuo
Cc: clg, joel, andrew, linux-aspeed, openbmc, linux-spi,
linux-arm-kernel, linux-kernel, BMC-SW, kernel test robot
In-Reply-To: <20260518095708.2502537-3-chin-ting_kuo@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
On Mon, May 18, 2026 at 05:57:08PM +0800, Chin-Ting Kuo wrote:
> - while (k < cols && buf[i][k])
> + while (k < cols && buf[i * cols + k])
This really needs () to make it clear what's going on; the precedence is
well defined but not everyone is going to know that off the top of their
head.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Mostafa Saleh @ 2026-05-19 11:04 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Jason Gunthorpe,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5ah5oa59wy.fsf@kernel.org>
On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote:
> >>
> >> What I meant was that we need a generic way to identify a pKVM guest, so
> >> that we can use it in the conditional above.
> >
> > I have this patch, with that I can boot with your series unmodified,
> > but I will need to do more testing.
> >
>
> Thanks, I can add this to the series once you complete the required testing.
>
I am still running more tests, but looking more into it. Setting
force_dma_unencrypted() to true for pKVM guests is wrong, as the
guest shouldn’t try to decrypt arbitrary memory as it can include
sensitive information (for example in case of virtio sub-page
allocation) and should strictly rely on the restricted-dma-pool
for that.
However, with my patch and setting force_dma_unencrypted() to false
on top of this series, it fails on pKVM due to a missing shared
attribute as Alexey mentioned, as now SWIOTLB rejects non shared
attrs, so, the DMA-API has to pass it. With that, I can boot again:
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 5103a04df99f..b19aeec03f27 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -286,6 +286,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
}
if (is_swiotlb_for_alloc(dev)) {
+ attrs |= DMA_ATTR_CC_SHARED;
+
page = dma_direct_alloc_swiotlb(dev, size, attrs);
if (page) {
/*
@@ -449,6 +451,8 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
&cpu_addr, gfp, attrs);
if (is_swiotlb_for_alloc(dev)) {
+ attrs |= DMA_ATTR_CC_SHARED;
+
page = dma_direct_alloc_swiotlb(dev, size, attrs);
if (!page)
return NULL;
diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
index 4e35264ab6f8..8ee5bbf78cfb 100644
--- a/kernel/dma/direct.h
+++ b/kernel/dma/direct.h
@@ -92,6 +92,7 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
return DMA_MAPPING_ERROR;
+ attrs |= DMA_ATTR_CC_SHARED;
return swiotlb_map(dev, phys, size, dir, attrs);
}
--
I will keep testing and let you know how it goes. If there is nothing
else required to convert pKVM guests to CC, I can just post the patch
separately as it has no dependency on this series.
Re force_dma_unencrypted(), I am looking into a safe way to use it
for pKVM as I beleive it will be useful to eliminate some bouncing.
However, that’s not critical for this series and can be added later
as I am still investigating it, if I reach something I can post it
along the pKVM patch above.
Thanks,
Mostafa
>
>
> -aneesh
^ permalink raw reply related
* Re: [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel
From: Jens Remus @ 2026-05-19 11:05 UTC (permalink / raw)
To: Dylan Hatch, Mostafa Saleh
Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan,
Song Liu, joe.lawrence, linux-toolchains, linux-kernel,
live-patching, linux-arm-kernel, Randy Dunlap
In-Reply-To: <CADBMgpx38SUUuYYCm612STqh01jqv817WnJeeXYTD7Uc1r-fug@mail.gmail.com>
Hi Dylan and Mostafa!
On 5/18/2026 7:55 PM, Dylan Hatch wrote:
> On Fri, May 15, 2026 at 4:32 AM Mostafa Saleh <smostafa@google.com> wrote:
>> On Tue, Apr 28, 2026 at 06:36:35PM +0000, Dylan Hatch wrote:
>>> Implement a generic kernel sframe-based [1] unwinder. The main goal is
>>> to improve reliable stacktrace on arm64 by unwinding across exception
>>> boundaries.
>>>
>>> On x86, the ORC unwinder provides reliable stacktrace through similar
>>> methodology, but arm64 lacks the necessary support from objtool to
>>> create ORC unwind tables.
>>>
>>> Currently, there's already a sframe unwinder proposed for userspace: [2].
>>> To maintain common definitions and algorithms for sframe lookup, a
>>> substantial portion of this patch series aims to refactor the sframe
>>> lookup code to support both kernel and userspace sframe sections.
>>>
>>> Currently, only GNU Binutils support sframe. This series relies on the
>>> Sframe V3 format, which is supported in binutils 2.46.
>>>
>>> These patches are based on Steven Rostedt's sframe/core branch [3],
>>> which is and aggregation of existing work done for x86 sframe userspace
>>> unwind, and contains [2]. This branch is, in turn, based on Linux
>>> v7.0-rc3. This full series (applied to the sframe/core branch) is
>>> available on github: [4].
>>>
>>
>> Not sure if related, but after updating my toolchain
>> (aarch64-linux-gnu-gcc (Debian 15.2.0-4) 15.2.0), I hit link errors:
>> ld.lld: error: arch/arm64/kernel/vdso/vgettimeofday.o:(.sframe) is being placed in '.sframe'
>> ld.lld: error: arch/arm64/kernel/vdso/vgetrandom.o:(.sframe) is being placed in '.sframe`
>
> Previously when developing against the SFrame V2 format, I had fixed
> these warnings with the VDSO Makefile change currently in this series:
>
> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> index 7dec05dd33b7..c60ef921956f 100644
> --- a/arch/arm64/kernel/vdso/Makefile
> +++ b/arch/arm64/kernel/vdso/Makefile
> @@ -38,7 +38,7 @@ ccflags-y += -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
> CC_FLAGS_REMOVE_VDSO := $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) \
> $(RANDSTRUCT_CFLAGS) $(KSTACK_ERASE_CFLAGS) \
> $(GCC_PLUGINS_CFLAGS) \
> - $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) \
> + $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(CC_FLAGS_SFRAME) \
> -Wmissing-prototypes -Wmissing-declarations
>
> CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
>
> But the warnings seem to have returned after upgrading my toolchain,
> possibly due to SFrame V3 or some confounding change in GCC. The
> --gsframe in the assembler should be set to 'no' by default, so
> perhaps GCC is providing an override --gsframe internally?
Could it be that your build of binutils was configured with
--enable-default-sframe, so that the GNU assembler defaults to generate
.sframe? AFAIK this configure option was meant for distributors and
package maintainers.
You can check as follows whether --gsframe defaults to "no" or "yes":
$ as --help | grep -A1 gsframe
--gsframe[={no|yes}] whether to generate SFrame stack trace information
(default: no)
...
>
>>
>> I applied this series hoping that fix it, but it doesn't, so far I
>> have this hack :
>> diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
>> index 52314be29191..53bdf757ee44 100644
>> --- a/arch/arm64/kernel/vdso/vdso.lds.S
>> +++ b/arch/arm64/kernel/vdso/vdso.lds.S
>> @@ -77,7 +77,7 @@ SECTIONS
>> /DISCARD/ : {
>> *(.data .data.* .gnu.linkonce.d.* .sdata*)
>> *(.bss .sbss .dynbss .dynsbss)
>> - *(.eh_frame .eh_frame_hdr)
>> + *(.eh_frame .eh_frame_hdr .sframe)
>> }
>> }
>>
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index 60c8c22fd3e4..759903acd6fc 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -1064,6 +1064,7 @@
>> /* ld.bfd warns about .gnu.version* even when not emitted */ \
>> *(.gnu.version*) \
>> *(__tracepoint_check) \
>> + *(.sframe) \
>>
>> #define DISCARDS \
>> /DISCARD/ : { \
>
> Since this series only handles kernel stacktrace, I believe it's
> better to omit the .sframe section entirely in the case where only
> ARCH_SUPPORTS_UNWIND_KERNEL_SFRAME is enabled. I think this hack may
> work better for this purpose:
>
> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> index c60ef921956f..29f802bfedb1 100644
> --- a/arch/arm64/kernel/vdso/Makefile
> +++ b/arch/arm64/kernel/vdso/Makefile
> @@ -41,7 +41,7 @@ CC_FLAGS_REMOVE_VDSO := $(CC_FLAGS_FTRACE) -Os
> $(CC_FLAGS_SCS) \
> $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(CC_FLAGS_SFRAME) \
> -Wmissing-prototypes -Wmissing-declarations
>
> -CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> +CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> -Wa,--gsframe=no
>
> CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_REMOVE_VDSO)
> CFLAGS_REMOVE_vgetrandom.o = $(CC_FLAGS_REMOVE_VDSO)
>
> Though, I don't understand why it is necessary to provide --gsframe=no
> explicitly. If this approach seems ok to other folks/maintainers, I
> can fold this into my series.
Maybe build the VDSO separately with V=1 to see what assembler/compiler
options are effectively used (e.g. for vgettimeofday.o and vgetrandom.o
mentioned in the linker error message above)?
$ make mrproper
$ make defconfig
$ ./scripts/config --enable HAVE_UNWIND_KERNEL_SFRAME # enable kernel sframe unwinder
$ make arch/arm64/kernel/vdso/ V=1
>
> On the topic of SFrame for VDSO, Jens has a patch adding support for
> this as part of a series to support userspace SFrame unwinding for
> arm64:
>
> https://lore.kernel.org/lkml/20260417150827.1183376-4-jremus@linux.ibm.com/
Any feedback is very welcome. :-)
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Mostafa Saleh @ 2026-05-19 11:06 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260515225113.GN7702@ziepe.ca>
On Fri, May 15, 2026 at 07:51:13PM -0300, Jason Gunthorpe wrote:
> On Thu, May 14, 2026 at 02:43:39PM +0000, Mostafa Saleh wrote:
> > > That's a somewhat different problem, we have the dev->trusted stuff
> > > that is supposed to deal with this kind of security. We need it for
> > > IOMMU based systems too, eg hot plug thunderbolt should have it.
> >
> > I see that it is used only for dma-iommu and for PCI devices.
> > However, I think that should be a problem with other CCA solutions
> > with emulated devices as they are untrusted. As I'd expect they
> > would have virtio devices.
>
> Yes, any security solution with an out of TCB device should be using either
> memory encryption so the kernel already bounces or this trusted stuff
> and a force strict dma-iommu so the dma layer is careful.
>
> This is more policy from userspace what devices they want in or out of
> their TCB. Like you make accept the device into T=1 but then still
> want to keep it out of your TCB with the vIOMMU, I can see good
> arguments for something like that.
>
> > > > While we can debate the aesthetics of the setup , this is
> > > > the exisitng behaviour for Linux, which existed for years
> > > > and pKVM relies on and is used extensively.
> > > > And, this patch alters that long-standing logic and introduces
> > > > a functional regression.
> > >
> > > Yeah, Aneesh needs to do something here, I'm pointing out it is
> > > entirely seperate thing from the CC path we are working on which is
> > > decoupling CC from reylying on force swiotlb.
> >
> > I am looking into converting pKVM to use the CC stuff, I replied with
> > a patch to Aneesh in this thread. However, I need to do more testing
> > and make sure there are not any unwanted consequences.
>
> Yeah, it is a nice patch and I think it will help reduce the
> complexity if it aligns to CCA type stuff.
>
> > > In a pkvm world it should be the same, the S2 table for the SMMU will
> > > control what the device can access, and if the SMMU points to a
> > > "private" or "shared" page is not something the device needs to know
> > > or care about.
> >
> > I see that's because dma-iommu chooses the attrs for iommu_map().
>
> Long term the DMA API path through the dma-iommu will pass the
> ATTR_CC_SHARED through to iommu_map so when the arch requires a
> different IOPTE it can construct it.
>
> > In pKVM, dma_addr_t and IOPTE are the same for private and shared,
> > so nothing differs in that case.
>
> Yes, so you don't have to worry.
>
> > We don’t expect pass-through devices to interact with shared
> > memory (T=0) at the moment.
> > However, I can see use cases for that, where the host and the guest
> > collaborate with device passthrough and require zero copy.
>
> Once you add the CC patch it becomes immediately possible though
> because the user can allocate a CC shared DMA HEAP and feed that all
> over the place.
>
> > One other interesting case for device-passthrough is non-coherent
> > devices which then require private pools for bouncing.
>
> Why does shared/private matter for bouncing? Why do you need to bounce
> at all? Do cmo's not work in pkvm guests?
At the moment, in iommu_dma_map_phys(), if a non coherent device
tries to map an unaligned address or size it will be bounced.
In pKVM, dma-iommu is used for assigned devices which operate on
private memory, so bouncing that through the SWIOTLB would leak
information from the guest as the SWIOTLB is decrypted.
In that case, the device needs a pool which remains private.
Thanks,
Mostafa
>
> Jason
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Barry Song @ 2026-05-19 11:07 UTC (permalink / raw)
To: Yang Shi
Cc: Matthew Wilcox, surenb, akpm, linux-mm, david, ljs, liam, vbabka,
rppt, mhocko, jack, pfalcato, wanglian, chentao, lianux.mm,
kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAHbLzkrOSoh-jmR=uaNvx73n_wn+vExoKY0UzH5zGcfdAiDbNg@mail.gmail.com>
On Tue, May 19, 2026 at 5:21 AM Yang Shi <shy828301@gmail.com> wrote:
>
> On Sun, May 17, 2026 at 1:45 AM Barry Song <baohua@kernel.org> wrote:
> >
> > On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> > > > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > >
> > > > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:
> > > > > > 1. There is no deterministic latency for I/O completion. It depends on
> > > > > > both the hardware and the software stack (bio/request queues and the
> > > > > > block scheduler). Sometimes the latency is short; at other times it can
> > > > > > be quite long. In such cases, a high-priority thread performing operations
> > > > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait
> > > > > > for an unpredictable amount of time.
> > > > >
> > > > > But does that actually happen? I find it hard to believe that thread A
> > > > > unmaps a VMA while thread B is in the middle of taking a page fault in
> > > > > that same VMA. mprotect() and madvise() are more likely to happen, but
> > > > > it still seems really unlikely to me.
> > > >
> > > > It doesn’t have to involve unmapping or applying mprotect to
> > > > the entire VMA—just a portion of it is sufficient.
> > >
> > > Yes, but that still fails to answer "does this actually happen". How much
> > > performance is all this complexity in the page fault handler buying us?
> > > If you don't answer this question, I'm just going to go in and rip it
> > > all out.
> > >
> >
> > Hi Matthew (and Lorenzo, Jan, and anyone else who may be
> > waiting for answers),
> >
> > As promised during LSF/MM/BPF, we conducted thorough
> > testing on Android phones to determine whether performing
> > I/O in `filemap_fault()` can block `vma_start_write()`.
> > I wanted to give a quick update on this question.
> >
> > Nanzhe at Xiaomi created tracing scripts and ran various
> > applications on Android devices with I/O performed under
> > the VMA lock in `filemap_fault()`. We found that:
> >
> > 1. There are very few cases where unmap() is blocked by
> > page faults. I assume this is due to buggy user code
> > or poor synchronization between reads and unmap().
> > So I assume it is not a problem.
> >
> > 2. We observed many cases where `vma_start_write()`
> > is blocked by page-fault I/O in some applications.
> > The blocking occurs in the `dup_mmap()` path during
> > fork().
> >
> > With Suren's commit fb49c455323ff ("fork: lock VMAs of
> > the parent process when forking"), we now always hold
> > `vma_write_lock()` for each VMA. Note that the
> > `mmap_lock` write lock is also held, which could lead to
> > chained waiting if page-fault I/O is performed without
> > releasing the VMA lock.
> >
> > My gut feeling is that Suren's commit may be overshooting,
> > so my rough idea is that we might want to do something like
> > the following (we haven't tested it yet and it might be
> > wrong):
> >
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 2311ae7c2ff4..5ddaf297f31a 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
> > *mm, struct mm_struct *oldmm)
> > for_each_vma(vmi, mpnt) {
> > struct file *file;
> >
> > - retval = vma_start_write_killable(mpnt);
> > + /*
> > + * For anonymous or writable private VMAs, prevent
> > + * concurrent CoW faults.
> > + */
> > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
> > + (mpnt->vm_flags & VM_WRITE)))
> > + retval = vma_start_write_killable(mpnt);
> > if (retval < 0)
> > goto loop_out;
> > if (mpnt->vm_flags & VM_DONTCOPY) {
>
> Maybe a little bit off topic. This is an interesting idea. It seems
> possible we don't have to take vma write lock unconditionally. IIUC
> the write lock is mainly used to serialize against page fault and
> madvise, right? I got a crazy idea off the top of my head. We may be
> able to just take vma write lock iff vma->anon_vma is not NULL.
>
> First of all, write mmap_lock is held, so the vma can't go or be
> changed under us.
>
> Secondly, if vma->anon_vma is NULL, it basically means either no page
> fault happened or no cow happened, so there is no page table to copy,
> this is also what copy_page_range() does currently. So we can shrink
> the critical section to:
>
> if (vma->anon_vma) {
> vma_start_write_killable(src_vma);
> anon_vma_fork(dst_vma, src_vma);
> copy_page_range(dst_vma, src_vma);
> }
>
> But page fault can happen before write mmap_lock is taken, when we
> check vma->anon_vma, it is possible it has not been set up yet. But it
> seems to be equivalent to page fault after fork and won't break the
> semantic.
Re-reading Suren's commit log for fb49c455323ff8
("fork: lock VMAs of the parent process when forking"),
it seems that vm_start_write() is used to protect
against a race where anon_vma changes from NULL to
non-NULL during fork. In that scenario, we hold the
mmap_lock write lock, but not vma_start_write(), so a
concurrent anon_vma_prepare() could still install an
anon_vma.
" A concurrent page fault on a page newly marked read-only by the page
copy might trigger wp_page_copy() and a anon_vma_prepare(vma) on the
source vma, defeating the anon_vma_clone() that wasn't done because the
parent vma originally didn't have an anon_vma, but we now might end up
copying a pte entry for a page that has one.
"
If that is the case, then your change does not work.
Nowadays, nobody calls anon_vma_prepare(vma) directly.
Instead, vmf_anon_prepare() is used, and we always
require the mmap_lock read lock before calling
__anon_vma_prepare(). As a result, anon_vma cannot
transition from NULL to non-NULL during fork.
So the original race condition has effectively
disappeared.
You also mentioned the madvise() case. If I understand
correctly, madvise() should take mmap_lock before
modifying anon_vma. Only some parts of madvise() can
support per-VMA locking. Therefore, we probably do not
need:
if (vma->anon_vma) {
vma_start_write_killable(src_vma);
...
}
>
> Anyway, just a crazy idea, I may miss some corner cases.
To me, it seems that we could remove vma_start_write()
entirely now. Or is that an even crazier idea?
Thanks
Barry
^ permalink raw reply
* Re: [PATCH v2 05/12] drm/bridge: synopsys: dw-dp: Add follow-up bridge support
From: Luca Ceresoli @ 2026-05-19 11:08 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Airlie,
Simona Vetter, Dmitry Baryshkov, Luca Ceresoli,
Cristian Ciocaltea, Damon Ding, Dmitry Baryshkov, Alexey Charkov,
dri-devel, linux-rockchip, linux-kernel, devicetree, kernel,
linux-arm-kernel
In-Reply-To: <20260501-synopsys-dw-dp-improvements-v2-5-d7e7f6bac77f@collabora.com>
On Fri, 01 May 2026 00:20:32 +0200, Sebastian Reichel <sebastian.reichel@collabora.com> wrote:
Hello Sebastian,
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index fc4ddb7792d7..ccc55e40e81c 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> @@ -2064,6 +2064,20 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
> goto unregister_aux;
> }
>
> + next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
devm_drm_of_get_bridge() looks for either a panel or a bridge. Is it
possible to have a panel connected here?
If it isn't, then using of_drm_get_bridge_by_endpoint() which has just been
merged [0] would be much simpler and cleaner.
[0] https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/03d1078112fddd706b2c1e4a7d98cf18700eb5df
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Will Deacon @ 2026-05-19 11:11 UTC (permalink / raw)
To: David Woodhouse
Cc: Paolo Bonzini, Marc Zyngier, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <3f9d731c3d26b0367600f1069e6425099bc34eac.camel@infradead.org>
On Tue, May 19, 2026 at 11:41:26AM +0100, David Woodhouse wrote:
> On Wed, 2026-05-13 at 18:24 +0200, Paolo Bonzini wrote:
> >
> > > See commit https://git.kernel.org/torvalds/c/49a1a2c70a7f which adds a
> > > new guest-visible feature in revision 3, but allowed userspace to
> > > restore the old behaviour by setting it to revision 2. All my patch
> > > above does, is make it possible to set it to revision 1 as
> > > well. Because https://git.kernel.org/torvalds/c/d53c2c29ae0d previously
> > > changed the behaviour and bumped the default to 2 *without* allowing
> > > userspace to restore the prior behaviour, and we've been carrying a
> > > *revert* of that patch.
> > >
> > > Why would we *not* accept such a patch?
> >
> > Agreed. Even ignoring your revert, there's no reason why any upgrade
> > past 49a1a2c70a7f has to be from after d53c2c29ae0d.
>
> So where do we go from here?
>
> I assume you'll be taking this Documentation patch via the KVM tree?
>
> But what about the actual fix at
> https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/
>
> This is a simple and unintrusive bug fix to make KVM/arm64 follow the
> "common sense" requirement that the doc patch codifies, apparently
> being rejected with the rather bizarre claim that KVM has no *need* to
> maintain guest-visible compatibility across host kernel changes.
>
> So... what next? Is one of the other KVM/arm64 maintainers going to
> speak up? Paolo would you consider taking the fixes through your tree
> directly?
>
> Does Arm not actually *care* whether AArch64 is considered a stable and
> mature platform for KVM hosting?
Hey, come on. Marc cares more about this stuff than anybody else on the
planet. He's been single-handedly maintaining the tree for the past
couple of releases while Oliver was out and he's on the end of a _lot_
of patches. I'm only cc'd on a fraction of the KVM/arm64 changes and
it's bedlam.
Will
^ permalink raw reply
* Re: [PATCH v9 1/7] pinctrl: s32cc: use dev_err_probe() and improve error messages
From: Enric Balletbo i Serra @ 2026-05-19 11:12 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, Eric Chanudet, imx,
linux-arm-kernel, linux-gpio, linux-kernel, NXP S32 Linux Team,
Pengutronix Kernel Team, Vincent Guittot
In-Reply-To: <20260504131148.3622697-2-khristineandreea.barbulescu@oss.nxp.com>
Hi,
On Mon, May 4, 2026 at 3:12 PM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
>
> Change dev_err&return statements into dev_err_probe throughout the driver
> on the probing path.
>
> Signed-off-by: Andrei Stefanescu <andrei.stefanescu@oss.nxp.com>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
> ---
> drivers/pinctrl/nxp/pinctrl-s32cc.c | 64 ++++++++++++++---------------
> 1 file changed, 30 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/pinctrl/nxp/pinctrl-s32cc.c b/drivers/pinctrl/nxp/pinctrl-s32cc.c
> index fe7cd641fddd..56be6e8d624e 100644
> --- a/drivers/pinctrl/nxp/pinctrl-s32cc.c
> +++ b/drivers/pinctrl/nxp/pinctrl-s32cc.c
> @@ -2,7 +2,7 @@
> /*
> * Core driver for the S32 CC (Common Chassis) pin controller
> *
> - * Copyright 2017-2022,2024 NXP
> + * Copyright 2017-2022,2024-2025 NXP
> * Copyright (C) 2022 SUSE LLC
> * Copyright 2015-2016 Freescale Semiconductor, Inc.
> */
> @@ -236,10 +236,10 @@ static int s32_dt_group_node_to_map(struct pinctrl_dev *pctldev,
> }
>
> ret = pinconf_generic_parse_dt_config(np, pctldev, &cfgs, &n_cfgs);
> - if (ret) {
> - dev_err(dev, "%pOF: could not parse node property\n", np);
> - return ret;
> - }
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "%pOF: could not parse node property\n",
> + np);
>
Nitpick: I think this is not part of the probe path but is called when
a consumer requests a pin group, so using dev_err_probe is slightly
misleading here, although I think it's harmless.
In any case, with or without that change it looks good to me, so
Reviewed-by: Enric Balletbo i Serra <eballetb@redhat.com>
> if (n_cfgs)
> reserve++;
> @@ -763,15 +763,15 @@ static int s32_pinctrl_parse_groups(struct device_node *np,
> grp->data.name = np->name;
>
> npins = of_property_count_elems_of_size(np, "pinmux", sizeof(u32));
> - if (npins < 0) {
> - dev_err(dev, "Failed to read 'pinmux' property in node %s.\n",
> - grp->data.name);
> - return -EINVAL;
> - }
> - if (!npins) {
> - dev_err(dev, "The group %s has no pins.\n", grp->data.name);
> - return -EINVAL;
> - }
> + if (npins < 0)
> + return dev_err_probe(dev, -EINVAL,
> + "Failed to read 'pinmux' in node %s\n",
> + grp->data.name);
> +
> + if (!npins)
> + return dev_err_probe(dev, -EINVAL,
> + "The group %s has no pins\n",
> + grp->data.name);
>
> grp->data.npins = npins;
>
> @@ -812,10 +812,9 @@ static int s32_pinctrl_parse_functions(struct device_node *np,
> /* Initialise function */
> func->name = np->name;
> func->ngroups = of_get_child_count(np);
> - if (func->ngroups == 0) {
> - dev_err(info->dev, "no groups defined in %pOF\n", np);
> - return -EINVAL;
> - }
> + if (func->ngroups == 0)
> + return dev_err_probe(info->dev, -EINVAL,
> + "No groups defined in %pOF\n", np);
>
> groups = devm_kcalloc(info->dev, func->ngroups,
> sizeof(*func->groups), GFP_KERNEL);
> @@ -886,10 +885,9 @@ static int s32_pinctrl_probe_dt(struct platform_device *pdev,
> }
>
> nfuncs = of_get_child_count(np);
> - if (nfuncs <= 0) {
> - dev_err(&pdev->dev, "no functions defined\n");
> - return -EINVAL;
> - }
> + if (nfuncs <= 0)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "No functions defined\n");
>
> info->nfunctions = nfuncs;
> info->functions = devm_kcalloc(&pdev->dev, nfuncs,
> @@ -919,18 +917,17 @@ static int s32_pinctrl_probe_dt(struct platform_device *pdev,
> int s32_pinctrl_probe(struct platform_device *pdev,
> const struct s32_pinctrl_soc_data *soc_data)
> {
> - struct s32_pinctrl *ipctl;
> - int ret;
> - struct pinctrl_desc *s32_pinctrl_desc;
> - struct s32_pinctrl_soc_info *info;
> #ifdef CONFIG_PM_SLEEP
> struct s32_pinctrl_context *saved_context;
> #endif
> + struct pinctrl_desc *s32_pinctrl_desc;
> + struct s32_pinctrl_soc_info *info;
> + struct s32_pinctrl *ipctl;
> + int ret;
>
> - if (!soc_data || !soc_data->pins || !soc_data->npins) {
> - dev_err(&pdev->dev, "wrong pinctrl info\n");
> - return -EINVAL;
> - }
> + if (!soc_data || !soc_data->pins || !soc_data->npins)
> + return dev_err_probe(&pdev->dev, -EINVAL,
> + "Wrong pinctrl info\n");
>
> info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
> if (!info)
> @@ -965,10 +962,9 @@ int s32_pinctrl_probe(struct platform_device *pdev,
> s32_pinctrl_desc->owner = THIS_MODULE;
>
> ret = s32_pinctrl_probe_dt(pdev, ipctl);
> - if (ret) {
> - dev_err(&pdev->dev, "fail to probe dt properties\n");
> - return ret;
> - }
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "Fail to probe dt properties\n");
>
> ipctl->pctl = devm_pinctrl_register(&pdev->dev, s32_pinctrl_desc,
> ipctl);
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH 0/5] arm64: dts: imx91-11x11-evk/imx91-9x9-qsb: misc cleanups and improvements
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
Remove unused clock-frequency property from mdio node for i.MX91 QSB.
Add watchdog pinctrl configuration for i.MX91 EVK and QSB to support
external reset output.
Add Ethernet PHY reset GPIO configuration for i.MX91 EVK and QSB to
ensure proper PHY initialization.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
Joy Zou (5):
arm64: dts: imx91-9x9-qsb: remove unused property clock-frequency from mdio node
arm64: dts: imx91-9x9-qsb: add pinctrl for wdog3 reset
arm64: dts: imx91-11x11-evk: add pinctrl for wdog3 reset
arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYs
arm64: dts: imx91-9x9-qsb: add reset gpios for ethernet PHYs
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 14 ++++++++++++++
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 12 +++++++++++-
2 files changed, 25 insertions(+), 1 deletion(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260519-b4-imx91-qsb-opt-583b781ee250
Best regards,
--
Joy Zou <joy.zou@nxp.com>
^ permalink raw reply
* [PATCH 1/5] arm64: dts: imx91-9x9-qsb: remove unused property clock-frequency from mdio node
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
The clock-frequency property is not implemented. Remove it to clean up the
device tree.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
index 1239bbf579da44ab3f4be2dc566c53a1e5db6c05..9cbfe57be2d3c37208611dfba5acd428f0b58c3e 100644
--- a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
@@ -79,7 +79,6 @@ mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <1>;
#size-cells = <0>;
- clock-frequency = <5000000>;
ethphy1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.37.1
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: imx91-9x9-qsb: add pinctrl for wdog3 reset
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
The wdog3 node enables fsl,ext-reset-output to assert an external
reset signal upon watchdog timeout, but lacks pinctrl configuration
for the physical pad.
Without proper pinctrl settings, which could cause the watchdog timeout
to fail to reset the board hardware.
Add pinctrl configuration to ensure the pin is properly muxed and
configured for external watchdog reset functionality.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
index 9cbfe57be2d3c37208611dfba5acd428f0b58c3e..62549a6de1b64496ffa5cf3f543145a00dbb10a8 100644
--- a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
@@ -230,6 +230,12 @@ MX91_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe
MX91_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX91_PAD_WDOG_ANY__WDOG1_WDOG_ANY 0x31e
+ >;
+ };
};
&lpi2c1 {
@@ -419,6 +425,8 @@ &usdhc2 {
};
&wdog3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
fsl,ext-reset-output;
status = "okay";
};
--
2.37.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: imx91-11x11-evk: add pinctrl for wdog3 reset
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
The wdog3 node enables fsl,ext-reset-output to assert an external
reset signal upon watchdog timeout, but lacks pinctrl configuration
for the physical pad.
Without proper pinctrl settings, which could cause the watchdog timeout
to fail to reset the board hardware.
Add pinctrl configuration to ensure the pin is properly muxed and
configured for external watchdog reset functionality.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
index de524f1921de808ee29895852fcbea37565a7e07..3fbdcb87a2f3acf44c15b98d7b6ee212fb62699f 100644
--- a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
@@ -586,6 +586,8 @@ &usdhc3 {
};
&wdog3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
fsl,ext-reset-output;
status = "okay";
};
@@ -947,4 +949,10 @@ MX91_PAD_SD3_DATA2__GPIO3_IO24 0x31e
MX91_PAD_SD3_DATA3__GPIO3_IO25 0x31e
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX91_PAD_WDOG_ANY__WDOG1_WDOG_ANY 0x31e
+ >;
+ };
};
--
2.37.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: imx91-11x11-evk: add reset gpios for ethernet PHYs
From: Joy Zou @ 2026-05-19 11:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Ye Li,
Jacky Bai, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Joy Zou
In-Reply-To: <20260519-b4-imx91-qsb-opt-v1-0-9b416d2dc224@nxp.com>
Both the PHYs of the EQOS interface and the FEC interface are supported
to be reset by I2C GPIO expander. So add the support to reset PHYs.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
index 3fbdcb87a2f3acf44c15b98d7b6ee212fb62699f..5716febb5a50f67b7b57a3cc856410857325c206 100644
--- a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
@@ -198,6 +198,9 @@ mdio {
ethphy1: ethernet-phy@1 {
reg = <1>;
+ reset-gpios = <&pcal6524 15 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
realtek,clkout-disable;
};
};
@@ -219,6 +222,9 @@ mdio {
ethphy2: ethernet-phy@2 {
reg = <2>;
+ reset-gpios = <&pcal6524 16 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <80000>;
realtek,clkout-disable;
};
};
--
2.37.1
^ 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