Am 25.01.2012 um 08:12 schrieb Adrian Chadd: > So when will you two have something consensus-y to commit? :-) > > What I'm hoping for is: > > * 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. > > 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. 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. 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 -- Stefan Bethke <s...@lassitu.de> Fon +49 151 14070811 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
