* [PATCH] spi: sun6i: Set SPI mode in prepare_message
From: Kevin Mehall @ 2026-04-20 16:46 UTC (permalink / raw)
To: Mark Brown, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Mirko Vogt, Ralf Schlatterbeck, linux-spi, linux-arm-kernel,
linux-sunxi, linux-kernel
Cc: Kevin Mehall
With a GPIO chip select, CS is asserted before entering transfer_one.
The spi-sun6i driver previously configured the SPI mode (including clock
polarity) and enabled the bus in transfer_one, which can cause an
extraneous SCK transition with CS asserted, corrupting the transferred
data.
This patch moves the SPI mode configuration and bus enable to the
spi_prepare_message callback, ensuring that SCK is driven to the correct
level prior to asserting CS.
A previous fix for a related issue (0d7993b234c9f) was incomplete in that
it only avoided driving SCK at the wrong level when resuming from
autosuspend, but didn't help if switching CPOL modes between chip selects
while active, or if SCK floats to the opposite level when suspended.
Fixes: 0d7993b234c9 ("spi: spi-sun6i: Fix chipselect/clock bug")
Signed-off-by: Kevin Mehall <km@kevinmehall.net>
---
drivers/spi/spi-sun6i.c | 76 +++++++++++++++++++++++++----------------
1 file changed, 47 insertions(+), 29 deletions(-)
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 240e46f84f7b..85395f1385bc 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -201,6 +201,50 @@ static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
return SUN6I_MAX_XFER_SIZE - 1;
}
+static int sun6i_spi_prepare_message(struct spi_controller *ctlr,
+ struct spi_message *msg)
+{
+ struct sun6i_spi *sspi = spi_controller_get_devdata(ctlr);
+ struct spi_device *spi = msg->spi;
+ u32 reg;
+
+ /*
+ * Set up the transfer control register: Chip Select,
+ * polarities, etc.
+ */
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
+ if (spi->mode & SPI_CPOL)
+ reg |= SUN6I_TFR_CTL_CPOL;
+ else
+ reg &= ~SUN6I_TFR_CTL_CPOL;
+
+ if (spi->mode & SPI_CPHA)
+ reg |= SUN6I_TFR_CTL_CPHA;
+ else
+ reg &= ~SUN6I_TFR_CTL_CPHA;
+
+ if (spi->mode & SPI_LSB_FIRST)
+ reg |= SUN6I_TFR_CTL_FBS;
+ else
+ reg &= ~SUN6I_TFR_CTL_FBS;
+
+ /* We want to control the chip select manually */
+ reg |= SUN6I_TFR_CTL_CS_MANUAL;
+
+ sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+
+ /*
+ * Now that the clock polarity is configured, enable the bus if the
+ * controller was previously suspended.
+ */
+ reg = sun6i_spi_read(sspi, SUN6I_GBL_CTL_REG);
+ reg |= SUN6I_GBL_CTL_BUS_ENABLE;
+ sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG, reg);
+
+ return 0;
+}
+
static void sun6i_spi_dma_rx_cb(void *param)
{
struct sun6i_spi *sspi = param;
@@ -332,31 +376,12 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG, reg);
- /*
- * Setup the transfer control register: Chip Select,
- * polarities, etc.
- */
- reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
-
- if (spi->mode & SPI_CPOL)
- reg |= SUN6I_TFR_CTL_CPOL;
- else
- reg &= ~SUN6I_TFR_CTL_CPOL;
-
- if (spi->mode & SPI_CPHA)
- reg |= SUN6I_TFR_CTL_CPHA;
- else
- reg &= ~SUN6I_TFR_CTL_CPHA;
-
- if (spi->mode & SPI_LSB_FIRST)
- reg |= SUN6I_TFR_CTL_FBS;
- else
- reg &= ~SUN6I_TFR_CTL_FBS;
-
/*
* If it's a TX only transfer, we don't want to fill the RX
* FIFO with bogus data
*/
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
if (sspi->rx_buf) {
reg &= ~SUN6I_TFR_CTL_DHB;
rx_len = tfr->len;
@@ -364,9 +389,6 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
reg |= SUN6I_TFR_CTL_DHB;
}
- /* We want to control the chip select manually */
- reg |= SUN6I_TFR_CTL_CS_MANUAL;
-
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
if (sspi->cfg->has_clk_ctl) {
@@ -428,11 +450,6 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
}
- /* Finally enable the bus - doing so before might raise SCK to HIGH */
- reg = sun6i_spi_read(sspi, SUN6I_GBL_CTL_REG);
- reg |= SUN6I_GBL_CTL_BUS_ENABLE;
- sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG, reg);
-
/* Setup the transfer now... */
if (sspi->tx_buf) {
tx_len = tfr->len;
@@ -667,6 +684,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
host->max_speed_hz = 100 * 1000 * 1000;
host->min_speed_hz = 3 * 1000;
host->use_gpio_descriptors = true;
+ host->prepare_message = sun6i_spi_prepare_message;
host->set_cs = sun6i_spi_set_cs;
host->transfer_one = sun6i_spi_transfer_one;
host->num_chipselect = 4;
--
2.53.0
^ permalink raw reply related
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Sudeep Holla @ 2026-04-20 16:50 UTC (permalink / raw)
To: Sebastian Ene, Yeoreum Yun
Cc: Marc Zyngier, Sudeep Holla, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <aeY2M3v97c00JjFe@google.com>
On Mon, Apr 20, 2026 at 02:20:35PM +0000, Sebastian Ene wrote:
> On Mon, Apr 20, 2026 at 01:46:47PM +0100, Marc Zyngier wrote:
> > On Mon, 20 Apr 2026 13:32:32 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > On Fri, Apr 17, 2026 at 06:57:59PM +0100, Yeoreum Yun wrote:
> > >
> > > Hello Yeoreum,
> > >
> > >
> > > > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > > > Otherwise, pKVM cannot negotiate the FF-A version or
> > > > obtain RX/TX buffer information, leading to failures in FF-A calls.
> > >
> > > At the moment this already happens after you move back ffa_init() to
> > > device_initcall().
> >
> > But relying on this sort of ordering is just making things more
> > fragile.
> >
>
> Thanks for letting me know. Since this is not a solid construct we will have
> to change the driver init code to come after pKVM in this case.
>
> > >
> > > >
> > > > During FF-A driver initialization, check whether pKVM has been initialized.
> > > > If not, defer probing of the FF-A driver.
> > > >
> > >
> > > I don't think you need to add this dependency. pKVM is
> > > installed through KVM's module_init() which ends up calling hyp_ffa_init() to
> > > do the proxy initialization. The ARM-FFA driver comes after it (since
> > > pKVM is arch specific code). We don't have to call finalize_pkvm(..) to
> > > be able to handle smc(FF-A) calls in the hyp-proxy.
> >
> > You do. Without the finalisation, SMCs are not trapped by EL2.
> >
> > And even if it did, relying on such hack is just wrong.
> >
>
> That makes it an even stronger argument to move the driver init at a
> later stage. I was relying on this to trap early ff-a when the
> ARM FF-A driver was used.
>
Indeed, if both are at `device_initcall` level, then correct behaviour is
effectively left to link order. That makes the outcome depend on build-time
ordering rather than on an explicit and well-defined dependency, which is
quite fragile and difficult to justify as a reliable fix.
That is precisely the kind of arrangement I am worried about here. Even if it
happens to work today, it is not guaranteed in any robust sense and can easily
break as the code evolves or as unrelated changes affect the link order. In
other words, it may appear functional, but it still lacks a proper dependency
model and remains vulnerable to subtle regressions.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v6 3/3] dts: s32g: Add GPR syscon region
From: Dan Carpenter @ 2026-04-20 16:45 UTC (permalink / raw)
To: Jared Kangas
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
NXP S32 Linux Team, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, imx,
devicetree, linux-kernel, linaro-s32, netdev
In-Reply-To: <aeZOcCOgMy2g9wqp@rh-jkangas-kernel>
On Mon, Apr 20, 2026 at 09:04:00AM -0700, Jared Kangas wrote:
> Fixing Dan's address based on mailmap update, sorry for the noise.
>
> On Fri, Apr 17, 2026 at 02:36:25PM -0700, Jared Kangas wrote:
> > Hi Dan,
> >
> > On Fri, Jan 30, 2026 at 04:19:52PM +0300, Dan Carpenter wrote:
> > > Add the GPR syscon region for the s32 chipset.
> > >
> > > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> > > ---
> > >
> > > [snip]
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > > index e314f3c7d61d..be03db737384 100644
> > > --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > > @@ -383,6 +383,11 @@ usdhc0-200mhz-grp4 {
> > > };
> > > };
> > >
> > > + gpr: syscon@4007c000 {
> > > + compatible = "nxp,s32g3-gpr", "syscon";
> > > + reg = <0x4007c000 0x3000>;
> > > + };
> > > +
> > > ocotp: nvmem@400a4000 {
> > > compatible = "nxp,s32g3-ocotp", "nxp,s32g2-ocotp";
> > > reg = <0x400a4000 0x400>;
> > > @@ -808,6 +813,7 @@ gmac0: ethernet@4033c000 {
> > > compatible = "nxp,s32g2-dwmac";
> > > reg = <0x4033c000 0x2000>, /* gmac IP */
> > > <0x4007c004 0x4>; /* GMAC_0_CTRL_STS */
> > > + nxp,phy-sel = <&gpr 0x4>;
> > > interrupt-parent = <&gic>;
> > > interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
> > > interrupt-names = "macirq";
> >
> > I gave this a test on an S32G-VNP-RDB3 and didn't see any issues on the
> > dwmac-s32 side, but this appears to trigger a panic when reading the new
> > debugfs regmap/*/registers file for the syscon node:
> >
> > # grep 4007c000 /proc/vmallocinfo
> > 0xffff800083da8000-0xffff800083dac000 16384 ioremap_prot+0x74/0xe0 phys=0x000000004007c000 ioremap
> > # cat /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers
> > Internal error: synchronous external abort: 0000000096000210 [#1] SMP
> > [...]
> > CPU: 0 UID: 0 PID: 4344 Comm: cat Tainted: G M E X ------ --- 6.12.0+ #226 PREEMPT_RT
> > Tainted: [M]=MACHINE_CHECK, [E]=UNSIGNED_MODULE, [X]=AUX
> > [...]
> > pc : regmap_mmio_read32le+0x44/0xa0
> > lr : regmap_mmio_read32le+0x44/0xa0
> > [...]
> > x23: ffff00080c080000 x22: ffff000802ac4c00 x21: ffff800087b13c9c
> > x20: ffff800080a46494 x19: ffff800083da810c x18: 0000000000000004
> > [...]
> > x5 : ffff800080a46448 x4 : ffff800083da8000 x3 : ffff800080a46494
> > x2 : ffff800080a47230 x1 : ffff800083da810c x0 : 0000000000000020
> > Call trace:
> > regmap_mmio_read32le+0x44/0xa0 (P)
> > regmap_mmio_read+0x4c/0x80
> > [...]
> > Code: 52800400 8b214093 aa1303e1 97f4caf0 (b9400275)
> > ---[ end trace 0000000000000000 ]---
> > Kernel panic - not syncing: synchronous external abort: Fatal exception
> >
> > Running this through decodecode gives:
> >
> > All code
> > ========
> > 0: 52800400 mov w0, #0x20 // #32
> > 4: 8b214093 add x19, x4, w1, uxtw
> > 8: aa1303e1 mov x1, x19
> > c: 97f4caf0 bl 0xffffffffffd32bcc
> > 10:* b9400275 ldr w21, [x19] <-- trapping instruction
> >
> > Code starting with the faulting instruction
> > ===========================================
> > 0: b9400275 ldr w21, [x19]
> >
> > x19's offset from the base address in /proc/vmallocinfo is 0x10c, which
> > points to a bad read at physical address 0x4007c10c; I also confirmed
> > that the preceding memory reads back without issues:
Oh, ugh... I didn't realize that this wasn't merged. I don't have a
way to test this any more. The simplest fix would be to do change the
0x3000 to 0x100. The GPR63 register is at 0xFC.
reg = <0x4007c000 0x100>;
That's probably the best fix as well. The later register areas would
be their own syscons.
regards,
dan carpenter
^ permalink raw reply
* [PATCH v4 3/3] hwrng: mtk - add support for hw access via SMCC
From: Daniel Golle @ 2026-04-20 16:35 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, Daniel Golle, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <912fe579eccf577f3064b69d6c945e2c9087cab8.1776702734.git.daniel@makrotopia.org>
Newer versions of ARM TrustedFirmware-A on MediaTek's ARMv8 SoCs no longer
allow accessing the TRNG from outside of the trusted firmware.
Instead, a vendor-defined custom Secure Monitor Call can be used to
acquire random bytes.
Add support for newer SoCs (MT7981, MT7987, MT7988).
As TF-A for the MT7986 may either follow the old or the new
convention, the best bet is to test if firmware blocks direct access
to the hwrng and if so, expect the SMCC interface to be usable.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v4: unchanged
v3: unchanged
v2: unchanged
drivers/char/hw_random/mtk-rng.c | 127 ++++++++++++++++++++++++++-----
1 file changed, 106 insertions(+), 21 deletions(-)
diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
index 5808d09d12c45..8f5856b59ad66 100644
--- a/drivers/char/hw_random/mtk-rng.c
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -3,6 +3,7 @@
* Driver for Mediatek Hardware Random Number Generator
*
* Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ * Copyright (C) 2026 Daniel Golle <daniel@makrotopia.org>
*/
#define MTK_RNG_DEV KBUILD_MODNAME
@@ -17,6 +18,8 @@
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
+#include <linux/arm-smccc.h>
+#include <linux/soc/mediatek/mtk_sip_svc.h>
/* Runtime PM autosuspend timeout: */
#define RNG_AUTOSUSPEND_TIMEOUT 100
@@ -30,6 +33,11 @@
#define RNG_DATA 0x08
+/* Driver feature flags */
+#define MTK_RNG_SMC BIT(0)
+
+#define MTK_SIP_KERNEL_GET_RND MTK_SIP_SMC_CMD(0x550)
+
#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
struct mtk_rng {
@@ -37,6 +45,7 @@ struct mtk_rng {
struct clk *clk;
struct hwrng rng;
struct device *dev;
+ unsigned long flags;
};
static int mtk_rng_init(struct hwrng *rng)
@@ -103,6 +112,56 @@ static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
return retval || !wait ? retval : -EIO;
}
+static int mtk_rng_read_smc(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ struct arm_smccc_res res;
+ int retval = 0;
+
+ while (max >= sizeof(u32)) {
+ arm_smccc_smc(MTK_SIP_KERNEL_GET_RND, 0, 0, 0, 0, 0, 0, 0,
+ &res);
+ if (res.a0)
+ break;
+
+ *(u32 *)buf = res.a1;
+ retval += sizeof(u32);
+ buf += sizeof(u32);
+ max -= sizeof(u32);
+ }
+
+ return retval || !wait ? retval : -EIO;
+}
+
+static bool mtk_rng_hw_accessible(struct mtk_rng *priv)
+{
+ u32 val;
+ int err;
+
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ return false;
+
+ val = readl(priv->base + RNG_CTRL);
+ val |= RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ val = readl(priv->base + RNG_CTRL);
+
+ if (val & RNG_EN) {
+ /* HW is accessible, clean up: disable RNG and clock */
+ writel(val & ~RNG_EN, priv->base + RNG_CTRL);
+ clk_disable_unprepare(priv->clk);
+ return true;
+ }
+
+ /*
+ * If TF-A blocks direct access, the register reads back as 0.
+ * Leave the clock enabled as TF-A needs it.
+ */
+ return false;
+}
+
static int mtk_rng_probe(struct platform_device *pdev)
{
int ret;
@@ -114,23 +173,42 @@ static int mtk_rng_probe(struct platform_device *pdev)
priv->dev = &pdev->dev;
priv->rng.name = pdev->name;
-#ifndef CONFIG_PM
- priv->rng.init = mtk_rng_init;
- priv->rng.cleanup = mtk_rng_cleanup;
-#endif
- priv->rng.read = mtk_rng_read;
priv->rng.quality = 900;
-
- priv->clk = devm_clk_get(&pdev->dev, "rng");
- if (IS_ERR(priv->clk)) {
- ret = PTR_ERR(priv->clk);
- dev_err(&pdev->dev, "no clock for device: %d\n", ret);
- return ret;
+ priv->flags = (unsigned long)device_get_match_data(&pdev->dev);
+
+ if (!(priv->flags & MTK_RNG_SMC)) {
+ priv->clk = devm_clk_get(&pdev->dev, "rng");
+ if (IS_ERR(priv->clk)) {
+ ret = PTR_ERR(priv->clk);
+ dev_err(&pdev->dev, "no clock for device: %d\n", ret);
+ return ret;
+ }
+
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ if (IS_ENABLED(CONFIG_HAVE_ARM_SMCCC) &&
+ of_device_is_compatible(pdev->dev.of_node,
+ "mediatek,mt7986-rng") &&
+ !mtk_rng_hw_accessible(priv)) {
+ priv->flags |= MTK_RNG_SMC;
+ dev_info(&pdev->dev,
+ "HW RNG not MMIO accessible, using SMC\n");
+ }
}
- priv->base = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(priv->base))
- return PTR_ERR(priv->base);
+ if (priv->flags & MTK_RNG_SMC) {
+ if (!IS_ENABLED(CONFIG_HAVE_ARM_SMCCC))
+ return -ENODEV;
+ priv->rng.read = mtk_rng_read_smc;
+ } else {
+#ifndef CONFIG_PM
+ priv->rng.init = mtk_rng_init;
+ priv->rng.cleanup = mtk_rng_cleanup;
+#endif
+ priv->rng.read = mtk_rng_read;
+ }
ret = devm_hwrng_register(&pdev->dev, &priv->rng);
if (ret) {
@@ -139,12 +217,15 @@ static int mtk_rng_probe(struct platform_device *pdev)
return ret;
}
- dev_set_drvdata(&pdev->dev, priv);
- pm_runtime_set_autosuspend_delay(&pdev->dev, RNG_AUTOSUSPEND_TIMEOUT);
- pm_runtime_use_autosuspend(&pdev->dev);
- ret = devm_pm_runtime_enable(&pdev->dev);
- if (ret)
- return ret;
+ if (!(priv->flags & MTK_RNG_SMC)) {
+ dev_set_drvdata(&pdev->dev, priv);
+ pm_runtime_set_autosuspend_delay(&pdev->dev,
+ RNG_AUTOSUSPEND_TIMEOUT);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ ret = devm_pm_runtime_enable(&pdev->dev);
+ if (ret)
+ return ret;
+ }
dev_info(&pdev->dev, "registered RNG driver\n");
@@ -181,8 +262,11 @@ static const struct dev_pm_ops mtk_rng_pm_ops = {
#endif /* CONFIG_PM */
static const struct of_device_id mtk_rng_match[] = {
- { .compatible = "mediatek,mt7986-rng" },
{ .compatible = "mediatek,mt7623-rng" },
+ { .compatible = "mediatek,mt7981-rng", .data = (void *)MTK_RNG_SMC },
+ { .compatible = "mediatek,mt7986-rng" },
+ { .compatible = "mediatek,mt7987-rng", .data = (void *)MTK_RNG_SMC },
+ { .compatible = "mediatek,mt7988-rng", .data = (void *)MTK_RNG_SMC },
{},
};
MODULE_DEVICE_TABLE(of, mtk_rng_match);
@@ -200,4 +284,5 @@ module_platform_driver(mtk_rng_driver);
MODULE_DESCRIPTION("Mediatek Random Number Generator Driver");
MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/3] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-20 16:35 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, Daniel Golle, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <912fe579eccf577f3064b69d6c945e2c9087cab8.1776702734.git.daniel@makrotopia.org>
Add compatible strings for MediaTek SoCs where the hardware random number
generator is accessed via a vendor-defined Secure Monitor Call (SMC)
rather than direct MMIO register access:
- mediatek,mt7981-rng
- mediatek,mt7987-rng
- mediatek,mt7988-rng
These variants require no reg, clocks, or clock-names properties since
the RNG hardware is managed by ARM Trusted Firmware-A.
Relax the $nodename pattern to also allow 'rng' in addition to the
existing 'rng@...' pattern.
Add a second example showing the minimal SMC variant binding.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v4:
* fix indentation in example
v3:
* drop not: in compatible conditional
* add reg/clocks/clock-names: false for mt7981-rng
* add else: requiring reg/clocks/clock-names for others
v2: express compatibilities with fallback
.../devicetree/bindings/rng/mtk-rng.yaml | 32 ++++++++++++++++---
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
index 8f2f4c32a0cfc..38e67861b88fa 100644
--- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
@@ -11,12 +11,13 @@ maintainers:
properties:
$nodename:
- pattern: "^rng@[0-9a-f]+$"
+ pattern: "^rng(@[0-9a-f]+)?$"
compatible:
oneOf:
- enum:
- mediatek,mt7623-rng
+ - mediatek,mt7981-rng
- items:
- enum:
- mediatek,mt7622-rng
@@ -25,6 +26,11 @@ properties:
- mediatek,mt8365-rng
- mediatek,mt8516-rng
- const: mediatek,mt7623-rng
+ - items:
+ - enum:
+ - mediatek,mt7987-rng
+ - mediatek,mt7988-rng
+ - const: mediatek,mt7981-rng
reg:
maxItems: 1
@@ -38,9 +44,23 @@ properties:
required:
- compatible
- - reg
- - clocks
- - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7981-rng
+ then:
+ properties:
+ reg: false
+ clocks: false
+ clock-names: false
+ else:
+ required:
+ - reg
+ - clocks
+ - clock-names
additionalProperties: false
@@ -54,3 +74,7 @@ examples:
clocks = <&infracfg CLK_INFRA_TRNG>;
clock-names = "rng";
};
+ - |
+ rng {
+ compatible = "mediatek,mt7981-rng";
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/3] dt-bindings: rng: mtk-rng: fix style problems in example
From: Daniel Golle @ 2026-04-20 16:34 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, Daniel Golle, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
Use 4 spaces for each level indentation, remove unused label, and add
missing empty line between header include and body.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v4: new patch
Documentation/devicetree/bindings/rng/mtk-rng.yaml | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
index 7e8dc62e5d3a6..8f2f4c32a0cfc 100644
--- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
@@ -47,9 +47,10 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt2701-clk.h>
- rng: rng@1020f000 {
- compatible = "mediatek,mt7623-rng";
- reg = <0x1020f000 0x1000>;
- clocks = <&infracfg CLK_INFRA_TRNG>;
- clock-names = "rng";
+
+ rng@1020f000 {
+ compatible = "mediatek,mt7623-rng";
+ reg = <0x1020f000 0x1000>;
+ clocks = <&infracfg CLK_INFRA_TRNG>;
+ clock-names = "rng";
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-20 16:25 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB7252BD7967D2567AD6DA7A1D8B2F2@OSQPR06MB7252.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 5939 bytes --]
On Mon, Apr 20, 2026 at 07:22:57AM +0000, Billy Tsai wrote:
> > > > > + properties:
> > > > > + function:
> > > > > + enum:
> > > > > + - EMMC
> > > > > + - JTAGDDR
> > > > > + - JTAGM0
> > > > > + - JTAGPCIEA
> > > > > + - JTAGPCIEB
> > > > > + - JTAGPSP
> > > > > + - JTAGSSP
> > > > > + - JTAGTSP
> > > > > + - JTAGUSB3A
> > > > > + - JTAGUSB3B
> > > > > + - PCIERC0PERST
> > > > > + - PCIERC1PERST
> > > > > + - TSPRSTN
> > > > > + - UFSCLKI
> > > > > + - USB2AD0
> > > > > + - USB2AD1
> > > > > + - USB2AH
> > > > > + - USB2AHP
> > > > > + - USB2AHPD0
> > > > > + - USB2AXH
> > > > > + - USB2AXH2B
> > > > > + - USB2AXHD1
> > > > > + - USB2AXHP
> > > > > + - USB2AXHP2B
> > > > > + - USB2AXHPD1
> > > > > + - USB2BD0
> > > > > + - USB2BD1
> > > > > + - USB2BH
> > > > > + - USB2BHP
> > > > > + - USB2BHPD0
> > > > > + - USB2BXH
> > > > > + - USB2BXH2A
> > > > > + - USB2BXHD1
> > > > > + - USB2BXHP
> > > > > + - USB2BXHP2A
> > > > > + - USB2BXHPD1
> > > > > + - USB3AXH
> > > > > + - USB3AXH2B
> > > > > + - USB3AXHD
> > > > > + - USB3AXHP
> > > > > + - USB3AXHP2B
> > > > > + - USB3AXHPD
> > > > > + - USB3BXH
> > > > > + - USB3BXH2A
> > > > > + - USB3BXHD
> > > > > + - USB3BXHP
> > > > > + - USB3BXHP2A
> > > > > + - USB3BXHPD
> > > > > + - VB
> > > > > + - VGADDC
> > > > > +
> > > > > + groups:
> > > > > + enum:
> > > > > + - EMMCCDN
> > > > > + - EMMCG1
> > > > > + - EMMCG4
> > > > > + - EMMCG8
> > > > > + - EMMCWPN
> > > > > + - JTAG0
> > > > > + - PCIERC0PERST
> > > > > + - PCIERC1PERST
> > > > > + - TSPRSTN
> > > > > + - UFSCLKI
> > > > > + - USB2A
> > > > > + - USB2AAP
> > > > > + - USB2ABP
> > > > > + - USB2ADAP
> > > > > + - USB2AH
> > > > > + - USB2AHAP
> > > > > + - USB2B
> > > > > + - USB2BAP
> > > > > + - USB2BBP
> > > > > + - USB2BDBP
> > > > > + - USB2BH
> > > > > + - USB2BHBP
> > > > > + - USB3A
> > > > > + - USB3AAP
> > > > > + - USB3ABP
> > > > > + - USB3B
> > > > > + - USB3BAP
> > > > > + - USB3BBP
> > > > > + - VB0
> > > > > + - VB1
> > > > > + - VGADDC
> > > > > + pins:
> > > > > + enum:
> > > > > + - AB13
> > > > > + - AB14
> > > > > + - AC13
> > > > > + - AC14
> > > > > + - AD13
> > > > > + - AD14
> > > > > + - AE13
> > > > > + - AE14
> > > > > + - AE15
> > > > > + - AF13
> > > > > + - AF14
> > > > > + - AF15
>
> > > > Why do you have groups and pins?
> > > > Is it valid in your device to have groups and pins in the same node?
>
> > > The intent is to support both group-based mux selection and
> > > configuration, as well as per-pin configuration.
>
> > > In our hardware:
> > > - `function` + `groups` are used for pinmux selection.
> > > - `pins` is used for per-pin configuration (e.g. drive strength,
> > > bias settings).
> > > - `groups` may also be used for group-level configuration.
>
> > > As a result, both `groups` and `pins` may appear in the same node,
> > > but they serve different purposes and do not conflict:
> > > - `groups` selects the mux function and may apply configuration to
> > > the entire group.
> > > - `pins` allows overriding or specifying configuration for individual
> > > pins.
>
> > > In most cases, only one of them is needed, but both are allowed when
> > > both group-level and per-pin configuration are required.
>
> > To be honest, that sounds like your groups are not sufficiently
> > granular and should be reduced such that you can use them for pin
> > settings.
>
> The intent was to keep the binding flexible, but in practice the mixed
> use of `groups` and `pins` in the same node is not expected to be used.
>
> Given that, I agree this flexibility is unnecessary and makes the
> binding semantics less clear. I'll rework the binding to make the
> expected usage explicit rather than allowing combinations that do not
> correspond to a real use case.
>
> In particular, I'll split the constraints as follows:
>
> - For pinmux, the presence of `function` will require `groups`, and
> `pins` will not be allowed. This reflects the hardware design, where
> the groups are defined by the pins affected by a given mux expression
>
> - For pin configuration, exactly one of `groups` or `pins` will be
> required (using oneOf), so that configuration is applied either at
> group level or per-pin, but not both.
>
>
> - if:
> required:
> - function
> then:
> required:
> - groups
> not:
> required:
> - pins
> else:
> oneOf:
> - required:
> - groups
> not:
> required:
> - pins
> - required:
> - pins
> not:
> required:
> - groups
> Does this match what you had in mind?
It's an improvement I think, but I am wondering why you cannot do
without pins entirely and apply pinconf stuff at the group level?
Of course that may not be possible with the current groups, but if you
made the groups more granular, would it be possible?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-20 16:27 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <aeIGxfQ7AoIVR5n6@monoceros>
Hi Uwe,
On 12:50 Fri 17 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
<...snip...>
> > I stand corrected here: after some more investigation it seems that only the
> > enable/disable (plus osme other not currently used registers) depends on the
> > global update flag, while the period and duty per-channel registers are
> > independtly updatable while they are latched on the end of (specific channel)
> > period strobe.
> > I'd say that this should avoid any cross-channel glitches since they are managed
> > independently. Unfortunately I'm not able to test this with my current (and
> > rather old) equipment, this would require at least an external trigger channel.
> > Regarding the setup of a new value exactly during the strobe: I think this is
> > quite hard to achieve.
>
> To sum up: period and duty_cycle changes might result in glitches unless
> the channel is disabled. This is ok, please just document it.
Maybe the glitch can occur if we're changing period and duty exactly during
the strobe, unless the register writing is somehow in sync with the PWM clock.
Disabling the channel immediately stops any execution and the line goes suddenly
low (if polarity is normal, otherwise stays high). See also next.
>
> The purpose of the update flag then is only to start several channels in
> sync?
Citing the datasheet:
"To prevent mis-sampling of multi-bit bus signals in the PWM clock domain,
this bit (SET_UPDATE) should be used to trigger a settings update. This
ensures that all PWM channel settings update on the same PWM clock cycle."
From my testing though, channels can be started in sync only if they have the
same period. I'll add a comment for all this, and other edge cases.
> What happens if sync is asserted while a disabled channel didn't
> complete the last period yet?
The output stops immediately without waiting for the current period to finish.
>
> Maybe it's worth to test the following procedure for updating duty and
> period:
>
> disable channel
> configure duty
> configure period
> enable
> set update flag
>
> Assumint disable is delayed until the end of the currently running
> period, the effect of this procedure might be that no glitch happens if
> the update flag is asserted before the currently running period ends and
> the anormality is reduced to a longer inactive state if the updates are
> not that lucky (in contrast to more severe glitches).
The disable isn't delayed as explained above. Setting just the new period/duty
(which do not depend on the sync bit) correctly waits for the end of the current
period without noticeable glitches (tested with a scope).
>
> If you can configure a short and a long period that is distinguishable
> "manually" with an LED I think this should be testable even without
> further equipment.
>
> > > > > > + if (ticks > U32_MAX)
> > > > > > + ticks = U32_MAX;
> > > > > > + wfhw->period_ticks = ticks;
> > > > >
> > > > > What happens if wf->period_length_ns > 0 but ticks == 0?
> > > >
> > > > I've added a check, returning 1 to signal teh round-up, and a minimum tick of 1
> > > > in this case.
> > >
> > > Sounds good. Are you able to verify that there is no +1 missing in the
> > > calculation, e.g. using 1 as register value really gives you a period of
> > > 1 tick and not 2?
> >
> > You are right. The scope reveals there's always one extra (low signal) tick at the
> > end of each period.
>
> So the hardware cannot do 100% relative duty, right? Please document
> that.
>
> > Let's say that teh user want 10 tick period, we have to use
> > 9 instead to account for the extra tick at the end, so that the complete period
> > contains that extra tick?
>
> I would describe that a bit differently, but in general: yes.
>
> The more straight forward description is that setting
>
> RP1_PWM_RANGE(pwm->hwpwm) := x
>
> results in a period of x + 1 ticks.
Exactly. So whatever the user request I have to subtract one from the value
to be written to the RANGE register.
>
> > This also means that if we ask for 100% duty cycle, the output waveform will
> > have the high part of the signal lasting one tick less than expected.a I guess
> > this is the accepted compromise.
>
> I assume you considered something like:
>
> RP1_PWM_RANGE(pwm->hwpwm) := 17
> RP1_PWM_DUTY(pwm->hwpwm) := 18
>
> to get a 100% relative duty?
Ah right! It's working fine and I've got 100% duty. So at hw register level
the duty can be greater that the period.
>
> If this doesn't work that means that this has to be formalized in the
> callbacks. That is the fromhw function has to always report
> duty_length_ns less than period_length_ns.
No need, it's working indeed.
>
> > OTOH, the minimum tick period would be 2 tick, less than that will otherwise
> > degenerate in a disabled channel.
>
> It's expected that in general for a period_length of 1 tick you can only
> have 0% and 100% relative duty. IIUC for this hardware you cannot do the
> 100% case so there is only a single valid duty_length for period_length
> = 1 tick.
Minimum tick confirmed to be 1.
>
> I think it would be more complicated to consistently filter out
> period_length = 1 tick in the driver than to just accept the conceptual
> limitations. (Otherwise: What would you report in the fromhw callback if
> period_length = 1 tick is configured in wfhw? Would you refuse to commit
> that wfhw to hardware in .write_waveform()? The pwm core handles that
> just fine and consumers have all the means to detect and prevent that if
> they care enough.)
>
> > > > > On remove you miss to balance the call to clk_prepare_enable() (if no
> > > > > failed call to clk_prepare_enable() in rp1_pwm_resume() happend).
> > > >
> > > > Since this driver now exports a syscon, it's only builtin (=Y) so
> > > > it cannot be unloaded.
> > > > I've also avoided the .remove callback via .suppress_bind_attrs.
> > >
> > > Oh no, please work cleanly here and make the driver unbindable. This
> > > yields better code quality and also helps during development and
> > > debugging.
> >
> > I wish to, but the issue here is that this driver exports a syscon via
> > of_syscon_register_regmap() which I think doesn't have the unregister
> > counterpart. So the consumer will break in case we can unbind/unload
> > the module and the syscon will leak.
> > If you have any alternative I'll be glad to discuss.
>
> My (not so well articulated) point is: Please be stringent about clock
> handling to not bank up technical dept more than necessary and such that
> the driver can be made unbindable if and when syscons grow
> that feature. Optionally wail at the syscon guys :-)
Hmmm not sure I've understood your point: is it a requirement that the driver
must be unbindable? In this case I should avoid registering the syscon. Or
should I just provide a .remove callback in case there will be a way to
unregister the syscon (even if this callback will not be called as of now)?
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* ✅ PASS: Test report for for-kernelci (7.0.0-0, upstream-arm-next, e583f808)
From: cki-project @ 2026-04-20 16:23 UTC (permalink / raw)
To: linux-arm-kernel, will, catalin.marinas
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge branch 'for-next/core' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2465743719
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Conor Dooley @ 2026-04-20 16:22 UTC (permalink / raw)
To: Ronald Claveau
Cc: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown,
linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-1-a6a7f570b11b@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
On Fri, Apr 17, 2026 at 06:27:17PM +0200, Ronald Claveau wrote:
> The Khadas VIM4 MCU register is slightly different
> from previous boards' MCU.
> This board also features a switchable power source for its fan.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> index 084960fd5a1fd..a80718f7595ce 100644
> --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> @@ -18,6 +18,7 @@ properties:
> compatible:
> enum:
> - khadas,mcu # MCU revision is discoverable
> + - khadas,vim4-mcu # Different MCU variant, not discoverable
>
> "#cooling-cells": # Only needed for boards having FAN control feature
> const: 2
> @@ -25,6 +26,10 @@ properties:
> reg:
> maxItems: 1
>
> + fan-supply:
> + description: Phandle to the regulator that powers the fan.
> + $ref: /schemas/types.yaml#/definitions/phandle
Can you limit this by compatible please?
pw-bot: changes-requested
> +
> required:
> - compatible
> - reg
>
> --
> 2.49.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: display: renesas,du: Document Renesas R-Car R8A779MD M3Le
From: Conor Dooley @ 2026-04-20 16:17 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-2-marek.vasut+renesas@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
On Sun, Apr 19, 2026 at 09:35:32PM +0200, Marek Vasut wrote:
> Extend the Renesas DU display bindings to support the Renesas R-Car
> R8A779MD M3Le SoC. This SoC is similar to R-Car R8A77965 M3-N SoC,
> except the HDMI port@1 is not present.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
From: Conor Dooley @ 2026-04-20 16:14 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-5-marek.vasut+renesas@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Sun, Apr 19, 2026 at 09:35:35PM +0200, Marek Vasut wrote:
> Document the compatible value for the Renesas R-Car M3Le (R8A779MD)
> SoC and the Renesas Geist development board. The Renesas M3Le SoC is
> a register-compatible variant of the R8A77965 (M3-N) with reduced set
> of peripherals. The Geist board is derived from Renesas Salvator-X/XS
> boards, with adjustment for the R8A779MD SoC.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: clock: cs2000-cp: document CS2500
From: Conor Dooley @ 2026-04-20 16:13 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-4-marek.vasut+renesas@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 320 bytes --]
On Sun, Apr 19, 2026 at 09:35:34PM +0200, Marek Vasut wrote:
> Document backward compatibility support for CS2500 chip, which
> is a drop-in replacement for CS2000 chip.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: amlogic: add X98Q compatible
From: Conor Dooley @ 2026-04-20 16:11 UTC (permalink / raw)
To: christian.koever-draxl
Cc: robh, krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet,
martin.blumenstingl, funderscore, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic
In-Reply-To: <20260420061854.5421-2-christian.koever-draxl@student.uibk.ac.at>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
On Mon, Apr 20, 2026 at 08:18:53AM +0200, christian.koever-draxl@student.uibk.ac.at wrote:
> From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
Even if a patch is simple, you still need a commit message.
pw-bot: changes-requested
Cheers,
Conor.
> Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
> index a885278bc4e2..82671d58d1da 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.yaml
> +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
> @@ -254,6 +254,13 @@ properties:
> - khadas,vim1s
> - const: amlogic,s905y4
> - const: amlogic,s4
> +
> + - description: Boards with the Amlogic Meson S4 S905W2 SoC
> + items:
> + - enum:
> + - amediatech,x98q
> + - const: amlogic,s905w2
> + - const: amlogic,s4
>
> - description: Boards with the Amlogic S6 S905X5 SoC
> items:
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 3/3] dts: s32g: Add GPR syscon region
From: Jared Kangas @ 2026-04-20 16:04 UTC (permalink / raw)
To: Dan Carpenter
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
NXP S32 Linux Team, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, imx,
devicetree, linux-kernel, linaro-s32, netdev
In-Reply-To: <aeKn2dvOOO43zdev@jkangas-thinkpadp1gen3.rmtuswa.csb>
Fixing Dan's address based on mailmap update, sorry for the noise.
On Fri, Apr 17, 2026 at 02:36:25PM -0700, Jared Kangas wrote:
> Hi Dan,
>
> On Fri, Jan 30, 2026 at 04:19:52PM +0300, Dan Carpenter wrote:
> > Add the GPR syscon region for the s32 chipset.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> > ---
> >
> > [snip]
> >
> > diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > index e314f3c7d61d..be03db737384 100644
> > --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > @@ -383,6 +383,11 @@ usdhc0-200mhz-grp4 {
> > };
> > };
> >
> > + gpr: syscon@4007c000 {
> > + compatible = "nxp,s32g3-gpr", "syscon";
> > + reg = <0x4007c000 0x3000>;
> > + };
> > +
> > ocotp: nvmem@400a4000 {
> > compatible = "nxp,s32g3-ocotp", "nxp,s32g2-ocotp";
> > reg = <0x400a4000 0x400>;
> > @@ -808,6 +813,7 @@ gmac0: ethernet@4033c000 {
> > compatible = "nxp,s32g2-dwmac";
> > reg = <0x4033c000 0x2000>, /* gmac IP */
> > <0x4007c004 0x4>; /* GMAC_0_CTRL_STS */
> > + nxp,phy-sel = <&gpr 0x4>;
> > interrupt-parent = <&gic>;
> > interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
> > interrupt-names = "macirq";
>
> I gave this a test on an S32G-VNP-RDB3 and didn't see any issues on the
> dwmac-s32 side, but this appears to trigger a panic when reading the new
> debugfs regmap/*/registers file for the syscon node:
>
> # grep 4007c000 /proc/vmallocinfo
> 0xffff800083da8000-0xffff800083dac000 16384 ioremap_prot+0x74/0xe0 phys=0x000000004007c000 ioremap
> # cat /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers
> Internal error: synchronous external abort: 0000000096000210 [#1] SMP
> [...]
> CPU: 0 UID: 0 PID: 4344 Comm: cat Tainted: G M E X ------ --- 6.12.0+ #226 PREEMPT_RT
> Tainted: [M]=MACHINE_CHECK, [E]=UNSIGNED_MODULE, [X]=AUX
> [...]
> pc : regmap_mmio_read32le+0x44/0xa0
> lr : regmap_mmio_read32le+0x44/0xa0
> [...]
> x23: ffff00080c080000 x22: ffff000802ac4c00 x21: ffff800087b13c9c
> x20: ffff800080a46494 x19: ffff800083da810c x18: 0000000000000004
> [...]
> x5 : ffff800080a46448 x4 : ffff800083da8000 x3 : ffff800080a46494
> x2 : ffff800080a47230 x1 : ffff800083da810c x0 : 0000000000000020
> Call trace:
> regmap_mmio_read32le+0x44/0xa0 (P)
> regmap_mmio_read+0x4c/0x80
> [...]
> Code: 52800400 8b214093 aa1303e1 97f4caf0 (b9400275)
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: synchronous external abort: Fatal exception
>
> Running this through decodecode gives:
>
> All code
> ========
> 0: 52800400 mov w0, #0x20 // #32
> 4: 8b214093 add x19, x4, w1, uxtw
> 8: aa1303e1 mov x1, x19
> c: 97f4caf0 bl 0xffffffffffd32bcc
> 10:* b9400275 ldr w21, [x19] <-- trapping instruction
>
> Code starting with the faulting instruction
> ===========================================
> 0: b9400275 ldr w21, [x19]
>
> x19's offset from the base address in /proc/vmallocinfo is 0x10c, which
> points to a bad read at physical address 0x4007c10c; I also confirmed
> that the preceding memory reads back without issues:
>
> # head -c 990 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> 0104: 00000000
> # head -c 1005 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> 0108: 00000000
> # head -c 1020 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> <panic>
>
> Best,
> Jared
>
^ permalink raw reply
* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Brian Masney @ 2026-04-20 16:02 UTC (permalink / raw)
To: Sebastian Reichel, Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Pavel Zhovner, Andy Yan,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
linux-clk, Cristian Ciocaltea, Maxime Ripard
In-Reply-To: <aeKtNf8CCAWduI-f@venus>
[-- Attachment #1: Type: text/plain, Size: 5457 bytes --]
Hi Alexey,
On Sat, Apr 18, 2026 at 12:24:57AM +0200, Sebastian Reichel wrote:
> On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> > Dear all,
> >
> > Need the help of the collective wisdom of the community.
> >
> > The problem I'm trying to solve is reliably obtaining the exact pixel
> > clock for arbitrary display modes supported by the RK3576 SoC.
> >
> > Rockchip RK3576 has three display output processors VP0~VP2, each
> > supporting different ranges of display modes, roughly as follows:
> > - VP0: 4K 120Hz
> > - VP1: 2.5k 60Hz
> > - VP2: 1080p 60Hz
> >
> > Each one obviously needs a pixel clock. The required frequencies for the
> > pixel clocks vary greatly depending on the display mode, and need to be
> > matched within a tight tolerance, or else many displays will refuse to
> > work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> > awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> > be obtained using integer dividers from its default clock source (GPLL
> > at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> > outside the tolerance of e.g. DP specification, resulting in a blank
> > screen on most displays by default.
> >
> > The clock sources are of course configurable, in particular there are muxes
> > connected to each VP for selecting the source of the pixel clock:
> > - Each VP can take the clock either from the (single!) HDMI PHY or from
> > its dedicated dclk_vpX_src mux
> > - The dclk_vpX_src mux can select the clock from a number of system PLLs
> > (GPLL, CPLL, VPLL, BPLL, LPLL)
> >
> > While the system PLLs can be configured to output a wide range of
> > frequencies, they are shared between many system components. E.g. on the
> > current mainline kernel on one of my RK3576 boards I've got the following:
> > GPLL: 1188 MHz, enable count 20
> > CPLL: 1000 MHz, enable count 17
> > VPLL: 594 MHz, enable count 0 (yaay!)
> > BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> > predividers, so are less flexible)
> >
> > So ultimately there is exactly one free fractional PLL (VPLL) which can be
> > used to generate arbitrary pixel clocks, but we have up to three consumers
> > trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> > VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> > frequency on the fly to satisfy the requirements of the selected display
> > mode.
> >
> > And this is where I'm stuck. Trying to satisfy the requirements of up to
> > three consumers while changing the PLL frequency on the fly sounds like
> > a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> > HDMI output out of the equation, because it can be driven from the HDMI
> > PHY (which is capable of arbitrary rates) instead of the mux, but that
> > makes the decision of which dclk source to use for a VP block dependent on
> > which downstream consumer is connected to it (HDMI vs. something else).
>
> It becomes more messy: The HDMI PHY cannot be used as clock source
> for modes exceeding 4K@60Hz.
>
> > Even then we somehow need two devices to cooperate in picking a PLL
> > frequency that satisfies the requirements of both of them, and change to it
> > without display corruption. I'm not even sure if the CCF has mechanisms
> > for that?..
> >
> > What follows is a brief set of patches which illustrate a partial solution
> > for the case of "I just need 2.5k60Hz on VP1 via DP and don't care about
> > the rest". It switches the VP1 unconditionally to use VPLL as the source
> > for its dclk mux, allows changing the VPLL frequency on the fly, and also
> > changes the frequency calculation logic to allow for nearest-match
> > frequencies which are not necessarily rounded down. These are not meant
> > to be merged as-is, as I see the following issues:
> > - The flag allowing the PLL to change rate is in the clock driver, while
> > the reparenting to an unused PLL is in the device tree. If these go out
> > of sync, we might end up trying to change the frequency of a PLL which
> > is used by other consumers (I presume that could be dangerous)
>
> It is a problem, see e.g. this patch from Heiko removing the flag
> for an RK3588 VOP source clock:
>
> https://lore.kernel.org/linux-rockchip/20251008133135.3745785-1-heiko@sntech.de/
>
> Also note, that there is some more general ongoing work regarding
> this:
>
> See: https://lore.kernel.org/linux-clk/20260327-clk-scaling-v8-0-86cd0aba3c5f@redhat.com/
I'm working on the patch set above to fix the clk scaling issues. You'll
have issues on clks that have CLK_SET_RATE_PARENT enabled, and there are
multiple children under that parent. Patches 2 and 4 in my series has
kunit tests that demonstrates the current behavior.
I attached a patch to drivers/clk/rockchip/clk-pll.c that adds support
for the v2 rate negotiation logic. You'll need to apply this on top my
clk scaling patch set. I only compile tested this, however it should work
based on the changes that I made to clk-divider.c.
You'll also need to add the flag CLK_V2_RATE_NEGOTIATION to your three
display clks. Otherwise, without the flag, it will just fall back to the
existing behavior.
Hopefully this will let you be able to use one of the PLLs that has a
high enable count as the parent.
Feel free to reach out to me if you have any questions or issues with
my patch set.
Brian
[-- Attachment #2: 0001-clk-rockchip-pll-add-support-for-v2-rate-negotiation.patch --]
[-- Type: text/plain, Size: 1326 bytes --]
From 66b44d756dba0152b415cc8eb8528b55c4253058 Mon Sep 17 00:00:00 2001
From: Brian Masney <bmasney@redhat.com>
Date: Mon, 20 Apr 2026 11:13:53 -0400
Subject: [PATCH] clk: rockchip: pll: add support for v2 rate negotiation logic
Content-type: text/plain
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
drivers/clk/rockchip/clk-pll.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6b853800cb6b..30e0722f872f 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -66,8 +66,20 @@ static int rockchip_pll_determine_rate(struct clk_hw *hw,
{
struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
const struct rockchip_pll_rate_table *rate_table = pll->rate_table;
+ struct clk_hw *parent = req->best_parent_hw;
int i;
+ if (parent && (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) &&
+ clk_has_v2_rate_negotiation(parent->core)) {
+ unsigned long lcm_rate;
+
+ lcm_rate = clk_hw_get_children_lcm(parent, hw, req->rate);
+ if (lcm_rate > 0) {
+ lcm_rate = clk_hw_round_rate(parent, lcm_rate);
+ req->best_parent_rate = lcm_rate;
+ }
+ }
+
/* Assuming rate_table is in descending order */
for (i = 0; i < pll->rate_count; i++) {
if (req->rate >= rate_table[i].rate) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Cristian Ciocaltea @ 2026-04-20 15:53 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <2480203.yKrmzQ4Hd0@phil>
On 4/20/26 6:18 PM, Heiko Stuebner wrote:
> Am Montag, 20. April 2026, 13:00:25 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> Hi Heiko,
>>
>> On 4/18/26 2:12 AM, Heiko Stuebner wrote:
>>> Hi Cristian,
>>>
>>> Am Freitag, 17. April 2026, 18:34:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>>>> On 4/17/26 2:32 PM, Heiko Stuebner wrote:
>>>>> the comments below apply sort of to all patches in that series.
>>>>>
>>>>> Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>>>>>> The board exposes the GPIO4_C6 line to control the voltage bias on the
>>>>>> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
>>>>>> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>>>>>>
>>>>>> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
>>>>>> property and drop the line from the vcc_5v0_hdmi regulator to allow
>>>>>> adjusting the bias when transitioning between TMDS and FRL operating
>>>>>> modes.
>>
>> [...]
>>
>>>>>
>>>>>
>>>>>> @@ -231,6 +228,8 @@ &gpu {
>>>>>> };
>>>>>>
>>>>>> &hdmi {
>>>>>> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
>>>>>> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>>>>>
>>>>> this should be sorted the other way around I think.
>>>>>
>>>>> Also please provide a pinctrl-names property too. If for whatever reason
>>>>> the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
>>>>> board DTs are staying in the "old" compatible mode until they are adapted.
>>>>
>>>> Just to make sure I fully understand, the convention is that
>>>>
>>>> pinctrl-names = "default";
>>>>
>>>> should be always provided, even when the node overrides an existing pinctrl-0
>>>> property?
>>>>
>>>> E.g. in rk3576.dtsi we have:
>>>>
>>>> hdmi: hdmi@27da0000 {
>>>> ...
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
>>>> ...
>>>> }
>>>>
>>>> Hence I omitted pinctrl-names which doesn't change and just appended
>>>> &hdmi_frl_en to pinctrl-0's original value.
>>>
>>> correct, please always provide a pinctrl-names entry when setting a new
>>> pinctrl-0 .
>>>
>>> The background is, imagine you have a base:
>>>
>>> pinctrl-names = "default";
>>> pinstrl-0 = <....>;
>>>
>>> and override pinctrl-0 in a board.
>>>
>>> Now a newer binding introduces a 2nd pinctrl state "foo". Of course
>>> we're backwards compatible, and both are valid and the driver checks
>>> what states are defined.
>>>
>>> So the base sets:
>>> pinctrl-names = "default", "foo";
>>> pinctrl-0 = <...>;
>>> pinctrl-1 = <...>;
>>>
>>> in your (old) board you override pinctrl-0, but the driver still sees
>>> the new variant with 2 pinctrl states, where it should've stayed with
>>> the legacy 1-state, until the board-dts might get adapted in the future.
>>>
>>>
>>> And I know, we're likely not doing that everywhere, and also in most
>>> cases it won't really matter, but still it is safer and sets the better
>>> precedent :-) .
>>
>> Thanks for the detailed explanation, that clears things up!
>>
>> There are several other nodes (e.g. i2c, pwm, uart) that also lack
>> pinctrl-names despite providing pinctrl-0 - I can address those in a
>> separate patch.
>
> As said above it is an ideal to aspire to (having -names together with
> defining states), but if you want to add the "missing" -names,
> go ahead :-) .
>
>
>> I also noticed an inconsistency in property ordering: some nodes place
>> pinctrl-names before pinctrl-<n> and others after. I have always used
>> the former, but we should probably prefer the latter to stay consistent
>> with how clocks, resets, phys, etc. are ordered.
>>
>> Thoughts?
>
> There is sort of a "conflict" between regular ordering and possibly
> better readability. I.e. the dt-writing guidelines propose alphabetical
> ordering which I guess puts numbers before letters.
>
> On the other hand the semantic definition of list the states and then
> define them (names first, -0, -1, etc second) looks more sensible from
> a understanding standpoint.
>
>
> But there we'd end up with special rules, so just sticking to the
> base sorting will cause less friction in the long run I think.
> Aka, -0, -1 first; -names after, follows the main sorting suggestions
> so it's easy to explain to newcomers.
Yes, that seems like a good enough reason to go with this approach.
> But please don't re-sort existing entries :-)
Oh, no, it's just for the current changes. :-)
Thanks,
Cristian
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Sudeep Holla @ 2026-04-20 15:47 UTC (permalink / raw)
To: Yeoreum Yun
Cc: Will Deacon, Marc Zyngier, linux-security-module, linux-kernel,
Sudeep Holla, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, peterhuewe, jarkko, jgg, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, sebastianene
In-Reply-To: <aeYGeojpqcYAN5++@e129823.arm.com>
On Mon, Apr 20, 2026 at 11:56:58AM +0100, Yeoreum Yun wrote:
> Hi Will,
>
> > [+Seb for the pKVM FFA bits]
> >
> > Ah sorry, I mixed up the ordering of 'module_init' vs 'rootfs_initcall'
> > and thought you wanted to probe the version earlier. But then I'm still
> > confused because, prior to 0e0546eabcd6 ("firmware: arm_ffa: Change
> > initcall level of ffa_init() to rootfs_initcall"), ffa_init() was a
> > 'device_initcall' which is still called earlier than finalize_pkvm().
>
> Right, and this is what I missed when writing patch
> 0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall").
> and it still exists even if it's device call.
>
> However, rather than changing ffa_init to rootfs_initcall, moving ima_init
> to late_initcall_sync is a better approach, as it also addresses similar
> issues for TPM devices that do not use FF-A. For this reason,
> the FF-A-related changes were reverted.
>
> As a result, patch 4/4 addresses an issue that existed independently of
> 0e0546eabcd6, as you pointed out.
>
I was not fully convinced by commit 0e0546eabcd6 ("firmware: arm_ffa: Change
initcall level of ffa_init() to rootfs_initcall"), and I had raised this
concern at the time. However, in the absence of a better alternative, we
proceeded with merging it.
My concern remains essentially the same. That change moved the initcall one
stage earlier, and now, by introducing `late_initcall_sync()`, we are
effectively shifting the dependency issue one stage later instead of resolving
it in a more fundamental way. From my perspective, this still relies on
adjusting initcall ordering as the primary means of making the dependency
work.
I do not think that is a robust or sustainable approach. Tweaking initcall
levels tends to be inherently fragile because it addresses the symptom through
sequencing rather than establishing a clear and explicit dependency model.
I also recall that `finalise_pkvm()` is itself at `device_initcall` level. If
that is correct, would this not introduce another ordering issue or at least
leave us exposed to similar dependency problems? That is exactly why I remain
uneasy about solving this by continuing to move initcalls backward or forward.
More broadly, the fact that we are revisiting the same class of issue again
after such a short time reinforces my concern that this direction is not
sufficiently stable. We may revisit it soon after we merge this approach.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC PATCH v5 1/9] media: v4l2-common: Add YUV24 format info
From: Nicolas Dufresne @ 2026-04-20 15:39 UTC (permalink / raw)
To: Nas Chung, mchehab, hverkuil, robh, krzk+dt, conor+dt, shawnguo,
s.hauer
Cc: linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, marek.vasut, ming.qian
In-Reply-To: <20260415092529.577-2-nas.chung@chipsnmedia.com>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
Le mercredi 15 avril 2026 à 18:25 +0900, Nas Chung a écrit :
> The YUV24 format is missing an entry in the v4l2_format_info().
> The YUV24 format is the packed YUV 4:4:4 formats with 8 bits
> per component.
>
> Fixes: 0376a51fbe5e ("media: v4l: Add packed YUV444 24bpp pixel format")
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Unless you disagree, I might cherry-pick this one. Would it be ok with you ?
Nicolas
> ---
> drivers/media/v4l2-core/v4l2-common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 554c591e1113..55bcd5975d9f 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -281,6 +281,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> { .format = V4L2_PIX_FMT_Y212, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 4, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_Y216, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 4, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_YUV48_12, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 6, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
> + { .format = V4L2_PIX_FMT_YUV24, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 3, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_MT2110T, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
> { .format = V4L2_PIX_FMT_MT2110R, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH bpf-next 2/3] bpf, arm64: Add JIT support for stack arguments
From: Puranjay Mohan @ 2026-04-20 15:36 UTC (permalink / raw)
To: bpf
Cc: Puranjay Mohan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Xu Kuohai,
Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20260420153603.4097618-1-puranjay@kernel.org>
Implement stack argument passing for BPF-to-BPF and kfunc calls with
more than 5 parameters on arm64, following the AAPCS64 calling
convention.
BPF R1-R5 already map to x0-x4. With BPF_REG_0 moved to x8 by the
previous commit, x5-x7 are free for arguments 6-8. Arguments 9-12
spill onto the stack at [SP+0], [SP+8], ... and the callee reads
them from [FP+16], [FP+24], ... (above the saved FP/LR pair).
BPF convention uses fixed offsets from BPF_REG_PARAMS (r11): off=-8 is
always arg 6, off=-16 arg 7, etc. The verifier invalidates all outgoing
stack arg slots after each call, so the compiler must re-store before
every call. This means x5-x7 don't need to be saved on stack.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
arch/arm64/net/bpf_jit_comp.c | 87 +++++++++++++++++++++++++++++++++--
1 file changed, 83 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 085e650662e3..7adf2b0f4610 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -86,6 +86,7 @@ struct jit_ctx {
__le32 *image;
__le32 *ro_image;
u32 stack_size;
+ u16 stack_arg_size;
u64 user_vm_start;
u64 arena_vm_start;
bool fp_used;
@@ -533,13 +534,19 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf)
* | |
* +-----+ <= (BPF_FP - prog->aux->stack_depth)
* |RSVD | padding
- * current A64_SP => +-----+ <= (BPF_FP - ctx->stack_size)
+ * +-----+ <= (BPF_FP - ctx->stack_size)
+ * | |
+ * | ... | outgoing stack args (9+, if any)
+ * | |
+ * current A64_SP => +-----+
* | |
* | ... | Function call stack
* | |
* +-----+
* low
*
+ * Stack args 6-8 are passed in x5-x7, args 9+ at [SP].
+ * Incoming args 9+ are at [FP + 16], [FP + 24], ...
*/
emit_kcfi(is_main_prog ? cfi_bpf_hash : cfi_bpf_subprog_hash, ctx);
@@ -613,6 +620,9 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf)
if (ctx->stack_size && !ctx->priv_sp_used)
emit(A64_SUB_I(1, A64_SP, A64_SP, ctx->stack_size), ctx);
+ if (ctx->stack_arg_size)
+ emit(A64_SUB_I(1, A64_SP, A64_SP, ctx->stack_arg_size), ctx);
+
if (ctx->arena_vm_start)
emit_a64_mov_i64(arena_vm_base, ctx->arena_vm_start, ctx);
@@ -673,6 +683,9 @@ static int emit_bpf_tail_call(struct jit_ctx *ctx)
/* Update tail_call_cnt if the slot is populated. */
emit(A64_STR64I(tcc, ptr, 0), ctx);
+ if (ctx->stack_arg_size)
+ emit(A64_ADD_I(1, A64_SP, A64_SP, ctx->stack_arg_size), ctx);
+
/* restore SP */
if (ctx->stack_size && !ctx->priv_sp_used)
emit(A64_ADD_I(1, A64_SP, A64_SP, ctx->stack_size), ctx);
@@ -1034,6 +1047,9 @@ static void build_epilogue(struct jit_ctx *ctx, bool was_classic)
const u8 r0 = bpf2a64[BPF_REG_0];
const u8 ptr = bpf2a64[TCCNT_PTR];
+ if (ctx->stack_arg_size)
+ emit(A64_ADD_I(1, A64_SP, A64_SP, ctx->stack_arg_size), ctx);
+
/* We're done with BPF stack */
if (ctx->stack_size && !ctx->priv_sp_used)
emit(A64_ADD_I(1, A64_SP, A64_SP, ctx->stack_size), ctx);
@@ -1191,6 +1207,41 @@ static int add_exception_handler(const struct bpf_insn *insn,
return 0;
}
+static const u8 stack_arg_reg[] = { A64_R(5), A64_R(6), A64_R(7) };
+
+#define NR_STACK_ARG_REGS ARRAY_SIZE(stack_arg_reg)
+
+static void emit_stack_arg_load(u8 dst, s16 bpf_off, struct jit_ctx *ctx)
+{
+ int idx = bpf_off / sizeof(u64) - 1;
+
+ if (idx < NR_STACK_ARG_REGS)
+ emit(A64_MOV(1, dst, stack_arg_reg[idx]), ctx);
+ else
+ emit(A64_LDR64I(dst, A64_FP, (idx - NR_STACK_ARG_REGS) * sizeof(u64) + 16), ctx);
+}
+
+static void emit_stack_arg_store(u8 src_a64, s16 bpf_off, struct jit_ctx *ctx)
+{
+ int idx = -bpf_off / sizeof(u64) - 1;
+
+ if (idx < NR_STACK_ARG_REGS)
+ emit(A64_MOV(1, stack_arg_reg[idx], src_a64), ctx);
+ else
+ emit(A64_STR64I(src_a64, A64_SP, (idx - NR_STACK_ARG_REGS) * sizeof(u64)), ctx);
+}
+
+static void emit_stack_arg_store_imm(s32 imm, s16 bpf_off, const u8 tmp, struct jit_ctx *ctx)
+{
+ int idx = -bpf_off / sizeof(u64) - 1;
+
+ emit_a64_mov_i(1, tmp, imm, ctx);
+ if (idx < NR_STACK_ARG_REGS)
+ emit(A64_MOV(1, stack_arg_reg[idx], tmp), ctx);
+ else
+ emit(A64_STR64I(tmp, A64_SP, (idx - NR_STACK_ARG_REGS) * sizeof(u64)), ctx);
+}
+
/* JITs an eBPF instruction.
* Returns:
* 0 - successfully JITed an 8-byte eBPF instruction.
@@ -1646,6 +1697,11 @@ static int build_insn(const struct bpf_verifier_env *env, const struct bpf_insn
case BPF_LDX | BPF_MEM | BPF_H:
case BPF_LDX | BPF_MEM | BPF_B:
case BPF_LDX | BPF_MEM | BPF_DW:
+ if (insn->src_reg == BPF_REG_PARAMS) {
+ emit_stack_arg_load(dst, off, ctx);
+ break;
+ }
+ fallthrough;
case BPF_LDX | BPF_PROBE_MEM | BPF_DW:
case BPF_LDX | BPF_PROBE_MEM | BPF_W:
case BPF_LDX | BPF_PROBE_MEM | BPF_H:
@@ -1671,7 +1727,7 @@ static int build_insn(const struct bpf_verifier_env *env, const struct bpf_insn
}
if (src == fp) {
src_adj = ctx->priv_sp_used ? priv_sp : A64_SP;
- off_adj = off + ctx->stack_size;
+ off_adj = off + ctx->stack_size + ctx->stack_arg_size;
} else {
src_adj = src;
off_adj = off;
@@ -1752,6 +1808,11 @@ static int build_insn(const struct bpf_verifier_env *env, const struct bpf_insn
case BPF_ST | BPF_MEM | BPF_H:
case BPF_ST | BPF_MEM | BPF_B:
case BPF_ST | BPF_MEM | BPF_DW:
+ if (insn->dst_reg == BPF_REG_PARAMS) {
+ emit_stack_arg_store_imm(imm, off, tmp, ctx);
+ break;
+ }
+ fallthrough;
case BPF_ST | BPF_PROBE_MEM32 | BPF_B:
case BPF_ST | BPF_PROBE_MEM32 | BPF_H:
case BPF_ST | BPF_PROBE_MEM32 | BPF_W:
@@ -1762,7 +1823,7 @@ static int build_insn(const struct bpf_verifier_env *env, const struct bpf_insn
}
if (dst == fp) {
dst_adj = ctx->priv_sp_used ? priv_sp : A64_SP;
- off_adj = off + ctx->stack_size;
+ off_adj = off + ctx->stack_size + ctx->stack_arg_size;
} else {
dst_adj = dst;
off_adj = off;
@@ -1814,6 +1875,11 @@ static int build_insn(const struct bpf_verifier_env *env, const struct bpf_insn
case BPF_STX | BPF_MEM | BPF_H:
case BPF_STX | BPF_MEM | BPF_B:
case BPF_STX | BPF_MEM | BPF_DW:
+ if (insn->dst_reg == BPF_REG_PARAMS) {
+ emit_stack_arg_store(src, off, ctx);
+ break;
+ }
+ fallthrough;
case BPF_STX | BPF_PROBE_MEM32 | BPF_B:
case BPF_STX | BPF_PROBE_MEM32 | BPF_H:
case BPF_STX | BPF_PROBE_MEM32 | BPF_W:
@@ -1824,7 +1890,7 @@ static int build_insn(const struct bpf_verifier_env *env, const struct bpf_insn
}
if (dst == fp) {
dst_adj = ctx->priv_sp_used ? priv_sp : A64_SP;
- off_adj = off + ctx->stack_size;
+ off_adj = off + ctx->stack_size + ctx->stack_arg_size;
} else {
dst_adj = dst;
off_adj = off;
@@ -2065,6 +2131,14 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_verifier_env *env, struct bpf_pr
ctx.user_vm_start = bpf_arena_get_user_vm_start(prog->aux->arena);
ctx.arena_vm_start = bpf_arena_get_kern_vm_start(prog->aux->arena);
+ if (prog->aux->stack_arg_depth > prog->aux->incoming_stack_arg_depth) {
+ u16 outgoing = prog->aux->stack_arg_depth - prog->aux->incoming_stack_arg_depth;
+ int nr_on_stack = outgoing / sizeof(u64) - NR_STACK_ARG_REGS;
+
+ if (nr_on_stack > 0)
+ ctx.stack_arg_size = round_up(nr_on_stack * sizeof(u64), 16);
+ }
+
if (priv_stack_ptr)
ctx.priv_sp_used = true;
@@ -2229,6 +2303,11 @@ bool bpf_jit_supports_kfunc_call(void)
return true;
}
+bool bpf_jit_supports_stack_args(void)
+{
+ return true;
+}
+
void *bpf_arch_text_copy(void *dst, void *src, size_t len)
{
if (!aarch64_insn_copy(dst, src, len))
--
2.52.0
^ permalink raw reply related
* [PATCH bpf-next 3/3] selftests/bpf: Enable stack argument tests for arm64
From: Puranjay Mohan @ 2026-04-20 15:36 UTC (permalink / raw)
To: bpf
Cc: Puranjay Mohan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Xu Kuohai,
Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20260420153603.4097618-1-puranjay@kernel.org>
Now that arm64 supports stack arguments, enable the existing stack_arg,
stack_arg_kfunc and verifier_stack_arg tests for __TARGET_ARCH_arm64.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
tools/testing/selftests/bpf/progs/stack_arg.c | 3 ++-
.../testing/selftests/bpf/progs/stack_arg_kfunc.c | 3 ++-
.../selftests/bpf/progs/verifier_stack_arg.c | 15 ++++++++++++++-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/stack_arg.c b/tools/testing/selftests/bpf/progs/stack_arg.c
index 8c198ee952ff..b1276009fd30 100644
--- a/tools/testing/selftests/bpf/progs/stack_arg.c
+++ b/tools/testing/selftests/bpf/progs/stack_arg.c
@@ -23,7 +23,8 @@ struct {
int timer_result;
-#if defined(__TARGET_ARCH_x86) && defined(__BPF_FEATURE_STACK_ARGUMENT)
+#if (defined(__TARGET_ARCH_x86) || defined(__TARGET_ARCH_arm64)) && \
+ defined(__BPF_FEATURE_STACK_ARGUMENT)
const volatile bool has_stack_arg = true;
diff --git a/tools/testing/selftests/bpf/progs/stack_arg_kfunc.c b/tools/testing/selftests/bpf/progs/stack_arg_kfunc.c
index 6cc404d57863..3818cd0cb67b 100644
--- a/tools/testing/selftests/bpf/progs/stack_arg_kfunc.c
+++ b/tools/testing/selftests/bpf/progs/stack_arg_kfunc.c
@@ -6,7 +6,8 @@
#include "bpf_kfuncs.h"
#include "../test_kmods/bpf_testmod_kfunc.h"
-#if defined(__TARGET_ARCH_x86) && defined(__BPF_FEATURE_STACK_ARGUMENT)
+#if (defined(__TARGET_ARCH_x86) || defined(__TARGET_ARCH_arm64)) && \
+ defined(__BPF_FEATURE_STACK_ARGUMENT)
const volatile bool has_stack_arg = true;
diff --git a/tools/testing/selftests/bpf/progs/verifier_stack_arg.c b/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
index 66dd11840a63..8f1eef911f70 100644
--- a/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
+++ b/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
@@ -12,7 +12,8 @@ struct {
__type(value, long long);
} map_hash_8b SEC(".maps");
-#if defined(__TARGET_ARCH_x86) && defined(__BPF_FEATURE_STACK_ARGUMENT)
+#if (defined(__TARGET_ARCH_x86) || defined(__TARGET_ARCH_arm64)) && \
+ defined(__BPF_FEATURE_STACK_ARGUMENT)
__noinline __used
static int subprog_6args(int a, int b, int c, int d, int e, int f)
@@ -36,6 +37,7 @@ SEC("tc")
__description("stack_arg: subprog with 6 args")
__success
__arch_x86_64
+__arch_arm64
__naked void stack_arg_6args(void)
{
asm volatile (
@@ -55,6 +57,7 @@ SEC("tc")
__description("stack_arg: two subprogs with >5 args")
__success
__arch_x86_64
+__arch_arm64
__naked void stack_arg_two_subprogs(void)
{
asm volatile (
@@ -84,6 +87,7 @@ SEC("tc")
__description("stack_arg: read from uninitialized stack arg slot")
__failure
__arch_x86_64
+__arch_arm64
__msg("invalid read from stack arg off 8 depth 0")
__naked void stack_arg_read_uninitialized(void)
{
@@ -99,6 +103,7 @@ SEC("tc")
__description("stack_arg: gap at offset -8, only wrote -16")
__failure
__arch_x86_64
+__arch_arm64
__msg("stack arg#6 not properly initialized")
__naked void stack_arg_gap_at_minus8(void)
{
@@ -120,6 +125,7 @@ __description("stack_arg: pruning with different stack arg types")
__failure
__flag(BPF_F_TEST_STATE_FREQ)
__arch_x86_64
+__arch_arm64
__msg("R1 invalid mem access 'scalar'")
__naked void stack_arg_pruning_type_mismatch(void)
{
@@ -157,6 +163,7 @@ SEC("tc")
__description("stack_arg: release_reference invalidates stack arg slot")
__failure
__arch_x86_64
+__arch_arm64
__msg("R1 invalid mem access 'scalar'")
__naked void stack_arg_release_ref(void)
{
@@ -207,6 +214,7 @@ SEC("tc")
__description("stack_arg: pkt pointer in stack arg slot invalidated after pull_data")
__failure
__arch_x86_64
+__arch_arm64
__msg("R1 invalid mem access 'scalar'")
__naked void stack_arg_stale_pkt_ptr(void)
{
@@ -246,6 +254,7 @@ SEC("tc")
__description("stack_arg: null propagation rejects deref on null branch")
__failure
__arch_x86_64
+__arch_arm64
__msg("R1 invalid mem access 'scalar'")
__naked void stack_arg_null_propagation_fail(void)
{
@@ -285,6 +294,7 @@ SEC("tc")
__description("stack_arg: missing store on one branch")
__failure
__arch_x86_64
+__arch_arm64
__msg("stack arg#6 not properly initialized")
__naked void stack_arg_missing_store_one_branch(void)
{
@@ -327,6 +337,7 @@ SEC("tc")
__description("stack_arg: share a store for both branches")
__success __retval(0)
__arch_x86_64
+__arch_arm64
__naked void stack_arg_shared_store(void)
{
asm volatile (
@@ -369,6 +380,7 @@ SEC("tc")
__description("stack_arg: write beyond max outgoing depth")
__failure
__arch_x86_64
+__arch_arm64
__msg("stack arg write offset -80 exceeds max 7 stack args")
__naked void stack_arg_write_beyond_max(void)
{
@@ -393,6 +405,7 @@ SEC("tc")
__description("stack_arg: sequential calls reuse slots")
__failure
__arch_x86_64
+__arch_arm64
__msg("stack arg#6 not properly initialized")
__naked void stack_arg_sequential_calls(void)
{
--
2.52.0
^ permalink raw reply related
* [PATCH bpf-next 1/3] bpf, arm64: Map BPF_REG_0 to x8 instead of x7
From: Puranjay Mohan @ 2026-04-20 15:35 UTC (permalink / raw)
To: bpf
Cc: Puranjay Mohan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Xu Kuohai,
Catalin Marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20260420153603.4097618-1-puranjay@kernel.org>
Move the BPF return value register from x7 to x8, freeing x7 for use
as an argument register. AAPCS64 designates x8 as the indirect result
location register; it is caller-saved and not used for argument
passing, making it a suitable home for BPF_REG_0.
This is a prerequisite for stack argument support, which needs x5-x7
to pass arguments 6-8 to native kfuncs following the AAPCS64 calling
convention.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
arch/arm64/net/bpf_jit_comp.c | 4 ++--
arch/arm64/net/bpf_timed_may_goto.S | 8 ++++----
.../testing/selftests/bpf/progs/verifier_jit_inline.c | 2 +-
tools/testing/selftests/bpf/progs/verifier_ldsx.c | 6 +++---
.../selftests/bpf/progs/verifier_private_stack.c | 10 +++++-----
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 0816c40fc7af..085e650662e3 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -47,7 +47,7 @@
/* Map BPF registers to A64 registers */
static const int bpf2a64[] = {
/* return value from in-kernel function, and exit value from eBPF */
- [BPF_REG_0] = A64_R(7),
+ [BPF_REG_0] = A64_R(8),
/* arguments from eBPF program to in-kernel function */
[BPF_REG_1] = A64_R(0),
[BPF_REG_2] = A64_R(1),
@@ -1048,7 +1048,7 @@ static void build_epilogue(struct jit_ctx *ctx, bool was_classic)
/* Restore FP/LR registers */
emit(A64_POP(A64_FP, A64_LR, A64_SP), ctx);
- /* Move the return value from bpf:r0 (aka x7) to x0 */
+ /* Move the return value from bpf:r0 (aka x8) to x0 */
emit(A64_MOV(1, A64_R(0), r0), ctx);
/* Authenticate lr */
diff --git a/arch/arm64/net/bpf_timed_may_goto.S b/arch/arm64/net/bpf_timed_may_goto.S
index 894cfcd7b241..a9a802711a7f 100644
--- a/arch/arm64/net/bpf_timed_may_goto.S
+++ b/arch/arm64/net/bpf_timed_may_goto.S
@@ -8,8 +8,8 @@ SYM_FUNC_START(arch_bpf_timed_may_goto)
stp x29, x30, [sp, #-64]!
mov x29, sp
- /* Save BPF registers R0 - R5 (x7, x0-x4)*/
- stp x7, x0, [sp, #16]
+ /* Save BPF registers R0 - R5 (x8, x0-x4)*/
+ stp x8, x0, [sp, #16]
stp x1, x2, [sp, #32]
stp x3, x4, [sp, #48]
@@ -28,8 +28,8 @@ SYM_FUNC_START(arch_bpf_timed_may_goto)
/* BPF_REG_AX(x9) will be stored into count, so move return value to it. */
mov x9, x0
- /* Restore BPF registers R0 - R5 (x7, x0-x4) */
- ldp x7, x0, [sp, #16]
+ /* Restore BPF registers R0 - R5 (x8, x0-x4) */
+ ldp x8, x0, [sp, #16]
ldp x1, x2, [sp, #32]
ldp x3, x4, [sp, #48]
diff --git a/tools/testing/selftests/bpf/progs/verifier_jit_inline.c b/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
index 4ea254063646..885ff69a3a62 100644
--- a/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
+++ b/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
@@ -9,7 +9,7 @@ __success __retval(0)
__arch_x86_64
__jited(" addq %gs:{{.*}}, %rax")
__arch_arm64
-__jited(" mrs x7, SP_EL0")
+__jited(" mrs x8, SP_EL0")
int inline_bpf_get_current_task(void)
{
bpf_get_current_task();
diff --git a/tools/testing/selftests/bpf/progs/verifier_ldsx.c b/tools/testing/selftests/bpf/progs/verifier_ldsx.c
index c8494b682c31..c814e82a7242 100644
--- a/tools/testing/selftests/bpf/progs/verifier_ldsx.c
+++ b/tools/testing/selftests/bpf/progs/verifier_ldsx.c
@@ -274,11 +274,11 @@ __jited("movslq 0x10(%rdi,%r12), %r15")
__jited("movswq 0x18(%rdi,%r12), %r15")
__jited("movsbq 0x20(%rdi,%r12), %r15")
__arch_arm64
-__jited("add x11, x7, x28")
+__jited("add x11, x8, x28")
__jited("ldrsw x21, [x11, #0x10]")
-__jited("add x11, x7, x28")
+__jited("add x11, x8, x28")
__jited("ldrsh x21, [x11, #0x18]")
-__jited("add x11, x7, x28")
+__jited("add x11, x8, x28")
__jited("ldrsb x21, [x11, #0x20]")
__jited("add x11, x0, x28")
__jited("ldrsw x22, [x11, #0x10]")
diff --git a/tools/testing/selftests/bpf/progs/verifier_private_stack.c b/tools/testing/selftests/bpf/progs/verifier_private_stack.c
index 646e8ef82051..c5078face38d 100644
--- a/tools/testing/selftests/bpf/progs/verifier_private_stack.c
+++ b/tools/testing/selftests/bpf/progs/verifier_private_stack.c
@@ -170,12 +170,12 @@ __jited(" mrs x10, TPIDR_EL{{[0-1]}}")
__jited(" add x27, x27, x10")
__jited(" add x25, x27, {{.*}}")
__jited(" bl 0x{{.*}}")
-__jited(" mov x7, x0")
+__jited(" mov x8, x0")
__jited(" mov x0, #0x2a")
__jited(" str x0, [x27]")
__jited(" bl 0x{{.*}}")
-__jited(" mov x7, x0")
-__jited(" mov x7, #0x0")
+__jited(" mov x8, x0")
+__jited(" mov x8, #0x0")
__jited(" ldp x25, x27, [sp], {{.*}}")
__naked void private_stack_callback(void)
{
@@ -220,7 +220,7 @@ __jited(" mov x0, #0x2a")
__jited(" str x0, [x27]")
__jited(" mov x0, #0x0")
__jited(" bl 0x{{.*}}")
-__jited(" mov x7, x0")
+__jited(" mov x8, x0")
__jited(" ldp x27, x28, [sp], #0x10")
int private_stack_exception_main_prog(void)
{
@@ -258,7 +258,7 @@ __jited(" add x25, x27, {{.*}}")
__jited(" mov x0, #0x2a")
__jited(" str x0, [x27]")
__jited(" bl 0x{{.*}}")
-__jited(" mov x7, x0")
+__jited(" mov x8, x0")
__jited(" ldp x27, x28, [sp], #0x10")
int private_stack_exception_sub_prog(void)
{
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: arm: aspeed: add Anacapa EVT1 EVT2 board
From: Conor Dooley @ 2026-04-20 15:36 UTC (permalink / raw)
To: Colin Huang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <CAPBH0A_K39218+=QHJuEY+SbFk-nCnM=Z8RQMdHBK7SkCj2QtQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Mon, Apr 20, 2026 at 01:41:30PM +0800, Colin Huang wrote:
> Conor Dooley <conor@kernel.org> 於 2026年4月9日週四 下午11:36寫道：
> >
> > On Thu, Apr 09, 2026 at 07:40:26PM +0800, Colin Huang wrote:
> > > Document Anacapa BMC EVT1 and EVT2 compatibles.
> > >
> > > Signed-off-by: Colin Huang <u8813345@gmail.com>
> >
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > pw-bot: not-applicable
>
> Hi
> Could anyone let me know, what is my next step which I need to do?
> I can't find the changed in for-next branch of
> https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git .
> Thanks.
You wait for the merge window to end and the maintainer to apply your
patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH bpf-next 0/3] bpf, arm64: Support stack arguments
From: Puranjay Mohan @ 2026-04-20 15:35 UTC (permalink / raw)
To: bpf
Cc: Puranjay Mohan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Xu Kuohai,
Catalin Marinas, Will Deacon, linux-arm-kernel
This set add support of stack arguments to the arm64 JIT based on the
preparatory work and x86 support in [1]. Arm64 allows passing 8
arguments in registers x0-x7 and remaining ones on stack. Currently, BPF
supports passing 5 arguments all of which map to x0-x4.
BPF passes arguments in R1-R5 which map to x0-x4 on arm64, BPF reg R0 is
mapped to arm64 reg x7, but as arm64 needs this register to pass
arguments now, the first patch changes the mapping of BPF reg R0 to x8
which allows passing arguments in x0-x7 (8 arguments). 9+ arguments are
passed on the stack.
Note: This set needs to be applied on top of [1]
All selftest pass:
./test_progs -t stack_arg,stack_arg_fail,stack_arg_kfunc,verifier_stack_arg
#431/1 stack_arg/global_many_args:OK
#431/2 stack_arg/async_cb_many_args:OK
#431/3 stack_arg/bpf2bpf:OK
#431/4 stack_arg/kfunc:OK
#431 stack_arg:OK
#432/1 stack_arg_fail/test_stack_arg_big:OK
#432/2 stack_arg_fail/r11 in ALU instruction:OK
#432/3 stack_arg_fail/r11 store with non-DW size:OK
#432/4 stack_arg_fail/r11 store with unaligned offset:OK
#432/5 stack_arg_fail/r11 store with positive offset:OK
#432/6 stack_arg_fail/r11 load with negative offset:OK
#432/7 stack_arg_fail/r11 load with non-DW size:OK
#432/8 stack_arg_fail/r11 store with zero offset:OK
#432 stack_arg_fail:OK
#631/1 verifier_stack_arg/stack_arg: subprog with 6 args:OK
#631/2 verifier_stack_arg/stack_arg: two subprogs with >5 args:OK
#631/3 verifier_stack_arg/stack_arg: read from uninitialized stack arg slot:OK
#631/4 verifier_stack_arg/stack_arg: gap at offset -8, only wrote -16:OK
#631/5 verifier_stack_arg/stack_arg: pruning with different stack arg types:OK
#631/6 verifier_stack_arg/stack_arg: release_reference invalidates stack arg slot:OK
#631/7 verifier_stack_arg/stack_arg: pkt pointer in stack arg slot invalidated after pull_data:OK
#631/8 verifier_stack_arg/stack_arg: null propagation rejects deref on null branch:OK
#631/9 verifier_stack_arg/stack_arg: missing store on one branch:OK
#631/10 verifier_stack_arg/stack_arg: share a store for both branches:OK
#631/11 verifier_stack_arg/stack_arg: write beyond max outgoing depth:OK
#631/12 verifier_stack_arg/stack_arg: sequential calls reuse slots:OK
#631 verifier_stack_arg:OK
Summary: 3/24 PASSED, 0 SKIPPED, 0 FAILED
[1] https://lore.kernel.org/all/20260419163316.731019-1-yonghong.song@linux.dev/
Puranjay Mohan (3):
bpf, arm64: Map BPF_REG_0 to x8 instead of x7
bpf, arm64: Add JIT support for stack arguments
selftests/bpf: Enable stack argument tests for arm64
arch/arm64/net/bpf_jit_comp.c | 91 +++++++++++++++++--
arch/arm64/net/bpf_timed_may_goto.S | 8 +-
tools/testing/selftests/bpf/progs/stack_arg.c | 3 +-
.../selftests/bpf/progs/stack_arg_kfunc.c | 3 +-
.../selftests/bpf/progs/verifier_jit_inline.c | 2 +-
.../selftests/bpf/progs/verifier_ldsx.c | 6 +-
.../bpf/progs/verifier_private_stack.c | 10 +-
.../selftests/bpf/progs/verifier_stack_arg.c | 15 ++-
8 files changed, 116 insertions(+), 22 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCH v2 6/6] usb: typec: ucsi: huawei-gaokun: pass down HPD_IRQ events
From: Dmitry Baryshkov @ 2026-04-20 15:31 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno
In-Reply-To: <20260420-hpd-irq-events-v2-0-402ffe27e9e9@oss.qualcomm.com>
Pass IRQ_HPD events to the HPD bridge, letting those to be delivered to
the DisplayPort driver.
Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
index ca749fde49bd..5e3f887ecbd8 100644
--- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
+++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
@@ -299,10 +299,13 @@ static void gaokun_ucsi_handle_altmode(struct gaokun_ucsi_port *port)
/* UCSI callback .connector_status() have set orientation */
if (port->bridge)
- drm_aux_hpd_bridge_notify(&port->bridge->dev,
- port->hpd_state ?
- connector_status_connected :
- connector_status_disconnected);
+ drm_aux_hpd_bridge_notify_extra(&port->bridge->dev,
+ port->hpd_state ?
+ connector_status_connected :
+ connector_status_disconnected,
+ port->hpd_irq ?
+ DRM_CONNECTOR_DP_IRQ_HPD :
+ DRM_CONNECTOR_NO_EXTRA_STATUS);
gaokun_ec_ucsi_pan_ack(uec->ec, port->idx);
}
--
2.47.3
^ 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