From: Rob Herring <robh@kernel.org> Date: 2022-12-01 13:36:45
On Thu, 01 Dec 2022 17:02:38 +0800, Yanhong Wang wrote:
Add bindings for the StarFive dwmac module on the StarFive RISC-V SoCs.
Signed-off-by: Yanhong Wang <redacted>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,dwmac-plat.yaml | 106 ++++++++++++++++++
MAINTAINERS | 5 +
3 files changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml:30:16: [warning] wrong indentation: expected 14 but found 15 (indentation)
dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml: $id: relative path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/net/starfive,dwmac-plat.yaml#
Documentation/devicetree/bindings/net/starfive,dwmac-plat.example.dts:21:18: fatal error: dt-bindings/clock/starfive-jh7110.h: No such file or directory
21 | #include <dt-bindings/clock/starfive-jh7110.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.lib:406: Documentation/devicetree/bindings/net/starfive,dwmac-plat.example.dtb] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1492: dt_binding_check] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20221201090242.2381-4-yanhong.wang@starfivetech.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Hey Yanhong,
On Thu, Dec 01, 2022 at 07:36:29AM -0600, Rob Herring wrote:
On Thu, 01 Dec 2022 17:02:38 +0800, Yanhong Wang wrote:
quoted
Add bindings for the StarFive dwmac module on the StarFive RISC-V SoCs.
Signed-off-by: Yanhong Wang <redacted>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,dwmac-plat.yaml | 106 ++++++++++++++++++
MAINTAINERS | 5 +
3 files changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml:30:16: [warning] wrong indentation: expected 14 but found 15 (indentation)
dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml: $id: relative path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/net/starfive,dwmac-plat.yaml#
Documentation/devicetree/bindings/net/starfive,dwmac-plat.example.dts:21:18: fatal error: dt-bindings/clock/starfive-jh7110.h: No such file or directory
21 | #include <dt-bindings/clock/starfive-jh7110.h>
Perhaps, rather than putting a long list of "prerequisite-patch-id" in
your cover letters etc, you drop the need for headers from your bindings
entirely? Otherwise, you need to wait for the clock bindings to be applied
before any of your other peripherals etc can have drivers/bindings upstream.
AFAIU, and Rob/Krzk please correct me, the example in a dt-binding
really is an *example* and there's no requirement for it to match the
jh7110 dts exactly. Because of that you can drop the header & just do
something like `clocks = <&clk 7>, <&clk 77>;` etc and the example is
still valid. Same goes for all of the other driver patchsets for new
StarFive stuff, like the pmu or crypto, that also have dt-bindings.
The only person who has to worry then about dependencies is me when I
apply the .dts patches :)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.lib:406: Documentation/devicetree/bindings/net/starfive,dwmac-plat.example.dtb] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1492: dt_binding_check] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20221201090242.2381-4-yanhong.wang@starfivetech.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
From: Krzysztof Kozlowski <hidden> Date: 2022-12-02 10:54:09
On 01/12/2022 17:45, Conor Dooley wrote:
Hey Yanhong,
On Thu, Dec 01, 2022 at 07:36:29AM -0600, Rob Herring wrote:
quoted
On Thu, 01 Dec 2022 17:02:38 +0800, Yanhong Wang wrote:
quoted
Add bindings for the StarFive dwmac module on the StarFive RISC-V SoCs.
Signed-off-by: Yanhong Wang <redacted>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,dwmac-plat.yaml | 106 ++++++++++++++++++
MAINTAINERS | 5 +
3 files changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml:30:16: [warning] wrong indentation: expected 14 but found 15 (indentation)
dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/net/starfive,dwmac-plat.yaml: $id: relative path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/net/starfive,dwmac-plat.yaml#
Documentation/devicetree/bindings/net/starfive,dwmac-plat.example.dts:21:18: fatal error: dt-bindings/clock/starfive-jh7110.h: No such file or directory
21 | #include <dt-bindings/clock/starfive-jh7110.h>
Perhaps, rather than putting a long list of "prerequisite-patch-id" in
your cover letters etc, you drop the need for headers from your bindings
entirely? Otherwise, you need to wait for the clock bindings to be applied
before any of your other peripherals etc can have drivers/bindings upstream.
AFAIU, and Rob/Krzk please correct me, the example in a dt-binding
really is an *example* and there's no requirement for it to match the
jh7110 dts exactly. Because of that you can drop the header & just do
something like `clocks = <&clk 7>, <&clk 77>;` etc and the example is
still valid. Same goes for all of the other driver patchsets for new
StarFive stuff, like the pmu or crypto, that also have dt-bindings.
The only person who has to worry then about dependencies is me when I
apply the .dts patches :)
It's nice when example looks good and matching final DTS, but that's not
a requirement. Pretty often clocks/resets/domains are mocked for the
example.
Best regards,
Krzysztof
Does not look like you tested the bindings. Please run `make
dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Wrong indentation.... kind of expected since you did not test the bindings.
quoted
+ - const: snps,dwmac-5.20
Disclaimer: no familiarity with the version info with DW stuff
Is it a bit foolish to call this binding "starfive,dwmac"? Could there
not be another StarFive SoC in the future that uses another DW mac IP
version & this would be better off as "starfive,jh7110-dwmac" or similar?
Thanks,
Conor.
Wrong indentation.... kind of expected since you did not test the bindings.
quoted
+ - const: snps,dwmac-5.20
Disclaimer: no familiarity with the version info with DW stuff
Is it a bit foolish to call this binding "starfive,dwmac"? Could there
not be another StarFive SoC in the future that uses another DW mac IP
version & this would be better off as "starfive,jh7110-dwmac" or similar?
Yes. Really, *only* "starfive,jh7110-dwmac" is enough IMO.
The question is what would the OS do with only understanding
"snps,dwmac-5.20"? The answer is typically nothing because it isn't
enough information to act on. So that compatible is not needed. Maybe
the driver can do some things based on version, but that can be implied
from the compatible (if not read from a register). And often, the exact
version is not known, so do you want to hardcode a guess in DT? For
these reasons, we've moved away from using these generic IP compatibles
(with or without versions).
Rob
Wrong indentation.... kind of expected since you did not test the bindings.
quoted
+ - const: snps,dwmac-5.20
Disclaimer: no familiarity with the version info with DW stuff
Is it a bit foolish to call this binding "starfive,dwmac"? Could there
not be another StarFive SoC in the future that uses another DW mac IP
version & this would be better off as "starfive,jh7110-dwmac" or similar?
The StarFive JH8100 SoC in the future that uses the same mac IP version, so call this binding "starfive,dwmac".
Wrong indentation.... kind of expected since you did not test the bindings.
quoted
+ - const: snps,dwmac-5.20
Disclaimer: no familiarity with the version info with DW stuff
Is it a bit foolish to call this binding "starfive,dwmac"? Could there
not be another StarFive SoC in the future that uses another DW mac IP
version & this would be better off as "starfive,jh7110-dwmac" or similar?
The StarFive JH8100 SoC in the future that uses the same mac IP version, so call this binding "starfive,dwmac".
It's not a reason to make compatible generic.
Best regards,
Krzysztof
Does not look like you tested the bindings. Please run `make
dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
@@ -48,6 +84,33 @@ static int yt8511_write_page(struct phy_device *phydev, int page)return__phy_write(phydev,YT8511_PAGE_SELECT,page);};+staticintytphy_read_ext(structphy_device*phydev,u32regnum)+{+intret;+intval;++ret=__phy_write(phydev,YT8511_PAGE_SELECT,regnum);+if(ret<0)+returnret;++val=__phy_read(phydev,YT8511_PAGE);++returnval;+}++staticintytphy_write_ext(structphy_device*phydev,u32regnum,u16val)+{+intret;++ret=__phy_write(phydev,YT8511_PAGE_SELECT,regnum);+if(ret<0)+returnret;++ret=__phy_write(phydev,YT8511_PAGE,val);++returnret;+}+staticintyt8511_config_init(structphy_device*phydev){intoldpage,ret=0;
@@ -111,6 +174,116 @@ static int yt8511_config_init(struct phy_device *phydev)returnphy_restore_page(phydev,oldpage,ret);}+staticintytphy_config_init(structphy_device*phydev)+{+structdevice_node*of_node;+u32val;+u32mask;+u32cfg;+intret;+inti=0;++of_node=phydev->mdio.dev.of_node;+if(of_node){+ret=of_property_read_u32(of_node,ytphy_rxden_grp[0].name,&cfg);+if(!ret){+mask=ytphy_rxden_grp[0].mask;+val=ytphy_read_ext(phydev,YTPHY_EXT_CHIP_CONFIG);++/* check the cfg overflow or not */+cfg=cfg>mask>>(ffs(mask)-1)?mask:cfg;++val&=~mask;+val|=FIELD_PREP(mask,cfg);+ytphy_write_ext(phydev,YTPHY_EXT_CHIP_CONFIG,val);+}++val=ytphy_read_ext(phydev,YTPHY_EXT_RGMII_CONFIG1);+for(i=0;i<ARRAY_SIZE(ytphy_rxtxd_grp);i++){+ret=of_property_read_u32(of_node,ytphy_rxtxd_grp[i].name,&cfg);+if(!ret){+mask=ytphy_rxtxd_grp[i].mask;++/* check the cfg overflow or not */+cfg=cfg>mask>>(ffs(mask)-1)?mask:cfg;++val&=~mask;+val|=cfg<<(ffs(mask)-1);+}+}+returnytphy_write_ext(phydev,YTPHY_EXT_RGMII_CONFIG1,val);+}++phydev_err(phydev,"Get of node fail\n");++return-EINVAL;+}++staticvoidytphy_link_change_notify(structphy_device*phydev)+{+u32val;+structytphy_priv_t*ytphy_priv=phydev->priv;++if(phydev->speed<0)+return;++val=ytphy_read_ext(phydev,YTPHY_EXT_RGMII_CONFIG1);+switch(phydev->speed){+caseSPEED_1000:+val&=~ytphy_txinver_grp[0].mask;+val|=FIELD_PREP(ytphy_txinver_grp[0].mask,+ytphy_priv->tx_inverted_1000);+break;++caseSPEED_100:+val&=~ytphy_txinver_grp[1].mask;+val|=FIELD_PREP(ytphy_txinver_grp[1].mask,+ytphy_priv->tx_inverted_100);+break;++caseSPEED_10:+val&=~ytphy_txinver_grp[2].mask;+val|=FIELD_PREP(ytphy_txinver_grp[2].mask,+ytphy_priv->tx_inverted_10);+break;++default:+break;+}++ytphy_write_ext(phydev,YTPHY_EXT_RGMII_CONFIG1,val);+}++staticintyt8531_probe(structphy_device*phydev)+{+structytphy_priv_t*priv;+conststructdevice_node*of_node;+u32val;+intret;++priv=devm_kzalloc(&phydev->mdio.dev,sizeof(*priv),GFP_KERNEL);+if(!priv)+return-ENOMEM;++of_node=phydev->mdio.dev.of_node;+if(of_node){+ret=of_property_read_u32(of_node,ytphy_txinver_grp[0].name,&val);+if(!ret)+priv->tx_inverted_1000=val;++ret=of_property_read_u32(of_node,ytphy_txinver_grp[1].name,&val);+if(!ret)+priv->tx_inverted_100=val;++ret=of_property_read_u32(of_node,ytphy_txinver_grp[2].name,&val);+if(!ret)+priv->tx_inverted_10=val;+}+phydev->priv=priv;++return0;+}+staticstructphy_drivermotorcomm_phy_drvs[]={{PHY_ID_MATCH_EXACT(PHY_ID_YT8511),
You need to document the device tree binding.
Frank Sae always gets the locking wrong in this driver. Have you
tested your patch with lockdep enabled?
Andrew
On Thu, Dec 01, 2022 at 05:49:08PM +0000, Conor Dooley wrote:
On Thu, Dec 01, 2022 at 05:02:42PM +0800, Yanhong Wang wrote:
quoted
riscv: dts: starfive: visionfive-v2: Add phy delay_chain configuration
Add phy delay_chain configuration to support motorcomm phy driver for
StarFive VisionFive 2 board.
nit: please re-word this commit next time around to actually say what
you're doing here. I didn't notice it initially, but this patch is doing
a lot more than adding `delay_chain` configuration. To my dwmac unaware
brain, there's nothing hits for that term outside of the changelog :(
Thanks,
Conor.
From: Andrew Lunn <andrew@lunn.ch> Date: 2022-12-01 19:42:52
On Thu, Dec 01, 2022 at 07:30:16PM +0000, Conor Dooley wrote:
On Thu, Dec 01, 2022 at 05:49:08PM +0000, Conor Dooley wrote:
quoted
On Thu, Dec 01, 2022 at 05:02:42PM +0800, Yanhong Wang wrote:
quoted
riscv: dts: starfive: visionfive-v2: Add phy delay_chain configuration
Add phy delay_chain configuration to support motorcomm phy driver for
StarFive VisionFive 2 board.
nit: please re-word this commit next time around to actually say what
you're doing here. I didn't notice it initially, but this patch is doing
a lot more than adding `delay_chain` configuration. To my dwmac unaware
brain, there's nothing hits for that term outside of the changelog :(
Hi Conor
I suspect once we see the documentation of the binding, it will get
rejected and implemented differently. So i would not worry too much
about this at the moment.
Andrew
From: yanhong wang <hidden> Date: 2022-12-09 01:28:28
On 2022/12/2 3:30, Conor Dooley wrote:
On Thu, Dec 01, 2022 at 05:49:08PM +0000, Conor Dooley wrote:
quoted
On Thu, Dec 01, 2022 at 05:02:42PM +0800, Yanhong Wang wrote:
quoted
riscv: dts: starfive: visionfive-v2: Add phy delay_chain configuration
Add phy delay_chain configuration to support motorcomm phy driver for
StarFive VisionFive 2 board.
nit: please re-word this commit next time around to actually say what
you're doing here. I didn't notice it initially, but this patch is doing
a lot more than adding `delay_chain` configuration. To my dwmac unaware
brain, there's nothing hits for that term outside of the changelog :(
I will re-word the commit message and add another dt-binding to describe the details that such as "rxc_dly_en","tx_inverted_10" etc.
From: Emil Renner Berthing <hidden> Date: 2022-12-07 14:17:07
Hi Yanhong,
Thanks for submitting this. Again please don't change the author of
the commits you cherry-picked from my tree. This is why we have the
Co-developed-by: tag so you can mark that you added or in this case
removed code.
I'd hoped you would still include the support for the JH7100 though.
Also you seem to have changed the name of some of the functions.
Please at least keep the prefix consistent if you do that. Now it's a
mix of dwmac_starfive_, starfive_eth_ and starfive_eth_plat.
On Thu, 1 Dec 2022 at 10:07, Yanhong Wang [off-list ref] wrote:
quoted hunk
This adds StarFive dwmac driver support on the StarFive JH7110 SoCs.
Signed-off-by: Yanhong Wang <redacted>
---
MAINTAINERS | 1 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../stmicro/stmmac/dwmac-starfive-plat.c | 147 ++++++++++++++++++
4 files changed, 160 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-starfive-plat.c
Why did you add the _PLAT suffix? None of the other SoC wrappers have this..
quoted hunk
+ tristate "StarFive dwmac support"
+ depends on OF && COMMON_CLK
+ depends on STMMAC_ETH
+ default SOC_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 RISC-V SoCs.
+
config DWMAC_VISCONTI
tristate "Toshiba Visconti DWMAC support"
default ARCH_VISCONTI
From: yanhong wang <hidden> Date: 2022-12-08 02:23:25
On 2022/12/7 22:16, Emil Renner Berthing wrote:
Hi Yanhong,
Thanks for submitting this. Again please don't change the author of
the commits you cherry-picked from my tree. This is why we have the
Co-developed-by: tag so you can mark that you added or in this case
removed code.
This commit is not cherry-picked from your tree.
I'd hoped you would still include the support for the JH7100 though.
If necessary, would include the support for the JH7100 in the next version.
Also you seem to have changed the name of some of the functions.
Please at least keep the prefix consistent if you do that. Now it's a
mix of dwmac_starfive_, starfive_eth_ and starfive_eth_plat.
On Thu, 1 Dec 2022 at 10:07, Yanhong Wang [off-list ref] wrote:
quoted
This adds StarFive dwmac driver support on the StarFive JH7110 SoCs.
Signed-off-by: Yanhong Wang <redacted>
---
MAINTAINERS | 1 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../stmicro/stmmac/dwmac-starfive-plat.c | 147 ++++++++++++++++++
4 files changed, 160 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-starfive-plat.c
Why did you add the _PLAT suffix? None of the other SoC wrappers have this..
The _PLAT suffix definition reference the other SoC,such as DWMAC_INTEL_PLAT.
quoted
+ tristate "StarFive dwmac support"
+ depends on OF && COMMON_CLK
+ depends on STMMAC_ETH
+ default SOC_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 RISC-V SoCs.
+
config DWMAC_VISCONTI
tristate "Toshiba Visconti DWMAC support"
default ARCH_VISCONTI
From: yanhong wang <hidden> Date: 2022-12-09 02:03:56
On 2022/12/7 22:16, Emil Renner Berthing wrote:
Hi Yanhong,
Thanks for submitting this. Again please don't change the author of
the commits you cherry-picked from my tree. This is why we have the
Co-developed-by: tag so you can mark that you added or in this case
removed code.
I'd hoped you would still include the support for the JH7100 though.
Hi Emil,
Thank you for your suggestion. If the dwmac-starfive-plat driver supports JH7100 and JH7110, the dt-binding calls "starfive,jh71x0-dwmac.yaml", is this ok?
Also you seem to have changed the name of some of the functions.
Please at least keep the prefix consistent if you do that. Now it's a
mix of dwmac_starfive_, starfive_eth_ and starfive_eth_plat.
I will named all the functions with starfive_eth_plat prefix in the next version.
On Thu, 1 Dec 2022 at 10:07, Yanhong Wang [off-list ref] wrote:
quoted
This adds StarFive dwmac driver support on the StarFive JH7110 SoCs.
Signed-off-by: Yanhong Wang <redacted>
---
MAINTAINERS | 1 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../stmicro/stmmac/dwmac-starfive-plat.c | 147 ++++++++++++++++++
4 files changed, 160 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-starfive-plat.c
Why did you add the _PLAT suffix? None of the other SoC wrappers have this..
quoted
+ tristate "StarFive dwmac support"
+ depends on OF && COMMON_CLK
+ depends on STMMAC_ETH
+ default SOC_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 RISC-V SoCs.
+
config DWMAC_VISCONTI
tristate "Toshiba Visconti DWMAC support"
default ARCH_VISCONTI
From: Yanhong Wang <hidden> Date: 2022-12-01 09:30:11
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid
to define some platform data in the glue layer.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <redacted>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Emil Renner Berthing <hidden> Date: 2022-12-07 13:58:44
On Thu, 1 Dec 2022 at 10:05, Yanhong Wang [off-list ref] wrote:
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid
to define some platform data in the glue layer.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <redacted>
Hi Yanhong.
Thanks for submitting this.
But just as a reminder. Please don't change the author of the commits
you cherry-picked from my tree.
/Emil
From: yanhong wang <hidden> Date: 2022-12-08 01:42:36
On 2022/12/7 21:58, Emil Renner Berthing wrote:
On Thu, 1 Dec 2022 at 10:05, Yanhong Wang [off-list ref] wrote:
quoted
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid
to define some platform data in the glue layer.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <redacted>
Hi Yanhong.
Thanks for submitting this.
But just as a reminder. Please don't change the author of the commits
you cherry-picked from my tree.
I will recover the author is you in the next version.
From: Ben Dooks <hidden> Date: 2022-12-09 04:01:18
On 2022-12-01 09:02, Yanhong Wang wrote:
quoted hunk
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid
to define some platform data in the glue layer.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <redacted>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
out of interest, is the version of the ip autodetectable yet?
also, we would be better off if having an if (version > 4) check if we
use the standard snps ip block code headers
From: yanhong wang <hidden> Date: 2022-12-09 02:27:12
On 2022/12/9 9:59, Ben Dooks wrote:
On 2022-12-01 09:02, Yanhong Wang wrote:
quoted
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid
to define some platform data in the glue layer.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <redacted>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
out of interest, is the version of the ip autodetectable yet?
also, we would be better off if having an if (version > 4) check if we use the standard snps ip block code headers
Yes, the version of the ip is autodetectable. It is also possible to use the standard "snps, dwmac-5.10a" definition on JH7110（has been tested on the VisionFive v2 boards and works normally）, do you have any better suggestions?
From: Emil Renner Berthing <hidden> Date: 2022-12-07 13:56:50
On Fri, 2 Dec 2022 at 09:04, Krzysztof Kozlowski
[off-list ref] wrote:
On 02/12/2022 03:53, yanhong wang wrote:
quoted
On 2022/12/2 0:18, Krzysztof Kozlowski wrote:
quoted
On 01/12/2022 10:02, Yanhong Wang wrote:
quoted
Add dwmac-5.20 version to snps.dwmac.yaml
Drop full stop from subject and add it here instead.
Will update in the next version.
quoted
quoted
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <redacted>
Two people contributed this one single line?
Emil made this patch and I submitted it.
If Emil made this patch, then your From field is incorrect.
Yes, please don't change the author of the commits you cherry-picked
from my tree.
But now I'm curious. Did you check with your colleagues that the dwmac
IP on the SoC is in fact version 5.20?
This was just an educated guess from my side.
/Emil
From: yanhong wang <hidden> Date: 2022-12-08 01:34:32
On 2022/12/7 21:56, Emil Renner Berthing wrote:
On Fri, 2 Dec 2022 at 09:04, Krzysztof Kozlowski
[off-list ref] wrote:
quoted
On 02/12/2022 03:53, yanhong wang wrote:
quoted
On 2022/12/2 0:18, Krzysztof Kozlowski wrote:
quoted
On 01/12/2022 10:02, Yanhong Wang wrote:
quoted
Add dwmac-5.20 version to snps.dwmac.yaml
Drop full stop from subject and add it here instead.
Will update in the next version.
quoted
quoted
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Yanhong Wang <redacted>
Two people contributed this one single line?
Emil made this patch and I submitted it.
If Emil made this patch, then your From field is incorrect.
Yes, please don't change the author of the commits you cherry-picked
from my tree.
But now I'm curious. Did you check with your colleagues that the dwmac
IP on the SoC is in fact version 5.20?
I can confirm that the IP version is 5.20 on JH7110 SoC.
This was just an educated guess from my side.
/Emil