[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061214173649.GB3452@infradead.org>
Date: Thu, 14 Dec 2006 17:36:49 +0000
From: Christoph Hellwig <hch@...radead.org>
To: Linas Vepstas <linas@...tin.ibm.com>
Cc: Michael Ellerman <michael@...erman.id.au>,
Andrew Morton <akpm@...l.org>, Arnd Bergmann <arnd@...db.de>,
netdev@...r.kernel.org, Christoph Hellwig <hch@...radead.org>,
linuxppc-dev@...abs.org, Jens Osterkamp <Jens.Osterkamp@....de>,
jgarzik@...ox.com, James K Lewis <jim@...ewis.com>
Subject: Re: [PATCH 12/14] Spidernet Avoid possible RX chain corruption
On Thu, Dec 14, 2006 at 11:15:11AM -0600, Linas Vepstas wrote:
> On Thu, Dec 14, 2006 at 11:22:43AM +1100, Michael Ellerman wrote:
> > > spider_net_refill_rx_chain(card);
> > > - spider_net_enable_rxchtails(card);
> > > spider_net_enable_rxdmac(card);
> > > return 0;
> >
> > Didn't you just add that line?
>
> Dagnabbit. The earlier pach was moving around existing code.
> Or, more precisely, trying to maintain the general function
> of the old code even while moving things around.
>
> Later on, when I started looking at what the danged function
> actually did, and the context it was in, I realized that it
> was a bad idea to call the thing. So then I removed it. :-/
>
> How should I handle this proceedurally? Resend the patch sequence?
> Let it slide?
Just keep it as is in this case. In case you have to redo the patch
series for some other reason or for similar cases in the future put
the patch to remove things in front of the one that reorders the surrounding
bits.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists