Marvell 88E609x switch?

Marvell 88E609x switch?

[Gary Thomas]

Is there support for this device anywhere?  In particular,
the M88E6095 switch.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Tue, 24 Feb 2009, Gary Thomas wrote:

> Is there support for this device anywhere?  In particular,
> the M88E6095 switch.

I have written a driver for the M88E6095F and M88E6097F switch, but only 
for an embedded 2.4.20 kernel device.  I have written it from scratch, so 
its not covered by Marvell license.  Although lately different marvell DSA 
support was added to kernel 2.6.

Whats you usage?

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Tue, Feb 24, 2009 at 06:16:54PM -0700, Gary Thomas wrote:

> Is there support for this device anywhere?  In particular,
> the M88E6095 switch.

Not at the moment, but it should be easy enough to add.  If your
board already runs on 2.6.28+, I can whip up some patches for you
to try from the docs I have for that part.

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Tue, Feb 24, 2009 at 06:16:54PM -0700, Gary Thomas wrote:
> 
>> Is there support for this device anywhere?  In particular,
>> the M88E6095 switch.
> 
> Not at the moment, but it should be easy enough to add.  If your
> board already runs on 2.6.28+, I can whip up some patches for you
> to try from the docs I have for that part.

That would be much appreciated, thanks.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Wed, Feb 25, 2009 at 02:30:31PM -0700, Gary Thomas wrote:

> >> Is there support for this device anywhere?  In particular,
> >> the M88E6095 switch.
> > 
> > Not at the moment, but it should be easy enough to add.  If your
> > board already runs on 2.6.28+, I can whip up some patches for you
> > to try from the docs I have for that part.
> 
> That would be much appreciated, thanks.

