mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Diederik de Haas" <diederik@cknow-tech.com>
To: <HystericalDragons@proton.me>, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Heiko Stuebner" <heiko@sntech.de>
Cc: <devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-rockchip@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, "Chukun Pan" <amadeus@jmu.edu.cn>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"jensen" <jensenhuang@friendlyarm.com>,
	"Andrey Korshunov" <razor1702@gmail.com>,
	"Diederik de Haas" <diederik@cknow-tech.com>,
	"Conor Dooley" <conor.dooley@microchip.com>
Subject: Re: [PATCH v5 0/4] arm64: dts: rockchip: Add FriendlyElec NanoPi R28S
Date: Mon, 14 Sep 2026 10:58:44 +0200	[thread overview]
Message-ID: <DLEWYVCME40R.L2IMBIU3ILG1@cknow-tech.com> (raw)
In-Reply-To: <20260914-r28s-upstream-v5-0-7409c498e8dc@proton.me>

On Mon Sep 14, 2026 at 10:24 AM CEST, 安容 via B4 Relay wrote:
> The NanoPi R28S is a dual gigabit Ethernet router board based on the
> Rockchip RK3528 SoC:
>
>   https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R28S
>
> It is closely related to the already supported NanoPi Zero2, sharing
> most of its power tree and peripheral routing. Patch 2 therefore moves
> the common parts into rk3528-nanopi.dtsi, and patch 3 adds the board on
> top of it. The split leaves the NanoPi Zero2 dtb unchanged; I verified
> this by comparing the node and property sets of the dtb before and after
> the split, which differ only in node order and phandle numbering. Patch
> 4 is a coding style cleanup in the shared devicetree and the NanoPi
> Zero2 devicetree.
>
> The devicetree was derived from the vendor tree:
>
>   https://github.com/friendlyarm/kernel-rockchip/commit/ee640c5344b13a0a317436e2357df01af8268ce7
>
> but with many changes to make it suitable for mainline.
>
> Tested on a metal-case unit without the optional onboard eMMC: boots
> from microSD, both Ethernet ports link up at 1000 Mbps, the HYM8563 RTC
> registers, and all three LEDs are functional. The USB Type-C connector
> registers as a DWC3 UDC in peripheral mode; gadget enumeration against
> a USB host was not completed, because that connector is also the 5V
> input and a PC port cannot power the board.
>
> The bootloader was U-Boot 2026.07 with a board specific R28S target,
> which releases the RGMII PHY reset before Linux starts, so the reset
> description in the PHY node is all the kernel needs.
>
> Two things I did not do, because my hardware cannot verify them:
>
> - The AICSemi AIC8800D80 WiFi chip on sdio0 has no upstream driver, so
>   only the SDIO controller is described.
> - The eMMC is described as HS200 rather than the vendor's HS400 with
>   enhanced strobe, since the board at hand has an unpopulated eMMC
>   footprint and the faster modes could not be verified.
>
> ---
> Changes in v5:
> - Dropped the pinctrl-0 before pinctrl-names reordering from the coding
>   style patch and used the order the rest of the rockchip devicetrees
>   use, pinctrl-names first, in the new devicetree as well. The strict
>   mode of scripts/dtc/dt-check-style asks for the alphabetical order,
>   but it does so for many other properties that no rockchip devicetree
>   sorts that way either (Chukun Pan).

Then you can also just drop patch 4 as (by far) most rockchip devicetrees
do not have a blank line before ``status = <okay>;``

