From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJsLK-0008Fg-Jj for qemu-devel@nongnu.org; Mon, 27 Jul 2015 20:02:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJsLF-0006hE-LC for qemu-devel@nongnu.org; Mon, 27 Jul 2015 20:02:02 -0400 Received: from icp-osb-irony-out1.external.iinet.net.au ([203.59.1.210]:56729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJsLF-0006gW-9A for qemu-devel@nongnu.org; Mon, 27 Jul 2015 20:01:57 -0400 Message-ID: <55B6C6E9.7070800@uclinux.org> Date: Tue, 28 Jul 2015 10:03:53 +1000 From: Greg Ungerer MIME-Version: 1.0 References: <1435296436-12152-1-git-send-email-gerg@uclinux.org> <20150626101251.GK15457@stefanha-thinkpad.redhat.com> <55922B43.9020502@uclinux.org> <20150727131130.GA12145@stefanha-thinkpad.redhat.com> In-Reply-To: <20150727131130.GA12145@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] hw/net: fix m68/ColdFire ethernet fec support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org Hi Stefan, On 27/07/15 23:11, Stefan Hajnoczi wrote: > On Tue, Jun 30, 2015 at 03:38:11PM +1000, Greg Ungerer wrote: >> Hi Stefan, >> >> On 26/06/15 20:12, Stefan Hajnoczi wrote: >>> On Fri, Jun 26, 2015 at 03:27:12PM +1000, gerg@uclinux.org wrote: >>>> >>>> The following set of patches fixes the emulated ColdFire ethernet fec >>>> driver. There is primarily two problems that need to be fixed. >>>> >>>> 1. The emulated driver needs to support probing of an attached phy. >>>> It is strait forward to emulate an attached phy, but to avoid using >>>> magic numbers I have factored out the common MII register and value >>>> definitions into their own mii.h file first. >>>> >>>> 2. Fix the fec driver receiver to return the correct value. >>>> >>>> With these changes in place the qemu m5208evb board emulation can probe, >>>> identify and use the fec ethernet running a Linux guest. >>>> >>>> >>>> hw/net/mcf_fec.c | 54 ++++++++++++++++++++++++++-- >>>> include/hw/net/allwinner_emac.h | 40 --------------------- >>>> include/hw/net/mii.h | 76 ++++++++++++++++++++++++++++++++++++++++ >>>> 3 files changed, 128 insertions(+), 42 deletions(-) >>> >>> Reviewed-by: Stefan Hajnoczi >>> >>> If this series has no maintainer to go through I'll merge it via my net >>> tree. Please let me know if you'd like that. >>> >>> mcf_fec is not fully correct yet, it needs to call >>> qemu_flush_queued_packets() when rx_enabled transitions from 0 to 1. >>> This will restart rx by sending any queued packets from the net >>> subsystem. >>> >>> In order to get flow control between NetClientState peers working the >>> following is missing: >>> >>> 1. mcf_fec_receive()'s !s->rx_enabled case should return -1 to drop >>> unexpected packets. >>> >>> 2. mcf_fec_receive() should return 0 in the (bd.flags & FEC_BD_E) == 0 >>> case where we've run out of rx buffers. That way the net subsystem >>> queues the packet and waits until the next RDAR write transitions >>> rx_enabled from 0 to 1. >> >> Is the correct behavior in this case to check if we can write >> out the whole packet data, or too partially write out what we can? > > It depends on the NIC you are emulation, but in all existing NICs we > either deliver the entire packet or we don't. Ok, that is good to know, thanks. >> For example it is possible that we hit bd.flags & FEC_BD_E) == 0 >> having written some of the packet data but now we cannot fit the rest. >> So is it correct to simply return what count we have written or >> should we not write unless we can fit the whole packet and return 0. > > Check the datasheet to see how the NIC handles that case. I have a patch that addresses the above issues and uses an all-or-nothing receive side processing. I'll send that through for review. Regards Greg