I noticed that the 6095/6095F are quite similar to the 6131 as far
as the register set goes.  So something along these lines (hacky
patch, breaks 6131, not for mainline) might just work to detect
single 6095s (cascading DSA chips is something that needs more work,
let's get the single-chip case working first).

The other thing you'll need to do is create dsa platform devices
for your switch chips, a la how it's done in arch/arm/mach-orion5x/
or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
device * for your network device, a struct device * for your mii bus,
the switch MII address on the MII bus, and names of the individual
ports (where you'll specify "cpu" for the port on the switch chip that
the CPU is connected to).

Let me know if this works.



diff --git a/net/dsa/mv88e6131.c b/net/dsa/mv88e6131.c
index 374d46a..d530e63 100644
--- a/net/dsa/mv88e6131.c
+++ b/net/dsa/mv88e6131.c
@@ -21,6 +21,8 @@ static char *mv88e6131_probe(struct mii_bus *bus, int sw_addr)
 	ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
 	if (ret >= 0) {
 		ret &= 0xfff0;
+		if (ret == 0x0950)
+			return "Marvell 88E6095/88E6095F";
 		if (ret == 0x1060)
 			return "Marvell 88E6131";
 	}
@@ -36,7 +38,7 @@ static int mv88e6131_switch_reset(struct dsa_switch *ds)
 	/*
 	 * Set all ports to the disabled state.
 	 */
-	for (i = 0; i < 8; i++) {
+	for (i = 0; i < 11; i++) {
 		ret = REG_READ(REG_PORT(i), 0x04);
 		REG_WRITE(REG_PORT(i), 0x04, ret & 0xfffc);
 	}
@@ -268,7 +270,7 @@ static int mv88e6131_setup(struct dsa_switch *ds)
 	if (ret < 0)
 		return ret;
 
-	for (i = 0; i < 6; i++) {
+	for (i = 0; i < 11; i++) {
 		ret = mv88e6131_setup_port(ds, i);
 		if (ret < 0)
 			return ret;
@@ -279,7 +281,7 @@ static int mv88e6131_setup(struct dsa_switch *ds)
 
 static int mv88e6131_port_to_phy_addr(int port)
 {
-	if (port >= 0 && port != 3 && port <= 7)
+	if (port >= 0 && port <= 11)
 		return port;
 	return -1;
 }

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Wed, Feb 25, 2009 at 02:30:31PM -0700, Gary Thomas wrote:
> 
>>>> Is there support for this device anywhere?  In particular,
>>>> the M88E6095 switch.
>>> Not at the moment, but it should be easy enough to add.  If your
>>> board already runs on 2.6.28+, I can whip up some patches for you
>>> to try from the docs I have for that part.
>> That would be much appreciated, thanks.
> 
> I noticed that the 6095/6095F are quite similar to the 6131 as far
> as the register set goes.  So something along these lines (hacky
> patch, breaks 6131, not for mainline) might just work to detect
> single 6095s (cascading DSA chips is something that needs more work,
> let's get the single-chip case working first).
> 
> The other thing you'll need to do is create dsa platform devices
> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
> device * for your network device, a struct device * for your mii bus,
> the switch MII address on the MII bus, and names of the individual
> ports (where you'll specify "cpu" for the port on the switch chip that
> the CPU is connected to).
> 
> Let me know if this works.
> 

Thanks, I'll give it a try.  It will take a little effort
to get setup as I have to work within the open firmware
structure (that's how all the various components are
specified).

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Thu, Feb 26, 2009 at 08:47:29AM -0700, Gary Thomas wrote:

> >>>> Is there support for this device anywhere?  In particular,
> >>>> the M88E6095 switch.
> >>> Not at the moment, but it should be easy enough to add.  If your
> >>> board already runs on 2.6.28+, I can whip up some patches for you
> >>> to try from the docs I have for that part.
> >> That would be much appreciated, thanks.
> > 
> > I noticed that the 6095/6095F are quite similar to the 6131 as far
> > as the register set goes.  So something along these lines (hacky
> > patch, breaks 6131, not for mainline) might just work to detect
> > single 6095s (cascading DSA chips is something that needs more work,
> > let's get the single-chip case working first).
> > 
> > The other thing you'll need to do is create dsa platform devices
> > for your switch chips, a la how it's done in arch/arm/mach-orion5x/
> > or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
> > device * for your network device, a struct device * for your mii bus,
> > the switch MII address on the MII bus, and names of the individual
> > ports (where you'll specify "cpu" for the port on the switch chip that
> > the CPU is connected to).
> > 
> > Let me know if this works.
> 
> Thanks, I'll give it a try.  It will take a little effort
> to get setup as I have to work within the open firmware
> structure (that's how all the various components are
> specified).

Right, we don't have OF bindings yet.  I guess this would make sense
to do generically at some point, since there are quite a few PPC
platforms with DSA switch chips.

Re: Marvell 88E609x switch?

[Gary Thomas]

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

Lennert Buytenhek wrote:
> On Thu, Feb 26, 2009 at 08:47:29AM -0700, Gary Thomas wrote:
> 
>>>>>> Is there support for this device anywhere?  In particular,
>>>>>> the M88E6095 switch.
>>>>> Not at the moment, but it should be easy enough to add.  If your
>>>>> board already runs on 2.6.28+, I can whip up some patches for you
>>>>> to try from the docs I have for that part.
>>>> That would be much appreciated, thanks.
>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
>>> as the register set goes.  So something along these lines (hacky
>>> patch, breaks 6131, not for mainline) might just work to detect
>>> single 6095s (cascading DSA chips is something that needs more work,
>>> let's get the single-chip case working first).
>>>
>>> The other thing you'll need to do is create dsa platform devices
>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
>>> device * for your network device, a struct device * for your mii bus,
>>> the switch MII address on the MII bus, and names of the individual
>>> ports (where you'll specify "cpu" for the port on the switch chip that
>>> the CPU is connected to).
>>>
>>> Let me know if this works.
>> Thanks, I'll give it a try.  It will take a little effort
>> to get setup as I have to work within the open firmware
>> structure (that's how all the various components are
>> specified).
> 
> Right, we don't have OF bindings yet.  I guess this would make sense
> to do generically at some point, since there are quite a few PPC
> platforms with DSA switch chips.

Here's what I tried - (patch attached) - a trulyhorrible hack,
but I've not figured out how to get the correct device pointers
from the OF world yet.  The boot log shows that it's trying, but
I don't see the DSA layer (M88E690x driver) doing the MII indirection
that's needed for this device.

I'm probably not starting it up correctly, but I think I followed
the examples you cited.  Any ideas?

Thanks

=============== boot log ===============================
Set gianfar_mdio = cf82fc08, mii_bus = cf9db400
gfar_mdio_read(cf9db400, 32, 2) = 0
gfar_mdio_read(cf9db400, 32, 3) = 0
gfar_mdio_read(cf9db400, 31, 2) = ffff
gfar_mdio_read(cf9db400, 31, 3) = ffff
gfar_mdio_read(cf9db400, 0, 2) = ffff
gfar_mdio_read(cf9db400, 0, 3) = ffff
gfar_mdio_read(cf9db400, 1, 2) = ffff
gfar_mdio_read(cf9db400, 1, 3) = ffff
gfar_mdio_read(cf9db400, 2, 2) = ffff
gfar_mdio_read(cf9db400, 2, 3) = ffff
gfar_mdio_read(cf9db400, 3, 2) = ffff
gfar_mdio_read(cf9db400, 3, 3) = ffff
gfar_mdio_read(cf9db400, 4, 2) = ffff
gfar_mdio_read(cf9db400, 4, 3) = ffff
gfar_mdio_read(cf9db400, 5, 2) = ffff
gfar_mdio_read(cf9db400, 5, 3) = ffff
gfar_mdio_read(cf9db400, 6, 2) = ffff
gfar_mdio_read(cf9db400, 6, 3) = ffff
gfar_mdio_read(cf9db400, 7, 2) = ffff
gfar_mdio_read(cf9db400, 7, 3) = ffff
gfar_mdio_read(cf9db400, 8, 2) = ffff
gfar_mdio_read(cf9db400, 8, 3) = ffff
gfar_mdio_read(cf9db400, 9, 2) = ffff
gfar_mdio_read(cf9db400, 9, 3) = ffff
gfar_mdio_read(cf9db400, 10, 2) = ffff
gfar_mdio_read(cf9db400, 10, 3) = ffff
gfar_mdio_read(cf9db400, 11, 2) = ffff
gfar_mdio_read(cf9db400, 11, 3) = ffff
gfar_mdio_read(cf9db400, 12, 2) = ffff
gfar_mdio_read(cf9db400, 12, 3) = ffff
gfar_mdio_read(cf9db400, 13, 2) = ffff
gfar_mdio_read(cf9db400, 13, 3) = ffff
gfar_mdio_read(cf9db400, 14, 2) = ffff
gfar_mdio_read(cf9db400, 14, 3) = ffff
gfar_mdio_read(cf9db400, 15, 2) = ffff
gfar_mdio_read(cf9db400, 15, 3) = ffff
gfar_mdio_read(cf9db400, 16, 2) = ffff
gfar_mdio_read(cf9db400, 16, 3) = ffff
gfar_mdio_read(cf9db400, 17, 2) = ffff
gfar_mdio_read(cf9db400, 17, 3) = ffff
gfar_mdio_read(cf9db400, 18, 2) = ffff
gfar_mdio_read(cf9db400, 18, 3) = ffff
gfar_mdio_read(cf9db400, 19, 2) = ffff
gfar_mdio_read(cf9db400, 19, 3) = ffff
gfar_mdio_read(cf9db400, 20, 2) = ffff
gfar_mdio_read(cf9db400, 20, 3) = ffff
gfar_mdio_read(cf9db400, 21, 2) = ffff
gfar_mdio_read(cf9db400, 21, 3) = ffff
gfar_mdio_read(cf9db400, 22, 2) = ffff
gfar_mdio_read(cf9db400, 22, 3) = ffff
gfar_mdio_read(cf9db400, 23, 2) = ffff
gfar_mdio_read(cf9db400, 23, 3) = ffff
gfar_mdio_read(cf9db400, 24, 2) = ffff
gfar_mdio_read(cf9db400, 24, 3) = ffff
gfar_mdio_read(cf9db400, 25, 2) = ffff
gfar_mdio_read(cf9db400, 25, 3) = ffff
gfar_mdio_read(cf9db400, 26, 2) = ffff
gfar_mdio_read(cf9db400, 26, 3) = ffff
gfar_mdio_read(cf9db400, 27, 2) = ffff
gfar_mdio_read(cf9db400, 27, 3) = ffff
gfar_mdio_read(cf9db400, 28, 2) = ffff
gfar_mdio_read(cf9db400, 28, 3) = ffff
gfar_mdio_read(cf9db400, 29, 2) = ffff
gfar_mdio_read(cf9db400, 29, 3) = ffff
gfar_mdio_read(cf9db400, 30, 2) = ffff
gfar_mdio_read(cf9db400, 30, 3) = ffff
gfar_mdio_read(cf9db400, 31, 2) = 0
gfar_mdio_read(cf9db400, 31, 3) = 0
Gianfar MII Bus: probed
Set gianfar_eth0 = cf82b008
eth0: Gianfar Ethernet Controller Version 1.2, 00:1d:11:81:00:00
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2, 00:1d:11:81:80:00
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
   ... snipNET: Registered protocol family 17
Distributed Switch Architecture driver version 0.1
gfar_mdio_read(cf9db400, 16, 3) = ffff
mv88e6131_probe(cf9db400, 0) = 65535
eth0: could not detect attached switch
dsa: probe of dsa.0 failed with error -22
========================================================


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3815 bytes --]

Index: drivers/net/gianfar_mii.c
===================================================================
--- drivers/net/gianfar_mii.c	(revision 4872)
+++ drivers/net/gianfar_mii.c	(working copy)
@@ -101,25 +101,36 @@
 /* Write value to the PHY at mii_id at register regnum,
  * on the bus, waiting until the write is done before returning.
  * All PHY configuration is done through the TSEC1 MIIM regs */
-int gfar_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value)
+int _gfar_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value)
 {
 	struct gfar_mii __iomem *regs = (void __iomem *)bus->priv;
 
 	/* Write to the local MII regs */
 	return(gfar_local_mdio_write(regs, mii_id, regnum, value));
 }
+int gfar_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value)
+{
+    int res = _gfar_mdio_write(bus, mii_id, regnum, value);
+    printk("%s(%p, %d, %d, %x) = %x\n", __FUNCTION__, bus, mii_id, regnum, value, res);
+    return res;
+}
 
 /* Read the bus for PHY at addr mii_id, register regnum, and
  * return the value.  Clears miimcom first.  All PHY
  * configuration has to be done through the TSEC1 MIIM regs */
-int gfar_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+int _gfar_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
 {
 	struct gfar_mii __iomem *regs = (void __iomem *)bus->priv;
 
 	/* Read the local MII regs */
 	return(gfar_local_mdio_read(regs, mii_id, regnum));
 }
-
+int gfar_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+    int res = _gfar_mdio_read(bus, mii_id, regnum);
+    printk("%s(%p, %d, %d) = %x\n", __FUNCTION__, bus, mii_id, regnum, res);
+    return res;
+}
 /* Reset the MIIM registers, and wait for the bus to free */
 static int gfar_mdio_reset(struct mii_bus *bus)
 {
@@ -150,6 +161,9 @@
 	return 0;
 }
 
+// HACK
+struct device *gianfar_mdio;
+// HACK
 
 static int gfar_mdio_probe(struct device *dev)
 {
@@ -174,6 +188,11 @@
 	new_bus->reset = &gfar_mdio_reset,
 	snprintf(new_bus->id, MII_BUS_ID_SIZE, "%x", pdev->id);
 
+        // HACK
+        gianfar_mdio = dev;
+        printk("Set gianfar_mdio = %p, mii_bus = %p\n", dev, new_bus);
+        // HACK
+
 	pdata = (struct gianfar_mdio_data *)pdev->dev.platform_data;
 
 	if (NULL == pdata) {
Index: drivers/net/gianfar.c
===================================================================
--- drivers/net/gianfar.c	(revision 4872)
+++ drivers/net/gianfar.c	(working copy)
@@ -152,6 +152,30 @@
 	return (priv->vlan_enable || priv->rx_csum_enable);
 }
 
+// HACK
+#include <net/dsa.h>
+struct device *gianfar_eth0;
+extern struct device *gianfar_mdio;
+struct dsa_platform_data _switch_data = {
+    .port_names[0]  = "lan1.1",
+    .port_names[1]  = "lan1.2",
+    .port_names[2]  = "lan1.3",
+    .port_names[3]  = "lan1.4",
+    .port_names[4]  = "lan1.5",
+    .port_names[5]  = "lan1.6",
+    .port_names[6]  = "lan1.7",
+    .port_names[7]  = "lan1.8",
+    .port_names[10]  = "cpu",
+};
+
+struct platform_device _switch_device = {
+    .name           = "dsa",
+    .id             = 0,
+    .num_resources  = 0,
+};
+
+// HACK
+
 /* Set up the ethernet device structure, private data,
  * and anything else we need before we start */
 static int gfar_probe(struct platform_device *pdev)
@@ -164,6 +188,17 @@
 	int err = 0, irq;
 	DECLARE_MAC_BUF(mac);
 
+        // HACK
+        if (!gianfar_eth0) {
+            gianfar_eth0 = &pdev->dev;
+            printk("Set gianfar_eth0 = %p\n", &pdev->dev);
+            _switch_data.netdev = gianfar_eth0;
+            _switch_data.mii_bus = gianfar_mdio;
+            _switch_device.dev.platform_data = &_switch_data;
+            platform_device_register(&_switch_device);
+        }
+        // HACK
+
 	einfo = (struct gianfar_platform_data *) pdev->dev.platform_data;
 
 	if (NULL == einfo) {

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Thu, Feb 26, 2009 at 06:12:32PM -0700, Gary Thomas wrote:

> >>>>>> Is there support for this device anywhere?  In particular,
> >>>>>> the M88E6095 switch.
> >>>>> Not at the moment, but it should be easy enough to add.  If your
> >>>>> board already runs on 2.6.28+, I can whip up some patches for you
> >>>>> to try from the docs I have for that part.
> >>>> That would be much appreciated, thanks.
> >>> I noticed that the 6095/6095F are quite similar to the 6131 as far
> >>> as the register set goes.  So something along these lines (hacky
> >>> patch, breaks 6131, not for mainline) might just work to detect
> >>> single 6095s (cascading DSA chips is something that needs more work,
> >>> let's get the single-chip case working first).
> >>>
> >>> The other thing you'll need to do is create dsa platform devices
> >>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
> >>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
> >>> device * for your network device, a struct device * for your mii bus,
> >>> the switch MII address on the MII bus, and names of the individual
> >>> ports (where you'll specify "cpu" for the port on the switch chip that
> >>> the CPU is connected to).
> >>>
> >>> Let me know if this works.
> >> Thanks, I'll give it a try.  It will take a little effort
> >> to get setup as I have to work within the open firmware
> >> structure (that's how all the various components are
> >> specified).
> > 
> > Right, we don't have OF bindings yet.  I guess this would make sense
> > to do generically at some point, since there are quite a few PPC
> > platforms with DSA switch chips.
> 
> Here's what I tried - (patch attached) - a trulyhorrible hack,
> but I've not figured out how to get the correct device pointers
> from the OF world yet.  The boot log shows that it's trying, but
> I don't see the DSA layer (M88E690x driver) doing the MII indirection
> that's needed for this device.
> 
> I'm probably not starting it up correctly, but I think I followed
> the examples you cited.  Any ideas?

"indirection needed for this device" -- does that mean that your
switch chip is configured to use the multi-chip addressing mode?
(It looks like it, as most of the MII addresses return ffff in
their ID registers.)  If yes, you should set ->sw_addr to whatever
MII address the chip has been assigned.

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Thu, Feb 26, 2009 at 06:12:32PM -0700, Gary Thomas wrote:
> 
>>>>>>>> Is there support for this device anywhere?  In particular,
>>>>>>>> the M88E6095 switch.
>>>>>>> Not at the moment, but it should be easy enough to add.  If your
>>>>>>> board already runs on 2.6.28+, I can whip up some patches for you
>>>>>>> to try from the docs I have for that part.
>>>>>> That would be much appreciated, thanks.
>>>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
>>>>> as the register set goes.  So something along these lines (hacky
>>>>> patch, breaks 6131, not for mainline) might just work to detect
>>>>> single 6095s (cascading DSA chips is something that needs more work,
>>>>> let's get the single-chip case working first).
>>>>>
>>>>> The other thing you'll need to do is create dsa platform devices
>>>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
>>>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
>>>>> device * for your network device, a struct device * for your mii bus,
>>>>> the switch MII address on the MII bus, and names of the individual
>>>>> ports (where you'll specify "cpu" for the port on the switch chip that
>>>>> the CPU is connected to).
>>>>>
>>>>> Let me know if this works.
>>>> Thanks, I'll give it a try.  It will take a little effort
>>>> to get setup as I have to work within the open firmware
>>>> structure (that's how all the various components are
>>>> specified).
>>> Right, we don't have OF bindings yet.  I guess this would make sense
>>> to do generically at some point, since there are quite a few PPC
>>> platforms with DSA switch chips.
>> Here's what I tried - (patch attached) - a trulyhorrible hack,
>> but I've not figured out how to get the correct device pointers
>> from the OF world yet.  The boot log shows that it's trying, but
>> I don't see the DSA layer (M88E690x driver) doing the MII indirection
>> that's needed for this device.
>>
>> I'm probably not starting it up correctly, but I think I followed
>> the examples you cited.  Any ideas?
> 
> "indirection needed for this device" -- does that mean that your
> switch chip is configured to use the multi-chip addressing mode?
> (It looks like it, as most of the MII addresses return ffff in
> their ID registers.)  If yes, you should set ->sw_addr to whatever
> MII address the chip has been assigned.

Much better, my switch seems to be found now.

  Distributed Switch Architecture driver version 0.1
  gfar_mdio_read(cf9db400, 1, 0) = 1811
  gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
  gfar_mdio_read(cf9db400, 1, 0) = 1a03
  gfar_mdio_read(cf9db400, 1, 1) = 953
  mv88e6131_probe(cf9db400, 1) = 2387
  eth0: detected a Marvell 88E6095/88E6095F switch
     ...
  root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
  24520:01:00  24520:01:02  24520:01:04  24520:01:06
  24520:01:01  24520:01:03  24520:01:05  24520:01:07

However, the network subsystem still can't locate it.  It may be
a complication of the OF stuff and how the [gianfar] network
device knows what PHY to look at.

  starting network interfaces...
  24520:01 not found
  eth0: Could not attach to PHY

Also, how do I specify the [implicit] route within the switch
that connects '24520:01:00' to the CPU port '24520:01:0A' (if
there was such a thing)?  My boot loader has configured the
switch for this path - I've not looked through the log to see
what the DSA layer did.

Thanks for your help

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

Gary Thomas wrote:
> Lennert Buytenhek wrote:
>> On Thu, Feb 26, 2009 at 06:12:32PM -0700, Gary Thomas wrote:
>>
>>>>>>>>> Is there support for this device anywhere?  In particular,
>>>>>>>>> the M88E6095 switch.
>>>>>>>> Not at the moment, but it should be easy enough to add.  If your
>>>>>>>> board already runs on 2.6.28+, I can whip up some patches for you
>>>>>>>> to try from the docs I have for that part.
>>>>>>> That would be much appreciated, thanks.
>>>>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
>>>>>> as the register set goes.  So something along these lines (hacky
>>>>>> patch, breaks 6131, not for mainline) might just work to detect
>>>>>> single 6095s (cascading DSA chips is something that needs more work,
>>>>>> let's get the single-chip case working first).
>>>>>>
>>>>>> The other thing you'll need to do is create dsa platform devices
>>>>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
>>>>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
>>>>>> device * for your network device, a struct device * for your mii bus,
>>>>>> the switch MII address on the MII bus, and names of the individual
>>>>>> ports (where you'll specify "cpu" for the port on the switch chip that
>>>>>> the CPU is connected to).
>>>>>>
>>>>>> Let me know if this works.
>>>>> Thanks, I'll give it a try.  It will take a little effort
>>>>> to get setup as I have to work within the open firmware
>>>>> structure (that's how all the various components are
>>>>> specified).
>>>> Right, we don't have OF bindings yet.  I guess this would make sense
>>>> to do generically at some point, since there are quite a few PPC
>>>> platforms with DSA switch chips.
>>> Here's what I tried - (patch attached) - a trulyhorrible hack,
>>> but I've not figured out how to get the correct device pointers
>>> from the OF world yet.  The boot log shows that it's trying, but
>>> I don't see the DSA layer (M88E690x driver) doing the MII indirection
>>> that's needed for this device.
>>>
>>> I'm probably not starting it up correctly, but I think I followed
>>> the examples you cited.  Any ideas?
>> "indirection needed for this device" -- does that mean that your
>> switch chip is configured to use the multi-chip addressing mode?
>> (It looks like it, as most of the MII addresses return ffff in
>> their ID registers.)  If yes, you should set ->sw_addr to whatever
>> MII address the chip has been assigned.
> 
> Much better, my switch seems to be found now.
> 
>   Distributed Switch Architecture driver version 0.1
>   gfar_mdio_read(cf9db400, 1, 0) = 1811
>   gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
>   gfar_mdio_read(cf9db400, 1, 0) = 1a03
>   gfar_mdio_read(cf9db400, 1, 1) = 953
>   mv88e6131_probe(cf9db400, 1) = 2387
>   eth0: detected a Marvell 88E6095/88E6095F switch
>      ...
>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
>   24520:01:01  24520:01:03  24520:01:05  24520:01:07
> 
> However, the network subsystem still can't locate it.  It may be
> a complication of the OF stuff and how the [gianfar] network
> device knows what PHY to look at.
> 
>   starting network interfaces...
>   24520:01 not found
>   eth0: Could not attach to PHY
> 
> Also, how do I specify the [implicit] route within the switch
> that connects '24520:01:00' to the CPU port '24520:01:0A' (if
> there was such a thing)?  My boot loader has configured the
> switch for this path - I've not looked through the log to see
> what the DSA layer did.
> 
> Thanks for your help
> 

Trying the simple/obvious did not work so well:
  Distributed Switch Architecture driver version 0.1
  mv88e6131_probe(cf9db400, 1) = 2387
  eth0: detected a Marvell 88E6095/88E6095F switch
  dsa slave smi: probed
  lan1.2: 24520:01:00 already attached
  Unable to handle kernel paging request for data at address 0x00000024
  Faulting instruction address: 0xc019e584
  Oops: Kernel access of bad area, sig: 11 [#1]
  ASP8347E
  Modules linked in:
  NIP: c019e584 LR: c019e570 CTR: c018a734
  REGS: cf821c40 TRAP: 0300   Not tainted  (2.6.28-svn4872-dirty)
  MSR: 00009032 <EE,ME,IR,DR>  CR: 22000024  XER: 20000000
  DAR: 00000024, DSISR: 20000000
  TASK = cf81f900[1] 'swapper' THREAD: cf820000
  GPR00: 00000001 cf821cf0 cf81f900 cf9ff200 00001697 ffffffff c018aeec 00004000
  GPR08: 00000001 00000000 00003fff cf9ff200 82000022 7e700000 00050000 00019edc
  GPR16: fffffffd 00050000 00043514 00044320 000434e8 c0362e88 c02f8f9c cf854800
  GPR24: cf8549c0 00000001 00000001 c0362e88 cf854800 cf9ff3b8 cf9f9b80 cf9ff200
  NIP [c019e584] phy_start_aneg+0x34/0xcc
  LR [c019e570] phy_start_aneg+0x20/0xcc
  Call Trace:
  [cf821cf0] [c019ff0c] phy_attach+0x140/0x148 (unreliable)
  [cf821d10] [c025ae3c] dsa_slave_create+0x16c/0x1ac
  [cf821d30] [c025aa9c] dsa_probe+0x428/0x454
  [cf821d70] [c0193cc4] platform_drv_probe+0x20/0x30
  [cf821d80] [c0192ae0] driver_probe_device+0xb4/0x1e8
  [cf821da0] [c0192cb8] __driver_attach+0xa4/0xa8
  [cf821dc0] [c0192278] bus_for_each_dev+0x5c/0xa4
  [cf821df0] [c01928fc] driver_attach+0x24/0x34
  [cf821e00] [c0191b90] bus_add_driver+0x1d8/0x24c
  [cf821e20] [c0192ed8] driver_register+0x70/0x160
  [cf821e40] [c0193f94] platform_driver_register+0xac/0xbc
  [cf821e50] [c0339828] dsa_init_module+0x18/0x28
  [cf821e60] [c0003874] do_one_initcall+0x38/0x194
  [cf821fc0] [c031a178] kernel_init+0x94/0x100
  [cf821ff0] [c0010df8] kernel_thread+0x4c/0x68

Ideas?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 05:42:40AM -0700, Gary Thomas wrote:

> >>>>>>>>> Is there support for this device anywhere?  In particular,
> >>>>>>>>> the M88E6095 switch.
> >>>>>>>> Not at the moment, but it should be easy enough to add.  If your
> >>>>>>>> board already runs on 2.6.28+, I can whip up some patches for you
> >>>>>>>> to try from the docs I have for that part.
> >>>>>>> That would be much appreciated, thanks.
> >>>>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
> >>>>>> as the register set goes.  So something along these lines (hacky
> >>>>>> patch, breaks 6131, not for mainline) might just work to detect
> >>>>>> single 6095s (cascading DSA chips is something that needs more work,
> >>>>>> let's get the single-chip case working first).
> >>>>>>
> >>>>>> The other thing you'll need to do is create dsa platform devices
> >>>>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
> >>>>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
> >>>>>> device * for your network device, a struct device * for your mii bus,
> >>>>>> the switch MII address on the MII bus, and names of the individual
> >>>>>> ports (where you'll specify "cpu" for the port on the switch chip that
> >>>>>> the CPU is connected to).
> >>>>>>
> >>>>>> Let me know if this works.
> >>>>> Thanks, I'll give it a try.  It will take a little effort
> >>>>> to get setup as I have to work within the open firmware
> >>>>> structure (that's how all the various components are
> >>>>> specified).
> >>>> Right, we don't have OF bindings yet.  I guess this would make sense
> >>>> to do generically at some point, since there are quite a few PPC
> >>>> platforms with DSA switch chips.
> >>> Here's what I tried - (patch attached) - a trulyhorrible hack,
> >>> but I've not figured out how to get the correct device pointers
> >>> from the OF world yet.  The boot log shows that it's trying, but
> >>> I don't see the DSA layer (M88E690x driver) doing the MII indirection
> >>> that's needed for this device.
> >>>
> >>> I'm probably not starting it up correctly, but I think I followed
> >>> the examples you cited.  Any ideas?
> >> "indirection needed for this device" -- does that mean that your
> >> switch chip is configured to use the multi-chip addressing mode?
> >> (It looks like it, as most of the MII addresses return ffff in
> >> their ID registers.)  If yes, you should set ->sw_addr to whatever
> >> MII address the chip has been assigned.
> > 
> > Much better, my switch seems to be found now.
> > 
> >   Distributed Switch Architecture driver version 0.1
> >   gfar_mdio_read(cf9db400, 1, 0) = 1811
> >   gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
> >   gfar_mdio_read(cf9db400, 1, 0) = 1a03
> >   gfar_mdio_read(cf9db400, 1, 1) = 953
> >   mv88e6131_probe(cf9db400, 1) = 2387
> >   eth0: detected a Marvell 88E6095/88E6095F switch
> >      ...
> >   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
> >   24520:01:00  24520:01:02  24520:01:04  24520:01:06
> >   24520:01:01  24520:01:03  24520:01:05  24520:01:07
> > 
> > However, the network subsystem still can't locate it.  It may be
> > a complication of the OF stuff and how the [gianfar] network
> > device knows what PHY to look at.
> > 
> >   starting network interfaces...
> >   24520:01 not found
> >   eth0: Could not attach to PHY
> > 
> > Also, how do I specify the [implicit] route within the switch
> > that connects '24520:01:00' to the CPU port '24520:01:0A' (if
> > there was such a thing)?  My boot loader has configured the
> > switch for this path - I've not looked through the log to see
> > what the DSA layer did.
> > 
> > Thanks for your help
> 
> Trying the simple/obvious did not work so well:
>   Distributed Switch Architecture driver version 0.1
>   mv88e6131_probe(cf9db400, 1) = 2387
>   eth0: detected a Marvell 88E6095/88E6095F switch
>   dsa slave smi: probed
>   lan1.2: 24520:01:00 already attached
>   Unable to handle kernel paging request for data at address 0x00000024

What did you do here?

Also, can you show me what you're filling the dsa platform data
structure with?

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 05:42:40AM -0700, Gary Thomas wrote:
> 
>>>>>>>>>>> Is there support for this device anywhere?  In particular,
>>>>>>>>>>> the M88E6095 switch.
>>>>>>>>>> Not at the moment, but it should be easy enough to add.  If your
>>>>>>>>>> board already runs on 2.6.28+, I can whip up some patches for you
>>>>>>>>>> to try from the docs I have for that part.
>>>>>>>>> That would be much appreciated, thanks.
>>>>>>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
>>>>>>>> as the register set goes.  So something along these lines (hacky
>>>>>>>> patch, breaks 6131, not for mainline) might just work to detect
>>>>>>>> single 6095s (cascading DSA chips is something that needs more work,
>>>>>>>> let's get the single-chip case working first).
>>>>>>>>
>>>>>>>> The other thing you'll need to do is create dsa platform devices
>>>>>>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
>>>>>>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
>>>>>>>> device * for your network device, a struct device * for your mii bus,
>>>>>>>> the switch MII address on the MII bus, and names of the individual
>>>>>>>> ports (where you'll specify "cpu" for the port on the switch chip that
>>>>>>>> the CPU is connected to).
>>>>>>>>
>>>>>>>> Let me know if this works.
>>>>>>> Thanks, I'll give it a try.  It will take a little effort
>>>>>>> to get setup as I have to work within the open firmware
>>>>>>> structure (that's how all the various components are
>>>>>>> specified).
>>>>>> Right, we don't have OF bindings yet.  I guess this would make sense
>>>>>> to do generically at some point, since there are quite a few PPC
>>>>>> platforms with DSA switch chips.
>>>>> Here's what I tried - (patch attached) - a trulyhorrible hack,
>>>>> but I've not figured out how to get the correct device pointers
>>>>> from the OF world yet.  The boot log shows that it's trying, but
>>>>> I don't see the DSA layer (M88E690x driver) doing the MII indirection
>>>>> that's needed for this device.
>>>>>
>>>>> I'm probably not starting it up correctly, but I think I followed
>>>>> the examples you cited.  Any ideas?
>>>> "indirection needed for this device" -- does that mean that your
>>>> switch chip is configured to use the multi-chip addressing mode?
>>>> (It looks like it, as most of the MII addresses return ffff in
>>>> their ID registers.)  If yes, you should set ->sw_addr to whatever
>>>> MII address the chip has been assigned.
>>> Much better, my switch seems to be found now.
>>>
>>>   Distributed Switch Architecture driver version 0.1
>>>   gfar_mdio_read(cf9db400, 1, 0) = 1811
>>>   gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
>>>   gfar_mdio_read(cf9db400, 1, 0) = 1a03
>>>   gfar_mdio_read(cf9db400, 1, 1) = 953
>>>   mv88e6131_probe(cf9db400, 1) = 2387
>>>   eth0: detected a Marvell 88E6095/88E6095F switch
>>>      ...
>>>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
>>>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
>>>   24520:01:01  24520:01:03  24520:01:05  24520:01:07
>>>
>>> However, the network subsystem still can't locate it.  It may be
>>> a complication of the OF stuff and how the [gianfar] network
>>> device knows what PHY to look at.
>>>
>>>   starting network interfaces...
>>>   24520:01 not found
>>>   eth0: Could not attach to PHY
>>>
>>> Also, how do I specify the [implicit] route within the switch
>>> that connects '24520:01:00' to the CPU port '24520:01:0A' (if
>>> there was such a thing)?  My boot loader has configured the
>>> switch for this path - I've not looked through the log to see
>>> what the DSA layer did.
>>>
>>> Thanks for your help
>> Trying the simple/obvious did not work so well:
>>   Distributed Switch Architecture driver version 0.1
>>   mv88e6131_probe(cf9db400, 1) = 2387
>>   eth0: detected a Marvell 88E6095/88E6095F switch
>>   dsa slave smi: probed
>>   lan1.2: 24520:01:00 already attached
>>   Unable to handle kernel paging request for data at address 0x00000024
> 
> What did you do here?

I just tried to force it by making it probe '24520:01:00'
instead of '24520:01'

> Also, can you show me what you're filling the dsa platform data
> structure with?

struct dsa_platform_data _switch_data = {
    .port_names[0]  = "lan1.1",
    .port_names[1]  = "lan1.2",
    .port_names[2]  = "lan1.3",
    .port_names[3]  = "lan1.4",
    .port_names[4]  = "lan1.5",
    .port_names[5]  = "lan1.6",
    .port_names[6]  = "lan1.7",
    .port_names[7]  = "lan1.8",
    .port_names[10]  = "cpu",
    .sw_addr = 1,
};

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 06:19:57AM -0700, Gary Thomas wrote:

> >>>>>>>>>>> Is there support for this device anywhere?  In particular,
> >>>>>>>>>>> the M88E6095 switch.
> >>>>>>>>>> Not at the moment, but it should be easy enough to add.  If your
> >>>>>>>>>> board already runs on 2.6.28+, I can whip up some patches for you
> >>>>>>>>>> to try from the docs I have for that part.
> >>>>>>>>> That would be much appreciated, thanks.
> >>>>>>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
> >>>>>>>> as the register set goes.  So something along these lines (hacky
> >>>>>>>> patch, breaks 6131, not for mainline) might just work to detect
> >>>>>>>> single 6095s (cascading DSA chips is something that needs more work,
> >>>>>>>> let's get the single-chip case working first).
> >>>>>>>>
> >>>>>>>> The other thing you'll need to do is create dsa platform devices
> >>>>>>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
> >>>>>>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
> >>>>>>>> device * for your network device, a struct device * for your mii bus,
> >>>>>>>> the switch MII address on the MII bus, and names of the individual
> >>>>>>>> ports (where you'll specify "cpu" for the port on the switch chip that
> >>>>>>>> the CPU is connected to).
> >>>>>>>>
> >>>>>>>> Let me know if this works.
> >>>>>>> Thanks, I'll give it a try.  It will take a little effort
> >>>>>>> to get setup as I have to work within the open firmware
> >>>>>>> structure (that's how all the various components are
> >>>>>>> specified).
> >>>>>> Right, we don't have OF bindings yet.  I guess this would make sense
> >>>>>> to do generically at some point, since there are quite a few PPC
> >>>>>> platforms with DSA switch chips.
> >>>>> Here's what I tried - (patch attached) - a trulyhorrible hack,
> >>>>> but I've not figured out how to get the correct device pointers
> >>>>> from the OF world yet.  The boot log shows that it's trying, but
> >>>>> I don't see the DSA layer (M88E690x driver) doing the MII indirection
> >>>>> that's needed for this device.
> >>>>>
> >>>>> I'm probably not starting it up correctly, but I think I followed
> >>>>> the examples you cited.  Any ideas?
> >>>> "indirection needed for this device" -- does that mean that your
> >>>> switch chip is configured to use the multi-chip addressing mode?
> >>>> (It looks like it, as most of the MII addresses return ffff in
> >>>> their ID registers.)  If yes, you should set ->sw_addr to whatever
> >>>> MII address the chip has been assigned.
> >>> Much better, my switch seems to be found now.
> >>>
> >>>   Distributed Switch Architecture driver version 0.1
> >>>   gfar_mdio_read(cf9db400, 1, 0) = 1811
> >>>   gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
> >>>   gfar_mdio_read(cf9db400, 1, 0) = 1a03
> >>>   gfar_mdio_read(cf9db400, 1, 1) = 953
> >>>   mv88e6131_probe(cf9db400, 1) = 2387
> >>>   eth0: detected a Marvell 88E6095/88E6095F switch
> >>>      ...
> >>>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
> >>>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
> >>>   24520:01:01  24520:01:03  24520:01:05  24520:01:07
> >>>
> >>> However, the network subsystem still can't locate it.  It may be
> >>> a complication of the OF stuff and how the [gianfar] network
> >>> device knows what PHY to look at.
> >>>
> >>>   starting network interfaces...
> >>>   24520:01 not found
> >>>   eth0: Could not attach to PHY
> >>>
> >>> Also, how do I specify the [implicit] route within the switch
> >>> that connects '24520:01:00' to the CPU port '24520:01:0A' (if
> >>> there was such a thing)?  My boot loader has configured the
> >>> switch for this path - I've not looked through the log to see
> >>> what the DSA layer did.
> >>>
> >>> Thanks for your help
> >> Trying the simple/obvious did not work so well:
> >>   Distributed Switch Architecture driver version 0.1
> >>   mv88e6131_probe(cf9db400, 1) = 2387
> >>   eth0: detected a Marvell 88E6095/88E6095F switch
> >>   dsa slave smi: probed
> >>   lan1.2: 24520:01:00 already attached
> >>   Unable to handle kernel paging request for data at address 0x00000024
> > 
> > What did you do here?
> 
> I just tried to force it by making it probe '24520:01:00'
> instead of '24520:01'
> 
> > Also, can you show me what you're filling the dsa platform data
> > structure with?
> 
> struct dsa_platform_data _switch_data = {
>     .port_names[0]  = "lan1.1",
>     .port_names[1]  = "lan1.2",
>     .port_names[2]  = "lan1.3",
>     .port_names[3]  = "lan1.4",
>     .port_names[4]  = "lan1.5",
>     .port_names[5]  = "lan1.6",
>     .port_names[6]  = "lan1.7",
>     .port_names[7]  = "lan1.8",
>     .port_names[10]  = "cpu",
>     .sw_addr = 1,
> };

Just this should do the trick.  So what's not working -- are the
interfaces not showing up?  Or packet RX/TX isn't working?  Or
something else?

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 06:19:57AM -0700, Gary Thomas wrote:
> 
>>>>>>>>>>>>> Is there support for this device anywhere?  In particular,
>>>>>>>>>>>>> the M88E6095 switch.
>>>>>>>>>>>> Not at the moment, but it should be easy enough to add.  If your
>>>>>>>>>>>> board already runs on 2.6.28+, I can whip up some patches for you
>>>>>>>>>>>> to try from the docs I have for that part.
>>>>>>>>>>> That would be much appreciated, thanks.
>>>>>>>>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
>>>>>>>>>> as the register set goes.  So something along these lines (hacky
>>>>>>>>>> patch, breaks 6131, not for mainline) might just work to detect
>>>>>>>>>> single 6095s (cascading DSA chips is something that needs more work,
>>>>>>>>>> let's get the single-chip case working first).
>>>>>>>>>>
>>>>>>>>>> The other thing you'll need to do is create dsa platform devices
>>>>>>>>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
>>>>>>>>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
>>>>>>>>>> device * for your network device, a struct device * for your mii bus,
>>>>>>>>>> the switch MII address on the MII bus, and names of the individual
>>>>>>>>>> ports (where you'll specify "cpu" for the port on the switch chip that
>>>>>>>>>> the CPU is connected to).
>>>>>>>>>>
>>>>>>>>>> Let me know if this works.
>>>>>>>>> Thanks, I'll give it a try.  It will take a little effort
>>>>>>>>> to get setup as I have to work within the open firmware
>>>>>>>>> structure (that's how all the various components are
>>>>>>>>> specified).
>>>>>>>> Right, we don't have OF bindings yet.  I guess this would make sense
>>>>>>>> to do generically at some point, since there are quite a few PPC
>>>>>>>> platforms with DSA switch chips.
>>>>>>> Here's what I tried - (patch attached) - a trulyhorrible hack,
>>>>>>> but I've not figured out how to get the correct device pointers
>>>>>>> from the OF world yet.  The boot log shows that it's trying, but
>>>>>>> I don't see the DSA layer (M88E690x driver) doing the MII indirection
>>>>>>> that's needed for this device.
>>>>>>>
>>>>>>> I'm probably not starting it up correctly, but I think I followed
>>>>>>> the examples you cited.  Any ideas?
>>>>>> "indirection needed for this device" -- does that mean that your
>>>>>> switch chip is configured to use the multi-chip addressing mode?
>>>>>> (It looks like it, as most of the MII addresses return ffff in
>>>>>> their ID registers.)  If yes, you should set ->sw_addr to whatever
>>>>>> MII address the chip has been assigned.
>>>>> Much better, my switch seems to be found now.
>>>>>
>>>>>   Distributed Switch Architecture driver version 0.1
>>>>>   gfar_mdio_read(cf9db400, 1, 0) = 1811
>>>>>   gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
>>>>>   gfar_mdio_read(cf9db400, 1, 0) = 1a03
>>>>>   gfar_mdio_read(cf9db400, 1, 1) = 953
>>>>>   mv88e6131_probe(cf9db400, 1) = 2387
>>>>>   eth0: detected a Marvell 88E6095/88E6095F switch
>>>>>      ...
>>>>>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
>>>>>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
>>>>>   24520:01:01  24520:01:03  24520:01:05  24520:01:07
>>>>>
>>>>> However, the network subsystem still can't locate it.  It may be
>>>>> a complication of the OF stuff and how the [gianfar] network
>>>>> device knows what PHY to look at.
>>>>>
>>>>>   starting network interfaces...
>>>>>   24520:01 not found
>>>>>   eth0: Could not attach to PHY
>>>>>
>>>>> Also, how do I specify the [implicit] route within the switch
>>>>> that connects '24520:01:00' to the CPU port '24520:01:0A' (if
>>>>> there was such a thing)?  My boot loader has configured the
>>>>> switch for this path - I've not looked through the log to see
>>>>> what the DSA layer did.
>>>>>
>>>>> Thanks for your help
>>>> Trying the simple/obvious did not work so well:
>>>>   Distributed Switch Architecture driver version 0.1
>>>>   mv88e6131_probe(cf9db400, 1) = 2387
>>>>   eth0: detected a Marvell 88E6095/88E6095F switch
>>>>   dsa slave smi: probed
>>>>   lan1.2: 24520:01:00 already attached
>>>>   Unable to handle kernel paging request for data at address 0x00000024
>>> What did you do here?
>> I just tried to force it by making it probe '24520:01:00'
>> instead of '24520:01'
>>
>>> Also, can you show me what you're filling the dsa platform data
>>> structure with?
>> struct dsa_platform_data _switch_data = {
>>     .port_names[0]  = "lan1.1",
>>     .port_names[1]  = "lan1.2",
>>     .port_names[2]  = "lan1.3",
>>     .port_names[3]  = "lan1.4",
>>     .port_names[4]  = "lan1.5",
>>     .port_names[5]  = "lan1.6",
>>     .port_names[6]  = "lan1.7",
>>     .port_names[7]  = "lan1.8",
>>     .port_names[10]  = "cpu",
>>     .sw_addr = 1,
>> };
> 
> Just this should do the trick.  So what's not working -- are the
> interfaces not showing up?  Or packet RX/TX isn't working?  Or
> something else?

It won't let me bring up eth0 (my scripts try to run DHCP):
  starting network interfaces...
  24520:01 not found
  eth0: Could not attach to PHY
  ip: SIOCSIFFLAGS: No such device

As for the other devices, they do show up if I let eth0 try to
attach to the PHY:

root@ppc_target:~ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compresse
d
    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
  eth0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
  eth1:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
lan1.1:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
lan1.2:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
lan1.3:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
lan1.4:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
lan1.5:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
lan1.6:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
lan1.7:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0
lan1.8:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 06:27:25AM -0700, Gary Thomas wrote:

> >>> Also, can you show me what you're filling the dsa platform data
> >>> structure with?
> >> struct dsa_platform_data _switch_data = {
> >>     .port_names[0]  = "lan1.1",
> >>     .port_names[1]  = "lan1.2",
> >>     .port_names[2]  = "lan1.3",
> >>     .port_names[3]  = "lan1.4",
> >>     .port_names[4]  = "lan1.5",
> >>     .port_names[5]  = "lan1.6",
> >>     .port_names[6]  = "lan1.7",
> >>     .port_names[7]  = "lan1.8",
> >>     .port_names[10]  = "cpu",
> >>     .sw_addr = 1,
> >> };
> > 
> > Just this should do the trick.  So what's not working -- are the
> > interfaces not showing up?  Or packet RX/TX isn't working?  Or
> > something else?
> 
> It won't let me bring up eth0 (my scripts try to run DHCP):
>   starting network interfaces...
>   24520:01 not found
>   eth0: Could not attach to PHY
>   ip: SIOCSIFFLAGS: No such device
> 
> As for the other devices, they do show up if I let eth0 try to
> attach to the PHY:

OK.  If you try to cheat the gianfar driver by having it attach to
the PHY for lan1.1, and plug a network cable into lan1.1 so that the
link goes up and gianfar thinks that the link on eth0 is up, does that
enable you to pass packets over any of the switch interfaces?  That
should be working now in this stage.

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 06:27:25AM -0700, Gary Thomas wrote:
> 
>>>>> Also, can you show me what you're filling the dsa platform data
>>>>> structure with?
>>>> struct dsa_platform_data _switch_data = {
>>>>     .port_names[0]  = "lan1.1",
>>>>     .port_names[1]  = "lan1.2",
>>>>     .port_names[2]  = "lan1.3",
>>>>     .port_names[3]  = "lan1.4",
>>>>     .port_names[4]  = "lan1.5",
>>>>     .port_names[5]  = "lan1.6",
>>>>     .port_names[6]  = "lan1.7",
>>>>     .port_names[7]  = "lan1.8",
>>>>     .port_names[10]  = "cpu",
>>>>     .sw_addr = 1,
>>>> };
>>> Just this should do the trick.  So what's not working -- are the
>>> interfaces not showing up?  Or packet RX/TX isn't working?  Or
>>> something else?
>> It won't let me bring up eth0 (my scripts try to run DHCP):
>>   starting network interfaces...
>>   24520:01 not found
>>   eth0: Could not attach to PHY
>>   ip: SIOCSIFFLAGS: No such device
>>
>> As for the other devices, they do show up if I let eth0 try to
>> attach to the PHY:
> 
> OK.  If you try to cheat the gianfar driver by having it attach to
> the PHY for lan1.1, and plug a network cable into lan1.1 so that the
> link goes up and gianfar thinks that the link on eth0 is up, does that
> enable you to pass packets over any of the switch interfaces?  That
> should be working now in this stage.

So, what name do I use when the gianfar is trying to attach?
It makes this call:
  phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface);
where phy_id="24520:01".

Using "24520:01:00" gets an error:
  eth0: 24520:01:00 already attached

Maybe the DSA layer/driver needs to export a device "24520:01"
which pretends all of the things that the gianfar wants (1000Mb/Full/Link)?


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 07:36:07AM -0700, Gary Thomas wrote:

> >>>>> Also, can you show me what you're filling the dsa platform data
> >>>>> structure with?
> >>>> struct dsa_platform_data _switch_data = {
> >>>>     .port_names[0]  = "lan1.1",
> >>>>     .port_names[1]  = "lan1.2",
> >>>>     .port_names[2]  = "lan1.3",
> >>>>     .port_names[3]  = "lan1.4",
> >>>>     .port_names[4]  = "lan1.5",
> >>>>     .port_names[5]  = "lan1.6",
> >>>>     .port_names[6]  = "lan1.7",
> >>>>     .port_names[7]  = "lan1.8",
> >>>>     .port_names[10]  = "cpu",
> >>>>     .sw_addr = 1,
> >>>> };
> >>> Just this should do the trick.  So what's not working -- are the
> >>> interfaces not showing up?  Or packet RX/TX isn't working?  Or
> >>> something else?
> >> It won't let me bring up eth0 (my scripts try to run DHCP):
> >>   starting network interfaces...
> >>   24520:01 not found
> >>   eth0: Could not attach to PHY
> >>   ip: SIOCSIFFLAGS: No such device
> >>
> >> As for the other devices, they do show up if I let eth0 try to
> >> attach to the PHY:
> > 
> > OK.  If you try to cheat the gianfar driver by having it attach to
> > the PHY for lan1.1, and plug a network cable into lan1.1 so that the
> > link goes up and gianfar thinks that the link on eth0 is up, does that
> > enable you to pass packets over any of the switch interfaces?  That
> > should be working now in this stage.
> 
> So, what name do I use when the gianfar is trying to attach?
> It makes this call:
>   phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface);
> where phy_id="24520:01".
> 
> Using "24520:01:00" gets an error:
>   eth0: 24520:01:00 already attached
> 
> Maybe the DSA layer/driver needs to export a device "24520:01"
> which pretends all of the things that the gianfar wants (1000Mb/Full/Link)?

Well, this isn't DSA-specific -- e.g. if you'd hook your CPU's
ethernet MAC up to an FPGA, you'd be in the same situation.

Maybe there is some fake PHY you can instantiate -- the "Fixed"
MDIO bus maybe?  Can you try enabling CONFIG_FIXED_PHY and pointing
it to that?

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 07:36:07AM -0700, Gary Thomas wrote:
> 
>>>>>>> Also, can you show me what you're filling the dsa platform data
>>>>>>> structure with?
>>>>>> struct dsa_platform_data _switch_data = {
>>>>>>     .port_names[0]  = "lan1.1",
>>>>>>     .port_names[1]  = "lan1.2",
>>>>>>     .port_names[2]  = "lan1.3",
>>>>>>     .port_names[3]  = "lan1.4",
>>>>>>     .port_names[4]  = "lan1.5",
>>>>>>     .port_names[5]  = "lan1.6",
>>>>>>     .port_names[6]  = "lan1.7",
>>>>>>     .port_names[7]  = "lan1.8",
>>>>>>     .port_names[10]  = "cpu",
>>>>>>     .sw_addr = 1,
>>>>>> };
>>>>> Just this should do the trick.  So what's not working -- are the
>>>>> interfaces not showing up?  Or packet RX/TX isn't working?  Or
>>>>> something else?
>>>> It won't let me bring up eth0 (my scripts try to run DHCP):
>>>>   starting network interfaces...
>>>>   24520:01 not found
>>>>   eth0: Could not attach to PHY
>>>>   ip: SIOCSIFFLAGS: No such device
>>>>
>>>> As for the other devices, they do show up if I let eth0 try to
>>>> attach to the PHY:
>>> OK.  If you try to cheat the gianfar driver by having it attach to
>>> the PHY for lan1.1, and plug a network cable into lan1.1 so that the
>>> link goes up and gianfar thinks that the link on eth0 is up, does that
>>> enable you to pass packets over any of the switch interfaces?  That
>>> should be working now in this stage.
>> So, what name do I use when the gianfar is trying to attach?
>> It makes this call:
>>   phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface);
>> where phy_id="24520:01".
>>
>> Using "24520:01:00" gets an error:
>>   eth0: 24520:01:00 already attached
>>
>> Maybe the DSA layer/driver needs to export a device "24520:01"
>> which pretends all of the things that the gianfar wants (1000Mb/Full/Link)?
> 
> Well, this isn't DSA-specific -- e.g. if you'd hook your CPU's
> ethernet MAC up to an FPGA, you'd be in the same situation.
> 
> Maybe there is some fake PHY you can instantiate -- the "Fixed"
> MDIO bus maybe?  Can you try enabling CONFIG_FIXED_PHY and pointing
> it to that?

OK, I did that:
  Sending discover...
  PHY: 0:01 - Link is Up - 1000/Full

I now see the fixed PHY (pretender, configured at build time)
and the 8 LAN sockets:
  root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
  0:01         24520:01:01  24520:01:03  24520:01:05  24520:01:07
  24520:01:00  24520:01:02  24520:01:04  24520:01:06

But nothing seems to get through the switch.  Of course, I
know that the switch and connections are working because that's
the path I downloaded/booted the kernel from.

Getting closer :-) Any ideas?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 07:55:29AM -0700, Gary Thomas wrote:

> >>>>>>> Also, can you show me what you're filling the dsa platform data
> >>>>>>> structure with?
> >>>>>> struct dsa_platform_data _switch_data = {
> >>>>>>     .port_names[0]  = "lan1.1",
> >>>>>>     .port_names[1]  = "lan1.2",
> >>>>>>     .port_names[2]  = "lan1.3",
> >>>>>>     .port_names[3]  = "lan1.4",
> >>>>>>     .port_names[4]  = "lan1.5",
> >>>>>>     .port_names[5]  = "lan1.6",
> >>>>>>     .port_names[6]  = "lan1.7",
> >>>>>>     .port_names[7]  = "lan1.8",
> >>>>>>     .port_names[10]  = "cpu",
> >>>>>>     .sw_addr = 1,
> >>>>>> };
> >>>>> Just this should do the trick.  So what's not working -- are the
> >>>>> interfaces not showing up?  Or packet RX/TX isn't working?  Or
> >>>>> something else?
> >>>> It won't let me bring up eth0 (my scripts try to run DHCP):
> >>>>   starting network interfaces...
> >>>>   24520:01 not found
> >>>>   eth0: Could not attach to PHY
> >>>>   ip: SIOCSIFFLAGS: No such device
> >>>>
> >>>> As for the other devices, they do show up if I let eth0 try to
> >>>> attach to the PHY:
> >>> OK.  If you try to cheat the gianfar driver by having it attach to
> >>> the PHY for lan1.1, and plug a network cable into lan1.1 so that the
> >>> link goes up and gianfar thinks that the link on eth0 is up, does that
> >>> enable you to pass packets over any of the switch interfaces?  That
> >>> should be working now in this stage.
> >> So, what name do I use when the gianfar is trying to attach?
> >> It makes this call:
> >>   phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface);
> >> where phy_id="24520:01".
> >>
> >> Using "24520:01:00" gets an error:
> >>   eth0: 24520:01:00 already attached
> >>
> >> Maybe the DSA layer/driver needs to export a device "24520:01"
> >> which pretends all of the things that the gianfar wants (1000Mb/Full/Link)?
> > 
> > Well, this isn't DSA-specific -- e.g. if you'd hook your CPU's
> > ethernet MAC up to an FPGA, you'd be in the same situation.
> > 
> > Maybe there is some fake PHY you can instantiate -- the "Fixed"
> > MDIO bus maybe?  Can you try enabling CONFIG_FIXED_PHY and pointing
> > it to that?
> 
> OK, I did that:
>   Sending discover...
>   PHY: 0:01 - Link is Up - 1000/Full
> 
> I now see the fixed PHY (pretender, configured at build time)
> and the 8 LAN sockets:
>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
>   0:01         24520:01:01  24520:01:03  24520:01:05  24520:01:07
>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
> 
> But nothing seems to get through the switch.  Of course, I
> know that the switch and connections are working because that's
> the path I downloaded/booted the kernel from.
> 
> Getting closer :-) Any ideas?

:-)  Do you see messages in your syslog about the lan interfaces
being up, full duplex, etc?  Something a la (from one of my boards):

	lan1: link up, 1000 Mb/s, full duplex, flow control disabled
	lan2: link up, 1000 Mb/s, full duplex, flow control disabled

If yes, can you up the interfaces, and send some packets over them
and see if the TX counters on eth0 increase?  If yes, can you dump
the packets sent out over eth0 using tcpdump?

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 07:55:29AM -0700, Gary Thomas wrote:
> 
>>>>>>>>> Also, can you show me what you're filling the dsa platform data
>>>>>>>>> structure with?
>>>>>>>> struct dsa_platform_data _switch_data = {
>>>>>>>>     .port_names[0]  = "lan1.1",
>>>>>>>>     .port_names[1]  = "lan1.2",
>>>>>>>>     .port_names[2]  = "lan1.3",
>>>>>>>>     .port_names[3]  = "lan1.4",
>>>>>>>>     .port_names[4]  = "lan1.5",
>>>>>>>>     .port_names[5]  = "lan1.6",
>>>>>>>>     .port_names[6]  = "lan1.7",
>>>>>>>>     .port_names[7]  = "lan1.8",
>>>>>>>>     .port_names[10]  = "cpu",
>>>>>>>>     .sw_addr = 1,
>>>>>>>> };
>>>>>>> Just this should do the trick.  So what's not working -- are the
>>>>>>> interfaces not showing up?  Or packet RX/TX isn't working?  Or
>>>>>>> something else?
>>>>>> It won't let me bring up eth0 (my scripts try to run DHCP):
>>>>>>   starting network interfaces...
>>>>>>   24520:01 not found
>>>>>>   eth0: Could not attach to PHY
>>>>>>   ip: SIOCSIFFLAGS: No such device
>>>>>>
>>>>>> As for the other devices, they do show up if I let eth0 try to
>>>>>> attach to the PHY:
>>>>> OK.  If you try to cheat the gianfar driver by having it attach to
>>>>> the PHY for lan1.1, and plug a network cable into lan1.1 so that the
>>>>> link goes up and gianfar thinks that the link on eth0 is up, does that
>>>>> enable you to pass packets over any of the switch interfaces?  That
>>>>> should be working now in this stage.
>>>> So, what name do I use when the gianfar is trying to attach?
>>>> It makes this call:
>>>>   phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface);
>>>> where phy_id="24520:01".
>>>>
>>>> Using "24520:01:00" gets an error:
>>>>   eth0: 24520:01:00 already attached
>>>>
>>>> Maybe the DSA layer/driver needs to export a device "24520:01"
>>>> which pretends all of the things that the gianfar wants (1000Mb/Full/Link)?
>>> Well, this isn't DSA-specific -- e.g. if you'd hook your CPU's
>>> ethernet MAC up to an FPGA, you'd be in the same situation.
>>>
>>> Maybe there is some fake PHY you can instantiate -- the "Fixed"
>>> MDIO bus maybe?  Can you try enabling CONFIG_FIXED_PHY and pointing
>>> it to that?
>> OK, I did that:
>>   Sending discover...
>>   PHY: 0:01 - Link is Up - 1000/Full
>>
>> I now see the fixed PHY (pretender, configured at build time)
>> and the 8 LAN sockets:
>>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
>>   0:01         24520:01:01  24520:01:03  24520:01:05  24520:01:07
>>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
>>
>> But nothing seems to get through the switch.  Of course, I
>> know that the switch and connections are working because that's
>> the path I downloaded/booted the kernel from.
>>
>> Getting closer :-) Any ideas?
> 
> :-)  Do you see messages in your syslog about the lan interfaces
> being up, full duplex, etc?  Something a la (from one of my boards):
> 
> 	lan1: link up, 1000 Mb/s, full duplex, flow control disabled
> 	lan2: link up, 1000 Mb/s, full duplex, flow control disabled

This does seem to work:
  root@ppc_target:~ ifconfig lan1.1 up
  root@ppc_target:~ lan1.1: link up, 100 Mb/s, full duplex, flow control disabled

When I try it on other ports:
  root@ppc_target:~ ifconfig lan1.2 up
  root@ppc_target:~ ifconfig lan1.3 up
Those ports aren't plugged (and I'm 6000 miles from them, literally,
so I can't change that)

> If yes, can you up the interfaces, and send some packets over them
> and see if the TX counters on eth0 increase?  If yes, can you dump
> the packets sent out over eth0 using tcpdump?

I tried to ping out and into the box.  Nothing seems to go anywhere:

root@ppc_target:~ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1810 (1.7 KiB)
          Base address:0x6000

lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Running tcpdump on the external network (192.168.12.x), I saw
no activity.

Do I need to do anything more than "ifconfig lan1.1 up"?
Maybe the "." is confusing things?  I was just trying to
look ahead when I have 3 switches running.

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 08:08:22AM -0700, Gary Thomas wrote:

> >> OK, I did that:
> >>   Sending discover...
> >>   PHY: 0:01 - Link is Up - 1000/Full
> >>
> >> I now see the fixed PHY (pretender, configured at build time)
> >> and the 8 LAN sockets:
> >>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
> >>   0:01         24520:01:01  24520:01:03  24520:01:05  24520:01:07
> >>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
> >>
> >> But nothing seems to get through the switch.  Of course, I
> >> know that the switch and connections are working because that's
> >> the path I downloaded/booted the kernel from.
> >>
> >> Getting closer :-) Any ideas?
> > 
> > :-)  Do you see messages in your syslog about the lan interfaces
> > being up, full duplex, etc?  Something a la (from one of my boards):
> > 
> > 	lan1: link up, 1000 Mb/s, full duplex, flow control disabled
> > 	lan2: link up, 1000 Mb/s, full duplex, flow control disabled
> 
> This does seem to work:
>   root@ppc_target:~ ifconfig lan1.1 up
>   root@ppc_target:~ lan1.1: link up, 100 Mb/s, full duplex, flow control disabled
> 
> When I try it on other ports:
>   root@ppc_target:~ ifconfig lan1.2 up
>   root@ppc_target:~ ifconfig lan1.3 up
> Those ports aren't plugged (and I'm 6000 miles from them, literally,
> so I can't change that)

