> On 24.10.25 18:58, E Shattow wrote: > Hi Hal, this is very good, I have some suggestion to improve more. > > On 10/24/25 01:59, Hal Feng wrote: > > > /****************************************************************/ > > This patch picked from [1] is just for test and can be ignored. > > dts/upstream should be synced regularly with devicetree-rebasing. > > > > [1] > > https://lore.kernel.org/all/20250821100930.71404-1-hal.feng@starfivete > > ch.com/ > > > /****************************************************************/ > > > > VisionFive 2 Lite is a mini SBC based on the StarFive JH7110S SoC. > > > > Board features: > > - JH7110S SoC > > - 2/4/8 GiB LPDDR4 DRAM > > - AXP15060 PMIC > > - 40 pin GPIO header > > - 1x USB 3.0 host port > > - 3x USB 2.0 host port > > - 1x M.2 M-Key (size: 2242) > > - 1x MicroSD slot (optional non-removable eMMC) > > - 1x QSPI Flash > > - 1x I2C EEPROM > > - 1x 1Gbps Ethernet port > > - SDIO-based Wi-Fi & UART-based Bluetooth > > - 1x HDMI port > > - 1x 2-lane DSI > > - 1x 2-lane CSI > > > > Signed-off-by: Hal Feng <[email protected]> > > --- > > .../jh7110s-starfive-visionfive-2-lite.dts | 159 ++++++++++++++++++ > > 1 file changed, 159 insertions(+) > > create mode 100644 > > dts/upstream/src/riscv/starfive/jh7110s-starfive-visionfive-2-lite.dts > > > > diff --git > > a/dts/upstream/src/riscv/starfive/jh7110s-starfive-visionfive-2-lite.d > > ts > > b/dts/upstream/src/riscv/starfive/jh7110s-starfive-visionfive-2-lite.d > > ts > > new file mode 100644 > > index 00000000000..30842b0cd1f > > --- /dev/null > > +++ b/dts/upstream/src/riscv/starfive/jh7110s-starfive-visionfive-2-li > > +++ te.dts > > @@ -0,0 +1,159 @@ > > +// SPDX-License-Identifier: GPL-2.0 OR MIT > > +/* > > + * Copyright (C) 2025 StarFive Technology Co., Ltd. > > + * Copyright (C) 2025 Hal Feng <[email protected]> */ > > + > > +/dts-v1/; > > +#include "jh7110-common.dtsi" > > + > > +/ { > > + model = "StarFive VisionFive 2 Lite"; > > + compatible = "starfive,visionfive-2-lite", "starfive,jh7110s"; }; > ... > > FYI as a follow-up to my earlier comments about modifying the dts subtree I > have now a working recommendation: > > 1). Return to using "RFC" subject prefix for the series while any modification > exists to dts subtree. The comment said about this is do not post any "DO > NOT MERGE" type patches that touch dts subtree, however... > > 2). Additions to CONFIG_OF_LIST will cause a build error if there is not any > corresponding file in the dts subtree. Use a workaround: > > git mv > dts/upstream/src/riscv/starfive/jh7110s-starfive-visionfive-2-lite.dts > arch/riscv/dts/jh7110s-starfive-visionfive-2-lite-u-boot.dtsi > touch dts/upstream/src/riscv/starfive/jh7110s-starfive-visionfive-2-lite.dts > git add > dts/upstream/src/riscv/starfive/jh7110s-starfive-visionfive-2-lite.dts > arch/riscv/dts/jh7110s-starfive-visionfive-2-lite-u-boot.dtsi
Thank you for providing another way to deal with this situation. With your method, 1. The situation will be more complicated in this patch, because I try to modify the common dtsi (jh7110-common.dtsi). 2. The maintainers have to revert the temporary device trees we added in arch/riscv/dts/ after the same device trees appear in dts/upstream/src/riscv/starfive/. It will bring more work to the OF_UPSTREAM maintainers. I think it may be easier for maintainers to merge the u-boot patches after the Linux device trees has already appeared in dts/upstream/. > > Alternatively for your local development environment: > > echo '#include > "/path/to/linux.git/arch/riscv/boot/dts/starfive/jh7110s-starfive-visionfive-2- > lite-u-boot.dtsi"' Maybe you mean "/path/to/linux.git/arch/riscv/boot/dts/starfive/jh7110s-starfive-visionfive-2-lite.dts" > > arch/riscv/dts/jh7110s-starfive-visionfive-2-lite-u-boot.dtsi > > This "-u-boot.dtsi" suffix file will get picked up by the build system > automatically when there is a corresponding file (empty file is okay) in dts > subtree. The empty file in dts subtree is a simple git file operation with no > actual content. It is not perfect as an answer but it is better for the review > now, and for anyone else reading this that may want to do the same. > > You can see this in the working example of RFC v1 series for Milk-V Mars CM > re-introduction: > > https://lore.kernel.org/u-boot/[email protected]/ > > and the follow-up as v2 series as this lands in devicetree-rebasing: > > https://lore.kernel.org/u-boot/[email protected]/ > > I hope that is a good example to follow for v3, v4 of your series > > 3). If you follow RFC -> PATCH -> RFC the version does increment (RFC v1, > PATCH v2, RFC v3, ...) Thanks for your suggestions. Best regards, Hal
