public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Liangbin Lian <jjm2473@gmail.com>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	heiko@sntech.de, quentin.schulz@cherry.de,
	kever.yang@rock-chips.com, naoki@radxa.com,
	honyuenkwun@gmail.com, inindev@gmail.com,
	ivan8215145640@gmail.com, neil.armstrong@linaro.org,
	mani@kernel.org, dsimic@manjaro.org, pbrobinson@gmail.com,
	alchark@gmail.com, didi.debian@cknow.org, jbx6244@gmail.com,
	andrew@lunn.ch, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/3] arm64: dts: rockchip: add LinkEase EasePi R1
Date: Thu, 9 Oct 2025 14:59:44 +0100	[thread overview]
Message-ID: <aOe_0EufouURu7R2@shell.armlinux.org.uk> (raw)
In-Reply-To: <20251009084416.45542-4-jjm2473@gmail.com>

On Thu, Oct 09, 2025 at 04:44:16PM +0800, Liangbin Lian wrote:
> +&gmac0 {
> +	phy-mode = "rgmii-id";
> +	clock_in_out = "input";
...
> +&gmac1 {
> +	phy-mode = "rgmii-id";
> +	clock_in_out = "input";

I am fine with what is being proposed here, but I think this
clock_in_out property needs fixing. The description for it is thus:

  clock_in_out:
    description:
      For RGMII, it must be "input", means main clock(125MHz)
      is not sourced from SoC's PLL, but input from PHY.
      For RMII, "input" means PHY provides the reference clock(50MHz),
      "output" means GMAC provides the reference clock.
    $ref: /schemas/types.yaml#/definitions/string
    enum: [input, output]
    default: input

The problems that I have here are:

1) the description states that the only possible value for this when in
   RGMII mode is "input" which is reasonable, because it's due to the
   RGMII specification. The driver code is perfectly able to determine
   whether RGMII has been specified, and set bsp_priv->clock_input
   itself, relieving DT of this need.

2) bsp_priv->clock_input is only used in gmac_clk_enable() when calling
   the SoC specific set_clock_selection() method. Only RK3528, RK3576,
   and RK3588 populate this method. Every other SoC supported by this
   driver still requires the property:

        ret = of_property_read_string(dev->of_node, "clock_in_out", &strings);
        if (ret) {
                dev_err(dev, "Can not read property: clock_in_out.\n");
                bsp_priv->clock_input = true;
        } ...

  If one doesn't provide it, one gets an error print, which is not nice
  I note that the DT binding doesn't list this property as required, so
  the code is at odds with the binding.

  (I note that your Rockchip SoC is RK3568, which doesn't implement this
  method.)

So, taking both these points together, the code should not be printing
an error if "clock_in_out" is missing when either:

a) RGMII is being used (or maybe only when RMII is being used?)
b) the set_clock_selection() method is not present for the SoC variant.

With the driver fixed as indicated above, I then think clock_in_out in
your descriptions becomes unnecessary, and should be removed.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  parent reply	other threads:[~2025-10-09 14:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-09  8:44 [PATCH v5 0/3] arm64: dts: rockchip: introduce LinkEase EasePi R1 Liangbin Lian
2025-10-09  8:44 ` [PATCH v5 1/3] dt-bindings: vendor-prefixes: Document LinkEase Liangbin Lian
2025-10-09  8:44 ` [PATCH v5 2/3] dt-bindings: arm: rockchip: Add LinkEase EasePi R1 Liangbin Lian
2025-10-09  8:44 ` [PATCH v5 3/3] arm64: dts: rockchip: add " Liangbin Lian
2025-10-09 13:14   ` Andrew Lunn
2025-10-09 13:59   ` Russell King (Oracle) [this message]
2025-10-10  3:10     ` Liangbin Lian
2025-10-10  3:20     ` Liangbin Lian
2025-10-13 12:49       ` Russell King (Oracle)
2025-10-13 14:07         ` Liangbin Lian
2025-10-13  7:00   ` Chukun Pan
2025-10-13  8:51     ` Liangbin Lian
2025-10-13 13:00       ` Chukun Pan
2025-10-13 14:03         ` Liangbin Lian

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=aOe_0EufouURu7R2@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=alchark@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=didi.debian@cknow.org \
    --cc=dsimic@manjaro.org \
    --cc=heiko@sntech.de \
    --cc=honyuenkwun@gmail.com \
    --cc=inindev@gmail.com \
    --cc=ivan8215145640@gmail.com \
    --cc=jbx6244@gmail.com \
    --cc=jjm2473@gmail.com \
    --cc=kever.yang@rock-chips.com \
    --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=mani@kernel.org \
    --cc=naoki@radxa.com \
    --cc=neil.armstrong@linaro.org \
    --cc=pbrobinson@gmail.com \
    --cc=quentin.schulz@cherry.de \
    --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