From: Willy Tarreau <[email protected]> Date: Wed, 9 Dec 2020 19:47:40 +0100
> This reverts commit 0a4e9ce17ba77847e5a9f87eed3c0ba46e3f82eb. > > The code was developed and tested on an MSC313E SoC, which seems to be > half-way between the AT91RM9200 and the AT91SAM9260 in that it supports > both the 2-descriptors mode and a Tx ring. > > It turns out that after the code was merged I could notice that the > controller would sometimes lock up, and only when dealing with sustained > bidirectional transfers, in which case it would report a Tx overrun > condition right after having reported being ready, and will stop sending > even after the status is cleared (a down/up cycle fixes it though). > > After adding lots of traces I couldn't spot a sequence pattern allowing > to predict that this situation would happen. The chip comes with no > documentation and other bits are often reported with no conclusive > pattern either. > > It is possible that my change is wrong just like it is possible that > the controller on the chip is bogus or at least unpredictable based on > existing docs from other chips. I do not have an RM9200 at hand to test > at the moment and a few tests run on a more recent 9G20 indicate that > this code path cannot be used there to test the code on a 3rd platform. > > Since the MSC313E works fine in the single-descriptor mode, and that > people using the old RM9200 very likely favor stability over performance, > better revert this patch until we can test it on the original platform > this part of the driver was written for. Note that the reverted patch > was actually tested on MSC313E. > > Cc: Nicolas Ferre <[email protected]> > Cc: Claudiu Beznea <[email protected]> > Cc: Daniel Palmer <[email protected]> > Cc: Alexandre Belloni <[email protected]> > Link: https://lore.kernel.org/netdev/[email protected]/ > Signed-off-by: Willy Tarreau <[email protected]> Applied, thanks.
