[PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[Simon Guinot]

Hello,

This patch series fixes the Ethernet jumbo frames support for the SoCs
Armada 370, 380 and 385. Unlike Armada XP, the Ethernet controller for
this SoCs don't support TCP/IP checksumming with a frame size larger
than 1600 bytes.

This patches should be applied to the -stable kernels 3.8 and onwards.

Changes since v1:
- Use a new compatible string for the Ethernet IP found in Armada XP
  SoCs (instead of using an optional property).
- Fix the issue for the Armada 380 and 385 SoCs as well.

Regards,

Simon

Simon Guinot (3):
  net: mvneta: introduce compatible string "marvell,armada-xp-neta"
  ARM: mvebu: update Ethernet compatible string for Armada XP
  ARM: mvebu: disable IP checksum with jumbo frames for Armada 370

 .../bindings/net/marvell-armada-370-neta.txt       |  2 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               |  2 --
 arch/arm/boot/dts/armada-370.dtsi                  |  8 +++++++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           |  2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           |  2 +-
 arch/arm/boot/dts/armada-xp.dtsi                   | 10 +++++++-
 drivers/net/ethernet/marvell/mvneta.c              | 27 +++++++++++++++++++++-
 7 files changed, 46 insertions(+), 7 deletions(-)

-- 
2.1.4

[PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[Simon Guinot]

Hello,

This patch series fixes the Ethernet jumbo frames support for the SoCs
Armada 370, 380 and 385. Unlike Armada XP, the Ethernet controller for
this SoCs don't support TCP/IP checksumming with a frame size larger
than 1600 bytes.

This patches should be applied to the -stable kernels 3.8 and onwards.

Changes since v1:
- Use a new compatible string for the Ethernet IP found in Armada XP
  SoCs (instead of using an optional property).
- Fix the issue for the Armada 380 and 385 SoCs as well.

Regards,

Simon

Simon Guinot (3):
  net: mvneta: introduce compatible string "marvell,armada-xp-neta"
  ARM: mvebu: update Ethernet compatible string for Armada XP
  ARM: mvebu: disable IP checksum with jumbo frames for Armada 370

 .../bindings/net/marvell-armada-370-neta.txt       |  2 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               |  2 --
 arch/arm/boot/dts/armada-370.dtsi                  |  8 +++++++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           |  2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           |  2 +-
 arch/arm/boot/dts/armada-xp.dtsi                   | 10 +++++++-
 drivers/net/ethernet/marvell/mvneta.c              | 27 +++++++++++++++++++++-
 7 files changed, 46 insertions(+), 7 deletions(-)

-- 
2.1.4

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Simon Guinot]

The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
380 and 385 SoCs. Since at least one more hardware feature is available
for the Armada XP SoCs then a way to identify them is needed.

This patch introduces a new compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: <stable@vger.kernel.org> # v3.8+
---
 Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
 drivers/net/ethernet/marvell/mvneta.c                             | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index 750d577e8083..f5a8ca29aff0 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -1,7 +1,7 @@
 * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
 
 Required properties:
-- compatible: should be "marvell,armada-370-neta".
+- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
 - reg: address and length of the register set for the device.
 - interrupts: interrupt for the device
 - phy: See ethernet.txt file in the same directory.
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index ce5f7f9cff06..aceb977b104d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3179,6 +3179,7 @@ static int mvneta_remove(struct platform_device *pdev)
 
 static const struct of_device_id mvneta_match[] = {
 	{ .compatible = "marvell,armada-370-neta" },
+	{ .compatible = "marvell,armada-xp-neta" },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, mvneta_match);
-- 
2.1.4

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell,armada-xp-neta"

[Simon Guinot]

The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
380 and 385 SoCs. Since at least one more hardware feature is available
for the Armada XP SoCs then a way to identify them is needed.

This patch introduces a new compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: <stable@vger.kernel.org> # v3.8+
---
 Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
 drivers/net/ethernet/marvell/mvneta.c                             | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index 750d577e8083..f5a8ca29aff0 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -1,7 +1,7 @@
 * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
 
 Required properties:
-- compatible: should be "marvell,armada-370-neta".
+- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
 - reg: address and length of the register set for the device.
 - interrupts: interrupt for the device
 - phy: See ethernet.txt file in the same directory.
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index ce5f7f9cff06..aceb977b104d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3179,6 +3179,7 @@ static int mvneta_remove(struct platform_device *pdev)
 
 static const struct of_device_id mvneta_match[] = {
 	{ .compatible = "marvell,armada-370-neta" },
+	{ .compatible = "marvell,armada-xp-neta" },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, mvneta_match);
-- 
2.1.4

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Gregory CLEMENT]

Hi Simon,

On 17/06/2015 15:19, Simon Guinot wrote:
> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> 380 and 385 SoCs. Since at least one more hardware feature is available
> for the Armada XP SoCs then a way to identify them is needed.
> 
> This patch introduces a new compatible string "marvell,armada-xp-neta".

Let's be future proof by going further. I would like to have an compatible string
for each SoC even if we currently we don't use them.

You even don't have to use add it in the mvneta.c file if you use:
"marvell,armada-380-neta", "marvell,armada-xp-neta"


Thanks,

Gregory


> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> Cc: <stable@vger.kernel.org> # v3.8+
> ---
>  Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
>  drivers/net/ethernet/marvell/mvneta.c                             | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> index 750d577e8083..f5a8ca29aff0 100644
> --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> @@ -1,7 +1,7 @@
>  * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
>  
>  Required properties:
> -- compatible: should be "marvell,armada-370-neta".
> +- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
>  - reg: address and length of the register set for the device.
>  - interrupts: interrupt for the device
>  - phy: See ethernet.txt file in the same directory.
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index ce5f7f9cff06..aceb977b104d 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3179,6 +3179,7 @@ static int mvneta_remove(struct platform_device *pdev)
>  
>  static const struct of_device_id mvneta_match[] = {
>  	{ .compatible = "marvell,armada-370-neta" },
> +	{ .compatible = "marvell,armada-xp-neta" },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, mvneta_match);
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell,armada-xp-neta"

[Gregory CLEMENT]

Hi Simon,

On 17/06/2015 15:19, Simon Guinot wrote:
> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> 380 and 385 SoCs. Since at least one more hardware feature is available
> for the Armada XP SoCs then a way to identify them is needed.
> 
> This patch introduces a new compatible string "marvell,armada-xp-neta".

Let's be future proof by going further. I would like to have an compatible string
for each SoC even if we currently we don't use them.

You even don't have to use add it in the mvneta.c file if you use:
"marvell,armada-380-neta", "marvell,armada-xp-neta"


Thanks,

Gregory


> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> Cc: <stable@vger.kernel.org> # v3.8+
> ---
>  Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
>  drivers/net/ethernet/marvell/mvneta.c                             | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> index 750d577e8083..f5a8ca29aff0 100644
> --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> @@ -1,7 +1,7 @@
>  * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
>  
>  Required properties:
> -- compatible: should be "marvell,armada-370-neta".
> +- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
>  - reg: address and length of the register set for the device.
>  - interrupts: interrupt for the device
>  - phy: See ethernet.txt file in the same directory.
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index ce5f7f9cff06..aceb977b104d 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3179,6 +3179,7 @@ static int mvneta_remove(struct platform_device *pdev)
>  
>  static const struct of_device_id mvneta_match[] = {
>  	{ .compatible = "marvell,armada-370-neta" },
> +	{ .compatible = "marvell,armada-xp-neta" },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, mvneta_match);
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Gregory CLEMENT]

On 17/06/2015 17:12, Gregory CLEMENT wrote:
> Hi Simon,
> 
> On 17/06/2015 15:19, Simon Guinot wrote:
>> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
>> 380 and 385 SoCs. Since at least one more hardware feature is available
>> for the Armada XP SoCs then a way to identify them is needed.
>>
>> This patch introduces a new compatible string "marvell,armada-xp-neta".
> 
> Let's be future proof by going further. I would like to have an compatible string
> for each SoC even if we currently we don't use them.
> 
> You even don't have to use add it in the mvneta.c file if you use:
> "marvell,armada-380-neta", "marvell,armada-xp-neta"

Actually I meant:
"marvell,armada-380-neta", "marvell,armada-370-neta"

> 
> 
> Thanks,
> 
> Gregory
> 
> 
>> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
>> Cc: <stable@vger.kernel.org> # v3.8+
>> ---
>>  Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
>>  drivers/net/ethernet/marvell/mvneta.c                             | 1 +
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
>> index 750d577e8083..f5a8ca29aff0 100644
>> --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
>> +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
>> @@ -1,7 +1,7 @@
>>  * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
>>  
>>  Required properties:
>> -- compatible: should be "marvell,armada-370-neta".
>> +- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
>>  - reg: address and length of the register set for the device.
>>  - interrupts: interrupt for the device
>>  - phy: See ethernet.txt file in the same directory.
>> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
>> index ce5f7f9cff06..aceb977b104d 100644
>> --- a/drivers/net/ethernet/marvell/mvneta.c
>> +++ b/drivers/net/ethernet/marvell/mvneta.c
>> @@ -3179,6 +3179,7 @@ static int mvneta_remove(struct platform_device *pdev)
>>  
>>  static const struct of_device_id mvneta_match[] = {
>>  	{ .compatible = "marvell,armada-370-neta" },
>> +	{ .compatible = "marvell,armada-xp-neta" },
>>  	{ }
>>  };
>>  MODULE_DEVICE_TABLE(of, mvneta_match);
>>
> 
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Gregory CLEMENT]

On 17/06/2015 17:12, Gregory CLEMENT wrote:
> Hi Simon,
> 
> On 17/06/2015 15:19, Simon Guinot wrote:
>> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
>> 380 and 385 SoCs. Since at least one more hardware feature is available
>> for the Armada XP SoCs then a way to identify them is needed.
>>
>> This patch introduces a new compatible string "marvell,armada-xp-neta".
> 
> Let's be future proof by going further. I would like to have an compatible string
> for each SoC even if we currently we don't use them.
> 
> You even don't have to use add it in the mvneta.c file if you use:
> "marvell,armada-380-neta", "marvell,armada-xp-neta"

Actually I meant:
"marvell,armada-380-neta", "marvell,armada-370-neta"

> 
> 
> Thanks,
> 
> Gregory
> 
> 
>> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
>> Cc: <stable@vger.kernel.org> # v3.8+
>> ---
>>  Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
>>  drivers/net/ethernet/marvell/mvneta.c                             | 1 +
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
>> index 750d577e8083..f5a8ca29aff0 100644
>> --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
>> +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
>> @@ -1,7 +1,7 @@
>>  * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
>>  
>>  Required properties:
>> -- compatible: should be "marvell,armada-370-neta".
>> +- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
>>  - reg: address and length of the register set for the device.
>>  - interrupts: interrupt for the device
>>  - phy: See ethernet.txt file in the same directory.
>> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
>> index ce5f7f9cff06..aceb977b104d 100644
>> --- a/drivers/net/ethernet/marvell/mvneta.c
>> +++ b/drivers/net/ethernet/marvell/mvneta.c
>> @@ -3179,6 +3179,7 @@ static int mvneta_remove(struct platform_device *pdev)
>>  
>>  static const struct of_device_id mvneta_match[] = {
>>  	{ .compatible = "marvell,armada-370-neta" },
>> +	{ .compatible = "marvell,armada-xp-neta" },
>>  	{ }
>>  };
>>  MODULE_DEVICE_TABLE(of, mvneta_match);
>>
> 
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Jason Cooper]

Hi Gregory,

On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
> On 17/06/2015 17:12, Gregory CLEMENT wrote:
> > On 17/06/2015 15:19, Simon Guinot wrote:
> >> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> >> 380 and 385 SoCs. Since at least one more hardware feature is available
> >> for the Armada XP SoCs then a way to identify them is needed.
> >>
> >> This patch introduces a new compatible string "marvell,armada-xp-neta".
> > 
> > Let's be future proof by going further. I would like to have an compatible string
> > for each SoC even if we currently we don't use them.

I disagree with this.  We can't predict what incosistencies we'll discover in
the future.  We should only assign new compatible strings based on known IP
variations when we discover them.  This seems fraught with demons since we
can't predict the scope of affected IP blocks (some steppings of one SoC, three
SoCs plus two steppings of a fourth, etc)

imho, the 'future-proofing' lies in being specific as to the naming of the
compatible strings against known hardware variations at the time.

thx,

Jason.

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Jason Cooper]

Hi Gregory,

On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
> On 17/06/2015 17:12, Gregory CLEMENT wrote:
> > On 17/06/2015 15:19, Simon Guinot wrote:
> >> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> >> 380 and 385 SoCs. Since at least one more hardware feature is available
> >> for the Armada XP SoCs then a way to identify them is needed.
> >>
> >> This patch introduces a new compatible string "marvell,armada-xp-neta".
> > 
> > Let's be future proof by going further. I would like to have an compatible string
> > for each SoC even if we currently we don't use them.

I disagree with this.  We can't predict what incosistencies we'll discover in
the future.  We should only assign new compatible strings based on known IP
variations when we discover them.  This seems fraught with demons since we
can't predict the scope of affected IP blocks (some steppings of one SoC, three
SoCs plus two steppings of a fourth, etc)

imho, the 'future-proofing' lies in being specific as to the naming of the
compatible strings against known hardware variations at the time.

thx,

Jason.

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Thomas Petazzoni]

Jason,

On Wed, 17 Jun 2015 17:01:12 +0000, Jason Cooper wrote:

> I disagree with this.  We can't predict what incosistencies we'll discover in
> the future.  We should only assign new compatible strings based on known IP
> variations when we discover them.  This seems fraught with demons since we
> can't predict the scope of affected IP blocks (some steppings of one SoC, three
> SoCs plus two steppings of a fourth, etc)
> 
> imho, the 'future-proofing' lies in being specific as to the naming of the
> compatible strings against known hardware variations at the time.

Except that this clearly doesn't work, and the case raised by Simon is
a perfect illustration of why planning ahead is beneficial. We already
had the issue several times on mvebu platforms, so it should really
become the rule to have one compatible string specific to the actual
SoC in the list of compatible strings.

Not doing so requires breaking DT backward compatibility more often, so
wanting DT backward compatibility and not wanting to plan ahead is a
bit antagonist. But I personally don't care much about DT backward
compatibility, and I've explained numerous times why, so in the end I
don't really care much.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Thomas Petazzoni]

Jason,

On Wed, 17 Jun 2015 17:01:12 +0000, Jason Cooper wrote:

> I disagree with this.  We can't predict what incosistencies we'll discover in
> the future.  We should only assign new compatible strings based on known IP
> variations when we discover them.  This seems fraught with demons since we
> can't predict the scope of affected IP blocks (some steppings of one SoC, three
> SoCs plus two steppings of a fourth, etc)
> 
> imho, the 'future-proofing' lies in being specific as to the naming of the
> compatible strings against known hardware variations at the time.

Except that this clearly doesn't work, and the case raised by Simon is
a perfect illustration of why planning ahead is beneficial. We already
had the issue several times on mvebu platforms, so it should really
become the rule to have one compatible string specific to the actual
SoC in the list of compatible strings.

Not doing so requires breaking DT backward compatibility more often, so
wanting DT backward compatibility and not wanting to plan ahead is a
bit antagonist. But I personally don't care much about DT backward
compatibility, and I've explained numerous times why, so in the end I
don't really care much.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Jason Cooper]

Hey Thomas,

On Wed, Jun 17, 2015 at 10:43:12PM +0200, Thomas Petazzoni wrote:
> On Wed, 17 Jun 2015 17:01:12 +0000, Jason Cooper wrote:
> 
> > I disagree with this.  We can't predict what incosistencies we'll discover in
> > the future.  We should only assign new compatible strings based on known IP
> > variations when we discover them.  This seems fraught with demons since we
> > can't predict the scope of affected IP blocks (some steppings of one SoC, three
> > SoCs plus two steppings of a fourth, etc)
> > 
> > imho, the 'future-proofing' lies in being specific as to the naming of the
> > compatible strings against known hardware variations at the time.
> 
> Except that this clearly doesn't work, and the case raised by Simon is
> a perfect illustration of why planning ahead is beneficial. 

Odd, I'd use that as an example of the process working.  ;-)  we have
everyone using 'armada-370-neta' for a given block.  We discovered that
the original IP block (on the 370s) had a limitation (no hw checksum
for greater than 1600 bytes).  A newer version of the IP block (XP)
doesn't have the limitation.

So we change the driver to honor the limit for the 370 compatible
string.  We create a new compatible string for xp where the block
doesn't have the limitation.

How did the process fail?

> We already had the issue several times on mvebu platforms, so it
> should really become the rule to have one compatible string specific
> to the actual SoC in the list of compatible strings.

Sorry, I'm just not a fan of guessing.  But I'll fall back to the DT
maintainers on this one.  if they are ok with it, then I'll drop my
objection.

> Not doing so requires breaking DT backward compatibility more often, so
> wanting DT backward compatibility and not wanting to plan ahead is a
> bit antagonist.

I'm not seeing where backwards compatibility was broken?  A device with
an old dtb booting a newer kernel gets a bugfix.  In the case of an XP
board with an old dtb (armada-370-neta), the hardware still works, but
not optimally.  Upgrading the dtb will enable hw checksumming for jumbo
packets.

thx,

Jason.

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Jason Cooper]

Hey Thomas,

On Wed, Jun 17, 2015 at 10:43:12PM +0200, Thomas Petazzoni wrote:
> On Wed, 17 Jun 2015 17:01:12 +0000, Jason Cooper wrote:
> 
> > I disagree with this.  We can't predict what incosistencies we'll discover in
> > the future.  We should only assign new compatible strings based on known IP
> > variations when we discover them.  This seems fraught with demons since we
> > can't predict the scope of affected IP blocks (some steppings of one SoC, three
> > SoCs plus two steppings of a fourth, etc)
> > 
> > imho, the 'future-proofing' lies in being specific as to the naming of the
> > compatible strings against known hardware variations at the time.
> 
> Except that this clearly doesn't work, and the case raised by Simon is
> a perfect illustration of why planning ahead is beneficial. 

Odd, I'd use that as an example of the process working.  ;-)  we have
everyone using 'armada-370-neta' for a given block.  We discovered that
the original IP block (on the 370s) had a limitation (no hw checksum
for greater than 1600 bytes).  A newer version of the IP block (XP)
doesn't have the limitation.

So we change the driver to honor the limit for the 370 compatible
string.  We create a new compatible string for xp where the block
doesn't have the limitation.

How did the process fail?

> We already had the issue several times on mvebu platforms, so it
> should really become the rule to have one compatible string specific
> to the actual SoC in the list of compatible strings.

Sorry, I'm just not a fan of guessing.  But I'll fall back to the DT
maintainers on this one.  if they are ok with it, then I'll drop my
objection.

> Not doing so requires breaking DT backward compatibility more often, so
> wanting DT backward compatibility and not wanting to plan ahead is a
> bit antagonist.

I'm not seeing where backwards compatibility was broken?  A device with
an old dtb booting a newer kernel gets a bugfix.  In the case of an XP
board with an old dtb (armada-370-neta), the hardware still works, but
not optimally.  Upgrading the dtb will enable hw checksumming for jumbo
packets.

thx,

Jason.

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Jason Cooper]

Hey Thomas,

On Wed, Jun 17, 2015 at 10:43:12PM +0200, Thomas Petazzoni wrote:
> On Wed, 17 Jun 2015 17:01:12 +0000, Jason Cooper wrote:
> 
> > I disagree with this.  We can't predict what incosistencies we'll discover in
> > the future.  We should only assign new compatible strings based on known IP
> > variations when we discover them.  This seems fraught with demons since we
> > can't predict the scope of affected IP blocks (some steppings of one SoC, three
> > SoCs plus two steppings of a fourth, etc)
> > 
> > imho, the 'future-proofing' lies in being specific as to the naming of the
> > compatible strings against known hardware variations at the time.
> 
> Except that this clearly doesn't work, and the case raised by Simon is
> a perfect illustration of why planning ahead is beneficial. 

Odd, I'd use that as an example of the process working.  ;-)  we have
everyone using 'armada-370-neta' for a given block.  We discovered that
the original IP block (on the 370s) had a limitation (no hw checksum
for greater than 1600 bytes).  A newer version of the IP block (XP)
doesn't have the limitation.

So we change the driver to honor the limit for the 370 compatible
string.  We create a new compatible string for xp where the block
doesn't have the limitation.

How did the process fail?

> We already had the issue several times on mvebu platforms, so it
> should really become the rule to have one compatible string specific
> to the actual SoC in the list of compatible strings.

Sorry, I'm just not a fan of guessing.  But I'll fall back to the DT
maintainers on this one.  if they are ok with it, then I'll drop my
objection.

> Not doing so requires breaking DT backward compatibility more often, so
> wanting DT backward compatibility and not wanting to plan ahead is a
> bit antagonist.

I'm not seeing where backwards compatibility was broken?  A device with
an old dtb booting a newer kernel gets a bugfix.  In the case of an XP
board with an old dtb (armada-370-neta), the hardware still works, but
not optimally.  Upgrading the dtb will enable hw checksumming for jumbo
packets.

thx,

Jason.

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Thomas Petazzoni]

Dear Jason Cooper,

On Wed, 17 Jun 2015 21:39:26 +0000, Jason Cooper wrote:

> Odd, I'd use that as an example of the process working.  ;-)  we have
> everyone using 'armada-370-neta' for a given block.  We discovered that
> the original IP block (on the 370s) had a limitation (no hw checksum
> for greater than 1600 bytes).  A newer version of the IP block (XP)
> doesn't have the limitation.
> 
> So we change the driver to honor the limit for the 370 compatible
> string.  We create a new compatible string for xp where the block
> doesn't have the limitation.
> 
> How did the process fail?

Because now all Armada XP users of jumbo frames are looking the HW
checksum on their jumbo frames, which you can consider to be a
regression: it was working, it is no longer working.

Of course, since it falls back to SW checksumming, it still "works",
but some users can complain of the performance penalty and consider it
to be a regression.

If on Armada XP, we had used for the beginning:

	compatible = "marvell,armada-xp-neta", "marvell,armada-370-neta"

with only marvell,armada-370-neta supported originally, we could have
added this fix without breaking HW checksumming on jumbo frames for
Armada XP users.

So I'm sorry, but the process indeed failed, because Armada XP users
keeping their old Device Tree blob will see a regression.

> I'm not seeing where backwards compatibility was broken?  A device with
> an old dtb booting a newer kernel gets a bugfix.  In the case of an XP
> board with an old dtb (armada-370-neta), the hardware still works, but
> not optimally.  Upgrading the dtb will enable hw checksumming for jumbo
> packets.

"not optimally" is still a breakage.

Again, I personally don't care about DT backward compatibility as I
think it's a stupid requirement. But I like to point out to the
DT backward compatibility fanatics when it was actually broken :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Thomas Petazzoni]

Dear Jason Cooper,

On Wed, 17 Jun 2015 21:39:26 +0000, Jason Cooper wrote:

> Odd, I'd use that as an example of the process working.  ;-)  we have
> everyone using 'armada-370-neta' for a given block.  We discovered that
> the original IP block (on the 370s) had a limitation (no hw checksum
> for greater than 1600 bytes).  A newer version of the IP block (XP)
> doesn't have the limitation.
> 
> So we change the driver to honor the limit for the 370 compatible
> string.  We create a new compatible string for xp where the block
> doesn't have the limitation.
> 
> How did the process fail?

Because now all Armada XP users of jumbo frames are looking the HW
checksum on their jumbo frames, which you can consider to be a
regression: it was working, it is no longer working.

Of course, since it falls back to SW checksumming, it still "works",
but some users can complain of the performance penalty and consider it
to be a regression.

If on Armada XP, we had used for the beginning:

	compatible = "marvell,armada-xp-neta", "marvell,armada-370-neta"

with only marvell,armada-370-neta supported originally, we could have
added this fix without breaking HW checksumming on jumbo frames for
Armada XP users.

So I'm sorry, but the process indeed failed, because Armada XP users
keeping their old Device Tree blob will see a regression.

> I'm not seeing where backwards compatibility was broken?  A device with
> an old dtb booting a newer kernel gets a bugfix.  In the case of an XP
> board with an old dtb (armada-370-neta), the hardware still works, but
> not optimally.  Upgrading the dtb will enable hw checksumming for jumbo
> packets.

"not optimally" is still a breakage.

Again, I personally don't care about DT backward compatibility as I
think it's a stupid requirement. But I like to point out to the
DT backward compatibility fanatics when it was actually broken :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Simon Guinot]

On Wed, Jun 17, 2015 at 05:01:12PM +0000, Jason Cooper wrote:
> Hi Gregory,
> 
> On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
> > On 17/06/2015 17:12, Gregory CLEMENT wrote:
> > > On 17/06/2015 15:19, Simon Guinot wrote:
> > >> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> > >> 380 and 385 SoCs. Since at least one more hardware feature is available
> > >> for the Armada XP SoCs then a way to identify them is needed.
> > >>
> > >> This patch introduces a new compatible string "marvell,armada-xp-neta".
> > > 
> > > Let's be future proof by going further. I would like to have an compatible string
> > > for each SoC even if we currently we don't use them.
> 
> I disagree with this.  We can't predict what incosistencies we'll discover in
> the future.  We should only assign new compatible strings based on known IP
> variations when we discover them.  This seems fraught with demons since we
> can't predict the scope of affected IP blocks (some steppings of one SoC, three
> SoCs plus two steppings of a fourth, etc)
> 
> imho, the 'future-proofing' lies in being specific as to the naming of the
> compatible strings against known hardware variations at the time.

So, should I add more compatible strings or not ?

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150619/5bc99def/attachment.sig>

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Simon Guinot]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

On Wed, Jun 17, 2015 at 05:01:12PM +0000, Jason Cooper wrote:
> Hi Gregory,
> 
> On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
> > On 17/06/2015 17:12, Gregory CLEMENT wrote:
> > > On 17/06/2015 15:19, Simon Guinot wrote:
> > >> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> > >> 380 and 385 SoCs. Since at least one more hardware feature is available
> > >> for the Armada XP SoCs then a way to identify them is needed.
> > >>
> > >> This patch introduces a new compatible string "marvell,armada-xp-neta".
> > > 
> > > Let's be future proof by going further. I would like to have an compatible string
> > > for each SoC even if we currently we don't use them.
> 
> I disagree with this.  We can't predict what incosistencies we'll discover in
> the future.  We should only assign new compatible strings based on known IP
> variations when we discover them.  This seems fraught with demons since we
> can't predict the scope of affected IP blocks (some steppings of one SoC, three
> SoCs plus two steppings of a fourth, etc)
> 
> imho, the 'future-proofing' lies in being specific as to the naming of the
> compatible strings against known hardware variations at the time.

So, should I add more compatible strings or not ?

Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Simon Guinot]

On Fri, Jun 19, 2015 at 02:32:53PM +0200, Simon Guinot wrote:
> On Wed, Jun 17, 2015 at 05:01:12PM +0000, Jason Cooper wrote:
> > Hi Gregory,
> > 
> > On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
> > > On 17/06/2015 17:12, Gregory CLEMENT wrote:
> > > > On 17/06/2015 15:19, Simon Guinot wrote:
> > > >> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> > > >> 380 and 385 SoCs. Since at least one more hardware feature is available
> > > >> for the Armada XP SoCs then a way to identify them is needed.
> > > >>
> > > >> This patch introduces a new compatible string "marvell,armada-xp-neta".
> > > > 
> > > > Let's be future proof by going further. I would like to have an compatible string
> > > > for each SoC even if we currently we don't use them.
> > 
> > I disagree with this.  We can't predict what incosistencies we'll discover in
> > the future.  We should only assign new compatible strings based on known IP
> > variations when we discover them.  This seems fraught with demons since we
> > can't predict the scope of affected IP blocks (some steppings of one SoC, three
> > SoCs plus two steppings of a fourth, etc)
> > 
> > imho, the 'future-proofing' lies in being specific as to the naming of the
> > compatible strings against known hardware variations at the time.
> 
> So, should I add more compatible strings or not ?

Hi Gregory and Jason,

How do you want me to handle this ? Did you reach an agreement ?

Thanks,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150625/30762b36/attachment-0001.sig>

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Simon Guinot]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On Fri, Jun 19, 2015 at 02:32:53PM +0200, Simon Guinot wrote:
> On Wed, Jun 17, 2015 at 05:01:12PM +0000, Jason Cooper wrote:
> > Hi Gregory,
> > 
> > On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
> > > On 17/06/2015 17:12, Gregory CLEMENT wrote:
> > > > On 17/06/2015 15:19, Simon Guinot wrote:
> > > >> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> > > >> 380 and 385 SoCs. Since at least one more hardware feature is available
> > > >> for the Armada XP SoCs then a way to identify them is needed.
> > > >>
> > > >> This patch introduces a new compatible string "marvell,armada-xp-neta".
> > > > 
> > > > Let's be future proof by going further. I would like to have an compatible string
> > > > for each SoC even if we currently we don't use them.
> > 
> > I disagree with this.  We can't predict what incosistencies we'll discover in
> > the future.  We should only assign new compatible strings based on known IP
> > variations when we discover them.  This seems fraught with demons since we
> > can't predict the scope of affected IP blocks (some steppings of one SoC, three
> > SoCs plus two steppings of a fourth, etc)
> > 
> > imho, the 'future-proofing' lies in being specific as to the naming of the
> > compatible strings against known hardware variations at the time.
> 
> So, should I add more compatible strings or not ?

Hi Gregory and Jason,

How do you want me to handle this ? Did you reach an agreement ?

Thanks,

Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Jason Cooper]

On Thu, Jun 25, 2015 at 11:13:23AM +0200, Simon Guinot wrote:
> On Fri, Jun 19, 2015 at 02:32:53PM +0200, Simon Guinot wrote:
> > On Wed, Jun 17, 2015 at 05:01:12PM +0000, Jason Cooper wrote:
> > > On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
> > > > On 17/06/2015 17:12, Gregory CLEMENT wrote:
> > > > > On 17/06/2015 15:19, Simon Guinot wrote:
> > > > >> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> > > > >> 380 and 385 SoCs. Since at least one more hardware feature is available
> > > > >> for the Armada XP SoCs then a way to identify them is needed.
> > > > >>
> > > > >> This patch introduces a new compatible string "marvell,armada-xp-neta".
> > > > > 
> > > > > Let's be future proof by going further. I would like to have an compatible string
> > > > > for each SoC even if we currently we don't use them.
> > > 
> > > I disagree with this.  We can't predict what incosistencies we'll discover in
> > > the future.  We should only assign new compatible strings based on known IP
> > > variations when we discover them.  This seems fraught with demons since we
> > > can't predict the scope of affected IP blocks (some steppings of one SoC, three
> > > SoCs plus two steppings of a fourth, etc)
> > > 
> > > imho, the 'future-proofing' lies in being specific as to the naming of the
> > > compatible strings against known hardware variations at the time.
> > 
> > So, should I add more compatible strings or not ?
> 
> How do you want me to handle this ? Did you reach an agreement ?

Sorry, this slipped off my radar.  Probably EBKAC.  :)

I'm still of the opinion that future-proofing equates to guessing.
It has the advantage of, if we guess correctly, things are easier down
the road when we discover differences between similar IP blocks.
However, if we guess incorrectly, then we have a mess on our hands.
iow, this proposal fails poorly.

I've no problem breaking DT compatibility when it's determined that we
made a mistake (or mistakes) in the past.  See the irqchip rework that
Marc did a few cycles ago.

The difference here is that we know better.  We *know* that dtbs are
upgraded with the kernel.  We *know* that no one is shipping products
with dtbs in ROMs.  So what are we really trying to protect against?

thx,

Jason.

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Jason Cooper]

On Thu, Jun 25, 2015 at 11:13:23AM +0200, Simon Guinot wrote:
> On Fri, Jun 19, 2015 at 02:32:53PM +0200, Simon Guinot wrote:
> > On Wed, Jun 17, 2015 at 05:01:12PM +0000, Jason Cooper wrote:
> > > On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
> > > > On 17/06/2015 17:12, Gregory CLEMENT wrote:
> > > > > On 17/06/2015 15:19, Simon Guinot wrote:
> > > > >> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> > > > >> 380 and 385 SoCs. Since at least one more hardware feature is available
> > > > >> for the Armada XP SoCs then a way to identify them is needed.
> > > > >>
> > > > >> This patch introduces a new compatible string "marvell,armada-xp-neta".
> > > > > 
> > > > > Let's be future proof by going further. I would like to have an compatible string
> > > > > for each SoC even if we currently we don't use them.
> > > 
> > > I disagree with this.  We can't predict what incosistencies we'll discover in
> > > the future.  We should only assign new compatible strings based on known IP
> > > variations when we discover them.  This seems fraught with demons since we
> > > can't predict the scope of affected IP blocks (some steppings of one SoC, three
> > > SoCs plus two steppings of a fourth, etc)
> > > 
> > > imho, the 'future-proofing' lies in being specific as to the naming of the
> > > compatible strings against known hardware variations at the time.
> > 
> > So, should I add more compatible strings or not ?
> 
> How do you want me to handle this ? Did you reach an agreement ?

