This is just a subset of the initial patch series [1] adding networking
support for StarFive JH7100 SoC.
[1]: https://lore.kernel.org/lkml/[email protected]/
Changes in v4:
- Rebased series onto next-20240125
- Added R-b tag from Rob in PATCH 1
- v3:
https://lore.kernel.org/lkml/[email protected]/
Changes in v3:
- Optimized jh7110 resets & reset-names properties (Rob)
- Added R-b tag from Jacob in PATCH 1
- v2:
https://lore.kernel.org/lkml/[email protected]/
Changes in v2:
- Add the missing binding patch (Conor)
- v1:
https://lore.kernel.org/lkml/[email protected]/
Cristian Ciocaltea (2):
dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible
net: stmmac: dwmac-starfive: Add support for JH7100 SoC
.../devicetree/bindings/net/snps,dwmac.yaml | 11 +--
.../bindings/net/starfive,jh7110-dwmac.yaml | 72 +++++++++++++------
drivers/net/ethernet/stmicro/stmmac/Kconfig | 6 +-
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 32 +++++++--
4 files changed, 88 insertions(+), 33 deletions(-)
--
2.43.0
The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
similar to the newer JH7110, but it requires only two interrupts and a
single reset line, which is 'ahb' instead of the commonly used
'stmmaceth'.
Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
conjunction with 'stmmaceth', extend the logic to also permit exclusive
usage of the 'ahb' reset name. This ensures the following use cases are
supported:
JH7110: reset-names = "stmmaceth", "ahb";
JH7100: reset-names = "ahb";
other: reset-names = "stmmaceth";
Also note the need to use a different dwmac fallback, as v5.20 applies
to JH7110 only, while JH7100 relies on v3.7x.
Additionally, drop the reset description items from top-level binding as
they are already provided by the included snps,dwmac schema.
Signed-off-by: Cristian Ciocaltea <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 11 +--
.../bindings/net/starfive,jh7110-dwmac.yaml | 72 +++++++++++++------
2 files changed, 57 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 5c2769dc689a..90c4db178c67 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -95,6 +95,7 @@ properties:
- snps,dwmac-5.20
- snps,dwxgmac
- snps,dwxgmac-2.10
+ - starfive,jh7100-dwmac
- starfive,jh7110-dwmac
reg:
@@ -144,10 +145,12 @@ properties:
- description: AHB reset
reset-names:
- minItems: 1
- items:
- - const: stmmaceth
- - const: ahb
+ oneOf:
+ - items:
+ - enum: [stmmaceth, ahb]
+ - items:
+ - const: stmmaceth
+ - const: ahb
power-domains:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 5e7cfbbebce6..0d1962980f57 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -16,16 +16,20 @@ select:
compatible:
contains:
enum:
+ - starfive,jh7100-dwmac
- starfive,jh7110-dwmac
required:
- compatible
properties:
compatible:
- items:
- - enum:
- - starfive,jh7110-dwmac
- - const: snps,dwmac-5.20
+ oneOf:
+ - items:
+ - const: starfive,jh7100-dwmac
+ - const: snps,dwmac
+ - items:
+ - const: starfive,jh7110-dwmac
+ - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -46,24 +50,6 @@ properties:
- const: tx
- const: gtx
- interrupts:
- minItems: 3
- maxItems: 3
-
- interrupt-names:
- minItems: 3
- maxItems: 3
-
- resets:
- items:
- - description: MAC Reset signal.
- - description: AHB Reset signal.
-
- reset-names:
- items:
- - const: stmmaceth
- - const: ahb
-
starfive,tx-use-rgmii-clk:
description:
Tx clock is provided by external rgmii clock.
@@ -94,6 +80,48 @@ required:
allOf:
- $ref: snps,dwmac.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7100-dwmac
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 2
+ maxItems: 2
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: ahb
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-dwmac
+ then:
+ properties:
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 3
+ maxItems: 3
+
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
+
unevaluatedProperties: false
examples:
--
2.43.0
Add a missing quirk to enable support for the StarFive JH7100 SoC.
Additionally, for greater flexibility in operation, allow using the
rgmii-rxid and rgmii-txid phy modes.
Co-developed-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Emil Renner Berthing <[email protected]>
Signed-off-by: Cristian Ciocaltea <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 6 ++--
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 32 ++++++++++++++++---
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 85dcda51df05..4ec61f1ee71a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -165,9 +165,9 @@ config DWMAC_STARFIVE
help
Support for ethernet controllers on StarFive RISC-V SoCs
- This selects the StarFive platform specific glue layer support for
- the stmmac device driver. This driver is used for StarFive JH7110
- ethernet controller.
+ This selects the StarFive platform specific glue layer support
+ for the stmmac device driver. This driver is used for the
+ StarFive JH7100 and JH7110 ethernet controllers.
config DWMAC_STI
tristate "STi GMAC support"
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index 5d630affb4d1..4e1076faee0c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -15,13 +15,20 @@
#include "stmmac_platform.h"
-#define STARFIVE_DWMAC_PHY_INFT_RGMII 0x1
-#define STARFIVE_DWMAC_PHY_INFT_RMII 0x4
-#define STARFIVE_DWMAC_PHY_INFT_FIELD 0x7U
+#define STARFIVE_DWMAC_PHY_INFT_RGMII 0x1
+#define STARFIVE_DWMAC_PHY_INFT_RMII 0x4
+#define STARFIVE_DWMAC_PHY_INFT_FIELD 0x7U
+
+#define JH7100_SYSMAIN_REGISTER49_DLYCHAIN 0xc8
+
+struct starfive_dwmac_data {
+ unsigned int gtxclk_dlychain;
+};
struct starfive_dwmac {
struct device *dev;
struct clk *clk_tx;
+ const struct starfive_dwmac_data *data;
};
static void starfive_dwmac_fix_mac_speed(void *priv, unsigned int speed, unsigned int mode)
@@ -67,6 +74,8 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
mode = STARFIVE_DWMAC_PHY_INFT_RGMII;
break;
@@ -89,6 +98,14 @@ static int starfive_dwmac_set_mode(struct plat_stmmacenet_data *plat_dat)
if (err)
return dev_err_probe(dwmac->dev, err, "error setting phy mode\n");
+ if (dwmac->data) {
+ err = regmap_write(regmap, JH7100_SYSMAIN_REGISTER49_DLYCHAIN,
+ dwmac->data->gtxclk_dlychain);
+ if (err)
+ return dev_err_probe(dwmac->dev, err,
+ "error selecting gtxclk delay chain\n");
+ }
+
return 0;
}
@@ -114,6 +131,8 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
if (!dwmac)
return -ENOMEM;
+ dwmac->data = device_get_match_data(&pdev->dev);
+
dwmac->clk_tx = devm_clk_get_enabled(&pdev->dev, "tx");
if (IS_ERR(dwmac->clk_tx))
return dev_err_probe(&pdev->dev, PTR_ERR(dwmac->clk_tx),
@@ -144,8 +163,13 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
}
+static const struct starfive_dwmac_data jh7100_data = {
+ .gtxclk_dlychain = 4,
+};
+
static const struct of_device_id starfive_dwmac_match[] = {
- { .compatible = "starfive,jh7110-dwmac" },
+ { .compatible = "starfive,jh7100-dwmac", .data = &jh7100_data },
+ { .compatible = "starfive,jh7110-dwmac" },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, starfive_dwmac_match);
--
2.43.0
Please ignore this and use the RESEND version [1], as the binding patch
was not correctly updated with the latest tags.
Sorry for the noise,
Cristian
[1] https://lore.kernel.org/lkml/[email protected]/
On 1/26/24 21:13, Cristian Ciocaltea wrote:
> This is just a subset of the initial patch series [1] adding networking
> support for StarFive JH7100 SoC.
>
> [1]: https://lore.kernel.org/lkml/[email protected]/
>
> Changes in v4:
> - Rebased series onto next-20240125
> - Added R-b tag from Rob in PATCH 1
> - v3:
> https://lore.kernel.org/lkml/[email protected]/
On 26/01/2024 20:13, Cristian Ciocaltea wrote:
> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
> similar to the newer JH7110, but it requires only two interrupts and a
> single reset line, which is 'ahb' instead of the commonly used
> 'stmmaceth'.
>
> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
> conjunction with 'stmmaceth', extend the logic to also permit exclusive
> usage of the 'ahb' reset name. This ensures the following use cases are
> supported:
>
> JH7110: reset-names = "stmmaceth", "ahb";
> JH7100: reset-names = "ahb";
> other: reset-names = "stmmaceth";
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
Hi Krzysztof,
On 1/29/24 10:26, Krzysztof Kozlowski wrote:
> On 26/01/2024 20:13, Cristian Ciocaltea wrote:
>> The Synopsys DesignWare MAC found on StarFive JH7100 SoC is mostly
>> similar to the newer JH7110, but it requires only two interrupts and a
>> single reset line, which is 'ahb' instead of the commonly used
>> 'stmmaceth'.
>>
>> Since the common binding 'snps,dwmac' allows selecting 'ahb' only in
>> conjunction with 'stmmaceth', extend the logic to also permit exclusive
>> usage of the 'ahb' reset name. This ensures the following use cases are
>> supported:
>>
>> JH7110: reset-names = "stmmaceth", "ahb";
>> JH7100: reset-names = "ahb";
>> other: reset-names = "stmmaceth";
>
>
> Reviewed-by: Krzysztof Kozlowski <[email protected]>
Thank you for the review!
Could you please apply it to the RESEND version [1] instead, as this one
had an issue collecting the latest tags, as indicated in [2].
Regards,
Cristian
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/lkml/[email protected]/
> > Reviewed-by: Krzysztof Kozlowski <[email protected]>
>
> Thank you for the review!
>
> Could you please apply it to the RESEND version [1] instead, as this one
> had an issue collecting the latest tags, as indicated in [2].
>
> Regards,
> Cristian
Hi Cristian
IT is your job as developers to collect together such reviewed-by:
tags add apply them to the latest version. So long as there are no
major changes, they are still consider applicable.
Andrew
On 1/29/24 15:34, Andrew Lunn wrote:
>>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>>
>> Thank you for the review!
>>
>> Could you please apply it to the RESEND version [1] instead, as this one
>> had an issue collecting the latest tags, as indicated in [2].
>>
>> Regards,
>> Cristian
>
> Hi Cristian
>
> IT is your job as developers to collect together such reviewed-by:
> tags add apply them to the latest version. So long as there are no
> major changes, they are still consider applicable.
Hi Andrew,
Jakub requested a rebase, but I missed a tag and that's why I submitted
the RESEND. Now we got this new tag which is not on the RESEND
submission, that's why I asked Krzysztof if he could add his R-b on that
one. Unless the maintainers' tooling is able to fetch tags from both
submissions?!
Thanks,
Cristian
On 1/29/24 18:54, Andrew Lunn wrote:
> On Mon, Jan 29, 2024 at 06:38:27PM +0200, Cristian Ciocaltea wrote:
>> On 1/29/24 15:34, Andrew Lunn wrote:
>>>>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
>>>>
>>>> Thank you for the review!
>>>>
>>>> Could you please apply it to the RESEND version [1] instead, as this one
>>>> had an issue collecting the latest tags, as indicated in [2].
>>>>
>>>> Regards,
>>>> Cristian
>>>
>>> Hi Cristian
>>>
>>> IT is your job as developers to collect together such reviewed-by:
>>> tags add apply them to the latest version. So long as there are no
>>> major changes, they are still consider applicable.
>>
>> Hi Andrew,
>>
>> Jakub requested a rebase, but I missed a tag and that's why I submitted
>> the RESEND. Now we got this new tag which is not on the RESEND
>> submission, that's why I asked Krzysztof if he could add his R-b on that
>> one. Unless the maintainers' tooling is able to fetch tags from both
>> submissions?!
>
> Well, b4 can do that:
>
> https://b4.docs.kernel.org/en/latest/contributor/trailers.html
>
> But i've no idea if the netdev tooling actual does.
Jakub, please let me know how should we proceed further!
The problem is that we ended up with a RESEND to include a missing R-b
tag from Rob, but afterwards we also got this new R-b from Krzysztof
here. If it's not possible for you to collect both tags, I could
prepare a v5 to avoid having another RESEND.
Thanks,
Cristian
On Mon, 29 Jan 2024 20:51:43 +0200 Cristian Ciocaltea wrote:
> > Well, b4 can do that:
> >
> > https://b4.docs.kernel.org/en/latest/contributor/trailers.html
> >
> > But i've no idea if the netdev tooling actual does.
>
> Jakub, please let me know how should we proceed further!
>
> The problem is that we ended up with a RESEND to include a missing R-b
> tag from Rob, but afterwards we also got this new R-b from Krzysztof
> here. If it's not possible for you to collect both tags, I could
> prepare a v5 to avoid having another RESEND.
First off, have another read of our rules:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
:)
IMHO forwarding the review tag to a newer version of the set yourself
(like I just did) is fine. None of the tooling I know checks if that
the person posting the tag matches the From:
On 1/29/24 22:26, Jakub Kicinski wrote:
> On Mon, 29 Jan 2024 20:51:43 +0200 Cristian Ciocaltea wrote:
>>> Well, b4 can do that:
>>>
>>> https://b4.docs.kernel.org/en/latest/contributor/trailers.html
>>>
>>> But i've no idea if the netdev tooling actual does.
>>
>> Jakub, please let me know how should we proceed further!
>>
>> The problem is that we ended up with a RESEND to include a missing R-b
>> tag from Rob, but afterwards we also got this new R-b from Krzysztof
>> here. If it's not possible for you to collect both tags, I could
>> prepare a v5 to avoid having another RESEND.
>
> First off, have another read of our rules:
> https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
> :)
Oh, net/net-next suffix is required, will make sure to add it next time!
The 24h period restriction is still applicable for a RESEND that is
meant to quickly fix a previous submission issue?
> IMHO forwarding the review tag to a newer version of the set yourself
> (like I just did) is fine. None of the tooling I know checks if that
> the person posting the tag matches the From:
Hmm, I didn't actually test, but according to the link Andrew posted
above, for b4 it might be necessary to make use of the
`--sloppy-trailers` flag:
"Accept trailers where the email address of the sender differs from the
email address found in the trailer itself."
Thanks,
Cristian
On Mon, 29 Jan 2024 22:57:11 +0200 Cristian Ciocaltea wrote:
> > First off, have another read of our rules:
> > https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
> > :)
>
> Oh, net/net-next suffix is required, will make sure to add it next time!
>
> The 24h period restriction is still applicable for a RESEND that is
> meant to quickly fix a previous submission issue?
Yes, reposting too quickly often leads to reviewers looking at
the wrong version.
> > IMHO forwarding the review tag to a newer version of the set yourself
> > (like I just did) is fine. None of the tooling I know checks if that
> > the person posting the tag matches the From:
>
> Hmm, I didn't actually test, but according to the link Andrew posted
> above, for b4 it might be necessary to make use of the
> `--sloppy-trailers` flag:
>
> "Accept trailers where the email address of the sender differs from the
> email address found in the trailer itself."
Hah, interesting. Using a corporate address for the tag but ML-friendly
account for sending the email is quite common. I'm surprised. In any
case, our tools don't do this. I think it's kinda pointless unless the
tool can also prove provenance of the tags already in the patch...
On Mon, Jan 29, 2024 at 06:38:27PM +0200, Cristian Ciocaltea wrote:
> On 1/29/24 15:34, Andrew Lunn wrote:
> >>> Reviewed-by: Krzysztof Kozlowski <[email protected]>
> >>
> >> Thank you for the review!
> >>
> >> Could you please apply it to the RESEND version [1] instead, as this one
> >> had an issue collecting the latest tags, as indicated in [2].
> >>
> >> Regards,
> >> Cristian
> >
> > Hi Cristian
> >
> > IT is your job as developers to collect together such reviewed-by:
> > tags add apply them to the latest version. So long as there are no
> > major changes, they are still consider applicable.
>
> Hi Andrew,
>
> Jakub requested a rebase, but I missed a tag and that's why I submitted
> the RESEND. Now we got this new tag which is not on the RESEND
> submission, that's why I asked Krzysztof if he could add his R-b on that
> one. Unless the maintainers' tooling is able to fetch tags from both
> submissions?!
Well, b4 can do that:
https://b4.docs.kernel.org/en/latest/contributor/trailers.html
But i've no idea if the netdev tooling actual does.
Andrew