Re: [PATCH 4/4] [IrDA] tsap init routine factorisation

[David Miller]

From: [EMAIL PROTECTED]
Date: Mon, 02 Jul 2007 01:14:31 +0300

> This patch extracts common code from irttp_open_tsap() and irttp_dup() 
> into a new function to 1) avoid code duplication, 2) help avoid forgetting 
> object initialization in the tsap duplication path in the future.
> 
> Signed-off-by: G. Liakhovetski <[EMAIL PROTECTED]>
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>

Also applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] [IrDA] kingsun-sir.c charset fix

[David Miller]

From: [EMAIL PROTECTED]
Date: Mon, 02 Jul 2007 01:14:30 +0300

> Cc: Alex Villacís Lasso <[EMAIL PROTECTED]>
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] [IrDA] Monitor mode

[David Miller]

From: [EMAIL PROTECTED]
Date: Mon, 02 Jul 2007 01:14:29 +0300

> Through the IrDA netlink set mode command, we switch to IrDA monitor mode,
> where one IrLAP instance receives all the packets on the media, without ever
> responding to them.
> 
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>

Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] [IrDA] Netlink layer

[David Miller]

From: [EMAIL PROTECTED]
Date: Mon, 02 Jul 2007 01:14:28 +0300

> First IrDA configuration netlink layer implementation.
> Currently, we only support the set/get mode commands.
> 
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>

Patch applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Allow group ownership of TUN/TAP devices (fwd)

[David Miller]

From: Jeff Dike <[EMAIL PROTECTED]>
Date: Thu, 21 Jun 2007 10:59:11 -0400

> On Mon, Jun 18, 2007 at 10:36:54PM -0700, David Miller wrote:
> > This patch looks fine.
> > 
> > I'd like it resubmitted with a proper changelog and signoff, and once
> > I have that I will thus queue it up for the 2.6.23 merge window.
> 
> Introduce a new syscall TUNSETGROUP for group ownership setting of tap
> devices. The user now is allowed to send packages if either his euid or
> his egid matches the one specified via tunctl (via -u or -g
> respecitvely). If both, gid and uid, are set via tunctl, both have to
> match.
> 
> Signed-Off-By: Guido Guenther <[EMAIL PROTECTED]>
> Signed-Off-By: Jeff Dike <[EMAIL PROTECTED]>

Patch applied, thanks a lot!
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [NET_SCHED 04/04]: Remove unnecessary includes

[David Miller]

From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 17:02:23 +0200 (MEST)

> [NET_SCHED]: Remove unnecessary includes
> 
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>

There was a minor conflict with the multi-queue patches but it
was line number noise so I took care of it.

Applied, thanks!
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [NET_SCHED 03/04]: sch_htb: use generic estimator

[David Miller]

From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 23:22:06 +0200

> [NET_SCHED]: sch_htb: use generic estimator
> 
> Use the generic estimator instead of reimplementing (parts of) it.
> For compatibility always create a default estimator for new classes.
> 
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>

Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [NET_SCHED 01/04]: Remove CONFIG_NET_ESTIMATOR option

[David Miller]

From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 17:02:19 +0200 (MEST)

> [NET_SCHED]: Remove CONFIG_NET_ESTIMATOR option
> 
> The generic estimator is always built in anways and all the config options
> does is prevent including a minimal amount of code for setting it up.
> Additionally the option is already automatically selected for most cases.
> 
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>

Applied, thanks Patrick.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [NET_SCHED 02/04]: Remove unnecessary stats_lock pointers

[David Miller]

From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 19 Jun 2007 17:02:21 +0200 (MEST)

> [NET_SCHED]: Remove unnecessary stats_lock pointers
> 
> Remove stats_lock pointers from qdisc-internal structures, in all cases
> it points to dev->queue_lock. The only case where it is necessary is for
> top-level qdiscs, where it might also point to dev->ingress_lock in case
> of the ingress qdisc. Also remove it from actions completely, it always
> points to the actions internal lock.
> 
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resend: [PATCH] pktgen IPSEC 4/4: Add IPSEC support to pktgen

[David Miller]

From: jamal <[EMAIL PROTECTED]>
Date: Tue, 12 Jun 2007 19:08:39 -0400

> commit bfd389bba7654aa118f0949ff0de45a3bce9700c
> Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
> Date:   Tue Jun 12 18:59:33 2007 -0400
> 
> [PKTGEN] IPSEC support
> Added transport mode ESP support for starters.
> I will send more of these modes and types once i have resolved
> the tunnel mode isses.
> 
> Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>

Also applied, thanks Jamal.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resend: [PATCH] pktgen IPSEC 3/4: Introduce xfrm SAD only lookup

[David Miller]

From: jamal <[EMAIL PROTECTED]>
Date: Tue, 12 Jun 2007 19:06:03 -0400

> commit 4fe3190756589ef8155eb97fe725f2564f1fc77d
> Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
> Date:   Tue Jun 12 12:35:39 2007 -0400
> 
> [XFRM] Introduce standalone SAD lookup
> This allows other in-kernel functions to do SAD lookups.
> The only known user at the moment is pktgen.
> 
> Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pktgen IPSEC 2/4: Introduce pktgen sequential flows

[David Miller]

From: jamal <[EMAIL PROTECTED]>
Date: Tue, 12 Jun 2007 08:01:55 -0400

> commit 882c296bb3f153e1ac770a874c75cfb2bab8481b
> Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
> Date:   Tue Jun 12 07:24:00 2007 -0400
> 
> [PKTGEN] Introduce sequential flows
> 
> By default all flows in pktgen are randomly selected.
> This patch introduces ability to have all defined flows to
> be sent sequentially. Robert defined randomness to be the
> default behavior.
> 
> Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pktgen IPSEC 1/4: Centralize pktgen packet overhead management

[David Miller]

From: jamal <[EMAIL PROTECTED]>
Date: Tue, 12 Jun 2007 08:00:28 -0400

> commit 38477d7ddfa58f58cce99bc902b4c18883647a71
> Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
> Date:   Tue Jun 12 06:43:00 2007 -0400
> 
> [PKTGEN] Centralize packet overhead tracking
> Track the extra packet overhead for VLAN tags, MPLS, IPSEC etc
> 
> Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Set low initial rate in rc80211_simple

[David Miller]

From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Mon, 11 Jun 2007 21:24:11 -0400

> From: Larry Finger <[EMAIL PROTECTED]>
> 
> The initial rate for STA's using rc80211_simple is set to the last
> rate in the rate table. For situations for which the signal is weak,
> the rate may be too high for authentication and association. Although
> the rc80211_simple module will adjust the speed, the response may not
> be fast enough for a successful connection. This modification sets the
> initial rate to the lowest supported value.
> 
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

Applied to net-2.6.23
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Add support for SIOCGIWRATE ioctl to provide rate information

[David Miller]

From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Mon, 11 Jun 2007 21:23:19 -0400

> From: Larry Finger <[EMAIL PROTECTED]>
> 
> At present, transmission rate information for mac80211 is available only
> if verbose debugging is turned on, and then only in the logs. This patch
> implements the SIOCGIWRATE ioctl, which adds the current transmission rate to
> the output of iwconfig.
> 
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

This change appears to already be in the tree.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [TCP]: Fix logic breakage due to DSACK separation

[David Miller]

From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Sat, 16 Jun 2007 02:04:25 +0300 (EEST)

> There are still some things I must think carefully in sacktag processing 
> since it does not validate start_seq and end_seq at all which can be 
> abused currently at least in tcp-2.6. ...I would rather put end to the 
> whole russian roulette in tcp-2.6 sacktag rather than fix/think individual 
> cases and leave future modifications of it similarily hazardous. It's not 
> very clear to me how to handle all possible cases of invalid SACK blocks 
> though, perhaps TCP should just ignore such sack blocks without doing 
> any processing based on them, i.e., ignore them whenever start_seq-end_seq 
> does not fully fit to snd_una-snd_nxt (expect DSACK of course, which 
> should be processed if it's between undo_marker-snd_nxt). Do you have any 
> thoughts about this?

I agree.  This is a problem that basically every single TCP stack out
there right now is vulnerable to, lots of cpu processing for invalid
or maliciously created SACK blocks.  This is why I even considered the
RB-Tree stuff at all.

Therefore the earlier we toss out bad SACK blocks the better, and thus
I agree with a scheme that does validation at the earliest stage
possible as you seem to be suggesting.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH tcp-2.6 3/3] [TCP]: Move sack_ok access to obviously named funcs & cleanup

[David Miller]

From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 15 Jun 2007 14:10:30 +0300

> From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
> 
> Previously code had IsReno/IsFack defined as macros that were
> local to tcp_input.c though sack_ok field has users elsewhere
> too for the same purpose. This changes them to static inlines as
> preferred according the current coding style and unifies the
> access to sack_ok across multiple files. Magic bitops of sack_ok
> for FACK and DSACK are also abstracted to functions with
> appropriate names.
> 
> Note:
> - One sack_ok = 1 remains but that's self explanary, i.e., it
>   enables sack
> - Couple of !IsReno cases are changed to tcp_is_sack
> - There were no users for IsDSack => I dropped it
> 
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>

Also applied to tcp-2.6, thanks a lot!
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH tcp-2.6 2/3] [TCP]: Remove num_acked>0 checks from cong.ctrl mods pkts_acked

[David Miller]

From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 15 Jun 2007 14:10:29 +0300

> From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
> 
> There is no need for such check in pkts_acked because the
> callback is not invoked unless at least one segment got fully
> ACKed (i.e., the snd_una moved past skb's end_seq) by the
> cumulative ACK's snd_una advancement.
> 
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>

Applied to tcp-2.6
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH tcp-2.6 1/3] [TCP]: Add tcp_dec_pcount_approx int variant

[David Miller]

From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 15 Jun 2007 14:10:28 +0300

> From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
> 
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>

Applied to tcp-2.6
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Suspicious fackets_out handling

[David Miller]

From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 1 Jun 2007 15:17:00 +0300 (EEST)

> On Thu, 31 May 2007, David Miller wrote:
> 
> > Is it possible to update fastpath_cnt_hint properly perhaps?
> 
> I think that would be valid and even accurate as it can checks skb's
> seq against fastpath_skb_hint->seq. I'm in a hurry and will be a week
> out of reach of internet connectivity but here's quick attempt to deal
> with this cleanly. Compile tested (be extra careful with this one, it's 
> done i a hurry :-)), consider to net-2.6. Considering the marginality of 
> this issue, stable might really be an overkill for this one, only a
> remotely valid concern comes to my mind in this case: possibility
> of fackets_out > packet_out might not be dealt that cleanly everywhere 
> (but I'm sure that you can come to a good decicion about it):
> 
> [PATCH] [TCP]: SACK fastpath did override adjusted fackets_out
> 
> Do same adjustment to SACK fastpath counters provided that
> they're valid.
> 
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>

Since the case is marginal and the patch does need some testing
I'm putting this into net-2.6.23 for now.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/9] [TCP]: Tighten tcp_sock's belt, drop left_out

[David Miller]

From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Thu, 31 May 2007 19:31:21 +0300 (EEST)

> (i.e, how does it show up in oops if tcp_verify_left_out looks like this):
> 
> #define tcp_verify_left_out(tp) BUG_ON(...)
> 
> ...does it still point to the tcp.h line  then or to the
> tcp_sync_left_out(tp) @ line  in tcp_input.c? ...I'll test that
> later on by myself in case you don't know the answer.

Yes a define would make the BUG appear in the function it gets
used in.

Depending upon the configuration and the implementation of BUG()
the same might happen for inline functions too.  For example, if
the BUG() is configured in non-verbose mode and is implemented using
a trap instruction or __builtin_trap().  But you cannot depend
upon this universally of course.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/9] [TCP]: Reduce sacked_out with reno when purging write_queue

[David Miller]

From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Sat, 26 May 2007 11:36:01 +0300

> Previously TCP had a transitional state during which reno
> counted segments that are already below the current window into
> sacked_out, which is now prevented. Re-try now unconditional
> S+L catching (I wonder if we could get that BUG_ON place
> pinpointed more exactly in oops because now inlining makes it
> lose its original context as they always seem to be in
> tcp_ack, #define helps?).
> 
> Beware, this change is not a trivial one and might have some
> unexpected side-effects under obscure conditions since state
> tracking is to happen much later on and the reno sack counting
> was highly depending on the current state.
> 
> This approach conservatively calls just remove_sack and leaves
> reset_sack() calls alone. The best solution to the whole problem
> would be to first calculate the new sacked_out fully (this patch
> does not move reno_sack_reset calls from original sites and thus
> does not implement this). However, that would require very
> invasive change to fastretrans_alert (perhaps even slicing it to
> two halves). Alternatively, all callers of tcp_packets_in_flight
> (i.e., users that depend on sacked_out) should be postponed
> until the new sacked_out has been calculated but it isn't any
> simpler alternative.
> 
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>

So basically the idea behind this patch is to do the update of
the fake RENO sakcs in clean_rtx_queue instead of fixing it up
at the very last moment right before we invoke tcp_try_to_undo_partial().

I like this patch and I can't find any holes in the idea.

But some things have changed in the meantime and this patch
(and probably 9/9 too) don't apply cleanly.  Could you respin
these against current tcp-2.6 so I can apply them?

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/12] use a dynamic pool of sk_buffs to keep up with fast targets

[David Miller]

From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 2 Jul 2007 21:36:36 -0700

> My initial thought is that if there is a legitimate need for this
> new capability then it should be made available to other parts of
> the kernel rather than being private to the AEO driver.

Absolutely.

We even used to have something like this on a per-cpu basis but using
generic SLAB is so much better for caching and NUMA that we got rid of
that.

Every sk_buff private "quicklist" pool implementation you
see should essentially be NAK'd from the get go, it's
meaningless and if it's really needed one should investigate
why SKB allocations become such a problem instead of papering
over the issue. :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/12] use a dynamic pool of sk_buffs to keep up with fast targets

[Andrew Morton]

On Tue, 26 Jun 2007 14:50:11 -0400 "Ed L. Cashin" <[EMAIL PROTECTED]> wrote:

> Use a dynamic pool of sk_buffs to keep up with fast targets.

That's far too skimpy a description of what this patch is doing, what it is
for, what makes AOE need this functionality, etc.

My initial thought is that if there is a legitimate need for this new capability
then it should be made available to other parts of the kernel rather than being
private to the AEO driver.

But 12 words is not enough information for us to make that judgement.

I have one lower-level comment way down below:

> Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>
> ---
>  drivers/block/aoe/aoe.h|5 ++
>  drivers/block/aoe/aoecmd.c |  129 
> +---
>  drivers/block/aoe/aoedev.c |   51 +++---
>  3 files changed, 134 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/block/aoe/aoe.h b/drivers/block/aoe/aoe.h
> index 7fa86dd..55c2f08 100644
> --- a/drivers/block/aoe/aoe.h
> +++ b/drivers/block/aoe/aoe.h
> @@ -98,6 +98,7 @@ enum {
>   MIN_BUFS = 16,
>   NTARGETS = 8,
>   NAOEIFS = 8,
> + NSKBPOOLMAX = 128,
>  
>   TIMERTICK = HZ / 10,
>   MINTIMER = HZ >> 2,
> @@ -147,6 +148,7 @@ struct aoetgt {
>   u16 useme;
>   ulong lastwadj; /* last window adjustment */
>  int wpkts, rpkts;
> +int dataref;
>  };
>  
>  struct aoedev {
> @@ -168,6 +170,9 @@ struct aoedev {
>   spinlock_t lock;
>   struct sk_buff *sendq_hd; /* packets needing to be sent, list head */
>   struct sk_buff *sendq_tl;
> + struct sk_buff *skbpool_hd;
> + struct sk_buff *skbpool_tl;
> + int nskbpool;
>   mempool_t *bufpool; /* for deadlock-free Buf allocation */
>   struct list_head bufq;  /* queue of bios to work on */
>   struct buf *inprocess;  /* the one we're currently working on */
> diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
> index 62ba58c..89df9de 100644
> --- a/drivers/block/aoe/aoecmd.c
> +++ b/drivers/block/aoe/aoecmd.c
> @@ -105,43 +105,102 @@ ifrotate(struct aoetgt *t)
>   }
>  }
>  
> +static void
> +skb_pool_put(struct aoedev *d, struct sk_buff *skb)
> +{
> + if (!d->skbpool_hd)
> + d->skbpool_hd = skb;
> + else
> + d->skbpool_tl->next = skb;
> + d->skbpool_tl = skb;
> +}
> +
> +static struct sk_buff *
> +skb_pool_get(struct aoedev *d)
> +{
> + struct sk_buff *skb;
> +
> + skb = d->skbpool_hd;
> + if (skb)
> + if (atomic_read(&skb_shinfo(skb)->dataref) == 1) {
> + d->skbpool_hd = skb->next;
> + skb->next = NULL;
> + return skb;
> + }
> + if (d->nskbpool < NSKBPOOLMAX)
> + if ((skb = new_skb(ETH_ZLEN))) {
> + d->nskbpool++;
> + return skb;
> + }
> + return NULL;
> +}
> +
> +/* freeframe is where we do our load balancing so it's a little hairy. */
>  static struct frame *
>  freeframe(struct aoedev *d)
>  {
> - struct frame *f, *e;
> + struct frame *f, *e, *rf;
>   struct aoetgt **t;
> - ulong n;
> + struct sk_buff *skb;
>  
>   if (d->targets[0] == NULL) {/* shouldn't happen, but I'm paranoid */
>   printk(KERN_ERR "aoe: NULL TARGETS!\n");
>   return NULL;
>   }
> - t = d->targets;
> - do {
> + t = d->tgt;
> + t++;
> + if (t >= &d->targets[NTARGETS] || !*t)
> + t = d->targets;
> + for (;;) {
> + if ((*t)->nout < (*t)->maxout)
>   if (t != d->htgt)
> - if ((*t)->ifp->nd)
> - if ((*t)->nout < (*t)->maxout) {
> - n = (*t)->nframes;
> + if ((*t)->ifp->nd) {
> + rf = NULL;
>   f = (*t)->frames;
> - e = f + n;
> + e = f + (*t)->nframes;
>   for (; f   if (f->tag != FREETAG)
>   continue;
> - if (atomic_read(&skb_shinfo(f->skb)->dataref) 
> != 1) {
> - n--;
> + skb = f->skb;
> + if (!skb)
> + if (!(f->skb = skb = new_skb(ETH_ZLEN)))
> + continue;
> + if (atomic_read(&skb_shinfo(skb)->dataref) != 
> 1) {
> + if (!rf)
> + rf = f;
>   continue;
>   }
> - skb_shinfo(f->skb)->nr_frags = f->skb->data_len 
> = 0;
> - skb_trim(f->skb, 0);
> +gotone:  skb_shinfo(skb)->nr_frags = 
> skb->data_len = 0;
> + skb_trim(skb, 0);
>   d->tgt = t;
>   ifrotate(

RE: [PATCH] ucc_geth.c, make PHY device optional.

[Li Yang-r58472]

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
> Behalf Of Joakim Tjernlund
> Sent: Tuesday, July 03, 2007 8:52 AM
> To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> Subject: [PATCH] ucc_geth.c, make PHY device optional.
> 
> > This patch makes the PHY optional for ucc_geth.c ethernet driver.
> > This is useful to support a direct mii to mii connection to, for
example,
> > a onboard swicth.
> >
> > Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
> 
Hi Joakim,

I'm wondering if we really need to have the option to disable phylib.
Actually we have made phylib selected by default for ucc_geth.  Many L2
switch chips have the capacity to be controlled.  Therefore they can be
managed as a phy device.  For the MII interface which is not
configurable, shouldn't we use the fixed phy support from Vitaly?

- Leo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [E1000-devel] e1000: backport ich9 support from 7.5.5 ?

[Kok, Auke]

Jason Lunz wrote:

On Mon, Jul 02, 2007 at 05:10:48PM -0700, Rick Jones wrote:
Rambling a bit, and recognizing that "e1000new" was probably just a 
strawman name, but I suspect that a _very_ different name for the new 
driver would be a good thing, rather than a varition on the e1000 theme. 


I rather liked the "e1000e" name suggested by Christoph Hellwig. That
may not be different enough for you, though. Anything but "e1000new";
it won't be new forever.


hehe, yes, true. And the e1000new was just a placeholder. e1000e seems much more 
attractive for me, especially if we end up splitting the driver at the pci/pci-e 
boundary (like ixgb and ixgbe are).


Auke


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [E1000-devel] e1000: backport ich9 support from 7.5.5 ?

[Jason Lunz]

On Mon, Jul 02, 2007 at 05:10:48PM -0700, Rick Jones wrote:
> Rambling a bit, and recognizing that "e1000new" was probably just a 
> strawman name, but I suspect that a _very_ different name for the new 
> driver would be a good thing, rather than a varition on the e1000 theme. 

I rather liked the "e1000e" name suggested by Christoph Hellwig. That
may not be different enough for you, though. Anything but "e1000new";
it won't be new forever.

Jason
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ucc_geth.c, make PHY device optional.

[Joakim Tjernlund]

> This patch makes the PHY optional for ucc_geth.c ethernet driver.
> This is useful to support a direct mii to mii connection to, for example,
> a onboard swicth.
> 
> Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>

[SNIP patch sent last Friday]

Since this is my last week before vacation, I would really like to
get feedback on this patch sooner than later :)

 Jocke

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Inaky Perez-Gonzalez]

On Monday 02 July 2007, Kok, Auke wrote:
> Jeff Garzik wrote:
> > Michael Buesch wrote:
> >> On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote:
> >>> well, FWIW when I started looking at adding these flags I looked in 
> >>> various 
> >>> subsystems in the kernel and picked an implementation that suited. Guess 
> >>> what 
> >>> pci.h has? ...:
> >>>
> >>>   unsigned int msi_enabled:1;
> >>>   unsigned int msix_enabled:1;
> >>>
> >>> this is literally where I copied the example from
> >>>
> >>> I suppose I can fix those, but I really don't understand what all the 
> >>> fuzz is 
> >>> about here. We're only conserving memory and staying far away from the 
> >>> real 
> >> I'm not sure if these bitfields actually _do_ conserve memory.
> >> Generated code gets bigger (need bitwise masks and stuff).
> >> Code also needs memory. It probably only conserves memory, if the
> >> structure is instanciated a lot.
> > 
> > Actually, that's a good point.  On several RISC architectures it 
> > certainly generates bigger code.
> 
>...
>
> but let's stay constructive here:
> 
> ~/git/linux-2.6 $ grep -r 'unsigned int.*:1;' * | wc -l
> 748
> 
> Is anyone going to fix those? If we don't, someone will certainly again 
> submit 
> patches to add more of these bitfields, after all, some very prominent parts 
> of 
> the kernel still use them. Only recently for instance mac80211 merged like 30 
> of 
> these and drivers/net, include etc.. certainly has a lot of these.

I don't think bitfields are broken. Maybe it's the compiler what should be 
fixed (*)

...bitfields are there to save the coder having to type masks by hand. There 
should 
be no difference in the generated code from doing

u32 value = readl(fromsomewhere);
printf("bits 16 & 15 0x%08x\n", value & 0x00018000 >> 15);

union {
  struct {
u32 reserved1:15;
u32 val:2;
   } __attribute__((packed))
   u32 data;
} value;
value.data = readl(fromsomewhere);
printf("bits 16 & 15 0x%08x\n", value.val);

Granted, that looks big, but once you nail it out at your struct definitons, it
makes maintenance much easier when looking at the bitmasks in the specs. Masks 
and
shifts tend to suck on the long term when they accumulate.

-- Inaky


(*) not to mention the endianness mess
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [E1000-devel] e1000: backport ich9 support from 7.5.5 ?

[Rick Jones]

There seems to be a lot of concern over obsoleting the e1000 driver
too quickly, and with confusing users (and startup scripts) about which
driver to load.


Yes.


Obviously, we at Intel want to get e1000new into the kernel as quickly
as possible, and to obsolete e1000 also as quickly as possible.  The
point of this exercise is to reduce our support and maintenance burden,
and e1000new has shown itself internally to be much easier to work on.

So how about this:
- We include e1000new in 2.6.23, along side e1000.  We expose ICH9
  device IDs in e1000new, and gate the rest of the IDs inside
  #ifndef CONFIG_E1000.  This gives distis ICH9 support, along
  with a guarantee of the known e1000 driver.  It also lets the more
  bleeding-edge people turn off e1000 and run with just e1000new to
  work out any kinks.
- For 2.6.24, we reverse the situation:  Gate all device IDs in e1000
  behind #ifndef CONFIG_E1000NEW, and expose all of them in e1000new.
  At this point we (i.e. the community, not just Intel) should be 
  confident in e1000new, and we can mark e1000 as obsolete.  It's still

  a fallback option for those with old/funky/misconfigured hardware.
- After a year (or whatever), we remove e1000.

Seems to me that this plan should appease either everybody or nobody.
We get ICH9 support out there, e1000new gets in the kernel and
exercised, and we get to set a definite date for obsoleting e1000.


What sort of timeframes are we looking at with 2.6.23 and then 2.6.24 
and how might they map to distro releases?  Much as everyone 
wants/encourages folks to test the kernel.org kernels and such, the 
_real_ exposure still seems to come with a distro release.


Rambling a bit, and recognizing that "e1000new" was probably just a 
strawman name, but I suspect that a _very_ different name for the new 
driver would be a good thing, rather than a varition on the e1000 theme. 
 "The Law of the Telephone Game" pretty much guaratees that something 
with "e1000" in its name will be shortened to just "e1000."


How about "elk" (ee el kay) - applying that same "telephone" game 
(consistency? nah) to e1000 to get e1k, which if you look at it quickly 
enough looks like elk.  OK, that's half in jest, but only half.  I may 
be wrong, but I don't think I've seen anyone shortening the current 
e1000 to e1k?


rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Jeff Garzik]

Kok, Auke wrote:

but let's stay constructive here:

~/git/linux-2.6 $ grep -r 'unsigned int.*:1;' * | wc -l
748

Is anyone going to fix those? If we don't, someone will certainly again 
submit patches to add more of these bitfields, after all, some very 
prominent parts of the kernel still use them. Only recently for instance 
mac80211 merged like 30 of these and drivers/net, include etc.. 
certainly has a lot of these.



There is a lot of crap in the kernel.  Just look at all the grotty SCSI 
or char drivers, for example.  The first task is to avoid adding more 
crap :)


Jeff


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Veeraiyan, Ayyappan]

On 7/2/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> 
> But that'll require the single receiver queue version I guess.  The
> netdevice abuse is the only really major issue I see, although I'd of
> course really like to see the driver getting rid of the bitfield abuse
> aswell.

The submitted driver code supports single queue version in case of MSIX
allocation failures... As I said in the other mail, I feel, restricting
to single Rx queue in NAPI mode is better approach till Stephen's and
DaveM' work of separating NAPI from netdevice is done..

> Lots of drivers where the interface name is assigned after request_irq
> just use an internal name, e.g. ixgbeX in the case of this driver.
> 

This sounds ok to me. 

With this change, this is the output..

[EMAIL PROTECTED] src]# ip link
1: lo:  mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: sit0:  mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
3: eth6:  mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:50:8b:05:5f:95 brd ff:ff:ff:ff:ff:ff
29: eth0:  mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:1b:21:01:e4:93 brd ff:ff:ff:ff:ff:ff
30: eth1:  mtu 1500 qdisc noop qlen 1000
link/ether 00:1b:21:01:e4:92 brd ff:ff:ff:ff:ff:ff

[EMAIL PROTECTED] src]# cat /proc/interrupts | grep 29
214:  0  0   PCI-MSI-edge  ixgbe29-lsc
215:  11764  80213   PCI-MSI-edge  ixgbe29-rx7
216:  80257  0   PCI-MSI-edge  ixgbe29-rx6
217:  77331  0   PCI-MSI-edge  ixgbe29-rx5
218:  24201  0   PCI-MSI-edge  ixgbe29-rx4
219:  52911  0   PCI-MSI-edge  ixgbe29-rx3
220: 104591  0   PCI-MSI-edge  ixgbe29-rx2
221:  80249  8   PCI-MSI-edge  ixgbe29-rx1
222: 14  0   PCI-MSI-edge  ixgbe29-rx0
223: 194023 118220   PCI-MSI-edge  ixgbe29-tx0 

Ayyappan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Kok, Auke]

Jeff Garzik wrote:

Michael Buesch wrote:

On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote:
well, FWIW when I started looking at adding these flags I looked in various 
subsystems in the kernel and picked an implementation that suited. Guess what 
pci.h has? ...:


unsigned int msi_enabled:1;
unsigned int msix_enabled:1;

this is literally where I copied the example from

I suppose I can fix those, but I really don't understand what all the fuzz is 
about here. We're only conserving memory and staying far away from the real 

I'm not sure if these bitfields actually _do_ conserve memory.
Generated code gets bigger (need bitwise masks and stuff).
Code also needs memory. It probably only conserves memory, if the
structure is instanciated a lot.


Actually, that's a good point.  On several RISC architectures it 
certainly generates bigger code.


so, even on i386 it does (17 bytes and 6 instructions to test vs. 10:3 if using 
a "bool"):


unsigned int:1:
 8048365:   0f b6 45 f8 movzbl 0xfff8(%ebp),%eax
 8048369:   0c 01   or $0x1,%al
 804836b:   88 45 f8mov%al,0xfff8(%ebp)
 804836e:   0f b6 45 f8 movzbl 0xfff8(%ebp),%eax
 8048372:   24 01   and$0x1,%al
 8048374:   84 c0   test   %al,%al

bool:
 8048365:   c6 45 fb 01 movb   $0x1,0xfffb(%ebp)
 8048369:   0f b6 45 fb movzbl 0xfffb(%ebp),%eax
 804836d:   84 c0   test   %al,%al

unsigned int:
 8048365:   c7 45 f8 01 00 00 00movl   $0x1,0xfff8(%ebp)
 804836c:   8b 45 f8mov0xfff8(%ebp),%eax
 804836f:   85 c0   test   %eax,%eax

using var & flag:
 8048365:   c7 45 f8 01 00 00 00movl   $0x1,0xfff8(%ebp)
 804836c:   8b 45 f8mov0xfff8(%ebp),%eax
 804836f:   25 00 04 00 00  and$0x400,%eax
 8048374:   85 c0   test   %eax,%eax

note that using "var & flag" is slightly larger here... 1 extra instruction and 
7 more bytes.


interesting...


but let's stay constructive here:

~/git/linux-2.6 $ grep -r 'unsigned int.*:1;' * | wc -l
748

Is anyone going to fix those? If we don't, someone will certainly again submit 
patches to add more of these bitfields, after all, some very prominent parts of 
the kernel still use them. Only recently for instance mac80211 merged like 30 of 
these and drivers/net, include etc.. certainly has a lot of these.


Cheers,


Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [E1000-devel] e1000: backport ich9 support from 7.5.5 ?

[Williams, Mitch A]

 

Mark McLoughlin wrote:

>> I disagree, we should not break the current e1000 driver in 
>the kernel while 
>> there is a new driver coming up that introduces ich9 support 
>without breaking 
>> (the old e1000) support for all other devices. This is why 
>we want to drop a new 
>> version of the e1000 driver upstream instead, and put all 
>newer devices in that 
>> driver.
>
>   Clearly some major changes are happening around e1000, 
>but the point
>I'm making is that ich9 support, in particular, doesn't need to be held
>hostage to these longer term changes. I think the backport shows that:
>

There seems to be a lot of concern over obsoleting the e1000 driver
too quickly, and with confusing users (and startup scripts) about which
driver to load.

Obviously, we at Intel want to get e1000new into the kernel as quickly
as possible, and to obsolete e1000 also as quickly as possible.  The
point of this exercise is to reduce our support and maintenance burden,
and e1000new has shown itself internally to be much easier to work on.

So how about this:
- We include e1000new in 2.6.23, along side e1000.  We expose ICH9
  device IDs in e1000new, and gate the rest of the IDs inside
  #ifndef CONFIG_E1000.  This gives distis ICH9 support, along
  with a guarantee of the known e1000 driver.  It also lets the more
  bleeding-edge people turn off e1000 and run with just e1000new to
  work out any kinks.
- For 2.6.24, we reverse the situation:  Gate all device IDs in e1000
  behind #ifndef CONFIG_E1000NEW, and expose all of them in e1000new.
  At this point we (i.e. the community, not just Intel) should be 
  confident in e1000new, and we can mark e1000 as obsolete.  It's still
  a fallback option for those with old/funky/misconfigured hardware.
- After a year (or whatever), we remove e1000.

Seems to me that this plan should appease either everybody or nobody.
We get ICH9 support out there, e1000new gets in the kernel and
exercised,
and we get to set a definite date for obsoleting e1000.

-Mitch
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [WIP][PATCHES] Network xmit batching - tg3 support

[Michael Chan]

On Mon, 2007-07-02 at 14:20 -0700, Matt Carlson wrote:

> 
> Also, I think the count, max_per_txd, and nr_frags fields of the
> tg3_tx_cbdata struct are not needed.

The count field is not needed also.

+struct tg3_tx_cbdata {
+   u32 base_flags;
+   int count;
+   unsigned int max_per_txd;
+   unsigned int nr_frags;
+   unsigned int mss;
+};
+#define TG3_SKB_CB(__skb)   ((struct tg3_tx_cbdata *)&((__skb)->cb[0]))

Only base_flags and mss are needed and these can be determined right
before sending the frame.  So is it better not to store these in the
skb->cb at all?

@@ -3118,12 +3120,16 @@ static void tg3_tx(struct tg3 *tp)
 */
smp_mb();
 
+   dcount = tg3_tx_avail(tp);
if (unlikely(netif_queue_stopped(tp->dev) &&
-(tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH(tp {
+(dcount > TG3_TX_WAKEUP_THRESH(tp {
netif_tx_lock(tp->dev);
+   tp->dev->xmit_win = 1;
if (netif_queue_stopped(tp->dev) &&
-   (tg3_tx_avail(tp) > TG3_TX_WAKEUP_THRESH(tp)))
+   (dcount > TG3_TX_WAKEUP_THRESH(tp))) {
netif_wake_queue(tp->dev);
+   tp->dev->xmit_win = dcount;
+   }
netif_tx_unlock(tp->dev);
}
 }

This is also not right.  tg3_tx() runs without netif_tx_lock().
tg3_tx_avail() can change after you get the netif_tx_lock() and we must
get the updated value again.  If we just rely on dcount, we can call
wake_queue() when the ring is full, or there may be no wakeup when the
ring is empty.



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Veeraiyan, Ayyappan]

On 7/2/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > Fake netdevs are needed for doing the multiple Rx queues in NAPI
mode.
> > We are thinking to solve in 2 ways. Having netdev pointer in ring
> > structure or having an array of netdev pointers in ixgbe_adatper
struct
> > which would be visible to all rings.
> 
> Wait until Davem & I separate NAPI from network device.
> The patch is close to ready for 2.6.24 when this driver will need to
show up.
> 
> Since I know Intel will be forced to backport this to older distro's.
You
> would be best to have a single receive queue version when you have to
make
> it work on the older code.

So far all our testing indicates we need multiple Rx queues to have
better CPU utilization number at 10Gig line rate. So I am thinking
adding the non-NAPI support to the driver (like other 10Gig drivers) and
restrict to single rx queue in case of NAPI. I already have the non-NAPI
version coded up and went through internal testing. I will add this in
the next submission. We will add the multiple Rx queues support in NAPI
mode once when "separate NAPI from network device" is done. Does this
sound ok?

> 
> You only need to store the name for when you are doing request_irq, so
> it can just be a stack temporary.
>

request_irq expects allocated memory not just stack temporary. I glanced
the kernel source.. There are precedents to the way we did.

linux-2.6/source/drivers/usb/core/hcd.c

1594 /* enable irqs just before we start the controller */
1595 if (hcd->driver->irq) {
1596 snprintf(hcd->irq_descr, sizeof(hcd->irq_descr),
"%s:usb%d",
1597 hcd->driver->description,
hcd->self.busnum);
1598 if ((retval = request_irq(irqnum, &usb_hcd_irq,
irqflags,
1599 hcd->irq_descr, hcd)) != 0) {
1600 dev_err(hcd->self.controller,
1601 "request interrupt %d
failed\n", irqnum);
1602 goto err_request_irq;
1603 }

 
> Stephen Hemminger <[EMAIL PROTECTED]>

I appreciate the feedback.

Thanks,
Ayyappa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Cleanup usbnet_probe() return value handling

[Peter Korsgaard]

> "David" == David Brownell <[EMAIL PROTECTED]> writes:

Hi,

 David> I'd rather see the later test updated to match this one.
 David> (Good catch!)

 David> The return convention is "negative means error".  There's
 David> code in USB which has multiple nonnegative success codes.

Ok, updated patch does that instead.

 David> In particular usb_control_msg(), which would very naturally
 David> used as the body of a bind() method, returns negative or
 David> the number of bytes transferred.

Yeah, that was the original problem in my dm9601 driver.

usbnet_probe() handles a positive return value from the driver bind()
function as success, but will later only setup the status handler if the
return value was zero, leading to confusion. Patch adjusts this to accept
positive values as success in both checks.

Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
 drivers/net/usb/usbnet.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.22-rc7/drivers/net/usb/usbnet.c
===
--- linux-2.6.22-rc7.orig/drivers/net/usb/usbnet.c
+++ linux-2.6.22-rc7/drivers/net/usb/usbnet.c
@@ -1208,7 +1208,7 @@
status = 0;
 
}
-   if (status == 0 && dev->status)
+   if (status >= 0 && dev->status)
status = init_status (dev, udev);
if (status < 0)
goto out3;

-- 
Bye, Peter Korsgaard

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Jeff Garzik]

Michael Buesch wrote:

On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote:
well, FWIW when I started looking at adding these flags I looked in various 
subsystems in the kernel and picked an implementation that suited. Guess what 
pci.h has? ...:


unsigned int msi_enabled:1;
unsigned int msix_enabled:1;

this is literally where I copied the example from

I suppose I can fix those, but I really don't understand what all the fuzz is 
about here. We're only conserving memory and staying far away from the real 


I'm not sure if these bitfields actually _do_ conserve memory.
Generated code gets bigger (need bitwise masks and stuff).
Code also needs memory. It probably only conserves memory, if the
structure is instanciated a lot.


Actually, that's a good point.  On several RISC architectures it 
certainly generates bigger code.


Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git patches] net driver fixes

[Stephen Hemminger]

On Tue, 3 Jul 2007 00:13:29 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:

> On Mon, Jul 02, 2007 at 10:54:01AM -0400, Jeff Garzik wrote:
> >...
> > maximilian attems (1):
> >   starfire list alpha as 64 bit arch
> >...
> > --- a/drivers/net/starfire.c
> > +++ b/drivers/net/starfire.c
> > @@ -152,7 +152,7 @@ static int full_duplex[MAX_UNITS] = {0, };
> >   * This SUCKS.
> >   * We need a much better method to determine if dma_addr_t is 64-bit.
> >   */
> > -#if (defined(__i386__) && defined(CONFIG_HIGHMEM64G)) || 
> > defined(__x86_64__) || defined (__ia64__) || defined(__mips64__) || 
> > (defined(__mips__) && defined(CONFIG_HIGHMEM) && 
> > defined(CONFIG_64BIT_PHYS_ADDR))
> > +#if (defined(__i386__) && defined(CONFIG_HIGHMEM64G)) || 
> > defined(__x86_64__) || defined (__ia64__) || defined(__alpha__) || 
> > defined(__mips64__) || (defined(__mips__) && defined(CONFIG_HIGHMEM) && 
> > defined(CONFIG_64BIT_PHYS_ADDR))
> >  /* 64-bit dma_addr_t */
> >  #define ADDR_64BITS/* This chip uses 64 bit addresses. */
> >  #define netdrv_addr_t u64
> >...
> 
> The patch is correct and definitely the best solution at this time of 
> the 2.6.22 development cycle.
> 
> But the comment in the context exactly matches what I thought when
> I saw this code...
> 
> Does anyone have a suggestion how to do this better?
> 
> cu
> Adrian
> 

Yeah, write code that handles it in compiler. Like:
if (sizeof(dma_addr_t) > sizeof(u32)) {
do something...
}
That means that it gets checked even if optimizer removes it as
unneeded.

-- 
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git patches] net driver fixes

[Adrian Bunk]

On Mon, Jul 02, 2007 at 10:54:01AM -0400, Jeff Garzik wrote:
>...
> maximilian attems (1):
>   starfire list alpha as 64 bit arch
>...
> --- a/drivers/net/starfire.c
> +++ b/drivers/net/starfire.c
> @@ -152,7 +152,7 @@ static int full_duplex[MAX_UNITS] = {0, };
>   * This SUCKS.
>   * We need a much better method to determine if dma_addr_t is 64-bit.
>   */
> -#if (defined(__i386__) && defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__) 
> || defined (__ia64__) || defined(__mips64__) || (defined(__mips__) && 
> defined(CONFIG_HIGHMEM) && defined(CONFIG_64BIT_PHYS_ADDR))
> +#if (defined(__i386__) && defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__) 
> || defined (__ia64__) || defined(__alpha__) || defined(__mips64__) || 
> (defined(__mips__) && defined(CONFIG_HIGHMEM) && 
> defined(CONFIG_64BIT_PHYS_ADDR))
>  /* 64-bit dma_addr_t */
>  #define ADDR_64BITS  /* This chip uses 64 bit addresses. */
>  #define netdrv_addr_t u64
>...

The patch is correct and definitely the best solution at this time of 
the 2.6.22 development cycle.

But the comment in the context exactly matches what I thought when
I saw this code...

Does anyone have a suggestion how to do this better?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Michael Buesch]

On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote:
> well, FWIW when I started looking at adding these flags I looked in various 
> subsystems in the kernel and picked an implementation that suited. Guess what 
> pci.h has? ...:
> 
>   unsigned int msi_enabled:1;
>   unsigned int msix_enabled:1;
> 
> this is literally where I copied the example from
> 
> I suppose I can fix those, but I really don't understand what all the fuzz is 
> about here. We're only conserving memory and staying far away from the real 

I'm not sure if these bitfields actually _do_ conserve memory.
Generated code gets bigger (need bitwise masks and stuff).
Code also needs memory. It probably only conserves memory, if the
structure is instanciated a lot.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Jeff Garzik]

Kok, Auke wrote:
I suppose I can fix those, but I really don't understand what all the 
fuzz is about here. We're only conserving memory and staying far away 
from the real risks of bitmasks, so forgive me if I don't grasp the 
problem.


Be it machine ints or bitfields, you're not conserving memory.  Think 
about struct padding.


As to the overall question, I already posted a long list of problems 
with bitfields.  Shall I repeat?


Jeff


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Kok, Auke]