OK, that makes sense then.


> > If yes, can you up the interfaces, and send some packets over them
> > and see if the TX counters on eth0 increase?  If yes, can you dump
> > the packets sent out over eth0 using tcpdump?
> 
> I tried to ping out and into the box.  Nothing seems to go anywhere:
> 
> root@ppc_target:~ ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:1810 (1.7 KiB)
>           Base address:0x6000
> 
> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> 
> Running tcpdump on the external network (192.168.12.x), I saw
> no activity.
>
> Do I need to do anything more than "ifconfig lan1.1 up"?

IP addresses should be attached to the lanX.X interfaces, not to eth0
-- eth0 will only be carrying specially tagged (DSA/EDSA) packets.
So you should move the IP address to lan1.1.

Can you trying pinging via lan1.1 and then seeing if there are
packets transmitted out over eth0, and dump those packets with tcpdump?


> Maybe the "." is confusing things?  I was just trying to
> look ahead when I have 3 switches running.

That shouldn't be causing trouble as far as I can see.

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 08:08:22AM -0700, Gary Thomas wrote:
> 
>>>> OK, I did that:
>>>>   Sending discover...
>>>>   PHY: 0:01 - Link is Up - 1000/Full
>>>>
>>>> I now see the fixed PHY (pretender, configured at build time)
>>>> and the 8 LAN sockets:
>>>>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
>>>>   0:01         24520:01:01  24520:01:03  24520:01:05  24520:01:07
>>>>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
>>>>
>>>> But nothing seems to get through the switch.  Of course, I
>>>> know that the switch and connections are working because that's
>>>> the path I downloaded/booted the kernel from.
>>>>
>>>> Getting closer :-) Any ideas?
>>> :-)  Do you see messages in your syslog about the lan interfaces
>>> being up, full duplex, etc?  Something a la (from one of my boards):
>>>
>>> 	lan1: link up, 1000 Mb/s, full duplex, flow control disabled
>>> 	lan2: link up, 1000 Mb/s, full duplex, flow control disabled
>> This does seem to work:
>>   root@ppc_target:~ ifconfig lan1.1 up
>>   root@ppc_target:~ lan1.1: link up, 100 Mb/s, full duplex, flow control disabled
>>
>> When I try it on other ports:
>>   root@ppc_target:~ ifconfig lan1.2 up
>>   root@ppc_target:~ ifconfig lan1.3 up
>> Those ports aren't plugged (and I'm 6000 miles from them, literally,
>> so I can't change that)
> 
> OK, that makes sense then.
> 
> 
>>> If yes, can you up the interfaces, and send some packets over them
>>> and see if the TX counters on eth0 increase?  If yes, can you dump
>>> the packets sent out over eth0 using tcpdump?
>> I tried to ping out and into the box.  Nothing seems to go anywhere:
>>
>> root@ppc_target:~ ifconfig
>> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:1000
>>           RX bytes:0 (0.0 B)  TX bytes:1810 (1.7 KiB)
>>           Base address:0x6000
>>
>> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:0
>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>
>> Running tcpdump on the external network (192.168.12.x), I saw
>> no activity.
>>
>> Do I need to do anything more than "ifconfig lan1.1 up"?
> 
> IP addresses should be attached to the lanX.X interfaces, not to eth0
> -- eth0 will only be carrying specially tagged (DSA/EDSA) packets.
> So you should move the IP address to lan1.1.
> 
> Can you trying pinging via lan1.1 and then seeing if there are
> packets transmitted out over eth0, and dump those packets with tcpdump?
> 

It looks like the packets are going out, but I don't see anything
on the wire.  After a few ping attempts:

root@ppc_target:~ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:2974 (2.9 KiB)
          Base address:0x6000

lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:1638 (1.5 KiB)

The eth0 and lan1.1 counters are going up at more or less the
same rate.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 08:25:58AM -0700, Gary Thomas wrote:

> >>> If yes, can you up the interfaces, and send some packets over them
> >>> and see if the TX counters on eth0 increase?  If yes, can you dump
> >>> the packets sent out over eth0 using tcpdump?
> >> I tried to ping out and into the box.  Nothing seems to go anywhere:
> >>
> >> root@ppc_target:~ ifconfig
> >> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
> >>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
> >>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >>           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
> >>           collisions:0 txqueuelen:1000
> >>           RX bytes:0 (0.0 B)  TX bytes:1810 (1.7 KiB)
> >>           Base address:0x6000
> >>
> >> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
> >>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> >>           collisions:0 txqueuelen:0
> >>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> >>
> >> Running tcpdump on the external network (192.168.12.x), I saw
> >> no activity.
> >>
> >> Do I need to do anything more than "ifconfig lan1.1 up"?
> > 
> > IP addresses should be attached to the lanX.X interfaces, not to eth0
> > -- eth0 will only be carrying specially tagged (DSA/EDSA) packets.
> > So you should move the IP address to lan1.1.
> > 
> > Can you trying pinging via lan1.1 and then seeing if there are
> > packets transmitted out over eth0, and dump those packets with tcpdump?
> 
> It looks like the packets are going out, but I don't see anything
> on the wire.  After a few ping attempts:
> 
> root@ppc_target:~ ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:2974 (2.9 KiB)
>           Base address:0x6000
> 
> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 B)  TX bytes:1638 (1.5 KiB)
> 
> The eth0 and lan1.1 counters are going up at more or less the
> same rate.

Can you run tcpdump on eth0 to see what the packets look like?

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 08:25:58AM -0700, Gary Thomas wrote:
> 
>>>>> If yes, can you up the interfaces, and send some packets over them
>>>>> and see if the TX counters on eth0 increase?  If yes, can you dump
>>>>> the packets sent out over eth0 using tcpdump?
>>>> I tried to ping out and into the box.  Nothing seems to go anywhere:
>>>>
>>>> root@ppc_target:~ ifconfig
>>>> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>>>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
>>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>>           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
>>>>           collisions:0 txqueuelen:1000
>>>>           RX bytes:0 (0.0 B)  TX bytes:1810 (1.7 KiB)
>>>>           Base address:0x6000
>>>>
>>>> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>>>           collisions:0 txqueuelen:0
>>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>>>
>>>> Running tcpdump on the external network (192.168.12.x), I saw
>>>> no activity.
>>>>
>>>> Do I need to do anything more than "ifconfig lan1.1 up"?
>>> IP addresses should be attached to the lanX.X interfaces, not to eth0
>>> -- eth0 will only be carrying specially tagged (DSA/EDSA) packets.
>>> So you should move the IP address to lan1.1.
>>>
>>> Can you trying pinging via lan1.1 and then seeing if there are
>>> packets transmitted out over eth0, and dump those packets with tcpdump?
>> It looks like the packets are going out, but I don't see anything
>> on the wire.  After a few ping attempts:
>>
>> root@ppc_target:~ ifconfig
>> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>           TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:1000
>>           RX bytes:0 (0.0 B)  TX bytes:2974 (2.9 KiB)
>>           Base address:0x6000
>>
>> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>           TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:0
>>           RX bytes:0 (0.0 B)  TX bytes:1638 (1.5 KiB)
>>
>> The eth0 and lan1.1 counters are going up at more or less the
>> same rate.
> 
> Can you run tcpdump on eth0 to see what the packets look like?

Locally (on the board with the switch)?  That will take a while to
set up as it's a 100% embedded system, runs from FLASH, etc.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 08:29:09AM -0700, Gary Thomas wrote:

> >>>>> If yes, can you up the interfaces, and send some packets over them
> >>>>> and see if the TX counters on eth0 increase?  If yes, can you dump
> >>>>> the packets sent out over eth0 using tcpdump?
> >>>> I tried to ping out and into the box.  Nothing seems to go anywhere:
> >>>>
> >>>> root@ppc_target:~ ifconfig
> >>>> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
> >>>>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
> >>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >>>>           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
> >>>>           collisions:0 txqueuelen:1000
> >>>>           RX bytes:0 (0.0 B)  TX bytes:1810 (1.7 KiB)
> >>>>           Base address:0x6000
> >>>>
> >>>> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
> >>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> >>>>           collisions:0 txqueuelen:0
> >>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> >>>>
> >>>> Running tcpdump on the external network (192.168.12.x), I saw
> >>>> no activity.
> >>>>
> >>>> Do I need to do anything more than "ifconfig lan1.1 up"?
> >>> IP addresses should be attached to the lanX.X interfaces, not to eth0
> >>> -- eth0 will only be carrying specially tagged (DSA/EDSA) packets.
> >>> So you should move the IP address to lan1.1.
> >>>
> >>> Can you trying pinging via lan1.1 and then seeing if there are
> >>> packets transmitted out over eth0, and dump those packets with tcpdump?
> >> It looks like the packets are going out, but I don't see anything
> >> on the wire.  After a few ping attempts:
> >>
> >> root@ppc_target:~ ifconfig
> >> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
> >>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >>           TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
> >>           collisions:0 txqueuelen:1000
> >>           RX bytes:0 (0.0 B)  TX bytes:2974 (2.9 KiB)
> >>           Base address:0x6000
> >>
> >> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
> >>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
> >>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >>           TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
> >>           collisions:0 txqueuelen:0
> >>           RX bytes:0 (0.0 B)  TX bytes:1638 (1.5 KiB)
> >>
> >> The eth0 and lan1.1 counters are going up at more or less the
> >> same rate.
> > 
> > Can you run tcpdump on eth0 to see what the packets look like?
> 
> Locally (on the board with the switch)?  That will take a while to
> set up as it's a 100% embedded system, runs from FLASH, etc.

OK, do you have ethtool then?  If yes, can you run ethtool on the
lan1.1 interface to see if any of the hardware (switch chip) TX
counters are increasing?

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 08:29:09AM -0700, Gary Thomas wrote:
> 
>>>>>>> If yes, can you up the interfaces, and send some packets over them
>>>>>>> and see if the TX counters on eth0 increase?  If yes, can you dump
>>>>>>> the packets sent out over eth0 using tcpdump?
>>>>>> I tried to ping out and into the box.  Nothing seems to go anywhere:
>>>>>>
>>>>>> root@ppc_target:~ ifconfig
>>>>>> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>>>>>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
>>>>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>>>>           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
>>>>>>           collisions:0 txqueuelen:1000
>>>>>>           RX bytes:0 (0.0 B)  TX bytes:1810 (1.7 KiB)
>>>>>>           Base address:0x6000
>>>>>>
>>>>>> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>>>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>>>>>           collisions:0 txqueuelen:0
>>>>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>>>>>
>>>>>> Running tcpdump on the external network (192.168.12.x), I saw
>>>>>> no activity.
>>>>>>
>>>>>> Do I need to do anything more than "ifconfig lan1.1 up"?
>>>>> IP addresses should be attached to the lanX.X interfaces, not to eth0
>>>>> -- eth0 will only be carrying specially tagged (DSA/EDSA) packets.
>>>>> So you should move the IP address to lan1.1.
>>>>>
>>>>> Can you trying pinging via lan1.1 and then seeing if there are
>>>>> packets transmitted out over eth0, and dump those packets with tcpdump?
>>>> It looks like the packets are going out, but I don't see anything
>>>> on the wire.  After a few ping attempts:
>>>>
>>>> root@ppc_target:~ ifconfig
>>>> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>>           TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
>>>>           collisions:0 txqueuelen:1000
>>>>           RX bytes:0 (0.0 B)  TX bytes:2974 (2.9 KiB)
>>>>           Base address:0x6000
>>>>
>>>> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
>>>>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
>>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>>>           TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
>>>>           collisions:0 txqueuelen:0
>>>>           RX bytes:0 (0.0 B)  TX bytes:1638 (1.5 KiB)
>>>>
>>>> The eth0 and lan1.1 counters are going up at more or less the
>>>> same rate.
>>> Can you run tcpdump on eth0 to see what the packets look like?
>> Locally (on the board with the switch)?  That will take a while to
>> set up as it's a 100% embedded system, runs from FLASH, etc.

Here's the result of 'tcpdump -i eth0' while pinging:

PING 192.168.12.18 (192.168.12.18): 56 data bytes
15:52:34.718207 00:1d:11:81:00:00 (oui Unknown) > Broadcast, ethertype Unknown (0x4000), length 46:
        0x0000:  0000 0806 0001 0800 0604 0001 001d 1181  ................
        0x0010:  0000 c0a8 0ca8 0000 0000 0000 c0a8 0c12  ................
15:52:35.717893 00:1d:11:81:00:00 (oui Unknown) > Broadcast, ethertype Unknown (0x4000), length 46:
        0x0000:  0000 0806 0001 0800 0604 0001 001d 1181  ................
        0x0010:  0000 c0a8 0ca8 0000 0000 0000 c0a8 0c12  ................

I also tried pinging in from the outside, but didn't see any
packets.  I would assume that I'd see at least broadcast/ARP
packets.

> OK, do you have ethtool then?  If yes, can you run ethtool on the
> lan1.1 interface to see if any of the hardware (switch chip) TX
> counters are increasing?

I'm not familiar with that tool (I did install it).  What
option (of the *many*) are you interested in?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 08:44:53AM -0700, Gary Thomas wrote:

> >>>>> IP addresses should be attached to the lanX.X interfaces, not to eth0
> >>>>> -- eth0 will only be carrying specially tagged (DSA/EDSA) packets.
> >>>>> So you should move the IP address to lan1.1.
> >>>>>
> >>>>> Can you trying pinging via lan1.1 and then seeing if there are
> >>>>> packets transmitted out over eth0, and dump those packets with tcpdump?
> >>>> It looks like the packets are going out, but I don't see anything
> >>>> on the wire.  After a few ping attempts:
> >>>>
> >>>> root@ppc_target:~ ifconfig
> >>>> eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
> >>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >>>>           TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
> >>>>           collisions:0 txqueuelen:1000
> >>>>           RX bytes:0 (0.0 B)  TX bytes:2974 (2.9 KiB)
> >>>>           Base address:0x6000
> >>>>
> >>>> lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
> >>>>           inet addr:192.168.12.189  Bcast:192.168.12.255  Mask:255.255.255.0
> >>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >>>>           TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
> >>>>           collisions:0 txqueuelen:0
> >>>>           RX bytes:0 (0.0 B)  TX bytes:1638 (1.5 KiB)
> >>>>
> >>>> The eth0 and lan1.1 counters are going up at more or less the
> >>>> same rate.
> >>> Can you run tcpdump on eth0 to see what the packets look like?
> >> Locally (on the board with the switch)?  That will take a while to
> >> set up as it's a 100% embedded system, runs from FLASH, etc.
> 
> Here's the result of 'tcpdump -i eth0' while pinging:
> 
> PING 192.168.12.18 (192.168.12.18): 56 data bytes
> 15:52:34.718207 00:1d:11:81:00:00 (oui Unknown) > Broadcast, ethertype Unknown (0x4000), length 46:
>         0x0000:  0000 0806 0001 0800 0604 0001 001d 1181  ................
>         0x0010:  0000 c0a8 0ca8 0000 0000 0000 c0a8 0c12  ................
> 15:52:35.717893 00:1d:11:81:00:00 (oui Unknown) > Broadcast, ethertype Unknown (0x4000), length 46:
>         0x0000:  0000 0806 0001 0800 0604 0001 001d 1181  ................
>         0x0010:  0000 c0a8 0ca8 0000 0000 0000 c0a8 0c12  ................
> 
> I also tried pinging in from the outside, but didn't see any
> packets.  I would assume that I'd see at least broadcast/ARP
> packets.

