From owner-freebsd-embedded@FreeBSD.ORG Tue May 15 06:42:06 2012 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DFC7106564A; Tue, 15 May 2012 06:42:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4BE798FC18; Tue, 15 May 2012 06:42:06 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8038132pbb.13 for ; Mon, 14 May 2012 23:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=HTWk+1T23tt1nfTlz42BcTw1evYpyHmJV89NENLlsqk=; b=wuIiX9Ahfa7BoVheaVU4RLmDuQPslc+kwpSxkuOFtukPnjoTawxQ/+7XSA4lT7OAay kN8jJkvxvMxSVXyoRv32pZ2HkWNbcIBv0vFoYC4fT0+obJTPXmP6/MYGwjL2DAmGkxyu JjwjxCiOyy/WhdSh0xLriV26FoUDUfMlboAPa8o53h82PSHAuCW6VMckzTUoK1+mTtuQ u+c69KkP5zbO7g65GwXNB7zGIlAcg1DrGRBaa+qavzi5L49CvDW5S+4XNgXcZjTKBZ5H wL1Oh09281cQ6Uw3oHl5FRWuGzTJIpr6Ptb5GLDmJkcQL0PEfNGI3vihcaKcuwOsaoPL 6W6A== MIME-Version: 1.0 Received: by 10.68.191.196 with SMTP id ha4mr2129915pbc.146.1337064125884; Mon, 14 May 2012 23:42:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.203.2 with HTTP; Mon, 14 May 2012 23:42:05 -0700 (PDT) Date: Mon, 14 May 2012 23:42:05 -0700 X-Google-Sender-Auth: XaU9y74YTLZbA7H3u-e_cWk8ffE Message-ID: From: Adrian Chadd To: freebsd-embedded@freebsd.org, freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [heads up] etherswitch is now slowly making it's appearance into -HEAD X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 06:42:06 -0000 Hi all, I've committed the beginnings of etherswitch support into HEAD. It comes to you from Stefan and Ray, with input (read: more example working code) from Juli/Patrick. I went with Stefan's architectural design primarily because I thought it was closer along the path to what would be "clean" and most flexible. It turned out that it indeed did spawn discussion during BSDcan along these very lines (thanks Warner!) so hopefully we'll see some upcoming work there. Ray's work went above and beyond this, exploring all of the other quirky weirdnesses that switch devices seem to have. This heavily influenced my decision about exactly what should be committed in the first pass. I've limited the commit to _almost_ the bare minimum required to bring the switch up and poll/configure each PHY. The only non-bare-minimum option (for now) is the vlan group support, just so Stefan and I can use it on the RTL8366RB units. The VLAN ID (per port) support isn't in there yet, as I'm not entirely sure what the API should look like. The architecture can be found in his wiki page: http://wiki.freebsd.org/StefanBethke/EtherSwitch I've committed the initial RTL8366RB support from Stefan, as well as AR8316/AR7240/AR7241 switch support from Ray/Stefan. I haven't yet tested the AR8216 (and I know the port initialisation code is all wrong), nor have I tested the AR8316 connected to the AR7242 SoC. I'm sure Ray, Stefan and I will do a lot more testing in the next couple of weeks. :) There's a whole lot more work to be done. Specifically: * We need to bring over the other bus and switch chip support that Ray has coded up, from the zrouter.org project. Again, enough to bring up individual PHYs from each switch, in a way that lets us initialise the device, poll the PHYs and configure them as needed. * Ray's work has a much larger API for programming things. I've left that out in this initial commit so (a) we have something in the tree that we can all start to use (even if we can't configure VLANs just yet) and (b) I don't want to commit to some API design without a bunch more discussion and experimenting. * I need to review how the locking is or isn't handled, especially for bus operations for the atheros switch PHYs. * There's quite a few discussions to be had with regards to newbus extensions and perhaps some miibus changes. * We still have to address some of the things that floatphy fixes - especially the port status But, the basic support is there and I'm able to see per-port PHY handling for my switch devices. To ray, stefan and juli/patrick - thanks so much for taking this particular project on board. I'm glad that someone stepped in and researched the bigger picture(s) here. I'll continue hacking on Atheros switch PHY support as needed; but I'd like to leave the rest of this work to others to design, improve and complain to me when I haven't committed anything. :) G'night, Adrian