netdev - Re: Marvell 88E609x switch?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090227145746.GD17040@xi.wantstofly.org>
Date:	Fri, 27 Feb 2009 15:57:46 +0100
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	Gary Thomas <gary@...assoc.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Marvell 88E609x switch?

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@..._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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html