| Message ID | 49A73E00.7050406@mlbassoc.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
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. -- 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
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 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?
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 -- 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
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? -- 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
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, };
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
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? -- 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
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
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. -- 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
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. -- 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
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)?
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? -- 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
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?
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? -- 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
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
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. -- 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
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.
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.
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
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? -- 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
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.
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? -- 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
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?
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.. -- 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
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 ------------------------------------------------------------------- -- 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
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. -- 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
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...
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 ------------------------------------------------------------------- -- 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
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...
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). -- 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
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) {