Christoph Hellwig wrote:

On Mon, Jul 02, 2007 at 02:09:58PM -0700, Stephen Hemminger wrote:

The patch is close to ready for 2.6.24 when this driver will need to show up.


If intel manages to fix up the reamining issues I'd rather see it appear
in 2.6.23..


Since I know Intel will be forced to backport this to older distro's. You
would be best to have a single receive queue version when you have to make
it work on the older code.


But that'll require the single receiver queue version I guess.  The
netdevice abuse is the only really major issue I see, although I'd of
course really like to see the driver getting rid of the bitfield abuse
aswell.


well, FWIW when I started looking at adding these flags I looked in various 
subsystems in the kernel and picked an implementation that suited. Guess what 
pci.h has? ...:


unsigned int msi_enabled:1;
unsigned int msix_enabled:1;

this is literally where I copied the example from

I suppose I can fix those, but I really don't understand what all the fuzz is 
about here. We're only conserving memory and staying far away from the real 
risks of bitmasks, so forgive me if I don't grasp the problem.


Honestly, if this is really considered "Bad coding" (TM) then we need to fix 
these prominent abuses of it too.


I count about 60 or so of these bitfields in drivers/net... (and countless more 
in other parts) !


Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: r8169 2.2LK: Low link speed after suspend

[Francois Romieu]

Peter Missel <[EMAIL PROTECTED]> :
[...]
> Unfortunately I couldn't get NFS to work with the updated kernel, so I had to 
> revert to the original from SuSE 10.2.

No NFS but networking or no networking at all ?

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6 patch] the overdue eepro100 removal

[Kok, Auke]

Bill Davidsen wrote:

Adrian Bunk wrote:

This patch contains the overdue removal of the eepro100 driver.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

The hardware supported by this driver is still in use, thanks. It's 
probably easier to leave the eepro100 driver in than find anyone who 
wants to investigate why the other driver (e100? from memory) doesn't 
work with some cards. As I recall this was suggested over a year ago and 
it was decided to leave it in, all of the reasons for doing so still 
seem valid. There really doesn't seem to be a benefit, it's not like 
people are working night and day to support new cards for this chip.




please see the thread "Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: 
or s and el bits)" which is discussing a fix for this issue and currently being 
worked.


eepro100 will *still* be removed once e100 is fixed to support those devices.

