From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: Milton Miller <miltonm@bga.com>
Cc: Scott Feldman <sfeldma@pobox.com>, Jeff Garzik <jeff@garzik.org>,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
John Ronciak <john.ronciak@intel.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: Re: [PATCH] e100 rx: or s and el bits
Date: Tue, 01 May 2007 08:21:33 -0700 [thread overview]
Message-ID: <46375AFD.7000609@intel.com> (raw)
In-Reply-To: <200705011124.l41BOEG4007662@sullivan.realtime.net>
Milton Miller wrote:
> In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description
> talks about emulating another driver by setting addtional bits and
> the being unable to test when submitted. Seeing the & operator to
> set more bits made me suspicious, and indeed the bits are defined
> in positive logic:
>
> cb_s = 0x4000,
> cb_el = 0x8000,
>
> So anding those together would be 0. I'm guessing they should
> be or'd, but don't have hardware here to test, much like the
> committed patch. In fact, I'll let someone else do the compile
> test too. I'll update the comment.
>
> (It looks like the end of list and s bits would not be set
> in the template nor cleared when linking in recieve skbs, so
> as long as the kernel can keep up with the 100Mb card we
> wouldn't see the adapter go off the linked list, possibly
> explaining any successful use of this patch written against
> 2.6.14).
yes, that definately doesn't seem right. I'll try to run this and watch out for
David Ackers report as well.
Thanks,
Auke
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
>
>
> --- linux-2.6/drivers/net/e100.c.orig 2007-05-01 05:19:17.000000000 -0500
> +++ linux-2.6/drivers/net/e100.c 2007-05-01 05:22:14.000000000 -0500
> @@ -947,7 +947,7 @@ static void e100_get_defaults(struct nic
> ((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
>
> /* Template for a freshly allocated RFD */
> - nic->blank_rfd.command = cpu_to_le16(cb_el & cb_s);
> + nic->blank_rfd.command = cpu_to_le16(cb_el | cb_s);
> nic->blank_rfd.rbd = 0xFFFFFFFF;
> nic->blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
>
> @@ -1769,13 +1769,13 @@ static int e100_rx_alloc_skb(struct nic
> }
>
> /* Link the RFD to end of RFA by linking previous RFD to
> - * this one, and clearing EL bit of previous. */
> + * this one, and clearing EL and S bit of previous. */
> if(rx->prev->skb) {
> struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;
> put_unaligned(cpu_to_le32(rx->dma_addr),
> (u32 *)&prev_rfd->link);
> wmb();
> - prev_rfd->command &= ~cpu_to_le16(cb_el & cb_s);
> + prev_rfd->command &= ~cpu_to_le16(cb_el | cb_s);
> pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,
> sizeof(struct rfd), PCI_DMA_TODEVICE);
> }
prev parent reply other threads:[~2007-05-01 15:21 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 11:24 [PATCH] e100 rx: or s and el bits Milton Miller
2007-05-01 15:01 ` David Acker
2007-05-02 20:21 ` David Acker
2007-05-04 21:43 ` David Acker
2007-05-06 6:36 ` Milton Miller
2007-05-07 15:27 ` David Acker
2007-05-14 18:26 ` [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits) David Acker
2007-05-18 1:54 ` Jeff Garzik
2007-05-18 3:47 ` Kok, Auke
2007-05-18 14:07 ` David Acker
2007-05-18 14:20 ` David Acker
2007-05-18 15:29 ` Kok, Auke
2007-05-18 15:47 ` David Acker
2007-05-18 15:59 ` Kok, Auke
2007-05-18 17:11 ` David Acker
2007-05-18 17:47 ` Kok, Auke
2007-05-21 17:35 ` Milton Miller
2007-05-21 17:45 ` Kok, Auke
2007-05-22 16:51 ` Milton Miller
2007-05-22 22:07 ` David Acker
2007-05-23 14:02 ` Milton Miller
2007-05-23 21:32 ` David Acker
2007-05-24 5:26 ` Milton Miller
2007-05-24 11:21 ` Milton Miller
2007-05-24 12:51 ` David Acker
2007-05-24 14:25 ` Milton Miller
2007-05-29 15:58 ` David Acker
2007-05-30 8:26 ` Milton Miller
2007-06-01 20:45 ` David Acker
2007-06-01 21:13 ` Jeff Garzik
2007-06-01 22:13 ` Kok, Auke
2007-06-04 9:03 ` Milton Miller
2007-06-05 13:34 ` David Acker
2007-06-05 16:14 ` Milton Miller
2007-08-27 17:34 ` Kok, Auke
2007-08-27 18:32 ` David Acker
2007-06-05 16:14 ` Milton Miller
2007-06-05 17:27 ` Kok, Auke
2007-06-05 17:39 ` Jeff Garzik
2007-06-05 17:42 ` David Acker
2007-06-05 17:43 ` Kok, Auke
2007-06-05 17:56 ` Milton Miller
2007-06-05 23:33 ` Kok, Auke
2007-06-05 23:44 ` Jeff Garzik
2007-06-06 2:26 ` Kok, Auke
2007-06-06 9:28 ` Milton Miller
2007-06-11 15:58 ` Milton Miller
2007-06-15 14:39 ` Jeff Garzik
2007-05-24 12:44 ` David Acker
2007-05-24 4:13 ` Milton Miller
2007-05-01 15:21 ` Kok, Auke [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46375AFD.7000609@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=akpm@linux-foundation.org \
--cc=e1000-devel@lists.sourceforge.net \
--cc=jeff@garzik.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miltonm@bga.com \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).