Re: [PATCH 3/3] riscv: dts: spacemit: Add Milk-V Jupiter board (M1)
Aurelien Jarno <[email protected]> Wed, 29 Jul 2026 11:40:57 +0200
| Newsgroups | dev.linux.lists.spacemit,dev.linux.lists.sashiko-reviews,org.infradead.lists.linux-riscv,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 2026-07-28 21:28, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > - [Medium] Missing unique board-specific `compatible` string for the M1 Jupiter board variant, which inherits the identical compatible string as the K1 variant and breaks DTB matching. > -- > > --- Patch [3]: [PATCH 3/3] riscv: dts: spacemit: Add Milk-V Jupiter board (M1) --- > commit 2d54397a3a4baaa8a2eee569d6fe3f912a3c7661 > Author: Aurelien Jarno <[email protected]> > > riscv: dts: spacemit: Add Milk-V Jupiter board (M1) > > This commit adds support for the Milk-V Jupiter board with the M1 CPU. > The M1 is similar to the K1 but allows running at up to 1.8 GHz, adding > a new device tree and an OPP table for this higher frequency. > > > diff --git a/arch/riscv/boot/dts/spacemit/m1-milkv-jupiter.dts b/arch/riscv/boot/dts/spacemit/m1-milkv-jupiter.dts > > new file mode 100644 > > index 0000000000000..32e1468385ca0 > > --- /dev/null > > +++ b/arch/riscv/boot/dts/spacemit/m1-milkv-jupiter.dts > > @@ -0,0 +1,11 @@ > > +// SPDX-License-Identifier: GPL-2.0 OR MIT > > +/* > > + * Copyright (C) 2026 Aurelien Jarno <[email protected]> > > + */ > > + > > +#include "k1-milkv-jupiter-common.dtsi" > > +#include "m1-opp.dtsi" > > + > > +/ { > > + model = "Milk-V Jupiter (M1)"; > > [Severity: Medium] > Since m1-milkv-jupiter.dts includes k1-milkv-jupiter-common.dtsi, does this > board inherit the identical root compatible string as the K1 variant? > > If a bootloader like U-Boot uses a FIT image containing both DTBs, it relies > on the root compatible string to select the correct one. If they are > identical, could the bootloader mistakenly apply this M1 DTB to a K1 board? > > If that happens, would the K1 board be allowed to run at the 1.8 GHz > operating point defined here, potentially causing instability or hardware > damage since it is only rated for 1.6 GHz? > > Should a unique board-specific compatible string be added to this root node > to uniquely identify the M1 board hardware? > > > +}; That's a valid point, I'll fix that in the next version. I believe we want to keep the spacemit,k1 compatible even with the m1, as the difference is rather a property of the board and not the SoC. What could be the compatible for the board? "milkv,jupiter-m1"? Maybe the existing board should have been called "milkv,jupiter-k1"... -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net