Moreover, we now also have a fix for the e100 IPMI issues on some tyan boards 
(patch coming this week!). That hopefully solves all e100 issues that are still 
open.


Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Christoph Hellwig]

On Mon, Jul 02, 2007 at 02:09:58PM -0700, Stephen Hemminger wrote:
> The patch is close to ready for 2.6.24 when this driver will need to show up.

If intel manages to fix up the reamining issues I'd rather see it appear
in 2.6.23..

> Since I know Intel will be forced to backport this to older distro's. You
> would be best to have a single receive queue version when you have to make
> it work on the older code.

But that'll require the single receiver queue version I guess.  The
netdevice abuse is the only really major issue I see, although I'd of
course really like to see the driver getting rid of the bitfield abuse
aswell.

> > Since we wanted to distinguish the various MSIX vectors in
> > /proc/interrupts and since request_irq expects memory for name to be
> > allocated somewhere, I added this part of the ring struct.
> 
> You only need to store the name for when you are doing request_irq, so
> it can just be a stack temporary.  

Lots of drivers where the interface name is assigned after request_irq
just use an internal name, e.g. ixgbeX in the case of this driver.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [WIP][PATCHES] Network xmit batching - tg3 support

[Matt Carlson]

On Wed, 2007-06-27 at 20:05 -0400, jamal wrote:
> peoplez,
> 
> I have added support for tg3 on batching. I see equivalent performance
> improvement for pktgen as i did with e1000 when using gige. 
> I have only tested on two machines (one being a laptop which does
> 10/100Mbps). Unfortunately in both cases these are considered to be in
> the class of  "buggy" tg3s (which take a longer code path).
> 
> To the tg3 folks - can you double check if am off on something?
> I have split a few things that you may like as well.
> I havent upgraded the tree - it is still circa 2.6.22-rc4 based; at some
> point i will sync with Daves net-26
> 
> Anyone who has tg3 based hardware: I would appreciate any testing and
> results ...
> 
> The git tree is at:
> git://git.kernel.org/pub/scm/linux/kernel/git/hadi/batch-lin26.git
> but i have attached the patch in case you just wanna stare.
> 
> cheers,
> jamal

Hi Jamal.  I'll be testing your patch soon, but I wanted to point out a
bug in the patch.  The patch defines TG3_SKB_CB() as follows :

#define TG3_SKB_CB(__skb) ((struct tg3_tx_cbdata *)&((__skb)->cb[0]))

This definition will collide with the VLAN macros if TG3_VLAN_TAG_USED
is set.  vlan_tx_tag_get() is defined as :

#define vlan_tx_tag_get(__skb)  (VLAN_TX_SKB_CB(__skb)->vlan_tag)

VLAN_TX_SKB_CB is defined as :

#define VLAN_TX_SKB_CB(__skb) \
((struct vlan_skb_tx_cookie *)&((__skb)->cb[0]))

Also, I think the count, max_per_txd, and nr_frags fields of the
tg3_tx_cbdata struct are not needed.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Stephen Hemminger]

On Mon, 2 Jul 2007 12:00:29 -0700
"Veeraiyan, Ayyappan" <[EMAIL PROTECTED]> wrote:

> On 7/2/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > Ayyappan Veeraiyan wrote:
> > > +#define IXGBE_TX_FLAGS_VLAN_MASK 0x
> > > +#define IXGBE_TX_FLAGS_VLAN_SHIFT16
> > 
> > defining bits using the form "(1 << n)" is preferred.  Makes it easier
> > to read, by eliminating the requirement of the human brain to decode
> hex
> > into bit numbers.
> > 
> > 
> 
> Ok.
> 
> > > + struct net_device netdev;
> > > + };
> > 
> > Embedded a struct net_device into your ring?  How can I put this?
> > 
> > Wrong, wrong.  Wrong, wrong, wrong.  Wrong.
> > 
> 
> Agreed. 
> Fake netdevs are needed for doing the multiple Rx queues in NAPI mode.
> We are thinking to solve in 2 ways. Having netdev pointer in ring
> structure or having an array of netdev pointers in ixgbe_adatper struct
> which would be visible to all rings.

Wait until Davem & I separate NAPI from network device.
The patch is close to ready for 2.6.24 when this driver will need to show up.

Since I know Intel will be forced to backport this to older distro's. You
would be best to have a single receive queue version when you have to make
it work on the older code.

> > > +
> > > + char name[IFNAMSIZ + 5];
> > 
> > The interface name should not be stored by your ring structure
> >

Gag
 
> Yes, I agree and also (pointed out by someone before) this would break
> if the user changes the interface name..
> But, having the "cause" in the MSIX vector name really helps in
> debugging and helps the user also. 

If you need a unique token use ifindex

> 
> I think the below output is much better
> 
> [EMAIL PROTECTED] src]# cat /proc/interrupts | grep eth0
> 214:  0  0   PCI-MSI-edge  eth0-lsc
> 215:  11763  4   PCI-MSI-edge  eth0-rx7
> 216:  0  0   PCI-MSI-edge  eth0-rx6
> 217:  77324  0   PCI-MSI-edge  eth0-rx5
> 218:  0  0   PCI-MSI-edge  eth0-rx4
> 219:  52911  0   PCI-MSI-edge  eth0-rx3
> 220:  80271  0   PCI-MSI-edge  eth0-rx2
> 221:  80244  6   PCI-MSI-edge  eth0-rx1
> 222: 12  0   PCI-MSI-edge  eth0-rx0
> 223: 124870  28543   PCI-MSI-edge  eth0-tx0
> 
> Compared to 
> 
> [EMAIL PROTECTED] src]# cat /proc/interrupts | grep eth0
> 214:  0  0   PCI-MSI-edge  eth0
> 215:  11763  4   PCI-MSI-edge  eth0
> 216:  0  0   PCI-MSI-edge  eth0
> 217:  77324  0   PCI-MSI-edge  eth0
> 218:  0  0   PCI-MSI-edge  eth0
> 219:  52911  0   PCI-MSI-edge  eth0
> 220:  80271  0   PCI-MSI-edge  eth0
> 221:  80244  6   PCI-MSI-edge  eth0
> 222: 12  0   PCI-MSI-edge  eth0
> 223: 124900  28543   PCI-MSI-edge  eth0
> 
> Since we wanted to distinguish the various MSIX vectors in
> /proc/interrupts and since request_irq expects memory for name to be
> allocated somewhere, I added this part of the ring struct.

You only need to store the name for when you are doing request_irq, so
it can just be a stack temporary.  

> > 
> > Kill io_base and stop setting netdev->base_addr
> 
> In my latest internal version, I already removed the io_base member (and
> couple more from ixgbe_adapter) but still setting the netdev->base_addr.
> I will remove that also..
> 
> > > + struct ixgbe_hw_stats stats;
> > > + char lsc_name[IFNAMSIZ + 5];
> > 
> > delete lsc_name and use netdev name directly in request_irq()
> > 
> 
> Please see the response for the name member of ring structure.
>  
> > 
> > Will review more after you fix these problems.
> > 
> 
> Thanks for the feedback. I will post another version shortly (except the
> feature flags change and the ring struct name members) which fixes my
> previous TODO list and also most of Francois comments..
> 
> Ayyappan


-- 
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Christoph Hellwig]

On Mon, Jul 02, 2007 at 12:00:29PM -0700, Veeraiyan, Ayyappan wrote:
> Agreed. 
> Fake netdevs are needed for doing the multiple Rx queues in NAPI mode.
> We are thinking to solve in 2 ways. Having netdev pointer in ring
> structure or having an array of netdev pointers in ixgbe_adatper struct
> which would be visible to all rings.

Didn't we have a patchset floating around recently that separates NAPI
state from struct netdevice?

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: r8169 2.2LK: Low link speed after suspend

[Peter Missel]

Thanks Francois.

Unfortunately I couldn't get NFS to work with the updated kernel, so I had to 
revert to the original from SuSE 10.2.

The other thing that didn't work with 2.6.21.5 was suspend-to-disk (would 
suspend, but not resume), so I don't have any useful input for you this time.

I'll be back.

regards,
Peter


> Peter Missel <[EMAIL PROTECTED]> :
> [...]
>
> > The patch applies without failure; I'm getting a warning during build,
> >
> >   CC [M]  drivers/net/r8169.o
> > drivers/net/r8169.c: In function ‘rtl8169_start_xmit’:
> > drivers/net/r8169.c:2341: warning: ‘txd’ may be used uninitialized in
> > this function
>
> It's known and harmless. Blame gcc :o)


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] dgrs romove Kconfig option

[Andres Salomon]

On Mon, 2 Jul 2007 15:52:01 +0200
maximilian attems <[EMAIL PROTECTED]> wrote:

> nobody objected to adrian's rfc dropping dgrs on netdev back in dec. 2006.
> -> http://marc.info/?l=linux-netdev&m=116507999803538&w=2
> as bonus points this will get rid of a prorpietary licensed firmware.
> 
> so now be a bit more serious and remove the Kconfig entries
> and see if anyone shouts. if no voice is to be heard as
> expected by zero bug entries on kernel.org or debian.org,
> the full removal is scheduled for 2.6.24.

Why not just do the full removal now?  If someone shouts, it's just as easy
to add it all back.  Leaving around half a driver is just annoying..

-- 
Andres Salomon <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Ayyappan Veeraiyan]

On 7/2/07, Veeraiyan, Ayyappan <[EMAIL PROTECTED]> wrote:


Thanks for the feedback. I will post another version shortly (except the
feature flags change and the ring struct name members) which fixes my


Just to clarify this, I will wait some more time for feature flags
discussion and the ring structure name feedback..

Ayyappan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: quirk_e100_interrupt() called too early

[Kok, Auke]

Nils Rennebarth wrote:

Bjorn Helgaas wrote:

On Thursday 28 June 2007 10:01:08 am Kok, Auke wrote:
I copied Nils Rennebarth, who originally reported the bug:
  http://bugzilla.kernel.org/show_bug.cgi?id=5918
in case he can test your patch.

>
Most of the embedded boards we now work with appear to exhibit the same 
behaviour: During boot the


Firmware left :01:05.0 e100 interrupts enabled, disabling

message appears for all four e100 nics. (The mainboard is a em-8510A 
btw.) When I have time I could try if the quirk still works with the

mentioned patch, but I am quite busy with other things at the moment.


well, we're too late for 2.6.22 I think so you have some time. However I'd like 
to make sure we can get this in with 2.6.23. Alternatively, someone could always 
send me one of these boards ;)


Thanks for taking the time to test

Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2.6 patch] the overdue eepro100 removal

[Bill Davidsen]

Adrian Bunk wrote:

This patch contains the overdue removal of the eepro100 driver.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

The hardware supported by this driver is still in use, thanks. It's 
probably easier to leave the eepro100 driver in than find anyone who 
wants to investigate why the other driver (e100? from memory) doesn't 
work with some cards. As I recall this was suggested over a year ago and 
it was decided to leave it in, all of the reasons for doing so still 
seem valid. There really doesn't seem to be a benefit, it's not like 
people are working night and day to support new cards for this chip.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Veeraiyan, Ayyappan]

On 7/2/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Ayyappan Veeraiyan wrote:
> > +#define IXGBE_TX_FLAGS_VLAN_MASK 0x
> > +#define IXGBE_TX_FLAGS_VLAN_SHIFT16
> 
> defining bits using the form "(1 << n)" is preferred.  Makes it easier
> to read, by eliminating the requirement of the human brain to decode
hex
> into bit numbers.
> 
> 

Ok.

> > + struct net_device netdev;
> > + };
> 
> Embedded a struct net_device into your ring?  How can I put this?
> 
> Wrong, wrong.  Wrong, wrong, wrong.  Wrong.
> 

Agreed. 
Fake netdevs are needed for doing the multiple Rx queues in NAPI mode.
We are thinking to solve in 2 ways. Having netdev pointer in ring
structure or having an array of netdev pointers in ixgbe_adatper struct
which would be visible to all rings.

> > +
> > + char name[IFNAMSIZ + 5];
> 
> The interface name should not be stored by your ring structure
>

Yes, I agree and also (pointed out by someone before) this would break
if the user changes the interface name..
But, having the "cause" in the MSIX vector name really helps in
debugging and helps the user also. 

I think the below output is much better

[EMAIL PROTECTED] src]# cat /proc/interrupts | grep eth0
214:  0  0   PCI-MSI-edge  eth0-lsc
215:  11763  4   PCI-MSI-edge  eth0-rx7
216:  0  0   PCI-MSI-edge  eth0-rx6
217:  77324  0   PCI-MSI-edge  eth0-rx5
218:  0  0   PCI-MSI-edge  eth0-rx4
219:  52911  0   PCI-MSI-edge  eth0-rx3
220:  80271  0   PCI-MSI-edge  eth0-rx2
221:  80244  6   PCI-MSI-edge  eth0-rx1
222: 12  0   PCI-MSI-edge  eth0-rx0
223: 124870  28543   PCI-MSI-edge  eth0-tx0

Compared to 

[EMAIL PROTECTED] src]# cat /proc/interrupts | grep eth0
214:  0  0   PCI-MSI-edge  eth0
215:  11763  4   PCI-MSI-edge  eth0
216:  0  0   PCI-MSI-edge  eth0
217:  77324  0   PCI-MSI-edge  eth0
218:  0  0   PCI-MSI-edge  eth0
219:  52911  0   PCI-MSI-edge  eth0
220:  80271  0   PCI-MSI-edge  eth0
221:  80244  6   PCI-MSI-edge  eth0
222: 12  0   PCI-MSI-edge  eth0
223: 124900  28543   PCI-MSI-edge  eth0

Since we wanted to distinguish the various MSIX vectors in
/proc/interrupts and since request_irq expects memory for name to be
allocated somewhere, I added this part of the ring struct.

> 
> Kill io_base and stop setting netdev->base_addr

In my latest internal version, I already removed the io_base member (and
couple more from ixgbe_adapter) but still setting the netdev->base_addr.
I will remove that also..

> > + struct ixgbe_hw_stats stats;
> > + char lsc_name[IFNAMSIZ + 5];
> 
> delete lsc_name and use netdev name directly in request_irq()
> 

Please see the response for the name member of ring structure.
 
> 
> Will review more after you fix these problems.
> 

Thanks for the feedback. I will post another version shortly (except the
feature flags change and the ring struct name members) which fixes my
previous TODO list and also most of Francois comments..

Ayyappan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [info] What's in netdev-2.6.git?

[Jeff Garzik]

Ben Dooks wrote:

On Mon, Jul 02, 2007 at 11:08:26AM -0400, Jeff Garzik wrote:

This is what is currently queued for 2.6.23.  There are a few patches
in my mbox not yet applied to the git tree, but this is most of them.


I sent driver support for the AX88796 a few weeks ago with no feedback,
should I re-send this CC: you?


Nothing from you in my mbox, so please do resend against 2.6.22-rc7...

Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)

[manio]

Peter Staubach wrote:

[EMAIL PROTECTED] wrote:
To use a NFS-root for UDP jumbo frames the kernel on the client need 
to bring
up interface with MTU set to 9000 bytes - otherwise it cannot contact 
server
with jumbo frames enabled (nfs server not responding, still trying) 
and cannot
boot. Added a kernel parameter named 'ipmtu' which can be used to 
specify

initial MTU size when booting via nfsroot.

  


Could you describe the problem better, please?  Something does not
sound right.  Both ends need to have jumbo frames enabled in order
to use jumbo frames, but if one end or the other does not, the systems
still should be able to exchange packets using normal sized ethernet
packets.  Isn't this a problem that mtu discovery should handle?

   Thanx...

  ps
ok - first of all: yes you're right - if both ends have jumbo frames 
enabled
it is all working fine - the patch is just for enabling client's MTU to 
jumbo

because when booting via NFS-root client's MTU is set to default (1500
in ethernet case). I know that when server has MTU=9000 and client=1500
it should work - but it only work when nfs-root directory is mounted with
TCP protocol. But i mean using UDP frames (then nfs options: wsize and
rsize could be 8192 bytes).

If I'm not clear I'll give you simple example:
My server has jumbo frames enabled (it's not a problem to set it because
server has HDD - can set up MTU during run time).
The problem is when my diskless client need to boot via nfs-root.
With vanilla kernel it looks like this:
1. Client boots
2. PXE get address from DHCP
3. without problem PXE client get kernel from server (via tftpboot)
4. it stop when kernel is going to mount root filesystem from NFS
it still trying because server has jumbo enabled and client doesn't
(endless message: NFS server is not responding, still trying)

If I pass the ipmtu option with 9000 value to client's patched kernel then
all is working fine because both client and server has jumbo frames
enabled and client is able to mount root filesystem via NFS from server.

the problem was some time ago posted by Tupshin Harper:
http://www.ussg.iu.edu/hypermail/linux/kernel/0311.1/1055.html

... and is also described on my webpage:
http://manio.skyboo.net/nfsroot_jumbo/

i hope you know what's going on :)

best regards,
Mariusz Bialonczyk

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [info] What's in netdev-2.6.git?

[Ben Dooks]

On Mon, Jul 02, 2007 at 11:08:26AM -0400, Jeff Garzik wrote:
> 
> This is what is currently queued for 2.6.23.  There are a few patches
> in my mbox not yet applied to the git tree, but this is most of them.

I sent driver support for the AX88796 a few weeks ago with no feedback,
should I re-send this CC: you?
 
-- 
Ben ([EMAIL PROTECTED], http://www.fluff.org/)

  'a smiley only costs 4 bytes'
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sky2 silicon bugs and workarounds...

[Stephen Hemminger]

On Mon, 2 Jul 2007 14:37:06 +0100
"Daniel J Blueman" <[EMAIL PROTECTED]> wrote:

> Hi Stephen,
> 
> When the sky2 driver initialises, it sets the the ISR timer register
> (STAT_ISR_TIMER_INI) to 125 * 20 = 2500, whereas the vendor sk98lin
> driver sets it to 400, irrespective of the clockspeed of the NIC
> processor.
> 
> I guess you found more performance/stability from this value...?
> 
> I've checked through the errata workarounds common to my rev-1 and 2
> Yukon-EC chips...the HWF_WA_DEV_4167 "oversize receive hang"
> workaround checks and can reset the (as I understand) bus master unit
> of the NIC (in CheckRxPath) in a periodic timer that is fired, where
> is finds no progress is made.

This code in the vendor driver is not acceptable. It causes the device
to continually reset itself in idle state. The sk9lin driver
can not tell the difference between no packets arriving and hung!


-- 
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Cleanup usbnet_probe() return value handling

[David Brownell]

On Monday 02 July 2007, Peter Korsgaard wrote:
> usbnet_probe() handles a positive return value from the driver bind()
> function as success, but will later only setup the status handler if the
> return value was zero, leading to confusion. Patch adjusts this to only
> accept 0 as success in both checks.

I'd rather see the later test updated to match this one.
(Good catch!)

The return convention is "negative means error".  There's
code in USB which has multiple nonnegative success codes.

In particular usb_control_msg(), which would very naturally
used as the body of a bind() method, returns negative or
the number of bytes transferred.

- Dave


> Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
> ---
>  drivers/net/usb/usbnet.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.22-rc7/drivers/net/usb/usbnet.c
> ===
> --- linux-2.6.22-rc7.orig/drivers/net/usb/usbnet.c
> +++ linux-2.6.22-rc7/drivers/net/usb/usbnet.c
> @@ -1182,7 +1182,7 @@
>   // NOTE net->name still not usable ...
>   if (info->bind) {
>   status = info->bind (dev, udev);
> - if (status < 0)
> + if (status != 0)
>   goto out1;
>  
>   // heuristic:  "usb%d" for links we know are two-host,
> 
> -- 
> Bye, Peter Korsgaard
> 


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Jeff Garzik]

Andrew Morton wrote:

On Mon, 02 Jul 2007 11:32:41 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:


Bitfields are to be avoided for many reasons:
* more difficult, in general, for a compiler to generate optimal code
* in particular, known to generate worse code on various architectures
* often causes endian problems
* often enhances programmer confusion, when trying to review structs and 
determine optimal layout and alignment
* programmers have proven they will screw up bitfields in e.g. cases 
with 1-bit and signedness.


I can probably think up more reasons to avoid bitfields if given another 
5 minutes :)


A significant problem is that modifications to "nearby" bitfields need
locking: concurrent modifications to two bitfields can result in concurrent
modifications to the same word.

And that's OK, but it's pretty unobvious that these stores are nonatomic
from the source code and people could easily forget to do it.


Indeed.

Overall, it isn't any one specific thing that makes me reject bitfields 
in new code, it's the sum of all these reasons.


Kernel and compiler history proves that humans and compilers screw up 
bitfields early and often :)


Another reason that I just thought of:  bitfields cannot be 
conglomerated into easy-to-assign-and-test masks, making


foo = (1 << 0),
bar = (1 << 4),
baz = (1 << 9),
default_feature_flags = foo | bar | baz,

foo->flags = default_feature_flags;

impossible with bitfields.

You also cannot test multiple bits at one time, with bitfields.



That being said, they _are_ attractive from the nice-to-read POV...


My personal style disagrees, but that's a personal taste.  I can see how 
other people might think that, though, agreed.


Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sky2 silicon bugs and workarounds...

[Daniel J Blueman]

On 02/07/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:

On Mon, 2 Jul 2007 14:37:06 +0100
"Daniel J Blueman" <[EMAIL PROTECTED]> wrote:
> When the sky2 driver initialises, it sets the the ISR timer register
> (STAT_ISR_TIMER_INI) to 125 * 20 = 2500, whereas the vendor sk98lin
> driver sets it to 400, irrespective of the clockspeed of the NIC
> processor.
>
> I guess you found more performance/stability from this value...?



Not really, it was just a rough guess to try and get more frames
per irq under DoS load.  Haven't fine tuned those values.



> I've checked through the errata workarounds common to my rev-1 and 2
> Yukon-EC chips...the HWF_WA_DEV_4167 "oversize receive hang"
> workaround checks and can reset the (as I understand) bus master unit
> of the NIC (in CheckRxPath) in a periodic timer that is fired, where
> is finds no progress is made.



Where did you get those errata's. I keep having to do reverse
engineering guessing with vendor driver.


http://www.syskonnect.de/e_en/products/adapters/pcie_server/sk-9exx/software/linux/driver/install_v10.0.4.3.tar.bz2
from sk98lin.tar.bz2 inside

---> defined in ./common/h/skgeinit.h

/*-RMV- DWORD 1: Deviations */
#define HWF_WA_DEV_53   0x1100UL/*-RMV- 5.3
(Tx Done LSOv2 rep)*/
#define HWF_WA_DEV_LIM_IPV6_RSS 0x1080UL/*-RMV- IPV6 RSS limitted */
#define HWF_WA_DEV_4217 0x1040UL/*-RMV- 4.217
(PCI-E blockage) */
#define HWF_WA_DEV_4200 0x1020UL/*-RMV- 4.200
(D3 Blue Screen)*/
#define HWF_WA_DEV_4185CS   0x1010UL/*-RMV- 4.185
(ECU 100 CS cal)*/
#define HWF_WA_DEV_4185 0x1008UL/*-RMV- 4.185
(ECU Tx h check)*/
#define HWF_WA_DEV_4167 0x1004UL/*-RMV- 4.167
(Rx OvSize Hang)*/
#define HWF_WA_DEV_4152 0x1002UL/*-RMV- 4.152
(RSS issue) */
#define HWF_WA_DEV_4115 0x1001UL/*-RMV- 4.115
(Rx MAC FIFO) */
#define HWF_WA_DEV_4109 0x10008000UL/*-RMV- 4.109
(BIU hang) */
#define HWF_WA_DEV_483  0x10004000UL/*-RMV- 4.83
(Rx TCP wrong) */
#define HWF_WA_DEV_479  0x10002000UL/*-RMV- 4.79
(Rx BMU hang II) */
#define HWF_WA_DEV_472  0x10001000UL/*-RMV- 4.72
(GPHY2 MDC clk) */
#define HWF_WA_DEV_463  0x1800UL/*-RMV- 4.63
(Rx BMU hang I) */
#define HWF_WA_DEV_427  0x1400UL/*-RMV- 4.27
(Tx Done Rep) */
#define HWF_WA_DEV_42   0x1200UL/*-RMV- 4.2
(pref unit burst) */
#define HWF_WA_DEV_46   0x1100UL/*-RMV- 4.6
(CPU crash II) */
#define HWF_WA_DEV_43_418   0x1080UL/*-RMV- 4.3 &
4.18 (PCI unexp */

/*-RMV- compl&Stat BMU deadl) */
#define HWF_WA_DEV_420  0x1040UL/*-RMV- 4.20
(Status BMU ov) */
#define HWF_WA_DEV_423  0x1020UL/*-RMV- 4.23
(TCP Segm Hang) */
#define HWF_WA_DEV_424  0x1010UL/*-RMV- 4.24
(MAC reg overwr) */
#define HWF_WA_DEV_425  0x1008UL/*-RMV- 4.25
(Magic packet */

/*-RMV- with odd offset) */
#define HWF_WA_DEV_428  0x1004UL/*-RMV- 4.28
(Poll-U &BigEndi)*/
#define HWF_WA_FIFO_FLUSH_YLA0  0x1002UL/*-RMV- dis Rx GMAC FIFO Flush*/

/*-RMV- for Yu-L Rev. A0 only */
#define HWF_WA_COMA_MODE0x1001UL/*-RMV- Coma
Mode WA req */

---> common/skgeinit.c:SkGeSetUpSupFeatures()

   case CHIP_ID_YUKON_EC:
   pAC->GIni.HwF.Features[HW_DEV_LIST] =
   HWF_WA_DEV_42   | HWF_WA_DEV_46   |
HWF_WA_DEV_43_418 |
...
   case CHIP_ID_YUKON_FE:
   pAC->GIni.HwF.Features[HW_DEV_LIST] =
   HWF_WA_DEV_427  | HWF_WA_DEV_4109 |
   HWF_WA_DEV_4152 | HWF_WA_DEV_4167;
   break;
   case CHIP_ID_YUKON_XL:
... etc

It's worthwhile looking at 2.6/skge.c:CheckRxPath() and it's call-site
from the timer handler.

Thanks,
 Daniel
--
Daniel J Blueman
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sky2 silicon bugs and workarounds...

[Stephen Hemminger]

On Mon, 2 Jul 2007 14:37:06 +0100
"Daniel J Blueman" <[EMAIL PROTECTED]> wrote:

> Hi Stephen,
> 
> When the sky2 driver initialises, it sets the the ISR timer register
> (STAT_ISR_TIMER_INI) to 125 * 20 = 2500, whereas the vendor sk98lin
> driver sets it to 400, irrespective of the clockspeed of the NIC
> processor.
> 
> I guess you found more performance/stability from this value...?


Not really, it was just a rough guess to try and get more frames
per irq under DoS load.  Haven't fine tuned those values.

> 
> I've checked through the errata workarounds common to my rev-1 and 2
> Yukon-EC chips...the HWF_WA_DEV_4167 "oversize receive hang"
> workaround checks and can reset the (as I understand) bus master unit
> of the NIC (in CheckRxPath) in a periodic timer that is fired, where
> is finds no progress is made.

Where did you get those errata's. I keep having to do reverse
engineering guessing with vendor driver.

> With the issues we see, can they be detected earlier by the stats
> counters not being incremented, then resetting the bus-master unit,
> rather than the whole chip getting kicked after a far longer period.
> 
> It looks like if it is a silicon bug, we can just acknowledge it and
> have a better framework to detect the chip's PCI interface locking up
> and kick it in a smarter way perhaps...
> 
> Daniel
> --
> Daniel J Blueman


-- 
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Kok, Auke]

Jeff Garzik wrote:

Kok, Auke wrote:
Maybe this is not most important for ixgbe, where we only have 8 or so 
flags, but the new e1000 driver that I posted this weekend currently has 
63 (you wanted flags ;)) of them. Do you want me to use 63 integers or 
just 2 ?


Don't be silly.  We are talking about single-bit feature flags 
implemented using machine ints (a la tg3 with 32 flags per int), versus 
bitfields.


tg3.c:

if ((tp->tg3_flags & TG3_FLAG_PCIX_TARGET_HWBUG) ||
(tp->tg3_flags2 & TG3_FLG2_ICH_WORKAROUND))

is obviously _not_ easier to read than

if (tp->tg3_flags.pcix_target_hwbug || tp->tg3_flags.ich_workaround)

you even have to cascade your flags into a second integer, prone to error and 
confusion!


I would say that this method is definately worse for readability. I would much 
rather then stick with 'bool' instead.



Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Andrew Morton]

On Mon, 02 Jul 2007 11:32:41 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote:

> Bitfields are to be avoided for many reasons:
> * more difficult, in general, for a compiler to generate optimal code
> * in particular, known to generate worse code on various architectures
> * often causes endian problems
> * often enhances programmer confusion, when trying to review structs and 
> determine optimal layout and alignment
> * programmers have proven they will screw up bitfields in e.g. cases 
> with 1-bit and signedness.
> 
> I can probably think up more reasons to avoid bitfields if given another 
> 5 minutes :)

A significant problem is that modifications to "nearby" bitfields need
locking: concurrent modifications to two bitfields can result in concurrent
modifications to the same word.

And that's OK, but it's pretty unobvious that these stores are nonatomic
from the source code and people could easily forget to do it.

That being said, they _are_ attractive from the nice-to-read POV...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Cleanup usbnet_probe() return value handling

[Peter Korsgaard]

usbnet_probe() handles a positive return value from the driver bind()
function as success, but will later only setup the status handler if the
return value was zero, leading to confusion. Patch adjusts this to only
accept 0 as success in both checks.

Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
 drivers/net/usb/usbnet.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.22-rc7/drivers/net/usb/usbnet.c
===
--- linux-2.6.22-rc7.orig/drivers/net/usb/usbnet.c
+++ linux-2.6.22-rc7/drivers/net/usb/usbnet.c
@@ -1182,7 +1182,7 @@
// NOTE net->name still not usable ...
if (info->bind) {
status = info->bind (dev, udev);
-   if (status < 0)
+   if (status != 0)
goto out1;
 
// heuristic:  "usb%d" for links we know are two-host,

-- 
Bye, Peter Korsgaard
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Jeff Garzik]