Sorry, this slipped off my radar.  Probably EBKAC.  :)

I'm still of the opinion that future-proofing equates to guessing.
It has the advantage of, if we guess correctly, things are easier down
the road when we discover differences between similar IP blocks.
However, if we guess incorrectly, then we have a mess on our hands.
iow, this proposal fails poorly.

I've no problem breaking DT compatibility when it's determined that we
made a mistake (or mistakes) in the past.  See the irqchip rework that
Marc did a few cycles ago.

The difference here is that we know better.  We *know* that dtbs are
upgraded with the kernel.  We *know* that no one is shipping products
with dtbs in ROMs.  So what are we really trying to protect against?

thx,

Jason.

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Gregory CLEMENT]

Hi Jason, Simon,

On 25/06/2015 15:20, Jason Cooper wrote:
> On Thu, Jun 25, 2015 at 11:13:23AM +0200, Simon Guinot wrote:
>> On Fri, Jun 19, 2015 at 02:32:53PM +0200, Simon Guinot wrote:
>>> On Wed, Jun 17, 2015 at 05:01:12PM +0000, Jason Cooper wrote:
>>>> On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
>>>>> On 17/06/2015 17:12, Gregory CLEMENT wrote:
>>>>>> On 17/06/2015 15:19, Simon Guinot wrote:
>>>>>>> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
>>>>>>> 380 and 385 SoCs. Since at least one more hardware feature is available
>>>>>>> for the Armada XP SoCs then a way to identify them is needed.
>>>>>>>
>>>>>>> This patch introduces a new compatible string "marvell,armada-xp-neta".
>>>>>>
>>>>>> Let's be future proof by going further. I would like to have an compatible string
>>>>>> for each SoC even if we currently we don't use them.
>>>>
>>>> I disagree with this.  We can't predict what incosistencies we'll discover in
>>>> the future.  We should only assign new compatible strings based on known IP
>>>> variations when we discover them.  This seems fraught with demons since we
>>>> can't predict the scope of affected IP blocks (some steppings of one SoC, three
>>>> SoCs plus two steppings of a fourth, etc)
>>>>
>>>> imho, the 'future-proofing' lies in being specific as to the naming of the
>>>> compatible strings against known hardware variations at the time.
>>>
>>> So, should I add more compatible strings or not ?
>>
>> How do you want me to handle this ? Did you reach an agreement ?
> 
> Sorry, this slipped off my radar.  Probably EBKAC.  :)
> 
> I'm still of the opinion that future-proofing equates to guessing.
> It has the advantage of, if we guess correctly, things are easier down
> the road when we discover differences between similar IP blocks.
> However, if we guess incorrectly, then we have a mess on our hands.
> iow, this proposal fails poorly.
> 
> I've no problem breaking DT compatibility when it's determined that we
> made a mistake (or mistakes) in the past.  See the irqchip rework that
> Marc did a few cycles ago.
> 
> The difference here is that we know better.  We *know* that dtbs are
> upgraded with the kernel.  We *know* that no one is shipping products
> with dtbs in ROMs.  So what are we really trying to protect against?

Ok then, if we don't have to ensure backward compatibility, then the patch
is fine as is.



Thanks,

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Gregory CLEMENT]

Hi Jason, Simon,

On 25/06/2015 15:20, Jason Cooper wrote:
> On Thu, Jun 25, 2015 at 11:13:23AM +0200, Simon Guinot wrote:
>> On Fri, Jun 19, 2015 at 02:32:53PM +0200, Simon Guinot wrote:
>>> On Wed, Jun 17, 2015 at 05:01:12PM +0000, Jason Cooper wrote:
>>>> On Wed, Jun 17, 2015 at 05:15:28PM +0200, Gregory CLEMENT wrote:
>>>>> On 17/06/2015 17:12, Gregory CLEMENT wrote:
>>>>>> On 17/06/2015 15:19, Simon Guinot wrote:
>>>>>>> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
>>>>>>> 380 and 385 SoCs. Since at least one more hardware feature is available
>>>>>>> for the Armada XP SoCs then a way to identify them is needed.
>>>>>>>
>>>>>>> This patch introduces a new compatible string "marvell,armada-xp-neta".
>>>>>>
>>>>>> Let's be future proof by going further. I would like to have an compatible string
>>>>>> for each SoC even if we currently we don't use them.
>>>>
>>>> I disagree with this.  We can't predict what incosistencies we'll discover in
>>>> the future.  We should only assign new compatible strings based on known IP
>>>> variations when we discover them.  This seems fraught with demons since we
>>>> can't predict the scope of affected IP blocks (some steppings of one SoC, three
>>>> SoCs plus two steppings of a fourth, etc)
>>>>
>>>> imho, the 'future-proofing' lies in being specific as to the naming of the
>>>> compatible strings against known hardware variations at the time.
>>>
>>> So, should I add more compatible strings or not ?
>>
>> How do you want me to handle this ? Did you reach an agreement ?
> 
> Sorry, this slipped off my radar.  Probably EBKAC.  :)
> 
> I'm still of the opinion that future-proofing equates to guessing.
> It has the advantage of, if we guess correctly, things are easier down
> the road when we discover differences between similar IP blocks.
> However, if we guess incorrectly, then we have a mess on our hands.
> iow, this proposal fails poorly.
> 
> I've no problem breaking DT compatibility when it's determined that we
> made a mistake (or mistakes) in the past.  See the irqchip rework that
> Marc did a few cycles ago.
> 
> The difference here is that we know better.  We *know* that dtbs are
> upgraded with the kernel.  We *know* that no one is shipping products
> with dtbs in ROMs.  So what are we really trying to protect against?

Ok then, if we don't have to ensure backward compatibility, then the patch
is fine as is.



Thanks,

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

[Gregory CLEMENT]

Hi Simon,

On 17/06/2015 15:19, Simon Guinot wrote:
> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> 380 and 385 SoCs. Since at least one more hardware feature is available
> for the Armada XP SoCs then a way to identify them is needed.
> 
> This patch introduces a new compatible string "marvell,armada-xp-neta".
> 
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> Cc: <stable@vger.kernel.org> # v3.8+

Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory

> ---
>  Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
>  drivers/net/ethernet/marvell/mvneta.c                             | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> index 750d577e8083..f5a8ca29aff0 100644
> --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> @@ -1,7 +1,7 @@
>  * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
>  
>  Required properties:
> -- compatible: should be "marvell,armada-370-neta".
> +- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
>  - reg: address and length of the register set for the device.
>  - interrupts: interrupt for the device
>  - phy: See ethernet.txt file in the same directory.
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index ce5f7f9cff06..aceb977b104d 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3179,6 +3179,7 @@ static int mvneta_remove(struct platform_device *pdev)
>  
>  static const struct of_device_id mvneta_match[] = {
>  	{ .compatible = "marvell,armada-370-neta" },
> +	{ .compatible = "marvell,armada-xp-neta" },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, mvneta_match);
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell,armada-xp-neta"

[Gregory CLEMENT]

Hi Simon,

On 17/06/2015 15:19, Simon Guinot wrote:
> The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
> 380 and 385 SoCs. Since at least one more hardware feature is available
> for the Armada XP SoCs then a way to identify them is needed.
> 
> This patch introduces a new compatible string "marvell,armada-xp-neta".
> 
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> Cc: <stable@vger.kernel.org> # v3.8+

Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory

> ---
>  Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 2 +-
>  drivers/net/ethernet/marvell/mvneta.c                             | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> index 750d577e8083..f5a8ca29aff0 100644
> --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
> @@ -1,7 +1,7 @@
>  * Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
>  
>  Required properties:
> -- compatible: should be "marvell,armada-370-neta".
> +- compatible: "marvell,armada-370-neta" or "marvell,armada-xp-neta".
>  - reg: address and length of the register set for the device.
>  - interrupts: interrupt for the device
>  - phy: See ethernet.txt file in the same directory.
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index ce5f7f9cff06..aceb977b104d 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3179,6 +3179,7 @@ static int mvneta_remove(struct platform_device *pdev)
>  
>  static const struct of_device_id mvneta_match[] = {
>  	{ .compatible = "marvell,armada-370-neta" },
> +	{ .compatible = "marvell,armada-xp-neta" },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, mvneta_match);
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v2 2/3] ARM: mvebu: update Ethernet compatible string for Armada XP

[Simon Guinot]

