On Mon, Jan 06, 2014 at 01:46:54PM +1000, Peter Crosthwaite wrote: > On Mon, Jan 6, 2014 at 1:27 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > > On Thu, Jan 02, 2014 at 08:25:10PM +1000, Peter Crosthwaite wrote: > >> Hi Beniamino, > >> > >> On Thu, Jan 2, 2014 at 7:18 PM, Beniamino Galvani <b.galv...@gmail.com> > >> wrote: > >> > This patch adds support for the Fast Ethernet MAC found on Allwinner > >> > SoCs, together with a basic emulation of Realtek RTL8201CP PHY. > >> > > >> > >> More a comment for net in general, but I think sooner or later we need > >> to move towards a split between phy and mac on the device level. > >> continuing the phy-within-mac philosophy is going to make the > >> socification efforts awkward. Are MII and friends a busses (as in > >> TYPE_BUS) in their own right, and connection of mac and phy has to > >> happen on the board level? > > > > I see PHY and MAC split as advantageous because it allows code reuse and > > better testing. The main thing I'd like to see is PHY device tests > > using tests/libqtest.h. > > > > If someone wants to implement it, great. It would make it easier to add > > more NIC models in the future. > > > > Regarding SOCification and busses, I'm not sure. Is it okay to just say > > a NIC has-a PHY (i.e. composition)? > > > > Generally speaking, in the (ARM) SoCification the MAC is part of the > SoC which in the latest styling guidelines is a composite device. This > composite is supposed to reflect the self contained SoC product which > the PHY is usually not a part of. So we have two opposing compositions > here: > > NIC = MAC + PHY > SOC = CPUs + MAC + ... > > MAC can't be in both. So for SoCs the NIC concept needs to abandoned. > After all the expansion of NIC as "Network Interface Card" is a little > bit PCish. Your average SoC networking solution has no such "card". > Just an on chip MAC (same pacakge/die as CPU etc) connecting to a PHY > via PCB traces. > > So I think long term, MII has to be a TYPE_BUS that is visible on the > top level SoC device. Self contained NICs (as we know them today) are > then also implementable as container devices (of MAC and PHY) that use > this bus internally (in much the same way the SoC boards would attach > external PHY to SoC).
Okay, that makes sense. Given the amount of emulated hardware in QEMU today, I think it would be okay to simply add new MAC/PHYs while still supporting the NICs of old. If someone is enthusiastic about refactoring and testing existing NICs then great. But I think it's more pragmatic to simply start working with a split MAC/PHY where that is beneficial. Stefan