* Re: [PATCH] checkpatch: add double empty line check
From: Eilon Greenstein @ 2012-11-17 11:12 UTC (permalink / raw)
To: Joe Perches; +Cc: David Rientjes, Andy Whitcroft, linux-kernel, netdev
In-Reply-To: <1353113454.2512.21.camel@joe-AO722>
On Fri, 2012-11-16 at 16:50 -0800, Joe Perches wrote:
Hi Joe, thanks for replying.
> On Fri, 2012-11-16 at 22:04 +0200, Eilon Greenstein wrote:
> > On Fri, 2012-11-16 at 11:55 -0800, David Rientjes wrote:
> > > On Fri, 16 Nov 2012, Eilon Greenstein wrote:
> > > This is fairly common in all the acpi code where variables declared in a
> > > function are separated from the code in a function.
> > >
> >
> > Indeed, I see that you do use it in some functions.
> >
> > Maybe we can limit it only to the networking tree (similar to the
> > networking comments style) or if the ACPI is the exception, we can apply
> > to all but ACPI.
>
> I'm not sure this should be done.
> Double line spacing has some utility and
> is pretty common.
Since adding double empty line can cause a patch to be rejected, we
should have an easy way to catch it before submitting.
> Perhaps make this a --strict/CHK option
> and also perhaps make sure this isn't
> emitted on consecutive lines.
Indeed, CHK makes more sense. I wanted to have a warning per redundant
line, but since it can be annoying when adding 3 or more empty lines
intentionally, I will issue one comment for consecutive lines.
v2 is on its way.
Thanks,
Eilon
^ permalink raw reply
* [PATCH v2] checkpatch: add double empty line check
From: Eilon Greenstein @ 2012-11-17 11:17 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Joe Perches, David Rientjes, linux-kernel, netdev
Changes from previous attempt:
- Use CHK instead of WARN
- Issue only one warning per empty lines block
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
scripts/checkpatch.pl | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 21a9f5d..13d264f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3579,6 +3579,14 @@ sub process {
WARN("EXPORTED_WORLD_WRITABLE",
"Exporting world writable files is usually an error. Consider more restrictive permissions.\n" . $herecurr);
}
+
+# check for double empty lines
+ if ($line =~ /^\+\s*$/ &&
+ ($rawlines[$linenr] =~ /^\s*$/ ||
+ $prevline =~ /^\+?\s*$/ && $rawlines[$linenr] !~ /^\+\s*$/)) {
+ CHK("DOUBLE_EMPTY_LINE",
+ "One empty line should be sufficient. Consider removing this one.\n" . $herecurr);
+ }
}
# If we have no input at all, then there is nothing to report on
--
1.7.9.5
^ permalink raw reply related
* Re: PROBLEM: freeze when resuming from suspend-to-ram
From: Francois Romieu @ 2012-11-17 10:57 UTC (permalink / raw)
To: Daniele Venzano; +Cc: medhefgo, netdev
In-Reply-To: <20121114211115.GD14880@ge.brownhat.org>
Thanks for Cc:ing Daniele.
Daniele Venzano <venza@brownhat.org> :
> On Sun, Nov 11, 2012 at 08:47:45PM +0100, medhefgo@web.de wrote:
[...]
> The patch is big and, while by looking at it nothing jumps to my eyes as
> clearly wrong, I currently do not have access to sis900 hardware to test
> it. Francois Romieu (in CC), who did the patch, perhaps can shed some light.
Nothing here. I'll search harder but I won't mind some brute force approach
at the same time.
Jan, is it ok if I split this changeset in smaller chunks to identify
which part bugs / triggers the problem ? If so please specify a kernel
version - linusish or stable - I should work with.
--
Ueimor
^ permalink raw reply
* [net-next patch] vxlan: remove unused variable.
From: Rami Rosen @ 2012-11-17 14:08 UTC (permalink / raw)
To: davem; +Cc: netdev, shemminger, Rami Rosen
This patch removes addrexceeded member from vxlan_dev struct as it is unused.
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
drivers/net/vxlan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 9814d67..288ad3a 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -117,7 +117,6 @@ struct vxlan_dev {
spinlock_t hash_lock;
unsigned int addrcnt;
unsigned int addrmax;
- unsigned int addrexceeded;
struct hlist_head fdb_head[FDB_HASH_SIZE];
};
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH v2 net-next] sctp: Add support to per-association statistics via a new SCTP_GET_ASSOC_STATS call
From: Neil Horman @ 2012-11-17 13:20 UTC (permalink / raw)
To: Thomas Graf
Cc: Michele Baldessari, linux-sctp, Vlad Yasevich, netdev,
David S. Miller
In-Reply-To: <20121116214742.GH10831@casper.infradead.org>
On Fri, Nov 16, 2012 at 09:47:42PM +0000, Thomas Graf wrote:
> On 11/16/12 at 11:39am, Neil Horman wrote:
> > Yes, I think this is good, I still don't like the idea of having to do these via
> > an ioctl, but I suppose it fits well enough.
>
> I'm with you on this. I have started scribbling notes on paper for
> a netlink based stats retriever. We should discuss this at some
> point making sure we get everyone on board with interests in this
> and solve this nice and clean for everyone to enjoy.
>
Agreed, I was also doodling out some protocol format and kernel API ideas for
this. We have a short week due to Thanksgiving here next week, but why don't I
email you after the holiday and we can exchange thoughts? I think a netlink
stats protocol would be a great way to solve the process-private/global access
problem.
> I guess the ioctl is the best we can do as long as we don't have
> the above.
>
Agreed, it will do, and if we do a good job with the kernel API for the netlink
idea above, maybe we can even inherit existing stats transparently.
Neil
^ permalink raw reply
* Re: PROBLEM: freeze when resuming from suspend-to-ram
From: Jan Janssen @ 2012-11-17 13:21 UTC (permalink / raw)
To: Francois Romieu; +Cc: Daniele Venzano, netdev
In-Reply-To: <20121117105702.GA25549@electric-eye.fr.zoreil.com>
Hi,
On Saturday 17 November 2012 11:57:02 you wrote:
> Jan, is it ok if I split this changeset in smaller chunks to identify
> which part bugs / triggers the problem ? If so please specify a kernel
> version - linusish or stable - I should work with.
I'd be glad to help you with that. The bug happens with 3.6.6 and with 3.7-
rc6. Pick one that suits you best, I can work with both.
Jan
^ permalink raw reply
* Re: [net-next patch] vxlan: remove unused variable.
From: Stephen Hemminger @ 2012-11-17 17:52 UTC (permalink / raw)
To: Rami Rosen; +Cc: davem, netdev
In-Reply-To: <1353161287-22493-1-git-send-email-ramirose@gmail.com>
On Sat, 17 Nov 2012 16:08:07 +0200
Rami Rosen <ramirose@gmail.com> wrote:
> This patch removes addrexceeded member from vxlan_dev struct as it is unused.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
> ---
> drivers/net/vxlan.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 9814d67..288ad3a 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -117,7 +117,6 @@ struct vxlan_dev {
> spinlock_t hash_lock;
> unsigned int addrcnt;
> unsigned int addrmax;
> - unsigned int addrexceeded;
>
> struct hlist_head fdb_head[FDB_HASH_SIZE];
> };
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Re: PROBLEM: freeze when resuming from suspend-to-ram
From: Francois Romieu @ 2012-11-17 19:20 UTC (permalink / raw)
To: Jan Janssen; +Cc: Daniele Venzano, netdev
In-Reply-To: <2582926.dI8WEMfVKW@brinja>
Jan Janssen <medhefgo@web.de> :
[...]
> I'd be glad to help you with that. The bug happens with 3.6.6 and with 3.7-
> rc6. Pick one that suits you best, I can work with both.
/me slaps head.
Please try the patch below against v3.7-rc6
diff --git a/drivers/net/ethernet/sis/sis900.c b/drivers/net/ethernet/sis/sis900.c
index fb9f6b3..edf5edb 100644
--- a/drivers/net/ethernet/sis/sis900.c
+++ b/drivers/net/ethernet/sis/sis900.c
@@ -2479,7 +2479,7 @@ static int sis900_resume(struct pci_dev *pci_dev)
netif_start_queue(net_dev);
/* Workaround for EDB */
- sis900_set_mode(ioaddr, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
+ sis900_set_mode(sis_priv, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
/* Enable all known interrupts by setting the interrupt mask. */
sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE);
^ permalink raw reply related
* RE:
From: UNITED NATION @ 2012-11-17 13:14 UTC (permalink / raw)
To: netdev
Contact Jacek Slotala of Bank Zachodni WBK Poland via his email address : 1744837202@qq.com for your UN Compensation draft worth $550,000.00
^ permalink raw reply
* Re: [PATCH v2 net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: Brian Haley @ 2012-11-17 21:58 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <50A71B50.3030603@parallels.com>
On 11/17/2012 12:06 AM, Pavel Emelyanov wrote:
>> @@ -4165,6 +4180,8 @@ static int dev_ifname(struct net *net, struct ifreq __user
>> *arg)
>>
>> strcpy(ifr.ifr_name, dev->name);
>> rcu_read_unlock();
>> + if (read_seqretry(&devnet_rename_seq, seq))
>> + goto retry;
>
> I believe it makes sense to make the seqcount protection as a separate patch
> with description of what may happen.
I asked about that before and Dave said he "wanted all the races resolved". At
best I could make this a series...
>> +retry:
>> + seq = read_seqbegin(&devnet_rename_seq);
>> + rcu_read_lock();
>> + dev = dev_get_by_index_rcu(net, sk->sk_bound_dev_if);
>
> The sk->sk_bound_dev_if might have changed to 0 while we did read_seqretry (or
> did the len check above, but the race window is smaller) and this code will
> report -ENODEV instead of zero lenght.
If there are two threads twiddling with the same socket like this the
application is broken in my mind.
-Brian
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Michael Richardson @ 2012-11-17 22:14 UTC (permalink / raw)
To: tcpdump-workers, Eric W. Biederman; +Cc: Ani Sinha, netdev, Francesco Ruggeri
In-Reply-To: <87mwyi9h1x.fsf@xmission.com>
[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]
Thank you for this reply.
>>>>> "Eric" == Eric W Biederman <ebiederm@xmission.com> writes:
Eric> I don't see any need to add any kernel code to allow checking
Eric> if vlan tags are stripped. Vlan headers are stripped on all
Eric> kernel interfaces today. Vlan headers have been stripped on
Eric> all but a handful of software interfaces for 6+ years. For
Eric> all kernels if the vlan header is stripped it is reported in
Eric> the auxdata, upon packet reception. Careful code should also
Eric> look for TP_STATUS_VLAN_VALID which allows for distinguishing
Eric> a striped vlan header of 0 from no vlan header.
I can regularly see vlan tags on raw dumps from the untagged ("eth0")
today, running 3.2 (debian stable):
obiwan-[~] mcr 4848 %sudo tcpdump -i eth0 -n -p -e | grep -i vlan
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:05:15.404909 38:60:77:38:e6:47 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 3800, p 0, ethertype ARP, Request who-has 172.30.42.1 tell 172.30.42.11, length 28
So, I'm curious about the statement that vlan tags have been stripped
for some time, because I don't see them stripped today. My desktop has
an Intel 82579V NIC in it...
Eric> For old kernels that do not support the new extensions it is
Eric> possible to generate code that looks at the ethernet header
Eric> and sees if the ethertype is 0x8100 and then does things with
Eric> it, but that will only work on a small handful of software
Eric> only interfaces.
at tcpdump.org, our concern is to release code that works on both new,
and what for kernel.org folks would be considered "ancient" systems,
such as Centos5/RHEL5 machines which are regularly still in production
in the field (sadly...), but often need the latest diagnostics.
What I hear you saying is that our existing code will work on older
kernels, and that once we have new code to use the VLAN tag extensions,
we should simply attempt to load it, and either it loads, or we get an
error, and we go back to the code we had before. That's great news.
The major concern is that if the 802.1q header is gone, although we can
retrieve it somehow (I'm not sure how the AUXDATA is presented on the
MMAP PF_PACKET interface...) we will have to reconstruct it in order to
save it properly to a savefile. Many entities, including most major
Network Telescopes (http://en.wikipedia.org/wiki/Network_telescope) use
libpcap (and often tcpdump itself) to capture packets on probe points,
and having good performance matters here...
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Daniel Borkmann @ 2012-11-17 23:16 UTC (permalink / raw)
To: Michael Richardson
Cc: tcpdump-workers, Eric W. Biederman, Ani Sinha, netdev,
Francesco Ruggeri
In-Reply-To: <12918.1353190488@obiwan.sandelman.ca>
On Sat, Nov 17, 2012 at 11:14 PM, Michael Richardson <mcr@sandelman.ca> wrote:
>
> Thank you for this reply.
>
>>>>>> "Eric" == Eric W Biederman <ebiederm@xmission.com> writes:
> Eric> I don't see any need to add any kernel code to allow checking
> Eric> if vlan tags are stripped. Vlan headers are stripped on all
> Eric> kernel interfaces today. Vlan headers have been stripped on
> Eric> all but a handful of software interfaces for 6+ years. For
> Eric> all kernels if the vlan header is stripped it is reported in
> Eric> the auxdata, upon packet reception. Careful code should also
> Eric> look for TP_STATUS_VLAN_VALID which allows for distinguishing
> Eric> a striped vlan header of 0 from no vlan header.
>
> I can regularly see vlan tags on raw dumps from the untagged ("eth0")
> today, running 3.2 (debian stable):
>
> obiwan-[~] mcr 4848 %sudo tcpdump -i eth0 -n -p -e | grep -i vlan
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 17:05:15.404909 38:60:77:38:e6:47 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 3800, p 0, ethertype ARP, Request who-has 172.30.42.1 tell 172.30.42.11, length 28
>
> So, I'm curious about the statement that vlan tags have been stripped
> for some time, because I don't see them stripped today. My desktop has
> an Intel 82579V NIC in it...
Speaking of netsniff-ng where we don't reconstruct VLAN headers, users
have reported that depending on the NIC/driver resp. ethtool setting,
they can come in stripped or not (in the pf_packet's rx_ring buffer).
However, I assume VLAN AUXDATA is always consistent (and so the
BPF/BPF JIT filtering).
> Eric> For old kernels that do not support the new extensions it is
> Eric> possible to generate code that looks at the ethernet header
> Eric> and sees if the ethertype is 0x8100 and then does things with
> Eric> it, but that will only work on a small handful of software
> Eric> only interfaces.
>
> at tcpdump.org, our concern is to release code that works on both new,
> and what for kernel.org folks would be considered "ancient" systems,
> such as Centos5/RHEL5 machines which are regularly still in production
> in the field (sadly...), but often need the latest diagnostics.
>
> What I hear you saying is that our existing code will work on older
> kernels, and that once we have new code to use the VLAN tag extensions,
> we should simply attempt to load it, and either it loads, or we get an
> error, and we go back to the code we had before. That's great news.
Yes, this should be handled in such a way.
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Eric W. Biederman @ 2012-11-17 23:33 UTC (permalink / raw)
To: Michael Richardson; +Cc: tcpdump-workers, Ani Sinha, netdev, Francesco Ruggeri
In-Reply-To: <12918.1353190488@obiwan.sandelman.ca>
Michael Richardson <mcr@sandelman.ca> writes:
> Thank you for this reply.
>
>>>>>> "Eric" == Eric W Biederman <ebiederm@xmission.com> writes:
> Eric> I don't see any need to add any kernel code to allow checking
> Eric> if vlan tags are stripped. Vlan headers are stripped on all
> Eric> kernel interfaces today. Vlan headers have been stripped on
> Eric> all but a handful of software interfaces for 6+ years. For
> Eric> all kernels if the vlan header is stripped it is reported in
> Eric> the auxdata, upon packet reception. Careful code should also
> Eric> look for TP_STATUS_VLAN_VALID which allows for distinguishing
> Eric> a striped vlan header of 0 from no vlan header.
>
> I can regularly see vlan tags on raw dumps from the untagged ("eth0")
> today, running 3.2 (debian stable):
>
> obiwan-[~] mcr 4848 %sudo tcpdump -i eth0 -n -p -e | grep -i vlan
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 17:05:15.404909 38:60:77:38:e6:47 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 3800, p 0, ethertype ARP, Request who-has 172.30.42.1 tell 172.30.42.11, length 28
>
> So, I'm curious about the statement that vlan tags have been stripped
> for some time, because I don't see them stripped today. My desktop has
> an Intel 82579V NIC in it...
So I just took a quick look at libpcap 1.1.1.1.
In pcap_read_packet in pcap-linux.c the code to readd the vlan header is
protected by HAVE_PACKET_AUXDATA.
In pcap_read_linux_mmap in pcap-linux.c the code to readd the vlan
header is protected by HAVE_TPACKET2.
That code is shifting the the ethernet header up 4 bytes and inserting
the vlan header in packets as we receive them.
The code is correct except for the case of packets in vlan 0. Currently
the packet reconstruction is ambiguous. The most recent kernels have
a TP_STATUS_VLAN_VALID flag that can be checked to see if the packet was
in vlan 0 or if there was no vlan at all. libpcap probably should be
taught how to handle TP_STATUS_VLAN_VALID so that it can get the vlan 0
handling correct.
> Eric> For old kernels that do not support the new extensions it is
> Eric> possible to generate code that looks at the ethernet header
> Eric> and sees if the ethertype is 0x8100 and then does things with
> Eric> it, but that will only work on a small handful of software
> Eric> only interfaces.
>
> at tcpdump.org, our concern is to release code that works on both new,
> and what for kernel.org folks would be considered "ancient" systems,
> such as Centos5/RHEL5 machines which are regularly still in production
> in the field (sadly...), but often need the latest diagnostics.
> What I hear you saying is that our existing code will work on older
> kernels, and that once we have new code to use the VLAN tag extensions,
> we should simply attempt to load it, and either it loads, or we get an
> error, and we go back to the code we had before. That's great news.
The existing code will work as well as anything if you don't have the
VLAN tag extensions. If you are not using the VLAN tag extensions there
is no reliable way to filter for vlan tagged packets in the kernel as on
most network devices (all for the last year) the vlan header has been
stripped at the time the bpf filter is run.
So yes. Just falling back to the existing code seems as good as it is
going to get. Which isn't very good but it took 5+ years before people
cared enough to get this fixed. :(
> The major concern is that if the 802.1q header is gone, although we can
> retrieve it somehow (I'm not sure how the AUXDATA is presented on the
> MMAP PF_PACKET interface...) we will have to reconstruct it in order to
> save it properly to a savefile. Many entities, including most major
> Network Telescopes (http://en.wikipedia.org/wiki/Network_telescope) use
> libpcap (and often tcpdump itself) to capture packets on probe points,
> and having good performance matters here...
Yes. I wasn't looking at the mmap path. The vlan information is
present in the tpacket2_hdr and tpacket3_hdr structures that accompany
packets read with the mmap interface. The old tpacket1_hdr doesn't
support the vlan_tci information so that won't work.
Not having the vlan header on the packet when the bpf filter is run is
justified by performance, and likewise reading vlan tagged packets to
userspace with the vlan header stripped is justified by performance.
Eric
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Eric W. Biederman @ 2012-11-17 23:37 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Michael Richardson, tcpdump-workers, Ani Sinha, netdev,
Francesco Ruggeri
In-Reply-To: <CAD6jFUQguS0oqGuA-HDFV2gd9m_=kZAvKJJq3ymr8zWM2cePXw@mail.gmail.com>
Daniel Borkmann <danborkmann@iogearbox.net> writes:
> Speaking of netsniff-ng where we don't reconstruct VLAN headers, users
> have reported that depending on the NIC/driver resp. ethtool setting,
> they can come in stripped or not (in the pf_packet's rx_ring buffer).
> However, I assume VLAN AUXDATA is always consistent (and so the
> BPF/BPF JIT filtering).
Yes it was a mess before we added software stripping of the vlan headers
a year ago.
Eric
^ permalink raw reply
* Re: [PATCH] sctp: use bitmap_weight
From: Vlad Yasevich @ 2012-11-18 1:45 UTC (permalink / raw)
To: Akinobu Mita; +Cc: linux-sctp, Sridhar Samudrala, netdev
In-Reply-To: <1353134389-25583-1-git-send-email-akinobu.mita@gmail.com>
On 11/17/2012 01:39 AM, Akinobu Mita wrote:
> Use bitmap_weight to count the total number of bits set in bitmap.
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Cc: Sridhar Samudrala <sri@us.ibm.com>
> Cc: linux-sctp@vger.kernel.org
> Cc: netdev@vger.kernel.org
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/tsnmap.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/net/sctp/tsnmap.c b/net/sctp/tsnmap.c
> index b5fb7c4..5f25e0c 100644
> --- a/net/sctp/tsnmap.c
> +++ b/net/sctp/tsnmap.c
> @@ -272,7 +272,7 @@ __u16 sctp_tsnmap_pending(struct sctp_tsnmap *map)
> __u32 max_tsn = map->max_tsn_seen;
> __u32 base_tsn = map->base_tsn;
> __u16 pending_data;
> - u32 gap, i;
> + u32 gap;
>
> pending_data = max_tsn - cum_tsn;
> gap = max_tsn - base_tsn;
> @@ -280,11 +280,7 @@ __u16 sctp_tsnmap_pending(struct sctp_tsnmap *map)
> if (gap == 0 || gap >= map->len)
> goto out;
>
> - for (i = 0; i < gap+1; i++) {
> - if (test_bit(i, map->tsn_map))
> - pending_data--;
> - }
> -
> + pending_data -= bitmap_weight(map->tsn_map, gap + 1);
> out:
> return pending_data;
> }
>
^ permalink raw reply
* Re: [PATCH] sctp: use bitmap_weight
From: David Miller @ 2012-11-18 3:01 UTC (permalink / raw)
To: vyasevich; +Cc: akinobu.mita, linux-sctp, sri, netdev
In-Reply-To: <50A83DAF.8000408@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Sat, 17 Nov 2012 20:45:19 -0500
> On 11/17/2012 01:39 AM, Akinobu Mita wrote:
>> Use bitmap_weight to count the total number of bits set in bitmap.
>>
>> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
>> Cc: Vlad Yasevich <vyasevich@gmail.com>
>> Cc: Sridhar Samudrala <sri@us.ibm.com>
>> Cc: linux-sctp@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next patch] vxlan: remove unused variable.
From: David Miller @ 2012-11-18 3:02 UTC (permalink / raw)
To: shemminger; +Cc: ramirose, netdev
In-Reply-To: <20121117095225.48bd9ab1@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 17 Nov 2012 09:52:25 -0800
> On Sat, 17 Nov 2012 16:08:07 +0200
> Rami Rosen <ramirose@gmail.com> wrote:
>
>> This patch removes addrexceeded member from vxlan_dev struct as it is unused.
>>
>> Signed-off-by: Rami Rosen <ramirose@gmail.com>
...
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] pch_gbe, ptp_pch: Fix the dependency direction between these drivers
From: David Miller @ 2012-11-18 3:12 UTC (permalink / raw)
To: rdunlap; +Cc: bhutchings, netdev, tshimizu818, richardcochran
In-Reply-To: <50A6F01C.4010304@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Fri, 16 Nov 2012 18:02:04 -0800
> On 11/16/2012 05:43 PM, Ben Hutchings wrote:
>
>> In commit a24006ed12616bde1bbdb26868495906a212d8dc ('ptp: Enable clock
>> drivers along with associated net/PHY drivers') I wrongly made
>> PTP_1588_CLOCK_PCH depend on PCH_GBE. The dependency is really the
>> other way around. Therefore make PCH_GBE select PTP_1588_CLOCK_PCH
>> and remove the 'default y' from the latter.
>>
>> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
>> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
>
> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next 1/2] PPC: net: bpf_jit_comp: add XOR instruction for BPF JIT
From: David Miller @ 2012-11-18 3:13 UTC (permalink / raw)
To: matt; +Cc: dxchgb, benh, netdev
In-Reply-To: <744A32A4-3F1F-4253-9ECB-59DBCC240847@ozlabs.org>
From: Matt Evans <matt@ozlabs.org>
Date: Sat, 17 Nov 2012 00:00:38 +0000
> Hi Daniel,
>
>
> On 08/11/2012, at 9:39 PM, Daniel Borkmann wrote:
>
>> This patch is a follow-up for patch "filter: add XOR instruction for use
>> with X/K" that implements BPF PowerPC JIT parts for the BPF XOR operation.
>>
>> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
>> Cc: Matt Evans <matt@ozlabs.org>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> ---
>> Disclaimer: uncompiled and untested, since I don't have a PPC machine,
>> but it should (hopefully) integrate cleanly; impl. after PPC instruction
>> reference.
>
> Unfortunately I can only compile and test this mentally, but it looks fine, instruction formats correct etc. Thanks!
>
>
> Acked-by: Matt Evans <matt@ozlabs.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] PPC: net: bpf_jit_comp: add VLAN instructions for BPF JIT
From: David Miller @ 2012-11-18 3:13 UTC (permalink / raw)
To: matt; +Cc: dxchgb, benh, netdev
In-Reply-To: <45EBCE3A-FE92-4A8D-B5D8-DED4E30DF419@ozlabs.org>
From: Matt Evans <matt@ozlabs.org>
Date: Sat, 17 Nov 2012 00:06:03 +0000
> Hi,
>
> On 08/11/2012, at 9:41 PM, Daniel Borkmann wrote:
>
>> This patch is a follow-up for patch "net: filter: add vlan tag access"
>> to support the new VLAN_TAG/VLAN_TAG_PRESENT accessors in BPF JIT.
>>
>> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
>> Cc: Matt Evans <matt@ozlabs.org>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> ---
>> Disclaimer: uncompiled and untested, since I don't have a PPC machine,
>> but it should (hopefully) integrate cleanly; impl. after PPC instruction
>> reference.
>
> And for this too,
>
> Acked-by: Matt Evans <matt@ozlabs.org>
>
> Sorry for the delay in reviewing this!
Applied, thanks for reviewing.
^ permalink raw reply
* [PATCH RFC 1/2] ixp4xx_eth: avoid calling dma_pool_create() with NULL dev
From: Xi Wang @ 2012-11-18 6:25 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: netdev, Xi Wang, Andrew Morton
Use &port->netdev->dev instead of NULL since dma_pool_create() doesn't
allow NULL dev.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
See also
https://lkml.org/lkml/2012/11/14/11
---
drivers/net/ethernet/xscale/ixp4xx_eth.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 98934bd..477d672 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -1102,10 +1102,12 @@ static int init_queues(struct port *port)
{
int i;
- if (!ports_open)
- if (!(dma_pool = dma_pool_create(DRV_NAME, NULL,
- POOL_ALLOC_SIZE, 32, 0)))
+ if (!ports_open) {
+ dma_pool = dma_pool_create(DRV_NAME, &port->netdev->dev,
+ POOL_ALLOC_SIZE, 32, 0);
+ if (!dma_pool)
return -ENOMEM;
+ }
if (!(port->desc_tab = dma_pool_alloc(dma_pool, GFP_KERNEL,
&port->desc_tab_phys)))
--
1.7.10.4
^ permalink raw reply related
* [PATCH RFC 2/2] ixp4xx_hss: avoid calling dma_pool_create() with NULL dev
From: Xi Wang @ 2012-11-18 6:25 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: netdev, Xi Wang, Andrew Morton
In-Reply-To: <1353219910-24690-1-git-send-email-xi.wang@gmail.com>
Use &port->netdev->dev instead of NULL since dma_pool_create() doesn't
allow NULL dev.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
See also
https://lkml.org/lkml/2012/11/14/11
---
drivers/net/wan/ixp4xx_hss.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
index 3f575af..e9a3da5 100644
--- a/drivers/net/wan/ixp4xx_hss.c
+++ b/drivers/net/wan/ixp4xx_hss.c
@@ -969,10 +969,12 @@ static int init_hdlc_queues(struct port *port)
{
int i;
- if (!ports_open)
- if (!(dma_pool = dma_pool_create(DRV_NAME, NULL,
- POOL_ALLOC_SIZE, 32, 0)))
+ if (!ports_open) {
+ dma_pool = dma_pool_create(DRV_NAME, &port->netdev->dev,
+ POOL_ALLOC_SIZE, 32, 0);
+ if (!dma_pool)
return -ENOMEM;
+ }
if (!(port->desc_tab = dma_pool_alloc(dma_pool, GFP_KERNEL,
&port->desc_tab_phys)))
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] qlcnic: fix sparse warnings
From: Sony Chacko @ 2012-11-18 7:04 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sony Chacko
In-Reply-To: <1353222279-15736-1-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
qlcnic_hw.c:1337:17: warning: cast removes address space of expression
qlcnic_hw.c:1337:17: warning: incorrect type in argument 2 (different address spaces)
qlcnic_hw.c:1337:17: expected void volatile [noderef] <asn:2>*addr
qlcnic_hw.c:1337:17: got void *<noident>
qlcnic_hw.c:1337:17: warning: cast removes address space of expression
qlcnic_hw.c:1337:17: warning: incorrect type in argument 1 (different address spaces)
qlcnic_hw.c:1337:17: expected void const volatile [noderef] <asn:2>*addr
qlcnic_hw.c:1337:17: got void *<noident>
The above warnings are originating from the macros QLCNIC_RD_DUMP_REG and
QLCNIC_WR_DUMP_REG.
The warnings are fixed and macros are replaced with equivalent functions
in the only file from where it is called.
The following warnings are fixed by making the functions static.
qlcnic_hw.c:543:5: warning: symbol 'qlcnic_set_fw_loopback' was not declared. Should it be static?
qlcnic_init.c:1853:6: warning: symbol 'qlcnic_process_rcv_diag' was not declared. Should it be static?
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h | 16 ----
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 98 +++++++++++++++---------
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 4 +-
3 files changed, 65 insertions(+), 53 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
index 28a6b28..bd5030e 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
@@ -792,22 +792,6 @@ static const u32 MIU_TEST_READ_DATA[] = {
#define QLCNIC_FLASH_SEM2_ULK 0x0013C014
#define QLCNIC_FLASH_LOCK_ID 0x001B2100
-#define QLCNIC_RD_DUMP_REG(addr, bar0, data) do { \
- writel((addr & 0xFFFF0000), (void *) (bar0 + \
- QLCNIC_FW_DUMP_REG1)); \
- readl((void *) (bar0 + QLCNIC_FW_DUMP_REG1)); \
- *data = readl((void *) (bar0 + QLCNIC_FW_DUMP_REG2 + \
- LSW(addr))); \
-} while (0)
-
-#define QLCNIC_WR_DUMP_REG(addr, bar0, data) do { \
- writel((addr & 0xFFFF0000), (void *) (bar0 + \
- QLCNIC_FW_DUMP_REG1)); \
- readl((void *) (bar0 + QLCNIC_FW_DUMP_REG1)); \
- writel(data, (void *) (bar0 + QLCNIC_FW_DUMP_REG2 + LSW(addr)));\
- readl((void *) (bar0 + QLCNIC_FW_DUMP_REG2 + LSW(addr))); \
-} while (0)
-
/* PCI function operational mode */
enum {
QLCNIC_MGMT_FUNC = 0,
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
index fc308c8..bd3e766 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
@@ -266,6 +266,33 @@ static const unsigned crb_hub_agt[64] = {
0,
};
+static void qlcnic_read_dump_reg(u32 addr, void __iomem *bar0, u32 *data)
+{
+ u32 dest;
+ void __iomem *window_reg;
+
+ dest = addr & 0xFFFF0000;
+ window_reg = bar0 + QLCNIC_FW_DUMP_REG1;
+ writel(dest, window_reg);
+ readl(window_reg);
+ window_reg = bar0 + QLCNIC_FW_DUMP_REG2 + LSW(addr);
+ *data = readl(window_reg);
+}
+
+static void qlcnic_write_dump_reg(u32 addr, void __iomem *bar0, u32 data)
+{
+ u32 dest;
+ void __iomem *window_reg;
+
+ dest = addr & 0xFFFF0000;
+ window_reg = bar0 + QLCNIC_FW_DUMP_REG1;
+ writel(dest, window_reg);
+ readl(window_reg);
+ window_reg = bar0 + QLCNIC_FW_DUMP_REG2 + LSW(addr);
+ writel(data, window_reg);
+ readl(window_reg);
+}
+
/* PCI Windowing for DDR regions. */
#define QLCNIC_PCIE_SEM_TIMEOUT 10000
@@ -540,7 +567,7 @@ void qlcnic_delete_lb_filters(struct qlcnic_adapter *adapter)
}
}
-int qlcnic_set_fw_loopback(struct qlcnic_adapter *adapter, u8 flag)
+static int qlcnic_set_fw_loopback(struct qlcnic_adapter *adapter, u8 flag)
{
struct qlcnic_nic_req req;
int rv;
@@ -1334,7 +1361,7 @@ qlcnic_dump_crb(struct qlcnic_adapter *adapter, struct qlcnic_dump_entry *entry,
addr = crb->addr;
for (i = 0; i < crb->no_ops; i++) {
- QLCNIC_RD_DUMP_REG(addr, base, &data);
+ qlcnic_read_dump_reg(addr, base, &data);
*buffer++ = cpu_to_le32(addr);
*buffer++ = cpu_to_le32(data);
addr += crb->stride;
@@ -1364,25 +1391,25 @@ qlcnic_dump_ctrl(struct qlcnic_adapter *adapter,
continue;
switch (1 << k) {
case QLCNIC_DUMP_WCRB:
- QLCNIC_WR_DUMP_REG(addr, base, ctr->val1);
+ qlcnic_write_dump_reg(addr, base, ctr->val1);
break;
case QLCNIC_DUMP_RWCRB:
- QLCNIC_RD_DUMP_REG(addr, base, &data);
- QLCNIC_WR_DUMP_REG(addr, base, data);
+ qlcnic_read_dump_reg(addr, base, &data);
+ qlcnic_write_dump_reg(addr, base, data);
break;
case QLCNIC_DUMP_ANDCRB:
- QLCNIC_RD_DUMP_REG(addr, base, &data);
- QLCNIC_WR_DUMP_REG(addr, base,
- (data & ctr->val2));
+ qlcnic_read_dump_reg(addr, base, &data);
+ qlcnic_write_dump_reg(addr, base,
+ data & ctr->val2);
break;
case QLCNIC_DUMP_ORCRB:
- QLCNIC_RD_DUMP_REG(addr, base, &data);
- QLCNIC_WR_DUMP_REG(addr, base,
- (data | ctr->val3));
+ qlcnic_read_dump_reg(addr, base, &data);
+ qlcnic_write_dump_reg(addr, base,
+ data | ctr->val3);
break;
case QLCNIC_DUMP_POLLCRB:
while (timeout <= ctr->timeout) {
- QLCNIC_RD_DUMP_REG(addr, base, &data);
+ qlcnic_read_dump_reg(addr, base, &data);
if ((data & ctr->val2) == ctr->val1)
break;
msleep(1);
@@ -1397,7 +1424,7 @@ qlcnic_dump_ctrl(struct qlcnic_adapter *adapter,
case QLCNIC_DUMP_RD_SAVE:
if (ctr->index_a)
addr = t_hdr->saved_state[ctr->index_a];
- QLCNIC_RD_DUMP_REG(addr, base, &data);
+ qlcnic_read_dump_reg(addr, base, &data);
t_hdr->saved_state[ctr->index_v] = data;
break;
case QLCNIC_DUMP_WRT_SAVED:
@@ -1407,7 +1434,7 @@ qlcnic_dump_ctrl(struct qlcnic_adapter *adapter,
data = ctr->val1;
if (ctr->index_a)
addr = t_hdr->saved_state[ctr->index_a];
- QLCNIC_WR_DUMP_REG(addr, base, data);
+ qlcnic_write_dump_reg(addr, base, data);
break;
case QLCNIC_DUMP_MOD_SAVE_ST:
data = t_hdr->saved_state[ctr->index_v];
@@ -1441,8 +1468,8 @@ qlcnic_dump_mux(struct qlcnic_adapter *adapter, struct qlcnic_dump_entry *entry,
val = mux->val;
for (loop = 0; loop < mux->no_ops; loop++) {
- QLCNIC_WR_DUMP_REG(mux->addr, base, val);
- QLCNIC_RD_DUMP_REG(mux->read_addr, base, &data);
+ qlcnic_write_dump_reg(mux->addr, base, val);
+ qlcnic_read_dump_reg(mux->read_addr, base, &data);
*buffer++ = cpu_to_le32(val);
*buffer++ = cpu_to_le32(data);
val += mux->val_stride;
@@ -1463,10 +1490,10 @@ qlcnic_dump_que(struct qlcnic_adapter *adapter, struct qlcnic_dump_entry *entry,
cnt = que->read_addr_cnt;
for (loop = 0; loop < que->no_ops; loop++) {
- QLCNIC_WR_DUMP_REG(que->sel_addr, base, que_id);
+ qlcnic_write_dump_reg(que->sel_addr, base, que_id);
addr = que->read_addr;
for (i = 0; i < cnt; i++) {
- QLCNIC_RD_DUMP_REG(addr, base, &data);
+ qlcnic_read_dump_reg(addr, base, &data);
*buffer++ = cpu_to_le32(data);
addr += que->read_addr_stride;
}
@@ -1514,9 +1541,9 @@ lock_try:
writel(adapter->ahw->pci_func, (base + QLCNIC_FLASH_LOCK_ID));
for (i = 0; i < size; i++) {
addr = fl_addr & 0xFFFF0000;
- QLCNIC_WR_DUMP_REG(FLASH_ROM_WINDOW, base, addr);
+ qlcnic_write_dump_reg(FLASH_ROM_WINDOW, base, addr);
addr = LSW(fl_addr) + FLASH_ROM_DATA;
- QLCNIC_RD_DUMP_REG(addr, base, &val);
+ qlcnic_read_dump_reg(addr, base, &val);
fl_addr += 4;
*buffer++ = cpu_to_le32(val);
}
@@ -1536,12 +1563,12 @@ qlcnic_dump_l1_cache(struct qlcnic_adapter *adapter,
val = l1->init_tag_val;
for (i = 0; i < l1->no_ops; i++) {
- QLCNIC_WR_DUMP_REG(l1->addr, base, val);
- QLCNIC_WR_DUMP_REG(l1->ctrl_addr, base, LSW(l1->ctrl_val));
+ qlcnic_write_dump_reg(l1->addr, base, val);
+ qlcnic_write_dump_reg(l1->ctrl_addr, base, LSW(l1->ctrl_val));
addr = l1->read_addr;
cnt = l1->read_addr_num;
while (cnt) {
- QLCNIC_RD_DUMP_REG(addr, base, &data);
+ qlcnic_read_dump_reg(addr, base, &data);
*buffer++ = cpu_to_le32(data);
addr += l1->read_addr_stride;
cnt--;
@@ -1566,14 +1593,14 @@ qlcnic_dump_l2_cache(struct qlcnic_adapter *adapter,
poll_to = MSB(MSW(l2->ctrl_val));
for (i = 0; i < l2->no_ops; i++) {
- QLCNIC_WR_DUMP_REG(l2->addr, base, val);
+ qlcnic_write_dump_reg(l2->addr, base, val);
if (LSW(l2->ctrl_val))
- QLCNIC_WR_DUMP_REG(l2->ctrl_addr, base,
- LSW(l2->ctrl_val));
+ qlcnic_write_dump_reg(l2->ctrl_addr, base,
+ LSW(l2->ctrl_val));
if (!poll_mask)
goto skip_poll;
do {
- QLCNIC_RD_DUMP_REG(l2->ctrl_addr, base, &data);
+ qlcnic_read_dump_reg(l2->ctrl_addr, base, &data);
if (!(data & poll_mask))
break;
msleep(1);
@@ -1590,7 +1617,7 @@ skip_poll:
addr = l2->read_addr;
cnt = l2->read_addr_num;
while (cnt) {
- QLCNIC_RD_DUMP_REG(addr, base, &data);
+ qlcnic_read_dump_reg(addr, base, &data);
*buffer++ = cpu_to_le32(data);
addr += l2->read_addr_stride;
cnt--;
@@ -1622,13 +1649,13 @@ qlcnic_read_memory(struct qlcnic_adapter *adapter,
mutex_lock(&adapter->ahw->mem_lock);
while (reg_read != 0) {
- QLCNIC_WR_DUMP_REG(MIU_TEST_ADDR_LO, base, addr);
- QLCNIC_WR_DUMP_REG(MIU_TEST_ADDR_HI, base, 0);
- QLCNIC_WR_DUMP_REG(MIU_TEST_CTR, base,
- TA_CTL_ENABLE | TA_CTL_START);
+ qlcnic_write_dump_reg(MIU_TEST_ADDR_LO, base, addr);
+ qlcnic_write_dump_reg(MIU_TEST_ADDR_HI, base, 0);
+ qlcnic_write_dump_reg(MIU_TEST_CTR, base,
+ TA_CTL_ENABLE | TA_CTL_START);
for (i = 0; i < MAX_CTL_CHECK; i++) {
- QLCNIC_RD_DUMP_REG(MIU_TEST_CTR, base, &test);
+ qlcnic_read_dump_reg(MIU_TEST_CTR, base, &test);
if (!(test & TA_CTL_BUSY))
break;
}
@@ -1641,7 +1668,8 @@ qlcnic_read_memory(struct qlcnic_adapter *adapter,
}
}
for (i = 0; i < 4; i++) {
- QLCNIC_RD_DUMP_REG(MIU_TEST_READ_DATA[i], base, &data);
+ qlcnic_read_dump_reg(MIU_TEST_READ_DATA[i], base,
+ &data);
*buffer++ = cpu_to_le32(data);
}
addr += 16;
@@ -1661,7 +1689,7 @@ qlcnic_dump_nop(struct qlcnic_adapter *adapter,
return 0;
}
-struct qlcnic_dump_operations fw_dump_ops[] = {
+static const struct qlcnic_dump_operations fw_dump_ops[] = {
{ QLCNIC_DUMP_NOP, qlcnic_dump_nop },
{ QLCNIC_DUMP_READ_CRB, qlcnic_dump_crb },
{ QLCNIC_DUMP_READ_MUX, qlcnic_dump_mux },
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index faae9c5..a7f5bbe 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -1849,8 +1849,8 @@ static void dump_skb(struct sk_buff *skb, struct qlcnic_adapter *adapter)
}
}
-void qlcnic_process_rcv_diag(struct qlcnic_adapter *adapter, int ring,
- u64 sts_data0)
+static void qlcnic_process_rcv_diag(struct qlcnic_adapter *adapter, int ring,
+ u64 sts_data0)
{
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
struct sk_buff *skb;
--
1.8.0
^ permalink raw reply related
* [PATCH 1/2] qlcnic: fix compiler warnings
From: Sony Chacko @ 2012-11-18 7:04 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sony Chacko
In-Reply-To: <1353222279-15736-1-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Fix the following warnings:
qlcnic_main.c: In function 'qlcnic_update_cmd_producer':
qlcnic_main.c:119:51: warning: unused parameter 'adapter' [-Wunused-parameter]
qlcnic_main.c:119: warning: unused parameter adapter
qlcnic_init.c: In function qlcnic_process_lro
qlcnic_init.c:1586: warning: unused parameter sds_ring
qlcnic_init.c: In function qlcnic_process_rcv_diag
qlcnic_init.c:1854: warning: unused parameter sds_ring
qlcnic_init.c: In function qlcnic_fetch_mac
qlcnic_init.c:1938: warning: unused parameter adapter
warning: 'pci_using_dac' may be used uninitialized in this function [-Wmaybe-uninitialized]
qlcnic_main.c:1569:10: note: 'pci_using_dac' was declared here
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 5 ++---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 16 ++++++----------
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 17 +++++++----------
5 files changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index eaa1db9..8b3d3b3 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -1530,9 +1530,8 @@ int qlcnic_set_features(struct net_device *netdev, netdev_features_t features);
int qlcnic_config_hw_lro(struct qlcnic_adapter *adapter, int enable);
int qlcnic_config_bridged_mode(struct qlcnic_adapter *adapter, u32 enable);
int qlcnic_send_lro_cleanup(struct qlcnic_adapter *adapter);
-void qlcnic_update_cmd_producer(struct qlcnic_adapter *adapter,
- struct qlcnic_host_tx_ring *tx_ring);
-void qlcnic_fetch_mac(struct qlcnic_adapter *, u32, u32, u8, u8 *);
+void qlcnic_update_cmd_producer(struct qlcnic_host_tx_ring *);
+void qlcnic_fetch_mac(u32, u32, u8, u8 *);
void qlcnic_process_rcv_ring_diag(struct qlcnic_host_sds_ring *sds_ring);
void qlcnic_clear_lb_mode(struct qlcnic_adapter *adapter);
int qlcnic_set_lb_mode(struct qlcnic_adapter *adapter, u8 mode);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index 2a179d0..bbd3b30 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -671,7 +671,7 @@ int qlcnic_get_mac_address(struct qlcnic_adapter *adapter, u8 *mac)
err = cmd.rsp.cmd;
if (err == QLCNIC_RCODE_SUCCESS)
- qlcnic_fetch_mac(adapter, cmd.rsp.arg1, cmd.rsp.arg2, 0, mac);
+ qlcnic_fetch_mac(cmd.rsp.arg1, cmd.rsp.arg2, 0, mac);
else {
dev_err(&adapter->pdev->dev,
"Failed to get mac address%d\n", err);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
index 2a0c9dc..fc308c8 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
@@ -350,7 +350,7 @@ qlcnic_send_cmd_descs(struct qlcnic_adapter *adapter,
tx_ring->producer = producer;
- qlcnic_update_cmd_producer(adapter, tx_ring);
+ qlcnic_update_cmd_producer(tx_ring);
__netif_tx_unlock_bh(tx_ring->txq);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index 0bcda9c..faae9c5 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -1583,7 +1583,6 @@ qlcnic_process_rcv(struct qlcnic_adapter *adapter,
static struct qlcnic_rx_buffer *
qlcnic_process_lro(struct qlcnic_adapter *adapter,
- struct qlcnic_host_sds_ring *sds_ring,
int ring, u64 sts_data0, u64 sts_data1)
{
struct net_device *netdev = adapter->netdev;
@@ -1698,8 +1697,8 @@ qlcnic_process_rcv_ring(struct qlcnic_host_sds_ring *sds_ring, int max)
case QLCNIC_LRO_DESC:
ring = qlcnic_get_lro_sts_type(sts_data0);
sts_data1 = le64_to_cpu(desc->status_desc_data[1]);
- rxbuf = qlcnic_process_lro(adapter, sds_ring,
- ring, sts_data0, sts_data1);
+ rxbuf = qlcnic_process_lro(adapter, ring, sts_data0,
+ sts_data1);
break;
case QLCNIC_RESPONSE_DESC:
qlcnic_handle_fw_message(desc_cnt, consumer, sds_ring);
@@ -1850,9 +1849,8 @@ static void dump_skb(struct sk_buff *skb, struct qlcnic_adapter *adapter)
}
}
-void qlcnic_process_rcv_diag(struct qlcnic_adapter *adapter,
- struct qlcnic_host_sds_ring *sds_ring,
- int ring, u64 sts_data0)
+void qlcnic_process_rcv_diag(struct qlcnic_adapter *adapter, int ring,
+ u64 sts_data0)
{
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
struct sk_buff *skb;
@@ -1920,7 +1918,7 @@ qlcnic_process_rcv_ring_diag(struct qlcnic_host_sds_ring *sds_ring)
break;
default:
ring = qlcnic_get_sts_type(sts_data0);
- qlcnic_process_rcv_diag(adapter, sds_ring, ring, sts_data0);
+ qlcnic_process_rcv_diag(adapter, ring, sts_data0);
break;
}
@@ -1934,9 +1932,7 @@ qlcnic_process_rcv_ring_diag(struct qlcnic_host_sds_ring *sds_ring)
writel(consumer, sds_ring->crb_sts_consumer);
}
-void
-qlcnic_fetch_mac(struct qlcnic_adapter *adapter, u32 off1, u32 off2,
- u8 alt_mac, u8 *mac)
+void qlcnic_fetch_mac(u32 off1, u32 off2, u8 alt_mac, u8 *mac)
{
u32 mac_low, mac_high;
int i;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 24ad17e..4109a41 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -115,9 +115,7 @@ static DEFINE_PCI_DEVICE_TABLE(qlcnic_pci_tbl) = {
MODULE_DEVICE_TABLE(pci, qlcnic_pci_tbl);
-inline void
-qlcnic_update_cmd_producer(struct qlcnic_adapter *adapter,
- struct qlcnic_host_tx_ring *tx_ring)
+inline void qlcnic_update_cmd_producer(struct qlcnic_host_tx_ring *tx_ring)
{
writel(tx_ring->producer, tx_ring->crb_cmd_producer);
}
@@ -1485,8 +1483,8 @@ qlcnic_reset_context(struct qlcnic_adapter *adapter)
}
static int
-qlcnic_setup_netdev(struct qlcnic_adapter *adapter,
- struct net_device *netdev, u8 pci_using_dac)
+qlcnic_setup_netdev(struct qlcnic_adapter *adapter, struct net_device *netdev,
+ int pci_using_dac)
{
int err;
struct pci_dev *pdev = adapter->pdev;
@@ -1506,7 +1504,7 @@ qlcnic_setup_netdev(struct qlcnic_adapter *adapter,
if (adapter->capabilities & QLCNIC_FW_CAPABILITY_TSO)
netdev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
- if (pci_using_dac)
+ if (pci_using_dac == 1)
netdev->hw_features |= NETIF_F_HIGHDMA;
netdev->vlan_features = netdev->hw_features;
@@ -1530,7 +1528,7 @@ qlcnic_setup_netdev(struct qlcnic_adapter *adapter,
return 0;
}
-static int qlcnic_set_dma_mask(struct pci_dev *pdev, u8 *pci_using_dac)
+static int qlcnic_set_dma_mask(struct pci_dev *pdev, int *pci_using_dac)
{
if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
!pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64)))
@@ -1564,9 +1562,8 @@ qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
struct net_device *netdev = NULL;
struct qlcnic_adapter *adapter = NULL;
- int err;
+ int err, pci_using_dac = -1;
uint8_t revision_id;
- uint8_t pci_using_dac;
char brd_name[QLCNIC_MAX_BOARD_NAME_LEN];
err = pci_enable_device(pdev);
@@ -2337,7 +2334,7 @@ qlcnic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
adapter->stats.txbytes += skb->len;
adapter->stats.xmitcalled++;
- qlcnic_update_cmd_producer(adapter, tx_ring);
+ qlcnic_update_cmd_producer(tx_ring);
return NETDEV_TX_OK;
--
1.8.0
^ permalink raw reply related
* [PATCH 0/2] qlcnic: fix warnings
From: Sony Chacko @ 2012-11-18 7:04 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sony Chacko
From: Sony Chacko <sony.chacko@qlogic.com>
Please apply to net-next.
Thanks,
Sony
^ 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