qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH 1/2] hw/net: add support for Allwinner EMAC Fast Ethernet controller
Date: Sat, 11 Jan 2014 08:16:40 +1000

On Sat, Jan 11, 2014 at 7:48 AM, Beniamino Galvani <address@hidden> wrote:
> On Mon, Jan 06, 2014 at 02:12:27PM +0800, Stefan Hajnoczi wrote:
>> > >> 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.
>
> Regarding the patch, can I resubmit it with MAC and PHY modeled as a
> single device? Or it's better to start thinking on how to implement
> proper MAC/PHY split?
>

Resubmit as a single. Don't wait on the proposed fifo cleanups either.
I'm not going to block.

Regards,
Peter

> Beniamino
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]