Re: [Qemu-devel] [PATCH 1/2] hw/net: add support for Allwinner EMAC Fast Ethernet controller

[Stefan Hajnoczi <stefanha@redhat.com>]

On Mon, Jan 06, 2014 at 01:46:54PM +1000, Peter Crosthwaite wrote:
> On Mon, Jan 6, 2014 at 1:27 PM, Stefan Hajnoczi <stefanha@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.galvani@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