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: <20090311151208.GF4738@xi.wantstofly.org>
Date:	Wed, 11 Mar 2009 16:12:08 +0100
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	Gary Thomas <gary@...assoc.com>
Cc:	jdb@...x.dk, Jesper Dangaard Brouer <hawk@...u.dk>,
	netdev <netdev@...r.kernel.org>
Subject: Re: Marvell 88E609x switch?

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

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