Kok, Auke wrote:
Maybe this is not most important for ixgbe, where we only have 8 or so 
flags, but the new e1000 driver that I posted this weekend currently has 
63 (you wanted flags ;)) of them. Do you want me to use 63 integers or 
just 2 ?



Don't be silly.  We are talking about single-bit feature flags 
implemented using machine ints (a la tg3 with 32 flags per int), versus 
bitfields.


Bitfields are to be avoided for many reasons:
* more difficult, in general, for a compiler to generate optimal code
* in particular, known to generate worse code on various architectures
* often causes endian problems
* often enhances programmer confusion, when trying to review structs and 
determine optimal layout and alignment
* programmers have proven they will screw up bitfields in e.g. cases 
with 1-bit and signedness.


I can probably think up more reasons to avoid bitfields if given another 
5 minutes :)


Jeff


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Kok, Auke]

Jeff Garzik wrote:

Arjan van de Ven wrote:

Jeff Garzik wrote:
always avoid bitfields.  They generate horrible code, and endian 
problems abound (though no endian problems are apparent here).
they generate no worse code than open coding the checks for these 
feature flags...
That would be the logical assumption, but reality does not bear that 
logic out to be true.


I just checked a small example and gcc just generates a testb with an 
immediate value, which isn't all that bad code.


Do you remember which gcc you tested with?


gcc 2.95, gcc 3.x, gcc 4.x, ...  on multiple architectures, not just ia32.

It's simple logic:  using machine integers are the easiest for the 
compiler to Do The Right Thing, the easiest way to eliminate endian 
problems, the easiest way for programmers to read and understand struct 
alignment.


I really disagree with you here, I much rather prefer using code style like:

  if (adapter->flags.msi_enabled) ..

than

  if (adapter->flags & E1000_FLAG_MSI_ENABLED) ...

not only does it read easier, it's also shorter and not prone to &/&& confusion 
typo's, takes away parentheses when the test has multiple parts etc...


Maybe this is not most important for ixgbe, where we only have 8 or so flags, 
but the new e1000 driver that I posted this weekend currently has 63 (you wanted 
flags ;)) of them. Do you want me to use 63 integers or just 2 ?


And as Arjan said, we're not passing any of these to hardware, so there should 
not be any endian issues.


I think acme would agree with me that pahole currently is the easiest way to 
show struct alignment ...



Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[info] What's in netdev-2.6.git?

[Jeff Garzik]

This is what is currently queued for 2.6.23.  There are a few patches
in my mbox not yet applied to the git tree, but this is most of them.

The following is found in the 'upstream' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

Akinobu Mita (1):
  softmac: use list_for_each_entry

Bill Nottingham (1):
  drivers/net: fix comparisons of unsigned < 0

Daniel Drake (4):
  zd1211rw: Add ID for ZyXEL G-200v2
  zd1211rw: Extend RF layer
  zd1211rw: Add UW2453 RF support
  zd1211rw: Make CCK gain patching conditional on RF type

David Brownell (1):
  usbnet whitespace fixes

David S. Miller (1):
  r8169: kill eth_copy_and_sum()

Divy Le Ray (3):
  cxgb3 - sge page management
  cxgb3 - Firmware update
  cxgb3 - TP SRAM update

Francois Romieu (17):
  r8169: de-obfuscate modulo arithmetic
  r8169: add hooks for per-device hw_start handler
  r8169: add helpers for per-device hw_start handler
  r8169: populate the hw_start handler for the 8168
  r8169: populate the hw_start handler for the 8110
  r8169: prettify mac_version
  r8169: merge with version 6.001.00 of Realtek's r8169 driver
  r8169: merge with version 8.001.00 of Realtek's r8168 driver
  r8169: confusion between hardware and IP header alignment
  r8169: small 8101 comment
  r8169: remove the media option
  r8169: cleanup
  r8169: add bit description for the TxPoll register
  r8169: align the IP header when there is no DMA constraint
  r8169: display some extra debug information during startup
  r8169: mac address change support
  r8169: perform RX config change after mac filtering

Geert Uytterhoeven (1):
  acenic: SET_NETDEV_DEV is always there these days

Ivo van Doorn (2):
  Add 93cx6 eeprom library
  eeprom_93cx6: Add comment for 1us delay after pulse

Jan Engelhardt (1):
  Use menuconfig objects II - netdev (general+100mbit)

Jan-Bernd Themann (1):
  ehea: Whitespace cleanup

Jeff Garzik (2):
  Merge branch 'upstream-fixes' into upstream
  Merge branch 'upstream-fixes' into upstream

John W. Linville (2):
  eeprom_93cx6: shorten pulse timing to match spec
  rtl8187: add header blocks and indicate origin of magic values

Jouni Malinen (1):
  hostap: Remove driver version number

Kapil Juneja (2):
  gianfar: add support for SGMII
  phylib: m88e: enable SGMII mode

Komuro (1):
  PCMCIA-NETDEV : add new ID of lan&modem multifunction card

Larry Finger (1):
  bcm43xx: Fix deviation from specifications in set_baseband_attenuation

Linas Vepstas (10):
  s2io: add PCI error recovery support
  s2io: add PCI error recovery support
  spidernet: beautify error messages
  spidernet: enhance the dump routine
  spidernet: invalidate unused pointer.
  spidernet: service TX later.
  spidernet: move a block of code around
  spidernet: fix misnamed flag
  spidernet: driver docmentation
  spidernet: Replace literal with const

Matthias Kaehlcke (1):
  hostap: Use list_for_each_entry

Michael Barkowski (1):
  phylib: add the ICPlus IP175C PHY driver

Michael Wu (1):
  Add rtl8187 wireless driver

Olof Johansson (1):
  pasemi_mac: Fix TX interrupt threshold

Pavel Roskin (1):
  hostap: Suppress broadcast if no stations are associated

Richard Knutsson (2):
  8139cp: Convert to generic boolean
  tulip: Convert to generic boolean

Rolf Eike Beer (1):
  r8169: add endianess annotations to [RT]xDesc

Stephen Hemminger (14):
  b44: timer power saving
  b44: tx bounce sizing.
  b44: packet offset is constant
  b44: use netdev_alloc_skb
  qla3xxx: cleanup checksum offload code
  sky2: avoid reserved regions on ethtool reg dump
  sky2: Add PCI device specfic register 4 & 5
  sky2: rename BMU register
  sky2: enable clocks before probe
  sky2: GPIO register
  sky2: Yukon Extreme (88e8071) support.
  sky2: version 1.15
  r8169: use netdev_alloc_skb
  r8169: Rx path update

Thomas Bogendoerfer (2):
  Extract chip specific code out of lasi_82596.c
  Ethernet driver for EISA only SNI RM200/RM400 machines

Yoichi Yuasa (1):
  add return value check of request_irq()

 Documentation/networking/spider_net.txt |  204 +++
 MAINTAINERS |   10 
 drivers/misc/Kconfig|5 
 drivers/misc/Makefile   |1 
 drivers/misc/eeprom_93cx6.c |  241 +++
 drivers/net/8139cp.c|   11 
 drivers/net/Kconfig |  172 +-
 drivers/net/Makefile|1 
 drivers/net/acenic.c|4 
 drivers/net/arm/Kconfig |   12 
 drivers/net/b44.c   |   56 
 drivers/net/b44.h   |2 
 

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Johannes Berg]

On Mon, 2007-07-02 at 16:38 +0200, Patrick McHardy wrote:

> > Do I understand you correctly in that you prefer the way I did it now?
> 
> 
> Yes.

Alright, then I'll rework the event generation to not include the whole
family info and repost with that tomorrow or so. If I find time I might
actually fix the unregistration bug too, but I have a feeling digging in
the socket code might take more time than I have right now.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Arjan van de Ven]

Jeff Garzik wrote:
It's simple logic:  using machine integers are the easiest for the 
compiler to Do The Right Thing, the easiest way to eliminate endian 
problems, the easiest way for programmers to read and understand struct 
alignment.


using integers pure is obviously natural..
but using integers and then manually doing bit masking yourself... 
that's not fundamentally better than what the compiler can do.


yes bitfields are hard for not-1-bit cases and for cases where you 
mimick hardware layouts. neither is the case in this code.
The code gets actually harder to read for the feature flags if you 
don't use bitfields  so unless the code is really worse (and so 
far I've not seen that, but I'll investigate more when I get to work), 
I think it's fair to use single-bit, non-packed bitfields for them...

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Jeff Garzik]

Arjan van de Ven wrote:

Jeff Garzik wrote:
always avoid bitfields.  They generate horrible code, and endian 
problems abound (though no endian problems are apparent here).


they generate no worse code than open coding the checks for these 
feature flags...


That would be the logical assumption, but reality does not bear that 
logic out to be true.




I just checked a small example and gcc just generates a testb with an 
immediate value, which isn't all that bad code.


Do you remember which gcc you tested with?


gcc 2.95, gcc 3.x, gcc 4.x, ...  on multiple architectures, not just ia32.

It's simple logic:  using machine integers are the easiest for the 
compiler to Do The Right Thing, the easiest way to eliminate endian 
problems, the easiest way for programmers to read and understand struct 
alignment.


Just say no to bitfields.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Patrick McHardy]

Johannes Berg wrote:
> On Mon, 2007-07-02 at 14:56 +0200, Patrick McHardy wrote:
> 
>>The main reason to use nested attributes is when you only have a
>>single attribute to store your data in (for example TCA_OPTIONS
>>for qdiscs). In that case a nested attribute should be used to
>>allow to extend it in the future. Below that nested attribute
>>you could put a struct of course.
> 
> 
> Right, but that's not applicable to this unless I'm misunderstanding
> you.


Not really, it already uses a nested top-level attribute.

>>In this case I think using a string attribute instead of a fixed
>>sized structure also makes sense for a different reason. Its
>>unlikely that groups will really use the maximum name length
>>allowed, so it should save some bandwidth.
> 
> 
> I suppose if I put (ID,name) into the struct it needn't be fixed-size
> length, but I dislike that as well.


Me too.

> Do I understand you correctly in that you prefer the way I did it now?


Yes.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Johannes Berg]

On Mon, 2007-07-02 at 14:56 +0200, Patrick McHardy wrote:

> For information that belongs together logically a struct is fine.

Ok.

> The main reason to use nested attributes is when you only have a
> single attribute to store your data in (for example TCA_OPTIONS
> for qdiscs). In that case a nested attribute should be used to
> allow to extend it in the future. Below that nested attribute
> you could put a struct of course.

Right, but that's not applicable to this unless I'm misunderstanding
you.

> In this case I think using a string attribute instead of a fixed
> sized structure also makes sense for a different reason. Its
> unlikely that groups will really use the maximum name length
> allowed, so it should save some bandwidth.

I suppose if I put (ID,name) into the struct it needn't be fixed-size
length, but I dislike that as well. Do I understand you correctly in
that you prefer the way I did it now?

johannes


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Arjan van de Ven]

Jeff Garzik wrote:
I'm not sure whether gcc is confused about ABI alignment or such, on 
various platforms, but every time I look at the asm generated it is 
/not/ equivalent to open-coded feature flags and bitwise logic.  Often 
it is demonstrably worse.


(I can imagine this being different if you forcefully pack your 
structure to align with hw masks, but that is obviously not the case here)

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Arjan van de Ven]

Jeff Garzik wrote:
always avoid bitfields.  They generate horrible code, and endian 
problems abound (though no endian problems are apparent here).


they generate no worse code than open coding the checks for these 
feature flags...


That would be the logical assumption, but reality does not bear that 
logic out to be true.




I just checked a small example and gcc just generates a testb with an 
immediate value, which isn't all that bad code.


Do you remember which gcc you tested with?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Jeff Garzik]

Arjan van de Ven wrote:

 >> +u32 alloc_rx_buff_failed;

+struct {
+unsigned int rx_csum_enabled:1;
+unsigned int msi_capable:1;
+unsigned int msi_enabled:1;
+unsigned int msix_capable:1;
+unsigned int msix_enabled:1;
+unsigned int imir_enabled:1;
+unsigned int in_netpoll:1;
+} flags;


always avoid bitfields.  They generate horrible code, and endian 
problems abound (though no endian problems are apparent here).


they generate no worse code than open coding the checks for these 
feature flags...


That would be the logical assumption, but reality does not bear that 
logic out to be true.


I'm not sure whether gcc is confused about ABI alignment or such, on 
various platforms, but every time I look at the asm generated it is 
/not/ equivalent to open-coded feature flags and bitwise logic.  Often 
it is demonstrably worse.


The same is true for icc too :)  Bitfields are just bad juju for 
compilers, I guess.


Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.22-rc6: local_bh_enable warning

[Jeff Garzik]

Patrick McHardy wrote:

Russell King wrote:

Having upgraded from 2.6.16 to 2.6.22-rc6, I'm now seeing the following.

Looks like netfilter is calling local_bh_enable() with IRQs disabled,
which would appear to be illegal.  Thankfully, this is a warn-once
warning.

WARNING: at /home/rmk/git/linux-2.6-rmk/kernel/softirq.c:138 local_bh_enable()
[...]
[] (nf_conntrack_destroy+0x0/0x2c) from [] 
(__kfree_skb+0xd0/0x100)
[] (__kfree_skb+0x0/0x100) from [] (kfree_skb+0x4c/0x50)
 r5:c12a3800 r4:0300
[] (kfree_skb+0x0/0x50) from [] (el3_start_xmit+0xb8/0xd0 
[3c589_cs])
[] (el3_start_xmit+0x0/0xd0 [3c589_cs]) from [] 
(dev_hard_start_xmit+0x1a8/0x244)
 r7:c12a3800 r6:c1a9aa00 r5:c1a9aa00 r4:c12a3800
[] (dev_hard_start_xmit+0x0/0x244) from [] 
(__qdisc_run+0xb0/0x198)



Thats a bug in the 3c589_cs driver. Patch attached.

Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>


You would post this JUST after I finished my patch applying run, 
wouldn't you?  :)


Will apply in a few minutes, thanks :)

Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)

[Krzysztof Halasa]

[EMAIL PROTECTED] writes:

> To use a NFS-root for UDP jumbo frames the kernel on the client need to bring
> up interface with MTU set to 9000 bytes - otherwise it cannot contact server
> with jumbo frames enabled (nfs server not responding, still trying) and
> cannot
> boot. Added a kernel parameter named 'ipmtu' which can be used to specify
> initial MTU size when booting via nfsroot.

Isn't the whole IP autoconfig and NFS root set to die?
Why not do it in initramfs?
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.22-rc6: local_bh_enable warning

[Patrick McHardy]