Can you dump the entire packet (-s 2000) including the ethernet
headers and all (-eeexxxvvvnnn or so)?


> > OK, do you have ethtool then?  If yes, can you run ethtool on the
> > lan1.1 interface to see if any of the hardware (switch chip) TX
> > counters are increasing?
> 
> I'm not familiar with that tool (I did install it).  What
> option (of the *many*) are you interested in?

"ethtool -S lan1.1", please.

Perhaps we should take this off-list..

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Fri, 27 Feb 2009, Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 08:44:53AM -0700, Gary Thomas wrote:
>
> Perhaps we should take this off-list..

I'm still interrested... please Cc. me at jdb@comx.dk.

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 10:12:52PM +0100, Jesper Dangaard Brouer wrote:

> >Perhaps we should take this off-list..
> 
> I'm still interrested... please Cc. me at jdb@comx.dk.

The main conclusion so far is that this write (net/dsa/mv88e6131.c):

	/*
	 * MAC Forcing register: don't force link, speed, duplex
	 * or flow control state to any particular values.
	 */
	REG_WRITE(addr, 0x01, 0x0003);

isn't correct on ports that can either be CPU ports or external ports.
Forcing the link up on the CPU port helps somewhat, but things aren't
100% working yet.

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

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

On Fri, 2009-02-27 at 23:28 +0100, Lennert Buytenhek wrote:

> The main conclusion so far is that this write (net/dsa/mv88e6131.c):
> 
> 	/*
> 	 * MAC Forcing register: don't force link, speed, duplex
> 	 * or flow control state to any particular values.
> 	 */
>	REG_WRITE(addr, 0x01, 0x0003);

This sort of enables auto-detection of speed.

> isn't correct on ports that can either be CPU ports or external ports.

For external ports I had to enabled the PPU to allow the external PHYs
to negotiate.

Also, on external PHYs ports 8 and 9, I write 0x0403 not 0x0003 (to
register 0x1, PCS Control Register).  Which also enables inband
auto-negotiation, but I'm not sure this is necessary.


> Forcing the link up on the CPU port helps somewhat, but things aren't
> 100% working yet.

On the CPU port I force link-up and force speed+duplex setting.  I only
got 100Mbit/s to the CPU port...

/* CPU Port 10: Force 100Mbit Full-Duplex */
REG_WRITE( 0x1A , 0x01 , 0x003D );

You should write 0x003E ... see attached patch

-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer

[-- Attachment #2: test01 --]
[-- Type: text/plain, Size: 844 bytes --]

On CPU port, Force 1000Mbit/s Full-duplex and link-up.


---

 net/dsa/mv88e6131.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)


diff --git a/net/dsa/mv88e6131.c b/net/dsa/mv88e6131.c
index 374d46a..400473a 100644
--- a/net/dsa/mv88e6131.c
+++ b/net/dsa/mv88e6131.c
@@ -159,9 +159,13 @@ static int mv88e6131_setup_port(struct dsa_switch *ds, int p)
 
 	/*
 	 * MAC Forcing register: don't force link, speed, duplex
-	 * or flow control state to any particular values.
+	 * or flow control state to any particular values.  Unless
+	 * this is the CPU port, then force 1Gb/s and link-up.
 	 */
-	REG_WRITE(addr, 0x01, 0x0003);
+	if ((p == ds->cpu_port))
+		REG_WRITE(addr, 0x01, 0x003E);
+	else
+		REG_WRITE(addr, 0x01, 0x0003);
 
 	/*
 	 * Port Control: disable Core Tag, disable Drop-on-Lock,

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:

> You should write 0x003E ... see attached patch

Ups, I see (from the thread) that you have already done/tried this...

-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer

Re: Marvell 88E609x switch?

[Gary Thomas]

Jesper Dangaard Brouer wrote:
> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
> 
>> You should write 0x003E ... see attached patch
> 
> Ups, I see (from the thread) that you have already done/tried this...
> 

Yes, although I think it will need some work in the future
(I've set it to 1000Mb connection, you said you used 100Mb, etc)

Question: I'm testing this by trying a ping out of my box.
Linux replies by sending an ARP packet out, and the destination
replies with an ARP packet in.  I can see from the ethtool stats
that the reply packets get into lan1.1 (the physical port I'm
using), but I don't see them get moved through the CPU port.
My understanding is that this should work via the VLAN map?
I checked that setup and it looks OK.

Any ideas where this might be going wrong?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

Gary Thomas wrote:
> Jesper Dangaard Brouer wrote:
>> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
>>
>>> You should write 0x003E ... see attached patch
>> Ups, I see (from the thread) that you have already done/tried this...
>>
> 
> Yes, although I think it will need some work in the future
> (I've set it to 1000Mb connection, you said you used 100Mb, etc)
> 
> Question: I'm testing this by trying a ping out of my box.
> Linux replies by sending an ARP packet out, and the destination
> replies with an ARP packet in.  I can see from the ethtool stats
> that the reply packets get into lan1.1 (the physical port I'm
> using), but I don't see them get moved through the CPU port.
> My understanding is that this should work via the VLAN map?
> I checked that setup and it looks OK.
> 
> Any ideas where this might be going wrong?

I also just noticed that the ESA registers (Global 1,2,3)
aren't set at all.  I'm pretty sure that the way I'm using
the switch in my bootloader this doesn't matter as all packets
have a fixed routing and the ESA recognition happens at the
actual ethernet device.

Is this going to cause problems with the VLAN (+DSA) based
routing?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Mon, 2 Mar 2009, Gary Thomas wrote:

> Gary Thomas wrote:
>> Jesper Dangaard Brouer wrote:
>>> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
>>>
>>>> You should write 0x003E ... see attached patch
>>> Ups, I see (from the thread) that you have already done/tried this...
>>>
>>
>> Yes, although I think it will need some work in the future
>> (I've set it to 1000Mb connection, you said you used 100Mb, etc)
>>
>> Question: I'm testing this by trying a ping out of my box.
>> Linux replies by sending an ARP packet out, and the destination
>> replies with an ARP packet in.  I can see from the ethtool stats
>> that the reply packets get into lan1.1 (the physical port I'm
>> using), but I don't see them get moved through the CPU port.

Well, thats a break through :-) If I understand you correctly, the 
destination host actually receives the ARP packet and responds with a 
packet.

That should means that the outgoing DSA tagging is working.  Although I'm 
not sure about the incomming...

>> My understanding is that this should work via the VLAN map?

I think that the "VLAN map/table" has gotten a wrong name as it does not 
really determine the VLANs, it only says who can talk to whom.  The switch 
does support a real vlan setup, but its deactivated in Lennerts driver, as 
I guess he wants Linux to handle the VLANs.  (I use the real VLAN setup 
extensively in my driver).

>> I checked that setup and it looks OK.

I have also checked the different registers setting, and things looks 
quite alright.  Although I'm missing the register datasheets for the 6131 
chip, I found that I only have part 1 of 3 crap...

I did find that the 6095 and 6097 does differ in the way DSA handling is 
done, as the 6097 supports Ethertype DSA and 6095 don't.  But the 6131 
driver looks like it does the right thing for the 6095.


>> Any ideas where this might be going wrong?

Is lan1.1 up and have you given it an IP address?
(could I get a 'ifconfig' output?)

Are you sending packets with VLAN tags?


> I also just noticed that the ESA registers (Global 1,2,3)
> aren't set at all.  I'm pretty sure that the way I'm using
> the switch in my bootloader this doesn't matter as all packets
> have a fixed routing and the ESA recognition happens at the
> actual ethernet device.

Don't think the switch needs a MAC address...

> Is this going to cause problems with the VLAN (+DSA) based
> routing?

Don't think so...

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

Jesper Dangaard Brouer wrote:
> 
> 
> 
> On Mon, 2 Mar 2009, Gary Thomas wrote:
> 
>> Gary Thomas wrote:
>>> Jesper Dangaard Brouer wrote:
>>>> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
>>>>
>>>>> You should write 0x003E ... see attached patch
>>>> Ups, I see (from the thread) that you have already done/tried this...
>>>>
>>>
>>> Yes, although I think it will need some work in the future
>>> (I've set it to 1000Mb connection, you said you used 100Mb, etc)
>>>
>>> Question: I'm testing this by trying a ping out of my box.
>>> Linux replies by sending an ARP packet out, and the destination
>>> replies with an ARP packet in.  I can see from the ethtool stats
>>> that the reply packets get into lan1.1 (the physical port I'm
>>> using), but I don't see them get moved through the CPU port.
> 
> Well, thats a break through :-) If I understand you correctly, the
> destination host actually receives the ARP packet and responds with a
> packet.
> 
> That should means that the outgoing DSA tagging is working.  Although
> I'm not sure about the incomming...
> 
>>> My understanding is that this should work via the VLAN map?
> 
> I think that the "VLAN map/table" has gotten a wrong name as it does not
> really determine the VLANs, it only says who can talk to whom.  The
> switch does support a real vlan setup, but its deactivated in Lennerts
> driver, as I guess he wants Linux to handle the VLANs.  (I use the real
> VLAN setup extensively in my driver).

I agree that the simple mode Lennert's code uses is not VLAN on
the hardware, just internal switch path routes.

>>> I checked that setup and it looks OK.
> 
> I have also checked the different registers setting, and things looks
> quite alright.  Although I'm missing the register datasheets for the
> 6131 chip, I found that I only have part 1 of 3 crap...
> 
> I did find that the 6095 and 6097 does differ in the way DSA handling is
> done, as the 6097 supports Ethertype DSA and 6095 don't.  But the 6131
> driver looks like it does the right thing for the 6095.

I didn't look at the 6097 yet, but I have scoured the 6095 and 6131
data sheets and I can't see what's wrong.  The differences between
these two parts are extremely minor - basically the number of ports
and which one might be used for the CPU.

> 
>>> Any ideas where this might be going wrong?
> 
> Is lan1.1 up and have you given it an IP address?
> (could I get a 'ifconfig' output?)

Yes it's up.

> Are you sending packets with VLAN tags?

No VLAN tagging (by Linux), just normal IPv4 packets. Here's what I did:

root@ppc_target:~ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1180 (1.1 KiB)  TX bytes:1180 (1.1 KiB)
          Base address:0x6000

root@ppc_target:~ ifconfig lan1.1 192.168.12.188 up
root@ppc_target:~ lan1.1: link up, 100 Mb/s, full duplex, flow control disabled

root@ppc_target:~ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1180 (1.1 KiB)  TX bytes:1180 (1.1 KiB)
          Base address:0x6000

lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          inet addr:192.168.12.188  Bcast:192.168.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@ppc_target:~ ethtool -S lan1.1
NIC statistics:
     tx_packets: 0
     tx_bytes: 0
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 2096784
     in_bad_octets: 0
     in_unicast: 3601
     in_broadcasts: 528
     in_multicasts: 70
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 230866
     out_unicast: 3595
     out_broadcasts: 3
     out_multicasts: 0
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 3705
     hist_65_127bytes: 326
     hist_128_255bytes: 159
     hist_256_511bytes: 15
     hist_512_1023bytes: 3592
     hist_1024_max_bytes: 0
root@ppc_target:~ ethtool -S lan1.8
mv88e6131_get_ethtool_stats(7) => CPU
NIC statistics:
     tx_packets: 0
     tx_bytes: 0
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 232054
     in_bad_octets: 0
     in_unicast: 3595
     in_broadcasts: 5
     in_multicasts: 0
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 2021576
     out_unicast: 3599
     out_broadcasts: 9
     out_multicasts: 1
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 3600
     hist_65_127bytes: 9
     hist_128_255bytes: 0
     hist_256_511bytes: 4
     hist_512_1023bytes: 3596
     hist_1024_max_bytes: 0
root@ppc_target:~ ping -c 5 192.168.12.18
PING 192.168.12.18 (192.168.12.18): 56 data bytes

--- 192.168.12.18 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
root@ppc_target:~ ifconfig lan1.1
lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          inet addr:192.168.12.188  Bcast:192.168.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:252 (252.0 B)

root@ppc_target:~ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1180 (1.1 KiB)  TX bytes:1456 (1.4 KiB)
          Base address:0x6000

root@ppc_target:~ ethtool -S lan1.1
NIC statistics:
     tx_packets: 6
     tx_bytes: 252
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 2099816
     in_bad_octets: 0
     in_unicast: 3607
     in_broadcasts: 542
     in_multicasts: 71
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 231250
     out_unicast: 3595
     out_broadcasts: 9
     out_multicasts: 0
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 3718
     hist_65_127bytes: 331
     hist_128_255bytes: 168
     hist_256_511bytes: 15
     hist_512_1023bytes: 3592
     hist_1024_max_bytes: 0
root@ppc_target:~ ethtool -S lan1.8
mv88e6131_get_ethtool_stats(7) => CPU
NIC statistics:
     tx_packets: 0
     tx_bytes: 0
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 232438
     in_bad_octets: 0
     in_unicast: 3595
     in_broadcasts: 11
     in_multicasts: 0
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 2021576
     out_unicast: 3599
     out_broadcasts: 9
     out_multicasts: 1
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 3606
     hist_65_127bytes: 9
     hist_128_255bytes: 0
     hist_256_511bytes: 4
     hist_512_1023bytes: 3596
     hist_1024_max_bytes: 0

You can see that lan1.1 "in_unicast" changed by 6 packets.  These
correspond to the ARP reply packets I see the destination host
(192.168.12.18) send out.

> 
>> I also just noticed that the ESA registers (Global 1,2,3)
>> aren't set at all.  I'm pretty sure that the way I'm using
>> the switch in my bootloader this doesn't matter as all packets
>> have a fixed routing and the ESA recognition happens at the
>> actual ethernet device.
> 
> Don't think the switch needs a MAC address...
> 
>> Is this going to cause problems with the VLAN (+DSA) based
>> routing?
> 
> Don't think so...

I added in the correct ESA on the switch and the lan1.1
incoming counters now track the unicode packets.  Since I
still can't get them through to the CPU port, I don't
know if this was important.

Any ideas how I might troubleshoot why packets that come
into lan1.1 (port 0) aren't being pushed to the CPU port?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
> Any ideas how I might troubleshoot why packets that come
> into lan1.1 (port 0) aren't being pushed to the CPU port?

The switch supports port monitoring, with seperate ingress and egress
mapping, thus you could place another PC on another port and direct
traffic towards that, and by tcpdump inspecting ingress and egress on
the different physical ports... Thats how I debugged it once...

I also used/implemented the VLAN violation interrupt, while I debugged
the VLAN setup.   The switch also have a ATU (MAC-table) violation
interrupt, perhaps that might tell you something?

-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Tue, 2009-03-03 at 09:52 +0100, Jesper Dangaard Brouer wrote:
> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
> > Any ideas how I might troubleshoot why packets that come
> > into lan1.1 (port 0) aren't being pushed to the CPU port?
> 
> The switch supports port monitoring, with seperate ingress and egress
> mapping, thus you could place another PC on another port and direct
> traffic towards that, and by tcpdump inspecting ingress and egress on
> the different physical ports... Thats how I debugged it once...
> 
> I also used/implemented the VLAN violation interrupt, while I debugged
> the VLAN setup.   The switch also have a ATU (MAC-table) violation
> interrupt, perhaps that might tell you something?

Another thing... An IXP425 specific change I had to make, was to disable
NPE_learning for the ixp400_eth driver.

 insmod ixp400_eth npe_learning=0

MODULE_PARM_DESC(npe_learning, "If non-zero, NPE MAC Address Learning &
Filtering feature will be enabled");

Perhaps the GIANFAR driver also has this kind of MAC address filtering?

-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer

Re: Marvell 88E609x switch?

[Gary Thomas]

Jesper Dangaard Brouer wrote:
> On Tue, 2009-03-03 at 09:52 +0100, Jesper Dangaard Brouer wrote:
>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>> Any ideas how I might troubleshoot why packets that come
>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>> The switch supports port monitoring, with seperate ingress and egress
>> mapping, thus you could place another PC on another port and direct
>> traffic towards that, and by tcpdump inspecting ingress and egress on
>> the different physical ports... Thats how I debugged it once...
>>
>> I also used/implemented the VLAN violation interrupt, while I debugged
>> the VLAN setup.   The switch also have a ATU (MAC-table) violation
>> interrupt, perhaps that might tell you something?
> 
> Another thing... An IXP425 specific change I had to make, was to disable
> NPE_learning for the ixp400_eth driver.
> 
>  insmod ixp400_eth npe_learning=0
> 
> MODULE_PARM_DESC(npe_learning, "If non-zero, NPE MAC Address Learning &
> Filtering feature will be enabled");
> 
> Perhaps the GIANFAR driver also has this kind of MAC address filtering?
> 

I don't think this is a problem; no packets are getting
[back] to the gianfar interface (based on RX interrupt counts)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

Jesper Dangaard Brouer wrote:
> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>> Any ideas how I might troubleshoot why packets that come
>> into lan1.1 (port 0) aren't being pushed to the CPU port?
> 
> The switch supports port monitoring, with seperate ingress and egress
> mapping, thus you could place another PC on another port and direct
> traffic towards that, and by tcpdump inspecting ingress and egress on
> the different physical ports... Thats how I debugged it once...

I'm a bit fuzzy on this - could you explain in a bit more detail?

> I also used/implemented the VLAN violation interrupt, while I debugged
> the VLAN setup.   The switch also have a ATU (MAC-table) violation
> interrupt, perhaps that might tell you something?
> 

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
> Jesper Dangaard Brouer wrote:
> > On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
> >> Any ideas how I might troubleshoot why packets that come
> >> into lan1.1 (port 0) aren't being pushed to the CPU port?
> > 
> > The switch supports port monitoring, with seperate ingress and egress
> > mapping, thus you could place another PC on another port and direct
> > traffic towards that, and by tcpdump inspecting ingress and egress on
> > the different physical ports... Thats how I debugged it once...
> 
> I'm a bit fuzzy on this - could you explain in a bit more detail?

You basically set the monitor destination port via REG_GLOBAL reg 0x1A
"Monitor Control".

/* Register: Monitor Control (0x1A)
   -------------------------
    bit 15:12= Ingress Monitor Dest
    bit 11:8 = Egress  Monitor Dest
    bit  7:4 = ARP Dest
    bit  3:0 = Reserved
*/

Then you configure the port register 0x08 "port control2", that this
port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.

/* Register: Port Control 2 (0x8)
   ------------------------
    bit 15    = IgnoreFSC: Force good FSC in frame
    bit 14    = VTU_prio_override   : VTU    setting overrides prio
    bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
    bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
    bit 11:10 = 802.1Q mode
     [00] = <Disabled>: use VLANtable only
     [01] = <Fallback>: fallback to VLANTable
     [10] = <Check>   : drop on miss (eq. not in VTU)
     [11] = <Secure>  : drop on miss and membership violation
    bit 9     = Discard Tagged
    bit 8     = Discard Untagged
    bit 7     = MapDA: Map using DA hits
    bit 6     = Default Forward (normal switch operation)
    bit 5     = Monitor egress
    bit 4     = Monitor ingress
    bit 3:0   = CPU port
*/


Reading through the "Monitor Control" register description, there is a
interesting description about the "ARPdest" setting... Could you try to
set it to the CPU port and see if that helps?

-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer

Re: Marvell 88E609x switch?

[Gary Thomas]

Jesper Dangaard Brouer wrote:
> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
>> Jesper Dangaard Brouer wrote:
>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>>> Any ideas how I might troubleshoot why packets that come
>>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>>> The switch supports port monitoring, with seperate ingress and egress
>>> mapping, thus you could place another PC on another port and direct
>>> traffic towards that, and by tcpdump inspecting ingress and egress on
>>> the different physical ports... Thats how I debugged it once...
>> I'm a bit fuzzy on this - could you explain in a bit more detail?
> 
> You basically set the monitor destination port via REG_GLOBAL reg 0x1A
> "Monitor Control".
> 
> /* Register: Monitor Control (0x1A)
>    -------------------------
>     bit 15:12= Ingress Monitor Dest
>     bit 11:8 = Egress  Monitor Dest
>     bit  7:4 = ARP Dest
>     bit  3:0 = Reserved
> */
> 
> Then you configure the port register 0x08 "port control2", that this
> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.
> 
> /* Register: Port Control 2 (0x8)
>    ------------------------
>     bit 15    = IgnoreFSC: Force good FSC in frame
>     bit 14    = VTU_prio_override   : VTU    setting overrides prio
>     bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
>     bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
>     bit 11:10 = 802.1Q mode
>      [00] = <Disabled>: use VLANtable only
>      [01] = <Fallback>: fallback to VLANTable
>      [10] = <Check>   : drop on miss (eq. not in VTU)
>      [11] = <Secure>  : drop on miss and membership violation
>     bit 9     = Discard Tagged
>     bit 8     = Discard Untagged
>     bit 7     = MapDA: Map using DA hits
>     bit 6     = Default Forward (normal switch operation)
>     bit 5     = Monitor egress
>     bit 4     = Monitor ingress
>     bit 3:0   = CPU port
> */
> 
> 
> Reading through the "Monitor Control" register description, there is a
> interesting description about the "ARPdest" setting... Could you try to
> set it to the CPU port and see if that helps?
> 

It's already set this way (sans bits 4&5)
	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);

I tried turning on bit 4 on port 0 (lan1.1).  Now I can see what's
coming into that port, but it doesn't look right:

Here's the ARP going out:

13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46:
        0x0000:  ffff ffff ffff 001d 1181 0000 4000 0000
        0x0010:  0806 0001 0800 0604 0001 001d 1181 0000
        0x0020:  c0a8 0cbc 0000 0000 0000 c0a8 0c12

Here's the ARP reply coming back:

13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64:
        0x0000:  001d 1181 0000 001e c92f 736c 8004 0000
        0x0010:  0806 0001 0800 0604 0002 001e c92f 736c
        0x0020:  c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000

I understand the 0x4000 DSA tag going out, but what's the 0x8004?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

Gary Thomas wrote:
> Jesper Dangaard Brouer wrote:
>> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
>>> Jesper Dangaard Brouer wrote:
>>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>>>> Any ideas how I might troubleshoot why packets that come
>>>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>>>> The switch supports port monitoring, with seperate ingress and egress
>>>> mapping, thus you could place another PC on another port and direct
>>>> traffic towards that, and by tcpdump inspecting ingress and egress on
>>>> the different physical ports... Thats how I debugged it once...
>>> I'm a bit fuzzy on this - could you explain in a bit more detail?
>> You basically set the monitor destination port via REG_GLOBAL reg 0x1A
>> "Monitor Control".
>>
>> /* Register: Monitor Control (0x1A)
>>    -------------------------
>>     bit 15:12= Ingress Monitor Dest
>>     bit 11:8 = Egress  Monitor Dest
>>     bit  7:4 = ARP Dest
>>     bit  3:0 = Reserved
>> */
>>
>> Then you configure the port register 0x08 "port control2", that this
>> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.
>>
>> /* Register: Port Control 2 (0x8)
>>    ------------------------
>>     bit 15    = IgnoreFSC: Force good FSC in frame
>>     bit 14    = VTU_prio_override   : VTU    setting overrides prio
>>     bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
>>     bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
>>     bit 11:10 = 802.1Q mode
>>      [00] = <Disabled>: use VLANtable only
>>      [01] = <Fallback>: fallback to VLANTable
>>      [10] = <Check>   : drop on miss (eq. not in VTU)
>>      [11] = <Secure>  : drop on miss and membership violation
>>     bit 9     = Discard Tagged
>>     bit 8     = Discard Untagged
>>     bit 7     = MapDA: Map using DA hits
>>     bit 6     = Default Forward (normal switch operation)
>>     bit 5     = Monitor egress
>>     bit 4     = Monitor ingress
>>     bit 3:0   = CPU port
>> */
>>
>>
>> Reading through the "Monitor Control" register description, there is a
>> interesting description about the "ARPdest" setting... Could you try to
>> set it to the CPU port and see if that helps?
>>
> 
> It's already set this way (sans bits 4&5)
> 	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);
> 
> I tried turning on bit 4 on port 0 (lan1.1).  Now I can see what's
> coming into that port, but it doesn't look right:
> 
> Here's the ARP going out:
> 
> 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46:
>         0x0000:  ffff ffff ffff 001d 1181 0000 4000 0000
>         0x0010:  0806 0001 0800 0604 0001 001d 1181 0000
>         0x0020:  c0a8 0cbc 0000 0000 0000 c0a8 0c12
> 
> Here's the ARP reply coming back:
> 
> 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64:
>         0x0000:  001d 1181 0000 001e c92f 736c 8004 0000
>         0x0010:  0806 0001 0800 0604 0002 001e c92f 736c
>         0x0020:  c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000
>         0x0030:  0000 0000 0000 0000 0000 0000 0000 0000
> 
> I understand the 0x4000 DSA tag going out, but what's the 0x8004?
> 

