Noticed by sparse:
drivers/net/vmxnet3/vmxnet3_drv.c:876:38: warning: cast from restricted __be16
drivers/net/vmxnet3/vmxnet3_drv.c:876:38: warning: cast from restricted __be16
drivers/net/vmxnet3/vmxnet3_drv.c:876:24: warning: restricted __be16 degrades to integer
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
readl/writel swap to little-endian internally.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit a18135eb93 (Add UDP_MIB_{SND,RCV}BUFERRORS handling.)
forgot to make the necessary changes in net/ipv6/proc.c to report
additional counters in /proc/net/snmp6
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The marvell 88ec048's official part number is 88e1318s. This patch renames
definitions in the driver to reflect this.
In addition, a minor bug fix has been added to write back the MSCR1 register
value properly.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I noticed two small issues in mac80211/debugfs_key.c::key_key_read while
reading through the code. Patch below.
The key_key_read() function returns ssize_t and the value that's actually
returned is the return value of simple_read_from_buffer() which also
returns ssize_t, so let's hold the return value in a ssize_t local
variable rather than a int one.
Also, memory is allocated dynamically with kmalloc() which can fail, but
the return value of kmalloc() is not checked, so we may end up operating
on a null pointer further on. So check for a NULL return and bail out with
-ENOMEM in that case.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For the SD8686, we cannot rely on the scratch register to read the firmware
load status, because the same register is used for storing RX packet length.
Broaden the check to account for this.
The module can now be unloaded/reloaded successfully.
Based on the implementation from libertas_tf.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Steve deRosier <steve@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The index variable to access the rate flags should be obtained from the
inner loop counter which corresponds to the rate table structure.This
fixes the invalid rate selection i.e when the supported basic rate is
invalid on a particular band and also the following warning message.
Thanks to Raj for finding this out.
Call Trace:
[<ffffffff8104ee4a>] warn_slowpath_common+0x7a/0xb0
[<ffffffff8104ee95>] warn_slowpath_null+0x15/0x20
[<ffffffffa0583c45>] ath_get_rate+0x595/0x5b0 [ath9k]
[<ffffffff811a0636>] ? cpumask_next_and+0x36/0x50
[<ffffffffa0405186>] rate_control_get_rate+0x86/0x160 [mac80211]
[<ffffffffa040dfac>] invoke_tx_handlers+0x81c/0x12d0 [mac80211]
[<ffffffffa040eae9>] ieee80211_tx+0x89/0x2b0 [mac80211]
[<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0
[<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211]
[<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211]
[<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0
[<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211]
[<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211]
[<ffffffffa03f8896>] ieee80211_scan_work+0x146/0x600 [mac80211]
[<ffffffff8133a375>] ? schedule+0x2f5/0x8e0
[<ffffffffa03f8750>] ? ieee80211_scan_work+0x0/0x600 [mac80211]
[<ffffffff81064fcf>] process_one_work+0x10f/0x380
[<ffffffff81066bc2>] worker_thread+0x162/0x340
[<ffffffff81066a60>] ? worker_thread+0x0/0x340
Cc: stable@kernel.org
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Otherwise error indications from ipv6_find_hdr() won't be noticed.
This required making the protocol argument to extract_icmp6_fields()
signed too.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch enables and disables the rx and tx bits in the MAC control reg
by using a single write operation.
This also solves a possible problem (spotted on SPEAr platforms) at 10Mbps
where two consecutive writes to a MAC control register can take more than
4 phy_clk cycles.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/atarilance.c: In function ‘addr_accessible’:
drivers/net/atarilance.c:413: warning: comparison of distinct pointer types lacks a cast
drivers/net/atarilance.c:450: warning: comparison of distinct pointer types lacks a cast
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reset the whole hw instead of freeing hw resources
consumed by each pci function.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A program that accidentally writes too much data to the pktgen file can overflow
the kernel stack and oops the machine. This is only triggerable by root, so
there's no security issue, but it's still an unfortunate bug.
printk() won't print more than 1024 bytes in a single call, anyways, so let's
just never copy more than that much data. We're on a fairly shallow stack, so
that should be safe even with CONFIG_4KSTACKS.
Signed-off-by: Nelson Elhage <nelhage@ksplice.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This helps protect us from overflow issues down in the
individual protocol sendmsg/recvmsg handlers. Once
we hit INT_MAX we truncate out the rest of the iovec
by setting the iov_len members to zero.
This works because:
1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
writes are allowed and the application will just continue
with another write to send the rest of the data.
2) For datagram oriented sockets, where there must be a
one-to-one correspondance between write() calls and
packets on the wire, INT_MAX is going to be far larger
than the packet size limit the protocol is going to
check for and signal with -EMSGSIZE.
Based upon a patch by Linus Torvalds.
Signed-off-by: David S. Miller <davem@davemloft.net>
Crash is triggered by commit e6484930d7 ("net: allocate tx queues in
register_netdevice"), which moved tx netqueue creation into register_netdev.
So now calling netif_stop_queue() before register_netdev causes an oops.
Move netif_stop_queue() after net device registration to fix crash.
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
When we stop a namespace we flush the table and free one, but the
added fn_zone-s (and their hashes if grown) are leaked. Need to free.
Tries releases all its stuff in the flushing code.
Shame on us - this bug exists since the very first make-fib-per-net
patches in 2.6.27 :(
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Along the same lines as "cxgb4: fix crash due to manipulating queues
before registration" (8f6d9f4047), before
commit "net: allocate tx queues in register_netdevice"
netif_tx_stop_all_queues and related functions could be used between
device allocation and registration but now only after registration.
cxgb4 has such a call before registration and crashes now. Move it
after register_netdev.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: eric.dumazet@gmail.com
Cc: sonnyrao@us.ibm.com
Cc: Divy Le Ray <divy@chelsio.com>
Cc: Dimitris Michailidis <dm@chelsio.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
Acked-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The __NS8390_init tries to start the device queue before the
device is registered. This results in an oops (snipped):
[ 2.865493] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 2.866106] IP: [<ffffffffa000602a>] netif_start_queue+0xb/0x12 [8390]
[ 2.881267] Call Trace:
[ 2.881437] [<ffffffffa000624d>] __NS8390_init+0x102/0x15a [8390]
[ 2.881999] [<ffffffffa00062ae>] NS8390_init+0x9/0xb [8390]
[ 2.882237] [<ffffffffa000d820>] ne2k_pci_init_one+0x297/0x354 [ne2k_pci]
[ 2.882955] [<ffffffff811c7a0e>] local_pci_probe+0x12/0x16
[ 2.883308] [<ffffffff811c85ad>] pci_device_probe+0xc3/0xef
[ 2.884049] [<ffffffff8129218d>] driver_probe_device+0xbe/0x14b
[ 2.884937] [<ffffffff81292260>] __driver_attach+0x46/0x62
[ 2.885170] [<ffffffff81291788>] bus_for_each_dev+0x49/0x78
[ 2.885781] [<ffffffff81291fbb>] driver_attach+0x1c/0x1e
[ 2.886089] [<ffffffff812912ab>] bus_add_driver+0xba/0x227
[ 2.886330] [<ffffffff8129259a>] driver_register+0x9e/0x115
[ 2.886933] [<ffffffff811c8815>] __pci_register_driver+0x50/0xac
[ 2.887785] [<ffffffffa001102c>] ne2k_pci_init+0x2c/0x2e [ne2k_pci]
[ 2.888093] [<ffffffff81000212>] do_one_initcall+0x7c/0x130
[ 2.888693] [<ffffffff8106d74f>] sys_init_module+0x99/0x1da
[ 2.888946] [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b
This happens because the netif_start_queue sets respective bit on the dev->_tx
array which is not yet allocated.
As far as I understand the code removing the netif_start_queue from __NS8390_init
is OK, since queue will be started later on device open. Plz, correct me if I'm wrong.
Found in the Dave's current tree, so he's in Cc.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This updates CCID-2 to use the CCID dequeuing mechanism, converting from
previous continuous-polling to a now event-driven mechanism.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID, addressing the following problems:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID-2 to become unblocked
could lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID-3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case of __skb_queue_purge() after waiting for
the CCID. This is necessary since the write queue may still have data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch reorganises the return value convention of the CCID TX sending
function, to permit more flexible schemes, as required by subsequent patches.
Currently the convention is
* values < 0 mean error,
* a value == 0 means "send now", and
* a value x > 0 means "send in x milliseconds".
The patch provides symbolic constants and a function to interpret return values.
In addition, it caps the maximum positive return value to 0xFFFF milliseconds,
corresponding to 65.535 seconds. This is possible since in CCID-3/4 the
maximum possible inter-packet gap is fixed at t_mbi = 64 sec.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Introduced by commit:e6484930d7c73d324bccda7d43d131088da697b9
net: allocate tx queues in register_netdevice
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Acked-by: Greg Rose <greg.v.rose@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ixgb fails to work after reload on recent kernels:
rmmod ixgb (dev->current_state = PCI_UNKNOWN)
modprobe ixgb (pci_enable_device will bail leaving current_state to PCI_UNKNOWN)
ifup eth0
do_IRQ: 2.82 No irq handler for vector (irq -1)
The issue was exposed by commit fcd097f31a
PCI: MSI: Remove unsafe and unnecessary hardware access
which avoids HW writes for power states != PCI_D0
CC: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The DCB credits refill quantum _must_ be greater than half the max
packet size. This is needed to guarantee that TX DMA operations
are not attempted during a pause state. Additionally, the min IFG
must be set correctly for DCB mode. If a DMA operation is
requested unexpectedly during the pause state the HW data
store may be corrupted leading to a DMA hang. The DMA hang
requires a reset to correct. This fixes the HW configuration
to avoid this condition.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some parts need to execute resets during normal operation. This flag
check ensures that those parts reset without needlessly alarming the
user. Other unexpected resets by other parts will dump debug info
and message the reset action to the user, as originally intended.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some errors can be induced in the PHY via environmental testing
(specifically extreme temperature changes and electro static
discharge testing), and in the case of the PHY hanging due to
this input, this detects the problem and resets to continue.
This issue only applies to 82574 silicon.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit eab6d18d "vlan: Don't check for vlan group before
vlan_tx_tag_present" removed the need for the adapter variable
in igb_xmit_frame_ring_adv(). This removes the variable as well
to avoid the compiler warning.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(Applied over Eric's "ehea: fix use after free" patch)
Currently ehea stats are broken. The bytes counters are got from
the hardware, while the packets counters are got from the device
driver. Also, the device driver counters are resetted during the
the down process, and the hardware aren't, causing some weird
numbers.
This patch just consolidates the packets and bytes on the device
driver.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After making rcu protection for tunnels (ipip, gre, sit and ip6) a bug
was introduced into the SIOCCHGTUNNEL code.
The tunnel is first unlinked, then addresses change, then it is linked
back probably into another bucket. But while changing the parms, the
hash table is unlocked to readers and they can lookup the improper tunnel.
Respective commits are b7285b79 (ipip: get rid of ipip_lock), 1507850b
(gre: get rid of ipgre_lock), 3a43be3c (sit: get rid of ipip6_lock) and
94767632 (ip6tnl: get rid of ip6_tnl_lock).
The quick fix is to wait for quiescent state to pass after unlinking,
but if it is inappropriate I can invent something better, just let me
know.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If ath5k_hw_attach fails it will free sc->ah (local variable ah) before
returning. However, when it reports failure the caller (ath5k_pci_probe)
will also free sc->ah. Let the caller handle the deallocation, it does
so on further errors as well.
Signed-off-by: Jones Desougi <jones.desougi@27m.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 651b52254f added DS Parameter Set
information into Probe Request frames that are transmitted on 2.4 GHz
band, but it failed to increment local->scan_ies_len to cover this new
information. This variable needs to be updated to match the maximum IE
data length so that the extra buffer need gets reduced from the driver
limit.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Netgear WNDA3200 device uses ar7010 firmware but it is failed to set
correct firmware offset on firmware download which causes device initialization
failure.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Completing aggregate frames can lead to new buffers being pushed into
the tid queues due to software retransmission.
When the tx queues are being drained, all pending aggregates must be
completed before the tid queues get drained, otherwise buffers might be
leaked.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Apart from locking the start and stop PCU we need
to ensure we also content starting and stopping the PCU
between hardware resets.
This is part of a series that will help resolve the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=14624
For more details about this issue refer to:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The real way to lock RX is to contend on the PCU
and reset, this will be fixed in the next patch but for
now just do the renames so that the next patch which changes
the locking order is crystal clear.
This is part of a series that will help resolve the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=14624
For more details about this issue refer to:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There was some locking for starting some parts of
RX but not for starting the PCU. Include this otherwise
we can content against stopping the PCU.
This can potentially lead to races against different
buffers on the PCU which can lead to to the DMA RX
engine writing to buffers which are already freed.
This is part of a series that will help resolve the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=14624
For more details about this issue refer to:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k locks for starting RX but not for stopping RX. We could
potentially run into a situation where tried to stop RX
but immediately started RX. This allows for races on the
the RX engine deciding what buffer we last left off on
and could potentially cause ath9k to DMA into already
free'd memory or in the worst case at a later time to
already given memory to other drivers.
Fix this by locking stopping RX.
This is part of a series that will help resolve the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=14624
For more details about this issue refer to:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Delete successive assignments to the same location. In the first case, the
hscx array has two elements, so change the assignment to initialize the
second one. In the second case, the two assignments are simply identical.
Furthermore, neither is necessary, because the effect of the assignment is
only visible in the next line, in the assignment in the if test. The patch
inlines the right hand side value in the latter assignment and pulls that
assignment out of the if test.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression i;
@@
*i = ...;
i = ...;
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Delete successive assignments to the same location. The current definition
does not initialize the respRing structure, which has the same type as the
cmdRing structure, so initialize that one instead.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression i;
@@
*i = ...;
i = ...;
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: David Dillow <dave@thedillows.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The other code around these duplicated assignments initializes the 0 1 2
and 3 elements of an array, so change the initialization of the
rx_session_id array to do the same.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression i;
@@
*i = ...;
i = ...;
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
4095 vlan id is reserved and should not be use.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
