* [PATCH net-2.6] r6040: Fix multicast filter some more
From: Ben Hutchings @ 2010-10-15 3:17 UTC (permalink / raw)
To: David Miller, Florian Fainelli; +Cc: netdev
This code has been broken forever, but in several different and
creative ways.
So far as I can work out, the R6040 MAC filter has 4 exact-match
entries, the first of which the driver uses for its assigned unicast
address, plus a 64-entry hash-based filter for multicast addresses
(maybe unicast as well?).
The original version of this code would write the first 4 multicast
addresses as exact-match entries from offset 1 (bug #1: there is no
entry 4 so this could write to some PHY registers). It would fill the
remainder of the exact-match entries with the broadcast address (bug
addresses were configured, it would set up the hash table, write some
random crap to the MAC control register (bug #3) and finally walk off
the end of the list when filling the exact-match entries (bug #4).
All of this seems to be pointless, since it sets the promiscuous bit
when the interface is made promiscuous or if >4 multicast addresses
are enabled, and never clears it (bug #5, masking bug #2).
The recent(ish) changes to the multicast list fixed bug #4, but
completely removed the limit on iteration over the exact-match entries
(bug #6).
Bug #4 was reported as
<https://bugzilla.kernel.org/show_bug.cgi?id=15355> and more recently
as <http://bugs.debian.org/600155>. Florian Fainelli attempted to fix
these in commit 3bcf8229a8c49769e48d3e0bd1e20d8e003f8106, but that
actually dealt with bugs #1-3, bug #4 having been fixed in mainline at
that point.
That commit fixes the most important current bug #6.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@kernel.org [2.6.35 only]
---
Compile-tested only.
Ben.
drivers/net/r6040.c | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 142c381..80666f0 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -893,16 +893,18 @@ static void r6040_multicast_list(struct net_device *dev)
/* Multicast Address 1~4 case */
i = 0;
netdev_for_each_mc_addr(ha, dev) {
- if (i < MCAST_MAX) {
- adrp = (u16 *) ha->addr;
- iowrite16(adrp[0], ioaddr + MID_1L + 8 * i);
- iowrite16(adrp[1], ioaddr + MID_1M + 8 * i);
- iowrite16(adrp[2], ioaddr + MID_1H + 8 * i);
- } else {
- iowrite16(0xffff, ioaddr + MID_1L + 8 * i);
- iowrite16(0xffff, ioaddr + MID_1M + 8 * i);
- iowrite16(0xffff, ioaddr + MID_1H + 8 * i);
- }
+ if (i >= MCAST_MAX)
+ break;
+ adrp = (u16 *) ha->addr;
+ iowrite16(adrp[0], ioaddr + MID_1L + 8 * i);
+ iowrite16(adrp[1], ioaddr + MID_1M + 8 * i);
+ iowrite16(adrp[2], ioaddr + MID_1H + 8 * i);
+ i++;
+ }
+ while (i < MCAST_MAX) {
+ iowrite16(0xffff, ioaddr + MID_1L + 8 * i);
+ iowrite16(0xffff, ioaddr + MID_1M + 8 * i);
+ iowrite16(0xffff, ioaddr + MID_1H + 8 * i);
i++;
}
}
--
1.7.1
^ permalink raw reply related
* Re: [RFC PATCH 3/7] bnx2: Update bnx2 to use new vlan accleration.
From: Jesse Gross @ 2010-10-15 1:36 UTC (permalink / raw)
To: Michael Chan; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1287096960.14523.31.camel@nseg_linux_HP1.broadcom.com>
On Thu, Oct 14, 2010 at 3:56 PM, Michael Chan <mchan@broadcom.com> wrote:
>> if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) &&
>> - !(bp->rx_mode & BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG)) {
>> - vtag = rx_hdr->l2_fhdr_vlan_tag;
>> -#ifdef BCM_VLAN
>> - if (bp->vlgrp)
>> - hw_vlan = 1;
>> - else
>> -#endif
>> - {
>> - struct vlan_ethhdr *ve = (struct vlan_ethhdr *)
>> - __skb_push(skb, 4);
>> -
>> - memmove(ve, skb->data + 4, ETH_ALEN * 2);
>> - ve->h_vlan_proto = htons(ETH_P_8021Q);
>> - ve->h_vlan_TCI = htons(vtag);
>> - len += 4;
>> - }
>> - }
>> + !(bp->rx_mode & BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG))
>
> This check for the rx_mode bit is no longer necessary if we always
> configure the chip to strip out the vlan tag.
Thanks, I've dropped it from my local tree. I may add support for
ethtool to disable vlan stripping in the future, so I might have to
add it back.
^ permalink raw reply
* Re: [PATCH net-next 3/5] tipc: Optimizations to bearer enabling logic
From: Paul Gortmaker @ 2010-10-15 1:11 UTC (permalink / raw)
To: Neil Horman; +Cc: davem, netdev, allan.stephens
In-Reply-To: <20101013145843.GD31379@hmsreliant.think-freely.org>
[Re: [PATCH net-next 3/5] tipc: Optimizations to bearer enabling logic] On 13/10/2010 (Wed 10:58) Neil Horman wrote:
> On Tue, Oct 12, 2010 at 08:25:56PM -0400, Paul Gortmaker wrote:
> > From: Allan Stephens <allan.stephens@windriver.com>
> >
> > Introduces "enabling" state during activation of a new TIPC bearer,
> > which supplements the existing "disabled" and "enabled" states.
> > This change allows the new bearer to be added without having to
> > temporarily block the processing of incoming packets on existing
> > bearers during the binding of the new bearer to its associated
> > interface. It also makes it unnecessary to zero out the entire
> > bearer structure at the start of activation.
> >
[...]
> > + b_ptr->state = BEARER_ENABLING;
> > strcpy(b_ptr->publ.name, name);
> > + b_ptr->priority = priority;
> > +
> > + write_unlock_bh(&tipc_net_lock);
> Why the 3rd state? Doesn't seem needed.
I'm a bit disappointed in myself for also not noticing that it
was set but never tested for. The following should give the
same end result but without the obfuscation of an extra state.
This one also doesn't explicitly depend on any other changes,
so if it is now OK, the option is there for it to be applied
independently of the others that haven't been reworked yet.
Thanks,
Paul.
>From 86d0d5c92439d0a3f5a0f165aa8bd842d377dae9 Mon Sep 17 00:00:00 2001
From: Allan Stephens <allan.stephens@windriver.com>
Date: Thu, 14 Oct 2010 16:09:23 -0400
Subject: [PATCH] tipc: Optimizations to bearer enabling logic
Allow new bearers to be added without having to temporarily block
the processing of incoming packets on existing bearers during the
binding of the new bearer to its associated interface. Eliminates
zeroing out of the new bearer structure at the start of activation,
since it is already in that state.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/bearer.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index fd9c06c..2ff8181 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -556,14 +556,15 @@ restart:
}
b_ptr = &tipc_bearers[bearer_id];
- memset(b_ptr, 0, sizeof(struct bearer));
-
strcpy(b_ptr->publ.name, name);
+
+ write_unlock_bh(&tipc_net_lock);
res = m_ptr->enable_bearer(&b_ptr->publ);
if (res) {
warn("Bearer <%s> rejected, enable failure (%d)\n", name, -res);
- goto failed;
+ return res;
}
+ write_lock_bh(&tipc_net_lock);
b_ptr->identity = bearer_id;
b_ptr->media = m_ptr;
--
1.7.2.1
^ permalink raw reply related
* linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2010-10-15 0:38 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Emil Tantilov, Jeff Kirsher
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
Hi all,
After merging the net tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_configure_dcb':
drivers/net/ixgbe/ixgbe_main.c:3377: error: implicit declaration of function 'ixgbe_dcb_check_config'
Caused by commit f32f837b75233588cd4f8542214a30915ab7847b ("ixgbe: remove
unused functions").
Grep is your friend :-)
I have used the net tree from next-20101014 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH net-next] 3c52x: remove IRQF_SAMPLE_RANDOM from legacy MCA drivers.
From: Paul Gortmaker @ 2010-10-15 0:21 UTC (permalink / raw)
To: davem; +Cc: netdev
If you are genuinely using one of these legacy MCA drivers
then you are tragically on hardware where you really don't
have the extra CPU cycles to be wasting on this.
In addition, it makes two less cases for people to inadvertently
blindly copy flags from without explicitly thinking whether it
makes sense -- see the addition to feature-removal.txt as per
commit 9d9b8fb0e5ebf4b0398e579f6061d4451fea3242.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/3c523.c | 2 +-
drivers/net/3c527.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/3c523.c b/drivers/net/3c523.c
index 1719079..3aa9baa 100644
--- a/drivers/net/3c523.c
+++ b/drivers/net/3c523.c
@@ -287,7 +287,7 @@ static int elmc_open(struct net_device *dev)
elmc_id_attn586(); /* disable interrupts */
- ret = request_irq(dev->irq, elmc_interrupt, IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+ ret = request_irq(dev->irq, elmc_interrupt, IRQF_SHARED,
dev->name, dev);
if (ret) {
pr_err("%s: couldn't get irq %d\n", dev->name, dev->irq);
diff --git a/drivers/net/3c527.c b/drivers/net/3c527.c
index 5c07b14..cf4cfd3 100644
--- a/drivers/net/3c527.c
+++ b/drivers/net/3c527.c
@@ -443,7 +443,7 @@ static int __init mc32_probe1(struct net_device *dev, int slot)
* Grab the IRQ
*/
- err = request_irq(dev->irq, mc32_interrupt, IRQF_SHARED | IRQF_SAMPLE_RANDOM, DRV_NAME, dev);
+ err = request_irq(dev->irq, mc32_interrupt, IRQF_SHARED, DRV_NAME, dev);
if (err) {
release_region(dev->base_addr, MC32_IO_EXTENT);
pr_err("%s: unable to get IRQ %d.\n", DRV_NAME, dev->irq);
--
1.7.2.1
^ permalink raw reply related
* Re: [PATCH net-next 2/5] tipc: Simplify bearer shutdown logic
From: Paul Gortmaker @ 2010-10-14 23:58 UTC (permalink / raw)
To: Neil Horman; +Cc: davem, netdev, allan.stephens
In-Reply-To: <20101013143922.GC31379@hmsreliant.think-freely.org>
[Re: [PATCH net-next 2/5] tipc: Simplify bearer shutdown logic] On 13/10/2010 (Wed 10:39) Neil Horman wrote:
> On Tue, Oct 12, 2010 at 08:25:55PM -0400, Paul Gortmaker wrote:
> > From: Allan Stephens <allan.stephens@windriver.com>
> >
> > Disable all active bearers when TIPC is shut down without having to do
> > a name-based search to locate each bearer object.
> >
> It seems like you're doing a good deal more in this patch than just disabling
> all active bearers without doing a name search. The description is implemented
> in the for loop of tipc_bearer_stop. Whats the rest of it for?
It seems the original needlessly bloated out the patch size by
swapping the order of tipc_bearer_find_interface & bearer_find
in the file (now fixed) - and you are right, the locking change
wasn't properly covered in the commit log. The extra test you'd
suggested tossing out is also now gone.
This change doesn't explicitly depend on any other changes,
so if it is now OK, the option is there for it to be applied
independently of the others that haven't been reworked yet.
Thanks,
Paul.
>From 1771ad642cb076dbeb71e3533a25cb2f07df9cd8 Mon Sep 17 00:00:00 2001
From: Allan Stephens <allan.stephens@windriver.com>
Date: Sat, 4 Sep 2010 09:29:04 -0400
Subject: [PATCH] tipc: Simplify bearer shutdown logic
Optimize processing in TIPC's bearer shutdown code, including:
1. Remove an unnecessary check to see if TIPC bearer's can exist.
2. Don't release spinlocks before calling a media-specific disabling
routine, since the routine can't sleep.
3. Make bearer_disable() operate directly on a struct bearer, instead
of needlessly taking a name and then mapping that to the struct.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/bearer.c | 38 +++++++++++---------------------------
1 files changed, 11 insertions(+), 27 deletions(-)
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 9c10c6b..fd9c06c 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -288,9 +288,6 @@ static struct bearer *bearer_find(const char *name)
struct bearer *b_ptr;
u32 i;
- if (tipc_mode != TIPC_NET_MODE)
- return NULL;
-
for (i = 0, b_ptr = tipc_bearers; i < MAX_BEARERS; i++, b_ptr++) {
if (b_ptr->active && (!strcmp(b_ptr->publ.name, name)))
return b_ptr;
@@ -630,30 +627,17 @@ int tipc_block_bearer(const char *name)
* Note: This routine assumes caller holds tipc_net_lock.
*/
-static int bearer_disable(const char *name)
+static int bearer_disable(struct bearer *b_ptr)
{
- struct bearer *b_ptr;
struct link *l_ptr;
struct link *temp_l_ptr;
- b_ptr = bearer_find(name);
- if (!b_ptr) {
- warn("Attempt to disable unknown bearer <%s>\n", name);
- return -EINVAL;
- }
-
- info("Disabling bearer <%s>\n", name);
+ info("Disabling bearer <%s>\n", b_ptr->publ.name);
tipc_disc_stop_link_req(b_ptr->link_req);
spin_lock_bh(&b_ptr->publ.lock);
b_ptr->link_req = NULL;
b_ptr->publ.blocked = 1;
- if (b_ptr->media->disable_bearer) {
- spin_unlock_bh(&b_ptr->publ.lock);
- write_unlock_bh(&tipc_net_lock);
- b_ptr->media->disable_bearer(&b_ptr->publ);
- write_lock_bh(&tipc_net_lock);
- spin_lock_bh(&b_ptr->publ.lock);
- }
+ b_ptr->media->disable_bearer(&b_ptr->publ);
list_for_each_entry_safe(l_ptr, temp_l_ptr, &b_ptr->links, link_list) {
tipc_link_delete(l_ptr);
}
@@ -664,10 +648,16 @@ static int bearer_disable(const char *name)
int tipc_disable_bearer(const char *name)
{
+ struct bearer *b_ptr;
int res;
write_lock_bh(&tipc_net_lock);
- res = bearer_disable(name);
+ b_ptr = bearer_find(name);
+ if (b_ptr == NULL) {
+ warn("Attempt to disable unknown bearer <%s>\n", name);
+ res = -EINVAL;
+ } else
+ res = bearer_disable(b_ptr);
write_unlock_bh(&tipc_net_lock);
return res;
}
@@ -680,13 +670,7 @@ void tipc_bearer_stop(void)
for (i = 0; i < MAX_BEARERS; i++) {
if (tipc_bearers[i].active)
- tipc_bearers[i].publ.blocked = 1;
- }
- for (i = 0; i < MAX_BEARERS; i++) {
- if (tipc_bearers[i].active)
- bearer_disable(tipc_bearers[i].publ.name);
+ bearer_disable(&tipc_bearers[i]);
}
media_count = 0;
}
-
-
--
1.7.2.1
^ permalink raw reply related
* Couple tc filter questions.
From: Jonathan Thibault @ 2010-10-14 23:31 UTC (permalink / raw)
To: netdev
Since the lartc mailing list appears to be dead, I'll ask here and hope not to offend anyone.
1- This page:
http://lartc.org/howto/lartc.qdisc.filters.html
States: "Also, with HTB, you should attach all filters to the root!"
Why? Is it still true? My setup would be a lot easier with cascading filters. If it's just a matter of there not being any efficiency gains from cascading filters, that's fine. If there is a risk of things exploding randomly and without notice, I'd be keen to know. Testing shows that cascading works okay, but I haven't tried under any serious load.
2- Are filter flowid (classify) actions terminating? Meaning if two consecutive filters would match the same packet, only the first match would ever apply and no further filter is evaluated? Are there actions for which this isn't the case? Intuitively and experimentally, I'd answer no but if anyone knowledgeable in the matter would care to expand on that topic I'd be grateful. Especially considering cascading classes/filters.
Another area where termination isn't entirely clear is when using mirred and ifb devices. I might want to send a copy of all my traffic to an ifb device, but then I would still want subsequent filters to match in the current qdisc. In such a case, a filter that matches all traffic with a mirred action should probably not be terminating.
Maybe I'm thinking too much in terms of iptables here :P
Jonathan
^ permalink raw reply
* RE: [PATCH 2.6.35-rc6] net-next: Add multiqueue support to vmxnet3 driver
From: Shreyas Bhatewara @ 2010-10-14 23:31 UTC (permalink / raw)
To: Ben Hutchings, Stephen Hemminger
Cc: netdev@vger.kernel.org, pv-drivers@vmware.com,
linux-kernel@vger.kernel.org
In-Reply-To: <1287073868.2258.13.camel@achroite.uk.solarflarecom.com>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Thursday, October 14, 2010 9:31 AM
> To: Stephen Hemminger; Shreyas Bhatewara
> Cc: netdev@vger.kernel.org; pv-drivers@vmware.com; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 2.6.35-rc6] net-next: Add multiqueue support to
> vmxnet3 driver
>
> On Wed, 2010-10-13 at 14:57 -0700, Stephen Hemminger wrote:
> > On Wed, 13 Oct 2010 14:47:05 -0700 (PDT)
> > Shreyas Bhatewara <sbhatewara@vmware.com> wrote:
> >
> > > #ifdef VMXNET3_RSS
> > > +static unsigned int num_rss_entries;
> > > +#define VMXNET3_MAX_DEVICES 10
> > > +
> > > +static int rss_ind_table[VMXNET3_MAX_DEVICES *
> > > + VMXNET3_RSS_IND_TABLE_SIZE + 1] = {
> > > + [0 ... VMXNET3_MAX_DEVICES * VMXNET3_RSS_IND_TABLE_SIZE] = -1 };
> > > +#endif
> > > +static int num_tqs[VMXNET3_MAX_DEVICES + 1] = {
> > > + [0 ... VMXNET3_MAX_DEVICES] = 1 };
> > > +static int num_rqs[VMXNET3_MAX_DEVICES + 1] = {
> > > + [0 ... VMXNET3_MAX_DEVICES] = 1 };
> > > +static int share_tx_intr[VMXNET3_MAX_DEVICES + 1] = {
> > > + [0 ... VMXNET3_MAX_DEVICES] = 0 };
> > > +static int buddy_intr[VMXNET3_MAX_DEVICES + 1] = {
> > > + [0 ... VMXNET3_MAX_DEVICES] = 1 };
> > > +
> > > +static unsigned int num_adapters;
> > > +module_param_array(share_tx_intr, int, &num_adapters, 0400);
> > > +MODULE_PARM_DESC(share_tx_intr, "Share one IRQ among all tx queue
> completions. "
> > > + "Comma separated list of 1s and 0s - one for each NIC. "
> > > + "1 to share, 0 to not, default is 0");
> > > +module_param_array(buddy_intr, int, &num_adapters, 0400);
> > > +MODULE_PARM_DESC(buddy_intr, "Share one IRQ among corresponding tx
> and rx "
> > > + "queues. Comma separated list of 1s and 0s - one for each
> "
> > > + "NIC. 1 to share, 0 to not, default is 1");
> > > +module_param_array(num_tqs, int, &num_adapters, 0400);
> > > +MODULE_PARM_DESC(num_tqs, "Number of transmit queues in each
> adapter. Comma "
> > > + "separated list of integers. Setting this to 0 makes
> number"
> > > + " of queues same as number of CPUs. Default is 1.");
> > > +
> > > +#ifdef VMXNET3_RSS
> > > +module_param_array(rss_ind_table, int, &num_rss_entries, 0400);
> > > +MODULE_PARM_DESC(rss_ind_table, "RSS Indirection table. Number of
> entries "
> > > + "per NIC should be 32. Each integer in a comma separated
> list"
> > > + " is an rx queue number starting with 0. Repeat the same
> for"
> > > + " all NICs.");
> > > +module_param_array(num_rqs, int, &num_adapters, 0400);
> > > +MODULE_PARM_DESC(num_rqs, "Number of receive queues in each
> adapter. Comma "
> > > + " separated list of integers. Setting this to 0 makes
> number"
> > > + " of queues same as number of CPUs. Default is 1.");
> >
> > Module parameters are not right for this. They lead to different API
> > for interacting with each driver vendor. Is there a another better
> API?
> > Does it have to be this tweakable in a production environment.
>
> The ethtool commands ETHTOOL_{G,S}RXFHINDIR cover the RSS indirection
> table. These are new in 2.6.36 but already supported in the ethtool
> utility.
Thanks Ben,
Good to know. I will try and replace the module parameter for RSS indirection table with handlers for these ethtool commands.
>
> As for numbers of queues and association of their completions with
> interrupts, we currently have nothing except ETHTOOL_GRXRINGS to get
> the
> number of RX queues. I did post a tentative definition of an ethtool
> interface for this in
> <http://article.gmane.org/gmane.linux.network/172386> though it
> wouldn't
> provide quite as much control as these module parameters. It is also
> significantly more difficult to support changing numbers of queues
> after
> an interface has been created, and I have not yet attempted to
> implement
> the 'set' command myself.
Okay. It would be best to keep module parameters to dictate number of queues till ethtool commands to do so become available/easy to use (command to change number of tx queues do not exist).
Regards.
Shreyas
>
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: BUG ? ipip unregister_netdevice_many()
From: Paul E. McKenney @ 2010-10-14 23:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, daniel.lezcano, ebiederm, hans.schillstrom, netdev
In-Reply-To: <1287028631.2649.100.camel@edumazet-laptop>
On Thu, Oct 14, 2010 at 05:57:11AM +0200, Eric Dumazet wrote:
> Le mercredi 13 octobre 2010 à 16:23 -0700, David Miller a écrit :
> > From: Daniel Lezcano <daniel.lezcano@free.fr>
[ . . . ]
> > for (i = 0; i <= rt_hash_mask; i++) {
> > + struct rtable *list = NULL, **pprev;
> > +
> > if (process_context && need_resched())
> > cond_resched();
> > rth = rt_hash_table[i].chain;
> > @@ -726,41 +727,27 @@ static void rt_do_flush(int process_context)
> > continue;
> >
> > spin_lock_bh(rt_hash_lock_addr(i));
> > -#ifdef CONFIG_NET_NS
> > - {
> > - struct rtable ** prev, * p;
> >
> > - rth = rt_hash_table[i].chain;
> > + pprev = &rt_hash_table[i].chain;
> > + rth = *pprev;
> > + while (rth) {
> > + next = rth->dst.rt_next;
> > + if (dev_net(rth->dst.dev) == net) {
>
> if (net_eq(dev_net(rth->dst.dev), net)) {
>
>
> > + *pprev = next;
> >
> > - /* defer releasing the head of the list after spin_unlock */
> > - for (tail = rth; tail; tail = tail->dst.rt_next)
> > - if (!rt_is_expired(tail))
> > - break;
> > - if (rth != tail)
> > - rt_hash_table[i].chain = tail;
> > -
> > - /* call rt_free on entries after the tail requiring flush */
> > - prev = &rt_hash_table[i].chain;
> > - for (p = *prev; p; p = next) {
> > - next = p->dst.rt_next;
> > - if (!rt_is_expired(p)) {
> > - prev = &p->dst.rt_next;
> > - } else {
> > - *prev = next;
> > - rt_free(p);
> > - }
> > - }
> > + rth->dst.rt_next = list;
> > + list = rth;
>
> I was wondering about RCU rules here.
> We change pointers while a reader might enter in a loop.
> It seems fine : At soon as we spin_unlock(), the loop should be closed.
I don't see where the structure pointed to by list came from, but
especially if it is newly allocated, we do need an rcu_assign_pointer().
Thanx, Paul
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> minor coding style : You should add a brace in the else clause :
>
> pprev = &rt_hash_table[i].chain;
> for (rth = *pprev; rth != NULL; rth = next) {
> next = rth->dst.rt_next;
> if (net_eq(dev_net(rth->dst.dev), net)) {
> *pprev = next;
> rth->dst.rt_next = list;
> list = rth;
> } else {
> pprev = &rth->dst.rt_next;
> }
> }
>
> Thanks !
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 3/7] bnx2: Update bnx2 to use new vlan accleration.
From: Michael Chan @ 2010-10-14 22:56 UTC (permalink / raw)
To: Jesse Gross; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1287000177-7126-4-git-send-email-jesse@nicira.com>
On Wed, 2010-10-13 at 13:02 -0700, Jesse Gross wrote:
> Make the bnx2 driver use the new vlan accleration model.
>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
> CC: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/bnx2.c | 75 +++------------------------------------------------
> drivers/net/bnx2.h | 4 ---
> 2 files changed, 5 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index ae894bc..2d306f4 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -37,9 +37,6 @@
> #include <linux/ethtool.h>
> #include <linux/mii.h>
> #include <linux/if_vlan.h>
> -#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
> -#define BCM_VLAN 1
> -#endif
> #include <net/ip.h>
> #include <net/tcp.h>
> #include <net/checksum.h>
> @@ -3087,8 +3084,6 @@ bnx2_rx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget)
> struct sw_bd *rx_buf, *next_rx_buf;
> struct sk_buff *skb;
> dma_addr_t dma_addr;
> - u16 vtag = 0;
> - int hw_vlan __maybe_unused = 0;
>
> sw_ring_cons = RX_RING_IDX(sw_cons);
> sw_ring_prod = RX_RING_IDX(sw_prod);
> @@ -3168,23 +3163,8 @@ bnx2_rx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget)
> goto next_rx;
>
> if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) &&
> - !(bp->rx_mode & BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG)) {
> - vtag = rx_hdr->l2_fhdr_vlan_tag;
> -#ifdef BCM_VLAN
> - if (bp->vlgrp)
> - hw_vlan = 1;
> - else
> -#endif
> - {
> - struct vlan_ethhdr *ve = (struct vlan_ethhdr *)
> - __skb_push(skb, 4);
> -
> - memmove(ve, skb->data + 4, ETH_ALEN * 2);
> - ve->h_vlan_proto = htons(ETH_P_8021Q);
> - ve->h_vlan_TCI = htons(vtag);
> - len += 4;
> - }
> - }
> + !(bp->rx_mode & BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG))
This check for the rx_mode bit is no longer necessary if we always
configure the chip to strip out the vlan tag.
> + __vlan_hwaccel_put_tag(skb, rx_hdr->l2_fhdr_vlan_tag);
>
> skb->protocol = eth_type_trans(skb, bp->dev);
>
> @@ -3211,14 +3191,7 @@ bnx2_rx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget)
> skb->rxhash = rx_hdr->l2_fhdr_hash;
>
> skb_record_rx_queue(skb, bnapi - &bp->bnx2_napi[0]);
> -
> -#ifdef BCM_VLAN
> - if (hw_vlan)
> - vlan_gro_receive(&bnapi->napi, bp->vlgrp, vtag, skb);
> - else
> -#endif
> - napi_gro_receive(&bnapi->napi, skb);
> -
> + napi_gro_receive(&bnapi->napi, skb);
> rx_pkt++;
>
> next_rx:
> @@ -3533,13 +3506,6 @@ bnx2_set_rx_mode(struct net_device *dev)
> rx_mode = bp->rx_mode & ~(BNX2_EMAC_RX_MODE_PROMISCUOUS |
> BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG);
> sort_mode = 1 | BNX2_RPM_SORT_USER0_BC_EN;
> -#ifdef BCM_VLAN
> - if (!bp->vlgrp && (bp->flags & BNX2_FLAG_CAN_KEEP_VLAN))
> - rx_mode |= BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG;
> -#else
> - if (bp->flags & BNX2_FLAG_CAN_KEEP_VLAN)
> - rx_mode |= BNX2_EMAC_RX_MODE_KEEP_VLAN_TAG;
> -#endif
> if (dev->flags & IFF_PROMISC) {
> /* Promiscuous mode. */
> rx_mode |= BNX2_EMAC_RX_MODE_PROMISCUOUS;
> @@ -6365,29 +6331,6 @@ bnx2_tx_timeout(struct net_device *dev)
> schedule_work(&bp->reset_task);
> }
>
> -#ifdef BCM_VLAN
> -/* Called with rtnl_lock */
> -static void
> -bnx2_vlan_rx_register(struct net_device *dev, struct vlan_group *vlgrp)
> -{
> - struct bnx2 *bp = netdev_priv(dev);
> -
> - if (netif_running(dev))
> - bnx2_netif_stop(bp, false);
> -
> - bp->vlgrp = vlgrp;
> -
> - if (!netif_running(dev))
> - return;
> -
> - bnx2_set_rx_mode(dev);
> - if (bp->flags & BNX2_FLAG_CAN_KEEP_VLAN)
> - bnx2_fw_sync(bp, BNX2_DRV_MSG_CODE_KEEP_VLAN_UPDATE, 0, 1);
> -
> - bnx2_netif_start(bp, false);
> -}
> -#endif
> -
> /* Called with netif_tx_lock.
> * bnx2_tx_int() runs without netif_tx_lock unless it needs to call
> * netif_wake_queue().
> @@ -6428,12 +6371,11 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device *dev)
> vlan_tag_flags |= TX_BD_FLAGS_TCP_UDP_CKSUM;
> }
>
> -#ifdef BCM_VLAN
> - if (bp->vlgrp && vlan_tx_tag_present(skb)) {
> + if (vlan_tx_tag_present(skb)) {
> vlan_tag_flags |=
> (TX_BD_FLAGS_VLAN_TAG | (vlan_tx_tag_get(skb) << 16));
> }
> -#endif
> +
> if ((mss = skb_shinfo(skb)->gso_size)) {
> u32 tcp_opt_len;
> struct iphdr *iph;
> @@ -8318,9 +8260,6 @@ static const struct net_device_ops bnx2_netdev_ops = {
> .ndo_set_mac_address = bnx2_change_mac_addr,
> .ndo_change_mtu = bnx2_change_mtu,
> .ndo_tx_timeout = bnx2_tx_timeout,
> -#ifdef BCM_VLAN
> - .ndo_vlan_rx_register = bnx2_vlan_rx_register,
> -#endif
> #ifdef CONFIG_NET_POLL_CONTROLLER
> .ndo_poll_controller = poll_bnx2,
> #endif
> @@ -8328,9 +8267,7 @@ static const struct net_device_ops bnx2_netdev_ops = {
>
> static void inline vlan_features_add(struct net_device *dev, unsigned long flags)
> {
> -#ifdef BCM_VLAN
> dev->vlan_features |= flags;
> -#endif
> }
>
> static int __devinit
> @@ -8379,9 +8316,7 @@ bnx2_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev->features |= NETIF_F_IPV6_CSUM;
> vlan_features_add(dev, NETIF_F_IPV6_CSUM);
> }
> -#ifdef BCM_VLAN
> dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
> -#endif
> dev->features |= NETIF_F_TSO | NETIF_F_TSO_ECN;
> vlan_features_add(dev, NETIF_F_TSO | NETIF_F_TSO_ECN);
> if (CHIP_NUM(bp) == CHIP_NUM_5709) {
> diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
> index efdfbc2..4f44db6 100644
> --- a/drivers/net/bnx2.h
> +++ b/drivers/net/bnx2.h
> @@ -6742,10 +6742,6 @@ struct bnx2 {
>
> struct bnx2_napi bnx2_napi[BNX2_MAX_MSIX_VEC];
>
> -#ifdef BCM_VLAN
> - struct vlan_group *vlgrp;
> -#endif
> -
> u32 rx_buf_use_size; /* useable size */
> u32 rx_buf_size; /* with alignment */
> u32 rx_copy_thresh;
^ permalink raw reply
* Re: [PATCH] SIW: Documentation (initial)
From: Randy Dunlap @ 2010-10-14 22:57 UTC (permalink / raw)
To: Bernard Metzler
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1286261747-5288-1-git-send-email-bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
On Tue, 5 Oct 2010 08:55:47 +0200 Bernard Metzler wrote:
> ---
> Documentation/networking/siw.txt | 91 ++++++++++++++++++++++++++++++++++++++
> 1 files changed, 91 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/networking/siw.txt
>
> diff --git a/Documentation/networking/siw.txt b/Documentation/networking/siw.txt
> new file mode 100644
> index 0000000..f051d8b
> --- /dev/null
> +++ b/Documentation/networking/siw.txt
> @@ -0,0 +1,91 @@
> +SoftiWARP: Software iWARP kernel driver module.
> +
> +General
> +-------
> +SoftiWARP (siw) implements the iWARP protocol suite (MPA/DDP/RDMAP,
> +IETF-RFC 5044/5041/5040) completely in software as a Linux kernel module.
> +siw runs on top of TCP kernel sockets and exports the Linux kernel ibvers
^^^^^^
Is that "ibverbs"? (just checking)
> +RDMA interface. siw interfaces with the iwcm connection manager.
> +
> +
> +Transmit Path
> +-------------
> +If a send queue (SQ) work queue element gets posted, siw tries to send
> +it directly out of the application context. If the SQ was non-empty,
> +SQ processing is done asynchronously by a kernel worker thread. This
> +thread gets scheduled, if the TCP socket signals new write space to
drop the comma.
> +be available. If during send operation the socket send space get
becomes
(or "is")
> +exhausted, SQ processing is abandoned until new socket write space
> +becomes available.
> +
> +
> +Receive Path
> +------------
> +All application data is placed into target buffers within softirq
> +socket callback. Application notification is asynchronous.
> +
> +
> +User Interface
> +--------------
> +All fast path operations such as posting of work requests and
> +reaping of work completions currently involve a system call into
> +the siw module. Kernel/user-mapped send and receive as well as
I didn't find the system call(s). Are they new syscalls or just
(socket) reads/writes? (I was probably looking for new syscalls.)
> +completion queues are not part of the current code. In
> +particular, mapped completion queues may improve performance,
> +since reaping completion queue entries as well as re-arming
> +the completion queue could be done more efficiently.
> +
> +
> +Memory Management
> +-----------------
> +siw currently uses kernels ib_umem_get() function to pin memory for later
the kernel's
> +use in data transfer operations. Transmit and receive memory is checked
are checked
(or change "and" to "or")
> +against correct access permissions only in the moment of access by the
> +network input path or before pushing it to the socket for transmission.
> +ib_umem_get() provides DMA mappings for the requested address space which
> +is not used by siw.
> +
> +
> +Module Parameters
> +-----------------
> +The following siw module parameters are recognized.
> +loopback_enabled:
> + If set, siw attaches also to the looback device. Checked only
> + during module insertion.
> +
> +mpa_crc_enabled:
> + If set, the MPA CRC gets generated and checked both in tx and rx
> + path. Without hardware support, setting this flag will severely
> + hurt throughput.
> +
> +zcopy_tx:
> + If set, payload of non signalled work requests
non-signalled
> + (such as non signalled WRITE or SEND as well as all READ
non-signalled
> + responses) are transferred using the TCP sockets
socket's
> + sendpage interface. This parameter can be switched on and
> + off dynamically (echo 1 >> /sys/module/siw/parameters/zcopy_tx
> + for enablement, 0 for disabling). System load may benefits from
benefit
> + using 0copy data transmission. 0copy is not enabled if
> + mpa_crc_enabled is set.
> +
> +
> +Compile Time Flags:
> +-DCHECK_DMA_CAPABILITIES
> + Checks if the device siw wants to attach to provides
> + DMA capabilities. While DMA capabilities are currently not
> + needed (siw works on top of a kernel TCP socket), siw
> + uses ib_umem_get() which performs a (not used) DMA address
> + translation. Writing a siw private memory reservation and
> + pinning routine would solve the issue.
> +
> +-DSIW_TX_FULLSEGS
> + Experimental, not enabled by default. If set,
> + siw tries not to overrun the socket (not sending until
> + -EAGAIN retrun), but stops sending if the current segment
return),
> + would not fit into the socket's estimated tx buffer. With that,
> + wire FPDUs may get truncated by the TCP stack far less often.
> + Since this feature manipulates the sock's SOCK_NOSPACE
> + bit, it violates strict layering and is therefore considered
> + proprietary.
> + Since TCP is a byte stream protocol, no guarantee can be given
> + if FPDU's are not fragmented.
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 2/7] vlan: Centralize handling of hardware acceleration.
From: Jesse Gross @ 2010-10-14 22:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <1287004334.2649.43.camel@edumazet-laptop>
On Wed, Oct 13, 2010 at 2:12 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 13 octobre 2010 à 13:02 -0700, Jesse Gross a écrit :
>> +#define VLAN_N_VID 4096
>>
>
> This should be a patch on its own (change VLAN_GROUP_ARRAY_LEN to
> VLAN_N_ID), because this patch is too big.
That's fine, I separated it out.
>
> Please try to not change too many things at once, you remove many
> temporary variables and this only makes review very time consuming.
For what's worth, it used to be worse: originally all seven of these
patches were one...
>> #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
>> +/* Must be invoked with rcu_read_lock or with RTNL. */
>> +static inline struct net_device *vlan_find_dev(struct net_device *real_dev,
>> + u16 vlan_id)
>> +{
>> + struct vlan_group *grp = rcu_dereference(real_dev->vlgrp);
>> +
>
> This rcu_dereference() doesnt match the comment.
>
> You might want rcu_dereference_rtnl() instead and use CONFIG_PROVE_RCU
Sure, I changed it to use rcu_dereference_rtnl().
>> static inline int netif_needs_gso(struct net_device *dev, struct sk_buff *skb)
>> {
>> + int features = dev->features;
>> +
>> + if (skb->protocol == htons(ETH_P_8021Q) || skb->vlan_tci)
>> + features &= dev->vlan_features;
>> +
>> return skb_is_gso(skb) &&
>> - (!skb_gso_ok(skb, dev->features) ||
>> + (!skb_gso_ok(skb, features) ||
>> unlikely(skb->ip_summed != CHECKSUM_PARTIAL));
>
>
> Maybe reorder tests to common case, avoiding some uneeded computations
> if !skb_is_gso()
That's a good idea, thanks.
>> -void vlan_hwaccel_do_receive(struct sk_buff *skb)
>> -{
>> - struct net_device *dev = skb->dev;
>
> this temporary variable was nice for a better code readability
I changed all these references to use vlan_dev.
>
>> - struct vlan_rx_stats *rx_stats;
>> + if (netpoll_receive_skb(skb))
>> + return NET_RX_DROP;
>>
>> - skb->dev = vlan_dev_real_dev(dev);
>
>> netif_nit_deliver(skb);
> Strange you dont change netif_nit_deliver() ?
netif_nit_deliver() is used in pretty much the same manner that it was
before, which is why I didn't change it. Specifically, it can already
handle pulling the tag out of skb->vlan_tci on the underlying device.
tcpdump works as expected after my changes. Is there something that
you think I'm missing?
> I believe this stuff is a great idea, but you should take more time to
> make your patches more understandable.
>
> Given 2.6.36 is about to be released, and Netfilter Workshop 2010 begins
> in few days, there is no hurry, because there is no chance we add so
> many fundamental changes before three weeks at least.
>
> I believe this patch (2/7), should be split in small units, maybe 3 or 4
> different patches.
Thanks for the review Eric. I made the above changes plus broke this
patch down into 4 separate components (and you're right, it is much
easier to look through). I'll hold onto the series until things open
up again. In the meantime I'll also try to convert over more of the
drivers.
Thanks again.
^ permalink raw reply
* Re: [RFC PATCH net-next] drivers/net Documentation/networking: Create directory intel_wired_lan
From: Jeff Kirsher @ 2010-10-14 22:20 UTC (permalink / raw)
To: Joe Perches
Cc: Michal Marek, Sam Ravnborg, linux-kbuild@vger.kernel.org,
Brandeburg, Jesse, Allan, Bruce W, Wyborny, Carolyn,
Skidmore, Donald C, Rose, Gregory V, Waskiewicz Jr, Peter P,
Duyck, Alexander H, Ronciak, John, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, e1000-devel
In-Reply-To: <1287084643.1117.602.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]
On Thu, 2010-10-14 at 12:30 -0700, Joe Perches wrote:
> On Thu, 2010-10-14 at 02:34 -0700, Jeff Kirsher wrote:
> > On Wed, 2010-10-13 at 22:57 -0700, Joe Perches wrote:
> > > On Wed, 2010-10-13 at 21:57 -0700, Jeff Kirsher wrote:
> > > > On Wed, 2010-10-13 at 15:28 -0700, Joe Perches wrote:
> > > > Sorry I am not ignoring you, I was taking a closer look at your patch.
> > > > > What regression testing would actually be done?
> > > > The Makefile and Kconfig needs more work. I applied your patch and none
> > > > of the Intel Wired drivers build.
> > > Care to describe the Makefile/Kconfig issues you have seen?
> > > I built it allyesconfig, defconfig, allmodconfig and allnoconfig.
> > Yeah, I found all of those built without errors, but if you build the
> > Intel Wired LAN drivers as modules, you will not find the *.ko files
> > after the build. The Kconfig files look fine, the problem was with the
> > Makefiles. Instead of creating a drivers/net/intel_wired_lan/Makefile,
> > I simply changed the path in drivers/net/Makefile to the updated path
> > and that resolved the issue.
>
> (adding a few cc's and a link for history)
>
> http://lkml.org/lkml/2010/10/10/207
>
> That's the way I had done it originally as well, but I found
> you couldn't build the directory with:
>
> make drivers/net/intel_wired_lan/
>
> so I created a Makefile in the new directory below with
> the elements necessary.
>
> Perhaps there's some missing functionality in the build system
> when the Kconfig file resides in a higher directory and the
> directory being built doesn't have a Kconfig file?
>
> I think it'd wrong to duplicate the makefile components in
> 2 places to allow "make subdir/" and I wonder if there's a
> good solution for this.
>
> > As far as the sub-directory name "intel_wired_lan", what about "intel"
> > or "intel_wired"? Just a thought...
>
> Using "intel" seemed too sweeping because of the wireless drivers.
> I think intel_wired_lan isn't overly long, but your choice...
>
> Should the new (OKI?/intel) pch_gbe directory be moved as well?
> It's using a PCI_VENDOR_ID_INTEL.
>
>
No, the pch_gbe is not our driver.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] tipc: cleanup function namespace
From: Stephen Hemminger @ 2010-10-14 22:13 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Neil Horman, David Miller, netdev, allan.stephens, Jon Maloy
In-Reply-To: <20101014214426.GA9236@windriver.com>
On Thu, 14 Oct 2010 17:44:27 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> [Re: [PATCH net-next] tipc: cleanup function namespace] On 14/10/2010 (Thu 11:33) Stephen Hemminger wrote:
>
> > On Thu, 14 Oct 2010 13:53:21 -0400
> > Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> >
> > > On 10-10-13 09:29 PM, Neil Horman wrote:
> > > > On Wed, Oct 13, 2010 at 08:23:24PM -0400, Paul Gortmaker wrote:
> > > >> On 10-10-13 07:20 PM, Stephen Hemminger wrote:
> > > >>> Do some cleanups of TIPC based on make namespacecheck
> > > >>> 1. Don't export unused symbols
> > > >>> 2. Eliminate dead code
> > > >>> 3. Make functions and variables local
> > > >>> 4. Rename buf_acquire to tipc_buf_acquire since it is used in several files
> > > >>>
> > > >>> Compile tested only.
> > > >>> This make break out of tree kernel modules that depend on TIPC routines.
> > > >>
> > > >> Hi Stephen,
> > > >>
> > > >> When I first started looking at TIPC code, I too came to the
> > > >> same conclusion as you did and was about to do #1,2,3 -- but
> > > >> then I was told that the exported symbols were part of an API
> > > >> and might be in use by folks here and there as per this thread:
> > > >>
> > > >> http://www.mail-archive.com/netdev@vger.kernel.org/msg30208.html
> > > >>
> > > > I think its telling the the argument in the above thread for keeping the API
> > > > were that users of it were out there and 'likely to contribute' in the future.
> > > > That thread was 3 years ago. They might be using the API from outside the
> > > > kernel tree, but they're not planning on contributing. As Christoph noted,
> > > > they're freeloaders. The community really doesn't need or want to maintain an
> > > > API like that. If these users are your customers, and removing the API is
> > > > unacceptable, perhaps its time to move the entire TIPC module out of tree.
> > >
> > > As I'd said -- I don't know what the use cases of these API users are,
> > > and so as far as I know they aren't customers either. For what it is
> > > worth, know that I personally wouldn't try and use a business case to
> > > justify a technically wrong decision here on netdev anyway.
> > >
> > > I was just describing the history of the situation, and suggesting
> > > one possible slower approach of phasing it out as a courtesy to those
> > > users, in the same way that the kernel community has extended that
> > > same courtesy with other things in feature-removal.txt
> > >
> > > In the end, since Jon is OK with the removal, and is in the process of
> > > communicating this to the API users he is aware of, I sure don't have
> > > any reason to try and save the API. If folks are good with having it
> > > just go away overnight, then great -- I'll be just as happy to see it
> > > disappear as you and Stephen. So, a long winded way of saying...
> > >
> > > Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> >
> > How about putting an entry in feature-removal.txt with a short (6 month)
> > window?
>
> I'm fine with that too.
>
> P.
>
> From 5a15a26de63a29fcb6cb7a7fb83b6d2fc63cbadb Mon Sep 17 00:00:00 2001
> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Thu, 14 Oct 2010 17:29:08 -0400
> Subject: [PATCH] TIPC: Document the demise of the Native API for March 2011
>
> The native API in the TIPC code exists as a bunch of functions
> and exported symbols that aren't actually used by any currently
> in-tree kernel code/modules.
>
> Since this code is anomalous to the general guiding principle that
> the kernel should not be libc, coverage tools and people intending
> to do general cleanups keep finding this code and suggesting that
> it be removed.
>
> It seems the right thing to do is to just finally delete it once
> and for all, after giving a reasonable window for any existing
> users to find alternative solutions to their custom use case(s).
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> Documentation/feature-removal-schedule.txt | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> index f456389..1def37e 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -573,3 +573,15 @@ Why: Hareware scan is the prefer method for iwlwifi devices for
> Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>
> ----------------------------
> +
> +What: TIPC: Delete all code and exported symbols specific to Native API
> +When: March 2011
> +Why: The TIPC Native API, as described here:
> + http://tipc.sourceforge.net/doc/tipc_1.7_prog_guide.html#native_api
> + is implemented by exporting a bunch of otherwise unused functions
> + for possible modular linkage by custom end-user code. This goes
> + against the general concept that the kernel should not be libc.
> +
> +Who: Paul Gortmaker <paul.gortmaker@windriver.com>
> +
> +----------------------------
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Jeff Kirsher @ 2010-10-14 22:07 UTC (permalink / raw)
To: Stephen Rothwell, Harvey Harrison
Cc: David Miller, netdev@vger.kernel.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Tantilov, Emil S
In-Reply-To: <20101015113854.ae080284.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
On Thu, 2010-10-14 at 17:38 -0700, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_configure_dcb':
> drivers/net/ixgbe/ixgbe_main.c:3377: error: implicit declaration of function 'ixgbe_dcb_check_config'
>
> Caused by commit f32f837b75233588cd4f8542214a30915ab7847b ("ixgbe: remove
> unused functions").
>
> Grep is your friend :-)
>
> I have used the net tree from next-20101014 for today.
I apologize, this is my fault. I have a patch coming to resolved the
issue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] tipc: cleanup function namespace
From: Paul Gortmaker @ 2010-10-14 21:44 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Neil Horman, David Miller, netdev, allan.stephens, Jon Maloy
In-Reply-To: <20101014113320.7720828f@nehalam>
[Re: [PATCH net-next] tipc: cleanup function namespace] On 14/10/2010 (Thu 11:33) Stephen Hemminger wrote:
> On Thu, 14 Oct 2010 13:53:21 -0400
> Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> > On 10-10-13 09:29 PM, Neil Horman wrote:
> > > On Wed, Oct 13, 2010 at 08:23:24PM -0400, Paul Gortmaker wrote:
> > >> On 10-10-13 07:20 PM, Stephen Hemminger wrote:
> > >>> Do some cleanups of TIPC based on make namespacecheck
> > >>> 1. Don't export unused symbols
> > >>> 2. Eliminate dead code
> > >>> 3. Make functions and variables local
> > >>> 4. Rename buf_acquire to tipc_buf_acquire since it is used in several files
> > >>>
> > >>> Compile tested only.
> > >>> This make break out of tree kernel modules that depend on TIPC routines.
> > >>
> > >> Hi Stephen,
> > >>
> > >> When I first started looking at TIPC code, I too came to the
> > >> same conclusion as you did and was about to do #1,2,3 -- but
> > >> then I was told that the exported symbols were part of an API
> > >> and might be in use by folks here and there as per this thread:
> > >>
> > >> http://www.mail-archive.com/netdev@vger.kernel.org/msg30208.html
> > >>
> > > I think its telling the the argument in the above thread for keeping the API
> > > were that users of it were out there and 'likely to contribute' in the future.
> > > That thread was 3 years ago. They might be using the API from outside the
> > > kernel tree, but they're not planning on contributing. As Christoph noted,
> > > they're freeloaders. The community really doesn't need or want to maintain an
> > > API like that. If these users are your customers, and removing the API is
> > > unacceptable, perhaps its time to move the entire TIPC module out of tree.
> >
> > As I'd said -- I don't know what the use cases of these API users are,
> > and so as far as I know they aren't customers either. For what it is
> > worth, know that I personally wouldn't try and use a business case to
> > justify a technically wrong decision here on netdev anyway.
> >
> > I was just describing the history of the situation, and suggesting
> > one possible slower approach of phasing it out as a courtesy to those
> > users, in the same way that the kernel community has extended that
> > same courtesy with other things in feature-removal.txt
> >
> > In the end, since Jon is OK with the removal, and is in the process of
> > communicating this to the API users he is aware of, I sure don't have
> > any reason to try and save the API. If folks are good with having it
> > just go away overnight, then great -- I'll be just as happy to see it
> > disappear as you and Stephen. So, a long winded way of saying...
> >
> > Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> How about putting an entry in feature-removal.txt with a short (6 month)
> window?
I'm fine with that too.
P.
>From 5a15a26de63a29fcb6cb7a7fb83b6d2fc63cbadb Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 14 Oct 2010 17:29:08 -0400
Subject: [PATCH] TIPC: Document the demise of the Native API for March 2011
The native API in the TIPC code exists as a bunch of functions
and exported symbols that aren't actually used by any currently
in-tree kernel code/modules.
Since this code is anomalous to the general guiding principle that
the kernel should not be libc, coverage tools and people intending
to do general cleanups keep finding this code and suggesting that
it be removed.
It seems the right thing to do is to just finally delete it once
and for all, after giving a reasonable window for any existing
users to find alternative solutions to their custom use case(s).
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Documentation/feature-removal-schedule.txt | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index f456389..1def37e 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -573,3 +573,15 @@ Why: Hareware scan is the prefer method for iwlwifi devices for
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
----------------------------
+
+What: TIPC: Delete all code and exported symbols specific to Native API
+When: March 2011
+Why: The TIPC Native API, as described here:
+ http://tipc.sourceforge.net/doc/tipc_1.7_prog_guide.html#native_api
+ is implemented by exporting a bunch of otherwise unused functions
+ for possible modular linkage by custom end-user code. This goes
+ against the general concept that the kernel should not be libc.
+
+Who: Paul Gortmaker <paul.gortmaker@windriver.com>
+
+----------------------------
--
1.7.2.1
^ permalink raw reply related
* Re: [RFC PATCH net-next] drivers/net Documentation/networking: Create directory intel_wired_lan
From: Michal Marek @ 2010-10-14 21:37 UTC (permalink / raw)
To: Joe Perches
Cc: linux-kbuild, e1000-devel, Allan, Bruce W, Brandeburg, Jesse,
linux-kernel@vger.kernel.org, Rose, Gregory V, Ronciak, John,
jeffrey.t.kirsher, netdev@vger.kernel.org, Sam Ravnborg
In-Reply-To: <1287084643.1117.602.camel@Joe-Laptop>
On 14.10.2010 21:30, Joe Perches wrote:
> On Thu, 2010-10-14 at 02:34 -0700, Jeff Kirsher wrote:
>> On Wed, 2010-10-13 at 22:57 -0700, Joe Perches wrote:
>>> On Wed, 2010-10-13 at 21:57 -0700, Jeff Kirsher wrote:
>>>> On Wed, 2010-10-13 at 15:28 -0700, Joe Perches wrote:
>>>> Sorry I am not ignoring you, I was taking a closer look at your patch.
>>>>> What regression testing would actually be done?
>>>> The Makefile and Kconfig needs more work. I applied your patch and none
>>>> of the Intel Wired drivers build.
>>> Care to describe the Makefile/Kconfig issues you have seen?
>>> I built it allyesconfig, defconfig, allmodconfig and allnoconfig.
>> Yeah, I found all of those built without errors, but if you build the
>> Intel Wired LAN drivers as modules, you will not find the *.ko files
>> after the build. The Kconfig files look fine, the problem was with the
>> Makefiles. Instead of creating a drivers/net/intel_wired_lan/Makefile,
>> I simply changed the path in drivers/net/Makefile to the updated path
>> and that resolved the issue.
>
> (adding a few cc's and a link for history)
>
> http://lkml.org/lkml/2010/10/10/207
>
> That's the way I had done it originally as well, but I found
> you couldn't build the directory with:
>
> make drivers/net/intel_wired_lan/
>
> so I created a Makefile in the new directory below with
> the elements necessary.
>
> Perhaps there's some missing functionality in the build system
> when the Kconfig file resides in a higher directory and the
> directory being built doesn't have a Kconfig file?
This has nothing to do with Kconfig files, I assume you meant Makefiles.
> I think it'd wrong to duplicate the makefile components in
> 2 places to allow "make subdir/" and I wonder if there's a
> good solution for this.
There is no duplication needed, drivers/net/Makefile needs to contain
obj-y += intel_wired_lan/ and drivers/net/intel_wired_lan/Makefile
similar lines for its subdirs. I see your original patch was lacking an
entry in drivers/net/Makefile, so perhaps that was the problem Jeff was
seeing?
Michal
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH net-next 5/8] tg3: Cleanup tg3_alloc_rx_skb()
From: Matt Carlson @ 2010-10-14 20:37 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
src_map is no longer used in tg3_alloc_rx_skb(). Remove it.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index f2d96dd..84530d9 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -4573,12 +4573,11 @@ static int tg3_alloc_rx_skb(struct tg3 *tp, struct tg3_rx_prodring_set *tpr,
u32 opaque_key, u32 dest_idx_unmasked)
{
struct tg3_rx_buffer_desc *desc;
- struct ring_info *map, *src_map;
+ struct ring_info *map;
struct sk_buff *skb;
dma_addr_t mapping;
int skb_size, dest_idx;
- src_map = NULL;
switch (opaque_key) {
case RXD_OPAQUE_RING_STD:
dest_idx = dest_idx_unmasked & tp->rx_std_ring_mask;
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 7/8] tg3: Report invalid link from tg3_get_settings()
From: Matt Carlson @ 2010-10-14 20:37 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
Currently the tg3 driver leaves the speed and duplex fields
uninitialized in tg3_get_settings() if the device is not up. This can
lead to some strange deductions in certain versions of ethtool. When
the device is up and the link is down, the driver reports SPEED_INVALID
and DUPLEX_INVALID for these fields. This patch makes the presentation
consistent by returning SPEED_INVALID and DUPLEX_INVALID when the device
has not been brought up as well.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 17ca0a3..5d30e67 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9807,6 +9807,9 @@ static int tg3_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
if (netif_running(dev)) {
cmd->speed = tp->link_config.active_speed;
cmd->duplex = tp->link_config.active_duplex;
+ } else {
+ cmd->speed = SPEED_INVALID;
+ cmd->duplex = DUPLEX_INVALID;
}
cmd->phy_address = tp->phy_addr;
cmd->transceiver = XCVR_INTERNAL;
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 6/8] tg3: Don't allocate jumbo ring for 5780 class devs
From: Matt Carlson @ 2010-10-14 20:37 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
The 5714, 5715, and 5780 devices do not have a separate rx jumbo
producer ring. This patch changes the code so that resources are not
allocated for it.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 84530d9..17ca0a3 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6219,7 +6219,8 @@ static void tg3_rx_prodring_free(struct tg3 *tp,
tg3_rx_skb_free(tp, &tpr->rx_std_buffers[i],
tp->rx_pkt_map_sz);
- if (tp->tg3_flags & TG3_FLAG_JUMBO_CAPABLE) {
+ if ((tp->tg3_flags & TG3_FLAG_JUMBO_CAPABLE) &&
+ !(tp->tg3_flags2 & TG3_FLG2_5780_CLASS)) {
for (i = 0; i <= tp->rx_jmb_ring_mask; i++)
tg3_rx_skb_free(tp, &tpr->rx_jmb_buffers[i],
TG3_RX_JMB_MAP_SZ);
@@ -6246,7 +6247,7 @@ static int tg3_rx_prodring_alloc(struct tg3 *tp,
if (tpr != &tp->napi[0].prodring) {
memset(&tpr->rx_std_buffers[0], 0,
TG3_RX_STD_BUFF_RING_SIZE(tp));
- if (tp->tg3_flags & TG3_FLAG_JUMBO_CAPABLE)
+ if (tpr->rx_jmb_buffers)
memset(&tpr->rx_jmb_buffers[0], 0,
TG3_RX_JMB_BUFF_RING_SIZE(tp));
goto done;
@@ -6289,7 +6290,8 @@ static int tg3_rx_prodring_alloc(struct tg3 *tp,
}
}
- if (!(tp->tg3_flags & TG3_FLAG_JUMBO_CAPABLE))
+ if (!(tp->tg3_flags & TG3_FLAG_JUMBO_CAPABLE) ||
+ (tp->tg3_flags2 & TG3_FLG2_5780_CLASS))
goto done;
memset(tpr->rx_jmb, 0, TG3_RX_JMB_RING_BYTES(tp));
@@ -6361,7 +6363,8 @@ static int tg3_rx_prodring_init(struct tg3 *tp,
if (!tpr->rx_std)
goto err_out;
- if (tp->tg3_flags & TG3_FLAG_JUMBO_CAPABLE) {
+ if ((tp->tg3_flags & TG3_FLAG_JUMBO_CAPABLE) &&
+ !(tp->tg3_flags2 & TG3_FLG2_5780_CLASS)) {
tpr->rx_jmb_buffers = kzalloc(TG3_RX_JMB_BUFF_RING_SIZE(tp),
GFP_KERNEL);
if (!tpr->rx_jmb_buffers)
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 8/8] tg3: Update version to 3.115
From: Matt Carlson @ 2010-10-14 20:37 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patch updates the tg3 version to 3.115.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 5d30e67..5b4c510 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,10 +69,10 @@
#define DRV_MODULE_NAME "tg3"
#define TG3_MAJ_NUM 3
-#define TG3_MIN_NUM 114
+#define TG3_MIN_NUM 115
#define DRV_MODULE_VERSION \
__stringify(TG3_MAJ_NUM) "." __stringify(TG3_MIN_NUM)
-#define DRV_MODULE_RELDATE "September 30, 2010"
+#define DRV_MODULE_RELDATE "October 14, 2010"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 3/8] tg3: Add clause 45 register accessor methods
From: Matt Carlson @ 2010-10-14 20:37 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patch adds clause 45 register access methods. They will be used in
the following patch.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/tg3.h | 4 ++++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 1c680ff..afcc593 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1162,6 +1162,52 @@ static void tg3_mdio_fini(struct tg3 *tp)
}
}
+static int tg3_phy_cl45_write(struct tg3 *tp, u32 devad, u32 addr, u32 val)
+{
+ int err;
+
+ err = tg3_writephy(tp, MII_TG3_MMD_CTRL, devad);
+ if (err)
+ goto done;
+
+ err = tg3_writephy(tp, MII_TG3_MMD_ADDRESS, addr);
+ if (err)
+ goto done;
+
+ err = tg3_writephy(tp, MII_TG3_MMD_CTRL,
+ MII_TG3_MMD_CTRL_DATA_NOINC | devad);
+ if (err)
+ goto done;
+
+ err = tg3_writephy(tp, MII_TG3_MMD_ADDRESS, val);
+
+done:
+ return err;
+}
+
+static int tg3_phy_cl45_read(struct tg3 *tp, u32 devad, u32 addr, u32 *val)
+{
+ int err;
+
+ err = tg3_writephy(tp, MII_TG3_MMD_CTRL, devad);
+ if (err)
+ goto done;
+
+ err = tg3_writephy(tp, MII_TG3_MMD_ADDRESS, addr);
+ if (err)
+ goto done;
+
+ err = tg3_writephy(tp, MII_TG3_MMD_CTRL,
+ MII_TG3_MMD_CTRL_DATA_NOINC | devad);
+ if (err)
+ goto done;
+
+ err = tg3_readphy(tp, MII_TG3_MMD_ADDRESS, val);
+
+done:
+ return err;
+}
+
/* tp->lock is held. */
static inline void tg3_generate_fw_event(struct tg3 *tp)
{
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 89553c4..99fc306 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2061,6 +2061,10 @@
#define MII_TG3_CTRL_AS_MASTER 0x0800
#define MII_TG3_CTRL_ENABLE_AS_MASTER 0x1000
+#define MII_TG3_MMD_CTRL 0x0d /* MMD Access Control register */
+#define MII_TG3_MMD_CTRL_DATA_NOINC 0x4000
+#define MII_TG3_MMD_ADDRESS 0x0e /* MMD Address Data register */
+
#define MII_TG3_EXT_CTRL 0x10 /* Extended control register */
#define MII_TG3_EXT_CTRL_FIFO_ELASTIC 0x0001
#define MII_TG3_EXT_CTRL_LNK3_LED_MODE 0x0002
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 4/8] tg3: Add EEE support
From: Matt Carlson @ 2010-10-14 20:37 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patch adds Energy Efficient Ethernet (EEE) support for the 5718
device ID and the 57765 B0 asic revision.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/tg3.h | 33 +++++++++++++++-
2 files changed, 146 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index afcc593..f2d96dd 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1584,6 +1584,17 @@ static void tg3_phy_fini(struct tg3 *tp)
}
}
+static int tg3_phydsp_read(struct tg3 *tp, u32 reg, u32 *val)
+{
+ int err;
+
+ err = tg3_writephy(tp, MII_TG3_DSP_ADDRESS, reg);
+ if (!err)
+ err = tg3_readphy(tp, MII_TG3_DSP_RW_PORT, val);
+
+ return err;
+}
+
static int tg3_phydsp_write(struct tg3 *tp, u32 reg, u32 val)
{
int err;
@@ -1747,6 +1758,42 @@ static void tg3_phy_apply_otp(struct tg3 *tp)
tg3_writephy(tp, MII_TG3_AUX_CTRL, phy);
}
+static void tg3_phy_eee_adjust(struct tg3 *tp, u32 current_link_up)
+{
+ u32 val;
+
+ if (!(tp->phy_flags & TG3_PHYFLG_EEE_CAP))
+ return;
+
+ tp->setlpicnt = 0;
+
+ if (tp->link_config.autoneg == AUTONEG_ENABLE &&
+ current_link_up == 1 &&
+ (tp->link_config.active_speed == SPEED_1000 ||
+ (tp->link_config.active_speed == SPEED_100 &&
+ tp->link_config.active_duplex == DUPLEX_FULL))) {
+ u32 eeectl;
+
+ if (tp->link_config.active_speed == SPEED_1000)
+ eeectl = TG3_CPMU_EEE_CTRL_EXIT_16_5_US;
+ else
+ eeectl = TG3_CPMU_EEE_CTRL_EXIT_36_US;
+
+ tw32(TG3_CPMU_EEE_CTRL, eeectl);
+
+ tg3_phy_cl45_read(tp, 0x7, TG3_CL45_D7_EEERES_STAT, &val);
+
+ if (val == TG3_CL45_D7_EEERES_STAT_LP_1000T ||
+ val == TG3_CL45_D7_EEERES_STAT_LP_100TX)
+ tp->setlpicnt = 2;
+ }
+
+ if (!tp->setlpicnt) {
+ val = tr32(TG3_CPMU_EEE_MODE);
+ tw32(TG3_CPMU_EEE_MODE, val & ~TG3_CPMU_EEEMD_LPI_ENABLE);
+ }
+}
+
static int tg3_wait_macro_done(struct tg3 *tp)
{
int limit = 100;
@@ -2921,6 +2968,44 @@ static void tg3_phy_copper_begin(struct tg3 *tp)
tg3_writephy(tp, MII_TG3_CTRL, new_adv);
}
+ if (tp->phy_flags & TG3_PHYFLG_EEE_CAP) {
+ u32 val = 0;
+
+ tw32(TG3_CPMU_EEE_MODE,
+ tr32(TG3_CPMU_EEE_MODE) & ~TG3_CPMU_EEEMD_LPI_ENABLE);
+
+ /* Enable SM_DSP clock and tx 6dB coding. */
+ val = MII_TG3_AUXCTL_SHDWSEL_AUXCTL |
+ MII_TG3_AUXCTL_ACTL_SMDSP_ENA |
+ MII_TG3_AUXCTL_ACTL_TX_6DB;
+ tg3_writephy(tp, MII_TG3_AUX_CTRL, val);
+
+ if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5717 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765) &&
+ !tg3_phydsp_read(tp, MII_TG3_DSP_CH34TP2, &val))
+ tg3_phydsp_write(tp, MII_TG3_DSP_CH34TP2,
+ val | MII_TG3_DSP_CH34TP2_HIBW01);
+
+ if (tp->link_config.autoneg == AUTONEG_ENABLE) {
+ /* Advertise 100-BaseTX EEE ability */
+ if (tp->link_config.advertising &
+ (ADVERTISED_100baseT_Half |
+ ADVERTISED_100baseT_Full))
+ val |= TG3_CL45_D7_EEEADV_CAP_100TX;
+ /* Advertise 1000-BaseT EEE ability */
+ if (tp->link_config.advertising &
+ (ADVERTISED_1000baseT_Half |
+ ADVERTISED_1000baseT_Full))
+ val |= TG3_CL45_D7_EEEADV_CAP_1000T;
+ }
+ tg3_phy_cl45_write(tp, 0x7, TG3_CL45_D7_EEEADV_CAP, val);
+
+ /* Turn off SM_DSP clock. */
+ val = MII_TG3_AUXCTL_SHDWSEL_AUXCTL |
+ MII_TG3_AUXCTL_ACTL_TX_6DB;
+ tg3_writephy(tp, MII_TG3_AUX_CTRL, val);
+ }
+
if (tp->link_config.autoneg == AUTONEG_DISABLE &&
tp->link_config.speed != SPEED_INVALID) {
u32 bmcr, orig_bmcr;
@@ -3282,6 +3367,8 @@ relink:
tw32_f(MAC_MODE, tp->mac_mode);
udelay(40);
+ tg3_phy_eee_adjust(tp, current_link_up);
+
if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) {
/* Polled via timer. */
tw32_f(MAC_EVENT, 0);
@@ -7790,6 +7877,22 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
tw32(TG3_CPMU_LSPD_10MB_CLK, val);
}
+ /* Enable MAC control of LPI */
+ if (tp->phy_flags & TG3_PHYFLG_EEE_CAP) {
+ tw32_f(TG3_CPMU_EEE_LNKIDL_CTRL,
+ TG3_CPMU_EEE_LNKIDL_PCIE_NL0 |
+ TG3_CPMU_EEE_LNKIDL_UART_IDL);
+
+ tw32_f(TG3_CPMU_EEE_CTRL,
+ TG3_CPMU_EEE_CTRL_EXIT_20_1_US);
+
+ tw32_f(TG3_CPMU_EEE_MODE,
+ TG3_CPMU_EEEMD_ERLY_L1_XIT_DET |
+ TG3_CPMU_EEEMD_LPI_IN_TX |
+ TG3_CPMU_EEEMD_LPI_IN_RX |
+ TG3_CPMU_EEEMD_EEE_ENABLE);
+ }
+
/* This works around an issue with Athlon chipsets on
* B3 tigon3 silicon. This bit has no effect on any
* other revision. But do not set this on PCI Express
@@ -8598,6 +8701,12 @@ static void tg3_timer(unsigned long __opaque)
if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS)
tg3_periodic_fetch_stats(tp);
+ if (tp->setlpicnt && !--tp->setlpicnt) {
+ u32 val = tr32(TG3_CPMU_EEE_MODE);
+ tw32(TG3_CPMU_EEE_MODE,
+ val | TG3_CPMU_EEEMD_LPI_ENABLE);
+ }
+
if (tp->tg3_flags & TG3_FLAG_USE_LINKCHG_REG) {
u32 mac_stat;
int phy_event;
@@ -12432,6 +12541,11 @@ static int __devinit tg3_phy_probe(struct tg3 *tp)
}
}
+ if (tp->pdev->device == TG3PCI_DEVICE_TIGON3_5718 ||
+ (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765 &&
+ tp->pci_chip_rev_id != CHIPREV_ID_57765_A0))
+ tp->phy_flags |= TG3_PHYFLG_EEE_CAP;
+
if (!(tp->phy_flags & TG3_PHYFLG_ANY_SERDES) &&
!(tp->tg3_flags3 & TG3_FLG3_ENABLE_APE) &&
!(tp->tg3_flags & TG3_FLAG_ENABLE_ASF)) {
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 99fc306..8342190 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -1091,7 +1091,26 @@
#define CPMU_MUTEX_GNT_DRIVER 0x00001000
#define TG3_CPMU_PHY_STRAP 0x00003664
#define TG3_CPMU_PHY_STRAP_IS_SERDES 0x00000020
-/* 0x3664 --> 0x3800 unused */
+/* 0x3664 --> 0x36b0 unused */
+
+#define TG3_CPMU_EEE_MODE 0x000036b0
+#define TG3_CPMU_EEEMD_ERLY_L1_XIT_DET 0x00000008
+#define TG3_CPMU_EEEMD_LPI_ENABLE 0x00000080
+#define TG3_CPMU_EEEMD_LPI_IN_TX 0x00000100
+#define TG3_CPMU_EEEMD_LPI_IN_RX 0x00000200
+#define TG3_CPMU_EEEMD_EEE_ENABLE 0x00100000
+/* 0x36b4 --> 0x36b8 unused */
+
+#define TG3_CPMU_EEE_LNKIDL_CTRL 0x000036bc
+#define TG3_CPMU_EEE_LNKIDL_PCIE_NL0 0x01000000
+#define TG3_CPMU_EEE_LNKIDL_UART_IDL 0x00000004
+/* 0x36c0 --> 0x36d0 unused */
+
+#define TG3_CPMU_EEE_CTRL 0x000036d0
+#define TG3_CPMU_EEE_CTRL_EXIT_16_5_US 0x0000019d
+#define TG3_CPMU_EEE_CTRL_EXIT_36_US 0x00000384
+#define TG3_CPMU_EEE_CTRL_EXIT_20_1_US 0x000001f8
+/* 0x36d4 --> 0x3800 unused */
/* Mbuf cluster free registers */
#define MBFREE_MODE 0x00003800
@@ -2082,6 +2101,8 @@
#define MII_TG3_DSP_TAP1 0x0001
#define MII_TG3_DSP_TAP1_AGCTGT_DFLT 0x0007
#define MII_TG3_DSP_AADJ1CH0 0x001f
+#define MII_TG3_DSP_CH34TP2 0x4022
+#define MII_TG3_DSP_CH34TP2_HIBW01 0x0010
#define MII_TG3_DSP_AADJ1CH3 0x601f
#define MII_TG3_DSP_AADJ1CH3_ADCCKADJ 0x0002
#define MII_TG3_DSP_EXP1_INT_STAT 0x0f01
@@ -2148,6 +2169,14 @@
#define MII_TG3_TEST1_TRIM_EN 0x0010
#define MII_TG3_TEST1_CRC_EN 0x8000
+/* Clause 45 expansion registers */
+#define TG3_CL45_D7_EEEADV_CAP 0x003c
+#define TG3_CL45_D7_EEEADV_CAP_100TX 0x0002
+#define TG3_CL45_D7_EEEADV_CAP_1000T 0x0004
+#define TG3_CL45_D7_EEERES_STAT 0x803e
+#define TG3_CL45_D7_EEERES_STAT_LP_100TX 0x0002
+#define TG3_CL45_D7_EEERES_STAT_LP_1000T 0x0004
+
/* Fast Ethernet Tranceiver definitions */
#define MII_TG3_FET_PTEST 0x17
@@ -2992,9 +3021,11 @@ struct tg3 {
#define TG3_PHYFLG_BER_BUG 0x00008000
#define TG3_PHYFLG_SERDES_PREEMPHASIS 0x00010000
#define TG3_PHYFLG_PARALLEL_DETECT 0x00020000
+#define TG3_PHYFLG_EEE_CAP 0x00040000
u32 led_ctrl;
u32 phy_otp;
+ u32 setlpicnt;
#define TG3_BPN_SIZE 24
char board_part_number[TG3_BPN_SIZE];
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 2/8] tg3: Disable unused transmit rings
From: Matt Carlson @ 2010-10-14 20:37 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patch allows the driver to disable the additional transmit rings
available on the 5717 and 5719 devices. This is not strictly necessary,
but is done anyways for correctness.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/tg3.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 978ba5d..1c680ff 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7536,6 +7536,9 @@ static void tg3_rings_reset(struct tg3 *tp)
/* Disable all transmit rings but the first. */
if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS))
limit = NIC_SRAM_SEND_RCB + TG3_BDINFO_SIZE * 16;
+ else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5717 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5719)
+ limit = NIC_SRAM_SEND_RCB + TG3_BDINFO_SIZE * 4;
else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57765)
limit = NIC_SRAM_SEND_RCB + TG3_BDINFO_SIZE * 2;
else
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 0/8] tg3: Updates and EEE support
From: Matt Carlson @ 2010-10-14 20:37 UTC (permalink / raw)
To: davem; +Cc: netdev, andy, mcarlson
This patchset integrates a few minor changes and adds EEE support
for the 5717 and 57765 asic revs.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox