[PATCH v5 0/2] Add support for the ethernet switch on the ESPRESSObin

[Gregory CLEMENT]

Hi,

This set of patches adds support for the Marvell Ethernet switch
88E6341 which is found on the ESPRESSObin. With this series the
network is usable on this board.

From now on, I am taking care of this series.

As Andrew Lunn pointed this switch is not fully compatible with the
6352. However it is neither fully compatible with the 6390. Actually
it is more a mix between this two families.

I created a new family for this switch and filled the ops structure by
selecting which seems the more appropriate functions. I rebased the
series on net-next/master which allowed me to benefit to the eeprom
functions introduced for the 6390.



While comparing the datasheet and the ops functions used, some
question came to me. They should not prevent applying this series,
but their answer would help me to have a better understanding of the
dsa subsystem.

- Are the temperature related operation still useful with dsa2 ?

Indeed the hwmon initialization is only done from dsa_probe which is
not called if we use dsa2.

- Why the setup is done differently between the 6390 and the 6352
families when the have exactly the same register?

- On the Port Controller 2, the bit PORT_CONTROL_2_MAP_DA is set for
6352 and not for 6390 whereas the same bit exists in 6360 and the
description for this bit is the same for both datasheet.


- Register PORT_ATU_CONTROL and PORT_PRI_OVERRIDE are reset on 6352
and not on 6390. While here again the registers description are
the same.

Thanks,

Gregory


Gregory CLEMENT (1):
net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

Romain Perier (1):
net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >=
num_of_ports

drivers/net/dsa/mv88e6xxx/chip.c | 61 +++++++++++++++++++++++++++++------
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 21 +++++++++++-
2 files changed, 72 insertions(+), 10 deletions(-)

--
2.11.0

[Gregory CLEMENT]

From: Romain Perier <romain...@free-electrons.com>

Some Marvell ethernet switches have internal ethernet transceivers with
hardcoded phy addresses. These addresses can be greater than the number
of ports or its value might be different than the associated port number.
This is for example the case for MV88E6341 that has 6 ports and internal
Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.

This commits fixes the issue by removing the condition in MDIO callbacks.

Signed-off-by: Romain Perier <romain...@free-electrons.com>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
1 file changed, 6 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 987b2dbbd35a..d1960ae0a618 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2882,9 +2882,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
u16 val;
int err;

- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_read(chip, phy, reg, &val);
mutex_unlock(&chip->reg_lock);
@@ -2897,9 +2894,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
struct mv88e6xxx_chip *chip = bus->priv;
int err;

- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_write(chip, phy, reg, val);
mutex_unlock(&chip->reg_lock);
--
2.11.0

[Andrew Lunn]

> While comparing the datasheet and the ops functions used, some
> question came to me. They should not prevent applying this series,
> but their answer would help me to have a better understanding of the
> dsa subsystem.
>
> - Are the temperature related operation still useful with dsa2 ?

No. I'm in the process of moving the code into the Marvell PHY driver,
since the sensor is in the embedded PHYs.

What ID does the embedded PHY use? The 6390 has a blank ID, where as
older device have a real ID.

> - Why the setup is done differently between the 6390 and the 6352
> families when the have exactly the same register?

EDSA on 6390 works differently to 6352, meaning it breaks. So we need
to run the 6390 with DSA tagging, not EDSA. Maybe this is the source
of the differences?

It should also be noted that the 6390 support is not yet complete. I
have a few more patches in my tree to post.

> - On the Port Controller 2, the bit PORT_CONTROL_2_MAP_DA is set for
> 6352 and not for 6390 whereas the same bit exists in 6360 and the
> description for this bit is the same for both datasheet.

Humm, it does look like it is missing mv88e6xxx_6390_family(chip).

>
> - Register PORT_ATU_CONTROL and PORT_PRI_OVERRIDE are reset on 6352
> and not on 6390. While here again the registers description are
> the same.

And the same here. I've mostly been working on where the 6390 is
different. Where it is the same i've mostly ignored it so far :-)

There is also an ongoing effort to remove all these big if statements
with a list of families.

Andrew

[Vivien Didelot]

Hi Gregory,

Gregory CLEMENT <gregory...@free-electrons.com> writes:

> I created a new family for this switch and filled the ops structure by
> selecting which seems the more appropriate functions.

We don't create families, this information comes from the Marvell
DSDT. If you don't know which switch family Marvell put the 6341 in, you
should be able to use MV88E6XXX_FAMILY_NONE safely.

Note that this is anyway not a useful information since the Marvell
chips have lots of per-models specificities... Any family related code
(e.g. the mv88e6xxx_*_family() helpers) are likely to be removed soon.

> While comparing the datasheet and the ops functions used, some
> question came to me. They should not prevent applying this series,
> but their answer would help me to have a better understanding of the
> dsa subsystem.
>
> - Are the temperature related operation still useful with dsa2 ?
>
> Indeed the hwmon initialization is only done from dsa_probe which is
> not called if we use dsa2.

HWMON is not supported anymore in dsa2. Andrew is in the process of
moving its support to the PHY driver instead. However you can still test
it locally with this patch:

http://ix.io/1QvY

The temperature is accessed via ethtool -e|-E.

> - Why the setup is done differently between the 6390 and the 6352
> families when the have exactly the same register?
>
> - On the Port Controller 2, the bit PORT_CONTROL_2_MAP_DA is set for
> 6352 and not for 6390 whereas the same bit exists in 6360 and the
> description for this bit is the same for both datasheet.
>
>
> - Register PORT_ATU_CONTROL and PORT_PRI_OVERRIDE are reset on 6352
> and not on 6390. While here again the registers description are
> the same.

You are totally correct here. We are in the process of moving every old
pieces of code such as this:

if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
mv88e6xxx_6095_family(chip) || mv88e6xxx_6320_family(chip) ||
mv88e6xxx_6185_family(chip))
reg = PORT_CONTROL_2_MAP_DA;

into proper "library" functions defined in the correct internal SMI
device specific file (here, port.c), to be used in the mv88e6xxx_ops
structure, if a given model support the feature described in the
datasheet.