Note: without the extra monitor bit (#4), I don't see these packets
get back to my ethernet device.  Maybe the tag says something of why?

Any pointers on how I can test/debug the "VLAN" (internal routing) setup?


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

Gary Thomas wrote:
> Gary Thomas wrote:
>> Jesper Dangaard Brouer wrote:
>>> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
>>>> Jesper Dangaard Brouer wrote:
>>>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>>>>> Any ideas how I might troubleshoot why packets that come
>>>>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>>>>> The switch supports port monitoring, with seperate ingress and egress
>>>>> mapping, thus you could place another PC on another port and direct
>>>>> traffic towards that, and by tcpdump inspecting ingress and egress on
>>>>> the different physical ports... Thats how I debugged it once...
>>>> I'm a bit fuzzy on this - could you explain in a bit more detail?
>>> You basically set the monitor destination port via REG_GLOBAL reg 0x1A
>>> "Monitor Control".
>>>
>>> /* Register: Monitor Control (0x1A)
>>>    -------------------------
>>>     bit 15:12= Ingress Monitor Dest
>>>     bit 11:8 = Egress  Monitor Dest
>>>     bit  7:4 = ARP Dest
>>>     bit  3:0 = Reserved
>>> */
>>>
>>> Then you configure the port register 0x08 "port control2", that this
>>> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.
>>>
>>> /* Register: Port Control 2 (0x8)
>>>    ------------------------
>>>     bit 15    = IgnoreFSC: Force good FSC in frame
>>>     bit 14    = VTU_prio_override   : VTU    setting overrides prio
>>>     bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
>>>     bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
>>>     bit 11:10 = 802.1Q mode
>>>      [00] = <Disabled>: use VLANtable only
>>>      [01] = <Fallback>: fallback to VLANTable
>>>      [10] = <Check>   : drop on miss (eq. not in VTU)
>>>      [11] = <Secure>  : drop on miss and membership violation
>>>     bit 9     = Discard Tagged
>>>     bit 8     = Discard Untagged
>>>     bit 7     = MapDA: Map using DA hits
>>>     bit 6     = Default Forward (normal switch operation)
>>>     bit 5     = Monitor egress
>>>     bit 4     = Monitor ingress
>>>     bit 3:0   = CPU port
>>> */
>>>
>>>
>>> Reading through the "Monitor Control" register description, there is a
>>> interesting description about the "ARPdest" setting... Could you try to
>>> set it to the CPU port and see if that helps?
>>>
>> It's already set this way (sans bits 4&5)
>> 	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);
>>
>> I tried turning on bit 4 on port 0 (lan1.1).  Now I can see what's
>> coming into that port, but it doesn't look right:
>>
>> Here's the ARP going out:
>>
>> 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46:
>>         0x0000:  ffff ffff ffff 001d 1181 0000 4000 0000
>>         0x0010:  0806 0001 0800 0604 0001 001d 1181 0000
>>         0x0020:  c0a8 0cbc 0000 0000 0000 c0a8 0c12
>>
>> Here's the ARP reply coming back:
>>
>> 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64:
>>         0x0000:  001d 1181 0000 001e c92f 736c 8004 0000
>>         0x0010:  0806 0001 0800 0604 0002 001e c92f 736c
>>         0x0020:  c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000
>>         0x0030:  0000 0000 0000 0000 0000 0000 0000 0000
>>
>> I understand the 0x4000 DSA tag going out, but what's the 0x8004?
>>
> 
> Note: without the extra monitor bit (#4), I don't see these packets
> get back to my ethernet device.  Maybe the tag says something of why?

I found this tag in the 6131 manual - it basically says that it's
a copied packet which was received on VID 0.  Exactly as expected.

> Any pointers on how I can test/debug the "VLAN" (internal routing) setup?

Do you understand where (which register settings) cause packets
which come in on lan1.1 (VID=0 I think, port 0) to be sent on
to the CPU port (10) along with the TO_CPU tag?  I've been through
this document a dozen times and I still don't see where the mapping
that direction happens...

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

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

Gary Thomas wrote:
> Gary Thomas wrote:
>> Gary Thomas wrote:
>>> Jesper Dangaard Brouer wrote:
>>>> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
>>>>> Jesper Dangaard Brouer wrote:
>>>>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>>>>>> Any ideas how I might troubleshoot why packets that come
>>>>>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>>>>>> The switch supports port monitoring, with seperate ingress and egress
>>>>>> mapping, thus you could place another PC on another port and direct
>>>>>> traffic towards that, and by tcpdump inspecting ingress and egress on
>>>>>> the different physical ports... Thats how I debugged it once...
>>>>> I'm a bit fuzzy on this - could you explain in a bit more detail?
>>>> You basically set the monitor destination port via REG_GLOBAL reg 0x1A
>>>> "Monitor Control".
>>>>
>>>> /* Register: Monitor Control (0x1A)
>>>>    -------------------------
>>>>     bit 15:12= Ingress Monitor Dest
>>>>     bit 11:8 = Egress  Monitor Dest
>>>>     bit  7:4 = ARP Dest
>>>>     bit  3:0 = Reserved
>>>> */
>>>>
>>>> Then you configure the port register 0x08 "port control2", that this
>>>> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.
>>>>
>>>> /* Register: Port Control 2 (0x8)
>>>>    ------------------------
>>>>     bit 15    = IgnoreFSC: Force good FSC in frame
>>>>     bit 14    = VTU_prio_override   : VTU    setting overrides prio
>>>>     bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
>>>>     bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
>>>>     bit 11:10 = 802.1Q mode
>>>>      [00] = <Disabled>: use VLANtable only
>>>>      [01] = <Fallback>: fallback to VLANTable
>>>>      [10] = <Check>   : drop on miss (eq. not in VTU)
>>>>      [11] = <Secure>  : drop on miss and membership violation
>>>>     bit 9     = Discard Tagged
>>>>     bit 8     = Discard Untagged
>>>>     bit 7     = MapDA: Map using DA hits
>>>>     bit 6     = Default Forward (normal switch operation)
>>>>     bit 5     = Monitor egress
>>>>     bit 4     = Monitor ingress
>>>>     bit 3:0   = CPU port
>>>> */
>>>>
>>>>
>>>> Reading through the "Monitor Control" register description, there is a
>>>> interesting description about the "ARPdest" setting... Could you try to
>>>> set it to the CPU port and see if that helps?
>>>>
>>> It's already set this way (sans bits 4&5)
>>> 	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);
>>>
>>> I tried turning on bit 4 on port 0 (lan1.1).  Now I can see what's
>>> coming into that port, but it doesn't look right:
>>>
>>> Here's the ARP going out:
>>>
>>> 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46:
>>>         0x0000:  ffff ffff ffff 001d 1181 0000 4000 0000
>>>         0x0010:  0806 0001 0800 0604 0001 001d 1181 0000
>>>         0x0020:  c0a8 0cbc 0000 0000 0000 c0a8 0c12
>>>
>>> Here's the ARP reply coming back:
>>>
>>> 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64:
>>>         0x0000:  001d 1181 0000 001e c92f 736c 8004 0000
>>>         0x0010:  0806 0001 0800 0604 0002 001e c92f 736c
>>>         0x0020:  c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000
>>>         0x0030:  0000 0000 0000 0000 0000 0000 0000 0000
>>>
>>> I understand the 0x4000 DSA tag going out, but what's the 0x8004?
>>>
>> Note: without the extra monitor bit (#4), I don't see these packets
>> get back to my ethernet device.  Maybe the tag says something of why?
> 
> I found this tag in the 6131 manual - it basically says that it's
> a copied packet which was received on VID 0.  Exactly as expected.
> 
>> Any pointers on how I can test/debug the "VLAN" (internal routing) setup?
> 
> Do you understand where (which register settings) cause packets
> which come in on lan1.1 (VID=0 I think, port 0) to be sent on
> to the CPU port (10) along with the TO_CPU tag?  I've been through
> this document a dozen times and I still don't see where the mapping
> that direction happens...

After much experimentation, I finally found out what was
wrong.  Basically, the trunk masks have 8 bits on the 6131,
but 11 bits on the 609x and this wasn't being handled.  Once
the trunk masks were reset by the init code, there was no
path to the CPU port from the LAN ports :-(  The attached
patch is what I've ended up with.  It works, at least for
a single switch.

Next, I need to get it to work with multiple switches (separate
ethernet controllers, same/shared MII bus), as well as a cascaded
switch.



-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3795 bytes --]

Index: net/dsa/mv88e6131.c
===================================================================
--- net/dsa/mv88e6131.c	(.../kvaerner-subsea-2008-08-14-branch/tools/linuxppc-2.6/net/dsa)	(revision 4831)
+++ net/dsa/mv88e6131.c	(.../elbit-systems-2009-02-24-branch/tools/linuxppc-2.6/net/dsa)	(working copy)
@@ -21,6 +21,8 @@
 	ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
 	if (ret >= 0) {
 		ret &= 0xfff0;
+		if (ret == 0x0950)
+			return "Marvell 88E6095/88E6095F";
 		if (ret == 0x1060)
 			return "Marvell 88E6131";
 	}
@@ -28,6 +30,49 @@
 	return NULL;
 }
 