Russell King wrote:
> Having upgraded from 2.6.16 to 2.6.22-rc6, I'm now seeing the following.
> 
> Looks like netfilter is calling local_bh_enable() with IRQs disabled,
> which would appear to be illegal.  Thankfully, this is a warn-once
> warning.
> 
> WARNING: at /home/rmk/git/linux-2.6-rmk/kernel/softirq.c:138 local_bh_enable()
> [...]
> [] (nf_conntrack_destroy+0x0/0x2c) from [] 
> (__kfree_skb+0xd0/0x100)
> [] (__kfree_skb+0x0/0x100) from [] (kfree_skb+0x4c/0x50)
>  r5:c12a3800 r4:0300
> [] (kfree_skb+0x0/0x50) from [] (el3_start_xmit+0xb8/0xd0 
> [3c589_cs])
> [] (el3_start_xmit+0x0/0xd0 [3c589_cs]) from [] 
> (dev_hard_start_xmit+0x1a8/0x244)
>  r7:c12a3800 r6:c1a9aa00 r5:c1a9aa00 r4:c12a3800
> [] (dev_hard_start_xmit+0x0/0x244) from [] 
> (__qdisc_run+0xb0/0x198)


Thats a bug in the 3c589_cs driver. Patch attached.

Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
diff --git a/drivers/net/pcmcia/3c589_cs.c b/drivers/net/pcmcia/3c589_cs.c
index 143ae2f..503f268 100644
--- a/drivers/net/pcmcia/3c589_cs.c
+++ b/drivers/net/pcmcia/3c589_cs.c
@@ -629,9 +629,9 @@ static int el3_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
outw(SetTxThreshold + 1536, ioaddr + EL3_CMD);
 }
 
-dev_kfree_skb(skb);
 pop_tx_status(dev);
 spin_unlock_irqrestore(&priv->lock, flags);
+dev_kfree_skb(skb);
 
 return 0;
 }

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Arjan van de Ven]

>> +u32 alloc_rx_buff_failed;

+struct {
+unsigned int rx_csum_enabled:1;
+unsigned int msi_capable:1;
+unsigned int msi_enabled:1;
+unsigned int msix_capable:1;
+unsigned int msix_enabled:1;
+unsigned int imir_enabled:1;
+unsigned int in_netpoll:1;
+} flags;


always avoid bitfields.  They generate horrible code, and endian 
problems abound (though no endian problems are apparent here).


they generate no worse code than open coding the checks for these 
feature flags...

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.22-rc7] 8139cp: dev->tx_timeout

[Mika . Lansirinne]

(Resending the patch against 2.6.22-rc7)

This patch implements the missing dev->tx_timeout for 8139cp driver

Signed-off-by: Mika Lansirinne <[EMAIL PROTECTED]>

---

diff -uprN linux-2.6.22-rc7/drivers/net/8139cp.c 
linux-2.6.22-rc7_8139cp-tx_timeout/drivers/net/8139cp.c
--- linux-2.6.22-rc7/drivers/net/8139cp.c 2007-07-01 22:54:24.0 +0300
+++ linux-2.6.22-rc7_8139cp-tx_timeout/drivers/net/8139cp.c 2007-07-02 
16:00:38.0 +0300
@@ -26,7 +26,6 @@

  TODO:
  * Test Tx checksumming thoroughly
- * Implement dev->tx_timeout

  Low priority TODO:
  * Complete reset on PciErr
@@ -1223,6 +1222,30 @@ static int cp_close (struct net_device *
  return 0;
 }

+static void cp_tx_timeout(struct net_device *dev)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ int rc;
+ unsigned long flags;
+
+printk (KERN_WARNING "%s: Transmit timeout, status %2x %4x %4x %4x\n",
+dev->name, cpr8(Cmd), cpr16(CpCmd),
+cpr16(IntrStatus), cpr16(IntrMask));
+
+ spin_lock_irqsave(&cp->lock, flags);
+
+ cp_stop_hw(cp);
+ cp_clean_rings(cp);
+ rc = cp_init_rings(cp);
+ cp_start_hw(cp);
+
+ netif_wake_queue(dev);
+
+ spin_unlock_irqrestore(&cp->lock, flags);
+
+ return;
+}
+
 #ifdef BROKEN
 static int cp_change_mtu(struct net_device *dev, int new_mtu)
 {
@@ -1928,10 +1951,8 @@ static int cp_init_one (struct pci_dev *
  dev->change_mtu = cp_change_mtu;
 #endif
  dev->ethtool_ops = &cp_ethtool_ops;
-#if 0
  dev->tx_timeout = cp_tx_timeout;
  dev->watchdog_timeo = TX_TIMEOUT;
-#endif

 #if CP_VLAN_TAG_USED
  dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH UPDATE #2] Extract chip specific code out of lasi_82596.c

[Jeff Garzik]

Thomas Bogendoerfer wrote:

On Mon, Jul 02, 2007 at 08:43:04AM -0400, Jeff Garzik wrote:

applied both patches.

Please provide an update that does at Andrew requested -- rather than 
#include'ing lib82596.c, you should update the Makefile for relevant 
drivers to look like



I got the impression that Andrew is fine with that approach after my
explanation. I would need additional header files for all the
different swap macros/dma stuff, and that isn't nice either, isn't it ? 


Fair enough.



There are other drivers doing the same as I do, which didn't get any
objections. Is it me you have a prolem with ?


Put down the insanity and paranoia juice.  Slowly.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] dgrs romove Kconfig option

[maximilian attems]

nobody objected to adrian's rfc dropping dgrs on netdev back in dec. 2006.
-> http://marc.info/?l=linux-netdev&m=116507999803538&w=2
as bonus points this will get rid of a prorpietary licensed firmware.

so now be a bit more serious and remove the Kconfig entries
and see if anyone shouts. if no voice is to be heard as
expected by zero bug entries on kernel.org or debian.org,
the full removal is scheduled for 2.6.24.

Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
Acked-by: Alan <[EMAIL PROTECTED]>


diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index 7d3f205..306276e 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -348,3 +348,10 @@ Who:  Tejun Heo <[EMAIL PROTECTED]>
 
 ---
 
+What: drivers/net/dgrs.c
+When: option 2.6.23, code 2.6.24
+Why: no users, product never reached market
+Who: maximilian attems <[EMAIL PROTECTED]>
+
+---
+
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 7d57f4a..78a6a78 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1447,21 +1447,6 @@ config TC35815
depends on NET_PCI && PCI && MIPS
select MII
 
-config DGRS
-   tristate "Digi Intl. RightSwitch SE-X support"
-   depends on NET_PCI && (PCI || EISA)
-   ---help---
- This is support for the Digi International RightSwitch series of
- PCI/EISA Ethernet switch cards. These include the SE-4 and the SE-6
- models.  If you have a network card of this type, say Y and read the
- Ethernet-HOWTO, available from
- .  More specific
- information is contained in .
-
- To compile this driver as a module, choose M here and read
- .  The module
- will be called dgrs.
-
 config EEPRO100
tristate "EtherExpressPro/100 support (eepro100, original Becker 
driver)"
depends on NET_PCI && PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index a77affa..209a079 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -38,7 +38,6 @@ obj-$(CONFIG_CASSINI) += cassini.o
 obj-$(CONFIG_MACE) += mace.o
 obj-$(CONFIG_BMAC) += bmac.o
 
-obj-$(CONFIG_DGRS) += dgrs.o
 obj-$(CONFIG_VORTEX) += 3c59x.o
 obj-$(CONFIG_TYPHOON) += typhoon.o
 obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH UPDATE #2] Extract chip specific code out of lasi_82596.c

[Thomas Bogendoerfer]

On Mon, Jul 02, 2007 at 08:43:04AM -0400, Jeff Garzik wrote:
> applied both patches.
> 
> Please provide an update that does at Andrew requested -- rather than 
> #include'ing lib82596.c, you should update the Makefile for relevant 
> drivers to look like

I got the impression that Andrew is fine with that approach after my
explanation. I would need additional header files for all the
different swap macros/dma stuff, and that isn't nice either, isn't it ? 

There are other drivers doing the same as I do, which didn't get any
objections. Is it me you have a prolem with ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.[ RFC1925, 2.3 ]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

sky2 silicon bugs and workarounds...

[Daniel J Blueman]

Hi Stephen,

When the sky2 driver initialises, it sets the the ISR timer register
(STAT_ISR_TIMER_INI) to 125 * 20 = 2500, whereas the vendor sk98lin
driver sets it to 400, irrespective of the clockspeed of the NIC
processor.

I guess you found more performance/stability from this value...?

I've checked through the errata workarounds common to my rev-1 and 2
Yukon-EC chips...the HWF_WA_DEV_4167 "oversize receive hang"
workaround checks and can reset the (as I understand) bus master unit
of the NIC (in CheckRxPath) in a periodic timer that is fired, where
is finds no progress is made.

With the issues we see, can they be detected earlier by the stats
counters not being incremented, then resetting the bus-master unit,
rather than the whole chip getting kicked after a far longer period.

It looks like if it is a silicon bug, we can just acknowledge it and
have a better framework to detect the chip's PCI interface locking up
and kick it in a smarter way perhaps...

Daniel
--
Daniel J Blueman
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)

[Peter Staubach]

[EMAIL PROTECTED] wrote:

To use a NFS-root for UDP jumbo frames the kernel on the client need to bring
up interface with MTU set to 9000 bytes - otherwise it cannot contact server
with jumbo frames enabled (nfs server not responding, still trying) and cannot
boot. Added a kernel parameter named 'ipmtu' which can be used to specify
initial MTU size when booting via nfsroot.

  


Could you describe the problem better, please?  Something does not
sound right.  Both ends need to have jumbo frames enabled in order
to use jumbo frames, but if one end or the other does not, the systems
still should be able to exchange packets using normal sized ethernet
packets.  Isn't this a problem that mtu discovery should handle?

   Thanx...

  ps


Signed-off-by: Mariusz Bialonczyk <[EMAIL PROTECTED]>

diff -Nru linux-2.6.21.1-orig/Documentation/kernel-parameters.txt 
linux-2.6.21.1/Documentation/kernel-parameters.txt
--- linux-2.6.21.1-orig/Documentation/kernel-parameters.txt 2007-04-27 
23:49:26.0 +0200
+++ linux-2.6.21.1/Documentation/kernel-parameters.txt  2007-07-01 
18:47:11.0 +0200
@@ -720,6 +720,9 @@
ip2=[HW] Set IO/IRQ pairs for up to 4 IntelliPort boards
See comment before ip2_setup() in drivers/char/ip2.c.
 
+	ipmtu=		[IP_PNP]

+   See Documentation/nfsroot.txt.
+
ips=[HW,SCSI] Adaptec / IBM ServeRAID controller
See header of drivers/scsi/ips.c.
 
diff -Nru linux-2.6.21.1-orig/Documentation/nfsroot.txt linux-2.6.21.1/Documentation/nfsroot.txt

--- linux-2.6.21.1-orig/Documentation/nfsroot.txt   2007-04-27 
23:49:26.0 +0200
+++ linux-2.6.21.1/Documentation/nfsroot.txt2007-07-01 19:02:40.0 
+0200
@@ -153,6 +153,16 @@
 Default: any
 
 
+ipmtu=

+
+  This parameter tells the kernel to override default MTU size to specified
+  . Useful in cases where NFS server have jumbo frames enabled and
+  client can't connect via UDP because of default MTU value (in ethernet
+  usually 1500 bytes). With this option before bringing interface up, kernel
+  will set the passed MTU size. In case of NFS-root booting server and client
+  can use UDP jumbo frames (NFS's rsize and wsize set to 8192 for instance).
+
+
 
 
 3.) Boot Loader

diff -Nru linux-2.6.21.1-orig/net/ipv4/ipconfig.c 
linux-2.6.21.1/net/ipv4/ipconfig.c
--- linux-2.6.21.1-orig/net/ipv4/ipconfig.c 2007-04-27 23:49:26.0 
+0200
+++ linux-2.6.21.1/net/ipv4/ipconfig.c  2007-07-01 15:44:44.0 +0200
@@ -113,6 +113,8 @@
  */
 int ic_set_manually __initdata = 0;/* IPconfig parameters set 
manually */
 
+unsigned int ic_mtu __initdata = 0;		/* IPconfig MTU parameter: 0 - defaults, other - override */

+
 static int ic_enable __initdata = 0;   /* IP config enabled? */
 
 /* Protocol choice */

@@ -209,6 +211,11 @@
able &= ic_proto_enabled;
if (ic_proto_enabled && !able)
continue;
+   if (ic_mtu > 0)
+   {
+   printk(KERN_ERR "IP-Config: Overriding %s MTU to %d 
bytes\n", dev->name, ic_mtu);
+   dev->mtu = ic_mtu;
+   }
oflags = dev->flags;
if (dev_change_flags(dev, oflags | IFF_UP) < 0) {
printk(KERN_ERR "IP-Config: Failed to open %s\n", 
dev->name);
@@ -1506,5 +1513,14 @@
return ip_auto_config_setup(addrs);
 }
 
+static int __init mtu_config_setup(char *str)

+{
+   if (!str)
+   return 0;
+   ic_mtu = simple_strtoul(str, &str, 0);
+   return 1;
+}
+
 __setup("ip=", ip_auto_config_setup);
+__setup("ipmtu=", mtu_config_setup);
 __setup("nfsaddrs=", nfsaddrs_config_setup);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)

[manio]

To use a NFS-root for UDP jumbo frames the kernel on the client need to bring
up interface with MTU set to 9000 bytes - otherwise it cannot contact server
with jumbo frames enabled (nfs server not responding, still trying) and cannot
boot. Added a kernel parameter named 'ipmtu' which can be used to specify
initial MTU size when booting via nfsroot.

Signed-off-by: Mariusz Bialonczyk <[EMAIL PROTECTED]>

diff -Nru linux-2.6.21.1-orig/Documentation/kernel-parameters.txt 
linux-2.6.21.1/Documentation/kernel-parameters.txt
--- linux-2.6.21.1-orig/Documentation/kernel-parameters.txt 2007-04-27 
23:49:26.0 +0200
+++ linux-2.6.21.1/Documentation/kernel-parameters.txt  2007-07-01 
18:47:11.0 +0200
@@ -720,6 +720,9 @@
ip2=[HW] Set IO/IRQ pairs for up to 4 IntelliPort boards
See comment before ip2_setup() in drivers/char/ip2.c.
 
+   ipmtu=  [IP_PNP]
+   See Documentation/nfsroot.txt.
+
ips=[HW,SCSI] Adaptec / IBM ServeRAID controller
See header of drivers/scsi/ips.c.
 
diff -Nru linux-2.6.21.1-orig/Documentation/nfsroot.txt 
linux-2.6.21.1/Documentation/nfsroot.txt
--- linux-2.6.21.1-orig/Documentation/nfsroot.txt   2007-04-27 
23:49:26.0 +0200
+++ linux-2.6.21.1/Documentation/nfsroot.txt2007-07-01 19:02:40.0 
+0200
@@ -153,6 +153,16 @@
 Default: any
 
 
+ipmtu=
+
+  This parameter tells the kernel to override default MTU size to specified
+  . Useful in cases where NFS server have jumbo frames enabled and
+  client can't connect via UDP because of default MTU value (in ethernet
+  usually 1500 bytes). With this option before bringing interface up, kernel
+  will set the passed MTU size. In case of NFS-root booting server and client
+  can use UDP jumbo frames (NFS's rsize and wsize set to 8192 for instance).
+
+
 
 
 3.) Boot Loader
