In the original code we allocated memory conditionally and freed it in
the error handling unconditionally.  It turns out that this function is
only called during initialization and "adapter->npars" and
"adapter->eswitch" are always NULL at the start of the function.  I
removed those checks.

Also since I was cleaning things, I changed the error handling for
qlcnic_get_pci_info() and pulled everything in an indent level.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix phy.c kernel-doc notation:

Warning(drivers/net/phy/phy.c:313): No description found for parameter 'ifr'
Warning(drivers/net/phy/phy.c:313): Excess function parameter 'mii_data' description in 'phy_mii_ioctl'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

drivers/net/wan/farsync.c: In function 'fst_intr_rx':
drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size
drivers/net/wan/farsync.c: In function 'do_bottom_half_tx':
drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size

The "skb" and "mem" arguments being passed here are DMA addresses
being programmed into the hardware registers, so pass them as the type
that they actually are.  And use the correct printf formatting in
debug logging statements for these things to match the type change.
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Based on patches from Sonny Rao and Milton Miller...

Combined the patches to fix up clean_tx_irq and clean_rx_irq.

The PowerPC architecture does not require loads to independent bytes
to be ordered without adding an explicit barrier.

In ixgbe_clean_rx_irq we load the status bit then load the packet data.
With packet split disabled if these loads go out of order we get a
stale packet, but we will notice the bad sequence numbers and drop it.

The problem occurs with packet split enabled where the TCP/IP header
and data are in different descriptors. If the reads go out of order
we may have data that doesn't match the TCP/IP header. Since we use
hardware checksumming this bad data is never verified and it makes it
all the way to the application.

This bug was found during stress testing and adding this barrier has
been shown to fix it.  The bug can manifest as a data integrity issue
(bad payload data) or as a BUG in skb_pull().

This was a nasty bug to hunt down, if people agree with the fix I think
it's a candidate for stable.

Previously Submitted to e1000-devel only for ixgbe

http://marc.info/?l=e1000-devel&m=126593062701537&w=3

We've now seen this problem hit with other device drivers (e1000e mostly)
So I'm resubmitting with fixes for other Intel Device Drivers with
similar issues.

CC: Milton Miller <miltonm@bga.com>
CC: Anton Blanchard <anton@samba.org>
CC: Sonny Rao <sonnyrao@us.ibm.com>
CC: stable <stable@kernel.org>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Building ixgbe without DCB_CONFIG and FCOE_CONFIG will cause
a build error.  This resolves the build error by wrapping
the fcoe.up in CONFIG_IXGBE_DCB ifdefs.

Also frames were being priority VLAN tagged even without DCB
enabled.  This fixes this so that 8021Q priority tags are
only added with DCB actually enabled.
Reported-by: Ndivya <dipraksh@linux.vnet.ibm.com>
Reported-by: NJon Mason <jon.mason@exar.com>
Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
Tested-by: NStephen Ko <stephen.s.ko@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAmit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I moved the kfree(cb) below the dereferences.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We should unlock here.  This is the only place where we return from the
function with the lock held.  The caller isn't expecting it.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We were seeing faults in the solos-pci receive tasklet when packets
arrived for a VCC which was currently being closed:

[18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684] SS:ESP 0068:dfb89d14 

[18845.090712] [<c13ecff3>] ? do_page_fault+0x0/0x2e1 
[18845.120042] [<e082f490>] ? br2684_push+0x19/0x234 [br2684] 
[18845.153530] [<e084fa13>] solos_bh+0x28b/0x7c8 [solos_pci] 
[18845.186488] [<e084f711>] ? solos_irq+0x2d/0x51 [solos_pci] 
[18845.219960] [<c100387b>] ? handle_irq+0x3b/0x48 
[18845.247732] [<c10265cb>] ? irq_exit+0x34/0x57 
[18845.274437] [<c1025720>] tasklet_action+0x42/0x69 
[18845.303247] [<c102643f>] __do_softirq+0x8e/0x129 
[18845.331540] [<c10264ff>] do_softirq+0x25/0x2a 
[18845.358274] [<c102664c>] _local_bh_enable_ip+0x5e/0x6a 
[18845.389677] [<c102666d>] local_bh_enable+0xb/0xe 
[18845.417944] [<e08490a8>] ppp_unregister_channel+0x32/0xbb [ppp_generic] 
[18845.458193] [<e08731ad>] pppox_unbind_sock+0x18/0x1f [pppox] 