This patch updates the Ethernet DT nodes for Armada XP SoCs with the
compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: <stable@vger.kernel.org> # v3.8+
---
 arch/arm/boot/dts/armada-370-xp.dtsi     |  2 --
 arch/arm/boot/dts/armada-370.dtsi        |  8 ++++++++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |  2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |  2 +-
 arch/arm/boot/dts/armada-xp.dtsi         | 10 +++++++++-
 5 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index ec96f0b36346..06a2f2ae9d1e 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -270,7 +270,6 @@
 			};
 
 			eth0: ethernet at 70000 {
-				compatible = "marvell,armada-370-neta";
 				reg = <0x70000 0x4000>;
 				interrupts = <8>;
 				clocks = <&gateclk 4>;
@@ -286,7 +285,6 @@
 			};
 
 			eth1: ethernet at 74000 {
-				compatible = "marvell,armada-370-neta";
 				reg = <0x74000 0x4000>;
 				interrupts = <10>;
 				clocks = <&gateclk 3>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 00b50db57c9c..ca4257b2f77d 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -307,6 +307,14 @@
 					dmacap,memset;
 				};
 			};
+
+			ethernet at 70000 {
+				compatible = "marvell,armada-370-neta";
+			};
+
+			ethernet at 74000 {
+				compatible = "marvell,armada-370-neta";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 8479fdc9e9c2..c5fdc99f0dbe 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -318,7 +318,7 @@
 			};
 
 			eth3: ethernet at 34000 {
-				compatible = "marvell,armada-370-neta";
+				compatible = "marvell,armada-xp-neta";
 				reg = <0x34000 0x4000>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 661d54c81580..0e24f1a38540 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -356,7 +356,7 @@
 			};
 
 			eth3: ethernet at 34000 {
-				compatible = "marvell,armada-370-neta";
+				compatible = "marvell,armada-xp-neta";
 				reg = <0x34000 0x4000>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 013d63f69e36..8fdd6d7c0ab1 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -177,7 +177,7 @@
 			};
 
 			eth2: ethernet at 30000 {
-				compatible = "marvell,armada-370-neta";
+				compatible = "marvell,armada-xp-neta";
 				reg = <0x30000 0x4000>;
 				interrupts = <12>;
 				clocks = <&gateclk 2>;
@@ -220,6 +220,14 @@
 				};
 			};
 
+			ethernet at 70000 {
+				compatible = "marvell,armada-xp-neta";
+			};
+
+			ethernet at 74000 {
+				compatible = "marvell,armada-xp-neta";
+			};
+
 			xor at f0900 {
 				compatible = "marvell,orion-xor";
 				reg = <0xF0900 0x100
-- 
2.1.4

[PATCH v2 2/3] ARM: mvebu: update Ethernet compatible string for Armada XP

[Simon Guinot]

This patch updates the Ethernet DT nodes for Armada XP SoCs with the
compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: <stable@vger.kernel.org> # v3.8+
---
 arch/arm/boot/dts/armada-370-xp.dtsi     |  2 --
 arch/arm/boot/dts/armada-370.dtsi        |  8 ++++++++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |  2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |  2 +-
 arch/arm/boot/dts/armada-xp.dtsi         | 10 +++++++++-
 5 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index ec96f0b36346..06a2f2ae9d1e 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -270,7 +270,6 @@
 			};
 
 			eth0: ethernet@70000 {
-				compatible = "marvell,armada-370-neta";
 				reg = <0x70000 0x4000>;
 				interrupts = <8>;
 				clocks = <&gateclk 4>;
@@ -286,7 +285,6 @@
 			};
 
 			eth1: ethernet@74000 {
-				compatible = "marvell,armada-370-neta";
 				reg = <0x74000 0x4000>;
 				interrupts = <10>;
 				clocks = <&gateclk 3>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 00b50db57c9c..ca4257b2f77d 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -307,6 +307,14 @@
 					dmacap,memset;
 				};
 			};
+
+			ethernet@70000 {
+				compatible = "marvell,armada-370-neta";
+			};
+
+			ethernet@74000 {
+				compatible = "marvell,armada-370-neta";
+			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 8479fdc9e9c2..c5fdc99f0dbe 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -318,7 +318,7 @@
 			};
 
 			eth3: ethernet@34000 {
-				compatible = "marvell,armada-370-neta";
+				compatible = "marvell,armada-xp-neta";
 				reg = <0x34000 0x4000>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 661d54c81580..0e24f1a38540 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -356,7 +356,7 @@
 			};
 
 			eth3: ethernet@34000 {
-				compatible = "marvell,armada-370-neta";
+				compatible = "marvell,armada-xp-neta";
 				reg = <0x34000 0x4000>;
 				interrupts = <14>;
 				clocks = <&gateclk 1>;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 013d63f69e36..8fdd6d7c0ab1 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -177,7 +177,7 @@
 			};
 
 			eth2: ethernet@30000 {
-				compatible = "marvell,armada-370-neta";
+				compatible = "marvell,armada-xp-neta";
 				reg = <0x30000 0x4000>;
 				interrupts = <12>;
 				clocks = <&gateclk 2>;
@@ -220,6 +220,14 @@
 				};
 			};
 
