|Aleksandr Rybalko||Jan 20, 2012 12:12 pm|
|Stefan Bethke||Jan 20, 2012 3:34 pm|
|Stefan Bethke||Jan 22, 2012 7:30 am|
|Aleksandr Rybalko||Jan 22, 2012 9:51 am|
|Adrian Chadd||Jan 24, 2012 11:12 pm|
|Stefan Bethke||Jan 25, 2012 12:57 am|
|Adrian Chadd||Jan 26, 2012 10:03 pm|
|Aleksandr Rybalko||Jan 28, 2012 2:12 pm|
|Juli Mallett||Jan 28, 2012 2:59 pm|
|Warner Losh||Jan 28, 2012 11:05 pm|
|Aleksandr Rybalko||Jan 29, 2012 3:14 am|
|Stefan Bethke||Jan 29, 2012 4:25 am|
|Aleksandr Rybalko||Jan 29, 2012 4:43 am|
|Stefan Bethke||Jan 29, 2012 4:48 am|
|Stefan Bethke||Jan 29, 2012 5:14 am|
|Marius Strobl||Jan 29, 2012 7:31 am|
|Stefan Bethke||Jan 29, 2012 8:00 am|
|Marius Strobl||Jan 29, 2012 8:19 am|
|Stefan Bethke||Jan 29, 2012 8:21 am|
|Marius Strobl||Jan 29, 2012 9:31 am|
|Adrian Chadd||Jan 29, 2012 10:59 am|
|Marius Strobl||Jan 29, 2012 2:12 pm|
|Subject:||Re: Ethernet Switch Framework|
|From:||Aleksandr Rybalko (ra...@ddteam.net)|
|Date:||Jan 28, 2012 2:12:28 pm|
On Wed, 25 Jan 2012 09:57:32 +0100 Stefan Bethke <st...@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 <adr...@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. :)
-- Aleksandr Rybalko <ra...@ddteam.net>
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "free...@freebsd.org"