Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Dec 2011 15:50:54 +0100
From:      Stefan Bethke <stb@lassitu.de>
To:        Adrian Chadd <adrian@freebsd.org>, Aleksandr Rybalko <ray@freebsd.org>
Cc:        freebsd-embedded@freebsd.org
Subject:   Re: TL-WR1043: switch
Message-ID:  <D86C7618-7CF8-4913-985B-00EF85BA110D@lassitu.de>
In-Reply-To: <CAJ-VmokES0svxckV10uF8dF_z5XgzWzXjh50fbGeo6TsEU_6jQ@mail.gmail.com>
References:  <68ABED76-CB1F-405A-8036-EC254F7511FA@lassitu.de> <3B3DB17D-BF87-40EE-B1C1-445F178E8844@lassitu.de> <86030CEE-6839-4B96-ACDC-2BA9AC1E4AE4@lassitu.de> <2D625CC9-A0E3-47AA-A504-CE8FB2F90245@lassitu.de> <203BF1C8-D528-40C9-8611-9C7AC7E43BAB@lassitu.de> <3C0E9CA3-E130-4E9A-ABCC-1782E28999D1@lassitu.de> <CAJ-VmomWsGy9wMb0zA-WjTRP6Qh%2BO2u_Pe-rgkerFFpi04iKnw@mail.gmail.com> <6387ABA5-AC55-49DD-9058-E45CC0A3E0A0@lassitu.de> <CAJ-VmonM91s-kbbEqVDy9PvtH-gxLWYmusGiqzqCWMtfMdoo2A@mail.gmail.com> <EA0807C1-6FEE-4743-8DCA-1AC873664005@lassitu.de> <74E4AF57-3D22-415E-B913-176753B09B16@lassitu.de> <710E2C7A-E9AC-4103-8C61-0EDC4A3AF9DE@lassitu.de> <CAJ-Vmo=zn7K35Tk%2BkoHs8Kba9C9ypMCdJjSU=2O1TfwohV9GzQ@mail.gmail.com> <E2992227-7989-4278-8BA8-1ADDA0A58FDC@lassitu.de> <CAJ-VmokES0svxckV10uF8dF_z5XgzWzXjh50fbGeo6TsEU_6jQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 12.12.2011 um 11:28 schrieb Adrian Chadd:

>> The RTL8366 family of switches has a GMII interface to hook up an =
ethernet controller.  MDC/MDIO are not connected to the ethernet =
controller, instead register access is through this I2C-like interface, =
which on the TL-WR1043ND is through two GPIOs.
>=20
> Right. So all the PHY access/glue has to come out of this i2c style =
bus.
>=20
>> The RTL8306SD (which is used for example in the Linksys WRT160NL) has =
two MII ports. One is always used to connect a CPU, while the second one =
can be configured to either communicate with the switch or with one =
specific PHY.
>=20
>> I believe the WRT160NL uses the latter mode, using the first ethernet =
port of the CPU to talk to the switch ("LAN"), and the second one to the =
PHY ("WAN"). It exposes both the five PHYs via MDC/MDIO, as well as =
switch configuration.  Unfortunately, the configuration registers are =
spread out over all the PHYs, so you can't cleanly isolate the PHYs from =
the switch portion.  Since the switch has only one set of MDC/MDIO, both =
ethernet controllers share the same minibus (and both driver instances =
need to work on just the one instance).  For arge1, using the =
appropriate phymask should be sufficient.
>=20
> Right. This I think is one of those places where it gets ugly.

I've looked at the miibus code a bit more, and I think it's necessary to =
decide about the (implied) semantics.

With a standard Ethernet card, you have the MAC, a MDC/MDIO bus, and one =
or more PHYs connected to the MAC.  Our current miibus seems to work =
with this model, and assumes that only one PHY can be active at any =
time, which makes sense if there's only a single MAC.

With the switch controllers, these assumptions are not correct anymore.  =
We still have multiple PHYs that are connected to one MDC/MDIO bus, but =
the MII lines are not shared between the switch MACs and the PHYs, as =
there's a one-to-one relationship between MACs and PHYs. (Ignoring the =
complications of reconfigurable ports for the moment.)

My current thinking is that there should be an miibus instance per =
switch port, with a single PHY attached to it.  All these miibus =
instances talk to the same MDC/MDIO interface, but attach only one of =
the PHYs accessible through it.  I haven't checked what locking =
implications this has on the miibus_if device (usually the Ethernet =
driver).

For my RTL8366RB, that's straight-forward to implement.  For the PHY =
switch controllers like the RTL8306SD the miibusses should be split =
between the MAC (for the "WAN" port) and the switch (for the "LAN" =
ports).  I'm not sure when and where these additional busses would be =
instantiated and probed.

The miibus code also assumes that it is always attached to something =
that has a struct ifnet.  In my RTL8366RB driver, I'm creating one =
myself, but I'm not sure what side effects this might have.


Stefan

--=20
Stefan Bethke <stb@lassitu.de>   Fon +49 151 14070811




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D86C7618-7CF8-4913-985B-00EF85BA110D>