> - Moved the SYS LED, which the NanoPi R28S shares with the NanoPi Zero2,
>   and the led1 and led_sys pin configurations into rk3528-nanopi.dtsi.
>   Both boards now only add their own LEDs to &leds (Chukun Pan).
> - Renamed the NanoPi R28S LED nodes to led-1 and led-2, to use the
>   led-[0-9] node naming (Chukun Pan).
> - Changed the user button from KEY_RESTART to BTN_1. It is a general
>   purpose button on this board, not a reset button (Chukun Pan).
> - Link to v4: https://patch.msgid.link/20260911-r28s-upstream-v4-0-fb6c85f226d4@proton.me
>
> Changes in v4:
> - Dropped the patch that moved the NanoPi Zero2 RGMII PHY reset to the
>   MDIO bus. GPIO4_C2 resets the PHY, not the bus, so describing it on
>   &mdio1 is not a description of the hardware. It would also break
>   Ethernet in U-Boot, which reads reset-gpios, reset-assert-us and
>   reset-deassert-us from the PHY node and has no support for a bus
>   level reset. The nanopi-zero2-rk3528 U-Boot target releases the PHY
>   reset before Linux starts; the failure I reported was seen with the
>   generic-rk3528 target, which carries no board devicetree. Pointed out
>   by Chukun Pan, and by Jonas Karlman in the same discussion for the
>   HINLINK H28K:
>   https://lore.kernel.org/lkml/1e8da54f-ef87-4d31-9a0a-17c0ff66bee0@kwiboo.se/
>   My own R28S has in fact been running a board specific U-Boot target
>   all along, with the PHY node description this series now keeps, so
>   the reset ordering problem I described does not arise there.
> - Reworded the coding style patch to state the coding style violation
>   itself as the reason, rather than the tool that found it (Diederik de
>   Haas).
> - Link to v3: https://patch.msgid.link/20260909-r28s-upstream-v3-0-ee3e1a34a353@proton.me
>
> Changes in v3:
> - New patch 1: describe the NanoPi Zero2 RGMII PHY reset on the MDIO
>   bus rather than in the PHY node, so that it is applied before the PHY
>   ID is read. A PHY held in reset by the bootloader was otherwise never
>   probed, leaving the port dead. Reported by Andrey Korshunov, who
>   proposed the deprecated snps,reset-gpio properties on the MAC; the
>   bus level reset-gpios in mdio.yaml fixes the same ordering without a
>   deprecated property.
> - New patch 5: follow the DTS coding style in the three NanoPi RK3528
>   devicetrees, as found by scripts/dtc/dt-check-style --mode=strict:
>   pinctrl-0 before pinctrl-names, and a blank line before status.
>   Suggested by Diederik de Haas.
> - Picked up Conor Dooley's Acked-by on the binding.
> - Link to v2: https://patch.msgid.link/20260907-r28s-upstream-v2-0-21ab570fc91c@proton.me
>
> Changes in v2:
> - Split the parts shared with the NanoPi Zero2 into a new
>   rk3528-nanopi.dtsi (new patch 2). The NanoPi Zero2 dtb is unchanged.
> - Name the pinctrl labels after the nets in the schematic: usr_btn,
>   led1, led2, led_sys, pwr_wf and pcie_eth_perstb.
> - Rename the button node to button-user and its label to "USER".
> - Link to v1: https://patch.msgid.link/20260905-r28s-upstream-v1-0-f68d5389269a@proton.me
>
> ---
> 安容 (4):
>       dt-bindings: arm: rockchip: Add FriendlyElec NanoPi R28S
>       arm64: dts: rockchip: Split out the common NanoPi RK3528 parts
>       arm64: dts: rockchip: Add devicetree for the FriendlyElec NanoPi R28S
>       arm64: dts: rockchip: Follow the DTS coding style in the NanoPi RK3528 devicetrees
>
>  .../devicetree/bindings/arm/rockchip.yaml          |   5 +
>  arch/arm64/boot/dts/rockchip/Makefile              |   1 +
>  .../arm64/boot/dts/rockchip/rk3528-nanopi-r28s.dts | 127 +++++++++
>  .../boot/dts/rockchip/rk3528-nanopi-zero2.dts      | 306 +-------------------
>  arch/arm64/boot/dts/rockchip/rk3528-nanopi.dtsi    | 314 +++++++++++++++++++++
>  5 files changed, 456 insertions(+), 297 deletions(-)
> ---
> base-commit: 32e0f64640d558a0f5410ac5cdd8ebf371c5e6a6
> change-id: 20260905-r28s-upstream-e212e27d6165
>
> Best regards,
> --  
> 安容 <HystericalDragons@proton.me>
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip



      parent reply	other threads:[~2026-09-14  8:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14  8:24 安容 via B4 Relay
2026-09-14  8:24 ` [PATCH v5 1/4] dt-bindings: arm: " 安容 via B4 Relay
2026-09-14  9:13   ` Jonas Karlman
2026-09-14  8:24 ` [PATCH v5 2/4] arm64: dts: rockchip: Split out the common NanoPi RK3528 parts 安容 via B4 Relay
2026-09-14  9:28   ` Jonas Karlman
2026-09-14  8:24 ` [PATCH v5 3/4] arm64: dts: rockchip: Add devicetree for the FriendlyElec NanoPi R28S 安容 via B4 Relay
2026-09-14  9:46   ` Jonas Karlman
2026-09-14  8:24 ` [PATCH v5 4/4] arm64: dts: rockchip: Follow the DTS coding style in the NanoPi RK3528 devicetrees 安容 via B4 Relay
2026-09-14  8:58 ` Diederik de Haas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DLEWYVCME40R.L2IMBIU3ILG1@cknow-tech.com \
    --to=diederik@cknow-tech.com \
    --cc=HystericalDragons@proton.me \
    --cc=amadeus@jmu.edu.cn \
    --cc=conor+dt@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jensenhuang@friendlyarm.com \
    --cc=jonas@kwiboo.se \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=razor1702@gmail.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®