netdev - Re: [PATCH net-next V2 06/16] net: fec: don't clear all rx queue bits when just one is being checked

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 Mar 2016 16:38:54 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Troy Kisky <troy.kisky@...ndarydevices.com>
Cc:	Fugang Duan <fugang.duan@....com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"b38611@...escale.com" <b38611@...escale.com>,
	"fabio.estevam@...escale.com" <fabio.estevam@...escale.com>,
	"l.stach@...gutronix.de" <l.stach@...gutronix.de>,
	"andrew@...n.ch" <andrew@...n.ch>,
	"tremyfr@...il.com" <tremyfr@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"laci@...ndarydevices.com" <laci@...ndarydevices.com>,
	"shawnguo@...nel.org" <shawnguo@...nel.org>,
	"johannes@...solutions.net" <johannes@...solutions.net>,
	"stillcompiling@...il.com" <stillcompiling@...il.com>,
	"sergei.shtylyov@...entembedded.com" 
	<sergei.shtylyov@...entembedded.com>,
	"arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH net-next V2 06/16] net: fec: don't clear all rx queue
 bits when just one is being checked

On Fri, Mar 04, 2016 at 09:18:19AM -0700, Troy Kisky wrote:
> On 3/4/2016 2:11 AM, Fugang Duan wrote:
> > From: Troy Kisky <troy.kisky@...ndarydevices.com>Sent: Thursday, February 25, 2016 8:37 AM
> >> To: netdev@...r.kernel.org; davem@...emloft.net; b38611@...escale.com
> >> Cc: fabio.estevam@...escale.com; l.stach@...gutronix.de; andrew@...n.ch;
> >> tremyfr@...il.com; linux@....linux.org.uk; linux-arm-
> >> kernel@...ts.infradead.org; laci@...ndarydevices.com; shawnguo@...nel.org;
> >> johannes@...solutions.net; stillcompiling@...il.com;
> >> sergei.shtylyov@...entembedded.com; arnd@...db.de; Troy Kisky
> >> <troy.kisky@...ndarydevices.com>
> >> 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 <troy.kisky@...ndarydevices.com>
> >> ---
> >>  drivers/net/ethernet/freescale/fec_main.c | 2 --
> >>  1 file changed, 2 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> >> b/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, struct
> >> fec_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.