net: get rid of SET_ETHTOOL_OPS
Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone.
This does that.
Mostly done via coccinelle script:
@@
struct ethtool_ops *ops;
struct net_device *dev;
@@
- SET_ETHTOOL_OPS(dev, ops);
+ dev->ethtool_ops = ops;
Compile tested only, but I'd seriously wonder if this broke anything.
Suggested-by: Dave Miller <davem@davemloft.net>
Signed-off-by: Wilfried Klaebe <w-lkml@lebenslange-mailadresse.de>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Conflicts:
drivers/net/ethernet/altera/altera_sgdma.c
net/netlink/af_netlink.c
net/sched/cls_api.c
net/sched/sch_api.c
The netlink conflict dealt with moving to netlink_capable() and
netlink_ns_capable() in the 'net' tree vs. supporting 'tc' operations
in non-init namespaces. These were simple transformations from
netlink_capable to netlink_ns_capable.
The Altera driver conflict was simply code removal overlapping some
void pointer cast cleanups in net-next.
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes: a53268be0c ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Cc: stable@vger.kernel.org
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Beginning with kernel 3.13, this driver fails on some systems. The problem
was bisected to:
Commit 1bf4bbb402
Author: Felix Fietkau <nbd@openwrt.org>
Title: mac80211: send control port protocol frames to the VO queue
There is noting wrong with the above commit. The regression occurs because
V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to
modify the rtl8192se routine that sets the correct transmit queue.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=74541
Reported-by: Alex Miller <almiller_1@yahoo.co.uk>
Tested-by: Alex Miller <almiller_1@yahoo.co.uk>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [3.13+]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adjust FIR filter co-efficients to improve EVM for 11b rates.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rfsat gainchange hysteresis of rf_gain stuck with large
interference present.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I was reading ath5k power setting code and
noticed typing error in ath5k_hw_txpower function.
Invalid value was written to AR5K_PHY_TXPOWER_RATE_MAX
register.
Signed-off-by: Nikolay Ledovskikh <nledovskikh@gmail.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Coverity CID 986698 reports leakage of struct wlcore_platdev_data in the
probe functions of both the SPI/SDIO interfaces. The structure passed to
platform_device_add_data() is dynamically allocated and only freed in the
error paths, however, platform_device_add_data() adds a copy of the platform
specific data to the device. Move the temporary struct that is kmemdup'ed
to the stack. This issue exists since afb43e6d (wlcore: remove if_ops from
platform_data).
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
94010fa0dd ("rtlwifi: add MSI interrupts
mode support") introduced MSI interrupts mode support, which seemed
safe enough with RTL8188EE and RTL8723BE as RealTek's testing results,
but some users reported their RTL8188EE modules could not connect to
any wireless network after the MSI mode was enabled by Ubuntu 14.04.
So, let's fallback to pin-based mode until rtlwifi's MSI support get
good compatibility.
BugLink: https://bugs.launchpad.net/bugs/1310512
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit 2a54eb5e14
("rtlwifi: rtl8188ee: enable MSI interrupts mode").
94010fa0dd ("rtlwifi: add MSI interrupts
mode support") introduced MSI interrupts mode support, which seemed
safe enough with RTL8188EE and RTL8723BE as RealTek's testing results,
but some users reported their RTL8188EE modules could not connect to
any wireless network after the MSI mode was enabled by Ubuntu 14.04.
So, let's fallback to pin-based mode until rtlwifi's MSI support get
good compatibility.
BugLink: https://bugs.launchpad.net/bugs/1310512
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Setting it to true during init doesn't seem to be any workaround while
it can cause problems (not enabling radio due to belief it's enabled).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes dealing with pointers directly and allows tracking radio
state with radio_on variable.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are some corner cases where the driver could get stuck with a full
tid queue that is paused, leading to a software tx queue hang.
Since the tx queueing rework, pausing per-tid queues on aggregation
session setup is no longer necessary. The driver will assign sequence
numbers to buffered frames when a new session is established, in order
to get the correct starting sequence number.
mac80211 prevents new frames from entering the queue during setup.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the amount of noise fluctuates strongly, low immunity settings
can sometimes disrupt signal detection on AR913x chips. When that
happens, no OFDM/CCK errors are reported anymore, and ANI tunes the
radio to the lowest immunity settings.
Usually rx/tx fails as well in that case.
To fix this, keep noise immunity settings at or above ANI default level,
which will keep radio parameters at or above INI values.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 takes care of all the needed steps for hwsim, so indicate
support for this capability.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
brcmfmac has been broken on my cubietruck with a BCM43362:
brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
since commit 5303626103: "brcmfmac: update core reset and disable routines".
The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
BCMA_IOCTL itself before bringing the core out of reset, instead relying on
brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
to always set BCMA_IOCTL even if the core is already in reset.
This fixes brcmfmac hanging in firmware loading on my board.
Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit "ath9k: move sc_flags to ath_common" moved setting
ATH_OP_INVALID flag below ieee80211_register_hw. This is causing
the flag never being cleared randomly as the drv_start is called
prior to setting flag. Fix this by setting the flag prior to
register_hw.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit e050c76fcf.
I'm not sure what crack pipe I was using when I merged this...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is the first step to remove leftover code.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We've implemented table calculation, but forgot to enable writing it in
power setup function.
By the way document table layout.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Logic in specs and our code was wrong. Init and calibration values for
newer cards depend on radio revision, not PHY revision.
To make code clearer, change tables names to include "radio" or "phy".
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
They were extracted from MMIO dumps of 14e4:4353 and wl 6.30.223.141.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bit 0x200 has been noticed in the following log:
radio_read(0x02ca) -> 0x0000
radio_write(0x00ca) <- 0x0080
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
New Broadcom drivers don't upload it anymore. It was probably a copy & paste
mistake in early N-PHY rev 3+ days.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently AMSDU and AMPDU aggregation is enabled for TID 0 to
TID 5 streams. Lets enable it for remaining two streams also.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This will help to aggregate more packets which yields better
throughput results for 11ac chipsets.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This will help to aggregate more packets which yields better
throughput results.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware dump feature is added for PCIe based chipsets.
Separate file will be created at /var/log/fw_dump_*
for each memory segment.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This option be useful to dump firmware memory for debugging
purpose. Actual code to dump firmware momory for SDIO and PCIe
chipsets will be added later.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After changing local per interface beacon setting restore original
global beaconing state.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When command timeout occurs due to a firmware/hardware bug,
there is no chance of next command being successful. We will
keep cmd_sent flag on so that next command won't be sent to
firmware.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
IE's are parsed from beacon buffer and stored locally using
mwifiex_update_bss_desc_with_ie() function.
Sometimes the local pointers point to the data inside IE, but
while using them it is assumed that they are pointing to the IE
itself.
These issues are fixed in this patch.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
'add_remove_card_sem' semaphore already takes care of
synchronization for driver load and unload threads.
Hence there won't be a case when unload thread is waiting on
'wait_for_completion(fw_load)'.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This option allows driver to finish pending operations in
disconnect handler by not killing URBs after usb_deregister
call.
We will get rid of global pointer 'usb_card' by moving code
from cleanup_module() to disconnect(). This will help to match
with our handling for SDIO and PCIe interfaces.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
New skbs are allocated at the time of AMSDU aggregation. Setting
up in timestamps for such skbs was missing which would result
into wrong queue delays passed to FW. Fix this by setting
timestamp of skbs created for AMSDU aggregation.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Command nodes are increased from 20 to 50. Now we can always
scan 1 channel per scan command to avoid traffic delay/loss in
connected state. We will get rid of *CHANNEL_PER_SCAN_CMD macros
used due to command node constraints.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For PCIe, aggregate more AMSDU packets till PCIe TXBD is full.
For SDIO, aggregation was disabled for AMSDU packets because
AMSDU aggregated packet size is already 4K or 8K, SDIO Multiport
Aggregation feature didn't use to gain much previously.
Now with increased multiport aggregation buffer, we can enable
it for AMSDU packets.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently Tx and Rx buffer sizes are 8K and 16K respectively for
all chipsets. We will change them to 32K for SD8897 and 16K for
older chipsets. SD8897 chipset has more SDIO data ports than
older chipsets.
This patch will help to improve throughput numbers.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
WARNING: single byte memset is suspicious.
Swapped 2nd/3rd argument?
This code happens to work because rx_mcs is the first variable
in mcs structure. We should use 'mcs.rx_mcs' here anyway.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Maithili Hinge <maithili@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
