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: <49B64CF5.9090508@mlbassoc.com>
Date:	Tue, 10 Mar 2009 05:20:21 -0600
From:	Gary Thomas <gary@...assoc.com>
To:	Lennert Buytenhek <buytenh@...tstofly.org>
CC:	jdb@...x.dk, Jesper Dangaard Brouer <hawk@...u.dk>,
	netdev <netdev@...r.kernel.org>
Subject: Re: Marvell 88E609x switch?

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

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

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

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

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

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

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

Thanks for your help


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
--
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