+			ethernet@70000 {
+				compatible = "marvell,armada-xp-neta";
+			};
+
+			ethernet@74000 {
+				compatible = "marvell,armada-xp-neta";
+			};
+
 			xor@f0900 {
 				compatible = "marvell,orion-xor";
 				reg = <0xF0900 0x100
-- 
2.1.4

[PATCH v2 2/3] ARM: mvebu: update Ethernet compatible string for Armada XP

[Gregory CLEMENT]

Hi Simon,

> This patch updates the Ethernet DT nodes for Armada XP SoCs with the
> compatible string "marvell,armada-xp-neta".
> 
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> Cc: <stable@vger.kernel.org> # v3.8+

Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory

> ---
>  arch/arm/boot/dts/armada-370-xp.dtsi     |  2 --
>  arch/arm/boot/dts/armada-370.dtsi        |  8 ++++++++
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |  2 +-
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi |  2 +-
>  arch/arm/boot/dts/armada-xp.dtsi         | 10 +++++++++-
>  5 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index ec96f0b36346..06a2f2ae9d1e 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -270,7 +270,6 @@
>  			};
>  
>  			eth0: ethernet at 70000 {
> -				compatible = "marvell,armada-370-neta";
>  				reg = <0x70000 0x4000>;
>  				interrupts = <8>;
>  				clocks = <&gateclk 4>;
> @@ -286,7 +285,6 @@
>  			};
>  
>  			eth1: ethernet at 74000 {
> -				compatible = "marvell,armada-370-neta";
>  				reg = <0x74000 0x4000>;
>  				interrupts = <10>;
>  				clocks = <&gateclk 3>;
> diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
> index 00b50db57c9c..ca4257b2f77d 100644
> --- a/arch/arm/boot/dts/armada-370.dtsi
> +++ b/arch/arm/boot/dts/armada-370.dtsi
> @@ -307,6 +307,14 @@
>  					dmacap,memset;
>  				};
>  			};
> +
> +			ethernet at 70000 {
> +				compatible = "marvell,armada-370-neta";
> +			};
> +
> +			ethernet at 74000 {
> +				compatible = "marvell,armada-370-neta";
> +			};
>  		};
>  	};
>  };
> diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> index 8479fdc9e9c2..c5fdc99f0dbe 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> @@ -318,7 +318,7 @@
>  			};
>  
>  			eth3: ethernet at 34000 {
> -				compatible = "marvell,armada-370-neta";
> +				compatible = "marvell,armada-xp-neta";
>  				reg = <0x34000 0x4000>;
>  				interrupts = <14>;
>  				clocks = <&gateclk 1>;
> diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> index 661d54c81580..0e24f1a38540 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> @@ -356,7 +356,7 @@
>  			};
>  
>  			eth3: ethernet at 34000 {
> -				compatible = "marvell,armada-370-neta";
> +				compatible = "marvell,armada-xp-neta";
>  				reg = <0x34000 0x4000>;
>  				interrupts = <14>;
>  				clocks = <&gateclk 1>;
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> index 013d63f69e36..8fdd6d7c0ab1 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -177,7 +177,7 @@
>  			};
>  
>  			eth2: ethernet at 30000 {
> -				compatible = "marvell,armada-370-neta";
> +				compatible = "marvell,armada-xp-neta";
>  				reg = <0x30000 0x4000>;
>  				interrupts = <12>;
>  				clocks = <&gateclk 2>;
> @@ -220,6 +220,14 @@
>  				};
>  			};
>  
> +			ethernet at 70000 {
> +				compatible = "marvell,armada-xp-neta";
> +			};
> +
> +			ethernet at 74000 {
> +				compatible = "marvell,armada-xp-neta";
> +			};
> +
>  			xor at f0900 {
>  				compatible = "marvell,orion-xor";
>  				reg = <0xF0900 0x100
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [PATCH v2 2/3] ARM: mvebu: update Ethernet compatible string for Armada XP

[Gregory CLEMENT]

Hi Simon,

> This patch updates the Ethernet DT nodes for Armada XP SoCs with the
> compatible string "marvell,armada-xp-neta".
> 
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> Cc: <stable@vger.kernel.org> # v3.8+

Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory

> ---
>  arch/arm/boot/dts/armada-370-xp.dtsi     |  2 --
>  arch/arm/boot/dts/armada-370.dtsi        |  8 ++++++++
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |  2 +-
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi |  2 +-
>  arch/arm/boot/dts/armada-xp.dtsi         | 10 +++++++++-
>  5 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index ec96f0b36346..06a2f2ae9d1e 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -270,7 +270,6 @@
>  			};
>  
>  			eth0: ethernet@70000 {
> -				compatible = "marvell,armada-370-neta";
>  				reg = <0x70000 0x4000>;
>  				interrupts = <8>;
>  				clocks = <&gateclk 4>;
> @@ -286,7 +285,6 @@
>  			};
>  
>  			eth1: ethernet@74000 {
> -				compatible = "marvell,armada-370-neta";
>  				reg = <0x74000 0x4000>;
>  				interrupts = <10>;
>  				clocks = <&gateclk 3>;
> diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
> index 00b50db57c9c..ca4257b2f77d 100644
> --- a/arch/arm/boot/dts/armada-370.dtsi
> +++ b/arch/arm/boot/dts/armada-370.dtsi
> @@ -307,6 +307,14 @@
>  					dmacap,memset;
>  				};
>  			};
> +
> +			ethernet@70000 {
> +				compatible = "marvell,armada-370-neta";
> +			};
> +
> +			ethernet@74000 {
> +				compatible = "marvell,armada-370-neta";
> +			};
>  		};
>  	};
>  };
> diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> index 8479fdc9e9c2..c5fdc99f0dbe 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> @@ -318,7 +318,7 @@
>  			};
>  
>  			eth3: ethernet@34000 {
> -				compatible = "marvell,armada-370-neta";
> +				compatible = "marvell,armada-xp-neta";
>  				reg = <0x34000 0x4000>;
>  				interrupts = <14>;
>  				clocks = <&gateclk 1>;
> diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> index 661d54c81580..0e24f1a38540 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> @@ -356,7 +356,7 @@
>  			};
>  
>  			eth3: ethernet@34000 {
> -				compatible = "marvell,armada-370-neta";
> +				compatible = "marvell,armada-xp-neta";
>  				reg = <0x34000 0x4000>;
>  				interrupts = <14>;
>  				clocks = <&gateclk 1>;
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> index 013d63f69e36..8fdd6d7c0ab1 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -177,7 +177,7 @@
>  			};
>  
>  			eth2: ethernet@30000 {
> -				compatible = "marvell,armada-370-neta";
> +				compatible = "marvell,armada-xp-neta";
>  				reg = <0x30000 0x4000>;
>  				interrupts = <12>;
>  				clocks = <&gateclk 2>;
> @@ -220,6 +220,14 @@
>  				};
>  			};
>  
> +			ethernet@70000 {
> +				compatible = "marvell,armada-xp-neta";
> +			};
> +
> +			ethernet@74000 {
> +				compatible = "marvell,armada-xp-neta";
> +			};
> +
>  			xor@f0900 {
>  				compatible = "marvell,orion-xor";
>  				reg = <0xF0900 0x100
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v2 3/3] ARM: mvebu: disable IP checksum with jumbo frames for Armada 370

[Simon Guinot]

The Ethernet controller found in the Armada 370, 380 and 385 SoCs don't
support TCP/IP checksumming with frame sizes larger than 1600 bytes.

This patch fixes the issue by disabling the features NETIF_F_IP_CSUM and
NETIF_F_TSO for the Armada 370 and compatibles SoCs when the MTU is set
to a value greater than 1600 bytes.

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: <stable@vger.kernel.org> # v3.8+
---
 drivers/net/ethernet/marvell/mvneta.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index aceb977b104d..9b2b7478fe47 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -310,6 +310,7 @@ struct mvneta_port {
 	unsigned int link;
 	unsigned int duplex;
 	unsigned int speed;
+	unsigned int tx_csum_limit;
 	int use_inband_status:1;
 };
 
@@ -2502,8 +2503,10 @@ static int mvneta_change_mtu(struct net_device *dev, int mtu)
 
 	dev->mtu = mtu;
 
