Message ID | 20221129072714.22880-1-amadeus@jmu.edu.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp186647wrr; Mon, 28 Nov 2022 23:34:37 -0800 (PST) X-Google-Smtp-Source: AA0mqf6HWD329p5DQrgr8bJHYuWh2oaAE8NlEWtVz5Lr/whCqC6OI1+ZFoYl5KvrFbXoH9FgVSev X-Received: by 2002:a63:5b01:0:b0:477:e3df:13ac with SMTP id p1-20020a635b01000000b00477e3df13acmr17393490pgb.321.1669707277716; Mon, 28 Nov 2022 23:34:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669707277; cv=none; d=google.com; s=arc-20160816; b=MR2i6eDTX/js18aGcEzv5iZFMrlwwSh/zKLG87oBHxCnyJyZsiAF5Kd+cIwyDlYdgK V6n+UwzBhI0ynVYPYtxDsX3rYvgXyohzYaZzuM62sKX2dHIhB6ByiX3cXRd1CyQviGAJ ezPgDw76Fg9YDNuHLk7XWdWKH2eG/MHTicBrqvYWVyB0hemBK01H3gIogJ/Jdq+QX7BR JYnM4Sdsuy43uLMt77+6D67AlLJ6APdPUOfcznESb7A+nUgUWftFQ4yHae029qXV+SvO XKigdv7fXVcpiFy8yswarYeCiqKWCn7dTmwOkjLC60wpiT9pWcXgc9KaGg+GCQ4tUL56 G3/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=+nfLUrEQaHZnDK2OtU2frNuB4JPokNxZThOjKyFbtPg=; b=e7FpNef4pIhuKAwAscdGraf6Agu3dM4l+JpWTSts6OPKbkWOZfULIdyPCIyhloimsY ZiRjRy+2ChdtD1g29bAAKEYxfjtY+fN683Fz8rXLfZA6s7WnHutk8svC7vHWX9118Tpj 3ZUA1iy2kRwxpIj62E41R2fh6tfkRe7bD1tPJlReO6Ca3FMIaVnLHFtvcsHMdNDxEJqq kX+d3MFFKon+E5KdWku4aTDkbT3/FNzakt37pmJ2msgmcKDKDstw8L4sARItyHv2EjYQ DX6qgJ7+CKmRBhBYNDAD9+7WwdnOe3p0owEz4RKMA11Hb+VkIf6i+87EWZlGiE5sLA5l 2zGA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=jmu.edu.cn Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t11-20020a170902e84b00b00186a3bb7ae3si15488125plg.213.2022.11.28.23.34.23; Mon, 28 Nov 2022 23:34:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=jmu.edu.cn Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229768AbiK2H1u (ORCPT <rfc822;gah0developer@gmail.com> + 99 others); Tue, 29 Nov 2022 02:27:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229529AbiK2H1s (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 29 Nov 2022 02:27:48 -0500 Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0670658D; Mon, 28 Nov 2022 23:27:43 -0800 (PST) Received: from amadeus-VLT-WX0.lan (unknown [112.48.80.27]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id EFF73800056; Tue, 29 Nov 2022 15:27:37 +0800 (CST) From: Chukun Pan <amadeus@jmu.edu.cn> To: "David S . Miller" <davem@davemloft.net> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, David Wu <david.wu@rock-chips.com>, Rob Herring <robh+dt@kernel.org>, Heiko Stuebner <heiko@sntech.de>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Chukun Pan <amadeus@jmu.edu.cn> Subject: [PATCH 1/2] dt-bindings: net: rockchip-dwmac: add rk3568 xpcs compatible Date: Tue, 29 Nov 2022 15:27:13 +0800 Message-Id: <20221129072714.22880-1-amadeus@jmu.edu.cn> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFITzdXWS1ZQUlXWQ8JGhUIEh9ZQVkZQ0pKVhlDQ0MdGhoZGh4aSFUTARMWGhIXJBQOD1 lXWRgSC1lBWUpKSVVPQ1VDS1VJTFlXWRYaDxIVHRRZQVlPS0hVSklLQ05NVUpLS1VLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NVE6Myo6Hj0tOBwVQz8JCzwy Kj4aCjpVSlVKTU1CTEtNQ05CSUpMVTMWGhIXVRoWGh8eDgg7ERYOVR4fDlUYFUVZV1kSC1lBWUpK SVVPQ1VDS1VJTFlXWQgBWUFIS0pLNwY+ X-HM-Tid: 0a84c248c0a4b03akuuueff73800056 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750814978169712796?= X-GMAIL-MSGID: =?utf-8?q?1750814978169712796?= |
Series |
[1/2] dt-bindings: net: rockchip-dwmac: add rk3568 xpcs compatible
|
|
Commit Message
Chukun Pan
Nov. 29, 2022, 7:27 a.m. UTC
The gmac of RK3568 supports RGMII/SGMII/QSGMII interface.
This patch adds a compatible string for the required clock.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 6 ++++++
1 file changed, 6 insertions(+)
Comments
On 29/11/2022 08:27, Chukun Pan wrote: > The gmac of RK3568 supports RGMII/SGMII/QSGMII interface. > This patch adds a compatible string for the required clock. > > Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> > --- > Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > index 42fb72b6909d..36b1e82212e7 100644 > --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > @@ -68,6 +68,7 @@ properties: > - mac_clk_rx > - aclk_mac > - pclk_mac > + - pclk_xpcs > - clk_mac_ref > - clk_mac_refout > - clk_mac_speed > @@ -90,6 +91,11 @@ properties: > The phandle of the syscon node for the peripheral general register file. > $ref: /schemas/types.yaml#/definitions/phandle > > + rockchip,xpcs: > + description: > + The phandle of the syscon node for the peripheral general register file. You used the same description as above, so no, you cannot have two properties which are the same. syscons for GRF are called "rockchip,grf", aren't they? Best regards, Krzysztof
On 29/11/2022 09:49, Krzysztof Kozlowski wrote: > On 29/11/2022 08:27, Chukun Pan wrote: >> The gmac of RK3568 supports RGMII/SGMII/QSGMII interface. >> This patch adds a compatible string for the required clock. >> >> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> >> --- >> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml >> index 42fb72b6909d..36b1e82212e7 100644 >> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml >> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml >> @@ -68,6 +68,7 @@ properties: >> - mac_clk_rx >> - aclk_mac >> - pclk_mac >> + - pclk_xpcs >> - clk_mac_ref >> - clk_mac_refout >> - clk_mac_speed >> @@ -90,6 +91,11 @@ properties: >> The phandle of the syscon node for the peripheral general register file. >> $ref: /schemas/types.yaml#/definitions/phandle >> >> + rockchip,xpcs: >> + description: >> + The phandle of the syscon node for the peripheral general register file. > > You used the same description as above, so no, you cannot have two > properties which are the same. syscons for GRF are called > "rockchip,grf", aren't they? Also: 1. Your commit msg does not explain it at all. 2. Your driver code uses this as some phy? Don't use syscon as workaround for missing drivers. Best regards, Krzysztof
Am Dienstag, 29. November 2022, 09:49:08 CET schrieb Krzysztof Kozlowski: > On 29/11/2022 08:27, Chukun Pan wrote: > > The gmac of RK3568 supports RGMII/SGMII/QSGMII interface. > > This patch adds a compatible string for the required clock. > > > > Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> > > --- > > Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > > index 42fb72b6909d..36b1e82212e7 100644 > > --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > > +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > > @@ -68,6 +68,7 @@ properties: > > - mac_clk_rx > > - aclk_mac > > - pclk_mac > > + - pclk_xpcs > > - clk_mac_ref > > - clk_mac_refout > > - clk_mac_speed > > @@ -90,6 +91,11 @@ properties: > > The phandle of the syscon node for the peripheral general register file. > > $ref: /schemas/types.yaml#/definitions/phandle > > > > + rockchip,xpcs: > > + description: > > + The phandle of the syscon node for the peripheral general register file. > > You used the same description as above, so no, you cannot have two > properties which are the same. syscons for GRF are called > "rockchip,grf", aren't they? Not necessarily :-) . The GRF is Rockchip's way of not sorting their own invented additional registers. (aka a bunch of registers While on the older models there only ever was the one GRF as dumping ground, newer SoCs now end up with multiple ones :-) These are still iomem areas separate from the actual device-iomem they work with/for but SoCs like the rk3568 now have at least 13 of them. _But_ for the patch in question I fail to see what this set does at all. The rk3568 (only) has XPCS_CON0 and XPCS_STATUS in its PIPE_GRF syscon (according to the TRM), but the patch2 does strange things with offset calculations and names that do not seem to have a match in the TRM. So definitely more explanation on what happens here would be necessary. Heiko
On 29/11/2022 10:56, Heiko Stübner wrote: > Am Dienstag, 29. November 2022, 09:49:08 CET schrieb Krzysztof Kozlowski: >> On 29/11/2022 08:27, Chukun Pan wrote: >>> The gmac of RK3568 supports RGMII/SGMII/QSGMII interface. >>> This patch adds a compatible string for the required clock. >>> >>> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> >>> --- >>> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml >>> index 42fb72b6909d..36b1e82212e7 100644 >>> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml >>> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml >>> @@ -68,6 +68,7 @@ properties: >>> - mac_clk_rx >>> - aclk_mac >>> - pclk_mac >>> + - pclk_xpcs >>> - clk_mac_ref >>> - clk_mac_refout >>> - clk_mac_speed >>> @@ -90,6 +91,11 @@ properties: >>> The phandle of the syscon node for the peripheral general register file. >>> $ref: /schemas/types.yaml#/definitions/phandle >>> >>> + rockchip,xpcs: >>> + description: >>> + The phandle of the syscon node for the peripheral general register file. >> >> You used the same description as above, so no, you cannot have two >> properties which are the same. syscons for GRF are called >> "rockchip,grf", aren't they? > > Not necessarily :-) . OK, then description should have something like "...GRF for foo bar". Best regards, Krzysztof
Am Dienstag, 29. November 2022, 10:59:34 CET schrieb Krzysztof Kozlowski: > On 29/11/2022 10:56, Heiko Stübner wrote: > > Am Dienstag, 29. November 2022, 09:49:08 CET schrieb Krzysztof Kozlowski: > >> On 29/11/2022 08:27, Chukun Pan wrote: > >>> The gmac of RK3568 supports RGMII/SGMII/QSGMII interface. > >>> This patch adds a compatible string for the required clock. > >>> > >>> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> > >>> --- > >>> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 6 ++++++ > >>> 1 file changed, 6 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > >>> index 42fb72b6909d..36b1e82212e7 100644 > >>> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > >>> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > >>> @@ -68,6 +68,7 @@ properties: > >>> - mac_clk_rx > >>> - aclk_mac > >>> - pclk_mac > >>> + - pclk_xpcs > >>> - clk_mac_ref > >>> - clk_mac_refout > >>> - clk_mac_speed > >>> @@ -90,6 +91,11 @@ properties: > >>> The phandle of the syscon node for the peripheral general register file. > >>> $ref: /schemas/types.yaml#/definitions/phandle > >>> > >>> + rockchip,xpcs: > >>> + description: > >>> + The phandle of the syscon node for the peripheral general register file. > >> > >> You used the same description as above, so no, you cannot have two > >> properties which are the same. syscons for GRF are called > >> "rockchip,grf", aren't they? > > > > Not necessarily :-) . > > OK, then description should have something like "...GRF for foo bar". Actually looking deeper in the TRM, having these registers "just" written to from the dwmac-glue-layer feels quite a bit like a hack. The "pcs" thingy referenced in patch2 actually looks more like a real device with its own section in the TRM and own iomem area. This pcs device then itself has some more settings stored in said pipe-grf. So this looks more like it wants to be an actual phy-driver. @Chukun Pan: plase take a look at something like https://elixir.bootlin.com/linux/latest/source/drivers/phy/mscc/phy-ocelot-serdes.c#L398 on how phy-drivers for ethernets could look like. Aquiring such a phy from the dwmac-glue and calling phy_set_mode after moving the xpcs_setup to a phy-driver shouldn't be too hard I think. The qsgmii/sgmii_pcs list of registers in the TRM alone already takes up 4 A4 pages, so while using the PCS as syscon and just writing some values into it might work now, this doesn't feel at all like a future-save handling. Heiko
On Tue, Nov 29, 2022 at 11:22:28AM +0100, Heiko Stübner wrote: > Am Dienstag, 29. November 2022, 10:59:34 CET schrieb Krzysztof Kozlowski: > > On 29/11/2022 10:56, Heiko Stübner wrote: > > > Am Dienstag, 29. November 2022, 09:49:08 CET schrieb Krzysztof Kozlowski: > > >> On 29/11/2022 08:27, Chukun Pan wrote: > > >>> The gmac of RK3568 supports RGMII/SGMII/QSGMII interface. > > >>> This patch adds a compatible string for the required clock. > > >>> > > >>> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> > > >>> --- > > >>> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 6 ++++++ > > >>> 1 file changed, 6 insertions(+) > > >>> > > >>> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > > >>> index 42fb72b6909d..36b1e82212e7 100644 > > >>> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > > >>> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > > >>> @@ -68,6 +68,7 @@ properties: > > >>> - mac_clk_rx > > >>> - aclk_mac > > >>> - pclk_mac > > >>> + - pclk_xpcs > > >>> - clk_mac_ref > > >>> - clk_mac_refout > > >>> - clk_mac_speed > > >>> @@ -90,6 +91,11 @@ properties: > > >>> The phandle of the syscon node for the peripheral general register file. > > >>> $ref: /schemas/types.yaml#/definitions/phandle > > >>> > > >>> + rockchip,xpcs: > > >>> + description: > > >>> + The phandle of the syscon node for the peripheral general register file. > > >> > > >> You used the same description as above, so no, you cannot have two > > >> properties which are the same. syscons for GRF are called > > >> "rockchip,grf", aren't they? > > > > > > Not necessarily :-) . > > > > OK, then description should have something like "...GRF for foo bar". > > Actually looking deeper in the TRM, having these registers "just" written > to from the dwmac-glue-layer feels quite a bit like a hack. > > The "pcs" thingy referenced in patch2 actually looks more like a real device > with its own section in the TRM and own iomem area. This pcs device then > itself has some more settings stored in said pipe-grf. > > So this looks more like it wants to be an actual phy-driver. There's a PCS binding now. Seems like it should be used if there is also a PHY already. PCS may be part of the PHY or separate block AIUI. Rob
> Actually looking deeper in the TRM, having these registers "just" written > to from the dwmac-glue-layer feels quite a bit like a hack. > The "pcs" thingy referenced in patch2 actually looks more like a real device > with its own section in the TRM and own iomem area. This pcs device then > itself has some more settings stored in said pipe-grf. > So this looks more like it wants to be an actual phy-driver. > @Chukun Pan: plase take a look at something like > https://elixir.bootlin.com/linux/latest/source/drivers/phy/mscc/phy-ocelot-serdes.c#L398 > on how phy-drivers for ethernets could look like. > Aquiring such a phy from the dwmac-glue and calling phy_set_mode after > moving the xpcs_setup to a phy-driver shouldn't be too hard I think. Thanks for pointing that out. The patch2 is come from the sdk kernel of rockchip. The sgmii-phy of RK3568 is designed on nanning combo phy. In the sdk kernel, if we want to use sgmii mode, we need to modify the device tree in the gmac section like this: ``` &gmac0 { power-domains = <&power RK3568_PD_PIPE>; phys = <&combphy1_usq PHY_TYPE_SGMII>; phy-handle = <&sgmii_phy>; phy-mode = "sgmii"; rockchip,pipegrf = <&pipegrf>; rockchip,xpcs = <&xpcs>; status = "okay"; }; ``` I'm not sure how to write this on the mainline kernel. Any hint will be appreciated. -- Thanks, Chukun
On Sat, Dec 03, 2022 at 05:00:15PM +0800, Chukun Pan wrote: > > Actually looking deeper in the TRM, having these registers "just" written > > to from the dwmac-glue-layer feels quite a bit like a hack. > > > The "pcs" thingy referenced in patch2 actually looks more like a real device > > with its own section in the TRM and own iomem area. This pcs device then > > itself has some more settings stored in said pipe-grf. > > > So this looks more like it wants to be an actual phy-driver. > > > @Chukun Pan: plase take a look at something like > > https://elixir.bootlin.com/linux/latest/source/drivers/phy/mscc/phy-ocelot-serdes.c#L398 > > on how phy-drivers for ethernets could look like. > > > Aquiring such a phy from the dwmac-glue and calling phy_set_mode after > > moving the xpcs_setup to a phy-driver shouldn't be too hard I think. > > Thanks for pointing that out. > The patch2 is come from the sdk kernel of rockchip. > The sgmii-phy of RK3568 is designed on nanning combo phy. > In the sdk kernel, if we want to use sgmii mode, we need > to modify the device tree in the gmac section like this: > > ``` > &gmac0 { > power-domains = <&power RK3568_PD_PIPE>; > phys = <&combphy1_usq PHY_TYPE_SGMII>; > phy-handle = <&sgmii_phy>; > phy-mode = "sgmii"; phy-mode tells you you are using SGMII. You can tell the generic PHY driver this which will call the PHY drivers .set_mode(). As said above, there are plenty of examples of this, mvneta and its comphy, various mscc drivers etc. Andrew
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 42fb72b6909d..36b1e82212e7 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -68,6 +68,7 @@ properties: - mac_clk_rx - aclk_mac - pclk_mac + - pclk_xpcs - clk_mac_ref - clk_mac_refout - clk_mac_speed @@ -90,6 +91,11 @@ properties: The phandle of the syscon node for the peripheral general register file. $ref: /schemas/types.yaml#/definitions/phandle + rockchip,xpcs: + description: + The phandle of the syscon node for the peripheral general register file. + $ref: /schemas/types.yaml#/definitions/phandle + tx_delay: description: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as default. $ref: /schemas/types.yaml#/definitions/uint32