| Message ID | 20240126191319.1209821-2-cristian.ciocaltea@collabora.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | StarFive DWMAC support for JH7100 | expand |
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> 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...
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: