My guess is that with this patch, the "flush" feature that was added by
Andrey in "imx_fec: Change queue flushing heuristics" (commit b2b012a)
is not really necessary anymore.
But it does not hurt (it might induce a little bit more processing).
JC
Le 22/01/2018 à 15:59, Peter Maydell a écrit :
On 22 January 2018 at 14:54, Andrey Smirnov <andrew.smir...@gmail.com> wrote:
On Mon, Jan 22, 2018 at 3:48 AM, Peter Maydell <peter.mayd...@linaro.org> wrote:
On 13 January 2018 at 11:34, Jean-Christophe Dubois <j...@tribudubois.net>
wrote:
The actual imx_eth_enable_rx() function is buggy.
It updates s->regs[ENET_RDAR] after calling qemu_flush_queued_packets().
qemu_flush_queued_packets() is going to call imx_XXX_receive() which itself
is going to call imx_eth_enable_rx().
By updating s->regs[ENET_RDAR] after calling qemu_flush_queued_packets()
we end up updating the register with an outdated value which might
lead to disabling the receive function in the i.MX FEC/ENET device.
This patch change the place where the register update is done so that the
register value stays up to date and the receive function can keep
running.
Reported-by: Fyleo <fyle...@gmail.com>
Tested-by: Fyleo <fyle...@gmail.com>
Signed-off-by: Jean-Christophe Dubois <j...@tribudubois.net>
---
Andrey, do you have an opinion on this patch, since you've been
looking at i.MX code recently?
The rationale makes sense to me and patch looks like a good cleanup in
general, so FWIW:
Reviewed-by: Andrey Smirnov <andrew.smir...@gmail.com>
I also gave it a spin against my i.MX7 changes with doing basic things
like ping and scp of 1GB file, so I can give my:
Tested-by: Andrey Smirnov <andrew.smir...@gmail.com>
Thanks; I've applied the patch to target-arm.next.
-- PMM
