* Re: [PATCH net-next 03/10] net: stmmac: move TSO VLAN tag insertion to core code
From: Russell King (Oracle) @ 2026-03-29 9:09 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Ong Boon Leong, Paolo Abeni
In-Reply-To: <E1w6bKu-0000000ELtr-0U6v@rmk-PC.armlinux.org.uk>
On Sat, Mar 28, 2026 at 09:36:52PM +0000, Russell King (Oracle) wrote:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index e21ca1c70c6d..ed3e9515cf25 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -4419,19 +4419,6 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> u8 proto_hdr_len, hdr;
> dma_addr_t des;
>
> - /* Always insert VLAN tag to SKB payload for TSO frames.
> - *
> - * Never insert VLAN tag by HW, since segments split by
> - * TSO engine will be un-tagged by mistake.
> - */
> - if (skb_vlan_tag_present(skb)) {
> - skb = __vlan_hwaccel_push_inside(skb);
> - if (unlikely(!skb)) {
> - priv->xstats.tx_dropped++;
> - return NETDEV_TX_OK;
> - }
> - }
> -
> nfrags = skb_shinfo(skb)->nr_frags;
> queue = skb_get_queue_mapping(skb);
>
> @@ -4932,6 +4919,14 @@ static netdev_features_t stmmac_features_check(struct sk_buff *skb,
> features = vlan_features_check(skb, features);
>
> if (skb_is_gso(skb)) {
> + /* Always insert VLAN tag to SKB payload for TSO frames.
> + *
> + * Never insert VLAN tag by HW, since segments split by
> + * TSO engine will be un-tagged by mistake.
> + */
> + features &= ~(NETIF_F_HW_VLAN_STAG_TX |
> + NETIF_F_HW_VLAN_CTAG_TX);
> +
I'm wondering whether this is the correct place to do this. If as a
result of the following tests we fallback to software GSO, then we
will be submitting "normal" frames to the driver to transmit, which
means it can insert the VLAN tag in hardware.
So, I'm thinking this isn't the correct place for the test, but it
should be after the tests that disable NETIF_F_GSO_MASK and only be
masked out when the features mask still contains any of the
NETIF_F_GSO_MASK features. Anyone concur?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH v2] arm: mediatek: MAINTAINERS: Include SoC bindings
From: Krzysztof Kozlowski @ 2026-03-29 8:53 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: Krzysztof Kozlowski
The ARM/ARM64 Mediatek SoC maintainer entry misses bindings directory
for SoC devices.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
FYI, there are already patches on the list which used get_maintainers.pl
script and did not CC Mediatek maintainers, so they might get
forgotten/missed.
Changes in v2:
1. Correct f:->F:
2. Cc maintainers...
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 80b9074e96ae..8474210a93b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3061,6 +3061,7 @@ L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Maintained
W: https://mtk.wiki.kernel.org/
C: irc://irc.libera.chat/linux-mediatek
+F: Documentation/devicetree/bindings/soc/mediatek/
F: arch/arm/boot/dts/mediatek/
F: arch/arm/mach-mediatek/
F: arch/arm64/boot/dts/mediatek/
--
2.51.0
^ permalink raw reply related
* Re: [PATCH RFC 2/8] clk: sunxi-ng: sdm: Add dual patterns support
From: Chen-Yu Tsai @ 2026-03-29 7:56 UTC (permalink / raw)
To: Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Richard Cochran, linux-clk, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, netdev
In-Reply-To: <20260310-a733-clk-v1-2-36b4e9b24457@pigmoral.tech>
On Tue, Mar 10, 2026 at 4:42 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>
> On newer Allwinner platforms like the A733, the Sigma-Delta Modulation
> (SDM) control logic is more complex. The SDM enable bit, which was
> previously located in the PLL register, is now moved to a second
> pattern register (PATTERN1).
>
> To support this, rename the existing "tuning" members to "pattern0" to
> align with the datasheet, and introduce the _SUNXI_CCU_SDM_DUAL_PAT
> macro to provide pattern1 register support. Related operations are also
> updated.
>
> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> ---
> drivers/clk/sunxi-ng/ccu_sdm.c | 51 +++++++++++++++++++++++++++++-------------
> drivers/clk/sunxi-ng/ccu_sdm.h | 32 +++++++++++++++++---------
> 2 files changed, 57 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_sdm.c b/drivers/clk/sunxi-ng/ccu_sdm.c
> index c564e5f9e610..204e25feaa36 100644
> --- a/drivers/clk/sunxi-ng/ccu_sdm.c
> +++ b/drivers/clk/sunxi-ng/ccu_sdm.c
> @@ -18,7 +18,10 @@ bool ccu_sdm_helper_is_enabled(struct ccu_common *common,
> if (sdm->enable && !(readl(common->base + common->reg) & sdm->enable))
> return false;
>
> - return !!(readl(common->base + sdm->tuning_reg) & sdm->tuning_enable);
> + if (sdm->pat1_enable && !(readl(common->base + sdm->pat1_reg) & sdm->pat1_enable))
> + return false;
> +
> + return !!(readl(common->base + sdm->pat0_reg) & sdm->pat0_enable);
> }
> EXPORT_SYMBOL_NS_GPL(ccu_sdm_helper_is_enabled, "SUNXI_CCU");
>
> @@ -37,18 +40,27 @@ void ccu_sdm_helper_enable(struct ccu_common *common,
> for (i = 0; i < sdm->table_size; i++)
> if (sdm->table[i].rate == rate)
> writel(sdm->table[i].pattern,
> - common->base + sdm->tuning_reg);
> + common->base + sdm->pat0_reg);
>
> /* Make sure SDM is enabled */
> spin_lock_irqsave(common->lock, flags);
> - reg = readl(common->base + sdm->tuning_reg);
> - writel(reg | sdm->tuning_enable, common->base + sdm->tuning_reg);
> + reg = readl(common->base + sdm->pat0_reg);
> + writel(reg | sdm->pat0_enable, common->base + sdm->pat0_reg);
> spin_unlock_irqrestore(common->lock, flags);
>
> - spin_lock_irqsave(common->lock, flags);
> - reg = readl(common->base + common->reg);
> - writel(reg | sdm->enable, common->base + common->reg);
> - spin_unlock_irqrestore(common->lock, flags);
> + if (sdm->enable) {
> + spin_lock_irqsave(common->lock, flags);
> + reg = readl(common->base + common->reg);
> + writel(reg | sdm->enable, common->base + common->reg);
> + spin_unlock_irqrestore(common->lock, flags);
> + }
> +
> + if (sdm->pat1_enable) {
> + spin_lock_irqsave(common->lock, flags);
> + reg = readl(common->base + sdm->pat1_reg);
> + writel(reg | sdm->pat1_enable, common->base + sdm->pat1_reg);
> + spin_unlock_irqrestore(common->lock, flags);
> + }
> }
> EXPORT_SYMBOL_NS_GPL(ccu_sdm_helper_enable, "SUNXI_CCU");
>
> @@ -61,14 +73,23 @@ void ccu_sdm_helper_disable(struct ccu_common *common,
> if (!(common->features & CCU_FEATURE_SIGMA_DELTA_MOD))
> return;
>
> - spin_lock_irqsave(common->lock, flags);
> - reg = readl(common->base + common->reg);
> - writel(reg & ~sdm->enable, common->base + common->reg);
> - spin_unlock_irqrestore(common->lock, flags);
> + if (sdm->enable) {
> + spin_lock_irqsave(common->lock, flags);
> + reg = readl(common->base + common->reg);
> + writel(reg & ~sdm->enable, common->base + common->reg);
> + spin_unlock_irqrestore(common->lock, flags);
> + }
> +
> + if (sdm->pat1_enable) {
> + spin_lock_irqsave(common->lock, flags);
> + reg = readl(common->base + sdm->pat1_reg);
> + writel(reg & ~sdm->pat1_enable, common->base + sdm->pat1_reg);
> + spin_unlock_irqrestore(common->lock, flags);
> + }
>
> spin_lock_irqsave(common->lock, flags);
> - reg = readl(common->base + sdm->tuning_reg);
> - writel(reg & ~sdm->tuning_enable, common->base + sdm->tuning_reg);
> + reg = readl(common->base + sdm->pat0_reg);
> + writel(reg & ~sdm->pat0_enable, common->base + sdm->pat0_reg);
> spin_unlock_irqrestore(common->lock, flags);
> }
> EXPORT_SYMBOL_NS_GPL(ccu_sdm_helper_disable, "SUNXI_CCU");
> @@ -123,7 +144,7 @@ unsigned long ccu_sdm_helper_read_rate(struct ccu_common *common,
> pr_debug("%s: clock is sigma-delta modulated\n",
> clk_hw_get_name(&common->hw));
>
> - reg = readl(common->base + sdm->tuning_reg);
> + reg = readl(common->base + sdm->pat0_reg);
>
> pr_debug("%s: pattern reg is 0x%x",
> clk_hw_get_name(&common->hw), reg);
> diff --git a/drivers/clk/sunxi-ng/ccu_sdm.h b/drivers/clk/sunxi-ng/ccu_sdm.h
> index c1a7159b89c3..c289be28e1b4 100644
> --- a/drivers/clk/sunxi-ng/ccu_sdm.h
> +++ b/drivers/clk/sunxi-ng/ccu_sdm.h
> @@ -33,21 +33,31 @@ struct ccu_sdm_internal {
> u32 table_size;
> /* early SoCs don't have the SDM enable bit in the PLL register */
> u32 enable;
> - /* second enable bit in tuning register */
> - u32 tuning_enable;
> - u16 tuning_reg;
> + /* second enable bit in pattern0 register */
> + u32 pat0_enable;
> + u16 pat0_reg;
> + /* on some platforms, the sdm enable bit in pattern1 register */
> + u32 pat1_enable;
> + u16 pat1_reg;
> };
>
> -#define _SUNXI_CCU_SDM(_table, _enable, \
> - _reg, _reg_enable) \
> - { \
> - .table = _table, \
> - .table_size = ARRAY_SIZE(_table), \
> - .enable = _enable, \
> - .tuning_enable = _reg_enable, \
> - .tuning_reg = _reg, \
> +#define __SUNXI_CCU_SDM(_table, _enable, _pat0, _pat0_enable, _pat1, _pat1_enable) \
> + { \
> + .table = _table, \
> + .table_size = ARRAY_SIZE(_table), \
> + .enable = _enable, \
> + .pat0_enable = _pat0_enable, \
> + .pat0_reg = _pat0, \
> + .pat1_enable = _pat1_enable, \
> + .pat1_reg = _pat1, \
> }
>
> +#define _SUNXI_CCU_SDM(_table, _enable, _pat0, _pat0_enable) \
> + __SUNXI_CCU_SDM(_table, _enable, _pat0, _pat0_enable, 0, 0)
> +
> +#define _SUNXI_CCU_SDM_DUAL_PAT(_table, _pat0, _pat0_enable, _pat1, _pat1_enable) \
> + __SUNXI_CCU_SDM(_table, 0, _pat0, _pat0_enable, _pat1, _pat1_enable)
> +
Don't introduce an intermediate macro that looks _almost_ the same as the
macro the driver is actually supposed to use.
Just declare _SUNXI_CCU_SDM_DUAL_PAT() to expand to the full entry, and
_SUNXI_CCU_SDM() to _SUNXI_CCU_SDM_DUAL_PAT() with the last two parameters
as zero. That takes less lines.
ChenYu
> bool ccu_sdm_helper_is_enabled(struct ccu_common *common,
> struct ccu_sdm_internal *sdm);
> void ccu_sdm_helper_enable(struct ccu_common *common,
>
> --
> 2.52.0
>
>
^ permalink raw reply
* [PATCH v3] lib/crc: arm64: add NEON accelerated CRC64-NVMe implementation
From: Demian Shulhan @ 2026-03-29 7:43 UTC (permalink / raw)
To: linux-crypto, linux-kernel, linux-arm-kernel
Cc: ebiggers, ardb, Demian Shulhan
In-Reply-To: <20260317065425.2684093-1-demyansh@gmail.com>
Implement an optimized CRC64 (NVMe) algorithm for ARM64 using NEON
Polynomial Multiply Long (PMULL) instructions. The generic shift-and-XOR
software implementation is slow, which creates a bottleneck in NVMe and
other storage subsystems.
The acceleration is implemented using C intrinsics (<arm_neon.h>) rather
than raw assembly for better readability and maintainability.
Key highlights of this implementation:
- Uses 4KB chunking inside scoped_ksimd() to avoid preemption latency
spikes on large buffers.
- Pre-calculates and loads fold constants via vld1q_u64() to minimize
register spilling.
- Benchmarks show the break-even point against the generic implementation
is around 128 bytes. The PMULL path is enabled only for len >= 128.
Performance results (kunit crc_benchmark on Cortex-A72):
- Generic (len=4096): ~268 MB/s
- PMULL (len=4096): ~1556 MB/s (nearly 6x improvement)
Signed-off-by: Demian Shulhan <demyansh@gmail.com>
---
v2: - Removed KERNEL_MODE_NEON check from Kconfig as it's redundant on arm64.
- Added missing prototype for crc64_nvme_arm64_c to fix sparse/W=1 warning.
- Improved readability in Makefile with extra newlines and comments.
- Removed redundant include guards in crc64.h.
- Switched to do-while loops for better optimization in hot paths.
- Added comments explaining the magic constants (fold/Barrett).
---
v3: - Removed big-endian fallback from the commit message.
- Rewrote the comment explaining the final Barrett reduction step.
- Adjusted the formatting of the scoped_ksimd() call.
---
lib/crc/Kconfig | 1 +
lib/crc/Makefile | 8 +++-
lib/crc/arm64/crc64-neon-inner.c | 78 ++++++++++++++++++++++++++++++++
lib/crc/arm64/crc64.h | 30 ++++++++++++
4 files changed, 116 insertions(+), 1 deletion(-)
create mode 100644 lib/crc/arm64/crc64-neon-inner.c
create mode 100644 lib/crc/arm64/crc64.h
diff --git a/lib/crc/Kconfig b/lib/crc/Kconfig
index 70e7a6016de3..16cb42d5e306 100644
--- a/lib/crc/Kconfig
+++ b/lib/crc/Kconfig
@@ -82,6 +82,7 @@ config CRC64
config CRC64_ARCH
bool
depends on CRC64 && CRC_OPTIMIZATIONS
+ default y if ARM64
default y if RISCV && RISCV_ISA_ZBC && 64BIT
default y if X86_64
diff --git a/lib/crc/Makefile b/lib/crc/Makefile
index 7543ad295ab6..c9c35419b39c 100644
--- a/lib/crc/Makefile
+++ b/lib/crc/Makefile
@@ -38,9 +38,15 @@ obj-$(CONFIG_CRC64) += crc64.o
crc64-y := crc64-main.o
ifeq ($(CONFIG_CRC64_ARCH),y)
CFLAGS_crc64-main.o += -I$(src)/$(SRCARCH)
+
+CFLAGS_REMOVE_arm64/crc64-neon-inner.o += -mgeneral-regs-only
+CFLAGS_arm64/crc64-neon-inner.o += -ffreestanding -march=armv8-a+crypto
+CFLAGS_arm64/crc64-neon-inner.o += -isystem $(shell $(CC) -print-file-name=include)
+crc64-$(CONFIG_ARM64) += arm64/crc64-neon-inner.o
+
crc64-$(CONFIG_RISCV) += riscv/crc64_lsb.o riscv/crc64_msb.o
crc64-$(CONFIG_X86) += x86/crc64-pclmul.o
-endif
+endif # CONFIG_CRC64_ARCH
obj-y += tests/
diff --git a/lib/crc/arm64/crc64-neon-inner.c b/lib/crc/arm64/crc64-neon-inner.c
new file mode 100644
index 000000000000..881cdafadb37
--- /dev/null
+++ b/lib/crc/arm64/crc64-neon-inner.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Accelerated CRC64 (NVMe) using ARM NEON C intrinsics
+ */
+
+#include <linux/types.h>
+#include <asm/neon-intrinsics.h>
+
+u64 crc64_nvme_arm64_c(u64 crc, const u8 *p, size_t len);
+
+#define GET_P64_0(v) ((poly64_t)vgetq_lane_u64(vreinterpretq_u64_p64(v), 0))
+#define GET_P64_1(v) ((poly64_t)vgetq_lane_u64(vreinterpretq_u64_p64(v), 1))
+
+/* x^191 mod G, x^127 mod G */
+static const u64 fold_consts_val[2] = { 0xeadc41fd2ba3d420ULL,
+ 0x21e9761e252621acULL };
+/* floor(x^127 / G), (G - x^64) / x */
+static const u64 bconsts_val[2] = { 0x27ecfa329aef9f77ULL,
+ 0x34d926535897936aULL };
+
+u64 crc64_nvme_arm64_c(u64 crc, const u8 *p, size_t len)
+{
+ uint64x2_t v0_u64 = { crc, 0 };
+ poly64x2_t v0 = vreinterpretq_p64_u64(v0_u64);
+ poly64x2_t fold_consts =
+ vreinterpretq_p64_u64(vld1q_u64(fold_consts_val));
+ poly64x2_t v1 = vreinterpretq_p64_u8(vld1q_u8(p));
+
+ v0 = vreinterpretq_p64_u8(veorq_u8(vreinterpretq_u8_p64(v0),
+ vreinterpretq_u8_p64(v1)));
+ p += 16;
+ len -= 16;
+
+ do {
+ v1 = vreinterpretq_p64_u8(vld1q_u8(p));
+
+ poly128_t v2 = vmull_high_p64(fold_consts, v0);
+ poly128_t v0_128 =
+ vmull_p64(GET_P64_0(fold_consts), GET_P64_0(v0));
+
+ uint8x16_t x0 = veorq_u8(vreinterpretq_u8_p128(v0_128),
+ vreinterpretq_u8_p128(v2));
+
+ x0 = veorq_u8(x0, vreinterpretq_u8_p64(v1));
+ v0 = vreinterpretq_p64_u8(x0);
+
+ p += 16;
+ len -= 16;
+ } while (len >= 16);
+
+ /* Multiply the 128-bit value by x^64 and reduce it back to 128 bits. */
+ poly64x2_t v7 = vreinterpretq_p64_u64((uint64x2_t){ 0, 0 });
+ poly128_t v1_128 = vmull_p64(GET_P64_1(fold_consts), GET_P64_0(v0));
+
+ uint8x16_t ext_v0 =
+ vextq_u8(vreinterpretq_u8_p64(v0), vreinterpretq_u8_p64(v7), 8);
+ uint8x16_t x0 = veorq_u8(ext_v0, vreinterpretq_u8_p128(v1_128));
+
+ v0 = vreinterpretq_p64_u8(x0);
+
+ /* Final Barrett reduction */
+ poly64x2_t bconsts = vreinterpretq_p64_u64(vld1q_u64(bconsts_val));
+
+ v1_128 = vmull_p64(GET_P64_0(bconsts), GET_P64_0(v0));
+
+ poly64x2_t v1_64 = vreinterpretq_p64_u8(vreinterpretq_u8_p128(v1_128));
+ poly128_t v3_128 = vmull_p64(GET_P64_1(bconsts), GET_P64_0(v1_64));
+
+ x0 = veorq_u8(vreinterpretq_u8_p64(v0), vreinterpretq_u8_p128(v3_128));
+
+ uint8x16_t ext_v2 = vextq_u8(vreinterpretq_u8_p64(v7),
+ vreinterpretq_u8_p128(v1_128), 8);
+
+ x0 = veorq_u8(x0, ext_v2);
+
+ v0 = vreinterpretq_p64_u8(x0);
+ return vgetq_lane_u64(vreinterpretq_u64_p64(v0), 1);
+}
diff --git a/lib/crc/arm64/crc64.h b/lib/crc/arm64/crc64.h
new file mode 100644
index 000000000000..cc65abeee24c
--- /dev/null
+++ b/lib/crc/arm64/crc64.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * CRC64 using ARM64 PMULL instructions
+ */
+
+#include <linux/cpufeature.h>
+#include <asm/simd.h>
+#include <linux/minmax.h>
+#include <linux/sizes.h>
+
+u64 crc64_nvme_arm64_c(u64 crc, const u8 *p, size_t len);
+
+#define crc64_be_arch crc64_be_generic
+
+static inline u64 crc64_nvme_arch(u64 crc, const u8 *p, size_t len)
+{
+ if (len >= 128 && cpu_have_named_feature(PMULL) &&
+ likely(may_use_simd())) {
+ do {
+ size_t chunk = min_t(size_t, len & ~15, SZ_4K);
+
+ scoped_ksimd()
+ crc = crc64_nvme_arm64_c(crc, p, chunk);
+
+ p += chunk;
+ len -= chunk;
+ } while (len >= 128);
+ }
+ return crc64_nvme_generic(crc, p, len);
+}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()
From: Greg Kroah-Hartman @ 2026-03-29 7:31 UTC (permalink / raw)
To: Sebastián Alba
Cc: Florian Fainelli, bcm-kernel-feedback-list, linux-staging,
linux-rpi-kernel, linux-arm-kernel, Dave Stevenson, kernel-list
In-Reply-To: <CAJD=UNdEqLW_CGpq0=p+DwJraiHTus+t-bPRW9wi2wh8B8C-rw@mail.gmail.com>
On Sun, Mar 29, 2026 at 01:04:54AM -0600, Sebastián Alba wrote:
> Hi Greg, Thanks for the quick review.
>
> Regarding kmalloc_array(): the patch does replace kmalloc() with
> kmalloc_array() - perhaps the question is about the remaining
> ioparam.op_count * sizeof(*block) in the copy_from_user() call below?
> That multiplication is now safe because kmalloc_array() already
> verified that op_count * sizeof(*block) does not overflow(if it did,
> kmalloc_array would have returned NULL and we'd have exited). Happy to
> add a comment clarifying this if you prefer.
Sorry, my fault, I meant alloc_objs(), coffee hadn't kicked in yet.
And please do not top-post:
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
> Regarding the Fixes tag: the commit dfdc7a773374 is from the
> raspberrypi/linux tree (branch rpi-6.6.y). This driver (vc-sm-cma)
> appears to only exist in the Raspberry Pi kernel fork and has not been
> merged into mainline staging.
Then we can't do anything with it here :(
> I apologize for sending this to the wrong tree. Should these patches
> go directly to the Raspberry Pi kernel maintainers
> (kernel-list@raspberrypi.com) instead?
No idea how that out-of-tree driver is managed, sorry.
good luck,
greg k-h
^ permalink raw reply
* [PATCH v2 4/4] staging: vc04_services: vchiq-mmal: fix integer underflow in port_parameter_get()
From: Sebastian Josue Alba Vives @ 2026-03-29 7:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives, stable
In-Reply-To: <20260329071616.507876-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
port_parameter_get() subtracts 2 * sizeof(u32) from the VideoCore
firmware's reply size field to compute the parameter value size. If
the firmware returns a size smaller than 8, the subtraction wraps
around to a large value due to unsigned integer underflow.
The underflowed size is then used in a comparison that selects the
wrong copy path and stored back to the caller via *value_size,
propagating a bogus size to subsequent operations.
Add a minimum size check before the subtraction and return -EPROTO
if the reply is malformed.
Cc: stable@vger.kernel.org
Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index 18e805b92..f2bb5ce0a 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -1436,6 +1436,10 @@ static int port_parameter_get(struct vchiq_mmal_instance *instance,
/* port_parameter_get_reply.size includes the header,
* whilst *value_size doesn't.
*/
+ if (rmsg->u.port_parameter_get_reply.size < (2 * sizeof(u32))) {
+ ret = -EPROTO;
+ goto release_msg;
+ }
rmsg->u.port_parameter_get_reply.size -= (2 * sizeof(u32));
if (ret || rmsg->u.port_parameter_get_reply.size > *value_size) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] staging: vc04_services: vchiq-mmal: validate component index in event_to_host_cb()
From: Sebastian Josue Alba Vives @ 2026-03-29 7:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives, stable
In-Reply-To: <20260329071616.507876-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
event_to_host_cb() uses msg->u.event_to_host.client_component as an
index into the instance->component[] array (size VCHIQ_MMAL_MAX_COMPONENTS
= 64) without bounds validation. While the kernel generally trusts the
hardware it is bound to, a bounds check here hardens the driver against
potential firmware bugs that could otherwise cause an uncontrolled
out-of-bounds array access and kernel crash.
Add a bounds check on comp_idx before using it as an array index and
move the component pointer assignment after the validation. Use
pr_err_ratelimited() to avoid log flooding. Note: this file does not
currently have access to a struct device, so dev_err() is not available.
Cc: stable@vger.kernel.org
Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index d36ad71cc..9c6533f82 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -477,12 +477,19 @@ static void event_to_host_cb(struct vchiq_mmal_instance *instance,
struct mmal_msg *msg, u32 msg_len)
{
int comp_idx = msg->u.event_to_host.client_component;
- struct vchiq_mmal_component *component =
- &instance->component[comp_idx];
+ struct vchiq_mmal_component *component;
struct vchiq_mmal_port *port = NULL;
struct mmal_msg_context *msg_context;
u32 port_num = msg->u.event_to_host.port_num;
+ if (comp_idx < 0 || comp_idx >= VCHIQ_MMAL_MAX_COMPONENTS) {
+ pr_err_ratelimited("%s: component index %d out of range\n",
+ __func__, comp_idx);
+ return;
+ }
+
+ component = &instance->component[comp_idx];
+
if (msg->u.buffer_from_host.drvbuf.magic == MMAL_MAGIC) {
pr_err("%s: MMAL_MSG_TYPE_BUFFER_TO_HOST with bad magic\n",
__func__);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] staging: vc04_services: vchiq-mmal: prevent stack overflow in port_parameter_set()
From: Sebastian Josue Alba Vives @ 2026-03-29 7:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives, stable
In-Reply-To: <20260329071616.507876-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
port_parameter_set() copies value_size bytes from the caller-supplied
value buffer into the stack-allocated struct mmal_msg's
port_parameter_set.value field, which is u32[96] (384 bytes). There is
no bounds check on value_size before the memcpy.
While current in-tree callers pass small fixed-size structures, the
function is exported via EXPORT_SYMBOL_GPL and accessible to any GPL
kernel module. A caller passing value_size > 384 would overflow the
stack-allocated mmal_msg structure.
Add a bounds check rejecting value_size larger than the value field.
Cc: stable@vger.kernel.org
Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index 44e5246f1..18e805b92 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -1361,6 +1361,14 @@ static int port_parameter_set(struct vchiq_mmal_instance *instance,
struct mmal_msg *rmsg;
struct vchiq_header *rmsg_handle;
+ if (value_size >
+ sizeof(m.u.port_parameter_set.value)) {
+ pr_err_ratelimited("port_parameter_set: value_size %u exceeds max %zu\n",
+ value_size,
+ sizeof(m.u.port_parameter_set.value));
+ return -EINVAL;
+ }
+
m.h.type = MMAL_MSG_TYPE_PORT_PARAMETER_SET;
m.u.port_parameter_set.component_handle = port->component->handle;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] staging: vc04_services: vchiq-mmal: add buffer size check in inline_receive()
From: Sebastian Josue Alba Vives @ 2026-03-29 7:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives, stable
In-Reply-To: <20260329071616.507876-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
inline_receive() copies payload data from a VCHIQ message into a
destination buffer using payload_in_message as the copy length, but
never validates that this length fits within the destination buffer
(msg_context->u.bulk.buffer->buffer_size).
While the caller validates payload_in_message <= MMAL_VC_SHORT_DATA
(128) to prevent overreading the source, the destination buffer may be
smaller than 128 bytes. This is inconsistent with bulk_receive() which
does check buffer_size before copying.
Add a bounds check against buffer_size and truncate the copy length if
it exceeds the destination capacity, matching the defensive pattern used
in bulk_receive(). Use pr_warn_ratelimited() for the truncation warning.
Cc: stable@vger.kernel.org
Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
.../vc04_services/vchiq-mmal/mmal-vchiq.c | 20 ++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index 9c6533f82..44e5246f1 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -368,12 +368,26 @@ static int inline_receive(struct vchiq_mmal_instance *instance,
struct mmal_msg *msg,
struct mmal_msg_context *msg_context)
{
+ u32 payload_len = msg->u.buffer_from_host.payload_in_message;
+
+ /*
+ * Ensure the payload fits within the destination buffer.
+ * The caller already validates payload_len <= MMAL_VC_SHORT_DATA
+ * against the source, but the destination buffer may be smaller.
+ * bulk_receive() performs this check; inline_receive() must too.
+ */
+ if (payload_len > msg_context->u.bulk.buffer->buffer_size) {
+ payload_len = msg_context->u.bulk.buffer->buffer_size;
+ pr_warn_ratelimited("inline_receive: payload truncated (%u > %lu)\n",
+ msg->u.buffer_from_host.payload_in_message,
+ msg_context->u.bulk.buffer->buffer_size);
+ }
+
memcpy(msg_context->u.bulk.buffer->buffer,
msg->u.buffer_from_host.short_data,
- msg->u.buffer_from_host.payload_in_message);
+ payload_len);
- msg_context->u.bulk.buffer_used =
- msg->u.buffer_from_host.payload_in_message;
+ msg_context->u.bulk.buffer_used = payload_len;
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] staging: vc04_services: vchiq-mmal: fix multiple memory safety issues
From: Sebastian Josue Alba Vives @ 2026-03-29 7:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062229.493430-1-sebasjosue84@gmail.com>
Changes since v1:
- Reframed patch 1 as hardening rather than security fix (Greg)
- Switched pr_err/pr_warn to ratelimited variants (Greg)
- Added Cc: stable to all patches (Greg)
- Note: dev_err() not used as this file has no struct device access
This series adds defensive bounds checks to the MMAL VCHIQ driver
which handles multimedia message passing between the ARM CPU and the
VideoCore GPU on all Raspberry Pi models.
Reported-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/4] staging: vc04_services: vchiq-mmal: fix OOB array access in event_to_host_cb()
From: Sebastián Alba @ 2026-03-29 7:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Florian Fainelli, bcm-kernel-feedback-list, linux-staging,
linux-rpi-kernel, linux-arm-kernel, linux-media, Dave Stevenson,
kernel-list
In-Reply-To: <2026032936-deniable-visa-2459@gregkh>
Hi Greg,
> The kernel trusts the hardware the driver is bound to, so this
> shouldn't be happening ever, right?
You're right that the kernel generally trusts hardware it's bound to.
This is a defensive hardening patch - a malformed index from buggy
firmware would currently cause an uncontrolled OOB access, while with
the check we get a clean error return. Happy to reframe the commit
message as hardening rather than a security fix if you prefer.
> No cc: stable?
Will add Cc: stable@vger.kernel.org in v2.
> dev_err() is best, right?
Agreed, will switch to dev_err() in v2. I'll need to thread the
struct device through - will check how other functions in this
file handle it.
> And are you going to allow a malicious hardware device to spam
> the kernel log? :)
Good point, will switch to dev_err_ratelimited() in v2.
I'll send a v2 addressing all of these. Thanks for the review.
Sebastián
El dom, 29 mar 2026 a las 0:35, Greg Kroah-Hartman
(<gregkh@linuxfoundation.org>) escribió:
>
> On Sun, Mar 29, 2026 at 12:21:11AM -0600, Sebastian Josue Alba Vives wrote:
> > From: Sebastián Alba Vives <sebasjosue84@gmail.com>
> >
> > event_to_host_cb() uses msg->u.event_to_host.client_component as an
> > index into the instance->component[] array (size VCHIQ_MMAL_MAX_COMPONENTS
> > = 64) without any bounds validation. The client_component value comes
> > from the VideoCore GPU firmware via VCHIQ message passing.
> >
> > A malicious or buggy GPU firmware could send a crafted
> > MMAL_MSG_TYPE_EVENT_TO_HOST message with client_component >= 64 (or
> > negative), causing an out-of-bounds array access in kernel memory. This
> > results in reading/dereferencing a bogus vchiq_mmal_component structure
> > from memory beyond the array, which can lead to kernel crashes or
> > potentially arbitrary kernel memory access.
>
> The kernel trusts the hardware the driver is bound to, so this shouldn't
> be happening ever, right?
>
> >
> > Add a bounds check on comp_idx before using it as an array index.
> > Move the component pointer assignment after the validation.
> >
> > Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
> > Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
>
> No cc: stable?
>
> > ---
> > drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> > index d36ad71cc..4772126d7 100644
> > --- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> > +++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> > @@ -477,12 +477,19 @@ static void event_to_host_cb(struct vchiq_mmal_instance *instance,
> > struct mmal_msg *msg, u32 msg_len)
> > {
> > int comp_idx = msg->u.event_to_host.client_component;
> > - struct vchiq_mmal_component *component =
> > - &instance->component[comp_idx];
> > + struct vchiq_mmal_component *component;
> > struct vchiq_mmal_port *port = NULL;
> > struct mmal_msg_context *msg_context;
> > u32 port_num = msg->u.event_to_host.port_num;
> >
> > + if (comp_idx < 0 || comp_idx >= VCHIQ_MMAL_MAX_COMPONENTS) {
> > + pr_err("%s: component index %d out of range\n",
> > + __func__, comp_idx);
>
> dev_err() is best, right?
>
> And are you going to allow a malicious hardware device to spam the
> kernel log? :)
>
> thanks,
>
> greg k-h
--
Sebastián Alba
^ permalink raw reply
* Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()
From: Sebastián Alba @ 2026-03-29 7:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Florian Fainelli, bcm-kernel-feedback-list, linux-staging,
linux-rpi-kernel, linux-arm-kernel, Dave Stevenson, kernel-list
In-Reply-To: <2026032956-railroad-renewable-3328@gregkh>
Hi Greg, Thanks for the quick review.
Regarding kmalloc_array(): the patch does replace kmalloc() with
kmalloc_array() - perhaps the question is about the remaining
ioparam.op_count * sizeof(*block) in the copy_from_user() call below?
That multiplication is now safe because kmalloc_array() already
verified that op_count * sizeof(*block) does not overflow(if it did,
kmalloc_array would have returned NULL and we'd have exited). Happy to
add a comment clarifying this if you prefer.
Regarding the Fixes tag: the commit dfdc7a773374 is from the
raspberrypi/linux tree (branch rpi-6.6.y). This driver (vc-sm-cma)
appears to only exist in the Raspberry Pi kernel fork and has not been
merged into mainline staging.
I apologize for sending this to the wrong tree. Should these patches
go directly to the Raspberry Pi kernel maintainers
(kernel-list@raspberrypi.com) instead?
El dom, 29 mar 2026 a las 0:33, Greg Kroah-Hartman
(<gregkh@linuxfoundation.org>) escribió:
>
> On Sun, Mar 29, 2026 at 12:18:45AM -0600, Sebastian Josue Alba Vives wrote:
> > From: Sebastián Alba Vives <sebasjosue84@gmail.com>
> >
> > vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
> > compute the allocation size passed to kmalloc(). Since ioparam.op_count
> > is a __u32 supplied directly by userspace via ioctl, an attacker can
> > choose a value that causes the multiplication to overflow on 32-bit
> > platforms, resulting in a small allocation followed by a large
> > copy_from_user() and out-of-bounds heap reads in the subsequent loop.
> >
> > Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
> > Also add an early return for op_count == 0 to avoid a zero-size
> > allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
> > correctly indicate out of memory.
>
> Why not use kmalloc_array() instead?
>
> >
> > The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
> > reachable by any unprivileged local user.
> >
> > Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
>
> I do not see that git id anywhere, what tree is it in?
>
> thanks,
>
> greg k-h
--
Sebastián Alba
^ permalink raw reply
* Re: [PATCH 1/4] staging: vc04_services: vchiq-mmal: fix OOB array access in event_to_host_cb()
From: Greg Kroah-Hartman @ 2026-03-29 6:35 UTC (permalink / raw)
To: Sebastian Josue Alba Vives
Cc: Florian Fainelli, bcm-kernel-feedback-list, linux-staging,
linux-rpi-kernel, linux-arm-kernel, linux-media, Dave Stevenson,
kernel-list
In-Reply-To: <20260329062229.493430-2-sebasjosue84@gmail.com>
On Sun, Mar 29, 2026 at 12:21:11AM -0600, Sebastian Josue Alba Vives wrote:
> From: Sebastián Alba Vives <sebasjosue84@gmail.com>
>
> event_to_host_cb() uses msg->u.event_to_host.client_component as an
> index into the instance->component[] array (size VCHIQ_MMAL_MAX_COMPONENTS
> = 64) without any bounds validation. The client_component value comes
> from the VideoCore GPU firmware via VCHIQ message passing.
>
> A malicious or buggy GPU firmware could send a crafted
> MMAL_MSG_TYPE_EVENT_TO_HOST message with client_component >= 64 (or
> negative), causing an out-of-bounds array access in kernel memory. This
> results in reading/dereferencing a bogus vchiq_mmal_component structure
> from memory beyond the array, which can lead to kernel crashes or
> potentially arbitrary kernel memory access.
The kernel trusts the hardware the driver is bound to, so this shouldn't
be happening ever, right?
>
> Add a bounds check on comp_idx before using it as an array index.
> Move the component pointer assignment after the validation.
>
> Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
> Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
No cc: stable?
> ---
> drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> index d36ad71cc..4772126d7 100644
> --- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> +++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> @@ -477,12 +477,19 @@ static void event_to_host_cb(struct vchiq_mmal_instance *instance,
> struct mmal_msg *msg, u32 msg_len)
> {
> int comp_idx = msg->u.event_to_host.client_component;
> - struct vchiq_mmal_component *component =
> - &instance->component[comp_idx];
> + struct vchiq_mmal_component *component;
> struct vchiq_mmal_port *port = NULL;
> struct mmal_msg_context *msg_context;
> u32 port_num = msg->u.event_to_host.port_num;
>
> + if (comp_idx < 0 || comp_idx >= VCHIQ_MMAL_MAX_COMPONENTS) {
> + pr_err("%s: component index %d out of range\n",
> + __func__, comp_idx);
dev_err() is best, right?
And are you going to allow a malicious hardware device to spam the
kernel log? :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()
From: Greg Kroah-Hartman @ 2026-03-29 6:33 UTC (permalink / raw)
To: Sebastian Josue Alba Vives
Cc: Florian Fainelli, bcm-kernel-feedback-list, linux-staging,
linux-rpi-kernel, linux-arm-kernel, Dave Stevenson, kernel-list
In-Reply-To: <20260329062004.492812-2-sebasjosue84@gmail.com>
On Sun, Mar 29, 2026 at 12:18:45AM -0600, Sebastian Josue Alba Vives wrote:
> From: Sebastián Alba Vives <sebasjosue84@gmail.com>
>
> vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
> compute the allocation size passed to kmalloc(). Since ioparam.op_count
> is a __u32 supplied directly by userspace via ioctl, an attacker can
> choose a value that causes the multiplication to overflow on 32-bit
> platforms, resulting in a small allocation followed by a large
> copy_from_user() and out-of-bounds heap reads in the subsequent loop.
>
> Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
> Also add an early return for op_count == 0 to avoid a zero-size
> allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
> correctly indicate out of memory.
Why not use kmalloc_array() instead?
>
> The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
> reachable by any unprivileged local user.
>
> Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
I do not see that git id anywhere, what tree is it in?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 4/4] staging: vc04_services: vchiq-mmal: fix integer underflow in port_parameter_get()
From: Sebastian Josue Alba Vives @ 2026-03-29 6:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062229.493430-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
port_parameter_get() subtracts 2 * sizeof(u32) from the GPU firmware's
reply size field to compute the parameter value size. The reply size is
a u32 provided by the VideoCore firmware. If the firmware returns a
size smaller than 8, the subtraction wraps around to a large value due
to unsigned integer underflow.
The underflowed size is then:
1) Used in a comparison that selects the wrong copy path
2) Stored back to the caller via *value_size, propagating a bogus
size (up to ~4GB) to subsequent operations
Add a minimum size check before the subtraction and return -EPROTO if
the reply is malformed.
Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index 11af71309..914ab9215 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -1436,6 +1436,10 @@ static int port_parameter_get(struct vchiq_mmal_instance *instance,
/* port_parameter_get_reply.size includes the header,
* whilst *value_size doesn't.
*/
+ if (rmsg->u.port_parameter_get_reply.size < (2 * sizeof(u32))) {
+ ret = -EPROTO;
+ goto release_msg;
+ }
rmsg->u.port_parameter_get_reply.size -= (2 * sizeof(u32));
if (ret || rmsg->u.port_parameter_get_reply.size > *value_size) {
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] staging: vc04_services: vchiq-mmal: prevent stack overflow in port_parameter_set()
From: Sebastian Josue Alba Vives @ 2026-03-29 6:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062229.493430-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
port_parameter_set() copies value_size bytes from the caller-supplied
value buffer into the stack-allocated struct mmal_msg's
port_parameter_set.value field, which is u32[96] (384 bytes). There is
no bounds check on value_size before the memcpy.
While current in-tree callers pass small fixed-size structures, the
function is exported via EXPORT_SYMBOL_GPL and accessible to any GPL
kernel module. A caller passing value_size > 384 would overflow the
stack-allocated mmal_msg structure, potentially leading to stack
corruption and code execution.
Add a bounds check rejecting value_size larger than the value field.
Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index e18471930..11af71309 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -1361,6 +1361,14 @@ static int port_parameter_set(struct vchiq_mmal_instance *instance,
struct mmal_msg *rmsg;
struct vchiq_header *rmsg_handle;
+ if (value_size >
+ sizeof(m.u.port_parameter_set.value)) {
+ pr_err("port_parameter_set: value_size %u exceeds max %zu\n",
+ value_size,
+ sizeof(m.u.port_parameter_set.value));
+ return -EINVAL;
+ }
+
m.h.type = MMAL_MSG_TYPE_PORT_PARAMETER_SET;
m.u.port_parameter_set.component_handle = port->component->handle;
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] staging: vc04_services: vchiq-mmal: add buffer size check in inline_receive()
From: Sebastian Josue Alba Vives @ 2026-03-29 6:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062229.493430-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
inline_receive() copies payload data from a VCHIQ message into a
destination buffer using payload_in_message as the copy length, but
never validates that this length fits within the destination buffer
(msg_context->u.bulk.buffer->buffer_size).
While the caller validates payload_in_message <= MMAL_VC_SHORT_DATA
(128) to prevent overreading the source, the destination buffer may be
smaller than 128 bytes. This is inconsistent with bulk_receive() which
does check buffer_size before copying. A VideoCore GPU sending a short
inline payload to a smaller destination buffer would cause a heap buffer
overflow in kernel memory.
Add a bounds check against buffer_size and truncate the copy length if
it exceeds the destination capacity, matching the defensive pattern used
in bulk_receive().
Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
.../vc04_services/vchiq-mmal/mmal-vchiq.c | 20 ++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index 4772126d7..e18471930 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -368,12 +368,26 @@ static int inline_receive(struct vchiq_mmal_instance *instance,
struct mmal_msg *msg,
struct mmal_msg_context *msg_context)
{
+ u32 payload_len = msg->u.buffer_from_host.payload_in_message;
+
+ /*
+ * Ensure the payload fits within the destination buffer.
+ * The caller already validates payload_len <= MMAL_VC_SHORT_DATA
+ * against the source, but the destination buffer may be smaller.
+ * bulk_receive() performs this check; inline_receive() must too.
+ */
+ if (payload_len > msg_context->u.bulk.buffer->buffer_size) {
+ payload_len = msg_context->u.bulk.buffer->buffer_size;
+ pr_warn("inline_receive: payload truncated (%u > %lu)\n",
+ msg->u.buffer_from_host.payload_in_message,
+ msg_context->u.bulk.buffer->buffer_size);
+ }
+
memcpy(msg_context->u.bulk.buffer->buffer,
msg->u.buffer_from_host.short_data,
- msg->u.buffer_from_host.payload_in_message);
+ payload_len);
- msg_context->u.bulk.buffer_used =
- msg->u.buffer_from_host.payload_in_message;
+ msg_context->u.bulk.buffer_used = payload_len;
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 1/4] staging: vc04_services: vchiq-mmal: fix OOB array access in event_to_host_cb()
From: Sebastian Josue Alba Vives @ 2026-03-29 6:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062229.493430-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
event_to_host_cb() uses msg->u.event_to_host.client_component as an
index into the instance->component[] array (size VCHIQ_MMAL_MAX_COMPONENTS
= 64) without any bounds validation. The client_component value comes
from the VideoCore GPU firmware via VCHIQ message passing.
A malicious or buggy GPU firmware could send a crafted
MMAL_MSG_TYPE_EVENT_TO_HOST message with client_component >= 64 (or
negative), causing an out-of-bounds array access in kernel memory. This
results in reading/dereferencing a bogus vchiq_mmal_component structure
from memory beyond the array, which can lead to kernel crashes or
potentially arbitrary kernel memory access.
Add a bounds check on comp_idx before using it as an array index.
Move the component pointer assignment after the validation.
Fixes: b18ee53ad297 ("staging: bcm2835: Break MMAL support out from camera")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index d36ad71cc..4772126d7 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -477,12 +477,19 @@ static void event_to_host_cb(struct vchiq_mmal_instance *instance,
struct mmal_msg *msg, u32 msg_len)
{
int comp_idx = msg->u.event_to_host.client_component;
- struct vchiq_mmal_component *component =
- &instance->component[comp_idx];
+ struct vchiq_mmal_component *component;
struct vchiq_mmal_port *port = NULL;
struct mmal_msg_context *msg_context;
u32 port_num = msg->u.event_to_host.port_num;
+ if (comp_idx < 0 || comp_idx >= VCHIQ_MMAL_MAX_COMPONENTS) {
+ pr_err("%s: component index %d out of range\n",
+ __func__, comp_idx);
+ return;
+ }
+
+ component = &instance->component[comp_idx];
+
if (msg->u.buffer_from_host.drvbuf.magic == MMAL_MAGIC) {
pr_err("%s: MMAL_MSG_TYPE_BUFFER_TO_HOST with bad magic\n",
__func__);
--
2.43.0
^ permalink raw reply related
* [PATCH 0/4] staging: vc04_services: vchiq-mmal: fix multiple memory safety issues
From: Sebastian Josue Alba Vives @ 2026-03-29 6:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, linux-media, Dave Stevenson, kernel-list,
Sebastián Alba Vives
This series fixes four memory safety issues in the MMAL VCHIQ driver
which handles multimedia message passing between the ARM CPU and the
VideoCore GPU on all Raspberry Pi models.
Patch 1: OOB array access in event_to_host_cb()
Patch 2: Missing buffer size check in inline_receive()
Patch 3: Missing bounds check in port_parameter_set()
Patch 4: Integer underflow in port_parameter_get()
All four issues affect both ARM32 and ARM64 Raspberry Pi kernels.
Found through manual source code auditing.
I would like to request separate CVE assignments for each
independently exploitable vulnerability.
Reported-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
^ permalink raw reply
* [PATCH 2/2] staging: vc04_services: vc-sm-cma: add address validation in clean_invalid_contig_2d()
From: Sebastian Josue Alba Vives @ 2026-03-29 6:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062004.492812-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
clean_invalid_contig_2d() performs cache maintenance operations
(dmac_inv_range, dmac_clean_range, dmac_flush_range) on a user-supplied
virtual address without verifying that it falls within the user address
space. A local attacker can pass a kernel virtual address via the
VC_SM_CMA_CMD_CLEAN_INVALID2 ioctl, causing the kernel to execute cache
maintenance operations on arbitrary kernel memory, potentially leading
to data corruption or information disclosure.
Add access_ok() validation to verify the entire address range falls
within userspace before performing any cache operations. Also add
overflow checks using check_mul_overflow()/check_add_overflow() for the
range computation to prevent size_t wraparound.
The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
reachable by any unprivileged local user on 32-bit Raspberry Pi
kernels.
Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
.../staging/vc04_services/vc-sm-cma/vc_sm.c | 21 ++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
index d597d41b4..29aa5a939 100644
--- a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
+++ b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
@@ -40,6 +40,7 @@
#include <linux/module.h>
#include <linux/mm.h>
#include <linux/of_device.h>
+#include <linux/overflow.h>
#include <linux/platform_device.h>
#include <linux/proc_fs.h>
#include <linux/slab.h>
@@ -1263,6 +1264,8 @@ static int clean_invalid_contig_2d(const void __user *addr,
const unsigned int cache_op)
{
size_t i;
+ size_t last_block_offset;
+ size_t total_range;
void (*op_fn)(const void *start, const void *end);
if (!block_size) {
@@ -1270,11 +1273,27 @@ static int clean_invalid_contig_2d(const void __user *addr,
return -EINVAL;
}
+ if (!block_count)
+ return 0;
+
op_fn = cache_op_to_func(cache_op);
if (!op_fn)
return -EINVAL;
- for (i = 0; i < block_count; i ++, addr += stride)
+ /*
+ * Validate that the entire user-supplied address range falls
+ * within userspace. Without this check, an attacker could
+ * invoke cache maintenance operations on kernel addresses.
+ */
+ if (check_mul_overflow((size_t)(block_count - 1), stride,
+ &last_block_offset))
+ return -EOVERFLOW;
+ if (check_add_overflow(last_block_offset, block_size, &total_range))
+ return -EOVERFLOW;
+ if (!access_ok(addr, total_range))
+ return -EFAULT;
+
+ for (i = 0; i < block_count; i++, addr += stride)
op_fn(addr, addr + block_size);
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()
From: Sebastian Josue Alba Vives @ 2026-03-29 6:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, Dave Stevenson, kernel-list,
Sebastián Alba Vives
In-Reply-To: <20260329062004.492812-1-sebasjosue84@gmail.com>
From: Sebastián Alba Vives <sebasjosue84@gmail.com>
vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
compute the allocation size passed to kmalloc(). Since ioparam.op_count
is a __u32 supplied directly by userspace via ioctl, an attacker can
choose a value that causes the multiplication to overflow on 32-bit
platforms, resulting in a small allocation followed by a large
copy_from_user() and out-of-bounds heap reads in the subsequent loop.
Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
Also add an early return for op_count == 0 to avoid a zero-size
allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
correctly indicate out of memory.
The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
reachable by any unprivileged local user.
Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
drivers/staging/vc04_services/vc-sm-cma/vc_sm.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
index 34155d62a..d597d41b4 100644
--- a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
+++ b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
@@ -1292,9 +1292,13 @@ static int vc_sm_cma_clean_invalid2(unsigned int cmdnr, unsigned long arg)
__func__, cmdnr);
return -EFAULT;
}
- block = kmalloc(ioparam.op_count * sizeof(*block), GFP_KERNEL);
+
+ if (!ioparam.op_count)
+ return 0;
+
+ block = kmalloc_array(ioparam.op_count, sizeof(*block), GFP_KERNEL);
if (!block)
- return -EFAULT;
+ return -ENOMEM;
if (copy_from_user(block, (void *)(arg + sizeof(ioparam)),
ioparam.op_count * sizeof(*block)) != 0) {
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] staging: vc04_services: vc-sm-cma: fix security issues in clean_invalid2 ioctl
From: Sebastian Josue Alba Vives @ 2026-03-29 6:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Florian Fainelli
Cc: bcm-kernel-feedback-list, linux-staging, linux-rpi-kernel,
linux-arm-kernel, Dave Stevenson, kernel-list,
Sebastián Alba Vives
This series fixes two security issues in the VideoCore shared memory CMA
driver (vc-sm-cma), accessible via /dev/vc-sm-cma which is created with
mode 0666 (world-accessible, no authentication required).
Both bugs are in vc_sm_cma_clean_invalid2(), reachable via the
VC_SM_CMA_CMD_CLEAN_INVALID2 ioctl on 32-bit ARM kernels.
Patch 1: Integer overflow in kmalloc size computation
Patch 2: Missing address validation in cache maintenance operations
Both issues affect 32-bit Raspberry Pi kernels (RPi 1/2/3/Zero and
32-bit RPi 4/5 configurations) running the rpi-6.6.y kernel series.
Both issues were found through manual source code auditing.
I would like to request separate CVE assignments for each patch as they
are independent vulnerabilities.
Reported-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-1-krishnagopi487@gmail.com>
st,thermal-flags is a required property in SPEAr Thermal Sensor node,
which is incorrectly written as thermal_flags in spear13xx.dtsi.
Rename thermal_flags to st,thermal-flags to fix the property name
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v1:
- Reword the commit message and subject
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
arch/arm/boot/dts/st/spear13xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 159e941708ca..97357680dd51 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -332,7 +332,7 @@ wdt@ec800620 {
thermal@e07008c4 {
compatible = "st,thermal-spear1340";
reg = <0xe07008c4 0x4>;
- thermal_flags = <0x7000>;
+ st,thermal-flags = <0x7000>;
};
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329061523.98346-1-krishnagopi487@gmail.com>
Convert the SPEAr Thermal Sensor bindings to DT schema.
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
---
Changes since v1:
- Changed unevaluatedProperties to additionalProperties
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
2 files changed, 36 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
diff --git a/Documentation/devicetree/bindings/thermal/spear-thermal.txt b/Documentation/devicetree/bindings/thermal/spear-thermal.txt
deleted file mode 100644
index 93e3b67c102d..000000000000
--- a/Documentation/devicetree/bindings/thermal/spear-thermal.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* SPEAr Thermal
-
-Required properties:
-- compatible : "st,thermal-spear1340"
-- reg : Address range of the thermal registers
-- st,thermal-flags: flags used to enable thermal sensor
-
-Example:
-
- thermal@fc000000 {
- compatible = "st,thermal-spear1340";
- reg = <0xfc000000 0x1000>;
- st,thermal-flags = <0x7000>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
new file mode 100644
index 000000000000..e3462a974691
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPEAr Thermal Sensor
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+
+properties:
+ compatible:
+ const: st,thermal-spear1340
+
+ reg:
+ maxItems: 1
+
+ st,thermal-flags:
+ description: flags used to enable thermal sensor
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - st,thermal-flags
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal@fc000000 {
+ compatible = "st,thermal-spear1340";
+ reg = <0xfc000000 0x1000>;
+ st,thermal-flags = <0x7000>;
+ };
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Gopi Krishna Menon @ 2026-03-29 6:15 UTC (permalink / raw)
To: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt
Cc: Gopi Krishna Menon, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
This patch series converts SPEAr Thermal Sensor bindings to DT schema
and corrects the thermal_flags property in spear13xx.dtsi to
st,thermal-flags.
Changes since v1:
- Changed unevaluatedProperties to additionalProperties in the binding
- Reword the commit message and subject in the second patch
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
Gopi Krishna Menon (2):
dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
ARM: dts: st: spear: rename thermal_flags to st,thermal-flags
.../bindings/thermal/spear-thermal.txt | 14 --------
.../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
arch/arm/boot/dts/st/spear13xx.dtsi | 2 +-
3 files changed, 37 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
--
2.52.0
^ 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