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 <cristian.ciocaltea@collabora.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
---
.../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.0On 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 <krzysztof.kozlowski@linaro.org> 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 <krzysztof.kozlowski@linaro.org> 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/20240126192128.1210579-2-cristian.ciocaltea@collabora.com/ [2] https://lore.kernel.org/lkml/920e764c-4fa3-4298-bb49-d31416fc3dd6@collabora.com/
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > 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 <krzysztof.kozlowski@linaro.org> >> >> 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 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 <krzysztof.kozlowski@linaro.org>
> >>
> >> 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
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 <krzysztof.kozlowski@linaro.org> >>>> >>>> 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...
© 2016 - 2025 Red Hat, Inc.