* Re: [PATCH v6] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
From: Heiko Stuebner @ 2026-04-27 12:23 UTC (permalink / raw)
To: MidG971
Cc: Heiko Stuebner, linux-rockchip, linux-arm-kernel, devicetree,
shawn.lin, jonas
In-Reply-To: <20260327091128.2458-1-midgy971@gmail.com>
On Fri, 27 Mar 2026 10:11:28 +0100, MidG971 wrote:
> The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
> provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
> This chip is currently modeled only as a fixed regulator
> (vcc3v3_pi6c_03), with no clock output representation.
>
> The PI6C20100 is a clock generator, not a power supply. Model it
> properly as a gated-fixed-clock, following the pattern established
> for the Rock 5 ITX and other boards with similar PCIe clock buffer
> chips.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
commit: 8df9160f6a50dbdae8ec287d429efc9d2d9001bd
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: (subset) [PATCH 0/6] arm64: dts: rockchip: Add peripheral support for Khadas Edge 2L
From: Heiko Stuebner @ 2026-04-27 12:23 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Gray Huang
Cc: Heiko Stuebner, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, nick
In-Reply-To: <20260325054614.1497147-1-gray.huang@wesion.com>
On Wed, 25 Mar 2026 13:46:08 +0800, Gray Huang wrote:
> This patch series adds support for several key peripherals to the
> Khadas Edge 2L board, which is based on the Rockchip RK3576 SoC.
>
> These patches build upon the basic board support that was previously
> applied to the rockchip tree. This series enables essential
> functionalities including power management, wireless connectivity,
> graphics, display output, and USB support.
>
> [...]
Applied, thanks!
[1/6] arm64: dts: rockchip: Add PMIC support for Khadas Edge 2L
commit: 7cd8b37304be367106a02d4d902294e9bea3f45d
[3/6] arm64: dts: rockchip: Enable GPU for Khadas Edge 2L
commit: 6d72e0d07145449a33678624436c73da09873c43
[4/6] arm64: dts: rockchip: Add HDMI and VOP support for Khadas Edge 2L
commit: e9ec83fbc3d46b39fe92a0cbda4795ece30717f5
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Enable the NPU on rk3588-rock-5-itx
From: Heiko Stuebner @ 2026-04-27 12:23 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sten-Silver Ots
Cc: Heiko Stuebner, FUKAUMI Naoki, Torsten Duwe, Dmitry Baryshkov,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260413215301.4656-1-stensilver@gmail.com>
On Tue, 14 Apr 2026 00:52:49 +0300, Sten-Silver Ots wrote:
> This commit enables the NPU on Radxa Rock 5 ITX board.
> The regulator vdd_npu_s0 was already in place and since the NPUs
> power domain supply is now described remove the always-on property
> from the regulator.
>
>
Applied, thanks!
[1/1] arm64: dts: rockchip: Enable the NPU on rk3588-rock-5-itx
commit: e4f7054e819eece6fd83072ff2dcefc7a36224c0
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v4 0/5] clk: rockchip: rk3588: add I2S MCLK output gate clocks
From: Heiko Stuebner @ 2026-04-27 12:23 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniele Briguglio
Cc: Heiko Stuebner, Nicolas Frattaroli, linux-clk, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel,
Krzysztof Kozlowski, Ricardo Pardini
In-Reply-To: <20260419-rk3588-mclk-gate-grf-v4-0-513a42dd1dcc@superkali.me>
On Sun, 19 Apr 2026 13:43:05 +0200, Daniele Briguglio wrote:
> On RK3588, the four I2S master clock (MCLK) outputs to external IO
> pins are gated by bits in SYS_GRF SOC_CON6 (offset 0x0318). These
> are set-to-disable gates with hiword mask semantics.
>
> The TRM documents the reset value of these bits as 0 (gate open),
> but in practice the Rockchip firmware (BL31) may set them during
> early boot, preventing the MCLK signal from reaching external audio
> codecs. The kernel should manage these gates explicitly so that
> audio functionality does not depend on bootloader register state.
>
> [...]
Applied, thanks!
[1/5] dt-bindings: clock: rockchip,rk3588-cru: add I2S MCLK output to IO clock IDs
commit: 56c2ca0ae7cb9254c4c2b82baa0afe29feaa274e
[2/5] clk: rockchip: allow grf_type_sys lookup in aux_grf_table
commit: 28820fc7983b9c8e160c0095067a570bdfcae1f0
[3/5] clk: rockchip: add helper to register auxiliary GRFs
commit: 32d1d88c4165d0da31d3bfda912e80e8110d6fc1
[4/5] soc: rockchip: rk3588: add SYS_GRF SOC_CON6 register offset
commit: 06c990bffdbea7cf655e728f4423ecd13fb030f6
[5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
commit: 02b9b0bb626989b947d82bbe4e050f0254e2046d
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: (subset) [PATCH 0/2] Improve gmac0 DT config for NanoPi R5S
From: Heiko Stuebner @ 2026-04-27 12:23 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Diederik de Haas
Cc: Heiko Stuebner, Arnd Bergmann, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260401131551.734456-1-diederik@cknow-tech.com>
On Wed, 01 Apr 2026 15:11:37 +0200, Diederik de Haas wrote:
> These 2 patches contain a fix for an incorrect pinctlr definition and
> replaces several deprecated snps,reset* properties with their
> non-deprecated replacements.
>
> Diederik de Haas (2):
> arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S
> arm64: dts: rockchip: Replace deprecated snps,* props for NanoPi R5S
>
> [...]
Applied, thanks!
[1/2] arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S
commit: c83c4a09d4c01c91d6c52d6d4d77a06892a3e83b
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: rockchip: Add AP6275P wireless support for Khadas Edge 2L
From: Heiko Stuebner @ 2026-04-27 12:25 UTC (permalink / raw)
To: Gray Huang
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, nick, Gray Huang
In-Reply-To: <20260325054614.1497147-3-gray.huang@wesion.com>
Am Mittwoch, 25. März 2026, 06:46:10 Mitteleuropäische Sommerzeit schrieb Gray Huang:
> The Khadas Edge 2L board uses the Ampak AP6275P (BCM43752) PCIe
> Wi-Fi 6 module.
>
> Enable the pcie0 controller and add the Wi-Fi module as its child
> node. Additionally, enable the HYM8563 RTC to provide the 32.768kHz
> LPO clock required by the Wi-Fi module, along with the necessary
> CombPHY and fixed regulator.
>
> Signed-off-by: Gray Huang <gray.huang@wesion.com>
Please make this 2 patches:
- add the rtc
- add the wifi using the rtc
> ---
> .../dts/rockchip/rk3576-khadas-edge-2l.dts | 71 ++++++++++++++++++-
> 1 file changed, 70 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> index 5781deae00d9..09cb0f0d6dcf 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> @@ -47,7 +47,19 @@ vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
> vin-supply = <&vcc_sys>;
> };
>
> -
> + vcc_wifi_reg_on: regulator-wifi-reg-on {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&wifi_reg_on>;
> + pinctrl-names = "default";
> + regulator-name = "wifi_reg_on";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vcc_1v8_s3>;
> + };
> };
>
> &cpu_l0 {
> @@ -431,6 +443,63 @@ regulator-state-mem {
> };
> };
>
> +&combphy0_ps {
> + status = "okay";
> +};
also please sort also phandles alphabetically, i.e. pcie2 between
c-something and i2c is the wrong place :-)
Heiko
> +
> +&pcie0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie0_rst>;
^ permalink raw reply
* Re: [PATCH v2] arm64/irqflags: __always_inline the arch_local_irq_*() helpers
From: Catalin Marinas @ 2026-04-27 12:26 UTC (permalink / raw)
To: Breno Leitao
Cc: Will Deacon, mark.rutland, leo.bras, leo.yan, linux-arm-kernel,
linux-kernel, palmer, paulmck, puranjay, usama.arif, rmikey,
kernel-team
In-Reply-To: <20260421-arm64_always_inline-v2-1-c59d1400514d@debian.org>
On Tue, Apr 21, 2026 at 08:58:57AM -0700, Breno Leitao wrote:
> Force-inline all of the arch_local_irq_*() wrappers so they cannot be
> emitted out-of-line:
>
> - arch_local_irq_enable()
> - arch_local_irq_disable()
> - arch_local_save_flags()
> - arch_irqs_disabled_flags()
> - arch_irqs_disabled()
> - arch_local_irq_save()
> - arch_local_irq_restore()
I'll queue this, thanks!
I think we should also do local_daif_{mask,restore,inherit} as they seem
to be called from noinstr locations in entry-common.c.
--
Catalin
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: rockchip: Enable USB for Khadas Edge 2L
From: Heiko Stuebner @ 2026-04-27 12:27 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Gray Huang
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260325054614.1497147-6-gray.huang@wesion.com>
Am Mittwoch, 25. März 2026, 06:46:13 Mitteleuropäische Sommerzeit schrieb Gray Huang:
> The Khadas Edge 2L board provides one USB 3.0 Host port and one
> USB 2.0 port (connected via an internal hub). Enable the
> corresponding DWC3 controllers and PHYs.
>
> Signed-off-by: Gray Huang <gray.huang@wesion.com>
> ---
> .../dts/rockchip/rk3576-khadas-edge-2l.dts | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> index 003342fd69a7..8ecd00f6645d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> @@ -30,6 +30,29 @@ hdmi_con_in: endpoint {
> };
> };
>
> + vcc5v0_device: regulator-vcc5v0-device {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_device";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> +
> + vcc5v0_host: regulator-vcc5v0-host {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_host";
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + enable-active-high;
> + gpio = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
> + vin-supply = <&vcc5v0_device>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb_host_pwren>;
> + };
> +
> vcc_sys: regulator-vcc5v0-sys {
> compatible = "regulator-fixed";
> regulator-name = "vcc_sys";
> @@ -531,6 +554,12 @@ pcie0_rst: pcie0-rst {
> };
> };
>
> + usb {
> + usb_host_pwren: usb-host-pwren {
> + rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> wifi {
> wifi_reg_on: wifi-reg-on {
> rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
> @@ -542,6 +571,24 @@ wifi_wake_host: wifi-wake-host {
> };
> };
>
> +&usb_drd1_dwc3 {
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> +&u2phy1 {
> + status = "okay";
> +};
> +
> +&u2phy1_otg {
> + phy-supply = <&vcc5v0_host>;
> + status = "okay";
> +};
> +
> +&combphy1_psu {
> + status = "okay";
> +};
same here, u-something and c-something between pinctrl and sdhci
is the wrong place.
Heko
> +
> &sdhci {
> bus-width = <8>;
> no-sdio;
>
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: rockchip: Add Bluetooth support for Khadas Edge 2L
From: Heiko Stuebner @ 2026-04-27 12:27 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Gray Huang
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, nick,
Gray Huang
In-Reply-To: <20260325054614.1497147-7-gray.huang@wesion.com>
Am Mittwoch, 25. März 2026, 06:46:14 Mitteleuropäische Sommerzeit schrieb Gray Huang:
> Enable Bluetooth support for the Ampak AP6275P module on the
> Khadas Edge 2L. This involves enabling the UART5 interface for
> HCI communication and defining the required regulators and
> power-sequence pins.
>
> Signed-off-by: Gray Huang <gray.huang@wesion.com>
> ---
> .../dts/rockchip/rk3576-khadas-edge-2l.dts | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> index 8ecd00f6645d..345dc4c981c1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-khadas-edge-2l.dts
> @@ -560,6 +560,20 @@ usb_host_pwren: usb-host-pwren {
> };
> };
>
> + bluetooth {
> + bt_reg_on: bt-reg-on {
> + rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> +
> + bt_wake_host: bt-wake-host {
> + rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> +
> + host_wake_bt: host-wake-bt {
> + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
same sorting problem with bluetooth between usb-foo and wifi-foo.
> +
> wifi {
> wifi_reg_on: wifi-reg-on {
> rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
Heiko
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: remoteproc: Add MediaTek mt8196 VCP binding
From: Rob Herring (Arm) @ 2026-04-27 12:39 UTC (permalink / raw)
To: Xiangzhi Tang
Cc: Hailong Fan, Krzysztof Kozlowski, linux-mediatek, linux-kernel,
devicetree, Project_Global_Chrome_Upstream_Group, Justin Yeh,
Conor Dooley, Xiangzhi Tang, AngeloGioacchino Del Regno,
linux-remoteproc, linux-arm-kernel, Vince-WL Liu, Huayu Zong,
Jarried Lin, Bjorn Andersson, Matthias Brugger, Mathieu Poirier
In-Reply-To: <20260427111446.22955-2-xiangzhi.tang@mediatek.com>
On Mon, 27 Apr 2026 19:04:40 +0800, Xiangzhi Tang wrote:
> Add device tree binding for the MediaTek Video Companion Processor
> (VCP), a RISC-V based coprocessor used for video processing and
> multimedia tasks on mt8196 and future MediaTek SoCs.
>
> The VCP is a heterogeneous multi-core processor that can contain
> multiple RISC-V cores with different hart (hardware thread)
> configurations. Key features:
>
> - Supports both single-core and multi-core VCP configurations
> - Each core can have 1 or 2 harts (hardware threads)
> - Shared SRAM memory space partitioned among cores
> - Communication via 5 dedicated mailbox channels for IPI messaging
> - Integrated with SoC IOMMU for multimedia memory management
> - Boot and power management coordinated with ARM Trusted Firmware
>
> The binding defines both the top-level VCP device (with mailboxes,
> interrupts, and power domains) and child nodes for individual VCP
> cores (with SRAM allocation and hart configuration).
>
> Signed-off-by: Xiangzhi Tang <xiangzhi.tang@mediatek.com>
> ---
> .../remoteproc/mediatek,mt8196-vcp.yaml | 166 ++++++++++++++++++
> 1 file changed, 166 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/mediatek,mt8196-vcp.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/remoteproc/mediatek,mt8196-vcp.example.dts:26:18: fatal error: dt-bindings/power/mt8196-power.h: No such file or directory
26 | #include <dt-bindings/power/mt8196-power.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.dtbs:140: Documentation/devicetree/bindings/remoteproc/mediatek,mt8196-vcp.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1635: dt_binding_check] Error 2
make: *** [Makefile:248: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260427111446.22955-2-xiangzhi.tang@mediatek.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH] crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A
From: Thorsten Blum @ 2026-04-27 12:40 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Marek Behún,
Ard Biesheuvel, Linus Walleij
Cc: stable, linux-crypto, linux-arm-kernel, linux-kernel
Commit 8006aff15516 ("crypto: atmel-sha204a - Set hwrng quality to
lowest possible") reduced the hwrng quality to 1 based on a review by
Bill Cox [1]. However, despite its title, the review only tested the
ATSHA204, not the ATSHA204A.
In the same thread, Atmel engineer Landon Cox wrote "this behavior has
been eliminated entirely"[2] in the ATSHA204A and "this problem does not
affect the ATECC108 or the ATECC108A (or the ATSHA204A)"[3].
According to the official ATSHA204A datasheet [4], the device contains a
high-quality hardware RNG that combines its output with an internal seed
value stored in EEPROM or SRAM to generate random numbers. The device
also implements all security functions using SHA-256, and the driver
uses the chip's Random command in seed-update mode.
Keep 'quality = 1' for ATSHA204, but drop the explicit hwrng quality
reduction for ATSHA204A and fall back to the hwrng core default.
[1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html
[2] https://www.metzdowd.com/pipermail/cryptography/2014-December/023852.html
[3] https://www.metzdowd.com/pipermail/cryptography/2014-December/023886.html
[4] https://ww1.microchip.com/downloads/en/DeviceDoc/ATSHA204A-Data-Sheet-40002025A.pdf
Fixes: 8006aff15516 ("crypto: atmel-sha204a - Set hwrng quality to lowest possible")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-sha204a.c | 40 ++++++++++++++++++----------------
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index dbb39ed0cea1..df69fb190e52 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -19,6 +19,25 @@
#include <linux/workqueue.h>
#include "atmel-i2c.h"
+enum atmel_sha204a_variant {
+ ATSHA204 = 1,
+ ATSHA204A,
+};
+
+static const struct of_device_id atmel_sha204a_dt_ids[] __maybe_unused = {
+ { .compatible = "atmel,atsha204", .data = (void *)ATSHA204 },
+ { .compatible = "atmel,atsha204a", .data = (void *)ATSHA204A },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
+
+static const struct i2c_device_id atmel_sha204a_id[] = {
+ { .name = "atsha204", .driver_data = ATSHA204 },
+ { .name = "atsha204a", .driver_data = ATSHA204A },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, atmel_sha204a_id);
+
static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
void *areq, int status)
{
@@ -171,11 +190,8 @@ static int atmel_sha204a_probe(struct i2c_client *client)
i2c_priv->hwrng.name = dev_name(&client->dev);
i2c_priv->hwrng.read = atmel_sha204a_rng_read;
- /*
- * According to review by Bill Cox [1], this HWRNG has very low entropy.
- * [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html
- */
- i2c_priv->hwrng.quality = 1;
+ if ((uintptr_t)i2c_get_match_data(client) == ATSHA204)
+ i2c_priv->hwrng.quality = 1;
ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng);
if (ret)
@@ -202,20 +218,6 @@ static void atmel_sha204a_remove(struct i2c_client *client)
kfree((void *)i2c_priv->hwrng.priv);
}
-static const struct of_device_id atmel_sha204a_dt_ids[] __maybe_unused = {
- { .compatible = "atmel,atsha204", },
- { .compatible = "atmel,atsha204a", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
-
-static const struct i2c_device_id atmel_sha204a_id[] = {
- { "atsha204" },
- { "atsha204a" },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(i2c, atmel_sha204a_id);
-
static struct i2c_driver atmel_sha204a_driver = {
.probe = atmel_sha204a_probe,
.remove = atmel_sha204a_remove,
^ permalink raw reply related
* Re: [PATCH 3/8] firmware: arm_ffa: Align RxTx buffer size before mapping
From: Sudeep Holla @ 2026-04-27 12:42 UTC (permalink / raw)
To: Sebastian Ene; +Cc: linux-kernel, linux-arm-kernel, Jens Wiklander
In-Reply-To: <ae8sqehR7yQFheuj@google.com>
On Mon, Apr 27, 2026 at 09:30:17AM +0000, Sebastian Ene wrote:
> On Thu, Apr 23, 2026 at 06:22:53PM +0100, Sudeep Holla wrote:
> > Commit 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during
> > RXTX_MAP") advertises PAGE_ALIGN(rxtx_bufsz) to firmware when mapping the
> > buffers but the driver continues to stores the minimum FF-A buffer size
> > in drv_info->rxtx_bufsz which is used elsewhere in the driver.
>
> Hello Sudeep,
>
> >
> > Align the size before storing it so that the allocation, validation and
> > FFA_RXTX_MAP all use the same buffer size.
> >
>
> Thanks for fixing this,
It was my fault, I wasn't expecting sashiko was covering most of the lists
now, so didn't check for it in time.
> Reviewed-by: Sebastian Ene <sebastianene@google.com>.
>
Thanks!
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: M.samet Duman @ 2026-04-27 12:48 UTC (permalink / raw)
To: Sebastian Ene
Cc: maz, oupton, will, ayrton, catalin.marinas, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui, stable,
sebastianene
In-Reply-To: <20260422102540.1433704-1-sebastianene@google.com>
I haven't tested this, but the change looks reasonable to me.
Samet
> 2026. 4. 22. 오후 1:27, Sebastian Ene <sebastianene@google.com> 작성:
>
> Prevent the pKVM hypervisor from making assumptions that the
> endpoint memory access descriptor (EMAD) comes right after the
> FF-A memory region header and enforce a strict placement for it
> when validating an FF-A memory lend/share transaction.
>
> Prior to FF-A version 1.1 the header of the memory region
> didn't contain an offset to the endpoint memory access descriptor.
> The layout of a memory transaction looks like this:
>
> Field name | Offset
> -- 0
> [ Header (ffa_mem_region) |__ ep_mem_offset
> EMAD 1 (ffa_mem_region_attributes) |
> ]
>
> Reject the host from specifying a memory access descriptor offset
> that is different than the size of the memory region header.
>
> Cc: stable@vger.kernel.org
> Fixes: 42fb33dde42b ("KVM: arm64: Use FF-A 1.1 with pKVM")
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 94161ea1cd60..0703c0ad8dff 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -508,6 +508,12 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> buf = hyp_buffers.tx;
> memcpy(buf, host_buffers.tx, fraglen);
>
> + if (FFA_MEM_REGION_HAS_EP_MEM_OFFSET(hyp_ffa_version) &&
> + buf->ep_mem_offset != sizeof(struct ffa_mem_region)) {
> + ret = FFA_RET_INVALID_PARAMETERS;
> + goto out_unlock;
> + }
> +
> ep_mem_access = (void *)buf +
> ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
> offset = ep_mem_access->composite_off;
> --
> 2.54.0.rc1.555.g9c883467ad-goog
>
>
^ permalink raw reply
* Re: [PATCH v22 5/8] dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
From: Luca Ceresoli @ 2026-04-27 12:59 UTC (permalink / raw)
To: Laurentiu Palcu, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, linux-phy, imx,
linux-arm-kernel, linux, Alexander Stein, Ying Liu
In-Reply-To: <20260424-dcss-hdmi-upstreaming-v22-5-30a28f89298d@oss.nxp.com>
Hello Laurentiu,
On Fri Apr 24, 2026 at 1:07 PM CEST, Laurentiu Palcu wrote:
> From: Sandor Yu <Sandor.yu@nxp.com>
>
> Add bindings for Freescale iMX8MQ DP and HDMI PHY.
>
> Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
> .../bindings/phy/fsl,imx8mq-hdptx-phy.yaml | 80 ++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-hdptx-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-hdptx-phy.yaml
> new file mode 100644
> index 0000000000000..a24435139b8b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-hdptx-phy.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/fsl,imx8mq-hdptx-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence HDP-TX DP/HDMI PHY for Freescale i.MX8MQ SoC
> +
> +maintainers:
> + - Sandor Yu <sandor.yu@nxp.com>
Based on what you said in the cover, I guess this line will have to be
changed. Are you willing to maintain this binding?
> +description:
> + The Cadence HDP-TX DP/HDMI PHY is a child node of the MHDP8501 bridge,
> + sharing the same MMIO region as the parent bridge node.
> +
> +properties:
> + compatible:
> + const: fsl,imx8mq-hdptx-phy
> +
> + clocks:
> + items:
> + - description: PHY reference clock.
> + - description: APB clock.
> +
> + clock-names:
> + items:
> + - const: ref
> + - const: apb
> +
> + "#phy-cells":
> + const: 0
> +
> +required:
> + - compatible
> + - clocks
> + - clock-names
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/imx8mq-clock.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + display-bridge@32c00000 {
> + compatible = "fsl,imx8mq-mhdp8501";
> + reg = <0x32c00000 0x100000>;
> + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "plug_in", "plug_out";
> + clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
> + phys = <&dp_phy>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
The ports are not mentioned in the properties. I'm not a DT maintainer, but
I think they should, e.g. to mention which port is the input and which is
the output.
> +
> + port@0 {
> + reg = <0>;
> + endpoint {
> + remote-endpoint = <&dcss_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + endpoint {
> + data-lanes = <2 1 0 3>;
Having a remote-endpoint property would be nice here, to make the example
more complete.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v22 4/8] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
From: Luca Ceresoli @ 2026-04-27 12:59 UTC (permalink / raw)
To: Laurentiu Palcu, Parshuram Thombare, Swapnil Jakhade,
Dmitry Baryshkov, Nikhil Devshatwar, Jayesh Choudhary,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: dri-devel, devicetree, linux-kernel, linux-phy, imx,
linux-arm-kernel, linux, Alexander Stein, Ying Liu
In-Reply-To: <20260424-dcss-hdmi-upstreaming-v22-4-30a28f89298d@oss.nxp.com>
Hello Laurentiu,
On Fri Apr 24, 2026 at 1:07 PM CEST, Laurentiu Palcu wrote:
> From: Sandor Yu <Sandor.yu@nxp.com>
>
> Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
> used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
> standards according embedded Firmware running in the uCPU.
>
> For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
> SOC's ROM code. Bootload binary included respective specific firmware
> is required.
>
> Driver will check display connector type and
> then load the corresponding driver.
>
> Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
> Co-developed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
...
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
...
> +enum drm_connector_status cdns_mhdp8501_detect(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> + struct cdns_mhdp8501_device *mhdp = bridge->driver_private;
Please don't use driver_private. Write a oneliner function wrapping
container_of(). There are many examples in bridges,
e.g. bridge_to_sn65dsi83().
> +static int cdns_mhdp8501_get_bridge_type(struct device_node *out_ep,
> + int *bridge_type)
> +{
> + struct device_node *incoming_ep, *node, *ep;
> + int ret = -ENODEV;
> +
> + incoming_ep = of_graph_get_remote_endpoint(out_ep);
> + if (!incoming_ep)
> + return -ENODEV;
> +
> + node = of_graph_get_port_parent(incoming_ep);
> + if (!node) {
> + of_node_put(incoming_ep);
> + return -ENODEV;
> + }
> +
> + if (of_device_is_compatible(node, "hdmi-connector")) {
> + *bridge_type = DRM_MODE_CONNECTOR_HDMIA;
> + ret = 0;
> + } else if (of_device_is_compatible(node, "dp-connector")) {
> + *bridge_type = DRM_MODE_CONNECTOR_DisplayPort;
> + ret = 0;
> + } else {
> + for_each_endpoint_of_node(node, ep) {
> + if (ep == incoming_ep)
> + continue;
> +
> + ret = cdns_mhdp8501_get_bridge_type(ep, bridge_type);
> + if (!ret) {
> + of_node_put(ep);
> + break;
> + }
> + }
> + }
I don't follow what this logic is doing. Can you provide a practical
example of the "next node" (@node variable) where you fall in the else
case?
Also, while this resursion will probably work in most, if not all,
realistic cases, it could take incorrect decisions. Consider the case there
in the else branch your @node points to some node having two input
endpoints: ep0 is the incoming_ep and ep1 is another input endpoint. In
such case you would recurse on ep1 and return its bridge type, which
however has nothing to to with the output and might be incorrect.
Another question is whether this driver should have two compatible strings,
one for hdmi and one for dp, and set the bridge_type based on that. This
would make it a lot simpler and remove the need for this function.
But if I guess right from the code, this device can output either hdmi or
dp, and the implementation infers the type based on this device tree
walk. Is it the case?
> +static int cdns_mhdp8501_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct cdns_mhdp8501_device *mhdp;
> + const struct drm_bridge_funcs *bridge_funcs;
> + enum phy_mode phy_mode;
> + struct resource *res;
> + u32 lane_mapping;
> + int bridge_type;
> + u32 reg;
> + int ret;
> +
> + ret = cdns_mhdp8501_dt_parse(pdev, &bridge_type, &lane_mapping);
> + if (ret < 0)
> + return ret;
> +
> + ret = devm_of_platform_populate(dev);
> + if (ret)
> + return ret;
> +
> + bridge_funcs = (bridge_type == DRM_MODE_CONNECTOR_HDMIA) ?
> + &cdns_hdmi_bridge_funcs : &cdns_dp_bridge_funcs;
> +
> + mhdp = devm_drm_bridge_alloc(dev, struct cdns_mhdp8501_device,
> + bridge, bridge_funcs);
> + if (!mhdp)
> + return -ENOMEM;
> +
> + mhdp->dev = dev;
> + mhdp->bridge_type = bridge_type;
> + mhdp->lane_mapping = lane_mapping;
> +
> + mhdp->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
> + if (IS_ERR(mhdp->next_bridge))
> + return dev_err_probe(dev, PTR_ERR(mhdp->next_bridge),
> + "failed to get next bridge\n");
devm_drm_of_get_bridge() is there to either create a new panel_bridge
wrapping a panel or return an existing bridge. However based on the
cdns_mhdp8501_get_bridge_type() code it seems to me that you will always
have another bridge after this bridge. And so instead of
devm_drm_of_get_bridge() you should use of_drm_find_and_get_bridge(),
which handles bridge refcounting.
When switching to it, you additionally can use the drm_bridge::next_bridge
pointer instead of having your mhdp->next_bridge. This will simplify
putting the bridge reference. An example of its usage is in [0].
[0] https://lore.kernel.org/lkml/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-2-v2-4-8bad3ef90b9f@bootlin.com/
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
...
> +static int cdns_dp_bridge_attach(struct drm_bridge *bridge,
> + struct drm_encoder *encoder,
> + enum drm_bridge_attach_flags flags)
> +{
> + struct cdns_mhdp8501_device *mhdp = bridge->driver_private;
> + int ret;
> +
> + ret = drm_bridge_attach(encoder, mhdp->next_bridge, bridge,
> + flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> + if (ret < 0)
> + return ret;
> +
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> + dev_err(mhdp->dev, "do not support creating a drm_connector\n");
> + return -EINVAL;
> + }
Any good reason for doing this check after calling drm_bridge_attach()? It
looks to me that you should first check for valid arguments, and if they
pass take any actions.
Same below for the HDMI version.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: David Laight @ 2026-04-27 13:05 UTC (permalink / raw)
To: Ai Chao
Cc: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas, linux-fbdev, dri-devel, linux-kernel,
linux-arm-kernel, linux-geode, linux-parisc
In-Reply-To: <20260427090910.1940231-1-aichao@kylinos.cn>
On Mon, 27 Apr 2026 17:09:10 +0800
Ai Chao <aichao@kylinos.cn> wrote:
> Hello David and Helge
> ...
> > > > - strcpy(ivideo->myid, "SiS 730");
> > > > + strscpy(ivideo->myid, "SiS 730");
> > >
> > > The compiler knows at build time the length of myid, and the "SIS 730" string.
> > > Using strscpy() has no benefit here either. Contrary, the code generated
> > > because of using strscpy() is probably even larger.
> > > Don't replace such code with strscpy().
>
> > Both should get converted to a memcpy().
>
> > If you increase the literal to be too long I'm pretty sure you'll
> > get a compiler warning/error from strcpy().
> > OTOH strscpy() is more likely to truncate the string (I'd need to
> > check).
>
> > So leaving it as strcpy() is fine - and possibly even better.
> > The header files might get changed to error strcpy() unless the compiler
> > knows the source string has a constant length and the destination is
> > big enough - but that hasn't been done yet.
>
> struct sis_video_info {
> char myid[40];
> }
> I have rewritten the code:
> strcpy(ivideo->myid, "SiS 730-0123456789abcdefghijklmnopqrstuvwxyz0123456789");
> Used gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.3)
> There was no compiler warning or error.
> The strcpy copies the entire string into myid(causing a buffer overflow),
> whereas strscpy only copies 40 characters into myid according to its size.
It depends on what is in string.h and the enabled warnings.
Testing on 'godbolt' gives an error with both gcc and clang without any
special compilation options.
The linux kernel build errors strcpy() at line 799 of fortify-string.h.
strscpy() doesn't (and really shouldn't) generate an error since it is
expected to truncate overlong strings.
Since you should (at least) test compile any patches before sending them
(even trivial ones) you ought to have things setup to have checked what
happens in a kernel build.
Ideally you should also run the code.
This really means that strcpy() is better than strscpy() for copying fixed
length strings into arrays.
David
>
> Thanks,
> Ai Chao
>
^ permalink raw reply
* Re: [PATCH 2/4] firmware: samsung: acpm: Fix sequence number leak and infinite loop
From: Tudor Ambarus @ 2026-04-27 13:06 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, stable
In-Reply-To: <20260423-acpm-fixes-sashiko-reports-v1-2-2217b790925e@linaro.org>
Hi!
I need to drop this patch, as it can cause silent data corruption.
Will send a v2 dropping this patch and adding a few more fixes for bugs
identified by sashiko.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH v2] arm64/irqflags: __always_inline the arch_local_irq_*() helpers
From: Mark Rutland @ 2026-04-27 13:08 UTC (permalink / raw)
To: Catalin Marinas
Cc: Breno Leitao, Will Deacon, leo.bras, leo.yan, linux-arm-kernel,
linux-kernel, palmer, paulmck, puranjay, usama.arif, rmikey,
kernel-team
In-Reply-To: <ae9V6jrYEwa6Uwqn@arm.com>
On Mon, Apr 27, 2026 at 01:26:18PM +0100, Catalin Marinas wrote:
> On Tue, Apr 21, 2026 at 08:58:57AM -0700, Breno Leitao wrote:
> > Force-inline all of the arch_local_irq_*() wrappers so they cannot be
> > emitted out-of-line:
> >
> > - arch_local_irq_enable()
> > - arch_local_irq_disable()
> > - arch_local_save_flags()
> > - arch_irqs_disabled_flags()
> > - arch_irqs_disabled()
> > - arch_local_irq_save()
> > - arch_local_irq_restore()
>
> I'll queue this, thanks!
>
> I think we should also do local_daif_{mask,restore,inherit} as they seem
> to be called from noinstr locations in entry-common.c.
I agree we probably should mark those as __always_inline, but I beleive
they're safe as-is. For their current usage in entry-common.c they're
only called between between enter_from_*_mode() and exit_to_*_mode(), in
a period where instrumentation is safe.
Mark.
^ permalink raw reply
* Re: [PATCH] pmdomain: core: Fix detach procedure for virtual devices in genpd
From: Ulf Hansson @ 2026-04-27 13:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, linux-pm, Frank Binns, Matt Coster, Marek Vasut,
Rafael J . Wysocki, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <CAMuHMdVr-dzRUruue0XEky_6fCt+v3AHp3G+Zv_N7S2_TpC7yg@mail.gmail.com>
On Fri, 17 Apr 2026 at 20:36, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Ulf,
>
> On Fri, 17 Apr 2026 at 13:13, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(),
> > genpd calls pm_runtime_enable() for the corresponding virtual device that
> > it registers. While this avoids boilerplate code in drivers, there is no
> > corresponding call to pm_runtime_disable() in genpd_dev_pm_detach().
> >
> > This means these virtual devices are typically detached from its genpd,
> > while runtime PM remains enabled for them, which is not how things are
> > designed to work. In worst cases it may lead to critical errors, like a
> > NULL pointer dereference bug in genpd_runtime_suspend(), which was recently
> > reported. For another case, we may end up keeping an unnecessary vote for a
> > performance state for the device.
> >
> > To fix these problems, let's add this missing call to pm_runtime_disable()
> > in genpd_dev_pm_detach().
> >
> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Fixes: 3c095f32a92b ("PM / Domains: Add support for multi PM domains per device to genpd")
> > Cc: stable@vger.kernel.org
> > Closes: https://lore.kernel.org/all/CAMuHMdWapT40hV3c+CSBqFOW05aWcV1a6v_NiJYgoYi0i9_PDQ@mail.gmail.com/
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>
> Thanks for your patch!
>
> This survived more than 160000 bind/unbind attempts[1] on R-Car M3-W
> and M3-N, so
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks for testing! I have queued the patch for fixes.
>
> > --- a/drivers/pmdomain/core.c
> > +++ b/drivers/pmdomain/core.c
> > @@ -3089,6 +3089,7 @@ static const struct bus_type genpd_bus_type = {
> > static void genpd_dev_pm_detach(struct device *dev, bool power_off)
> > {
> > struct generic_pm_domain *pd;
> > + bool is_virt_dev;
> > unsigned int i;
> > int ret = 0;
> >
> > @@ -3098,6 +3099,13 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
> >
> > dev_dbg(dev, "removing from PM domain %s\n", pd->name);
> >
> > + /* Check if the device was created by genpd at attach. */
> > + is_virt_dev = dev->bus == &genpd_bus_type;
> > +
> > + /* Disable runtime PM if we enabled it at attach. */
> > + if (is_virt_dev)
> > + pm_runtime_disable(dev);
> > +
> > /* Drop the default performance state */
> > if (dev_gpd_data(dev)->default_pstate) {
> > dev_pm_genpd_set_performance_state(dev, 0);
> > @@ -3123,7 +3131,7 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
>
> Above, out of context, there is an error return.
> Should we call pm_runtime_enable() again, to keep the reference count
> balanced? Or can we just ignore this? It's probably futile anyway.
Good point. I considered it, but I think it's safer to keep runtime PM
disabled, if we encounter an error.
If we end up converting genpd_dev_pm_detach() to return an int instead
of void, then we could revisit this.
>
> > genpd_queue_power_off_work(pd);
> >
> > /* Unregister the device if it was created by genpd. */
> > - if (dev->bus == &genpd_bus_type)
> > + if (is_virt_dev)
> > device_unregister(dev);
> > }
> >
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] pmdomain: mediatek: fix use-after-free in scpsys_get_bus_protection_legacy()
From: Ulf Hansson @ 2026-04-27 13:13 UTC (permalink / raw)
To: Wentao Liang
Cc: Matthias Brugger, AngeloGioacchino Del Regno, nfraprado,
Macpaul Lin, Adam Ford, Chen-Yu Tsai, linux-pm, linux-kernel,
linux-arm-kernel, linux-mediatek, stable
In-Reply-To: <20260408141121.386522-1-vulab@iscas.ac.cn>
On Wed, 8 Apr 2026 at 16:11, Wentao Liang <vulab@iscas.ac.cn> wrote:
>
> In scpsys_get_bus_protection_legacy(), of_find_node_with_property()
> returns a device node with its reference count incremented. The function
> then calls of_node_put(node) before checking whether
> syscon_regmap_lookup_by_phandle() returns an error. If an error occurs,
> dev_err_probe() dereferences the node pointer to print diagnostic
> information, but the node memory may have already been freed due to the
> earlier of_node_put(), leading to a use-after-free vulnerability.
>
> Fix this by moving the of_node_put() call after the error check, ensuring
> the node is still valid when accessed in the error path.
>
> Fixes: c29345fa5f66 ("pmdomain: mediatek: Refactor bus protection regmaps retrieval")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Applied for fixes, thanks!
Kind regards
Uffe
> ---
> drivers/pmdomain/mediatek/mtk-pm-domains.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
> index e2800aa1bc59..d3b36f32417c 100644
> --- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
> +++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
> @@ -993,6 +993,7 @@ static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *s
> struct device_node *node, *smi_np;
> int num_regmaps = 0, i, j;
> struct regmap *regmap[3];
> + int ret = 0;
>
> /*
> * Legacy code retrieves a maximum of three bus protection handles:
> @@ -1043,11 +1044,14 @@ static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *s
> if (node) {
> regmap[2] = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg-nao");
> num_regmaps++;
> - of_node_put(node);
> - if (IS_ERR(regmap[2]))
> - return dev_err_probe(dev, PTR_ERR(regmap[2]),
> + if (IS_ERR(regmap[2])) {
> + ret = dev_err_probe(dev, PTR_ERR(regmap[2]),
> "%pOF: failed to get infracfg regmap\n",
> node);
> + of_node_put(node);
> + return ret;
> + }
> + of_node_put(node);
> } else {
> regmap[2] = NULL;
> }
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2] arm64: smp: Do not mark secondary CPUs possible under nosmp
From: Catalin Marinas @ 2026-04-27 13:20 UTC (permalink / raw)
To: Pengjie Zhang
Cc: will, maz, timothy.hayes, lpieralisi, mrigendra.chaubey, arnd,
linux-arm-kernel, linux-kernel, zhanjie9, zhenglifeng1, lihuisong,
yubowen8, linhongye, linuxarm, wangzhi12
In-Reply-To: <20260423134654.4178271-1-zhangpengjie2@huawei.com>
On Thu, Apr 23, 2026 at 09:46:54PM +0800, Pengjie Zhang wrote:
> Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
>
> However, arm64 still enumerates firmware-described CPUs during SMP
> initialization, which can leave secondary CPUs visible to
> for_each_possible_cpu() users even though they never reach the
> bringup path in this configuration.
>
> This is not just a cosmetic mask mismatch: code iterating over
> possible CPUs may observe secondary CPU per-CPU state that is never
> fully initialized under nosmp.
I'm fine with the patch in principle but I fail to see why it is not
mostly cosmetic. If we have possible & !present CPUs (there's another
thread around cpuhp_smt_enable() to allow this combination on arm64),
get_cpu_device() would return NULL and the core code is supposed to
handle this. What other per-CPU state should be initialised for a
possible CPU but it is not without this patch?
--
Catalin
^ permalink raw reply
* Re: [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()
From: Gary Guo @ 2026-04-27 13:29 UTC (permalink / raw)
To: Shashank Balaji, Suzuki K Poulose, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Richard Cochran, Jonathan Corbet, Shuah Khan, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Mike Leach,
Leo Yan
Cc: Rahul Bukte, linux-kernel, coresight, linux-arm-kernel,
driver-core, rust-for-linux, linux-doc, Daniel Palmer, Tim Bird,
linux-modules
In-Reply-To: <20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com>
On Mon Apr 27, 2026 at 3:41 AM BST, Shashank Balaji wrote:
> module_kset is initialized in param_sysfs_init(), a subsys_initcall. A number
> of platform drivers register themselves prior to subsys_initcalls
> (tegra194_cbb_driver registers in a pure_initcall, for example). With an
> upcoming patch ("driver core: platform: set mod_name in driver registration")
> that sets their mod_name in struct device_driver, lookup_or_create_module_kobject()
> will be called for those drivers, which calls kset_find_obj(module_kset, mod_name).
> This causes a null deref because module_kset isn't alive yet.
>
> Fix this by initializing module_kset in do_basic_setup() before do_initcalls().
> Modernize the pr_warn while we're at it.
>
> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Suggested-by: Gary Guo <gary@garyguo.net>
I didn't suggest this change :)
I suggested `pure_initcall`, which is just a one line change.
diff --git a/kernel/params.c b/kernel/params.c
index 74d620bc2521..ac088d4b09a9 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -957,7 +957,7 @@ static int __init param_sysfs_init(void)
return 0;
}
-subsys_initcall(param_sysfs_init);
+pure_initcall(param_sysfs_init);
/*
* param_sysfs_builtin_init - add sysfs version and parameter
pure_initcall is level 0 so it happens before all other init calls. Does it not
work?
Best,
Gary
> Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> ---
> include/linux/module.h | 4 ++++
> init/main.c | 1 +
> kernel/params.c | 21 +++++++++------------
> 3 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 7566815fabbe..6478596e8f9f 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -886,6 +886,10 @@ static inline void module_for_each_mod(int(*func)(struct module *mod, void *data
> #ifdef CONFIG_SYSFS
> extern struct kset *module_kset;
> extern const struct kobj_type module_ktype;
> +
> +void param_sysfs_init(void);
> +#else
> +static inline void param_sysfs_init(void) {}
> #endif /* CONFIG_SYSFS */
>
> #define symbol_request(x) try_then_request_module(symbol_get(x), "symbol:" #x)
> diff --git a/init/main.c b/init/main.c
> index 96f93bb06c49..01552c6b62ff 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1486,6 +1486,7 @@ static void __init do_basic_setup(void)
> ksysfs_init();
> driver_init();
> init_irq_proc();
> + param_sysfs_init();
> do_ctors();
> do_initcalls();
> }
> diff --git a/kernel/params.c b/kernel/params.c
> index 74d620bc2521..d1e3934fb3a7 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -942,22 +942,19 @@ const struct kobj_type module_ktype = {
> /*
> * param_sysfs_init - create "module" kset
> *
> - * This must be done before the initramfs is unpacked and
> - * request_module() thus becomes possible, because otherwise the
> - * module load would fail in mod_sysfs_init.
> + * Must run before:
> + * - do_initcalls(): some drivers register during initcalls and rely on
> + * module_kset existing for their sysfs module symlink.
> + * - rootfs_initcall (initramfs unpack): request_module() becomes possible.
> + * But if module_kset is null, module load would fail in mod_sysfs_init(),
> + * causing request_module() to fail.
> */
> -static int __init param_sysfs_init(void)
> +void __init param_sysfs_init(void)
> {
> module_kset = kset_create_and_add("module", &module_uevent_ops, NULL);
> - if (!module_kset) {
> - printk(KERN_WARNING "%s (%d): error creating kset\n",
> - __FILE__, __LINE__);
> - return -ENOMEM;
> - }
> -
> - return 0;
> + if (!module_kset)
> + pr_warn("Error creating module kset\n");
> }
> -subsys_initcall(param_sysfs_init);
>
> /*
> * param_sysfs_builtin_init - add sysfs version and parameter
^ permalink raw reply related
* Re: [PATCH v4 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: Jason Gunthorpe @ 2026-04-27 13:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: Aneesh Kumar K.V (Arm), linux-kernel, iommu, linux-coco,
linux-arm-kernel, kvmarm, Catalin Marinas, Marek Szyprowski,
Robin Murphy, Steven Price, Suzuki K Poulose, Thomas Gleixner,
Will Deacon
In-Reply-To: <86zf2ozrb8.wl-maz@kernel.org>
On Mon, Apr 27, 2026 at 10:27:23AM +0100, Marc Zyngier wrote:
> > With CCA, although Stage-2 mappings managed by the RMM still operate at a
> > 4K granularity, shared pages must nonetheless be aligned to the
> > host-managed page size and sized as whole host pages to avoid the issues
> > described above.
>
> I thought that was being fixed, and that there was now a strong
> guarantee that RMM and host are aligned on the page size.
Yes, the RMM and host are supposed to be aligned on page size, but
this means the guest now has this mem_decrypt_granule_size() value
that it has to deal with, and it won't always be 4k.
The spec introduction of RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT is
fixing a defect in earlier RMM specs that just assumed it was always
4k.
AFAIK this is unfixable in ARM's architecture..
> Even more, S2 is totally irrelevant here. The only thing that
> matters is the host page size vs the guest page size. Nothing else.
Yeah
Or rather more specifically the RMM now has
RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT which says exactly the minimum
supported shared/private conversion granule and the VM must obey it.
It doesn't actually matter *WHY* the RMM chooses a size, whatever it
is the guest must follow it.
It would probably be helpful to focus on this a little more, as really
this series is implementing a new RMM feature. It is good to explain
why this feature was added to RMM in the cover letter, but I would
focus the patch commentary on explaining the process of introducing
mem_decrypt_granule_size()
Jason
^ permalink raw reply
* Re: [PATCH RFC] arm64/scs: Fix potential sign extension issue of advance_loc4
From: Catalin Marinas @ 2026-04-27 13:39 UTC (permalink / raw)
To: linux-arm-kernel, Wentao Guan; +Cc: Will Deacon, hello, linux-kernel
In-Reply-To: <20260413095459.2470584-1-guanwentao@uniontech.com>
On Mon, 13 Apr 2026 17:54:59 +0800, Wentao Guan wrote:
> The expression (*opcode++ << 24) and exp * code_alignment_factor
> may overflow signed int and becomes negative.
>
> Fix this by casting each byte to u64 before shifting. Also fix
> the misaligned break statement while we are here.
>
> Example of the result can be seen here:
> Link: https://godbolt.org/z/zhY8d3595
>
> [...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64/scs: Fix potential sign extension issue of advance_loc4
https://git.kernel.org/arm64/c/4023b7424ecd
^ permalink raw reply
* Re: [PATCH] ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
From: Catalin Marinas @ 2026-04-27 13:44 UTC (permalink / raw)
To: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Will Deacon,
Rafael J. Wysocki, Len Brown, Huisong Li, Breno Leitao
Cc: Rafael J. Wysocki, linux-acpi, linux-arm-kernel, linux-kernel,
pjaroszynski, rmikey, kernel-team, stable
In-Reply-To: <20260420-ffh-v1-1-6b4c10fec442@debian.org>
On Mon, 20 Apr 2026 02:27:13 -0700, Breno Leitao wrote:
> Commit cac173bea57d ("ACPI: processor: idle: Rework the handling of
> acpi_processor_ffh_lpi_probe()") moved the acpi_processor_ffh_lpi_probe()
> call from acpi_processor_setup_cpuidle_dev(), where its return value was
> ignored, to acpi_processor_get_power_info(), where it is now treated as
> a hard failure. As a result, platforms where psci_acpi_cpu_init_idle()
> returned -ENODEV stopped registering any cpuidle states, forcing CPUs to
> busy-poll when idle.
>
> [...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
https://git.kernel.org/arm64/c/3ea4415015d6
^ 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