+static void mv88e6131_show_all(struct dsa_switch *ds)
+{
+    int p, r;
+
+    printk("=== Global regs:\n");
+    for (r = 0;  r < 27;  r++) {
+        printk("  REG[0x%02x] = 0x%04X\n", r, REG_READ(REG_GLOBAL, r));
+    }
+    printk("=== Port regs:\n");
+    for (p = 0x0;  p < 0xB;  p++) {
+        for (r = 0;  r < 26;  r++) {
+            if ((r == 2) || (r == 5) || ((r >= 12) && (r <= 15))) 
+                continue;
+            printk("  REG[0x%02x.%02x] = 0x%04x\n", p, r, REG_READ(REG_PORT(p), r));
+        }
+    }
+    printk("=== VTU table:\n");
+    REG_WRITE(REG_GLOBAL, 0x06, 0x0FFF);
+    while (true) {
+        // Issue VTU 'get next' command
+        REG_WRITE(REG_GLOBAL, 0x05, 0xC000);
+        while ((REG_READ(REG_GLOBAL, 0x05) & 0x8000) != 0) msleep(1);
+        p = REG_READ(REG_GLOBAL, 0x06) & 0x1FFF;
+        if ((p & 0x1000) == 0) {
+            break;
+        }
+        printk("   VTU[0x%03x] = 0x%04x/0x%04x/0x%04x\n", p & 0x0FFF,
+               REG_READ(REG_GLOBAL, 0x07),
+               REG_READ(REG_GLOBAL, 0x08),
+               REG_READ(REG_GLOBAL, 0x09));
+    }
+    printk("=== Trunk mask table\n");
+    for (r = 0;  r < 8;  r++) {
+        REG_WRITE(REG_GLOBAL2, 0x07, (r << 12));
+        printk("   MASK[0x%1x] = 0x%04x\n", r, REG_READ(REG_GLOBAL2, 0x07));
+    }
+    printk("=== Trunk mapping table\n");
+    for (r = 0;  r < 16;  r++) {
+        REG_WRITE(REG_GLOBAL2, 0x08, (r << 11));
+        printk("   MAP[0x%1x] = 0x%04x\n", r, REG_READ(REG_GLOBAL2, 0x08));
+    }
+}
+
 static int mv88e6131_switch_reset(struct dsa_switch *ds)
 {
 	int i;
@@ -36,7 +81,7 @@
 	/*
 	 * Set all ports to the disabled state.
 	 */
-	for (i = 0; i < 8; i++) {
+	for (i = 0; i < 11; i++) {
 		ret = REG_READ(REG_PORT(i), 0x04);
 		REG_WRITE(REG_PORT(i), 0x04, ret & 0xfffc);
 	}
@@ -91,7 +136,7 @@
 	 * Configure the priority mapping registers.
 	 */
 	ret = mv88e6xxx_config_prio(ds);
-	if (ret < 0)
+        if (ret < 0)
 		return ret;
 
 	/*
@@ -136,7 +181,7 @@
 	 * Clear all trunk masks.
 	 */
 	for (i = 0; i < 8; i++)
-		REG_WRITE(REG_GLOBAL2, 0x07, 0x8000 | (i << 12) | 0xff);
+		REG_WRITE(REG_GLOBAL2, 0x07, 0x8000 | (i << 12) | 0x7ff);
 
 	/*
 	 * Clear all trunk mappings.
@@ -159,9 +204,10 @@
 
 	/*
 	 * MAC Forcing register: don't force link, speed, duplex
-	 * or flow control state to any particular values.
+	 * or flow control state to any particular values for normal ports.
+         * CPU port is forced link+full+1000Mb
 	 */
-	REG_WRITE(addr, 0x01, 0x0003);
+	REG_WRITE(addr, 0x01, (p == ds->cpu_port) ? 0x003E : 0x0003);
 
 	/*
 	 * Port Control: disable Core Tag, disable Drop-on-Lock,
@@ -212,7 +258,7 @@
 	 * addresses.
 	 */
 	REG_WRITE(addr, 0x08,
-			((p == ds->cpu_port) ? 0x00c0 : 0x0080) |
+                        ((p == ds->cpu_port) ? 0x00c0 : 0x0080) |
 			 ds->cpu_port);
 
 	/*
@@ -268,7 +314,7 @@
 	if (ret < 0)
 		return ret;
 
-	for (i = 0; i < 6; i++) {
+	for (i = 0; i < 11; i++) {
 		ret = mv88e6131_setup_port(ds, i);
 		if (ret < 0)
 			return ret;
@@ -279,7 +325,7 @@
 
 static int mv88e6131_port_to_phy_addr(int port)
 {
-	if (port >= 0 && port != 3 && port <= 7)
+	if (port >= 0 && port <= 11)
 		return port;
 	return -1;
 }

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Fri, 2009-03-06 at 08:49 -0700, Gary Thomas wrote:
> After much experimentation, I finally found out what was
> wrong.  Basically, the trunk masks have 8 bits on the 6131,
> but 11 bits on the 609x and this wasn't being handled.  Once
> the trunk masks were reset by the init code, there was no
> path to the CPU port from the LAN ports :-(  The attached
> patch is what I've ended up with.  It works, at least for
> a single switch.

Thats great! ... finally you discovered the difference :-)

Once you are ready with a more final patch, I'll be happy to review it
(and fixup any whitespace compliance stuff... which the attached patch
does not comply to ;-))

> Next, I need to get it to work with multiple switches (separate
> ethernet controllers, same/shared MII bus), as well as a cascaded
> switch.

Okay, I'll be happy to review any patches, but I don't have any
experience with a multiple switch chip setup...

-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Mar 06, 2009 at 08:49:19AM -0700, Gary Thomas wrote:
> 
>> After much experimentation, I finally found out what was
>> wrong.  Basically, the trunk masks have 8 bits on the 6131,
>> but 11 bits on the 609x and this wasn't being handled.  Once
>> the trunk masks were reset by the init code, there was no
>> path to the CPU port from the LAN ports :-(  The attached
>> patch is what I've ended up with.  It works, at least for
>> a single switch.
> 
> Cool.  How about the patch below then?
> 

This looks fine to me - is this part safe on the smaller parts
(6131, etc)?  I wasn't sure about setting those "reserved" bits
on other chips.

> @@ -136,7 +138,7 @@ static int mv88e6131_setup_global(struct dsa_switch *ds)
>  	 * Clear all trunk masks.
>  	 */
>  	for (i = 0; i < 8; i++)
> -		REG_WRITE(REG_GLOBAL2, 0x07, 0x8000 | (i << 12) | 0xff);
> +		REG_WRITE(REG_GLOBAL2, 0x07, 0x8000 | (i << 12) | 0x7ff);
>
>  	/*
>  	 * Clear all trunk mappings.

> 
>> Next, I need to get it to work with multiple switches (separate
>> ethernet controllers, same/shared MII bus),
> 
> That should be easy -- the DSA driver only accesses MII buses via
> phylib, and that does the required locking, etc.  Also, we've
> verified that multi-chip addressing mode works.
> 
> 
>> as well as a cascaded switch.
> 
> That's a bit trickier, but also not entirely hard:
> - Instead of the CPU port concept, we'll have to use the port number
>   that brings us one hop closer to the CPU (i.e. the upstream port).
> - Assign each chip a DSA device address (instead of always setting it
>   to zero).
> - Populate the 'DSA device address -> port' mapping table for each
>   switch.
> - Enable DSA tagging and flooding of unknown unicasts and multicasts
>   on all inter-switch links and not just on the CPU port on switch 0.
> 
> I don't think it makes sense to implement Dijkstra in the kernel, so
> it's probably easiest to just pass in a precomputed NxN array of how
> to go from which switch to which switch via which port, along with a
> separate DSA port list for each switch chip.
> 
> I don't have multi-switch chip setups myself, or I would have
> implemented this already.  But I can whip up some patches to try..
> 

That would be great.  What I'd like to figure out is a
way to provide that mapping (static from the driver point
of view), much like the current "port_names[]" table now.

For my particular setup, there are two cases (on the same
board):
  Switch 1 - ports 1..8
  Switch 2 - ports 9..16
    Switch 3 - ports 17..24 (cascaded off of Switch 2)
Thus, the only access to Switch 3 and its ports is indirect via
Switch 2.

Presumably, one could have a multiple cascade, so this structure
should be considered from the start.

Thanks for your help


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Tue, Mar 10, 2009 at 05:20:21AM -0600, Gary Thomas wrote:

> >> After much experimentation, I finally found out what was
> >> wrong.  Basically, the trunk masks have 8 bits on the 6131,
> >> but 11 bits on the 609x and this wasn't being handled.  Once
> >> the trunk masks were reset by the init code, there was no
> >> path to the CPU port from the LAN ports :-(  The attached
> >> patch is what I've ended up with.  It works, at least for
> >> a single switch.
> > 
> > Cool.  How about the patch below then?
> 
> This looks fine to me - is this part safe on the smaller parts
> (6131, etc)?  I wasn't sure about setting those "reserved" bits
> on other chips.

It should be OK, but I'll test it to make sure.


> > That's a bit trickier, but also not entirely hard:
> > - Instead of the CPU port concept, we'll have to use the port number
> >   that brings us one hop closer to the CPU (i.e. the upstream port).
> > - Assign each chip a DSA device address (instead of always setting it
> >   to zero).
> > - Populate the 'DSA device address -> port' mapping table for each
> >   switch.
> > - Enable DSA tagging and flooding of unknown unicasts and multicasts
> >   on all inter-switch links and not just on the CPU port on switch 0.
> > 
> > I don't think it makes sense to implement Dijkstra in the kernel, so
> > it's probably easiest to just pass in a precomputed NxN array of how
> > to go from which switch to which switch via which port, along with a
> > separate DSA port list for each switch chip.
> > 
> > I don't have multi-switch chip setups myself, or I would have
> > implemented this already.  But I can whip up some patches to try..
> 
> That would be great.  What I'd like to figure out is a
> way to provide that mapping (static from the driver point
> of view), much like the current "port_names[]" table now.

Something a la the attached patch should be enough from the
data structure point of view, AFAICS.  And then you'd have:


> For my particular setup, there are two cases (on the same
> board):
>   Switch 1 - ports 1..8
>   Switch 2 - ports 9..16
>     Switch 3 - ports 17..24 (cascaded off of Switch 2)
> Thus, the only access to Switch 3 and its ports is indirect via
> Switch 2.
> 
> Presumably, one could have a multiple cascade, so this structure
> should be considered from the start.

Switch 1 can correspond to its own DSA platform device as it is now.

And for switch 2/3 you'd then have something a la:


struct dsa_switch_data switches[] = {
	{
		.mii_bus = &blah,
		.sw_addr = 2,
		.port_names[0] = "p9",
		.port_names[1] = "p10",
		.port_names[2] = "p11",
		.port_names[3] = "p12",
		.port_names[4] = "p13",
		.port_names[5] = "p14",
		.port_names[6] = "p15",
		.port_names[7] = "p16",
		.port_names[9] = "dsa",
		.port_names[10] = "cpu",
	}, {
		.mii_bus = &blah,
		.sw_addr = 3,
		.port_names[0] = "p17",
		.port_names[1] = "p18",
		.port_names[2] = "p19",
		.port_names[3] = "p20",
		.port_names[4] = "p21",
		.port_names[5] = "p22",
		.port_names[6] = "p23",
		.port_names[7] = "p24",
		.port_names[9] = "dsa",
	},
};

struct dsa_platform_data switch23 = {
	.netdev = &blah,
	.nr_switches = 2,
	.sw = switches,
	.rtable = {
		{ -1,  9 },
		{  9, -1 },
	},
};

Or something along those lines.

Thoughts?




diff --git a/include/net/dsa.h b/include/net/dsa.h
index 52e97bf..8bbf5ba 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -1,6 +1,6 @@
 /*
  * include/net/dsa.h - Driver for Distributed Switch Architecture switch chips
- * Copyright (c) 2008 Marvell Semiconductor
+ * Copyright (c) 2008-2009 Marvell Semiconductor
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -13,21 +13,44 @@
 
 #define DSA_MAX_PORTS	12
 
+struct dsa_switch_data {
+	/*
+	 * How to access the switch configuration registers.
+	 */
+	struct device	*mii_bus;
+	int		sw_addr;
+
+	/*
+	 * The names of the switch's ports.  Use "cpu" to
+	 * designate the switch port that the cpu is connected to,
+	 * "dsa" to indicate that this port is a DSA link to
+	 * another switch, NULL to indicate the port is unused,
+	 * or any other string to indicate this is a physical port.
+	 */
+	char		*port_names[DSA_MAX_PORTS];
+};
+
 struct dsa_platform_data {
 	/*
 	 * Reference to a Linux network interface that connects
-	 * to the switch chip.
+	 * to one of the switch chips in the tree.
 	 */
 	struct device	*netdev;
 
 	/*
-	 * How to access the switch configuration registers, and
-	 * the names of the switch ports (use "cpu" to designate
-	 * the switch port that the cpu is connected to).
+	 * Info structs describing each of the switch chips
+	 * connected via this network interface.
 	 */
-	struct device	*mii_bus;
-	int		sw_addr;
-	char		*port_names[DSA_MAX_PORTS];
+	int		nr_switches;
+	struct dsa_switch_data *sw;
+
+	/*
+	 * A nr_switches * nr_switches array where element [a][b]
+	 * indicates which port on switch a should be used to send
+	 * packets to that are destined for switch b.  Can be NULL
+	 * if there is only one switch chip.
+	 */
+	u8		**rtable;
 };
 
 extern bool dsa_uses_dsa_tags(void *dsa_ptr);

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Tue, Mar 10, 2009 at 05:20:21AM -0600, Gary Thomas wrote:
> 
>>>> After much experimentation, I finally found out what was
>>>> wrong.  Basically, the trunk masks have 8 bits on the 6131,
>>>> but 11 bits on the 609x and this wasn't being handled.  Once
>>>> the trunk masks were reset by the init code, there was no
>>>> path to the CPU port from the LAN ports :-(  The attached
>>>> patch is what I've ended up with.  It works, at least for
>>>> a single switch.
>>> Cool.  How about the patch below then?
>> This looks fine to me - is this part safe on the smaller parts
>> (6131, etc)?  I wasn't sure about setting those "reserved" bits
>> on other chips.
> 
> It should be OK, but I'll test it to make sure.
> 
> 
>>> That's a bit trickier, but also not entirely hard:
>>> - Instead of the CPU port concept, we'll have to use the port number
>>>   that brings us one hop closer to the CPU (i.e. the upstream port).
>>> - Assign each chip a DSA device address (instead of always setting it
>>>   to zero).
>>> - Populate the 'DSA device address -> port' mapping table for each
>>>   switch.
>>> - Enable DSA tagging and flooding of unknown unicasts and multicasts
>>>   on all inter-switch links and not just on the CPU port on switch 0.
>>>
>>> I don't think it makes sense to implement Dijkstra in the kernel, so
>>> it's probably easiest to just pass in a precomputed NxN array of how
>>> to go from which switch to which switch via which port, along with a
>>> separate DSA port list for each switch chip.
>>>
>>> I don't have multi-switch chip setups myself, or I would have
>>> implemented this already.  But I can whip up some patches to try..
>> That would be great.  What I'd like to figure out is a
>> way to provide that mapping (static from the driver point
>> of view), much like the current "port_names[]" table now.
> 
> Something a la the attached patch should be enough from the
> data structure point of view, AFAICS.  And then you'd have:
> 
> 
>> For my particular setup, there are two cases (on the same
>> board):
>>   Switch 1 - ports 1..8
>>   Switch 2 - ports 9..16
>>     Switch 3 - ports 17..24 (cascaded off of Switch 2)
>> Thus, the only access to Switch 3 and its ports is indirect via
>> Switch 2.
>>
>> Presumably, one could have a multiple cascade, so this structure
>> should be considered from the start.
> 
> Switch 1 can correspond to its own DSA platform device as it is now.
> 
> And for switch 2/3 you'd then have something a la:
> 
> 
> struct dsa_switch_data switches[] = {
> 	{
> 		.mii_bus = &blah,
> 		.sw_addr = 2,
> 		.port_names[0] = "p9",
> 		.port_names[1] = "p10",
> 		.port_names[2] = "p11",
> 		.port_names[3] = "p12",
> 		.port_names[4] = "p13",
> 		.port_names[5] = "p14",
> 		.port_names[6] = "p15",
> 		.port_names[7] = "p16",
> 		.port_names[9] = "dsa",
> 		.port_names[10] = "cpu",
> 	}, {
> 		.mii_bus = &blah,
> 		.sw_addr = 3,
> 		.port_names[0] = "p17",
> 		.port_names[1] = "p18",
> 		.port_names[2] = "p19",
> 		.port_names[3] = "p20",
> 		.port_names[4] = "p21",
> 		.port_names[5] = "p22",
> 		.port_names[6] = "p23",
> 		.port_names[7] = "p24",
> 		.port_names[9] = "dsa",
> 	},
> };
> 
> struct dsa_platform_data switch23 = {
> 	.netdev = &blah,
> 	.nr_switches = 2,
> 	.sw = switches,
> 	.rtable = {
> 		{ -1,  9 },
> 		{  9, -1 },
> 	},
> };
> 
> Or something along those lines.
> 
> Thoughts?
> 

The setup looks good.  Let me know when you have the rest of
the patch ready to test (I'm all setup here)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Tue, Mar 10, 2009 at 09:11:22AM -0600, Gary Thomas wrote:

> >> For my particular setup, there are two cases (on the same
> >> board):
> >>   Switch 1 - ports 1..8
> >>   Switch 2 - ports 9..16
> >>     Switch 3 - ports 17..24 (cascaded off of Switch 2)
> >> Thus, the only access to Switch 3 and its ports is indirect via
> >> Switch 2.
> >>
> >> Presumably, one could have a multiple cascade, so this structure
> >> should be considered from the start.
> > 
> > Switch 1 can correspond to its own DSA platform device as it is now.
> > 
> > And for switch 2/3 you'd then have something a la:
> > 
> > 
> > struct dsa_switch_data switches[] = {
> > 	{
> > 		.mii_bus = &blah,
> > 		.sw_addr = 2,
> > 		.port_names[0] = "p9",
> > 		.port_names[1] = "p10",
> > 		.port_names[2] = "p11",
> > 		.port_names[3] = "p12",
> > 		.port_names[4] = "p13",
> > 		.port_names[5] = "p14",
> > 		.port_names[6] = "p15",
> > 		.port_names[7] = "p16",
> > 		.port_names[9] = "dsa",
> > 		.port_names[10] = "cpu",
> > 	}, {
> > 		.mii_bus = &blah,
> > 		.sw_addr = 3,
> > 		.port_names[0] = "p17",
> > 		.port_names[1] = "p18",
> > 		.port_names[2] = "p19",
> > 		.port_names[3] = "p20",
> > 		.port_names[4] = "p21",
> > 		.port_names[5] = "p22",
> > 		.port_names[6] = "p23",
> > 		.port_names[7] = "p24",
> > 		.port_names[9] = "dsa",
> > 	},
> > };
> > 
> > struct dsa_platform_data switch23 = {
> > 	.netdev = &blah,
> > 	.nr_switches = 2,
> > 	.sw = switches,
> > 	.rtable = {
> > 		{ -1,  9 },
> > 		{  9, -1 },
> > 	},
> > };
> > 
> > Or something along those lines.
> > 
> > Thoughts?
> 
> The setup looks good.  Let me know when you have the rest of
> the patch ready to test (I'm all setup here)

OK, I hit a snag with my initial implementation (we can't put an array
of dsa_switch in dsa_switch_tree as dsa_switch has driver-private data
at the end, making it variable length), but I should hopefully have a
patch by day end.

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Tue, Mar 10, 2009 at 09:11:22AM -0600, Gary Thomas wrote:

> The setup looks good.  Let me know when you have the rest of
> the patch ready to test (I'm all setup here)

Attached patch is what I came up with, and should implement full
cascaded DSA.  It adds the DSA device ID to DSA/EDSA tags, should
be able to deal with trees of DSA switches, and should configure
inter-switch links for DSA tagging and the CPU port for DSA or
EDSA tagging depending on which one we want.

Basically, this should let you send DSA tagged FROM_CPU packets to
any switch because it sets up the device routing table in each switch
correctly, TO_CPU packets should be able to find the CPU because we
program the upstream port into each switch, and unknown unicasts/
multicasts should find the CPU because only to upstream ports can
unknown unicasts/multicasts be forwarded.

I don't have multi-chip devices to test with, but it seems to still
work (i.e. ping still works) on the main board I use for testing
(which has a 6165).

Can you see if it works for you?

Left to do:
- Perhaps enumerate switches in multiple passes: first forcibly
  disable all ports, then configure all ports, and then re-enable
  link, to prevent races where one end of an inter-switch link is
  switched to DSA mode while the other end isn't yet.
- Re-port the HW bridging patch to go on top of this patch.
- Check if we need in-band autoneg and/or link speed forcing for
  SERDES ports.
- Perhaps allow configuring the speed/duplex/etc of the CPU port.
- Split up the patch into smaller pieces.



commit 0aabe480fe99c02a6609bdd2d2cecb001e82a7c7
Author: Lennert Buytenhek <buytenh@wantstofly.org>
Date:   Wed Mar 11 22:08:05 2009 +0100

    dsa: add dsa cascading support
    
    Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index b3404b7..a2c8f6e 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -231,14 +231,17 @@ static struct platform_device kirkwood_switch_device = {
 
 void __init kirkwood_ge00_switch_init(struct dsa_platform_data *d, int irq)
 {
+	int i;
+
 	if (irq != NO_IRQ) {
 		kirkwood_switch_resources[0].start = irq;
 		kirkwood_switch_resources[0].end = irq;
 		kirkwood_switch_device.num_resources = 1;
 	}
 
-	d->mii_bus = &kirkwood_ge00_shared.dev;
 	d->netdev = &kirkwood_ge00.dev;
+	for (i = 0; i < d->nr_switches; i++)
+		d->sw[i].mii_bus = &kirkwood_ge00_shared.dev;
 	kirkwood_switch_device.dev.platform_data = d;
 
 	platform_device_register(&kirkwood_switch_device);
diff --git a/arch/arm/mach-kirkwood/rd88f6281-setup.c b/arch/arm/mach-kirkwood/rd88f6281-setup.c
index 9a0e905..ad3fc91 100644
--- a/arch/arm/mach-kirkwood/rd88f6281-setup.c
+++ b/arch/arm/mach-kirkwood/rd88f6281-setup.c
@@ -75,7 +75,7 @@ static struct mv643xx_eth_platform_data rd88f6281_ge00_data = {
 	.duplex		= DUPLEX_FULL,
 };
 
-static struct dsa_platform_data rd88f6281_switch_data = {
+static struct dsa_switch_data rd88f6281_switch_data = {
 	.port_names[0]	= "lan1",
 	.port_names[1]	= "lan2",
 	.port_names[2]	= "lan3",
@@ -83,6 +83,11 @@ static struct dsa_platform_data rd88f6281_switch_data = {
 	.port_names[5]	= "cpu",
 };
 
+static struct dsa_platform_data rd88f6281_switch_plat_data = {
+	.nr_switches	= 1,
+	.sw		= &rd88f6281_switch_data,
+};
+
 static struct mv643xx_eth_platform_data rd88f6281_ge01_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(11),
 };
@@ -110,7 +115,7 @@ static void __init rd88f6281_init(void)
 	} else {
 		rd88f6281_switch_data.port_names[4] = "wan";
 	}
-	kirkwood_ge00_switch_init(&rd88f6281_switch_data, NO_IRQ);
+	kirkwood_ge00_switch_init(&rd88f6281_switch_plat_data, NO_IRQ);
 
 	kirkwood_rtc_init();
 	kirkwood_sata_init(&rd88f6281_sata_data);
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 0a62337..7eb61b3 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -219,14 +219,17 @@ static struct platform_device orion5x_switch_device = {
 
 void __init orion5x_eth_switch_init(struct dsa_platform_data *d, int irq)
 {
+	int i;
+
 	if (irq != NO_IRQ) {
 		orion5x_switch_resources[0].start = irq;
 		orion5x_switch_resources[0].end = irq;
 		orion5x_switch_device.num_resources = 1;
 	}
 
-	d->mii_bus = &orion5x_eth_shared.dev;
 	d->netdev = &orion5x_eth.dev;
+	for (i = 0; i < d->nr_switches; i++)
+		d->sw[i].mii_bus = &orion5x_eth_shared.dev;
 	orion5x_switch_device.dev.platform_data = d;
 
 	platform_device_register(&orion5x_switch_device);
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index 15f5323..aa6968c 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -94,7 +94,7 @@ static struct mv643xx_eth_platform_data rd88f5181l_fxo_eth_data = {
 	.duplex		= DUPLEX_FULL,
 };
 
-static struct dsa_platform_data rd88f5181l_fxo_switch_data = {
+static struct dsa_switch_data rd88f5181l_fxo_switch_data = {
 	.port_names[0]	= "lan2",
 	.port_names[1]	= "lan1",
 	.port_names[2]	= "wan",
@@ -103,6 +103,11 @@ static struct dsa_platform_data rd88f5181l_fxo_switch_data = {
 	.port_names[7]	= "lan3",
 };
 
+static struct dsa_platform_data rd88f5181l_fxo_switch_plat_data = {
+	.nr_switches	= 1,
+	.sw		= &rd88f5181l_fxo_switch_data,
+};
+
 static void __init rd88f5181l_fxo_init(void)
 {
 	/*
@@ -117,7 +122,7 @@ static void __init rd88f5181l_fxo_init(void)
 	 */
 	orion5x_ehci0_init();
 	orion5x_eth_init(&rd88f5181l_fxo_eth_data);
-	orion5x_eth_switch_init(&rd88f5181l_fxo_switch_data, NO_IRQ);
+	orion5x_eth_switch_init(&rd88f5181l_fxo_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
 	orion5x_setup_dev_boot_win(RD88F5181L_FXO_NOR_BOOT_BASE,
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index 8ad3934..d48c57b 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -95,7 +95,7 @@ static struct mv643xx_eth_platform_data rd88f5181l_ge_eth_data = {
 	.duplex		= DUPLEX_FULL,
 };
 
-static struct dsa_platform_data rd88f5181l_ge_switch_data = {
+static struct dsa_switch_data rd88f5181l_ge_switch_data = {
 	.port_names[0]	= "lan2",
 	.port_names[1]	= "lan1",
 	.port_names[2]	= "wan",
@@ -104,6 +104,11 @@ static struct dsa_platform_data rd88f5181l_ge_switch_data = {
 	.port_names[7]	= "lan3",
 };
 
+static struct dsa_platform_data rd88f5181l_ge_switch_plat_data = {
+	.nr_switches	= 1,
+	.sw		= &rd88f5181l_ge_switch_data,
+};
+
 static struct i2c_board_info __initdata rd88f5181l_ge_i2c_rtc = {
 	I2C_BOARD_INFO("ds1338", 0x68),
 };
@@ -122,7 +127,7 @@ static void __init rd88f5181l_ge_init(void)
 	 */
 	orion5x_ehci0_init();
 	orion5x_eth_init(&rd88f5181l_ge_eth_data);
-	orion5x_eth_switch_init(&rd88f5181l_ge_switch_data, gpio_to_irq(8));
+	orion5x_eth_switch_init(&rd88f5181l_ge_switch_plat_data, gpio_to_irq(8));
 	orion5x_i2c_init();
 	orion5x_uart0_init();
 
diff --git a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c b/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
index 262e25e..eb716b8 100644
--- a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
@@ -35,7 +35,7 @@ static struct mv643xx_eth_platform_data rd88f6183ap_ge_eth_data = {
 	.duplex		= DUPLEX_FULL,
 };
 
-static struct dsa_platform_data rd88f6183ap_ge_switch_data = {
+static struct dsa_switch_data rd88f6183ap_ge_switch_data = {
 	.port_names[0]	= "lan1",
 	.port_names[1]	= "lan2",
 	.port_names[2]	= "lan3",
@@ -44,6 +44,11 @@ static struct dsa_platform_data rd88f6183ap_ge_switch_data = {
 	.port_names[5]	= "cpu",
 };
 
+static struct dsa_platform_data rd88f6183ap_ge_switch_plat_data = {
+	.nr_switches	= 1,
+	.sw		= &rd88f6183ap_ge_switch_data,
+};
+
 static struct mtd_partition rd88f6183ap_ge_partitions[] = {
 	{
 		.name	= "kernel",
@@ -89,7 +94,7 @@ static void __init rd88f6183ap_ge_init(void)
 	 */
 	orion5x_ehci0_init();
 	orion5x_eth_init(&rd88f6183ap_ge_eth_data);
-	orion5x_eth_switch_init(&rd88f6183ap_ge_switch_data, gpio_to_irq(3));
+	orion5x_eth_switch_init(&rd88f6183ap_ge_switch_plat_data, gpio_to_irq(3));
 	spi_register_board_info(rd88f6183ap_ge_spi_slave_info,
 				ARRAY_SIZE(rd88f6183ap_ge_spi_slave_info));
 	orion5x_spi_init();
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
index cc8f892..238c8b2 100644
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -106,7 +106,7 @@ static struct mv643xx_eth_platform_data wrt350n_v2_eth_data = {
 	.duplex		= DUPLEX_FULL,
 };
 
-static struct dsa_platform_data wrt350n_v2_switch_data = {
+static struct dsa_switch_data wrt350n_v2_switch_data = {
 	.port_names[0]	= "lan2",
 	.port_names[1]	= "lan1",
 	.port_names[2]	= "wan",
@@ -115,6 +115,11 @@ static struct dsa_platform_data wrt350n_v2_switch_data = {
 	.port_names[7]	= "lan4",
 };
 
+static struct dsa_platform_data wrt350n_v2_switch_plat_data = {
+	.nr_switches	= 1,
+	.sw		= &wrt350n_v2_switch_data,
+};
+
 static void __init wrt350n_v2_init(void)
 {
 	/*
@@ -129,7 +134,7 @@ static void __init wrt350n_v2_init(void)
 	 */
 	orion5x_ehci0_init();
 	orion5x_eth_init(&wrt350n_v2_eth_data);
-	orion5x_eth_switch_init(&wrt350n_v2_switch_data, NO_IRQ);
+	orion5x_eth_switch_init(&wrt350n_v2_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
 	orion5x_setup_dev_boot_win(WRT350N_V2_NOR_BOOT_BASE,
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 52e97bf..649ade3 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -1,6 +1,6 @@
 /*
  * include/net/dsa.h - Driver for Distributed Switch Architecture switch chips
- * Copyright (c) 2008 Marvell Semiconductor
+ * Copyright (c) 2008-2009 Marvell Semiconductor
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -11,23 +11,47 @@
 #ifndef __LINUX_NET_DSA_H
 #define __LINUX_NET_DSA_H
 
-#define DSA_MAX_PORTS	12
+#define DSA_MAX_SWITCHES	4
+#define DSA_MAX_PORTS		12
+
+struct dsa_switch_data {
+	/*
+	 * How to access the switch configuration registers.
+	 */
+	struct device	*mii_bus;
+	int		sw_addr;
+
+	/*
+	 * The names of the switch's ports.  Use "cpu" to
+	 * designate the switch port that the cpu is connected to,
+	 * "dsa" to indicate that this port is a DSA link to
+	 * another switch, NULL to indicate the port is unused,
+	 * or any other string to indicate this is a physical port.
+	 */
+	char		*port_names[DSA_MAX_PORTS];
+
+	/*
+	 * An array (with nr_switches elements) of which element [a]
+	 * indicates which port on this switch should be used to
+	 * send packets to that are destined for switch a.  Can be
+	 * NULL if there is only one switch chip.
+	 */
+	s8		*rtable;
+};
 
 struct dsa_platform_data {
 	/*
 	 * Reference to a Linux network interface that connects
-	 * to the switch chip.
+	 * to the root switch chip of the tree.
 	 */
 	struct device	*netdev;
 
 	/*
-	 * How to access the switch configuration registers, and
-	 * the names of the switch ports (use "cpu" to designate
-	 * the switch port that the cpu is connected to).
+	 * Info structs describing each of the switch chips
+	 * connected via this network interface.
 	 */
-	struct device	*mii_bus;
-	int		sw_addr;
-	char		*port_names[DSA_MAX_PORTS];
+	int		nr_switches;
+	struct dsa_switch_data *sw;
 };
 
 extern bool dsa_uses_dsa_tags(void *dsa_ptr);
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 33e9946..7ac31cc 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -67,12 +67,13 @@ dsa_switch_probe(struct mii_bus *bus, int sw_addr, char **_name)
 
 /* basic switch operations **************************************************/
 static struct dsa_switch *
-dsa_switch_setup(struct device *parent, struct dsa_platform_data *pd,
-		 struct mii_bus *bus, struct net_device *dev)
+dsa_switch_setup(struct dsa_switch_tree *dst, int index,
+		 struct device *parent, struct mii_bus *bus)
 {
+	struct dsa_switch_data *pd = dst->pd->sw + index;
+	struct dsa_switch_driver *drv;
 	struct dsa_switch *ds;
 	int ret;
-	struct dsa_switch_driver *drv;
 	char *name;
 	int i;
 
@@ -82,10 +83,11 @@ dsa_switch_setup(struct device *parent, struct dsa_platform_data *pd,
 	drv = dsa_switch_probe(bus, pd->sw_addr, &name);
 	if (drv == NULL) {
 		printk(KERN_ERR "%s: could not detect attached switch\n",
-		       dev->name);
+		       dst->master_netdev->name);
 		return ERR_PTR(-EINVAL);
 	}
-	printk(KERN_INFO "%s: detected a %s switch\n", dev->name, name);
+	printk(KERN_INFO "%s[%d]: detected a %s switch\n",
+		dst->master_netdev->name, index, name);
 
 
 	/*
@@ -95,18 +97,16 @@ dsa_switch_setup(struct device *parent, struct dsa_platform_data *pd,
 	if (ds == NULL)
 		return ERR_PTR(-ENOMEM);
 
-	ds->pd = pd;
-	ds->master_netdev = dev;
-	ds->master_mii_bus = bus;
-
+	ds->dst = dst;
+	ds->index = index;
+	ds->pd = dst->pd->sw + index;
 	ds->drv = drv;
-	ds->tag_protocol = drv->tag_protocol;
+	ds->master_mii_bus = bus;
 
 
 	/*
 	 * Validate supplied switch configuration.
 	 */
-	ds->cpu_port = -1;
 	for (i = 0; i < DSA_MAX_PORTS; i++) {
 		char *name;
 
@@ -115,32 +115,28 @@ dsa_switch_setup(struct device *parent, struct dsa_platform_data *pd,
 			continue;
 
 		if (!strcmp(name, "cpu")) {
-			if (ds->cpu_port != -1) {
+			if (dst->cpu_switch != -1) {
 				printk(KERN_ERR "multiple cpu ports?!\n");
 				ret = -EINVAL;
 				goto out;
 			}
-			ds->cpu_port = i;
+			dst->cpu_switch = index;
+			dst->cpu_port = i;
+		} else if (!strcmp(name, "dsa")) {
+			ds->dsa_port_mask |= 1 << i;
 		} else {
-			ds->valid_port_mask |= 1 << i;
+			ds->phys_port_mask |= 1 << i;
 		}
 	}
 
-	if (ds->cpu_port == -1) {
-		printk(KERN_ERR "no cpu port?!\n");
-		ret = -EINVAL;
-		goto out;
-	}
-
 
 	/*
-	 * If we use a tagging format that doesn't have an ethertype
-	 * field, make sure that all packets from this point on get
-	 * sent to the tag format's receive function.  (Which will
-	 * discard received packets until we set ds->ports[] below.)
+	 * If the CPU connects to this switch, set the switch tree
+	 * tagging protocol to the preferred tagging format of this
+	 * switch.
 	 */
-	wmb();
-	dev->dsa_ptr = (void *)ds;
+	if (ds->dst->cpu_switch == index)
+		ds->dst->tag_protocol = drv->tag_protocol;
 
 
 	/*
@@ -150,7 +146,7 @@ dsa_switch_setup(struct device *parent, struct dsa_platform_data *pd,
 	if (ret < 0)
 		goto out;
 
-	ret = drv->set_addr(ds, dev->dev_addr);
+	ret = drv->set_addr(ds, dst->master_netdev->dev_addr);
 	if (ret < 0)
 		goto out;
 
@@ -169,18 +165,18 @@ dsa_switch_setup(struct device *parent, struct dsa_platform_data *pd,
 	/*
 	 * Create network devices for physical switch ports.
 	 */
-	wmb();
 	for (i = 0; i < DSA_MAX_PORTS; i++) {
 		struct net_device *slave_dev;
 
-		if (!(ds->valid_port_mask & (1 << i)))
+		if (!(ds->phys_port_mask & (1 << i)))
 			continue;
 
 		slave_dev = dsa_slave_create(ds, parent, i, pd->port_names[i]);
 		if (slave_dev == NULL) {
 			printk(KERN_ERR "%s: can't create dsa slave "
-			       "device for port %d(%s)\n",
-			       dev->name, i, pd->port_names[i]);
+			       "device for port %d:%d(%s)\n",
+			       dst->master_netdev->name,
+			       index, i, pd->port_names[i]);
 			continue;
 		}
 
@@ -192,7 +188,6 @@ dsa_switch_setup(struct device *parent, struct dsa_platform_data *pd,
 out_free:
 	mdiobus_free(ds->slave_mii_bus);
 out:
-	dev->dsa_ptr = NULL;
 	kfree(ds);
 	return ERR_PTR(ret);
 }
@@ -212,35 +207,40 @@ static void dsa_switch_destroy(struct dsa_switch *ds)
  */
 bool dsa_uses_dsa_tags(void *dsa_ptr)
 {
-	struct dsa_switch *ds = dsa_ptr;
+	struct dsa_switch_tree *dst = dsa_ptr;
 
-	return !!(ds->tag_protocol == htons(ETH_P_DSA));
+	return !!(dst->tag_protocol == htons(ETH_P_DSA));
 }
 
 bool dsa_uses_trailer_tags(void *dsa_ptr)
 {
-	struct dsa_switch *ds = dsa_ptr;
+	struct dsa_switch_tree *dst = dsa_ptr;
 
-	return !!(ds->tag_protocol == htons(ETH_P_TRAILER));
+	return !!(dst->tag_protocol == htons(ETH_P_TRAILER));
 }
 
 
 /* link polling *************************************************************/
 static void dsa_link_poll_work(struct work_struct *ugly)
 {
-	struct dsa_switch *ds;
+	struct dsa_switch_tree *dst;
+	int i;
+
+	dst = container_of(ugly, struct dsa_switch_tree, link_poll_work);
 
-	ds = container_of(ugly, struct dsa_switch, link_poll_work);
+	for (i = 0; i < dst->pd->nr_switches; i++) {
+		struct dsa_switch *ds = dst->ds[i];
+		ds->drv->poll_link(ds);
+	}
 
-	ds->drv->poll_link(ds);
-	mod_timer(&ds->link_poll_timer, round_jiffies(jiffies + HZ));
+	mod_timer(&dst->link_poll_timer, round_jiffies(jiffies + HZ));
 }
 
-static void dsa_link_poll_timer(unsigned long _ds)
+static void dsa_link_poll_timer(unsigned long _dst)
 {
-	struct dsa_switch *ds = (void *)_ds;
+	struct dsa_switch_tree *dst = (void *)_dst;
 
-	schedule_work(&ds->link_poll_work);
+	schedule_work(&dst->link_poll_work);
 }
 
 
@@ -303,18 +303,14 @@ static int dsa_probe(struct platform_device *pdev)
 	static int dsa_version_printed;
 	struct dsa_platform_data *pd = pdev->dev.platform_data;
 	struct net_device *dev;
-	struct mii_bus *bus;
-	struct dsa_switch *ds;
+	struct dsa_switch_tree *dst;
+	int i;
 
 	if (!dsa_version_printed++)
 		printk(KERN_NOTICE "Distributed Switch Architecture "
 			"driver version %s\n", dsa_driver_version);
 
-	if (pd == NULL || pd->mii_bus == NULL || pd->netdev == NULL)
-		return -EINVAL;
-
-	bus = dev_to_mii_bus(pd->mii_bus);
-	if (bus == NULL)
+	if (pd == NULL || pd->netdev == NULL)
 		return -EINVAL;
 
 	dev = dev_to_net_device(pd->netdev);
@@ -326,36 +322,79 @@ static int dsa_probe(struct platform_device *pdev)
 		return -EEXIST;
 	}
 
-	ds = dsa_switch_setup(&pdev->dev, pd, bus, dev);
-	if (IS_ERR(ds)) {
+	dst = kzalloc(sizeof(*dst), GFP_KERNEL);
+	if (dst == NULL) {
 		dev_put(dev);
-		return PTR_ERR(ds);
+		return -ENOMEM;
 	}
 
-	if (ds->drv->poll_link != NULL) {
-		INIT_WORK(&ds->link_poll_work, dsa_link_poll_work);
-		init_timer(&ds->link_poll_timer);
-		ds->link_poll_timer.data = (unsigned long)ds;
-		ds->link_poll_timer.function = dsa_link_poll_timer;
-		ds->link_poll_timer.expires = round_jiffies(jiffies + HZ);
-		add_timer(&ds->link_poll_timer);
+	platform_set_drvdata(pdev, dst);
+
+	dst->pd = pd;
+	dst->master_netdev = dev;
+	dst->cpu_switch = -1;
+	dst->cpu_port = -1;
+
+	for (i = 0; i < pd->nr_switches; i++) {
+		struct mii_bus *bus;
+		struct dsa_switch *ds;
+
+		bus = dev_to_mii_bus(pd->sw[i].mii_bus);
+		if (bus == NULL) {
+			printk(KERN_ERR "%s: no mii bus found for "
+				"dsa switch %d\n", dev->name, i);
+			continue;
+		}
+
+		ds = dsa_switch_setup(dst, i, &pdev->dev, bus);
+		if (IS_ERR(ds)) {
+			printk(KERN_ERR "%s: couldn't create dsa switch "
+				"instance for switch %d (error %ld)\n",
+				dev->name, i, PTR_ERR(ds));
+			continue;
+		}
+
+		dst->ds[i] = ds;
+		if (ds->drv->poll_link != NULL)
+			dst->link_poll_needed = 1;
 	}
 
-	platform_set_drvdata(pdev, ds);
+	/*
+	 * If we use a tagging format that doesn't have an ethertype
+	 * field, make sure that all packets from this point on get
+	 * sent to the tag format's receive function.
+	 */
+	wmb();
+	dev->dsa_ptr = (void *)dst;
+
+	if (dst->link_poll_needed) {
+		INIT_WORK(&dst->link_poll_work, dsa_link_poll_work);
+		init_timer(&dst->link_poll_timer);
+		dst->link_poll_timer.data = (unsigned long)dst;
+		dst->link_poll_timer.function = dsa_link_poll_timer;
+		dst->link_poll_timer.expires = round_jiffies(jiffies + HZ);
+		add_timer(&dst->link_poll_timer);
+	}
 
 	return 0;
 }
 
 static int dsa_remove(struct platform_device *pdev)
 {
-	struct dsa_switch *ds = platform_get_drvdata(pdev);
+	struct dsa_switch_tree *dst = platform_get_drvdata(pdev);
+	int i;
 
-	if (ds->drv->poll_link != NULL)
-		del_timer_sync(&ds->link_poll_timer);
+	if (dst->link_poll_needed)
+		del_timer_sync(&dst->link_poll_timer);
 
 	flush_scheduled_work();
 
-	dsa_switch_destroy(ds);
+	for (i = 0; i < dst->pd->nr_switches; i++) {
+		struct dsa_switch *ds = dst->ds[i];
+
+		if (ds != NULL)
+			dsa_switch_destroy(ds);
+	}
 
 	return 0;
 }
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 7063378..e6b4e83 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -19,42 +19,107 @@
 
 struct dsa_switch {
 	/*
-	 * Configuration data for the platform device that owns
-	 * this dsa switch instance.
+	 * Parent switch tree, and switch index.
 	 */
-	struct dsa_platform_data	*pd;
+	struct dsa_switch_tree	*dst;
+	int			index;
 
 	/*
-	 * References to network device and mii bus to use.
+	 * Configuration data for this switch.
 	 */
-	struct net_device		*master_netdev;
-	struct mii_bus			*master_mii_bus;
+	struct dsa_switch_data	*pd;
 
 	/*
-	 * The used switch driver and frame tagging type.
+	 * The used switch driver.
 	 */
 	struct dsa_switch_driver	*drv;
-	__be16				tag_protocol;
+
+	/*
+	 * Reference to mii bus to use.
+	 */
+	struct mii_bus		*master_mii_bus;
 
 	/*
 	 * Slave mii_bus and devices for the individual ports.
 	 */
-	int				cpu_port;
-	u32				valid_port_mask;
-	struct mii_bus			*slave_mii_bus;
-	struct net_device		*ports[DSA_MAX_PORTS];
+	u32			dsa_port_mask;
+	u32			phys_port_mask;
+	struct mii_bus		*slave_mii_bus;
+	struct net_device	*ports[DSA_MAX_PORTS];
+};
+
+struct dsa_switch_tree {
+	/*
+	 * Configuration data for the platform device that owns
+	 * this dsa switch tree instance.
+	 */
+	struct dsa_platform_data	*pd;
+
+	/*
+	 * Reference to network device to use, and which tagging
+	 * protocol to use.
+	 */
+	struct net_device	*master_netdev;
+	__be16			tag_protocol;
+
+	/*
+	 * The switch and port to which the CPU is attached.
+	 */
+	s8			cpu_switch;
+	s8			cpu_port;
 
 	/*
 	 * Link state polling.
 	 */
-	struct work_struct		link_poll_work;
-	struct timer_list		link_poll_timer;
+	int			link_poll_needed;
+	struct work_struct	link_poll_work;
+	struct timer_list	link_poll_timer;
+
+	/*
+	 * Data for the individual switch chips.
+	 */
+	struct dsa_switch	*ds[DSA_MAX_SWITCHES];
 };
 
+static inline bool dsa_is_cpu_port(struct dsa_switch *ds, int p)
+{
+	return !!(ds->index == ds->dst->cpu_switch && p == ds->dst->cpu_port);
+}
+
+static inline u8 dsa_upstream_port(struct dsa_switch *ds)
+{
+	struct dsa_switch_tree *dst = ds->dst;
+
+	/*
+	 * If this is the root switch (i.e. the switch that connects
+	 * to the CPU), return the cpu port number on this switch.
+	 * Else return the (DSA) port number that connects to the
+	 * switch that is one hop closer to the cpu.
+	 */
+	if (dst->cpu_switch == ds->index)
+		return dst->cpu_port;
+	else
+		return ds->pd->rtable[dst->cpu_switch];
+}
+
 struct dsa_slave_priv {
+	/*
+	 * The linux network interface corresponding to this
+	 * switch port.
+	 */
 	struct net_device	*dev;
+
+	/*
+	 * Which switch this port is a part of, and the port index
+	 * for this port.
+	 */
 	struct dsa_switch	*parent;
-	int			port;
+	u8			port;
+
+	/*
+	 * The phylib phy_device pointer for the PHY connected
+	 * to this port.
+	 */
 	struct phy_device	*phy;
 };
 
diff --git a/net/dsa/mv88e6060.c b/net/dsa/mv88e6060.c
index 85081ae..d56bfe0 100644
--- a/net/dsa/mv88e6060.c
+++ b/net/dsa/mv88e6060.c
@@ -81,7 +81,7 @@ static int mv88e6060_switch_reset(struct dsa_switch *ds)
 	/*
 	 * Reset the switch.
 	 */
-	REG_WRITE(REG_GLOBAL, 0x0A, 0xa130);
+	REG_WRITE(REG_GLOBAL, 0x0a, 0xa130);
 
 	/*
 	 * Wait up to one second for reset to complete.
@@ -128,7 +128,7 @@ static int mv88e6060_setup_port(struct dsa_switch *ds, int p)
 	 * state to Forwarding.  Additionally, if this is the CPU
 	 * port, enable Ingress and Egress Trailer tagging mode.
 	 */
-	REG_WRITE(addr, 0x04, (p == ds->cpu_port) ? 0x4103 : 0x0003);
+	REG_WRITE(addr, 0x04, dsa_is_cpu_port(ds, p) ?  0x4103 : 0x0003);
 
 	/*
 	 * Port based VLAN map: give each port its own address
@@ -138,9 +138,8 @@ static int mv88e6060_setup_port(struct dsa_switch *ds, int p)
 	 */
 	REG_WRITE(addr, 0x06,
 			((p & 0xf) << 12) |
-			 ((p == ds->cpu_port) ?
-				ds->valid_port_mask :
-				(1 << ds->cpu_port)));
+			 (dsa_is_cpu_port(ds, p) ?
+				ds->phys_port_mask : (1 << ds->dst->cpu_port)));
 
 	/*
 	 * Port Association Vector: when learning source addresses
diff --git a/net/dsa/mv88e6123_61_65.c b/net/dsa/mv88e6123_61_65.c
index ec8c6a0..2e2e794 100644
--- a/net/dsa/mv88e6123_61_65.c
+++ b/net/dsa/mv88e6123_61_65.c
@@ -98,11 +98,11 @@ static int mv88e6123_61_65_setup_global(struct dsa_switch *ds)
 		return ret;
 
 	/*
-	 * Configure the cpu port, and configure the cpu port as the
-	 * port to which ingress and egress monitor frames are to be
-	 * sent.
+	 * Configure the upstream port, and configure the upstream
+	 * port as the port to which ingress and egress monitor frames
+	 * are to be sent.
 	 */
-	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1110));
+	REG_WRITE(REG_GLOBAL, 0x1a, (dsa_upstream_port(ds) * 0x1110));
 
 	/*
 	 * Disable remote management for now, and set the switch's
@@ -133,10 +133,17 @@ static int mv88e6123_61_65_setup_global(struct dsa_switch *ds)
 	REG_WRITE(REG_GLOBAL2, 0x05, 0x00ff);
 
 	/*
-	 * Map all DSA device IDs to the CPU port.
+	 * Program the DSA routing table.
 	 */
-	for (i = 0; i < 32; i++)
-		REG_WRITE(REG_GLOBAL2, 0x06, 0x8000 | (i << 8) | ds->cpu_port);
+	for (i = 0; i < 32; i++) {
+		int nexthop;
+
+		nexthop = 0x1f;
+		if (i != ds->index && i < ds->dst->pd->nr_switches)
+			nexthop = ds->pd->rtable[i] & 0x1f;
+
+		REG_WRITE(REG_GLOBAL2, 0x06, 0x8000 | (i << 8) | nexthop);
+	}
 
 	/*
 	 * Clear all trunk masks.
@@ -176,6 +183,7 @@ static int mv88e6123_61_65_setup_global(struct dsa_switch *ds)
 static int mv88e6123_61_65_setup_port(struct dsa_switch *ds, int p)
 {
 	int addr = REG_PORT(p);
+	u16 val;
 
 	/*
 	 * MAC Forcing register: don't force link, speed, duplex
@@ -192,37 +200,46 @@ static int mv88e6123_61_65_setup_port(struct dsa_switch *ds, int p)
 
 	/*
 	 * Port Control: disable Drop-on-Unlock, disable Drop-on-Lock,
-	 * configure the requested (DSA/EDSA) tagging mode if this is
-	 * the CPU port, disable Header mode, enable IGMP/MLD snooping,
-	 * disable VLAN tunneling, determine priority by looking at
-	 * 802.1p and IP priority fields (IP prio has precedence), and
-	 * set STP state to Forwarding.  Finally, if this is the CPU
-	 * port, additionally enable forwarding of unknown unicast and
-	 * multicast addresses.
-	 */
-	REG_WRITE(addr, 0x04,
-			(p == ds->cpu_port) ?
-			 (ds->tag_protocol == htons(ETH_P_DSA)) ?
-			  0x053f : 0x373f :
-			 0x0433);
+	 * disable Header mode, enable IGMP/MLD snooping, disable VLAN
+	 * tunneling, determine priority by looking at 802.1p and IP
+	 * priority fields (IP prio has precedence), and set STP state
+	 * to Forwarding.
+	 *
+	 * If this is the upstream port for this switch, enable
+	 * forwarding of unknown unicasts and multicasts.
+	 *
+	 * If this is a link to another switch, use DSA tagging mode.
+	 *
+	 * If this is the CPU link, use DSA or EDSA tagging depending
+	 * on which tagging mode was configured.
+	 */
+	val = 0x0433;
+	if (p == dsa_upstream_port(ds))
+		val |= 0x000c;
+	if (ds->dsa_port_mask & (1 << p))
+		val |= 0x0100;
+	if (dsa_is_cpu_port(ds, p) && ds->dst->tag_protocol == htons(ETH_P_EDSA))
+		val |= 0x3300;
+	REG_WRITE(addr, 0x04, val);
 
 	/*
 	 * Port Control 1: disable trunking.  Also, if this is the
 	 * CPU port, enable learn messages to be sent to this port.
 	 */
-	REG_WRITE(addr, 0x05, (p == ds->cpu_port) ? 0x8000 : 0x0000);
+	REG_WRITE(addr, 0x05, dsa_is_cpu_port(ds, p) ? 0x8000 : 0x0000);
 
 	/*
 	 * Port based VLAN map: give each port its own address
 	 * database, allow the CPU port to talk to each of the 'real'
 	 * ports, and allow each of the 'real' ports to only talk to
-	 * the CPU port.
-	 */
-	REG_WRITE(addr, 0x06,
-			((p & 0xf) << 12) |
-			 ((p == ds->cpu_port) ?
-				ds->valid_port_mask :
-				(1 << ds->cpu_port)));
+	 * the upstream port.
+	 */
+	val = (p & 0xf) << 12;
+	if (dsa_is_cpu_port(ds, p))
+		val |= ds->phys_port_mask;
+	else
+		val |= 1 << dsa_upstream_port(ds);
+	REG_WRITE(addr, 0x06, val);
 
 	/*
 	 * Default VLAN ID and priority: don't set a default VLAN
diff --git a/net/dsa/mv88e6131.c b/net/dsa/mv88e6131.c
index 4e24eca..61f07d4 100644
--- a/net/dsa/mv88e6131.c
+++ b/net/dsa/mv88e6131.c
@@ -102,11 +102,11 @@ static int mv88e6131_setup_global(struct dsa_switch *ds)
 	REG_WRITE(REG_GLOBAL, 0x19, 0x8100);
 
 	/*
-	 * Disable ARP mirroring, and configure the cpu port as the
-	 * port to which ingress and egress monitor frames are to be
-	 * sent.
+	 * Disable ARP mirroring, and configure the upstream port as
+	 * the port to which ingress and egress monitor frames are to
+	 * be sent.
 	 */
-	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);
+	REG_WRITE(REG_GLOBAL, 0x1a, (dsa_upstream_port(ds) * 0x1100) | 0x00f0);
 
 	/*
 	 * Disable cascade port functionality, and set the switch's
@@ -129,10 +129,17 @@ static int mv88e6131_setup_global(struct dsa_switch *ds)
 	REG_WRITE(REG_GLOBAL2, 0x05, 0x00ff);
 
 	/*
-	 * Map all DSA device IDs to the CPU port.
+	 * Program the DSA routing table.
 	 */
-	for (i = 0; i < 32; i++)
-		REG_WRITE(REG_GLOBAL2, 0x06, 0x8000 | (i << 8) | ds->cpu_port);
+	for (i = 0; i < 32; i++) {
+		int nexthop;
+
+		nexthop = 0x1f;
+		if (i != ds->index && i < ds->dst->pd->nr_switches)
+			nexthop = ds->pd->rtable[i] & 0x1f;
+
+		REG_WRITE(REG_GLOBAL2, 0x06, 0x8000 | (i << 8) | nexthop);
+	}
 
 	/*
 	 * Clear all trunk masks.
@@ -158,13 +165,14 @@ static int mv88e6131_setup_global(struct dsa_switch *ds)
 static int mv88e6131_setup_port(struct dsa_switch *ds, int p)
 {
 	int addr = REG_PORT(p);
+	u16 val;
 
 	/*
 	 * MAC Forcing register: don't force link, speed, duplex
 	 * or flow control state to any particular values on physical
 	 * ports, but force the CPU port to 1000 Mb/s full duplex.
 	 */
-	if (p == ds->cpu_port)
+	if (dsa_is_cpu_port(ds, p))
 		REG_WRITE(addr, 0x01, 0x003e);
 	else
 		REG_WRITE(addr, 0x01, 0x0003);
@@ -175,29 +183,40 @@ static int mv88e6131_setup_port(struct dsa_switch *ds, int p)
 	 * enable IGMP/MLD snoop, disable DoubleTag, disable VLAN
 	 * tunneling, determine priority by looking at 802.1p and
 	 * IP priority fields (IP prio has precedence), and set STP
-	 * state to Forwarding.  Finally, if this is the CPU port,
-	 * additionally enable DSA tagging and forwarding of unknown
-	 * unicast addresses.
+	 * state to Forwarding.
+	 *
+	 * If this is the upstream port for this switch, enable
+	 * forwarding of unknown unicasts, and enable DSA tagging
+	 * mode.
+	 *
+	 * If this is the link to another switch, use DSA tagging
+	 * mode, but do not enable forwarding of unknown unicasts.
 	 */
-	REG_WRITE(addr, 0x04, (p == ds->cpu_port) ? 0x0537 : 0x0433);
+	val = 0x0433;
+	if (p == dsa_upstream_port(ds))
+		val |= 0x0004;
+	if (ds->dsa_port_mask & (1 << p))
+		val |= 0x0100;
+	REG_WRITE(addr, 0x04, val);
 
 	/*
 	 * Port Control 1: disable trunking.  Also, if this is the
 	 * CPU port, enable learn messages to be sent to this port.
 	 */
-	REG_WRITE(addr, 0x05, (p == ds->cpu_port) ? 0x8000 : 0x0000);
+	REG_WRITE(addr, 0x05, dsa_is_cpu_port(ds, p) ? 0x8000 : 0x0000);
 
 	/*
 	 * Port based VLAN map: give each port its own address
 	 * database, allow the CPU port to talk to each of the 'real'
 	 * ports, and allow each of the 'real' ports to only talk to
-	 * the CPU port.
+	 * the upstream port.
 	 */
-	REG_WRITE(addr, 0x06,
-			((p & 0xf) << 12) |
-			 ((p == ds->cpu_port) ?
-				ds->valid_port_mask :
-				(1 << ds->cpu_port)));
+	val = (p & 0xf) << 12;
+	if (dsa_is_cpu_port(ds, p))
+		val |= ds->phys_port_mask;
+	else
+		val |= 1 << dsa_upstream_port(ds);
+	REG_WRITE(addr, 0x06, val);
 
 	/*
 	 * Default VLAN ID and priority: don't set a default VLAN
@@ -213,13 +232,15 @@ static int mv88e6131_setup_port(struct dsa_switch *ds, int p)
 	 * untagged frames on this port, do a destination address
 	 * lookup on received packets as usual, don't send a copy
 	 * of all transmitted/received frames on this port to the
-	 * CPU, and configure the CPU port number.  Also, if this
-	 * is the CPU port, enable forwarding of unknown multicast
-	 * addresses.
+	 * CPU, and configure the upstream port number.
+	 *
+	 * If this is the upstream port for this switch, enable
+	 * forwarding of unknown multicast addresses.
 	 */
-	REG_WRITE(addr, 0x08,
-			((p == ds->cpu_port) ? 0x00c0 : 0x0080) |
-			 ds->cpu_port);
+	val = 0x0080 | dsa_upstream_port(ds);
+	if (p == dsa_upstream_port(ds))
+		val |= 0x0040;
+	REG_WRITE(addr, 0x08, val);
 
 	/*
 	 * Rate Control: disable ingress rate limiting.
diff --git a/net/dsa/mv88e6xxx.h b/net/dsa/mv88e6xxx.h
index eb0e0aa..09f13b2 100644
--- a/net/dsa/mv88e6xxx.h
+++ b/net/dsa/mv88e6xxx.h
@@ -19,7 +19,7 @@ struct mv88e6xxx_priv_state {
 	/*
 	 * When using multi-chip addressing, this mutex protects
 	 * access to the indirect access registers.  (In single-chip
-	 * mode, this mutex is effectively useless.)
+	 * addressing mode, this mutex is effectively useless.)
 	 */
 	struct mutex	smi_mutex;
 
@@ -89,5 +89,4 @@ void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds,
 	})
 
 
-
 #endif
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 99114e5..eaa7a22 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -19,7 +19,7 @@ static int dsa_slave_phy_read(struct mii_bus *bus, int addr, int reg)
 {
 	struct dsa_switch *ds = bus->priv;
 
-	if (ds->valid_port_mask & (1 << addr))
+	if (ds->phys_port_mask & (1 << addr))
 		return ds->drv->phy_read(ds, addr, reg);
 
 	return 0xffff;
@@ -29,7 +29,7 @@ static int dsa_slave_phy_write(struct mii_bus *bus, int addr, int reg, u16 val)
 {
 	struct dsa_switch *ds = bus->priv;
 
-	if (ds->valid_port_mask & (1 << addr))
+	if (ds->phys_port_mask & (1 << addr))
 		return ds->drv->phy_write(ds, addr, reg, val);
 
 	return 0;
@@ -43,7 +43,7 @@ void dsa_slave_mii_bus_init(struct dsa_switch *ds)
 	ds->slave_mii_bus->write = dsa_slave_phy_write;
 	snprintf(ds->slave_mii_bus->id, MII_BUS_ID_SIZE, "%s:%.2x",
 			ds->master_mii_bus->id, ds->pd->sw_addr);
-	ds->slave_mii_bus->parent = &(ds->master_mii_bus->dev);
+	ds->slave_mii_bus->parent = &ds->master_mii_bus->dev;
 }
 
 
@@ -51,9 +51,8 @@ void dsa_slave_mii_bus_init(struct dsa_switch *ds)
 static int dsa_slave_init(struct net_device *dev)
 {
 	struct dsa_slave_priv *p = netdev_priv(dev);
-	struct net_device *master = p->parent->master_netdev;
 
-	dev->iflink = master->ifindex;
+	dev->iflink = p->parent->dst->master_netdev->ifindex;
 
 	return 0;
 }
@@ -61,7 +60,7 @@ static int dsa_slave_init(struct net_device *dev)
 static int dsa_slave_open(struct net_device *dev)
 {
 	struct dsa_slave_priv *p = netdev_priv(dev);
-	struct net_device *master = p->parent->master_netdev;
+	struct net_device *master = p->parent->dst->master_netdev;
 	int err;
 
 	if (!(master->flags & IFF_UP))
@@ -99,7 +98,7 @@ out:
 static int dsa_slave_close(struct net_device *dev)
 {
 	struct dsa_slave_priv *p = netdev_priv(dev);
-	struct net_device *master = p->parent->master_netdev;
+	struct net_device *master = p->parent->dst->master_netdev;
 
 	dev_mc_unsync(master, dev);
 	dev_unicast_unsync(master, dev);
@@ -117,7 +116,7 @@ static int dsa_slave_close(struct net_device *dev)
 static void dsa_slave_change_rx_flags(struct net_device *dev, int change)
 {
 	struct dsa_slave_priv *p = netdev_priv(dev);
-	struct net_device *master = p->parent->master_netdev;
+	struct net_device *master = p->parent->dst->master_netdev;
 
 	if (change & IFF_ALLMULTI)
 		dev_set_allmulti(master, dev->flags & IFF_ALLMULTI ? 1 : -1);
@@ -128,7 +127,7 @@ static void dsa_slave_change_rx_flags(struct net_device *dev, int change)
 static void dsa_slave_set_rx_mode(struct net_device *dev)
 {
 	struct dsa_slave_priv *p = netdev_priv(dev);
-	struct net_device *master = p->parent->master_netdev;
+	struct net_device *master = p->parent->dst->master_netdev;
 
 	dev_mc_sync(master, dev);
 	dev_unicast_sync(master, dev);
@@ -137,7 +136,7 @@ static void dsa_slave_set_rx_mode(struct net_device *dev)
 static int dsa_slave_set_mac_address(struct net_device *dev, void *a)
 {
 	struct dsa_slave_priv *p = netdev_priv(dev);
-	struct net_device *master = p->parent->master_netdev;
+	struct net_device *master = p->parent->dst->master_netdev;
 	struct sockaddr *addr = a;
 	int err;
 
@@ -341,7 +340,7 @@ struct net_device *
 dsa_slave_create(struct dsa_switch *ds, struct device *parent,
 		 int port, char *name)
 {
-	struct net_device *master = ds->master_netdev;
+	struct net_device *master = ds->dst->master_netdev;
 	struct net_device *slave_dev;
 	struct dsa_slave_priv *p;
 	int ret;
@@ -356,7 +355,7 @@ dsa_slave_create(struct dsa_switch *ds, struct device *parent,
 	memcpy(slave_dev->dev_addr, master->dev_addr, ETH_ALEN);
 	slave_dev->tx_queue_len = 0;
 
-	switch (ds->tag_protocol) {
+	switch (ds->dst->tag_protocol) {
 #ifdef CONFIG_NET_DSA_TAG_DSA
 	case htons(ETH_P_DSA):
 		slave_dev->netdev_ops = &dsa_netdev_ops;
diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c
index f99a019..237e419 100644
--- a/net/dsa/tag_dsa.c
+++ b/net/dsa/tag_dsa.c
@@ -36,7 +36,7 @@ int dsa_xmit(struct sk_buff *skb, struct net_device *dev)
 		 * Construct tagged FROM_CPU DSA tag from 802.1q tag.
 		 */
 		dsa_header = skb->data + 2 * ETH_ALEN;
-		dsa_header[0] = 0x60;
+		dsa_header[0] = 0x60 | p->parent->index;
 		dsa_header[1] = p->port << 3;
 
 		/*
@@ -57,7 +57,7 @@ int dsa_xmit(struct sk_buff *skb, struct net_device *dev)
 		 * Construct untagged FROM_CPU DSA tag.
 		 */
 		dsa_header = skb->data + 2 * ETH_ALEN;
-		dsa_header[0] = 0x40;
+		dsa_header[0] = 0x40 | p->parent->index;
 		dsa_header[1] = p->port << 3;
 		dsa_header[2] = 0x00;
 		dsa_header[3] = 0x00;
@@ -65,7 +65,7 @@ int dsa_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	skb->protocol = htons(ETH_P_DSA);
 
-	skb->dev = p->parent->master_netdev;
+	skb->dev = p->parent->dst->master_netdev;
 	dev_queue_xmit(skb);
 
 	return NETDEV_TX_OK;
@@ -78,11 +78,13 @@ out_free:
 static int dsa_rcv(struct sk_buff *skb, struct net_device *dev,
 		   struct packet_type *pt, struct net_device *orig_dev)
 {
-	struct dsa_switch *ds = dev->dsa_ptr;
+	struct dsa_switch_tree *dst = dev->dsa_ptr;
+	struct dsa_switch *ds;
 	u8 *dsa_header;
+	int source_device;
 	int source_port;
 
-	if (unlikely(ds == NULL))
+	if (unlikely(dst == NULL))
 		goto out_drop;
 
 	skb = skb_unshare(skb, GFP_ATOMIC);
@@ -105,9 +107,17 @@ static int dsa_rcv(struct sk_buff *skb, struct net_device *dev,
 		goto out_drop;
 
 	/*
-	 * Check that the source port is a registered DSA port.
+	 * Determine source port and device.
 	 */
+	source_device = dsa_header[0] & 0x1f;
 	source_port = (dsa_header[1] >> 3) & 0x1f;
+
+	/*
+	 * Check that the source device/port combo is valid.
+	 */
+	if (source_device >= dst->pd->nr_switches)
+		goto out_drop;
+	ds = dst->ds[source_device];
 	if (source_port >= DSA_MAX_PORTS || ds->ports[source_port] == NULL)
 		goto out_drop;
 
diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c
index 328ec95..8606941 100644
--- a/net/dsa/tag_edsa.c
+++ b/net/dsa/tag_edsa.c
@@ -45,7 +45,7 @@ int edsa_xmit(struct sk_buff *skb, struct net_device *dev)
 		edsa_header[1] = ETH_P_EDSA & 0xff;
 		edsa_header[2] = 0x00;
 		edsa_header[3] = 0x00;
-		edsa_header[4] = 0x60;
+		edsa_header[4] = 0x60 | p->parent->index;
 		edsa_header[5] = p->port << 3;
 
 		/*
@@ -70,7 +70,7 @@ int edsa_xmit(struct sk_buff *skb, struct net_device *dev)
 		edsa_header[1] = ETH_P_EDSA & 0xff;
 		edsa_header[2] = 0x00;
 		edsa_header[3] = 0x00;
-		edsa_header[4] = 0x40;
+		edsa_header[4] = 0x40 | p->parent->index;
 		edsa_header[5] = p->port << 3;
 		edsa_header[6] = 0x00;
 		edsa_header[7] = 0x00;
@@ -78,7 +78,7 @@ int edsa_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	skb->protocol = htons(ETH_P_EDSA);
 
-	skb->dev = p->parent->master_netdev;
+	skb->dev = p->parent->dst->master_netdev;
 	dev_queue_xmit(skb);
 
 	return NETDEV_TX_OK;
@@ -91,11 +91,13 @@ out_free:
 static int edsa_rcv(struct sk_buff *skb, struct net_device *dev,
 		    struct packet_type *pt, struct net_device *orig_dev)
 {
-	struct dsa_switch *ds = dev->dsa_ptr;
+	struct dsa_switch_tree *dst = dev->dsa_ptr;
+	struct dsa_switch *ds;
 	u8 *edsa_header;
+	int source_device;
 	int source_port;
 
-	if (unlikely(ds == NULL))
+	if (unlikely(dst == NULL))
 		goto out_drop;
 
 	skb = skb_unshare(skb, GFP_ATOMIC);
@@ -118,9 +120,17 @@ static int edsa_rcv(struct sk_buff *skb, struct net_device *dev,
 		goto out_drop;
 
 	/*
-	 * Check that the source port is a registered DSA port.
+	 * Determine source port and device.
 	 */
+	source_device = edsa_header[0] & 0x1f;
 	source_port = (edsa_header[1] >> 3) & 0x1f;
+
+	/*
+	 * Check that the source port is a registered DSA port.
+	 */
+	if (source_device >= dst->pd->nr_switches)
+		goto out_drop;
+	ds = dst->ds[source_device];
 	if (source_port >= DSA_MAX_PORTS || ds->ports[source_port] == NULL)
 		goto out_drop;
 
diff --git a/net/dsa/tag_trailer.c b/net/dsa/tag_trailer.c
index b591328..d8f9ecf 100644
--- a/net/dsa/tag_trailer.c
+++ b/net/dsa/tag_trailer.c
@@ -59,7 +59,7 @@ int trailer_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	nskb->protocol = htons(ETH_P_TRAILER);
 
-	nskb->dev = p->parent->master_netdev;
+	nskb->dev = p->parent->dst->master_netdev;
 	dev_queue_xmit(nskb);
 
 	return NETDEV_TX_OK;
@@ -68,12 +68,14 @@ int trailer_xmit(struct sk_buff *skb, struct net_device *dev)
 static int trailer_rcv(struct sk_buff *skb, struct net_device *dev,
 		       struct packet_type *pt, struct net_device *orig_dev)
 {
-	struct dsa_switch *ds = dev->dsa_ptr;
+	struct dsa_switch_tree *dst = dev->dsa_ptr;
+	struct dsa_switch *ds;
 	u8 *trailer;
 	int source_port;
 
-	if (unlikely(ds == NULL))
+	if (unlikely(dst == NULL))
 		goto out_drop;
+	ds = dst->ds[0];
 
 	skb = skb_unshare(skb, GFP_ATOMIC);
 	if (skb == NULL)

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Mon, Mar 02, 2009 at 11:05:29PM +0100, Jesper Dangaard Brouer wrote:

> >>My understanding is that this should work via the VLAN map?
> 
> I think that the "VLAN map/table" has gotten a wrong name as it does not 
> really determine the VLANs, it only says who can talk to whom.  The switch 
> does support a real vlan setup, but its deactivated in Lennerts driver, as 
> I guess he wants Linux to handle the VLANs.  (I use the real VLAN setup 
> extensively in my driver).

I have some patches that make use of this (see the earlier h/w
bridging patch I posted to netdev@ -- I've extended that to handle
VLANs as well).  Without those patches, each port will just have its
own address database.


> >>I checked that setup and it looks OK.
> 
> I have also checked the different registers setting, and things looks 
> quite alright.  Although I'm missing the register datasheets for the 6131 
> chip, I found that I only have part 1 of 3 crap...
> 
> I did find that the 6095 and 6097 does differ in the way DSA handling is 
> done, as the 6097 supports Ethertype DSA and 6095 don't.  But the 6131 
> driver looks like it does the right thing for the 6095.

For the gigabit switches, there are more or less two groups of
switches from a register programming point of view.

Group 1:
- models: 6045, 6045f, 6092, 6095, 6095f, 6121, 6122,
  6131, 6152, 6155, 6182, 6185
- Support Header and DSA tagging.
- MAC address programmed directly via global 1/2/3.
- PPU handling generally needed.

Group 2:
- models: 6046, 6046f, 6085, 6096 (FE), 6097, 6097f, 6123, 6161, 6165 
- Support Header, DSA and Ethertype DSA tagging.
- MAC address programmed indirectly via global 1/2.
- PPU handling generally not needed.
- Extended stats access via bits [8:5]

(And of course, various advanced queueing/filtering capabilities are
only available in the higher end switches, but we don't use those
capabilities for now.)

So the 6095 is in the first group and the 6097 in the second.

The 6131 driver can probably be very easily extended to handle all
switches in the first group, and the 6123/6161/6165 driver can probably
be easily extended to handle all switches in the second group.

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Mon, Mar 02, 2009 at 08:22:17AM -0700, Gary Thomas wrote:

> >>> You should write 0x003E ... see attached patch
> >> Ups, I see (from the thread) that you have already done/tried this...
> > 
> > Yes, although I think it will need some work in the future
> > (I've set it to 1000Mb connection, you said you used 100Mb, etc)
> > 
> > Question: I'm testing this by trying a ping out of my box.
> > Linux replies by sending an ARP packet out, and the destination
> > replies with an ARP packet in.  I can see from the ethtool stats
> > that the reply packets get into lan1.1 (the physical port I'm
> > using), but I don't see them get moved through the CPU port.
> > My understanding is that this should work via the VLAN map?
> > I checked that setup and it looks OK.
> > 
> > Any ideas where this might be going wrong?
> 
> I also just noticed that the ESA registers (Global 1,2,3)
> aren't set at all.

This is done by mv88e6xxx_set_addr_{in,}direct() in mv88e6xxx.c,
via the ->set_addr() callback.

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Mon, Mar 02, 2009 at 11:56:22AM +0100, Jesper Dangaard Brouer wrote:
> 
>>> The main conclusion so far is that this write (net/dsa/mv88e6131.c):
>>>
>>> 	/*
>>> 	 * MAC Forcing register: don't force link, speed, duplex
>>> 	 * or flow control state to any particular values.
>>> 	 */
>>> 	REG_WRITE(addr, 0x01, 0x0003);
>> This sort of enables auto-detection of speed.
>>
>>> isn't correct on ports that can either be CPU ports or external ports.
>> For external ports I had to enabled the PPU to allow the external PHYs
>> to negotiate.
> 
> The PPU should be re-enabled 10ms after the last MII access.
> 
> 
>> Also, on external PHYs ports 8 and 9, I write 0x0403 not 0x0003 (to
>> register 0x1, PCS Control Register).  Which also enables inband
>> auto-negotiation, but I'm not sure this is necessary.
> 
> Not sure whether it is.  Gary?
> 

I'm not sure either.  On my system, these ports are SERDES used to
cascade switches.  When we get that part working, we may learn if
these bits are important.

> 
>>> Forcing the link up on the CPU port helps somewhat, but things aren't
>>> 100% working yet.
>> On the CPU port I force link-up and force speed+duplex setting.  I only
>> got 100Mbit/s to the CPU port...
> 
> I suppose the cpu port speed should be made into a platform data
> config option in case there's only a 100 Mb/s link on a gigabit
> capable switch?

I agree.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

Jesper Dangaard Brouer wrote:
> 
> On Fri, 27 Feb 2009, Lennert Buytenhek wrote:
>> On Fri, Feb 27, 2009 at 08:44:53AM -0700, Gary Thomas wrote:
>>
>> Perhaps we should take this off-list..
> 
> I'm still interrested... please Cc. me at jdb@comx.dk.

Hi Jesper,

Lennert and I have been working on this and we have parts of
it working (PowerPC GIANFAR 1000Mb driver).  I can get the
basic switch recognized and packets go out, but nothing seems
to come back in.

I'll continue to work on this and let you know of the progress.
Lennert is away for a few days, so the actual progress may be
a bit slow...

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Sat, 28 Feb 2009, Gary Thomas wrote:

> Jesper Dangaard Brouer wrote:
>>
>> On Fri, 27 Feb 2009, Lennert Buytenhek wrote:
>>> On Fri, Feb 27, 2009 at 08:44:53AM -0700, Gary Thomas wrote:
>>>
>>> Perhaps we should take this off-list..
>>
>> I'm still interrested... please Cc. me at jdb@comx.dk.
>
> Hi Jesper,
>
> Lennert and I have been working on this and we have parts of
> it working (PowerPC GIANFAR 1000Mb driver).  I can get the
> basic switch recognized and packets go out, but nothing seems
> to come back in.

Strange behavior...

If you will send me the current patches/code, then I'll use some time 
monday to look at the register settings to see if I can spot the problem, 
by corrolating with my device driver.


> I'll continue to work on this and let you know of the progress.
> Lennert is away for a few days, so the actual progress may be
> a bit slow...

Thanks for keeping me in the loop :-)

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------

Re: Marvell 88E609x switch?

[Gary Thomas]

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

Jesper Dangaard Brouer wrote:
> On Sat, 28 Feb 2009, Gary Thomas wrote:
> 
>> Jesper Dangaard Brouer wrote:
>>>
>>> On Fri, 27 Feb 2009, Lennert Buytenhek wrote:
>>>> On Fri, Feb 27, 2009 at 08:44:53AM -0700, Gary Thomas wrote:
>>>>
>>>> Perhaps we should take this off-list..
>>>
>>> I'm still interrested... please Cc. me at jdb@comx.dk.
>>
>> Hi Jesper,
>>
>> Lennert and I have been working on this and we have parts of
>> it working (PowerPC GIANFAR 1000Mb driver).  I can get the
>> basic switch recognized and packets go out, but nothing seems
>> to come back in.
> 
> Strange behavior...
> 
> If you will send me the current patches/code, then I'll use some time
> monday to look at the register settings to see if I can spot the
> problem, by corrolating with my device driver.
> 

I'm using the 6131 driver (which is mostly the same as the 6095).
There are no other changes other than to force the link on the
CPU port (10).  Actual changes attached.   Note: the HACK in
the 'get_ethtool_stats' is so I can peek at the CPU port info,
using one of the unused external ports.

> 
>> I'll continue to work on this and let you know of the progress.
>> Lennert is away for a few days, so the actual progress may be
>> a bit slow...
> 
> Thanks for keeping me in the loop :-)

Thanks for any ideas you might have.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 2134 bytes --]

Index: net/dsa/mv88e6131.c
===================================================================
--- net/dsa/mv88e6131.c	(.../test1-2008-08-14-branch/tools/linuxppc-2.6/net/dsa)	(revision 4831)
+++ net/dsa/mv88e6131.c	(.../test2-2009-02-24-branch/tools/linuxppc-2.6/net/dsa)	(working copy)
@@ -19,8 +19,11 @@
 	int ret;
 
 	ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
+        printk("%s(%p, %d) = %d\n", __FUNCTION__, bus, sw_addr, ret);
 	if (ret >= 0) {
 		ret &= 0xfff0;
+		if (ret == 0x0950)
+			return "Marvell 88E6095/88E6095F";
 		if (ret == 0x1060)
 			return "Marvell 88E6131";
 	}
@@ -36,7 +39,7 @@
 	/*
 	 * Set all ports to the disabled state.
 	 */
-	for (i = 0; i < 8; i++) {
+	for (i = 0; i < 11; i++) {
 		ret = REG_READ(REG_PORT(i), 0x04);
 		REG_WRITE(REG_PORT(i), 0x04, ret & 0xfffc);
 	}
@@ -91,7 +94,7 @@
 	 * Configure the priority mapping registers.
 	 */
 	ret = mv88e6xxx_config_prio(ds);
-	if (ret < 0)
+        if (ret < 0)
 		return ret;
 
 	/*
@@ -161,8 +164,11 @@
 	 * MAC Forcing register: don't force link, speed, duplex
 	 * or flow control state to any particular values.
 	 */
-	REG_WRITE(addr, 0x01, 0x0003);
-
+//	REG_WRITE(addr, 0x01, 0x0003);
+	if (p == ds->cpu_port)
+		REG_WRITE(addr, 0x01, 0x003E);
+	else
+		REG_WRITE(addr, 0x01, 0x0003);
 	/*
 	 * Port Control: disable Core Tag, disable Drop-on-Lock,
 	 * transmit frames unmodified, disable Header mode,
@@ -268,7 +274,7 @@
 	if (ret < 0)
 		return ret;
 
-	for (i = 0; i < 6; i++) {
+	for (i = 0; i < 11; i++) {
 		ret = mv88e6131_setup_port(ds, i);
 		if (ret < 0)
 			return ret;
@@ -279,7 +285,7 @@
 
 static int mv88e6131_port_to_phy_addr(int port)
 {
-	if (port >= 0 && port != 3 && port <= 7)
+	if (port >= 0 && port <= 11)
 		return port;
 	return -1;
 }
@@ -343,6 +349,12 @@
 mv88e6131_get_ethtool_stats(struct dsa_switch *ds,
 				  int port, uint64_t *data)
 {
+    // HACK
+    if (port == 7) {
+        printk("%s(%d) => CPU\n", __FUNCTION__, port);
+        port = 10;        
+    }
+    // HACK
 	mv88e6xxx_get_ethtool_stats(ds, ARRAY_SIZE(mv88e6131_hw_stats),
 				    mv88e6131_hw_stats, port, data);
 }

Re: Marvell 88E609x switch?

[Jesper Dangaard Brouer]

On Sat, 2009-02-28 at 20:10 +0100, Jesper Dangaard Brouer wrote:

> If you will send me the current patches/code, then I'll use some time 
> monday to look at the register settings to see if I can spot the problem, 
> by corrolating with my device driver.

Looking through my old code I found this comment, which indicate that
you should take care of PPU (Phy Polling Unit) state... I had to support
both the 6095 and 6097 chip.

Cite code:

 /*** Setup PHY's ***/
 /*
   Accessing the PHY devices is special.  Direct access to a PHY
   device requires that the PPU (Phy Polling Unit) has been
   disabled.  The 6097 series support indirect access through SMI
   registers (GLOBAL_DEV2 registers 0x18 and 0x19).

   Disabling the PPU _here_ is not necessary, as the drivers R/W
   operation handles disabling the PPU or does indirect SMI access
   (if supported by the chip).

   Notice, that there is a catch with the 6097 SMI access, as it
   requires the PPU to be enabled (or else it will returns
   0xFFFF).
 */

Thus, you should make sure that the PPU is disabled during setup of the
PHYs.

Well, I don't think this will solve all your issues... I'm still looking
for the missing link...

-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Mon, Mar 02, 2009 at 11:14:45AM +0100, Jesper Dangaard Brouer wrote:

> > If you will send me the current patches/code, then I'll use some time 
> > monday to look at the register settings to see if I can spot the problem, 
> > by corrolating with my device driver.
> 
> Looking through my old code I found this comment, which indicate that
> you should take care of PPU (Phy Polling Unit) state... I had to support
> both the 6095 and 6097 chip.

PPU disabling/enabling should be handled by the current code already,
as it is also necessary for the 6131 (but not for the 6161/6165/etc).

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 05:25:06AM -0700, Gary Thomas wrote:

> >>>>>>>> Is there support for this device anywhere?  In particular,
> >>>>>>>> the M88E6095 switch.
> >>>>>>> Not at the moment, but it should be easy enough to add.  If your
> >>>>>>> board already runs on 2.6.28+, I can whip up some patches for you
> >>>>>>> to try from the docs I have for that part.
> >>>>>> That would be much appreciated, thanks.
> >>>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
> >>>>> as the register set goes.  So something along these lines (hacky
> >>>>> patch, breaks 6131, not for mainline) might just work to detect
> >>>>> single 6095s (cascading DSA chips is something that needs more work,
> >>>>> let's get the single-chip case working first).
> >>>>>
> >>>>> The other thing you'll need to do is create dsa platform devices
> >>>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
> >>>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
> >>>>> device * for your network device, a struct device * for your mii bus,
> >>>>> the switch MII address on the MII bus, and names of the individual
> >>>>> ports (where you'll specify "cpu" for the port on the switch chip that
> >>>>> the CPU is connected to).
> >>>>>
> >>>>> Let me know if this works.
> >>>> Thanks, I'll give it a try.  It will take a little effort
> >>>> to get setup as I have to work within the open firmware
> >>>> structure (that's how all the various components are
> >>>> specified).
> >>> Right, we don't have OF bindings yet.  I guess this would make sense
> >>> to do generically at some point, since there are quite a few PPC
> >>> platforms with DSA switch chips.
> >> Here's what I tried - (patch attached) - a trulyhorrible hack,
> >> but I've not figured out how to get the correct device pointers
> >> from the OF world yet.  The boot log shows that it's trying, but
> >> I don't see the DSA layer (M88E690x driver) doing the MII indirection
> >> that's needed for this device.
> >>
> >> I'm probably not starting it up correctly, but I think I followed
> >> the examples you cited.  Any ideas?
> > 
> > "indirection needed for this device" -- does that mean that your
> > switch chip is configured to use the multi-chip addressing mode?
> > (It looks like it, as most of the MII addresses return ffff in
> > their ID registers.)  If yes, you should set ->sw_addr to whatever
> > MII address the chip has been assigned.
> 
> Much better, my switch seems to be found now.
> 
>   Distributed Switch Architecture driver version 0.1
>   gfar_mdio_read(cf9db400, 1, 0) = 1811
>   gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
>   gfar_mdio_read(cf9db400, 1, 0) = 1a03
>   gfar_mdio_read(cf9db400, 1, 1) = 953
>   mv88e6131_probe(cf9db400, 1) = 2387

That looks like the proper indirect access sequence.


>   eth0: detected a Marvell 88E6095/88E6095F switch

Yay.


>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
>   24520:01:01  24520:01:03  24520:01:05  24520:01:07

That looks good too.


> However, the network subsystem still can't locate it.  It may be
> a complication of the OF stuff and how the [gianfar] network
> device knows what PHY to look at.
> 
>   starting network interfaces...
>   24520:01 not found
>   eth0: Could not attach to PHY

It's correct that eth0 should not associate with a PHY -- since the
MAC connects to the switch chip over GMII/RGMII/SGMII, there is no
PHY involved.

Is the gianfar driver refusing to up the interface without a PHY?
It shouldn't do that -- IMHO it's perfectly fine to not have a PHY
on your ethernet MAC.


> Also, how do I specify the [implicit] route within the switch
> that connects '24520:01:00' to the CPU port '24520:01:0A' (if
> there was such a thing)?  My boot loader has configured the
> switch for this path - I've not looked through the log to see
> what the DSA layer did.

Just specify "cpu" as the port name of port 10 in your dsa platform
data (assuming that there's where your CPU is), that'll take care of
it.

Does it give you Linux network interfaces for the other switch chip
ports (1-8)?


thanks,
Lennert

Re: Marvell 88E609x switch?

[Gary Thomas]

Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 05:25:06AM -0700, Gary Thomas wrote:
> 
>>>>>>>>>> Is there support for this device anywhere?  In particular,
>>>>>>>>>> the M88E6095 switch.
>>>>>>>>> Not at the moment, but it should be easy enough to add.  If your
>>>>>>>>> board already runs on 2.6.28+, I can whip up some patches for you
>>>>>>>>> to try from the docs I have for that part.
>>>>>>>> That would be much appreciated, thanks.
>>>>>>> I noticed that the 6095/6095F are quite similar to the 6131 as far
>>>>>>> as the register set goes.  So something along these lines (hacky
>>>>>>> patch, breaks 6131, not for mainline) might just work to detect
>>>>>>> single 6095s (cascading DSA chips is something that needs more work,
>>>>>>> let's get the single-chip case working first).
>>>>>>>
>>>>>>> The other thing you'll need to do is create dsa platform devices
>>>>>>> for your switch chips, a la how it's done in arch/arm/mach-orion5x/
>>>>>>> or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
>>>>>>> device * for your network device, a struct device * for your mii bus,
>>>>>>> the switch MII address on the MII bus, and names of the individual
>>>>>>> ports (where you'll specify "cpu" for the port on the switch chip that
>>>>>>> the CPU is connected to).
>>>>>>>
>>>>>>> Let me know if this works.
>>>>>> Thanks, I'll give it a try.  It will take a little effort
>>>>>> to get setup as I have to work within the open firmware
>>>>>> structure (that's how all the various components are
>>>>>> specified).
>>>>> Right, we don't have OF bindings yet.  I guess this would make sense
>>>>> to do generically at some point, since there are quite a few PPC
>>>>> platforms with DSA switch chips.
>>>> Here's what I tried - (patch attached) - a trulyhorrible hack,
>>>> but I've not figured out how to get the correct device pointers
>>>> from the OF world yet.  The boot log shows that it's trying, but
>>>> I don't see the DSA layer (M88E690x driver) doing the MII indirection
>>>> that's needed for this device.
>>>>
>>>> I'm probably not starting it up correctly, but I think I followed
>>>> the examples you cited.  Any ideas?
>>> "indirection needed for this device" -- does that mean that your
>>> switch chip is configured to use the multi-chip addressing mode?
>>> (It looks like it, as most of the MII addresses return ffff in
>>> their ID registers.)  If yes, you should set ->sw_addr to whatever
>>> MII address the chip has been assigned.
>> Much better, my switch seems to be found now.
>>
>>   Distributed Switch Architecture driver version 0.1
>>   gfar_mdio_read(cf9db400, 1, 0) = 1811
>>   gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
>>   gfar_mdio_read(cf9db400, 1, 0) = 1a03
>>   gfar_mdio_read(cf9db400, 1, 1) = 953
>>   mv88e6131_probe(cf9db400, 1) = 2387
> 
> That looks like the proper indirect access sequence.
> 
> 
>>   eth0: detected a Marvell 88E6095/88E6095F switch
> 
> Yay.
> 
> 
>>   root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
>>   24520:01:00  24520:01:02  24520:01:04  24520:01:06
>>   24520:01:01  24520:01:03  24520:01:05  24520:01:07
> 
> That looks good too.
> 
> 
>> However, the network subsystem still can't locate it.  It may be
>> a complication of the OF stuff and how the [gianfar] network
>> device knows what PHY to look at.
>>
>>   starting network interfaces...
>>   24520:01 not found
>>   eth0: Could not attach to PHY
> 
> It's correct that eth0 should not associate with a PHY -- since the
> MAC connects to the switch chip over GMII/RGMII/SGMII, there is no
> PHY involved.

Yes, but it's expecting to be able to talk to the PHYLIB layer
and ask things like speed, duplex, link state, etc.

> Is the gianfar driver refusing to up the interface without a PHY?
> It shouldn't do that -- IMHO it's perfectly fine to not have a PHY
> on your ethernet MAC.
> 

It seems so, yes.  I tried disabling the PHY connection in the OF
tree and now eth0 doesn't even try to come up :-(

> 
>> Also, how do I specify the [implicit] route within the switch
>> that connects '24520:01:00' to the CPU port '24520:01:0A' (if
>> there was such a thing)?  My boot loader has configured the
>> switch for this path - I've not looked through the log to see
>> what the DSA layer did.
> 
> Just specify "cpu" as the port name of port 10 in your dsa platform
> data (assuming that there's where your CPU is), that'll take care of
> it.
> 
> Does it give you Linux network interfaces for the other switch chip
> ports (1-8)?

Not sure I understand this question, there are no other network
interfaces listed:

root@ppc_target:~ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compresse
d
    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0
0


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Marvell 88E609x switch?

[Lennert Buytenhek]

On Fri, Feb 27, 2009 at 06:22:40AM -0700, Gary Thomas wrote:

> >> However, the network subsystem still can't locate it.  It may be
> >> a complication of the OF stuff and how the [gianfar] network
> >> device knows what PHY to look at.
> >>
> >>   starting network interfaces...
> >>   24520:01 not found
> >>   eth0: Could not attach to PHY
> > 
> > It's correct that eth0 should not associate with a PHY -- since the
> > MAC connects to the switch chip over GMII/RGMII/SGMII, there is no
> > PHY involved.
> 
> Yes, but it's expecting to be able to talk to the PHYLIB layer
> and ask things like speed, duplex, link state, etc.
> 
> > Is the gianfar driver refusing to up the interface without a PHY?
> > It shouldn't do that -- IMHO it's perfectly fine to not have a PHY
> > on your ethernet MAC.
> 
> It seems so, yes.  I tried disabling the PHY connection in the OF
> tree and now eth0 doesn't even try to come up :-(

gianfar authors/maintainers: is there a way of using gianfar purely
as a (R)(G)MII transport, i.e. without it trying to talk to a PHY?
Gary is trying to use it to just pass packets to another
(R)(G)MII-speaking chip that doesn't have a PHY interface, but gianfar
seems to bail out if you don't give it a PHY to talk to.

Re: Marvell 88E609x switch?

[Anton Vorontsov]

On Fri, Feb 27, 2009 at 03:25:48PM +0100, Lennert Buytenhek wrote:
> On Fri, Feb 27, 2009 at 06:22:40AM -0700, Gary Thomas wrote:
> 
> > >> However, the network subsystem still can't locate it.  It may be
> > >> a complication of the OF stuff and how the [gianfar] network
> > >> device knows what PHY to look at.
> > >>
> > >>   starting network interfaces...
> > >>   24520:01 not found
> > >>   eth0: Could not attach to PHY
> > > 
> > > It's correct that eth0 should not associate with a PHY -- since the
> > > MAC connects to the switch chip over GMII/RGMII/SGMII, there is no
> > > PHY involved.
> > 
> > Yes, but it's expecting to be able to talk to the PHYLIB layer
> > and ask things like speed, duplex, link state, etc.
> > 
> > > Is the gianfar driver refusing to up the interface without a PHY?
> > > It shouldn't do that -- IMHO it's perfectly fine to not have a PHY
> > > on your ethernet MAC.
> > 
> > It seems so, yes.  I tried disabling the PHY connection in the OF
> > tree and now eth0 doesn't even try to come up :-(
> 
> gianfar authors/maintainers: is there a way of using gianfar purely
> as a (R)(G)MII transport, i.e. without it trying to talk to a PHY?
> Gary is trying to use it to just pass packets to another
> (R)(G)MII-speaking chip that doesn't have a PHY interface, but gianfar
> seems to bail out if you don't give it a PHY to talk to.

You can use fixed-link property in the device tree, and CONFIG_FIXED_PHY
driver. See arch/powerpc/boot/dts/mpc8349emitx.dts as an example, and
Documentation/powerpc/dts-bindings/fsl/tsec.txt for the fixed-link's
fields meaning.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: Marvell 88E609x switch?

[Gary Thomas]

Anton Vorontsov wrote:
> On Fri, Feb 27, 2009 at 03:25:48PM +0100, Lennert Buytenhek wrote:
>> On Fri, Feb 27, 2009 at 06:22:40AM -0700, Gary Thomas wrote:
>>
>>>>> However, the network subsystem still can't locate it.  It may be
>>>>> a complication of the OF stuff and how the [gianfar] network
>>>>> device knows what PHY to look at.
>>>>>
>>>>>   starting network interfaces...
>>>>>   24520:01 not found
>>>>>   eth0: Could not attach to PHY
>>>> It's correct that eth0 should not associate with a PHY -- since the
>>>> MAC connects to the switch chip over GMII/RGMII/SGMII, there is no
>>>> PHY involved.
>>> Yes, but it's expecting to be able to talk to the PHYLIB layer
>>> and ask things like speed, duplex, link state, etc.
>>>
>>>> Is the gianfar driver refusing to up the interface without a PHY?
>>>> It shouldn't do that -- IMHO it's perfectly fine to not have a PHY
>>>> on your ethernet MAC.
>>> It seems so, yes.  I tried disabling the PHY connection in the OF
>>> tree and now eth0 doesn't even try to come up :-(
>> gianfar authors/maintainers: is there a way of using gianfar purely
>> as a (R)(G)MII transport, i.e. without it trying to talk to a PHY?
>> Gary is trying to use it to just pass packets to another
>> (R)(G)MII-speaking chip that doesn't have a PHY interface, but gianfar
>> seems to bail out if you don't give it a PHY to talk to.
> 
> You can use fixed-link property in the device tree, and CONFIG_FIXED_PHY
> driver. See arch/powerpc/boot/dts/mpc8349emitx.dts as an example, and
> Documentation/powerpc/dts-bindings/fsl/tsec.txt for the fixed-link's
> fields meaning.
> 

Yes, thanks, that seems to work.  I can at least now get eth0
starting to come up - still problems with the actual switch.

Can you give me some guidance on my question (linuxppc-devel list 2009-02-26)
with subject 'OF -> platform_device'?  This is needed in order to
use this switch and the DSA layer.

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------