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

[Edgar E. Iglesias]

On Sat, Jan 11, 2014 at 08:48:12AM +1000, Peter Crosthwaite wrote:
> On Mon, Jan 6, 2014 at 4:12 PM, Stefan Hajnoczi <address@hidden> wrote:
> > On Mon, Jan 06, 2014 at 01:46:54PM +1000, Peter Crosthwaite wrote:
> >> On Mon, Jan 6, 2014 at 1:27 PM, Stefan Hajnoczi <address@hidden> 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 <address@hidden> 
> >> >> 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.
> >
> 
> Alright,
> 
> So lets make some plans. There is devil in the detail here. There was
> a previous attempt to do something similar by Grant early last year so
> cc as FYI.
> 
> So the main question is whether or not this new interface is just for
> MDIO or is the full MII interface (both MDIO and packet data).
> 
> My inclination is the latter, we want a new proper QOM bus that is
> both. What this would mean, is that these MAC-only devices wont be net
> devices at all. the -net args are instead applied to the PHY. This
> makes the most sense to me as its the phy that actually has copper
> connection to the external network, not MAC.
> 
> MAC <---- TYPE_MII_BUS ----> PHY <-----net layer ------> external
> network: "-net foo,bar,baz"

I don't really agree with this. You can do ethernet without a PHY,
it is in fact fairly common in the embedded switch space. You can also
have a single MDIO iface that is completely separate from any MAC take
care of many PHYs.

IMO, the MDIO bus should be separate from the data path.


> Another approach is to make both net devices in their own right. Phy
> has two net-layer-managed attachments, one for external network, and
> one point-to-point for the MII connecting to MAC. The MDIO bus is then
> a side channel which may or may not be QOMified (depending on effort
> levels). So you can still connect a standalone MAC to an external
> network, assuming the guest can handle no PHY (may in reality have
> limited use).
> 
> MAC <---- net layer --------> PHY <-----net layer ------> external network
>     <---- TYPE_MDIO_BUS ---->
> 
> OR:
> 
> MAC <---- net layer --------> external network
> 
> 
> The third approach (which is closest to current implementation) is to
> only have the phy do MDIO and still connect the MAC straight to an
> external network:
> 
> MAC <---- net layer --------> external network
>      \
>       <-- TYPE_MDIO_BUS ----> PHY
> 
> I dont like this though, as its a little mismatched to real hw.
> Although it may be a good stepping stone to approaches 1 or 2.

I'd go for this third one and possibly do something about the
data path later if needed. Or possibly nr 2, not sure if I understood
that one correctly though.

Cheers,
Edgar