Date: Wed, 25 Jan 2012 09:57:32 +0100 From: Stefan Bethke <stb@lassitu.de> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-net@freebsd.org, Aleksandr Rybalko <ray@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework Message-ID: <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> In-Reply-To: <CAJ-VmokTh2q0ZH=kwU6GzJm5Mr4k7geJiFsoX_A9hcLhMZNxsg@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 25.01.2012 um 08:12 schrieb Adrian Chadd: > So when will you two have something consensus-y to commit? :-) >=20 > What I'm hoping for is: >=20 > * some traction on the MII bus / MDIO bus split and tidyup from stb, = which is nice; > * ray's switch API for speaking to userland with; > * agreeing on whether the correct place to put the driver(s) is where = stb, ray, or a mix of both approaches says so. >=20 > I've been (mostly) trying to stay out of this to see where both of you = have gone. I think we've made some good progress; now it's time to = solidify a design for the first pass of what we want in -HEAD and figure = out how to move forward. My suggestion is to take my bus attachment code (incl. mdio and = miiproxy) and ray's ioctl and userland code. 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. 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. =46rom 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. Having a description of the generic switch model that the API assumes = and driver-specific documentation also wouldn't hurt. (Yes, I'm = volunteering.) Stefan --=20 Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE>