Driver incorrectly validates command completion: instead of waiting
for a command to be acknowledged it continues execution. Most of the
time driver gets acknowledge of the command completion in a tasklet
before it executes the next one. But sometimes it sends the next
command before it gets acknowledge for the previous one. In such a
case one of the following error messages appear in the log:
Failed to send SYSTEM_CONFIG: Already sending a command.
Failed to send ASSOCIATE: Already sending a command.
Failed to send TX_POWER: Already sending a command.
After that you need to reload the driver to get it working again.
This bug occurs during roaming (reported by Sam Varshavchik)
https://bugzilla.redhat.com/show_bug.cgi?id=738508
and machine booting (reported by Tom Gundersen and Mads Kiilerich)
https://bugs.archlinux.org/task/28097https://bugzilla.redhat.com/show_bug.cgi?id=802106
This patch doesn't fix the delay issue during firmware load.
But at least device now works as usual after boot.
Cc: stable@kernel.org
Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ctx->vif is dereferenced in different part of iwlwifi code, so do not
nullify it.
This should address at least one of the possible reasons of WARNING at
iwlagn_mac_remove_interface, and perhaps some random crashes when
firmware reset is performed.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The 'ath9k_hw_update_regulatory_maxpower'
helper function has been introduced by
commit a55f858852
(ath9k_hw: Cleanup TX power calculation for AR9287).
Updating of the max_power_level value has been moved
into the helper function in that change, however the
removed code from 'ath9k_hw_ar9287_set_txpower' has
not been replaced with a call of the new helper
function.
Due to that missing call, retrieving tx power for 2x2
and 3x3 chainmask is not handled properly. During the
calculation of the tx power for 2x2 and 3x3 chainmasks
the values are reduced. Those reductions must be
compensated during retrieving.
Fix this by adding the missing call of the helper
function.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In order to unifying regulatory limit handling
commit ca2c68cc7b
(ath9k_hw: clean up tx power handling) introduced
a new helper function 'ath9k_hw_apply_txpower',
and the direct calls of 'ah->eep_ops->set_txpower'
has been replaced by a call of the helper function.
This caused a change in the behaviour of the
'ath9k_hw_set_txpowerlimit' function. The purpose
of that function is to calculate and store the
rate txpower table and the regulatory limit without
touching the hardware registers. Before the commit,
the 'test' parameter of the function was passed to
the 'ah->eep_ops->set_txpower'. Now the calling of
the 'set_txpower' function happens indirectly through
'ath9k_hw_apply_txpower', so the 'test' argument of
the 'set_txpower' is always 'false'.
This patch restores the original behaviour of
'ath9k_hw_set_txpowerlimit' by adding a new
argument to 'ath9k_hw_apply_txpower.'
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Complete the waiting fwlog_block_read on debugfs cleanup, otherwise
userspace and module unload might softlock.
Signed-off-by: Thomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The original conditions are always true. I think && was intended here,
but I don't have the hardware to test. Could you take a look?
kvalo: Chilam confirmed that the fix is valid
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
The ath6kl fw does not have enough memory to support the WoW filters of
more than one vif. Disallow WoW suspend if this is the case.
Signed-off-by: Thomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Now that we know the supported PHY capabilities, only restore supported
bands / HT capabilities in firmware when stopping AP.
Signed-off-by: Thomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Currently the supported bands are just hard coded in the driver.
However, the ath6kl FW will include its 11n and band capabilites in a
WMI_READY event. Handle this and report capabilites to cfg80211
accordingly.
Signed-off-by: Thomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath6kl: If wow deepsleep pno suspend failure driver will choose cutpower.
in this scenario MMC_PM_KEEP_POWER should be cleared so that mmc will power
off the ar6000
kvalo: remove extra parenthesis
Signed-off-by: Ming Jiang <mjiang@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Device interrupts numbers were changed to unsigned int in 1997, the year
IRQ_MACHSPEC was killed as well.
Also kill a related cast while we're at it.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: netdev@vger.kernel.org
This patch adds device tree support for lpc_eth.c.
The runtime option for MII/RMII is solved via the "phy-mode" property, SRAM
("IRAM") usage for DMA can be chosen via "use-iram".
Signed-off-by: Roland Stigge <stigge@antcom.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
This patch changes content of hashlist (used to get port struct by
computed index (0...en_port_count-1)). Now the hash list contains only
enabled ports so userspace will be able to say what ports can be used
for tx/rx. This becomes handy when userspace will need to disable ports
which does not belong to active aggregator. By default, newly added port
is enabled.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The dev_id parameter passed to free_irq needs to match the one passed
to the corresponding request_irq.
Signed-off-by: Matt Renzelmann <mjr@cs.wisc.edu>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Although the network interface is down, the RX packets number which
could be observed by ifconfig may keep on increasing.
This is because the WORK scheduled in netvsc_set_multicast_list()
may be executed after netvsc_close(). That means the rndis filter
may be re-enabled by do_set_multicast() even if it was closed by
netvsc_close().
By canceling possible WORK before close the rndis filter, the issue
could be never happened.
Signed-off-by: Wenqi Ma <wenqi_ma@trendmicro.com.cn>
Reviewed-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is a potential deadlock scenario when the ks8851 driver
is removed. The interrupt handler schedules a workqueue which
acquires a mutex that ks8851_net_stop() also acquires before
flushing the workqueue. Previously lockdep wouldn't be able
to find this problem but now that it has the support we can
trigger this lockdep warning by rmmoding the driver after
an ifconfig up.
Fix the possible deadlock by disabling the interrupts in
the chip and then release the lock across the workqueue
flushing. The mutex is only there to proect the registers
anyway so this should be ok.
=======================================================
[ INFO: possible circular locking dependency detected ]
3.0.21-00021-g8b33780-dirty #2911
-------------------------------------------------------
rmmod/125 is trying to acquire lock:
((&ks->irq_work)){+.+...}, at: [<c019e0b8>] flush_work+0x0/0xac
but task is already holding lock:
(&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&ks->lock){+.+...}:
[<c01b89c8>] __lock_acquire+0x940/0x9f8
[<c01b9058>] lock_acquire+0x10c/0x130
[<c083dbec>] mutex_lock_nested+0x68/0x3dc
[<bf00bd48>] ks8851_irq_work+0x24/0x46c [ks8851]
[<c019c580>] process_one_work+0x2d8/0x518
[<c019cb98>] worker_thread+0x220/0x3a0
[<c01a2ad4>] kthread+0x88/0x94
[<c0107008>] kernel_thread_exit+0x0/0x8
-> #0 ((&ks->irq_work)){+.+...}:
[<c01b7984>] validate_chain+0x914/0x1018
[<c01b89c8>] __lock_acquire+0x940/0x9f8
[<c01b9058>] lock_acquire+0x10c/0x130
[<c019e104>] flush_work+0x4c/0xac
[<bf00b858>] ks8851_net_stop+0x6c/0x138 [ks8851]
[<c06b209c>] __dev_close_many+0x98/0xcc
[<c06b2174>] dev_close_many+0x68/0xd0
[<c06b22ec>] rollback_registered_many+0xcc/0x2b8
[<c06b2554>] rollback_registered+0x28/0x34
[<c06b25b8>] unregister_netdevice_queue+0x58/0x7c
[<c06b25f4>] unregister_netdev+0x18/0x20
[<bf00c1f4>] ks8851_remove+0x64/0xb4 [ks8851]
[<c049ddf0>] spi_drv_remove+0x18/0x1c
[<c0468e98>] __device_release_driver+0x7c/0xbc
[<c0468f64>] driver_detach+0x8c/0xb4
[<c0467f00>] bus_remove_driver+0xb8/0xe8
[<c01c1d20>] sys_delete_module+0x1e8/0x27c
[<c0105ec0>] ret_fast_syscall+0x0/0x3c
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ks->lock);
lock((&ks->irq_work));
lock(&ks->lock);
lock((&ks->irq_work));
*** DEADLOCK ***
4 locks held by rmmod/125:
#0: (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f44>] driver_detach+0x6c/0xb4
#1: (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f50>] driver_detach+0x78/0xb4
#2: (rtnl_mutex){+.+.+.}, at: [<c06b25e8>] unregister_netdev+0xc/0x20
#3: (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The two options are separate, and some platforms (e.g. arm pxa)
have ISA slots but no ISA dma controller, so they cannot build
drivers using the DMA API functions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some architectures like ARM cannot handle large numbers as
arguments to udelay, so the drivers should use mdelay when
delaying for multiple miliseconds.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
No driver should spin the CPU for 10ms, so better use
an msleep, which is allowed in the ->suspend function.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The ax88796 driver uses the CRC32 functions, so make sure that
they are actually enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The iwmc3200 driver selects other code in Kconfig that depends on
EXPERIMENTAL. Kconfig warns about this when CONFIG_EXPERIMENTAL
is not already set, so logically, these options should also
be marked experimental or promoted to stable.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The caif_shmcore requires io.h in order to use ioremap, so include that
explicitly to compile in all configurations.
Also add a note about the use of ioremap(), which is not a proper way
to map a DMA buffer into kernel space. It's not completely clear what
the intention is for using ioremap, but it is clear that the result
of ioremap must not simply be accessed using kernel pointers but
should use readl/writel or memcopy_{to,from}io. Assigning the result
of ioremap to a regular pointer that can also be set to something
else is not ok.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Drivers that refer to a __devexit function in an operations
structure need to annotate that pointer with __devexit_p so
replace it with a NULL pointer when the section gets discarded.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The davinci_emac driver can be a module, so the symbols
it needs from the cpdma driver must be exported.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The time stamping code in this driver appears to have been copied from
the ixp4xx_eth.c driver, including this timing comment. I had actually
measured the time stamp delay on an IXP425, but I really doubt that this
value also applies here.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes code which needlessly ran the BPF twice per
packet. Instead, we just run the classifier once and test
whether the packet is any kind of PTP event message.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the driver so that multicast PTP event messages can
be recognized by the hardware time stamping unit. The station address
register must be set according to the desired transport type.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch clears up a few coding style issues:
- Makes two function definitions a bit nicer looking.
- Remove unneeded parentheses.
- Simplify macros for register bits.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The code in phc_gbe_main will need to call this method in order to set the
station address register according to the receive time stamping filter.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The reset logic after a Rx FIFO overrun will clear the programmed
multicast addresses. This patch fixes the issue by reprogramming the
registers after the reset.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch makes logic surrounding the test of the
transmit time stamping flag more readable.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the helper functions that give the transmit and
receive time stamps to return nanoseconds, instead of arbitrary clock
ticks.
[ RC - Rebased Takahiro's changes and wrote a commit message
explaining the changes. ]
Signed-off-by: Takahiro Shimizu <tshimizu818@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
l2cb 1.1 hardware has a bug for magic wakeup,
the workaround is to add pattern enable.
WoL related registers are refined as well.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
bit PCIE_PHYMISC_FORCE_RCV_DET is only for l1c&l2c to fix WoL issue,
other chips set bit5 of REG_MASTER_CTRL --- this way could save more
power than the former, and the bit should be kept all time.
l2cb 1.x has special setting for L0S/L1
l2cb 1.x & l1d 1.x should clear Vendor Message on some platforms,
otherwise it will cause the root complex hang.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
some platforms(BIOS or OS) may change ASPM configuration in
PCI Express Link Control Register directly and dynamically
regardless the device driver installation.
Checking if ASPM support during the driver init phase by reading
PCI Express Link Contrl Register doesn't make sense.
This refine/update assume L0S/L1 is defalut enabled as hw->ctrl_flags
inited. atl1c_set_aspm will set real configuration based on chip
capability to hardware register.
atl1c_disable_l0s_l1 and register definition of REG_PM_CTRL are
refined as well.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
bit MASTER_CTRL_CLK_SEL_DIS could be set before enter suspend
clear it after resume to enable pclk(PCIE clock) switch to
low frequency(25M) in some circumstances to save power.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
clear PCIE error status (error log is write-1-clear).
REG_PCIE_UC_SEVERITY is removed as it's a standard pcie register,
and using kernle API to access it.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
atl1c_configure_tx used a wrong value of MAX_TX_OFFLOAD_THRESH(9KB)
for TSO threshold.
the right value should be 7KB
Fast Ethernet controller doesn't support Jumbo frame.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
l1c_wait_until_idle is called for serval modules (TXQ/RXQ/TXMAC/RXMAC).
specific moudle have specific idle/busy status in reg REG_IDLE_STATUS.
the previous code return wrongly if all modules are in idle status,
regardless the 'stop' action is applied on individual module.
Refine the reg REG_IDLE_STATUS definition as well.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
threshold setting to control ASPM for diff chips are different.
currently, all gigabit-capability chips have limited-ASPM under
100M throughput.
Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: Liu David <dwliu@qca.qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
