Date: Sun, 29 Jan 2012 00:12:51 +0200 From: Aleksandr Rybalko <ray@ddteam.net> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-net@freebsd.org, Aleksandr Rybalko <ray@freebsd.org>, Stefan Bethke <stb@lassitu.de>, freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework Message-ID: <20120129001251.7e4cfe83.ray@ddteam.net> In-Reply-To: <CAJ-Vmo=GRKRf%2BYsFqNm9d_T3Tq583uV_pabMV6ozuaytSRLivg@mail.gmail.com> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <CAJ-VmokTh2q0ZH=kwU6GzJm5Mr4k7geJiFsoX_A9hcLhMZNxsg@mail.gmail.com> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <CAJ-Vmo=GRKRf%2BYsFqNm9d_T3Tq583uV_pabMV6ozuaytSRLivg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Jan 2012 09:57:32 +0100 Stefan Bethke <stb@lassitu.de> 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 <adrian@freebsd.org> 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 <ray@ddteam.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120129001251.7e4cfe83.ray>