* Re: Apple Thunderbolt Ethernet device support
From: Greg KH @ 2012-07-12 23:23 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <20120712231834.GA26823@kroah.com>
On Thu, Jul 12, 2012 at 04:18:34PM -0700, Greg KH wrote:
> On Thu, Jul 12, 2012 at 04:11:37PM -0700, Rick Jones wrote:
> > On 07/12/2012 01:57 PM, Greg KH wrote:
> > >On Thu, Jul 12, 2012 at 01:21:31PM -0700, Greg KH wrote:
> > >>I have an Apple Thunderbolt Ethernet device here, and running 3.5-rc6 it
> > >>isn't detected. It has PCI id 14e4:1682, which seems like it should be
> > >>supported by the tg3 driver. Any hints?
> > >>
> > >>I guess I could just go and add the device id to the driver and see what
> > >>happens...
> > >And that worked, patch sent.
> > >
> > >But, as the patch shows, odds are it has a "real" device type in it,
> > >so the #define I used isn't as descriptive as it should be. Any hints
> > >on how I can figure out what to look at to make it more "correct"?
> >
> > a long-shot, but maybe there is something in the pci.ids database?
>
> Ah, nice, there is something there:
> 1682 NetXtreme BCM57762 Gigabit Ethernet PCIe
>
> I'll redo the patch with that information, thanks.
Wait, something's a bit "odd" here. We already have:
#define TG3PCI_DEVICE_TIGON3_57762 0x1682
in drivers/net/ethernet/broadcom/tg3.h
But it's only used in the function where we can't figure out what type
of vpd we have in tg3_read_vpd(). One could ask how that codepath
was ever tested, as that device id was not in the MODULE_DEVICE_TABLE();
I wonder if someone reused the device id?
Anyway, I'll respin the patch...
greg k-h
^ permalink raw reply
* Re: Apple Thunderbolt Ethernet device support
From: Greg KH @ 2012-07-12 23:18 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4FFF59A9.4010009@hp.com>
On Thu, Jul 12, 2012 at 04:11:37PM -0700, Rick Jones wrote:
> On 07/12/2012 01:57 PM, Greg KH wrote:
> >On Thu, Jul 12, 2012 at 01:21:31PM -0700, Greg KH wrote:
> >>I have an Apple Thunderbolt Ethernet device here, and running 3.5-rc6 it
> >>isn't detected. It has PCI id 14e4:1682, which seems like it should be
> >>supported by the tg3 driver. Any hints?
> >>
> >>I guess I could just go and add the device id to the driver and see what
> >>happens...
> >And that worked, patch sent.
> >
> >But, as the patch shows, odds are it has a "real" device type in it,
> >so the #define I used isn't as descriptive as it should be. Any hints
> >on how I can figure out what to look at to make it more "correct"?
>
> a long-shot, but maybe there is something in the pci.ids database?
Ah, nice, there is something there:
1682 NetXtreme BCM57762 Gigabit Ethernet PCIe
I'll redo the patch with that information, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 4/4] asix: Add a new driver for the AX88172A
From: Grant Grundler @ 2012-07-12 23:10 UTC (permalink / raw)
To: Christian Riesch
Cc: netdev, Oliver Neukum, Eric Dumazet, Allan Chou, Mark Lord,
Ming Lei, Michael Riesch
In-Reply-To: <CABkLObpRNpcEjFYaUUEjnEWN-8snQZaa27+CCO7pHnR7kPVMUg@mail.gmail.com>
On Thu, Jul 12, 2012 at 12:22 AM, Christian Riesch
<christian.riesch@omicron.at> wrote:
> Hi Grant,
...
> After rethinking it I decided to keep the switch structure, but use
> defines for the different modes and the bitmask. I think this will be
> easier to understand. I will submit a new version of the patchset
> later today, please have a look at it.
That's fine too. I agree the new version is easier to read.
thanks!
grant
> Thanks!
> Christian
^ permalink raw reply
* Re: [PATCH iproute2] Ability to compile iproute2 as shared library
From: Ben Hutchings @ 2012-07-12 22:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: hamid jafarian, netdev
In-Reply-To: <20120712090330.38dd5b37@nehalam.linuxnetplumber.net>
On Thu, 2012-07-12 at 09:03 -0700, Stephen Hemminger wrote:
> On Thu, 12 Jul 2012 16:14:54 +0430
> hamid jafarian <hamid.jafarian@pdnsoft.com> wrote:
>
> > Hi,
> >
> > This is a try with minimum changes to compile iproute2 as shared
> > library.
> > Some functions would be used when we compile iproute2 as
> > shared library has been defined in "ip.c".
> > Also NICs caching strategy has been changed because, when we use
> > "libiproute2.so", system NIC list may change, so we should
> > re-cache all NICs at each call to NIC manipulation functions.
> > Also some call of "exit(*)" changed to "return *".
> > HOWTO Make: # export LIBIPROUTE2_SO=y; make
> >
> > in attached files there is a simple wrapper to work with
> > libiproute2.so ...
> >
>
> Thank you for the contribution. I can see how this could be useful
> in some limited embedded applications, but at this moment it doesn't
> seem to be generally worth adding to the upstream code.
>
> The patch does contain some cleanup bits for where the existing
> code is not freeing stuff. This should be fixed, independent of
> whether library support is added, because it would remove the number
> of leaks reported when testing under valgrind. Could you resubmit
> that part please.
Compiling as a shared library would also mean commiting to managing the
ABI (i.e. bump the soversion every time you make an incompatible change,
and then try to avoid such changes too often).
Ben.
--
Ben Hutchings, Staff 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: [PATCH net-next 7/7] be2net: Enable RSS UDP hashing for Lancer and Skyhawk
From: Ben Hutchings @ 2012-07-12 22:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Padmanabh Ratnakar, netdev
In-Reply-To: <1342102215.3265.8263.camel@edumazet-glaptop>
On Thu, 2012-07-12 at 16:10 +0200, Eric Dumazet wrote:
> On Thu, 2012-07-12 at 19:27 +0530, Padmanabh Ratnakar wrote:
> > Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
> > ---
> > drivers/net/ethernet/emulex/benet/be.h | 3 +++
> > drivers/net/ethernet/emulex/benet/be_cmds.c | 7 +++++++
> > drivers/net/ethernet/emulex/benet/be_cmds.h | 2 ++
> > 3 files changed, 12 insertions(+), 0 deletions(-)
>
> It would be nice to add a bit of documentation on this, and what
> components are used from the tuple (dst addr, src addr, dst port, src
> port)
That's what ETHTOOL_GRXFH is for.
Ben.
--
Ben Hutchings, Staff 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: resurrecting tcphealth
From: Randy Dunlap @ 2012-07-12 22:29 UTC (permalink / raw)
To: Piotr Sawuk; +Cc: netdev, linux-kernel
In-Reply-To: <dee325378a2d3b7792da9640fc14905f.squirrel@webmail.univie.ac.at>
On 07/12/2012 01:55 PM, Piotr Sawuk wrote:
> hello! I haven't done any kernel-hacking before, so be patient.
>
> I got as far as to make tcphealth run, but now I need some help:
> how does read-locking work in the tcp_sock struct?
> the original code (for 2.5.1) made a read_lock(&head->lock) with
> struct tcp_ehash_bucket *head = &tcp_ehash[i];
> at the beginning of the for-loop over all sk=head->chain.
> i.e.
> for (i=0; i < tcp_ehash_size; i++) {
> struct tcp_ehash_bucket *head = &tcp_ehash[i];
> struct sock *sk;
> struct tcp_opt *tp;
>
> read_lock(&head->lock);
> for (sk=head->chain; sk; sk=sk->next) {
> if (!TCP_INET_FAMILY(sk->family))
> continue;
>
> and in the new kernel this construction has been replaced by
>
> if (st->state==TCP_SEQ_STATE_ESTABLISHED)
> ...
> static struct tcp_seq_afinfo tcphealth_seq_afinfo
> ...
>
> and the example with proc/net/tcp is seemingly not locking anything. do I
> actually need a read-lock for diagnostic data from tcp_sock? why did the
> original author need to lock the whole chain of tcp_sock?
>
> here's my patch against 3.4.4 so far, any further comments welcome:
Along with what Mr. Hemminger said:
Don't make patches to a stable kernel version. Just make them
to mainline (e.g., 3.5-rc6).
More comments below.
>
> diff -rub linux-3.4.4/include/linux/tcp.h
> linux-3.4.4-heal-lsm/include/linux/tcp.h
> --- linux-3.4.4/include/linux/tcp.h 2012-06-22 20:37:50.000000000 +0200
> +++ linux-3.4.4-heal-lsm/include/linux/tcp.h 2012-07-06 10:23:13.000000000
> +0200
See the 2 lines above. They should be all on one line (the +0200 is
on a separate line). Something along the way split this long line for
you, but this is bad. It corrupts the patch.
> @@ -472,6 +474,15 @@
> * contains related tcp_cookie_transactions fields.
> */
> struct tcp_cookie_values *cookie_values;
> +
> + /*
> + * TCP health monitoring counters.
> + */
> + __u32 dup_acks_sent;
> + __u32 dup_pkts_recv;
> + __u32 acks_sent;
> + __u32 pkts_recv;
> + __u32 last_ack_sent; /* Sequence number of the last ack we sent.
Extra tab before __u32 above.
*/
> };
>
> static inline struct tcp_sock *tcp_sk(const struct sock *sk)
> diff -rub linux-3.4.4/net/ipv4/tcp_input.c
> linux-3.4.4-heal-lsm/net/ipv4/tcp_input.c
> --- linux-3.4.4/net/ipv4/tcp_input.c 2012-06-22 20:37:50.000000000 +0200
> +++ linux-3.4.4-heal-lsm/net/ipv4/tcp_input.c 2012-07-06
> 10:12:12.000000000 +0200
Bad line(s) above.
> @@ -5375,6 +5382,14 @@
>
> tp->rx_opt.saw_tstamp = 0;
>
> + /*
> + * Tcp health monitoring is interested in
> + * total per-connection packet arrivals.
> + * This is in the fast path, but is quick.
> + */
> +
The */
is enough white space; don't add an extra line.
> + tp->pkts_recv++;
> +
> /* pred_flags is 0xS?10 << 16 + snd_wnd
> * if header_prediction is to be made
> * 'S' will always be tp->tcp_header_len >> 2
> diff -rub linux-3.4.4/net/ipv4/tcp_ipv4.c
> linux-3.4.4-heal-lsm/net/ipv4/tcp_ipv4.c
> --- linux-3.4.4/net/ipv4/tcp_ipv4.c 2012-06-22 20:37:50.000000000 +0200
> +++ linux-3.4.4-heal-lsm/net/ipv4/tcp_ipv4.c 2012-07-11 09:34:22.000000000
> +0200
> @@ -2533,6 +2533,82 @@
> return 0;
> }
>
> +
> +/*
> + * Output /proc/net/tcphealth
> + */
> +#define LINESZ 128
> +
> +int tcp_health_seq_show(struct seq_file *seq, void *v)
> +{
> + int len, num;
> + char srcIP[32], destIP[32];
Use tab above for indentation (don't use spaces).
> +
> + unsigned long SmoothedRttEstimate,
> + AcksSent, DupAcksSent, PktsRecv, DupPktsRecv;
> + struct tcp_iter_state *st;
> +
> + if (v == SEQ_START_TOKEN) {
> + seq_printf(seq,
> + "TCP Health Monitoring (established connections only)\n"
> + " -Duplicate ACKs indicate lost or reordered packets on the connection.\n"
> + " -Duplicate Packets Received signal a slow and badly inefficient
> connection.\n"
> + " -RttEst estimates how long future packets will take on a round trip
> over the connection.\n"
> + "id Local Address Remote Address RttEst(ms) AcksSent "
> + "DupAcksSent PktsRecv DupPktsRecv\n");
> + goto out;
> + }
> +
> + /* Loop through established TCP connections */
> + st = seq->private;
> +
> +
> + if (st->state==TCP_SEQ_STATE_ESTABLISHED)
> + {
Kernel style is:
if (st->state == TCP_SEQ_STATE_ESTABLISHED) {
> +/* ; //insert read-lock here */
> + const struct tcp_sock *tp = tcp_sk(v);
> + const struct inet_sock *inet = inet_sk(v);
> + __be32 dest = inet->inet_daddr;
> + __be32 src = inet->inet_rcv_saddr;
> + __u16 destp = ntohs(inet->inet_dport);
> + __u16 srcp = ntohs(inet->inet_sport);
> +
> + num=st->num;
num = st->num;
> + SmoothedRttEstimate = (tp->srtt >> 3);
> + AcksSent = tp->acks_sent;
> + DupAcksSent = tp->dup_acks_sent;
> + PktsRecv = tp->pkts_recv;
> + DupPktsRecv = tp->dup_pkts_recv;
> +
> + sprintf(srcIP, "%lu.%lu.%lu.%lu:%u",
> + ((src >> 24) & 0xFF), ((src >> 16) & 0xFF), ((src >> 8) & 0xFF), (src
> & 0xFF),
> + srcp);
> + sprintf(destIP, "%3d.%3d.%3d.%3d:%u",
> + ((dest >> 24) & 0xFF), ((dest >> 16) & 0xFF), ((dest >> 8) & 0xFF),
> (dest & 0xFF),
> + destp);
> +
> + seq_printf(seq, "%d: %-21s %-21s "
> + "%8lu %8lu %8lu %8lu %8lu%n",
> + num,
> + srcIP,
> + destIP,
> + SmoothedRttEstimate,
> + AcksSent,
> + DupAcksSent,
> + PktsRecv,
> + DupPktsRecv,
> +
> + &len
> + );
> +
> + seq_printf(seq, "%*s\n", LINESZ - 1 - len, "");
> +/* ; //insert read-unlock here */
> + }
> +
> +out:
> + return 0;
> +}
> +
> static const struct file_operations tcp_afinfo_seq_fops = {
> .owner = THIS_MODULE,
> .open = tcp_seq_open,
> @@ -2541,6 +2617,15 @@
> .release = seq_release_net
> };
>
> +static struct tcp_seq_afinfo tcphealth_seq_afinfo = {
> + .name = "tcphealth",
> + .family = AF_INET,
> + .seq_fops = &tcp_afinfo_seq_fops,
> + .seq_ops = {
> + .show = tcp_health_seq_show,
> + },
> +};
> +
> static struct tcp_seq_afinfo tcp4_seq_afinfo = {
> .name = "tcp",
> .family = AF_INET,
> @@ -2552,12 +2637,15 @@
>
> static int __net_init tcp4_proc_init_net(struct net *net)
> {
> - return tcp_proc_register(net, &tcp4_seq_afinfo);
> + int ret=tcp_proc_register(net, &tcp4_seq_afinfo);
int ret = tcp_proc_register(...);
> + if(ret==0) ret=tcp_proc_register(net, &tcphealth_seq_afinfo);
if (ret == 0)
ret = tcp_proc_register(...);
> + return ret;
> }
>
> static void __net_exit tcp4_proc_exit_net(struct net *net)
> {
> tcp_proc_unregister(net, &tcp4_seq_afinfo);
> + tcp_proc_unregister(net, &tcphealth_seq_afinfo);
> }
>
> static struct pernet_operations tcp4_net_ops = {
> diff -rub linux-3.4.4/net/ipv4/tcp_output.c
> linux-3.4.4-heal-lsm/net/ipv4/tcp_output.c
> --- linux-3.4.4/net/ipv4/tcp_output.c 2012-06-22 20:37:50.000000000 +0200
> +++ linux-3.4.4-heal-lsm/net/ipv4/tcp_output.c 2012-07-06
> 17:15:14.000000000 +0200
Bad split lines above.
> @@ -2754,8 +2755,15 @@
> skb_reserve(buff, MAX_TCP_HEADER);
> tcp_init_nondata_skb(buff, tcp_acceptable_seq(sk), TCPHDR_ACK);
>
> + /* If the rcv_nxt has not advanced since sending our last ACK, this is
> a duplicate. */
> + if (tcp_sk(sk)->rcv_nxt == tcp_sk(sk)->last_ack_sent)
> + tcp_sk(sk)->dup_acks_sent++;
> + /* Record the total number of acks sent on this connection. */
> + tcp_sk(sk)->acks_sent++;
> +
> /* Send it off, this clears delayed acks for us. */
> TCP_SKB_CB(buff)->when = tcp_time_stamp;
> + tcp_sk(sk)->last_ack_sent = tcp_sk(sk)->rcv_nxt;
Extra tab indentation above.
> tcp_transmit_skb(sk, buff, 0, GFP_ATOMIC);
> }
>
>
> --
--
~Randy
^ permalink raw reply
* Re: [PATCH net-next] r8169: Remove rtl_ocpdr_cond
From: Francois Romieu @ 2012-07-12 22:14 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <20120711220045.GA8913@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
[...]
> I'll try again tomorrow evening.
W/o firmware does not seem to make a difference.
# ping -qf -l 4 -s 81 -c 60 10.0.3.1
PING 10.0.3.1 (10.0.3.1) 81(109) bytes of data.
--- 10.0.3.1 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 153ms
rtt min/avg/max/mdev = 0.047/0.064/0.117/0.016 ms, pipe 4, ipg/ewma 2.607/0.058 ms
# ping -qf -l 4 -s 82 -c 60 10.0.3.1
PING 10.0.3.1 (10.0.3.1) 82(110) bytes of data.
--- 10.0.3.1 ping statistics ---
60 packets transmitted, 60 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 0.195/0.210/0.281/0.018 ms, pipe 4, ipg/ewma 0.057/0.205 ms
It would translate into a 127/128 cutoff after inclusion of the FCS.
Any idea ?
--
Ueimor
^ permalink raw reply
* Re: resurrecting tcphealth
From: Stephen Hemminger @ 2012-07-12 21:35 UTC (permalink / raw)
To: Piotr Sawuk; +Cc: netdev, linux-kernel
In-Reply-To: <dee325378a2d3b7792da9640fc14905f.squirrel@webmail.univie.ac.at>
On Thu, 12 Jul 2012 22:55:57 +0200
"Piotr Sawuk" <a9702387@unet.univie.ac.at> wrote:
> diff -rub linux-3.4.4/net/ipv4/tcp_input.c
> linux-3.4.4-heal-lsm/net/ipv4/tcp_input.c
> --- linux-3.4.4/net/ipv4/tcp_input.c 2012-06-22 20:37:50.000000000 +0200
> +++ linux-3.4.4-heal-lsm/net/ipv4/tcp_input.c 2012-07-06
> 10:12:12.000000000 +0200
> @@ -59,7 +59,8 @@
> * Panu Kuhlberg: Experimental audit of TCP (re)transmission
> * engine. Lots of bugs are found.
> * Pasi Sarolahti: F-RTO for dealing with spurious RTOs
> - */
> + * Federico D. Sacerdoti: Added TCP health monitoring.
Please don't do this.
The kernel community no longer maintains a list of contributors
in the comments. The history is maintained in the git commit log.
^ permalink raw reply
* RE: [PATCH 02/11] enic: remove unnecessary setting of skb->dev
From: Christian Benvenuti (benve) @ 2012-07-12 21:23 UTC (permalink / raw)
To: Jon Mason, David S. Miller
Cc: netdev@vger.kernel.org, Neel Patel (neepatel),
Nishank Trivedi (nistrive)
In-Reply-To: <CAPoiz9y2D15o4ueTCWPQHiNHexBVXSABO_1ghpKtYCruSDV-Ew@mail.gmail.com>
Jon,
Roopa is not in the maintainer list anymore.
Sorry about that.
We will update MAINTAINERS.
BTW, the change in enic_main.c looks good.
/Chris
> -----Original Message-----
> From: Jon Mason [mailto:jdmason@kudzu.us]
> Sent: Thursday, July 12, 2012 2:19 PM
> To: David S. Miller
> Cc: netdev@vger.kernel.org; Christian Benvenuti (benve); Neel Patel (neepatel); Nishank Trivedi
> (nistrive)
> Subject: Re: [PATCH 02/11] enic: remove unnecessary setting of skb->dev
>
> On Mon, Jul 9, 2012 at 5:09 PM, Jon Mason <jdmason@kudzu.us> wrote:
> > skb->dev is being unnecessarily set after calling eth_type_trans.
> > eth_type_trans already sets skb->dev to the proper value, thus making this
> > unnecessary.
> >
> > Signed-off-by: Jon Mason <jdmason@kudzu.us>
> > Cc: Christian Benvenuti <benve@cisco.com>
> > Cc: Roopa Prabhu <roprabhu@cisco.com>
>
> This address bounced. Anyone know of an updated address for Roopa or
> should they be removed from the MAINTAINERS list?
>
> > Cc: Neel Patel <neepatel@cisco.com>
> > Cc: Nishank Trivedi <nistrive@cisco.com>
> > ---
> > drivers/net/ethernet/cisco/enic/enic_main.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c
> b/drivers/net/ethernet/cisco/enic/enic_main.c
> > index 8132c78..ad1468b 100644
> > --- a/drivers/net/ethernet/cisco/enic/enic_main.c
> > +++ b/drivers/net/ethernet/cisco/enic/enic_main.c
> > @@ -1300,8 +1300,6 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
> > skb->ip_summed = CHECKSUM_COMPLETE;
> > }
> >
> > - skb->dev = netdev;
> > -
> > if (vlan_stripped)
> > __vlan_hwaccel_put_tag(skb, vlan_tci);
> >
> > --
> > 1.7.9.5
> >
^ permalink raw reply
* Re: [PATCH 02/11] enic: remove unnecessary setting of skb->dev
From: Jon Mason @ 2012-07-12 21:19 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Christian Benvenuti, Neel Patel, Nishank Trivedi
In-Reply-To: <1341878975-10577-2-git-send-email-jdmason@kudzu.us>
On Mon, Jul 9, 2012 at 5:09 PM, Jon Mason <jdmason@kudzu.us> wrote:
> skb->dev is being unnecessarily set after calling eth_type_trans.
> eth_type_trans already sets skb->dev to the proper value, thus making this
> unnecessary.
>
> Signed-off-by: Jon Mason <jdmason@kudzu.us>
> Cc: Christian Benvenuti <benve@cisco.com>
> Cc: Roopa Prabhu <roprabhu@cisco.com>
This address bounced. Anyone know of an updated address for Roopa or
should they be removed from the MAINTAINERS list?
> Cc: Neel Patel <neepatel@cisco.com>
> Cc: Nishank Trivedi <nistrive@cisco.com>
> ---
> drivers/net/ethernet/cisco/enic/enic_main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
> index 8132c78..ad1468b 100644
> --- a/drivers/net/ethernet/cisco/enic/enic_main.c
> +++ b/drivers/net/ethernet/cisco/enic/enic_main.c
> @@ -1300,8 +1300,6 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
> skb->ip_summed = CHECKSUM_COMPLETE;
> }
>
> - skb->dev = netdev;
> -
> if (vlan_stripped)
> __vlan_hwaccel_put_tag(skb, vlan_tci);
>
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: Apple Thunderbolt Ethernet device support
From: Greg KH @ 2012-07-12 20:57 UTC (permalink / raw)
To: netdev
In-Reply-To: <20120712202131.GA26436@kroah.com>
On Thu, Jul 12, 2012 at 01:21:31PM -0700, Greg KH wrote:
> I have an Apple Thunderbolt Ethernet device here, and running 3.5-rc6 it
> isn't detected. It has PCI id 14e4:1682, which seems like it should be
> supported by the tg3 driver. Any hints?
>
> I guess I could just go and add the device id to the driver and see what
> happens...
And that worked, patch sent.
But, as the patch shows, odds are it has a "real" device type in it,
so the #define I used isn't as descriptive as it should be. Any hints
on how I can figure out what to look at to make it more "correct"?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] tg3: add device id of Apple Thunderbolt Ethernet device
From: Greg KH @ 2012-07-12 20:56 UTC (permalink / raw)
To: netdev
In-Reply-To: <20120712202131.GA26436@kroah.com>
Add a PCI device id for the Apple Thunderbolt Ethernet device
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Note, I'm sure there's a better #define for this device, any way I can
determine what it should really be?
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index e47ff8b..46576f9 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -298,6 +298,7 @@ static DEFINE_PCI_DEVICE_TABLE(tg3_pci_tbl) = {
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57795)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_5719)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_5720)},
+ {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_APPLE)},
{PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_9DXX)},
{PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_9MXX)},
{PCI_DEVICE(PCI_VENDOR_ID_ALTIMA, PCI_DEVICE_ID_ALTIMA_AC1000)},
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index 93865f8..0a2ddff 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -63,6 +63,7 @@
#define TG3PCI_DEVICE_TIGON3_57766 0x1686
#define TG3PCI_DEVICE_TIGON3_57786 0x16b3
#define TG3PCI_DEVICE_TIGON3_57782 0x16b7
+#define TG3PCI_DEVICE_TIGON3_APPLE 0x1682
/* 0x04 --> 0x2c unused */
#define TG3PCI_SUBVENDOR_ID_BROADCOM PCI_VENDOR_ID_BROADCOM
#define TG3PCI_SUBDEVICE_ID_BROADCOM_95700A6 0x1644
^ permalink raw reply related
* resurrecting tcphealth
From: Piotr Sawuk @ 2012-07-12 20:55 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
hello! I haven't done any kernel-hacking before, so be patient.
I got as far as to make tcphealth run, but now I need some help:
how does read-locking work in the tcp_sock struct?
the original code (for 2.5.1) made a read_lock(&head->lock) with
struct tcp_ehash_bucket *head = &tcp_ehash[i];
at the beginning of the for-loop over all sk=head->chain.
i.e.
for (i=0; i < tcp_ehash_size; i++) {
struct tcp_ehash_bucket *head = &tcp_ehash[i];
struct sock *sk;
struct tcp_opt *tp;
read_lock(&head->lock);
for (sk=head->chain; sk; sk=sk->next) {
if (!TCP_INET_FAMILY(sk->family))
continue;
and in the new kernel this construction has been replaced by
if (st->state==TCP_SEQ_STATE_ESTABLISHED)
...
static struct tcp_seq_afinfo tcphealth_seq_afinfo
...
and the example with proc/net/tcp is seemingly not locking anything. do I
actually need a read-lock for diagnostic data from tcp_sock? why did the
original author need to lock the whole chain of tcp_sock?
here's my patch against 3.4.4 so far, any further comments welcome:
diff -rub linux-3.4.4/include/linux/tcp.h
linux-3.4.4-heal-lsm/include/linux/tcp.h
--- linux-3.4.4/include/linux/tcp.h 2012-06-22 20:37:50.000000000 +0200
+++ linux-3.4.4-heal-lsm/include/linux/tcp.h 2012-07-06 10:23:13.000000000
+0200
@@ -7,6 +7,8 @@
*
* Version: @(#)tcp.h 1.0.2 04/28/93
*
+ * Federico D. Sacerdoti : Added TCP health counters.
+ *
* Author: Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
*
* This program is free software; you can redistribute it and/or
@@ -472,6 +474,15 @@
* contains related tcp_cookie_transactions fields.
*/
struct tcp_cookie_values *cookie_values;
+
+ /*
+ * TCP health monitoring counters.
+ */
+ __u32 dup_acks_sent;
+ __u32 dup_pkts_recv;
+ __u32 acks_sent;
+ __u32 pkts_recv;
+ __u32 last_ack_sent; /* Sequence number of the last ack we sent. */
};
static inline struct tcp_sock *tcp_sk(const struct sock *sk)
diff -rub linux-3.4.4/net/ipv4/tcp_input.c
linux-3.4.4-heal-lsm/net/ipv4/tcp_input.c
--- linux-3.4.4/net/ipv4/tcp_input.c 2012-06-22 20:37:50.000000000 +0200
+++ linux-3.4.4-heal-lsm/net/ipv4/tcp_input.c 2012-07-06
10:12:12.000000000 +0200
@@ -59,7 +59,8 @@
* Panu Kuhlberg: Experimental audit of TCP (re)transmission
* engine. Lots of bugs are found.
* Pasi Sarolahti: F-RTO for dealing with spurious RTOs
- */
+ * Federico D. Sacerdoti: Added TCP health monitoring.
+*/
#define pr_fmt(fmt) "TCP: " fmt
@@ -4414,6 +4415,8 @@
}
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
+ /* Course retransmit inefficiency- this packet has been received
twice. */
+ tp->dup_pkts_recv++;
SOCK_DEBUG(sk, "ofo packet was already received\n");
__skb_unlink(skb, &tp->out_of_order_queue);
__kfree_skb(skb);
@@ -4664,6 +4667,10 @@
return;
}
+ /* A packet is a "duplicate" if it contains bytes we have already
received. */
+ if (before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
+ tp->dup_pkts_recv++;
+
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
/* A retransmit, 2nd most common case. Force an immediate ack. */
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_DELAYEDACKLOST);
@@ -5375,6 +5382,14 @@
tp->rx_opt.saw_tstamp = 0;
+ /*
+ * Tcp health monitoring is interested in
+ * total per-connection packet arrivals.
+ * This is in the fast path, but is quick.
+ */
+
+ tp->pkts_recv++;
+
/* pred_flags is 0xS?10 << 16 + snd_wnd
* if header_prediction is to be made
* 'S' will always be tp->tcp_header_len >> 2
diff -rub linux-3.4.4/net/ipv4/tcp_ipv4.c
linux-3.4.4-heal-lsm/net/ipv4/tcp_ipv4.c
--- linux-3.4.4/net/ipv4/tcp_ipv4.c 2012-06-22 20:37:50.000000000 +0200
+++ linux-3.4.4-heal-lsm/net/ipv4/tcp_ipv4.c 2012-07-11 09:34:22.000000000
+0200
@@ -2533,6 +2533,82 @@
return 0;
}
+
+/*
+ * Output /proc/net/tcphealth
+ */
+#define LINESZ 128
+
+int tcp_health_seq_show(struct seq_file *seq, void *v)
+{
+ int len, num;
+ char srcIP[32], destIP[32];
+
+ unsigned long SmoothedRttEstimate,
+ AcksSent, DupAcksSent, PktsRecv, DupPktsRecv;
+ struct tcp_iter_state *st;
+
+ if (v == SEQ_START_TOKEN) {
+ seq_printf(seq,
+ "TCP Health Monitoring (established connections only)\n"
+ " -Duplicate ACKs indicate lost or reordered packets on the connection.\n"
+ " -Duplicate Packets Received signal a slow and badly inefficient
connection.\n"
+ " -RttEst estimates how long future packets will take on a round trip
over the connection.\n"
+ "id Local Address Remote Address RttEst(ms) AcksSent "
+ "DupAcksSent PktsRecv DupPktsRecv\n");
+ goto out;
+ }
+
+ /* Loop through established TCP connections */
+ st = seq->private;
+
+
+ if (st->state==TCP_SEQ_STATE_ESTABLISHED)
+ {
+/* ; //insert read-lock here */
+ const struct tcp_sock *tp = tcp_sk(v);
+ const struct inet_sock *inet = inet_sk(v);
+ __be32 dest = inet->inet_daddr;
+ __be32 src = inet->inet_rcv_saddr;
+ __u16 destp = ntohs(inet->inet_dport);
+ __u16 srcp = ntohs(inet->inet_sport);
+
+ num=st->num;
+ SmoothedRttEstimate = (tp->srtt >> 3);
+ AcksSent = tp->acks_sent;
+ DupAcksSent = tp->dup_acks_sent;
+ PktsRecv = tp->pkts_recv;
+ DupPktsRecv = tp->dup_pkts_recv;
+
+ sprintf(srcIP, "%lu.%lu.%lu.%lu:%u",
+ ((src >> 24) & 0xFF), ((src >> 16) & 0xFF), ((src >> 8) & 0xFF), (src
& 0xFF),
+ srcp);
+ sprintf(destIP, "%3d.%3d.%3d.%3d:%u",
+ ((dest >> 24) & 0xFF), ((dest >> 16) & 0xFF), ((dest >> 8) & 0xFF),
(dest & 0xFF),
+ destp);
+
+ seq_printf(seq, "%d: %-21s %-21s "
+ "%8lu %8lu %8lu %8lu %8lu%n",
+ num,
+ srcIP,
+ destIP,
+ SmoothedRttEstimate,
+ AcksSent,
+ DupAcksSent,
+ PktsRecv,
+ DupPktsRecv,
+
+ &len
+ );
+
+ seq_printf(seq, "%*s\n", LINESZ - 1 - len, "");
+/* ; //insert read-unlock here */
+ }
+
+out:
+ return 0;
+}
+
static const struct file_operations tcp_afinfo_seq_fops = {
.owner = THIS_MODULE,
.open = tcp_seq_open,
@@ -2541,6 +2617,15 @@
.release = seq_release_net
};
+static struct tcp_seq_afinfo tcphealth_seq_afinfo = {
+ .name = "tcphealth",
+ .family = AF_INET,
+ .seq_fops = &tcp_afinfo_seq_fops,
+ .seq_ops = {
+ .show = tcp_health_seq_show,
+ },
+};
+
static struct tcp_seq_afinfo tcp4_seq_afinfo = {
.name = "tcp",
.family = AF_INET,
@@ -2552,12 +2637,15 @@
static int __net_init tcp4_proc_init_net(struct net *net)
{
- return tcp_proc_register(net, &tcp4_seq_afinfo);
+ int ret=tcp_proc_register(net, &tcp4_seq_afinfo);
+ if(ret==0) ret=tcp_proc_register(net, &tcphealth_seq_afinfo);
+ return ret;
}
static void __net_exit tcp4_proc_exit_net(struct net *net)
{
tcp_proc_unregister(net, &tcp4_seq_afinfo);
+ tcp_proc_unregister(net, &tcphealth_seq_afinfo);
}
static struct pernet_operations tcp4_net_ops = {
diff -rub linux-3.4.4/net/ipv4/tcp_output.c
linux-3.4.4-heal-lsm/net/ipv4/tcp_output.c
--- linux-3.4.4/net/ipv4/tcp_output.c 2012-06-22 20:37:50.000000000 +0200
+++ linux-3.4.4-heal-lsm/net/ipv4/tcp_output.c 2012-07-06
17:15:14.000000000 +0200
@@ -31,6 +31,7 @@
* Andrea Arcangeli: SYNACK carry ts_recent in tsecr.
* Cacophonix Gaul : draft-minshall-nagle-01
* J Hadi Salim : ECN support
+ * Federico D. Sacerdoti : Added TCP health monitoring.
*
*/
@@ -2754,8 +2755,15 @@
skb_reserve(buff, MAX_TCP_HEADER);
tcp_init_nondata_skb(buff, tcp_acceptable_seq(sk), TCPHDR_ACK);
+ /* If the rcv_nxt has not advanced since sending our last ACK, this is
a duplicate. */
+ if (tcp_sk(sk)->rcv_nxt == tcp_sk(sk)->last_ack_sent)
+ tcp_sk(sk)->dup_acks_sent++;
+ /* Record the total number of acks sent on this connection. */
+ tcp_sk(sk)->acks_sent++;
+
/* Send it off, this clears delayed acks for us. */
TCP_SKB_CB(buff)->when = tcp_time_stamp;
+ tcp_sk(sk)->last_ack_sent = tcp_sk(sk)->rcv_nxt;
tcp_transmit_skb(sk, buff, 0, GFP_ATOMIC);
}
^ permalink raw reply
* Apple Thunderbolt Ethernet device support
From: Greg KH @ 2012-07-12 20:21 UTC (permalink / raw)
To: netdev
I have an Apple Thunderbolt Ethernet device here, and running 3.5-rc6 it
isn't detected. It has PCI id 14e4:1682, which seems like it should be
supported by the tg3 driver. Any hints?
I guess I could just go and add the device id to the driver and see what
happens...
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC] net:phy:phylib: phy shares the same interrupt with mac
From: Andy Fleming @ 2012-07-12 20:05 UTC (permalink / raw)
To: Jason Lin; +Cc: Florian Fainelli, netdev
In-Reply-To: <CAGCDX1nqBEWbAMNPeUZyf3KdtmhjnVKesV6TXZ-QDtb83R7LBw@mail.gmail.com>
On Tue, Jul 10, 2012 at 8:32 PM, Jason Lin <kernel.jason@gmail.com> wrote:
> Dear :
> I describe my situation again.
> In my hardware design, the interrupt (INT) pin of phy is connected to
> the INT input pin of MAC.
> In other words, one of triggering interrupt condition of MAC is
> related to phy's interrupt.
> So the phy will share the same "IRQ pin" with MAC.
> As described above, the best solution is the INT pin of phy is
> connected to architecture independently.
> But, the hardware architecture cannot modify easily.
> So I think
> 1. We can assign dummy IRQ number (which is a empty IRQ number but
> large than zero) to phy.
> phydev->irq = PHY_DUMMY_IRQ (this value is depend on architecture)
> 2. Change to do the soft IRQ in phy's ISR.
> To schedule workqueue in this soft IRQ.
> In this way, the MAC can schedule phy's soft IRQ to do phy's work
> queue (to do ack phy's interrupt ... etc).
>
> Dose it make sense?
>
If PHY_IGNORE_INTERRUPT doesn't currently work to allow a MAC's driver
to manage PHY interrupts, then we need to fix PHY Lib to support this
correctly. PHY_IGNORE_INTERRUPT was meant for this purpose. We don't
want to start defining interrupt numbers which may conflict with real
numbers, and have to be constantly re-defined by various systems to
avoid that.
Your notion of making the phy_enable_interrupts() and
phy_disable_interrupts() code available to the MAC drivers sounds like
the right approach to me. But you might want to implement your own
version. The biggest problem with PHY interrupts is that masking them
requires an MDIO transaction, which is *slow*. If you can mask the
interrupt by writing a bit in a memory-mapped register, it's far
better to do it that way, at interrupt time, and *then* schedule the
PHY code to be run from a work queue. However, your driver probably
already *does* have a workqueue of some sort. If so, what you should
probably do is implement a new version of phy_change(), that doesn't
have to deal with the weird PHY interrupt masking issues. Something
like this:
mydriver_phy_change(struct mydriver_priv *priv)
{
int err;
struct phy_device *phydev = priv->phydev;
if (phydev->drv->did_interrupt &&
!phydev->drv->did_interrupt(phydev))
goto ignore;
err = phy_disable_interrupts(phydev);
if (err)
goto phy_err;
mutex_lock(&phydev->lock);
if ((PHY_RUNNING == phydev->state) || (PHY_NOLINK == phydev->state))
phydev->state = PHY_CHANGELINK;
mutex_unlock(&phydev->lock);
/* Reenable interrupts */
if (PHY_HALTED != phydev->state)
err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED);
if (err)
goto irq_enable_err;
/* reschedule state queue work to run as soon as possible */
cancel_delayed_work_sync(&phydev->state_queue);
schedule_delayed_work(&phydev->state_queue, 0);
return;
ignore:
return;
irq_enable_err:
phy_err:
phy_error(phydev);
}
Of course, now I re-read your question, and I'm not sure I've
interpreted it correctly. Are you saying your MAC has control of the
PHY interrupt (ie - the interrupt sets a bit in some event register in
your MAC, and you can MASK/ACK it from your driver), or that the PHY
shares the same interrupt pin?
If it's the second one, you don't need to do anything, but allow your
MAC driver to register its interrupt as a shared interrupt, and allow
the PHY to manage its own interrupts, as usual.
Andy
^ permalink raw reply
* [PATCH v2] ipvs: generalize app registration in netns
From: Julian Anastasov @ 2012-07-12 20:06 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Simon Horman, lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Hans Schillstrom, Jesper Dangaard Brouer
In-Reply-To: <20120712162209.GA21904@1984>
Get rid of the ftp_app pointer and allow applications
to be registered without adding fields in the netns_ipvs structure.
v2: fix coding style as suggested by Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
include/net/ip_vs.h | 5 +--
net/netfilter/ipvs/ip_vs_app.c | 58 +++++++++++++++++++++++++++++-----------
net/netfilter/ipvs/ip_vs_ftp.c | 21 +++-----------
3 files changed, 49 insertions(+), 35 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index d6146b4..6cb4699 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -808,8 +808,6 @@ struct netns_ipvs {
struct list_head rs_table[IP_VS_RTAB_SIZE];
/* ip_vs_app */
struct list_head app_list;
- /* ip_vs_ftp */
- struct ip_vs_app *ftp_app;
/* ip_vs_proto */
#define IP_VS_PROTO_TAB_SIZE 32 /* must be power of 2 */
struct ip_vs_proto_data *proto_data_table[IP_VS_PROTO_TAB_SIZE];
@@ -1179,7 +1177,8 @@ extern void ip_vs_service_net_cleanup(struct net *net);
* (from ip_vs_app.c)
*/
#define IP_VS_APP_MAX_PORTS 8
-extern int register_ip_vs_app(struct net *net, struct ip_vs_app *app);
+extern struct ip_vs_app *register_ip_vs_app(struct net *net,
+ struct ip_vs_app *app);
extern void unregister_ip_vs_app(struct net *net, struct ip_vs_app *app);
extern int ip_vs_bind_app(struct ip_vs_conn *cp, struct ip_vs_protocol *pp);
extern void ip_vs_unbind_app(struct ip_vs_conn *cp);
diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
index 64f9e8f..9713e6e 100644
--- a/net/netfilter/ipvs/ip_vs_app.c
+++ b/net/netfilter/ipvs/ip_vs_app.c
@@ -180,22 +180,38 @@ register_ip_vs_app_inc(struct net *net, struct ip_vs_app *app, __u16 proto,
}
-/*
- * ip_vs_app registration routine
- */
-int register_ip_vs_app(struct net *net, struct ip_vs_app *app)
+/* Register application for netns */
+struct ip_vs_app *register_ip_vs_app(struct net *net, struct ip_vs_app *app)
{
struct netns_ipvs *ipvs = net_ipvs(net);
- /* increase the module use count */
- ip_vs_use_count_inc();
+ struct ip_vs_app *a;
+ int err = 0;
+
+ if (!ipvs)
+ return ERR_PTR(-ENOENT);
mutex_lock(&__ip_vs_app_mutex);
- list_add(&app->a_list, &ipvs->app_list);
+ list_for_each_entry(a, &ipvs->app_list, a_list) {
+ if (!strcmp(app->name, a->name)) {
+ err = -EEXIST;
+ goto out_unlock;
+ }
+ }
+ a = kmemdup(app, sizeof(*app), GFP_KERNEL);
+ if (!a) {
+ err = -ENOMEM;
+ goto out_unlock;
+ }
+ INIT_LIST_HEAD(&a->incs_list);
+ list_add(&a->a_list, &ipvs->app_list);
+ /* increase the module use count */
+ ip_vs_use_count_inc();
+out_unlock:
mutex_unlock(&__ip_vs_app_mutex);
- return 0;
+ return err ? ERR_PTR(err) : a;
}
@@ -205,20 +221,29 @@ int register_ip_vs_app(struct net *net, struct ip_vs_app *app)
*/
void unregister_ip_vs_app(struct net *net, struct ip_vs_app *app)
{
- struct ip_vs_app *inc, *nxt;
+ struct netns_ipvs *ipvs = net_ipvs(net);
+ struct ip_vs_app *a, *anxt, *inc, *nxt;
+
+ if (!ipvs)
+ return;
mutex_lock(&__ip_vs_app_mutex);
- list_for_each_entry_safe(inc, nxt, &app->incs_list, a_list) {
- ip_vs_app_inc_release(net, inc);
- }
+ list_for_each_entry_safe(a, anxt, &ipvs->app_list, a_list) {
+ if (app && strcmp(app->name, a->name))
+ continue;
+ list_for_each_entry_safe(inc, nxt, &a->incs_list, a_list) {
+ ip_vs_app_inc_release(net, inc);
+ }
- list_del(&app->a_list);
+ list_del(&a->a_list);
+ kfree(a);
- mutex_unlock(&__ip_vs_app_mutex);
+ /* decrease the module use count */
+ ip_vs_use_count_dec();
+ }
- /* decrease the module use count */
- ip_vs_use_count_dec();
+ mutex_unlock(&__ip_vs_app_mutex);
}
@@ -586,5 +611,6 @@ int __net_init ip_vs_app_net_init(struct net *net)
void __net_exit ip_vs_app_net_cleanup(struct net *net)
{
+ unregister_ip_vs_app(net, NULL /* all */);
proc_net_remove(net, "ip_vs_app");
}
diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
index b20b29c..ad70b7e 100644
--- a/net/netfilter/ipvs/ip_vs_ftp.c
+++ b/net/netfilter/ipvs/ip_vs_ftp.c
@@ -441,16 +441,10 @@ static int __net_init __ip_vs_ftp_init(struct net *net)
if (!ipvs)
return -ENOENT;
- app = kmemdup(&ip_vs_ftp, sizeof(struct ip_vs_app), GFP_KERNEL);
- if (!app)
- return -ENOMEM;
- INIT_LIST_HEAD(&app->a_list);
- INIT_LIST_HEAD(&app->incs_list);
- ipvs->ftp_app = app;
- ret = register_ip_vs_app(net, app);
- if (ret)
- goto err_exit;
+ app = register_ip_vs_app(net, &ip_vs_ftp);
+ if (IS_ERR(app))
+ return PTR_ERR(app);
for (i = 0; i < ports_count; i++) {
if (!ports[i])
@@ -464,9 +458,7 @@ static int __net_init __ip_vs_ftp_init(struct net *net)
return 0;
err_unreg:
- unregister_ip_vs_app(net, app);
-err_exit:
- kfree(ipvs->ftp_app);
+ unregister_ip_vs_app(net, &ip_vs_ftp);
return ret;
}
/*
@@ -474,10 +466,7 @@ err_exit:
*/
static void __ip_vs_ftp_exit(struct net *net)
{
- struct netns_ipvs *ipvs = net_ipvs(net);
^ permalink raw reply related
* Re: [PATCH 2/2] ipvs: generalize app registration in netns
From: Julian Anastasov @ 2012-07-12 20:04 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Simon Horman, lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Hans Schillstrom, Jesper Dangaard Brouer
In-Reply-To: <20120712162209.GA21904@1984>
Hello,
On Thu, 12 Jul 2012, Pablo Neira Ayuso wrote:
> > +struct ip_vs_app *register_ip_vs_app(struct net *net, struct ip_vs_app *app)
> > {
> > struct netns_ipvs *ipvs = net_ipvs(net);
> > - /* increase the module use count */
> > - ip_vs_use_count_inc();
> > + struct ip_vs_app *a;
> > + int err = 0;
> > +
> > + if (!ipvs)
> > + return ERR_PTR(-ENOENT);
> >
> > mutex_lock(&__ip_vs_app_mutex);
> >
> > - list_add(&app->a_list, &ipvs->app_list);
> > + list_for_each_entry(a, &ipvs->app_list, a_list) {
> > + if (!strcmp(app->name, a->name)) {
> > + err = -EEXIST;
> > + break;
> > + }
> > + }
> > + if (!err) {
> > + a = kmemdup(app, sizeof(*app), GFP_KERNEL);
> > + if (!a)
> > + err = -ENOMEM;
> > + }
> > + if (!err) {
> > + INIT_LIST_HEAD(&a->incs_list);
> > + list_add(&a->a_list, &ipvs->app_list);
> > + /* increase the module use count */
> > + ip_vs_use_count_inc();
> > + }
>
> I think this code will look better if you use something like:
>
> + if (!strcmp(app->name, a->name)) {
> + err = -EEXIST;
> + goto err_unlock;
> + }
>
> err_unlock:
> mutex_unlock(...)
>
> >
> > mutex_unlock(&__ip_vs_app_mutex);
> >
> > - return 0;
> > + if (err)
> > + return ERR_PTR(err);
> > + return a;
>
> For this three lines above, you can use:
>
> return err ? return ERR_PTR(err) : a;
Good point, sending v2 ...
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [trivial PATCH 2/7] ixgbe: remove unused #define
From: Jeff Kirsher @ 2012-07-12 19:58 UTC (permalink / raw)
To: Jon Mason
Cc: trivial, linux-kernel, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, Peter P Waskiewicz Jr,
Alex Duyck, John Ronciak, netdev
In-Reply-To: <CAPoiz9wcj7tbgVUf+D=HdonXnaMYFHb+TmSb77f2R2mpwGQM7g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]
On Thu, 2012-07-12 at 12:49 -0700, Jon Mason wrote:
> On Thu, Jul 12, 2012 at 11:15 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > On Tue, 2012-07-10 at 15:43 -0700, Jeff Kirsher wrote:
> >> On Tue, 2012-07-10 at 15:31 -0700, Jon Mason wrote:
> >> > Remove unused IXGBE_INTEL_VENDOR_ID #define
> >> >
> >> > Signed-off-by: Jon Mason <jdmason@kudzu.us>
> >> > Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >> > Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> >> > Cc: Bruce Allan <bruce.w.allan@intel.com>
> >> > Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
> >> > Cc: Don Skidmore <donald.c.skidmore@intel.com>
> >> > Cc: Greg Rose <gregory.v.rose@intel.com>
> >> > Cc: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> >> > Cc: Alex Duyck <alexander.h.duyck@intel.com>
> >> > Cc: John Ronciak <john.ronciak@intel.com>
> >> > ---
> >> > drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 3 ---
> >> > 1 file changed, 3 deletions(-)
> >>
> >> This should also go through David Miller's networking tree's.
> Adding
> >> netdev mailing list.
> >>
> >> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >
> > After looking at this further, I rescind my ACK.
> >
> > NAK, this define is used in several places in ixgbe_main.c and the
> > driver will not compile with this patch.
>
> My apologies, I was a bit sloppy and simply rebased my old patches
> without retesting them. The code has changed since I originally
> pushed the patch (http://www.spinics.net/lists/netdev/msg171523.html).
> I will fix and resubmit.
>
> Thanks,
> Jon
Also note, that when you fix up the patch and resend it, could you
resend patch 1 (ixgb) as well to netdev@vger.kernel.org. That way
netdev patchwork will pickup the patches and I can get them into my
queue.
Thanks!
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [trivial PATCH 2/7] ixgbe: remove unused #define
From: Jon Mason @ 2012-07-12 19:49 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: trivial, linux-kernel, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, Peter P Waskiewicz Jr,
Alex Duyck, John Ronciak, netdev
In-Reply-To: <1342116938.1783.57.camel@jtkirshe-mobl>
On Thu, Jul 12, 2012 at 11:15 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> On Tue, 2012-07-10 at 15:43 -0700, Jeff Kirsher wrote:
>> On Tue, 2012-07-10 at 15:31 -0700, Jon Mason wrote:
>> > Remove unused IXGBE_INTEL_VENDOR_ID #define
>> >
>> > Signed-off-by: Jon Mason <jdmason@kudzu.us>
>> > Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> > Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> > Cc: Bruce Allan <bruce.w.allan@intel.com>
>> > Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
>> > Cc: Don Skidmore <donald.c.skidmore@intel.com>
>> > Cc: Greg Rose <gregory.v.rose@intel.com>
>> > Cc: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
>> > Cc: Alex Duyck <alexander.h.duyck@intel.com>
>> > Cc: John Ronciak <john.ronciak@intel.com>
>> > ---
>> > drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 3 ---
>> > 1 file changed, 3 deletions(-)
>>
>> This should also go through David Miller's networking tree's. Adding
>> netdev mailing list.
>>
>> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> After looking at this further, I rescind my ACK.
>
> NAK, this define is used in several places in ixgbe_main.c and the
> driver will not compile with this patch.
My apologies, I was a bit sloppy and simply rebased my old patches
without retesting them. The code has changed since I originally
pushed the patch (http://www.spinics.net/lists/netdev/msg171523.html).
I will fix and resubmit.
Thanks,
Jon
>>
>> >
>> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
>> > index 204848d..c8d8040 100644
>> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
>> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
>> > @@ -32,9 +32,6 @@
>> > #include <linux/mdio.h>
>> > #include <linux/netdevice.h>
>> >
>> > -/* Vendor ID */
>> > -#define IXGBE_INTEL_VENDOR_ID 0x8086
>> > -
>> > /* Device IDs */
>> > #define IXGBE_DEV_ID_82598 0x10B6
>> > #define IXGBE_DEV_ID_82598_BX 0x1508
>>
>>
>
^ permalink raw reply
* Re: [PATCH 1/2] ipvs: ip_vs_ftp depends on nf_conntrack_ftp helper
From: Julian Anastasov @ 2012-07-12 19:43 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Simon Horman, lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Hans Schillstrom, Jesper Dangaard Brouer
In-Reply-To: <20120712153937.GB18793@1984>
Hello,
On Thu, 12 Jul 2012, Pablo Neira Ayuso wrote:
> On Wed, Jul 11, 2012 at 09:25:26AM +0900, Simon Horman wrote:
> > From: Julian Anastasov <ja@ssi.bg>
> >
> > The FTP application indirectly depends on the
> > nf_conntrack_ftp helper for proper NAT support. If the
> > module is not loaded, IPVS can resize the packets for the
> > command connection, eg. PASV response but the SEQ adjustment
> > logic in ipv4_confirm is not called without helper.
> >
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> > ---
> > net/netfilter/ipvs/Kconfig | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
> > index f987138..8b2cffd 100644
> > --- a/net/netfilter/ipvs/Kconfig
> > +++ b/net/netfilter/ipvs/Kconfig
> > @@ -250,7 +250,8 @@ comment 'IPVS application helper'
> >
> > config IP_VS_FTP
> > tristate "FTP protocol helper"
> > - depends on IP_VS_PROTO_TCP && NF_CONNTRACK && NF_NAT
> > + depends on IP_VS_PROTO_TCP && NF_CONNTRACK && NF_NAT && \
> > + NF_CONNTRACK_FTP
>
> If you require FTP NAT support, then this depends on NF_NAT_FTP
> instead of NF_CONNTRACK_FTP.
No, I just checked again, it works without nf_nat_ftp,
only nf_nat, nf_conntrack_ftp and iptable_nat are needed.
We use packet mangling part from nf_nat (nf_nat_mangle_tcp_packet).
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [RFC PATCH 0/2] Coalesce MMIO writes for transmits
From: Alexander Duyck @ 2012-07-12 19:01 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, davem, jeffrey.t.kirsher, edumazet, bhutchings, therbert,
alexander.duyck
In-Reply-To: <20120712102331.42a7b041@nehalam.linuxnetplumber.net>
On 07/12/2012 10:23 AM, Stephen Hemminger wrote:
> On Wed, 11 Jul 2012 17:25:58 -0700
> Alexander Duyck <alexander.h.duyck@intel.com> wrote:
>
>> This patch set is meant to address recent issues I found with ixgbe
>> performance being bound by Tx tail writes. With these changes in place
>> and the dispatch_limit set to 1 or more I see a significant increase in
>> performance.
>>
>> In the case of one of my systems I saw the routing rate for 7 queues jump
>> from 10.5 to 11.7Mpps. The overall increase I have seen on most systems is
>> something on the order of about 15%. In the case of pktgen I have also
>> seen a noticeable increase as the previous limit for transmits was
>> ~12.5Mpps, but with this patch set in place and the dispatch_limit enabled
>> the value increases to ~14.2Mpps.
>>
>> I expected there to be an increase in latency, however so far I have not
>> ran into that. I have tried running NPtcp tests for latency and seen no
>> difference in the coalesced and non-coalesced transaction times. I welcome
>> any suggestions for tests I might run that might expose any latency issues
>> as a result of this patch.
>>
>> ---
>>
>> Alexander Duyck (2):
>> ixgbe: Add functionality for delaying the MMIO write for Tx
>> net: Add new network device function to allow for MMIO batching
>>
>>
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 22 +++++++-
>> include/linux/netdevice.h | 57 +++++++++++++++++++++
>> net/core/dev.c | 67 +++++++++++++++++++++++++
>> net/core/net-sysfs.c | 36 +++++++++++++
>> 4 files changed, 180 insertions(+), 2 deletions(-)
>>
> This is a good idea. I was thinking of adding a multi-skb operation
> to netdevice_ops to allow this. Something like ndo_start_xmit_pkts but
> the problem is how to deal with the boundary case where there is only
> a limited number of slots in the ring. Using a "that's all folks"
> operation seems better.
I had considered a multi-skb operation originally, but the problem was
in my case I would have had to come up with a more complex buffering
mechanism to generate a stream of skbs before handing them off to the
device. By letting the transmit path proceed normally I shouldn't have
any effect on things like the byte queue limits for the transmit queues
and such.
The wierd bit is how this issue was showing up. I don't know if you
recall my presentation from plumbers last year, but one of the things I
had brought up was the qdisc spinlock being an issue. However it was
actually this MMIO write that was causing the problem because it was
posting a write to non-coherent memory and then the spinlock was getting
stalled behind the write and couldn't complete until the write was
completed. With this change in place and the dispatch_limit set to
something like 31 I see the CPU utilization for spinlocks drop from 15%
(90% sch_direct_xmit / 10% dev_queue_xmit) to 5% (66% sch_direct_xmit /
33% dev_queue_xmit). Makes me wonder what other hotspots we have in the
drivers that can be resolved by avoiding MMIO followed by locked
operations.
Thanks,
Alex
^ permalink raw reply
* pull request: wireless-next 2012-07-12
From: John W. Linville @ 2012-07-12 18:15 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 27801 bytes --]
commit 38a00840638b4932152bca48098dbfa069d942a2
Dave,
Here is another batch of updates intended for 3.6.
Several drivers see updates: mwifiex, ath9k, iwlwifi, brcmsmac,
wlcore/wl12xx/wl18xx, and a handful of others. The bcma bus got a
lot of attention from Hauke Mehrtens. The cfg80211 component gets
a flurry of patches for multi-channel support, and the mac80211
component gets the first few VHT (11ac) and 60GHz (11ad) patches.
This also includes the removal of the iwmc3200 drivers, since the
hardware never became available to normal people.
Additionally, the NFC subsystem gets a series of updates. According to
Samuel, "Here are the interesting bits:
- A better error management for the HCI stack.
- An LLCP "late" binding implementation for a better NFC SAP usage. SAPs are
now reserved only when there's a client for it.
- Support for Sony RC-S360 (a.k.a. PaSoRi) pn533 based dongle. We can read and
write NFC tags and also establish a p2p link with this dongle now.
- A few LLCP fixes."
Finally, this includes another pull of the fixes from the wireless
tree in order to resolve some merge issues.
Please let me know if there problems!
Thanks,
John
P.S. This includes the bcma fix for the build issue on MIPS mentioned
in response to the previous pull request.
---
The following changes since commit 391e5c22f5f4e55817f8ba18a08ea717ed2d4a1f:
ipv4: Remove tb_peers from fib_table. (2012-07-12 09:39:28 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
for you to fetch changes up to 38a00840638b4932152bca48098dbfa069d942a2:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem (2012-07-12 13:44:50 -0400)
----------------------------------------------------------------
Amitkumar Karwar (1):
mwifiex: add set_antenna handler support
Arend van Spriel (1):
brcmsmac: fix brcms_c_regd_init() which crashed after 11ad patch
Arik Nemtsov (9):
wlcore/wl12xx/wl18xx: check min FW version
wlcore: don't stop tx queue via watermark if already stopped
wlcore: remove recover cmd from testmode
wlcore: avoid debug prints during intended FW recovery
wlcore: always clear recovery flag during recovery_work
wlcore: don't set SDIO_FAILED flag when driver state is off
wlcore: define number of supported bands internally
wl12xx/wl18xx: use a dynamic PS timeout of 1.5sec
wlcore: determine AP extra rates correctly
Avinash Patil (6):
mwifiex: pass cfg80211_beacon_data to mwifiex_set_mgmt_ie()
mwifiex: separate IE parsing for Head/Tail IEs and beacon_ies etc
mwifiex: overwrite earlier IE buffers for new set IE request
mwifiex: add change_beacon cfg80211 handler
mwifiex: advertise WPS probe response offload support to cfg80211
mwifiex: parse WPS IEs from beacon_data
Christian Lamparter (2):
carl9170: import 1.9.6 firmware headers
carl9170: fix HT peer BA session corruption
Dan Carpenter (1):
wlcore: fix a couple small memory leaks
Eliad Peller (6):
mac80211: flush queues before deauth/disassoc
mac80211: don't require associated->beacon_ies for ps
mac80211: allow calling ieee80211_ap_probereq_get() during auth/assoc
mac80211: always set in_reconfig=false on wakeup
wlcore: implement .flush callback
wlcore: check ssid length against the correct element
Emmanuel Grumbach (2):
iwlwifi: configure the queues from the op_mode
iwlwifi: disable the watchdog for queues by default
Eric Lapuyade (15):
NFC: Prepare asynchronous error management for driver and shdlc
NFC: Removed addressed shdlc TODOs
NFC: Handle SHDLC RSET frames from an SHDLC connected chip
NFC: Remove an impossible HCI error case
NFC: Implement HCP reaggregation allocation error case
NFC: Changed HCI cmd execution completion result to std linux errno
NFC: Driver failure API
NFC: Factorize HCI cmd completion
NFC: Implement HCI driver or internal error management
NFC: Core must test the device polling state inside the device lock
NFC: nfc_targets_found() should accept zero target found
NFC: nfc_driver_failure() implementation
NFC: Error management documentation
NFC: update PN544 HCI driver state when opened/closed
NFC: Allow HCI driver to pre-open pipes to some gates
Gabor Juhos (20):
ath9k: define DEVID for QCA955x
ath9k: define MAC version for AR9550
ath9k: set MAC version for AR9550
ath9k: add platform_device_id for AR9550
ath9k: add BB name string for AR9550
ath9k: clear pciexpress flag for AR9550
ath9k: enable TX/RX data byte swap for AR9550
ath9k: add initvals for AR9550
ath9k: add mode register initialization code for AR9550
ath9k: read spur frequency information from eeprom for AR9550
ath9k: fix XPABIASLEVEL settings for AR9550
ath9k: fix antenna control configuration for AR9550
ath9k: fix PAPRD settings for AR9550
ath9k: fix RF channel frequency configuration for AR9550
ath9k: disable SYNC_HOST1_FATAL interrupts for AR9550
ath9k: skip internal regulator configuration for AR9550
ath9k: fix PLL initialization for AR9550
ath9k: enable PLL workaround for AR9550
ath9k: set 4ADDRESS bit in RX filter for AR9550
ath9k: enable support for AR9550
Hauke Mehrtens (28):
bcma: extend workaround for bcm4331
bcma: add constants for chip ids
bcma: remove fix for 4329b0 bad LPOM is detection
bcma: add PCI ID for BCM43224
bcma: complete workaround for BCMA43224 and BCM4313
bcma: remove bcma_pmu_{pll,swreg}_init()
bcma: remove chip ids doing nothing from PMU initialization.
bcma: add bcma_pmu_spuravoid_pllupdate()
bcma: add mdelay bcma_pmu_resources_init()
brcmsmac: remove PCIE() macro
brcmsmac: remove PCI_FORCEHT() macro
brcmsmac: remove ai_get_buscore{type,rev}()
brcmsmac: use container_of instead of cast
brcmsmac: remove ai_findcore()
brcmsmac: remove si_pmu_init() and si_pmu_res_init()
brcmsmac: remove si_pmu_spuravoid_pllupdate()
brcmsmac: remove some redundant chip common workarounds
brcmsmac: use core id constants from bcma
brcmsmac: use chip and package id constants from bcma
brcmsmac: remove some unnessessacry casts and void pointer
brcmsmac: add a conditions for core rev 17 again
brcmsmac: add some workarounds for other chips again
brcmsmac: extend xmtfifo_sz array
brcmsmac: fix DMA on SoCs
brcmsmac: extend brcms_c_chipmatch() to also handle non PCIe devices
brcmsmac: fix read in write_phy_reg
brcmsmac: handle non PCI devices in the phy code
bcma: add PMU clock support for BCM4706
Ido Yariv (1):
wlcore: Prevent processing of work items during op_stop
Johannes Berg (17):
iwlwifi: bump trace message limit
iwlwifi: use __get_str in tracing
iwlwifi: limit dwell time more strictly
mac80211: make __ieee80211_recalc_idle static
cfg80211: don't allow WoWLAN support without CONFIG_PM
mac80211: don't expose ieee80211_add_srates_ie()
Merge remote-tracking branch 'wireless-next/master' into mac80211-next
iwlwifi: add trailing newline to some messages
iwlwifi: fix debug message level
mac80211: remove tx_frags driver callback
mac80211_hwsim: fix NUM_BANDS usage
mac80211: add TX prepare API
iwlwifi: remove unneeded NULL check
cfg80211: fix locking regression in monitor channel tracking
mac80211: fix debugfs default key links
mac80211: fix crash with single-queue drivers
mac80211_hwsim: add testmode code to stop/wake queues
John W. Linville (7):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Merge branch 'for-john' of git://git.sipsolutions.net/mac80211-next
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
iwmc3200wifi: remove driver for unavailable hardware
i2400m: remove SDIO device support
iwmc3200top: remove driver for unavailable hardware
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Luciano Coelho (1):
wl12xx/wlcore: increase FW filename version
Luis R. Rodriguez (1):
ath5k: replace modparam_all_channels with CONFIG_ATH5K_TEST_CHANNELS
Mahesh Palivela (3):
wireless: add VHT (802.11ac) definitions
cfg80211: allow advertising VHT capabilities
mac80211: include VHT capability IE in probe requests
Michal Kazior (13):
cfg80211: introduce cfg80211_stop_ap
cfg80211: .stop_ap when interface is going down
cfg80211: add channel tracking for AP and mesh
cfg80211: track ibss fixed channel
cfg80211: introduce cfg80211_get_chan_state
cfg80211: track monitor interfaces count
mac80211: refactor virtual monitor code
cfg80211: refuse to .set_monitor_channel when non-monitors are present
cfg80211: track monitor channel
cfg80211: set initial monitor channel
cfg80211/mac80211: remove .get_channel
cfg80211: add channel checking for iface combinations
cfg80211: respect iface combinations when starting operation
Mohammed Shafi Shajakhan (3):
ath9k: Fix clearing of BTCOEX flags
ath9k: Fix MCI cleanup
ath9k: Stop the BTCOEX timers before disabling BTCOEX
Oskar Schirmer (1):
net/wireless: remove macro defined twice with same value
Rafał Miłecki (3):
b43: N-PHY: fix RSSI calibration
bcma: use custom printing functions
bcma: fix CC driver compilation on MIPS
Rajkumar Manoharan (6):
ath9k_hw: start noisefloor calibration after MCI reset
ath9k_hw: do not load noise floor readings when it is running
ath9k: fix fullsleep power consumption when BTCOEX is enabled
ath9k: fix power consumption on network sleep when BTCOEX is enabled
ath9k_hw: fix AR9462 2g5g switch on full reset
ath9k_hw: remove debugging masks from AR_MCI_INTERRUPT_RX_MSG_DEFAULT
Richard A. Griffiths (1):
iwlwifi: disallow log_event access if interface down
Samuel Ortiz (18):
NFC: Add modules alias for NFC sockets
NFC: Add netlink module alias for NFC
NFC: Update LLCP socket target index when getting a connection
NFC: Fix LLCP getname socket op
NFC: Build LLCP general bytes upon request
NFC: Close listening LLCP sockets when the device is gone
NFC: Release LLCP SAP when the owner is released
NFC: Forbid LLCP service name reusing
NFC: Forbid SSAP binding to a not well known LLCP service
NFC: LLCP late binding
NFC: Handle LLCP Disconnected Mode frames
NFC: Remove warning from nfc_llcp_local_put
NFC: Do not return EBUSY when stopping a poll that's already stopped
NFC: Dereference LLCP bind socket address after checking for it to be NULL
NFC: Add initial Sony RC-S360 support to pn533
NFC: Use communicate thru only for PaSoRi when trying to read Felica tags
NFC: Add ISO 14443 type B protocol
NFC: Check for llcp_sock and its device from llcp_sock_getname
Stanislaw Gruszka (3):
rt2x00pci: small 3290 changes cleanup
rt2800lib: merge same defines
rt2x00: remove unused argument
Thomas Huehn (2):
mac80211: reduce IEEE80211_TX_MAX_RATES
ath9k: fixing register bit shift values of control packets to support TPC
Victor Goldenshtein (1):
wlcore: enable sched scan while connected
Vladimir Kondratiev (5):
cfg80211: add 802.11ad (60gHz band) support
wireless: regulatory for 60g
wireless: 60g protocol constants
{nl,cfg}80211: support high bitrates
cfg80211: bitrate calculation for 60g
Yoni Divinsky (2):
wlcore: add probe request templates for sched and one-shot scans
wlcore: change the wait for event mechanism
Documentation/nfc/nfc-hci.txt | 33 +
MAINTAINERS | 8 -
drivers/bcma/bcma_private.h | 9 +
drivers/bcma/core.c | 10 +-
drivers/bcma/driver_chipcommon.c | 5 +-
drivers/bcma/driver_chipcommon_pmu.c | 369 +++--
drivers/bcma/driver_mips.c | 24 +-
drivers/bcma/driver_pci_host.c | 18 +-
drivers/bcma/host_pci.c | 5 +-
drivers/bcma/main.c | 19 +-
drivers/bcma/scan.c | 24 +-
drivers/bcma/sprom.c | 26 +-
drivers/misc/Kconfig | 1 -
drivers/misc/Makefile | 1 -
drivers/misc/iwmc3200top/Kconfig | 20 -
drivers/misc/iwmc3200top/Makefile | 29 -
drivers/misc/iwmc3200top/debugfs.c | 137 --
drivers/misc/iwmc3200top/debugfs.h | 58 -
drivers/misc/iwmc3200top/fw-download.c | 358 ----
drivers/misc/iwmc3200top/fw-msg.h | 113 --
drivers/misc/iwmc3200top/iwmc3200top.h | 205 ---
drivers/misc/iwmc3200top/log.c | 348 ----
drivers/misc/iwmc3200top/log.h | 171 --
drivers/misc/iwmc3200top/main.c | 662 --------
drivers/net/wimax/i2400m/Kconfig | 22 -
drivers/net/wimax/i2400m/Makefile | 8 -
drivers/net/wimax/i2400m/driver.c | 3 +-
drivers/net/wimax/i2400m/fw.c | 3 +-
drivers/net/wimax/i2400m/i2400m-sdio.h | 157 --
drivers/net/wimax/i2400m/i2400m.h | 13 +-
drivers/net/wimax/i2400m/sdio-debug-levels.h | 22 -
drivers/net/wimax/i2400m/sdio-fw.c | 210 ---
drivers/net/wimax/i2400m/sdio-rx.c | 301 ----
drivers/net/wimax/i2400m/sdio-tx.c | 177 --
drivers/net/wimax/i2400m/sdio.c | 602 -------
drivers/net/wireless/Kconfig | 1 -
drivers/net/wireless/Makefile | 2 -
drivers/net/wireless/ath/ath5k/Kconfig | 8 +
drivers/net/wireless/ath/ath5k/base.c | 17 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +
drivers/net/wireless/ath/ath9k/ahb.c | 4 +
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 13 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 87 +-
drivers/net/wireless/ath/ath9k/ar9003_mci.c | 18 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 72 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 6 +-
.../net/wireless/ath/ath9k/ar955x_1p0_initvals.h | 1284 +++++++++++++++
drivers/net/wireless/ath/ath9k/ath9k.h | 4 +
drivers/net/wireless/ath/ath9k/gpio.c | 25 +-
drivers/net/wireless/ath/ath9k/hw.c | 46 +-
drivers/net/wireless/ath/ath9k/hw.h | 2 +
drivers/net/wireless/ath/ath9k/mac.c | 2 +-
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 16 +-
drivers/net/wireless/ath/ath9k/mci.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 3 +
drivers/net/wireless/ath/ath9k/reg.h | 16 +-
drivers/net/wireless/ath/carl9170/carl9170.h | 11 +
drivers/net/wireless/ath/carl9170/fw.c | 3 +
drivers/net/wireless/ath/carl9170/fwdesc.h | 3 +
drivers/net/wireless/ath/carl9170/main.c | 6 +
drivers/net/wireless/ath/carl9170/rx.c | 49 +
drivers/net/wireless/ath/carl9170/tx.c | 69 +-
drivers/net/wireless/ath/carl9170/version.h | 8 +-
drivers/net/wireless/b43/phy_n.c | 17 +-
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 128 +-
drivers/net/wireless/brcm80211/brcmsmac/aiutils.h | 16 -
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 17 +-
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 15 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 3 +-
drivers/net/wireless/brcm80211/brcmsmac/main.c | 87 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 22 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_n.c | 140 +-
drivers/net/wireless/brcm80211/brcmsmac/pmu.c | 172 +-
drivers/net/wireless/brcm80211/brcmsmac/pmu.h | 3 -
drivers/net/wireless/brcm80211/brcmsmac/pub.h | 2 +-
drivers/net/wireless/brcm80211/include/soc.h | 62 -
drivers/net/wireless/iwlegacy/3945-rs.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/commands.h | 40 +-
drivers/net/wireless/iwlwifi/dvm/debugfs.c | 6 +-
drivers/net/wireless/iwlwifi/dvm/dev.h | 16 -
drivers/net/wireless/iwlwifi/dvm/main.c | 56 +-
drivers/net/wireless/iwlwifi/dvm/scan.c | 37 +-
drivers/net/wireless/iwlwifi/dvm/ucode.c | 37 +
drivers/net/wireless/iwlwifi/iwl-debug.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-devtrace.h | 4 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 1 +
drivers/net/wireless/iwlwifi/iwl-trans.h | 27 +-
drivers/net/wireless/iwlwifi/pcie/internal.h | 3 +-
drivers/net/wireless/iwlwifi/pcie/rx.c | 3 -
drivers/net/wireless/iwlwifi/pcie/trans.c | 36 +-
drivers/net/wireless/iwmc3200wifi/Kconfig | 39 -
drivers/net/wireless/iwmc3200wifi/Makefile | 10 -
drivers/net/wireless/iwmc3200wifi/bus.h | 57 -
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 882 ----------
drivers/net/wireless/iwmc3200wifi/cfg80211.h | 31 -
drivers/net/wireless/iwmc3200wifi/commands.c | 1002 ------------
drivers/net/wireless/iwmc3200wifi/commands.h | 509 ------
drivers/net/wireless/iwmc3200wifi/debug.h | 123 --
drivers/net/wireless/iwmc3200wifi/debugfs.c | 488 ------
drivers/net/wireless/iwmc3200wifi/eeprom.c | 234 ---
drivers/net/wireless/iwmc3200wifi/eeprom.h | 127 --
drivers/net/wireless/iwmc3200wifi/fw.c | 416 -----
drivers/net/wireless/iwmc3200wifi/fw.h | 100 --
drivers/net/wireless/iwmc3200wifi/hal.c | 470 ------
drivers/net/wireless/iwmc3200wifi/hal.h | 237 ---
drivers/net/wireless/iwmc3200wifi/iwm.h | 367 -----
drivers/net/wireless/iwmc3200wifi/lmac.h | 484 ------
drivers/net/wireless/iwmc3200wifi/main.c | 847 ----------
drivers/net/wireless/iwmc3200wifi/netdev.c | 191 ---
drivers/net/wireless/iwmc3200wifi/rx.c | 1701 --------------------
drivers/net/wireless/iwmc3200wifi/rx.h | 60 -
drivers/net/wireless/iwmc3200wifi/sdio.c | 509 ------
drivers/net/wireless/iwmc3200wifi/sdio.h | 64 -
drivers/net/wireless/iwmc3200wifi/trace.c | 3 -
drivers/net/wireless/iwmc3200wifi/trace.h | 283 ----
drivers/net/wireless/iwmc3200wifi/tx.c | 529 ------
drivers/net/wireless/iwmc3200wifi/umac.h | 789 ---------
drivers/net/wireless/libertas/host.h | 1 -
drivers/net/wireless/mac80211_hwsim.c | 12 +-
drivers/net/wireless/mwifiex/cfg80211.c | 76 +-
drivers/net/wireless/mwifiex/fw.h | 21 +
drivers/net/wireless/mwifiex/ie.c | 185 ++-
drivers/net/wireless/mwifiex/ioctl.h | 5 +
drivers/net/wireless/mwifiex/main.h | 2 +-
drivers/net/wireless/mwifiex/sta_cmd.c | 37 +
drivers/net/wireless/mwifiex/sta_cmdresp.c | 30 +
drivers/net/wireless/p54/txrx.c | 6 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 29 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 10 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 5 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 20 +-
drivers/net/wireless/ti/wl12xx/main.c | 26 +-
drivers/net/wireless/ti/wl12xx/wl12xx.h | 14 +
drivers/net/wireless/ti/wl18xx/main.c | 27 +-
drivers/net/wireless/ti/wl18xx/wl18xx.h | 7 +
drivers/net/wireless/ti/wlcore/boot.c | 55 +-
drivers/net/wireless/ti/wlcore/cmd.c | 22 +-
drivers/net/wireless/ti/wlcore/cmd.h | 6 +-
drivers/net/wireless/ti/wlcore/init.c | 16 +
drivers/net/wireless/ti/wlcore/io.c | 6 +
drivers/net/wireless/ti/wlcore/io.h | 13 +-
drivers/net/wireless/ti/wlcore/main.c | 77 +-
drivers/net/wireless/ti/wlcore/scan.c | 11 +-
drivers/net/wireless/ti/wlcore/sdio.c | 6 -
drivers/net/wireless/ti/wlcore/spi.c | 6 -
drivers/net/wireless/ti/wlcore/testmode.c | 13 +-
drivers/net/wireless/ti/wlcore/wlcore.h | 25 +-
drivers/net/wireless/ti/wlcore/wlcore_i.h | 16 +-
drivers/nfc/nfcwilink.c | 7 +-
drivers/nfc/pn533.c | 224 ++-
drivers/nfc/pn544_hci.c | 37 +-
include/linux/bcma/bcma.h | 30 +
include/linux/bcma/bcma_driver_chipcommon.h | 37 +
include/linux/ieee80211.h | 160 +-
include/linux/nfc.h | 14 +-
include/linux/nl80211.h | 17 +
include/net/cfg80211.h | 40 +-
include/net/mac80211.h | 44 +-
include/net/nfc/hci.h | 19 +-
include/net/nfc/nfc.h | 2 +
net/mac80211/cfg.c | 24 +-
net/mac80211/debugfs_key.c | 16 +-
net/mac80211/driver-ops.h | 22 +-
net/mac80211/ieee80211_i.h | 11 +-
net/mac80211/iface.c | 258 ++-
net/mac80211/main.c | 17 +-
net/mac80211/mesh_plink.c | 4 +-
net/mac80211/mlme.c | 28 +-
net/mac80211/trace.h | 7 +
net/mac80211/tx.c | 16 +-
net/mac80211/util.c | 49 +-
net/nfc/core.c | 38 +-
net/nfc/hci/command.c | 26 +-
net/nfc/hci/core.c | 104 +-
net/nfc/hci/hci.h | 12 +-
net/nfc/hci/shdlc.c | 38 +-
net/nfc/llcp/llcp.c | 342 ++--
net/nfc/llcp/llcp.h | 5 +
net/nfc/llcp/sock.c | 31 +-
net/nfc/nci/core.c | 5 +-
net/nfc/nci/ntf.c | 5 +-
net/nfc/netlink.c | 9 +
net/wireless/Makefile | 2 +-
net/wireless/ap.c | 46 +
net/wireless/chan.c | 62 +-
net/wireless/core.c | 84 +-
net/wireless/core.h | 64 +-
net/wireless/ibss.c | 11 +
net/wireless/mesh.c | 30 +-
net/wireless/mlme.c | 17 +
net/wireless/nl80211.c | 65 +-
net/wireless/reg.c | 5 +-
net/wireless/util.c | 156 +-
net/wireless/wext-compat.c | 9 +-
198 files changed, 4692 insertions(+), 15819 deletions(-)
delete mode 100644 drivers/misc/iwmc3200top/Kconfig
delete mode 100644 drivers/misc/iwmc3200top/Makefile
delete mode 100644 drivers/misc/iwmc3200top/debugfs.c
delete mode 100644 drivers/misc/iwmc3200top/debugfs.h
delete mode 100644 drivers/misc/iwmc3200top/fw-download.c
delete mode 100644 drivers/misc/iwmc3200top/fw-msg.h
delete mode 100644 drivers/misc/iwmc3200top/iwmc3200top.h
delete mode 100644 drivers/misc/iwmc3200top/log.c
delete mode 100644 drivers/misc/iwmc3200top/log.h
delete mode 100644 drivers/misc/iwmc3200top/main.c
delete mode 100644 drivers/net/wimax/i2400m/i2400m-sdio.h
delete mode 100644 drivers/net/wimax/i2400m/sdio-debug-levels.h
delete mode 100644 drivers/net/wimax/i2400m/sdio-fw.c
delete mode 100644 drivers/net/wimax/i2400m/sdio-rx.c
delete mode 100644 drivers/net/wimax/i2400m/sdio-tx.c
delete mode 100644 drivers/net/wimax/i2400m/sdio.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar955x_1p0_initvals.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/Kconfig
delete mode 100644 drivers/net/wireless/iwmc3200wifi/Makefile
delete mode 100644 drivers/net/wireless/iwmc3200wifi/bus.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/cfg80211.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/cfg80211.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/commands.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/commands.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/debug.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/debugfs.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/eeprom.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/eeprom.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/fw.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/fw.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/hal.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/hal.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/iwm.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/lmac.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/main.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/netdev.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/rx.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/rx.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/sdio.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/sdio.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/trace.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/trace.h
delete mode 100644 drivers/net/wireless/iwmc3200wifi/tx.c
delete mode 100644 drivers/net/wireless/iwmc3200wifi/umac.h
create mode 100644 net/wireless/ap.c
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ixgbevf - Prevent RX/TX statistics getting reset to zero
From: Jeff Kirsher @ 2012-07-12 18:26 UTC (permalink / raw)
To: Narendra_K, gregory.v.rose; +Cc: netdev
In-Reply-To: <E31FB011129F30488D5861F38390491520D00B9F01@BLRX7MCDC201.AMER.DELL.COM>
[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]
On 07/12/2012 06:55 AM, Narendra_K@Dell.com wrote:
> Hello,
>
> [Apologies if you are receiving this message twice. I am resending the message, as I got message delivery failure note].
>
> While exploring SR-IOV on Intel 82599EB 10-Gigabit SFP+ adapter, I had the following observation. I enabled two VFs by passing 'max_vfs=2' to ixgbe driver. One of the VFs was assigned to a guest.
> In the guest, the ifconfig and ip tools reported 'RX packets' and 'TX packets' as zero, after pinging to a remote host. Looking into it further, the commit 4197aa7bb81877ebb06e4f2cc1b5fea2da23a7bd implements 64 bit per ring statistics. It seemed like the 'total_bytes' and 'total_packets' of RX and TX ring were being reset to zero by the RX and TX interrupt handlers, resulting in the user space tools reporting zero RX and TX bytes.
>
> The attached patch addresses the issue by preventing the resetting of RX and TX ring statistics to zero. The patch was taken against latest mainline 3.5-rc6 kernel.
>
> I tested the patch by pinging from the guest OS to a remote host.
>
> ping -f <remote host> -c 10000
>
> The ip and ifcofig showed the statistics increased by 10000 packets.
>
> # lspci | grep 82599
> 04:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFP+ Network Connection (rev 01)
> 04:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFP+ Network Connection (rev 01)
> 04:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
> 04:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
> 04:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
> 04:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
>
> # lspci -s 04:00.0 -n
> 04:00.0 0200: 8086:154d (rev 01)
> # lspci -s 04:10.0 -n
> 04:10.0 0200: 8086:10ed (rev 01)
>
> Please let me know if additional details and logs are required.
>
> With regards,
> Narendra K
>
>
>
Thanks, I will add the patch to my queue
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply
* RE: 82571EB: Detected Hardware Unit Hang
From: Dave, Tushar N @ 2012-07-12 18:19 UTC (permalink / raw)
To: Joe Jin
Cc: e1000-devel@lists.sf.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4FFE787B.9050201@oracle.com>
>-----Original Message-----
>From: Joe Jin [mailto:joe.jin@oracle.com]
>Sent: Thursday, July 12, 2012 12:11 AM
>To: Dave, Tushar N
>Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>kernel@vger.kernel.org
>Subject: Re: 82571EB: Detected Hardware Unit Hang
>
>On 07/12/12 14:41, Dave, Tushar N wrote:
>>> On 07/12/12 13:57, Dave, Tushar N wrote:
>>>>> -----Original Message-----
>>>>> From: Joe Jin [mailto:joe.jin@oracle.com]
>>>>> Sent: Wednesday, July 11, 2012 8:13 PM
>>>>> To: Dave, Tushar N
>>>>> Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>>>>> kernel@vger.kernel.org
>>>>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>>>>
>>>>> On 07/12/12 11:07, Dave, Tushar N wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Joe Jin [mailto:joe.jin@oracle.com]
>>>>>>> Sent: Wednesday, July 11, 2012 7:58 PM
>>>>>>> To: Dave, Tushar N
>>>>>>> Cc: e1000-devel@lists.sf.net; netdev@vger.kernel.org; linux-
>>>>>>> kernel@vger.kernel.org
>>>>>>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>>>>>>
>>>>>>> On 07/12/12 10:52, Dave, Tushar N wrote:
>>>>>>>> What is the exact error messages in BIOS log?
>>>>>>>
>>>>>>> Error message from BIOS event log:
>>>>>>> 07/12/12 05:54:00
>>>>>>> PCI Express Non-Fatal Error
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>> Hi Tushar,
>>>>>
>>>>> Please find eeprom from attachment.
>>>>
>>>> Do you have lspci -vvv dump of entire system before and after issue
>>> occurs? If you have can you send it to me?
>>>>
>>>
>> Sorry but I meant the full lspci -vvv of *entire system* before and
>after issue occurs and not of 82571 only.
>>
>
>Before:
>=======
>00:00.0 Host bridge: Intel Corporation 5500 I/O Hub to ESI Port (rev 22)
> Subsystem: Oracle Corporation Device 5352
Joe, thanks for all the data.
You said you have changed max payload size and issue stop occurring. How did you change it? Where did you make that change in BIOS or EEPROM or in PCIe config space?
Also please send me the full dmesg of entire system after you change max payload size.
Thanks.
^ permalink raw reply
* RE: [patch] qlge: fix an "&&" vs "||" bug
From: Jitendra Kalsaria @ 2012-07-12 18:15 UTC (permalink / raw)
To: Dan Carpenter, Anirban Chakraborty
Cc: Ron Mercer, Dept-Eng Linux Driver, netdev,
kernel-janitors@vger.kernel.org
In-Reply-To: <20120712144702.GB24202@elgon.mountain>
-----Original Message-----
>From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
>Sent: Thursday, July 12, 2012 7:47 AM
>To: Anirban Chakraborty
>Cc: Jitendra Kalsaria; Ron Mercer; Dept-Eng Linux Driver; netdev; kernel-janitors@vger.kernel.org
>Subject: [patch] qlge: fix an "&&" vs "||" bug
>
>The condition is always true so WOL will never work.
>
>Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
>diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c b/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
>index 3d4462b..6f316ab 100644
>--- a/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
>+++ b/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
>@@ -440,7 +440,7 @@ static int ql_set_wol(struct net_device *ndev, struct ethtool_wolinfo *wol)
> unsigned short ssys_dev = qdev->pdev->subsystem_device;
>
> /* WOL is only supported for mezz card. */
>- if (ssys_dev != QLGE_MEZZ_SSYS_ID_068 ||
>+ if (ssys_dev != QLGE_MEZZ_SSYS_ID_068 &&
> ssys_dev != QLGE_MEZZ_SSYS_ID_180) {
> netif_info(qdev, drv, qdev->ndev,
> "WOL is only supported for mezz card\n");
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
^ 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