diff -Nru linux-2.6.21.1-orig/net/ipv4/ipconfig.c 
linux-2.6.21.1/net/ipv4/ipconfig.c
--- linux-2.6.21.1-orig/net/ipv4/ipconfig.c 2007-04-27 23:49:26.0 
+0200
+++ linux-2.6.21.1/net/ipv4/ipconfig.c  2007-07-01 15:44:44.0 +0200
@@ -113,6 +113,8 @@
  */
 int ic_set_manually __initdata = 0;/* IPconfig parameters set 
manually */
 
+unsigned int ic_mtu __initdata = 0;/* IPconfig MTU parameter: 0 - 
defaults, other - override */
+
 static int ic_enable __initdata = 0;   /* IP config enabled? */
 
 /* Protocol choice */
@@ -209,6 +211,11 @@
able &= ic_proto_enabled;
if (ic_proto_enabled && !able)
continue;
+   if (ic_mtu > 0)
+   {
+   printk(KERN_ERR "IP-Config: Overriding %s MTU 
to %d bytes\n", dev->name, ic_mtu);
+   dev->mtu = ic_mtu;
+   }
oflags = dev->flags;
if (dev_change_flags(dev, oflags | IFF_UP) < 0) {
printk(KERN_ERR "IP-Config: Failed to open 
%s\n", dev->name);
@@ -1506,5 +1513,14 @@
return ip_auto_config_setup(addrs);
 }
 
+static int __init mtu_config_setup(char *str)
+{
+   if (!str)
+   return 0;
+   ic_mtu = simple_strtoul(str, &str, 0);
+   return 1;
+}
+
 __setup("ip=", ip_auto_config_setup);
+__setup("ipmtu=", mtu_config_setup);
 __setup("nfsaddrs=", nfsaddrs_config_setup);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...

[Jeff Garzik]

Ayyappan Veeraiyan wrote:

+#define IXGBE_TX_FLAGS_CSUM0x0001
+#define IXGBE_TX_FLAGS_VLAN0x0002
+#define IXGBE_TX_FLAGS_TSO 0x0004
+#define IXGBE_TX_FLAGS_IPV40x0008
+#define IXGBE_TX_FLAGS_VLAN_MASK   0x
+#define IXGBE_TX_FLAGS_VLAN_SHIFT  16


defining bits using the form "(1 << n)" is preferred.  Makes it easier 
to read, by eliminating the requirement of the human brain to decode hex 
into bit numbers.




+   union {
+   /* To protect race between sender and clean_tx_irq */
+   spinlock_t tx_lock;
+   struct net_device netdev;
+   };


Embedded a struct net_device into your ring?  How can I put this?

Wrong, wrong.  Wrong, wrong, wrong.  Wrong.




+   struct ixgbe_queue_stats stats;
+
+   u32 eims_value;
+   u32 itr_val;
+   u16 itr_range;
+   u16 itr_register;
+
+   char name[IFNAMSIZ + 5];


The interface name should not be stored by your ring structure




+#define IXGBE_DESC_UNUSED(R) \
+   R)->next_to_clean > (R)->next_to_use) ? 0 : (R)->count) + \
+   (R)->next_to_clean - (R)->next_to_use - 1)
+
+#define IXGBE_RX_DESC_ADV(R, i)\
+   (&(((union ixgbe_adv_rx_desc *)((R).desc))[i]))
+#define IXGBE_TX_DESC_ADV(R, i)\
+   (&(((union ixgbe_adv_tx_desc *)((R).desc))[i]))
+#define IXGBE_TX_CTXTDESC_ADV(R, i)\
+   (&(((struct ixgbe_adv_tx_context_desc *)((R).desc))[i]))
+
+#define IXGBE_MAX_JUMBO_FRAME_SIZE 16128
+
+/* board specific private data structure */
+struct ixgbe_adapter {
+   struct timer_list watchdog_timer;
+   struct vlan_group *vlgrp;
+   u16 bd_number;
+   u16 rx_buf_len;
+   u32 part_num;
+   u32 link_speed;
+   unsigned long io_base;


Kill io_base and stop setting netdev->base_addr



+   atomic_t irq_sem;
+   struct work_struct reset_task;
+
+   /* TX */
+   struct ixgbe_ring *tx_ring; /* One per active queue */
+   u64 restart_queue;
+   u64 lsc_int;
+   u32 txd_cmd;
+   u64 hw_tso_ctxt;
+   u64 hw_tso6_ctxt;
+   u32 tx_timeout_count;
+   boolean_t detect_tx_hung;
+
+   /* RX */
+   struct ixgbe_ring *rx_ring; /* One per active queue */
+   u64 hw_csum_tx_good;
+   u64 hw_csum_rx_error;
+   u64 hw_csum_rx_good;
+   u64 non_eop_descs;
+   int num_tx_queues;
+   int num_rx_queues;
+   struct msix_entry *msix_entries;
+
+   u64 rx_hdr_split;
+   u32 alloc_rx_page_failed;
+   u32 alloc_rx_buff_failed;
+   struct {
+   unsigned int rx_csum_enabled:1;
+   unsigned int msi_capable:1;
+   unsigned int msi_enabled:1;
+   unsigned int msix_capable   :1;
+   unsigned int msix_enabled   :1;
+   unsigned int imir_enabled   :1;
+   unsigned int in_netpoll :1;
+   } flags;


always avoid bitfields.  They generate horrible code, and endian 
problems abound (though no endian problems are apparent here).




+   u32 max_frame_size; /* Maximum frame size supported */
+   u32 eitr;   /* Interrupt Throttle Rate */
+
+   /* OS defined structs */
+   struct net_device *netdev;
+   struct pci_dev *pdev;
+   struct net_device_stats net_stats;
+
+   /* structs defined in ixgbe_hw.h */
+   struct ixgbe_hw hw;
+   u16 msg_enable;
+   struct ixgbe_hw_stats stats;
+   char lsc_name[IFNAMSIZ + 5];


delete lsc_name and use netdev name directly in request_irq()



Will review more after you fix these problems.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

[Patrick McHardy]

Johannes Berg wrote:
> On Sat, 2007-06-30 at 11:32 -0400, jamal wrote:
> 
> 
>>>+NLA_PUT_U32(skb, CTRL_ATTR_MCAST_GRP_ID, grp->id);
>>>+NLA_PUT_STRING(skb, CTRL_ATTR_MCAST_GRP_NAME,
>>>+   grp->name);
>>>+
>>
>>Consider my earlier suggestion to use CTRL_ATTR_MCAST_GRP which has both
>>id and name in one struct.
> 
> 
> Yeah I thought about that but then saw Patrick's patches to convert
> other things away from structs so I wasn't sure what the idea here is.
> Patrick, care to comment?


For information that belongs together logically a struct is fine.
The main reason to use nested attributes is when you only have a
single attribute to store your data in (for example TCA_OPTIONS
for qdiscs). In that case a nested attribute should be used to
allow to extend it in the future. Below that nested attribute
you could put a struct of course.

In this case I think using a string attribute instead of a fixed
sized structure also makes sense for a different reason. Its
unlikely that groups will really use the maximum name length
allowed, so it should save some bandwidth.


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH UPDATE #2] Extract chip specific code out of lasi_82596.c

[Jeff Garzik]

applied both patches.

Please provide an update that does at Andrew requested -- rather than 
#include'ing lib82596.c, you should update the Makefile for relevant 
drivers to look like


obj-$(CONFIG_FOO_BAR) += lib82596.o foo_bar_82596.o

and make sure it exports everything to make lib82596 a full fledged module.


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.21.5] 8139cp: dev->tx_timeout

[Jeff Garzik]

[EMAIL PROTECTED] wrote:

This patch implements the missing dev->tx_timeout for 8139cp driver

Signed-off-by: Mika Lansirinne <[EMAIL PROTECTED]>


does not seem to apply to current kernel.  please resend against 
netdev-2.6.git#upstream or 2.6.22-rc7.



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RESENT] ehea: Whitespace cleanup

[Jeff Garzik]

Jan-Bernd Themann wrote:

This patch fixes several whitespace issues.

Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>


applied


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] pasemi_mac: Fix TX interrupt threshold

[Jeff Garzik]

Olof Johansson wrote:

It was mistakenly set to interrupt on the second packet instead of first, 
causing
some interesting latency behaviour.


Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>


applied


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spidernet: Replace literal with const

[Jeff Garzik]

Linas Vepstas wrote:

Replace literal with const; add bit definitions.

Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>



On Wed, Jun 13, 2007 at 04:12:00PM -0400, Jeff Garzik wrote:
A follow-up patch needs to remove the above magic numbers (==numeric 
constants), replacing them with named constants


Here it is. Lightly stres-tested (about 1/2 hour), as this patch
tests some additonal bits.

 drivers/net/spider_net.c |2 +-
 drivers/net/spider_net.h |   19 +++
 2 files changed, 20 insertions(+), 1 deletion(-)


applied to #upstream (2.6.23)


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/9] pasemi_mac: Use MMIO instead of pci config accessors

[Jeff Garzik]

Olof Johansson wrote:

Move away from using the pci config access functions for simple register
access.  Our device has all of the registers in the config space (hey,
from the hardware point of view it looks reasonable :-), so we need to
somehow get to it. Newer firmwares have it in the device tree such that
we can just get it and ioremap it there (in case it ever moves in future
products). For now, provide a hardcoded fallback for older firmwares.


Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>


patches 4-9 seen sane.  dropped due to previous patches being dropped


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] pasemi_mac: Clean TX ring in poll

[Jeff Garzik]

Olof Johansson wrote:

Clean the TX ring in the poll call, to avoid sitting on mapped buffers
for a long time. NFS doesn't seem to like it much, for example.


Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

Index: netdev-2.6/drivers/net/pasemi_mac.c
===
--- netdev-2.6.orig/drivers/net/pasemi_mac.c
+++ netdev-2.6/drivers/net/pasemi_mac.c
@@ -1052,6 +1052,7 @@ static int pasemi_mac_poll(struct net_de
int pkts, limit = min(*budget, dev->quota);
struct pasemi_mac *mac = netdev_priv(dev);
 
+	pasemi_mac_clean_tx(mac);

pkts = pasemi_mac_clean_rx(mac, limit);


Why is this needed?  Is your TX interrupt mitigated or delayed somehow?

In general, drivers should only clean TX in one place.  Doing so in 
multiple places tends to indicate a bug somewhere.


You are correct that you should not sit on buffers for too long -- that 
increases latency of all who are waiting on those buffers to be sent.



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/9] pasemi_mac: Abstract out register access

[Jeff Garzik]

Olof Johansson wrote:

Abstract out the PCI config read/write accesses into reg read/write ones, still
calling the pci accessors on the back end.

Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>


Index: netdev-2.6/drivers/net/pasemi_mac.c
===
--- netdev-2.6.orig/drivers/net/pasemi_mac.c
+++ netdev-2.6/drivers/net/pasemi_mac.c
@@ -81,6 +81,48 @@ MODULE_PARM_DESC(debug, "PA Semi MAC bit
 
 static struct pasdma_status *dma_status;
 
+static unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)

+{
+   unsigned int val;
+
+   pci_read_config_dword(mac->iob_pdev, reg, &val);
+   return val;
+}
+
+static void write_iob_reg(struct pasemi_mac *mac, unsigned int reg,
+ unsigned int val)
+{
+   pci_write_config_dword(mac->iob_pdev, reg, val);
+}
+
+static unsigned int read_mac_reg(struct pasemi_mac *mac, unsigned int reg)
+{
+   unsigned int val;
+
+   pci_read_config_dword(mac->pdev, reg, &val);
+   return val;
+}
+
+static void write_mac_reg(struct pasemi_mac *mac, unsigned int reg,
+ unsigned int val)
+{
+   pci_write_config_dword(mac->pdev, reg, val);
+}
+
+static unsigned int read_dma_reg(struct pasemi_mac *mac, unsigned int reg)
+{
+   unsigned int val;
+
+   pci_read_config_dword(mac->dma_pdev, reg, &val);
+   return val;
+}
+
+static void write_dma_reg(struct pasemi_mac *mac, unsigned int reg,
+ unsigned int val)
+{
+   pci_write_config_dword(mac->dma_pdev, reg, val);
+}


The general concept is fine, but you should use 'u32' and similar 
size-based types for your input and output values.



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ps3: gigabit ethernet driver for PS3, take2

[Jeff Garzik]

MOKUNO Masakazu wrote:

Hi,

This is the second submission of the network driver for PS3.
This version have been updated to address issues raised in the review. 
Please apply for 2.6.23.


From: Masakazu Mokuno <[EMAIL PROTECTED]>

Add Gigabit Ethernet support for the PS3 game console.  The module will
be called ps3_gelic.

CC: Geoff Levand <[EMAIL PROTECTED]>
Signed-off-by: Masakazu Mokuno <[EMAIL PROTECTED]>
---
 MAINTAINERS |6 
 drivers/net/Kconfig |   10 
 drivers/net/Makefile|2 
 drivers/net/gelic_net.c | 1578 

 drivers/net/gelic_net.h |  241 +++
 5 files changed, 1837 insertions(+)

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2920,6 +2920,12 @@ M:   [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
 S: Maintained
 
+PS3 NETWORK SUPPORT

+P: Masakazu Mokuno
+M: [EMAIL PROTECTED]
+L: netdev@vger.kernel.org
+S: Supported
+
 PS3 PLATFORM SUPPORT
 P: Geoff Levand
 M: [EMAIL PROTECTED]
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2264,6 +2264,16 @@ config TSI108_ETH
 To compile this driver as a module, choose M here: the module
 will be called tsi108_eth.
 
+config GELIC_NET

+   tristate "PS3 Gigabit Ethernet driver"
+   depends on PPC_PS3
+   help
+ This driver supports the network device on the PS3 game
+ console.  This driver has built-in support for Ethernet.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ps3_gelic.
+
 config GIANFAR
tristate "Gianfar Ethernet"
depends on 85xx || 83xx || PPC_86xx
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -60,6 +60,8 @@ obj-$(CONFIG_TIGON3) += tg3.o
 obj-$(CONFIG_BNX2) += bnx2.o
 spidernet-y += spider_net.o spider_net_ethtool.o
 obj-$(CONFIG_SPIDER_NET) += spidernet.o sungem_phy.o
+obj-$(CONFIG_GELIC_NET) += ps3_gelic.o
+ps3_gelic-objs += gelic_net.o
 obj-$(CONFIG_TC35815) += tc35815.o
 obj-$(CONFIG_SKGE) += skge.o
 obj-$(CONFIG_SKY2) += sky2.o
--- /dev/null
+++ b/drivers/net/gelic_net.c


The patch does not reflect the new name...


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RESEND [PATCH 1/3] NetXen: Fix issue of MSI not working correctly

[Jeff Garzik]

[EMAIL PROTECTED] wrote:

NetXen driver uses PCI function 0 to provide the functionality of MSI.
The patch makes driver check the bus master bit for function 0 and
enable it after the card initialization.

Signed-off-by: Dhananjay Phadke<[EMAIL PROTECTED]>
Signed-off-by: Milan Bag <[EMAIL PROTECTED]>
Signed-off-by: Wen Xiong <[EMAIL PROTECTED]>


applied patch #1 and #2 (dated July 1, 2:55PM)

applied patch #3 (dated July 2, 12:07 AM)


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html