Hi Rong An,
On 10/1/26 8:14 AM, 安容 wrote:
Hi here,
I would like to add U-Boot support for the FriendlyElec NanoPi R28S
(https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R28S), a
dual gigabit Ethernet router board based on the Rockchip RK3528, and
Looking forward to the patches!
would like to ask how to handle its devicetree dependency before I send
the patches.
The Linux devicetree for the board has been applied to the Rockchip
tree for v7.4, together with a patch that splits the parts shared with
the NanoPi Zero2 into a common rk3528-nanopi.dtsi:
fdb087806e80 ("arm64: dts: rockchip: Split out the common NanoPi RK3528
parts")
c1e23f3425c4 ("arm64: dts: rockchip: Add devicetree for the FriendlyElec NanoPi
R28S")
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v7.4-armsoc/dts64
Neither commit is in dts/upstream yet, and they will not be in a Linux
release until v7.4-rc1.
I have a two patch series ready on top of master
(c92d8c3c431e37a17c3b37918037dbd7ade32d1e):
1. rockchip: rk3528: Split out common NanoPi u-boot.dtsi
Moves the vdd_arm/vdd_logic regulator-init-microvolt overrides of
the NanoPi Zero2 into a common rk3528-nanopi-u-boot.dtsi, following
the split in Linux. No functional change, no dependency.
2. board: rockchip: Add FriendlyElec NanoPi R28S
Adds rk3528-nanopi-r28s-u-boot.dtsi (only includes the common
file), nanopi-r28s-rk3528_defconfig (the Zero2 defconfig plus
CONFIG_BUTTON_GPIO for the reset button) and a line in
doc/board/rockchip/rockchip.rst. It needs the R28S devicetree in
dts/upstream to build.
I build-tested both nanopi-r28s-rk3528 and nanopi-zero2-rk3528 with
the devicetree files from v7.4-armsoc/dts64 copied into dts/upstream.
My questions:
- Would you take patch 2 now, or should I wait until dts/upstream is
synced to a release that contains the commits above and send it
then?
"No" to the first part of the question. "Not necessarily" to the second
part of the question as you can cherry-pick commits from
devicetree-rebasing before we do a sync. This is your only option,
barring asking Tom to do a dts/upstream sync (nobody else is allowed to
do it).
- Alternatively, is it acceptable to pick the two devicetree commits
into dts/upstream early, once they are in a Linux tag that
devicetree-rebasing follows (v7.4-rc1)?
They don't need to be in a tag, I think I've seen devicetree-rebasing
sometimes pulling master early, but they do need to be available in that
repo yes. In which case, you are allowed to pick the commits with
tools/update-subtree.sh pick <commit>
- Can patch 1 be sent and merged on its own in the meantime?
Not available in devicetree-rebasing yet, so the answer is unfortunately no.
And, unfortunately, proton mail does not provide SMTP for free user. So I can't
send the patch myself.
https://b4.docs.kernel.org/en/latest/contributor/send.html#authenticating-with-the-web-submission-endpoint
should allow you to send patches with b4 without your own SMTP server. I
have not had to use this yet but I believe some people in the community do.
I have seen some proton.me senders for patches, are you implying they
are all paying to be able to send patches? (I know proton is not great
for sending patches, see https://mamot.fr/@ploum/117285599520702326 for
example; https://git-send-email.io suggests some tools but they do
advise to switch to a different mail provider).
In the meanwhile, if you have patches that aren't device trees, you can
send them now so we can review them (cherry-picks to dts/upstream are
usually straight forward and usually don't require multiple versions)
and you can have support for this board as soon as possible once the
commits are available in devicetree-rebasing.
Cheers,
Quentin
