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:	Wed, 6 Jun 2007 04:28:33 -0500
From:	Milton Miller <miltonm@....com>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
Cc:	Jeff Garzik <jeff@...zik.org>, Jeff Garzik <jgarzik@...ox.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)


On Jun 5, 2007, at 9:26 PM, Kok, Auke wrote:

> Kok, Auke wrote:
>>>
>> 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)
>> ---
>
> A little bit more is needed to explain why we're reverting it for now. 
> Jeff, please insert this into the revert commit.
>
> Auke
>
> --
> This patch attempted to fix e100 for non-cache coherent memory 
> architectures by using the cb style code that eepro100 had and using 
> the EL and s bits from the RFD list. Unfortunately the hardware 
> doesn't work exactly like this and therefore this patch actually 
> breaks e100 on those systems.

on all systems.  (Both the &| typo and the removed restart logic).

> Reverting the change brings it back to the previously known good state 
> for 2.6.22. The pending rewrite in progress to this code can then be 
> safely merged later.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@...el.com>
> ---

milton

-
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