Date: Sat, 10 Dec 2011 15:06:02 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Aleksandr Rybalko <ray@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: "float PHYs", communication between indirect attached devices Message-ID: <20111210140602.GA39223@alchemy.franken.de> In-Reply-To: <20111210140540.6301dfa9.ray@freebsd.org> References: <20111210140540.6301dfa9.ray@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 10, 2011 at 02:05:40PM +0200, Aleksandr Rybalko wrote:
> Hi net@ subscribers,
>
> Simple explanation of problem:
> real situation, device with two NICs (arge0 and arge1)
> arge0 attached to PHY w/o direct access to it.
> arge1 attached to switch MII port (and have access to MDIO bus).
>
> switch have child MDIO bus for all Physical ports.
> One of this ports (or his PHY) must be controlled by arge0.
>
> I will do pseudo PHY driver that must communicate with real one on
> switch MDIO bus.
>
> Question: how to communicate, since newbus can't handle two parents:
> 1) sysctl
> 2) events
> 3) kenv
> 4) something better
> globals is not a solution, because it is possible that we will have
> some device with more than one "float PHYs"
>
> please, help me to find best way!
>
> Wait for your suggestions, comments, hints, etc.
>
Given that this is one of the really awkward hardware hacks you'll
only find in the embedded world I'd just change arge(4) to allocate
its SYS_RES_MEMORY as RF_SHAREABLE and let arge0 search for the
device_t of its sibling arge1 using device_get_children(9) on its
parent or devclass_get_devices(9). Then for arge0 additionally
allocate the SYS_RES_MEMORY of arge1 as RF_SHAREABLE and let arge0
use the latter in arge_miibus_{read,write}reg(). This requires a
common mutex for the MII bus access but arge(4) actually already
has a global miibus_mtx.
A cleaner approach though more to code but in turn allowing to
implement a generic solution for this problem would be a pseudo-bus
driver roughly similar to f.e. puc(4) that takes care of the
resource and MII bus sharing which the MAC drivers then attach to.
This generic approach would have a common core dealing with the
resource and MII bus sharing as such and chip/hardware specific glue
for talking to a particular shared MII bus and also different bus
front-ends (nexus(4), pci(4) etc.). That way one could f.e. also
use a shared MII bus that is implemented via GPIO pins of the
CPU with multiple MACs (as it isn't necessarily a MAC that the
MII bus in question is attached to, at least we use something
like that at $work).
Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111210140602.GA39223>