FEC ethernet issues [Was: PL310 errata workarounds]

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Sun, Mar 23, 2014 at 12:38:31PM +0100, Bernd Faust wrote:
> On 21 March 2014 18:32, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Fri, Mar 21, 2014 at 05:33:02PM +0100, Bernd Faust wrote:
> >> I also tried the patch, but unfortunately it doesn't work for me either.
> >> I get the same error as Robert Daniels. My target is a i.MX6 (Cortex A9,
> >> single core) running Linux Kernel version 3.10.9-rt5+
> >
> > Hmm, rt kernels.  Does this happen without the rt patches applied?
> >
> 
> On a kernel without RT patches the problem does not occur, so in my
> case the problem seems to be introduced/triggered by the RT patches.

Yes, this suggests it's some kind of race introduced by the RT patches.
I've never looked at the RT patches, so I can't help there.

What I can say is that there are a number of other problems with this
driver which are all races of one form or another, but they should not
affect normal operation.

For example:
- the FEC_QUIRK_ERR006358 workaround (for iMX6 only) can read the previous
  descriptor before the write to new descriptor's TX status bit has become
  visible to the hardware.
- FEC_QUIRK_ERR006358 workaround not quite having the desired effect
  (a scheduled delayed work can't be re-scheduled until after it has
  already fired.)
- the number of places that call fec_stop() without first stopping the
  transmit queue or dealing with the above work-around before
  reconfiguring the hardware and re-initialising the rings.
- the rx path having a similar problem to the above (writing descriptor
  entries after the descriptor has been handed over to uDMA.)

I haven't addressed any of these yet, but they're on my list.  I'm pretty
sure there's other problems in there too...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.