From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1jxP-0007bs-Jv for qemu-devel@nongnu.org; Fri, 10 Jan 2014 16:49:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1jxH-0000wE-5H for qemu-devel@nongnu.org; Fri, 10 Jan 2014 16:49:35 -0500 Received: from mail-ea0-x235.google.com ([2a00:1450:4013:c01::235]:48768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1jxG-0000w3-Uu for qemu-devel@nongnu.org; Fri, 10 Jan 2014 16:49:27 -0500 Received: by mail-ea0-f181.google.com with SMTP id m10so2287867eaj.26 for ; Fri, 10 Jan 2014 13:49:25 -0800 (PST) Date: Fri, 10 Jan 2014 22:48:48 +0100 From: Beniamino Galvani Message-ID: <20140110214847.GA7557@gmail.com> References: <1388654332-10303-1-git-send-email-b.galvani@gmail.com> <1388654332-10303-2-git-send-email-b.galvani@gmail.com> <20140106032711.GA14603@stefanha-thinkpad.redhat.com> <20140106061227.GA20766@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140106061227.GA20766@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/2] hw/net: add support for Allwinner EMAC Fast Ethernet controller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Peter Maydell , Peter Crosthwaite , "qemu-devel@nongnu.org Developers" , Li Guang , "Edgar E. Iglesias" 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? Beniamino