From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJiBt-00087B-1Q for qemu-devel@nongnu.org; Mon, 27 Jul 2015 09:11:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJiBq-0003kj-1I for qemu-devel@nongnu.org; Mon, 27 Jul 2015 09:11:36 -0400 Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:38224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJiBp-0003kc-QD for qemu-devel@nongnu.org; Mon, 27 Jul 2015 09:11:33 -0400 Received: by wibxm9 with SMTP id xm9so116027145wib.1 for ; Mon, 27 Jul 2015 06:11:33 -0700 (PDT) Date: Mon, 27 Jul 2015 14:11:30 +0100 From: Stefan Hajnoczi Message-ID: <20150727131130.GA12145@stefanha-thinkpad.redhat.com> References: <1435296436-12152-1-git-send-email-gerg@uclinux.org> <20150626101251.GK15457@stefanha-thinkpad.redhat.com> <55922B43.9020502@uclinux.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <55922B43.9020502@uclinux.org> 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: Greg Ungerer Cc: qemu-devel@nongnu.org --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2015 at 03:38:11PM +1000, Greg Ungerer wrote: > Hi Stefan, >=20 > 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 prob= e, > >> 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(-) > >=20 > > Reviewed-by: Stefan Hajnoczi > >=20 > > 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. > >=20 > > 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. > >=20 > > In order to get flow control between NetClientState peers working the > > following is missing: > >=20 > > 1. mcf_fec_receive()'s !s->rx_enabled case should return -1 to drop > > unexpected packets. > >=20 > > 2. mcf_fec_receive() should return 0 in the (bd.flags & FEC_BD_E) =3D= =3D 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. >=20 > 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. > For example it is possible that we hit bd.flags & FEC_BD_E) =3D=3D 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. --DocE+STaALJfprDB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVti4CAAoJEJykq7OBq3PIhr8IALzaKXlMK1n5PnEb9AwMiQ8z haPTBirJnmx8RH/cbRZ95/X/wuFpJkkHl5ryGgMRtTfDxf1CpCiVr92LNmZqXmIQ eXT4C/6CW8KwBqAD4kl8aPpgv2L5VQy6W8ttp2IQXXW67lXPa5DzdxhTnpMHW9Qj Uh/IL2Uj9xgcN8vHYq43XM/O1tOZX7FiubyKIB7iCikh/VQlgvh40wEoILQKOVGR GSCSMc0ZULCcVzoWOH2W0ftn6L8R2jnLFPUd/RuplUJ7DX11JKPJMFeRlQpfgTJE KZbrTtEP+5PZDw2EeGeE0ZqnsNyiMrLk6FX8Kid7XLsslf4xa4MHFQeKXe+4fj4= =shBQ -----END PGP SIGNATURE----- --DocE+STaALJfprDB--