Date: Sat, 11 Feb 2012 14:45:44 +0200 From: Aleksandr Rybalko <ray@ddteam.net> To: Marius Strobl <marius@alchemy.franken.de> Cc: Juli Mallett <jmallett@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, FreeBSD-arch <freebsd-arch@freebsd.org>, Aleksandr Rybalko <ray@freebsd.org>, Stefan Bethke <stb@lassitu.de> Subject: Re: Extending sys/dev/mii Message-ID: <20120211144544.c91701d9.ray@ddteam.net> In-Reply-To: <20120211111731.GE39861@alchemy.franken.de> References: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <F60B2B70-049F-4497-BBA8-3C421088C1EA@lassitu.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <AF2CF7A4-27B8-4181-96F5-7998B126CD1C@lassitu.de> <CAJ-VmomcgC6V-sY7jN%2Bh6T7uPfVesPBV%2BKPu2TVD4YDKrdk4LQ@mail.gmail.com> <20120211111731.GE39861@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Good day hackers! On Sat, 11 Feb 2012 12:17:31 +0100 Marius Strobl <marius@alchemy.franken.de> wrote: > On Fri, Feb 10, 2012 at 09:23:21PM -0800, Adrian Chadd wrote: > > Hi all, > > > > So where'd we get to with this? > > > > I'd like to finalise a unified proposal for this. > > > > I still like the idea of tidying up the miibus/mdiobus stuff (ie, > > miibus really is an mdiobus for speaking to things, along with some > > methods to do MII stuff like media change, media set, MAC PLL/type > > set, etc) but I agree with ray@ that things begin to look a _lot_ > > more complicated when we start trying to handle alternate methods > > of how switches are connected. > > > > So I'd like to not lose interest on this. > > > > If we can't come to some kind of consensus, I'll just commit ray@'s > > work (and cop the flak) then work with stb@ to tidy up the newbus > > bits to hopefully be better for the long term. > > > > In summary - I'm fed up that we're this close to having _something_ > > that looks like a workable switch API and working code but it's not > > in the tree. So I'm happy stirring up trouble and copping the flak > > from things if it means it Just Gets Done. > > > > I haven't seen ray@'s work (where is it?) There is thread about it: http://lists.freebsd.org/pipermail/freebsd-net/2012-January/031132.html > but the general approach > sounds backwards to me. As you say the whole picture of how switches > are connected in reality is complicated. Therefore I'd like to see a > proposal for a framework first that can handle the various ways of > taking to a switch (GPIO, I2C, MDIO etc or combinations thereof) Currently framework handle OBIO(memory attached) and MDIO, but designed to handle various bus attachment. And as i see GPIO variant must use some bus attached to GPIO (f.e. gpiospi, gpioiic), the switch framework attach to it. When i design framework core, i was keep in mind that: 1. some switches can be controlled with many ways (BCM53115 can be controlled by MDIO and SPI). 2. MAC driver must not be modified, as long as possible. if_arge was modified only to clear special bits like phymask from it. > separately from a MAC (as there may be no MAC associated with the > switch to begin with). The stuff proposed so far (again, I haven't > looked at ray@'s current work) only dealt with the more or less > low hanging fruit in that picture with discussions how we may hack > some more scenarios into working. Getting _something_ in at this > stage just for the sake that there's something in the tree really > asks for one of two typical things happening: > o it sticks as-is forever as nobody really wants to do the work > to get it right and in the end the supposedly generic framework > is ignored and people implement their own local stuff to get what > they need, or > o there actually are some brave souls working on getting it right > over time but requiring API and ABI breakages over and over again > to get there. I think second is near to be true :), but last time i add methods to manipulate Port based VLANs on BCM53115, and 1) i'm not add anything to ioctl definitions (switch_ioctl.h), 2) most of newbus methods have defaults, so adding new feature to some driver, will not break other drivers. Updated work accessible here: http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/switch/ > > Marius > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" -- Aleksandr Rybalko <ray@ddteam.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120211144544.c91701d9.ray>