So the two registers you mentioned don't have proper ops yet.

Thanks!

Vivien

[Vivien Didelot]

Hi Gregory,

Gregory CLEMENT <gregory...@free-electrons.com> writes:

> From: Romain Perier <romain...@free-electrons.com>
>
> Some Marvell ethernet switches have internal ethernet transceivers with
> hardcoded phy addresses. These addresses can be greater than the number
> of ports or its value might be different than the associated port number.
> This is for example the case for MV88E6341 that has 6 ports and internal
> Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.

Isn't there an hardware table used to map the PHY addresses on such chip?

> This commits fixes the issue by removing the condition in MDIO callbacks.
>
> Signed-off-by: Romain Perier <romain...@free-electrons.com>
> Reviewed-by: Andrew Lunn <and...@lunn.ch>
> Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>

The patch is anyway still valid:

Reviewed-by: Vivien Didelot <vivien....@savoirfairelinux.com>

Thanks,

Vivien

[Vivien Didelot]

Hi Gregory,

Vivien Didelot <vivien....@savoirfairelinux.com> writes:

> The temperature is accessed via ethtool -e|-E.

Oops, that was a silly mistake, no need to explain! ;-)

Vivien

[Jon Pannell]

+ Bob + Christine

Jon Pannell


-----Original Message-----
From: Andrew Lunn [mailto:and...@lunn.ch]
Sent: Thursday, January 19, 2017 2:06 PM
To: Gregory CLEMENT <gregory...@free-electrons.com>
Cc: Vivien Didelot <vivien....@savoirfairelinux.com>; Florian Fainelli <f.fai...@gmail.com>; net...@vger.kernel.org; linux-...@vger.kernel.org; David S. Miller <da...@davemloft.net>; Jason Cooper <ja...@lakedaemon.net>; Sebastian Hesselbarth <sebastian....@gmail.com>; Thomas Petazzoni <thomas.p...@free-electrons.com>; linux-ar...@lists.infradead.org; Nadav Haklai <nad...@marvell.com>; Wilson Ding <din...@marvell.com>; Kostya Porotchkin <kos...@marvell.com>; Joe Zhou <shj...@marvell.com>; Jon Pannell <jpan...@marvell.com>
Subject: [EXT] Re: [PATCH v5 0/2] Add support for the ethernet switch on the ESPRESSObin

External Email

----------------------------------------------------------------------

[Andrew Lunn]

On Thu, Jan 19, 2017 at 05:13:12PM -0500, Vivien Didelot wrote:
> Hi Gregory,
>
> Gregory CLEMENT <gregory...@free-electrons.com> writes:
>
> > From: Romain Perier <romain...@free-electrons.com>
> >
> > Some Marvell ethernet switches have internal ethernet transceivers with
> > hardcoded phy addresses. These addresses can be greater than the number
> > of ports or its value might be different than the associated port number.
> > This is for example the case for MV88E6341 that has 6 ports and internal
> > Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.
>
> Isn't there an hardware table used to map the PHY addresses on such chip?

The 6390 has something like this. But if we can avoid it, lets keep it
KISS.

Andrew

[Vivien Didelot]

Hi Andrew,

Andrew Lunn <and...@lunn.ch> writes:

>> Isn't there an hardware table used to map the PHY addresses on such chip?
>
> The 6390 has something like this. But if we can avoid it, lets keep it
> KISS.

I definitely agree. I was just curious about this new chip.

Thanks,

Vivien

[Gregory CLEMENT]

Hi Andrew,

On jeu., janv. 19 2017, Andrew Lunn <and...@lunn.ch> wrote:

>> While comparing the datasheet and the ops functions used, some
>> question came to me. They should not prevent applying this series,
>> but their answer would help me to have a better understanding of the
>> dsa subsystem.
>>
>> - Are the temperature related operation still useful with dsa2 ?
>
> No. I'm in the process of moving the code into the Marvell PHY driver,
> since the sensor is in the embedded PHYs.
>
> What ID does the embedded PHY use? The 6390 has a blank ID, where as
> older device have a real ID.

Actually I didn't find anything related to the temperature measurement
in the datasheet I have. For the 6390 there is a dedicated datsheet for
the PHY part for the 6352 it is part of the same datasheet.

After a second look I think I don't have anything related to the PHY
part in the datasheets.

What I wanted to do was to test 6390 and 6352 temperature related
functions and to see if one of them worked. That's how I realized it was
not possible to do it with dsa2.

>
>> - Why the setup is done differently between the 6390 and the 6352
>> families when the have exactly the same register?
>
> EDSA on 6390 works differently to 6352, meaning it breaks. So we need
> to run the 6390 with DSA tagging, not EDSA. Maybe this is the source
> of the differences?
>
> It should also be noted that the 6390 support is not yet complete. I
> have a few more patches in my tree to post.
>
>> - On the Port Controller 2, the bit PORT_CONTROL_2_MAP_DA is set for
>> 6352 and not for 6390 whereas the same bit exists in 6360 and the
>> description for this bit is the same for both datasheet.
>
> Humm, it does look like it is missing mv88e6xxx_6390_family(chip).
>
>>
>> - Register PORT_ATU_CONTROL and PORT_PRI_OVERRIDE are reset on 6352
>> and not on 6390. While here again the registers description are
>> the same.
>
> And the same here. I've mostly been working on where the 6390 is
> different. Where it is the same i've mostly ignored it so far :-)
>
> There is also an ongoing effort to remove all these big if statements
> with a list of families.

Thanks for this answers I understand it a little better now.

Gregory

>
> Andrew

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

[Andrew Lunn]

> What I wanted to do was to test 6390 and 6352 temperature related
> functions and to see if one of them worked. That's how I realized it was
> not possible to do it with dsa2.

Hi Gregory

Probably the best thing to do is wait until the temperature code moves
into the PHY driver. It then becomes easier to test. It probably is
the same as the 6352, or like the 6390 which i've so far failed to get
working, despite the registers being the same as the 6352.

Andrew

[David Miller]

From: Gregory CLEMENT <gregory...@free-electrons.com>
Date: Thu, 19 Jan 2017 22:49:32 +0100

> I created a new family for this switch and filled the ops structure
> by selecting which seems the more appropriate functions. I rebased
> the series on net-next/master which allowed me to benefit to the
> eeprom functions introduced for the 6390.

It looks like there will be at least one more respin of this series,
specifically to remove the new family as Vivien seems to object to
this.

[Andrew Lunn]

> Actually I didn't find anything related to the temperature measurement
> in the datasheet I have. For the 6390 there is a dedicated datsheet for
> the PHY part for the 6352 it is part of the same datasheet.

Hi Gregory

The temperature sensor changes have landed in net-next. If you have
time, please rebase to it and do some tests. Here are the likely
outcomes:

1) Like the 6390, it does not have a valid PHY product ID. Hence the
Marvell PHY driver is not loaded. You can see the PHY ID in

/sys/bus/mdio_bus/devices/*/phy_id

If it is 0x01410000, there is no product ID. I have a workaround for
this.

2) It has a valid phy_id, but it is not known to the marvell driver.
Add an entry to the table at the bottom of drivers/net/phy/marvell.c,
and a new entry in marvell_drivers. I would copy the 1540.


3) The Marvell PHY driver does recognise it, and makes the temperature
available in /sys/class/hwmon/hwmon*/temp1_input. It always returns
-25000mC. Same problem i have with the 6390. No idea how to fix it yet.

4) The Marvell PHY driver does recognise it, and makes the temperature
available in /sys/class/hwmon/hwmon*/temp1_input. The value is O.K. It
all works :-)

Personally, i'm not betting on 4 :-)


Andrew

[Gregory CLEMENT]

Hi David,

I am about to send a new version. However about removing the new family,
I thought that with the confirmation from Andrew we could keep it.

Vivien could you confirm this?

Thanks,

Gregory

[Vivien Didelot]

Hi Gregory,

Gregory CLEMENT <gregory...@free-electrons.com> writes:

> Hi David,
>
> On ven., janv. 20 2017, David Miller <da...@davemloft.net> wrote:
>
>> From: Gregory CLEMENT <gregory...@free-electrons.com>
>> Date: Thu, 19 Jan 2017 22:49:32 +0100
>>
>>> I created a new family for this switch and filled the ops structure
>>> by selecting which seems the more appropriate functions. I rebased
>>> the series on net-next/master which allowed me to benefit to the
>>> eeprom functions introduced for the 6390.
>>
>> It looks like there will be at least one more respin of this series,
>> specifically to remove the new family as Vivien seems to object to
>> this.
>
> I am about to send a new version. However about removing the new family,
> I thought that with the confirmation from Andrew we could keep it.
>
> Vivien could you confirm this?

I confirm.

Thanks!

Vivien

[Andrew Lunn]

On Tue, Jan 24, 2017 at 05:47:06PM +0100, Gregory CLEMENT wrote:
> Hi David,
>
> On ven., janv. 20 2017, David Miller <da...@davemloft.net> wrote:
>
> > From: Gregory CLEMENT <gregory...@free-electrons.com>
> > Date: Thu, 19 Jan 2017 22:49:32 +0100
> >
> >> I created a new family for this switch and filled the ops structure
> >> by selecting which seems the more appropriate functions. I rebased
> >> the series on net-next/master which allowed me to benefit to the
> >> eeprom functions introduced for the 6390.
> >
> > It looks like there will be at least one more respin of this series,
> > specifically to remove the new family as Vivien seems to object to
> > this.
>
> I am about to send a new version. However about removing the new family,
> I thought that with the confirmation from Andrew we could keep it.

Hi Gregory

Yes, keep it. It will hopefully be short lived, but it is needed at
the moment.

Andrew

[Gregory CLEMENT]

From: Romain Perier <romain...@free-electrons.com>

Some Marvell ethernet switches have internal ethernet transceivers with
hardcoded phy addresses. These addresses can be greater than the number
of ports or its value might be different than the associated port number.
This is for example the case for MV88E6341 that has 6 ports and internal
Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.

This commits fixes the issue by removing the condition in MDIO callbacks.

Signed-off-by: Romain Perier <romain...@free-electrons.com>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>

---
drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
1 file changed, 6 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c

index c7e08e13bb54..7d942f8a42a7 100644

--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2882,9 +2882,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
u16 val;
int err;

- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_read(chip, phy, reg, &val);
mutex_unlock(&chip->reg_lock);
@@ -2897,9 +2894,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
struct mv88e6xxx_chip *chip = bus->priv;
int err;

- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_write(chip, phy, reg, val);
mutex_unlock(&chip->reg_lock);
--

git-series 0.9.1

[Gregory CLEMENT]

Hi,

This set of patches adds support for the Marvell Ethernet Topaz switch
family (88E6141/88E6341) which is found on the ESPRESSObin. With this

series the network is usable on this board.

I rebased the series again on the very last net-next/master which
allowed me this time to benefit to the temperature support introduced
by Andrew Lunn.

I still do not have a datasheet about the PHY embedded in the switch
but thanks to the help of Andrew I was able to retrieve the PHY
ID. Then, by using the 88E1510 operations I was able to get temperature
with credible values.

In this series I also added the support of the 88E6141 which is
actually the switch on the boards I tested. The difference with the
88E6341, is the absence of the TCAM on the 88E6141, however I don't
think this feature is used in the driver, so currently for Linux there
is no difference except the switch ID.

Thanks,

Gregory

Changelog:

v5 -> v6:
- rebased on net-next/master (d140199af510)
- Fix the redundant check on mv88e6xxx_6341_family (reported by Julia
Lawall)
- Add support for the 88E6141
- Move support for temperature sensor in the phy part

Gregory CLEMENT (3):

net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141
phy: marvell: Add support for the PHY embedded in the topaz switch

Romain Perier (1):
net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports

drivers/net/dsa/mv88e6xxx/chip.c | 102 ++++++++++++++++++++++++---
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 21 +++++-
drivers/net/phy/marvell.c | 21 ++++++-
include/linux/marvell_phy.h | 1 +-
4 files changed, 135 insertions(+), 10 deletions(-)

base-commit: 1d0ec6626e558f9eb0043352745c02c42ff13a11
--
git-series 0.9.1

[Gregory CLEMENT]

The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with
four integrated 10/100/1000Mbps Ethernet transceivers and one high speed
SerDes interfaces. It is partially compatible with switches of family
88E6352 and switches of family 88E6390.

This commit adds an initial support for this switch by describing its
capabilities to the driver and introducing a new family.

Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>
---

drivers/net/dsa/mv88e6xxx/chip.c | 54 ++++++++++++++++++++++++++--
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 19 +++++++++-
2 files changed, 69 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 7d942f8a42a7..00db33ca1696 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -664,6 +664,11 @@ static bool mv88e6xxx_6320_family(struct mv88e6xxx_chip *chip)
return chip->info->family == MV88E6XXX_FAMILY_6320;
}

+static bool mv88e6xxx_6341_family(struct mv88e6xxx_chip *chip)
+{
+ return chip->info->family == MV88E6XXX_FAMILY_6341;
+}
+
static bool mv88e6xxx_6351_family(struct mv88e6xxx_chip *chip)
{
return chip->info->family == MV88E6XXX_FAMILY_6351;
@@ -1688,7 +1693,8 @@ static int _mv88e6xxx_vtu_new(struct mv88e6xxx_chip *chip, u16 vid,
: GLOBAL_VTU_DATA_MEMBER_TAG_NON_MEMBER;

if (mv88e6xxx_6097_family(chip) || mv88e6xxx_6165_family(chip) ||
- mv88e6xxx_6351_family(chip) || mv88e6xxx_6352_family(chip)) {
+ mv88e6xxx_6351_family(chip) || mv88e6xxx_6352_family(chip) ||
+ mv88e6xxx_6341_family(chip)) {
struct mv88e6xxx_vtu_entry vstp;

/* Adding a VTU entry requires a valid STU entry. As VSTP is not
@@ -2543,7 +2549,7 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)

if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
mv88e6xxx_6095_family(chip) || mv88e6xxx_6320_family(chip) ||

- mv88e6xxx_6185_family(chip))
+ mv88e6xxx_6185_family(chip) || mv88e6xxx_6341_family(chip))
reg = PORT_CONTROL_2_MAP_DA;

if (mv88e6xxx_6095_family(chip) || mv88e6xxx_6185_family(chip)) {
@@ -2597,7 +2603,7 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)

if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||

- mv88e6xxx_6320_family(chip)) {
+ mv88e6xxx_6320_family(chip) || mv88e6xxx_6341_family(chip)) {
/* Port ATU control: disable limiting the number of
* address database entries that this port is allowed
* to use.
@@ -3566,6 +3572,34 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
.reset = mv88e6352_g1_reset,
};

+static const struct mv88e6xxx_ops mv88e6341_ops = {
+ /* MV88E6XXX_FAMILY_6341 */
+ .get_eeprom = mv88e6xxx_g2_get_eeprom8,
+ .set_eeprom = mv88e6xxx_g2_set_eeprom8,
+ .set_switch_mac = mv88e6xxx_g2_set_switch_mac,
+ .phy_read = mv88e6xxx_g2_smi_phy_read,
+ .phy_write = mv88e6xxx_g2_smi_phy_write,
+ .port_set_link = mv88e6xxx_port_set_link,
+ .port_set_duplex = mv88e6xxx_port_set_duplex,
+ .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
+ .port_set_speed = mv88e6390_port_set_speed,
+ .port_tag_remap = mv88e6095_port_tag_remap,
+ .port_set_frame_mode = mv88e6351_port_set_frame_mode,
+ .port_set_egress_unknowns = mv88e6351_port_set_egress_unknowns,
+ .port_set_ether_type = mv88e6351_port_set_ether_type,
+ .port_jumbo_config = mv88e6165_port_jumbo_config,
+ .port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
+ .port_pause_config = mv88e6097_port_pause_config,
+ .stats_snapshot = mv88e6390_g1_stats_snapshot,
+ .stats_get_sset_count = mv88e6320_stats_get_sset_count,
+ .stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
+ .g1_set_cpu_port = mv88e6390_g1_set_cpu_port,
+ .g1_set_egress_port = mv88e6390_g1_set_egress_port,
+ .mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
+ .reset = mv88e6352_g1_reset,
+};
+
static const struct mv88e6xxx_ops mv88e6390_ops = {
/* MV88E6XXX_FAMILY_6390 */
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
@@ -3953,6 +3987,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.ops = &mv88e6321_ops,
},

+ [MV88E6341] = {
+ .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
+ .family = MV88E6XXX_FAMILY_6341,
+ .name = "Marvell 88E6341",
+ .num_databases = 4096,
+ .num_ports = 6,
+ .port_base_addr = 0x10,
+ .global1_addr = 0x1b,
+ .age_time_coeff = 15000,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
+ .flags = MV88E6XXX_FLAGS_FAMILY_6341,
+ .ops = &mv88e6341_ops,
+ },
+
[MV88E6350] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
.family = MV88E6XXX_FAMILY_6351,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index ce8b43b14e96..e0527db0ef6e 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -100,6 +100,7 @@
#define PORT_SWITCH_ID_PROD_NUM_6240 0x240
#define PORT_SWITCH_ID_PROD_NUM_6290 0x290
#define PORT_SWITCH_ID_PROD_NUM_6321 0x310
+#define PORT_SWITCH_ID_PROD_NUM_6341 0x341
#define PORT_SWITCH_ID_PROD_NUM_6352 0x352
#define PORT_SWITCH_ID_PROD_NUM_6350 0x371
#define PORT_SWITCH_ID_PROD_NUM_6351 0x375
@@ -382,7 +383,7 @@
#define GLOBAL2_EEPROM_CMD_WRITE_EN BIT(10)
#define GLOBAL2_EEPROM_CMD_ADDR_MASK 0xff
#define GLOBAL2_EEPROM_DATA 0x15
-#define GLOBAL2_EEPROM_ADDR 0x15 /* 6390 */
+#define GLOBAL2_EEPROM_ADDR 0x15 /* 6390, 6341 */
#define GLOBAL2_PTP_AVB_OP 0x16
#define GLOBAL2_PTP_AVB_DATA 0x17
#define GLOBAL2_SMI_PHY_CMD 0x18
@@ -433,6 +434,7 @@ enum mv88e6xxx_model {
MV88E6290,
MV88E6320,
MV88E6321,
+ MV88E6341,
MV88E6350,
MV88E6351,
MV88E6352,
@@ -448,6 +450,7 @@ enum mv88e6xxx_family {
MV88E6XXX_FAMILY_6165, /* 6123 6161 6165 */
MV88E6XXX_FAMILY_6185, /* 6108 6121 6122 6131 6152 6155 6182 6185 */
MV88E6XXX_FAMILY_6320, /* 6320 6321 */
+ MV88E6XXX_FAMILY_6341, /* 6141 6341 */
MV88E6XXX_FAMILY_6351, /* 6171 6175 6350 6351 */
MV88E6XXX_FAMILY_6352, /* 6172 6176 6240 6352 */
MV88E6XXX_FAMILY_6390, /* 6190 6190X 6191 6290 6390 6390X */
@@ -601,6 +604,20 @@ enum mv88e6xxx_cap {
MV88E6XXX_FLAGS_MULTI_CHIP | \
MV88E6XXX_FLAGS_PVT)

+#define MV88E6XXX_FLAGS_FAMILY_6341 \
+ (MV88E6XXX_FLAG_EEE | \
+ MV88E6XXX_FLAG_G1_ATU_FID | \
+ MV88E6XXX_FLAG_G1_VTU_FID | \
+ MV88E6XXX_FLAG_GLOBAL2 | \
+ MV88E6XXX_FLAG_G2_INT | \
+ MV88E6XXX_FLAG_G2_POT | \
+ MV88E6XXX_FLAG_STU | \
+ MV88E6XXX_FLAG_VTU | \
+ MV88E6XXX_FLAGS_IRL | \
+ MV88E6XXX_FLAGS_MULTI_CHIP | \
+ MV88E6XXX_FLAGS_PVT | \
+ MV88E6XXX_FLAGS_SERDES)
+
#define MV88E6XXX_FLAGS_FAMILY_6351 \
(MV88E6XXX_FLAG_G1_ATU_FID | \
MV88E6XXX_FLAG_G1_VTU_FID | \
--
git-series 0.9.1

[Gregory CLEMENT]

The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with
four integrated 10/100/1000Mbps Ethernet transceivers and one high speed
SerDes interfaces.

It belongs to the Topaz family and unlike the 88E6341 it does not have
a TCAM.

Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>
---

drivers/net/dsa/mv88e6xxx/chip.c | 42 ++++++++++++++++++++++++++++-
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 2 +-
2 files changed, 44 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 00db33ca1696..cdb8c7c4accd 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3572,6 +3572,34 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
.reset = mv88e6352_g1_reset,
};

+static const struct mv88e6xxx_ops mv88e6141_ops = {

static const struct mv88e6xxx_ops mv88e6341_ops = {
/* MV88E6XXX_FAMILY_6341 */
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
@@ -3987,6 +4015,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.ops = &mv88e6321_ops,
},

+ [MV88E6141] = {
+ .prod_num = PORT_SWITCH_ID_PROD_NUM_6141,

+ .family = MV88E6XXX_FAMILY_6341,
+ .name = "Marvell 88E6341",
+ .num_databases = 4096,
+ .num_ports = 6,
+ .port_base_addr = 0x10,
+ .global1_addr = 0x1b,
+ .age_time_coeff = 15000,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
+ .flags = MV88E6XXX_FLAGS_FAMILY_6341,

+ .ops = &mv88e6141_ops,
+ },
+
[MV88E6341] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
.family = MV88E6XXX_FAMILY_6341,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index e0527db0ef6e..94d1e98d4e2c 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -87,6 +87,7 @@
#define PORT_SWITCH_ID_PROD_NUM_6131 0x106
#define PORT_SWITCH_ID_PROD_NUM_6320 0x115
#define PORT_SWITCH_ID_PROD_NUM_6123 0x121
+#define PORT_SWITCH_ID_PROD_NUM_6141 0x340
#define PORT_SWITCH_ID_PROD_NUM_6161 0x161
#define PORT_SWITCH_ID_PROD_NUM_6165 0x165
#define PORT_SWITCH_ID_PROD_NUM_6171 0x171
@@ -420,6 +421,7 @@ enum mv88e6xxx_model {
MV88E6097,
MV88E6123,
MV88E6131,
+ MV88E6141,
MV88E6161,
MV88E6165,
MV88E6171,
--
git-series 0.9.1

[Gregory CLEMENT]

The PHY with the ID 0x1410C00 can be found embedded in the Marvell Topaz
switches (88E6141/88E6341). It is compatible with the 88E1510 (at least for
the temperature information), so add support for it, using the 88E1510
specific functions.

Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>
---

drivers/net/phy/marvell.c | 21 +++++++++++++++++++++
include/linux/marvell_phy.h | 1 +
2 files changed, 22 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 64229976ace1..8b9338a746b8 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2141,6 +2141,26 @@ static struct phy_driver marvell_drivers[] = {
.get_strings = marvell_get_strings,
.get_stats = marvell_get_stats,
},
+ {
+ .phy_id = MARVELL_PHY_ID_88E6141,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
+ .name = "Marvell 88E6141",
+ .probe = m88e1510_probe,
+ .remove = &marvell_remove,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = &marvell_config_init,
+ .config_aneg = &m88e1510_config_aneg,
+ .read_status = &marvell_read_status,
+ .ack_interrupt = &marvell_ack_interrupt,
+ .config_intr = &marvell_config_intr,
+ .did_interrupt = &m88e1121_did_interrupt,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
+ .get_sset_count = marvell_get_sset_count,
+ .get_strings = marvell_get_strings,
+ .get_stats = marvell_get_stats,
+ },
};

module_phy_driver(marvell_drivers);
@@ -2159,6 +2179,7 @@ static struct mdio_device_id __maybe_unused marvell_tbl[] = {
{ MARVELL_PHY_ID_88E1510, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E1540, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E3016, MARVELL_PHY_ID_MASK },
+ { MARVELL_PHY_ID_88E6141, MARVELL_PHY_ID_MASK },
{ }
};

diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index a57f0dfb6db7..6f33b73f2044 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -5,6 +5,7 @@
#define MARVELL_PHY_ID_MASK 0xfffffff0

/* Known PHY IDs */
+#define MARVELL_PHY_ID_88E6141 0x01410c00
#define MARVELL_PHY_ID_88E1101 0x01410c60
#define MARVELL_PHY_ID_88E1112 0x01410c90
#define MARVELL_PHY_ID_88E1111 0x01410cc0
--
git-series 0.9.1

[Andrew Lunn]

On Tue, Jan 24, 2017 at 09:10:26PM +0100, Gregory CLEMENT wrote:
> The PHY with the ID 0x1410C00

:-(

I don't have a better reference, but
Linux/Documentation/devicetree/bindings/net/phy.txt says:

22 If the phy's identifier is known then the list may contain an entry
23 of the form: "ethernet-phy-idAAAA.BBBB" where
24 AAAA - The value of the 16 bit Phy Identifier 1 register as
25 4 hex digits. This is the chip vendor OUI bits 3:18
26 BBBB - The value of the 16 bit Phy Identifier 2 register as
27 4 hex digits. This is the chip vendor OUI bits 19:24,
28 followed by 10 bits of a vendor specific ID.

So the lower 10 bits of 0x1410C00 are 0. So we know it is a Marvell
PHY from the OUI, but the vendor specific bits are all 0.

Please take a look at:

https://marc.info/?l=linux-netdev&m=148495522620757&w=1

and

https://marc.info/?l=linux-netdev&m=148495510320714&w=1

Maybe i should submit these two independently, so you can extend it
for the 88E6341 family.

Andrew

[Gregory CLEMENT]

Hi,

On mar., janv. 24 2017, Gregory CLEMENT <gregory...@free-electrons.com> wrote:

> From: Romain Perier <romain...@free-electrons.com>
>
> Some Marvell ethernet switches have internal ethernet transceivers with
> hardcoded phy addresses. These addresses can be greater than the number
> of ports or its value might be different than the associated port number.
> This is for example the case for MV88E6341 that has 6 ports and internal
> Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.
>
> This commits fixes the issue by removing the condition in MDIO callbacks.
>
> Signed-off-by: Romain Perier <romain...@free-electrons.com>
> Reviewed-by: Andrew Lunn <and...@lunn.ch>

This flag is missing:
Reviewed-by: Vivien Didelot <vivien....@savoirfairelinux.com>

Actually I added during an interactive rebase, but I had to abort it
and it was lost.

Gregory

[Gregory CLEMENT]

Hi Andrew,

On mar., janv. 24 2017, Andrew Lunn <and...@lunn.ch> wrote:

> On Tue, Jan 24, 2017 at 09:10:26PM +0100, Gregory CLEMENT wrote:
>> The PHY with the ID 0x1410C00
>
> :-(
>
> I don't have a better reference, but
> Linux/Documentation/devicetree/bindings/net/phy.txt says:
>
> 22 If the phy's identifier is known then the list may contain an entry
> 23 of the form: "ethernet-phy-idAAAA.BBBB" where
> 24 AAAA - The value of the 16 bit Phy Identifier 1 register as
> 25 4 hex digits. This is the chip vendor OUI bits 3:18
> 26 BBBB - The value of the 16 bit Phy Identifier 2 register as
> 27 4 hex digits. This is the chip vendor OUI bits 19:24,
> 28 followed by 10 bits of a vendor specific ID.
>
> So the lower 10 bits of 0x1410C00 are 0. So we know it is a Marvell
> PHY from the OUI, but the vendor specific bits are all 0.

In your previous email you mention a value of 0x01410000, so when I saw
the "C00" at the end I was happy and I didn't look for further.

>
> Please take a look at:
>
> https://marc.info/?l=linux-netdev&m=148495522620757&w=1
>
> and
>
> https://marc.info/?l=linux-netdev&m=148495510320714&w=1
>
> Maybe i should submit these two independently, so you can extend it
> for the 88E6341 family.

Please do it :)

The feedback from Florian and Vivian was good about it so I see no
reason to not apply them.

Add me in CC so I will now when to rebase my series.

Thanks,

Gregory

>
> Andrew

[Andrew Lunn]

> + [MV88E6341] = {
> + .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
> + .family = MV88E6XXX_FAMILY_6341,
> + .name = "Marvell 88E6341",
> + .num_databases = 4096,
> + .num_ports = 6,
> + .port_base_addr = 0x10,
> + .global1_addr = 0x1b,
> + .age_time_coeff = 15000,

Hi Gregory

Please could you check this timer in the datasheet. There is currently
a bug in the mv88e6390 support code. I also set it to 15s. But in fact
it is 3.75 seconds. The 6341 might also use 3.75 seconds.

Thanks
Andrew

[Gregory CLEMENT]

Hi Andrew,

When I read your series I also thought about it and indeed it is 3.75
seconds. I will fix it.

Thanks,

Gregory


>
> Thanks

[Jon Pannell]

Adding Bob Bernstein

Jon Pannell


-----Original Message-----
From: Gregory CLEMENT [mailto:gregory...@free-electrons.com]
Sent: Tuesday, January 24, 2017 11:56 PM
To: Andrew Lunn <and...@lunn.ch>
Cc: Vivien Didelot <vivien....@savoirfairelinux.com>; Florian Fainelli <f.fai...@gmail.com>; net...@vger.kernel.org; linux-...@vger.kernel.org; David S. Miller <da...@davemloft.net>; Jason Cooper <ja...@lakedaemon.net>; Sebastian Hesselbarth <sebastian....@gmail.com>; Thomas Petazzoni <thomas.p...@free-electrons.com>; linux-ar...@lists.infradead.org; Nadav Haklai <nad...@marvell.com>; Wilson Ding <din...@marvell.com>; Kostya Porotchkin <kos...@marvell.com>; Joe Zhou <shj...@marvell.com>; Jon Pannell <jpan...@marvell.com>

[Gregory CLEMENT]

The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with
four integrated 10/100/1000Mbps Ethernet transceivers and one high speed
SerDes interfaces.

It belongs to the Topaz family and unlike the 88E6341 it does not have
a TCAM.

Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>
---

drivers/net/dsa/mv88e6xxx/chip.c | 42 ++++++++++++++++++++++++++++-
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 2 +-
2 files changed, 44 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 6a583527917d..bf385377a461 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3656,6 +3656,34 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {

@@ -4071,6 +4099,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {

.ops = &mv88e6321_ops,
},

+ [MV88E6141] = {
+ .prod_num = PORT_SWITCH_ID_PROD_NUM_6141,

+ .family = MV88E6XXX_FAMILY_6341,
+ .name = "Marvell 88E6341",
+ .num_databases = 4096,
+ .num_ports = 6,
+ .port_base_addr = 0x10,
+ .global1_addr = 0x1b,

+ .age_time_coeff = 3750,

+ .tag_protocol = DSA_TAG_PROTO_EDSA,
+ .flags = MV88E6XXX_FLAGS_FAMILY_6341,
+ .ops = &mv88e6141_ops,
+ },
+
[MV88E6341] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
.family = MV88E6XXX_FAMILY_6341,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h

index 76837d2022bb..9c5c0472b211 100644

--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -87,6 +87,7 @@
#define PORT_SWITCH_ID_PROD_NUM_6131 0x106
#define PORT_SWITCH_ID_PROD_NUM_6320 0x115
#define PORT_SWITCH_ID_PROD_NUM_6123 0x121
+#define PORT_SWITCH_ID_PROD_NUM_6141 0x340
#define PORT_SWITCH_ID_PROD_NUM_6161 0x161
#define PORT_SWITCH_ID_PROD_NUM_6165 0x165
#define PORT_SWITCH_ID_PROD_NUM_6171 0x171

@@ -421,6 +422,7 @@ enum mv88e6xxx_model {

[Gregory CLEMENT]

Hi,

This set of patches adds support for the Marvell Ethernet Topaz switch
family (88E6141/88E6341) which is found on the ESPRESSObin. With this
series the network is usable on this board.

As usual, I rebased the series on the very last net-next/master. In
this series there is no temperature support which need some patches
form Andrew Lunn.

As soon as Andrew Lunn will post the needed patch I will send a patch
to enable the temperature support.

Thanks,

Gregory

Changelog:

v6 -> v7:
- rebased on net-next/master (5b8784aaf29b)
- Fixed the wrong age time coeff from 15s to 3.75s.
- Remove support for temperature sensor

v5 -> v6:
- rebased on net-next/master (d140199af510)
- Fix the redundant check on mv88e6xxx_6341_family (reported by Julia
Lawall)
- Add support for the 88E6141
- Move support for temperature sensor in the phy part

Gregory CLEMENT (2):

net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341

net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141

Romain Perier (1):
net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports

drivers/net/dsa/mv88e6xxx/chip.c | 102 ++++++++++++++++++++++++---
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 21 +++++-

2 files changed, 113 insertions(+), 10 deletions(-)

base-commit: 334c367fd5cea7a9493c3026f7e6195ebab3d7b9
--
git-series 0.9.1

[Gregory CLEMENT]

From: Romain Perier <romain...@free-electrons.com>

Some Marvell ethernet switches have internal ethernet transceivers with
hardcoded phy addresses. These addresses can be greater than the number
of ports or its value might be different than the associated port number.
This is for example the case for MV88E6341 that has 6 ports and internal
Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.

This commits fixes the issue by removing the condition in MDIO callbacks.

Signed-off-by: Romain Perier <romain...@free-electrons.com>
Reviewed-by: Andrew Lunn <and...@lunn.ch>

Reviewed-by: Vivien Didelot <vivien....@savoirfairelinux.com>

Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>
---

drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
1 file changed, 6 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 84cba32443de..1344dad21f46 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2917,9 +2917,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)

u16 val;
int err;

- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-

if (!chip->info->ops->phy_read)
return -EOPNOTSUPP;

@@ -2936,9 +2933,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
struct mv88e6xxx_chip *chip = mdio_bus->chip;

int err;

- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-

if (!chip->info->ops->phy_write)
return -EOPNOTSUPP;

--
git-series 0.9.1

[Gregory CLEMENT]

The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with
four integrated 10/100/1000Mbps Ethernet transceivers and one high speed

SerDes interfaces. It is partially compatible with switches of family
88E6352 and switches of family 88E6390.

This commit adds an initial support for this switch by describing its
capabilities to the driver and introducing a new family.

Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>
---

drivers/net/dsa/mv88e6xxx/chip.c | 54 ++++++++++++++++++++++++++--
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 19 +++++++++-

2 files changed, 69 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 1344dad21f46..6a583527917d 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -702,6 +702,11 @@ static bool mv88e6xxx_6320_family(struct mv88e6xxx_chip *chip)

return chip->info->family == MV88E6XXX_FAMILY_6320;
}

+static bool mv88e6xxx_6341_family(struct mv88e6xxx_chip *chip)
+{
+ return chip->info->family == MV88E6XXX_FAMILY_6341;
+}
+
static bool mv88e6xxx_6351_family(struct mv88e6xxx_chip *chip)
{
return chip->info->family == MV88E6XXX_FAMILY_6351;

@@ -1726,7 +1731,8 @@ static int _mv88e6xxx_vtu_new(struct mv88e6xxx_chip *chip, u16 vid,

: GLOBAL_VTU_DATA_MEMBER_TAG_NON_MEMBER;

if (mv88e6xxx_6097_family(chip) || mv88e6xxx_6165_family(chip) ||
- mv88e6xxx_6351_family(chip) || mv88e6xxx_6352_family(chip)) {
+ mv88e6xxx_6351_family(chip) || mv88e6xxx_6352_family(chip) ||
+ mv88e6xxx_6341_family(chip)) {
struct mv88e6xxx_vtu_entry vstp;

/* Adding a VTU entry requires a valid STU entry. As VSTP is not

@@ -2577,7 +2583,7 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)

if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
mv88e6xxx_6095_family(chip) || mv88e6xxx_6320_family(chip) ||
- mv88e6xxx_6185_family(chip))
+ mv88e6xxx_6185_family(chip) || mv88e6xxx_6341_family(chip))
reg = PORT_CONTROL_2_MAP_DA;

if (mv88e6xxx_6095_family(chip) || mv88e6xxx_6185_family(chip)) {

@@ -2631,7 +2637,7 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)

if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
- mv88e6xxx_6320_family(chip)) {
+ mv88e6xxx_6320_family(chip) || mv88e6xxx_6341_family(chip)) {
/* Port ATU control: disable limiting the number of
* address database entries that this port is allowed
* to use.

@@ -3650,6 +3656,34 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
.reset = mv88e6352_g1_reset,
};

+static const struct mv88e6xxx_ops mv88e6341_ops = {

static const struct mv88e6xxx_ops mv88e6390_ops = {
/* MV88E6XXX_FAMILY_6390 */
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
@@ -4037,6 +4071,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.ops = &mv88e6321_ops,
},

+ [MV88E6341] = {
+ .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,

+ .family = MV88E6XXX_FAMILY_6341,
+ .name = "Marvell 88E6341",
+ .num_databases = 4096,
+ .num_ports = 6,
+ .port_base_addr = 0x10,
+ .global1_addr = 0x1b,
+ .age_time_coeff = 3750,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
+ .flags = MV88E6XXX_FLAGS_FAMILY_6341,

+ .ops = &mv88e6341_ops,
+ },
+
[MV88E6350] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
.family = MV88E6XXX_FAMILY_6351,

diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index e126ed00937b..76837d2022bb 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h

@@ -100,6 +100,7 @@
#define PORT_SWITCH_ID_PROD_NUM_6240 0x240
#define PORT_SWITCH_ID_PROD_NUM_6290 0x290
#define PORT_SWITCH_ID_PROD_NUM_6321 0x310
+#define PORT_SWITCH_ID_PROD_NUM_6341 0x341
#define PORT_SWITCH_ID_PROD_NUM_6352 0x352
#define PORT_SWITCH_ID_PROD_NUM_6350 0x371
#define PORT_SWITCH_ID_PROD_NUM_6351 0x375
@@ -382,7 +383,7 @@
#define GLOBAL2_EEPROM_CMD_WRITE_EN BIT(10)
#define GLOBAL2_EEPROM_CMD_ADDR_MASK 0xff
#define GLOBAL2_EEPROM_DATA 0x15
-#define GLOBAL2_EEPROM_ADDR 0x15 /* 6390 */
+#define GLOBAL2_EEPROM_ADDR 0x15 /* 6390, 6341 */
#define GLOBAL2_PTP_AVB_OP 0x16
#define GLOBAL2_PTP_AVB_DATA 0x17
#define GLOBAL2_SMI_PHY_CMD 0x18

@@ -434,6 +435,7 @@ enum mv88e6xxx_model {

MV88E6290,
MV88E6320,
MV88E6321,
+ MV88E6341,
MV88E6350,
MV88E6351,
MV88E6352,

@@ -449,6 +451,7 @@ enum mv88e6xxx_family {

MV88E6XXX_FAMILY_6165, /* 6123 6161 6165 */
MV88E6XXX_FAMILY_6185, /* 6108 6121 6122 6131 6152 6155 6182 6185 */
MV88E6XXX_FAMILY_6320, /* 6320 6321 */
+ MV88E6XXX_FAMILY_6341, /* 6141 6341 */
MV88E6XXX_FAMILY_6351, /* 6171 6175 6350 6351 */
MV88E6XXX_FAMILY_6352, /* 6172 6176 6240 6352 */
MV88E6XXX_FAMILY_6390, /* 6190 6190X 6191 6290 6390 6390X */

@@ -602,6 +605,20 @@ enum mv88e6xxx_cap {

[Vivien Didelot]

Hi Gregory,

Gregory CLEMENT <gregory...@free-electrons.com> writes:

> The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with
> four integrated 10/100/1000Mbps Ethernet transceivers and one high speed
> SerDes interfaces.

I'm sure you meant 88E6141 here ;-)

> It belongs to the Topaz family and unlike the 88E6341 it does not have
> a TCAM.
>
> Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>

Reviewed-by: Vivien Didelot <vivien....@savoirfairelinux.com>

Thanks,

Vivien

[Vivien Didelot]

Hi Gregory,

Gregory CLEMENT <gregory...@free-electrons.com> writes:

> The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with
> four integrated 10/100/1000Mbps Ethernet transceivers and one high speed
> SerDes interfaces. It is partially compatible with switches of family
> 88E6352 and switches of family 88E6390.
>
> This commit adds an initial support for this switch by describing its
> capabilities to the driver and introducing a new family.
>
> Signed-off-by: Gregory CLEMENT <gregory...@free-electrons.com>

[David Miller]

From: Gregory CLEMENT <gregory...@free-electrons.com>
Date: Mon, 30 Jan 2017 20:29:32 +0100

> This set of patches adds support for the Marvell Ethernet Topaz switch
> family (88E6141/88E6341) which is found on the ESPRESSObin. With this
> series the network is usable on this board.
>
> As usual, I rebased the series on the very last net-next/master. In
> this series there is no temperature support which need some patches
> form Andrew Lunn.
>
> As soon as Andrew Lunn will post the needed patch I will send a patch
> to enable the temperature support.

Series applied, thank you.