-	if (!netif_running(dev))
+	if (!netif_running(dev)) {
+		netdev_update_features(dev);
 		return 0;
+	}
 
 	/* The interface is running, so we have to force a
 	 * reallocation of the queues
@@ -2532,9 +2535,26 @@ static int mvneta_change_mtu(struct net_device *dev, int mtu)
 	mvneta_start_dev(pp);
 	mvneta_port_up(pp);
 
+	netdev_update_features(dev);
+
 	return 0;
 }
 
+static netdev_features_t mvneta_fix_features(struct net_device *dev,
+					     netdev_features_t features)
+{
+	struct mvneta_port *pp = netdev_priv(dev);
+
+	if (pp->tx_csum_limit && dev->mtu > pp->tx_csum_limit) {
+		features &= ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
+		netdev_info(dev,
+			    "Disable IP checksum for MTU greater than %dB\n",
+			    pp->tx_csum_limit);
+	}
+
+	return features;
+}
+
 /* Get mac address */
 static void mvneta_get_mac_addr(struct mvneta_port *pp, unsigned char *addr)
 {
@@ -2856,6 +2876,7 @@ static const struct net_device_ops mvneta_netdev_ops = {
 	.ndo_set_rx_mode     = mvneta_set_rx_mode,
 	.ndo_set_mac_address = mvneta_set_mac_addr,
 	.ndo_change_mtu      = mvneta_change_mtu,
+	.ndo_fix_features    = mvneta_fix_features,
 	.ndo_get_stats64     = mvneta_get_stats64,
 	.ndo_do_ioctl        = mvneta_ioctl,
 };
@@ -3101,6 +3122,9 @@ static int mvneta_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (of_device_is_compatible(dn, "marvell,armada-370-neta"))
+		pp->tx_csum_limit = 1600;
+
 	pp->tx_ring_size = MVNETA_MAX_TXD;
 	pp->rx_ring_size = MVNETA_MAX_RXD;
 
-- 
2.1.4

[PATCH v2 3/3] ARM: mvebu: disable IP checksum with jumbo frames for Armada 370

[Simon Guinot]

The Ethernet controller found in the Armada 370, 380 and 385 SoCs don't
support TCP/IP checksumming with frame sizes larger than 1600 bytes.

This patch fixes the issue by disabling the features NETIF_F_IP_CSUM and
NETIF_F_TSO for the Armada 370 and compatibles SoCs when the MTU is set
to a value greater than 1600 bytes.

Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: <stable@vger.kernel.org> # v3.8+
---
 drivers/net/ethernet/marvell/mvneta.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index aceb977b104d..9b2b7478fe47 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -310,6 +310,7 @@ struct mvneta_port {
 	unsigned int link;
 	unsigned int duplex;
 	unsigned int speed;
+	unsigned int tx_csum_limit;
 	int use_inband_status:1;
 };
 
@@ -2502,8 +2503,10 @@ static int mvneta_change_mtu(struct net_device *dev, int mtu)
 
 	dev->mtu = mtu;
 
-	if (!netif_running(dev))
+	if (!netif_running(dev)) {
+		netdev_update_features(dev);
 		return 0;
+	}
 
 	/* The interface is running, so we have to force a
 	 * reallocation of the queues
@@ -2532,9 +2535,26 @@ static int mvneta_change_mtu(struct net_device *dev, int mtu)
 	mvneta_start_dev(pp);
 	mvneta_port_up(pp);
 
+	netdev_update_features(dev);
+
 	return 0;
 }
 
+static netdev_features_t mvneta_fix_features(struct net_device *dev,
+					     netdev_features_t features)
+{
+	struct mvneta_port *pp = netdev_priv(dev);
+
+	if (pp->tx_csum_limit && dev->mtu > pp->tx_csum_limit) {
+		features &= ~(NETIF_F_IP_CSUM | NETIF_F_TSO);
+		netdev_info(dev,
+			    "Disable IP checksum for MTU greater than %dB\n",
+			    pp->tx_csum_limit);
+	}
+
+	return features;
+}
+
 /* Get mac address */
 static void mvneta_get_mac_addr(struct mvneta_port *pp, unsigned char *addr)
 {
@@ -2856,6 +2876,7 @@ static const struct net_device_ops mvneta_netdev_ops = {
 	.ndo_set_rx_mode     = mvneta_set_rx_mode,
 	.ndo_set_mac_address = mvneta_set_mac_addr,
 	.ndo_change_mtu      = mvneta_change_mtu,
+	.ndo_fix_features    = mvneta_fix_features,
 	.ndo_get_stats64     = mvneta_get_stats64,
 	.ndo_do_ioctl        = mvneta_ioctl,
 };
@@ -3101,6 +3122,9 @@ static int mvneta_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (of_device_is_compatible(dn, "marvell,armada-370-neta"))
+		pp->tx_csum_limit = 1600;
+
 	pp->tx_ring_size = MVNETA_MAX_TXD;
 	pp->rx_ring_size = MVNETA_MAX_RXD;
 
-- 
2.1.4

[PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[Thomas Petazzoni]

Dear Simon Guinot,

On Wed, 17 Jun 2015 15:19:19 +0200, Simon Guinot wrote:

> This patch series fixes the Ethernet jumbo frames support for the SoCs
> Armada 370, 380 and 385. Unlike Armada XP, the Ethernet controller for
> this SoCs don't support TCP/IP checksumming with a frame size larger
> than 1600 bytes.
> 
> This patches should be applied to the -stable kernels 3.8 and onwards.

You should add a Fixes: tag to each commit to indicate which commit is
being fixed by your patches.

Also, I was a bit surprised by your statement that Armada 38x is also
affected by the problem, since Armada 38x is more recent than Armada
XP. but indeed, according to the Armada 38x datasheet:

  IPv4 and TCP/UDP over IPv4/IPv6 checksum generation on transmit
  frames for standard Ethernet packet size

While the Armada XP datasheet says:

  Long frames transmission (including jumbo frames), with
  IPv4/v6/TCP/UDP checksum generation

So it seems like you're right about this!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[Thomas Petazzoni]

Dear Simon Guinot,

On Wed, 17 Jun 2015 15:19:19 +0200, Simon Guinot wrote:

> This patch series fixes the Ethernet jumbo frames support for the SoCs
> Armada 370, 380 and 385. Unlike Armada XP, the Ethernet controller for
> this SoCs don't support TCP/IP checksumming with a frame size larger
> than 1600 bytes.
> 
> This patches should be applied to the -stable kernels 3.8 and onwards.

You should add a Fixes: tag to each commit to indicate which commit is
being fixed by your patches.

Also, I was a bit surprised by your statement that Armada 38x is also
affected by the problem, since Armada 38x is more recent than Armada
XP. but indeed, according to the Armada 38x datasheet:

  IPv4 and TCP/UDP over IPv4/IPv6 checksum generation on transmit
  frames for standard Ethernet packet size

While the Armada XP datasheet says:

  Long frames transmission (including jumbo frames), with
  IPv4/v6/TCP/UDP checksum generation

So it seems like you're right about this!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[Simon Guinot]

On Wed, Jun 17, 2015 at 05:24:58PM +0200, Thomas Petazzoni wrote:
> Dear Simon Guinot,
> 
> On Wed, 17 Jun 2015 15:19:19 +0200, Simon Guinot wrote:
> 
> > This patch series fixes the Ethernet jumbo frames support for the SoCs
> > Armada 370, 380 and 385. Unlike Armada XP, the Ethernet controller for
> > this SoCs don't support TCP/IP checksumming with a frame size larger
> > than 1600 bytes.
> > 
> > This patches should be applied to the -stable kernels 3.8 and onwards.
> 
> You should add a Fixes: tag to each commit to indicate which commit is
> being fixed by your patches.
> 
> Also, I was a bit surprised by your statement that Armada 38x is also
> affected by the problem, since Armada 38x is more recent than Armada
> XP. but indeed, according to the Armada 38x datasheet:
> 
>   IPv4 and TCP/UDP over IPv4/IPv6 checksum generation on transmit
>   frames for standard Ethernet packet size
> 
> While the Armada XP datasheet says:
> 
>   Long frames transmission (including jumbo frames), with
>   IPv4/v6/TCP/UDP checksum generation
> 
> So it seems like you're right about this!

At first, I though this was an error in the Armada 38x datasheet (maybe
a sloppy copy/paster). Therefore I have checked on an DB-88F6820-GP
board and then I can confirm that the Armada 38x is also affected.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150617/bed0e4d9/attachment.sig>

Re: [PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[Simon Guinot]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On Wed, Jun 17, 2015 at 05:24:58PM +0200, Thomas Petazzoni wrote:
> Dear Simon Guinot,
> 
> On Wed, 17 Jun 2015 15:19:19 +0200, Simon Guinot wrote:
> 
> > This patch series fixes the Ethernet jumbo frames support for the SoCs
> > Armada 370, 380 and 385. Unlike Armada XP, the Ethernet controller for
> > this SoCs don't support TCP/IP checksumming with a frame size larger
> > than 1600 bytes.
> > 
> > This patches should be applied to the -stable kernels 3.8 and onwards.
> 
> You should add a Fixes: tag to each commit to indicate which commit is
> being fixed by your patches.
> 
> Also, I was a bit surprised by your statement that Armada 38x is also
> affected by the problem, since Armada 38x is more recent than Armada
> XP. but indeed, according to the Armada 38x datasheet:
> 
>   IPv4 and TCP/UDP over IPv4/IPv6 checksum generation on transmit
>   frames for standard Ethernet packet size
> 
> While the Armada XP datasheet says:
> 
>   Long frames transmission (including jumbo frames), with
>   IPv4/v6/TCP/UDP checksum generation
> 
> So it seems like you're right about this!

At first, I though this was an error in the Armada 38x datasheet (maybe
a sloppy copy/paster). Therefore I have checked on an DB-88F6820-GP
board and then I can confirm that the Armada 38x is also affected.

Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[Thomas Petazzoni]

Simon,

On Wed, 17 Jun 2015 19:22:17 +0200, Simon Guinot wrote:

> > You should add a Fixes: tag to each commit to indicate which commit is
> > being fixed by your patches.
> > 
> > Also, I was a bit surprised by your statement that Armada 38x is also
> > affected by the problem, since Armada 38x is more recent than Armada
> > XP. but indeed, according to the Armada 38x datasheet:
> > 
> >   IPv4 and TCP/UDP over IPv4/IPv6 checksum generation on transmit
> >   frames for standard Ethernet packet size
> > 
> > While the Armada XP datasheet says:
> > 
> >   Long frames transmission (including jumbo frames), with
> >   IPv4/v6/TCP/UDP checksum generation
> > 
> > So it seems like you're right about this!
> 
> At first, I though this was an error in the Armada 38x datasheet (maybe
> a sloppy copy/paster). Therefore I have checked on an DB-88F6820-GP
> board and then I can confirm that the Armada 38x is also affected.

Ok, so the datasheet was correct (houra!). Thanks a lot for having done
the additional testing.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v2 0/3] Fix Ethernet jumbo frames support for Armada 370 and 38x

[Thomas Petazzoni]

Simon,

On Wed, 17 Jun 2015 19:22:17 +0200, Simon Guinot wrote:

> > You should add a Fixes: tag to each commit to indicate which commit is
> > being fixed by your patches.
> > 
> > Also, I was a bit surprised by your statement that Armada 38x is also
> > affected by the problem, since Armada 38x is more recent than Armada
> > XP. but indeed, according to the Armada 38x datasheet:
> > 
> >   IPv4 and TCP/UDP over IPv4/IPv6 checksum generation on transmit
> >   frames for standard Ethernet packet size
> > 
> > While the Armada XP datasheet says:
> > 
> >   Long frames transmission (including jumbo frames), with
> >   IPv4/v6/TCP/UDP checksum generation
> > 
> > So it seems like you're right about this!
> 
> At first, I though this was an error in the Armada 38x datasheet (maybe
> a sloppy copy/paster). Therefore I have checked on an DB-88F6820-GP
> board and then I can confirm that the Armada 38x is also affected.

Ok, so the datasheet was correct (houra!). Thanks a lot for having done
the additional testing.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com