This driver adds WiFi support for Marvell 802.11n based chipsets
with SDIO interface. Currently only SD8787 is supported. More
chipsets will be supported later.

drivers/net/wireless/mwifiex/
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NMarc Yang <yangyang@marvell.com>
Signed-off-by: NRamesh Radhakrishnan <rramesh@marvell.com>
Signed-off-by: NFrank Huang <frankh@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Only AR9485 1.1 was sold. This debloats the driver by ~14 KiB.

   text    data     bss     dec     hex filename
 300413     624    1056  302093   49c0d drivers/net/wireless/ath/ath9k/ath9k_hw.ko

   text    data     bss     dec     hex filename
 310285     624    1056  311965   4c29d drivers/net/wireless/ath/ath9k/ath9k_hw-old.ko

$ du -b ath9k_hw*
6210541	ath9k_hw.ko
6225089	ath9k_hw-old.ko

Cc: Bill Wu <bill.wu@atheros.com>
Cc: Paul Shaw <paul.shaw@atheros.com>
Cc: Forbes Tsai <Forbes.Tsai@Atheros.com>
Cc: Jesmine Chen <jesmine.chen@atheros.com>
Cc: Marvian Chen <Hou-hua.Chen@Atheros.com>
Cc: Vivek Natarajan <vivek.natarajan@atheros.com>
Cc: Bernadette Yetso <bernadette.yetso@atheros.com>
Cc: Sarvesh Shrivastava <sarvesh.shrivastava@atheros.com>
Acked-by: NYi-Chen Su <yi-chen.su@atheros.com>
Acked-by: NJeffrey Chung <jeffrey.chung@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This workaround called ath_txq_schedule whenever there were still pending
frames for a queue, but the queue depth was zero. Because of its its high
false positive probability (e.g. with paused TIDs) and because it is in
the way of other pending work (AP powersave fixes), it is better to remove
this code entirely.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Most AR9100 devices already have a chainmask of 7 (three antennas), however
on the ones that don't (rx and tx chainmask set to 5), problems with IQ
mismatch calibration have been observed.
This shows up as tx queue hangs (and subsequent hardware resets) if traffic
is sent during this type of calibration.
Forcing the rx chainmask to 7 fixes the calibration issues with no apparent
negative side effects on throughput and stability.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fixes interop issues with aggregation in combination with multi-BSSID
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On some devices the correct MAC address is not in the EEPROM data, but
stored somewhere else.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some devices control antenna settings or other things through GPIO pins
of the wireless interface. Add a debugfs interface for changing those
and keeping them set across card resets.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since the ath9k debugfs directory is cleaned up by debugfs_remove_recursive,
there's no point in checking the return code of every single debugfs create
line.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Queue ADDBA requests in respective data queues to avoid ADDBA
requests and the the related data packets (to the same ra/tid)
queued in the hardware to be sent out asynchronously.
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If the outgoing packet rate to a particular HT station is <=6.5
Mbps, do not attempt to create an ampdu. Also, if the outgoing
rate is legacy rate, do not create an ampdu.
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When an ampdu stream is on, if the firmware rate adaptation
logic decides that the outgoing packet rate to the station needs
to go below 6.5Mbps (non HT rate), it sends an event indicating that
the ampdu stream needs to be destroyed. Handle this event in the driver
and destroy the ampdu stream so that the rate can go below 6.5Mbps
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Specifically, handle ampdu_action and attempt to start a BA
session on receiving the first qos packet from mac80211 for
transmission to a HT sta.  While the BA session is being created,
all the packets belonging to that stream will be dropped to
prevent sequence number mismatch at the recipient.

Contains contributions from:
Yogesh Powar <yogeshp@marvell.com>
Pradeep Nemavat <pnemavat@marvell.com>
Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In particular, we can now add, start, lookup, and remove streams.

Based on work by Nishant Sarmukadam <nishants@marvell.com> and
Pradeep Nemavat <pnemavat@marvell.com>.
Signed-off-by: NPradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We now have two different kinds of queues.  And the number of
AMPDU queues may vary.  So we must be clear about which queues we
are dealing with.  Note that when we report the number of queues
to mac80211, we only report the WMM queues.

Based on work by Yogesh Powar <yogeshp@marvell.com>.
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NPradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Firmware APIv2 adds the following enhancements:

-- capabilities are reported by the firmware
-- API supports up to 8 dedicated AMPDU streams
-- optional packet timestamping and expiration can be enabled.
   Specifically, packets that are queued in firmware for longer
   than 500ms will be dropped if this option is used.

Based on work by "Nishant Sarmukadam" <nishants@marvell.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Specifically, APIv2 will specify a variable number of AMPDU
queues in the MWL8K_CMD_GET_HW_SPEC.  So init the tx queues after
MWL8K_CMD_GET_HW_SPEC for ap fw.

Also, we make it safe to deinit queues that have not been init'd.
This happens if the mwl8k_get_hw_spec_ap routine fails, for
example.
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fine-tuning register write operation and avoid unnecessay
delays for ath9k_htc driver, saves hw reset time which
improves scanning time and also solves one of the following
scenario.

Sometimes the ACK is sent by STA for assoc response is not
seen at AP side. So the AP continues to send retry assoc
responses. At the STA side, since the assoc response was
already forwarded to mac80211, it proceeded to channel change
which in turns does chip reset.

In most of the cases the chip reset was completed before
max retries are reached at AP side. Hence STA can able to ACK
the retried frames again. But in clear environment these retries
are completed within shortspan of time.

Since ath9k_htc consumes more time for hw reset, this latency
is causing dissociation by AP due to max reties are reached.
This issue was originally reported with Cisco Aironet 1250 AP
in HT40 mode in noise free environment.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

By enabling buffered register write for ath9k_htc driver
avoids unnecessary dissociation while rekeying phase under
heavy traffic exchange.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Doing adc gain calibration for AR9287 chips is causing
throughput drops in HT40 mode. Remove ADC Gain from supported
calibration list.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We initialize exit_pending twice.  It's the second initialization which
is correct.  That was added in d745d472 "iwlwifi: cancel scan when
down the device".
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Scripted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

The current code sometimes generates build warnings due to how it checks
the silicon revision, so clean it up and properly document things.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The correct usage should be "static inline void" instead of "static void inline"
Signed-off-by: NG.Balaji <balajig81@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While testing the performance of different receive interrupt
coalescing settings on a single stream TCP benchmark, I noticed two
very different results. With rx-usecs=50, most of the time a
connection would hit 8280 Mbps but once in a while it would hit
9330 Mbps.

It turns out we are only applying the interrupt coalescing settings
to the first queue and whenever the rx hash would direct us onto
that queue we ran faster.

With this patch applied and rx-usecs=50, I get 9330 Mbps
consistently.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Acked-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After commit d5dbda23 "ethtool: Add
support for vlan accleration.", drivers that have NETIF_F_HW_VLAN_TX,
and/or NETIF_F_HW_VLAN_RX feature, but do not allow enable/disable vlan
acceleration via ethtool set_flags, always return -EINVAL from that
function. Fix by returning -EINVAL only if requested features do not
match current settings and can not be changed by driver.

Change any driver that define ethtool->set_flags to use
ethtool_invalid_flags() to avoid similar problems in the future
(also on drivers that do not have the problem).

Tested with modified (to reproduce this bug) myri10ge driver.

Cc: stable@kernel.org # 2.6.37+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The mlx4_en driver uses the combination stop_port/start_port
in a number of places.  Unfortunately that causes any promiscuous
mode settings on the hardware to be lost.

This patch fixes that problem.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The correct usage is "static inline void" not "static void inline".
Signed-off-by: NJavier Martinez Canillas <martinez.javier@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is proper style to include linux/foo.h instead asm/foo.h if both exist
Signed-off-by: NJavier Martinez Canillas <martinez.javier@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Two places in the kernel were doing skb->ip_summed = 0.

Change both to skb->ip_summed = CHECKSUM_NONE, which is more readable.
Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The jme driver uses the legacy PCI power management, so it has to do
some PCI-specific things in its ->suspend() and ->resume() callbacks,
which isn't necessary and should better be done by the PCI
sybsystem-level power management code.  It also doesn't use device
wakeup flags correctly.

Convert jme to the new PCI power management framework and make it
let the PCI subsystem take care of all the PCI-specific aspects of
device handling during system power transitions.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Avoid theoretical race condition regarding accessing dev->features
NETIF_F_LRO flag, which is illustrated below.

CPU1					CPU2

myri10ge_clean_rx_done():		myri10ge_set_flags():
					or
					myri10ge_set_rx_csum():

if (dev->features & NETIF_F_LRO)
        setup lro
					dev->features |= NETIF_F_LRO
					or
					dev->features &= ~NETIF_F_LRO;
if (dev->features & NETIF_F_LRO)
        flush lro

On the way reduce myri10ge_rx_done() number of arguments and calls by
moving mgp->small_bytes check into that function. That reduce code size

from:
   text	   data	    bss	    dec	    hex	filename
  36644	    248	    100	  36992	   9080	drivers/net/myri10ge/myri10ge.o

to:
   text	   data	    bss	    dec	    hex	filename
  36037	    247	    100	  36384	   8e20	drivers/net/myri10ge/myri10ge.o

on my i686 system, what should also make myri10ge_clean_rx_done()
being faster.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current SocketCAN implementation for the Bosch c_can cell doesn't
account the TX bytes correctly, because it calls
c_can_inval_msg_object() (which clears the msg ctrl register) before
reading the DLC value:

for (/* nix */; (priv->tx_next - priv->tx_echo) > 0; priv->tx_echo++) {
        msg_obj_no = get_tx_echo_msg_obj(priv);
        c_can_inval_msg_object(dev, 0, msg_obj_no);
        val = c_can_read_reg32(priv, &priv->regs->txrqst1);
        if (!(val & (1 << msg_obj_no))) {
                can_get_echo_skb(dev,
                                msg_obj_no - C_CAN_MSG_OBJ_TX_FIRST);
                stats->tx_bytes += priv->read_reg(priv,
                                &priv->regs->ifregs[0].msg_cntrl)
                                & IF_MCONT_DLC_MASK;
                stats->tx_packets++;
        }
}

So, we will always read 0 for the DLC value and "ifconfig" will report
*0* TX Bytes.

The fix is quite easy: Just move c_can_inval_msg_object() to the end of
the if() statement. So:
      * We only call c_can_inval_msg_object() if the message was
        actually transmitted
      * We read out the DLC value _before_ clearing the msg ctrl
        register
Signed-off-by: NJan Altenberg <jan@linutronix.de>
Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the check in the probe function whether a IRQ was supplied
to the driver. The original driver check the irq "struct resource *" against
<= 0. Use "platform_get_irq" instead.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch disables the one shot mode, until the driver has been fixed and
tested to support it.

> I'm quite sure I've seen a situation where msg_obj 17 "seemed" to be
> pending, while msg_obj 18 and 19 already have been transmitted. But
> in that case, I enabled ONESHOT for the can interface, which enables
> the DA mode (automatic retransmission is disabled).
Reported-by: NJan Altenberg <jan@linutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix section mismatch warning by renaming the pci_driver variable to a
recognized (whitelisted) name.

WARNING: drivers/net/pch_gbe/pch_gbe.o(.data+0x1f8): Section mismatch in reference from the variable pch_gbe_pcidev to the variable .devinit.rodata:pch_gbe_pcidev_id
The variable pch_gbe_pcidev references
the variable __devinitconst pch_gbe_pcidev_id
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Avoiding abuse of ethtool_drvinfo.driver field.
HW specific info can be retrieved using lspci.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>