From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 22:38:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99D72106566C; Sat, 28 Jan 2012 22:38:36 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0401D8FC13; Sat, 28 Jan 2012 22:38:35 +0000 (UTC) Received: by eaaa14 with SMTP id a14so1120452eaa.13 for ; Sat, 28 Jan 2012 14:38:34 -0800 (PST) Received: by 10.213.25.78 with SMTP id y14mr1955869ebb.139.1327788787920; Sat, 28 Jan 2012 14:13:07 -0800 (PST) Received: from rnote.ddteam.net (238-239-92-178.pool.ukrtel.net. [178.92.239.238]) by mx.google.com with ESMTPS id n56sm49505525eeh.6.2012.01.28.14.13.04 (version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 14:13:06 -0800 (PST) Date: Sun, 29 Jan 2012 00:12:51 +0200 From: Aleksandr Rybalko To: Adrian Chadd Message-Id: <20120129001251.7e4cfe83.ray@ddteam.net> In-Reply-To: References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Aleksandr Rybalko , Stefan Bethke , freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 22:38:36 -0000 On Wed, 25 Jan 2012 09:57:32 +0100 Stefan Bethke wrote: > My suggestion is to take my bus attachment code (incl. mdio and > miiproxy) and ray's ioctl and userland code. As I see from your patch, mdio/miiproxy require special bits in MAC driver. When I design switch framework, I keeping in mind that MAC drivers should be standard as possible, that why I send you patch http://my.ddteam.net/files/2012-01-22_arge.patch which clean most phymask features from if_arge driver. You may ask me why I do so? It is because arge H/W is not the single implementation, it is just FPGA design that also used in many other devices, f.e. if_et. Look into dev/et/if_etreg.h, begin from line: #define ET_MAC_CFG1 0x5000 There is the same registers, same logic, just mapped at 0x5000 in device PCI BAR, instead of 0x19000000(arge) and I bet it is not last time when that FPGA design used :) > > Aleksandr's approach for the driver attachment is to have a generic > switch "bus" driver that abstracts the mii, i2c, memory mapped I/O, > etc. busses the devices are physically attached to, and present a > uniform register file to the chip-specific switch driver. I believe > that this is unnecessarily complicated for two reasons: newbus > already provides that abstraction, and chip-specific drivers usually > differ in so many aspects, including their register files, that code > sharing between chips will be somewhat limited anyway. newbus allow attach anything to anything, but bus interfaces implemented in different ways (for mem/mdio we call read/write, for SPI/IIC we call transfer). When we made that interfaces consistent we be able really forget about "bus glue". While we still not done it(even still not doing it), model with single parent (switch0) require bus glue for each supported interface (MDIO, MEM, SPI, etc.). But model with direct attach driver to bus will require bus glue per driver. If only one interface is supported, then glue in driver file, else - separate file per each supported interface. And two words about "complicated": 1. If we about complicated structure of devices - yes switch0 with bcm5325_switch0 more complicated, than just bcm5325_switch0, but device tree will care about it. 2. If we about code size, then I will say my model much smaller even having more drivers. My personal decision - is 2, because - less code better for maintenance. > > One aspect that I would enjoy looking into in more detail is how > register accesses on, for example, MDIO, can be provided through the > bus space API. From my cursory reading, it seems that the code > currently is tailored towards register accesses that can be > implemented through CPU native instructions, instead of indirectly > through a controller. > > Aleksandr has defined a quite comprehensive ethernet switch control > API that the framework provides towards in-kernel clients as well as > userland. I think it would be really helpful if we could concentrate > on those API functions that can be controlled through the userland > utility, have immediate use cases (for example, VLAN configuration on > the TL-WR1043ND to separate the WAN from the LAN ports), and we have > test hardware for. In short, don't commit dead code. It is not dead code, it is TODO :) > > Having a description of the generic switch model that the API assumes > and driver-specific documentation also wouldn't hurt. (Yes, I'm > volunteering.) It is also TODO :) On Thu, 26 Jan 2012 22:03:58 -0800 Adrian Chadd wrote: > Ok, I do like the idea of: > > * mdiobus/miibus proxy tidyup; > * then the switch API; > * then the switch devices themselves. > > Can we get some consensus/agreement from Marius (and others) about the > first step? I think we don't need to "rewrite" miibus now. :) > > > Adrian WBW -- Aleksandr Rybalko