* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Eric Dumazet @ 2011-04-13 15:28 UTC (permalink / raw)
To: Scot Doyle; +Cc: Stephen Hemminger, David Miller, Hiroaki SHIMODA, netdev
In-Reply-To: <4DA5BCF7.9020606@scotdoyle.com>
Le mercredi 13 avril 2011 à 10:10 -0500, Scot Doyle a écrit :
> The net effect is that three patches are required to eliminate the panics.
>
> These two patches have been accepted by David:
> http://article.gmane.org/gmane.linux.network/192015
> http://article.gmane.org/gmane.linux.network/192055
>
> This patch, incrementally authored by Stephen and Eric and compiled by
> me, is also required:
> http://article.gmane.org/gmane.linux.network/192007
>
> What should happen for this third patch to be included upstream?
Dont worry, Stephen or me will send it asap.
Thanks
^ permalink raw reply
* Linux L4-Load Balancing with ECMP
From: Christoph Paasch @ 2011-04-13 15:24 UTC (permalink / raw)
To: netdev; +Cc: Gregory Detal
Hi all,
we were trying to do L4-load-balancing with the Linux Kernel (by configuring
multiple nexthops for the default-route) , and were surprised to see that the
Linux Kernel load-balances the traffic based only on the IP-addresses and does
not consider the 5-tuple, when forwarding the traffic.
As L4 load-balancing with ECMP is quite common, I was wondering, if it has
ever been considered to include this in the Kernel?
Or, what are the reasons that it is not inside?
Thanks,
Christoph Paasch
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [PATCH] bridge: reset IPCB in br_parse_ip_options
From: Scot Doyle @ 2011-04-13 15:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, netdev
In-Reply-To: <20110413082457.52784d6d@nehalam>
On 04/13/2011 10:24 AM, Stephen Hemminger wrote:
>> The net effect is that three patches are required to eliminate the panics.
>>
>> These two patches have been accepted by David:
>> http://article.gmane.org/gmane.linux.network/192015
>> http://article.gmane.org/gmane.linux.network/192055
>>
>> This patch, incrementally authored by Stephen and Eric and compiled by
>> me, is also required:
>> http://article.gmane.org/gmane.linux.network/192007
>>
>> What should happen for this third patch to be included upstream?
> Although making IP more robust is a good.
> I still think bridging shouldn't give bad packets to IP.
I'm definitely willing to test alternative patches. The output without
that third patch is:
[ 761.720393] BUG: unable to handle kernel NULL pointer dereference at
00000000000000d0
[ 761.728206] IP: [<ffffffff8129fbe9>] ip_options_compile+0x1c1/0x435
[ 761.734452] PGD 0
[ 761.736459] Oops: 0000 [#1] SMP
[ 761.739683] last sysfs file: /sys/devices/virtual/misc/kvm/uevent
[ 761.745744] CPU 0
[ 761.747570] Modules linked in: kvm_intel kvm bridge stp loop snd_pcm
snd_timer snd tpm_tis tpm tpm_bios soundcore psmouse snd_page_alloc
processor ghes thermal_sys
i7core_edac evdev pcspkr serio_raw edac_core dcdbas power_meter button
hed ext2 mbcache dm_mod raid1 md_mod sd_mod crc_t10dif usb_storage uas
uhci_hcd ehci_hcd mpt2sas
scsi_transport_sas raid_class igb scsi_mod usbcore bnx2 dca [last
unloaded: scsi_wait_scan]
[ 761.785171]
[ 761.786651] Pid: 0, comm: swapper Not tainted 2.6.39-rc3+ #14 Dell
Inc. PowerEdge R510/0DPRKF
[ 761.795157] RIP: 0010:[<ffffffff8129fbe9>] [<ffffffff8129fbe9>]
ip_options_compile+0x1c1/0x435
[ 761.803823] RSP: 0018:ffff88042f203af0 EFLAGS: 00010286
[ 761.809106] RAX: 0000000000000017 RBX: ffff8804027b3600 RCX:
ffff88040466a864
[ 761.816205] RDX: 000000000000001a RSI: 0000000000000000 RDI:
ffffffff817e6100
[ 761.823304] RBP: ffff88040466a862 R08: ffffffffa01d6e89 R09:
ffff88042f203c58
[ 761.830402] R10: 0000000000000000 R11: 0000000000000000 R12:
ffff8804027b3628
[ 761.837501] R13: 000000000000001d R14: ffff88040466a84e R15:
0000000000000024
[ 761.844601] FS: 0000000000000000(0000) GS:ffff88042f200000(0000)
knlGS:0000000000000000
[ 761.852650] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 761.858365] CR2: 00000000000000d0 CR3: 0000000001603000 CR4:
00000000000006f0
[ 761.865463] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 761.872562] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 761.879661] Process swapper (pid: 0, threadinfo ffffffff81600000,
task ffffffff8160b020)
[ 761.887710] Stack:
[ 761.889708] 0000000000000000 ffffffff81276928 0000000000000000
ffffffff817e6100
[ 761.897102] 000000000000004e ffff88040500e600 ffff88040500e600
ffff8804027b3600
[ 761.904496] ffff880404fc0000 ffff8804027b3628 0000000000000000
ffff880404fc0000
[ 761.911889] Call Trace:
[ 761.914319] <IRQ>
[ 761.916413] [<ffffffff81276928>] ? netif_receive_skb+0x52/0x58
[ 761.922306] [<ffffffffa01dae3b>] ? br_parse_ip_options+0x134/0x1a8
[bridge]
[ 761.929319] [<ffffffffa01dbbe0>] ? br_nf_pre_routing+0x348/0x3cb
[bridge]
[ 761.936160] [<ffffffff81298527>] ? nf_iterate+0x41/0x7e
[ 761.941444] [<ffffffff8104afaa>] ? irq_exit+0x58/0x8f
[ 761.946556] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
[ 761.953052] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
[ 761.959546] [<ffffffff812985d7>] ? nf_hook_slow+0x73/0x114
[ 761.965089] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
[ 761.971583] [<ffffffff8126d097>] ? __netdev_alloc_skb+0x15/0x2f
[ 761.977561] [<ffffffffa01d6e89>] ? NF_HOOK.clone.4+0x56/0x56 [bridge]
[ 761.984055] [<ffffffffa01d6e6f>] ? NF_HOOK.clone.4+0x3c/0x56 [bridge]
[ 761.990551] [<ffffffff812a7dde>] ? tcp_gro_receive+0xa1/0x204
[ 761.996355] [<ffffffffa01d71e5>] ? br_handle_frame+0x195/0x1ac [bridge]
[ 762.003022] [<ffffffffa01d7050>] ?
br_handle_frame_finish+0x1c7/0x1c7 [bridge]
[ 762.010294] [<ffffffff812764ef>] ? __netif_receive_skb+0x2a7/0x450
[ 762.016530] [<ffffffff81276928>] ? netif_receive_skb+0x52/0x58
[ 762.022420] [<ffffffff81276e2a>] ? napi_gro_receive+0x1f/0x2f
[ 762.028222] [<ffffffff812769ff>] ? napi_skb_finish+0x1c/0x31
[ 762.033941] [<ffffffffa024afcd>] ? igb_poll+0x6d9/0x9ee [igb]
[ 762.039744] [<ffffffff8109034f>] ? handle_irq_event+0x40/0x55
[ 762.045547] [<ffffffff8106fc3c>] ? arch_local_irq_save+0x14/0x1d
[ 762.051609] [<ffffffff81276f55>] ? net_rx_action+0xa4/0x1b1
[ 762.057239] [<ffffffff8104ad26>] ? __do_softirq+0xb8/0x176
[ 762.062783] [<ffffffff81333cdc>] ? call_softirq+0x1c/0x30
[ 762.068241] [<ffffffff8100aa57>] ? do_softirq+0x3f/0x84
[ 762.073524] [<ffffffff8104af91>] ? irq_exit+0x3f/0x8f
[ 762.078635] [<ffffffff8100a793>] ? do_IRQ+0x85/0x9e
[ 762.083575] [<ffffffff8132cc53>] ? common_interrupt+0x13/0x13
[ 762.089375] <EOI>
[ 762.091469] [<ffffffff81061348>] ? enqueue_hrtimer+0x3f/0x53
[ 762.097188] [<ffffffffa0430417>] ? arch_local_irq_enable+0x7/0x8
[processor]
[ 762.104288] [<ffffffffa0430dab>] ? acpi_idle_enter_c1+0x86/0xa2
[processor]
[ 762.111303] [<ffffffff8125d05d>] ? cpuidle_idle_call+0xf4/0x17e
[ 762.117277] [<ffffffff81008298>] ? cpu_idle+0xa2/0xc4
[ 762.122388] [<ffffffff8169db60>] ? start_kernel+0x3b9/0x3c4
[ 762.128018] [<ffffffff8169d3c6>] ? x86_64_start_kernel+0x102/0x10f
[ 762.134253] Code: 4d 02 3c 03 0f 86 59 02 00 00 0f b6 d0 44 39 ea 7f
32 83 c2 03 44 39 ea 0f 8f 45 02 00 00 48 85 db 74 18 48 8b 74 24 10 0f
b6 c0 <8b> 96 d0 00 00 00 89 54 05 ff 41 80 4c 24 08 04 80 01 04 41 80
[ 762.153593] RIP [<ffffffff8129fbe9>] ip_options_compile+0x1c1/0x435
[ 762.159923] RSP <ffff88042f203af0>
[ 762.163391] CR2: 00000000000000d0
[ 762.167017] ---[ end trace e15d7b082f680b62 ]---
^ permalink raw reply
* Re: [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Amit Salecha @ 2011-04-13 15:59 UTC (permalink / raw)
To: Greg KH
Cc: netdev@vger.kernel.org, Anirban Chakraborty, David Miller,
Ameen Rahman, stable@kernel.org
In-Reply-To: <20110413140307.GA7426@kroah.com>
> On Wed, Apr 13, 2011 at 12:56:56AM -0500, Amit Salecha wrote:
> > > On Tue, Apr 12, 2011 at 09:01:13PM -0500, Amit Salecha wrote:
> > > >
> > > > This message and any attached documents contain information from
> > > QLogic Corporation or its wholly-owned subsidiaries that may be
> > > confidential. If you are not the intended recipient, you may not
> read,
> > > copy, distribute, or use this information. If you have received
> this
> > > transmission in error, please notify the sender immediately by
> reply e-
> > > mail and then delete this message.
> > >
> > > I have received this transmission in error.
> > >
> > > Please remove this from your footer, otherwise we can not accept
> any
> > > emails sent from you as actually being allowed to contribute to the
> > > kernel properly :(
> > >
> > I have send version two of this patch, that doesn't have this footer.
> > Please discard this one.
> >
> > This message and any attached documents contain information from
> QLogic Corporation or its wholly-owned subsidiaries that may be
> confidential. If you are not the intended recipient, you may not read,
> copy, distribute, or use this information. If you have received this
> transmission in error, please notify the sender immediately by reply e-
> mail and then delete this message.
>
> Your footer is still present, please fix this.
Footer will present in my reply to this email. But footer should not be there in patches sent by me.
Can you verify patch version 2 again ? Here http://patchwork.ozlabs.org/patch/90938/ I don't see any footer.
If you see footer with patch version 2, please send me that.
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* Re: [PATCH NET-2.6 1/1] qlcnic: limit skb frags for non tso packet
From: Greg KH @ 2011-04-13 16:15 UTC (permalink / raw)
To: Amit Salecha
Cc: netdev@vger.kernel.org, Anirban Chakraborty, David Miller,
Ameen Rahman, stable@kernel.org
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FD138407E@MNEXMB2.qlogic.org>
On Wed, Apr 13, 2011 at 10:59:56AM -0500, Amit Salecha wrote:
> > On Wed, Apr 13, 2011 at 12:56:56AM -0500, Amit Salecha wrote:
> > > > On Tue, Apr 12, 2011 at 09:01:13PM -0500, Amit Salecha wrote:
> > > > >
> > > > > This message and any attached documents contain information from
> > > > QLogic Corporation or its wholly-owned subsidiaries that may be
> > > > confidential. If you are not the intended recipient, you may not
> > read,
> > > > copy, distribute, or use this information. If you have received
> > this
> > > > transmission in error, please notify the sender immediately by
> > reply e-
> > > > mail and then delete this message.
> > > >
> > > > I have received this transmission in error.
> > > >
> > > > Please remove this from your footer, otherwise we can not accept
> > any
> > > > emails sent from you as actually being allowed to contribute to the
> > > > kernel properly :(
> > > >
> > > I have send version two of this patch, that doesn't have this footer.
> > > Please discard this one.
> > >
> > > This message and any attached documents contain information from
> > QLogic Corporation or its wholly-owned subsidiaries that may be
> > confidential. If you are not the intended recipient, you may not read,
> > copy, distribute, or use this information. If you have received this
> > transmission in error, please notify the sender immediately by reply e-
> > mail and then delete this message.
> >
> > Your footer is still present, please fix this.
>
>
> Footer will present in my reply to this email. But footer should not be there in patches sent by me.
> Can you verify patch version 2 again ? Here http://patchwork.ozlabs.org/patch/90938/ I don't see any footer.
> If you see footer with patch version 2, please send me that.
Your footer was not in your patch, correct. But it was in this email.
And that's the issue, you can't have that footer on emails you send to a
public list where you are going to be collaborating on a public project,
otherwise no one can use anything you say.
Now if you only think that people will just accept your patches, without
being able to have you participate in development and maintance of those
patches (which is required to be done through email), you are mistaken.
So please fix your email issue, otherwise it is not going to work.
Note, other people at qualcomm have fixed this, so you are not alone.
thanks,
greg k-h
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
^ permalink raw reply
* Re: [PATCH 2/4] [RFC rev2] virtio-net changes
From: Krishna Kumar2 @ 2011-04-13 16:20 UTC (permalink / raw)
To: Rusty Russell
Cc: anthony, arnd, avi, davem, eric.dumazet, horms, kvm, mst, netdev
In-Reply-To: <878vvf0wkd.fsf@rustcorp.com.au>
Hi Rusty,
Thanks for your feedback. I agree with all the changes, and will
make it and resubmit next.
thanks,
- KK
Rusty Russell <rusty@rustcorp.com.au> wrote on 04/13/2011 06:58:02 AM:
> Rusty Russell <rusty@rustcorp.com.au>
> 04/13/2011 06:58 AM
>
> To
>
> Krishna Kumar2/India/IBM@IBMIN, davem@davemloft.net, mst@redhat.com
>
> cc
>
> eric.dumazet@gmail.com, arnd@arndb.de, netdev@vger.kernel.org,
> horms@verge.net.au, avi@redhat.com, anthony@codemonkey.ws,
> kvm@vger.kernel.org, Krishna Kumar2/India/IBM@IBMIN
>
> Subject
>
> Re: [PATCH 2/4] [RFC rev2] virtio-net changes
>
> On Tue, 05 Apr 2011 20:38:52 +0530, Krishna Kumar <krkumar2@in.ibm.com>
wrote:
> > Implement mq virtio-net driver.
> >
> > Though struct virtio_net_config changes, it works with the old
> > qemu since the last element is not accessed unless qemu sets
> > VIRTIO_NET_F_MULTIQUEUE.
> >
> > Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
>
> Hi Krishna!
>
> This change looks fairly solid, but I'd prefer it split into a few
> stages for clarity.
>
> The first patch should extract out the struct send_queue and struct
> receive_queue, even though there's still only one. The second patch
> can then introduce VIRTIO_NET_F_MULTIQUEUE.
>
> You could split into more parts if that makes sense, but I'd prefer to
> see the mechanical changes separate from the feature addition.
>
> > -struct virtnet_info {
> > - struct virtio_device *vdev;
> > - struct virtqueue *rvq, *svq, *cvq;
> > - struct net_device *dev;
> > +/* Internal representation of a send virtqueue */
> > +struct send_queue {
> > + /* Virtqueue associated with this send _queue */
> > + struct virtqueue *svq;
>
> You can simply call this vq now it's inside 'send_queue'.
>
> > +
> > + /* TX: fragments + linear part + virtio header */
> > + struct scatterlist tx_sg[MAX_SKB_FRAGS + 2];
>
> Similarly, this can just be sg.
>
> > +static void free_receive_bufs(struct virtnet_info *vi)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < vi->numtxqs; i++) {
> > + BUG_ON(vi->rq[i] == NULL);
> > + while (vi->rq[i]->pages)
> > + __free_pages(get_a_page(vi->rq[i], GFP_KERNEL), 0);
> > + }
> > +}
>
> You can skip the BUG_ON(), since the next line will have the same effect.
>
> > +/* Free memory allocated for send and receive queues */
> > +static void free_rq_sq(struct virtnet_info *vi)
> > +{
> > + int i;
> > +
> > + if (vi->rq) {
> > + for (i = 0; i < vi->numtxqs; i++)
> > + kfree(vi->rq[i]);
> > + kfree(vi->rq);
> > + }
> > +
> > + if (vi->sq) {
> > + for (i = 0; i < vi->numtxqs; i++)
> > + kfree(vi->sq[i]);
> > + kfree(vi->sq);
> > + }
>
> This looks weird, even though it's correct.
>
> I think we need a better name than numtxqs and shorter than
> num_queue_pairs. Let's just use num_queues; sure, there are both tx and
> rq queues, but I still think it's pretty clear.
>
> > + for (i = 0; i < vi->numtxqs; i++) {
> > + struct virtqueue *svq = vi->sq[i]->svq;
> > +
> > + while (1) {
> > + buf = virtqueue_detach_unused_buf(svq);
> > + if (!buf)
> > + break;
> > + dev_kfree_skb(buf);
> > + }
> > + }
>
> I know this isn't your code, but it's ugly :)
>
> while ((buf = virtqueue_detach_unused_buf(svq)) != NULL)
> dev_kfree_skb(buf);
>
> > + for (i = 0; i < vi->numtxqs; i++) {
> > + struct virtqueue *rvq = vi->rq[i]->rvq;
> > +
> > + while (1) {
> > + buf = virtqueue_detach_unused_buf(rvq);
> > + if (!buf)
> > + break;
>
> Here too...
>
> > +#define MAX_DEVICE_NAME 16
>
> This isn't a good idea, see below.
>
> > +static int initialize_vqs(struct virtnet_info *vi, int numtxqs)
> > +{
> > + vq_callback_t **callbacks;
> > + struct virtqueue **vqs;
> > + int i, err = -ENOMEM;
> > + int totalvqs;
> > + char **names;
>
> This whole routine is really messy. How about doing find_vqs first,
> then have routines like setup_rxq(), setup_txq() and setup_controlq()
> would make this neater:
>
> static int setup_rxq(struct send_queue *sq, char *name);
>
> Also, use kasprintf() instead of kmalloc & sprintf.
>
> > +#if 1
> > + /* Allocate/initialize parameters for recv/send virtqueues */
>
> Why is this #if 1'd?
>
> I do prefer the #else method of doing two loops, myself (but use
> kasprintf).
>
> Cheers,
> Rusty.
^ permalink raw reply
* Re: [PATCH 0/4] [RFC rev2] Implement multiqueue (RX & TX) virtio-net
From: Krishna Kumar2 @ 2011-04-13 16:22 UTC (permalink / raw)
To: Avi Kivity
Cc: anthony, arnd, davem, eric.dumazet, horms, kvm, mst, netdev,
rusty
In-Reply-To: <4DA5904B.9090006@redhat.com>
Avi Kivity <avi@redhat.com> wrote on 04/13/2011 05:30:11 PM:
Hi Avi,
> > --------
> > 1. Reduce vectors for find_vqs().
> > 2. Make vhost changes minimal. For now, I have restricted the number of
> > vhost threads to 4. This can be either made unrestricted; or if the
> > userspace vhost works, it can be removed altogether.
> >
> > Please review and provide feedback. I am travelling a bit in the next
> > few days but will respond at the earliest.
>
> Do you have an update to the virtio-pci spec for this?
Not yet, will keep it in my TODO list.
thanks,
- KK
^ permalink raw reply
* Re: [PATCHv4 NEXT 1/1] net: ethtool support to configure number of channels
From: David Miller @ 2011-04-13 17:40 UTC (permalink / raw)
To: bhutchings
Cc: amit.salecha, netdev, ameen.rahman, sucheta.chakraborty,
anirban.chakraborty
In-Reply-To: <1302696197.5282.612.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 13 Apr 2011 13:03:17 +0100
> It's marked as 'deferred'; not sure what that means:
>
> http://patchwork.ozlabs.org/patch/90166/
It means it's out of my TODO list until something happens.
Specifically Ben I'm waiting for you to provide some review and
feedback on this patch since in the past you were the one saying
what needed to be changed in this patch.
I can't tell if you're requests have been met unless you actually
provide an ACK, or more feedback.
^ permalink raw reply
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: David Miller @ 2011-04-13 17:43 UTC (permalink / raw)
To: dbaluta; +Cc: eric.dumazet, akpm, netdev, bugzilla-daemon, bugme-daemon, kees
In-Reply-To: <BANLkTi=1wmQYRgHmO5SbPBiSwzKwVz4_ag@mail.gmail.com>
From: Daniel Baluta <dbaluta@ixiacom.com>
Date: Wed, 13 Apr 2011 14:57:18 +0300
> Cyril's use case looks suspect. I don't think that this is a good
> reason for reverting this commit.
I complete disagree.
Something that worked perfectly fine, probably for years, we broke.
We simply cannot do that, especially since we do not have a reasonable
alternative at this time.
Adding SO_REUSEPORT is a long range option, and not something that
will provide a fix for users right now.
So please don't even pretend to suggest that we shouldn't fix this
with a revert unless a simple, obvious, kernel fix presents itself.
^ permalink raw reply
* Re: [net-next-2.6] if_vlan.h: fix compile errors
From: David Miller @ 2011-04-13 17:46 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: jpirko, netdev
In-Reply-To: <BANLkTimn2GfWs3tmoh+GRX6vX6tH9FpEyg@mail.gmail.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 13 Apr 2011 04:03:57 -0700
> On Wed, Apr 13, 2011 at 03:57, Jiri Pirko <jpirko@redhat.com> wrote:
>> Thanks Jeff, this fix was already submitted by DaveM
>
> Ah, ok. I did not see anything in netdev patchworks and I did a
> recent pull of Dave's net-next tree so I knew I had the latest.
> Good to know it was caught, thanks Jiri.
Sorry, forgot to push before going to bed :-/
It's there now.
^ permalink raw reply
* Re: [PATCH] r8169: Be verbose when unable to load fw patch
From: François Romieu @ 2011-04-13 17:48 UTC (permalink / raw)
To: David Miller; +Cc: bp, romieu, linux-kernel, borislav.petkov, netdev
In-Reply-To: <20110412.162036.241924043.davem@davemloft.net>
On Tue, Apr 12, 2011 at 04:20:36PM -0700, David Miller wrote:
[...]
> Seems reasonable, Francois?
Yes, it makes sense.
The patch goes way beyond 80 cols but I'll do a round of
cleanups later anyway.
--
Ueimor
^ permalink raw reply
* Re: r8169 doesn't report link state correctly.
From: François Romieu @ 2011-04-13 17:48 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4DA35FEF.1030009@candelatech.com>
On Mon, Apr 11, 2011 at 01:09:19PM -0700, Ben Greear wrote:
> I notice that in kernel 2.6.38-wl, the realtek 8169 NIC doesn't
> report link down when in fact there is no cable connected. Instead,
> it shows 10Mbps half-duplex. I have no idea if this previously worked
> or not.
Thanks for the report. I'll try it tomorrow or friday.
--
Ueimor
^ permalink raw reply
* Re: [PATCH v2] net: r8169: convert to hw_features
From: François Romieu @ 2011-04-13 17:47 UTC (permalink / raw)
To: hayeswang
Cc: 'Michał Mirosław', netdev,
'David Dillow'
In-Reply-To: <BAFB047F568645FE911024B882E5C022@realtek.com.tw>
On Tue, Apr 12, 2011 at 10:10:20AM +0800, hayeswang wrote:
[...]
> Yes, all 8168 have the same Tx descriptors layout except for 8168B series.
Thanks Hayes.
I have started playing with the patch below on top of davem-next but
something in it is probably broken as enabling TSO kills the traffic
from several 10s of Mbytes per second to a few kbytes. I'll dig
further.
Subject: [PATCH] r8169: TSO fixes.
- the MSS value is actually contained in a 11 bits wide (0x7ff) field.
The extra bit in the former MSSMask did encompass the TSO command
bit ("LargeSend") as well (0xfff). Oops.
- the Tx descriptor layout is not the same through the whole chipset
family. The 8169 documentation, the 8168c documentation and Realtek's
drivers (8.020.00, 1.019.00, 6.014.00) highlight two layouts:
1. 8169, 8168 up to 8168b (included) and 8101
2. {8102e, 8168c} and beyond
- notwithstanding the "first descriptor" and "last descriptor" bits, the
same Tx descriptor content is enforced when a packet consists of several
descriptors. The chipsets are documented to require it.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 207 ++++++++++++++++++++++++++++++++++-----------------
1 files changed, 137 insertions(+), 70 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 058524f..61196a1 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -134,47 +134,52 @@ enum mac_version {
RTL_GIGA_MAC_VER_33 = 0x21, // 8168E
};
-#define _R(NAME,MAC,MASK) \
- { .name = NAME, .mac_version = MAC, .RxConfigMask = MASK }
+enum rtl_tx_desc_version {
+ RTL_TD_0 = 0,
+ RTL_TD_1 = 1,
+};
+
+#define _R(NAME,MAC,TD) \
+ { .name = NAME, .mac_version = MAC, .txd_version = TD }
static const struct {
const char *name;
u8 mac_version;
- u32 RxConfigMask; /* Clears the bits supported by this chip */
+ enum rtl_tx_desc_version txd_version;
} rtl_chip_info[] = {
- _R("RTL8169", RTL_GIGA_MAC_VER_01, 0xff7e1880), // 8169
- _R("RTL8169s", RTL_GIGA_MAC_VER_02, 0xff7e1880), // 8169S
- _R("RTL8110s", RTL_GIGA_MAC_VER_03, 0xff7e1880), // 8110S
- _R("RTL8169sb/8110sb", RTL_GIGA_MAC_VER_04, 0xff7e1880), // 8169SB
- _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_05, 0xff7e1880), // 8110SCd
- _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_06, 0xff7e1880), // 8110SCe
- _R("RTL8102e", RTL_GIGA_MAC_VER_07, 0xff7e1880), // PCI-E
- _R("RTL8102e", RTL_GIGA_MAC_VER_08, 0xff7e1880), // PCI-E
- _R("RTL8102e", RTL_GIGA_MAC_VER_09, 0xff7e1880), // PCI-E
- _R("RTL8101e", RTL_GIGA_MAC_VER_10, 0xff7e1880), // PCI-E
- _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
- _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_12, 0xff7e1880), // PCI-E
- _R("RTL8101e", RTL_GIGA_MAC_VER_13, 0xff7e1880), // PCI-E 8139
- _R("RTL8100e", RTL_GIGA_MAC_VER_14, 0xff7e1880), // PCI-E 8139
- _R("RTL8100e", RTL_GIGA_MAC_VER_15, 0xff7e1880), // PCI-E 8139
- _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_17, 0xff7e1880), // PCI-E
- _R("RTL8101e", RTL_GIGA_MAC_VER_16, 0xff7e1880), // PCI-E
- _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_18, 0xff7e1880), // PCI-E
- _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_19, 0xff7e1880), // PCI-E
- _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_20, 0xff7e1880), // PCI-E
- _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_21, 0xff7e1880), // PCI-E
- _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_22, 0xff7e1880), // PCI-E
- _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_23, 0xff7e1880), // PCI-E
- _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_24, 0xff7e1880), // PCI-E
- _R("RTL8168d/8111d", RTL_GIGA_MAC_VER_25, 0xff7e1880), // PCI-E
- _R("RTL8168d/8111d", RTL_GIGA_MAC_VER_26, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_27, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880), // PCI-E
- _R("RTL8105e", RTL_GIGA_MAC_VER_29, 0xff7e1880), // PCI-E
- _R("RTL8105e", RTL_GIGA_MAC_VER_30, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_31, 0xff7e1880), // PCI-E
- _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_32, 0xff7e1880), // PCI-E
- _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_33, 0xff7e1880) // PCI-E
+ _R("RTL8169", RTL_GIGA_MAC_VER_01, RTL_TD_0), // 8169
+ _R("RTL8169s", RTL_GIGA_MAC_VER_02, RTL_TD_0), // 8169S
+ _R("RTL8110s", RTL_GIGA_MAC_VER_03, RTL_TD_0), // 8110S
+ _R("RTL8169sb/8110sb", RTL_GIGA_MAC_VER_04, RTL_TD_0), // 8169SB
+ _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_05, RTL_TD_0), // 8110SCd
+ _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_06, RTL_TD_0), // 8110SCe
+ _R("RTL8102e", RTL_GIGA_MAC_VER_07, RTL_TD_1), // PCI-E
+ _R("RTL8102e", RTL_GIGA_MAC_VER_08, RTL_TD_1), // PCI-E
+ _R("RTL8102e", RTL_GIGA_MAC_VER_09, RTL_TD_1), // PCI-E
+ _R("RTL8101e", RTL_GIGA_MAC_VER_10, RTL_TD_0), // PCI-E
+ _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_11, RTL_TD_0), // PCI-E
+ _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_12, RTL_TD_0), // PCI-E
+ _R("RTL8101e", RTL_GIGA_MAC_VER_13, RTL_TD_0), // PCI-E 8139
+ _R("RTL8100e", RTL_GIGA_MAC_VER_14, RTL_TD_0), // PCI-E 8139
+ _R("RTL8100e", RTL_GIGA_MAC_VER_15, RTL_TD_0), // PCI-E 8139
+ _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_17, RTL_TD_0), // PCI-E
+ _R("RTL8101e", RTL_GIGA_MAC_VER_16, RTL_TD_0), // PCI-E
+ _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_18, RTL_TD_1), // PCI-E
+ _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_19, RTL_TD_1), // PCI-E
+ _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_20, RTL_TD_1), // PCI-E
+ _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_21, RTL_TD_1), // PCI-E
+ _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_22, RTL_TD_1), // PCI-E
+ _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_23, RTL_TD_1), // PCI-E
+ _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_24, RTL_TD_1), // PCI-E
+ _R("RTL8168d/8111d", RTL_GIGA_MAC_VER_25, RTL_TD_1), // PCI-E
+ _R("RTL8168d/8111d", RTL_GIGA_MAC_VER_26, RTL_TD_1), // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_27, RTL_TD_1), // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, RTL_TD_1), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_29, RTL_TD_1), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_30, RTL_TD_1), // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_31, RTL_TD_1), // PCI-E
+ _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_32, RTL_TD_1), // PCI-E
+ _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_33, RTL_TD_1) // PCI-E
};
#undef _R
@@ -230,6 +235,9 @@ enum rtl_registers {
IntrStatus = 0x3e,
TxConfig = 0x40,
RxConfig = 0x44,
+
+#define RTL_RX_CONFIG_MASK 0xff7e1880u
+
RxMissed = 0x4c,
Cfg9346 = 0x50,
Config0 = 0x51,
@@ -452,21 +460,69 @@ enum rtl_register_content {
CounterDump = 0x8,
};
-enum desc_status_bit {
+enum rtl_desc_bit {
+ /* First doubleword. */
DescOwn = (1 << 31), /* Descriptor is owned by NIC */
RingEnd = (1 << 30), /* End of descriptor ring */
FirstFrag = (1 << 29), /* First segment of a packet */
LastFrag = (1 << 28), /* Final segment of a packet */
+};
+
+/* Generic case. */
+enum rtl_tx_desc_bit {
+ /* First doubleword. */
+ TD_LSO = (1 << 27), /* Large Send Offload */
+#define TD_MSS_MAX 0x07ffu /* MSS value */
- /* Tx private */
- LargeSend = (1 << 27), /* TCP Large Send Offload (TSO) */
- MSSShift = 16, /* MSS value position */
- MSSMask = 0xfff, /* MSS value + LargeSend bit: 12 bits */
- IPCS = (1 << 18), /* Calculate IP checksum */
- UDPCS = (1 << 17), /* Calculate UDP/IP checksum */
- TCPCS = (1 << 16), /* Calculate TCP/IP checksum */
- TxVlanTag = (1 << 17), /* Add VLAN tag */
+ /* Second doubleword. */
+ TxVlanTag = (1 << 17), /* Add VLAN tag */
+};
+
+/* 8169, 8168b and 810x except 8102e. */
+enum rtl_tx_desc_bit_0 {
+ /* First doubleword. */
+#define TD0_MSS_SHIFT 16 /* MSS position (11 bits) */
+ TD0_TCP_CS = (1 << 16), /* Calculate TCP/IP checksum */
+ TD0_UDP_CS = (1 << 17), /* Calculate UDP/IP checksum */
+ TD0_IP_CS = (1 << 18), /* Calculate IP checksum */
+};
+
+/* 8102e, 8168c and beyond. */
+enum rtl_tx_desc_bit_1 {
+ /* Second doubleword. */
+#define TD1_MSS_SHIFT 18 /* MSS position (11 bits) */
+ TD1_IP_CS = (1 << 29), /* Calculate IP checksum */
+ TD1_TCP_CS = (1 << 30), /* Calculate TCP/IP checksum */
+ TD1_UDP_CS = (1 << 31), /* Calculate UDP/IP checksum */
+};
+static const struct rtl_tx_desc_info {
+ struct {
+ u32 udp;
+ u32 tcp;
+ } checksum;
+ u16 mss_shift;
+ u16 opts_offset;
+} tx_desc_info [] = {
+ [RTL_TD_0] = {
+ .checksum = {
+ .udp = TD0_IP_CS | TD0_UDP_CS,
+ .tcp = TD0_IP_CS | TD0_TCP_CS
+ },
+ .mss_shift = TD0_MSS_SHIFT,
+ .opts_offset = 0
+ },
+ [RTL_TD_1] = {
+ .checksum = {
+ .udp = TD1_IP_CS | TD1_UDP_CS,
+ .tcp = TD1_IP_CS | TD1_TCP_CS
+ },
+ .mss_shift = TD1_MSS_SHIFT,
+ .opts_offset = 1
+ }
+};
+
+enum rtl_rx_desc_bit {
/* Rx private */
PID1 = (1 << 18), /* Protocol ID bit 1/2 */
PID0 = (1 << 17), /* Protocol ID bit 2/2 */
@@ -531,8 +587,8 @@ struct rtl8169_private {
struct napi_struct napi;
spinlock_t lock; /* spin lock flag */
u32 msg_enable;
- int chipset;
- int mac_version;
+ u16 txd_version;
+ u16 mac_version;
u32 cur_rx; /* Index into the Rx descriptor buffer of next Rx pkt. */
u32 cur_tx; /* Index into the Tx descriptor buffer of next Rx pkt. */
u32 dirty_rx;
@@ -1288,7 +1344,7 @@ static int rtl8169_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
static u32 rtl8169_fix_features(struct net_device *dev, u32 features)
{
- if (dev->mtu > MSSMask)
+ if (dev->mtu > TD_MSS_MAX)
features &= ~NETIF_F_ALL_TSO;
return features;
@@ -3194,7 +3250,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
struct mii_if_info *mii;
struct net_device *dev;
void __iomem *ioaddr;
- unsigned int i;
+ int chipset, i;
int rc;
if (netif_msg_drv(&debug)) {
@@ -3336,7 +3392,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
"driver bug, MAC version not found in rtl_chip_info\n");
goto err_out_msi_4;
}
- tp->chipset = i;
+ chipset = i;
+ tp->txd_version = rtl_chip_info[chipset].txd_version;
RTL_W8(Cfg9346, Cfg9346_Unlock);
RTL_W8(Config1, RTL_R8(Config1) | PMEnable);
@@ -3413,8 +3470,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, dev);
netif_info(tp, probe, dev, "%s at 0x%lx, %pM, XID %08x IRQ %d\n",
- rtl_chip_info[tp->chipset].name,
- dev->base_addr, dev->dev_addr,
+ rtl_chip_info[chipset].name, dev->base_addr, dev->dev_addr,
(u32)(RTL_R32(TxConfig) & 0x9cf0f8ff), dev->irq);
if ((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
@@ -3572,7 +3628,7 @@ static void rtl_set_rx_tx_config_registers(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
u32 cfg = rtl8169_rx_config;
- cfg |= (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask);
+ cfg |= (RTL_R32(RxConfig) & RTL_RX_CONFIG_MASK);
RTL_W32(RxConfig, cfg);
/* Set DMA burst size and Interframe Gap Time */
@@ -4564,7 +4620,7 @@ static void rtl8169_tx_timeout(struct net_device *dev)
}
static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
- u32 opts1)
+ u32 *opts)
{
struct skb_shared_info *info = skb_shinfo(skb);
unsigned int cur_frag, entry;
@@ -4592,9 +4648,11 @@ static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
}
/* anti gcc 2.95.3 bugware (sic) */
- status = opts1 | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
+ status = opts[0] | len |
+ (RingEnd * !((entry + 1) % NUM_TX_DESC));
txd->opts1 = cpu_to_le32(status);
+ txd->opts2 = cpu_to_le32(opts[1]);
txd->addr = cpu_to_le64(mapping);
tp->tx_skb[entry].len = len;
@@ -4612,23 +4670,28 @@ err_out:
return -EIO;
}
-static inline u32 rtl8169_tso_csum(struct sk_buff *skb, struct net_device *dev)
+static inline void rtl8169_tso_csum(struct rtl8169_private *tp,
+ struct sk_buff *skb, u32 *opts)
{
+ const struct rtl_tx_desc_info *info = tx_desc_info + tp->txd_version;
u32 mss = skb_shinfo(skb)->gso_size;
+ int offset = info->opts_offset;
- if (mss)
- return LargeSend | ((mss & MSSMask) << MSSShift);
+ if (mss) {
+ opts[0] |= TD_LSO;
+ opts[offset] |= min(mss, TD_MSS_MAX) << info->mss_shift;
+ }
if (skb->ip_summed == CHECKSUM_PARTIAL) {
const struct iphdr *ip = ip_hdr(skb);
if (ip->protocol == IPPROTO_TCP)
- return IPCS | TCPCS;
+ opts[offset] |= info->checksum.tcp;
else if (ip->protocol == IPPROTO_UDP)
- return IPCS | UDPCS;
- WARN_ON(1); /* we need a WARN() */
+ opts[offset] |= info->checksum.udp;
+ else
+ WARN_ON(1); /* we need a WARN() */
}
- return 0;
}
static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
@@ -4641,7 +4704,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
struct device *d = &tp->pci_dev->dev;
dma_addr_t mapping;
u32 status, len;
- u32 opts1;
+ u32 opts[2];
int frags;
if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) {
@@ -4662,24 +4725,28 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
tp->tx_skb[entry].len = len;
txd->addr = cpu_to_le64(mapping);
- txd->opts2 = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
- opts1 = DescOwn | rtl8169_tso_csum(skb, dev);
+ opts[1] = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
+ opts[0] = DescOwn;
- frags = rtl8169_xmit_frags(tp, skb, opts1);
+ rtl8169_tso_csum(tp, skb, opts);
+
+ frags = rtl8169_xmit_frags(tp, skb, opts);
if (frags < 0)
goto err_dma_1;
else if (frags)
- opts1 |= FirstFrag;
+ opts[0] |= FirstFrag;
else {
- opts1 |= FirstFrag | LastFrag;
+ opts[0] |= FirstFrag | LastFrag;
tp->tx_skb[entry].skb = skb;
}
+ txd->opts2 = cpu_to_le32(opts[1]);
+
wmb();
/* anti gcc 2.95.3 bugware (sic) */
- status = opts1 | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
+ status = opts[0] | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
txd->opts1 = cpu_to_le32(status);
tp->cur_tx += frags + 1;
@@ -5167,7 +5234,7 @@ static void rtl_set_rx_mode(struct net_device *dev)
spin_lock_irqsave(&tp->lock, flags);
tmp = rtl8169_rx_config | rx_mode |
- (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask);
+ (RTL_R32(RxConfig) & RTL_RX_CONFIG_MASK);
if (tp->mac_version > RTL_GIGA_MAC_VER_06) {
u32 data = mc_filter[0];
--
1.7.4.2
^ permalink raw reply related
* Re: [PATCH] r8169: Be verbose when unable to load fw patch
From: David Miller @ 2011-04-13 17:57 UTC (permalink / raw)
To: romieu; +Cc: bp, linux-kernel, borislav.petkov, netdev
In-Reply-To: <20110413174852.GC17579@electric-eye.fr.zoreil.com>
From: François Romieu <romieu@fr.zoreil.com>
Date: Wed, 13 Apr 2011 19:48:52 +0200
> On Tue, Apr 12, 2011 at 04:20:36PM -0700, David Miller wrote:
> [...]
>> Seems reasonable, Francois?
>
> Yes, it makes sense.
>
> The patch goes way beyond 80 cols but I'll do a round of
> cleanups later anyway.
Ok. So will you submit this yourself later or should I just
apply this myself directly to net-2.6?
I'm fine either way.
Thanks!
^ permalink raw reply
* Re: Bonding/LACP on RTL8169sc/8110sc (R1869)
From: François Romieu @ 2011-04-13 17:49 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Jonathan Thibault, netdev
In-Reply-To: <13118.1302648465@death>
On Tue, Apr 12, 2011 at 03:47:45PM -0700, Jay Vosburgh wrote:
> Jonathan Thibault <jonathan@navigue.com> wrote:
[2.6.32.old]
> That's a fairly old kernel; one relatively recent fix that comes
> to mind is:
The r8169 driver has undergone some multicast fixes since 2.6.32 as well.
If I remember correctly, the old 8169 - not the 8168 - was hit.
Upgrading is really suggested.
--
Ueimor
^ permalink raw reply
* Re: [Bugme-new] [Bug 33042] New: Marvell 88E1145 phy configured incorrectly in fiber mode
From: Andy Fleming @ 2011-04-13 18:01 UTC (permalink / raw)
To: Alex Dubov
Cc: Andrew Morton, David Daney, netdev, bugzilla-daemon, bugme-daemon,
Grant Likely, Andy Fleming
In-Reply-To: <392488.26736.qm@web37606.mail.mud.yahoo.com>
On Mon, Apr 11, 2011 at 10:45 PM, Alex Dubov <oakad@yahoo.com> wrote:
>>
>> How does your u-boot configure the part? Does it
>> write any of the
>> configuration registers, or is it just the default
>> configuration set via
>> the strapping pins?
>
> U-boot configures this phy just like any other phy - by running a set of
> register assignments from phy_info_M88E1145.
>
> Unfortunately, I don't have a datasheet for this phy and kernel does
> quite a few things differently, so simply copying stuff from u-boot
> does not work well (in kernel, phy initialization is broken into 3
> functions, if I'm not mistaken).
I've just rewritten the U-Boot code for PHY management, so I'd be
interested in hearing if this breaks your board. But what's
interesting to me is that, in order for U-Boot to report that the link
is a "fiber" link, something had to set the TSEC_FIBER flag, and only
one PHY in the public source did. This implies to me that your board
isn't supported by mainline U-Boot, and suggests that someone may have
modified the 88e1145 driver. Otherwise, I don't see any fiber-related
differences between the U-Boot 1145 driver, and the Linux one.
>
>
>>
>> In any event, you will probably have to read the
>> configuration before
>> the drivers/net/phy/marvel.c changes them. Then
>> compare that to what
>> the driver is trying to set. Then you will either
>> have to override the
>> configuration with the device tree "marvell,reg-init"
>> property, or if
>> you are not using the device tree, add a 88e1145 specific
>> flag that you
>> set when calling phy_connect().
Reading the configuration from U-Boot is straightforward. use the
"mii" command to read the registers. But don't forget to set register
22 (16 - mii command only reads hex) to 1, and read all of the
registers that way, too.
You will either need to add some code to detect when the PHY is using
fiber, and change the phydev->port to PORT_FIBRE, or you will need to
add a board-level "fixup" to change the port to PORT_FIBRE on your
board.
Then the PHY driver should use that information to do the right configuration.
Andy
^ permalink raw reply
* Re: [PATCHv4 NEXT 1/1] net: ethtool support to configure number of channels
From: Ben Hutchings @ 2011-04-13 18:22 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: davem, netdev, ameen.rahman, sucheta.chakraborty,
anirban.chakraborty
In-Reply-To: <1302177522-17815-1-git-send-email-amit.salecha@qlogic.com>
On Thu, 2011-04-07 at 04:58 -0700, Amit Kumar Salecha wrote:
> Ethtool support to configure RX, TX and other channels. combined field
> in struct ethtool_channels to reflect set of channel (RX, TX or other).
> Other channel can be link interrupts, SR-IOV coordination etc.
>
> ETHTOOL_GCHANNELS will report max and current number of RX channels,
> max and current number of TX channels, max and current number of other channel
> or max and current number of combined channel.
>
> Number of channel can be modify upto max number of channel through
> ETHTOOL_SCHANNELS command.
>
> Ben Hutchings:
> o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
> queues so that most channels combine RX and TX work.
> o Please could you use a kernel-doc comment to describe the structure.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Sorry for the delay.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: panic in tg3 driver
From: Stephen Clark @ 2011-04-13 18:23 UTC (permalink / raw)
To: Matt Carlson; +Cc: Linux Kernel Network Developers, Michael Chan
In-Reply-To: <20110125022532.GA19884@mcarlson.broadcom.com>
On 01/24/2011 09:25 PM, Matt Carlson wrote:
> On Mon, Jan 24, 2011 at 04:59:22PM -0800, Matt Carlson wrote:
>
>> On Sun, Jan 16, 2011 at 10:11:50AM -0800, Stephen Clark wrote:
>>
>>> On 01/13/2011 08:12 AM, Stephen Clark wrote:
>>>
>>>> On 01/11/2011 10:06 PM, Matt Carlson wrote:
>>>>
>>>>> lspci -vvv -xxx -s 81:00.0
>>>>>
>>>>
>>>>
>>>> Further information - I found these messages in /var/log/messages. It
>>>> looks
>>>> like after it switched to INTx mode interrupts for other devices were
>>>> hosed.
>>>>
>>>> Jan 12 08:37:49 localhost kernel: tg3 0000:81:00.0: eth2: No interrupt
>>>> was gener
>>>> ated using MSI. Switching to INTx mode. Please report this failure to
>>>> the PCI ma
>>>> intainer and include system chipset information
>>>> Jan 12 08:37:49 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is
>>>> not ready
>>>> Jan 12 08:38:50 localhost kernel: ata2: lost interrupt (Status 0x50)
>>>> Jan 12 08:38:50 localhost kernel: ata2.01: exception Emask 0x0 SAct
>>>> 0x0 SErr 0x0
>>>> action 0x6 frozen
>>>> Jan 12 08:38:50 localhost kernel: ata2.01: failed command: WRITE DMA
>>>> Jan 12 08:38:50 localhost kernel: ata2.01: cmd
>>>> ca/00:08:e0:bc:51/00:00:00:00:00/f0 tag 0 dma 4096 out
>>>> Jan 12 08:38:50 localhost kernel: res
>>>> 40/00:01:00:4f:c2/00:00:00:00:00/b0 Emask 0x4 (timeout)
>>>> Jan 12 08:38:50 localhost kernel: ata2.01: status: { DRDY }
>>>> Jan 12 08:38:50 localhost kernel: ata2: soft resetting link
>>>> Jan 12 08:38:50 localhost kernel: do_IRQ: 0.64 No irq handler for
>>>> vector (irq -1)
>>>> Jan 12 08:38:50 localhost kernel: ata2.01: configured for UDMA/33
>>>> Jan 12 08:38:54 localhost pppd[1983]: No response to 3 echo-requests
>>>> Jan 12 08:39:55 localhost pppoe[1988]: Inactivity timeout... something
>>>> wicked happened on session 3363
>>>>
>>> Just checking to make sure you have everything you need?
>>>
>> Sorry for the delay Stephen.
>>
>> It looks to me like interrupts aren't being setup correctly on this
>> system. I tested MSI and INTx interrupt modes locally and they both
>> work. I'm guessing one of two things could be happening:
>>
>> 1) The 2nd parameter of the low-level ISR (tg3_interrupt_tagged()) is
>> not correct. The ISR tries to tell the hardware the interrupt is
>> acknowledged, but the message goes unheard. (This might also explain
>> why other devices are also afflicted.)
>>
>> 2) Something is blocking the delivery of the interrupt to the tg3 driver
>> altogether.
>>
>> In both cases, the hardware persistently nags the host to ack the
>> interrupt, hence the interrupt storm.
>>
> Just curious, is the problem still there if you add pci=nomsi to the
> kernel command line?
>
>
Sorry I have been tied up.
With kernel 2.6.32-44.1.el6.i686 and pci=nomsi on the kernel command
line it seems to work great.
[root@Z1010 ~]# ping -f 3.3.3.2
PING 3.3.3.2 (3.3.3.2) 56(84) bytes of data.
.^
--- 3.3.3.2 ping statistics ---
20562 packets transmitted, 20562 received, 0% packet loss, time 4408ms
rtt min/avg/max/mdev = 0.141/0.163/1.021/0.034 ms, ipg/ewma 0.214/0.161 ms
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: Bonding/LACP on RTL8169sc/8110sc (R1869)
From: Ben Hutchings @ 2011-04-13 18:28 UTC (permalink / raw)
To: François Romieu; +Cc: Jay Vosburgh, Jonathan Thibault, netdev
In-Reply-To: <20110413174943.GD17579@electric-eye.fr.zoreil.com>
On Wed, 2011-04-13 at 19:49 +0200, François Romieu wrote:
> On Tue, Apr 12, 2011 at 03:47:45PM -0700, Jay Vosburgh wrote:
> > Jonathan Thibault <jonathan@navigue.com> wrote:
> [2.6.32.old]
> > That's a fairly old kernel; one relatively recent fix that comes
> > to mind is:
>
> The r8169 driver has undergone some multicast fixes since 2.6.32 as well.
>
> If I remember correctly, the old 8169 - not the 8168 - was hit.
>
> Upgrading is really suggested.
If you mean the changes to register writes (commits
78f1cd02457252e1ffbc6caa44a17424a45286b8 and
908ba2bfd22253f26fa910cd855e4ccffb1467d0), those went into 2.6.32.y.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCHv4 NEXT 1/1] net: ethtool support to configure number of channels
From: David Miller @ 2011-04-13 18:31 UTC (permalink / raw)
To: bhutchings
Cc: amit.salecha, netdev, ameen.rahman, sucheta.chakraborty,
anirban.chakraborty
In-Reply-To: <1302718921.2873.1.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 13 Apr 2011 19:22:01 +0100
> On Thu, 2011-04-07 at 04:58 -0700, Amit Kumar Salecha wrote:
>> Ethtool support to configure RX, TX and other channels. combined field
>> in struct ethtool_channels to reflect set of channel (RX, TX or other).
>> Other channel can be link interrupts, SR-IOV coordination etc.
>>
>> ETHTOOL_GCHANNELS will report max and current number of RX channels,
>> max and current number of TX channels, max and current number of other channel
>> or max and current number of combined channel.
>>
>> Number of channel can be modify upto max number of channel through
>> ETHTOOL_SCHANNELS command.
>>
>> Ben Hutchings:
>> o define 'combined' and 'other' types. Most multiqueue drivers pair up RX and TX
>> queues so that most channels combine RX and TX work.
>> o Please could you use a kernel-doc comment to describe the structure.
>>
>> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net: can: mscan: fix build breakage in mpc5xxx_can
From: David Miller @ 2011-04-13 18:33 UTC (permalink / raw)
To: mkl; +Cc: agust, netdev, grant.likely
In-Reply-To: <4DA57F55.7080304@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 13 Apr 2011 12:47:49 +0200
> On 04/13/2011 11:49 AM, Anatolij Gustschin wrote:
>> Commit 74888760d40b3ac9054f9c5fa07b566c0676ba2d
>> "dt/net: Eliminate users of of_platform_{,un}register_driver"
>> broke building mscan driver. Fix it.
>>
>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
I'll apply this to net-2.6, thanks everyone.
^ permalink raw reply
* Re: [Bugme-new] [Bug 32832] New: shutdown(2) does not fully shut down socket any more
From: Stephen Hemminger @ 2011-04-13 18:47 UTC (permalink / raw)
To: David Miller
Cc: dbaluta, eric.dumazet, akpm, netdev, bugzilla-daemon,
bugme-daemon, kees
In-Reply-To: <20110413.104317.71110417.davem@davemloft.net>
On Wed, 13 Apr 2011 10:43:17 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Daniel Baluta <dbaluta@ixiacom.com>
> Date: Wed, 13 Apr 2011 14:57:18 +0300
>
> > Cyril's use case looks suspect. I don't think that this is a good
> > reason for reverting this commit.
>
> I complete disagree.
>
> Something that worked perfectly fine, probably for years, we broke.
>
> We simply cannot do that, especially since we do not have a reasonable
> alternative at this time.
>
> Adding SO_REUSEPORT is a long range option, and not something that
> will provide a fix for users right now.
>
> So please don't even pretend to suggest that we shouldn't fix this
> with a revert unless a simple, obvious, kernel fix presents itself.
Just to echo what Dave said.
Even though the semantics of this is not documented in some standard,
applications have been built on Linux expecting a certain behavior.
If you want to change what happens in this case, you have to have a
really good reason (like crash, security hole, or standards violation).
^ permalink raw reply
* [PATCH] net: allow shifted access in smsc911x V2
From: mathieu.poirier @ 2011-04-13 18:50 UTC (permalink / raw)
To: netdev, mathieu.poirier; +Cc: lee.jones, patches, rubini, linus.walleij
From: Mathieu J. Poirier <mathieu.poirier@linaro.org>
This is a revised patch that permits a shifted access to the
LAN9221 registers. More specifically:
It adds a shift parameter in the platform_data.
It introduces an ops in smsc911x_data.
A choice of access function to use at run-time.
Four new shifted access function.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
---
drivers/net/smsc911x.c | 156 +++++++++++++++++++++++++++++++++++++++++++--
include/linux/smsc911x.h | 1 +
2 files changed, 150 insertions(+), 7 deletions(-)
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index d70bde9..2d65fa4 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -69,6 +69,17 @@ static int debug = 3;
module_param(debug, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+struct smsc911x_data;
+
+struct smsc911x_ops {
+ u32 (*reg_read)(struct smsc911x_data *pdata, u32 reg);
+ void (*reg_write)(struct smsc911x_data *pdata, u32 reg, u32 val);
+ void (*rx_readfifo)(struct smsc911x_data *pdata,
+ unsigned int *buf, unsigned int wordcount);
+ void (*tx_writefifo)(struct smsc911x_data *pdata,
+ unsigned int *buf, unsigned int wordcount);
+};
+
struct smsc911x_data {
void __iomem *ioaddr;
@@ -116,8 +127,14 @@ struct smsc911x_data {
unsigned int clear_bits_mask;
unsigned int hashhi;
unsigned int hashlo;
+
+ /* register access functions */
+ const struct smsc911x_ops *ops;
};
+/* Easy access to information */
+#define __smsc_shift(pdata, reg) ((reg) << ((pdata)->config.shift))
+
static inline u32 __smsc911x_reg_read(struct smsc911x_data *pdata, u32 reg)
{
if (pdata->config.flags & SMSC911X_USE_32BIT)
@@ -131,13 +148,29 @@ static inline u32 __smsc911x_reg_read(struct smsc911x_data *pdata, u32 reg)
return 0;
}
+static inline u32
+__smsc911x_reg_read_shift(struct smsc911x_data *pdata, u32 reg)
+{
+ if (pdata->config.flags & SMSC911X_USE_32BIT)
+ return readl(pdata->ioaddr + __smsc_shift(pdata, reg));
+
+ if (pdata->config.flags & SMSC911X_USE_16BIT)
+ return (readw(pdata->ioaddr +
+ __smsc_shift(pdata, reg)) & 0xFFFF) |
+ ((readw(pdata->ioaddr +
+ __smsc_shift(pdata, reg + 2)) & 0xFFFF) << 16);
+
+ BUG();
+ return 0;
+}
+
static inline u32 smsc911x_reg_read(struct smsc911x_data *pdata, u32 reg)
{
u32 data;
unsigned long flags;
spin_lock_irqsave(&pdata->dev_lock, flags);
- data = __smsc911x_reg_read(pdata, reg);
+ data = pdata->ops->reg_read(pdata, reg);
spin_unlock_irqrestore(&pdata->dev_lock, flags);
return data;
@@ -160,13 +193,32 @@ static inline void __smsc911x_reg_write(struct smsc911x_data *pdata, u32 reg,
BUG();
}
+static inline void
+__smsc911x_reg_write_shift(struct smsc911x_data *pdata, u32 reg, u32 val)
+{
+ if (pdata->config.flags & SMSC911X_USE_32BIT) {
+ writel(val, pdata->ioaddr + __smsc_shift(pdata, reg));
+ return;
+ }
+
+ if (pdata->config.flags & SMSC911X_USE_16BIT) {
+ writew(val & 0xFFFF,
+ pdata->ioaddr + __smsc_shift(pdata, reg));
+ writew((val >> 16) & 0xFFFF,
+ pdata->ioaddr + __smsc_shift(pdata, reg + 2));
+ return;
+ }
+
+ BUG();
+}
+
static inline void smsc911x_reg_write(struct smsc911x_data *pdata, u32 reg,
u32 val)
{
unsigned long flags;
spin_lock_irqsave(&pdata->dev_lock, flags);
- __smsc911x_reg_write(pdata, reg, val);
+ pdata->ops->reg_write(pdata, reg, val);
spin_unlock_irqrestore(&pdata->dev_lock, flags);
}
@@ -202,6 +254,40 @@ out:
spin_unlock_irqrestore(&pdata->dev_lock, flags);
}
+/* Writes a packet to the TX_DATA_FIFO - shifted version */
+static inline void
+smsc911x_tx_writefifo_shift(struct smsc911x_data *pdata, unsigned int *buf,
+ unsigned int wordcount)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pdata->dev_lock, flags);
+
+ if (pdata->config.flags & SMSC911X_SWAP_FIFO) {
+ while (wordcount--)
+ __smsc911x_reg_write_shift(pdata, TX_DATA_FIFO,
+ swab32(*buf++));
+ goto out;
+ }
+
+ if (pdata->config.flags & SMSC911X_USE_32BIT) {
+ writesl(pdata->ioaddr + __smsc_shift(pdata,
+ TX_DATA_FIFO), buf, wordcount);
+ goto out;
+ }
+
+ if (pdata->config.flags & SMSC911X_USE_16BIT) {
+ while (wordcount--)
+ __smsc911x_reg_write_shift(pdata,
+ TX_DATA_FIFO, *buf++);
+ goto out;
+ }
+
+ BUG();
+out:
+ spin_unlock_irqrestore(&pdata->dev_lock, flags);
+}
+
/* Reads a packet out of the RX_DATA_FIFO */
static inline void
smsc911x_rx_readfifo(struct smsc911x_data *pdata, unsigned int *buf,
@@ -234,6 +320,40 @@ out:
spin_unlock_irqrestore(&pdata->dev_lock, flags);
}
+/* Reads a packet out of the RX_DATA_FIFO - shifted version */
+static inline void
+smsc911x_rx_readfifo_shift(struct smsc911x_data *pdata, unsigned int *buf,
+ unsigned int wordcount)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pdata->dev_lock, flags);
+
+ if (pdata->config.flags & SMSC911X_SWAP_FIFO) {
+ while (wordcount--)
+ *buf++ = swab32(__smsc911x_reg_read_shift(pdata,
+ RX_DATA_FIFO));
+ goto out;
+ }
+
+ if (pdata->config.flags & SMSC911X_USE_32BIT) {
+ readsl(pdata->ioaddr + __smsc_shift(pdata,
+ RX_DATA_FIFO), buf, wordcount);
+ goto out;
+ }
+
+ if (pdata->config.flags & SMSC911X_USE_16BIT) {
+ while (wordcount--)
+ *buf++ = __smsc911x_reg_read_shift(pdata,
+ RX_DATA_FIFO);
+ goto out;
+ }
+
+ BUG();
+out:
+ spin_unlock_irqrestore(&pdata->dev_lock, flags);
+}
+
/* waits for MAC not busy, with timeout. Only called by smsc911x_mac_read
* and smsc911x_mac_write, so assumes mac_lock is held */
static int smsc911x_mac_complete(struct smsc911x_data *pdata)
@@ -499,7 +619,7 @@ static int smsc911x_phy_check_loopbackpkt(struct smsc911x_data *pdata)
wrsz += (u32)((ulong)pdata->loopback_tx_pkt & 0x3);
wrsz >>= 2;
- smsc911x_tx_writefifo(pdata, (unsigned int *)bufp, wrsz);
+ pdata->ops->tx_writefifo(pdata, (unsigned int *)bufp, wrsz);
/* Wait till transmit is done */
i = 60;
@@ -543,7 +663,7 @@ static int smsc911x_phy_check_loopbackpkt(struct smsc911x_data *pdata)
rdsz += (u32)((ulong)pdata->loopback_rx_pkt & 0x3);
rdsz >>= 2;
- smsc911x_rx_readfifo(pdata, (unsigned int *)bufp, rdsz);
+ pdata->ops->rx_readfifo(pdata, (unsigned int *)bufp, rdsz);
if (pktlength != (MIN_PACKET_SIZE + 4)) {
SMSC_WARNING(HW, "Unexpected packet size "
@@ -1046,8 +1166,8 @@ static int smsc911x_poll(struct napi_struct *napi, int budget)
/* Align IP on 16B boundary */
skb_reserve(skb, NET_IP_ALIGN);
skb_put(skb, pktlength - 4);
- smsc911x_rx_readfifo(pdata, (unsigned int *)skb->head,
- pktwords);
+ pdata->ops->rx_readfifo(pdata,
+ (unsigned int *)skb->head, pktwords);
skb->protocol = eth_type_trans(skb, dev);
skb_checksum_none_assert(skb);
netif_receive_skb(skb);
@@ -1350,7 +1470,7 @@ static int smsc911x_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
wrsz += (u32)((ulong)skb->data & 0x3);
wrsz >>= 2;
- smsc911x_tx_writefifo(pdata, (unsigned int *)bufp, wrsz);
+ pdata->ops->tx_writefifo(pdata, (unsigned int *)bufp, wrsz);
freespace -= (skb->len + 32);
dev_kfree_skb(skb);
@@ -1951,6 +2071,22 @@ static int __devexit smsc911x_drv_remove(struct platform_device *pdev)
return 0;
}
+/* standard register acces */
+static const struct smsc911x_ops standard_smsc911x_ops = {
+ .reg_read = __smsc911x_reg_read,
+ .reg_write = __smsc911x_reg_write,
+ .rx_readfifo = smsc911x_rx_readfifo,
+ .tx_writefifo = smsc911x_tx_writefifo,
+};
+
+/* shifted register access */
+static const struct smsc911x_ops shifted_smsc911x_ops = {
+ .reg_read = __smsc911x_reg_read_shift,
+ .reg_write = __smsc911x_reg_write_shift,
+ .rx_readfifo = smsc911x_rx_readfifo_shift,
+ .tx_writefifo = smsc911x_tx_writefifo_shift,
+};
+
static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
{
struct net_device *dev;
@@ -2023,6 +2159,12 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
goto out_free_netdev_2;
}
+ /* assume standard, non-shifted, access to HW registers */
+ pdata->ops = &standard_smsc911x_ops;
+ /* apply the right access if shifting is needed */
+ if (config->shift)
+ pdata->ops = &shifted_smsc911x_ops;
+
retval = smsc911x_init(dev);
if (retval < 0)
goto out_unmap_io_3;
diff --git a/include/linux/smsc911x.h b/include/linux/smsc911x.h
index 7144e8a..4dde70e 100644
--- a/include/linux/smsc911x.h
+++ b/include/linux/smsc911x.h
@@ -29,6 +29,7 @@ struct smsc911x_platform_config {
unsigned int irq_polarity;
unsigned int irq_type;
unsigned int flags;
+ unsigned int shift;
phy_interface_t phy_interface;
unsigned char mac[6];
};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] macb: Add rx overrun counter
From: David Miller @ 2011-04-13 18:50 UTC (permalink / raw)
To: alexander.stein; +Cc: nicolas.ferre, netdev
In-Reply-To: <1302707004-15818-1-git-send-email-alexander.stein@systec-electronic.com>
From: Alexander Stein <alexander.stein@systec-electronic.com>
Date: Wed, 13 Apr 2011 17:03:24 +0200
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Applied.
^ permalink raw reply
* Re: [PATCH] stmmac: review Wol and enable the Unicast support
From: David Miller @ 2011-04-13 18:51 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1302679635-7035-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 13 Apr 2011 09:27:15 +0200
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox