[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/4] hw/net: fix m68/ColdFire ethernet fec suppo
From: |
Greg Ungerer |
Subject: |
Re: [Qemu-devel] [PATCH 0/4] hw/net: fix m68/ColdFire ethernet fec support |
Date: |
Tue, 28 Jul 2015 10:03:53 +1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 |
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, address@hidden 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 <address@hidden>
>>>
>>> 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