* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
Hello
This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
present on Allwinner H3/H5/A83T/A64 SoCs.
This driver is the continuation of the sun8i-emac driver.
During the development, it appeared that in fact the hardware was a modified
version of some dwmac.
So the driver is now written as a glue driver for stmmac.
It supports 10/100/1000 Mbit/s speed with half/full duplex.
It can use an internal PHY (MII 10/100) or an external PHY
via RGMII/RMII.
This patch series enable the driver only for the H3/A64/H5 SoC since A83T
doesn't have the necessary clocks present in mainline.
The driver have been tested on the following boards:
- H3 Orange PI PC, BananaPI-M2+
- A64 Pine64, BananaPi-M64
- A83T BananaPI-M3
The first two patchs are some mandatory changes for letting dwmac-sun8i be used.
The following three patchs add the driver and its documentation.
The remaining are DT patch enabling it.
Regards
Corentin Labbe
Changes since v5:
- Added DT patch for NanoPi neo
- Use the new adjust_link variables (speedxxx/speedmask)
- Made the timeout of readl_poll_timeout from 10 to 100ms
- Fix sun8i_unpower_phy that could be called twice
- Replace phy by phy-handle in doc/dwmac-sun8i.txt
Changes since v4:
- Re-ordered by alphabetical order some DT nodes
- Simplified power/unpower_phy functions by testing the use of internal_phy
- Added a patch for adding dwmac-sun8i to arm64 defconfig
- Fix a typo in sun50i-a64-system-controller (wrongly used sun8i)
- Reworked uc/mc filter address setting
Changes since v3:
- Renamed tx-delay/rx-delay to tx-delay-ps/rx-delay-ps
- fix syscon compatible example
- Changed parameter type for setup() function
- Dropped some DT patchs for boards which I could not test further
Changes since v2:
- corrected order of syscon compatible
- added compatible = "ethernet-phy-ieee802.3-c22 to PHY
- added set_mac function
Changes since v1:
- added TX/RX delay units
- splitted syscon documentation in its own patch
- regulator is now disabled after clk_prepare_enable(gmac->tx_clk) error
- Fixed a memory leak on mac_device_info
- Use now generic pin config for all DT stuff
- CONFIG_DWMAC_SUN8I is now set to y in defconfigs
Corentin Labbe (21):
net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
net-next: stmmac: add optional setup function
dt-bindings: net-next: Add DT bindings documentation for Allwinner
dwmac-sun8i
dt-bindings: syscon: Add DT bindings documentation for Allwinner
syscon
net-next: stmmac: Add dwmac-sun8i
arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
arm: sun8i: orangepi-pc: Enable dwmac-sun8i
arm: sun8i: orangepi-zero: Enable dwmac-sun8i
arm: sun8i: orangepi-one: Enable dwmac-sun8i
arm: sun8i: orangepi-2: Enable dwmac-sun8i
arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
arm: sun8i: nanopi-neo: Enable dwmac-sun8i
arm64: allwinner: sun50i-a64: Add dt node for the syscon control
module
arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
arm64: allwinner: pine64: Enable dwmac-sun8i
arm64: allwinner: pine64-plus: Enable dwmac-sun8i
arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
arm64: defconfig: Enable dwmac-sun8i driver on defconfig
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +
.../devicetree/bindings/net/dwmac-sun8i.txt | 78 ++
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 8 +
arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 +
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 40 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +
.../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 +-
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 +
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 41 +
arch/arm64/configs/defconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 990 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 2 +
23 files changed, 1303 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
--
2.13.0
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
Hello
This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
present on Allwinner H3/H5/A83T/A64 SoCs.
This driver is the continuation of the sun8i-emac driver.
During the development, it appeared that in fact the hardware was a modified
version of some dwmac.
So the driver is now written as a glue driver for stmmac.
It supports 10/100/1000 Mbit/s speed with half/full duplex.
It can use an internal PHY (MII 10/100) or an external PHY
via RGMII/RMII.
This patch series enable the driver only for the H3/A64/H5 SoC since A83T
doesn't have the necessary clocks present in mainline.
The driver have been tested on the following boards:
- H3 Orange PI PC, BananaPI-M2+
- A64 Pine64, BananaPi-M64
- A83T BananaPI-M3
The first two patchs are some mandatory changes for letting dwmac-sun8i be used.
The following three patchs add the driver and its documentation.
The remaining are DT patch enabling it.
Regards
Corentin Labbe
Changes since v5:
- Added DT patch for NanoPi neo
- Use the new adjust_link variables (speedxxx/speedmask)
- Made the timeout of readl_poll_timeout from 10 to 100ms
- Fix sun8i_unpower_phy that could be called twice
- Replace phy by phy-handle in doc/dwmac-sun8i.txt
Changes since v4:
- Re-ordered by alphabetical order some DT nodes
- Simplified power/unpower_phy functions by testing the use of internal_phy
- Added a patch for adding dwmac-sun8i to arm64 defconfig
- Fix a typo in sun50i-a64-system-controller (wrongly used sun8i)
- Reworked uc/mc filter address setting
Changes since v3:
- Renamed tx-delay/rx-delay to tx-delay-ps/rx-delay-ps
- fix syscon compatible example
- Changed parameter type for setup() function
- Dropped some DT patchs for boards which I could not test further
Changes since v2:
- corrected order of syscon compatible
- added compatible = "ethernet-phy-ieee802.3-c22 to PHY
- added set_mac function
Changes since v1:
- added TX/RX delay units
- splitted syscon documentation in its own patch
- regulator is now disabled after clk_prepare_enable(gmac->tx_clk) error
- Fixed a memory leak on mac_device_info
- Use now generic pin config for all DT stuff
- CONFIG_DWMAC_SUN8I is now set to y in defconfigs
Corentin Labbe (21):
net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
net-next: stmmac: add optional setup function
dt-bindings: net-next: Add DT bindings documentation for Allwinner
dwmac-sun8i
dt-bindings: syscon: Add DT bindings documentation for Allwinner
syscon
net-next: stmmac: Add dwmac-sun8i
arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
arm: sun8i: orangepi-pc: Enable dwmac-sun8i
arm: sun8i: orangepi-zero: Enable dwmac-sun8i
arm: sun8i: orangepi-one: Enable dwmac-sun8i
arm: sun8i: orangepi-2: Enable dwmac-sun8i
arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
arm: sun8i: nanopi-neo: Enable dwmac-sun8i
arm64: allwinner: sun50i-a64: Add dt node for the syscon control
module
arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
arm64: allwinner: pine64: Enable dwmac-sun8i
arm64: allwinner: pine64-plus: Enable dwmac-sun8i
arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
arm64: defconfig: Enable dwmac-sun8i driver on defconfig
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +
.../devicetree/bindings/net/dwmac-sun8i.txt | 78 ++
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 8 +
arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 +
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 40 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +
.../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 +-
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 +
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 41 +
arch/arm64/configs/defconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 990 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 2 +
23 files changed, 1303 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
--
2.13.0
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 01/21] net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
Thoses symbol will be needed for the dwmac-sun8i ethernet driver.
For letting it to be build as module, they need to be exported.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 38f94305aab5..67af0bdd7f10 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -248,6 +248,7 @@ void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
data = (addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) | addr[0];
writel(data, ioaddr + low);
}
+EXPORT_SYMBOL_GPL(stmmac_set_mac_addr);
/* Enable disable MAC RX/TX */
void stmmac_set_mac(void __iomem *ioaddr, bool enable)
@@ -279,4 +280,4 @@ void stmmac_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
addr[4] = hi_addr & 0xff;
addr[5] = (hi_addr >> 8) & 0xff;
}
-
+EXPORT_SYMBOL_GPL(stmmac_get_mac_addr);
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 01/21] net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
Thoses symbol will be needed for the dwmac-sun8i ethernet driver.
For letting it to be build as module, they need to be exported.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 38f94305aab5..67af0bdd7f10 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -248,6 +248,7 @@ void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
data = (addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) | addr[0];
writel(data, ioaddr + low);
}
+EXPORT_SYMBOL_GPL(stmmac_set_mac_addr);
/* Enable disable MAC RX/TX */
void stmmac_set_mac(void __iomem *ioaddr, bool enable)
@@ -279,4 +280,4 @@ void stmmac_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
addr[4] = hi_addr & 0xff;
addr[5] = (hi_addr >> 8) & 0xff;
}
-
+EXPORT_SYMBOL_GPL(stmmac_get_mac_addr);
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 01/21] net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
Thoses symbol will be needed for the dwmac-sun8i ethernet driver.
For letting it to be build as module, they need to be exported.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index 38f94305aab5..67af0bdd7f10 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -248,6 +248,7 @@ void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
data = (addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) | addr[0];
writel(data, ioaddr + low);
}
+EXPORT_SYMBOL_GPL(stmmac_set_mac_addr);
/* Enable disable MAC RX/TX */
void stmmac_set_mac(void __iomem *ioaddr, bool enable)
@@ -279,4 +280,4 @@ void stmmac_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
addr[4] = hi_addr & 0xff;
addr[5] = (hi_addr >> 8) & 0xff;
}
-
+EXPORT_SYMBOL_GPL(stmmac_get_mac_addr);
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 02/21] net-next: stmmac: add optional setup function
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
Instead of adding more ifthen logic for adding a new mac_device_info
setup function, it is easier to add a function pointer to the function
needed.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
include/linux/stmmac.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f158273eab9b..c80c9c3b67db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3933,7 +3933,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
struct mac_device_info *mac;
/* Identify the MAC HW device */
- if (priv->plat->has_gmac) {
+ if (priv->plat->setup) {
+ mac = priv->plat->setup(priv);
+ } else if (priv->plat->has_gmac) {
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_bins,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 3921cb9dfadb..8bb550bca96d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -177,6 +177,7 @@ struct plat_stmmacenet_data {
void (*fix_mac_speed)(void *priv, unsigned int speed);
int (*init)(struct platform_device *pdev, void *priv);
void (*exit)(struct platform_device *pdev, void *priv);
+ struct mac_device_info *(*setup)(void *priv);
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 02/21] net-next: stmmac: add optional setup function
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
Instead of adding more ifthen logic for adding a new mac_device_info
setup function, it is easier to add a function pointer to the function
needed.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
include/linux/stmmac.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f158273eab9b..c80c9c3b67db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3933,7 +3933,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
struct mac_device_info *mac;
/* Identify the MAC HW device */
- if (priv->plat->has_gmac) {
+ if (priv->plat->setup) {
+ mac = priv->plat->setup(priv);
+ } else if (priv->plat->has_gmac) {
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_bins,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 3921cb9dfadb..8bb550bca96d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -177,6 +177,7 @@ struct plat_stmmacenet_data {
void (*fix_mac_speed)(void *priv, unsigned int speed);
int (*init)(struct platform_device *pdev, void *priv);
void (*exit)(struct platform_device *pdev, void *priv);
+ struct mac_device_info *(*setup)(void *priv);
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 02/21] net-next: stmmac: add optional setup function
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
Instead of adding more ifthen logic for adding a new mac_device_info
setup function, it is easier to add a function pointer to the function
needed.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
include/linux/stmmac.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f158273eab9b..c80c9c3b67db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3933,7 +3933,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
struct mac_device_info *mac;
/* Identify the MAC HW device */
- if (priv->plat->has_gmac) {
+ if (priv->plat->setup) {
+ mac = priv->plat->setup(priv);
+ } else if (priv->plat->has_gmac) {
priv->dev->priv_flags |= IFF_UNICAST_FLT;
mac = dwmac1000_setup(priv->ioaddr,
priv->plat->multicast_filter_bins,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 3921cb9dfadb..8bb550bca96d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -177,6 +177,7 @@ struct plat_stmmacenet_data {
void (*fix_mac_speed)(void *priv, unsigned int speed);
int (*init)(struct platform_device *pdev, void *priv);
void (*exit)(struct platform_device *pdev, void *priv);
+ struct mac_device_info *(*setup)(void *priv);
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 03/21] dt-bindings: net-next: Add DT bindings documentation for Allwinner dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
This patch adds documentation for Device-Tree bindings for the
Allwinner dwmac-sun8i driver.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/net/dwmac-sun8i.txt | 78 ++++++++++++++++++++++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
new file mode 100644
index 000000000000..08e708c73193
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -0,0 +1,78 @@
+* Allwinner sun8i GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+- compatible: should be one of the following string:
+ "allwinner,sun8i-a83t-emac"
+ "allwinner,sun8i-h3-emac"
+ "allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- interrupts: interrupt for the device
+- interrupt-names: should be "macirq"
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "stmmaceth"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "stmmaceth"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+- syscon: A phandle to the syscon of the SoC with one of the following
+ compatible string:
+ - allwinner,sun8i-h3-system-controller
+ - allwinner,sun50i-a64-system-controller
+ - allwinner,sun8i-a83t-system-controller
+
+Optional properties:
+- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
+- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
+Both delay properties need to be a multiple of 100. They control the delay for
+external PHY.
+
+Optional properties for "allwinner,sun8i-h3-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with "allwinner,sun8i-h3-emac":
+- clocks: a phandle to the reference clock for the EPHY
+- resets: a phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet@1c0b000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c0b000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 03/21] dt-bindings: net-next: Add DT bindings documentation for Allwinner dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds documentation for Device-Tree bindings for the
Allwinner dwmac-sun8i driver.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/net/dwmac-sun8i.txt | 78 ++++++++++++++++++++++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
new file mode 100644
index 000000000000..08e708c73193
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -0,0 +1,78 @@
+* Allwinner sun8i GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+- compatible: should be one of the following string:
+ "allwinner,sun8i-a83t-emac"
+ "allwinner,sun8i-h3-emac"
+ "allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- interrupts: interrupt for the device
+- interrupt-names: should be "macirq"
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "stmmaceth"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "stmmaceth"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+- syscon: A phandle to the syscon of the SoC with one of the following
+ compatible string:
+ - allwinner,sun8i-h3-system-controller
+ - allwinner,sun50i-a64-system-controller
+ - allwinner,sun8i-a83t-system-controller
+
+Optional properties:
+- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
+- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
+Both delay properties need to be a multiple of 100. They control the delay for
+external PHY.
+
+Optional properties for "allwinner,sun8i-h3-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with "allwinner,sun8i-h3-emac":
+- clocks: a phandle to the reference clock for the EPHY
+- resets: a phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet at 1c0b000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c0b000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy at 1 {
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 03/21] dt-bindings: net-next: Add DT bindings documentation for Allwinner dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
This patch adds documentation for Device-Tree bindings for the
Allwinner dwmac-sun8i driver.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/net/dwmac-sun8i.txt | 78 ++++++++++++++++++++++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
new file mode 100644
index 000000000000..08e708c73193
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -0,0 +1,78 @@
+* Allwinner sun8i GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+- compatible: should be one of the following string:
+ "allwinner,sun8i-a83t-emac"
+ "allwinner,sun8i-h3-emac"
+ "allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- interrupts: interrupt for the device
+- interrupt-names: should be "macirq"
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "stmmaceth"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "stmmaceth"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+- syscon: A phandle to the syscon of the SoC with one of the following
+ compatible string:
+ - allwinner,sun8i-h3-system-controller
+ - allwinner,sun50i-a64-system-controller
+ - allwinner,sun8i-a83t-system-controller
+
+Optional properties:
+- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
+- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
+Both delay properties need to be a multiple of 100. They control the delay for
+external PHY.
+
+Optional properties for "allwinner,sun8i-h3-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with "allwinner,sun8i-h3-emac":
+- clocks: a phandle to the reference clock for the EPHY
+- resets: a phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet@1c0b000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c0b000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 04/21] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
This patch adds documentation for Device-Tree bindings for the
syscon present in allwinner devices.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
new file mode 100644
index 000000000000..cb5769137c6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
@@ -0,0 +1,19 @@
+* Allwinner sun8i system controller
+
+This file describes the bindings for the system controller present in
+Allwinner SoC H3, A83T and A64.
+The principal function of this syscon is to control EMAC PHY choice and
+config.
+
+Required properties for the system controller:
+- reg: address and length of the register for the device.
+- compatible: should be "syscon" and one of the following string:
+ "allwinner,sun8i-h3-system-controller"
+ "allwinner,sun50i-a64-system-controller"
+ "allwinner,sun8i-a83t-system-controller"
+
+Example:
+syscon: syscon@1c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller", "syscon";
+ reg = <0x01c00000 0x1000>;
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 04/21] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds documentation for Device-Tree bindings for the
syscon present in allwinner devices.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
new file mode 100644
index 000000000000..cb5769137c6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
@@ -0,0 +1,19 @@
+* Allwinner sun8i system controller
+
+This file describes the bindings for the system controller present in
+Allwinner SoC H3, A83T and A64.
+The principal function of this syscon is to control EMAC PHY choice and
+config.
+
+Required properties for the system controller:
+- reg: address and length of the register for the device.
+- compatible: should be "syscon" and one of the following string:
+ "allwinner,sun8i-h3-system-controller"
+ "allwinner,sun50i-a64-system-controller"
+ "allwinner,sun8i-a83t-system-controller"
+
+Example:
+syscon: syscon at 1c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller", "syscon";
+ reg = <0x01c00000 0x1000>;
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 04/21] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
This patch adds documentation for Device-Tree bindings for the
syscon present in allwinner devices.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
new file mode 100644
index 000000000000..cb5769137c6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
@@ -0,0 +1,19 @@
+* Allwinner sun8i system controller
+
+This file describes the bindings for the system controller present in
+Allwinner SoC H3, A83T and A64.
+The principal function of this syscon is to control EMAC PHY choice and
+config.
+
+Required properties for the system controller:
+- reg: address and length of the register for the device.
+- compatible: should be "syscon" and one of the following string:
+ "allwinner,sun8i-h3-system-controller"
+ "allwinner,sun50i-a64-system-controller"
+ "allwinner,sun8i-a83t-system-controller"
+
+Example:
+syscon: syscon@1c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller", "syscon";
+ reg = <0x01c00000 0x1000>;
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i is a heavy hacked version of stmmac hardware by
allwinner.
In fact the only common part is the descriptor management and the first
register function.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 990 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 1 +
6 files changed, 1025 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cfbe3634dfa1..85c0e41f8021 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -145,6 +145,17 @@ config DWMAC_SUNXI
This selects Allwinner SoC glue layer support for the
stmmac device driver. This driver is used for A20/A31
GMAC ethernet controller.
+
+config DWMAC_SUN8I
+ tristate "Allwinner sun8i GMAC support"
+ default ARCH_SUNXI
+ depends on OF && (ARCH_SUNXI || COMPILE_TEST)
+ ---help---
+ Support for Allwinner H3 A83T A64 EMAC ethernet controllers.
+
+ This selects Allwinner SoC glue layer support for the
+ stmmac device driver. This driver is used for H3/A83T/A64
+ EMAC ethernet controller.
endif
config STMMAC_PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 700c60336674..fd4937a7fcab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
obj-$(CONFIG_DWMAC_STM32) += dwmac-stm32.o
obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
+obj-$(CONFIG_DWMAC_SUN8I) += dwmac-sun8i.o
obj-$(CONFIG_DWMAC_DWC_QOS_ETH) += dwmac-dwc-qos-eth.o
obj-$(CONFIG_DWMAC_GENERIC) += dwmac-generic.o
stmmac-platform-objs:= stmmac_platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
new file mode 100644
index 000000000000..1a6bfe6c958f
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -0,0 +1,990 @@
+/*
+ * dwmac-sun8i.c - Allwinner sun8i DWMAC specific glue layer
+ *
+ * Copyright (C) 2017 Corentin Labbe <clabbe.montjoie@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/regmap.h>
+#include <linux/stmmac.h>
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+
+/* General notes on dwmac-sun8i:
+ * Locking: no locking is necessary in this file because all necessary locking
+ * is done in the "stmmac files"
+ */
+
+/* struct emac_variant - Descrive dwmac-sun8i hardware variant
+ * @default_syscon_value: The default value of the EMAC register in syscon
+ * This value is used for disabling properly EMAC
+ * and used as a good starting value in case of the
+ * boot process(uboot) leave some stuff.
+ * @internal_phy: Does the MAC embed an internal PHY
+ * @support_mii: Does the MAC handle MII
+ * @support_rmii: Does the MAC handle RMII
+ * @support_rgmii: Does the MAC handle RGMII
+ */
+struct emac_variant {
+ u32 default_syscon_value;
+ int internal_phy;
+ bool support_mii;
+ bool support_rmii;
+ bool support_rgmii;
+};
+
+/* struct sunxi_priv_data - hold all sunxi private data
+ * @tx_clk: reference to MAC TX clock
+ * @ephy_clk: reference to the optional EPHY clock for the internal PHY
+ * @regulator: reference to the optional regulator
+ * @rst_ephy: reference to the optional EPHY reset for the internal PHY
+ * @variant: reference to the current board variant
+ * @regmap: regmap for using the syscon
+ * @use_internal_phy: Does the current PHY choice imply using the internal PHY
+ */
+struct sunxi_priv_data {
+ struct clk *tx_clk;
+ struct clk *ephy_clk;
+ struct regulator *regulator;
+ struct reset_control *rst_ephy;
+ const struct emac_variant *variant;
+ struct regmap *regmap;
+ bool use_internal_phy;
+};
+
+static const struct emac_variant emac_variant_h3 = {
+ .default_syscon_value = 0x58000,
+ .internal_phy = PHY_INTERFACE_MODE_MII,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true
+};
+
+static const struct emac_variant emac_variant_a83t = {
+ .default_syscon_value = 0,
+ .internal_phy = 0,
+ .support_mii = true,
+ .support_rgmii = true
+};
+
+static const struct emac_variant emac_variant_a64 = {
+ .default_syscon_value = 0,
+ .internal_phy = 0,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true
+};
+
+#define EMAC_BASIC_CTL0 0x00
+#define EMAC_BASIC_CTL1 0x04
+#define EMAC_INT_STA 0x08
+#define EMAC_INT_EN 0x0C
+#define EMAC_TX_CTL0 0x10
+#define EMAC_TX_CTL1 0x14
+#define EMAC_TX_FLOW_CTL 0x1C
+#define EMAC_TX_DESC_LIST 0x20
+#define EMAC_RX_CTL0 0x24
+#define EMAC_RX_CTL1 0x28
+#define EMAC_RX_DESC_LIST 0x34
+#define EMAC_RX_FRM_FLT 0x38
+#define EMAC_MDIO_CMD 0x48
+#define EMAC_MDIO_DATA 0x4C
+#define EMAC_MACADDR_HI(reg) (0x50 + (reg) * 8)
+#define EMAC_MACADDR_LO(reg) (0x54 + (reg) * 8)
+#define EMAC_TX_DMA_STA 0xB0
+#define EMAC_TX_CUR_DESC 0xB4
+#define EMAC_TX_CUR_BUF 0xB8
+#define EMAC_RX_DMA_STA 0xC0
+#define EMAC_RX_CUR_DESC 0xC4
+#define EMAC_RX_CUR_BUF 0xC8
+
+/* Use in EMAC_BASIC_CTL0 */
+#define EMAC_DUPLEX_FULL BIT(0)
+#define EMAC_LOOPBACK BIT(1)
+#define EMAC_SPEED_1000 0
+#define EMAC_SPEED_100 (0x03 << 2)
+#define EMAC_SPEED_10 (0x02 << 2)
+
+/* Use in EMAC_BASIC_CTL1 */
+#define EMAC_BURSTLEN_SHIFT 24
+
+/* Used in EMAC_RX_FRM_FLT */
+#define EMAC_FRM_FLT_RXALL BIT(0)
+#define EMAC_FRM_FLT_CTL BIT(13)
+#define EMAC_FRM_FLT_MULTICAST BIT(16)
+
+/* Used in RX_CTL1*/
+#define EMAC_RX_MD BIT(1)
+#define EMAC_RX_TH_MASK GENMASK(4, 5)
+#define EMAC_RX_TH_32 0
+#define EMAC_RX_TH_64 (0x1 << 4)
+#define EMAC_RX_TH_96 (0x2 << 4)
+#define EMAC_RX_TH_128 (0x3 << 4)
+#define EMAC_RX_DMA_EN BIT(30)
+#define EMAC_RX_DMA_START BIT(31)
+
+/* Used in TX_CTL1*/
+#define EMAC_TX_MD BIT(1)
+#define EMAC_TX_NEXT_FRM BIT(2)
+#define EMAC_TX_TH_MASK GENMASK(8, 10)
+#define EMAC_TX_TH_64 0
+#define EMAC_TX_TH_128 (0x1 << 8)
+#define EMAC_TX_TH_192 (0x2 << 8)
+#define EMAC_TX_TH_256 (0x3 << 8)
+#define EMAC_TX_DMA_EN BIT(30)
+#define EMAC_TX_DMA_START BIT(31)
+
+/* Used in RX_CTL0 */
+#define EMAC_RX_RECEIVER_EN BIT(31)
+#define EMAC_RX_DO_CRC BIT(27)
+#define EMAC_RX_FLOW_CTL_EN BIT(16)
+
+/* Used in TX_CTL0 */
+#define EMAC_TX_TRANSMITTER_EN BIT(31)
+
+/* Used in EMAC_TX_FLOW_CTL */
+#define EMAC_TX_FLOW_CTL_EN BIT(0)
+
+/* Used in EMAC_INT_STA */
+#define EMAC_TX_INT BIT(0)
+#define EMAC_TX_DMA_STOP_INT BIT(1)
+#define EMAC_TX_BUF_UA_INT BIT(2)
+#define EMAC_TX_TIMEOUT_INT BIT(3)
+#define EMAC_TX_UNDERFLOW_INT BIT(4)
+#define EMAC_TX_EARLY_INT BIT(5)
+#define EMAC_RX_INT BIT(8)
+#define EMAC_RX_BUF_UA_INT BIT(9)
+#define EMAC_RX_DMA_STOP_INT BIT(10)
+#define EMAC_RX_TIMEOUT_INT BIT(11)
+#define EMAC_RX_OVERFLOW_INT BIT(12)
+#define EMAC_RX_EARLY_INT BIT(13)
+#define EMAC_RGMII_STA_INT BIT(16)
+
+#define MAC_ADDR_TYPE_DST BIT(31)
+
+/* H3 specific bits for EPHY */
+#define H3_EPHY_ADDR_SHIFT 20
+#define H3_EPHY_LED_POL BIT(17) /* 1: active low, 0: active high */
+#define H3_EPHY_SHUTDOWN BIT(16) /* 1: shutdown, 0: power up */
+#define H3_EPHY_SELECT BIT(15) /* 1: internal PHY, 0: external PHY */
+
+/* H3/A64 specific bits */
+#define SYSCON_RMII_EN BIT(13) /* 1: enable RMII (overrides EPIT) */
+
+/* Generic system control EMAC_CLK bits */
+#define SYSCON_ETXDC_MASK GENMASK(2, 0)
+#define SYSCON_ETXDC_SHIFT 10
+#define SYSCON_ERXDC_MASK GENMASK(4, 0)
+#define SYSCON_ERXDC_SHIFT 5
+/* EMAC PHY Interface Type */
+#define SYSCON_EPIT BIT(2) /* 1: RGMII, 0: MII */
+#define SYSCON_ETCS_MASK GENMASK(1, 0)
+#define SYSCON_ETCS_MII 0x0
+#define SYSCON_ETCS_EXT_GMII 0x1
+#define SYSCON_ETCS_INT_GMII 0x2
+#define SYSCON_EMAC_REG 0x30
+
+/* sun8i_dwmac_dma_reset() - reset the EMAC
+ * Called from stmmac via stmmac_dma_ops->reset
+ */
+static int sun8i_dwmac_dma_reset(void __iomem *ioaddr)
+{
+ writel(0, ioaddr + EMAC_RX_CTL1);
+ writel(0, ioaddr + EMAC_TX_CTL1);
+ writel(0, ioaddr + EMAC_RX_FRM_FLT);
+ writel(0, ioaddr + EMAC_RX_DESC_LIST);
+ writel(0, ioaddr + EMAC_TX_DESC_LIST);
+ writel(0, ioaddr + EMAC_INT_EN);
+ writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
+ return 0;
+}
+
+/* sun8i_dwmac_dma_init() - initialize the EMAC
+ * Called from stmmac via stmmac_dma_ops->init
+ */
+static void sun8i_dwmac_dma_init(void __iomem *ioaddr,
+ struct stmmac_dma_cfg *dma_cfg,
+ u32 dma_tx, u32 dma_rx, int atds)
+{
+ /* Write TX and RX descriptors address */
+ writel(dma_rx, ioaddr + EMAC_RX_DESC_LIST);
+ writel(dma_tx, ioaddr + EMAC_TX_DESC_LIST);
+
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+ writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
+}
+
+/* sun8i_dwmac_dump_regs() - Dump EMAC address space
+ * Called from stmmac_dma_ops->dump_regs
+ * Used for ethtool
+ */
+static void sun8i_dwmac_dump_regs(void __iomem *ioaddr, u32 *reg_space)
+{
+ int i;
+
+ for (i = 0; i < 0xC8; i += 4) {
+ if (i == 0x32 || i == 0x3C)
+ continue;
+ reg_space[i / 4] = readl(ioaddr + i);
+ }
+}
+
+/* sun8i_dwmac_dump_mac_regs() - Dump EMAC address space
+ * Called from stmmac_ops->dump_regs
+ * Used for ethtool
+ */
+static void sun8i_dwmac_dump_mac_regs(struct mac_device_info *hw,
+ u32 *reg_space)
+{
+ int i;
+ void __iomem *ioaddr = hw->pcsr;
+
+ for (i = 0; i < 0xC8; i += 4) {
+ if (i == 0x32 || i == 0x3C)
+ continue;
+ reg_space[i / 4] = readl(ioaddr + i);
+ }
+}
+
+static void sun8i_dwmac_enable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(0, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v |= EMAC_TX_DMA_START;
+ v |= EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v |= EMAC_TX_DMA_START;
+ v |= EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v &= ~EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ v |= EMAC_RX_DMA_START;
+ v |= EMAC_RX_DMA_EN;
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static void sun8i_dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ v &= ~EMAC_RX_DMA_EN;
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static int sun8i_dwmac_dma_interrupt(void __iomem *ioaddr,
+ struct stmmac_extra_stats *x, u32 chan)
+{
+ u32 v;
+ int ret = 0;
+
+ v = readl(ioaddr + EMAC_INT_STA);
+
+ if (v & EMAC_TX_INT) {
+ ret |= handle_tx;
+ x->tx_normal_irq_n++;
+ }
+
+ if (v & EMAC_TX_DMA_STOP_INT)
+ x->tx_process_stopped_irq++;
+
+ if (v & EMAC_TX_BUF_UA_INT)
+ x->tx_process_stopped_irq++;
+
+ if (v & EMAC_TX_TIMEOUT_INT)
+ ret |= tx_hard_error;
+
+ if (v & EMAC_TX_UNDERFLOW_INT) {
+ ret |= tx_hard_error;
+ x->tx_undeflow_irq++;
+ }
+
+ if (v & EMAC_TX_EARLY_INT)
+ x->tx_early_irq++;
+
+ if (v & EMAC_RX_INT) {
+ ret |= handle_rx;
+ x->rx_normal_irq_n++;
+ }
+
+ if (v & EMAC_RX_BUF_UA_INT)
+ x->rx_buf_unav_irq++;
+
+ if (v & EMAC_RX_DMA_STOP_INT)
+ x->rx_process_stopped_irq++;
+
+ if (v & EMAC_RX_TIMEOUT_INT)
+ ret |= tx_hard_error;
+
+ if (v & EMAC_RX_OVERFLOW_INT) {
+ ret |= tx_hard_error;
+ x->rx_overflow_irq++;
+ }
+
+ if (v & EMAC_RX_EARLY_INT)
+ x->rx_early_irq++;
+
+ if (v & EMAC_RGMII_STA_INT)
+ x->irq_rgmii_n++;
+
+ writel(v, ioaddr + EMAC_INT_STA);
+
+ return ret;
+}
+
+static void sun8i_dwmac_dma_operation_mode(void __iomem *ioaddr, int txmode,
+ int rxmode, int rxfifosz)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ if (txmode == SF_DMA_MODE) {
+ v |= EMAC_TX_MD;
+ /* Undocumented bit (called TX_NEXT_FRM in BSP), the original
+ * comment is
+ * "Operating on second frame increase the performance
+ * especially when transmit store-and-forward is used."
+ */
+ v |= EMAC_TX_NEXT_FRM;
+ } else {
+ v &= ~EMAC_TX_MD;
+ v &= ~EMAC_TX_TH_MASK;
+ if (txmode < 64)
+ v |= EMAC_TX_TH_64;
+ else if (txmode < 128)
+ v |= EMAC_TX_TH_128;
+ else if (txmode < 192)
+ v |= EMAC_TX_TH_192;
+ else if (txmode < 256)
+ v |= EMAC_TX_TH_256;
+ }
+ writel(v, ioaddr + EMAC_TX_CTL1);
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ if (rxmode == SF_DMA_MODE) {
+ v |= EMAC_RX_MD;
+ } else {
+ v &= ~EMAC_RX_MD;
+ v &= ~EMAC_RX_TH_MASK;
+ if (rxmode < 32)
+ v |= EMAC_RX_TH_32;
+ else if (rxmode < 64)
+ v |= EMAC_RX_TH_64;
+ else if (rxmode < 96)
+ v |= EMAC_RX_TH_96;
+ else if (rxmode < 128)
+ v |= EMAC_RX_TH_128;
+ }
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static const struct stmmac_dma_ops sun8i_dwmac_dma_ops = {
+ .reset = sun8i_dwmac_dma_reset,
+ .init = sun8i_dwmac_dma_init,
+ .dump_regs = sun8i_dwmac_dump_regs,
+ .dma_mode = sun8i_dwmac_dma_operation_mode,
+ .enable_dma_transmission = sun8i_dwmac_enable_dma_transmission,
+ .enable_dma_irq = sun8i_dwmac_enable_dma_irq,
+ .disable_dma_irq = sun8i_dwmac_disable_dma_irq,
+ .start_tx = sun8i_dwmac_dma_start_tx,
+ .stop_tx = sun8i_dwmac_dma_stop_tx,
+ .start_rx = sun8i_dwmac_dma_start_rx,
+ .stop_rx = sun8i_dwmac_dma_stop_rx,
+ .dma_interrupt = sun8i_dwmac_dma_interrupt,
+};
+
+static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
+{
+ struct sunxi_priv_data *gmac = priv;
+ int ret;
+
+ if (gmac->regulator) {
+ ret = regulator_enable(gmac->regulator);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable regulator\n");
+ return ret;
+ }
+ }
+
+ ret = clk_prepare_enable(gmac->tx_clk);
+ if (ret) {
+ if (gmac->regulator)
+ regulator_disable(gmac->regulator);
+ dev_err(&pdev->dev, "Could not enable AHB clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = (8 << EMAC_BURSTLEN_SHIFT); /* burst len */
+ writel(v, ioaddr + EMAC_BASIC_CTL1);
+}
+
+static void sun8i_dwmac_set_mac(void __iomem *ioaddr, bool enable)
+{
+ u32 t, r;
+
+ t = readl(ioaddr + EMAC_TX_CTL0);
+ r = readl(ioaddr + EMAC_RX_CTL0);
+ if (enable) {
+ t |= EMAC_TX_TRANSMITTER_EN;
+ r |= EMAC_RX_RECEIVER_EN;
+ } else {
+ t &= ~EMAC_TX_TRANSMITTER_EN;
+ r &= ~EMAC_RX_RECEIVER_EN;
+ }
+ writel(t, ioaddr + EMAC_TX_CTL0);
+ writel(r, ioaddr + EMAC_RX_CTL0);
+}
+
+/* Set MAC address at slot reg_n
+ * All slot > 0 need to be enabled with MAC_ADDR_TYPE_DST
+ * If addr is NULL, clear the slot
+ */
+static void sun8i_dwmac_set_umac_addr(struct mac_device_info *hw,
+ unsigned char *addr,
+ unsigned int reg_n)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ if (!addr) {
+ writel(0, ioaddr + EMAC_MACADDR_HI(reg_n));
+ return;
+ }
+
+ stmmac_set_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
+ EMAC_MACADDR_LO(reg_n));
+ if (reg_n > 0) {
+ v = readl(ioaddr + EMAC_MACADDR_HI(reg_n));
+ v |= MAC_ADDR_TYPE_DST;
+ writel(v, ioaddr + EMAC_MACADDR_HI(reg_n));
+ }
+}
+
+static void sun8i_dwmac_get_umac_addr(struct mac_device_info *hw,
+ unsigned char *addr,
+ unsigned int reg_n)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ stmmac_get_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
+ EMAC_MACADDR_LO(reg_n));
+}
+
+/* caution this function must return non 0 to work */
+static int sun8i_dwmac_rx_ipc_enable(struct mac_device_info *hw)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL0);
+ v |= EMAC_RX_DO_CRC;
+ writel(v, ioaddr + EMAC_RX_CTL0);
+
+ return 1;
+}
+
+static void sun8i_dwmac_set_filter(struct mac_device_info *hw,
+ struct net_device *dev)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+ int i = 1;
+ struct netdev_hw_addr *ha;
+ int macaddrs = netdev_uc_count(dev) + netdev_mc_count(dev) + 1;
+
+ v = EMAC_FRM_FLT_CTL;
+
+ if (dev->flags & IFF_PROMISC) {
+ v = EMAC_FRM_FLT_RXALL;
+ } else if (dev->flags & IFF_ALLMULTI) {
+ v |= EMAC_FRM_FLT_MULTICAST;
+ } else if (macaddrs <= hw->unicast_filter_entries) {
+ if (!netdev_mc_empty(dev)) {
+ netdev_for_each_mc_addr(ha, dev) {
+ sun8i_dwmac_set_umac_addr(hw, ha->addr, i);
+ i++;
+ }
+ }
+ if (!netdev_uc_empty(dev)) {
+ netdev_for_each_uc_addr(ha, dev) {
+ sun8i_dwmac_set_umac_addr(hw, ha->addr, i);
+ i++;
+ }
+ }
+ } else {
+ netdev_info(dev, "Too many address, switching to promiscuous\n");
+ v = EMAC_FRM_FLT_RXALL;
+ }
+
+ /* Disable unused address filter slots */
+ while (i < hw->unicast_filter_entries)
+ sun8i_dwmac_set_umac_addr(hw, NULL, i++);
+
+ writel(v, ioaddr + EMAC_RX_FRM_FLT);
+}
+
+static void sun8i_dwmac_flow_ctrl(struct mac_device_info *hw,
+ unsigned int duplex, unsigned int fc,
+ unsigned int pause_time, u32 tx_cnt)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL0);
+ if (fc == FLOW_AUTO)
+ v |= EMAC_RX_FLOW_CTL_EN;
+ else
+ v &= ~EMAC_RX_FLOW_CTL_EN;
+ writel(v, ioaddr + EMAC_RX_CTL0);
+
+ v = readl(ioaddr + EMAC_TX_FLOW_CTL);
+ if (fc == FLOW_AUTO)
+ v |= EMAC_TX_FLOW_CTL_EN;
+ else
+ v &= ~EMAC_TX_FLOW_CTL_EN;
+ writel(v, ioaddr + EMAC_TX_FLOW_CTL);
+}
+
+static int sun8i_dwmac_reset(struct stmmac_priv *priv)
+{
+ u32 v;
+ int err;
+
+ v = readl(priv->ioaddr + EMAC_BASIC_CTL1);
+ writel(v | 0x01, priv->ioaddr + EMAC_BASIC_CTL1);
+
+ /* The timeout was previoulsy set to 10ms, but some board (OrangePI0)
+ * need more if no cable plugged. 100ms seems OK
+ */
+ err = readl_poll_timeout(priv->ioaddr + EMAC_BASIC_CTL1, v,
+ !(v & 0x01), 100, 100000);
+
+ if (err) {
+ dev_err(priv->device, "EMAC reset timeout\n");
+ return -EFAULT;
+ }
+ return 0;
+}
+
+static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ struct device_node *node = priv->device->of_node;
+ int ret;
+ u32 reg, val;
+
+ regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+ reg = gmac->variant->default_syscon_value;
+ if (reg != val)
+ dev_warn(priv->device,
+ "Current syscon value is not the default %x (expect %x)\n",
+ val, reg);
+
+ if (gmac->variant->internal_phy) {
+ if (!gmac->use_internal_phy) {
+ /* switch to external PHY interface */
+ reg &= ~H3_EPHY_SELECT;
+ } else {
+ reg |= H3_EPHY_SELECT;
+ reg &= ~H3_EPHY_SHUTDOWN;
+ dev_dbg(priv->device, "Select internal_phy %x\n", reg);
+
+ if (of_property_read_bool(priv->plat->phy_node,
+ "allwinner,leds-active-low"))
+ reg |= H3_EPHY_LED_POL;
+ else
+ reg &= ~H3_EPHY_LED_POL;
+
+ ret = of_mdio_parse_addr(priv->device,
+ priv->plat->phy_node);
+ if (ret < 0) {
+ dev_err(priv->device, "Could not parse MDIO addr\n");
+ return ret;
+ }
+ /* of_mdio_parse_addr returns a valid (0 ~ 31) PHY
+ * address. No need to mask it again.
+ */
+ reg |= ret << H3_EPHY_ADDR_SHIFT;
+ }
+ }
+
+ if (!of_property_read_u32(node, "allwinner,tx-delay-ps", &val)) {
+ if (val % 100) {
+ dev_err(priv->device, "tx-delay must be a multiple of 100\n");
+ return -EINVAL;
+ }
+ val /= 100;
+ dev_dbg(priv->device, "set tx-delay to %x\n", val);
+ if (val <= SYSCON_ETXDC_MASK) {
+ reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+ reg |= (val << SYSCON_ETXDC_SHIFT);
+ } else {
+ dev_err(priv->device, "Invalid TX clock delay: %d\n",
+ val);
+ return -EINVAL;
+ }
+ }
+
+ if (!of_property_read_u32(node, "allwinner,rx-delay-ps", &val)) {
+ if (val % 100) {
+ dev_err(priv->device, "rx-delay must be a multiple of 100\n");
+ return -EINVAL;
+ }
+ val /= 100;
+ dev_dbg(priv->device, "set rx-delay to %x\n", val);
+ if (val <= SYSCON_ERXDC_MASK) {
+ reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+ reg |= (val << SYSCON_ERXDC_SHIFT);
+ } else {
+ dev_err(priv->device, "Invalid RX clock delay: %d\n",
+ val);
+ return -EINVAL;
+ }
+ }
+
+ /* Clear interface mode bits */
+ reg &= ~(SYSCON_ETCS_MASK | SYSCON_EPIT);
+ if (gmac->variant->support_rmii)
+ reg &= ~SYSCON_RMII_EN;
+
+ switch (priv->plat->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ /* default */
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ reg |= SYSCON_EPIT | SYSCON_ETCS_INT_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ reg |= SYSCON_RMII_EN | SYSCON_ETCS_EXT_GMII;
+ break;
+ default:
+ dev_err(priv->device, "Unsupported interface mode: %s",
+ phy_modes(priv->plat->interface));
+ return -EINVAL;
+ }
+
+ regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+
+ return 0;
+}
+
+static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
+{
+ u32 reg = gmac->variant->default_syscon_value;
+
+ regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+}
+
+static int sun8i_dwmac_power_internal_phy(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ int ret;
+
+ if (!gmac->use_internal_phy)
+ return 0;
+
+ ret = clk_prepare_enable(gmac->ephy_clk);
+ if (ret) {
+ dev_err(priv->device, "Cannot enable ephy\n");
+ return ret;
+ }
+
+ ret = reset_control_deassert(gmac->rst_ephy);
+ if (ret) {
+ dev_err(priv->device, "Cannot deassert ephy\n");
+ clk_disable_unprepare(gmac->ephy_clk);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int sun8i_dwmac_unpower_internal_phy(struct sunxi_priv_data *gmac)
+{
+ if (!gmac->use_internal_phy)
+ return 0;
+
+ clk_disable_unprepare(gmac->ephy_clk);
+ reset_control_assert(gmac->rst_ephy);
+ return 0;
+}
+
+/* sun8i_power_phy() - Activate the PHY:
+ * In case of error, no need to call sun8i_unpower_phy(),
+ * it will be called anyway by sun8i_dwmac_exit()
+ */
+static int sun8i_power_phy(struct stmmac_priv *priv)
+{
+ int ret;
+
+ ret = sun8i_dwmac_power_internal_phy(priv);
+ if (ret)
+ return ret;
+
+ ret = sun8i_dwmac_set_syscon(priv);
+ if (ret)
+ return ret;
+
+ /* After changing syscon value, the MAC need reset or it will use
+ * the last value (and so the last PHY set.
+ */
+ ret = sun8i_dwmac_reset(priv);
+ if (ret)
+ return ret;
+ return 0;
+}
+
+static void sun8i_unpower_phy(struct sunxi_priv_data *gmac)
+{
+ sun8i_dwmac_unset_syscon(gmac);
+ sun8i_dwmac_unpower_internal_phy(gmac);
+}
+
+static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
+{
+ struct sunxi_priv_data *gmac = priv;
+
+ sun8i_unpower_phy(gmac);
+
+ clk_disable_unprepare(gmac->tx_clk);
+
+ if (gmac->regulator)
+ regulator_disable(gmac->regulator);
+}
+
+static const struct stmmac_ops sun8i_dwmac_ops = {
+ .core_init = sun8i_dwmac_core_init,
+ .set_mac = sun8i_dwmac_set_mac,
+ .dump_regs = sun8i_dwmac_dump_mac_regs,
+ .rx_ipc = sun8i_dwmac_rx_ipc_enable,
+ .set_filter = sun8i_dwmac_set_filter,
+ .flow_ctrl = sun8i_dwmac_flow_ctrl,
+ .set_umac_addr = sun8i_dwmac_set_umac_addr,
+ .get_umac_addr = sun8i_dwmac_get_umac_addr,
+};
+
+static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
+{
+ struct mac_device_info *mac;
+ struct stmmac_priv *priv = ppriv;
+ int ret;
+
+ mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
+ if (!mac)
+ return NULL;
+
+ ret = sun8i_power_phy(priv);
+ if (ret)
+ return NULL;
+
+ mac->pcsr = priv->ioaddr;
+ mac->mac = &sun8i_dwmac_ops;
+ mac->dma = &sun8i_dwmac_dma_ops;
+
+ /* The loopback bit seems to be re-set when link change
+ * Simply mask it each time
+ * Speed 10/100/1000 are set in BIT(2)/BIT(3)
+ */
+ mac->link.speed_mask = GENMASK(3, 2) | EMAC_LOOPBACK;
+ mac->link.speed10 = EMAC_SPEED_10;
+ mac->link.speed100 = EMAC_SPEED_100;
+ mac->link.speed1000 = EMAC_SPEED_1000;
+ mac->link.duplex = EMAC_DUPLEX_FULL;
+ mac->mii.addr = EMAC_MDIO_CMD;
+ mac->mii.data = EMAC_MDIO_DATA;
+ mac->mii.reg_shift = 4;
+ mac->mii.reg_mask = GENMASK(8, 4);
+ mac->mii.addr_shift = 12;
+ mac->mii.addr_mask = GENMASK(16, 12);
+ mac->mii.clk_csr_shift = 20;
+ mac->mii.clk_csr_mask = GENMASK(22, 20);
+ mac->unicast_filter_entries = 8;
+
+ /* Synopsys Id is not available */
+ priv->synopsys_id = 0;
+
+ return mac;
+}
+
+static int sun8i_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct sunxi_priv_data *gmac;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
+ if (!gmac)
+ return -ENOMEM;
+
+ gmac->variant = of_device_get_match_data(&pdev->dev);
+ if (!gmac->variant) {
+ dev_err(&pdev->dev, "Missing dwmac-sun8i variant\n");
+ return -EINVAL;
+ }
+
+ gmac->tx_clk = devm_clk_get(dev, "stmmaceth");
+ if (IS_ERR(gmac->tx_clk)) {
+ dev_err(dev, "Could not get TX clock\n");
+ return PTR_ERR(gmac->tx_clk);
+ }
+
+ /* Optional regulator for PHY */
+ gmac->regulator = devm_regulator_get_optional(dev, "phy");
+ if (IS_ERR(gmac->regulator)) {
+ if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_info(dev, "No regulator found\n");
+ gmac->regulator = NULL;
+ }
+
+ gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "syscon");
+ if (IS_ERR(gmac->regmap)) {
+ ret = PTR_ERR(gmac->regmap);
+ dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
+ return ret;
+ }
+
+ plat_dat->interface = of_get_phy_mode(dev->of_node);
+ if (plat_dat->interface == gmac->variant->internal_phy) {
+ dev_info(&pdev->dev, "Will use internal PHY\n");
+ gmac->use_internal_phy = true;
+ gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
+ if (IS_ERR(gmac->ephy_clk)) {
+ ret = PTR_ERR(gmac->ephy_clk);
+ dev_err(&pdev->dev, "Cannot get EPHY clock: %d\n", ret);
+ return -EINVAL;
+ }
+
+ gmac->rst_ephy = of_reset_control_get(plat_dat->phy_node, NULL);
+ if (IS_ERR(gmac->rst_ephy)) {
+ ret = PTR_ERR(gmac->rst_ephy);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ dev_err(&pdev->dev, "No EPHY reset control found %d\n",
+ ret);
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&pdev->dev, "Will use external PHY\n");
+ gmac->use_internal_phy = false;
+ }
+
+ /* platform data specifying hardware features and callbacks.
+ * hardware features were copied from Allwinner drivers.
+ */
+ plat_dat->rx_coe = STMMAC_RX_COE_TYPE2;
+ plat_dat->tx_coe = 1;
+ plat_dat->has_sun8i = true;
+ plat_dat->bsp_priv = gmac;
+ plat_dat->init = sun8i_dwmac_init;
+ plat_dat->exit = sun8i_dwmac_exit;
+ plat_dat->setup = sun8i_dwmac_setup;
+
+ ret = sun8i_dwmac_init(pdev, plat_dat->bsp_priv);
+ if (ret)
+ return ret;
+
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (ret)
+ sun8i_dwmac_exit(pdev, plat_dat->bsp_priv);
+
+ return ret;
+}
+
+static const struct of_device_id sun8i_dwmac_match[] = {
+ { .compatible = "allwinner,sun8i-h3-emac",
+ .data = &emac_variant_h3 },
+ { .compatible = "allwinner,sun8i-a83t-emac",
+ .data = &emac_variant_a83t },
+ { .compatible = "allwinner,sun50i-a64-emac",
+ .data = &emac_variant_a64 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
+
+static struct platform_driver sun8i_dwmac_driver = {
+ .probe = sun8i_dwmac_probe,
+ .remove = stmmac_pltfr_remove,
+ .driver = {
+ .name = "dwmac-sun8i",
+ .pm = &stmmac_pltfr_pm_ops,
+ .of_match_table = sun8i_dwmac_match,
+ },
+};
+module_platform_driver(sun8i_dwmac_driver);
+
+MODULE_AUTHOR("Corentin Labbe <clabbe.montjoie@gmail.com>");
+MODULE_DESCRIPTION("Allwinner sun8i DWMAC specific glue layer");
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c80c9c3b67db..68a188e74c54 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -235,6 +235,17 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
priv->clk_csr = STMMAC_CSR_250_300M;
}
+
+ if (priv->plat->has_sun8i) {
+ if (clk_rate > 160000000)
+ priv->clk_csr = 0x03;
+ else if (clk_rate > 80000000)
+ priv->clk_csr = 0x02;
+ else if (clk_rate > 40000000)
+ priv->clk_csr = 0x01;
+ else
+ priv->clk_csr = 0;
+ }
}
static void print_pkt(unsigned char *buf, int len)
@@ -3955,6 +3966,10 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->hw = mac;
+ /* dwmac-sun8i only work in chain mode */
+ if (priv->plat->has_sun8i)
+ chain_mode = 1;
+
/* To use the chained or ring mode */
if (priv->synopsys_id >= DWMAC_CORE_4_00) {
priv->hw->mode = &dwmac4_ring_mode_ops;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 7fc3a1ef395a..3840529344ed 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -309,6 +309,12 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
struct device_node *np, struct device *dev)
{
bool mdio = true;
+ static const struct of_device_id need_mdio_ids[] = {
+ { .compatible = "snps,dwc-qos-ethernet-4.10" },
+ { .compatible = "allwinner,sun8i-a83t-emac" },
+ { .compatible = "allwinner,sun8i-h3-emac" },
+ { .compatible = "allwinner,sun50i-a64-emac" },
+ };
/* If phy-handle property is passed from DT, use it as the PHY */
plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
@@ -325,8 +331,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
mdio = false;
}
- /* exception for dwmac-dwc-qos-eth glue logic */
- if (of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
+ if (of_match_node(need_mdio_ids, np)) {
plat->mdio_node = of_get_child_by_name(np, "mdio");
} else {
/**
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 8bb550bca96d..108739ff9223 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -186,6 +186,7 @@ struct plat_stmmacenet_data {
struct reset_control *stmmac_rst;
struct stmmac_axi *axi;
int has_gmac4;
+ bool has_sun8i;
bool tso_en;
int mac_port_sel_speed;
bool en_tx_lpi_clockgating;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i is a heavy hacked version of stmmac hardware by
allwinner.
In fact the only common part is the descriptor management and the first
register function.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 990 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 1 +
6 files changed, 1025 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cfbe3634dfa1..85c0e41f8021 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -145,6 +145,17 @@ config DWMAC_SUNXI
This selects Allwinner SoC glue layer support for the
stmmac device driver. This driver is used for A20/A31
GMAC ethernet controller.
+
+config DWMAC_SUN8I
+ tristate "Allwinner sun8i GMAC support"
+ default ARCH_SUNXI
+ depends on OF && (ARCH_SUNXI || COMPILE_TEST)
+ ---help---
+ Support for Allwinner H3 A83T A64 EMAC ethernet controllers.
+
+ This selects Allwinner SoC glue layer support for the
+ stmmac device driver. This driver is used for H3/A83T/A64
+ EMAC ethernet controller.
endif
config STMMAC_PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 700c60336674..fd4937a7fcab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
obj-$(CONFIG_DWMAC_STM32) += dwmac-stm32.o
obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
+obj-$(CONFIG_DWMAC_SUN8I) += dwmac-sun8i.o
obj-$(CONFIG_DWMAC_DWC_QOS_ETH) += dwmac-dwc-qos-eth.o
obj-$(CONFIG_DWMAC_GENERIC) += dwmac-generic.o
stmmac-platform-objs:= stmmac_platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
new file mode 100644
index 000000000000..1a6bfe6c958f
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -0,0 +1,990 @@
+/*
+ * dwmac-sun8i.c - Allwinner sun8i DWMAC specific glue layer
+ *
+ * Copyright (C) 2017 Corentin Labbe <clabbe.montjoie@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/regmap.h>
+#include <linux/stmmac.h>
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+
+/* General notes on dwmac-sun8i:
+ * Locking: no locking is necessary in this file because all necessary locking
+ * is done in the "stmmac files"
+ */
+
+/* struct emac_variant - Descrive dwmac-sun8i hardware variant
+ * @default_syscon_value: The default value of the EMAC register in syscon
+ * This value is used for disabling properly EMAC
+ * and used as a good starting value in case of the
+ * boot process(uboot) leave some stuff.
+ * @internal_phy: Does the MAC embed an internal PHY
+ * @support_mii: Does the MAC handle MII
+ * @support_rmii: Does the MAC handle RMII
+ * @support_rgmii: Does the MAC handle RGMII
+ */
+struct emac_variant {
+ u32 default_syscon_value;
+ int internal_phy;
+ bool support_mii;
+ bool support_rmii;
+ bool support_rgmii;
+};
+
+/* struct sunxi_priv_data - hold all sunxi private data
+ * @tx_clk: reference to MAC TX clock
+ * @ephy_clk: reference to the optional EPHY clock for the internal PHY
+ * @regulator: reference to the optional regulator
+ * @rst_ephy: reference to the optional EPHY reset for the internal PHY
+ * @variant: reference to the current board variant
+ * @regmap: regmap for using the syscon
+ * @use_internal_phy: Does the current PHY choice imply using the internal PHY
+ */
+struct sunxi_priv_data {
+ struct clk *tx_clk;
+ struct clk *ephy_clk;
+ struct regulator *regulator;
+ struct reset_control *rst_ephy;
+ const struct emac_variant *variant;
+ struct regmap *regmap;
+ bool use_internal_phy;
+};
+
+static const struct emac_variant emac_variant_h3 = {
+ .default_syscon_value = 0x58000,
+ .internal_phy = PHY_INTERFACE_MODE_MII,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true
+};
+
+static const struct emac_variant emac_variant_a83t = {
+ .default_syscon_value = 0,
+ .internal_phy = 0,
+ .support_mii = true,
+ .support_rgmii = true
+};
+
+static const struct emac_variant emac_variant_a64 = {
+ .default_syscon_value = 0,
+ .internal_phy = 0,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true
+};
+
+#define EMAC_BASIC_CTL0 0x00
+#define EMAC_BASIC_CTL1 0x04
+#define EMAC_INT_STA 0x08
+#define EMAC_INT_EN 0x0C
+#define EMAC_TX_CTL0 0x10
+#define EMAC_TX_CTL1 0x14
+#define EMAC_TX_FLOW_CTL 0x1C
+#define EMAC_TX_DESC_LIST 0x20
+#define EMAC_RX_CTL0 0x24
+#define EMAC_RX_CTL1 0x28
+#define EMAC_RX_DESC_LIST 0x34
+#define EMAC_RX_FRM_FLT 0x38
+#define EMAC_MDIO_CMD 0x48
+#define EMAC_MDIO_DATA 0x4C
+#define EMAC_MACADDR_HI(reg) (0x50 + (reg) * 8)
+#define EMAC_MACADDR_LO(reg) (0x54 + (reg) * 8)
+#define EMAC_TX_DMA_STA 0xB0
+#define EMAC_TX_CUR_DESC 0xB4
+#define EMAC_TX_CUR_BUF 0xB8
+#define EMAC_RX_DMA_STA 0xC0
+#define EMAC_RX_CUR_DESC 0xC4
+#define EMAC_RX_CUR_BUF 0xC8
+
+/* Use in EMAC_BASIC_CTL0 */
+#define EMAC_DUPLEX_FULL BIT(0)
+#define EMAC_LOOPBACK BIT(1)
+#define EMAC_SPEED_1000 0
+#define EMAC_SPEED_100 (0x03 << 2)
+#define EMAC_SPEED_10 (0x02 << 2)
+
+/* Use in EMAC_BASIC_CTL1 */
+#define EMAC_BURSTLEN_SHIFT 24
+
+/* Used in EMAC_RX_FRM_FLT */
+#define EMAC_FRM_FLT_RXALL BIT(0)
+#define EMAC_FRM_FLT_CTL BIT(13)
+#define EMAC_FRM_FLT_MULTICAST BIT(16)
+
+/* Used in RX_CTL1*/
+#define EMAC_RX_MD BIT(1)
+#define EMAC_RX_TH_MASK GENMASK(4, 5)
+#define EMAC_RX_TH_32 0
+#define EMAC_RX_TH_64 (0x1 << 4)
+#define EMAC_RX_TH_96 (0x2 << 4)
+#define EMAC_RX_TH_128 (0x3 << 4)
+#define EMAC_RX_DMA_EN BIT(30)
+#define EMAC_RX_DMA_START BIT(31)
+
+/* Used in TX_CTL1*/
+#define EMAC_TX_MD BIT(1)
+#define EMAC_TX_NEXT_FRM BIT(2)
+#define EMAC_TX_TH_MASK GENMASK(8, 10)
+#define EMAC_TX_TH_64 0
+#define EMAC_TX_TH_128 (0x1 << 8)
+#define EMAC_TX_TH_192 (0x2 << 8)
+#define EMAC_TX_TH_256 (0x3 << 8)
+#define EMAC_TX_DMA_EN BIT(30)
+#define EMAC_TX_DMA_START BIT(31)
+
+/* Used in RX_CTL0 */
+#define EMAC_RX_RECEIVER_EN BIT(31)
+#define EMAC_RX_DO_CRC BIT(27)
+#define EMAC_RX_FLOW_CTL_EN BIT(16)
+
+/* Used in TX_CTL0 */
+#define EMAC_TX_TRANSMITTER_EN BIT(31)
+
+/* Used in EMAC_TX_FLOW_CTL */
+#define EMAC_TX_FLOW_CTL_EN BIT(0)
+
+/* Used in EMAC_INT_STA */
+#define EMAC_TX_INT BIT(0)
+#define EMAC_TX_DMA_STOP_INT BIT(1)
+#define EMAC_TX_BUF_UA_INT BIT(2)
+#define EMAC_TX_TIMEOUT_INT BIT(3)
+#define EMAC_TX_UNDERFLOW_INT BIT(4)
+#define EMAC_TX_EARLY_INT BIT(5)
+#define EMAC_RX_INT BIT(8)
+#define EMAC_RX_BUF_UA_INT BIT(9)
+#define EMAC_RX_DMA_STOP_INT BIT(10)
+#define EMAC_RX_TIMEOUT_INT BIT(11)
+#define EMAC_RX_OVERFLOW_INT BIT(12)
+#define EMAC_RX_EARLY_INT BIT(13)
+#define EMAC_RGMII_STA_INT BIT(16)
+
+#define MAC_ADDR_TYPE_DST BIT(31)
+
+/* H3 specific bits for EPHY */
+#define H3_EPHY_ADDR_SHIFT 20
+#define H3_EPHY_LED_POL BIT(17) /* 1: active low, 0: active high */
+#define H3_EPHY_SHUTDOWN BIT(16) /* 1: shutdown, 0: power up */
+#define H3_EPHY_SELECT BIT(15) /* 1: internal PHY, 0: external PHY */
+
+/* H3/A64 specific bits */
+#define SYSCON_RMII_EN BIT(13) /* 1: enable RMII (overrides EPIT) */
+
+/* Generic system control EMAC_CLK bits */
+#define SYSCON_ETXDC_MASK GENMASK(2, 0)
+#define SYSCON_ETXDC_SHIFT 10
+#define SYSCON_ERXDC_MASK GENMASK(4, 0)
+#define SYSCON_ERXDC_SHIFT 5
+/* EMAC PHY Interface Type */
+#define SYSCON_EPIT BIT(2) /* 1: RGMII, 0: MII */
+#define SYSCON_ETCS_MASK GENMASK(1, 0)
+#define SYSCON_ETCS_MII 0x0
+#define SYSCON_ETCS_EXT_GMII 0x1
+#define SYSCON_ETCS_INT_GMII 0x2
+#define SYSCON_EMAC_REG 0x30
+
+/* sun8i_dwmac_dma_reset() - reset the EMAC
+ * Called from stmmac via stmmac_dma_ops->reset
+ */
+static int sun8i_dwmac_dma_reset(void __iomem *ioaddr)
+{
+ writel(0, ioaddr + EMAC_RX_CTL1);
+ writel(0, ioaddr + EMAC_TX_CTL1);
+ writel(0, ioaddr + EMAC_RX_FRM_FLT);
+ writel(0, ioaddr + EMAC_RX_DESC_LIST);
+ writel(0, ioaddr + EMAC_TX_DESC_LIST);
+ writel(0, ioaddr + EMAC_INT_EN);
+ writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
+ return 0;
+}
+
+/* sun8i_dwmac_dma_init() - initialize the EMAC
+ * Called from stmmac via stmmac_dma_ops->init
+ */
+static void sun8i_dwmac_dma_init(void __iomem *ioaddr,
+ struct stmmac_dma_cfg *dma_cfg,
+ u32 dma_tx, u32 dma_rx, int atds)
+{
+ /* Write TX and RX descriptors address */
+ writel(dma_rx, ioaddr + EMAC_RX_DESC_LIST);
+ writel(dma_tx, ioaddr + EMAC_TX_DESC_LIST);
+
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+ writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
+}
+
+/* sun8i_dwmac_dump_regs() - Dump EMAC address space
+ * Called from stmmac_dma_ops->dump_regs
+ * Used for ethtool
+ */
+static void sun8i_dwmac_dump_regs(void __iomem *ioaddr, u32 *reg_space)
+{
+ int i;
+
+ for (i = 0; i < 0xC8; i += 4) {
+ if (i == 0x32 || i == 0x3C)
+ continue;
+ reg_space[i / 4] = readl(ioaddr + i);
+ }
+}
+
+/* sun8i_dwmac_dump_mac_regs() - Dump EMAC address space
+ * Called from stmmac_ops->dump_regs
+ * Used for ethtool
+ */
+static void sun8i_dwmac_dump_mac_regs(struct mac_device_info *hw,
+ u32 *reg_space)
+{
+ int i;
+ void __iomem *ioaddr = hw->pcsr;
+
+ for (i = 0; i < 0xC8; i += 4) {
+ if (i == 0x32 || i == 0x3C)
+ continue;
+ reg_space[i / 4] = readl(ioaddr + i);
+ }
+}
+
+static void sun8i_dwmac_enable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(0, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v |= EMAC_TX_DMA_START;
+ v |= EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v |= EMAC_TX_DMA_START;
+ v |= EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v &= ~EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ v |= EMAC_RX_DMA_START;
+ v |= EMAC_RX_DMA_EN;
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static void sun8i_dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ v &= ~EMAC_RX_DMA_EN;
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static int sun8i_dwmac_dma_interrupt(void __iomem *ioaddr,
+ struct stmmac_extra_stats *x, u32 chan)
+{
+ u32 v;
+ int ret = 0;
+
+ v = readl(ioaddr + EMAC_INT_STA);
+
+ if (v & EMAC_TX_INT) {
+ ret |= handle_tx;
+ x->tx_normal_irq_n++;
+ }
+
+ if (v & EMAC_TX_DMA_STOP_INT)
+ x->tx_process_stopped_irq++;
+
+ if (v & EMAC_TX_BUF_UA_INT)
+ x->tx_process_stopped_irq++;
+
+ if (v & EMAC_TX_TIMEOUT_INT)
+ ret |= tx_hard_error;
+
+ if (v & EMAC_TX_UNDERFLOW_INT) {
+ ret |= tx_hard_error;
+ x->tx_undeflow_irq++;
+ }
+
+ if (v & EMAC_TX_EARLY_INT)
+ x->tx_early_irq++;
+
+ if (v & EMAC_RX_INT) {
+ ret |= handle_rx;
+ x->rx_normal_irq_n++;
+ }
+
+ if (v & EMAC_RX_BUF_UA_INT)
+ x->rx_buf_unav_irq++;
+
+ if (v & EMAC_RX_DMA_STOP_INT)
+ x->rx_process_stopped_irq++;
+
+ if (v & EMAC_RX_TIMEOUT_INT)
+ ret |= tx_hard_error;
+
+ if (v & EMAC_RX_OVERFLOW_INT) {
+ ret |= tx_hard_error;
+ x->rx_overflow_irq++;
+ }
+
+ if (v & EMAC_RX_EARLY_INT)
+ x->rx_early_irq++;
+
+ if (v & EMAC_RGMII_STA_INT)
+ x->irq_rgmii_n++;
+
+ writel(v, ioaddr + EMAC_INT_STA);
+
+ return ret;
+}
+
+static void sun8i_dwmac_dma_operation_mode(void __iomem *ioaddr, int txmode,
+ int rxmode, int rxfifosz)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ if (txmode == SF_DMA_MODE) {
+ v |= EMAC_TX_MD;
+ /* Undocumented bit (called TX_NEXT_FRM in BSP), the original
+ * comment is
+ * "Operating on second frame increase the performance
+ * especially when transmit store-and-forward is used."
+ */
+ v |= EMAC_TX_NEXT_FRM;
+ } else {
+ v &= ~EMAC_TX_MD;
+ v &= ~EMAC_TX_TH_MASK;
+ if (txmode < 64)
+ v |= EMAC_TX_TH_64;
+ else if (txmode < 128)
+ v |= EMAC_TX_TH_128;
+ else if (txmode < 192)
+ v |= EMAC_TX_TH_192;
+ else if (txmode < 256)
+ v |= EMAC_TX_TH_256;
+ }
+ writel(v, ioaddr + EMAC_TX_CTL1);
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ if (rxmode == SF_DMA_MODE) {
+ v |= EMAC_RX_MD;
+ } else {
+ v &= ~EMAC_RX_MD;
+ v &= ~EMAC_RX_TH_MASK;
+ if (rxmode < 32)
+ v |= EMAC_RX_TH_32;
+ else if (rxmode < 64)
+ v |= EMAC_RX_TH_64;
+ else if (rxmode < 96)
+ v |= EMAC_RX_TH_96;
+ else if (rxmode < 128)
+ v |= EMAC_RX_TH_128;
+ }
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static const struct stmmac_dma_ops sun8i_dwmac_dma_ops = {
+ .reset = sun8i_dwmac_dma_reset,
+ .init = sun8i_dwmac_dma_init,
+ .dump_regs = sun8i_dwmac_dump_regs,
+ .dma_mode = sun8i_dwmac_dma_operation_mode,
+ .enable_dma_transmission = sun8i_dwmac_enable_dma_transmission,
+ .enable_dma_irq = sun8i_dwmac_enable_dma_irq,
+ .disable_dma_irq = sun8i_dwmac_disable_dma_irq,
+ .start_tx = sun8i_dwmac_dma_start_tx,
+ .stop_tx = sun8i_dwmac_dma_stop_tx,
+ .start_rx = sun8i_dwmac_dma_start_rx,
+ .stop_rx = sun8i_dwmac_dma_stop_rx,
+ .dma_interrupt = sun8i_dwmac_dma_interrupt,
+};
+
+static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
+{
+ struct sunxi_priv_data *gmac = priv;
+ int ret;
+
+ if (gmac->regulator) {
+ ret = regulator_enable(gmac->regulator);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable regulator\n");
+ return ret;
+ }
+ }
+
+ ret = clk_prepare_enable(gmac->tx_clk);
+ if (ret) {
+ if (gmac->regulator)
+ regulator_disable(gmac->regulator);
+ dev_err(&pdev->dev, "Could not enable AHB clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = (8 << EMAC_BURSTLEN_SHIFT); /* burst len */
+ writel(v, ioaddr + EMAC_BASIC_CTL1);
+}
+
+static void sun8i_dwmac_set_mac(void __iomem *ioaddr, bool enable)
+{
+ u32 t, r;
+
+ t = readl(ioaddr + EMAC_TX_CTL0);
+ r = readl(ioaddr + EMAC_RX_CTL0);
+ if (enable) {
+ t |= EMAC_TX_TRANSMITTER_EN;
+ r |= EMAC_RX_RECEIVER_EN;
+ } else {
+ t &= ~EMAC_TX_TRANSMITTER_EN;
+ r &= ~EMAC_RX_RECEIVER_EN;
+ }
+ writel(t, ioaddr + EMAC_TX_CTL0);
+ writel(r, ioaddr + EMAC_RX_CTL0);
+}
+
+/* Set MAC address@slot reg_n
+ * All slot > 0 need to be enabled with MAC_ADDR_TYPE_DST
+ * If addr is NULL, clear the slot
+ */
+static void sun8i_dwmac_set_umac_addr(struct mac_device_info *hw,
+ unsigned char *addr,
+ unsigned int reg_n)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ if (!addr) {
+ writel(0, ioaddr + EMAC_MACADDR_HI(reg_n));
+ return;
+ }
+
+ stmmac_set_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
+ EMAC_MACADDR_LO(reg_n));
+ if (reg_n > 0) {
+ v = readl(ioaddr + EMAC_MACADDR_HI(reg_n));
+ v |= MAC_ADDR_TYPE_DST;
+ writel(v, ioaddr + EMAC_MACADDR_HI(reg_n));
+ }
+}
+
+static void sun8i_dwmac_get_umac_addr(struct mac_device_info *hw,
+ unsigned char *addr,
+ unsigned int reg_n)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ stmmac_get_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
+ EMAC_MACADDR_LO(reg_n));
+}
+
+/* caution this function must return non 0 to work */
+static int sun8i_dwmac_rx_ipc_enable(struct mac_device_info *hw)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL0);
+ v |= EMAC_RX_DO_CRC;
+ writel(v, ioaddr + EMAC_RX_CTL0);
+
+ return 1;
+}
+
+static void sun8i_dwmac_set_filter(struct mac_device_info *hw,
+ struct net_device *dev)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+ int i = 1;
+ struct netdev_hw_addr *ha;
+ int macaddrs = netdev_uc_count(dev) + netdev_mc_count(dev) + 1;
+
+ v = EMAC_FRM_FLT_CTL;
+
+ if (dev->flags & IFF_PROMISC) {
+ v = EMAC_FRM_FLT_RXALL;
+ } else if (dev->flags & IFF_ALLMULTI) {
+ v |= EMAC_FRM_FLT_MULTICAST;
+ } else if (macaddrs <= hw->unicast_filter_entries) {
+ if (!netdev_mc_empty(dev)) {
+ netdev_for_each_mc_addr(ha, dev) {
+ sun8i_dwmac_set_umac_addr(hw, ha->addr, i);
+ i++;
+ }
+ }
+ if (!netdev_uc_empty(dev)) {
+ netdev_for_each_uc_addr(ha, dev) {
+ sun8i_dwmac_set_umac_addr(hw, ha->addr, i);
+ i++;
+ }
+ }
+ } else {
+ netdev_info(dev, "Too many address, switching to promiscuous\n");
+ v = EMAC_FRM_FLT_RXALL;
+ }
+
+ /* Disable unused address filter slots */
+ while (i < hw->unicast_filter_entries)
+ sun8i_dwmac_set_umac_addr(hw, NULL, i++);
+
+ writel(v, ioaddr + EMAC_RX_FRM_FLT);
+}
+
+static void sun8i_dwmac_flow_ctrl(struct mac_device_info *hw,
+ unsigned int duplex, unsigned int fc,
+ unsigned int pause_time, u32 tx_cnt)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL0);
+ if (fc == FLOW_AUTO)
+ v |= EMAC_RX_FLOW_CTL_EN;
+ else
+ v &= ~EMAC_RX_FLOW_CTL_EN;
+ writel(v, ioaddr + EMAC_RX_CTL0);
+
+ v = readl(ioaddr + EMAC_TX_FLOW_CTL);
+ if (fc == FLOW_AUTO)
+ v |= EMAC_TX_FLOW_CTL_EN;
+ else
+ v &= ~EMAC_TX_FLOW_CTL_EN;
+ writel(v, ioaddr + EMAC_TX_FLOW_CTL);
+}
+
+static int sun8i_dwmac_reset(struct stmmac_priv *priv)
+{
+ u32 v;
+ int err;
+
+ v = readl(priv->ioaddr + EMAC_BASIC_CTL1);
+ writel(v | 0x01, priv->ioaddr + EMAC_BASIC_CTL1);
+
+ /* The timeout was previoulsy set to 10ms, but some board (OrangePI0)
+ * need more if no cable plugged. 100ms seems OK
+ */
+ err = readl_poll_timeout(priv->ioaddr + EMAC_BASIC_CTL1, v,
+ !(v & 0x01), 100, 100000);
+
+ if (err) {
+ dev_err(priv->device, "EMAC reset timeout\n");
+ return -EFAULT;
+ }
+ return 0;
+}
+
+static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ struct device_node *node = priv->device->of_node;
+ int ret;
+ u32 reg, val;
+
+ regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+ reg = gmac->variant->default_syscon_value;
+ if (reg != val)
+ dev_warn(priv->device,
+ "Current syscon value is not the default %x (expect %x)\n",
+ val, reg);
+
+ if (gmac->variant->internal_phy) {
+ if (!gmac->use_internal_phy) {
+ /* switch to external PHY interface */
+ reg &= ~H3_EPHY_SELECT;
+ } else {
+ reg |= H3_EPHY_SELECT;
+ reg &= ~H3_EPHY_SHUTDOWN;
+ dev_dbg(priv->device, "Select internal_phy %x\n", reg);
+
+ if (of_property_read_bool(priv->plat->phy_node,
+ "allwinner,leds-active-low"))
+ reg |= H3_EPHY_LED_POL;
+ else
+ reg &= ~H3_EPHY_LED_POL;
+
+ ret = of_mdio_parse_addr(priv->device,
+ priv->plat->phy_node);
+ if (ret < 0) {
+ dev_err(priv->device, "Could not parse MDIO addr\n");
+ return ret;
+ }
+ /* of_mdio_parse_addr returns a valid (0 ~ 31) PHY
+ * address. No need to mask it again.
+ */
+ reg |= ret << H3_EPHY_ADDR_SHIFT;
+ }
+ }
+
+ if (!of_property_read_u32(node, "allwinner,tx-delay-ps", &val)) {
+ if (val % 100) {
+ dev_err(priv->device, "tx-delay must be a multiple of 100\n");
+ return -EINVAL;
+ }
+ val /= 100;
+ dev_dbg(priv->device, "set tx-delay to %x\n", val);
+ if (val <= SYSCON_ETXDC_MASK) {
+ reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+ reg |= (val << SYSCON_ETXDC_SHIFT);
+ } else {
+ dev_err(priv->device, "Invalid TX clock delay: %d\n",
+ val);
+ return -EINVAL;
+ }
+ }
+
+ if (!of_property_read_u32(node, "allwinner,rx-delay-ps", &val)) {
+ if (val % 100) {
+ dev_err(priv->device, "rx-delay must be a multiple of 100\n");
+ return -EINVAL;
+ }
+ val /= 100;
+ dev_dbg(priv->device, "set rx-delay to %x\n", val);
+ if (val <= SYSCON_ERXDC_MASK) {
+ reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+ reg |= (val << SYSCON_ERXDC_SHIFT);
+ } else {
+ dev_err(priv->device, "Invalid RX clock delay: %d\n",
+ val);
+ return -EINVAL;
+ }
+ }
+
+ /* Clear interface mode bits */
+ reg &= ~(SYSCON_ETCS_MASK | SYSCON_EPIT);
+ if (gmac->variant->support_rmii)
+ reg &= ~SYSCON_RMII_EN;
+
+ switch (priv->plat->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ /* default */
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ reg |= SYSCON_EPIT | SYSCON_ETCS_INT_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ reg |= SYSCON_RMII_EN | SYSCON_ETCS_EXT_GMII;
+ break;
+ default:
+ dev_err(priv->device, "Unsupported interface mode: %s",
+ phy_modes(priv->plat->interface));
+ return -EINVAL;
+ }
+
+ regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+
+ return 0;
+}
+
+static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
+{
+ u32 reg = gmac->variant->default_syscon_value;
+
+ regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+}
+
+static int sun8i_dwmac_power_internal_phy(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ int ret;
+
+ if (!gmac->use_internal_phy)
+ return 0;
+
+ ret = clk_prepare_enable(gmac->ephy_clk);
+ if (ret) {
+ dev_err(priv->device, "Cannot enable ephy\n");
+ return ret;
+ }
+
+ ret = reset_control_deassert(gmac->rst_ephy);
+ if (ret) {
+ dev_err(priv->device, "Cannot deassert ephy\n");
+ clk_disable_unprepare(gmac->ephy_clk);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int sun8i_dwmac_unpower_internal_phy(struct sunxi_priv_data *gmac)
+{
+ if (!gmac->use_internal_phy)
+ return 0;
+
+ clk_disable_unprepare(gmac->ephy_clk);
+ reset_control_assert(gmac->rst_ephy);
+ return 0;
+}
+
+/* sun8i_power_phy() - Activate the PHY:
+ * In case of error, no need to call sun8i_unpower_phy(),
+ * it will be called anyway by sun8i_dwmac_exit()
+ */
+static int sun8i_power_phy(struct stmmac_priv *priv)
+{
+ int ret;
+
+ ret = sun8i_dwmac_power_internal_phy(priv);
+ if (ret)
+ return ret;
+
+ ret = sun8i_dwmac_set_syscon(priv);
+ if (ret)
+ return ret;
+
+ /* After changing syscon value, the MAC need reset or it will use
+ * the last value (and so the last PHY set.
+ */
+ ret = sun8i_dwmac_reset(priv);
+ if (ret)
+ return ret;
+ return 0;
+}
+
+static void sun8i_unpower_phy(struct sunxi_priv_data *gmac)
+{
+ sun8i_dwmac_unset_syscon(gmac);
+ sun8i_dwmac_unpower_internal_phy(gmac);
+}
+
+static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
+{
+ struct sunxi_priv_data *gmac = priv;
+
+ sun8i_unpower_phy(gmac);
+
+ clk_disable_unprepare(gmac->tx_clk);
+
+ if (gmac->regulator)
+ regulator_disable(gmac->regulator);
+}
+
+static const struct stmmac_ops sun8i_dwmac_ops = {
+ .core_init = sun8i_dwmac_core_init,
+ .set_mac = sun8i_dwmac_set_mac,
+ .dump_regs = sun8i_dwmac_dump_mac_regs,
+ .rx_ipc = sun8i_dwmac_rx_ipc_enable,
+ .set_filter = sun8i_dwmac_set_filter,
+ .flow_ctrl = sun8i_dwmac_flow_ctrl,
+ .set_umac_addr = sun8i_dwmac_set_umac_addr,
+ .get_umac_addr = sun8i_dwmac_get_umac_addr,
+};
+
+static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
+{
+ struct mac_device_info *mac;
+ struct stmmac_priv *priv = ppriv;
+ int ret;
+
+ mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
+ if (!mac)
+ return NULL;
+
+ ret = sun8i_power_phy(priv);
+ if (ret)
+ return NULL;
+
+ mac->pcsr = priv->ioaddr;
+ mac->mac = &sun8i_dwmac_ops;
+ mac->dma = &sun8i_dwmac_dma_ops;
+
+ /* The loopback bit seems to be re-set when link change
+ * Simply mask it each time
+ * Speed 10/100/1000 are set in BIT(2)/BIT(3)
+ */
+ mac->link.speed_mask = GENMASK(3, 2) | EMAC_LOOPBACK;
+ mac->link.speed10 = EMAC_SPEED_10;
+ mac->link.speed100 = EMAC_SPEED_100;
+ mac->link.speed1000 = EMAC_SPEED_1000;
+ mac->link.duplex = EMAC_DUPLEX_FULL;
+ mac->mii.addr = EMAC_MDIO_CMD;
+ mac->mii.data = EMAC_MDIO_DATA;
+ mac->mii.reg_shift = 4;
+ mac->mii.reg_mask = GENMASK(8, 4);
+ mac->mii.addr_shift = 12;
+ mac->mii.addr_mask = GENMASK(16, 12);
+ mac->mii.clk_csr_shift = 20;
+ mac->mii.clk_csr_mask = GENMASK(22, 20);
+ mac->unicast_filter_entries = 8;
+
+ /* Synopsys Id is not available */
+ priv->synopsys_id = 0;
+
+ return mac;
+}
+
+static int sun8i_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct sunxi_priv_data *gmac;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
+ if (!gmac)
+ return -ENOMEM;
+
+ gmac->variant = of_device_get_match_data(&pdev->dev);
+ if (!gmac->variant) {
+ dev_err(&pdev->dev, "Missing dwmac-sun8i variant\n");
+ return -EINVAL;
+ }
+
+ gmac->tx_clk = devm_clk_get(dev, "stmmaceth");
+ if (IS_ERR(gmac->tx_clk)) {
+ dev_err(dev, "Could not get TX clock\n");
+ return PTR_ERR(gmac->tx_clk);
+ }
+
+ /* Optional regulator for PHY */
+ gmac->regulator = devm_regulator_get_optional(dev, "phy");
+ if (IS_ERR(gmac->regulator)) {
+ if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_info(dev, "No regulator found\n");
+ gmac->regulator = NULL;
+ }
+
+ gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "syscon");
+ if (IS_ERR(gmac->regmap)) {
+ ret = PTR_ERR(gmac->regmap);
+ dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
+ return ret;
+ }
+
+ plat_dat->interface = of_get_phy_mode(dev->of_node);
+ if (plat_dat->interface == gmac->variant->internal_phy) {
+ dev_info(&pdev->dev, "Will use internal PHY\n");
+ gmac->use_internal_phy = true;
+ gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
+ if (IS_ERR(gmac->ephy_clk)) {
+ ret = PTR_ERR(gmac->ephy_clk);
+ dev_err(&pdev->dev, "Cannot get EPHY clock: %d\n", ret);
+ return -EINVAL;
+ }
+
+ gmac->rst_ephy = of_reset_control_get(plat_dat->phy_node, NULL);
+ if (IS_ERR(gmac->rst_ephy)) {
+ ret = PTR_ERR(gmac->rst_ephy);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ dev_err(&pdev->dev, "No EPHY reset control found %d\n",
+ ret);
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&pdev->dev, "Will use external PHY\n");
+ gmac->use_internal_phy = false;
+ }
+
+ /* platform data specifying hardware features and callbacks.
+ * hardware features were copied from Allwinner drivers.
+ */
+ plat_dat->rx_coe = STMMAC_RX_COE_TYPE2;
+ plat_dat->tx_coe = 1;
+ plat_dat->has_sun8i = true;
+ plat_dat->bsp_priv = gmac;
+ plat_dat->init = sun8i_dwmac_init;
+ plat_dat->exit = sun8i_dwmac_exit;
+ plat_dat->setup = sun8i_dwmac_setup;
+
+ ret = sun8i_dwmac_init(pdev, plat_dat->bsp_priv);
+ if (ret)
+ return ret;
+
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (ret)
+ sun8i_dwmac_exit(pdev, plat_dat->bsp_priv);
+
+ return ret;
+}
+
+static const struct of_device_id sun8i_dwmac_match[] = {
+ { .compatible = "allwinner,sun8i-h3-emac",
+ .data = &emac_variant_h3 },
+ { .compatible = "allwinner,sun8i-a83t-emac",
+ .data = &emac_variant_a83t },
+ { .compatible = "allwinner,sun50i-a64-emac",
+ .data = &emac_variant_a64 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
+
+static struct platform_driver sun8i_dwmac_driver = {
+ .probe = sun8i_dwmac_probe,
+ .remove = stmmac_pltfr_remove,
+ .driver = {
+ .name = "dwmac-sun8i",
+ .pm = &stmmac_pltfr_pm_ops,
+ .of_match_table = sun8i_dwmac_match,
+ },
+};
+module_platform_driver(sun8i_dwmac_driver);
+
+MODULE_AUTHOR("Corentin Labbe <clabbe.montjoie@gmail.com>");
+MODULE_DESCRIPTION("Allwinner sun8i DWMAC specific glue layer");
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c80c9c3b67db..68a188e74c54 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -235,6 +235,17 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
priv->clk_csr = STMMAC_CSR_250_300M;
}
+
+ if (priv->plat->has_sun8i) {
+ if (clk_rate > 160000000)
+ priv->clk_csr = 0x03;
+ else if (clk_rate > 80000000)
+ priv->clk_csr = 0x02;
+ else if (clk_rate > 40000000)
+ priv->clk_csr = 0x01;
+ else
+ priv->clk_csr = 0;
+ }
}
static void print_pkt(unsigned char *buf, int len)
@@ -3955,6 +3966,10 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->hw = mac;
+ /* dwmac-sun8i only work in chain mode */
+ if (priv->plat->has_sun8i)
+ chain_mode = 1;
+
/* To use the chained or ring mode */
if (priv->synopsys_id >= DWMAC_CORE_4_00) {
priv->hw->mode = &dwmac4_ring_mode_ops;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 7fc3a1ef395a..3840529344ed 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -309,6 +309,12 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
struct device_node *np, struct device *dev)
{
bool mdio = true;
+ static const struct of_device_id need_mdio_ids[] = {
+ { .compatible = "snps,dwc-qos-ethernet-4.10" },
+ { .compatible = "allwinner,sun8i-a83t-emac" },
+ { .compatible = "allwinner,sun8i-h3-emac" },
+ { .compatible = "allwinner,sun50i-a64-emac" },
+ };
/* If phy-handle property is passed from DT, use it as the PHY */
plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
@@ -325,8 +331,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
mdio = false;
}
- /* exception for dwmac-dwc-qos-eth glue logic */
- if (of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
+ if (of_match_node(need_mdio_ids, np)) {
plat->mdio_node = of_get_child_by_name(np, "mdio");
} else {
/**
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 8bb550bca96d..108739ff9223 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -186,6 +186,7 @@ struct plat_stmmacenet_data {
struct reset_control *stmmac_rst;
struct stmmac_axi *axi;
int has_gmac4;
+ bool has_sun8i;
bool tso_en;
int mac_port_sel_speed;
bool en_tx_lpi_clockgating;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i is a heavy hacked version of stmmac hardware by
allwinner.
In fact the only common part is the descriptor management and the first
register function.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 990 +++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 +-
include/linux/stmmac.h | 1 +
6 files changed, 1025 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cfbe3634dfa1..85c0e41f8021 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -145,6 +145,17 @@ config DWMAC_SUNXI
This selects Allwinner SoC glue layer support for the
stmmac device driver. This driver is used for A20/A31
GMAC ethernet controller.
+
+config DWMAC_SUN8I
+ tristate "Allwinner sun8i GMAC support"
+ default ARCH_SUNXI
+ depends on OF && (ARCH_SUNXI || COMPILE_TEST)
+ ---help---
+ Support for Allwinner H3 A83T A64 EMAC ethernet controllers.
+
+ This selects Allwinner SoC glue layer support for the
+ stmmac device driver. This driver is used for H3/A83T/A64
+ EMAC ethernet controller.
endif
config STMMAC_PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 700c60336674..fd4937a7fcab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
obj-$(CONFIG_DWMAC_STM32) += dwmac-stm32.o
obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
+obj-$(CONFIG_DWMAC_SUN8I) += dwmac-sun8i.o
obj-$(CONFIG_DWMAC_DWC_QOS_ETH) += dwmac-dwc-qos-eth.o
obj-$(CONFIG_DWMAC_GENERIC) += dwmac-generic.o
stmmac-platform-objs:= stmmac_platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
new file mode 100644
index 000000000000..1a6bfe6c958f
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -0,0 +1,990 @@
+/*
+ * dwmac-sun8i.c - Allwinner sun8i DWMAC specific glue layer
+ *
+ * Copyright (C) 2017 Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_mdio.h>
+#include <linux/of_net.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/regmap.h>
+#include <linux/stmmac.h>
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+
+/* General notes on dwmac-sun8i:
+ * Locking: no locking is necessary in this file because all necessary locking
+ * is done in the "stmmac files"
+ */
+
+/* struct emac_variant - Descrive dwmac-sun8i hardware variant
+ * @default_syscon_value: The default value of the EMAC register in syscon
+ * This value is used for disabling properly EMAC
+ * and used as a good starting value in case of the
+ * boot process(uboot) leave some stuff.
+ * @internal_phy: Does the MAC embed an internal PHY
+ * @support_mii: Does the MAC handle MII
+ * @support_rmii: Does the MAC handle RMII
+ * @support_rgmii: Does the MAC handle RGMII
+ */
+struct emac_variant {
+ u32 default_syscon_value;
+ int internal_phy;
+ bool support_mii;
+ bool support_rmii;
+ bool support_rgmii;
+};
+
+/* struct sunxi_priv_data - hold all sunxi private data
+ * @tx_clk: reference to MAC TX clock
+ * @ephy_clk: reference to the optional EPHY clock for the internal PHY
+ * @regulator: reference to the optional regulator
+ * @rst_ephy: reference to the optional EPHY reset for the internal PHY
+ * @variant: reference to the current board variant
+ * @regmap: regmap for using the syscon
+ * @use_internal_phy: Does the current PHY choice imply using the internal PHY
+ */
+struct sunxi_priv_data {
+ struct clk *tx_clk;
+ struct clk *ephy_clk;
+ struct regulator *regulator;
+ struct reset_control *rst_ephy;
+ const struct emac_variant *variant;
+ struct regmap *regmap;
+ bool use_internal_phy;
+};
+
+static const struct emac_variant emac_variant_h3 = {
+ .default_syscon_value = 0x58000,
+ .internal_phy = PHY_INTERFACE_MODE_MII,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true
+};
+
+static const struct emac_variant emac_variant_a83t = {
+ .default_syscon_value = 0,
+ .internal_phy = 0,
+ .support_mii = true,
+ .support_rgmii = true
+};
+
+static const struct emac_variant emac_variant_a64 = {
+ .default_syscon_value = 0,
+ .internal_phy = 0,
+ .support_mii = true,
+ .support_rmii = true,
+ .support_rgmii = true
+};
+
+#define EMAC_BASIC_CTL0 0x00
+#define EMAC_BASIC_CTL1 0x04
+#define EMAC_INT_STA 0x08
+#define EMAC_INT_EN 0x0C
+#define EMAC_TX_CTL0 0x10
+#define EMAC_TX_CTL1 0x14
+#define EMAC_TX_FLOW_CTL 0x1C
+#define EMAC_TX_DESC_LIST 0x20
+#define EMAC_RX_CTL0 0x24
+#define EMAC_RX_CTL1 0x28
+#define EMAC_RX_DESC_LIST 0x34
+#define EMAC_RX_FRM_FLT 0x38
+#define EMAC_MDIO_CMD 0x48
+#define EMAC_MDIO_DATA 0x4C
+#define EMAC_MACADDR_HI(reg) (0x50 + (reg) * 8)
+#define EMAC_MACADDR_LO(reg) (0x54 + (reg) * 8)
+#define EMAC_TX_DMA_STA 0xB0
+#define EMAC_TX_CUR_DESC 0xB4
+#define EMAC_TX_CUR_BUF 0xB8
+#define EMAC_RX_DMA_STA 0xC0
+#define EMAC_RX_CUR_DESC 0xC4
+#define EMAC_RX_CUR_BUF 0xC8
+
+/* Use in EMAC_BASIC_CTL0 */
+#define EMAC_DUPLEX_FULL BIT(0)
+#define EMAC_LOOPBACK BIT(1)
+#define EMAC_SPEED_1000 0
+#define EMAC_SPEED_100 (0x03 << 2)
+#define EMAC_SPEED_10 (0x02 << 2)
+
+/* Use in EMAC_BASIC_CTL1 */
+#define EMAC_BURSTLEN_SHIFT 24
+
+/* Used in EMAC_RX_FRM_FLT */
+#define EMAC_FRM_FLT_RXALL BIT(0)
+#define EMAC_FRM_FLT_CTL BIT(13)
+#define EMAC_FRM_FLT_MULTICAST BIT(16)
+
+/* Used in RX_CTL1*/
+#define EMAC_RX_MD BIT(1)
+#define EMAC_RX_TH_MASK GENMASK(4, 5)
+#define EMAC_RX_TH_32 0
+#define EMAC_RX_TH_64 (0x1 << 4)
+#define EMAC_RX_TH_96 (0x2 << 4)
+#define EMAC_RX_TH_128 (0x3 << 4)
+#define EMAC_RX_DMA_EN BIT(30)
+#define EMAC_RX_DMA_START BIT(31)
+
+/* Used in TX_CTL1*/
+#define EMAC_TX_MD BIT(1)
+#define EMAC_TX_NEXT_FRM BIT(2)
+#define EMAC_TX_TH_MASK GENMASK(8, 10)
+#define EMAC_TX_TH_64 0
+#define EMAC_TX_TH_128 (0x1 << 8)
+#define EMAC_TX_TH_192 (0x2 << 8)
+#define EMAC_TX_TH_256 (0x3 << 8)
+#define EMAC_TX_DMA_EN BIT(30)
+#define EMAC_TX_DMA_START BIT(31)
+
+/* Used in RX_CTL0 */
+#define EMAC_RX_RECEIVER_EN BIT(31)
+#define EMAC_RX_DO_CRC BIT(27)
+#define EMAC_RX_FLOW_CTL_EN BIT(16)
+
+/* Used in TX_CTL0 */
+#define EMAC_TX_TRANSMITTER_EN BIT(31)
+
+/* Used in EMAC_TX_FLOW_CTL */
+#define EMAC_TX_FLOW_CTL_EN BIT(0)
+
+/* Used in EMAC_INT_STA */
+#define EMAC_TX_INT BIT(0)
+#define EMAC_TX_DMA_STOP_INT BIT(1)
+#define EMAC_TX_BUF_UA_INT BIT(2)
+#define EMAC_TX_TIMEOUT_INT BIT(3)
+#define EMAC_TX_UNDERFLOW_INT BIT(4)
+#define EMAC_TX_EARLY_INT BIT(5)
+#define EMAC_RX_INT BIT(8)
+#define EMAC_RX_BUF_UA_INT BIT(9)
+#define EMAC_RX_DMA_STOP_INT BIT(10)
+#define EMAC_RX_TIMEOUT_INT BIT(11)
+#define EMAC_RX_OVERFLOW_INT BIT(12)
+#define EMAC_RX_EARLY_INT BIT(13)
+#define EMAC_RGMII_STA_INT BIT(16)
+
+#define MAC_ADDR_TYPE_DST BIT(31)
+
+/* H3 specific bits for EPHY */
+#define H3_EPHY_ADDR_SHIFT 20
+#define H3_EPHY_LED_POL BIT(17) /* 1: active low, 0: active high */
+#define H3_EPHY_SHUTDOWN BIT(16) /* 1: shutdown, 0: power up */
+#define H3_EPHY_SELECT BIT(15) /* 1: internal PHY, 0: external PHY */
+
+/* H3/A64 specific bits */
+#define SYSCON_RMII_EN BIT(13) /* 1: enable RMII (overrides EPIT) */
+
+/* Generic system control EMAC_CLK bits */
+#define SYSCON_ETXDC_MASK GENMASK(2, 0)
+#define SYSCON_ETXDC_SHIFT 10
+#define SYSCON_ERXDC_MASK GENMASK(4, 0)
+#define SYSCON_ERXDC_SHIFT 5
+/* EMAC PHY Interface Type */
+#define SYSCON_EPIT BIT(2) /* 1: RGMII, 0: MII */
+#define SYSCON_ETCS_MASK GENMASK(1, 0)
+#define SYSCON_ETCS_MII 0x0
+#define SYSCON_ETCS_EXT_GMII 0x1
+#define SYSCON_ETCS_INT_GMII 0x2
+#define SYSCON_EMAC_REG 0x30
+
+/* sun8i_dwmac_dma_reset() - reset the EMAC
+ * Called from stmmac via stmmac_dma_ops->reset
+ */
+static int sun8i_dwmac_dma_reset(void __iomem *ioaddr)
+{
+ writel(0, ioaddr + EMAC_RX_CTL1);
+ writel(0, ioaddr + EMAC_TX_CTL1);
+ writel(0, ioaddr + EMAC_RX_FRM_FLT);
+ writel(0, ioaddr + EMAC_RX_DESC_LIST);
+ writel(0, ioaddr + EMAC_TX_DESC_LIST);
+ writel(0, ioaddr + EMAC_INT_EN);
+ writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
+ return 0;
+}
+
+/* sun8i_dwmac_dma_init() - initialize the EMAC
+ * Called from stmmac via stmmac_dma_ops->init
+ */
+static void sun8i_dwmac_dma_init(void __iomem *ioaddr,
+ struct stmmac_dma_cfg *dma_cfg,
+ u32 dma_tx, u32 dma_rx, int atds)
+{
+ /* Write TX and RX descriptors address */
+ writel(dma_rx, ioaddr + EMAC_RX_DESC_LIST);
+ writel(dma_tx, ioaddr + EMAC_TX_DESC_LIST);
+
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+ writel(0x1FFFFFF, ioaddr + EMAC_INT_STA);
+}
+
+/* sun8i_dwmac_dump_regs() - Dump EMAC address space
+ * Called from stmmac_dma_ops->dump_regs
+ * Used for ethtool
+ */
+static void sun8i_dwmac_dump_regs(void __iomem *ioaddr, u32 *reg_space)
+{
+ int i;
+
+ for (i = 0; i < 0xC8; i += 4) {
+ if (i == 0x32 || i == 0x3C)
+ continue;
+ reg_space[i / 4] = readl(ioaddr + i);
+ }
+}
+
+/* sun8i_dwmac_dump_mac_regs() - Dump EMAC address space
+ * Called from stmmac_ops->dump_regs
+ * Used for ethtool
+ */
+static void sun8i_dwmac_dump_mac_regs(struct mac_device_info *hw,
+ u32 *reg_space)
+{
+ int i;
+ void __iomem *ioaddr = hw->pcsr;
+
+ for (i = 0; i < 0xC8; i += 4) {
+ if (i == 0x32 || i == 0x3C)
+ continue;
+ reg_space[i / 4] = readl(ioaddr + i);
+ }
+}
+
+static void sun8i_dwmac_enable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(EMAC_RX_INT | EMAC_TX_INT, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_disable_dma_irq(void __iomem *ioaddr, u32 chan)
+{
+ writel(0, ioaddr + EMAC_INT_EN);
+}
+
+static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v |= EMAC_TX_DMA_START;
+ v |= EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_enable_dma_transmission(void __iomem *ioaddr)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v |= EMAC_TX_DMA_START;
+ v |= EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_dma_stop_tx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ v &= ~EMAC_TX_DMA_EN;
+ writel(v, ioaddr + EMAC_TX_CTL1);
+}
+
+static void sun8i_dwmac_dma_start_rx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ v |= EMAC_RX_DMA_START;
+ v |= EMAC_RX_DMA_EN;
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static void sun8i_dwmac_dma_stop_rx(void __iomem *ioaddr, u32 chan)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ v &= ~EMAC_RX_DMA_EN;
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static int sun8i_dwmac_dma_interrupt(void __iomem *ioaddr,
+ struct stmmac_extra_stats *x, u32 chan)
+{
+ u32 v;
+ int ret = 0;
+
+ v = readl(ioaddr + EMAC_INT_STA);
+
+ if (v & EMAC_TX_INT) {
+ ret |= handle_tx;
+ x->tx_normal_irq_n++;
+ }
+
+ if (v & EMAC_TX_DMA_STOP_INT)
+ x->tx_process_stopped_irq++;
+
+ if (v & EMAC_TX_BUF_UA_INT)
+ x->tx_process_stopped_irq++;
+
+ if (v & EMAC_TX_TIMEOUT_INT)
+ ret |= tx_hard_error;
+
+ if (v & EMAC_TX_UNDERFLOW_INT) {
+ ret |= tx_hard_error;
+ x->tx_undeflow_irq++;
+ }
+
+ if (v & EMAC_TX_EARLY_INT)
+ x->tx_early_irq++;
+
+ if (v & EMAC_RX_INT) {
+ ret |= handle_rx;
+ x->rx_normal_irq_n++;
+ }
+
+ if (v & EMAC_RX_BUF_UA_INT)
+ x->rx_buf_unav_irq++;
+
+ if (v & EMAC_RX_DMA_STOP_INT)
+ x->rx_process_stopped_irq++;
+
+ if (v & EMAC_RX_TIMEOUT_INT)
+ ret |= tx_hard_error;
+
+ if (v & EMAC_RX_OVERFLOW_INT) {
+ ret |= tx_hard_error;
+ x->rx_overflow_irq++;
+ }
+
+ if (v & EMAC_RX_EARLY_INT)
+ x->rx_early_irq++;
+
+ if (v & EMAC_RGMII_STA_INT)
+ x->irq_rgmii_n++;
+
+ writel(v, ioaddr + EMAC_INT_STA);
+
+ return ret;
+}
+
+static void sun8i_dwmac_dma_operation_mode(void __iomem *ioaddr, int txmode,
+ int rxmode, int rxfifosz)
+{
+ u32 v;
+
+ v = readl(ioaddr + EMAC_TX_CTL1);
+ if (txmode == SF_DMA_MODE) {
+ v |= EMAC_TX_MD;
+ /* Undocumented bit (called TX_NEXT_FRM in BSP), the original
+ * comment is
+ * "Operating on second frame increase the performance
+ * especially when transmit store-and-forward is used."
+ */
+ v |= EMAC_TX_NEXT_FRM;
+ } else {
+ v &= ~EMAC_TX_MD;
+ v &= ~EMAC_TX_TH_MASK;
+ if (txmode < 64)
+ v |= EMAC_TX_TH_64;
+ else if (txmode < 128)
+ v |= EMAC_TX_TH_128;
+ else if (txmode < 192)
+ v |= EMAC_TX_TH_192;
+ else if (txmode < 256)
+ v |= EMAC_TX_TH_256;
+ }
+ writel(v, ioaddr + EMAC_TX_CTL1);
+
+ v = readl(ioaddr + EMAC_RX_CTL1);
+ if (rxmode == SF_DMA_MODE) {
+ v |= EMAC_RX_MD;
+ } else {
+ v &= ~EMAC_RX_MD;
+ v &= ~EMAC_RX_TH_MASK;
+ if (rxmode < 32)
+ v |= EMAC_RX_TH_32;
+ else if (rxmode < 64)
+ v |= EMAC_RX_TH_64;
+ else if (rxmode < 96)
+ v |= EMAC_RX_TH_96;
+ else if (rxmode < 128)
+ v |= EMAC_RX_TH_128;
+ }
+ writel(v, ioaddr + EMAC_RX_CTL1);
+}
+
+static const struct stmmac_dma_ops sun8i_dwmac_dma_ops = {
+ .reset = sun8i_dwmac_dma_reset,
+ .init = sun8i_dwmac_dma_init,
+ .dump_regs = sun8i_dwmac_dump_regs,
+ .dma_mode = sun8i_dwmac_dma_operation_mode,
+ .enable_dma_transmission = sun8i_dwmac_enable_dma_transmission,
+ .enable_dma_irq = sun8i_dwmac_enable_dma_irq,
+ .disable_dma_irq = sun8i_dwmac_disable_dma_irq,
+ .start_tx = sun8i_dwmac_dma_start_tx,
+ .stop_tx = sun8i_dwmac_dma_stop_tx,
+ .start_rx = sun8i_dwmac_dma_start_rx,
+ .stop_rx = sun8i_dwmac_dma_stop_rx,
+ .dma_interrupt = sun8i_dwmac_dma_interrupt,
+};
+
+static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
+{
+ struct sunxi_priv_data *gmac = priv;
+ int ret;
+
+ if (gmac->regulator) {
+ ret = regulator_enable(gmac->regulator);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable regulator\n");
+ return ret;
+ }
+ }
+
+ ret = clk_prepare_enable(gmac->tx_clk);
+ if (ret) {
+ if (gmac->regulator)
+ regulator_disable(gmac->regulator);
+ dev_err(&pdev->dev, "Could not enable AHB clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = (8 << EMAC_BURSTLEN_SHIFT); /* burst len */
+ writel(v, ioaddr + EMAC_BASIC_CTL1);
+}
+
+static void sun8i_dwmac_set_mac(void __iomem *ioaddr, bool enable)
+{
+ u32 t, r;
+
+ t = readl(ioaddr + EMAC_TX_CTL0);
+ r = readl(ioaddr + EMAC_RX_CTL0);
+ if (enable) {
+ t |= EMAC_TX_TRANSMITTER_EN;
+ r |= EMAC_RX_RECEIVER_EN;
+ } else {
+ t &= ~EMAC_TX_TRANSMITTER_EN;
+ r &= ~EMAC_RX_RECEIVER_EN;
+ }
+ writel(t, ioaddr + EMAC_TX_CTL0);
+ writel(r, ioaddr + EMAC_RX_CTL0);
+}
+
+/* Set MAC address at slot reg_n
+ * All slot > 0 need to be enabled with MAC_ADDR_TYPE_DST
+ * If addr is NULL, clear the slot
+ */
+static void sun8i_dwmac_set_umac_addr(struct mac_device_info *hw,
+ unsigned char *addr,
+ unsigned int reg_n)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ if (!addr) {
+ writel(0, ioaddr + EMAC_MACADDR_HI(reg_n));
+ return;
+ }
+
+ stmmac_set_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
+ EMAC_MACADDR_LO(reg_n));
+ if (reg_n > 0) {
+ v = readl(ioaddr + EMAC_MACADDR_HI(reg_n));
+ v |= MAC_ADDR_TYPE_DST;
+ writel(v, ioaddr + EMAC_MACADDR_HI(reg_n));
+ }
+}
+
+static void sun8i_dwmac_get_umac_addr(struct mac_device_info *hw,
+ unsigned char *addr,
+ unsigned int reg_n)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ stmmac_get_mac_addr(ioaddr, addr, EMAC_MACADDR_HI(reg_n),
+ EMAC_MACADDR_LO(reg_n));
+}
+
+/* caution this function must return non 0 to work */
+static int sun8i_dwmac_rx_ipc_enable(struct mac_device_info *hw)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL0);
+ v |= EMAC_RX_DO_CRC;
+ writel(v, ioaddr + EMAC_RX_CTL0);
+
+ return 1;
+}
+
+static void sun8i_dwmac_set_filter(struct mac_device_info *hw,
+ struct net_device *dev)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+ int i = 1;
+ struct netdev_hw_addr *ha;
+ int macaddrs = netdev_uc_count(dev) + netdev_mc_count(dev) + 1;
+
+ v = EMAC_FRM_FLT_CTL;
+
+ if (dev->flags & IFF_PROMISC) {
+ v = EMAC_FRM_FLT_RXALL;
+ } else if (dev->flags & IFF_ALLMULTI) {
+ v |= EMAC_FRM_FLT_MULTICAST;
+ } else if (macaddrs <= hw->unicast_filter_entries) {
+ if (!netdev_mc_empty(dev)) {
+ netdev_for_each_mc_addr(ha, dev) {
+ sun8i_dwmac_set_umac_addr(hw, ha->addr, i);
+ i++;
+ }
+ }
+ if (!netdev_uc_empty(dev)) {
+ netdev_for_each_uc_addr(ha, dev) {
+ sun8i_dwmac_set_umac_addr(hw, ha->addr, i);
+ i++;
+ }
+ }
+ } else {
+ netdev_info(dev, "Too many address, switching to promiscuous\n");
+ v = EMAC_FRM_FLT_RXALL;
+ }
+
+ /* Disable unused address filter slots */
+ while (i < hw->unicast_filter_entries)
+ sun8i_dwmac_set_umac_addr(hw, NULL, i++);
+
+ writel(v, ioaddr + EMAC_RX_FRM_FLT);
+}
+
+static void sun8i_dwmac_flow_ctrl(struct mac_device_info *hw,
+ unsigned int duplex, unsigned int fc,
+ unsigned int pause_time, u32 tx_cnt)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 v;
+
+ v = readl(ioaddr + EMAC_RX_CTL0);
+ if (fc == FLOW_AUTO)
+ v |= EMAC_RX_FLOW_CTL_EN;
+ else
+ v &= ~EMAC_RX_FLOW_CTL_EN;
+ writel(v, ioaddr + EMAC_RX_CTL0);
+
+ v = readl(ioaddr + EMAC_TX_FLOW_CTL);
+ if (fc == FLOW_AUTO)
+ v |= EMAC_TX_FLOW_CTL_EN;
+ else
+ v &= ~EMAC_TX_FLOW_CTL_EN;
+ writel(v, ioaddr + EMAC_TX_FLOW_CTL);
+}
+
+static int sun8i_dwmac_reset(struct stmmac_priv *priv)
+{
+ u32 v;
+ int err;
+
+ v = readl(priv->ioaddr + EMAC_BASIC_CTL1);
+ writel(v | 0x01, priv->ioaddr + EMAC_BASIC_CTL1);
+
+ /* The timeout was previoulsy set to 10ms, but some board (OrangePI0)
+ * need more if no cable plugged. 100ms seems OK
+ */
+ err = readl_poll_timeout(priv->ioaddr + EMAC_BASIC_CTL1, v,
+ !(v & 0x01), 100, 100000);
+
+ if (err) {
+ dev_err(priv->device, "EMAC reset timeout\n");
+ return -EFAULT;
+ }
+ return 0;
+}
+
+static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ struct device_node *node = priv->device->of_node;
+ int ret;
+ u32 reg, val;
+
+ regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+ reg = gmac->variant->default_syscon_value;
+ if (reg != val)
+ dev_warn(priv->device,
+ "Current syscon value is not the default %x (expect %x)\n",
+ val, reg);
+
+ if (gmac->variant->internal_phy) {
+ if (!gmac->use_internal_phy) {
+ /* switch to external PHY interface */
+ reg &= ~H3_EPHY_SELECT;
+ } else {
+ reg |= H3_EPHY_SELECT;
+ reg &= ~H3_EPHY_SHUTDOWN;
+ dev_dbg(priv->device, "Select internal_phy %x\n", reg);
+
+ if (of_property_read_bool(priv->plat->phy_node,
+ "allwinner,leds-active-low"))
+ reg |= H3_EPHY_LED_POL;
+ else
+ reg &= ~H3_EPHY_LED_POL;
+
+ ret = of_mdio_parse_addr(priv->device,
+ priv->plat->phy_node);
+ if (ret < 0) {
+ dev_err(priv->device, "Could not parse MDIO addr\n");
+ return ret;
+ }
+ /* of_mdio_parse_addr returns a valid (0 ~ 31) PHY
+ * address. No need to mask it again.
+ */
+ reg |= ret << H3_EPHY_ADDR_SHIFT;
+ }
+ }
+
+ if (!of_property_read_u32(node, "allwinner,tx-delay-ps", &val)) {
+ if (val % 100) {
+ dev_err(priv->device, "tx-delay must be a multiple of 100\n");
+ return -EINVAL;
+ }
+ val /= 100;
+ dev_dbg(priv->device, "set tx-delay to %x\n", val);
+ if (val <= SYSCON_ETXDC_MASK) {
+ reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+ reg |= (val << SYSCON_ETXDC_SHIFT);
+ } else {
+ dev_err(priv->device, "Invalid TX clock delay: %d\n",
+ val);
+ return -EINVAL;
+ }
+ }
+
+ if (!of_property_read_u32(node, "allwinner,rx-delay-ps", &val)) {
+ if (val % 100) {
+ dev_err(priv->device, "rx-delay must be a multiple of 100\n");
+ return -EINVAL;
+ }
+ val /= 100;
+ dev_dbg(priv->device, "set rx-delay to %x\n", val);
+ if (val <= SYSCON_ERXDC_MASK) {
+ reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+ reg |= (val << SYSCON_ERXDC_SHIFT);
+ } else {
+ dev_err(priv->device, "Invalid RX clock delay: %d\n",
+ val);
+ return -EINVAL;
+ }
+ }
+
+ /* Clear interface mode bits */
+ reg &= ~(SYSCON_ETCS_MASK | SYSCON_EPIT);
+ if (gmac->variant->support_rmii)
+ reg &= ~SYSCON_RMII_EN;
+
+ switch (priv->plat->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ /* default */
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ reg |= SYSCON_EPIT | SYSCON_ETCS_INT_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ reg |= SYSCON_RMII_EN | SYSCON_ETCS_EXT_GMII;
+ break;
+ default:
+ dev_err(priv->device, "Unsupported interface mode: %s",
+ phy_modes(priv->plat->interface));
+ return -EINVAL;
+ }
+
+ regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+
+ return 0;
+}
+
+static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
+{
+ u32 reg = gmac->variant->default_syscon_value;
+
+ regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+}
+
+static int sun8i_dwmac_power_internal_phy(struct stmmac_priv *priv)
+{
+ struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+ int ret;
+
+ if (!gmac->use_internal_phy)
+ return 0;
+
+ ret = clk_prepare_enable(gmac->ephy_clk);
+ if (ret) {
+ dev_err(priv->device, "Cannot enable ephy\n");
+ return ret;
+ }
+
+ ret = reset_control_deassert(gmac->rst_ephy);
+ if (ret) {
+ dev_err(priv->device, "Cannot deassert ephy\n");
+ clk_disable_unprepare(gmac->ephy_clk);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int sun8i_dwmac_unpower_internal_phy(struct sunxi_priv_data *gmac)
+{
+ if (!gmac->use_internal_phy)
+ return 0;
+
+ clk_disable_unprepare(gmac->ephy_clk);
+ reset_control_assert(gmac->rst_ephy);
+ return 0;
+}
+
+/* sun8i_power_phy() - Activate the PHY:
+ * In case of error, no need to call sun8i_unpower_phy(),
+ * it will be called anyway by sun8i_dwmac_exit()
+ */
+static int sun8i_power_phy(struct stmmac_priv *priv)
+{
+ int ret;
+
+ ret = sun8i_dwmac_power_internal_phy(priv);
+ if (ret)
+ return ret;
+
+ ret = sun8i_dwmac_set_syscon(priv);
+ if (ret)
+ return ret;
+
+ /* After changing syscon value, the MAC need reset or it will use
+ * the last value (and so the last PHY set.
+ */
+ ret = sun8i_dwmac_reset(priv);
+ if (ret)
+ return ret;
+ return 0;
+}
+
+static void sun8i_unpower_phy(struct sunxi_priv_data *gmac)
+{
+ sun8i_dwmac_unset_syscon(gmac);
+ sun8i_dwmac_unpower_internal_phy(gmac);
+}
+
+static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
+{
+ struct sunxi_priv_data *gmac = priv;
+
+ sun8i_unpower_phy(gmac);
+
+ clk_disable_unprepare(gmac->tx_clk);
+
+ if (gmac->regulator)
+ regulator_disable(gmac->regulator);
+}
+
+static const struct stmmac_ops sun8i_dwmac_ops = {
+ .core_init = sun8i_dwmac_core_init,
+ .set_mac = sun8i_dwmac_set_mac,
+ .dump_regs = sun8i_dwmac_dump_mac_regs,
+ .rx_ipc = sun8i_dwmac_rx_ipc_enable,
+ .set_filter = sun8i_dwmac_set_filter,
+ .flow_ctrl = sun8i_dwmac_flow_ctrl,
+ .set_umac_addr = sun8i_dwmac_set_umac_addr,
+ .get_umac_addr = sun8i_dwmac_get_umac_addr,
+};
+
+static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
+{
+ struct mac_device_info *mac;
+ struct stmmac_priv *priv = ppriv;
+ int ret;
+
+ mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
+ if (!mac)
+ return NULL;
+
+ ret = sun8i_power_phy(priv);
+ if (ret)
+ return NULL;
+
+ mac->pcsr = priv->ioaddr;
+ mac->mac = &sun8i_dwmac_ops;
+ mac->dma = &sun8i_dwmac_dma_ops;
+
+ /* The loopback bit seems to be re-set when link change
+ * Simply mask it each time
+ * Speed 10/100/1000 are set in BIT(2)/BIT(3)
+ */
+ mac->link.speed_mask = GENMASK(3, 2) | EMAC_LOOPBACK;
+ mac->link.speed10 = EMAC_SPEED_10;
+ mac->link.speed100 = EMAC_SPEED_100;
+ mac->link.speed1000 = EMAC_SPEED_1000;
+ mac->link.duplex = EMAC_DUPLEX_FULL;
+ mac->mii.addr = EMAC_MDIO_CMD;
+ mac->mii.data = EMAC_MDIO_DATA;
+ mac->mii.reg_shift = 4;
+ mac->mii.reg_mask = GENMASK(8, 4);
+ mac->mii.addr_shift = 12;
+ mac->mii.addr_mask = GENMASK(16, 12);
+ mac->mii.clk_csr_shift = 20;
+ mac->mii.clk_csr_mask = GENMASK(22, 20);
+ mac->unicast_filter_entries = 8;
+
+ /* Synopsys Id is not available */
+ priv->synopsys_id = 0;
+
+ return mac;
+}
+
+static int sun8i_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct sunxi_priv_data *gmac;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
+ if (!gmac)
+ return -ENOMEM;
+
+ gmac->variant = of_device_get_match_data(&pdev->dev);
+ if (!gmac->variant) {
+ dev_err(&pdev->dev, "Missing dwmac-sun8i variant\n");
+ return -EINVAL;
+ }
+
+ gmac->tx_clk = devm_clk_get(dev, "stmmaceth");
+ if (IS_ERR(gmac->tx_clk)) {
+ dev_err(dev, "Could not get TX clock\n");
+ return PTR_ERR(gmac->tx_clk);
+ }
+
+ /* Optional regulator for PHY */
+ gmac->regulator = devm_regulator_get_optional(dev, "phy");
+ if (IS_ERR(gmac->regulator)) {
+ if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_info(dev, "No regulator found\n");
+ gmac->regulator = NULL;
+ }
+
+ gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "syscon");
+ if (IS_ERR(gmac->regmap)) {
+ ret = PTR_ERR(gmac->regmap);
+ dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
+ return ret;
+ }
+
+ plat_dat->interface = of_get_phy_mode(dev->of_node);
+ if (plat_dat->interface == gmac->variant->internal_phy) {
+ dev_info(&pdev->dev, "Will use internal PHY\n");
+ gmac->use_internal_phy = true;
+ gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
+ if (IS_ERR(gmac->ephy_clk)) {
+ ret = PTR_ERR(gmac->ephy_clk);
+ dev_err(&pdev->dev, "Cannot get EPHY clock: %d\n", ret);
+ return -EINVAL;
+ }
+
+ gmac->rst_ephy = of_reset_control_get(plat_dat->phy_node, NULL);
+ if (IS_ERR(gmac->rst_ephy)) {
+ ret = PTR_ERR(gmac->rst_ephy);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ dev_err(&pdev->dev, "No EPHY reset control found %d\n",
+ ret);
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&pdev->dev, "Will use external PHY\n");
+ gmac->use_internal_phy = false;
+ }
+
+ /* platform data specifying hardware features and callbacks.
+ * hardware features were copied from Allwinner drivers.
+ */
+ plat_dat->rx_coe = STMMAC_RX_COE_TYPE2;
+ plat_dat->tx_coe = 1;
+ plat_dat->has_sun8i = true;
+ plat_dat->bsp_priv = gmac;
+ plat_dat->init = sun8i_dwmac_init;
+ plat_dat->exit = sun8i_dwmac_exit;
+ plat_dat->setup = sun8i_dwmac_setup;
+
+ ret = sun8i_dwmac_init(pdev, plat_dat->bsp_priv);
+ if (ret)
+ return ret;
+
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (ret)
+ sun8i_dwmac_exit(pdev, plat_dat->bsp_priv);
+
+ return ret;
+}
+
+static const struct of_device_id sun8i_dwmac_match[] = {
+ { .compatible = "allwinner,sun8i-h3-emac",
+ .data = &emac_variant_h3 },
+ { .compatible = "allwinner,sun8i-a83t-emac",
+ .data = &emac_variant_a83t },
+ { .compatible = "allwinner,sun50i-a64-emac",
+ .data = &emac_variant_a64 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
+
+static struct platform_driver sun8i_dwmac_driver = {
+ .probe = sun8i_dwmac_probe,
+ .remove = stmmac_pltfr_remove,
+ .driver = {
+ .name = "dwmac-sun8i",
+ .pm = &stmmac_pltfr_pm_ops,
+ .of_match_table = sun8i_dwmac_match,
+ },
+};
+module_platform_driver(sun8i_dwmac_driver);
+
+MODULE_AUTHOR("Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
+MODULE_DESCRIPTION("Allwinner sun8i DWMAC specific glue layer");
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c80c9c3b67db..68a188e74c54 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -235,6 +235,17 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
priv->clk_csr = STMMAC_CSR_250_300M;
}
+
+ if (priv->plat->has_sun8i) {
+ if (clk_rate > 160000000)
+ priv->clk_csr = 0x03;
+ else if (clk_rate > 80000000)
+ priv->clk_csr = 0x02;
+ else if (clk_rate > 40000000)
+ priv->clk_csr = 0x01;
+ else
+ priv->clk_csr = 0;
+ }
}
static void print_pkt(unsigned char *buf, int len)
@@ -3955,6 +3966,10 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->hw = mac;
+ /* dwmac-sun8i only work in chain mode */
+ if (priv->plat->has_sun8i)
+ chain_mode = 1;
+
/* To use the chained or ring mode */
if (priv->synopsys_id >= DWMAC_CORE_4_00) {
priv->hw->mode = &dwmac4_ring_mode_ops;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 7fc3a1ef395a..3840529344ed 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -309,6 +309,12 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
struct device_node *np, struct device *dev)
{
bool mdio = true;
+ static const struct of_device_id need_mdio_ids[] = {
+ { .compatible = "snps,dwc-qos-ethernet-4.10" },
+ { .compatible = "allwinner,sun8i-a83t-emac" },
+ { .compatible = "allwinner,sun8i-h3-emac" },
+ { .compatible = "allwinner,sun50i-a64-emac" },
+ };
/* If phy-handle property is passed from DT, use it as the PHY */
plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
@@ -325,8 +331,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
mdio = false;
}
- /* exception for dwmac-dwc-qos-eth glue logic */
- if (of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
+ if (of_match_node(need_mdio_ids, np)) {
plat->mdio_node = of_get_child_by_name(np, "mdio");
} else {
/**
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 8bb550bca96d..108739ff9223 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -186,6 +186,7 @@ struct plat_stmmacenet_data {
struct reset_control *stmmac_rst;
struct stmmac_axi *axi;
int has_gmac4;
+ bool has_sun8i;
bool tso_en;
int mac_port_sel_speed;
bool en_tx_lpi_clockgating;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-26 0:18 ` André Przywara
0 siblings, 0 replies; 148+ messages in thread
From: André Przywara @ 2017-06-26 0:18 UTC (permalink / raw)
To: Corentin Labbe, robh+dt, mark.rutland, maxime.ripard, wens,
linux, catalin.marinas, will.deacon, peppe.cavallaro,
alexandre.torgue
Cc: devicetree, netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
Icenowy Zheng
On 31/05/17 08:18, Corentin Labbe wrote:
> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> allwinner.
> In fact the only common part is the descriptor management and the first
> register function.
Hi,
I know I am a bit late with this, but while adapting the U-Boot driver
to the new binding I was wondering about the internal PHY detection:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> new file mode 100644
> index 000000000000..1a6bfe6c958f
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -0,0 +1,990 @@
....
> +static int sun8i_dwmac_probe(struct platform_device *pdev)
> +{
> + struct plat_stmmacenet_data *plat_dat;
> + struct stmmac_resources stmmac_res;
> + struct sunxi_priv_data *gmac;
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> + if (ret)
> + return ret;
> +
> + plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> + if (IS_ERR(plat_dat))
> + return PTR_ERR(plat_dat);
> +
> + gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
> + if (!gmac)
> + return -ENOMEM;
> +
> + gmac->variant = of_device_get_match_data(&pdev->dev);
> + if (!gmac->variant) {
> + dev_err(&pdev->dev, "Missing dwmac-sun8i variant\n");
> + return -EINVAL;
> + }
> +
> + gmac->tx_clk = devm_clk_get(dev, "stmmaceth");
> + if (IS_ERR(gmac->tx_clk)) {
> + dev_err(dev, "Could not get TX clock\n");
> + return PTR_ERR(gmac->tx_clk);
> + }
> +
> + /* Optional regulator for PHY */
> + gmac->regulator = devm_regulator_get_optional(dev, "phy");
> + if (IS_ERR(gmac->regulator)) {
> + if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_info(dev, "No regulator found\n");
> + gmac->regulator = NULL;
> + }
> +
> + gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> + "syscon");
> + if (IS_ERR(gmac->regmap)) {
> + ret = PTR_ERR(gmac->regmap);
> + dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
> + return ret;
> + }
> +
> + plat_dat->interface = of_get_phy_mode(dev->of_node);
> + if (plat_dat->interface == gmac->variant->internal_phy) {
> + dev_info(&pdev->dev, "Will use internal PHY\n");
So here you seem to deduce the usage of the internal PHY by the PHY
interface specified in the DT (MII = internal, RGMII = external).
I think I raised this question before, but isn't it perfectly legal for
a board to use MII with an external PHY even on those SoCs that feature
an internal PHY?
On the first glance that does not make too much sense, but apart from
not being the correct binding to describe all of the SoCs features I see
two scenarios:
1) A board vendor might choose to not use the internal PHY because it
has bugs, lacks features (configurability) or has other issues. For
instance I have heard reports that the internal PHY makes the SoC go
rather hot, possibly limiting the CPU frequency. By using an external
MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
2) A PHY does not necessarily need to be directly connected to
magnetics. Indeed quite some boards use (RG)MII to connect to a switch
IC or some other network circuitry, for instance fibre connectors.
So I was wondering if we would need an explicit:
allwinner,use-internal-phy;
boolean DT property to signal the usage of the internal PHY?
Alternatively we could go with the negative version:
allwinner,disable-internal-phy;
Or what about introducing a new "allwinner,internal-mii-phy" compatible
string for the *PHY* node and use that?
I just want to avoid that we introduce a binding that causes us
headaches later. I think we can still fix this with a followup patch
before the driver and its binding hit a release kernel.
Cheers,
Andre.
> + gmac->use_internal_phy = true;
> + gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
> + if (IS_ERR(gmac->ephy_clk)) {
> + ret = PTR_ERR(gmac->ephy_clk);
> + dev_err(&pdev->dev, "Cannot get EPHY clock: %d\n", ret);
> + return -EINVAL;
> + }
> +
> + gmac->rst_ephy = of_reset_control_get(plat_dat->phy_node, NULL);
> + if (IS_ERR(gmac->rst_ephy)) {
> + ret = PTR_ERR(gmac->rst_ephy);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + dev_err(&pdev->dev, "No EPHY reset control found %d\n",
> + ret);
> + return -EINVAL;
> + }
> + } else {
> + dev_info(&pdev->dev, "Will use external PHY\n");
> + gmac->use_internal_phy = false;
> + }
> +
> + /* platform data specifying hardware features and callbacks.
> + * hardware features were copied from Allwinner drivers.
> + */
> + plat_dat->rx_coe = STMMAC_RX_COE_TYPE2;
> + plat_dat->tx_coe = 1;
> + plat_dat->has_sun8i = true;
> + plat_dat->bsp_priv = gmac;
> + plat_dat->init = sun8i_dwmac_init;
> + plat_dat->exit = sun8i_dwmac_exit;
> + plat_dat->setup = sun8i_dwmac_setup;
> +
> + ret = sun8i_dwmac_init(pdev, plat_dat->bsp_priv);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
> + if (ret)
> + sun8i_dwmac_exit(pdev, plat_dat->bsp_priv);
> +
> + return ret;
> +}
> +
> +static const struct of_device_id sun8i_dwmac_match[] = {
> + { .compatible = "allwinner,sun8i-h3-emac",
> + .data = &emac_variant_h3 },
> + { .compatible = "allwinner,sun8i-a83t-emac",
> + .data = &emac_variant_a83t },
> + { .compatible = "allwinner,sun50i-a64-emac",
> + .data = &emac_variant_a64 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
> +
> +static struct platform_driver sun8i_dwmac_driver = {
> + .probe = sun8i_dwmac_probe,
> + .remove = stmmac_pltfr_remove,
> + .driver = {
> + .name = "dwmac-sun8i",
> + .pm = &stmmac_pltfr_pm_ops,
> + .of_match_table = sun8i_dwmac_match,
> + },
> +};
> +module_platform_driver(sun8i_dwmac_driver);
> +
> +MODULE_AUTHOR("Corentin Labbe <clabbe.montjoie@gmail.com>");
> +MODULE_DESCRIPTION("Allwinner sun8i DWMAC specific glue layer");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index c80c9c3b67db..68a188e74c54 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -235,6 +235,17 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
> else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
> priv->clk_csr = STMMAC_CSR_250_300M;
> }
> +
> + if (priv->plat->has_sun8i) {
> + if (clk_rate > 160000000)
> + priv->clk_csr = 0x03;
> + else if (clk_rate > 80000000)
> + priv->clk_csr = 0x02;
> + else if (clk_rate > 40000000)
> + priv->clk_csr = 0x01;
> + else
> + priv->clk_csr = 0;
> + }
> }
>
> static void print_pkt(unsigned char *buf, int len)
> @@ -3955,6 +3966,10 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
>
> priv->hw = mac;
>
> + /* dwmac-sun8i only work in chain mode */
> + if (priv->plat->has_sun8i)
> + chain_mode = 1;
> +
> /* To use the chained or ring mode */
> if (priv->synopsys_id >= DWMAC_CORE_4_00) {
> priv->hw->mode = &dwmac4_ring_mode_ops;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 7fc3a1ef395a..3840529344ed 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -309,6 +309,12 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> struct device_node *np, struct device *dev)
> {
> bool mdio = true;
> + static const struct of_device_id need_mdio_ids[] = {
> + { .compatible = "snps,dwc-qos-ethernet-4.10" },
> + { .compatible = "allwinner,sun8i-a83t-emac" },
> + { .compatible = "allwinner,sun8i-h3-emac" },
> + { .compatible = "allwinner,sun50i-a64-emac" },
> + };
>
> /* If phy-handle property is passed from DT, use it as the PHY */
> plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
> @@ -325,8 +331,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> mdio = false;
> }
>
> - /* exception for dwmac-dwc-qos-eth glue logic */
> - if (of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
> + if (of_match_node(need_mdio_ids, np)) {
> plat->mdio_node = of_get_child_by_name(np, "mdio");
> } else {
> /**
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 8bb550bca96d..108739ff9223 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -186,6 +186,7 @@ struct plat_stmmacenet_data {
> struct reset_control *stmmac_rst;
> struct stmmac_axi *axi;
> int has_gmac4;
> + bool has_sun8i;
> bool tso_en;
> int mac_port_sel_speed;
> bool en_tx_lpi_clockgating;
>
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-26 0:18 ` André Przywara
0 siblings, 0 replies; 148+ messages in thread
From: André Przywara @ 2017-06-26 0:18 UTC (permalink / raw)
To: linux-arm-kernel
On 31/05/17 08:18, Corentin Labbe wrote:
> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> allwinner.
> In fact the only common part is the descriptor management and the first
> register function.
Hi,
I know I am a bit late with this, but while adapting the U-Boot driver
to the new binding I was wondering about the internal PHY detection:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> new file mode 100644
> index 000000000000..1a6bfe6c958f
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -0,0 +1,990 @@
....
> +static int sun8i_dwmac_probe(struct platform_device *pdev)
> +{
> + struct plat_stmmacenet_data *plat_dat;
> + struct stmmac_resources stmmac_res;
> + struct sunxi_priv_data *gmac;
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> + if (ret)
> + return ret;
> +
> + plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> + if (IS_ERR(plat_dat))
> + return PTR_ERR(plat_dat);
> +
> + gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
> + if (!gmac)
> + return -ENOMEM;
> +
> + gmac->variant = of_device_get_match_data(&pdev->dev);
> + if (!gmac->variant) {
> + dev_err(&pdev->dev, "Missing dwmac-sun8i variant\n");
> + return -EINVAL;
> + }
> +
> + gmac->tx_clk = devm_clk_get(dev, "stmmaceth");
> + if (IS_ERR(gmac->tx_clk)) {
> + dev_err(dev, "Could not get TX clock\n");
> + return PTR_ERR(gmac->tx_clk);
> + }
> +
> + /* Optional regulator for PHY */
> + gmac->regulator = devm_regulator_get_optional(dev, "phy");
> + if (IS_ERR(gmac->regulator)) {
> + if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_info(dev, "No regulator found\n");
> + gmac->regulator = NULL;
> + }
> +
> + gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> + "syscon");
> + if (IS_ERR(gmac->regmap)) {
> + ret = PTR_ERR(gmac->regmap);
> + dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
> + return ret;
> + }
> +
> + plat_dat->interface = of_get_phy_mode(dev->of_node);
> + if (plat_dat->interface == gmac->variant->internal_phy) {
> + dev_info(&pdev->dev, "Will use internal PHY\n");
So here you seem to deduce the usage of the internal PHY by the PHY
interface specified in the DT (MII = internal, RGMII = external).
I think I raised this question before, but isn't it perfectly legal for
a board to use MII with an external PHY even on those SoCs that feature
an internal PHY?
On the first glance that does not make too much sense, but apart from
not being the correct binding to describe all of the SoCs features I see
two scenarios:
1) A board vendor might choose to not use the internal PHY because it
has bugs, lacks features (configurability) or has other issues. For
instance I have heard reports that the internal PHY makes the SoC go
rather hot, possibly limiting the CPU frequency. By using an external
MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
2) A PHY does not necessarily need to be directly connected to
magnetics. Indeed quite some boards use (RG)MII to connect to a switch
IC or some other network circuitry, for instance fibre connectors.
So I was wondering if we would need an explicit:
allwinner,use-internal-phy;
boolean DT property to signal the usage of the internal PHY?
Alternatively we could go with the negative version:
allwinner,disable-internal-phy;
Or what about introducing a new "allwinner,internal-mii-phy" compatible
string for the *PHY* node and use that?
I just want to avoid that we introduce a binding that causes us
headaches later. I think we can still fix this with a followup patch
before the driver and its binding hit a release kernel.
Cheers,
Andre.
> + gmac->use_internal_phy = true;
> + gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
> + if (IS_ERR(gmac->ephy_clk)) {
> + ret = PTR_ERR(gmac->ephy_clk);
> + dev_err(&pdev->dev, "Cannot get EPHY clock: %d\n", ret);
> + return -EINVAL;
> + }
> +
> + gmac->rst_ephy = of_reset_control_get(plat_dat->phy_node, NULL);
> + if (IS_ERR(gmac->rst_ephy)) {
> + ret = PTR_ERR(gmac->rst_ephy);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + dev_err(&pdev->dev, "No EPHY reset control found %d\n",
> + ret);
> + return -EINVAL;
> + }
> + } else {
> + dev_info(&pdev->dev, "Will use external PHY\n");
> + gmac->use_internal_phy = false;
> + }
> +
> + /* platform data specifying hardware features and callbacks.
> + * hardware features were copied from Allwinner drivers.
> + */
> + plat_dat->rx_coe = STMMAC_RX_COE_TYPE2;
> + plat_dat->tx_coe = 1;
> + plat_dat->has_sun8i = true;
> + plat_dat->bsp_priv = gmac;
> + plat_dat->init = sun8i_dwmac_init;
> + plat_dat->exit = sun8i_dwmac_exit;
> + plat_dat->setup = sun8i_dwmac_setup;
> +
> + ret = sun8i_dwmac_init(pdev, plat_dat->bsp_priv);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
> + if (ret)
> + sun8i_dwmac_exit(pdev, plat_dat->bsp_priv);
> +
> + return ret;
> +}
> +
> +static const struct of_device_id sun8i_dwmac_match[] = {
> + { .compatible = "allwinner,sun8i-h3-emac",
> + .data = &emac_variant_h3 },
> + { .compatible = "allwinner,sun8i-a83t-emac",
> + .data = &emac_variant_a83t },
> + { .compatible = "allwinner,sun50i-a64-emac",
> + .data = &emac_variant_a64 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
> +
> +static struct platform_driver sun8i_dwmac_driver = {
> + .probe = sun8i_dwmac_probe,
> + .remove = stmmac_pltfr_remove,
> + .driver = {
> + .name = "dwmac-sun8i",
> + .pm = &stmmac_pltfr_pm_ops,
> + .of_match_table = sun8i_dwmac_match,
> + },
> +};
> +module_platform_driver(sun8i_dwmac_driver);
> +
> +MODULE_AUTHOR("Corentin Labbe <clabbe.montjoie@gmail.com>");
> +MODULE_DESCRIPTION("Allwinner sun8i DWMAC specific glue layer");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index c80c9c3b67db..68a188e74c54 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -235,6 +235,17 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
> else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
> priv->clk_csr = STMMAC_CSR_250_300M;
> }
> +
> + if (priv->plat->has_sun8i) {
> + if (clk_rate > 160000000)
> + priv->clk_csr = 0x03;
> + else if (clk_rate > 80000000)
> + priv->clk_csr = 0x02;
> + else if (clk_rate > 40000000)
> + priv->clk_csr = 0x01;
> + else
> + priv->clk_csr = 0;
> + }
> }
>
> static void print_pkt(unsigned char *buf, int len)
> @@ -3955,6 +3966,10 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
>
> priv->hw = mac;
>
> + /* dwmac-sun8i only work in chain mode */
> + if (priv->plat->has_sun8i)
> + chain_mode = 1;
> +
> /* To use the chained or ring mode */
> if (priv->synopsys_id >= DWMAC_CORE_4_00) {
> priv->hw->mode = &dwmac4_ring_mode_ops;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 7fc3a1ef395a..3840529344ed 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -309,6 +309,12 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> struct device_node *np, struct device *dev)
> {
> bool mdio = true;
> + static const struct of_device_id need_mdio_ids[] = {
> + { .compatible = "snps,dwc-qos-ethernet-4.10" },
> + { .compatible = "allwinner,sun8i-a83t-emac" },
> + { .compatible = "allwinner,sun8i-h3-emac" },
> + { .compatible = "allwinner,sun50i-a64-emac" },
> + };
>
> /* If phy-handle property is passed from DT, use it as the PHY */
> plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
> @@ -325,8 +331,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> mdio = false;
> }
>
> - /* exception for dwmac-dwc-qos-eth glue logic */
> - if (of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
> + if (of_match_node(need_mdio_ids, np)) {
> plat->mdio_node = of_get_child_by_name(np, "mdio");
> } else {
> /**
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 8bb550bca96d..108739ff9223 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -186,6 +186,7 @@ struct plat_stmmacenet_data {
> struct reset_control *stmmac_rst;
> struct stmmac_axi *axi;
> int has_gmac4;
> + bool has_sun8i;
> bool tso_en;
> int mac_port_sel_speed;
> bool en_tx_lpi_clockgating;
>
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-26 0:18 ` André Przywara
0 siblings, 0 replies; 148+ messages in thread
From: André Przywara @ 2017-06-26 0:18 UTC (permalink / raw)
To: Corentin Labbe, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
On 31/05/17 08:18, Corentin Labbe wrote:
> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> allwinner.
> In fact the only common part is the descriptor management and the first
> register function.
Hi,
I know I am a bit late with this, but while adapting the U-Boot driver
to the new binding I was wondering about the internal PHY detection:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> new file mode 100644
> index 000000000000..1a6bfe6c958f
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -0,0 +1,990 @@
....
> +static int sun8i_dwmac_probe(struct platform_device *pdev)
> +{
> + struct plat_stmmacenet_data *plat_dat;
> + struct stmmac_resources stmmac_res;
> + struct sunxi_priv_data *gmac;
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> + if (ret)
> + return ret;
> +
> + plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> + if (IS_ERR(plat_dat))
> + return PTR_ERR(plat_dat);
> +
> + gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
> + if (!gmac)
> + return -ENOMEM;
> +
> + gmac->variant = of_device_get_match_data(&pdev->dev);
> + if (!gmac->variant) {
> + dev_err(&pdev->dev, "Missing dwmac-sun8i variant\n");
> + return -EINVAL;
> + }
> +
> + gmac->tx_clk = devm_clk_get(dev, "stmmaceth");
> + if (IS_ERR(gmac->tx_clk)) {
> + dev_err(dev, "Could not get TX clock\n");
> + return PTR_ERR(gmac->tx_clk);
> + }
> +
> + /* Optional regulator for PHY */
> + gmac->regulator = devm_regulator_get_optional(dev, "phy");
> + if (IS_ERR(gmac->regulator)) {
> + if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_info(dev, "No regulator found\n");
> + gmac->regulator = NULL;
> + }
> +
> + gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> + "syscon");
> + if (IS_ERR(gmac->regmap)) {
> + ret = PTR_ERR(gmac->regmap);
> + dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
> + return ret;
> + }
> +
> + plat_dat->interface = of_get_phy_mode(dev->of_node);
> + if (plat_dat->interface == gmac->variant->internal_phy) {
> + dev_info(&pdev->dev, "Will use internal PHY\n");
So here you seem to deduce the usage of the internal PHY by the PHY
interface specified in the DT (MII = internal, RGMII = external).
I think I raised this question before, but isn't it perfectly legal for
a board to use MII with an external PHY even on those SoCs that feature
an internal PHY?
On the first glance that does not make too much sense, but apart from
not being the correct binding to describe all of the SoCs features I see
two scenarios:
1) A board vendor might choose to not use the internal PHY because it
has bugs, lacks features (configurability) or has other issues. For
instance I have heard reports that the internal PHY makes the SoC go
rather hot, possibly limiting the CPU frequency. By using an external
MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
2) A PHY does not necessarily need to be directly connected to
magnetics. Indeed quite some boards use (RG)MII to connect to a switch
IC or some other network circuitry, for instance fibre connectors.
So I was wondering if we would need an explicit:
allwinner,use-internal-phy;
boolean DT property to signal the usage of the internal PHY?
Alternatively we could go with the negative version:
allwinner,disable-internal-phy;
Or what about introducing a new "allwinner,internal-mii-phy" compatible
string for the *PHY* node and use that?
I just want to avoid that we introduce a binding that causes us
headaches later. I think we can still fix this with a followup patch
before the driver and its binding hit a release kernel.
Cheers,
Andre.
> + gmac->use_internal_phy = true;
> + gmac->ephy_clk = of_clk_get(plat_dat->phy_node, 0);
> + if (IS_ERR(gmac->ephy_clk)) {
> + ret = PTR_ERR(gmac->ephy_clk);
> + dev_err(&pdev->dev, "Cannot get EPHY clock: %d\n", ret);
> + return -EINVAL;
> + }
> +
> + gmac->rst_ephy = of_reset_control_get(plat_dat->phy_node, NULL);
> + if (IS_ERR(gmac->rst_ephy)) {
> + ret = PTR_ERR(gmac->rst_ephy);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + dev_err(&pdev->dev, "No EPHY reset control found %d\n",
> + ret);
> + return -EINVAL;
> + }
> + } else {
> + dev_info(&pdev->dev, "Will use external PHY\n");
> + gmac->use_internal_phy = false;
> + }
> +
> + /* platform data specifying hardware features and callbacks.
> + * hardware features were copied from Allwinner drivers.
> + */
> + plat_dat->rx_coe = STMMAC_RX_COE_TYPE2;
> + plat_dat->tx_coe = 1;
> + plat_dat->has_sun8i = true;
> + plat_dat->bsp_priv = gmac;
> + plat_dat->init = sun8i_dwmac_init;
> + plat_dat->exit = sun8i_dwmac_exit;
> + plat_dat->setup = sun8i_dwmac_setup;
> +
> + ret = sun8i_dwmac_init(pdev, plat_dat->bsp_priv);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
> + if (ret)
> + sun8i_dwmac_exit(pdev, plat_dat->bsp_priv);
> +
> + return ret;
> +}
> +
> +static const struct of_device_id sun8i_dwmac_match[] = {
> + { .compatible = "allwinner,sun8i-h3-emac",
> + .data = &emac_variant_h3 },
> + { .compatible = "allwinner,sun8i-a83t-emac",
> + .data = &emac_variant_a83t },
> + { .compatible = "allwinner,sun50i-a64-emac",
> + .data = &emac_variant_a64 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
> +
> +static struct platform_driver sun8i_dwmac_driver = {
> + .probe = sun8i_dwmac_probe,
> + .remove = stmmac_pltfr_remove,
> + .driver = {
> + .name = "dwmac-sun8i",
> + .pm = &stmmac_pltfr_pm_ops,
> + .of_match_table = sun8i_dwmac_match,
> + },
> +};
> +module_platform_driver(sun8i_dwmac_driver);
> +
> +MODULE_AUTHOR("Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
> +MODULE_DESCRIPTION("Allwinner sun8i DWMAC specific glue layer");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index c80c9c3b67db..68a188e74c54 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -235,6 +235,17 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
> else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
> priv->clk_csr = STMMAC_CSR_250_300M;
> }
> +
> + if (priv->plat->has_sun8i) {
> + if (clk_rate > 160000000)
> + priv->clk_csr = 0x03;
> + else if (clk_rate > 80000000)
> + priv->clk_csr = 0x02;
> + else if (clk_rate > 40000000)
> + priv->clk_csr = 0x01;
> + else
> + priv->clk_csr = 0;
> + }
> }
>
> static void print_pkt(unsigned char *buf, int len)
> @@ -3955,6 +3966,10 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
>
> priv->hw = mac;
>
> + /* dwmac-sun8i only work in chain mode */
> + if (priv->plat->has_sun8i)
> + chain_mode = 1;
> +
> /* To use the chained or ring mode */
> if (priv->synopsys_id >= DWMAC_CORE_4_00) {
> priv->hw->mode = &dwmac4_ring_mode_ops;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 7fc3a1ef395a..3840529344ed 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -309,6 +309,12 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> struct device_node *np, struct device *dev)
> {
> bool mdio = true;
> + static const struct of_device_id need_mdio_ids[] = {
> + { .compatible = "snps,dwc-qos-ethernet-4.10" },
> + { .compatible = "allwinner,sun8i-a83t-emac" },
> + { .compatible = "allwinner,sun8i-h3-emac" },
> + { .compatible = "allwinner,sun50i-a64-emac" },
> + };
>
> /* If phy-handle property is passed from DT, use it as the PHY */
> plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
> @@ -325,8 +331,7 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
> mdio = false;
> }
>
> - /* exception for dwmac-dwc-qos-eth glue logic */
> - if (of_device_is_compatible(np, "snps,dwc-qos-ethernet-4.10")) {
> + if (of_match_node(need_mdio_ids, np)) {
> plat->mdio_node = of_get_child_by_name(np, "mdio");
> } else {
> /**
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 8bb550bca96d..108739ff9223 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -186,6 +186,7 @@ struct plat_stmmacenet_data {
> struct reset_control *stmmac_rst;
> struct stmmac_axi *axi;
> int has_gmac4;
> + bool has_sun8i;
> bool tso_en;
> int mac_port_sel_speed;
> bool en_tx_lpi_clockgating;
>
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 8:05 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 8:05 UTC (permalink / raw)
To: André Przywara
Cc: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
devicetree, netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
Icenowy Zheng
On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> On 31/05/17 08:18, Corentin Labbe wrote:
> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > allwinner.
> > In fact the only common part is the descriptor management and the first
> > register function.
>
> Hi,
>
> I know I am a bit late with this, but while adapting the U-Boot driver
> to the new binding I was wondering about the internal PHY detection:
>
>
> So here you seem to deduce the usage of the internal PHY by the PHY
> interface specified in the DT (MII = internal, RGMII = external).
> I think I raised this question before, but isn't it perfectly legal for
> a board to use MII with an external PHY even on those SoCs that feature
> an internal PHY?
> On the first glance that does not make too much sense, but apart from
> not being the correct binding to describe all of the SoCs features I see
> two scenarios:
> 1) A board vendor might choose to not use the internal PHY because it
> has bugs, lacks features (configurability) or has other issues. For
> instance I have heard reports that the internal PHY makes the SoC go
> rather hot, possibly limiting the CPU frequency. By using an external
> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> 2) A PHY does not necessarily need to be directly connected to
> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> IC or some other network circuitry, for instance fibre connectors.
>
> So I was wondering if we would need an explicit:
> allwinner,use-internal-phy;
> boolean DT property to signal the usage of the internal PHY?
> Alternatively we could go with the negative version:
> allwinner,disable-internal-phy;
>
> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> string for the *PHY* node and use that?
>
> I just want to avoid that we introduce a binding that causes us
> headaches later. I think we can still fix this with a followup patch
> before the driver and its binding hit a release kernel.
>
> Cheers,
> Andre.
>
I just see some patch, where "phy-mode = internal" is valid.
I will try to find a way to use it
Regards
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 8:05 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 8:05 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> On 31/05/17 08:18, Corentin Labbe wrote:
> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > allwinner.
> > In fact the only common part is the descriptor management and the first
> > register function.
>
> Hi,
>
> I know I am a bit late with this, but while adapting the U-Boot driver
> to the new binding I was wondering about the internal PHY detection:
>
>
> So here you seem to deduce the usage of the internal PHY by the PHY
> interface specified in the DT (MII = internal, RGMII = external).
> I think I raised this question before, but isn't it perfectly legal for
> a board to use MII with an external PHY even on those SoCs that feature
> an internal PHY?
> On the first glance that does not make too much sense, but apart from
> not being the correct binding to describe all of the SoCs features I see
> two scenarios:
> 1) A board vendor might choose to not use the internal PHY because it
> has bugs, lacks features (configurability) or has other issues. For
> instance I have heard reports that the internal PHY makes the SoC go
> rather hot, possibly limiting the CPU frequency. By using an external
> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> 2) A PHY does not necessarily need to be directly connected to
> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> IC or some other network circuitry, for instance fibre connectors.
>
> So I was wondering if we would need an explicit:
> allwinner,use-internal-phy;
> boolean DT property to signal the usage of the internal PHY?
> Alternatively we could go with the negative version:
> allwinner,disable-internal-phy;
>
> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> string for the *PHY* node and use that?
>
> I just want to avoid that we introduce a binding that causes us
> headaches later. I think we can still fix this with a followup patch
> before the driver and its binding hit a release kernel.
>
> Cheers,
> Andre.
>
I just see some patch, where "phy-mode = internal" is valid.
I will try to find a way to use it
Regards
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 8:05 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 8:05 UTC (permalink / raw)
To: André Przywara
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> On 31/05/17 08:18, Corentin Labbe wrote:
> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > allwinner.
> > In fact the only common part is the descriptor management and the first
> > register function.
>
> Hi,
>
> I know I am a bit late with this, but while adapting the U-Boot driver
> to the new binding I was wondering about the internal PHY detection:
>
>
> So here you seem to deduce the usage of the internal PHY by the PHY
> interface specified in the DT (MII = internal, RGMII = external).
> I think I raised this question before, but isn't it perfectly legal for
> a board to use MII with an external PHY even on those SoCs that feature
> an internal PHY?
> On the first glance that does not make too much sense, but apart from
> not being the correct binding to describe all of the SoCs features I see
> two scenarios:
> 1) A board vendor might choose to not use the internal PHY because it
> has bugs, lacks features (configurability) or has other issues. For
> instance I have heard reports that the internal PHY makes the SoC go
> rather hot, possibly limiting the CPU frequency. By using an external
> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> 2) A PHY does not necessarily need to be directly connected to
> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> IC or some other network circuitry, for instance fibre connectors.
>
> So I was wondering if we would need an explicit:
> allwinner,use-internal-phy;
> boolean DT property to signal the usage of the internal PHY?
> Alternatively we could go with the negative version:
> allwinner,disable-internal-phy;
>
> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> string for the *PHY* node and use that?
>
> I just want to avoid that we introduce a binding that causes us
> headaches later. I think we can still fix this with a followup patch
> before the driver and its binding hit a release kernel.
>
> Cheers,
> Andre.
>
I just see some patch, where "phy-mode = internal" is valid.
I will try to find a way to use it
Regards
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-06-27 8:05 ` Corentin Labbe
(?)
@ 2017-06-27 8:11 ` Chen-Yu Tsai
-1 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 8:11 UTC (permalink / raw)
To: Corentin Labbe
Cc: André Przywara, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, netdev,
linux-kernel, linux-sunxi, linux-arm-kernel, Icenowy Zheng
On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>> On 31/05/17 08:18, Corentin Labbe wrote:
>> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>> > allwinner.
>> > In fact the only common part is the descriptor management and the first
>> > register function.
>>
>> Hi,
>>
>> I know I am a bit late with this, but while adapting the U-Boot driver
>> to the new binding I was wondering about the internal PHY detection:
>>
>>
>> So here you seem to deduce the usage of the internal PHY by the PHY
>> interface specified in the DT (MII = internal, RGMII = external).
>> I think I raised this question before, but isn't it perfectly legal for
>> a board to use MII with an external PHY even on those SoCs that feature
>> an internal PHY?
>> On the first glance that does not make too much sense, but apart from
>> not being the correct binding to describe all of the SoCs features I see
>> two scenarios:
>> 1) A board vendor might choose to not use the internal PHY because it
>> has bugs, lacks features (configurability) or has other issues. For
>> instance I have heard reports that the internal PHY makes the SoC go
>> rather hot, possibly limiting the CPU frequency. By using an external
>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>> 2) A PHY does not necessarily need to be directly connected to
>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>> IC or some other network circuitry, for instance fibre connectors.
>>
>> So I was wondering if we would need an explicit:
>> allwinner,use-internal-phy;
>> boolean DT property to signal the usage of the internal PHY?
>> Alternatively we could go with the negative version:
>> allwinner,disable-internal-phy;
>>
>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>> string for the *PHY* node and use that?
>>
>> I just want to avoid that we introduce a binding that causes us
>> headaches later. I think we can still fix this with a followup patch
>> before the driver and its binding hit a release kernel.
>>
>> Cheers,
>> Andre.
>>
>
> I just see some patch, where "phy-mode = internal" is valid.
> I will try to find a way to use it
Can you provide a link?
I'm not a fan of using phy-mode for this. There's no guarantee what
mode the internal PHY uses. That's what phy-mode is for.
In any case, we should fix this before 4.13 is released.
ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 8:11 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 8:11 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
<clabbe.montjoie@gmail.com> wrote:
> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>> On 31/05/17 08:18, Corentin Labbe wrote:
>> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>> > allwinner.
>> > In fact the only common part is the descriptor management and the first
>> > register function.
>>
>> Hi,
>>
>> I know I am a bit late with this, but while adapting the U-Boot driver
>> to the new binding I was wondering about the internal PHY detection:
>>
>>
>> So here you seem to deduce the usage of the internal PHY by the PHY
>> interface specified in the DT (MII = internal, RGMII = external).
>> I think I raised this question before, but isn't it perfectly legal for
>> a board to use MII with an external PHY even on those SoCs that feature
>> an internal PHY?
>> On the first glance that does not make too much sense, but apart from
>> not being the correct binding to describe all of the SoCs features I see
>> two scenarios:
>> 1) A board vendor might choose to not use the internal PHY because it
>> has bugs, lacks features (configurability) or has other issues. For
>> instance I have heard reports that the internal PHY makes the SoC go
>> rather hot, possibly limiting the CPU frequency. By using an external
>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>> 2) A PHY does not necessarily need to be directly connected to
>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>> IC or some other network circuitry, for instance fibre connectors.
>>
>> So I was wondering if we would need an explicit:
>> allwinner,use-internal-phy;
>> boolean DT property to signal the usage of the internal PHY?
>> Alternatively we could go with the negative version:
>> allwinner,disable-internal-phy;
>>
>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>> string for the *PHY* node and use that?
>>
>> I just want to avoid that we introduce a binding that causes us
>> headaches later. I think we can still fix this with a followup patch
>> before the driver and its binding hit a release kernel.
>>
>> Cheers,
>> Andre.
>>
>
> I just see some patch, where "phy-mode = internal" is valid.
> I will try to find a way to use it
Can you provide a link?
I'm not a fan of using phy-mode for this. There's no guarantee what
mode the internal PHY uses. That's what phy-mode is for.
In any case, we should fix this before 4.13 is released.
ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 8:11 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 8:11 UTC (permalink / raw)
To: Corentin Labbe
Cc: André Przywara, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
Icenowy Zheng
On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
<clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>> On 31/05/17 08:18, Corentin Labbe wrote:
>> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>> > allwinner.
>> > In fact the only common part is the descriptor management and the first
>> > register function.
>>
>> Hi,
>>
>> I know I am a bit late with this, but while adapting the U-Boot driver
>> to the new binding I was wondering about the internal PHY detection:
>>
>>
>> So here you seem to deduce the usage of the internal PHY by the PHY
>> interface specified in the DT (MII = internal, RGMII = external).
>> I think I raised this question before, but isn't it perfectly legal for
>> a board to use MII with an external PHY even on those SoCs that feature
>> an internal PHY?
>> On the first glance that does not make too much sense, but apart from
>> not being the correct binding to describe all of the SoCs features I see
>> two scenarios:
>> 1) A board vendor might choose to not use the internal PHY because it
>> has bugs, lacks features (configurability) or has other issues. For
>> instance I have heard reports that the internal PHY makes the SoC go
>> rather hot, possibly limiting the CPU frequency. By using an external
>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>> 2) A PHY does not necessarily need to be directly connected to
>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>> IC or some other network circuitry, for instance fibre connectors.
>>
>> So I was wondering if we would need an explicit:
>> allwinner,use-internal-phy;
>> boolean DT property to signal the usage of the internal PHY?
>> Alternatively we could go with the negative version:
>> allwinner,disable-internal-phy;
>>
>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>> string for the *PHY* node and use that?
>>
>> I just want to avoid that we introduce a binding that causes us
>> headaches later. I think we can still fix this with a followup patch
>> before the driver and its binding hit a release kernel.
>>
>> Cheers,
>> Andre.
>>
>
> I just see some patch, where "phy-mode = internal" is valid.
> I will try to find a way to use it
Can you provide a link?
I'm not a fan of using phy-mode for this. There's no guarantee what
mode the internal PHY uses. That's what phy-mode is for.
In any case, we should fix this before 4.13 is released.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 8:21 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 8:21 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: André Przywara, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, netdev, linux-kernel, linux-sunxi,
linux-arm-kernel, Icenowy Zheng
On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> <clabbe.montjoie@gmail.com> wrote:
> > On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >> On 31/05/17 08:18, Corentin Labbe wrote:
> >> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >> > allwinner.
> >> > In fact the only common part is the descriptor management and the first
> >> > register function.
> >>
> >> Hi,
> >>
> >> I know I am a bit late with this, but while adapting the U-Boot driver
> >> to the new binding I was wondering about the internal PHY detection:
> >>
> >>
> >> So here you seem to deduce the usage of the internal PHY by the PHY
> >> interface specified in the DT (MII = internal, RGMII = external).
> >> I think I raised this question before, but isn't it perfectly legal for
> >> a board to use MII with an external PHY even on those SoCs that feature
> >> an internal PHY?
> >> On the first glance that does not make too much sense, but apart from
> >> not being the correct binding to describe all of the SoCs features I see
> >> two scenarios:
> >> 1) A board vendor might choose to not use the internal PHY because it
> >> has bugs, lacks features (configurability) or has other issues. For
> >> instance I have heard reports that the internal PHY makes the SoC go
> >> rather hot, possibly limiting the CPU frequency. By using an external
> >> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> >> 2) A PHY does not necessarily need to be directly connected to
> >> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> >> IC or some other network circuitry, for instance fibre connectors.
> >>
> >> So I was wondering if we would need an explicit:
> >> allwinner,use-internal-phy;
> >> boolean DT property to signal the usage of the internal PHY?
> >> Alternatively we could go with the negative version:
> >> allwinner,disable-internal-phy;
> >>
> >> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> >> string for the *PHY* node and use that?
> >>
> >> I just want to avoid that we introduce a binding that causes us
> >> headaches later. I think we can still fix this with a followup patch
> >> before the driver and its binding hit a release kernel.
> >>
> >> Cheers,
> >> Andre.
> >>
> >
> > I just see some patch, where "phy-mode = internal" is valid.
> > I will try to find a way to use it
>
> Can you provide a link?
https://lkml.org/lkml/2017/6/23/479
>
> I'm not a fan of using phy-mode for this. There's no guarantee what
> mode the internal PHY uses. That's what phy-mode is for.
For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
So its not a problem.
Patch comming soon
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 8:21 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 8:21 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> <clabbe.montjoie@gmail.com> wrote:
> > On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> >> On 31/05/17 08:18, Corentin Labbe wrote:
> >> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >> > allwinner.
> >> > In fact the only common part is the descriptor management and the first
> >> > register function.
> >>
> >> Hi,
> >>
> >> I know I am a bit late with this, but while adapting the U-Boot driver
> >> to the new binding I was wondering about the internal PHY detection:
> >>
> >>
> >> So here you seem to deduce the usage of the internal PHY by the PHY
> >> interface specified in the DT (MII = internal, RGMII = external).
> >> I think I raised this question before, but isn't it perfectly legal for
> >> a board to use MII with an external PHY even on those SoCs that feature
> >> an internal PHY?
> >> On the first glance that does not make too much sense, but apart from
> >> not being the correct binding to describe all of the SoCs features I see
> >> two scenarios:
> >> 1) A board vendor might choose to not use the internal PHY because it
> >> has bugs, lacks features (configurability) or has other issues. For
> >> instance I have heard reports that the internal PHY makes the SoC go
> >> rather hot, possibly limiting the CPU frequency. By using an external
> >> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> >> 2) A PHY does not necessarily need to be directly connected to
> >> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> >> IC or some other network circuitry, for instance fibre connectors.
> >>
> >> So I was wondering if we would need an explicit:
> >> allwinner,use-internal-phy;
> >> boolean DT property to signal the usage of the internal PHY?
> >> Alternatively we could go with the negative version:
> >> allwinner,disable-internal-phy;
> >>
> >> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> >> string for the *PHY* node and use that?
> >>
> >> I just want to avoid that we introduce a binding that causes us
> >> headaches later. I think we can still fix this with a followup patch
> >> before the driver and its binding hit a release kernel.
> >>
> >> Cheers,
> >> Andre.
> >>
> >
> > I just see some patch, where "phy-mode = internal" is valid.
> > I will try to find a way to use it
>
> Can you provide a link?
https://lkml.org/lkml/2017/6/23/479
>
> I'm not a fan of using phy-mode for this. There's no guarantee what
> mode the internal PHY uses. That's what phy-mode is for.
For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
So its not a problem.
Patch comming soon
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 8:21 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 8:21 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: André Przywara, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, netdev, linux-kernel,
linux-sunxi, linux-arm-kernel, Icenowy Zheng
On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >> On 31/05/17 08:18, Corentin Labbe wrote:
> >> > The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >> > allwinner.
> >> > In fact the only common part is the descriptor management and the first
> >> > register function.
> >>
> >> Hi,
> >>
> >> I know I am a bit late with this, but while adapting the U-Boot driver
> >> to the new binding I was wondering about the internal PHY detection:
> >>
> >>
> >> So here you seem to deduce the usage of the internal PHY by the PHY
> >> interface specified in the DT (MII = internal, RGMII = external).
> >> I think I raised this question before, but isn't it perfectly legal for
> >> a board to use MII with an external PHY even on those SoCs that feature
> >> an internal PHY?
> >> On the first glance that does not make too much sense, but apart from
> >> not being the correct binding to describe all of the SoCs features I see
> >> two scenarios:
> >> 1) A board vendor might choose to not use the internal PHY because it
> >> has bugs, lacks features (configurability) or has other issues. For
> >> instance I have heard reports that the internal PHY makes the SoC go
> >> rather hot, possibly limiting the CPU frequency. By using an external
> >> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> >> 2) A PHY does not necessarily need to be directly connected to
> >> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> >> IC or some other network circuitry, for instance fibre connectors.
> >>
> >> So I was wondering if we would need an explicit:
> >> allwinner,use-internal-phy;
> >> boolean DT property to signal the usage of the internal PHY?
> >> Alternatively we could go with the negative version:
> >> allwinner,disable-internal-phy;
> >>
> >> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> >> string for the *PHY* node and use that?
> >>
> >> I just want to avoid that we introduce a binding that causes us
> >> headaches later. I think we can still fix this with a followup patch
> >> before the driver and its binding hit a release kernel.
> >>
> >> Cheers,
> >> Andre.
> >>
> >
> > I just see some patch, where "phy-mode = internal" is valid.
> > I will try to find a way to use it
>
> Can you provide a link?
https://lkml.org/lkml/2017/6/23/479
>
> I'm not a fan of using phy-mode for this. There's no guarantee what
> mode the internal PHY uses. That's what phy-mode is for.
For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
So its not a problem.
Patch comming soon
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-06-27 8:21 ` Corentin Labbe
(?)
@ 2017-06-27 9:02 ` Andre Przywara
-1 siblings, 0 replies; 148+ messages in thread
From: Andre Przywara @ 2017-06-27 9:02 UTC (permalink / raw)
To: Corentin Labbe, Chen-Yu Tsai
Cc: Rob Herring, Mark Rutland, Maxime Ripard, Russell King,
Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, netdev, linux-kernel, linux-sunxi,
linux-arm-kernel, Icenowy Zheng, david.wu, Florian Fainelli,
Andrew Lunn, Heiko Stübner
Hi,
(CC:ing some people from that Rockchip dmwac series)
On 27/06/17 09:21, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>> <clabbe.montjoie@gmail.com> wrote:
>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>> allwinner.
>>>>> In fact the only common part is the descriptor management and the first
>>>>> register function.
>>>>
>>>> Hi,
>>>>
>>>> I know I am a bit late with this, but while adapting the U-Boot driver
>>>> to the new binding I was wondering about the internal PHY detection:
>>>>
>>>>
>>>> So here you seem to deduce the usage of the internal PHY by the PHY
>>>> interface specified in the DT (MII = internal, RGMII = external).
>>>> I think I raised this question before, but isn't it perfectly legal for
>>>> a board to use MII with an external PHY even on those SoCs that feature
>>>> an internal PHY?
>>>> On the first glance that does not make too much sense, but apart from
>>>> not being the correct binding to describe all of the SoCs features I see
>>>> two scenarios:
>>>> 1) A board vendor might choose to not use the internal PHY because it
>>>> has bugs, lacks features (configurability) or has other issues. For
>>>> instance I have heard reports that the internal PHY makes the SoC go
>>>> rather hot, possibly limiting the CPU frequency. By using an external
>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>>>> 2) A PHY does not necessarily need to be directly connected to
>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>>>> IC or some other network circuitry, for instance fibre connectors.
>>>>
>>>> So I was wondering if we would need an explicit:
>>>> allwinner,use-internal-phy;
>>>> boolean DT property to signal the usage of the internal PHY?
>>>> Alternatively we could go with the negative version:
>>>> allwinner,disable-internal-phy;
>>>>
>>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>>>> string for the *PHY* node and use that?
>>>>
>>>> I just want to avoid that we introduce a binding that causes us
>>>> headaches later. I think we can still fix this with a followup patch
>>>> before the driver and its binding hit a release kernel.
>>>>
>>>> Cheers,
>>>> Andre.
>>>>
>>>
>>> I just see some patch, where "phy-mode = internal" is valid.
>>> I will try to find a way to use it
>>
>> Can you provide a link?
>
> https://lkml.org/lkml/2017/6/23/479
>
>>
>> I'm not a fan of using phy-mode for this. There's no guarantee what
>> mode the internal PHY uses. That's what phy-mode is for.
I can understand Chen-Yu's concerns, but ...
> For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
> So its not a problem.
that is true as well, at least for now.
So while I agree that having a separate property to indicate the usage
of the internal PHY would be nice, I am bit tempted to use this easier
approach and piggy back on the existing phy-mode property.
Are there any insights from the people involved with the Rockchip
internal PHY?
It is worth to introduce a generic boolean property for an internal PHY?
Or shall we actually move this more into the PHY code, introducing new
compatibles for the internal Allwinner and Rockchip Ethernet PHYs?
Cheers,
Andre.
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 9:02 ` Andre Przywara
0 siblings, 0 replies; 148+ messages in thread
From: Andre Przywara @ 2017-06-27 9:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
(CC:ing some people from that Rockchip dmwac series)
On 27/06/17 09:21, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>> <clabbe.montjoie@gmail.com> wrote:
>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>> allwinner.
>>>>> In fact the only common part is the descriptor management and the first
>>>>> register function.
>>>>
>>>> Hi,
>>>>
>>>> I know I am a bit late with this, but while adapting the U-Boot driver
>>>> to the new binding I was wondering about the internal PHY detection:
>>>>
>>>>
>>>> So here you seem to deduce the usage of the internal PHY by the PHY
>>>> interface specified in the DT (MII = internal, RGMII = external).
>>>> I think I raised this question before, but isn't it perfectly legal for
>>>> a board to use MII with an external PHY even on those SoCs that feature
>>>> an internal PHY?
>>>> On the first glance that does not make too much sense, but apart from
>>>> not being the correct binding to describe all of the SoCs features I see
>>>> two scenarios:
>>>> 1) A board vendor might choose to not use the internal PHY because it
>>>> has bugs, lacks features (configurability) or has other issues. For
>>>> instance I have heard reports that the internal PHY makes the SoC go
>>>> rather hot, possibly limiting the CPU frequency. By using an external
>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>>>> 2) A PHY does not necessarily need to be directly connected to
>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>>>> IC or some other network circuitry, for instance fibre connectors.
>>>>
>>>> So I was wondering if we would need an explicit:
>>>> allwinner,use-internal-phy;
>>>> boolean DT property to signal the usage of the internal PHY?
>>>> Alternatively we could go with the negative version:
>>>> allwinner,disable-internal-phy;
>>>>
>>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>>>> string for the *PHY* node and use that?
>>>>
>>>> I just want to avoid that we introduce a binding that causes us
>>>> headaches later. I think we can still fix this with a followup patch
>>>> before the driver and its binding hit a release kernel.
>>>>
>>>> Cheers,
>>>> Andre.
>>>>
>>>
>>> I just see some patch, where "phy-mode = internal" is valid.
>>> I will try to find a way to use it
>>
>> Can you provide a link?
>
> https://lkml.org/lkml/2017/6/23/479
>
>>
>> I'm not a fan of using phy-mode for this. There's no guarantee what
>> mode the internal PHY uses. That's what phy-mode is for.
I can understand Chen-Yu's concerns, but ...
> For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
> So its not a problem.
that is true as well, at least for now.
So while I agree that having a separate property to indicate the usage
of the internal PHY would be nice, I am bit tempted to use this easier
approach and piggy back on the existing phy-mode property.
Are there any insights from the people involved with the Rockchip
internal PHY?
It is worth to introduce a generic boolean property for an internal PHY?
Or shall we actually move this more into the PHY code, introducing new
compatibles for the internal Allwinner and Rockchip Ethernet PHYs?
Cheers,
Andre.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 9:02 ` Andre Przywara
0 siblings, 0 replies; 148+ messages in thread
From: Andre Przywara @ 2017-06-27 9:02 UTC (permalink / raw)
To: Corentin Labbe, Chen-Yu Tsai
Cc: Rob Herring, Mark Rutland, Maxime Ripard, Russell King,
Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, netdev, linux-kernel,
linux-sunxi, linux-arm-kernel, Icenowy Zheng,
david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli, Andrew Lunn,
Heiko Stübner
Hi,
(CC:ing some people from that Rockchip dmwac series)
On 27/06/17 09:21, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>> allwinner.
>>>>> In fact the only common part is the descriptor management and the first
>>>>> register function.
>>>>
>>>> Hi,
>>>>
>>>> I know I am a bit late with this, but while adapting the U-Boot driver
>>>> to the new binding I was wondering about the internal PHY detection:
>>>>
>>>>
>>>> So here you seem to deduce the usage of the internal PHY by the PHY
>>>> interface specified in the DT (MII = internal, RGMII = external).
>>>> I think I raised this question before, but isn't it perfectly legal for
>>>> a board to use MII with an external PHY even on those SoCs that feature
>>>> an internal PHY?
>>>> On the first glance that does not make too much sense, but apart from
>>>> not being the correct binding to describe all of the SoCs features I see
>>>> two scenarios:
>>>> 1) A board vendor might choose to not use the internal PHY because it
>>>> has bugs, lacks features (configurability) or has other issues. For
>>>> instance I have heard reports that the internal PHY makes the SoC go
>>>> rather hot, possibly limiting the CPU frequency. By using an external
>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>>>> 2) A PHY does not necessarily need to be directly connected to
>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>>>> IC or some other network circuitry, for instance fibre connectors.
>>>>
>>>> So I was wondering if we would need an explicit:
>>>> allwinner,use-internal-phy;
>>>> boolean DT property to signal the usage of the internal PHY?
>>>> Alternatively we could go with the negative version:
>>>> allwinner,disable-internal-phy;
>>>>
>>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>>>> string for the *PHY* node and use that?
>>>>
>>>> I just want to avoid that we introduce a binding that causes us
>>>> headaches later. I think we can still fix this with a followup patch
>>>> before the driver and its binding hit a release kernel.
>>>>
>>>> Cheers,
>>>> Andre.
>>>>
>>>
>>> I just see some patch, where "phy-mode = internal" is valid.
>>> I will try to find a way to use it
>>
>> Can you provide a link?
>
> https://lkml.org/lkml/2017/6/23/479
>
>>
>> I'm not a fan of using phy-mode for this. There's no guarantee what
>> mode the internal PHY uses. That's what phy-mode is for.
I can understand Chen-Yu's concerns, but ...
> For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
> So its not a problem.
that is true as well, at least for now.
So while I agree that having a separate property to indicate the usage
of the internal PHY would be nice, I am bit tempted to use this easier
approach and piggy back on the existing phy-mode property.
Are there any insights from the people involved with the Rockchip
internal PHY?
It is worth to introduce a generic boolean property for an internal PHY?
Or shall we actually move this more into the PHY code, introducing new
compatibles for the internal Allwinner and Rockchip Ethernet PHYs?
Cheers,
Andre.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 9:41 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 9:41 UTC (permalink / raw)
To: Andre Przywara
Cc: Corentin Labbe, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, netdev, linux-kernel, linux-sunxi,
linux-arm-kernel, Icenowy Zheng, david.wu, Florian Fainelli,
Andrew Lunn, Heiko Stübner
[-- Attachment #1: Type: text/plain, Size: 3907 bytes --]
On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> Hi,
>
> (CC:ing some people from that Rockchip dmwac series)
>
> On 27/06/17 09:21, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >> <clabbe.montjoie@gmail.com> wrote:
> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>> allwinner.
> >>>>> In fact the only common part is the descriptor management and the first
> >>>>> register function.
> >>>>
> >>>> Hi,
> >>>>
> >>>> I know I am a bit late with this, but while adapting the U-Boot driver
> >>>> to the new binding I was wondering about the internal PHY detection:
> >>>>
> >>>>
> >>>> So here you seem to deduce the usage of the internal PHY by the PHY
> >>>> interface specified in the DT (MII = internal, RGMII = external).
> >>>> I think I raised this question before, but isn't it perfectly legal for
> >>>> a board to use MII with an external PHY even on those SoCs that feature
> >>>> an internal PHY?
> >>>> On the first glance that does not make too much sense, but apart from
> >>>> not being the correct binding to describe all of the SoCs features I see
> >>>> two scenarios:
> >>>> 1) A board vendor might choose to not use the internal PHY because it
> >>>> has bugs, lacks features (configurability) or has other issues. For
> >>>> instance I have heard reports that the internal PHY makes the SoC go
> >>>> rather hot, possibly limiting the CPU frequency. By using an external
> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> >>>> 2) A PHY does not necessarily need to be directly connected to
> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> >>>> IC or some other network circuitry, for instance fibre connectors.
> >>>>
> >>>> So I was wondering if we would need an explicit:
> >>>> allwinner,use-internal-phy;
> >>>> boolean DT property to signal the usage of the internal PHY?
> >>>> Alternatively we could go with the negative version:
> >>>> allwinner,disable-internal-phy;
> >>>>
> >>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> >>>> string for the *PHY* node and use that?
> >>>>
> >>>> I just want to avoid that we introduce a binding that causes us
> >>>> headaches later. I think we can still fix this with a followup patch
> >>>> before the driver and its binding hit a release kernel.
> >>>>
> >>>> Cheers,
> >>>> Andre.
> >>>>
> >>>
> >>> I just see some patch, where "phy-mode = internal" is valid.
> >>> I will try to find a way to use it
> >>
> >> Can you provide a link?
> >
> > https://lkml.org/lkml/2017/6/23/479
> >
> >>
> >> I'm not a fan of using phy-mode for this. There's no guarantee what
> >> mode the internal PHY uses. That's what phy-mode is for.
>
> I can understand Chen-Yu's concerns, but ...
>
> > For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
> > So its not a problem.
>
> that is true as well, at least for now.
>
> So while I agree that having a separate property to indicate the usage
> of the internal PHY would be nice, I am bit tempted to use this easier
> approach and piggy back on the existing phy-mode property.
We're trying to fix an issue that works for now too.
If we want to consider future weird cases, then we must consider all
of them. And the phy mode changing is definitely not really far
fetched.
I agree with Chen-Yu, and I really feel like the compatible solution
you suggested would cover both your concerns, and ours.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 9:41 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 9:41 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> Hi,
>
> (CC:ing some people from that Rockchip dmwac series)
>
> On 27/06/17 09:21, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >> <clabbe.montjoie@gmail.com> wrote:
> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>> allwinner.
> >>>>> In fact the only common part is the descriptor management and the first
> >>>>> register function.
> >>>>
> >>>> Hi,
> >>>>
> >>>> I know I am a bit late with this, but while adapting the U-Boot driver
> >>>> to the new binding I was wondering about the internal PHY detection:
> >>>>
> >>>>
> >>>> So here you seem to deduce the usage of the internal PHY by the PHY
> >>>> interface specified in the DT (MII = internal, RGMII = external).
> >>>> I think I raised this question before, but isn't it perfectly legal for
> >>>> a board to use MII with an external PHY even on those SoCs that feature
> >>>> an internal PHY?
> >>>> On the first glance that does not make too much sense, but apart from
> >>>> not being the correct binding to describe all of the SoCs features I see
> >>>> two scenarios:
> >>>> 1) A board vendor might choose to not use the internal PHY because it
> >>>> has bugs, lacks features (configurability) or has other issues. For
> >>>> instance I have heard reports that the internal PHY makes the SoC go
> >>>> rather hot, possibly limiting the CPU frequency. By using an external
> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> >>>> 2) A PHY does not necessarily need to be directly connected to
> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> >>>> IC or some other network circuitry, for instance fibre connectors.
> >>>>
> >>>> So I was wondering if we would need an explicit:
> >>>> allwinner,use-internal-phy;
> >>>> boolean DT property to signal the usage of the internal PHY?
> >>>> Alternatively we could go with the negative version:
> >>>> allwinner,disable-internal-phy;
> >>>>
> >>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> >>>> string for the *PHY* node and use that?
> >>>>
> >>>> I just want to avoid that we introduce a binding that causes us
> >>>> headaches later. I think we can still fix this with a followup patch
> >>>> before the driver and its binding hit a release kernel.
> >>>>
> >>>> Cheers,
> >>>> Andre.
> >>>>
> >>>
> >>> I just see some patch, where "phy-mode = internal" is valid.
> >>> I will try to find a way to use it
> >>
> >> Can you provide a link?
> >
> > https://lkml.org/lkml/2017/6/23/479
> >
> >>
> >> I'm not a fan of using phy-mode for this. There's no guarantee what
> >> mode the internal PHY uses. That's what phy-mode is for.
>
> I can understand Chen-Yu's concerns, but ...
>
> > For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
> > So its not a problem.
>
> that is true as well, at least for now.
>
> So while I agree that having a separate property to indicate the usage
> of the internal PHY would be nice, I am bit tempted to use this easier
> approach and piggy back on the existing phy-mode property.
We're trying to fix an issue that works for now too.
If we want to consider future weird cases, then we must consider all
of them. And the phy mode changing is definitely not really far
fetched.
I agree with Chen-Yu, and I really feel like the compatible solution
you suggested would cover both your concerns, and ours.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170627/fa6875ab/attachment.sig>
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 9:41 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 9:41 UTC (permalink / raw)
To: Andre Przywara
Cc: Corentin Labbe, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, netdev, linux-kernel,
linux-sunxi, linux-arm-kernel, Icenowy Zheng,
david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli, Andrew Lunn,
Heiko Stübner
[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]
On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> Hi,
>
> (CC:ing some people from that Rockchip dmwac series)
>
> On 27/06/17 09:21, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>> allwinner.
> >>>>> In fact the only common part is the descriptor management and the first
> >>>>> register function.
> >>>>
> >>>> Hi,
> >>>>
> >>>> I know I am a bit late with this, but while adapting the U-Boot driver
> >>>> to the new binding I was wondering about the internal PHY detection:
> >>>>
> >>>>
> >>>> So here you seem to deduce the usage of the internal PHY by the PHY
> >>>> interface specified in the DT (MII = internal, RGMII = external).
> >>>> I think I raised this question before, but isn't it perfectly legal for
> >>>> a board to use MII with an external PHY even on those SoCs that feature
> >>>> an internal PHY?
> >>>> On the first glance that does not make too much sense, but apart from
> >>>> not being the correct binding to describe all of the SoCs features I see
> >>>> two scenarios:
> >>>> 1) A board vendor might choose to not use the internal PHY because it
> >>>> has bugs, lacks features (configurability) or has other issues. For
> >>>> instance I have heard reports that the internal PHY makes the SoC go
> >>>> rather hot, possibly limiting the CPU frequency. By using an external
> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
> >>>> 2) A PHY does not necessarily need to be directly connected to
> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
> >>>> IC or some other network circuitry, for instance fibre connectors.
> >>>>
> >>>> So I was wondering if we would need an explicit:
> >>>> allwinner,use-internal-phy;
> >>>> boolean DT property to signal the usage of the internal PHY?
> >>>> Alternatively we could go with the negative version:
> >>>> allwinner,disable-internal-phy;
> >>>>
> >>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
> >>>> string for the *PHY* node and use that?
> >>>>
> >>>> I just want to avoid that we introduce a binding that causes us
> >>>> headaches later. I think we can still fix this with a followup patch
> >>>> before the driver and its binding hit a release kernel.
> >>>>
> >>>> Cheers,
> >>>> Andre.
> >>>>
> >>>
> >>> I just see some patch, where "phy-mode = internal" is valid.
> >>> I will try to find a way to use it
> >>
> >> Can you provide a link?
> >
> > https://lkml.org/lkml/2017/6/23/479
> >
> >>
> >> I'm not a fan of using phy-mode for this. There's no guarantee what
> >> mode the internal PHY uses. That's what phy-mode is for.
>
> I can understand Chen-Yu's concerns, but ...
>
> > For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
> > So its not a problem.
>
> that is true as well, at least for now.
>
> So while I agree that having a separate property to indicate the usage
> of the internal PHY would be nice, I am bit tempted to use this easier
> approach and piggy back on the existing phy-mode property.
We're trying to fix an issue that works for now too.
If we want to consider future weird cases, then we must consider all
of them. And the phy mode changing is definitely not really far
fetched.
I agree with Chen-Yu, and I really feel like the compatible solution
you suggested would cover both your concerns, and ours.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:11 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andre Przywara, Corentin Labbe, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, netdev,
linux-kernel, linux-sunxi, linux-arm-kernel, Icenowy Zheng,
david.wu, Florian Fainelli, Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>> Hi,
>>
>> (CC:ing some people from that Rockchip dmwac series)
>>
>> On 27/06/17 09:21, Corentin Labbe wrote:
>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>> >> <clabbe.montjoie@gmail.com> wrote:
>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>> >>>>> allwinner.
>> >>>>> In fact the only common part is the descriptor management and the first
>> >>>>> register function.
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> I know I am a bit late with this, but while adapting the U-Boot driver
>> >>>> to the new binding I was wondering about the internal PHY detection:
>> >>>>
>> >>>>
>> >>>> So here you seem to deduce the usage of the internal PHY by the PHY
>> >>>> interface specified in the DT (MII = internal, RGMII = external).
>> >>>> I think I raised this question before, but isn't it perfectly legal for
>> >>>> a board to use MII with an external PHY even on those SoCs that feature
>> >>>> an internal PHY?
>> >>>> On the first glance that does not make too much sense, but apart from
>> >>>> not being the correct binding to describe all of the SoCs features I see
>> >>>> two scenarios:
>> >>>> 1) A board vendor might choose to not use the internal PHY because it
>> >>>> has bugs, lacks features (configurability) or has other issues. For
>> >>>> instance I have heard reports that the internal PHY makes the SoC go
>> >>>> rather hot, possibly limiting the CPU frequency. By using an external
>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>> >>>> 2) A PHY does not necessarily need to be directly connected to
>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>> >>>> IC or some other network circuitry, for instance fibre connectors.
>> >>>>
>> >>>> So I was wondering if we would need an explicit:
>> >>>> allwinner,use-internal-phy;
>> >>>> boolean DT property to signal the usage of the internal PHY?
>> >>>> Alternatively we could go with the negative version:
>> >>>> allwinner,disable-internal-phy;
>> >>>>
>> >>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>> >>>> string for the *PHY* node and use that?
>> >>>>
>> >>>> I just want to avoid that we introduce a binding that causes us
>> >>>> headaches later. I think we can still fix this with a followup patch
>> >>>> before the driver and its binding hit a release kernel.
>> >>>>
>> >>>> Cheers,
>> >>>> Andre.
>> >>>>
>> >>>
>> >>> I just see some patch, where "phy-mode = internal" is valid.
>> >>> I will try to find a way to use it
>> >>
>> >> Can you provide a link?
>> >
>> > https://lkml.org/lkml/2017/6/23/479
>> >
>> >>
>> >> I'm not a fan of using phy-mode for this. There's no guarantee what
>> >> mode the internal PHY uses. That's what phy-mode is for.
>>
>> I can understand Chen-Yu's concerns, but ...
>>
>> > For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
>> > So its not a problem.
>>
>> that is true as well, at least for now.
>>
>> So while I agree that having a separate property to indicate the usage
>> of the internal PHY would be nice, I am bit tempted to use this easier
>> approach and piggy back on the existing phy-mode property.
>
> We're trying to fix an issue that works for now too.
>
> If we want to consider future weird cases, then we must consider all
> of them. And the phy mode changing is definitely not really far
> fetched.
I guess the issue is whether it's likely that the vendor puts 2 internal
PHYs in one SoC, and they use different modes and can be switched around.
Otherwise it's fixed for a given SoC, and we can just handle that with
the per-SoC GMAC compatible.
Maybe Florian could tell us if this was one of the intended use cases
for the "internal" phy mode.
As for Rockchip, AFAIK they have 2 MACs, one is connected to the internal
PHY, while the other is connected to the external interface, and there is
no muxing involved, unlike Allwinner's solution.
> I agree with Chen-Yu, and I really feel like the compatible solution
> you suggested would cover both your concerns, and ours.
If using a PHY compatible is the solution, we could just use the
"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
Allwinner used.
Care must be taken to put this at the board level for boards using
the internal PHY, or we'd have to delete or override the property
in all other boards.
Ideally I think the internal PHY device node should _not_ be in
the SoC level .dtsi file. If we select the external interface, then
there's no connection to the internal PHY, and that device node becomes
unusable and bogus. This is something I think should be fixed regardless
of the phy-mode discussion above.
ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:11 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:11 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>> Hi,
>>
>> (CC:ing some people from that Rockchip dmwac series)
>>
>> On 27/06/17 09:21, Corentin Labbe wrote:
>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>> >> <clabbe.montjoie@gmail.com> wrote:
>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>> >>>>> allwinner.
>> >>>>> In fact the only common part is the descriptor management and the first
>> >>>>> register function.
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> I know I am a bit late with this, but while adapting the U-Boot driver
>> >>>> to the new binding I was wondering about the internal PHY detection:
>> >>>>
>> >>>>
>> >>>> So here you seem to deduce the usage of the internal PHY by the PHY
>> >>>> interface specified in the DT (MII = internal, RGMII = external).
>> >>>> I think I raised this question before, but isn't it perfectly legal for
>> >>>> a board to use MII with an external PHY even on those SoCs that feature
>> >>>> an internal PHY?
>> >>>> On the first glance that does not make too much sense, but apart from
>> >>>> not being the correct binding to describe all of the SoCs features I see
>> >>>> two scenarios:
>> >>>> 1) A board vendor might choose to not use the internal PHY because it
>> >>>> has bugs, lacks features (configurability) or has other issues. For
>> >>>> instance I have heard reports that the internal PHY makes the SoC go
>> >>>> rather hot, possibly limiting the CPU frequency. By using an external
>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>> >>>> 2) A PHY does not necessarily need to be directly connected to
>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>> >>>> IC or some other network circuitry, for instance fibre connectors.
>> >>>>
>> >>>> So I was wondering if we would need an explicit:
>> >>>> allwinner,use-internal-phy;
>> >>>> boolean DT property to signal the usage of the internal PHY?
>> >>>> Alternatively we could go with the negative version:
>> >>>> allwinner,disable-internal-phy;
>> >>>>
>> >>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>> >>>> string for the *PHY* node and use that?
>> >>>>
>> >>>> I just want to avoid that we introduce a binding that causes us
>> >>>> headaches later. I think we can still fix this with a followup patch
>> >>>> before the driver and its binding hit a release kernel.
>> >>>>
>> >>>> Cheers,
>> >>>> Andre.
>> >>>>
>> >>>
>> >>> I just see some patch, where "phy-mode = internal" is valid.
>> >>> I will try to find a way to use it
>> >>
>> >> Can you provide a link?
>> >
>> > https://lkml.org/lkml/2017/6/23/479
>> >
>> >>
>> >> I'm not a fan of using phy-mode for this. There's no guarantee what
>> >> mode the internal PHY uses. That's what phy-mode is for.
>>
>> I can understand Chen-Yu's concerns, but ...
>>
>> > For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
>> > So its not a problem.
>>
>> that is true as well, at least for now.
>>
>> So while I agree that having a separate property to indicate the usage
>> of the internal PHY would be nice, I am bit tempted to use this easier
>> approach and piggy back on the existing phy-mode property.
>
> We're trying to fix an issue that works for now too.
>
> If we want to consider future weird cases, then we must consider all
> of them. And the phy mode changing is definitely not really far
> fetched.
I guess the issue is whether it's likely that the vendor puts 2 internal
PHYs in one SoC, and they use different modes and can be switched around.
Otherwise it's fixed for a given SoC, and we can just handle that with
the per-SoC GMAC compatible.
Maybe Florian could tell us if this was one of the intended use cases
for the "internal" phy mode.
As for Rockchip, AFAIK they have 2 MACs, one is connected to the internal
PHY, while the other is connected to the external interface, and there is
no muxing involved, unlike Allwinner's solution.
> I agree with Chen-Yu, and I really feel like the compatible solution
> you suggested would cover both your concerns, and ours.
If using a PHY compatible is the solution, we could just use the
"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
Allwinner used.
Care must be taken to put this at the board level for boards using
the internal PHY, or we'd have to delete or override the property
in all other boards.
Ideally I think the internal PHY device node should _not_ be in
the SoC level .dtsi file. If we select the external interface, then
there's no connection to the internal PHY, and that device node becomes
unusable and bogus. This is something I think should be fixed regardless
of the phy-mode discussion above.
ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:11 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andre Przywara, Corentin Labbe, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
Icenowy Zheng, david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli,
Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>> Hi,
>>
>> (CC:ing some people from that Rockchip dmwac series)
>>
>> On 27/06/17 09:21, Corentin Labbe wrote:
>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>> >> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>> >>>>> allwinner.
>> >>>>> In fact the only common part is the descriptor management and the first
>> >>>>> register function.
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> I know I am a bit late with this, but while adapting the U-Boot driver
>> >>>> to the new binding I was wondering about the internal PHY detection:
>> >>>>
>> >>>>
>> >>>> So here you seem to deduce the usage of the internal PHY by the PHY
>> >>>> interface specified in the DT (MII = internal, RGMII = external).
>> >>>> I think I raised this question before, but isn't it perfectly legal for
>> >>>> a board to use MII with an external PHY even on those SoCs that feature
>> >>>> an internal PHY?
>> >>>> On the first glance that does not make too much sense, but apart from
>> >>>> not being the correct binding to describe all of the SoCs features I see
>> >>>> two scenarios:
>> >>>> 1) A board vendor might choose to not use the internal PHY because it
>> >>>> has bugs, lacks features (configurability) or has other issues. For
>> >>>> instance I have heard reports that the internal PHY makes the SoC go
>> >>>> rather hot, possibly limiting the CPU frequency. By using an external
>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>> >>>> 2) A PHY does not necessarily need to be directly connected to
>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>> >>>> IC or some other network circuitry, for instance fibre connectors.
>> >>>>
>> >>>> So I was wondering if we would need an explicit:
>> >>>> allwinner,use-internal-phy;
>> >>>> boolean DT property to signal the usage of the internal PHY?
>> >>>> Alternatively we could go with the negative version:
>> >>>> allwinner,disable-internal-phy;
>> >>>>
>> >>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>> >>>> string for the *PHY* node and use that?
>> >>>>
>> >>>> I just want to avoid that we introduce a binding that causes us
>> >>>> headaches later. I think we can still fix this with a followup patch
>> >>>> before the driver and its binding hit a release kernel.
>> >>>>
>> >>>> Cheers,
>> >>>> Andre.
>> >>>>
>> >>>
>> >>> I just see some patch, where "phy-mode = internal" is valid.
>> >>> I will try to find a way to use it
>> >>
>> >> Can you provide a link?
>> >
>> > https://lkml.org/lkml/2017/6/23/479
>> >
>> >>
>> >> I'm not a fan of using phy-mode for this. There's no guarantee what
>> >> mode the internal PHY uses. That's what phy-mode is for.
>>
>> I can understand Chen-Yu's concerns, but ...
>>
>> > For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
>> > So its not a problem.
>>
>> that is true as well, at least for now.
>>
>> So while I agree that having a separate property to indicate the usage
>> of the internal PHY would be nice, I am bit tempted to use this easier
>> approach and piggy back on the existing phy-mode property.
>
> We're trying to fix an issue that works for now too.
>
> If we want to consider future weird cases, then we must consider all
> of them. And the phy mode changing is definitely not really far
> fetched.
I guess the issue is whether it's likely that the vendor puts 2 internal
PHYs in one SoC, and they use different modes and can be switched around.
Otherwise it's fixed for a given SoC, and we can just handle that with
the per-SoC GMAC compatible.
Maybe Florian could tell us if this was one of the intended use cases
for the "internal" phy mode.
As for Rockchip, AFAIK they have 2 MACs, one is connected to the internal
PHY, while the other is connected to the external interface, and there is
no muxing involved, unlike Allwinner's solution.
> I agree with Chen-Yu, and I really feel like the compatible solution
> you suggested would cover both your concerns, and ours.
If using a PHY compatible is the solution, we could just use the
"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
Allwinner used.
Care must be taken to put this at the board level for boards using
the internal PHY, or we'd have to delete or override the property
in all other boards.
Ideally I think the internal PHY device node should _not_ be in
the SoC level .dtsi file. If we select the external interface, then
there's no connection to the internal PHY, and that device node becomes
unusable and bogus. This is something I think should be fixed regardless
of the phy-mode discussion above.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [linux-sunxi] Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-06-27 10:11 ` Chen-Yu Tsai
(?)
@ 2017-06-27 10:17 ` Icenowy Zheng
-1 siblings, 0 replies; 148+ messages in thread
From: Icenowy Zheng @ 2017-06-27 10:17 UTC (permalink / raw)
To: wens, Chen-Yu Tsai, Maxime Ripard
Cc: Andre Przywara, Corentin Labbe, Rob Herring, Mark Rutland,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, netdev, linux-kernel, linux-sunxi,
linux-arm-kernel, david.wu, Florian Fainelli, Andrew Lunn,
Heiko Stübner
于 2017年6月27日 GMT+08:00 下午6:11:47, Chen-Yu Tsai <wens@csie.org> 写到:
>On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
><maxime.ripard@free-electrons.com> wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>> >> <clabbe.montjoie@gmail.com> wrote:
>>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware
>by
>>> >>>>> allwinner.
>>> >>>>> In fact the only common part is the descriptor management and
>the first
>>> >>>>> register function.
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> I know I am a bit late with this, but while adapting the U-Boot
>driver
>>> >>>> to the new binding I was wondering about the internal PHY
>detection:
>>> >>>>
>>> >>>>
>>> >>>> So here you seem to deduce the usage of the internal PHY by the
>PHY
>>> >>>> interface specified in the DT (MII = internal, RGMII =
>external).
>>> >>>> I think I raised this question before, but isn't it perfectly
>legal for
>>> >>>> a board to use MII with an external PHY even on those SoCs that
>feature
>>> >>>> an internal PHY?
>>> >>>> On the first glance that does not make too much sense, but
>apart from
>>> >>>> not being the correct binding to describe all of the SoCs
>features I see
>>> >>>> two scenarios:
>>> >>>> 1) A board vendor might choose to not use the internal PHY
>because it
>>> >>>> has bugs, lacks features (configurability) or has other issues.
>For
>>> >>>> instance I have heard reports that the internal PHY makes the
>SoC go
>>> >>>> rather hot, possibly limiting the CPU frequency. By using an
>external
>>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>avoided.
>>> >>>> 2) A PHY does not necessarily need to be directly connected to
>>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>switch
>>> >>>> IC or some other network circuitry, for instance fibre
>connectors.
>>> >>>>
>>> >>>> So I was wondering if we would need an explicit:
>>> >>>> allwinner,use-internal-phy;
>>> >>>> boolean DT property to signal the usage of the internal PHY?
>>> >>>> Alternatively we could go with the negative version:
>>> >>>> allwinner,disable-internal-phy;
>>> >>>>
>>> >>>> Or what about introducing a new "allwinner,internal-mii-phy"
>compatible
>>> >>>> string for the *PHY* node and use that?
>>> >>>>
>>> >>>> I just want to avoid that we introduce a binding that causes us
>>> >>>> headaches later. I think we can still fix this with a followup
>patch
>>> >>>> before the driver and its binding hit a release kernel.
>>> >>>>
>>> >>>> Cheers,
>>> >>>> Andre.
>>> >>>>
>>> >>>
>>> >>> I just see some patch, where "phy-mode = internal" is valid.
>>> >>> I will try to find a way to use it
>>> >>
>>> >> Can you provide a link?
>>> >
>>> > https://lkml.org/lkml/2017/6/23/479
>>> >
>>> >>
>>> >> I'm not a fan of using phy-mode for this. There's no guarantee
>what
>>> >> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>> > For each soc the internal PHY mode is know and setted in
>emac_variant/internal_phy
>>> > So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the
>usage
>>> of the internal PHY would be nice, I am bit tempted to use this
>easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>
>I guess the issue is whether it's likely that the vendor puts 2
>internal
>PHYs in one SoC, and they use different modes and can be switched
>around.
>Otherwise it's fixed for a given SoC, and we can just handle that with
>the per-SoC GMAC compatible.
>
>Maybe Florian could tell us if this was one of the intended use cases
>for the "internal" phy mode.
>
>As for Rockchip, AFAIK they have 2 MACs, one is connected to the
>internal
>PHY, while the other is connected to the external interface, and there
>is
>no muxing involved, unlike Allwinner's solution.
>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
>If using a PHY compatible is the solution, we could just use the
>"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
>Allwinner used.
>
>Care must be taken to put this at the board level for boards using
>the internal PHY, or we'd have to delete or override the property
>in all other boards.
>
>Ideally I think the internal PHY device node should _not_ be in
>the SoC level .dtsi file. If we select the external interface, then
>there's no connection to the internal PHY, and that device node becomes
>unusable and bogus. This is something I think should be fixed
>regardless
>of the phy-mode discussion above.
I think it should be in the SoC DTSI, as it's part of the SoC.
But it makes sense to set status to disabled defaultly.
>
>ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* [linux-sunxi] Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:17 ` Icenowy Zheng
0 siblings, 0 replies; 148+ messages in thread
From: Icenowy Zheng @ 2017-06-27 10:17 UTC (permalink / raw)
To: linux-arm-kernel
? 2017?6?27? GMT+08:00 ??6:11:47, Chen-Yu Tsai <wens@csie.org> ??:
>On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
><maxime.ripard@free-electrons.com> wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>> >> <clabbe.montjoie@gmail.com> wrote:
>>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware
>by
>>> >>>>> allwinner.
>>> >>>>> In fact the only common part is the descriptor management and
>the first
>>> >>>>> register function.
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> I know I am a bit late with this, but while adapting the U-Boot
>driver
>>> >>>> to the new binding I was wondering about the internal PHY
>detection:
>>> >>>>
>>> >>>>
>>> >>>> So here you seem to deduce the usage of the internal PHY by the
>PHY
>>> >>>> interface specified in the DT (MII = internal, RGMII =
>external).
>>> >>>> I think I raised this question before, but isn't it perfectly
>legal for
>>> >>>> a board to use MII with an external PHY even on those SoCs that
>feature
>>> >>>> an internal PHY?
>>> >>>> On the first glance that does not make too much sense, but
>apart from
>>> >>>> not being the correct binding to describe all of the SoCs
>features I see
>>> >>>> two scenarios:
>>> >>>> 1) A board vendor might choose to not use the internal PHY
>because it
>>> >>>> has bugs, lacks features (configurability) or has other issues.
>For
>>> >>>> instance I have heard reports that the internal PHY makes the
>SoC go
>>> >>>> rather hot, possibly limiting the CPU frequency. By using an
>external
>>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>avoided.
>>> >>>> 2) A PHY does not necessarily need to be directly connected to
>>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>switch
>>> >>>> IC or some other network circuitry, for instance fibre
>connectors.
>>> >>>>
>>> >>>> So I was wondering if we would need an explicit:
>>> >>>> allwinner,use-internal-phy;
>>> >>>> boolean DT property to signal the usage of the internal PHY?
>>> >>>> Alternatively we could go with the negative version:
>>> >>>> allwinner,disable-internal-phy;
>>> >>>>
>>> >>>> Or what about introducing a new "allwinner,internal-mii-phy"
>compatible
>>> >>>> string for the *PHY* node and use that?
>>> >>>>
>>> >>>> I just want to avoid that we introduce a binding that causes us
>>> >>>> headaches later. I think we can still fix this with a followup
>patch
>>> >>>> before the driver and its binding hit a release kernel.
>>> >>>>
>>> >>>> Cheers,
>>> >>>> Andre.
>>> >>>>
>>> >>>
>>> >>> I just see some patch, where "phy-mode = internal" is valid.
>>> >>> I will try to find a way to use it
>>> >>
>>> >> Can you provide a link?
>>> >
>>> > https://lkml.org/lkml/2017/6/23/479
>>> >
>>> >>
>>> >> I'm not a fan of using phy-mode for this. There's no guarantee
>what
>>> >> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>> > For each soc the internal PHY mode is know and setted in
>emac_variant/internal_phy
>>> > So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the
>usage
>>> of the internal PHY would be nice, I am bit tempted to use this
>easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>
>I guess the issue is whether it's likely that the vendor puts 2
>internal
>PHYs in one SoC, and they use different modes and can be switched
>around.
>Otherwise it's fixed for a given SoC, and we can just handle that with
>the per-SoC GMAC compatible.
>
>Maybe Florian could tell us if this was one of the intended use cases
>for the "internal" phy mode.
>
>As for Rockchip, AFAIK they have 2 MACs, one is connected to the
>internal
>PHY, while the other is connected to the external interface, and there
>is
>no muxing involved, unlike Allwinner's solution.
>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
>If using a PHY compatible is the solution, we could just use the
>"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
>Allwinner used.
>
>Care must be taken to put this at the board level for boards using
>the internal PHY, or we'd have to delete or override the property
>in all other boards.
>
>Ideally I think the internal PHY device node should _not_ be in
>the SoC level .dtsi file. If we select the external interface, then
>there's no connection to the internal PHY, and that device node becomes
>unusable and bogus. This is something I think should be fixed
>regardless
>of the phy-mode discussion above.
I think it should be in the SoC DTSI, as it's part of the SoC.
But it makes sense to set status to disabled defaultly.
>
>ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [linux-sunxi] Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:17 ` Icenowy Zheng
0 siblings, 0 replies; 148+ messages in thread
From: Icenowy Zheng @ 2017-06-27 10:17 UTC (permalink / raw)
To: wens
Cc: Andre Przywara, Corentin Labbe, Rob Herring, Mark Rutland,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, netdev, linux-kernel, linux-sunxi,
linux-arm-kernel, david.wu, Florian Fainelli, Andrew Lunn,
Heiko Stübner
于 2017年6月27日 GMT+08:00 下午6:11:47, Chen-Yu Tsai <wens@csie.org> 写到:
>On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
><maxime.ripard@free-electrons.com> wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>> >> <clabbe.montjoie@gmail.com> wrote:
>>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware
>by
>>> >>>>> allwinner.
>>> >>>>> In fact the only common part is the descriptor management and
>the first
>>> >>>>> register function.
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> I know I am a bit late with this, but while adapting the U-Boot
>driver
>>> >>>> to the new binding I was wondering about the internal PHY
>detection:
>>> >>>>
>>> >>>>
>>> >>>> So here you seem to deduce the usage of the internal PHY by the
>PHY
>>> >>>> interface specified in the DT (MII = internal, RGMII =
>external).
>>> >>>> I think I raised this question before, but isn't it perfectly
>legal for
>>> >>>> a board to use MII with an external PHY even on those SoCs that
>feature
>>> >>>> an internal PHY?
>>> >>>> On the first glance that does not make too much sense, but
>apart from
>>> >>>> not being the correct binding to describe all of the SoCs
>features I see
>>> >>>> two scenarios:
>>> >>>> 1) A board vendor might choose to not use the internal PHY
>because it
>>> >>>> has bugs, lacks features (configurability) or has other issues.
>For
>>> >>>> instance I have heard reports that the internal PHY makes the
>SoC go
>>> >>>> rather hot, possibly limiting the CPU frequency. By using an
>external
>>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>avoided.
>>> >>>> 2) A PHY does not necessarily need to be directly connected to
>>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>switch
>>> >>>> IC or some other network circuitry, for instance fibre
>connectors.
>>> >>>>
>>> >>>> So I was wondering if we would need an explicit:
>>> >>>> allwinner,use-internal-phy;
>>> >>>> boolean DT property to signal the usage of the internal PHY?
>>> >>>> Alternatively we could go with the negative version:
>>> >>>> allwinner,disable-internal-phy;
>>> >>>>
>>> >>>> Or what about introducing a new "allwinner,internal-mii-phy"
>compatible
>>> >>>> string for the *PHY* node and use that?
>>> >>>>
>>> >>>> I just want to avoid that we introduce a binding that causes us
>>> >>>> headaches later. I think we can still fix this with a followup
>patch
>>> >>>> before the driver and its binding hit a release kernel.
>>> >>>>
>>> >>>> Cheers,
>>> >>>> Andre.
>>> >>>>
>>> >>>
>>> >>> I just see some patch, where "phy-mode = internal" is valid.
>>> >>> I will try to find a way to use it
>>> >>
>>> >> Can you provide a link?
>>> >
>>> > https://lkml.org/lkml/2017/6/23/479
>>> >
>>> >>
>>> >> I'm not a fan of using phy-mode for this. There's no guarantee
>what
>>> >> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>> > For each soc the internal PHY mode is know and setted in
>emac_variant/internal_phy
>>> > So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the
>usage
>>> of the internal PHY would be nice, I am bit tempted to use this
>easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>
>I guess the issue is whether it's likely that the vendor puts 2
>internal
>PHYs in one SoC, and they use different modes and can be switched
>around.
>Otherwise it's fixed for a given SoC, and we can just handle that with
>the per-SoC GMAC compatible.
>
>Maybe Florian could tell us if this was one of the intended use cases
>for the "internal" phy mode.
>
>As for Rockchip, AFAIK they have 2 MACs, one is connected to the
>internal
>PHY, while the other is connected to the external interface, and there
>is
>no muxing involved, unlike Allwinner's solution.
>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
>If using a PHY compatible is the solution, we could just use the
>"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
>Allwinner used.
>
>Care must be taken to put this at the board level for boards using
>the internal PHY, or we'd have to delete or override the property
>in all other boards.
>
>Ideally I think the internal PHY device node should _not_ be in
>the SoC level .dtsi file. If we select the external interface, then
>there's no connection to the internal PHY, and that device node becomes
>unusable and bogus. This is something I think should be fixed
>regardless
>of the phy-mode discussion above.
I think it should be in the SoC DTSI, as it's part of the SoC.
But it makes sense to set status to disabled defaultly.
>
>ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [linux-sunxi] Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:20 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:20 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Maxime Ripard, Andre Przywara, Corentin Labbe,
Rob Herring, Mark Rutland, Russell King, Catalin Marinas,
Will Deacon, Giuseppe Cavallaro, alexandre.torgue, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Florian Fainelli, Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 6:17 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2017年6月27日 GMT+08:00 下午6:11:47, Chen-Yu Tsai <wens@csie.org> 写到:
>>On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
>><maxime.ripard@free-electrons.com> wrote:
>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>> Hi,
>>>>
>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>
>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>> >> <clabbe.montjoie@gmail.com> wrote:
>>>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware
>>by
>>>> >>>>> allwinner.
>>>> >>>>> In fact the only common part is the descriptor management and
>>the first
>>>> >>>>> register function.
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> I know I am a bit late with this, but while adapting the U-Boot
>>driver
>>>> >>>> to the new binding I was wondering about the internal PHY
>>detection:
>>>> >>>>
>>>> >>>>
>>>> >>>> So here you seem to deduce the usage of the internal PHY by the
>>PHY
>>>> >>>> interface specified in the DT (MII = internal, RGMII =
>>external).
>>>> >>>> I think I raised this question before, but isn't it perfectly
>>legal for
>>>> >>>> a board to use MII with an external PHY even on those SoCs that
>>feature
>>>> >>>> an internal PHY?
>>>> >>>> On the first glance that does not make too much sense, but
>>apart from
>>>> >>>> not being the correct binding to describe all of the SoCs
>>features I see
>>>> >>>> two scenarios:
>>>> >>>> 1) A board vendor might choose to not use the internal PHY
>>because it
>>>> >>>> has bugs, lacks features (configurability) or has other issues.
>>For
>>>> >>>> instance I have heard reports that the internal PHY makes the
>>SoC go
>>>> >>>> rather hot, possibly limiting the CPU frequency. By using an
>>external
>>>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>avoided.
>>>> >>>> 2) A PHY does not necessarily need to be directly connected to
>>>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>switch
>>>> >>>> IC or some other network circuitry, for instance fibre
>>connectors.
>>>> >>>>
>>>> >>>> So I was wondering if we would need an explicit:
>>>> >>>> allwinner,use-internal-phy;
>>>> >>>> boolean DT property to signal the usage of the internal PHY?
>>>> >>>> Alternatively we could go with the negative version:
>>>> >>>> allwinner,disable-internal-phy;
>>>> >>>>
>>>> >>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>compatible
>>>> >>>> string for the *PHY* node and use that?
>>>> >>>>
>>>> >>>> I just want to avoid that we introduce a binding that causes us
>>>> >>>> headaches later. I think we can still fix this with a followup
>>patch
>>>> >>>> before the driver and its binding hit a release kernel.
>>>> >>>>
>>>> >>>> Cheers,
>>>> >>>> Andre.
>>>> >>>>
>>>> >>>
>>>> >>> I just see some patch, where "phy-mode = internal" is valid.
>>>> >>> I will try to find a way to use it
>>>> >>
>>>> >> Can you provide a link?
>>>> >
>>>> > https://lkml.org/lkml/2017/6/23/479
>>>> >
>>>> >>
>>>> >> I'm not a fan of using phy-mode for this. There's no guarantee
>>what
>>>> >> mode the internal PHY uses. That's what phy-mode is for.
>>>>
>>>> I can understand Chen-Yu's concerns, but ...
>>>>
>>>> > For each soc the internal PHY mode is know and setted in
>>emac_variant/internal_phy
>>>> > So its not a problem.
>>>>
>>>> that is true as well, at least for now.
>>>>
>>>> So while I agree that having a separate property to indicate the
>>usage
>>>> of the internal PHY would be nice, I am bit tempted to use this
>>easier
>>>> approach and piggy back on the existing phy-mode property.
>>>
>>> We're trying to fix an issue that works for now too.
>>>
>>> If we want to consider future weird cases, then we must consider all
>>> of them. And the phy mode changing is definitely not really far
>>> fetched.
>>
>>I guess the issue is whether it's likely that the vendor puts 2
>>internal
>>PHYs in one SoC, and they use different modes and can be switched
>>around.
>>Otherwise it's fixed for a given SoC, and we can just handle that with
>>the per-SoC GMAC compatible.
>>
>>Maybe Florian could tell us if this was one of the intended use cases
>>for the "internal" phy mode.
>>
>>As for Rockchip, AFAIK they have 2 MACs, one is connected to the
>>internal
>>PHY, while the other is connected to the external interface, and there
>>is
>>no muxing involved, unlike Allwinner's solution.
>>
>>> I agree with Chen-Yu, and I really feel like the compatible solution
>>> you suggested would cover both your concerns, and ours.
>>
>>If using a PHY compatible is the solution, we could just use the
>>"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
>>Allwinner used.
>>
>>Care must be taken to put this at the board level for boards using
>>the internal PHY, or we'd have to delete or override the property
>>in all other boards.
>>
>>Ideally I think the internal PHY device node should _not_ be in
>>the SoC level .dtsi file. If we select the external interface, then
>>there's no connection to the internal PHY, and that device node becomes
>>unusable and bogus. This is something I think should be fixed
>>regardless
>>of the phy-mode discussion above.
>
> I think it should be in the SoC DTSI, as it's part of the SoC.
>
> But it makes sense to set status to disabled defaultly.
Then you end up stepping on it when you add an external PHY
with the same address, and start wondering why things don't
work.
ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* [linux-sunxi] Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:20 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:20 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 6:17 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> ? 2017?6?27? GMT+08:00 ??6:11:47, Chen-Yu Tsai <wens@csie.org> ??:
>>On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
>><maxime.ripard@free-electrons.com> wrote:
>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>> Hi,
>>>>
>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>
>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>> >> <clabbe.montjoie@gmail.com> wrote:
>>>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware
>>by
>>>> >>>>> allwinner.
>>>> >>>>> In fact the only common part is the descriptor management and
>>the first
>>>> >>>>> register function.
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> I know I am a bit late with this, but while adapting the U-Boot
>>driver
>>>> >>>> to the new binding I was wondering about the internal PHY
>>detection:
>>>> >>>>
>>>> >>>>
>>>> >>>> So here you seem to deduce the usage of the internal PHY by the
>>PHY
>>>> >>>> interface specified in the DT (MII = internal, RGMII =
>>external).
>>>> >>>> I think I raised this question before, but isn't it perfectly
>>legal for
>>>> >>>> a board to use MII with an external PHY even on those SoCs that
>>feature
>>>> >>>> an internal PHY?
>>>> >>>> On the first glance that does not make too much sense, but
>>apart from
>>>> >>>> not being the correct binding to describe all of the SoCs
>>features I see
>>>> >>>> two scenarios:
>>>> >>>> 1) A board vendor might choose to not use the internal PHY
>>because it
>>>> >>>> has bugs, lacks features (configurability) or has other issues.
>>For
>>>> >>>> instance I have heard reports that the internal PHY makes the
>>SoC go
>>>> >>>> rather hot, possibly limiting the CPU frequency. By using an
>>external
>>>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>avoided.
>>>> >>>> 2) A PHY does not necessarily need to be directly connected to
>>>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>switch
>>>> >>>> IC or some other network circuitry, for instance fibre
>>connectors.
>>>> >>>>
>>>> >>>> So I was wondering if we would need an explicit:
>>>> >>>> allwinner,use-internal-phy;
>>>> >>>> boolean DT property to signal the usage of the internal PHY?
>>>> >>>> Alternatively we could go with the negative version:
>>>> >>>> allwinner,disable-internal-phy;
>>>> >>>>
>>>> >>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>compatible
>>>> >>>> string for the *PHY* node and use that?
>>>> >>>>
>>>> >>>> I just want to avoid that we introduce a binding that causes us
>>>> >>>> headaches later. I think we can still fix this with a followup
>>patch
>>>> >>>> before the driver and its binding hit a release kernel.
>>>> >>>>
>>>> >>>> Cheers,
>>>> >>>> Andre.
>>>> >>>>
>>>> >>>
>>>> >>> I just see some patch, where "phy-mode = internal" is valid.
>>>> >>> I will try to find a way to use it
>>>> >>
>>>> >> Can you provide a link?
>>>> >
>>>> > https://lkml.org/lkml/2017/6/23/479
>>>> >
>>>> >>
>>>> >> I'm not a fan of using phy-mode for this. There's no guarantee
>>what
>>>> >> mode the internal PHY uses. That's what phy-mode is for.
>>>>
>>>> I can understand Chen-Yu's concerns, but ...
>>>>
>>>> > For each soc the internal PHY mode is know and setted in
>>emac_variant/internal_phy
>>>> > So its not a problem.
>>>>
>>>> that is true as well, at least for now.
>>>>
>>>> So while I agree that having a separate property to indicate the
>>usage
>>>> of the internal PHY would be nice, I am bit tempted to use this
>>easier
>>>> approach and piggy back on the existing phy-mode property.
>>>
>>> We're trying to fix an issue that works for now too.
>>>
>>> If we want to consider future weird cases, then we must consider all
>>> of them. And the phy mode changing is definitely not really far
>>> fetched.
>>
>>I guess the issue is whether it's likely that the vendor puts 2
>>internal
>>PHYs in one SoC, and they use different modes and can be switched
>>around.
>>Otherwise it's fixed for a given SoC, and we can just handle that with
>>the per-SoC GMAC compatible.
>>
>>Maybe Florian could tell us if this was one of the intended use cases
>>for the "internal" phy mode.
>>
>>As for Rockchip, AFAIK they have 2 MACs, one is connected to the
>>internal
>>PHY, while the other is connected to the external interface, and there
>>is
>>no muxing involved, unlike Allwinner's solution.
>>
>>> I agree with Chen-Yu, and I really feel like the compatible solution
>>> you suggested would cover both your concerns, and ours.
>>
>>If using a PHY compatible is the solution, we could just use the
>>"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
>>Allwinner used.
>>
>>Care must be taken to put this at the board level for boards using
>>the internal PHY, or we'd have to delete or override the property
>>in all other boards.
>>
>>Ideally I think the internal PHY device node should _not_ be in
>>the SoC level .dtsi file. If we select the external interface, then
>>there's no connection to the internal PHY, and that device node becomes
>>unusable and bogus. This is something I think should be fixed
>>regardless
>>of the phy-mode discussion above.
>
> I think it should be in the SoC DTSI, as it's part of the SoC.
>
> But it makes sense to set status to disabled defaultly.
Then you end up stepping on it when you add an external PHY
with the same address, and start wondering why things don't
work.
ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:20 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:20 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Maxime Ripard, Andre Przywara, Corentin Labbe,
Rob Herring, Mark Rutland, Russell King, Catalin Marinas,
Will Deacon, Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o,
devicetree, netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli, Andrew Lunn,
Heiko Stübner
On Tue, Jun 27, 2017 at 6:17 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>
>
> 于 2017年6月27日 GMT+08:00 下午6:11:47, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>>On Tue, Jun 27, 2017 at 5:41 PM, Maxime Ripard
>><maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>> Hi,
>>>>
>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>
>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>> >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>> >> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>> >>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>> >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware
>>by
>>>> >>>>> allwinner.
>>>> >>>>> In fact the only common part is the descriptor management and
>>the first
>>>> >>>>> register function.
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> I know I am a bit late with this, but while adapting the U-Boot
>>driver
>>>> >>>> to the new binding I was wondering about the internal PHY
>>detection:
>>>> >>>>
>>>> >>>>
>>>> >>>> So here you seem to deduce the usage of the internal PHY by the
>>PHY
>>>> >>>> interface specified in the DT (MII = internal, RGMII =
>>external).
>>>> >>>> I think I raised this question before, but isn't it perfectly
>>legal for
>>>> >>>> a board to use MII with an external PHY even on those SoCs that
>>feature
>>>> >>>> an internal PHY?
>>>> >>>> On the first glance that does not make too much sense, but
>>apart from
>>>> >>>> not being the correct binding to describe all of the SoCs
>>features I see
>>>> >>>> two scenarios:
>>>> >>>> 1) A board vendor might choose to not use the internal PHY
>>because it
>>>> >>>> has bugs, lacks features (configurability) or has other issues.
>>For
>>>> >>>> instance I have heard reports that the internal PHY makes the
>>SoC go
>>>> >>>> rather hot, possibly limiting the CPU frequency. By using an
>>external
>>>> >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>avoided.
>>>> >>>> 2) A PHY does not necessarily need to be directly connected to
>>>> >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>switch
>>>> >>>> IC or some other network circuitry, for instance fibre
>>connectors.
>>>> >>>>
>>>> >>>> So I was wondering if we would need an explicit:
>>>> >>>> allwinner,use-internal-phy;
>>>> >>>> boolean DT property to signal the usage of the internal PHY?
>>>> >>>> Alternatively we could go with the negative version:
>>>> >>>> allwinner,disable-internal-phy;
>>>> >>>>
>>>> >>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>compatible
>>>> >>>> string for the *PHY* node and use that?
>>>> >>>>
>>>> >>>> I just want to avoid that we introduce a binding that causes us
>>>> >>>> headaches later. I think we can still fix this with a followup
>>patch
>>>> >>>> before the driver and its binding hit a release kernel.
>>>> >>>>
>>>> >>>> Cheers,
>>>> >>>> Andre.
>>>> >>>>
>>>> >>>
>>>> >>> I just see some patch, where "phy-mode = internal" is valid.
>>>> >>> I will try to find a way to use it
>>>> >>
>>>> >> Can you provide a link?
>>>> >
>>>> > https://lkml.org/lkml/2017/6/23/479
>>>> >
>>>> >>
>>>> >> I'm not a fan of using phy-mode for this. There's no guarantee
>>what
>>>> >> mode the internal PHY uses. That's what phy-mode is for.
>>>>
>>>> I can understand Chen-Yu's concerns, but ...
>>>>
>>>> > For each soc the internal PHY mode is know and setted in
>>emac_variant/internal_phy
>>>> > So its not a problem.
>>>>
>>>> that is true as well, at least for now.
>>>>
>>>> So while I agree that having a separate property to indicate the
>>usage
>>>> of the internal PHY would be nice, I am bit tempted to use this
>>easier
>>>> approach and piggy back on the existing phy-mode property.
>>>
>>> We're trying to fix an issue that works for now too.
>>>
>>> If we want to consider future weird cases, then we must consider all
>>> of them. And the phy mode changing is definitely not really far
>>> fetched.
>>
>>I guess the issue is whether it's likely that the vendor puts 2
>>internal
>>PHYs in one SoC, and they use different modes and can be switched
>>around.
>>Otherwise it's fixed for a given SoC, and we can just handle that with
>>the per-SoC GMAC compatible.
>>
>>Maybe Florian could tell us if this was one of the intended use cases
>>for the "internal" phy mode.
>>
>>As for Rockchip, AFAIK they have 2 MACs, one is connected to the
>>internal
>>PHY, while the other is connected to the external interface, and there
>>is
>>no muxing involved, unlike Allwinner's solution.
>>
>>> I agree with Chen-Yu, and I really feel like the compatible solution
>>> you suggested would cover both your concerns, and ours.
>>
>>If using a PHY compatible is the solution, we could just use the
>>"ethernet-phy-idAAAA.BBBB" style one, and put in the bogus ID that
>>Allwinner used.
>>
>>Care must be taken to put this at the board level for boards using
>>the internal PHY, or we'd have to delete or override the property
>>in all other boards.
>>
>>Ideally I think the internal PHY device node should _not_ be in
>>the SoC level .dtsi file. If we select the external interface, then
>>there's no connection to the internal PHY, and that device node becomes
>>unusable and bogus. This is something I think should be fixed
>>regardless
>>of the phy-mode discussion above.
>
> I think it should be in the SoC DTSI, as it's part of the SoC.
>
> But it makes sense to set status to disabled defaultly.
Then you end up stepping on it when you add an external PHY
with the same address, and start wondering why things don't
work.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-06-27 9:41 ` Maxime Ripard
@ 2017-06-27 10:15 ` Andre Przywara
-1 siblings, 0 replies; 148+ messages in thread
From: Andre Przywara @ 2017-06-27 10:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: Corentin Labbe, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, netdev, linux-kernel, linux-sunxi,
linux-arm-kernel, Icenowy Zheng, david.wu, Florian Fainelli,
Andrew Lunn, Heiko Stübner
Hi,
On 27/06/17 10:41, Maxime Ripard wrote:
> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>> Hi,
>>
>> (CC:ing some people from that Rockchip dmwac series)
>>
>> On 27/06/17 09:21, Corentin Labbe wrote:
>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>> allwinner.
>>>>>>> In fact the only common part is the descriptor management and the first
>>>>>>> register function.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I know I am a bit late with this, but while adapting the U-Boot driver
>>>>>> to the new binding I was wondering about the internal PHY detection:
>>>>>>
>>>>>>
>>>>>> So here you seem to deduce the usage of the internal PHY by the PHY
>>>>>> interface specified in the DT (MII = internal, RGMII = external).
>>>>>> I think I raised this question before, but isn't it perfectly legal for
>>>>>> a board to use MII with an external PHY even on those SoCs that feature
>>>>>> an internal PHY?
>>>>>> On the first glance that does not make too much sense, but apart from
>>>>>> not being the correct binding to describe all of the SoCs features I see
>>>>>> two scenarios:
>>>>>> 1) A board vendor might choose to not use the internal PHY because it
>>>>>> has bugs, lacks features (configurability) or has other issues. For
>>>>>> instance I have heard reports that the internal PHY makes the SoC go
>>>>>> rather hot, possibly limiting the CPU frequency. By using an external
>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>>>>>> IC or some other network circuitry, for instance fibre connectors.
>>>>>>
>>>>>> So I was wondering if we would need an explicit:
>>>>>> allwinner,use-internal-phy;
>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>> Alternatively we could go with the negative version:
>>>>>> allwinner,disable-internal-phy;
>>>>>>
>>>>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>>>>>> string for the *PHY* node and use that?
>>>>>>
>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>> headaches later. I think we can still fix this with a followup patch
>>>>>> before the driver and its binding hit a release kernel.
>>>>>>
>>>>>> Cheers,
>>>>>> Andre.
>>>>>>
>>>>>
>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>> I will try to find a way to use it
>>>>
>>>> Can you provide a link?
>>>
>>> https://lkml.org/lkml/2017/6/23/479
>>>
>>>>
>>>> I'm not a fan of using phy-mode for this. There's no guarantee what
>>>> mode the internal PHY uses. That's what phy-mode is for.
>>
>> I can understand Chen-Yu's concerns, but ...
>>
>>> For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
>>> So its not a problem.
>>
>> that is true as well, at least for now.
>>
>> So while I agree that having a separate property to indicate the usage
>> of the internal PHY would be nice, I am bit tempted to use this easier
>> approach and piggy back on the existing phy-mode property.
>
> We're trying to fix an issue that works for now too.
>
> If we want to consider future weird cases, then we must consider all
> of them. And the phy mode changing is definitely not really far
> fetched.
>
> I agree with Chen-Yu, and I really feel like the compatible solution
> you suggested would cover both your concerns, and ours.
So something like this?
emac: emac@1c30000 {
compatible = "allwinner,sun8i-h3-emac";
...
phy-mode = "mii";
phy-handle = <&int_mii_phy>;
...
mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
int_mii_phy: ethernet-phy@1 {
compatible = "allwinner,sun8i-h3-ephy";
syscon = <&syscon>;
reg = <1>;
clocks = <&ccu CLK_BUS_EPHY>;
resets = <&ccu RST_BUS_EPHY>;
};
};
};
And then move the internal-PHY setup code into a separate PHY driver?
That looks like the architecturally best solution to me, but is probably
also a bit involved since it would require a separate PHY driver.
Or can we make it simpler, but still use this binding?
Cheers,
Andre.
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:15 ` Andre Przywara
0 siblings, 0 replies; 148+ messages in thread
From: Andre Przywara @ 2017-06-27 10:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 27/06/17 10:41, Maxime Ripard wrote:
> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>> Hi,
>>
>> (CC:ing some people from that Rockchip dmwac series)
>>
>> On 27/06/17 09:21, Corentin Labbe wrote:
>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>> allwinner.
>>>>>>> In fact the only common part is the descriptor management and the first
>>>>>>> register function.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I know I am a bit late with this, but while adapting the U-Boot driver
>>>>>> to the new binding I was wondering about the internal PHY detection:
>>>>>>
>>>>>>
>>>>>> So here you seem to deduce the usage of the internal PHY by the PHY
>>>>>> interface specified in the DT (MII = internal, RGMII = external).
>>>>>> I think I raised this question before, but isn't it perfectly legal for
>>>>>> a board to use MII with an external PHY even on those SoCs that feature
>>>>>> an internal PHY?
>>>>>> On the first glance that does not make too much sense, but apart from
>>>>>> not being the correct binding to describe all of the SoCs features I see
>>>>>> two scenarios:
>>>>>> 1) A board vendor might choose to not use the internal PHY because it
>>>>>> has bugs, lacks features (configurability) or has other issues. For
>>>>>> instance I have heard reports that the internal PHY makes the SoC go
>>>>>> rather hot, possibly limiting the CPU frequency. By using an external
>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>>>>>> IC or some other network circuitry, for instance fibre connectors.
>>>>>>
>>>>>> So I was wondering if we would need an explicit:
>>>>>> allwinner,use-internal-phy;
>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>> Alternatively we could go with the negative version:
>>>>>> allwinner,disable-internal-phy;
>>>>>>
>>>>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>>>>>> string for the *PHY* node and use that?
>>>>>>
>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>> headaches later. I think we can still fix this with a followup patch
>>>>>> before the driver and its binding hit a release kernel.
>>>>>>
>>>>>> Cheers,
>>>>>> Andre.
>>>>>>
>>>>>
>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>> I will try to find a way to use it
>>>>
>>>> Can you provide a link?
>>>
>>> https://lkml.org/lkml/2017/6/23/479
>>>
>>>>
>>>> I'm not a fan of using phy-mode for this. There's no guarantee what
>>>> mode the internal PHY uses. That's what phy-mode is for.
>>
>> I can understand Chen-Yu's concerns, but ...
>>
>>> For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
>>> So its not a problem.
>>
>> that is true as well, at least for now.
>>
>> So while I agree that having a separate property to indicate the usage
>> of the internal PHY would be nice, I am bit tempted to use this easier
>> approach and piggy back on the existing phy-mode property.
>
> We're trying to fix an issue that works for now too.
>
> If we want to consider future weird cases, then we must consider all
> of them. And the phy mode changing is definitely not really far
> fetched.
>
> I agree with Chen-Yu, and I really feel like the compatible solution
> you suggested would cover both your concerns, and ours.
So something like this?
emac: emac at 1c30000 {
compatible = "allwinner,sun8i-h3-emac";
...
phy-mode = "mii";
phy-handle = <&int_mii_phy>;
...
mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
int_mii_phy: ethernet-phy at 1 {
compatible = "allwinner,sun8i-h3-ephy";
syscon = <&syscon>;
reg = <1>;
clocks = <&ccu CLK_BUS_EPHY>;
resets = <&ccu RST_BUS_EPHY>;
};
};
};
And then move the internal-PHY setup code into a separate PHY driver?
That looks like the architecturally best solution to me, but is probably
also a bit involved since it would require a separate PHY driver.
Or can we make it simpler, but still use this binding?
Cheers,
Andre.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:22 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:22 UTC (permalink / raw)
To: Andre Przywara
Cc: Maxime Ripard, Corentin Labbe, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, netdev,
linux-kernel, linux-sunxi, linux-arm-kernel, Icenowy Zheng,
david.wu, Florian Fainelli, Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 6:15 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 27/06/17 10:41, Maxime Ripard wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>> allwinner.
>>>>>>>> In fact the only common part is the descriptor management and the first
>>>>>>>> register function.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I know I am a bit late with this, but while adapting the U-Boot driver
>>>>>>> to the new binding I was wondering about the internal PHY detection:
>>>>>>>
>>>>>>>
>>>>>>> So here you seem to deduce the usage of the internal PHY by the PHY
>>>>>>> interface specified in the DT (MII = internal, RGMII = external).
>>>>>>> I think I raised this question before, but isn't it perfectly legal for
>>>>>>> a board to use MII with an external PHY even on those SoCs that feature
>>>>>>> an internal PHY?
>>>>>>> On the first glance that does not make too much sense, but apart from
>>>>>>> not being the correct binding to describe all of the SoCs features I see
>>>>>>> two scenarios:
>>>>>>> 1) A board vendor might choose to not use the internal PHY because it
>>>>>>> has bugs, lacks features (configurability) or has other issues. For
>>>>>>> instance I have heard reports that the internal PHY makes the SoC go
>>>>>>> rather hot, possibly limiting the CPU frequency. By using an external
>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>>>>>>> IC or some other network circuitry, for instance fibre connectors.
>>>>>>>
>>>>>>> So I was wondering if we would need an explicit:
>>>>>>> allwinner,use-internal-phy;
>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>> Alternatively we could go with the negative version:
>>>>>>> allwinner,disable-internal-phy;
>>>>>>>
>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>>>>>>> string for the *PHY* node and use that?
>>>>>>>
>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>> headaches later. I think we can still fix this with a followup patch
>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andre.
>>>>>>>
>>>>>>
>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>> I will try to find a way to use it
>>>>>
>>>>> Can you provide a link?
>>>>
>>>> https://lkml.org/lkml/2017/6/23/479
>>>>
>>>>>
>>>>> I'm not a fan of using phy-mode for this. There's no guarantee what
>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>>> For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
>>>> So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the usage
>>> of the internal PHY would be nice, I am bit tempted to use this easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
> So something like this?
> emac: emac@1c30000 {
> compatible = "allwinner,sun8i-h3-emac";
> ...
> phy-mode = "mii";
> phy-handle = <&int_mii_phy>;
> ...
>
> mdio: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> int_mii_phy: ethernet-phy@1 {
> compatible = "allwinner,sun8i-h3-ephy";
> syscon = <&syscon>;
> reg = <1>;
> clocks = <&ccu CLK_BUS_EPHY>;
> resets = <&ccu RST_BUS_EPHY>;
> };
> };
> };
>
> And then move the internal-PHY setup code into a separate PHY driver?
>
> That looks like the architecturally best solution to me, but is probably
> also a bit involved since it would require a separate PHY driver.
> Or can we make it simpler, but still use this binding?
This was my initial approach prior to handing it off to Corentin.
The MDIO bus is discoverable, so in the kernel MDIO bus driver code, the
devices are only created if something responds. However, for the EPHY to
respond, you must first configure the clocks, reset controls, and syscon
registers. You need either a platform device driver for that, or do it
in the MAC driver. The latter made more sense at the time, looking at
how the device tree is structured.
ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:22 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:22 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 6:15 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 27/06/17 10:41, Maxime Ripard wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>> allwinner.
>>>>>>>> In fact the only common part is the descriptor management and the first
>>>>>>>> register function.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I know I am a bit late with this, but while adapting the U-Boot driver
>>>>>>> to the new binding I was wondering about the internal PHY detection:
>>>>>>>
>>>>>>>
>>>>>>> So here you seem to deduce the usage of the internal PHY by the PHY
>>>>>>> interface specified in the DT (MII = internal, RGMII = external).
>>>>>>> I think I raised this question before, but isn't it perfectly legal for
>>>>>>> a board to use MII with an external PHY even on those SoCs that feature
>>>>>>> an internal PHY?
>>>>>>> On the first glance that does not make too much sense, but apart from
>>>>>>> not being the correct binding to describe all of the SoCs features I see
>>>>>>> two scenarios:
>>>>>>> 1) A board vendor might choose to not use the internal PHY because it
>>>>>>> has bugs, lacks features (configurability) or has other issues. For
>>>>>>> instance I have heard reports that the internal PHY makes the SoC go
>>>>>>> rather hot, possibly limiting the CPU frequency. By using an external
>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>>>>>>> IC or some other network circuitry, for instance fibre connectors.
>>>>>>>
>>>>>>> So I was wondering if we would need an explicit:
>>>>>>> allwinner,use-internal-phy;
>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>> Alternatively we could go with the negative version:
>>>>>>> allwinner,disable-internal-phy;
>>>>>>>
>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>>>>>>> string for the *PHY* node and use that?
>>>>>>>
>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>> headaches later. I think we can still fix this with a followup patch
>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andre.
>>>>>>>
>>>>>>
>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>> I will try to find a way to use it
>>>>>
>>>>> Can you provide a link?
>>>>
>>>> https://lkml.org/lkml/2017/6/23/479
>>>>
>>>>>
>>>>> I'm not a fan of using phy-mode for this. There's no guarantee what
>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>>> For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
>>>> So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the usage
>>> of the internal PHY would be nice, I am bit tempted to use this easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
> So something like this?
> emac: emac at 1c30000 {
> compatible = "allwinner,sun8i-h3-emac";
> ...
> phy-mode = "mii";
> phy-handle = <&int_mii_phy>;
> ...
>
> mdio: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> int_mii_phy: ethernet-phy at 1 {
> compatible = "allwinner,sun8i-h3-ephy";
> syscon = <&syscon>;
> reg = <1>;
> clocks = <&ccu CLK_BUS_EPHY>;
> resets = <&ccu RST_BUS_EPHY>;
> };
> };
> };
>
> And then move the internal-PHY setup code into a separate PHY driver?
>
> That looks like the architecturally best solution to me, but is probably
> also a bit involved since it would require a separate PHY driver.
> Or can we make it simpler, but still use this binding?
This was my initial approach prior to handing it off to Corentin.
The MDIO bus is discoverable, so in the kernel MDIO bus driver code, the
devices are only created if something responds. However, for the EPHY to
respond, you must first configure the clocks, reset controls, and syscon
registers. You need either a platform device driver for that, or do it
in the MAC driver. The latter made more sense at the time, looking at
how the device tree is structured.
ChenYu
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:22 ` Chen-Yu Tsai
0 siblings, 0 replies; 148+ messages in thread
From: Chen-Yu Tsai @ 2017-06-27 10:22 UTC (permalink / raw)
To: Andre Przywara
Cc: Maxime Ripard, Corentin Labbe, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
Icenowy Zheng, david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli,
Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 6:15 PM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi,
>
> On 27/06/17 10:41, Maxime Ripard wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>> allwinner.
>>>>>>>> In fact the only common part is the descriptor management and the first
>>>>>>>> register function.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I know I am a bit late with this, but while adapting the U-Boot driver
>>>>>>> to the new binding I was wondering about the internal PHY detection:
>>>>>>>
>>>>>>>
>>>>>>> So here you seem to deduce the usage of the internal PHY by the PHY
>>>>>>> interface specified in the DT (MII = internal, RGMII = external).
>>>>>>> I think I raised this question before, but isn't it perfectly legal for
>>>>>>> a board to use MII with an external PHY even on those SoCs that feature
>>>>>>> an internal PHY?
>>>>>>> On the first glance that does not make too much sense, but apart from
>>>>>>> not being the correct binding to describe all of the SoCs features I see
>>>>>>> two scenarios:
>>>>>>> 1) A board vendor might choose to not use the internal PHY because it
>>>>>>> has bugs, lacks features (configurability) or has other issues. For
>>>>>>> instance I have heard reports that the internal PHY makes the SoC go
>>>>>>> rather hot, possibly limiting the CPU frequency. By using an external
>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoided.
>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a switch
>>>>>>> IC or some other network circuitry, for instance fibre connectors.
>>>>>>>
>>>>>>> So I was wondering if we would need an explicit:
>>>>>>> allwinner,use-internal-phy;
>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>> Alternatively we could go with the negative version:
>>>>>>> allwinner,disable-internal-phy;
>>>>>>>
>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy" compatible
>>>>>>> string for the *PHY* node and use that?
>>>>>>>
>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>> headaches later. I think we can still fix this with a followup patch
>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andre.
>>>>>>>
>>>>>>
>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>> I will try to find a way to use it
>>>>>
>>>>> Can you provide a link?
>>>>
>>>> https://lkml.org/lkml/2017/6/23/479
>>>>
>>>>>
>>>>> I'm not a fan of using phy-mode for this. There's no guarantee what
>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>>> For each soc the internal PHY mode is know and setted in emac_variant/internal_phy
>>>> So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the usage
>>> of the internal PHY would be nice, I am bit tempted to use this easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
> So something like this?
> emac: emac@1c30000 {
> compatible = "allwinner,sun8i-h3-emac";
> ...
> phy-mode = "mii";
> phy-handle = <&int_mii_phy>;
> ...
>
> mdio: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> int_mii_phy: ethernet-phy@1 {
> compatible = "allwinner,sun8i-h3-ephy";
> syscon = <&syscon>;
> reg = <1>;
> clocks = <&ccu CLK_BUS_EPHY>;
> resets = <&ccu RST_BUS_EPHY>;
> };
> };
> };
>
> And then move the internal-PHY setup code into a separate PHY driver?
>
> That looks like the architecturally best solution to me, but is probably
> also a bit involved since it would require a separate PHY driver.
> Or can we make it simpler, but still use this binding?
This was my initial approach prior to handing it off to Corentin.
The MDIO bus is discoverable, so in the kernel MDIO bus driver code, the
devices are only created if something responds. However, for the EPHY to
respond, you must first configure the clocks, reset controls, and syscon
registers. You need either a platform device driver for that, or do it
in the MAC driver. The latter made more sense at the time, looking at
how the device tree is structured.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:23 ` Icenowy Zheng
0 siblings, 0 replies; 148+ messages in thread
From: Icenowy Zheng @ 2017-06-27 10:23 UTC (permalink / raw)
To: Andre Przywara, Maxime Ripard
Cc: Corentin Labbe, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, netdev, linux-kernel, linux-sunxi,
linux-arm-kernel, david.wu, Florian Fainelli, Andrew Lunn,
Heiko Stübner
于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
>Hi,
>
>On 27/06/17 10:41, Maxime Ripard wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>> allwinner.
>>>>>>>> In fact the only common part is the descriptor management and
>the first
>>>>>>>> register function.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>driver
>>>>>>> to the new binding I was wondering about the internal PHY
>detection:
>>>>>>>
>>>>>>>
>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>PHY
>>>>>>> interface specified in the DT (MII = internal, RGMII =
>external).
>>>>>>> I think I raised this question before, but isn't it perfectly
>legal for
>>>>>>> a board to use MII with an external PHY even on those SoCs that
>feature
>>>>>>> an internal PHY?
>>>>>>> On the first glance that does not make too much sense, but apart
>from
>>>>>>> not being the correct binding to describe all of the SoCs
>features I see
>>>>>>> two scenarios:
>>>>>>> 1) A board vendor might choose to not use the internal PHY
>because it
>>>>>>> has bugs, lacks features (configurability) or has other issues.
>For
>>>>>>> instance I have heard reports that the internal PHY makes the
>SoC go
>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>external
>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>avoided.
>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>switch
>>>>>>> IC or some other network circuitry, for instance fibre
>connectors.
>>>>>>>
>>>>>>> So I was wondering if we would need an explicit:
>>>>>>> allwinner,use-internal-phy;
>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>> Alternatively we could go with the negative version:
>>>>>>> allwinner,disable-internal-phy;
>>>>>>>
>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>compatible
>>>>>>> string for the *PHY* node and use that?
>>>>>>>
>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>> headaches later. I think we can still fix this with a followup
>patch
>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andre.
>>>>>>>
>>>>>>
>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>> I will try to find a way to use it
>>>>>
>>>>> Can you provide a link?
>>>>
>>>> https://lkml.org/lkml/2017/6/23/479
>>>>
>>>>>
>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>what
>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>>> For each soc the internal PHY mode is know and setted in
>emac_variant/internal_phy
>>>> So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the
>usage
>>> of the internal PHY would be nice, I am bit tempted to use this
>easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
>So something like this?
> emac: emac@1c30000 {
> compatible = "allwinner,sun8i-h3-emac";
> ...
> phy-mode = "mii";
> phy-handle = <&int_mii_phy>;
> ...
>
> mdio: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> int_mii_phy: ethernet-phy@1 {
> compatible = "allwinner,sun8i-h3-ephy";
> syscon = <&syscon>;
The MAC still needs to set some bits of syscon register.
> reg = <1>;
> clocks = <&ccu CLK_BUS_EPHY>;
> resets = <&ccu RST_BUS_EPHY>;
> };
> };
> };
>
>And then move the internal-PHY setup code into a separate PHY driver?
>
>That looks like the architecturally best solution to me, but is
>probably
>also a bit involved since it would require a separate PHY driver.
>Or can we make it simpler, but still use this binding?
>
>Cheers,
>Andre.
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:23 ` Icenowy Zheng
0 siblings, 0 replies; 148+ messages in thread
From: Icenowy Zheng @ 2017-06-27 10:23 UTC (permalink / raw)
To: linux-arm-kernel
? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
>Hi,
>
>On 27/06/17 10:41, Maxime Ripard wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>> allwinner.
>>>>>>>> In fact the only common part is the descriptor management and
>the first
>>>>>>>> register function.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>driver
>>>>>>> to the new binding I was wondering about the internal PHY
>detection:
>>>>>>>
>>>>>>>
>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>PHY
>>>>>>> interface specified in the DT (MII = internal, RGMII =
>external).
>>>>>>> I think I raised this question before, but isn't it perfectly
>legal for
>>>>>>> a board to use MII with an external PHY even on those SoCs that
>feature
>>>>>>> an internal PHY?
>>>>>>> On the first glance that does not make too much sense, but apart
>from
>>>>>>> not being the correct binding to describe all of the SoCs
>features I see
>>>>>>> two scenarios:
>>>>>>> 1) A board vendor might choose to not use the internal PHY
>because it
>>>>>>> has bugs, lacks features (configurability) or has other issues.
>For
>>>>>>> instance I have heard reports that the internal PHY makes the
>SoC go
>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>external
>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>avoided.
>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>switch
>>>>>>> IC or some other network circuitry, for instance fibre
>connectors.
>>>>>>>
>>>>>>> So I was wondering if we would need an explicit:
>>>>>>> allwinner,use-internal-phy;
>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>> Alternatively we could go with the negative version:
>>>>>>> allwinner,disable-internal-phy;
>>>>>>>
>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>compatible
>>>>>>> string for the *PHY* node and use that?
>>>>>>>
>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>> headaches later. I think we can still fix this with a followup
>patch
>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andre.
>>>>>>>
>>>>>>
>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>> I will try to find a way to use it
>>>>>
>>>>> Can you provide a link?
>>>>
>>>> https://lkml.org/lkml/2017/6/23/479
>>>>
>>>>>
>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>what
>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>>> For each soc the internal PHY mode is know and setted in
>emac_variant/internal_phy
>>>> So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the
>usage
>>> of the internal PHY would be nice, I am bit tempted to use this
>easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
>So something like this?
> emac: emac at 1c30000 {
> compatible = "allwinner,sun8i-h3-emac";
> ...
> phy-mode = "mii";
> phy-handle = <&int_mii_phy>;
> ...
>
> mdio: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> int_mii_phy: ethernet-phy at 1 {
> compatible = "allwinner,sun8i-h3-ephy";
> syscon = <&syscon>;
The MAC still needs to set some bits of syscon register.
> reg = <1>;
> clocks = <&ccu CLK_BUS_EPHY>;
> resets = <&ccu RST_BUS_EPHY>;
> };
> };
> };
>
>And then move the internal-PHY setup code into a separate PHY driver?
>
>That looks like the architecturally best solution to me, but is
>probably
>also a bit involved since it would require a separate PHY driver.
>Or can we make it simpler, but still use this binding?
>
>Cheers,
>Andre.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:23 ` Icenowy Zheng
0 siblings, 0 replies; 148+ messages in thread
From: Icenowy Zheng @ 2017-06-27 10:23 UTC (permalink / raw)
To: Andre Przywara, Maxime Ripard
Cc: Corentin Labbe, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, netdev, linux-kernel,
linux-sunxi, linux-arm-kernel, david.wu-TNX95d0MmH7DzftRWevZcw,
Florian Fainelli, Andrew Lunn, Heiko Stübner
于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>Hi,
>
>On 27/06/17 10:41, Maxime Ripard wrote:
>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> (CC:ing some people from that Rockchip dmwac series)
>>>
>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>> allwinner.
>>>>>>>> In fact the only common part is the descriptor management and
>the first
>>>>>>>> register function.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>driver
>>>>>>> to the new binding I was wondering about the internal PHY
>detection:
>>>>>>>
>>>>>>>
>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>PHY
>>>>>>> interface specified in the DT (MII = internal, RGMII =
>external).
>>>>>>> I think I raised this question before, but isn't it perfectly
>legal for
>>>>>>> a board to use MII with an external PHY even on those SoCs that
>feature
>>>>>>> an internal PHY?
>>>>>>> On the first glance that does not make too much sense, but apart
>from
>>>>>>> not being the correct binding to describe all of the SoCs
>features I see
>>>>>>> two scenarios:
>>>>>>> 1) A board vendor might choose to not use the internal PHY
>because it
>>>>>>> has bugs, lacks features (configurability) or has other issues.
>For
>>>>>>> instance I have heard reports that the internal PHY makes the
>SoC go
>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>external
>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>avoided.
>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>switch
>>>>>>> IC or some other network circuitry, for instance fibre
>connectors.
>>>>>>>
>>>>>>> So I was wondering if we would need an explicit:
>>>>>>> allwinner,use-internal-phy;
>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>> Alternatively we could go with the negative version:
>>>>>>> allwinner,disable-internal-phy;
>>>>>>>
>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>compatible
>>>>>>> string for the *PHY* node and use that?
>>>>>>>
>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>> headaches later. I think we can still fix this with a followup
>patch
>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andre.
>>>>>>>
>>>>>>
>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>> I will try to find a way to use it
>>>>>
>>>>> Can you provide a link?
>>>>
>>>> https://lkml.org/lkml/2017/6/23/479
>>>>
>>>>>
>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>what
>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>
>>> I can understand Chen-Yu's concerns, but ...
>>>
>>>> For each soc the internal PHY mode is know and setted in
>emac_variant/internal_phy
>>>> So its not a problem.
>>>
>>> that is true as well, at least for now.
>>>
>>> So while I agree that having a separate property to indicate the
>usage
>>> of the internal PHY would be nice, I am bit tempted to use this
>easier
>>> approach and piggy back on the existing phy-mode property.
>>
>> We're trying to fix an issue that works for now too.
>>
>> If we want to consider future weird cases, then we must consider all
>> of them. And the phy mode changing is definitely not really far
>> fetched.
>>
>> I agree with Chen-Yu, and I really feel like the compatible solution
>> you suggested would cover both your concerns, and ours.
>
>So something like this?
> emac: emac@1c30000 {
> compatible = "allwinner,sun8i-h3-emac";
> ...
> phy-mode = "mii";
> phy-handle = <&int_mii_phy>;
> ...
>
> mdio: mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> int_mii_phy: ethernet-phy@1 {
> compatible = "allwinner,sun8i-h3-ephy";
> syscon = <&syscon>;
The MAC still needs to set some bits of syscon register.
> reg = <1>;
> clocks = <&ccu CLK_BUS_EPHY>;
> resets = <&ccu RST_BUS_EPHY>;
> };
> };
> };
>
>And then move the internal-PHY setup code into a separate PHY driver?
>
>That looks like the architecturally best solution to me, but is
>probably
>also a bit involved since it would require a separate PHY driver.
>Or can we make it simpler, but still use this binding?
>
>Cheers,
>Andre.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-06-27 10:23 ` Icenowy Zheng
@ 2017-06-27 10:33 ` Andre Przywara
-1 siblings, 0 replies; 148+ messages in thread
From: Andre Przywara @ 2017-06-27 10:33 UTC (permalink / raw)
To: Icenowy Zheng, Maxime Ripard
Cc: Corentin Labbe, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, netdev, linux-kernel, linux-sunxi,
linux-arm-kernel, david.wu, Florian Fainelli, Andrew Lunn,
Heiko Stübner
Hi,
On 27/06/17 11:23, Icenowy Zheng wrote:
>
>
> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
>> Hi,
>>
>> On 27/06/17 10:41, Maxime Ripard wrote:
>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>> Hi,
>>>>
>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>
>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>>> allwinner.
>>>>>>>>> In fact the only common part is the descriptor management and
>> the first
>>>>>>>>> register function.
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>> driver
>>>>>>>> to the new binding I was wondering about the internal PHY
>> detection:
>>>>>>>>
>>>>>>>>
>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>> PHY
>>>>>>>> interface specified in the DT (MII = internal, RGMII =
>> external).
>>>>>>>> I think I raised this question before, but isn't it perfectly
>> legal for
>>>>>>>> a board to use MII with an external PHY even on those SoCs that
>> feature
>>>>>>>> an internal PHY?
>>>>>>>> On the first glance that does not make too much sense, but apart
>> from
>>>>>>>> not being the correct binding to describe all of the SoCs
>> features I see
>>>>>>>> two scenarios:
>>>>>>>> 1) A board vendor might choose to not use the internal PHY
>> because it
>>>>>>>> has bugs, lacks features (configurability) or has other issues.
>> For
>>>>>>>> instance I have heard reports that the internal PHY makes the
>> SoC go
>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>> external
>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>> avoided.
>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>> switch
>>>>>>>> IC or some other network circuitry, for instance fibre
>> connectors.
>>>>>>>>
>>>>>>>> So I was wondering if we would need an explicit:
>>>>>>>> allwinner,use-internal-phy;
>>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>>> Alternatively we could go with the negative version:
>>>>>>>> allwinner,disable-internal-phy;
>>>>>>>>
>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>> compatible
>>>>>>>> string for the *PHY* node and use that?
>>>>>>>>
>>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>>> headaches later. I think we can still fix this with a followup
>> patch
>>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Andre.
>>>>>>>>
>>>>>>>
>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>>> I will try to find a way to use it
>>>>>>
>>>>>> Can you provide a link?
>>>>>
>>>>> https://lkml.org/lkml/2017/6/23/479
>>>>>
>>>>>>
>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>> what
>>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>>
>>>> I can understand Chen-Yu's concerns, but ...
>>>>
>>>>> For each soc the internal PHY mode is know and setted in
>> emac_variant/internal_phy
>>>>> So its not a problem.
>>>>
>>>> that is true as well, at least for now.
>>>>
>>>> So while I agree that having a separate property to indicate the
>> usage
>>>> of the internal PHY would be nice, I am bit tempted to use this
>> easier
>>>> approach and piggy back on the existing phy-mode property.
>>>
>>> We're trying to fix an issue that works for now too.
>>>
>>> If we want to consider future weird cases, then we must consider all
>>> of them. And the phy mode changing is definitely not really far
>>> fetched.
>>>
>>> I agree with Chen-Yu, and I really feel like the compatible solution
>>> you suggested would cover both your concerns, and ours.
>>
>> So something like this?
>> emac: emac@1c30000 {
>> compatible = "allwinner,sun8i-h3-emac";
>> ...
>> phy-mode = "mii";
>> phy-handle = <&int_mii_phy>;
>> ...
>>
>> mdio: mdio {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> int_mii_phy: ethernet-phy@1 {
>> compatible = "allwinner,sun8i-h3-ephy";
>> syscon = <&syscon>;
>
> The MAC still needs to set some bits of syscon register.
Yes, the syscon property needs also to be in the MAC node, that was
meant to be somewhere in the second "..." ;-)
But now since Chen-Yu mentioned that we need to set up the PHY *first*
to make it actually discoverable via MDIO, I wonder if we could change
this to:
1) have the DT as described here
2) Let the dwmac-sun8i driver peek into the node referenced by
phy-handle and check the compatible string there.
3) If that matches some allwinner internal PHY name, it sets up the PHY
to make it respond when the MDIO driver queries its bus.
Or can a PHY driver set itself up (since we have clocks and resets
properties in there) *before* the MDIO bus gets scanned?
Chen-Yu's comment in the other mail hints at that this is not easily
possible.
Cheers,
Andre.
>
>> reg = <1>;
>> clocks = <&ccu CLK_BUS_EPHY>;
>> resets = <&ccu RST_BUS_EPHY>;
>> };
>> };
>> };
>>
>> And then move the internal-PHY setup code into a separate PHY driver?
>>
>> That looks like the architecturally best solution to me, but is
>> probably
>> also a bit involved since it would require a separate PHY driver.
>> Or can we make it simpler, but still use this binding?
>>
>> Cheers,
>> Andre.
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 10:33 ` Andre Przywara
0 siblings, 0 replies; 148+ messages in thread
From: Andre Przywara @ 2017-06-27 10:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 27/06/17 11:23, Icenowy Zheng wrote:
>
>
> ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
>> Hi,
>>
>> On 27/06/17 10:41, Maxime Ripard wrote:
>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>> Hi,
>>>>
>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>
>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>>> allwinner.
>>>>>>>>> In fact the only common part is the descriptor management and
>> the first
>>>>>>>>> register function.
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>> driver
>>>>>>>> to the new binding I was wondering about the internal PHY
>> detection:
>>>>>>>>
>>>>>>>>
>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>> PHY
>>>>>>>> interface specified in the DT (MII = internal, RGMII =
>> external).
>>>>>>>> I think I raised this question before, but isn't it perfectly
>> legal for
>>>>>>>> a board to use MII with an external PHY even on those SoCs that
>> feature
>>>>>>>> an internal PHY?
>>>>>>>> On the first glance that does not make too much sense, but apart
>> from
>>>>>>>> not being the correct binding to describe all of the SoCs
>> features I see
>>>>>>>> two scenarios:
>>>>>>>> 1) A board vendor might choose to not use the internal PHY
>> because it
>>>>>>>> has bugs, lacks features (configurability) or has other issues.
>> For
>>>>>>>> instance I have heard reports that the internal PHY makes the
>> SoC go
>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>> external
>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>> avoided.
>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>> switch
>>>>>>>> IC or some other network circuitry, for instance fibre
>> connectors.
>>>>>>>>
>>>>>>>> So I was wondering if we would need an explicit:
>>>>>>>> allwinner,use-internal-phy;
>>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>>> Alternatively we could go with the negative version:
>>>>>>>> allwinner,disable-internal-phy;
>>>>>>>>
>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>> compatible
>>>>>>>> string for the *PHY* node and use that?
>>>>>>>>
>>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>>> headaches later. I think we can still fix this with a followup
>> patch
>>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Andre.
>>>>>>>>
>>>>>>>
>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>>> I will try to find a way to use it
>>>>>>
>>>>>> Can you provide a link?
>>>>>
>>>>> https://lkml.org/lkml/2017/6/23/479
>>>>>
>>>>>>
>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>> what
>>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>>
>>>> I can understand Chen-Yu's concerns, but ...
>>>>
>>>>> For each soc the internal PHY mode is know and setted in
>> emac_variant/internal_phy
>>>>> So its not a problem.
>>>>
>>>> that is true as well, at least for now.
>>>>
>>>> So while I agree that having a separate property to indicate the
>> usage
>>>> of the internal PHY would be nice, I am bit tempted to use this
>> easier
>>>> approach and piggy back on the existing phy-mode property.
>>>
>>> We're trying to fix an issue that works for now too.
>>>
>>> If we want to consider future weird cases, then we must consider all
>>> of them. And the phy mode changing is definitely not really far
>>> fetched.
>>>
>>> I agree with Chen-Yu, and I really feel like the compatible solution
>>> you suggested would cover both your concerns, and ours.
>>
>> So something like this?
>> emac: emac at 1c30000 {
>> compatible = "allwinner,sun8i-h3-emac";
>> ...
>> phy-mode = "mii";
>> phy-handle = <&int_mii_phy>;
>> ...
>>
>> mdio: mdio {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> int_mii_phy: ethernet-phy at 1 {
>> compatible = "allwinner,sun8i-h3-ephy";
>> syscon = <&syscon>;
>
> The MAC still needs to set some bits of syscon register.
Yes, the syscon property needs also to be in the MAC node, that was
meant to be somewhere in the second "..." ;-)
But now since Chen-Yu mentioned that we need to set up the PHY *first*
to make it actually discoverable via MDIO, I wonder if we could change
this to:
1) have the DT as described here
2) Let the dwmac-sun8i driver peek into the node referenced by
phy-handle and check the compatible string there.
3) If that matches some allwinner internal PHY name, it sets up the PHY
to make it respond when the MDIO driver queries its bus.
Or can a PHY driver set itself up (since we have clocks and resets
properties in there) *before* the MDIO bus gets scanned?
Chen-Yu's comment in the other mail hints at that this is not easily
possible.
Cheers,
Andre.
>
>> reg = <1>;
>> clocks = <&ccu CLK_BUS_EPHY>;
>> resets = <&ccu RST_BUS_EPHY>;
>> };
>> };
>> };
>>
>> And then move the internal-PHY setup code into a separate PHY driver?
>>
>> That looks like the architecturally best solution to me, but is
>> probably
>> also a bit involved since it would require a separate PHY driver.
>> Or can we make it simpler, but still use this binding?
>>
>> Cheers,
>> Andre.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 12:37 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 12:37 UTC (permalink / raw)
To: Andre Przywara
Cc: Icenowy Zheng, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, netdev,
linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Florian Fainelli, Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> Hi,
>
> On 27/06/17 11:23, Icenowy Zheng wrote:
> >
> >
> > 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
> >> Hi,
> >>
> >> On 27/06/17 10:41, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>> Hi,
> >>>>
> >>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>
> >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>> <clabbe.montjoie@gmail.com> wrote:
> >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>> allwinner.
> >>>>>>>>> In fact the only common part is the descriptor management and
> >> the first
> >>>>>>>>> register function.
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >> driver
> >>>>>>>> to the new binding I was wondering about the internal PHY
> >> detection:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >> PHY
> >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >> external).
> >>>>>>>> I think I raised this question before, but isn't it perfectly
> >> legal for
> >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >> feature
> >>>>>>>> an internal PHY?
> >>>>>>>> On the first glance that does not make too much sense, but apart
> >> from
> >>>>>>>> not being the correct binding to describe all of the SoCs
> >> features I see
> >>>>>>>> two scenarios:
> >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >> because it
> >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >> For
> >>>>>>>> instance I have heard reports that the internal PHY makes the
> >> SoC go
> >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >> external
> >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >> avoided.
> >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >> switch
> >>>>>>>> IC or some other network circuitry, for instance fibre
> >> connectors.
> >>>>>>>>
> >>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>> allwinner,use-internal-phy;
> >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>
> >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >> compatible
> >>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>
> >>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>> headaches later. I think we can still fix this with a followup
> >> patch
> >>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Andre.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>> I will try to find a way to use it
> >>>>>>
> >>>>>> Can you provide a link?
> >>>>>
> >>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>
> >>>>>>
> >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >> what
> >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>
> >>>> I can understand Chen-Yu's concerns, but ...
> >>>>
> >>>>> For each soc the internal PHY mode is know and setted in
> >> emac_variant/internal_phy
> >>>>> So its not a problem.
> >>>>
> >>>> that is true as well, at least for now.
> >>>>
> >>>> So while I agree that having a separate property to indicate the
> >> usage
> >>>> of the internal PHY would be nice, I am bit tempted to use this
> >> easier
> >>>> approach and piggy back on the existing phy-mode property.
> >>>
> >>> We're trying to fix an issue that works for now too.
> >>>
> >>> If we want to consider future weird cases, then we must consider all
> >>> of them. And the phy mode changing is definitely not really far
> >>> fetched.
> >>>
> >>> I agree with Chen-Yu, and I really feel like the compatible solution
> >>> you suggested would cover both your concerns, and ours.
> >>
> >> So something like this?
> >> emac: emac@1c30000 {
> >> compatible = "allwinner,sun8i-h3-emac";
> >> ...
> >> phy-mode = "mii";
> >> phy-handle = <&int_mii_phy>;
> >> ...
> >>
> >> mdio: mdio {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> int_mii_phy: ethernet-phy@1 {
> >> compatible = "allwinner,sun8i-h3-ephy";
> >> syscon = <&syscon>;
> >
> > The MAC still needs to set some bits of syscon register.
>
> Yes, the syscon property needs also to be in the MAC node, that was
> meant to be somewhere in the second "..." ;-)
>
> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> to make it actually discoverable via MDIO, I wonder if we could change
> this to:
> 1) have the DT as described here
> 2) Let the dwmac-sun8i driver peek into the node referenced by
> phy-handle and check the compatible string there.
> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> to make it respond when the MDIO driver queries its bus.
>
> Or can a PHY driver set itself up (since we have clocks and resets
> properties in there) *before* the MDIO bus gets scanned?
> Chen-Yu's comment in the other mail hints at that this is not easily
> possible.
>
> Cheers,
> Andre.
>
I think adding phy compatible just make things more complex.
I think the patch series I sent early fix all problems without more complexity since:
- it does not add more DT stuff
- it use an already used in tree DT phy-mode "internal" (and so phy mode PHY_INTERFACE_MODE_INTERNAL)
Regards
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 12:37 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 12:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> Hi,
>
> On 27/06/17 11:23, Icenowy Zheng wrote:
> >
> >
> > ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
> >> Hi,
> >>
> >> On 27/06/17 10:41, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>> Hi,
> >>>>
> >>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>
> >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>> <clabbe.montjoie@gmail.com> wrote:
> >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>> allwinner.
> >>>>>>>>> In fact the only common part is the descriptor management and
> >> the first
> >>>>>>>>> register function.
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >> driver
> >>>>>>>> to the new binding I was wondering about the internal PHY
> >> detection:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >> PHY
> >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >> external).
> >>>>>>>> I think I raised this question before, but isn't it perfectly
> >> legal for
> >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >> feature
> >>>>>>>> an internal PHY?
> >>>>>>>> On the first glance that does not make too much sense, but apart
> >> from
> >>>>>>>> not being the correct binding to describe all of the SoCs
> >> features I see
> >>>>>>>> two scenarios:
> >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >> because it
> >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >> For
> >>>>>>>> instance I have heard reports that the internal PHY makes the
> >> SoC go
> >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >> external
> >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >> avoided.
> >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >> switch
> >>>>>>>> IC or some other network circuitry, for instance fibre
> >> connectors.
> >>>>>>>>
> >>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>> allwinner,use-internal-phy;
> >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>
> >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >> compatible
> >>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>
> >>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>> headaches later. I think we can still fix this with a followup
> >> patch
> >>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Andre.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>> I will try to find a way to use it
> >>>>>>
> >>>>>> Can you provide a link?
> >>>>>
> >>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>
> >>>>>>
> >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >> what
> >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>
> >>>> I can understand Chen-Yu's concerns, but ...
> >>>>
> >>>>> For each soc the internal PHY mode is know and setted in
> >> emac_variant/internal_phy
> >>>>> So its not a problem.
> >>>>
> >>>> that is true as well, at least for now.
> >>>>
> >>>> So while I agree that having a separate property to indicate the
> >> usage
> >>>> of the internal PHY would be nice, I am bit tempted to use this
> >> easier
> >>>> approach and piggy back on the existing phy-mode property.
> >>>
> >>> We're trying to fix an issue that works for now too.
> >>>
> >>> If we want to consider future weird cases, then we must consider all
> >>> of them. And the phy mode changing is definitely not really far
> >>> fetched.
> >>>
> >>> I agree with Chen-Yu, and I really feel like the compatible solution
> >>> you suggested would cover both your concerns, and ours.
> >>
> >> So something like this?
> >> emac: emac at 1c30000 {
> >> compatible = "allwinner,sun8i-h3-emac";
> >> ...
> >> phy-mode = "mii";
> >> phy-handle = <&int_mii_phy>;
> >> ...
> >>
> >> mdio: mdio {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> int_mii_phy: ethernet-phy at 1 {
> >> compatible = "allwinner,sun8i-h3-ephy";
> >> syscon = <&syscon>;
> >
> > The MAC still needs to set some bits of syscon register.
>
> Yes, the syscon property needs also to be in the MAC node, that was
> meant to be somewhere in the second "..." ;-)
>
> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> to make it actually discoverable via MDIO, I wonder if we could change
> this to:
> 1) have the DT as described here
> 2) Let the dwmac-sun8i driver peek into the node referenced by
> phy-handle and check the compatible string there.
> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> to make it respond when the MDIO driver queries its bus.
>
> Or can a PHY driver set itself up (since we have clocks and resets
> properties in there) *before* the MDIO bus gets scanned?
> Chen-Yu's comment in the other mail hints at that this is not easily
> possible.
>
> Cheers,
> Andre.
>
I think adding phy compatible just make things more complex.
I think the patch series I sent early fix all problems without more complexity since:
- it does not add more DT stuff
- it use an already used in tree DT phy-mode "internal" (and so phy mode PHY_INTERFACE_MODE_INTERNAL)
Regards
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 12:37 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 12:37 UTC (permalink / raw)
To: Andre Przywara
Cc: Icenowy Zheng, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli, Andrew Lunn,
Heiko Stübner
On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> Hi,
>
> On 27/06/17 11:23, Icenowy Zheng wrote:
> >
> >
> > 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> >> Hi,
> >>
> >> On 27/06/17 10:41, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>> Hi,
> >>>>
> >>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>
> >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>> allwinner.
> >>>>>>>>> In fact the only common part is the descriptor management and
> >> the first
> >>>>>>>>> register function.
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >> driver
> >>>>>>>> to the new binding I was wondering about the internal PHY
> >> detection:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >> PHY
> >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >> external).
> >>>>>>>> I think I raised this question before, but isn't it perfectly
> >> legal for
> >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >> feature
> >>>>>>>> an internal PHY?
> >>>>>>>> On the first glance that does not make too much sense, but apart
> >> from
> >>>>>>>> not being the correct binding to describe all of the SoCs
> >> features I see
> >>>>>>>> two scenarios:
> >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >> because it
> >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >> For
> >>>>>>>> instance I have heard reports that the internal PHY makes the
> >> SoC go
> >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >> external
> >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >> avoided.
> >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >> switch
> >>>>>>>> IC or some other network circuitry, for instance fibre
> >> connectors.
> >>>>>>>>
> >>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>> allwinner,use-internal-phy;
> >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>
> >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >> compatible
> >>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>
> >>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>> headaches later. I think we can still fix this with a followup
> >> patch
> >>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Andre.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>> I will try to find a way to use it
> >>>>>>
> >>>>>> Can you provide a link?
> >>>>>
> >>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>
> >>>>>>
> >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >> what
> >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>
> >>>> I can understand Chen-Yu's concerns, but ...
> >>>>
> >>>>> For each soc the internal PHY mode is know and setted in
> >> emac_variant/internal_phy
> >>>>> So its not a problem.
> >>>>
> >>>> that is true as well, at least for now.
> >>>>
> >>>> So while I agree that having a separate property to indicate the
> >> usage
> >>>> of the internal PHY would be nice, I am bit tempted to use this
> >> easier
> >>>> approach and piggy back on the existing phy-mode property.
> >>>
> >>> We're trying to fix an issue that works for now too.
> >>>
> >>> If we want to consider future weird cases, then we must consider all
> >>> of them. And the phy mode changing is definitely not really far
> >>> fetched.
> >>>
> >>> I agree with Chen-Yu, and I really feel like the compatible solution
> >>> you suggested would cover both your concerns, and ours.
> >>
> >> So something like this?
> >> emac: emac@1c30000 {
> >> compatible = "allwinner,sun8i-h3-emac";
> >> ...
> >> phy-mode = "mii";
> >> phy-handle = <&int_mii_phy>;
> >> ...
> >>
> >> mdio: mdio {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> int_mii_phy: ethernet-phy@1 {
> >> compatible = "allwinner,sun8i-h3-ephy";
> >> syscon = <&syscon>;
> >
> > The MAC still needs to set some bits of syscon register.
>
> Yes, the syscon property needs also to be in the MAC node, that was
> meant to be somewhere in the second "..." ;-)
>
> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> to make it actually discoverable via MDIO, I wonder if we could change
> this to:
> 1) have the DT as described here
> 2) Let the dwmac-sun8i driver peek into the node referenced by
> phy-handle and check the compatible string there.
> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> to make it respond when the MDIO driver queries its bus.
>
> Or can a PHY driver set itself up (since we have clocks and resets
> properties in there) *before* the MDIO bus gets scanned?
> Chen-Yu's comment in the other mail hints at that this is not easily
> possible.
>
> Cheers,
> Andre.
>
I think adding phy compatible just make things more complex.
I think the patch series I sent early fix all problems without more complexity since:
- it does not add more DT stuff
- it use an already used in tree DT phy-mode "internal" (and so phy mode PHY_INTERFACE_MODE_INTERNAL)
Regards
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-06-27 12:37 ` Corentin Labbe
(?)
@ 2017-06-27 17:29 ` Maxime Ripard
-1 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 17:29 UTC (permalink / raw)
To: Corentin Labbe
Cc: Andre Przywara, Icenowy Zheng, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, netdev,
linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Florian Fainelli, Andrew Lunn, Heiko Stübner
[-- Attachment #1: Type: text/plain, Size: 6849 bytes --]
On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> > Hi,
> >
> > On 27/06/17 11:23, Icenowy Zheng wrote:
> > >
> > >
> > > 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
> > >> Hi,
> > >>
> > >> On 27/06/17 10:41, Maxime Ripard wrote:
> > >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> > >>>> Hi,
> > >>>>
> > >>>> (CC:ing some people from that Rockchip dmwac series)
> > >>>>
> > >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> > >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> > >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> > >>>>>> <clabbe.montjoie@gmail.com> wrote:
> > >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> > >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> > >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > >>>>>>>>> allwinner.
> > >>>>>>>>> In fact the only common part is the descriptor management and
> > >> the first
> > >>>>>>>>> register function.
> > >>>>>>>>
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> > >> driver
> > >>>>>>>> to the new binding I was wondering about the internal PHY
> > >> detection:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> > >> PHY
> > >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> > >> external).
> > >>>>>>>> I think I raised this question before, but isn't it perfectly
> > >> legal for
> > >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> > >> feature
> > >>>>>>>> an internal PHY?
> > >>>>>>>> On the first glance that does not make too much sense, but apart
> > >> from
> > >>>>>>>> not being the correct binding to describe all of the SoCs
> > >> features I see
> > >>>>>>>> two scenarios:
> > >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> > >> because it
> > >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> > >> For
> > >>>>>>>> instance I have heard reports that the internal PHY makes the
> > >> SoC go
> > >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> > >> external
> > >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> > >> avoided.
> > >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> > >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> > >> switch
> > >>>>>>>> IC or some other network circuitry, for instance fibre
> > >> connectors.
> > >>>>>>>>
> > >>>>>>>> So I was wondering if we would need an explicit:
> > >>>>>>>> allwinner,use-internal-phy;
> > >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> > >>>>>>>> Alternatively we could go with the negative version:
> > >>>>>>>> allwinner,disable-internal-phy;
> > >>>>>>>>
> > >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> > >> compatible
> > >>>>>>>> string for the *PHY* node and use that?
> > >>>>>>>>
> > >>>>>>>> I just want to avoid that we introduce a binding that causes us
> > >>>>>>>> headaches later. I think we can still fix this with a followup
> > >> patch
> > >>>>>>>> before the driver and its binding hit a release kernel.
> > >>>>>>>>
> > >>>>>>>> Cheers,
> > >>>>>>>> Andre.
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> > >>>>>>> I will try to find a way to use it
> > >>>>>>
> > >>>>>> Can you provide a link?
> > >>>>>
> > >>>>> https://lkml.org/lkml/2017/6/23/479
> > >>>>>
> > >>>>>>
> > >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> > >> what
> > >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> > >>>>
> > >>>> I can understand Chen-Yu's concerns, but ...
> > >>>>
> > >>>>> For each soc the internal PHY mode is know and setted in
> > >> emac_variant/internal_phy
> > >>>>> So its not a problem.
> > >>>>
> > >>>> that is true as well, at least for now.
> > >>>>
> > >>>> So while I agree that having a separate property to indicate
> > >>>> the usage of the internal PHY would be nice, I am bit tempted
> > >>>> to use this easier approach and piggy back on the existing
> > >>>> phy-mode property.
> > >>>
> > >>> We're trying to fix an issue that works for now too.
> > >>>
> > >>> If we want to consider future weird cases, then we must
> > >>> consider all of them. And the phy mode changing is definitely
> > >>> not really far fetched.
> > >>>
> > >>> I agree with Chen-Yu, and I really feel like the compatible
> > >>> solution you suggested would cover both your concerns, and
> > >>> ours.
> > >>
> > >> So something like this?
> > >> emac: emac@1c30000 {
> > >> compatible = "allwinner,sun8i-h3-emac";
> > >> ...
> > >> phy-mode = "mii";
> > >> phy-handle = <&int_mii_phy>;
> > >> ...
> > >>
> > >> mdio: mdio {
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >> int_mii_phy: ethernet-phy@1 {
> > >> compatible = "allwinner,sun8i-h3-ephy";
> > >> syscon = <&syscon>;
> > >
> > > The MAC still needs to set some bits of syscon register.
> >
> > Yes, the syscon property needs also to be in the MAC node, that
> > was meant to be somewhere in the second "..." ;-)
> >
> > But now since Chen-Yu mentioned that we need to set up the PHY *first*
> > to make it actually discoverable via MDIO, I wonder if we could change
> > this to:
> > 1) have the DT as described here
> > 2) Let the dwmac-sun8i driver peek into the node referenced by
> > phy-handle and check the compatible string there.
> > 3) If that matches some allwinner internal PHY name, it sets up the PHY
> > to make it respond when the MDIO driver queries its bus.
> >
> > Or can a PHY driver set itself up (since we have clocks and resets
> > properties in there) *before* the MDIO bus gets scanned?
> > Chen-Yu's comment in the other mail hints at that this is not easily
> > possible.
>
> I think adding phy compatible just make things more complex.
>
> I think the patch series I sent early fix all problems without more
> complexity since:
>
> - it does not add more DT stuff
> - it use an already used in tree DT phy-mode "internal" (and so phy
> mode PHY_INTERFACE_MODE_INTERNAL)
- it doesn't cover all the concerns we had
- it uses an undocumented value, with an unclear implication
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 17:29 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 17:29 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> > Hi,
> >
> > On 27/06/17 11:23, Icenowy Zheng wrote:
> > >
> > >
> > > ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
> > >> Hi,
> > >>
> > >> On 27/06/17 10:41, Maxime Ripard wrote:
> > >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> > >>>> Hi,
> > >>>>
> > >>>> (CC:ing some people from that Rockchip dmwac series)
> > >>>>
> > >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> > >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> > >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> > >>>>>> <clabbe.montjoie@gmail.com> wrote:
> > >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> > >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> > >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > >>>>>>>>> allwinner.
> > >>>>>>>>> In fact the only common part is the descriptor management and
> > >> the first
> > >>>>>>>>> register function.
> > >>>>>>>>
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> > >> driver
> > >>>>>>>> to the new binding I was wondering about the internal PHY
> > >> detection:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> > >> PHY
> > >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> > >> external).
> > >>>>>>>> I think I raised this question before, but isn't it perfectly
> > >> legal for
> > >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> > >> feature
> > >>>>>>>> an internal PHY?
> > >>>>>>>> On the first glance that does not make too much sense, but apart
> > >> from
> > >>>>>>>> not being the correct binding to describe all of the SoCs
> > >> features I see
> > >>>>>>>> two scenarios:
> > >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> > >> because it
> > >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> > >> For
> > >>>>>>>> instance I have heard reports that the internal PHY makes the
> > >> SoC go
> > >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> > >> external
> > >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> > >> avoided.
> > >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> > >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> > >> switch
> > >>>>>>>> IC or some other network circuitry, for instance fibre
> > >> connectors.
> > >>>>>>>>
> > >>>>>>>> So I was wondering if we would need an explicit:
> > >>>>>>>> allwinner,use-internal-phy;
> > >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> > >>>>>>>> Alternatively we could go with the negative version:
> > >>>>>>>> allwinner,disable-internal-phy;
> > >>>>>>>>
> > >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> > >> compatible
> > >>>>>>>> string for the *PHY* node and use that?
> > >>>>>>>>
> > >>>>>>>> I just want to avoid that we introduce a binding that causes us
> > >>>>>>>> headaches later. I think we can still fix this with a followup
> > >> patch
> > >>>>>>>> before the driver and its binding hit a release kernel.
> > >>>>>>>>
> > >>>>>>>> Cheers,
> > >>>>>>>> Andre.
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> > >>>>>>> I will try to find a way to use it
> > >>>>>>
> > >>>>>> Can you provide a link?
> > >>>>>
> > >>>>> https://lkml.org/lkml/2017/6/23/479
> > >>>>>
> > >>>>>>
> > >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> > >> what
> > >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> > >>>>
> > >>>> I can understand Chen-Yu's concerns, but ...
> > >>>>
> > >>>>> For each soc the internal PHY mode is know and setted in
> > >> emac_variant/internal_phy
> > >>>>> So its not a problem.
> > >>>>
> > >>>> that is true as well, at least for now.
> > >>>>
> > >>>> So while I agree that having a separate property to indicate
> > >>>> the usage of the internal PHY would be nice, I am bit tempted
> > >>>> to use this easier approach and piggy back on the existing
> > >>>> phy-mode property.
> > >>>
> > >>> We're trying to fix an issue that works for now too.
> > >>>
> > >>> If we want to consider future weird cases, then we must
> > >>> consider all of them. And the phy mode changing is definitely
> > >>> not really far fetched.
> > >>>
> > >>> I agree with Chen-Yu, and I really feel like the compatible
> > >>> solution you suggested would cover both your concerns, and
> > >>> ours.
> > >>
> > >> So something like this?
> > >> emac: emac at 1c30000 {
> > >> compatible = "allwinner,sun8i-h3-emac";
> > >> ...
> > >> phy-mode = "mii";
> > >> phy-handle = <&int_mii_phy>;
> > >> ...
> > >>
> > >> mdio: mdio {
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >> int_mii_phy: ethernet-phy at 1 {
> > >> compatible = "allwinner,sun8i-h3-ephy";
> > >> syscon = <&syscon>;
> > >
> > > The MAC still needs to set some bits of syscon register.
> >
> > Yes, the syscon property needs also to be in the MAC node, that
> > was meant to be somewhere in the second "..." ;-)
> >
> > But now since Chen-Yu mentioned that we need to set up the PHY *first*
> > to make it actually discoverable via MDIO, I wonder if we could change
> > this to:
> > 1) have the DT as described here
> > 2) Let the dwmac-sun8i driver peek into the node referenced by
> > phy-handle and check the compatible string there.
> > 3) If that matches some allwinner internal PHY name, it sets up the PHY
> > to make it respond when the MDIO driver queries its bus.
> >
> > Or can a PHY driver set itself up (since we have clocks and resets
> > properties in there) *before* the MDIO bus gets scanned?
> > Chen-Yu's comment in the other mail hints at that this is not easily
> > possible.
>
> I think adding phy compatible just make things more complex.
>
> I think the patch series I sent early fix all problems without more
> complexity since:
>
> - it does not add more DT stuff
> - it use an already used in tree DT phy-mode "internal" (and so phy
> mode PHY_INTERFACE_MODE_INTERNAL)
- it doesn't cover all the concerns we had
- it uses an undocumented value, with an unclear implication
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170627/1c0a5ddb/attachment.sig>
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 17:29 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 17:29 UTC (permalink / raw)
To: Corentin Labbe
Cc: Andre Przywara, Icenowy Zheng, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli, Andrew Lunn,
Heiko Stübner
[-- Attachment #1: Type: text/plain, Size: 7222 bytes --]
On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> > Hi,
> >
> > On 27/06/17 11:23, Icenowy Zheng wrote:
> > >
> > >
> > > 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> > >> Hi,
> > >>
> > >> On 27/06/17 10:41, Maxime Ripard wrote:
> > >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> > >>>> Hi,
> > >>>>
> > >>>> (CC:ing some people from that Rockchip dmwac series)
> > >>>>
> > >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> > >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> > >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> > >>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> > >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> > >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > >>>>>>>>> allwinner.
> > >>>>>>>>> In fact the only common part is the descriptor management and
> > >> the first
> > >>>>>>>>> register function.
> > >>>>>>>>
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> > >> driver
> > >>>>>>>> to the new binding I was wondering about the internal PHY
> > >> detection:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> > >> PHY
> > >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> > >> external).
> > >>>>>>>> I think I raised this question before, but isn't it perfectly
> > >> legal for
> > >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> > >> feature
> > >>>>>>>> an internal PHY?
> > >>>>>>>> On the first glance that does not make too much sense, but apart
> > >> from
> > >>>>>>>> not being the correct binding to describe all of the SoCs
> > >> features I see
> > >>>>>>>> two scenarios:
> > >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> > >> because it
> > >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> > >> For
> > >>>>>>>> instance I have heard reports that the internal PHY makes the
> > >> SoC go
> > >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> > >> external
> > >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> > >> avoided.
> > >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> > >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> > >> switch
> > >>>>>>>> IC or some other network circuitry, for instance fibre
> > >> connectors.
> > >>>>>>>>
> > >>>>>>>> So I was wondering if we would need an explicit:
> > >>>>>>>> allwinner,use-internal-phy;
> > >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> > >>>>>>>> Alternatively we could go with the negative version:
> > >>>>>>>> allwinner,disable-internal-phy;
> > >>>>>>>>
> > >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> > >> compatible
> > >>>>>>>> string for the *PHY* node and use that?
> > >>>>>>>>
> > >>>>>>>> I just want to avoid that we introduce a binding that causes us
> > >>>>>>>> headaches later. I think we can still fix this with a followup
> > >> patch
> > >>>>>>>> before the driver and its binding hit a release kernel.
> > >>>>>>>>
> > >>>>>>>> Cheers,
> > >>>>>>>> Andre.
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> > >>>>>>> I will try to find a way to use it
> > >>>>>>
> > >>>>>> Can you provide a link?
> > >>>>>
> > >>>>> https://lkml.org/lkml/2017/6/23/479
> > >>>>>
> > >>>>>>
> > >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> > >> what
> > >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> > >>>>
> > >>>> I can understand Chen-Yu's concerns, but ...
> > >>>>
> > >>>>> For each soc the internal PHY mode is know and setted in
> > >> emac_variant/internal_phy
> > >>>>> So its not a problem.
> > >>>>
> > >>>> that is true as well, at least for now.
> > >>>>
> > >>>> So while I agree that having a separate property to indicate
> > >>>> the usage of the internal PHY would be nice, I am bit tempted
> > >>>> to use this easier approach and piggy back on the existing
> > >>>> phy-mode property.
> > >>>
> > >>> We're trying to fix an issue that works for now too.
> > >>>
> > >>> If we want to consider future weird cases, then we must
> > >>> consider all of them. And the phy mode changing is definitely
> > >>> not really far fetched.
> > >>>
> > >>> I agree with Chen-Yu, and I really feel like the compatible
> > >>> solution you suggested would cover both your concerns, and
> > >>> ours.
> > >>
> > >> So something like this?
> > >> emac: emac@1c30000 {
> > >> compatible = "allwinner,sun8i-h3-emac";
> > >> ...
> > >> phy-mode = "mii";
> > >> phy-handle = <&int_mii_phy>;
> > >> ...
> > >>
> > >> mdio: mdio {
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >> int_mii_phy: ethernet-phy@1 {
> > >> compatible = "allwinner,sun8i-h3-ephy";
> > >> syscon = <&syscon>;
> > >
> > > The MAC still needs to set some bits of syscon register.
> >
> > Yes, the syscon property needs also to be in the MAC node, that
> > was meant to be somewhere in the second "..." ;-)
> >
> > But now since Chen-Yu mentioned that we need to set up the PHY *first*
> > to make it actually discoverable via MDIO, I wonder if we could change
> > this to:
> > 1) have the DT as described here
> > 2) Let the dwmac-sun8i driver peek into the node referenced by
> > phy-handle and check the compatible string there.
> > 3) If that matches some allwinner internal PHY name, it sets up the PHY
> > to make it respond when the MDIO driver queries its bus.
> >
> > Or can a PHY driver set itself up (since we have clocks and resets
> > properties in there) *before* the MDIO bus gets scanned?
> > Chen-Yu's comment in the other mail hints at that this is not easily
> > possible.
>
> I think adding phy compatible just make things more complex.
>
> I think the patch series I sent early fix all problems without more
> complexity since:
>
> - it does not add more DT stuff
> - it use an already used in tree DT phy-mode "internal" (and so phy
> mode PHY_INTERFACE_MODE_INTERNAL)
- it doesn't cover all the concerns we had
- it uses an undocumented value, with an unclear implication
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-06-27 17:29 ` Maxime Ripard
(?)
@ 2017-06-27 17:37 ` Corentin Labbe
-1 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 17:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andre Przywara, Icenowy Zheng, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, netdev,
linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Florian Fainelli, Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 07:29:37PM +0200, Maxime Ripard wrote:
> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> > > Hi,
> > >
> > > On 27/06/17 11:23, Icenowy Zheng wrote:
> > > >
> > > >
> > > > 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
> > > >> Hi,
> > > >>
> > > >> On 27/06/17 10:41, Maxime Ripard wrote:
> > > >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> (CC:ing some people from that Rockchip dmwac series)
> > > >>>>
> > > >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> > > >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> > > >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> > > >>>>>> <clabbe.montjoie@gmail.com> wrote:
> > > >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> > > >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> > > >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > > >>>>>>>>> allwinner.
> > > >>>>>>>>> In fact the only common part is the descriptor management and
> > > >> the first
> > > >>>>>>>>> register function.
> > > >>>>>>>>
> > > >>>>>>>> Hi,
> > > >>>>>>>>
> > > >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> > > >> driver
> > > >>>>>>>> to the new binding I was wondering about the internal PHY
> > > >> detection:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> > > >> PHY
> > > >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> > > >> external).
> > > >>>>>>>> I think I raised this question before, but isn't it perfectly
> > > >> legal for
> > > >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> > > >> feature
> > > >>>>>>>> an internal PHY?
> > > >>>>>>>> On the first glance that does not make too much sense, but apart
> > > >> from
> > > >>>>>>>> not being the correct binding to describe all of the SoCs
> > > >> features I see
> > > >>>>>>>> two scenarios:
> > > >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> > > >> because it
> > > >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> > > >> For
> > > >>>>>>>> instance I have heard reports that the internal PHY makes the
> > > >> SoC go
> > > >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> > > >> external
> > > >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> > > >> avoided.
> > > >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> > > >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> > > >> switch
> > > >>>>>>>> IC or some other network circuitry, for instance fibre
> > > >> connectors.
> > > >>>>>>>>
> > > >>>>>>>> So I was wondering if we would need an explicit:
> > > >>>>>>>> allwinner,use-internal-phy;
> > > >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> > > >>>>>>>> Alternatively we could go with the negative version:
> > > >>>>>>>> allwinner,disable-internal-phy;
> > > >>>>>>>>
> > > >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> > > >> compatible
> > > >>>>>>>> string for the *PHY* node and use that?
> > > >>>>>>>>
> > > >>>>>>>> I just want to avoid that we introduce a binding that causes us
> > > >>>>>>>> headaches later. I think we can still fix this with a followup
> > > >> patch
> > > >>>>>>>> before the driver and its binding hit a release kernel.
> > > >>>>>>>>
> > > >>>>>>>> Cheers,
> > > >>>>>>>> Andre.
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> > > >>>>>>> I will try to find a way to use it
> > > >>>>>>
> > > >>>>>> Can you provide a link?
> > > >>>>>
> > > >>>>> https://lkml.org/lkml/2017/6/23/479
> > > >>>>>
> > > >>>>>>
> > > >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> > > >> what
> > > >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> > > >>>>
> > > >>>> I can understand Chen-Yu's concerns, but ...
> > > >>>>
> > > >>>>> For each soc the internal PHY mode is know and setted in
> > > >> emac_variant/internal_phy
> > > >>>>> So its not a problem.
> > > >>>>
> > > >>>> that is true as well, at least for now.
> > > >>>>
> > > >>>> So while I agree that having a separate property to indicate
> > > >>>> the usage of the internal PHY would be nice, I am bit tempted
> > > >>>> to use this easier approach and piggy back on the existing
> > > >>>> phy-mode property.
> > > >>>
> > > >>> We're trying to fix an issue that works for now too.
> > > >>>
> > > >>> If we want to consider future weird cases, then we must
> > > >>> consider all of them. And the phy mode changing is definitely
> > > >>> not really far fetched.
> > > >>>
> > > >>> I agree with Chen-Yu, and I really feel like the compatible
> > > >>> solution you suggested would cover both your concerns, and
> > > >>> ours.
> > > >>
> > > >> So something like this?
> > > >> emac: emac@1c30000 {
> > > >> compatible = "allwinner,sun8i-h3-emac";
> > > >> ...
> > > >> phy-mode = "mii";
> > > >> phy-handle = <&int_mii_phy>;
> > > >> ...
> > > >>
> > > >> mdio: mdio {
> > > >> #address-cells = <1>;
> > > >> #size-cells = <0>;
> > > >> int_mii_phy: ethernet-phy@1 {
> > > >> compatible = "allwinner,sun8i-h3-ephy";
> > > >> syscon = <&syscon>;
> > > >
> > > > The MAC still needs to set some bits of syscon register.
> > >
> > > Yes, the syscon property needs also to be in the MAC node, that
> > > was meant to be somewhere in the second "..." ;-)
> > >
> > > But now since Chen-Yu mentioned that we need to set up the PHY *first*
> > > to make it actually discoverable via MDIO, I wonder if we could change
> > > this to:
> > > 1) have the DT as described here
> > > 2) Let the dwmac-sun8i driver peek into the node referenced by
> > > phy-handle and check the compatible string there.
> > > 3) If that matches some allwinner internal PHY name, it sets up the PHY
> > > to make it respond when the MDIO driver queries its bus.
> > >
> > > Or can a PHY driver set itself up (since we have clocks and resets
> > > properties in there) *before* the MDIO bus gets scanned?
> > > Chen-Yu's comment in the other mail hints at that this is not easily
> > > possible.
> >
> > I think adding phy compatible just make things more complex.
> >
> > I think the patch series I sent early fix all problems without more
> > complexity since:
> >
> > - it does not add more DT stuff
> > - it use an already used in tree DT phy-mode "internal" (and so phy
> > mode PHY_INTERFACE_MODE_INTERNAL)
>
> - it doesn't cover all the concerns we had
> - it uses an undocumented value, with an unclear implication
>
The answer from Florian anyway breaks my logic, internal is for "internal phy with non-xMII protocol" not just internal PHY
Regards
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 17:37 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 17:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 07:29:37PM +0200, Maxime Ripard wrote:
> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> > > Hi,
> > >
> > > On 27/06/17 11:23, Icenowy Zheng wrote:
> > > >
> > > >
> > > > ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
> > > >> Hi,
> > > >>
> > > >> On 27/06/17 10:41, Maxime Ripard wrote:
> > > >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> (CC:ing some people from that Rockchip dmwac series)
> > > >>>>
> > > >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> > > >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> > > >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> > > >>>>>> <clabbe.montjoie@gmail.com> wrote:
> > > >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> > > >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> > > >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > > >>>>>>>>> allwinner.
> > > >>>>>>>>> In fact the only common part is the descriptor management and
> > > >> the first
> > > >>>>>>>>> register function.
> > > >>>>>>>>
> > > >>>>>>>> Hi,
> > > >>>>>>>>
> > > >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> > > >> driver
> > > >>>>>>>> to the new binding I was wondering about the internal PHY
> > > >> detection:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> > > >> PHY
> > > >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> > > >> external).
> > > >>>>>>>> I think I raised this question before, but isn't it perfectly
> > > >> legal for
> > > >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> > > >> feature
> > > >>>>>>>> an internal PHY?
> > > >>>>>>>> On the first glance that does not make too much sense, but apart
> > > >> from
> > > >>>>>>>> not being the correct binding to describe all of the SoCs
> > > >> features I see
> > > >>>>>>>> two scenarios:
> > > >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> > > >> because it
> > > >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> > > >> For
> > > >>>>>>>> instance I have heard reports that the internal PHY makes the
> > > >> SoC go
> > > >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> > > >> external
> > > >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> > > >> avoided.
> > > >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> > > >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> > > >> switch
> > > >>>>>>>> IC or some other network circuitry, for instance fibre
> > > >> connectors.
> > > >>>>>>>>
> > > >>>>>>>> So I was wondering if we would need an explicit:
> > > >>>>>>>> allwinner,use-internal-phy;
> > > >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> > > >>>>>>>> Alternatively we could go with the negative version:
> > > >>>>>>>> allwinner,disable-internal-phy;
> > > >>>>>>>>
> > > >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> > > >> compatible
> > > >>>>>>>> string for the *PHY* node and use that?
> > > >>>>>>>>
> > > >>>>>>>> I just want to avoid that we introduce a binding that causes us
> > > >>>>>>>> headaches later. I think we can still fix this with a followup
> > > >> patch
> > > >>>>>>>> before the driver and its binding hit a release kernel.
> > > >>>>>>>>
> > > >>>>>>>> Cheers,
> > > >>>>>>>> Andre.
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> > > >>>>>>> I will try to find a way to use it
> > > >>>>>>
> > > >>>>>> Can you provide a link?
> > > >>>>>
> > > >>>>> https://lkml.org/lkml/2017/6/23/479
> > > >>>>>
> > > >>>>>>
> > > >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> > > >> what
> > > >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> > > >>>>
> > > >>>> I can understand Chen-Yu's concerns, but ...
> > > >>>>
> > > >>>>> For each soc the internal PHY mode is know and setted in
> > > >> emac_variant/internal_phy
> > > >>>>> So its not a problem.
> > > >>>>
> > > >>>> that is true as well, at least for now.
> > > >>>>
> > > >>>> So while I agree that having a separate property to indicate
> > > >>>> the usage of the internal PHY would be nice, I am bit tempted
> > > >>>> to use this easier approach and piggy back on the existing
> > > >>>> phy-mode property.
> > > >>>
> > > >>> We're trying to fix an issue that works for now too.
> > > >>>
> > > >>> If we want to consider future weird cases, then we must
> > > >>> consider all of them. And the phy mode changing is definitely
> > > >>> not really far fetched.
> > > >>>
> > > >>> I agree with Chen-Yu, and I really feel like the compatible
> > > >>> solution you suggested would cover both your concerns, and
> > > >>> ours.
> > > >>
> > > >> So something like this?
> > > >> emac: emac at 1c30000 {
> > > >> compatible = "allwinner,sun8i-h3-emac";
> > > >> ...
> > > >> phy-mode = "mii";
> > > >> phy-handle = <&int_mii_phy>;
> > > >> ...
> > > >>
> > > >> mdio: mdio {
> > > >> #address-cells = <1>;
> > > >> #size-cells = <0>;
> > > >> int_mii_phy: ethernet-phy at 1 {
> > > >> compatible = "allwinner,sun8i-h3-ephy";
> > > >> syscon = <&syscon>;
> > > >
> > > > The MAC still needs to set some bits of syscon register.
> > >
> > > Yes, the syscon property needs also to be in the MAC node, that
> > > was meant to be somewhere in the second "..." ;-)
> > >
> > > But now since Chen-Yu mentioned that we need to set up the PHY *first*
> > > to make it actually discoverable via MDIO, I wonder if we could change
> > > this to:
> > > 1) have the DT as described here
> > > 2) Let the dwmac-sun8i driver peek into the node referenced by
> > > phy-handle and check the compatible string there.
> > > 3) If that matches some allwinner internal PHY name, it sets up the PHY
> > > to make it respond when the MDIO driver queries its bus.
> > >
> > > Or can a PHY driver set itself up (since we have clocks and resets
> > > properties in there) *before* the MDIO bus gets scanned?
> > > Chen-Yu's comment in the other mail hints at that this is not easily
> > > possible.
> >
> > I think adding phy compatible just make things more complex.
> >
> > I think the patch series I sent early fix all problems without more
> > complexity since:
> >
> > - it does not add more DT stuff
> > - it use an already used in tree DT phy-mode "internal" (and so phy
> > mode PHY_INTERFACE_MODE_INTERNAL)
>
> - it doesn't cover all the concerns we had
> - it uses an undocumented value, with an unclear implication
>
The answer from Florian anyway breaks my logic, internal is for "internal phy with non-xMII protocol" not just internal PHY
Regards
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 17:37 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-06-27 17:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andre Przywara, Icenowy Zheng, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli, Andrew Lunn,
Heiko Stübner
On Tue, Jun 27, 2017 at 07:29:37PM +0200, Maxime Ripard wrote:
> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> > > Hi,
> > >
> > > On 27/06/17 11:23, Icenowy Zheng wrote:
> > > >
> > > >
> > > > 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> > > >> Hi,
> > > >>
> > > >> On 27/06/17 10:41, Maxime Ripard wrote:
> > > >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> (CC:ing some people from that Rockchip dmwac series)
> > > >>>>
> > > >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> > > >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> > > >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> > > >>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> > > >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> > > >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> > > >>>>>>>>> allwinner.
> > > >>>>>>>>> In fact the only common part is the descriptor management and
> > > >> the first
> > > >>>>>>>>> register function.
> > > >>>>>>>>
> > > >>>>>>>> Hi,
> > > >>>>>>>>
> > > >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> > > >> driver
> > > >>>>>>>> to the new binding I was wondering about the internal PHY
> > > >> detection:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> > > >> PHY
> > > >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> > > >> external).
> > > >>>>>>>> I think I raised this question before, but isn't it perfectly
> > > >> legal for
> > > >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> > > >> feature
> > > >>>>>>>> an internal PHY?
> > > >>>>>>>> On the first glance that does not make too much sense, but apart
> > > >> from
> > > >>>>>>>> not being the correct binding to describe all of the SoCs
> > > >> features I see
> > > >>>>>>>> two scenarios:
> > > >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> > > >> because it
> > > >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> > > >> For
> > > >>>>>>>> instance I have heard reports that the internal PHY makes the
> > > >> SoC go
> > > >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> > > >> external
> > > >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> > > >> avoided.
> > > >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> > > >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> > > >> switch
> > > >>>>>>>> IC or some other network circuitry, for instance fibre
> > > >> connectors.
> > > >>>>>>>>
> > > >>>>>>>> So I was wondering if we would need an explicit:
> > > >>>>>>>> allwinner,use-internal-phy;
> > > >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> > > >>>>>>>> Alternatively we could go with the negative version:
> > > >>>>>>>> allwinner,disable-internal-phy;
> > > >>>>>>>>
> > > >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> > > >> compatible
> > > >>>>>>>> string for the *PHY* node and use that?
> > > >>>>>>>>
> > > >>>>>>>> I just want to avoid that we introduce a binding that causes us
> > > >>>>>>>> headaches later. I think we can still fix this with a followup
> > > >> patch
> > > >>>>>>>> before the driver and its binding hit a release kernel.
> > > >>>>>>>>
> > > >>>>>>>> Cheers,
> > > >>>>>>>> Andre.
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> > > >>>>>>> I will try to find a way to use it
> > > >>>>>>
> > > >>>>>> Can you provide a link?
> > > >>>>>
> > > >>>>> https://lkml.org/lkml/2017/6/23/479
> > > >>>>>
> > > >>>>>>
> > > >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> > > >> what
> > > >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> > > >>>>
> > > >>>> I can understand Chen-Yu's concerns, but ...
> > > >>>>
> > > >>>>> For each soc the internal PHY mode is know and setted in
> > > >> emac_variant/internal_phy
> > > >>>>> So its not a problem.
> > > >>>>
> > > >>>> that is true as well, at least for now.
> > > >>>>
> > > >>>> So while I agree that having a separate property to indicate
> > > >>>> the usage of the internal PHY would be nice, I am bit tempted
> > > >>>> to use this easier approach and piggy back on the existing
> > > >>>> phy-mode property.
> > > >>>
> > > >>> We're trying to fix an issue that works for now too.
> > > >>>
> > > >>> If we want to consider future weird cases, then we must
> > > >>> consider all of them. And the phy mode changing is definitely
> > > >>> not really far fetched.
> > > >>>
> > > >>> I agree with Chen-Yu, and I really feel like the compatible
> > > >>> solution you suggested would cover both your concerns, and
> > > >>> ours.
> > > >>
> > > >> So something like this?
> > > >> emac: emac@1c30000 {
> > > >> compatible = "allwinner,sun8i-h3-emac";
> > > >> ...
> > > >> phy-mode = "mii";
> > > >> phy-handle = <&int_mii_phy>;
> > > >> ...
> > > >>
> > > >> mdio: mdio {
> > > >> #address-cells = <1>;
> > > >> #size-cells = <0>;
> > > >> int_mii_phy: ethernet-phy@1 {
> > > >> compatible = "allwinner,sun8i-h3-ephy";
> > > >> syscon = <&syscon>;
> > > >
> > > > The MAC still needs to set some bits of syscon register.
> > >
> > > Yes, the syscon property needs also to be in the MAC node, that
> > > was meant to be somewhere in the second "..." ;-)
> > >
> > > But now since Chen-Yu mentioned that we need to set up the PHY *first*
> > > to make it actually discoverable via MDIO, I wonder if we could change
> > > this to:
> > > 1) have the DT as described here
> > > 2) Let the dwmac-sun8i driver peek into the node referenced by
> > > phy-handle and check the compatible string there.
> > > 3) If that matches some allwinner internal PHY name, it sets up the PHY
> > > to make it respond when the MDIO driver queries its bus.
> > >
> > > Or can a PHY driver set itself up (since we have clocks and resets
> > > properties in there) *before* the MDIO bus gets scanned?
> > > Chen-Yu's comment in the other mail hints at that this is not easily
> > > possible.
> >
> > I think adding phy compatible just make things more complex.
> >
> > I think the patch series I sent early fix all problems without more
> > complexity since:
> >
> > - it does not add more DT stuff
> > - it use an already used in tree DT phy-mode "internal" (and so phy
> > mode PHY_INTERFACE_MODE_INTERNAL)
>
> - it doesn't cover all the concerns we had
> - it uses an undocumented value, with an unclear implication
>
The answer from Florian anyway breaks my logic, internal is for "internal phy with non-xMII protocol" not just internal PHY
Regards
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-06-27 17:29 ` Maxime Ripard
(?)
@ 2017-06-27 17:37 ` Florian Fainelli
-1 siblings, 0 replies; 148+ messages in thread
From: Florian Fainelli @ 2017-06-27 17:37 UTC (permalink / raw)
To: Maxime Ripard, Corentin Labbe
Cc: Andre Przywara, Icenowy Zheng, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, netdev,
linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Andrew Lunn, Heiko Stübner
On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 27/06/17 11:23, Icenowy Zheng wrote:
>>>>
>>>>
>>>> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
>>>>> Hi,
>>>>>
>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>>>>
>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>>>>>> allwinner.
>>>>>>>>>>>> In fact the only common part is the descriptor management and
>>>>> the first
>>>>>>>>>>>> register function.
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>>>>> driver
>>>>>>>>>>> to the new binding I was wondering about the internal PHY
>>>>> detection:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>>>>> PHY
>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
>>>>> external).
>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
>>>>> legal for
>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
>>>>> feature
>>>>>>>>>>> an internal PHY?
>>>>>>>>>>> On the first glance that does not make too much sense, but apart
>>>>> from
>>>>>>>>>>> not being the correct binding to describe all of the SoCs
>>>>> features I see
>>>>>>>>>>> two scenarios:
>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
>>>>> because it
>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
>>>>> For
>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
>>>>> SoC go
>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>>>>> external
>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>>>> avoided.
>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>>>> switch
>>>>>>>>>>> IC or some other network circuitry, for instance fibre
>>>>> connectors.
>>>>>>>>>>>
>>>>>>>>>>> So I was wondering if we would need an explicit:
>>>>>>>>>>> allwinner,use-internal-phy;
>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>>>>>> Alternatively we could go with the negative version:
>>>>>>>>>>> allwinner,disable-internal-phy;
>>>>>>>>>>>
>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>>>> compatible
>>>>>>>>>>> string for the *PHY* node and use that?
>>>>>>>>>>>
>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>>>>>> headaches later. I think we can still fix this with a followup
>>>>> patch
>>>>>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Andre.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>>>>>> I will try to find a way to use it
>>>>>>>>>
>>>>>>>>> Can you provide a link?
>>>>>>>>
>>>>>>>> https://lkml.org/lkml/2017/6/23/479
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>>>>> what
>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>>>>>
>>>>>>> I can understand Chen-Yu's concerns, but ...
>>>>>>>
>>>>>>>> For each soc the internal PHY mode is know and setted in
>>>>> emac_variant/internal_phy
>>>>>>>> So its not a problem.
>>>>>>>
>>>>>>> that is true as well, at least for now.
>>>>>>>
>>>>>>> So while I agree that having a separate property to indicate
>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
>>>>>>> to use this easier approach and piggy back on the existing
>>>>>>> phy-mode property.
>>>>>>
>>>>>> We're trying to fix an issue that works for now too.
>>>>>>
>>>>>> If we want to consider future weird cases, then we must
>>>>>> consider all of them. And the phy mode changing is definitely
>>>>>> not really far fetched.
>>>>>>
>>>>>> I agree with Chen-Yu, and I really feel like the compatible
>>>>>> solution you suggested would cover both your concerns, and
>>>>>> ours.
>>>>>
>>>>> So something like this?
>>>>> emac: emac@1c30000 {
>>>>> compatible = "allwinner,sun8i-h3-emac";
>>>>> ...
>>>>> phy-mode = "mii";
>>>>> phy-handle = <&int_mii_phy>;
>>>>> ...
>>>>>
>>>>> mdio: mdio {
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> int_mii_phy: ethernet-phy@1 {
>>>>> compatible = "allwinner,sun8i-h3-ephy";
>>>>> syscon = <&syscon>;
>>>>
>>>> The MAC still needs to set some bits of syscon register.
>>>
>>> Yes, the syscon property needs also to be in the MAC node, that
>>> was meant to be somewhere in the second "..." ;-)
>>>
>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
>>> to make it actually discoverable via MDIO, I wonder if we could change
>>> this to:
>>> 1) have the DT as described here
>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
>>> phy-handle and check the compatible string there.
>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
>>> to make it respond when the MDIO driver queries its bus.
>>>
>>> Or can a PHY driver set itself up (since we have clocks and resets
>>> properties in there) *before* the MDIO bus gets scanned?
>>> Chen-Yu's comment in the other mail hints at that this is not easily
>>> possible.
>>
>> I think adding phy compatible just make things more complex.
>>
>> I think the patch series I sent early fix all problems without more
>> complexity since:
>>
>> - it does not add more DT stuff
>> - it use an already used in tree DT phy-mode "internal" (and so phy
>> mode PHY_INTERFACE_MODE_INTERNAL)
>
> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
No it's no longer undocumented since [1]
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
Due to the timezone difference, you guys have already managed to have
several exchanges, hopefully I will have a chance to review your
discussions a little later today.
--
Florian
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 17:37 ` Florian Fainelli
0 siblings, 0 replies; 148+ messages in thread
From: Florian Fainelli @ 2017-06-27 17:37 UTC (permalink / raw)
To: linux-arm-kernel
On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 27/06/17 11:23, Icenowy Zheng wrote:
>>>>
>>>>
>>>> ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
>>>>> Hi,
>>>>>
>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>>>>
>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>>>>>> allwinner.
>>>>>>>>>>>> In fact the only common part is the descriptor management and
>>>>> the first
>>>>>>>>>>>> register function.
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>>>>> driver
>>>>>>>>>>> to the new binding I was wondering about the internal PHY
>>>>> detection:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>>>>> PHY
>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
>>>>> external).
>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
>>>>> legal for
>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
>>>>> feature
>>>>>>>>>>> an internal PHY?
>>>>>>>>>>> On the first glance that does not make too much sense, but apart
>>>>> from
>>>>>>>>>>> not being the correct binding to describe all of the SoCs
>>>>> features I see
>>>>>>>>>>> two scenarios:
>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
>>>>> because it
>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
>>>>> For
>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
>>>>> SoC go
>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>>>>> external
>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>>>> avoided.
>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>>>> switch
>>>>>>>>>>> IC or some other network circuitry, for instance fibre
>>>>> connectors.
>>>>>>>>>>>
>>>>>>>>>>> So I was wondering if we would need an explicit:
>>>>>>>>>>> allwinner,use-internal-phy;
>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>>>>>> Alternatively we could go with the negative version:
>>>>>>>>>>> allwinner,disable-internal-phy;
>>>>>>>>>>>
>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>>>> compatible
>>>>>>>>>>> string for the *PHY* node and use that?
>>>>>>>>>>>
>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>>>>>> headaches later. I think we can still fix this with a followup
>>>>> patch
>>>>>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Andre.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>>>>>> I will try to find a way to use it
>>>>>>>>>
>>>>>>>>> Can you provide a link?
>>>>>>>>
>>>>>>>> https://lkml.org/lkml/2017/6/23/479
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>>>>> what
>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>>>>>
>>>>>>> I can understand Chen-Yu's concerns, but ...
>>>>>>>
>>>>>>>> For each soc the internal PHY mode is know and setted in
>>>>> emac_variant/internal_phy
>>>>>>>> So its not a problem.
>>>>>>>
>>>>>>> that is true as well, at least for now.
>>>>>>>
>>>>>>> So while I agree that having a separate property to indicate
>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
>>>>>>> to use this easier approach and piggy back on the existing
>>>>>>> phy-mode property.
>>>>>>
>>>>>> We're trying to fix an issue that works for now too.
>>>>>>
>>>>>> If we want to consider future weird cases, then we must
>>>>>> consider all of them. And the phy mode changing is definitely
>>>>>> not really far fetched.
>>>>>>
>>>>>> I agree with Chen-Yu, and I really feel like the compatible
>>>>>> solution you suggested would cover both your concerns, and
>>>>>> ours.
>>>>>
>>>>> So something like this?
>>>>> emac: emac at 1c30000 {
>>>>> compatible = "allwinner,sun8i-h3-emac";
>>>>> ...
>>>>> phy-mode = "mii";
>>>>> phy-handle = <&int_mii_phy>;
>>>>> ...
>>>>>
>>>>> mdio: mdio {
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> int_mii_phy: ethernet-phy at 1 {
>>>>> compatible = "allwinner,sun8i-h3-ephy";
>>>>> syscon = <&syscon>;
>>>>
>>>> The MAC still needs to set some bits of syscon register.
>>>
>>> Yes, the syscon property needs also to be in the MAC node, that
>>> was meant to be somewhere in the second "..." ;-)
>>>
>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
>>> to make it actually discoverable via MDIO, I wonder if we could change
>>> this to:
>>> 1) have the DT as described here
>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
>>> phy-handle and check the compatible string there.
>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
>>> to make it respond when the MDIO driver queries its bus.
>>>
>>> Or can a PHY driver set itself up (since we have clocks and resets
>>> properties in there) *before* the MDIO bus gets scanned?
>>> Chen-Yu's comment in the other mail hints at that this is not easily
>>> possible.
>>
>> I think adding phy compatible just make things more complex.
>>
>> I think the patch series I sent early fix all problems without more
>> complexity since:
>>
>> - it does not add more DT stuff
>> - it use an already used in tree DT phy-mode "internal" (and so phy
>> mode PHY_INTERFACE_MODE_INTERNAL)
>
> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
No it's no longer undocumented since [1]
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
Due to the timezone difference, you guys have already managed to have
several exchanges, hopefully I will have a chance to review your
discussions a little later today.
--
Florian
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 17:37 ` Florian Fainelli
0 siblings, 0 replies; 148+ messages in thread
From: Florian Fainelli @ 2017-06-27 17:37 UTC (permalink / raw)
To: Maxime Ripard, Corentin Labbe
Cc: Andre Przywara, Icenowy Zheng, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Andrew Lunn, Heiko Stübner
On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 27/06/17 11:23, Icenowy Zheng wrote:
>>>>
>>>>
>>>> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>>>> Hi,
>>>>>
>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>>>>
>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>>>>>> allwinner.
>>>>>>>>>>>> In fact the only common part is the descriptor management and
>>>>> the first
>>>>>>>>>>>> register function.
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>>>>> driver
>>>>>>>>>>> to the new binding I was wondering about the internal PHY
>>>>> detection:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>>>>> PHY
>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
>>>>> external).
>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
>>>>> legal for
>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
>>>>> feature
>>>>>>>>>>> an internal PHY?
>>>>>>>>>>> On the first glance that does not make too much sense, but apart
>>>>> from
>>>>>>>>>>> not being the correct binding to describe all of the SoCs
>>>>> features I see
>>>>>>>>>>> two scenarios:
>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
>>>>> because it
>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
>>>>> For
>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
>>>>> SoC go
>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>>>>> external
>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>>>> avoided.
>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>>>> switch
>>>>>>>>>>> IC or some other network circuitry, for instance fibre
>>>>> connectors.
>>>>>>>>>>>
>>>>>>>>>>> So I was wondering if we would need an explicit:
>>>>>>>>>>> allwinner,use-internal-phy;
>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>>>>>> Alternatively we could go with the negative version:
>>>>>>>>>>> allwinner,disable-internal-phy;
>>>>>>>>>>>
>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>>>> compatible
>>>>>>>>>>> string for the *PHY* node and use that?
>>>>>>>>>>>
>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>>>>>> headaches later. I think we can still fix this with a followup
>>>>> patch
>>>>>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Andre.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>>>>>> I will try to find a way to use it
>>>>>>>>>
>>>>>>>>> Can you provide a link?
>>>>>>>>
>>>>>>>> https://lkml.org/lkml/2017/6/23/479
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>>>>> what
>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>>>>>
>>>>>>> I can understand Chen-Yu's concerns, but ...
>>>>>>>
>>>>>>>> For each soc the internal PHY mode is know and setted in
>>>>> emac_variant/internal_phy
>>>>>>>> So its not a problem.
>>>>>>>
>>>>>>> that is true as well, at least for now.
>>>>>>>
>>>>>>> So while I agree that having a separate property to indicate
>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
>>>>>>> to use this easier approach and piggy back on the existing
>>>>>>> phy-mode property.
>>>>>>
>>>>>> We're trying to fix an issue that works for now too.
>>>>>>
>>>>>> If we want to consider future weird cases, then we must
>>>>>> consider all of them. And the phy mode changing is definitely
>>>>>> not really far fetched.
>>>>>>
>>>>>> I agree with Chen-Yu, and I really feel like the compatible
>>>>>> solution you suggested would cover both your concerns, and
>>>>>> ours.
>>>>>
>>>>> So something like this?
>>>>> emac: emac@1c30000 {
>>>>> compatible = "allwinner,sun8i-h3-emac";
>>>>> ...
>>>>> phy-mode = "mii";
>>>>> phy-handle = <&int_mii_phy>;
>>>>> ...
>>>>>
>>>>> mdio: mdio {
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> int_mii_phy: ethernet-phy@1 {
>>>>> compatible = "allwinner,sun8i-h3-ephy";
>>>>> syscon = <&syscon>;
>>>>
>>>> The MAC still needs to set some bits of syscon register.
>>>
>>> Yes, the syscon property needs also to be in the MAC node, that
>>> was meant to be somewhere in the second "..." ;-)
>>>
>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
>>> to make it actually discoverable via MDIO, I wonder if we could change
>>> this to:
>>> 1) have the DT as described here
>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
>>> phy-handle and check the compatible string there.
>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
>>> to make it respond when the MDIO driver queries its bus.
>>>
>>> Or can a PHY driver set itself up (since we have clocks and resets
>>> properties in there) *before* the MDIO bus gets scanned?
>>> Chen-Yu's comment in the other mail hints at that this is not easily
>>> possible.
>>
>> I think adding phy compatible just make things more complex.
>>
>> I think the patch series I sent early fix all problems without more
>> complexity since:
>>
>> - it does not add more DT stuff
>> - it use an already used in tree DT phy-mode "internal" (and so phy
>> mode PHY_INTERFACE_MODE_INTERNAL)
>
> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
No it's no longer undocumented since [1]
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
Due to the timezone difference, you guys have already managed to have
several exchanges, hopefully I will have a chance to review your
discussions a little later today.
--
Florian
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-07-01 6:53 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-07-01 6:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: Maxime Ripard, Andre Przywara, Icenowy Zheng, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Russell King, Catalin Marinas,
Will Deacon, Giuseppe Cavallaro, alexandre.torgue, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> > On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> >> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> >>> Hi,
> >>>
> >>> On 27/06/17 11:23, Icenowy Zheng wrote:
> >>>>
> >>>>
> >>>> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
> >>>>> Hi,
> >>>>>
> >>>>> On 27/06/17 10:41, Maxime Ripard wrote:
> >>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>>>>
> >>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>>>>> <clabbe.montjoie@gmail.com> wrote:
> >>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>>>>> allwinner.
> >>>>>>>>>>>> In fact the only common part is the descriptor management and
> >>>>> the first
> >>>>>>>>>>>> register function.
> >>>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >>>>> driver
> >>>>>>>>>>> to the new binding I was wondering about the internal PHY
> >>>>> detection:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >>>>> PHY
> >>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >>>>> external).
> >>>>>>>>>>> I think I raised this question before, but isn't it perfectly
> >>>>> legal for
> >>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >>>>> feature
> >>>>>>>>>>> an internal PHY?
> >>>>>>>>>>> On the first glance that does not make too much sense, but apart
> >>>>> from
> >>>>>>>>>>> not being the correct binding to describe all of the SoCs
> >>>>> features I see
> >>>>>>>>>>> two scenarios:
> >>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >>>>> because it
> >>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >>>>> For
> >>>>>>>>>>> instance I have heard reports that the internal PHY makes the
> >>>>> SoC go
> >>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >>>>> external
> >>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >>>>> avoided.
> >>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >>>>> switch
> >>>>>>>>>>> IC or some other network circuitry, for instance fibre
> >>>>> connectors.
> >>>>>>>>>>>
> >>>>>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>>>>> allwinner,use-internal-phy;
> >>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>>>>
> >>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >>>>> compatible
> >>>>>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>>>>
> >>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>>>>> headaches later. I think we can still fix this with a followup
> >>>>> patch
> >>>>>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Andre.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>>>>> I will try to find a way to use it
> >>>>>>>>>
> >>>>>>>>> Can you provide a link?
> >>>>>>>>
> >>>>>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >>>>> what
> >>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>>>>
> >>>>>>> I can understand Chen-Yu's concerns, but ...
> >>>>>>>
> >>>>>>>> For each soc the internal PHY mode is know and setted in
> >>>>> emac_variant/internal_phy
> >>>>>>>> So its not a problem.
> >>>>>>>
> >>>>>>> that is true as well, at least for now.
> >>>>>>>
> >>>>>>> So while I agree that having a separate property to indicate
> >>>>>>> the usage of the internal PHY would be nice, I am bit tempted
> >>>>>>> to use this easier approach and piggy back on the existing
> >>>>>>> phy-mode property.
> >>>>>>
> >>>>>> We're trying to fix an issue that works for now too.
> >>>>>>
> >>>>>> If we want to consider future weird cases, then we must
> >>>>>> consider all of them. And the phy mode changing is definitely
> >>>>>> not really far fetched.
> >>>>>>
> >>>>>> I agree with Chen-Yu, and I really feel like the compatible
> >>>>>> solution you suggested would cover both your concerns, and
> >>>>>> ours.
> >>>>>
> >>>>> So something like this?
> >>>>> emac: emac@1c30000 {
> >>>>> compatible = "allwinner,sun8i-h3-emac";
> >>>>> ...
> >>>>> phy-mode = "mii";
> >>>>> phy-handle = <&int_mii_phy>;
> >>>>> ...
> >>>>>
> >>>>> mdio: mdio {
> >>>>> #address-cells = <1>;
> >>>>> #size-cells = <0>;
> >>>>> int_mii_phy: ethernet-phy@1 {
> >>>>> compatible = "allwinner,sun8i-h3-ephy";
> >>>>> syscon = <&syscon>;
> >>>>
> >>>> The MAC still needs to set some bits of syscon register.
> >>>
> >>> Yes, the syscon property needs also to be in the MAC node, that
> >>> was meant to be somewhere in the second "..." ;-)
> >>>
> >>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> >>> to make it actually discoverable via MDIO, I wonder if we could change
> >>> this to:
> >>> 1) have the DT as described here
> >>> 2) Let the dwmac-sun8i driver peek into the node referenced by
> >>> phy-handle and check the compatible string there.
> >>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> >>> to make it respond when the MDIO driver queries its bus.
> >>>
> >>> Or can a PHY driver set itself up (since we have clocks and resets
> >>> properties in there) *before* the MDIO bus gets scanned?
> >>> Chen-Yu's comment in the other mail hints at that this is not easily
> >>> possible.
> >>
> >> I think adding phy compatible just make things more complex.
> >>
> >> I think the patch series I sent early fix all problems without more
> >> complexity since:
> >>
> >> - it does not add more DT stuff
> >> - it use an already used in tree DT phy-mode "internal" (and so phy
> >> mode PHY_INTERFACE_MODE_INTERNAL)
> >
> > - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
>
> No it's no longer undocumented since [1]
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
>
> Due to the timezone difference, you guys have already managed to have
> several exchanges, hopefully I will have a chance to review your
> discussions a little later today.
Hello
I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1431579.html
Could you confirm that internal is only meant for "non xMII internal protocol"
Regards
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-07-01 6:53 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-07-01 6:53 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> > On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> >> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> >>> Hi,
> >>>
> >>> On 27/06/17 11:23, Icenowy Zheng wrote:
> >>>>
> >>>>
> >>>> ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
> >>>>> Hi,
> >>>>>
> >>>>> On 27/06/17 10:41, Maxime Ripard wrote:
> >>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>>>>
> >>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>>>>> <clabbe.montjoie@gmail.com> wrote:
> >>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> >>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>>>>> allwinner.
> >>>>>>>>>>>> In fact the only common part is the descriptor management and
> >>>>> the first
> >>>>>>>>>>>> register function.
> >>>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >>>>> driver
> >>>>>>>>>>> to the new binding I was wondering about the internal PHY
> >>>>> detection:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >>>>> PHY
> >>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >>>>> external).
> >>>>>>>>>>> I think I raised this question before, but isn't it perfectly
> >>>>> legal for
> >>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >>>>> feature
> >>>>>>>>>>> an internal PHY?
> >>>>>>>>>>> On the first glance that does not make too much sense, but apart
> >>>>> from
> >>>>>>>>>>> not being the correct binding to describe all of the SoCs
> >>>>> features I see
> >>>>>>>>>>> two scenarios:
> >>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >>>>> because it
> >>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >>>>> For
> >>>>>>>>>>> instance I have heard reports that the internal PHY makes the
> >>>>> SoC go
> >>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >>>>> external
> >>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >>>>> avoided.
> >>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >>>>> switch
> >>>>>>>>>>> IC or some other network circuitry, for instance fibre
> >>>>> connectors.
> >>>>>>>>>>>
> >>>>>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>>>>> allwinner,use-internal-phy;
> >>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>>>>
> >>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >>>>> compatible
> >>>>>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>>>>
> >>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>>>>> headaches later. I think we can still fix this with a followup
> >>>>> patch
> >>>>>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Andre.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>>>>> I will try to find a way to use it
> >>>>>>>>>
> >>>>>>>>> Can you provide a link?
> >>>>>>>>
> >>>>>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >>>>> what
> >>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>>>>
> >>>>>>> I can understand Chen-Yu's concerns, but ...
> >>>>>>>
> >>>>>>>> For each soc the internal PHY mode is know and setted in
> >>>>> emac_variant/internal_phy
> >>>>>>>> So its not a problem.
> >>>>>>>
> >>>>>>> that is true as well, at least for now.
> >>>>>>>
> >>>>>>> So while I agree that having a separate property to indicate
> >>>>>>> the usage of the internal PHY would be nice, I am bit tempted
> >>>>>>> to use this easier approach and piggy back on the existing
> >>>>>>> phy-mode property.
> >>>>>>
> >>>>>> We're trying to fix an issue that works for now too.
> >>>>>>
> >>>>>> If we want to consider future weird cases, then we must
> >>>>>> consider all of them. And the phy mode changing is definitely
> >>>>>> not really far fetched.
> >>>>>>
> >>>>>> I agree with Chen-Yu, and I really feel like the compatible
> >>>>>> solution you suggested would cover both your concerns, and
> >>>>>> ours.
> >>>>>
> >>>>> So something like this?
> >>>>> emac: emac at 1c30000 {
> >>>>> compatible = "allwinner,sun8i-h3-emac";
> >>>>> ...
> >>>>> phy-mode = "mii";
> >>>>> phy-handle = <&int_mii_phy>;
> >>>>> ...
> >>>>>
> >>>>> mdio: mdio {
> >>>>> #address-cells = <1>;
> >>>>> #size-cells = <0>;
> >>>>> int_mii_phy: ethernet-phy at 1 {
> >>>>> compatible = "allwinner,sun8i-h3-ephy";
> >>>>> syscon = <&syscon>;
> >>>>
> >>>> The MAC still needs to set some bits of syscon register.
> >>>
> >>> Yes, the syscon property needs also to be in the MAC node, that
> >>> was meant to be somewhere in the second "..." ;-)
> >>>
> >>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> >>> to make it actually discoverable via MDIO, I wonder if we could change
> >>> this to:
> >>> 1) have the DT as described here
> >>> 2) Let the dwmac-sun8i driver peek into the node referenced by
> >>> phy-handle and check the compatible string there.
> >>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> >>> to make it respond when the MDIO driver queries its bus.
> >>>
> >>> Or can a PHY driver set itself up (since we have clocks and resets
> >>> properties in there) *before* the MDIO bus gets scanned?
> >>> Chen-Yu's comment in the other mail hints at that this is not easily
> >>> possible.
> >>
> >> I think adding phy compatible just make things more complex.
> >>
> >> I think the patch series I sent early fix all problems without more
> >> complexity since:
> >>
> >> - it does not add more DT stuff
> >> - it use an already used in tree DT phy-mode "internal" (and so phy
> >> mode PHY_INTERFACE_MODE_INTERNAL)
> >
> > - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
>
> No it's no longer undocumented since [1]
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
>
> Due to the timezone difference, you guys have already managed to have
> several exchanges, hopefully I will have a chance to review your
> discussions a little later today.
Hello
I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1431579.html
Could you confirm that internal is only meant for "non xMII internal protocol"
Regards
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-07-01 6:53 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-07-01 6:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: Maxime Ripard, Andre Przywara, Icenowy Zheng, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Russell King, Catalin Marinas,
Will Deacon, Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o,
devicetree, netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Andrew Lunn, Heiko Stübner
On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> > On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> >> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> >>> Hi,
> >>>
> >>> On 27/06/17 11:23, Icenowy Zheng wrote:
> >>>>
> >>>>
> >>>> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> >>>>> Hi,
> >>>>>
> >>>>> On 27/06/17 10:41, Maxime Ripard wrote:
> >>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>>>>
> >>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>>>>> allwinner.
> >>>>>>>>>>>> In fact the only common part is the descriptor management and
> >>>>> the first
> >>>>>>>>>>>> register function.
> >>>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >>>>> driver
> >>>>>>>>>>> to the new binding I was wondering about the internal PHY
> >>>>> detection:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >>>>> PHY
> >>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >>>>> external).
> >>>>>>>>>>> I think I raised this question before, but isn't it perfectly
> >>>>> legal for
> >>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >>>>> feature
> >>>>>>>>>>> an internal PHY?
> >>>>>>>>>>> On the first glance that does not make too much sense, but apart
> >>>>> from
> >>>>>>>>>>> not being the correct binding to describe all of the SoCs
> >>>>> features I see
> >>>>>>>>>>> two scenarios:
> >>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >>>>> because it
> >>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >>>>> For
> >>>>>>>>>>> instance I have heard reports that the internal PHY makes the
> >>>>> SoC go
> >>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >>>>> external
> >>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >>>>> avoided.
> >>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >>>>> switch
> >>>>>>>>>>> IC or some other network circuitry, for instance fibre
> >>>>> connectors.
> >>>>>>>>>>>
> >>>>>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>>>>> allwinner,use-internal-phy;
> >>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>>>>
> >>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >>>>> compatible
> >>>>>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>>>>
> >>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>>>>> headaches later. I think we can still fix this with a followup
> >>>>> patch
> >>>>>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Andre.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>>>>> I will try to find a way to use it
> >>>>>>>>>
> >>>>>>>>> Can you provide a link?
> >>>>>>>>
> >>>>>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >>>>> what
> >>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>>>>
> >>>>>>> I can understand Chen-Yu's concerns, but ...
> >>>>>>>
> >>>>>>>> For each soc the internal PHY mode is know and setted in
> >>>>> emac_variant/internal_phy
> >>>>>>>> So its not a problem.
> >>>>>>>
> >>>>>>> that is true as well, at least for now.
> >>>>>>>
> >>>>>>> So while I agree that having a separate property to indicate
> >>>>>>> the usage of the internal PHY would be nice, I am bit tempted
> >>>>>>> to use this easier approach and piggy back on the existing
> >>>>>>> phy-mode property.
> >>>>>>
> >>>>>> We're trying to fix an issue that works for now too.
> >>>>>>
> >>>>>> If we want to consider future weird cases, then we must
> >>>>>> consider all of them. And the phy mode changing is definitely
> >>>>>> not really far fetched.
> >>>>>>
> >>>>>> I agree with Chen-Yu, and I really feel like the compatible
> >>>>>> solution you suggested would cover both your concerns, and
> >>>>>> ours.
> >>>>>
> >>>>> So something like this?
> >>>>> emac: emac@1c30000 {
> >>>>> compatible = "allwinner,sun8i-h3-emac";
> >>>>> ...
> >>>>> phy-mode = "mii";
> >>>>> phy-handle = <&int_mii_phy>;
> >>>>> ...
> >>>>>
> >>>>> mdio: mdio {
> >>>>> #address-cells = <1>;
> >>>>> #size-cells = <0>;
> >>>>> int_mii_phy: ethernet-phy@1 {
> >>>>> compatible = "allwinner,sun8i-h3-ephy";
> >>>>> syscon = <&syscon>;
> >>>>
> >>>> The MAC still needs to set some bits of syscon register.
> >>>
> >>> Yes, the syscon property needs also to be in the MAC node, that
> >>> was meant to be somewhere in the second "..." ;-)
> >>>
> >>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> >>> to make it actually discoverable via MDIO, I wonder if we could change
> >>> this to:
> >>> 1) have the DT as described here
> >>> 2) Let the dwmac-sun8i driver peek into the node referenced by
> >>> phy-handle and check the compatible string there.
> >>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> >>> to make it respond when the MDIO driver queries its bus.
> >>>
> >>> Or can a PHY driver set itself up (since we have clocks and resets
> >>> properties in there) *before* the MDIO bus gets scanned?
> >>> Chen-Yu's comment in the other mail hints at that this is not easily
> >>> possible.
> >>
> >> I think adding phy compatible just make things more complex.
> >>
> >> I think the patch series I sent early fix all problems without more
> >> complexity since:
> >>
> >> - it does not add more DT stuff
> >> - it use an already used in tree DT phy-mode "internal" (and so phy
> >> mode PHY_INTERFACE_MODE_INTERNAL)
> >
> > - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
>
> No it's no longer undocumented since [1]
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
>
> Due to the timezone difference, you guys have already managed to have
> several exchanges, hopefully I will have a chance to review your
> discussions a little later today.
Hello
I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1431579.html
Could you confirm that internal is only meant for "non xMII internal protocol"
Regards
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
2017-07-01 6:53 ` Corentin Labbe
(?)
@ 2017-07-01 21:42 ` Florian Fainelli
-1 siblings, 0 replies; 148+ messages in thread
From: Florian Fainelli @ 2017-07-01 21:42 UTC (permalink / raw)
To: Corentin Labbe
Cc: Maxime Ripard, Andre Przywara, Icenowy Zheng, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Russell King, Catalin Marinas,
Will Deacon, Giuseppe Cavallaro, alexandre.torgue, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Andrew Lunn, Heiko Stübner
On 30/06/2017 23:53, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
>> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
>>> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
>>>>> Hi,
>>>>>
>>>>> On 27/06/17 11:23, Icenowy Zheng wrote:
>>>>>>
>>>>>>
>>>>>> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
>>>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>>>>>>
>>>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>>>>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>>>>>>>> allwinner.
>>>>>>>>>>>>>> In fact the only common part is the descriptor management and
>>>>>>> the first
>>>>>>>>>>>>>> register function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>>>>>>> driver
>>>>>>>>>>>>> to the new binding I was wondering about the internal PHY
>>>>>>> detection:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>>>>>>> PHY
>>>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
>>>>>>> external).
>>>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
>>>>>>> legal for
>>>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
>>>>>>> feature
>>>>>>>>>>>>> an internal PHY?
>>>>>>>>>>>>> On the first glance that does not make too much sense, but apart
>>>>>>> from
>>>>>>>>>>>>> not being the correct binding to describe all of the SoCs
>>>>>>> features I see
>>>>>>>>>>>>> two scenarios:
>>>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
>>>>>>> because it
>>>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
>>>>>>> For
>>>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
>>>>>>> SoC go
>>>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>>>>>>> external
>>>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>>>>>> avoided.
>>>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>>>>>> switch
>>>>>>>>>>>>> IC or some other network circuitry, for instance fibre
>>>>>>> connectors.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So I was wondering if we would need an explicit:
>>>>>>>>>>>>> allwinner,use-internal-phy;
>>>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>>>>>>>> Alternatively we could go with the negative version:
>>>>>>>>>>>>> allwinner,disable-internal-phy;
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>>>>>> compatible
>>>>>>>>>>>>> string for the *PHY* node and use that?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>>>>>>>> headaches later. I think we can still fix this with a followup
>>>>>>> patch
>>>>>>>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Andre.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>>>>>>>> I will try to find a way to use it
>>>>>>>>>>>
>>>>>>>>>>> Can you provide a link?
>>>>>>>>>>
>>>>>>>>>> https://lkml.org/lkml/2017/6/23/479
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>>>>>>> what
>>>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>>>>>>>
>>>>>>>>> I can understand Chen-Yu's concerns, but ...
>>>>>>>>>
>>>>>>>>>> For each soc the internal PHY mode is know and setted in
>>>>>>> emac_variant/internal_phy
>>>>>>>>>> So its not a problem.
>>>>>>>>>
>>>>>>>>> that is true as well, at least for now.
>>>>>>>>>
>>>>>>>>> So while I agree that having a separate property to indicate
>>>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
>>>>>>>>> to use this easier approach and piggy back on the existing
>>>>>>>>> phy-mode property.
>>>>>>>>
>>>>>>>> We're trying to fix an issue that works for now too.
>>>>>>>>
>>>>>>>> If we want to consider future weird cases, then we must
>>>>>>>> consider all of them. And the phy mode changing is definitely
>>>>>>>> not really far fetched.
>>>>>>>>
>>>>>>>> I agree with Chen-Yu, and I really feel like the compatible
>>>>>>>> solution you suggested would cover both your concerns, and
>>>>>>>> ours.
>>>>>>>
>>>>>>> So something like this?
>>>>>>> emac: emac@1c30000 {
>>>>>>> compatible = "allwinner,sun8i-h3-emac";
>>>>>>> ...
>>>>>>> phy-mode = "mii";
>>>>>>> phy-handle = <&int_mii_phy>;
>>>>>>> ...
>>>>>>>
>>>>>>> mdio: mdio {
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>> int_mii_phy: ethernet-phy@1 {
>>>>>>> compatible = "allwinner,sun8i-h3-ephy";
>>>>>>> syscon = <&syscon>;
>>>>>>
>>>>>> The MAC still needs to set some bits of syscon register.
>>>>>
>>>>> Yes, the syscon property needs also to be in the MAC node, that
>>>>> was meant to be somewhere in the second "..." ;-)
>>>>>
>>>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
>>>>> to make it actually discoverable via MDIO, I wonder if we could change
>>>>> this to:
>>>>> 1) have the DT as described here
>>>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
>>>>> phy-handle and check the compatible string there.
>>>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
>>>>> to make it respond when the MDIO driver queries its bus.
>>>>>
>>>>> Or can a PHY driver set itself up (since we have clocks and resets
>>>>> properties in there) *before* the MDIO bus gets scanned?
>>>>> Chen-Yu's comment in the other mail hints at that this is not easily
>>>>> possible.
>>>>
>>>> I think adding phy compatible just make things more complex.
>>>>
>>>> I think the patch series I sent early fix all problems without more
>>>> complexity since:
>>>>
>>>> - it does not add more DT stuff
>>>> - it use an already used in tree DT phy-mode "internal" (and so phy
>>>> mode PHY_INTERFACE_MODE_INTERNAL)
>>>
>>> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
>>
>> No it's no longer undocumented since [1]
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
>>
>> Due to the timezone difference, you guys have already managed to have
>> several exchanges, hopefully I will have a chance to review your
>> discussions a little later today.
>
> Hello
>
> I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1431579.html
> Could you confirm that internal is only meant for "non xMII internal protocol"
Yes that's what is it meant for. There are possibly two ways here:
1) assuming there is already a specific PHY driver for that internal
PHY, you should have this PHY driver set PHY_IS_INTERNAL (see bcm63xx.c
and bcm7xxx.c that do that) and so you would know that you did bind to
the correct internal PHY driver. Problem with that is if you need to
perform a particular action such that you will successfully bind to the
internal PHY (e.g: power on, reset, etc.)
2) We could create a new set of phy-mode values that are, e.g:
'internal-mii': internal MII connection to the PHY
and so on in order to cover the internal variants of those modes. I am
not sure this is strictly needed here though.
--
Florian
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-07-01 21:42 ` Florian Fainelli
0 siblings, 0 replies; 148+ messages in thread
From: Florian Fainelli @ 2017-07-01 21:42 UTC (permalink / raw)
To: linux-arm-kernel
On 30/06/2017 23:53, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
>> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
>>> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
>>>>> Hi,
>>>>>
>>>>> On 27/06/17 11:23, Icenowy Zheng wrote:
>>>>>>
>>>>>>
>>>>>> ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
>>>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>>>>>>
>>>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>>>>>>>> <clabbe.montjoie@gmail.com> wrote:
>>>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
>>>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>>>>>>>> allwinner.
>>>>>>>>>>>>>> In fact the only common part is the descriptor management and
>>>>>>> the first
>>>>>>>>>>>>>> register function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>>>>>>> driver
>>>>>>>>>>>>> to the new binding I was wondering about the internal PHY
>>>>>>> detection:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>>>>>>> PHY
>>>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
>>>>>>> external).
>>>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
>>>>>>> legal for
>>>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
>>>>>>> feature
>>>>>>>>>>>>> an internal PHY?
>>>>>>>>>>>>> On the first glance that does not make too much sense, but apart
>>>>>>> from
>>>>>>>>>>>>> not being the correct binding to describe all of the SoCs
>>>>>>> features I see
>>>>>>>>>>>>> two scenarios:
>>>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
>>>>>>> because it
>>>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
>>>>>>> For
>>>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
>>>>>>> SoC go
>>>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>>>>>>> external
>>>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>>>>>> avoided.
>>>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>>>>>> switch
>>>>>>>>>>>>> IC or some other network circuitry, for instance fibre
>>>>>>> connectors.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So I was wondering if we would need an explicit:
>>>>>>>>>>>>> allwinner,use-internal-phy;
>>>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>>>>>>>> Alternatively we could go with the negative version:
>>>>>>>>>>>>> allwinner,disable-internal-phy;
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>>>>>> compatible
>>>>>>>>>>>>> string for the *PHY* node and use that?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>>>>>>>> headaches later. I think we can still fix this with a followup
>>>>>>> patch
>>>>>>>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Andre.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>>>>>>>> I will try to find a way to use it
>>>>>>>>>>>
>>>>>>>>>>> Can you provide a link?
>>>>>>>>>>
>>>>>>>>>> https://lkml.org/lkml/2017/6/23/479
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>>>>>>> what
>>>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>>>>>>>
>>>>>>>>> I can understand Chen-Yu's concerns, but ...
>>>>>>>>>
>>>>>>>>>> For each soc the internal PHY mode is know and setted in
>>>>>>> emac_variant/internal_phy
>>>>>>>>>> So its not a problem.
>>>>>>>>>
>>>>>>>>> that is true as well, at least for now.
>>>>>>>>>
>>>>>>>>> So while I agree that having a separate property to indicate
>>>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
>>>>>>>>> to use this easier approach and piggy back on the existing
>>>>>>>>> phy-mode property.
>>>>>>>>
>>>>>>>> We're trying to fix an issue that works for now too.
>>>>>>>>
>>>>>>>> If we want to consider future weird cases, then we must
>>>>>>>> consider all of them. And the phy mode changing is definitely
>>>>>>>> not really far fetched.
>>>>>>>>
>>>>>>>> I agree with Chen-Yu, and I really feel like the compatible
>>>>>>>> solution you suggested would cover both your concerns, and
>>>>>>>> ours.
>>>>>>>
>>>>>>> So something like this?
>>>>>>> emac: emac at 1c30000 {
>>>>>>> compatible = "allwinner,sun8i-h3-emac";
>>>>>>> ...
>>>>>>> phy-mode = "mii";
>>>>>>> phy-handle = <&int_mii_phy>;
>>>>>>> ...
>>>>>>>
>>>>>>> mdio: mdio {
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>> int_mii_phy: ethernet-phy at 1 {
>>>>>>> compatible = "allwinner,sun8i-h3-ephy";
>>>>>>> syscon = <&syscon>;
>>>>>>
>>>>>> The MAC still needs to set some bits of syscon register.
>>>>>
>>>>> Yes, the syscon property needs also to be in the MAC node, that
>>>>> was meant to be somewhere in the second "..." ;-)
>>>>>
>>>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
>>>>> to make it actually discoverable via MDIO, I wonder if we could change
>>>>> this to:
>>>>> 1) have the DT as described here
>>>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
>>>>> phy-handle and check the compatible string there.
>>>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
>>>>> to make it respond when the MDIO driver queries its bus.
>>>>>
>>>>> Or can a PHY driver set itself up (since we have clocks and resets
>>>>> properties in there) *before* the MDIO bus gets scanned?
>>>>> Chen-Yu's comment in the other mail hints at that this is not easily
>>>>> possible.
>>>>
>>>> I think adding phy compatible just make things more complex.
>>>>
>>>> I think the patch series I sent early fix all problems without more
>>>> complexity since:
>>>>
>>>> - it does not add more DT stuff
>>>> - it use an already used in tree DT phy-mode "internal" (and so phy
>>>> mode PHY_INTERFACE_MODE_INTERNAL)
>>>
>>> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
>>
>> No it's no longer undocumented since [1]
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
>>
>> Due to the timezone difference, you guys have already managed to have
>> several exchanges, hopefully I will have a chance to review your
>> discussions a little later today.
>
> Hello
>
> I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1431579.html
> Could you confirm that internal is only meant for "non xMII internal protocol"
Yes that's what is it meant for. There are possibly two ways here:
1) assuming there is already a specific PHY driver for that internal
PHY, you should have this PHY driver set PHY_IS_INTERNAL (see bcm63xx.c
and bcm7xxx.c that do that) and so you would know that you did bind to
the correct internal PHY driver. Problem with that is if you need to
perform a particular action such that you will successfully bind to the
internal PHY (e.g: power on, reset, etc.)
2) We could create a new set of phy-mode values that are, e.g:
'internal-mii': internal MII connection to the PHY
and so on in order to cover the internal variants of those modes. I am
not sure this is strictly needed here though.
--
Florian
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-07-01 21:42 ` Florian Fainelli
0 siblings, 0 replies; 148+ messages in thread
From: Florian Fainelli @ 2017-07-01 21:42 UTC (permalink / raw)
To: Corentin Labbe
Cc: Maxime Ripard, Andre Przywara, Icenowy Zheng, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Russell King, Catalin Marinas,
Will Deacon, Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o,
devicetree, netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Andrew Lunn, Heiko Stübner
On 30/06/2017 23:53, Corentin Labbe wrote:
> On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
>> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
>>> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
>>>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
>>>>> Hi,
>>>>>
>>>>> On 27/06/17 11:23, Icenowy Zheng wrote:
>>>>>>
>>>>>>
>>>>>> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
>>>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> (CC:ing some people from that Rockchip dmwac series)
>>>>>>>>>
>>>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
>>>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
>>>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
>>>>>>>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
>>>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
>>>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
>>>>>>>>>>>>>> allwinner.
>>>>>>>>>>>>>> In fact the only common part is the descriptor management and
>>>>>>> the first
>>>>>>>>>>>>>> register function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
>>>>>>> driver
>>>>>>>>>>>>> to the new binding I was wondering about the internal PHY
>>>>>>> detection:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
>>>>>>> PHY
>>>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
>>>>>>> external).
>>>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
>>>>>>> legal for
>>>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
>>>>>>> feature
>>>>>>>>>>>>> an internal PHY?
>>>>>>>>>>>>> On the first glance that does not make too much sense, but apart
>>>>>>> from
>>>>>>>>>>>>> not being the correct binding to describe all of the SoCs
>>>>>>> features I see
>>>>>>>>>>>>> two scenarios:
>>>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
>>>>>>> because it
>>>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
>>>>>>> For
>>>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
>>>>>>> SoC go
>>>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
>>>>>>> external
>>>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
>>>>>>> avoided.
>>>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
>>>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
>>>>>>> switch
>>>>>>>>>>>>> IC or some other network circuitry, for instance fibre
>>>>>>> connectors.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So I was wondering if we would need an explicit:
>>>>>>>>>>>>> allwinner,use-internal-phy;
>>>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
>>>>>>>>>>>>> Alternatively we could go with the negative version:
>>>>>>>>>>>>> allwinner,disable-internal-phy;
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
>>>>>>> compatible
>>>>>>>>>>>>> string for the *PHY* node and use that?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
>>>>>>>>>>>>> headaches later. I think we can still fix this with a followup
>>>>>>> patch
>>>>>>>>>>>>> before the driver and its binding hit a release kernel.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Andre.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
>>>>>>>>>>>> I will try to find a way to use it
>>>>>>>>>>>
>>>>>>>>>>> Can you provide a link?
>>>>>>>>>>
>>>>>>>>>> https://lkml.org/lkml/2017/6/23/479
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
>>>>>>> what
>>>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
>>>>>>>>>
>>>>>>>>> I can understand Chen-Yu's concerns, but ...
>>>>>>>>>
>>>>>>>>>> For each soc the internal PHY mode is know and setted in
>>>>>>> emac_variant/internal_phy
>>>>>>>>>> So its not a problem.
>>>>>>>>>
>>>>>>>>> that is true as well, at least for now.
>>>>>>>>>
>>>>>>>>> So while I agree that having a separate property to indicate
>>>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
>>>>>>>>> to use this easier approach and piggy back on the existing
>>>>>>>>> phy-mode property.
>>>>>>>>
>>>>>>>> We're trying to fix an issue that works for now too.
>>>>>>>>
>>>>>>>> If we want to consider future weird cases, then we must
>>>>>>>> consider all of them. And the phy mode changing is definitely
>>>>>>>> not really far fetched.
>>>>>>>>
>>>>>>>> I agree with Chen-Yu, and I really feel like the compatible
>>>>>>>> solution you suggested would cover both your concerns, and
>>>>>>>> ours.
>>>>>>>
>>>>>>> So something like this?
>>>>>>> emac: emac@1c30000 {
>>>>>>> compatible = "allwinner,sun8i-h3-emac";
>>>>>>> ...
>>>>>>> phy-mode = "mii";
>>>>>>> phy-handle = <&int_mii_phy>;
>>>>>>> ...
>>>>>>>
>>>>>>> mdio: mdio {
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>> int_mii_phy: ethernet-phy@1 {
>>>>>>> compatible = "allwinner,sun8i-h3-ephy";
>>>>>>> syscon = <&syscon>;
>>>>>>
>>>>>> The MAC still needs to set some bits of syscon register.
>>>>>
>>>>> Yes, the syscon property needs also to be in the MAC node, that
>>>>> was meant to be somewhere in the second "..." ;-)
>>>>>
>>>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
>>>>> to make it actually discoverable via MDIO, I wonder if we could change
>>>>> this to:
>>>>> 1) have the DT as described here
>>>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
>>>>> phy-handle and check the compatible string there.
>>>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
>>>>> to make it respond when the MDIO driver queries its bus.
>>>>>
>>>>> Or can a PHY driver set itself up (since we have clocks and resets
>>>>> properties in there) *before* the MDIO bus gets scanned?
>>>>> Chen-Yu's comment in the other mail hints at that this is not easily
>>>>> possible.
>>>>
>>>> I think adding phy compatible just make things more complex.
>>>>
>>>> I think the patch series I sent early fix all problems without more
>>>> complexity since:
>>>>
>>>> - it does not add more DT stuff
>>>> - it use an already used in tree DT phy-mode "internal" (and so phy
>>>> mode PHY_INTERFACE_MODE_INTERNAL)
>>>
>>> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
>>
>> No it's no longer undocumented since [1]
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
>>
>> Due to the timezone difference, you guys have already managed to have
>> several exchanges, hopefully I will have a chance to review your
>> discussions a little later today.
>
> Hello
>
> I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1431579.html
> Could you confirm that internal is only meant for "non xMII internal protocol"
Yes that's what is it meant for. There are possibly two ways here:
1) assuming there is already a specific PHY driver for that internal
PHY, you should have this PHY driver set PHY_IS_INTERNAL (see bcm63xx.c
and bcm7xxx.c that do that) and so you would know that you did bind to
the correct internal PHY driver. Problem with that is if you need to
perform a particular action such that you will successfully bind to the
internal PHY (e.g: power on, reset, etc.)
2) We could create a new set of phy-mode values that are, e.g:
'internal-mii': internal MII connection to the PHY
and so on in order to cover the internal variants of those modes. I am
not sure this is strictly needed here though.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-07-02 8:36 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-07-02 8:36 UTC (permalink / raw)
To: Florian Fainelli
Cc: Maxime Ripard, Andre Przywara, Icenowy Zheng, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Russell King, Catalin Marinas,
Will Deacon, Giuseppe Cavallaro, alexandre.torgue, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Andrew Lunn, Heiko Stübner
On Sat, Jul 01, 2017 at 02:42:14PM -0700, Florian Fainelli wrote:
> On 30/06/2017 23:53, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
> >> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> >>>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 27/06/17 11:23, Icenowy Zheng wrote:
> >>>>>>
> >>>>>>
> >>>>>> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
> >>>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>>>>>>
> >>>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>>>>>>> <clabbe.montjoie@gmail.com> wrote:
> >>>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>>>>>>> allwinner.
> >>>>>>>>>>>>>> In fact the only common part is the descriptor management and
> >>>>>>> the first
> >>>>>>>>>>>>>> register function.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >>>>>>> driver
> >>>>>>>>>>>>> to the new binding I was wondering about the internal PHY
> >>>>>>> detection:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >>>>>>> PHY
> >>>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >>>>>>> external).
> >>>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
> >>>>>>> legal for
> >>>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >>>>>>> feature
> >>>>>>>>>>>>> an internal PHY?
> >>>>>>>>>>>>> On the first glance that does not make too much sense, but apart
> >>>>>>> from
> >>>>>>>>>>>>> not being the correct binding to describe all of the SoCs
> >>>>>>> features I see
> >>>>>>>>>>>>> two scenarios:
> >>>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >>>>>>> because it
> >>>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >>>>>>> For
> >>>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
> >>>>>>> SoC go
> >>>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >>>>>>> external
> >>>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >>>>>>> avoided.
> >>>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >>>>>>> switch
> >>>>>>>>>>>>> IC or some other network circuitry, for instance fibre
> >>>>>>> connectors.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>>>>>>> allwinner,use-internal-phy;
> >>>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >>>>>>> compatible
> >>>>>>>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>>>>>>> headaches later. I think we can still fix this with a followup
> >>>>>>> patch
> >>>>>>>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>> Andre.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>>>>>>> I will try to find a way to use it
> >>>>>>>>>>>
> >>>>>>>>>>> Can you provide a link?
> >>>>>>>>>>
> >>>>>>>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >>>>>>> what
> >>>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>>>>>>
> >>>>>>>>> I can understand Chen-Yu's concerns, but ...
> >>>>>>>>>
> >>>>>>>>>> For each soc the internal PHY mode is know and setted in
> >>>>>>> emac_variant/internal_phy
> >>>>>>>>>> So its not a problem.
> >>>>>>>>>
> >>>>>>>>> that is true as well, at least for now.
> >>>>>>>>>
> >>>>>>>>> So while I agree that having a separate property to indicate
> >>>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
> >>>>>>>>> to use this easier approach and piggy back on the existing
> >>>>>>>>> phy-mode property.
> >>>>>>>>
> >>>>>>>> We're trying to fix an issue that works for now too.
> >>>>>>>>
> >>>>>>>> If we want to consider future weird cases, then we must
> >>>>>>>> consider all of them. And the phy mode changing is definitely
> >>>>>>>> not really far fetched.
> >>>>>>>>
> >>>>>>>> I agree with Chen-Yu, and I really feel like the compatible
> >>>>>>>> solution you suggested would cover both your concerns, and
> >>>>>>>> ours.
> >>>>>>>
> >>>>>>> So something like this?
> >>>>>>> emac: emac@1c30000 {
> >>>>>>> compatible = "allwinner,sun8i-h3-emac";
> >>>>>>> ...
> >>>>>>> phy-mode = "mii";
> >>>>>>> phy-handle = <&int_mii_phy>;
> >>>>>>> ...
> >>>>>>>
> >>>>>>> mdio: mdio {
> >>>>>>> #address-cells = <1>;
> >>>>>>> #size-cells = <0>;
> >>>>>>> int_mii_phy: ethernet-phy@1 {
> >>>>>>> compatible = "allwinner,sun8i-h3-ephy";
> >>>>>>> syscon = <&syscon>;
> >>>>>>
> >>>>>> The MAC still needs to set some bits of syscon register.
> >>>>>
> >>>>> Yes, the syscon property needs also to be in the MAC node, that
> >>>>> was meant to be somewhere in the second "..." ;-)
> >>>>>
> >>>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> >>>>> to make it actually discoverable via MDIO, I wonder if we could change
> >>>>> this to:
> >>>>> 1) have the DT as described here
> >>>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
> >>>>> phy-handle and check the compatible string there.
> >>>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> >>>>> to make it respond when the MDIO driver queries its bus.
> >>>>>
> >>>>> Or can a PHY driver set itself up (since we have clocks and resets
> >>>>> properties in there) *before* the MDIO bus gets scanned?
> >>>>> Chen-Yu's comment in the other mail hints at that this is not easily
> >>>>> possible.
> >>>>
> >>>> I think adding phy compatible just make things more complex.
> >>>>
> >>>> I think the patch series I sent early fix all problems without more
> >>>> complexity since:
> >>>>
> >>>> - it does not add more DT stuff
> >>>> - it use an already used in tree DT phy-mode "internal" (and so phy
> >>>> mode PHY_INTERFACE_MODE_INTERNAL)
> >>>
> >>> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
> >>
> >> No it's no longer undocumented since [1]
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
> >>
> >> Due to the timezone difference, you guys have already managed to have
> >> several exchanges, hopefully I will have a chance to review your
> >> discussions a little later today.
> >
> > Hello
> >
> > I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1431579.html
> > Could you confirm that internal is only meant for "non xMII internal protocol"
>
> Yes that's what is it meant for. There are possibly two ways here:
>
> 1) assuming there is already a specific PHY driver for that internal
> PHY, you should have this PHY driver set PHY_IS_INTERNAL (see bcm63xx.c
> and bcm7xxx.c that do that) and so you would know that you did bind to
> the correct internal PHY driver. Problem with that is if you need to
> perform a particular action such that you will successfully bind to the
> internal PHY (e.g: power on, reset, etc.)
>
> 2) We could create a new set of phy-mode values that are, e.g:
>
> 'internal-mii': internal MII connection to the PHY
>
> and so on in order to cover the internal variants of those modes. I am
> not sure this is strictly needed here though.
Or perhaps a phy-location = "external|internal" ?
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-07-02 8:36 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-07-02 8:36 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jul 01, 2017 at 02:42:14PM -0700, Florian Fainelli wrote:
> On 30/06/2017 23:53, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
> >> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> >>>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 27/06/17 11:23, Icenowy Zheng wrote:
> >>>>>>
> >>>>>>
> >>>>>> ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
> >>>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>>>>>>
> >>>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>>>>>>> <clabbe.montjoie@gmail.com> wrote:
> >>>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> >>>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>>>>>>> allwinner.
> >>>>>>>>>>>>>> In fact the only common part is the descriptor management and
> >>>>>>> the first
> >>>>>>>>>>>>>> register function.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >>>>>>> driver
> >>>>>>>>>>>>> to the new binding I was wondering about the internal PHY
> >>>>>>> detection:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >>>>>>> PHY
> >>>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >>>>>>> external).
> >>>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
> >>>>>>> legal for
> >>>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >>>>>>> feature
> >>>>>>>>>>>>> an internal PHY?
> >>>>>>>>>>>>> On the first glance that does not make too much sense, but apart
> >>>>>>> from
> >>>>>>>>>>>>> not being the correct binding to describe all of the SoCs
> >>>>>>> features I see
> >>>>>>>>>>>>> two scenarios:
> >>>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >>>>>>> because it
> >>>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >>>>>>> For
> >>>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
> >>>>>>> SoC go
> >>>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >>>>>>> external
> >>>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >>>>>>> avoided.
> >>>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >>>>>>> switch
> >>>>>>>>>>>>> IC or some other network circuitry, for instance fibre
> >>>>>>> connectors.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>>>>>>> allwinner,use-internal-phy;
> >>>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >>>>>>> compatible
> >>>>>>>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>>>>>>> headaches later. I think we can still fix this with a followup
> >>>>>>> patch
> >>>>>>>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>> Andre.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>>>>>>> I will try to find a way to use it
> >>>>>>>>>>>
> >>>>>>>>>>> Can you provide a link?
> >>>>>>>>>>
> >>>>>>>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >>>>>>> what
> >>>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>>>>>>
> >>>>>>>>> I can understand Chen-Yu's concerns, but ...
> >>>>>>>>>
> >>>>>>>>>> For each soc the internal PHY mode is know and setted in
> >>>>>>> emac_variant/internal_phy
> >>>>>>>>>> So its not a problem.
> >>>>>>>>>
> >>>>>>>>> that is true as well, at least for now.
> >>>>>>>>>
> >>>>>>>>> So while I agree that having a separate property to indicate
> >>>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
> >>>>>>>>> to use this easier approach and piggy back on the existing
> >>>>>>>>> phy-mode property.
> >>>>>>>>
> >>>>>>>> We're trying to fix an issue that works for now too.
> >>>>>>>>
> >>>>>>>> If we want to consider future weird cases, then we must
> >>>>>>>> consider all of them. And the phy mode changing is definitely
> >>>>>>>> not really far fetched.
> >>>>>>>>
> >>>>>>>> I agree with Chen-Yu, and I really feel like the compatible
> >>>>>>>> solution you suggested would cover both your concerns, and
> >>>>>>>> ours.
> >>>>>>>
> >>>>>>> So something like this?
> >>>>>>> emac: emac at 1c30000 {
> >>>>>>> compatible = "allwinner,sun8i-h3-emac";
> >>>>>>> ...
> >>>>>>> phy-mode = "mii";
> >>>>>>> phy-handle = <&int_mii_phy>;
> >>>>>>> ...
> >>>>>>>
> >>>>>>> mdio: mdio {
> >>>>>>> #address-cells = <1>;
> >>>>>>> #size-cells = <0>;
> >>>>>>> int_mii_phy: ethernet-phy at 1 {
> >>>>>>> compatible = "allwinner,sun8i-h3-ephy";
> >>>>>>> syscon = <&syscon>;
> >>>>>>
> >>>>>> The MAC still needs to set some bits of syscon register.
> >>>>>
> >>>>> Yes, the syscon property needs also to be in the MAC node, that
> >>>>> was meant to be somewhere in the second "..." ;-)
> >>>>>
> >>>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> >>>>> to make it actually discoverable via MDIO, I wonder if we could change
> >>>>> this to:
> >>>>> 1) have the DT as described here
> >>>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
> >>>>> phy-handle and check the compatible string there.
> >>>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> >>>>> to make it respond when the MDIO driver queries its bus.
> >>>>>
> >>>>> Or can a PHY driver set itself up (since we have clocks and resets
> >>>>> properties in there) *before* the MDIO bus gets scanned?
> >>>>> Chen-Yu's comment in the other mail hints at that this is not easily
> >>>>> possible.
> >>>>
> >>>> I think adding phy compatible just make things more complex.
> >>>>
> >>>> I think the patch series I sent early fix all problems without more
> >>>> complexity since:
> >>>>
> >>>> - it does not add more DT stuff
> >>>> - it use an already used in tree DT phy-mode "internal" (and so phy
> >>>> mode PHY_INTERFACE_MODE_INTERNAL)
> >>>
> >>> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
> >>
> >> No it's no longer undocumented since [1]
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
> >>
> >> Due to the timezone difference, you guys have already managed to have
> >> several exchanges, hopefully I will have a chance to review your
> >> discussions a little later today.
> >
> > Hello
> >
> > I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1431579.html
> > Could you confirm that internal is only meant for "non xMII internal protocol"
>
> Yes that's what is it meant for. There are possibly two ways here:
>
> 1) assuming there is already a specific PHY driver for that internal
> PHY, you should have this PHY driver set PHY_IS_INTERNAL (see bcm63xx.c
> and bcm7xxx.c that do that) and so you would know that you did bind to
> the correct internal PHY driver. Problem with that is if you need to
> perform a particular action such that you will successfully bind to the
> internal PHY (e.g: power on, reset, etc.)
>
> 2) We could create a new set of phy-mode values that are, e.g:
>
> 'internal-mii': internal MII connection to the PHY
>
> and so on in order to cover the internal variants of those modes. I am
> not sure this is strictly needed here though.
Or perhaps a phy-location = "external|internal" ?
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-07-02 8:36 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-07-02 8:36 UTC (permalink / raw)
To: Florian Fainelli
Cc: Maxime Ripard, Andre Przywara, Icenowy Zheng, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Russell King, Catalin Marinas,
Will Deacon, Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o,
devicetree, netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Andrew Lunn, Heiko Stübner
On Sat, Jul 01, 2017 at 02:42:14PM -0700, Florian Fainelli wrote:
> On 30/06/2017 23:53, Corentin Labbe wrote:
> > On Tue, Jun 27, 2017 at 10:37:34AM -0700, Florian Fainelli wrote:
> >> On 06/27/2017 10:29 AM, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 02:37:48PM +0200, Corentin Labbe wrote:
> >>>> On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 27/06/17 11:23, Icenowy Zheng wrote:
> >>>>>>
> >>>>>>
> >>>>>> 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On 27/06/17 10:41, Maxime Ripard wrote:
> >>>>>>>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>>>>>>
> >>>>>>>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>>>>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>>>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>>>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>>>>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>>>>>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>>>>>>> allwinner.
> >>>>>>>>>>>>>> In fact the only common part is the descriptor management and
> >>>>>>> the first
> >>>>>>>>>>>>>> register function.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >>>>>>> driver
> >>>>>>>>>>>>> to the new binding I was wondering about the internal PHY
> >>>>>>> detection:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >>>>>>> PHY
> >>>>>>>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >>>>>>> external).
> >>>>>>>>>>>>> I think I raised this question before, but isn't it perfectly
> >>>>>>> legal for
> >>>>>>>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >>>>>>> feature
> >>>>>>>>>>>>> an internal PHY?
> >>>>>>>>>>>>> On the first glance that does not make too much sense, but apart
> >>>>>>> from
> >>>>>>>>>>>>> not being the correct binding to describe all of the SoCs
> >>>>>>> features I see
> >>>>>>>>>>>>> two scenarios:
> >>>>>>>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >>>>>>> because it
> >>>>>>>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >>>>>>> For
> >>>>>>>>>>>>> instance I have heard reports that the internal PHY makes the
> >>>>>>> SoC go
> >>>>>>>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >>>>>>> external
> >>>>>>>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >>>>>>> avoided.
> >>>>>>>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >>>>>>> switch
> >>>>>>>>>>>>> IC or some other network circuitry, for instance fibre
> >>>>>>> connectors.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>>>>>>> allwinner,use-internal-phy;
> >>>>>>>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >>>>>>> compatible
> >>>>>>>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>>>>>>> headaches later. I think we can still fix this with a followup
> >>>>>>> patch
> >>>>>>>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>> Andre.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>>>>>>> I will try to find a way to use it
> >>>>>>>>>>>
> >>>>>>>>>>> Can you provide a link?
> >>>>>>>>>>
> >>>>>>>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >>>>>>> what
> >>>>>>>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>>>>>>
> >>>>>>>>> I can understand Chen-Yu's concerns, but ...
> >>>>>>>>>
> >>>>>>>>>> For each soc the internal PHY mode is know and setted in
> >>>>>>> emac_variant/internal_phy
> >>>>>>>>>> So its not a problem.
> >>>>>>>>>
> >>>>>>>>> that is true as well, at least for now.
> >>>>>>>>>
> >>>>>>>>> So while I agree that having a separate property to indicate
> >>>>>>>>> the usage of the internal PHY would be nice, I am bit tempted
> >>>>>>>>> to use this easier approach and piggy back on the existing
> >>>>>>>>> phy-mode property.
> >>>>>>>>
> >>>>>>>> We're trying to fix an issue that works for now too.
> >>>>>>>>
> >>>>>>>> If we want to consider future weird cases, then we must
> >>>>>>>> consider all of them. And the phy mode changing is definitely
> >>>>>>>> not really far fetched.
> >>>>>>>>
> >>>>>>>> I agree with Chen-Yu, and I really feel like the compatible
> >>>>>>>> solution you suggested would cover both your concerns, and
> >>>>>>>> ours.
> >>>>>>>
> >>>>>>> So something like this?
> >>>>>>> emac: emac@1c30000 {
> >>>>>>> compatible = "allwinner,sun8i-h3-emac";
> >>>>>>> ...
> >>>>>>> phy-mode = "mii";
> >>>>>>> phy-handle = <&int_mii_phy>;
> >>>>>>> ...
> >>>>>>>
> >>>>>>> mdio: mdio {
> >>>>>>> #address-cells = <1>;
> >>>>>>> #size-cells = <0>;
> >>>>>>> int_mii_phy: ethernet-phy@1 {
> >>>>>>> compatible = "allwinner,sun8i-h3-ephy";
> >>>>>>> syscon = <&syscon>;
> >>>>>>
> >>>>>> The MAC still needs to set some bits of syscon register.
> >>>>>
> >>>>> Yes, the syscon property needs also to be in the MAC node, that
> >>>>> was meant to be somewhere in the second "..." ;-)
> >>>>>
> >>>>> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> >>>>> to make it actually discoverable via MDIO, I wonder if we could change
> >>>>> this to:
> >>>>> 1) have the DT as described here
> >>>>> 2) Let the dwmac-sun8i driver peek into the node referenced by
> >>>>> phy-handle and check the compatible string there.
> >>>>> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> >>>>> to make it respond when the MDIO driver queries its bus.
> >>>>>
> >>>>> Or can a PHY driver set itself up (since we have clocks and resets
> >>>>> properties in there) *before* the MDIO bus gets scanned?
> >>>>> Chen-Yu's comment in the other mail hints at that this is not easily
> >>>>> possible.
> >>>>
> >>>> I think adding phy compatible just make things more complex.
> >>>>
> >>>> I think the patch series I sent early fix all problems without more
> >>>> complexity since:
> >>>>
> >>>> - it does not add more DT stuff
> >>>> - it use an already used in tree DT phy-mode "internal" (and so phy
> >>>> mode PHY_INTERFACE_MODE_INTERNAL)
> >>>
> >>> - it doesn't cover all the concerns we ha> - it uses an undocumented value, with an unclear implication
> >>
> >> No it's no longer undocumented since [1]
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=29b65f5f97632722bb80969377e5b0e2401fb392
> >>
> >> Due to the timezone difference, you guys have already managed to have
> >> several exchanges, hopefully I will have a chance to review your
> >> discussions a little later today.
> >
> > Hello
> >
> > I wait for your comment before sending my reverts patch for http://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1431579.html
> > Could you confirm that internal is only meant for "non xMII internal protocol"
>
> Yes that's what is it meant for. There are possibly two ways here:
>
> 1) assuming there is already a specific PHY driver for that internal
> PHY, you should have this PHY driver set PHY_IS_INTERNAL (see bcm63xx.c
> and bcm7xxx.c that do that) and so you would know that you did bind to
> the correct internal PHY driver. Problem with that is if you need to
> perform a particular action such that you will successfully bind to the
> internal PHY (e.g: power on, reset, etc.)
>
> 2) We could create a new set of phy-mode values that are, e.g:
>
> 'internal-mii': internal MII connection to the PHY
>
> and so on in order to cover the internal variants of those modes. I am
> not sure this is strictly needed here though.
Or perhaps a phy-location = "external|internal" ?
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 16:00 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 16:00 UTC (permalink / raw)
To: Andre Przywara
Cc: Icenowy Zheng, Corentin Labbe, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, netdev,
linux-kernel, linux-sunxi, linux-arm-kernel, david.wu,
Florian Fainelli, Andrew Lunn, Heiko Stübner
[-- Attachment #1: Type: text/plain, Size: 6297 bytes --]
On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> Hi,
>
> On 27/06/17 11:23, Icenowy Zheng wrote:
> >
> >
> > 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara@arm.com> 写到:
> >> Hi,
> >>
> >> On 27/06/17 10:41, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>> Hi,
> >>>>
> >>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>
> >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>> <clabbe.montjoie@gmail.com> wrote:
> >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>> allwinner.
> >>>>>>>>> In fact the only common part is the descriptor management and
> >> the first
> >>>>>>>>> register function.
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >> driver
> >>>>>>>> to the new binding I was wondering about the internal PHY
> >> detection:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >> PHY
> >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >> external).
> >>>>>>>> I think I raised this question before, but isn't it perfectly
> >> legal for
> >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >> feature
> >>>>>>>> an internal PHY?
> >>>>>>>> On the first glance that does not make too much sense, but apart
> >> from
> >>>>>>>> not being the correct binding to describe all of the SoCs
> >> features I see
> >>>>>>>> two scenarios:
> >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >> because it
> >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >> For
> >>>>>>>> instance I have heard reports that the internal PHY makes the
> >> SoC go
> >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >> external
> >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >> avoided.
> >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >> switch
> >>>>>>>> IC or some other network circuitry, for instance fibre
> >> connectors.
> >>>>>>>>
> >>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>> allwinner,use-internal-phy;
> >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>
> >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >> compatible
> >>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>
> >>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>> headaches later. I think we can still fix this with a followup
> >> patch
> >>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Andre.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>> I will try to find a way to use it
> >>>>>>
> >>>>>> Can you provide a link?
> >>>>>
> >>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>
> >>>>>>
> >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >> what
> >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>
> >>>> I can understand Chen-Yu's concerns, but ...
> >>>>
> >>>>> For each soc the internal PHY mode is know and setted in
> >> emac_variant/internal_phy
> >>>>> So its not a problem.
> >>>>
> >>>> that is true as well, at least for now.
> >>>>
> >>>> So while I agree that having a separate property to indicate the
> >> usage
> >>>> of the internal PHY would be nice, I am bit tempted to use this
> >> easier
> >>>> approach and piggy back on the existing phy-mode property.
> >>>
> >>> We're trying to fix an issue that works for now too.
> >>>
> >>> If we want to consider future weird cases, then we must consider all
> >>> of them. And the phy mode changing is definitely not really far
> >>> fetched.
> >>>
> >>> I agree with Chen-Yu, and I really feel like the compatible solution
> >>> you suggested would cover both your concerns, and ours.
> >>
> >> So something like this?
> >> emac: emac@1c30000 {
> >> compatible = "allwinner,sun8i-h3-emac";
> >> ...
> >> phy-mode = "mii";
> >> phy-handle = <&int_mii_phy>;
> >> ...
> >>
> >> mdio: mdio {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> int_mii_phy: ethernet-phy@1 {
> >> compatible = "allwinner,sun8i-h3-ephy";
> >> syscon = <&syscon>;
> >
> > The MAC still needs to set some bits of syscon register.
>
> Yes, the syscon property needs also to be in the MAC node, that was
> meant to be somewhere in the second "..." ;-)
>
> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> to make it actually discoverable via MDIO, I wonder if we could change
> this to:
> 1) have the DT as described here
> 2) Let the dwmac-sun8i driver peek into the node referenced by
> phy-handle and check the compatible string there.
> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> to make it respond when the MDIO driver queries its bus.
That would be quite easy to do, and would be my implementation of
choice yes.
> Or can a PHY driver set itself up (since we have clocks and resets
> properties in there) *before* the MDIO bus gets scanned?
> Chen-Yu's comment in the other mail hints at that this is not easily
> possible.
Yeah, that's not easily doable, it would require your driver to probe
before your device has showed up, which is not quite what the driver
model is made like.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 16:00 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 16:00 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> Hi,
>
> On 27/06/17 11:23, Icenowy Zheng wrote:
> >
> >
> > ? 2017?6?27? GMT+08:00 ??6:15:58, Andre Przywara <andre.przywara@arm.com> ??:
> >> Hi,
> >>
> >> On 27/06/17 10:41, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>> Hi,
> >>>>
> >>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>
> >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>> <clabbe.montjoie@gmail.com> wrote:
> >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr? Przywara wrote:
> >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>> allwinner.
> >>>>>>>>> In fact the only common part is the descriptor management and
> >> the first
> >>>>>>>>> register function.
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >> driver
> >>>>>>>> to the new binding I was wondering about the internal PHY
> >> detection:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >> PHY
> >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >> external).
> >>>>>>>> I think I raised this question before, but isn't it perfectly
> >> legal for
> >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >> feature
> >>>>>>>> an internal PHY?
> >>>>>>>> On the first glance that does not make too much sense, but apart
> >> from
> >>>>>>>> not being the correct binding to describe all of the SoCs
> >> features I see
> >>>>>>>> two scenarios:
> >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >> because it
> >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >> For
> >>>>>>>> instance I have heard reports that the internal PHY makes the
> >> SoC go
> >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >> external
> >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >> avoided.
> >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >> switch
> >>>>>>>> IC or some other network circuitry, for instance fibre
> >> connectors.
> >>>>>>>>
> >>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>> allwinner,use-internal-phy;
> >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>
> >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >> compatible
> >>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>
> >>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>> headaches later. I think we can still fix this with a followup
> >> patch
> >>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Andre.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>> I will try to find a way to use it
> >>>>>>
> >>>>>> Can you provide a link?
> >>>>>
> >>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>
> >>>>>>
> >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >> what
> >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>
> >>>> I can understand Chen-Yu's concerns, but ...
> >>>>
> >>>>> For each soc the internal PHY mode is know and setted in
> >> emac_variant/internal_phy
> >>>>> So its not a problem.
> >>>>
> >>>> that is true as well, at least for now.
> >>>>
> >>>> So while I agree that having a separate property to indicate the
> >> usage
> >>>> of the internal PHY would be nice, I am bit tempted to use this
> >> easier
> >>>> approach and piggy back on the existing phy-mode property.
> >>>
> >>> We're trying to fix an issue that works for now too.
> >>>
> >>> If we want to consider future weird cases, then we must consider all
> >>> of them. And the phy mode changing is definitely not really far
> >>> fetched.
> >>>
> >>> I agree with Chen-Yu, and I really feel like the compatible solution
> >>> you suggested would cover both your concerns, and ours.
> >>
> >> So something like this?
> >> emac: emac at 1c30000 {
> >> compatible = "allwinner,sun8i-h3-emac";
> >> ...
> >> phy-mode = "mii";
> >> phy-handle = <&int_mii_phy>;
> >> ...
> >>
> >> mdio: mdio {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> int_mii_phy: ethernet-phy at 1 {
> >> compatible = "allwinner,sun8i-h3-ephy";
> >> syscon = <&syscon>;
> >
> > The MAC still needs to set some bits of syscon register.
>
> Yes, the syscon property needs also to be in the MAC node, that was
> meant to be somewhere in the second "..." ;-)
>
> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> to make it actually discoverable via MDIO, I wonder if we could change
> this to:
> 1) have the DT as described here
> 2) Let the dwmac-sun8i driver peek into the node referenced by
> phy-handle and check the compatible string there.
> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> to make it respond when the MDIO driver queries its bus.
That would be quite easy to do, and would be my implementation of
choice yes.
> Or can a PHY driver set itself up (since we have clocks and resets
> properties in there) *before* the MDIO bus gets scanned?
> Chen-Yu's comment in the other mail hints at that this is not easily
> possible.
Yeah, that's not easily doable, it would require your driver to probe
before your device has showed up, which is not quite what the driver
model is made like.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170627/d5a3db8e/attachment.sig>
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i
@ 2017-06-27 16:00 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-27 16:00 UTC (permalink / raw)
To: Andre Przywara
Cc: Icenowy Zheng, Corentin Labbe, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue-qxv4g6HH51o, devicetree,
netdev, linux-kernel, linux-sunxi, linux-arm-kernel,
david.wu-TNX95d0MmH7DzftRWevZcw, Florian Fainelli, Andrew Lunn,
Heiko Stübner
[-- Attachment #1: Type: text/plain, Size: 6670 bytes --]
On Tue, Jun 27, 2017 at 11:33:56AM +0100, Andre Przywara wrote:
> Hi,
>
> On 27/06/17 11:23, Icenowy Zheng wrote:
> >
> >
> > 于 2017年6月27日 GMT+08:00 下午6:15:58, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 写到:
> >> Hi,
> >>
> >> On 27/06/17 10:41, Maxime Ripard wrote:
> >>> On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote:
> >>>> Hi,
> >>>>
> >>>> (CC:ing some people from that Rockchip dmwac series)
> >>>>
> >>>> On 27/06/17 09:21, Corentin Labbe wrote:
> >>>>> On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote:
> >>>>>> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe
> >>>>>> <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>>>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, André Przywara wrote:
> >>>>>>>> On 31/05/17 08:18, Corentin Labbe wrote:
> >>>>>>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by
> >>>>>>>>> allwinner.
> >>>>>>>>> In fact the only common part is the descriptor management and
> >> the first
> >>>>>>>>> register function.
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I know I am a bit late with this, but while adapting the U-Boot
> >> driver
> >>>>>>>> to the new binding I was wondering about the internal PHY
> >> detection:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So here you seem to deduce the usage of the internal PHY by the
> >> PHY
> >>>>>>>> interface specified in the DT (MII = internal, RGMII =
> >> external).
> >>>>>>>> I think I raised this question before, but isn't it perfectly
> >> legal for
> >>>>>>>> a board to use MII with an external PHY even on those SoCs that
> >> feature
> >>>>>>>> an internal PHY?
> >>>>>>>> On the first glance that does not make too much sense, but apart
> >> from
> >>>>>>>> not being the correct binding to describe all of the SoCs
> >> features I see
> >>>>>>>> two scenarios:
> >>>>>>>> 1) A board vendor might choose to not use the internal PHY
> >> because it
> >>>>>>>> has bugs, lacks features (configurability) or has other issues.
> >> For
> >>>>>>>> instance I have heard reports that the internal PHY makes the
> >> SoC go
> >>>>>>>> rather hot, possibly limiting the CPU frequency. By using an
> >> external
> >>>>>>>> MII PHY (which are still cheaper than RGMII PHYs) this can be
> >> avoided.
> >>>>>>>> 2) A PHY does not necessarily need to be directly connected to
> >>>>>>>> magnetics. Indeed quite some boards use (RG)MII to connect to a
> >> switch
> >>>>>>>> IC or some other network circuitry, for instance fibre
> >> connectors.
> >>>>>>>>
> >>>>>>>> So I was wondering if we would need an explicit:
> >>>>>>>> allwinner,use-internal-phy;
> >>>>>>>> boolean DT property to signal the usage of the internal PHY?
> >>>>>>>> Alternatively we could go with the negative version:
> >>>>>>>> allwinner,disable-internal-phy;
> >>>>>>>>
> >>>>>>>> Or what about introducing a new "allwinner,internal-mii-phy"
> >> compatible
> >>>>>>>> string for the *PHY* node and use that?
> >>>>>>>>
> >>>>>>>> I just want to avoid that we introduce a binding that causes us
> >>>>>>>> headaches later. I think we can still fix this with a followup
> >> patch
> >>>>>>>> before the driver and its binding hit a release kernel.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Andre.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I just see some patch, where "phy-mode = internal" is valid.
> >>>>>>> I will try to find a way to use it
> >>>>>>
> >>>>>> Can you provide a link?
> >>>>>
> >>>>> https://lkml.org/lkml/2017/6/23/479
> >>>>>
> >>>>>>
> >>>>>> I'm not a fan of using phy-mode for this. There's no guarantee
> >> what
> >>>>>> mode the internal PHY uses. That's what phy-mode is for.
> >>>>
> >>>> I can understand Chen-Yu's concerns, but ...
> >>>>
> >>>>> For each soc the internal PHY mode is know and setted in
> >> emac_variant/internal_phy
> >>>>> So its not a problem.
> >>>>
> >>>> that is true as well, at least for now.
> >>>>
> >>>> So while I agree that having a separate property to indicate the
> >> usage
> >>>> of the internal PHY would be nice, I am bit tempted to use this
> >> easier
> >>>> approach and piggy back on the existing phy-mode property.
> >>>
> >>> We're trying to fix an issue that works for now too.
> >>>
> >>> If we want to consider future weird cases, then we must consider all
> >>> of them. And the phy mode changing is definitely not really far
> >>> fetched.
> >>>
> >>> I agree with Chen-Yu, and I really feel like the compatible solution
> >>> you suggested would cover both your concerns, and ours.
> >>
> >> So something like this?
> >> emac: emac@1c30000 {
> >> compatible = "allwinner,sun8i-h3-emac";
> >> ...
> >> phy-mode = "mii";
> >> phy-handle = <&int_mii_phy>;
> >> ...
> >>
> >> mdio: mdio {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> int_mii_phy: ethernet-phy@1 {
> >> compatible = "allwinner,sun8i-h3-ephy";
> >> syscon = <&syscon>;
> >
> > The MAC still needs to set some bits of syscon register.
>
> Yes, the syscon property needs also to be in the MAC node, that was
> meant to be somewhere in the second "..." ;-)
>
> But now since Chen-Yu mentioned that we need to set up the PHY *first*
> to make it actually discoverable via MDIO, I wonder if we could change
> this to:
> 1) have the DT as described here
> 2) Let the dwmac-sun8i driver peek into the node referenced by
> phy-handle and check the compatible string there.
> 3) If that matches some allwinner internal PHY name, it sets up the PHY
> to make it respond when the MDIO driver queries its bus.
That would be quite easy to do, and would be my implementation of
choice yes.
> Or can a PHY driver set itself up (since we have clocks and resets
> properties in there) *before* the MDIO bus gets scanned?
> Chen-Yu's comment in the other mail hints at that this is not easily
> possible.
Yeah, that's not easily doable, it would require your driver to probe
before your device has showed up, which is not quite what the driver
model is made like.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 06/21] arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
This patch add the dt node for the syscon register present on the
Allwinner H3/H5
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock..
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index d0067fec99de..3a28be5ab641 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -83,6 +83,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon@1c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 06/21] arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
This patch add the dt node for the syscon register present on the
Allwinner H3/H5
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock..
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index d0067fec99de..3a28be5ab641 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -83,6 +83,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon at 1c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
dma: dma-controller at 01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 06/21] arm: sun8i: sunxi-h3-h5: Add dt node for the syscon control module
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
This patch add the dt node for the syscon register present on the
Allwinner H3/H5
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock..
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index d0067fec99de..3a28be5ab641 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -83,6 +83,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon@1c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
dma: dma-controller@01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 07/21] arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000
speed.
This patch enable the dwmac-sun8i on Allwinner H3/H5 SoC Device-tree.
SoC H3/H5 have an internal PHY, so optionals syscon and ephy are set.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 3a28be5ab641..9e4a496f3cca 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -285,6 +285,14 @@
interrupt-controller;
#interrupt-cells = <3>;
+ emac_rgmii_pins: emac0 {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+ "PD5", "PD7", "PD8", "PD9", "PD10",
+ "PD12", "PD13", "PD15", "PD16", "PD17";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
i2c0_pins: i2c0 {
pins = "PA11", "PA12";
function = "i2c0";
@@ -381,6 +389,32 @@
clocks = <&osc24M>;
};
+ emac: ethernet@1c30000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+
spi0: spi@01c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 07/21] arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000
speed.
This patch enable the dwmac-sun8i on Allwinner H3/H5 SoC Device-tree.
SoC H3/H5 have an internal PHY, so optionals syscon and ephy are set.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 3a28be5ab641..9e4a496f3cca 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -285,6 +285,14 @@
interrupt-controller;
#interrupt-cells = <3>;
+ emac_rgmii_pins: emac0 {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+ "PD5", "PD7", "PD8", "PD9", "PD10",
+ "PD12", "PD13", "PD15", "PD16", "PD17";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
i2c0_pins: i2c0 {
pins = "PA11", "PA12";
function = "i2c0";
@@ -381,6 +389,32 @@
clocks = <&osc24M>;
};
+ emac: ethernet at 1c30000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+
spi0: spi at 01c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 07/21] arm: sun8i: sunxi-h3-h5: add dwmac-sun8i ethernet driver
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000
speed.
This patch enable the dwmac-sun8i on Allwinner H3/H5 SoC Device-tree.
SoC H3/H5 have an internal PHY, so optionals syscon and ephy are set.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 3a28be5ab641..9e4a496f3cca 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -285,6 +285,14 @@
interrupt-controller;
#interrupt-cells = <3>;
+ emac_rgmii_pins: emac0 {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+ "PD5", "PD7", "PD8", "PD9", "PD10",
+ "PD12", "PD13", "PD15", "PD16", "PD17";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
i2c0_pins: i2c0 {
pins = "PA11", "PA12";
function = "i2c0";
@@ -381,6 +389,32 @@
clocks = <&osc24M>;
};
+ emac: ethernet@1c30000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+
spi0: spi@01c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 08/21] arm: sun8i: orangepi-pc: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI PC.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 1a044b17d6c6..998b60f8d295 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -113,6 +114,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 08/21] arm: sun8i: orangepi-pc: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i hardware is present on the Orange PI PC.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 1a044b17d6c6..998b60f8d295 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -113,6 +114,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 08/21] arm: sun8i: orangepi-pc: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI PC.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 1a044b17d6c6..998b60f8d295 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -113,6 +114,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 09/21] arm: sun8i: orangepi-zero: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI Zero.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index 9e8b082c134f..dd3525a0f06a 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -57,6 +57,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &xr819;
};
@@ -103,6 +104,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 09/21] arm: sun8i: orangepi-zero: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i hardware is present on the Orange PI Zero.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index 9e8b082c134f..dd3525a0f06a 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -57,6 +57,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &xr819;
};
@@ -103,6 +104,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 09/21] arm: sun8i: orangepi-zero: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI Zero.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index 9e8b082c134f..dd3525a0f06a 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -57,6 +57,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &xr819;
};
@@ -103,6 +104,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 10/21] arm: sun8i: orangepi-one: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI One.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 5fea430e0eb1..6880268e8b87 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -97,6 +98,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 10/21] arm: sun8i: orangepi-one: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i hardware is present on the Orange PI One.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 5fea430e0eb1..6880268e8b87 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -97,6 +98,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 10/21] arm: sun8i: orangepi-one: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI One.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 5fea430e0eb1..6880268e8b87 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -97,6 +98,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 11/21] arm: sun8i: orangepi-2: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI 2.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 8ff71b1bb45b..17cdeae19c6f 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &rtl8189;
};
@@ -117,6 +118,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 11/21] arm: sun8i: orangepi-2: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i hardware is present on the Orange PI 2.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 8ff71b1bb45b..17cdeae19c6f 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &rtl8189;
};
@@ -117,6 +118,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 11/21] arm: sun8i: orangepi-2: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i hardware is present on the Orange PI 2.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 8ff71b1bb45b..17cdeae19c6f 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &rtl8189;
};
@@ -117,6 +118,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 12/21] arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet
port were changed from active low to active high.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
index 8b93f5c781a7..a10281b455f5 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
@@ -53,6 +53,11 @@
};
};
+&emac {
+ /* LEDs changed to active high on the plus */
+ /delete-property/ allwinner,leds-active-low;
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 12/21] arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet
port were changed from active low to active high.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
index 8b93f5c781a7..a10281b455f5 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
@@ -53,6 +53,11 @@
};
};
+&emac {
+ /* LEDs changed to active high on the plus */
+ /delete-property/ allwinner,leds-active-low;
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 12/21] arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet
port were changed from active low to active high.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
index 8b93f5c781a7..a10281b455f5 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
@@ -53,6 +53,11 @@
};
};
+&emac {
+ /* LEDs changed to active high on the plus */
+ /delete-property/ allwinner,leds-active-low;
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins_a>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 13/21] arm: sun8i: nanopi-neo: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i hardware is present on the NanoPi Neo.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
index 8d2cc6e9a03f..78f6c24952dd 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -46,3 +46,10 @@
model = "FriendlyARM NanoPi NEO";
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 13/21] arm: sun8i: nanopi-neo: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i hardware is present on the NanoPi Neo.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
index 8d2cc6e9a03f..78f6c24952dd 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -46,3 +46,10 @@
model = "FriendlyARM NanoPi NEO";
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 13/21] arm: sun8i: nanopi-neo: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i hardware is present on the NanoPi Neo.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
index 8d2cc6e9a03f..78f6c24952dd 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -46,3 +46,10 @@
model = "FriendlyARM NanoPi NEO";
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 14/21] arm64: allwinner: sun50i-a64: Add dt node for the syscon control module
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
This patch add the dt node for the syscon register present on the
Allwinner A64.
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 90dc4ec79485..2eeba0d44074 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -129,6 +129,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon@1c00000 {
+ compatible = "allwinner,sun50i-a64-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 14/21] arm64: allwinner: sun50i-a64: Add dt node for the syscon control module
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
This patch add the dt node for the syscon register present on the
Allwinner A64.
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 90dc4ec79485..2eeba0d44074 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -129,6 +129,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon at 1c00000 {
+ compatible = "allwinner,sun50i-a64-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
mmc0: mmc at 1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 14/21] arm64: allwinner: sun50i-a64: Add dt node for the syscon control module
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
This patch add the dt node for the syscon register present on the
Allwinner A64.
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 90dc4ec79485..2eeba0d44074 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -129,6 +129,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon@1c00000 {
+ compatible = "allwinner,sun50i-a64-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 15/21] arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
connections. It is very similar to the device found in the Allwinner
H3, but lacks the internal 100 Mbit PHY and its associated control
bits.
This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
it disabled at this level.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 35 +++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2eeba0d44074..7a07353ac1f6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -309,6 +309,21 @@
bias-pull-up;
};
+ rmii_pins: rmii_pins {
+ pins = "PD10", "PD11", "PD13", "PD14", "PD17",
+ "PD18", "PD19", "PD20", "PD22", "PD23";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
+ rgmii_pins: rgmii_pins {
+ pins = "PD8", "PD9", "PD10", "PD11", "PD12",
+ "PD13", "PD15", "PD16", "PD17", "PD18",
+ "PD19", "PD20", "PD21", "PD22", "PD23";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
@@ -433,6 +448,26 @@
#size-cells = <0>;
};
+ emac: ethernet@1c30000 {
+ compatible = "allwinner,sun50i-a64-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x100>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 15/21] arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
connections. It is very similar to the device found in the Allwinner
H3, but lacks the internal 100 Mbit PHY and its associated control
bits.
This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
it disabled at this level.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 35 +++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2eeba0d44074..7a07353ac1f6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -309,6 +309,21 @@
bias-pull-up;
};
+ rmii_pins: rmii_pins {
+ pins = "PD10", "PD11", "PD13", "PD14", "PD17",
+ "PD18", "PD19", "PD20", "PD22", "PD23";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
+ rgmii_pins: rgmii_pins {
+ pins = "PD8", "PD9", "PD10", "PD11", "PD12",
+ "PD13", "PD15", "PD16", "PD17", "PD18",
+ "PD19", "PD20", "PD21", "PD22", "PD23";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
uart0_pins_a: uart0 at 0 {
pins = "PB8", "PB9";
function = "uart0";
@@ -433,6 +448,26 @@
#size-cells = <0>;
};
+ emac: ethernet at 1c30000 {
+ compatible = "allwinner,sun50i-a64-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x100>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
gic: interrupt-controller at 1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 15/21] arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
connections. It is very similar to the device found in the Allwinner
H3, but lacks the internal 100 Mbit PHY and its associated control
bits.
This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
it disabled at this level.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 35 +++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2eeba0d44074..7a07353ac1f6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -309,6 +309,21 @@
bias-pull-up;
};
+ rmii_pins: rmii_pins {
+ pins = "PD10", "PD11", "PD13", "PD14", "PD17",
+ "PD18", "PD19", "PD20", "PD22", "PD23";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
+ rgmii_pins: rgmii_pins {
+ pins = "PD8", "PD9", "PD10", "PD11", "PD12",
+ "PD13", "PD15", "PD16", "PD17", "PD18",
+ "PD19", "PD20", "PD21", "PD22", "PD23";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
@@ -433,6 +448,26 @@
#size-cells = <0>;
};
+ emac: ethernet@1c30000 {
+ compatible = "allwinner,sun50i-a64-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x100>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 16/21] arm64: allwinner: pine64: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i hardware is present on the pine64
It uses an external PHY via RMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7c533b6d4ba9..08cda24ea194 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -78,6 +78,15 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rmii_pins>;
+ phy-mode = "rmii";
+ phy-handle = <&ext_rmii_phy1>;
+ status = "okay";
+
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -88,6 +97,13 @@
bias-pull-up;
};
+&mdio {
+ ext_rmii_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 16/21] arm64: allwinner: pine64: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i hardware is present on the pine64
It uses an external PHY via RMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7c533b6d4ba9..08cda24ea194 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -78,6 +78,15 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rmii_pins>;
+ phy-mode = "rmii";
+ phy-handle = <&ext_rmii_phy1>;
+ status = "okay";
+
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -88,6 +97,13 @@
bias-pull-up;
};
+&mdio {
+ ext_rmii_phy1: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 16/21] arm64: allwinner: pine64: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i hardware is present on the pine64
It uses an external PHY via RMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7c533b6d4ba9..08cda24ea194 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -78,6 +78,15 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rmii_pins>;
+ phy-mode = "rmii";
+ phy-handle = <&ext_rmii_phy1>;
+ status = "okay";
+
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -88,6 +97,13 @@
bias-pull-up;
};
+&mdio {
+ ext_rmii_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 17/21] arm64: allwinner: pine64-plus: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i hardware is present on the pine64 plus.
It uses an external PHY rtl8211e via RGMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
.../arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 790d14daaa6a..24f1aac366d6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -46,5 +46,20 @@
model = "Pine64+";
compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
- /* TODO: Camera, Ethernet PHY, touchscreen, etc. */
+ /* TODO: Camera, touchscreen, etc. */
+};
+
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 17/21] arm64: allwinner: pine64-plus: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i hardware is present on the pine64 plus.
It uses an external PHY rtl8211e via RGMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
.../arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 790d14daaa6a..24f1aac366d6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -46,5 +46,20 @@
model = "Pine64+";
compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
- /* TODO: Camera, Ethernet PHY, touchscreen, etc. */
+ /* TODO: Camera, touchscreen, etc. */
+};
+
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 17/21] arm64: allwinner: pine64-plus: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i hardware is present on the pine64 plus.
It uses an external PHY rtl8211e via RGMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 790d14daaa6a..24f1aac366d6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -46,5 +46,20 @@
model = "Pine64+";
compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
- /* TODO: Camera, Ethernet PHY, touchscreen, etc. */
+ /* TODO: Camera, touchscreen, etc. */
+};
+
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
};
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 18/21] arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
The dwmac-sun8i hardware is present on the BananaPi M64.
It uses an external PHY rtl8211e via RGMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 6872135d7f84..0d1f026d831a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -67,6 +67,14 @@
};
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -77,6 +85,13 @@
bias-pull-up;
};
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 18/21] arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
The dwmac-sun8i hardware is present on the BananaPi M64.
It uses an external PHY rtl8211e via RGMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 6872135d7f84..0d1f026d831a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -67,6 +67,14 @@
};
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -77,6 +85,13 @@
bias-pull-up;
};
+&mdio {
+ ext_rgmii_phy: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread* [PATCH v6 18/21] arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
The dwmac-sun8i hardware is present on the BananaPi M64.
It uses an external PHY rtl8211e via RGMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 6872135d7f84..0d1f026d831a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -67,6 +67,14 @@
};
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -77,6 +85,13 @@
bias-pull-up;
};
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 19/21] arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
Enable the dwmac-sun8i driver in the sunxi default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 5cd5dd70bc83..504e02238031 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -40,6 +40,7 @@ CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
CONFIG_NETDEVICES=y
CONFIG_SUN4I_EMAC=y
+CONFIG_DWMAC_SUN8I=y
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 19/21] arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
Enable the dwmac-sun8i driver in the sunxi default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 5cd5dd70bc83..504e02238031 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -40,6 +40,7 @@ CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
CONFIG_NETDEVICES=y
CONFIG_SUN4I_EMAC=y
+CONFIG_DWMAC_SUN8I=y
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 19/21] arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
Enable the dwmac-sun8i driver in the sunxi default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 5cd5dd70bc83..504e02238031 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -40,6 +40,7 @@ CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
CONFIG_NETDEVICES=y
CONFIG_SUN4I_EMAC=y
+CONFIG_DWMAC_SUN8I=y
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 20/21] arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
Enable the dwmac-sun8i driver in the multi_v7 default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 705d908e004a..60c0c01002c2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -257,6 +257,7 @@ CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_PLATFORM=y
CONFIG_DWMAC_DWC_QOS_ETH=y
+CONFIG_DWMAC_SUN8I=y
CONFIG_TI_CPSW=y
CONFIG_XILINX_EMACLITE=y
CONFIG_AT803X_PHY=y
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 20/21] arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
Enable the dwmac-sun8i driver in the multi_v7 default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 705d908e004a..60c0c01002c2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -257,6 +257,7 @@ CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_PLATFORM=y
CONFIG_DWMAC_DWC_QOS_ETH=y
+CONFIG_DWMAC_SUN8I=y
CONFIG_TI_CPSW=y
CONFIG_XILINX_EMACLITE=y
CONFIG_AT803X_PHY=y
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 20/21] arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
Enable the dwmac-sun8i driver in the multi_v7 default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 705d908e004a..60c0c01002c2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -257,6 +257,7 @@ CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_PLATFORM=y
CONFIG_DWMAC_DWC_QOS_ETH=y
+CONFIG_DWMAC_SUN8I=y
CONFIG_TI_CPSW=y
CONFIG_XILINX_EMACLITE=y
CONFIG_AT803X_PHY=y
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 21/21] arm64: defconfig: Enable dwmac-sun8i driver on defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
Cc: devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi,
Corentin Labbe
Enable the dwmac-sun8i ethernet driver as a module in the ARM64 defconfig.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 000de61802a1..fd7d22b8480c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -191,6 +191,7 @@ CONFIG_RAVB=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=m
+CONFIG_DWMAC_SUN8I=m
CONFIG_MDIO_BUS_MUX_MMIOREG=y
CONFIG_MESON_GXL_PHY=m
CONFIG_MICREL_PHY=y
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 21/21] arm64: defconfig: Enable dwmac-sun8i driver on defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: linux-arm-kernel
Enable the dwmac-sun8i ethernet driver as a module in the ARM64 defconfig.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 000de61802a1..fd7d22b8480c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -191,6 +191,7 @@ CONFIG_RAVB=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=m
+CONFIG_DWMAC_SUN8I=m
CONFIG_MDIO_BUS_MUX_MMIOREG=y
CONFIG_MESON_GXL_PHY=m
CONFIG_MICREL_PHY=y
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* [PATCH v6 21/21] arm64: defconfig: Enable dwmac-sun8i driver on defconfig
@ 2017-05-31 7:18 ` Corentin Labbe
0 siblings, 0 replies; 148+ messages in thread
From: Corentin Labbe @ 2017-05-31 7:18 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Corentin Labbe
Enable the dwmac-sun8i ethernet driver as a module in the ARM64 defconfig.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 000de61802a1..fd7d22b8480c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -191,6 +191,7 @@ CONFIG_RAVB=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=m
+CONFIG_DWMAC_SUN8I=m
CONFIG_MDIO_BUS_MUX_MMIOREG=y
CONFIG_MESON_GXL_PHY=m
CONFIG_MICREL_PHY=y
--
2.13.0
^ permalink raw reply related [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-01 18:58 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-01 18:58 UTC (permalink / raw)
To: clabbe.montjoie
Cc: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi
From: Corentin Labbe <clabbe.montjoie@gmail.com>
Date: Wed, 31 May 2017 09:18:31 +0200
> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> present on Allwinner H3/H5/A83T/A64 SoCs.
Series applied, but wow that's a lot of DT file changes :-(
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-01 18:58 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-01 18:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Corentin Labbe <clabbe.montjoie@gmail.com>
Date: Wed, 31 May 2017 09:18:31 +0200
> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> present on Allwinner H3/H5/A83T/A64 SoCs.
Series applied, but wow that's a lot of DT file changes :-(
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-01 18:58 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-01 18:58 UTC (permalink / raw)
To: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed, 31 May 2017 09:18:31 +0200
> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> present on Allwinner H3/H5/A83T/A64 SoCs.
Series applied, but wow that's a lot of DT file changes :-(
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 6:37 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 6:37 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie, robh+dt, mark.rutland, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> From: Corentin Labbe <clabbe.montjoie@gmail.com>
> Date: Wed, 31 May 2017 09:18:31 +0200
>
> > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > present on Allwinner H3/H5/A83T/A64 SoCs.
>
> Series applied, but wow that's a lot of DT file changes :-(
The DT patches should not go through your tree, but arm-soc, so I
guess this is not an issue for you?
Maximee
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 6:37 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 6:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> From: Corentin Labbe <clabbe.montjoie@gmail.com>
> Date: Wed, 31 May 2017 09:18:31 +0200
>
> > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > present on Allwinner H3/H5/A83T/A64 SoCs.
>
> Series applied, but wow that's a lot of DT file changes :-(
The DT patches should not go through your tree, but arm-soc, so I
guess this is not an issue for you?
Maximee
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170602/68bcf6b2/attachment-0001.sig>
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 6:37 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 6:37 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed, 31 May 2017 09:18:31 +0200
>
> > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > present on Allwinner H3/H5/A83T/A64 SoCs.
>
> Series applied, but wow that's a lot of DT file changes :-(
The DT patches should not go through your tree, but arm-soc, so I
guess this is not an issue for you?
Maximee
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 9:13 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 9:13 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie, robh+dt, mark.rutland, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]
On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
> > Date: Wed, 31 May 2017 09:18:31 +0200
> >
> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> >
> > Series applied, but wow that's a lot of DT file changes :-(
>
> The DT patches should not go through your tree, but arm-soc, so I
> guess this is not an issue for you?
Ok, so I saw that you actually merged them. Can you revert or drop
that merge for the DT part?
This will generate a lot of conflicts with our tree, and I'm not sure
this would be efficient to make you take all the entirely unrelated to
next patches.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 9:13 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 9:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
> > Date: Wed, 31 May 2017 09:18:31 +0200
> >
> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> >
> > Series applied, but wow that's a lot of DT file changes :-(
>
> The DT patches should not go through your tree, but arm-soc, so I
> guess this is not an issue for you?
Ok, so I saw that you actually merged them. Can you revert or drop
that merge for the DT part?
This will generate a lot of conflicts with our tree, and I'm not sure
this would be efficient to make you take all the entirely unrelated to
next patches.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170602/ce408b1a/attachment.sig>
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 9:13 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 9:13 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 926 bytes --]
On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> > From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Wed, 31 May 2017 09:18:31 +0200
> >
> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> >
> > Series applied, but wow that's a lot of DT file changes :-(
>
> The DT patches should not go through your tree, but arm-soc, so I
> guess this is not an issue for you?
Ok, so I saw that you actually merged them. Can you revert or drop
that merge for the DT part?
This will generate a lot of conflicts with our tree, and I'm not sure
this would be efficient to make you take all the entirely unrelated to
next patches.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 14:22 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-02 14:22 UTC (permalink / raw)
To: maxime.ripard
Cc: clabbe.montjoie, robh+dt, mark.rutland, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Date: Fri, 2 Jun 2017 11:13:20 +0200
> On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
>> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
>> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
>> > Date: Wed, 31 May 2017 09:18:31 +0200
>> >
>> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> > > present on Allwinner H3/H5/A83T/A64 SoCs.
>> >
>> > Series applied, but wow that's a lot of DT file changes :-(
>>
>> The DT patches should not go through your tree, but arm-soc, so I
>> guess this is not an issue for you?
>
> Ok, so I saw that you actually merged them. Can you revert or drop
> that merge for the DT part?
>
> This will generate a lot of conflicts with our tree, and I'm not sure
> this would be efficient to make you take all the entirely unrelated to
> next patches.
Please tell me which specific changes to revert.
Thank you.
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 14:22 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-02 14:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Date: Fri, 2 Jun 2017 11:13:20 +0200
> On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
>> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
>> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
>> > Date: Wed, 31 May 2017 09:18:31 +0200
>> >
>> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> > > present on Allwinner H3/H5/A83T/A64 SoCs.
>> >
>> > Series applied, but wow that's a lot of DT file changes :-(
>>
>> The DT patches should not go through your tree, but arm-soc, so I
>> guess this is not an issue for you?
>
> Ok, so I saw that you actually merged them. Can you revert or drop
> that merge for the DT part?
>
> This will generate a lot of conflicts with our tree, and I'm not sure
> this would be efficient to make you take all the entirely unrelated to
> next patches.
Please tell me which specific changes to revert.
Thank you.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 14:22 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-02 14:22 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Date: Fri, 2 Jun 2017 11:13:20 +0200
> On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
>> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
>> > From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > Date: Wed, 31 May 2017 09:18:31 +0200
>> >
>> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> > > present on Allwinner H3/H5/A83T/A64 SoCs.
>> >
>> > Series applied, but wow that's a lot of DT file changes :-(
>>
>> The DT patches should not go through your tree, but arm-soc, so I
>> guess this is not an issue for you?
>
> Ok, so I saw that you actually merged them. Can you revert or drop
> that merge for the DT part?
>
> This will generate a lot of conflicts with our tree, and I'm not sure
> this would be efficient to make you take all the entirely unrelated to
> next patches.
Please tell me which specific changes to revert.
Thank you.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 22:24 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 22:24 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie, robh+dt, mark.rutland, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]
Hi,
On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote:
> From: Maxime Ripard <maxime.ripard@free-electrons.com>
> Date: Fri, 2 Jun 2017 11:13:20 +0200
>
> > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> >> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
> >> > Date: Wed, 31 May 2017 09:18:31 +0200
> >> >
> >> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> >> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> >> >
> >> > Series applied, but wow that's a lot of DT file changes :-(
> >>
> >> The DT patches should not go through your tree, but arm-soc, so I
> >> guess this is not an issue for you?
> >
> > Ok, so I saw that you actually merged them. Can you revert or drop
> > that merge for the DT part?
> >
> > This will generate a lot of conflicts with our tree, and I'm not sure
> > this would be efficient to make you take all the entirely unrelated to
> > next patches.
>
> Please tell me which specific changes to revert.
>
> Thank you.
Ideally everything from 2c0cba482e79 ("arm: sun8i: sunxi-h3-h5: Add dt
node for the syscon control module") to 2428fd0fe550 ("arm64:
defconfig: Enable dwmac-sun8i driver on defconfig")
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 22:24 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 22:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote:
> From: Maxime Ripard <maxime.ripard@free-electrons.com>
> Date: Fri, 2 Jun 2017 11:13:20 +0200
>
> > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> >> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
> >> > Date: Wed, 31 May 2017 09:18:31 +0200
> >> >
> >> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> >> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> >> >
> >> > Series applied, but wow that's a lot of DT file changes :-(
> >>
> >> The DT patches should not go through your tree, but arm-soc, so I
> >> guess this is not an issue for you?
> >
> > Ok, so I saw that you actually merged them. Can you revert or drop
> > that merge for the DT part?
> >
> > This will generate a lot of conflicts with our tree, and I'm not sure
> > this would be efficient to make you take all the entirely unrelated to
> > next patches.
>
> Please tell me which specific changes to revert.
>
> Thank you.
Ideally everything from 2c0cba482e79 ("arm: sun8i: sunxi-h3-h5: Add dt
node for the syscon control module") to 2428fd0fe550 ("arm64:
defconfig: Enable dwmac-sun8i driver on defconfig")
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170603/362ee7f0/attachment-0001.sig>
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 22:24 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-02 22:24 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
Hi,
On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote:
> From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Date: Fri, 2 Jun 2017 11:13:20 +0200
>
> > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> >> > From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> > Date: Wed, 31 May 2017 09:18:31 +0200
> >> >
> >> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> >> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> >> >
> >> > Series applied, but wow that's a lot of DT file changes :-(
> >>
> >> The DT patches should not go through your tree, but arm-soc, so I
> >> guess this is not an issue for you?
> >
> > Ok, so I saw that you actually merged them. Can you revert or drop
> > that merge for the DT part?
> >
> > This will generate a lot of conflicts with our tree, and I'm not sure
> > this would be efficient to make you take all the entirely unrelated to
> > next patches.
>
> Please tell me which specific changes to revert.
>
> Thank you.
Ideally everything from 2c0cba482e79 ("arm: sun8i: sunxi-h3-h5: Add dt
node for the syscon control module") to 2428fd0fe550 ("arm64:
defconfig: Enable dwmac-sun8i driver on defconfig")
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-09 12:50 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-09 12:50 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie, robh+dt, mark.rutland, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
On Sat, Jun 03, 2017 at 12:24:22AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote:
> > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> > Date: Fri, 2 Jun 2017 11:13:20 +0200
> >
> > > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> > >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> > >> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
> > >> > Date: Wed, 31 May 2017 09:18:31 +0200
> > >> >
> > >> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > >> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> > >> >
> > >> > Series applied, but wow that's a lot of DT file changes :-(
> > >>
> > >> The DT patches should not go through your tree, but arm-soc, so I
> > >> guess this is not an issue for you?
> > >
> > > Ok, so I saw that you actually merged them. Can you revert or drop
> > > that merge for the DT part?
> > >
> > > This will generate a lot of conflicts with our tree, and I'm not sure
> > > this would be efficient to make you take all the entirely unrelated to
> > > next patches.
> >
> > Please tell me which specific changes to revert.
> >
> > Thank you.
>
> Ideally everything from 2c0cba482e79 ("arm: sun8i: sunxi-h3-h5: Add dt
> node for the syscon control module") to 2428fd0fe550 ("arm64:
> defconfig: Enable dwmac-sun8i driver on defconfig")
Ping?
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 148+ messages in thread* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-09 12:50 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-09 12:50 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jun 03, 2017 at 12:24:22AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote:
> > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> > Date: Fri, 2 Jun 2017 11:13:20 +0200
> >
> > > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> > >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> > >> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
> > >> > Date: Wed, 31 May 2017 09:18:31 +0200
> > >> >
> > >> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > >> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> > >> >
> > >> > Series applied, but wow that's a lot of DT file changes :-(
> > >>
> > >> The DT patches should not go through your tree, but arm-soc, so I
> > >> guess this is not an issue for you?
> > >
> > > Ok, so I saw that you actually merged them. Can you revert or drop
> > > that merge for the DT part?
> > >
> > > This will generate a lot of conflicts with our tree, and I'm not sure
> > > this would be efficient to make you take all the entirely unrelated to
> > > next patches.
> >
> > Please tell me which specific changes to revert.
> >
> > Thank you.
>
> Ideally everything from 2c0cba482e79 ("arm: sun8i: sunxi-h3-h5: Add dt
> node for the syscon control module") to 2428fd0fe550 ("arm64:
> defconfig: Enable dwmac-sun8i driver on defconfig")
Ping?
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170609/40accff3/attachment.sig>
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-09 12:50 ` Maxime Ripard
0 siblings, 0 replies; 148+ messages in thread
From: Maxime Ripard @ 2017-06-09 12:50 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
On Sat, Jun 03, 2017 at 12:24:22AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote:
> > From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Date: Fri, 2 Jun 2017 11:13:20 +0200
> >
> > > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> > >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> > >> > From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >> > Date: Wed, 31 May 2017 09:18:31 +0200
> > >> >
> > >> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > >> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> > >> >
> > >> > Series applied, but wow that's a lot of DT file changes :-(
> > >>
> > >> The DT patches should not go through your tree, but arm-soc, so I
> > >> guess this is not an issue for you?
> > >
> > > Ok, so I saw that you actually merged them. Can you revert or drop
> > > that merge for the DT part?
> > >
> > > This will generate a lot of conflicts with our tree, and I'm not sure
> > > this would be efficient to make you take all the entirely unrelated to
> > > next patches.
> >
> > Please tell me which specific changes to revert.
> >
> > Thank you.
>
> Ideally everything from 2c0cba482e79 ("arm: sun8i: sunxi-h3-h5: Add dt
> node for the syscon control module") to 2428fd0fe550 ("arm64:
> defconfig: Enable dwmac-sun8i driver on defconfig")
Ping?
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 14:08 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-02 14:08 UTC (permalink / raw)
To: maxime.ripard
Cc: clabbe.montjoie, robh+dt, mark.rutland, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
devicetree, linux-kernel, netdev, linux-arm-kernel, linux-sunxi
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Date: Fri, 2 Jun 2017 08:37:52 +0200
> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
>> From: Corentin Labbe <clabbe.montjoie@gmail.com>
>> Date: Wed, 31 May 2017 09:18:31 +0200
>>
>> > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> > present on Allwinner H3/H5/A83T/A64 SoCs.
>>
>> Series applied, but wow that's a lot of DT file changes :-(
>
> The DT patches should not go through your tree, but arm-soc, so I
> guess this is not an issue for you?
I already applied them, so if that is the intention, too late.
This needs to be explicitly stated in the header posting. Otherwise
I assume the entire series is meant to go into my tree.
Also, saying "net-next" in the patch subjects means it's targetting my
tree.
^ permalink raw reply [flat|nested] 148+ messages in thread
* [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 14:08 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-02 14:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Date: Fri, 2 Jun 2017 08:37:52 +0200
> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
>> From: Corentin Labbe <clabbe.montjoie@gmail.com>
>> Date: Wed, 31 May 2017 09:18:31 +0200
>>
>> > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> > present on Allwinner H3/H5/A83T/A64 SoCs.
>>
>> Series applied, but wow that's a lot of DT file changes :-(
>
> The DT patches should not go through your tree, but arm-soc, so I
> guess this is not an issue for you?
I already applied them, so if that is the intention, too late.
This needs to be explicitly stated in the header posting. Otherwise
I assume the entire series is meant to go into my tree.
Also, saying "net-next" in the patch subjects means it's targetting my
tree.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
@ 2017-06-02 14:08 ` David Miller
0 siblings, 0 replies; 148+ messages in thread
From: David Miller @ 2017-06-02 14:08 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Date: Fri, 2 Jun 2017 08:37:52 +0200
> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
>> From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Wed, 31 May 2017 09:18:31 +0200
>>
>> > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> > present on Allwinner H3/H5/A83T/A64 SoCs.
>>
>> Series applied, but wow that's a lot of DT file changes :-(
>
> The DT patches should not go through your tree, but arm-soc, so I
> guess this is not an issue for you?
I already applied them, so if that is the intention, too late.
This needs to be explicitly stated in the header posting. Otherwise
I assume the entire series is meant to go into my tree.
Also, saying "net-next" in the patch subjects means it's targetting my
tree.
^ permalink raw reply [flat|nested] 148+ messages in thread