netdev - Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)

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:	Tue, 05 Jun 2007 16:33:12 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Jeff Garzik <jeff@...zik.org>, Jeff Garzik <jgarzik@...ox.com>
CC:	Milton Miller <miltonm@....com>, e1000-devel@...ts.sourceforge.net,
	David Acker <dacker@...net.com>, netdev@...r.kernel.org,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Scott Feldman <sfeldma@...ox.com>,
	John Ronciak <john.ronciak@...el.com>
Subject: Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and
 el bits)

Milton Miller wrote:
> On Jun 5, 2007, at 12:43 PM, Kok, Auke wrote:
> 
>> Jeff Garzik wrote:
>>> On Tue, Jun 05, 2007 at 10:27:19AM -0700, Kok, Auke wrote:
>>>> We need to make sure that now that we're getting closer to 2.6.22 we 
>>>> don't end up killing e100 in it. Should we drop the current fixes in 
>>>> it to be on the safe side and aim for 2.6.23? I would hate to see an 
>>>> untested codepath breaking e100 on something like ppc or mips... 
>>>> that will be very painful
>>> I certainly agree with this assessment...
>>> I've been wondering if, based on all this recent work, we should 
>>> revert
>>> the s-bit stuff and wait for 2.6.23.
>> Yes, that's my point. If Milton and David agree I think we should do 
>> so immediately.
> 
> We definitely need something other than what is in now.
> 
> 
>> If so, do you want me to write a revert-patch or do you have some 
>> magic to do that for me?
>>
> 
> The simple git revert won't work because there have been other changes 
> (ioread for instance) that conflict.

Hmm git-revert seems to do the job right. I checked it with git-show | patch -p1 
-R and the results look OK. The two patches on top of the one we want to revert 
are unrelated enough to apply (manually it shows some fuzz, but otherwise it's OK).

Jeff, please `git-revert d52df4a35af569071fda3f4eb08e47cc7023f094` to revert the 
following patch for now:

---
commit  d52df4a35af569071fda3f4eb08e47cc7023f094
Author: Scott Feldman <sfeldma@...ox.com>
Date:   Wed Nov 9 02:18:52 2005 -0500

     [netdrvr e100] experiment with doing RX in a similar manner to eepro100

     I was going to say that eepro100's speedo_rx_link() does the same DMA
     abuse as e100, but then I noticed one little detail: eepro100 sets  both
     EL (end of list) and S (suspend) bits in the RFD as it chains it  to the
     RFD list.  e100 was only setting the EL bit.  Hmmm, that's  interesting.
     That means that if HW reads a RFD with the S-bit set,  it'll process
     that RFD and then suspend the receive unit.  The  receive unit will
     resume when SW clears the S-bit.  There is no need  for SW to restart
     the receive unit.  Which means a lot of the receive  unit state tracking
     code in the driver goes away.

     So here's a patch against 2.6.14.  (Sorry for inlining it; the mailer
     I'm using now will mess with the word wrap).  I can't test this on
     XScale (unless someone has an e100 module for Gumstix :) .  It should
     be doing exactly what eepro100 does with RFDs.  I don't believe this
     change will introduce a performance hit because the S-bit and EL-bit  go
     hand-in-hand meaning if we're going to suspend because of the S- bit,
     we're on the last resource anyway, so we'll have to wait for SW  to
     replenish.
     (cherry picked from 29e79da9495261119e3b2e4e7c72507348e75976 commit)
---

Cheers,

Auke
-
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