This patch uses an RCU-inspired approach to fix it. In the RX tasklet's
find_vcc() function we first refuse to use a VCC which already has the
ATM_VF_READY bit cleared. And in the VCC close function, we synchronise
with the tasklet to ensure that it can't still be using the VCC before
we continue and allow the VCC to be destroyed.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Tested-by: NNathan Williams <nathan@traverse.com.au>
Cc: stable@kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

spin_is_locked() can return zero on some (UP?)
configurations because locks don't exist, and
that causes an endless amount of warnings. Use
lockdep_assert_held() instead, which has two
advantages:
 1) it verifies the current task is holding
    the lock or mutex
 2) it compiles away completely when lockdep
    is not enabled

Cc: stable@kernel.org [2.6.34+, maybe only parts of patch]
Reported-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The TX tracing code copies with the wrong length,
which will typically copy too little data. Fix
this by using the correct length variable.

Cc: stable@kernel.org [2.6.32+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The main motivation of this patch changing strcpy() to strlcpy().
We strcpy() to copy a 48 byte buffers into a 49 byte buffers.  So at
best the last byte has leaked information, or maybe there is an
overflow?  Anyway, this patch closes the information leaks by zeroing
the memory and the calls to strlcpy() prevent overflows.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

With turned on hspa modem (Dell 5530 internal card) and activated usb auto
suspend, my system gets up 100 "usbnet_resume has delayed data" per
minute. I didnt noticed any pathological behaviour, so just drop
this message. if any objections, please at least change it to _DEBUG.
Signed-off-by: NChristian Samsel <christian.samsel@rwth-aachen.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ieee80211_beacon_get can return NULL...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Cc: stable@kernel.org

Fix this leftover TODO from the cfg80211 conversion by doing a scan
if cfg80211 didn't pass in the BSSID for us.  Since the scan code
uses so much of the cfg80211_scan_request structure to build up the
firmware command, we just fake one when the scan request is triggered
internally.  But we need to make sure that internal 'fake' cfg82011
scan request does not get back to cfg82011 via cfg80211_scan_done().
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some APs get pissy if you don't send the firmware the extended rates
in the association request's rates TLV.  Found this on a Linksys
WRT54G v2; it denies association with status code 18 unless you
add the extended rates too.  The old driver did this, but it got
lost in the cfg80211 conversion.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Let's actually check the right field in the command response; and
if there aren't any reported BSSes, exit early with success.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I often use "ethtool -i" command to check what driver controls the
ehternet device.  But because current virtio_net driver doesn't
support "ethtool -i", it becomes the following:

        # ethtool -i eth3
        Cannot get driver information: Operation not supported

This patch simply adds the "ethtool -i" support. The following is the
result when using the virtio_net driver with my patch applied to.

        # ethtool -i eth3
        driver: virtio_net
        version: N/A
        firmware-version: N/A
        bus-info: virtio0

Personally, "-i" is one of the most frequently-used option, and most
network drivers support "ethtool -i", so I think virtio_net also
should do.
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (use ARRAY_SIZE)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The PPP channel ops structure should be const.
Cleanup the declarations to use standard C99 format.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

free_netdev finally calls kfree which makes the contents
of ndev and priv (private data contained in ndev) invalid.

So iounmap should be called before free_netdev.

Cc: David S. Miller <davem@davemloft.net>
Cc: Chaithrika U S <chaithrika@ti.com>
Cc: Sriramakrishnan <srk@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.

The semantic match that finds this problem is as follows:

// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@

(
* x->irq
|
* x->resource
|
* request(x, ...)
)
 ...
*pci_enable_device(x)
// </smpl>
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.

The semantic match that finds this problem is as follows:

// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@

(
* x->irq
|
* x->resource
|
* request(x, ...)
)
 ...
*pci_enable_device(x)
// </smpl>
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.

The semantic match that finds this problem is as follows:

// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@

(
* x->irq
|
* x->resource
|
* request(x, ...)
)
 ...
*pci_enable_device(x)
// </smpl>
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

82ca9341 added scary looking
but harmless error messages.  Make them clearer and make the
actual failure message show up with the same severity as the
harmless one.
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.

The semantic match that finds this problem is as follows:

// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@

(
* x->irq
|
* x->resource
|
* request(x, ...)
)
 ...
*pci_enable_device(x)
// </smpl>
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If kzalloc() fails return with -ENOMEM from ipw2100_net_init() which is
called by register_netdev.

CC: Dan Carpenter <error27@gmail.com>
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_rx_skb_preprocess nulls rxs and the mactime is never set again -
mactime is always 0. This causes problems in IBSS mode.

ieee80211_rx_bss_info uses mactime to decide if an IBSS merge is needed.
Without this patch the merge is triggered by each beacon received.

This can be recognized by the "beacon TSF higher than local TSF - IBSS
merge with BSSID" log message accompanying each beacon.

This problem was not completely fixed in commit
a6d2055b and is not a stable kernel fix.
It is solely intended for wireless-testing.
Signed-off-by: NJan Friedrich <jft@dev2day.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The SMC2802W appears to work with p54pci.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Tested-by: NDavid Cozatt <olbrannon@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I noticed a possible issue in the paused flag management of the
ath_atx_tid data structure. In particular, in a noisy environment and
under heavy load, I observed that the AGGR session establishment could
fail several times consecutively causing values of the paused flag
greater than one for this TID (ath_tx_pause_tid is called more than
once from ath_tx_aggr_start).

Considering that the session for this TID can not be established also
after the mac80211 stack calls the ieee80211_agg_tx_operational() since
the ath_tx_aggr_resume() lowers the paused flag only by one.

This patch also replaces some BUG_ON calls with WARN_ON, as even if
these unlikely conditions happen, it's not fatal enough to justify a
BUG_ON.
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9003 was not relying on the CTL indexes from the EEPROM for capping the
max output power. The CTL indexes from the EEPROM provide calibrated
limits for output power for each tested and supported frequency. Without
this the device operates at a power level which only conforms to the
transmit spectrum mask as specified by IEEE Annex I.2.3.

The regulatory limit by CRDA is always used but does not provide
calibrated values for optimal performance, specially on band edges.
Using the calibrated data from the EEPROM ensures the device
operates at optimal output power while still ensuring proper
regulatory compliance. The device uses the minimum of these tree
values, the value from CRDA, the calibrated value from CTL indexex,
and the value to conform to the IEEE transmit spectrum mask.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wl1271_dump() uses cmd after kfree(cmd). Move kfree() just after
wl1271_dump().
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Acked-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

small typo fix in ucode_bt_stats_read debugfs file
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is a uCode bug which cause the tx queue id not match scd_flow
in compressed block ack frame, and it need to be addressed in uCode.
Currently, driver will log the information when it happen.

Since it is possible happen very often and we do not want to fill the syslog,
so don't enable the logging by default.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When iwlwifi is compiled w/o debug, we get
this warning:
iwl-agn.c: In function ‘iwlagn_load_firmware’:
iwl-agn.c:2014: warning: passing argument 3 of ‘iwl_print_hex_dump’ discards qualifiers from pointer target type
iwl-debug.h:73: note: expected ‘void *’ but argument is of type ‘const u8 *’

because the const qualifier is missing in the
inline stub. Fix this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On AR5008-AR9002, other forms of calibration must not be started while
the noise floor calibration is running, as this can create invalid
readings which were sometimes not even recoverable by any further
calibration attempts.

This patch also ensures that the result of noise floor measurements
are processed faster and also allows the result of the initial
calibration on reset to make it into the NF history buffer
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The noise floor history buffer is currently not kept per channel, which
can lead to problems when changing channels from a clean channel to a
noisy one. Also when switching from HT20 to HT40, the noise floor
history buffer is full of measurements, but none of them contain data
for the extension channel, which it needs quite a bit of time to recover
from.

This patch puts all the per-channel calibration data into a single data
structure, and gives the the driver control over whether that is used
per-channel or even not used for some channels.

For ath9k_htc, I decided to keep this per-channel in order to avoid
creating regressions.

For ath9k, the data is kept only for the operating channel, which saves
some space. ath9k_hw takes care of wiping old data when the operating
channel or its channel flags change.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Previously the software scan callback was used to indicate to the hardware,
when it was safe to calibrate. This didn't really work properly, because it
depends on a specific order of software scan callbacks vs. channel changes.
Also, software scans are not the only thing that triggers off-channel
activity, so it's better to use the newly added indication from mac80211 for
this and not use the software scan callback for anything calibration related.

This fixes at least some of the invalid noise floor readings that I've seen
in AP mode on AR9160
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Writes to the analog shift registers, which are issues by the initval
programming function, require a 100 usec delay (similar to AR9002,
but in a different register range).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When updating the PAPRD table in hardware, PAPRD itself needs to be
disabled first, otherwise the hardware can throw a data bus error,
which upsets at least some platforms.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>