[PATCH net-next V2 06/16] net: fec: don't clear all rx queue bits when just one is being checked
From: Russell King - ARM Linux <hidden>
Date: 2016-03-04 16:38:54
Also in:
netdev
On Fri, Mar 04, 2016 at 09:18:19AM -0700, Troy Kisky wrote:
On 3/4/2016 2:11 AM, Fugang Duan wrote:quoted
From: Troy Kisky <redacted>Sent: Thursday, February 25, 2016 8:37 AMquoted
To: netdev at vger.kernel.org; davem at davemloft.net; b38611 at freescale.com Cc: fabio.estevam at freescale.com; l.stach at pengutronix.de; andrew at lunn.ch; tremyfr at gmail.com; linux at arm.linux.org.uk; linux-arm- kernel at lists.infradead.org; laci at boundarydevices.com; shawnguo at kernel.org; johannes at sipsolutions.net; stillcompiling at gmail.com; sergei.shtylyov at cogentembedded.com; arnd at arndb.de; Troy Kisky [off-list ref] Subject: [PATCH net-next V2 06/16] net: fec: don't clear all rx queue bits when just one is being checked FEC_ENET_RXF is 3 separate bits, we only check one queue at a time. So, when the last queue is being checked, it is bad to remove the interrupt on the 1st queue. Also, since this is now done in the napi routine and not the interrupt, it is not needed. Signed-off-by: Troy Kisky <redacted> --- drivers/net/ethernet/freescale/fec_main.c | 2 -- 1 file changed, 2 deletions(-)diff --git a/drivers/net/ethernet/freescale/fec_main.cb/drivers/net/ethernet/freescale/fec_main.c index 610cf6c..791f385 100644--- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c@@ -1338,8 +1338,6 @@ static int fec_rxq(struct net_device *ndev, structfec_enet_private *fep, break; pkt_received++; - writel(FEC_ENET_RXF, fep->hwp + FEC_IEVENT); -We should clear the related rx queue ievent, not remove the code. Pls see commit: db3421c114cf that was submitted by Russell King. No ack the patch.This is now done in patch #4 "net: fec: reduce interrupts" and you could argue that it should be squashed into that patch. But I like separating changes as much as possible. Russell, this patch and patch #4 will likely need your ack before it will be applied. Can you take a look please?
I stopped caring about the FEC ethernet driver about 18 months ago, after I ended up dropping a significant pile of fixes on the floor through the huge number of conflicts and the shere effort of constantly trying to move them forward. My patch series tend to be large because I put concentrated effort into something for a month, which then gives a problem if conflicts come up later and the series has to be effectively rewritten from scratch. It was after the second or third time of facing an almost total rewrite that happened that I just gave up. I've toyed with the idea of forking the driver, but I wouldn't have time to maintain such a thing. So, right now I just put up with all the bad quirks, and reset/power cycle the boards when things go wrong. Right now, I just disable runtime PM support on the FEC to get stability here. :) Sorry, but I can't be of more help. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.