Extending sys/dev/mii

[Aleksandr Rybalko]

Good day hackers!

On Sat, 11 Feb 2012 12:17:31 +0100
Marius Strobl <marius at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to
> "freebsd-arch-unsubscribe at freebsd.org"


-- 
Aleksandr Rybalko <ray at ddteam.net>