Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH v8 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Andrew Lunn @ 2016-10-05 12:07 UTC (permalink / raw)
  To: Raju Lakkaraju
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
	f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
	Allan.Nielsen-dzo6w/eZyo2tG0bUXCXiUA
In-Reply-To: <1475667578-20799-1-git-send-email-Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>

> - As per review comment, Added DT vddmac, slowdown value error check. 

So i said an exact match, which this is not.

How about something like:

static u8 vsc85xx_edge_rate_magic_get(u16 vddmac, u8 slowdown)
{
	u8 vdd;
	u8 sd;

	for (vdd = 0; vdd < ARRAY_SIZE(edge_table); vdd++)
		if (edge_table[vdd].vddmac == vddmac)
			for (sd = 0; sd < MSCC_SLOWDOWN_MAX; sd++)
				if (edge_table[vdd].slowdown[sd] == slowdown)
					return (MSCC_SLOWDOWN_MAX - sd - 1);
 	return -EINVAL;
}

> @@ -197,15 +203,34 @@ static int vsc8531_of_init(struct phy_device *phydev)
  
  	rc = of_property_read_u16(of_node, "vsc8531,vddmac",
  				  &vsc8531->vddmac);
 	if (rc == -EINVAL)
 		vddmac = MSCC_VDDMAC_3300;

  	rc = of_property_read_u8(of_node, "vsc8531,edge-slowdown",
  				 &vsc8531->edge_slowdown);
 	if (rc == -EINVAL)
  		edge_slowdown = 0;

 	vsc8531->rate_magic = edge_rate_magic_get(vddmac, edge_slowdown);
	if (vsc8531->rate_magic < 0) {
 	   dev_err(phydev->dev, "Invalid vsc8531,vddmac or vsc8531,edge-slowdown");
	   return vsc8531->rate_magic;
        }

>  static int vsc8531_of_init(struct phy_device *phydev)
> @@ -232,8 +257,8 @@ static int vsc85xx_config_init(struct phy_device *phydev)
>  	if (rc)
>  		return rc;
>  
>  	rc = vsc85xx_edge_rate_cntl_set(phydev, vsc8531->rate_magic);
>  	if (rc)
>  		return rc;

	Andrew
--
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
* [PATCH net-next v2 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers
From: Nelson Chang @ 2016-10-05 12:12 UTC (permalink / raw)
  To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw, Nelson Chang
In-Reply-To: <1475669532-23894-1-git-send-email-nelson.chang@mediatek.com>

The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 registers
in mtk_probe().

Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 +++++++++++++++++++++++++++++
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  5 +++++
 2 files changed, 34 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ad4ab97..0c67ab1 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2323,6 +2323,31 @@ free_netdev:
 	return err;
 }
 
+static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
+{
+	u32 val[2], id[4];
+
+	regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, &val[0]);
+	regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, &val[1]);
+
+	id[3] = ((val[0] >> 16) & 0xff) - '0';
+	id[2] = ((val[0] >> 24) & 0xff) - '0';
+	id[1] = (val[1] & 0xff) - '0';
+	id[0] = ((val[1] >> 8) & 0xff) - '0';
+
+	*chip_id = (id[3] * 1000) + (id[2] * 100) +
+		   (id[1] * 10) + id[0];
+
+	if (!(*chip_id)) {
+		dev_err(eth->dev, "failed to get chip id\n");
+		return -ENODEV;
+	}
+
+	dev_info(eth->dev, "chip id = %d\n", *chip_id);
+
+	return 0;
+}
+
 static int mtk_probe(struct platform_device *pdev)
 {
 	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2388,6 +2413,10 @@ static int mtk_probe(struct platform_device *pdev)
 	if (err)
 		return err;
 
+	err = mtk_get_chip_id(eth, &eth->chip_id);
+	if (err)
+		return err;
+
 	for_each_child_of_node(pdev->dev.of_node, mac_np) {
 		if (!of_device_is_compatible(mac_np,
 					     "mediatek,eth-mac"))
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 3003195..a5b422b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -342,6 +342,10 @@
 #define GPIO_BIAS_CTRL		0xed0
 #define GPIO_DRV_SEL10		0xf00
 
+/* ethernet subsystem chip id register */
+#define ETHSYS_CHIPID0_3	0x0
+#define ETHSYS_CHIPID4_7	0x4
+
 /* ethernet subsystem config register */
 #define ETHSYS_SYSCFG0		0x14
 #define SYSCFG0_GE_MASK		0x3
@@ -534,6 +538,7 @@ struct mtk_eth {
 	unsigned long			sysclk;
 	struct regmap			*ethsys;
 	struct regmap			*pctl;
+	u32				chip_id;
 	bool				hwlro;
 	atomic_t			dma_refcnt;
 	struct mtk_tx_ring		tx_ring;
-- 
1.9.1

^ permalink raw reply related
* [PATCH net-next v2 3/3] net: ethernet: mediatek: remove hwlro property in the device tree
From: Nelson Chang @ 2016-10-05 12:12 UTC (permalink / raw)
  To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw, Nelson Chang
In-Reply-To: <1475669532-23894-1-git-send-email-nelson.chang@mediatek.com>

Since the proper way to check the hw lro capability is by the chip id,
hwlro property in the device tree should be removed.

Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index f095257..c010faf 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -24,7 +24,6 @@ Required properties:
 Optional properties:
 - interrupt-parent: Should be the phandle for the interrupt controller
   that services interrupts for this device
-- mediatek,hwlro: the capability if the hardware supports LRO functions
 
 * Ethernet MAC node
 
@@ -54,7 +53,6 @@ eth: ethernet@1b100000 {
 	reset-names = "eth";
 	mediatek,ethsys = <&ethsys>;
 	mediatek,pctl = <&syscfg_pctl_a>;
-	mediatek,hwlro;
 	#address-cells = <1>;
 	#size-cells = <0>;
 
-- 
1.9.1

^ permalink raw reply related
* [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Nelson Chang @ 2016-10-05 12:12 UTC (permalink / raw)
  To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw, Nelson Chang
In-Reply-To: <1475669532-23894-1-git-send-email-nelson.chang@mediatek.com>

Because hw lro started to be supported from MT7623, the proper way to check if
the feature is capable is to judge by the chip id instead of by the dtsi.

Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 0c67ab1..07f3ffa 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2348,6 +2348,14 @@ static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
 	return 0;
 }
 
+static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
+{
+	if (eth->chip_id == MT7623_ETH)
+		return true;
+	else
+		return false;
+}
+
 static int mtk_probe(struct platform_device *pdev)
 {
 	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2387,8 +2395,6 @@ static int mtk_probe(struct platform_device *pdev)
 		return PTR_ERR(eth->pctl);
 	}
 
-	eth->hwlro = of_property_read_bool(pdev->dev.of_node, "mediatek,hwlro");
-
 	for (i = 0; i < 3; i++) {
 		eth->irq[i] = platform_get_irq(pdev, i);
 		if (eth->irq[i] < 0) {
@@ -2417,6 +2423,8 @@ static int mtk_probe(struct platform_device *pdev)
 	if (err)
 		return err;
 
+	eth->hwlro = mtk_is_hwlro_supported(eth);
+
 	for_each_child_of_node(pdev->dev.of_node, mac_np) {
 		if (!of_device_is_compatible(mac_np,
 					     "mediatek,eth-mac"))
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index a5b422b..58738fd 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -345,6 +345,7 @@
 /* ethernet subsystem chip id register */
 #define ETHSYS_CHIPID0_3	0x0
 #define ETHSYS_CHIPID4_7	0x4
+#define MT7623_ETH		(7623)
 
 /* ethernet subsystem config register */
 #define ETHSYS_SYSCFG0		0x14
-- 
1.9.1

^ permalink raw reply related
* [PATCH net-next v2 0/3] net: ethernet: mediatek: check the hw lro capability by the chip id instead of the dtsi
From: Nelson Chang @ 2016-10-05 12:12 UTC (permalink / raw)
  To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw, Nelson Chang

The series modify to check if hw lro is supported by the chip id.

changes since v2:
- Refine mtk_get_chip_id() function

changes since v1:
- Because hw lro started to be supported from MT7623, the proper way to check if the feature is capable is to judge by the chip id instead of by the dtsi.

Nelson Chang (3):
  net: ethernet: mediatek: get the chip id by ETHDMASYS registers
  net: ethernet: mediatek: get hw lro capability by the chip id instead
    of by the dtsi
  net: ethernet: mediatek: remove hwlro property in the device tree

 .../devicetree/bindings/net/mediatek-net.txt       |  2 --
 drivers/net/ethernet/mediatek/mtk_eth_soc.c        | 39 ++++++++++++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h        |  6 ++++
 3 files changed, 43 insertions(+), 4 deletions(-)

-- 
1.9.1

^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Sergei Shtylyov @ 2016-10-05 12:18 UTC (permalink / raw)
  To: Nelson Chang, john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw
In-Reply-To: <1475669532-23894-3-git-send-email-nelson.chang@mediatek.com>

Hello.

On 10/05/2016 03:12 PM, Nelson Chang wrote:

> Because hw lro started to be supported from MT7623, the proper way to check if
> the feature is capable is to judge by the chip id instead of by the dtsi.
>
> Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++++--
>  drivers/net/ethernet/mediatek/mtk_eth_soc.h |  1 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 0c67ab1..07f3ffa 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2348,6 +2348,14 @@ static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
>  	return 0;
>  }
>
> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
> +{
> +	if (eth->chip_id == MT7623_ETH)
> +		return true;
> +	else
> +		return false;

	return eth->chip_id == MT7623_ETH;

[...]
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index a5b422b..58738fd 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -345,6 +345,7 @@
>  /* ethernet subsystem chip id register */
>  #define ETHSYS_CHIPID0_3	0x0
>  #define ETHSYS_CHIPID4_7	0x4
> +#define MT7623_ETH		(7623)

    () not needed at all.

MBR, Sergei

^ permalink raw reply
* [PATCH net-next v2 RESEND 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers
From: Nelson Chang @ 2016-10-05 12:32 UTC (permalink / raw)
  To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw, Nelson Chang
In-Reply-To: <1475670742-11498-1-git-send-email-nelson.chang@mediatek.com>

The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 registers
in mtk_probe().

Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 +++++++++++++++++++++++++++++
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  5 +++++
 2 files changed, 34 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ad4ab97..0c67ab1 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2323,6 +2323,31 @@ free_netdev:
 	return err;
 }
 
+static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
+{
+	u32 val[2], id[4];
+
+	regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, &val[0]);
+	regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, &val[1]);
+
+	id[3] = ((val[0] >> 16) & 0xff) - '0';
+	id[2] = ((val[0] >> 24) & 0xff) - '0';
+	id[1] = (val[1] & 0xff) - '0';
+	id[0] = ((val[1] >> 8) & 0xff) - '0';
+
+	*chip_id = (id[3] * 1000) + (id[2] * 100) +
+		   (id[1] * 10) + id[0];
+
+	if (!(*chip_id)) {
+		dev_err(eth->dev, "failed to get chip id\n");
+		return -ENODEV;
+	}
+
+	dev_info(eth->dev, "chip id = %d\n", *chip_id);
+
+	return 0;
+}
+
 static int mtk_probe(struct platform_device *pdev)
 {
 	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2388,6 +2413,10 @@ static int mtk_probe(struct platform_device *pdev)
 	if (err)
 		return err;
 
+	err = mtk_get_chip_id(eth, &eth->chip_id);
+	if (err)
+		return err;
+
 	for_each_child_of_node(pdev->dev.of_node, mac_np) {
 		if (!of_device_is_compatible(mac_np,
 					     "mediatek,eth-mac"))
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 3003195..a5b422b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -342,6 +342,10 @@
 #define GPIO_BIAS_CTRL		0xed0
 #define GPIO_DRV_SEL10		0xf00
 
+/* ethernet subsystem chip id register */
+#define ETHSYS_CHIPID0_3	0x0
+#define ETHSYS_CHIPID4_7	0x4
+
 /* ethernet subsystem config register */
 #define ETHSYS_SYSCFG0		0x14
 #define SYSCFG0_GE_MASK		0x3
@@ -534,6 +538,7 @@ struct mtk_eth {
 	unsigned long			sysclk;
 	struct regmap			*ethsys;
 	struct regmap			*pctl;
+	u32				chip_id;
 	bool				hwlro;
 	atomic_t			dma_refcnt;
 	struct mtk_tx_ring		tx_ring;
-- 
1.9.1

^ permalink raw reply related
* [PATCH net-next v2 RESEND 0/3] net: ethernet: mediatek: check the hw lro capability by the chip id instead of the dtsi
From: Nelson Chang @ 2016-10-05 12:32 UTC (permalink / raw)
  To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw, Nelson Chang

The series modify to check if hw lro is supported by the chip id.

changes since v2:
- Refine mtk_get_chip_id() function

changes since v1:
- Because hw lro started to be supported from MT7623, the proper way to check if the feature is capable is to judge by the chip id instead of by the dtsi.

Nelson Chang (3):
  net: ethernet: mediatek: get the chip id by ETHDMASYS registers
  net: ethernet: mediatek: get hw lro capability by the chip id instead
    of by the dtsi
  net: ethernet: mediatek: remove hwlro property in the device tree

 .../devicetree/bindings/net/mediatek-net.txt       |  2 --
 drivers/net/ethernet/mediatek/mtk_eth_soc.c        | 41 ++++++++++++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h        |  6 ++++
 3 files changed, 45 insertions(+), 4 deletions(-)

-- 
1.9.1

^ permalink raw reply
* [PATCH net-next v2 RESEND 3/3] net: ethernet: mediatek: remove hwlro property in the device tree
From: Nelson Chang @ 2016-10-05 12:32 UTC (permalink / raw)
  To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw, Nelson Chang
In-Reply-To: <1475670742-11498-1-git-send-email-nelson.chang@mediatek.com>

Since the proper way to check the hw lro capability is by the chip id,
hwlro property in the device tree should be removed.

Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index f095257..c010faf 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -24,7 +24,6 @@ Required properties:
 Optional properties:
 - interrupt-parent: Should be the phandle for the interrupt controller
   that services interrupts for this device
-- mediatek,hwlro: the capability if the hardware supports LRO functions
 
 * Ethernet MAC node
 
@@ -54,7 +53,6 @@ eth: ethernet@1b100000 {
 	reset-names = "eth";
 	mediatek,ethsys = <&ethsys>;
 	mediatek,pctl = <&syscfg_pctl_a>;
-	mediatek,hwlro;
 	#address-cells = <1>;
 	#size-cells = <0>;
 
-- 
1.9.1

^ permalink raw reply related
* [PATCH net-next v2 RESEND 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Nelson Chang @ 2016-10-05 12:32 UTC (permalink / raw)
  To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw, Nelson Chang
In-Reply-To: <1475670742-11498-1-git-send-email-nelson.chang@mediatek.com>

Because hw lro started to be supported from MT7623, the proper way to check if
the feature is capable is to judge by the chip id instead of by the dtsi.

Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 0c67ab1..07f3ffa 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2348,6 +2348,14 @@ static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
 	return 0;
 }
 
+static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
+{
+	if (eth->chip_id == MT7623_ETH)
+		return true;
+	else
+		return false;
+}
+
 static int mtk_probe(struct platform_device *pdev)
 {
 	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2387,8 +2395,6 @@ static int mtk_probe(struct platform_device *pdev)
 		return PTR_ERR(eth->pctl);
 	}
 
-	eth->hwlro = of_property_read_bool(pdev->dev.of_node, "mediatek,hwlro");
-
 	for (i = 0; i < 3; i++) {
 		eth->irq[i] = platform_get_irq(pdev, i);
 		if (eth->irq[i] < 0) {
@@ -2417,6 +2423,8 @@ static int mtk_probe(struct platform_device *pdev)
 	if (err)
 		return err;
 
+	eth->hwlro = mtk_is_hwlro_supported(eth);
+
 	for_each_child_of_node(pdev->dev.of_node, mac_np) {
 		if (!of_device_is_compatible(mac_np,
 					     "mediatek,eth-mac"))
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index a5b422b..99b1c8e 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -345,6 +345,7 @@
 /* ethernet subsystem chip id register */
 #define ETHSYS_CHIPID0_3	0x0
 #define ETHSYS_CHIPID4_7	0x4
+#define MT7623_ETH		7623
 
 /* ethernet subsystem config register */
 #define ETHSYS_SYSCFG0		0x14
-- 
1.9.1

^ permalink raw reply related
* RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Nelson Chang @ 2016-10-05 12:38 UTC (permalink / raw)
  To: sergei.shtylyov, john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw

Hi Sergei,

Thanks for your comments.
Modified.


Nelson

-----Original Message-----
From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com] 
Sent: Wednesday, October 05, 2016 8:18 PM
To: Nelson Chang (張家祥); john@phrozen.org; davem@davemloft.net
Cc: nbd@openwrt.org; netdev@vger.kernel.org;
linux-mediatek@lists.infradead.org; nelsonch.tw@gmail.com
Subject: Re: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro
capability by the chip id instead of by the dtsi

Hello.

On 10/05/2016 03:12 PM, Nelson Chang wrote:

> Because hw lro started to be supported from MT7623, the proper way to 
> check if the feature is capable is to judge by the chip id instead of
by the dtsi.
>
> Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++++--  
> drivers/net/ethernet/mediatek/mtk_eth_soc.h |  1 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 0c67ab1..07f3ffa 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2348,6 +2348,14 @@ static int mtk_get_chip_id(struct mtk_eth *eth,
u32 *chip_id)
>  	return 0;
>  }
>
> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> +	if (eth->chip_id == MT7623_ETH)
> +		return true;
> +	else
> +		return false;

	return eth->chip_id == MT7623_ETH;

[...]
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index a5b422b..58738fd 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -345,6 +345,7 @@
>  /* ethernet subsystem chip id register */
>  #define ETHSYS_CHIPID0_3	0x0
>  #define ETHSYS_CHIPID4_7	0x4
> +#define MT7623_ETH		(7623)

    () not needed at all.

MBR, Sergei

^ permalink raw reply
* RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Nelson Chang @ 2016-10-05 12:46 UTC (permalink / raw)
  To: sergei.shtylyov, john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw

Hi Sergei,

Sorry, miss that.

> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> +     if (eth->chip_id == MT7623_ETH)
> +             return true;
> +     else
> +             return false;

        return eth->chip_id == MT7623_ETH;

=> Since there will be more chips support hw lro in the future, keep the
original codes to have the scalability like this:
if (eth->chip_id == MTxxxx_ETH ||
    eth->chip_id == MTyyyy_ETH ||
    ....)
	return true;



Nelson

-----Original Message-----
From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
Sent: Wednesday, October 05, 2016 8:18 PM
To: Nelson Chang (張家祥); john@phrozen.org; davem@davemloft.net
Cc: nbd@openwrt.org; netdev@vger.kernel.org;
linux-mediatek@lists.infradead.org; nelsonch.tw@gmail.com
Subject: Re: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro
capability by the chip id instead of by the dtsi

Hello.

On 10/05/2016 03:12 PM, Nelson Chang wrote:

> Because hw lro started to be supported from MT7623, the proper way to
> check if the feature is capable is to judge by the chip id instead of
by the dtsi.
>
> Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++++--
> drivers/net/ethernet/mediatek/mtk_eth_soc.h |  1 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 0c67ab1..07f3ffa 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2348,6 +2348,14 @@ static int mtk_get_chip_id(struct mtk_eth *eth,
u32 *chip_id)
>       return 0;
>  }
>
> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> +     if (eth->chip_id == MT7623_ETH)
> +             return true;
> +     else
> +             return false;

        return eth->chip_id == MT7623_ETH;

[...]
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index a5b422b..58738fd 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -345,6 +345,7 @@
>  /* ethernet subsystem chip id register */
>  #define ETHSYS_CHIPID0_3     0x0
>  #define ETHSYS_CHIPID4_7     0x4
> +#define MT7623_ETH           (7623)

    () not needed at all.

MBR, Sergei

^ permalink raw reply
* Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers
From: Jiri Benc @ 2016-10-05 12:47 UTC (permalink / raw)
  To: Pravin Shelar; +Cc: Linux Kernel Network Developers, David Ahern
In-Reply-To: <CAOrHB_Cr7E+_GLtrReUqqG91LV_7yJSWoZhs0pe6N9E0rAxqPQ@mail.gmail.com>

On Tue, 4 Oct 2016 19:03:46 -0700, Pravin Shelar wrote:
> We could have encapsulated packet defragmented in physical bridge.
> that mean the packet is entering OVS after egressing tunnel device.
> That use case would break due to this patch.

Okay, thanks for explanation. I missed this use case and it would
indeed break. And we can't clear existing inner headers when the frame
enters the bridge as it would break GSO.

Seems checking for the MPLS ethertype is indeed the only safe solution.

> > If this patch is wrong, then the current push_mpls is wrong, too, it
> > does the same assumption.
> >
> I am not sure what you mean, can you explain?

push_mpls() uses inner_proto as an indication whether this is the first
MPLS label or not. But it checks skb->encapsulation at the start, thus
it's safe (I expected this check to be done at the config time, not
runtime, and looked in the wrong place for it.)

I'll respin the patch.

Thanks for the patience with me,

 Jiri

^ permalink raw reply
* Re: [PATCH net-next 1/2] openvswitch: remove nonreachable code in vlan parsing
From: Jiri Benc @ 2016-10-05 12:53 UTC (permalink / raw)
  To: Eric Garver; +Cc: netdev, pravin shelar
In-Reply-To: <20161005000618.GN25403@egarver>

On Tue, 4 Oct 2016 20:06:18 -0400, Eric Garver wrote:
> This code is also called for packets passed back down from userspace
> (after the flow key miss and upcall). So it does happen that we have a
> skb without skb->vlan_tci set.

That sucks. The vlan handling should be really consistent, Jiri Pirko
and others put great effort to unify it in the stack, we should make
use of that effort.

I'll respin this patchset and add a patch to make the vlan handling
consistent.

> See the chain:
> ovs_packet_cmd_execute()
>   ovs_flow_key_extract_userspace()
>     key_extract()
>       parse_vlan()
> 
> > Moreover, the likely() statement around skb_vlan_tag_present is bogus. This
> > code is called whenever flow key is being extracted from the packet. The
> > packet may be as likely vlan tagged as not.
> 
> I guess the unlikely scenario is the one I mention above.

But it's wrong. It's also called via

ovs_vport_receive()
  ovs_flow_key_extract()
    key_extract()
      parse_vlan()

and in that path, both cases (vlan vs. non-vlan) are equally possible.

 Jiri

^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Sergei Shtylyov @ 2016-10-05 12:57 UTC (permalink / raw)
  To: Nelson Chang, john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw
In-Reply-To: <1475671572.6101.7.camel@mtksdaap41>

On 10/05/2016 03:46 PM, Nelson Chang wrote:

>> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
>> +     if (eth->chip_id == MT7623_ETH)
>> +             return true;
>> +     else
>> +             return false;
>
>         return eth->chip_id == MT7623_ETH;
>
> => Since there will be more chips support hw lro in the future, keep the
> original codes to have the scalability like this:
> if (eth->chip_id == MTxxxx_ETH ||
>     eth->chip_id == MTyyyy_ETH ||
>     ....)
> 	return true;

    Then use *switch*, not *if*.

> Nelson

MBR, Sergei

^ permalink raw reply
* [PATCH net-next v2] openvswitch: correctly fragment packet with mpls headers
From: Jiri Benc @ 2016-10-05 13:01 UTC (permalink / raw)
  To: netdev; +Cc: David Ahern, pravin shelar

If mpls headers were pushed to a defragmented packet, the refragmentation no
longer works correctly after 48d2ab609b6b ("net: mpls: Fixups for GSO"). The
network header has to be shifted after the mpls headers for the
fragmentation and restored afterwards.

Fixes: 48d2ab609b6b ("net: mpls: Fixups for GSO")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
v2: rewrite and restore the network header only for MPLS packets
---
 net/openvswitch/actions.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 4e03f64709bc..1105c4e29c62 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -62,7 +62,8 @@ struct ovs_frag_data {
 	struct vport *vport;
 	struct ovs_skb_cb cb;
 	__be16 inner_protocol;
-	__u16 vlan_tci;
+	u16 network_offset;	/* valid only for MPLS */
+	u16 vlan_tci;
 	__be16 vlan_proto;
 	unsigned int l2_len;
 	u8 l2_data[MAX_L2_LEN];
@@ -666,6 +667,12 @@ static int ovs_vport_output(struct net *net, struct sock *sk, struct sk_buff *sk
 	skb_postpush_rcsum(skb, skb->data, data->l2_len);
 	skb_reset_mac_header(skb);
 
+	if (eth_p_mpls(skb->protocol)) {
+		skb->inner_network_header = skb->network_header;
+		skb_set_network_header(skb, data->network_offset);
+		skb_reset_mac_len(skb);
+	}
+
 	ovs_vport_send(vport, skb);
 	return 0;
 }
@@ -684,7 +691,8 @@ static struct dst_ops ovs_dst_ops = {
 /* prepare_frag() is called once per (larger-than-MTU) frame; its inverse is
  * ovs_vport_output(), which is called once per fragmented packet.
  */
-static void prepare_frag(struct vport *vport, struct sk_buff *skb)
+static void prepare_frag(struct vport *vport, struct sk_buff *skb,
+			 u16 orig_network_offset)
 {
 	unsigned int hlen = skb_network_offset(skb);
 	struct ovs_frag_data *data;
@@ -694,6 +702,7 @@ static void prepare_frag(struct vport *vport, struct sk_buff *skb)
 	data->vport = vport;
 	data->cb = *OVS_CB(skb);
 	data->inner_protocol = skb->inner_protocol;
+	data->network_offset = orig_network_offset;
 	data->vlan_tci = skb->vlan_tci;
 	data->vlan_proto = skb->vlan_proto;
 	data->l2_len = hlen;
@@ -706,6 +715,13 @@ static void prepare_frag(struct vport *vport, struct sk_buff *skb)
 static void ovs_fragment(struct net *net, struct vport *vport,
 			 struct sk_buff *skb, u16 mru, __be16 ethertype)
 {
+	u16 orig_network_offset = 0;
+
+	if (eth_p_mpls(skb->protocol)) {
+		orig_network_offset = skb_network_offset(skb);
+		skb->network_header = skb->inner_network_header;
+	}
+
 	if (skb_network_offset(skb) > MAX_L2_LEN) {
 		OVS_NLERR(1, "L2 header too long to fragment");
 		goto err;
@@ -715,7 +731,7 @@ static void ovs_fragment(struct net *net, struct vport *vport,
 		struct dst_entry ovs_dst;
 		unsigned long orig_dst;
 
-		prepare_frag(vport, skb);
+		prepare_frag(vport, skb, orig_network_offset);
 		dst_init(&ovs_dst, &ovs_dst_ops, NULL, 1,
 			 DST_OBSOLETE_NONE, DST_NOCOUNT);
 		ovs_dst.dev = vport->dev;
@@ -735,7 +751,7 @@ static void ovs_fragment(struct net *net, struct vport *vport,
 			goto err;
 		}
 
-		prepare_frag(vport, skb);
+		prepare_frag(vport, skb, orig_network_offset);
 		memset(&ovs_rt, 0, sizeof(ovs_rt));
 		dst_init(&ovs_rt.dst, &ovs_dst_ops, NULL, 1,
 			 DST_OBSOLETE_NONE, DST_NOCOUNT);
-- 
1.8.3.1

^ permalink raw reply related
* [PATCH net] Fixing a bug in team driver due to incorrect 'unsigned  int' to 'int' conversion
From: Alex Sidorenko @ 2016-10-05 13:06 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1475636928.28155.196.camel@edumazet-glaptop3.roam.corp.google.com>

Roundrobin runner of team driver uses 'unsigned int' variable to count the number of sent_packets.
Later it is passed to a subroutine team_num_to_port_index(struct team *team, int num) as
'num' and when we reach MAXINT (2**31-1), 'num' becomes negative.

This leads to using incorrect hash-bucket for port lookup and as a result, packets are dropped. The fix
consists of changing 'int num' to 'unsigned int num'. Testing of a fixed kernel shows that there
is no packet drop anymore.


Signed-off-by: Alex Sidorenko <alexandre.sidorenko@hpe.com>

---
 include/linux/if_team.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/if_team.h b/include/linux/if_team.h
index 174f43f..c05216a 100644
--- a/include/linux/if_team.h
+++ b/include/linux/if_team.h
@@ -245,7 +245,7 @@ static inline struct team_port *team_get_port_by_index(struct team *team,
        return NULL;
 }
 
-static inline int team_num_to_port_index(struct team *team, int num)
+static inline int team_num_to_port_index(struct team *team, unsigned int num)
 {
        int en_port_count = ACCESS_ONCE(team->en_port_count);
 
-- 
2.7.4
 


-- 

------------------------------------------------------------------
Alex Sidorenko	email: asid@hpe.com
ERT  Linux 	Hewlett-Packard Enterprise (Canada)
------------------------------------------------------------------

^ permalink raw reply related
* [PATCH net-next v2 0/3] openvswitch: make vlan handling consistent
From: Jiri Benc @ 2016-10-05 13:07 UTC (permalink / raw)
  To: netdev; +Cc: pravin shelar, Eric Garver

Always keep the first vlan tag "accelerated", i.e. in skb->vlan_tci. This
simplifies things considerably.

v2: added the first patch

Jiri Benc (3):
  openvswitch: normalize vlan rx path
  openvswitch: remove unreachable code in vlan parsing
  openvswitch: fix vlan subtraction from packet length

 net/openvswitch/datapath.c | 10 ++++++++++
 net/openvswitch/flow.c     | 28 ++++++++--------------------
 net/openvswitch/vport.c    | 10 +++-------
 3 files changed, 21 insertions(+), 27 deletions(-)

-- 
1.8.3.1

^ permalink raw reply
* [PATCH net-next v2 1/3] openvswitch: normalize vlan rx path
From: Jiri Benc @ 2016-10-05 13:07 UTC (permalink / raw)
  To: netdev; +Cc: pravin shelar, Eric Garver
In-Reply-To: <cover.1475672568.git.jbenc@redhat.com>

Similarly to how the core networking stack behaves, let the first vlan tag
be always stored in skb->vlan_tci. This is already ensured in
__netif_receive_skb_core for packets that were received from the kernel and
honored by skb_vlan_push and skb_vlan_pop. The only remaining place are
packets received from the user space. Just do the same things with vlan
frames as __netif_receive_skb_core does.

Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
 net/openvswitch/datapath.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 4d67ea856067..c47b3da8ecf2 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -594,6 +594,16 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb, struct genl_info *info)
 	else
 		packet->protocol = htons(ETH_P_802_2);
 
+	if (eth_type_vlan(packet->protocol)) {
+		__skb_pull(packet, ETH_HLEN);
+		skb_reset_network_header(packet);
+		skb_reset_mac_len(packet);
+		packet = skb_vlan_untag(packet);
+		if (unlikely(!packet))
+			goto err;
+		skb_push(packet, ETH_HLEN);
+	}
+
 	/* Set packet's mru */
 	if (a[OVS_PACKET_ATTR_MRU]) {
 		mru = nla_get_u16(a[OVS_PACKET_ATTR_MRU]);
-- 
1.8.3.1

^ permalink raw reply related
* [PATCH net-next v2 2/3] openvswitch: remove unreachable code in vlan parsing
From: Jiri Benc @ 2016-10-05 13:07 UTC (permalink / raw)
  To: netdev; +Cc: pravin shelar, Eric Garver
In-Reply-To: <cover.1475672568.git.jbenc@redhat.com>

Now when the first vlan tag is always in skb->vlan_tci, drop code that
assumed it might not be the case.

This patch also removes the wrong likely() statement around
skb_vlan_tag_present introduced by 018c1dda5ff1 ("openvswitch: 802.1AD Flow
handling, actions, vlan parsing, netlink attributes"). This code is called
whenever flow key is being extracted from the packet, the packet may be as
likely vlan tagged as not.

Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
 net/openvswitch/flow.c | 28 ++++++++--------------------
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index c8c82e109c68..d88c0a55b783 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -308,9 +308,7 @@ static bool icmp6hdr_ok(struct sk_buff *skb)
 
 /**
  * Parse vlan tag from vlan header.
- * Returns ERROR on memory error.
- * Returns 0 if it encounters a non-vlan or incomplete packet.
- * Returns 1 after successfully parsing vlan tag.
+ * Returns ERROR on memory error, 0 otherwise.
  */
 static int parse_vlan_tag(struct sk_buff *skb, struct vlan_head *key_vh)
 {
@@ -331,34 +329,24 @@ static int parse_vlan_tag(struct sk_buff *skb, struct vlan_head *key_vh)
 	key_vh->tpid = vh->tpid;
 
 	__skb_pull(skb, sizeof(struct vlan_head));
-	return 1;
+	return 0;
 }
 
 static int parse_vlan(struct sk_buff *skb, struct sw_flow_key *key)
 {
-	int res;
-
 	key->eth.vlan.tci = 0;
 	key->eth.vlan.tpid = 0;
 	key->eth.cvlan.tci = 0;
 	key->eth.cvlan.tpid = 0;
 
-	if (likely(skb_vlan_tag_present(skb))) {
-		key->eth.vlan.tci = htons(skb->vlan_tci);
-		key->eth.vlan.tpid = skb->vlan_proto;
-	} else {
-		/* Parse outer vlan tag in the non-accelerated case. */
-		res = parse_vlan_tag(skb, &key->eth.vlan);
-		if (res <= 0)
-			return res;
-	}
+	if (!skb_vlan_tag_present(skb))
+		return 0;
 
-	/* Parse inner vlan tag. */
-	res = parse_vlan_tag(skb, &key->eth.cvlan);
-	if (res <= 0)
-		return res;
+	key->eth.vlan.tci = htons(skb->vlan_tci);
+	key->eth.vlan.tpid = skb->vlan_proto;
 
-	return 0;
+	/* Parse inner vlan tag. */
+	return parse_vlan_tag(skb, &key->eth.cvlan);
 }
 
 static __be16 parse_ethertype(struct sk_buff *skb)
-- 
1.8.3.1

^ permalink raw reply related
* [PATCH net-next v2 3/3] openvswitch: fix vlan subtraction from packet length
From: Jiri Benc @ 2016-10-05 13:07 UTC (permalink / raw)
  To: netdev; +Cc: pravin shelar, Eric Garver
In-Reply-To: <cover.1475672568.git.jbenc@redhat.com>

When the packet has its vlan tag in skb->vlan_tci, the length of the VLAN
header is not counted in skb->len. It doesn't make sense to subtract it.

In addition, to honor the comment below the code, the VLAN header length
should not be subtracted if there's a vlan tag in skb->vlan_tci. This leads
to the code simply subtracting the Ethernet header length.

Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
 net/openvswitch/vport.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 8f198437c724..210bafc09bd8 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -483,17 +483,13 @@ EXPORT_SYMBOL_GPL(ovs_vport_deferred_free);
 
 static unsigned int packet_length(const struct sk_buff *skb)
 {
-	unsigned int length = skb->len - ETH_HLEN;
-
-	if (skb_vlan_tagged(skb))
-		length -= VLAN_HLEN;
-
 	/* Don't subtract for multiple VLAN tags. Most (all?) drivers allow
 	 * (ETH_LEN + VLAN_HLEN) in addition to the mtu value, but almost none
 	 * account for 802.1ad. e.g. is_skb_forwardable().
+	 * Note that the first VLAN tag is always in skb->vlan_tci, thus not
+	 * accounted for in skb->len.
 	 */
-
-	return length;
+	return skb->len - ETH_HLEN;
 }
 
 void ovs_vport_send(struct vport *vport, struct sk_buff *skb)
-- 
1.8.3.1

^ permalink raw reply related
* RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: David Laight @ 2016-10-05 13:07 UTC (permalink / raw)
  To: 'Nelson Chang', sergei.shtylyov@cogentembedded.com,
	john@phrozen.org, davem@davemloft.net
  Cc: nbd@openwrt.org, netdev@vger.kernel.org,
	linux-mediatek@lists.infradead.org, nelsonch.tw@gmail.com
In-Reply-To: <1475671572.6101.7.camel@mtksdaap41>

From: Nelson Chang
> Sent: 05 October 2016 13:46
> > +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> > +     if (eth->chip_id == MT7623_ETH)
> > +             return true;
> > +     else
> > +             return false;
> 
>         return eth->chip_id == MT7623_ETH;
> 
> => Since there will be more chips support hw lro in the future, keep the
> original codes to have the scalability like this:
> if (eth->chip_id == MTxxxx_ETH ||
>     eth->chip_id == MTyyyy_ETH ||
>     ....)
> 	return true;

Nothing wrong with:

	return eth->chip_id == MTxxxx_ETH ||
		eth->chip_id == MTyyyy_ETH;

	David


^ permalink raw reply
* RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Nelson Chang @ 2016-10-05 13:21 UTC (permalink / raw)
  To: David.Laight, sergei.shtylyov, john, davem
  Cc: nbd, netdev, linux-mediatek, nelsonch.tw

Hi Sergei, David,

I think modifying that as below is clear and scalable. Agree?

static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
{
	switch (eth->chip_id) {
	case MT7623_ETH:
		return true;
	}

	return false;
}

Thanks.


Nelson
-----Original Message-----
From: David Laight [mailto:David.Laight@ACULAB.COM] 
Sent: Wednesday, October 05, 2016 9:07 PM
To: Nelson Chang (張家祥); sergei.shtylyov@cogentembedded.com;
john@phrozen.org; davem@davemloft.net
Cc: nbd@openwrt.org; netdev@vger.kernel.org;
linux-mediatek@lists.infradead.org; nelsonch.tw@gmail.com
Subject: RE: [PATCH net-next v2 2/3] net: ethernet: mediatek: get hw lro
capability by the chip id instead of by the dtsi

From: Nelson Chang
> Sent: 05 October 2016 13:46
> > +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> > +     if (eth->chip_id == MT7623_ETH)
> > +             return true;
> > +     else
> > +             return false;
> 
>         return eth->chip_id == MT7623_ETH;
> 
> => Since there will be more chips support hw lro in the future, keep 
> the original codes to have the scalability like this:
> if (eth->chip_id == MTxxxx_ETH ||
>     eth->chip_id == MTyyyy_ETH ||
>     ....)
> 	return true;

Nothing wrong with:

	return eth->chip_id == MTxxxx_ETH ||
		eth->chip_id == MTyyyy_ETH;

	David

^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] bnx2x: page allocation failure
From: Jason Baron @ 2016-10-05 13:48 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Ariel.Elior, Yuval.Mintz
In-Reply-To: <20161003.201958.1459020191229947657.davem@davemloft.net>



On 10/03/2016 08:19 PM, David Miller wrote:
> From: "Baron, Jason" <jbaron@akamai.com>
> Date: Mon, 3 Oct 2016 20:24:32 +0000
>
>> Or should I just send the incremental at this point?
> Incremental is required at this point.

Hi David,

Ok. The above question was sent out erroneously. I have already posted
the incremental patch that I was referring to here:
https://patchwork.ozlabs.org/patch/675227/

Prior to that incremental patch post, I had composed the above question,
but realized that the right thing to do was simply to send the
incremental. However, I forgot to delete the 'draft' mail that I had,
and it accidentally got sent out on Monday.

Please ignore the noise, we are all set here :)

Thanks,

-Jason

^ permalink raw reply
* [PATCH] devicetree: net: micrel-ksz90x1.txt: Properly explain skew settings
From: Mike Looijmans @ 2016-10-05 14:03 UTC (permalink / raw)
  To: devicetree
  Cc: netdev, linux-kernel, davem, robh+dt, mark.rutland, andrew,
	f.fainelli, Mike Looijmans

The KSZ9031 skew registers contain an offset, the chip's default value
is "neutral" which does not add any skew. Programming a 0 into a skew
property will actually set it the maximal negative adjustment and not
to a neutral position as one would expect.

Explain this situation in the devicetree binding documentation and list
the settings that the chip considers neutral.

Changing the implementation to accept negative values would have been
a better solution, but would break existing configurations.

Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index f9c32ad..c35b5b4 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -34,16 +34,17 @@ KSZ9031:
 
   All skew control options are specified in picoseconds. The minimum
   value is 0, and the maximum is property-dependent. The increment
-  step is 60ps.
+  step is 60ps. The default value is the neutral setting, so setting
+  rxc-skew-ps=<0> actually results in -900 picoseconds adjustment.
 
   Optional properties:
 
-    Maximum value of 1860:
+    Maximum value of 1860, default value 900:
 
       - rxc-skew-ps : Skew control of RX clock pad
       - txc-skew-ps : Skew control of TX clock pad
 
-    Maximum value of 900:
+    Maximum value of 900, default value 420:
 
       - rxdv-skew-ps : Skew control of RX CTL pad
       - txen-skew-ps : Skew control of TX CTL pad
-- 
1.9.1

^ permalink raw reply related
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox