Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Jan 2012 00:12:51 +0200
From:      Aleksandr Rybalko <ray@ddteam.net>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        freebsd-net@freebsd.org, Aleksandr Rybalko <ray@freebsd.org>, Stefan Bethke <stb@lassitu.de>, freebsd-arch@freebsd.org
Subject:   Re: Ethernet Switch Framework
Message-ID:  <20120129001251.7e4cfe83.ray@ddteam.net>
In-Reply-To: <CAJ-Vmo=GRKRf%2BYsFqNm9d_T3Tq583uV_pabMV6ozuaytSRLivg@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> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <CAJ-Vmo=GRKRf%2BYsFqNm9d_T3Tq583uV_pabMV6ozuaytSRLivg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 25 Jan 2012 09:57:32 +0100
Stefan Bethke <stb@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 <adrian@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. :)

> 
> 
> Adrian

WBW
-- 
Aleksandr Rybalko <ray@ddteam.net>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120129001251.7e4cfe83.ray>