OSDN Git Service
Naftali Goldstein [Mon, 13 May 2019 13:36:30 +0000 (16:36 +0300)]
iwlwifi: mvm: correctly fill the ac array in the iwl_mac_ctx_cmd
The indexes into the ac array in the iwl_mac_ctx_cmd are from the iwl_ac
enum and not the txfs. The current code therefore puts the edca params
in the wrong indexes of the array, causing wrong priority for
data-streams of different ACs.
Fix this.
Note that this bug only occurs in NICs that use the new tx api, since in
the old tx api the txf number is equal to the corresponding ac in the
iwl_ac enum.
Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Dan Carpenter [Mon, 6 May 2019 12:54:09 +0000 (15:54 +0300)]
iwlwifi: remove some unnecessary NULL checks
These pointers are an offset into the "sta" struct. They're assigned
like this:
const struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
They're not the first member of the struct (->supp_rates[] is first) so
they can't be NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Gustavo A. R. Silva [Wed, 3 Apr 2019 16:03:42 +0000 (11:03 -0500)]
iwlwifi: d3: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, change the following form:
sizeof(*pattern_cmd) +
wowlan->n_patterns * sizeof(struct iwlagn_wowlan_pattern)
to :
struct_size(pattern_cmd, patterns, wowlan->n_patterns)
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Gustavo A. R. Silva [Wed, 3 Apr 2019 15:59:01 +0000 (10:59 -0500)]
iwlwifi: lib: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, change the following form:
sizeof(*pattern_cmd) +
wowlan->n_patterns * sizeof(struct iwlagn_wowlan_pattern)
to :
struct_size(pattern_cmd, patterns, wowlan->n_patterns)
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Wed, 1 May 2019 14:13:02 +0000 (17:13 +0300)]
iwlwifi: fw api: support adwell HB default APs number api
Support adaptive dwell high band default number of APs new api.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Mordechay Goodstein [Wed, 1 May 2019 17:48:12 +0000 (20:48 +0300)]
iwlwifi: mvm: remove multiple debugfs entries
Now that we have per station control over amsdu size no need for
multiple entries, especially that the old one is misleading due to not
setting it for all protocols as a limit.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Thu, 18 Apr 2019 07:24:28 +0000 (10:24 +0300)]
iwlwifi: dbg_ini: implement dump info collection
The info struct contains data about the FW, HW, RF and the debug
configuration.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Mordechay Goodstein [Sun, 21 Apr 2019 13:37:38 +0000 (16:37 +0300)]
iwlwifi: mvm: add a debugfs entry to set a fixed size AMSDU for all TX packets
The current debugfs entry only limits the max AMSDU for TCP. Add a new
debugfs entry to allow setting a fixed AMSDU size for all TX packets,
including UDP and ICMP
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Thu, 18 Apr 2019 07:15:19 +0000 (10:15 +0300)]
iwlwifi: dbg_ini: support debug info TLV
Add support to debug info TLV.
The TLV contains human readable naming of the FW image and the
debug configuration.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Sun, 28 Apr 2019 08:17:53 +0000 (11:17 +0300)]
iwlwifi: dbg_ini: use different barker for ini dump
Use a different barker for ini dump to allow differentiation from legacy
dump. Also it allows to remove INI_BIT from dump TLVs.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Tue, 2 Apr 2019 12:28:46 +0000 (15:28 +0300)]
iwlwifi: dbg_ini: add consecutive trigger firing support
When a dump trigger is fired, the driver sets IWL_FWRT_STATUS_DUMPING and
aborts any consecutive dump collection.
To allow consecutive triggers firing, use 5 dump workers and allocate
them upon incoming dump collection requests.
This functionality is needed since in ini debug mode each trigger may
have entirely different memory regions to collect unlike the legacy
mode in which all the triggers dump the same memory regions.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Mon, 8 Apr 2019 13:56:08 +0000 (16:56 +0300)]
iwlwifi: dbg_ini: abort region collection in case the size is 0
Allows to abort region collection in case the region size is 0.
It is needed for future regions that their size might be 0.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Johannes Berg [Thu, 4 Apr 2019 13:51:43 +0000 (15:51 +0200)]
iwlwifi: update CSI API
Update the CSI API to the new version supported by the firmware.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Mon, 8 Apr 2019 07:57:09 +0000 (10:57 +0300)]
iwlwifi: dbg_ini: dump headers cleanup
Unite dump memory ranges under a single struct and add a specific header
for each type of memory.
Also, maintain a single version to all dump structures.
This cleanup is also needed for the future addition of FW notification
regions and others.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Tue, 26 Mar 2019 07:55:37 +0000 (09:55 +0200)]
iwlwifi: dbg: allow dump collection in case of an early error
Improve the robustness of the dump collection flow in case of an early
error:
1. in iwl_trans_pcie_sync_nmi, disable and enable interrupts only if
they were already enabled
2. attempt to initiate dump collection in iwl_fw_dbg_error_collect only
if the device is enabled
3. check Tx command queue was already allocated before trying to collect it
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Jiri Kosina [Mon, 15 Apr 2019 12:07:09 +0000 (14:07 +0200)]
iwlwifi: iwl_mvm_tx_mpdu() must be called with BH disabled
As iwl_mvm_tx_mpdu() is not disabling BH while obtaining iwl_mvm_sta->lock
(which is being taken from BH context as well), it has to be always
invoked with BH disabled. Make that clear in a comment.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Zong-Zhe Yang [Wed, 29 May 2019 07:54:46 +0000 (15:54 +0800)]
rtw88: refine flow to get tx power index
Add a structure for power parameters including base,
offset, limit and a function to get tx power parameters.
Then, refine flow to get tx power index through the
function.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Tzu-En Huang [Wed, 29 May 2019 07:54:45 +0000 (15:54 +0800)]
rtw88: remove all RTW_MAX_POWER_INDEX macro
Since this macro definition has different values in different chipset,
the current defined macro value is for 8822b. This will cause the
settings of 8822c be incorrect.
Remove RTW_MAX_POWER_INDEX and use max_power_index in struct rtw_chip_info
to make sure the value of different chipset is right.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Zong-Zhe Yang [Wed, 29 May 2019 07:54:44 +0000 (15:54 +0800)]
rtw88: update tx power limit table to RF v20
Support more regulatory domains including IC, KCC,
ACMA, CHILE, UKRAINE, and MEXICO. Corresponding tx
power limits for these regulatory domains are added
in tx power limit table. Besides, tx power limits in
some case are also updated to follow RF v20 for better
tx power indexes.
Channel plan mapping table are upgraded to consider
more 2G and 5G channel plans combination cases. It
allow us to identify different situations more accuratly
by channel plan IDs. In addition, mapping table for
country code and channel plan ID and mapping table
for country code and tx power limit are also updated
to follow RF v20. It allow the new enrties in tx power
limit table to be applied correctly.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Zong-Zhe Yang [Wed, 29 May 2019 07:54:43 +0000 (15:54 +0800)]
rtw88: correct power limit selection
If phy rate is decreased, sub bandwidth may be chosen by RA.
We consider possible power limits and apply the min one;
otherwise, the tx power index may be larger than spec.
And we cross-reference power limits of vht and ht with
20/40M bandwidth in 5G to avoid values are not assigned.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:42 +0000 (15:54 +0800)]
rtw88: choose the lowest as world-wide power limit
When we are loading tx power limit from the power limit table, compare
the world-wide limit with the current limit and choose the lowest power
limit for the world-wide power settings.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:41 +0000 (15:54 +0800)]
rtw88: fix incorrect tx power limit at 5G
Tx power limit is stored separately by 2G and 5G.
But driver did not get tx power limit from 5G and causes incorrect tx
power. Check if the channel is beyond 2G and get the corresponding tx
power limit.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:40 +0000 (15:54 +0800)]
rtw88: remove unused variable
The orig variable is taken but not used, remove it
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:39 +0000 (15:54 +0800)]
rtw88: unify prefixes for tx power setting routine
Rename the function names to make them have the same prefix "rtw_phy"
for the tx power setting routines. Only the function names and
corresponding identation are modified.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:38 +0000 (15:54 +0800)]
rtw88: do not use (void *) as argument
The type change from (void *) to (struct rtw_dev *) is redundant.
Just pass the right type and compiler can check that for us.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:37 +0000 (15:54 +0800)]
rtw88: resolve order of tx power setting routines
Some functions that should be static are unnecessarily exposed, remove
their declaration in header file phy.h.
After resolving their declaration order, they can be declared as static.
So this commit changes nothing except the order and marking them static.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Brian Norris [Tue, 25 Jun 2019 17:40:45 +0000 (10:40 -0700)]
mwifiex: don't disable hardirqs; just softirqs
main_proc_lock and int_lock (in mwifiex_adapter) are the only spinlocks
used in hardirq contexts. The rest are only in task or softirq contexts.
Convert every other lock from *_irq{save,restore}() variants to _bh()
variants.
This is a mechanical transformation of all spinlock usage in mwifiex
using the following:
Step 1:
I ran this nasty sed script:
sed -i -E '/spin_lock_irqsave|spin_unlock_irqrestore/ {
/main_proc_lock|int_lock/! {
s:(spin_(un|)lock)_irq(save|restore):\1_bh: ;
# Join broken lines.
:a /;$/! {
N;
s/\s*\n\s*//;
ba
}
/,.*\);$/ s:,.*\):\):
}
}' drivers/net/wireless/marvell/mwifiex/*
Step 2:
Manually delete the flags / ra_list_flags args from:
mwifiex_send_single_packet()
mwifiex_11n_aggregate_pkt()
mwifiex_send_processed_packet()
which are now unused.
Step 3:
Apply this semantic patch (coccinelle) to remove the unused 'flags'
variables:
// <smpl>
@@
type T;
identifier i;
@@
(
extern T i;
|
- T i;
... when != i
)
// </smpl>
(Usage is something like this:
make coccicheck COCCI=./patch.cocci MODE=patch M=drivers/net/wireless/marvell/mwifiex/
although this skips *.h files for some reasons, so I had to massage
stuff.)
Testing: I've played with a variety of stress tests, including download
stress tests on the same APs which caught regressions with commit
5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've
primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO
a quick spin as well.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Brian Norris [Tue, 25 Jun 2019 17:40:44 +0000 (10:40 -0700)]
mwifiex: dispatch/rotate from reorder table atomically
mwifiex_11n_scan_and_dispatch() and
mwifiex_11n_dispatch_pkt_until_start_win() share similar patterns, where
they perform a few different actions on the same table, using the same
lock, but non-atomically. There have been other attempts to clean up
this sort of behavior, but they have had problems (incomplete;
introducing new deadlocks).
We can improve these functions' atomicity by queueing up our RX packets
in a list, to dispatch at the end of the function. This avoids problems
of another operation modifying the table in between our dispatch and
rotation operations.
This was inspired by investigations around this:
http://lkml.kernel.org/linux-wireless/
20181130175957.167031-1-briannorris@chromium.org
Subject: [4.20 PATCH] Revert "mwifiex: restructure rx_reorder_tbl_lock usage"
While the original (now-reverted) patch had good intentions in
restructuring some of the locking patterns in this driver, it missed an
important detail: we cannot defer to softirq contexts while already in
an atomic context. We can help avoid this sort of problem by separating
the two steps of:
(1) iterating / clearing the mwifiex reordering table
(2) dispatching received packets to upper layers
This makes it much harder to make lock recursion mistakes, as these
two steps no longer need to hold the same locks.
Testing: I've played with a variety of stress tests, including download
stress tests on the same APs which caught regressions with commit
5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've
primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO
a quick spin as well.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christoph Hellwig [Tue, 25 Jun 2019 10:29:32 +0000 (12:29 +0200)]
b43: simplify engine type / DMA mask selection
Return the engine type from the function looking at the registers, and
just derive the DMA mask from that in the one place we care.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christoph Hellwig [Tue, 25 Jun 2019 10:29:31 +0000 (12:29 +0200)]
b43: remove b43_dma_set_mask
These days drivers are not required to fallback to smaller DMA masks,
but can just set the largest mask they support, removing the need for
this trial and error logic.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christoph Hellwig [Tue, 25 Jun 2019 10:29:30 +0000 (12:29 +0200)]
b43legacy: simplify engine type / DMA mask selection
Return the engine type from the function looking at the registers, and
just derive the DMA mask from that in the one place we care.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christoph Hellwig [Tue, 25 Jun 2019 10:29:29 +0000 (12:29 +0200)]
b43legacy: remove b43legacy_dma_set_mask
These days drivers are not required to fallback to smaller DMA masks,
but can just set the largest mask they support, removing the need for
this trial and error logic.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
David S. Miller [Wed, 26 Jun 2019 21:09:33 +0000 (14:09 -0700)]
Merge branch 'macb-build-fixes'
Palmer Dabbelt says:
====================
net: macb: Fix compilation on systems without COMMON_CLK, v2
Our patch to add support for the FU540-C000 broke compilation on at
least powerpc allyesconfig, which was found as part of the linux-next
build regression tests. This must have somehow slipped through the
cracks, as the patch has been reverted in linux-next for a while now.
This patch applies on top of the offending commit, which is the only one
I've even tried it on as I'm not sure how this subsystem makes it to
Linus.
This patch set fixes the issue by adding a dependency of COMMON_CLK to
the MACB Kconfig entry, which avoids the build failure by disabling MACB
on systems where it wouldn't compile. All known users of MACB have
COMMON_CLK, so this shouldn't cause any issues. This is a significantly
simpler approach than disabling just the FU540-C000 support.
I've also included a second patch to indicate this is a driver for a
Cadence device that was originally written by an engineer at Atmel. The
only relation is that I stumbled across it when writing the first patch.
Changes since v1 <
20190624061603.1704-1-palmer@sifive.com>:
* Disable MACB on systems without COMMON_CLK, instead of just disabling
the FU540-C000 support on these systems.
* Update the commit message to reflect the driver was written by Atmel.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Palmer Dabbelt [Tue, 25 Jun 2019 08:48:28 +0000 (01:48 -0700)]
net: macb: Kconfig: Rename Atmel to Cadence
The help text makes it look like NET_VENDOR_CADENCE enables support for
Atmel devices, when in reality it's a driver written by Atmel that
supports Cadence devices. This may confuse users that have this device
on a non-Atmel SoC.
The fix is just s/Atmel/Cadence/, but I did go and re-wrap the Kconfig
help text as that change caused it to go over 80 characters.
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Palmer Dabbelt [Tue, 25 Jun 2019 08:48:27 +0000 (01:48 -0700)]
net: macb: Kconfig: Make MACB depend on COMMON_CLK
commit
c218ad559020 ("macb: Add support for SiFive FU540-C000") added a
dependency on the common clock framework to the macb driver, but didn't
express that dependency in Kconfig. As a result macb now fails to
compile on systems without COMMON_CLK, which specifically causes a build
failure on powerpc allyesconfig.
This patch adds the dependency, which results in the macb driver no
longer being selectable on systems without the common clock framework.
All known systems that have this device already support the common clock
framework, so this should not cause trouble for any uses. Supporting
both the FU540-C000 and systems without COMMON_CLK is quite ugly.
I've build tested this on powerpc allyesconfig and RISC-V defconfig
(which selects MACB), but I have not even booted the resulting kernels.
Fixes:
c218ad559020 ("macb: Add support for SiFive FU540-C000")
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dave Taht [Sat, 22 Jun 2019 17:07:34 +0000 (10:07 -0700)]
Allow 0.0.0.0/8 as a valid address range
The longstanding prohibition against using 0.0.0.0/8 dates back
to two issues with the early internet.
There was an interoperability problem with BSD 4.2 in 1984, fixed in
BSD 4.3 in 1986. BSD 4.2 has long since been retired.
Secondly, addresses of the form 0.x.y.z were initially defined only as
a source address in an ICMP datagram, indicating "node number x.y.z on
this IPv4 network", by nodes that know their address on their local
network, but do not yet know their network prefix, in RFC0792 (page
19). This usage of 0.x.y.z was later repealed in RFC1122 (section
3.2.2.7), because the original ICMP-based mechanism for learning the
network prefix was unworkable on many networks such as Ethernet (which
have longer addresses that would not fit into the 24 "node number"
bits). Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951)
or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask
(and other parameters such as default gateways). 0.x.y.z has had
16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for
future use, since 1989.
This patch allows for these 16m new IPv4 addresses to appear within
a box or on the wire. Layer 2 switches don't care.
0.0.0.0/32 is still prohibited, of course.
Signed-off-by: Dave Taht <dave.taht@gmail.com>
Signed-off-by: John Gilmore <gnu@toad.com>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Fri, 21 Jun 2019 23:27:16 +0000 (16:27 -0700)]
rtnetlink: skip metrics loop for dst_default_metrics
dst_default_metrics has all of the metrics initialized to 0, so nothing
will be added to the skb in rtnetlink_put_metrics. Avoid the loop if
metrics is from dst_default_metrics.
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 26 Jun 2019 20:05:42 +0000 (13:05 -0700)]
Merge branch 'skfp-cleanups'
Puranjay Mohan says:
====================
net: fddi: skfp: Use PCI generic definitions instead of private duplicates
This patch series removes the private duplicates of PCI definitions in
favour of generic definitions defined in pci_regs.h.
This driver only uses some of the generic PCI definitons,
which are included from pci_regs.h and thier private versions
are removed from skfbi.h with all other private defines.
The skfbi.h defines PCI_REV_ID and other private defines with different
names, these are renamed to Generic PCI names to make them
compatible with defines in pci_regs.h.
All unused defines are removed from skfbi.h.
Changes in v5:
Removed unused PCI definitions which were left in v4
Changes in v4:
Removed unused PCI definitions which were left in v3
Changes in v3:
Renamed all local PCI definitions to Generic names.
Corrected coding style mistakes.
Changes in v2:
Converted individual patches to a series.
Made sure that individual patches build correctly
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Puranjay Mohan [Fri, 21 Jun 2019 15:40:37 +0000 (21:10 +0530)]
net: fddi: skfp: Remove unused private PCI definitions
Remove unused private PCI definitions from skfbi.h because generic PCI
symbols are already included from pci_regs.h.
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Puranjay Mohan [Fri, 21 Jun 2019 15:40:36 +0000 (21:10 +0530)]
net: fddi: skfp: Include generic PCI definitions
Include the uapi/linux/pci_regs.h header file which contains the generic
PCI defines.
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Puranjay Mohan [Fri, 21 Jun 2019 15:40:35 +0000 (21:10 +0530)]
net: fddi: skfp: Rename local PCI defines to match generic PCI defines
Rename the PCI_REV_ID and other local defines to Generic PCI define names
in skfbi.h and drvfbi.c to make it compatible with the pci_regs.h.
Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 26 Jun 2019 17:12:17 +0000 (10:12 -0700)]
Merge tag 'wireless-drivers-next-for-davem-2019-06-26' of git://git./linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valu says:
====================
wireless-drivers-next patches for 5.3
First set of patches for 5.3, but not that many patches this time.
This pull request fails to compile with the tip tree due to
ktime_get_boot_ns() API changes there. It should be easy for Linus to
fix it in p54 driver once he pulls this, an example resolution here:
https://lkml.kernel.org/r/
20190625160432.
533aa140@canb.auug.org.au
Major changes:
airo
* switch to use skcipher interface
p54
* support boottime in scan results
rtw88
* add fast xmit support
* add random mac address on scan support
rt2x00
* add software watchdog to detect hangs, it's disabled by default
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Hunter [Wed, 26 Jun 2019 10:23:22 +0000 (11:23 +0100)]
net: stmmac: Fix crash observed if PHY does not support EEE
If the PHY does not support EEE mode, then a crash is observed when the
ethernet interface is enabled. The crash occurs, because if the PHY does
not support EEE, then although the EEE timer is never configured, it is
still marked as enabled and so the stmmac ethernet driver is still
trying to update the timer by calling mod_timer(). This triggers a BUG()
in the mod_timer() because we are trying to update a timer when there is
no callback function set because timer_setup() was never called for this
timer.
The problem is caused because we return true from the function
stmmac_eee_init(), marking the EEE timer as enabled, even when we have
not configured the EEE timer. Fix this by ensuring that we return false
if the PHY does not support EEE and hence, 'eee_active' is not set.
Fixes:
74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Hunter [Wed, 26 Jun 2019 10:23:21 +0000 (11:23 +0100)]
net: stmmac: Fix possible deadlock when disabling EEE support
When stmmac_eee_init() is called to disable EEE support, then the timer
for EEE support is stopped and we return from the function. Prior to
stopping the timer, a mutex was acquired but in this case it is never
released and so could cause a deadlock. Fix this by releasing the mutex
prior to returning from stmmax_eee_init() when stopping the EEE timer.
Fixes:
74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Wed, 26 Jun 2019 10:05:28 +0000 (03:05 -0700)]
ipv6: fix suspicious RCU usage in rt6_dump_route()
syzbot reminded us that rt6_nh_dump_exceptions() needs to be called
with rcu_read_lock()
net/ipv6/route.c:1593 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor609/8966:
#0:
00000000b7dbe288 (rtnl_mutex){+.+.}, at: netlink_dump+0xe7/0xfb0 net/netlink/af_netlink.c:2199
#1:
00000000f2d87c21 (&(&tb->tb6_lock)->rlock){+...}, at: spin_lock_bh include/linux/spinlock.h:343 [inline]
#1:
00000000f2d87c21 (&(&tb->tb6_lock)->rlock){+...}, at: fib6_dump_table.isra.0+0x37e/0x570 net/ipv6/ip6_fib.c:533
stack backtrace:
CPU: 0 PID: 8966 Comm: syz-executor609 Not tainted 5.2.0-rc5+ #43
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5250
fib6_nh_get_excptn_bucket+0x18e/0x1b0 net/ipv6/route.c:1593
rt6_nh_dump_exceptions+0x45/0x4d0 net/ipv6/route.c:5541
rt6_dump_route+0x904/0xc50 net/ipv6/route.c:5640
fib6_dump_node+0x168/0x280 net/ipv6/ip6_fib.c:467
fib6_walk_continue+0x4a9/0x8e0 net/ipv6/ip6_fib.c:1986
fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:2034
fib6_dump_table.isra.0+0x38a/0x570 net/ipv6/ip6_fib.c:534
inet6_dump_fib+0x93c/0xb00 net/ipv6/ip6_fib.c:624
rtnl_dump_all+0x295/0x490 net/core/rtnetlink.c:3445
netlink_dump+0x558/0xfb0 net/netlink/af_netlink.c:2244
__netlink_dump_start+0x5b1/0x7d0 net/netlink/af_netlink.c:2352
netlink_dump_start include/linux/netlink.h:226 [inline]
rtnetlink_rcv_msg+0x73d/0xb00 net/core/rtnetlink.c:5182
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5237
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:665
sock_write_iter+0x27c/0x3e0 net/socket.c:994
call_write_iter include/linux/fs.h:1872 [inline]
new_sync_write+0x4d3/0x770 fs/read_write.c:483
__vfs_write+0xe1/0x110 fs/read_write.c:496
vfs_write+0x20c/0x580 fs/read_write.c:558
ksys_write+0x14f/0x290 fs/read_write.c:611
__do_sys_write fs/read_write.c:623 [inline]
__se_sys_write fs/read_write.c:620 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:620
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4401b9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007ffc8e134978 EFLAGS:
00000246 ORIG_RAX:
0000000000000001
RAX:
ffffffffffffffda RBX:
00000000004002c8 RCX:
00000000004401b9
RDX:
000000000000001c RSI:
0000000020000000 RDI: 00
Fixes:
1e47b4837f3b ("ipv6: Dump route exceptions if requested")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Wed, 26 Jun 2019 10:04:50 +0000 (03:04 -0700)]
ipv4: fix suspicious RCU usage in fib_dump_info_fnhe()
sysbot reported that we lack appropriate rcu_read_lock()
protection in fib_dump_info_fnhe()
net/ipv4/route.c:2875 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz-executor609/8966:
#0:
00000000b7dbe288 (rtnl_mutex){+.+.}, at: netlink_dump+0xe7/0xfb0 net/netlink/af_netlink.c:2199
stack backtrace:
CPU: 0 PID: 8966 Comm: syz-executor609 Not tainted 5.2.0-rc5+ #43
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5250
fib_dump_info_fnhe+0x9d9/0x1080 net/ipv4/route.c:2875
fn_trie_dump_leaf net/ipv4/fib_trie.c:2141 [inline]
fib_table_dump+0x64a/0xd00 net/ipv4/fib_trie.c:2175
inet_dump_fib+0x83c/0xa90 net/ipv4/fib_frontend.c:1004
rtnl_dump_all+0x295/0x490 net/core/rtnetlink.c:3445
netlink_dump+0x558/0xfb0 net/netlink/af_netlink.c:2244
__netlink_dump_start+0x5b1/0x7d0 net/netlink/af_netlink.c:2352
netlink_dump_start include/linux/netlink.h:226 [inline]
rtnetlink_rcv_msg+0x73d/0xb00 net/core/rtnetlink.c:5182
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5237
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:646 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:665
sock_write_iter+0x27c/0x3e0 net/socket.c:994
call_write_iter include/linux/fs.h:1872 [inline]
new_sync_write+0x4d3/0x770 fs/read_write.c:483
__vfs_write+0xe1/0x110 fs/read_write.c:496
vfs_write+0x20c/0x580 fs/read_write.c:558
ksys_write+0x14f/0x290 fs/read_write.c:611
__do_sys_write fs/read_write.c:623 [inline]
__se_sys_write fs/read_write.c:620 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:620
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4401b9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007ffc8e134978 EFLAGS:
00000246 ORIG_RAX:
0000000000000001
RAX:
ffffffffffffffda RBX:
00000000004002c8 RCX:
00000000004401b9
RDX:
000000000000001c RSI:
0000000020000000 RDI:
0000000000000003
RBP:
00000000006ca018 R08:
00000000004002c8 R09:
00000000004002c8
R10:
0000000000000010 R11:
0000000000000246 R12:
0000000000401a40
R13:
0000000000401ad0 R14:
0000000000000000 R15:
0000000000000000
Fixes:
ee28906fd7a1 ("ipv4: Dump route exceptions if requested")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Stefano Brivio <sbrivio@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Tue, 25 Jun 2019 16:59:56 +0000 (09:59 -0700)]
Revert "net: ena: ethtool: add extra properties retrieval via get_priv_flags"
This reverts commit
315c28d2b714 ("net: ena: ethtool: add extra properties retrieval via get_priv_flags").
As discussed at netconf and on the mailing list we can't allow
for the the abuse of private flags for exposing arbitrary device
labels.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 26 Jun 2019 15:59:15 +0000 (11:59 -0400)]
Merge branch 'net-hns3-some-code-optimizations-bugfixes'
Huazhong Tan says:
====================
net: hns3: some code optimizations & bugfixes
This patch-set includes code optimizations and bugfixes for
the HNS3 ethernet controller driver.
[patch 1/11] fixes a selftest issue when doing autoneg.
[patch 2/11 - 3-11] adds two code optimizations about VLAN issue.
[patch 4/11] restores the MAC autoneg state after reset.
[patch 5/11 - 8/11] adds some code optimizations and bugfixes about
HW errors handling.
[patch 9/11 - 11/11] fixes some issues related to driver loading and
unloading.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Weihang Li [Thu, 20 Jun 2019 08:52:45 +0000 (16:52 +0800)]
net: hns3: add exception handling when enable NIC HW error interrupts
If we failed to enable NIC HW error interrupts during client
initialization in some cases, we should do exception handling to clear
flags and free the resources.
Fixes:
00ea6e5fda9d ("net: hns3: delay and separate enabling of NIC and ROCE HW errors")
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Huazhong Tan [Thu, 20 Jun 2019 08:52:44 +0000 (16:52 +0800)]
net: hns3: fixes wrong place enabling ROCE HW error when loading
The ROCE HW errors should only be enabled when initializing ROCE's
client, the current code enable it no matter initializing NIC or
ROCE client.
So this patch fixes it.
Fixes:
00ea6e5fda9d ("net: hns3: delay and separate enabling of NIC and ROCE HW errors")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Huazhong Tan [Thu, 20 Jun 2019 08:52:43 +0000 (16:52 +0800)]
net: hns3: fix race conditions between reset and module loading & unloading
When loading or unloading module, it should wait for the reset task
done before it un-initializes the client, otherwise the reset task
may cause a NULL pointer reference.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Weihang Li [Thu, 20 Jun 2019 08:52:42 +0000 (16:52 +0800)]
net: hns3: add check to number of buffer descriptors
This patch adds check to number of bds before we allocate memory for
them. If we get an invalid bd num in some cases, it will cause a memory
overflow.
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Weihang Li [Thu, 20 Jun 2019 08:52:41 +0000 (16:52 +0800)]
net: hns3: remove override_pci_need_reset
We add override_pci_need_reset to prevent redundant and unwanted PF
resets if a RAS error occurs in commit
69b51bbb03f7 ("net: hns3: fix
to stop multiple HNS reset due to the AER changes").
Now in HNS3 driver, we use hw_err_reset_req to record reset level that
we need to recover from a RAS error. This variable cans solve above
issue as override_pci_need_reset, so this patch removes
override_pci_need_reset.
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Weihang Li [Thu, 20 Jun 2019 08:52:40 +0000 (16:52 +0800)]
net: hns3: modify handling of out of memory in hclge_err.c
Users should be informed if HNS driver failed to allocate memory for
descriptor when handling hw errors. This patch solve above issues.
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Weihang Li [Thu, 20 Jun 2019 08:52:39 +0000 (16:52 +0800)]
net: hns3: code optimizaition of hclge_handle_hw_ras_error()
This patch optimizes hclge_handle_hw_ras_error() to make the code logic
clearer.
1. If there was no NIC or Roce RAS when we read
HCLGE_RAS_PF_OTHER_INT_STS_REG, we return directly.
2. Because NIC and Roce RAS may occurs at the same time, so we should
check value of revision at first before we handle Roce RAS instead
of only checking it in branch of no NIC RAS is detected.
3. Check HCLGE_STATE_RST_HANDLING each time before we want to return
PCI_ERS_RESULT_NEED_RESET.
4. Remove checking of HCLGE_RAS_REG_NFE_MASK and
HCLGE_RAS_REG_ROCEE_ERR_MASK because if hw_err_reset_req is not
zero, it proves that we have set it in handling of NIC or Roce RAS.
Signed-off-by: Weihang Li <liweihang@hisilicon.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jian Shen [Thu, 20 Jun 2019 08:52:38 +0000 (16:52 +0800)]
net: hns3: restore the MAC autoneg state after reset
When doing global reset, the MAC autoneg state of fibre
port is set to default, which may cause user configuration
lost. This patch fixes it by restore the MAC autoneg state
after reset.
Fixes:
22f48e24a23d ("net: hns3: add autoneg and change speed support for fibre port")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jian Shen [Thu, 20 Jun 2019 08:52:37 +0000 (16:52 +0800)]
net: hns3: sync VLAN filter entries when kill VLAN ID failed
When HW is resetting, firmware is unable to handle commands
from driver. So if remove VLAN device from stack at this time,
it will fail to remove the VLAN ID from HW VLAN filter, then
the VLAN filter status is unsynced with stack.
This patch fixes it by recording the VLAN ID delete failed,
and removes them again when reset complete.
Fixes:
44e626f720c3 ("net: hns3: fix VLAN offload handle for VLAN inserted by port")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jian Shen [Thu, 20 Jun 2019 08:52:36 +0000 (16:52 +0800)]
net: hns3: remove VF VLAN filter entry inexistent warning print
For VF VLAN filter is disabled when VF VLAN table is full, then the
new VLAN ID won't be added into VF VLAN table, it will always print
fail log when remove these VLAN IDs. If user has added too many
VLANs, it will cause massive verbose print logs.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jian Shen [Thu, 20 Jun 2019 08:52:35 +0000 (16:52 +0800)]
net: hns3: fix selftest fail issue for fibre port with autoneg on
When doing selftest for fibre port with autoneg on, the MAC speed
may be incorrect, which may cause the selftest failed. This patch
fixes it by halting autoneg during the selftest.
Fixes:
22f48e24a23d ("net: hns3: add autoneg and change speed support for fibre port")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Roman Mashak [Tue, 25 Jun 2019 18:18:52 +0000 (14:18 -0400)]
tc-testing: add ingress qdisc tests
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Maloy [Tue, 25 Jun 2019 17:37:00 +0000 (19:37 +0200)]
tipc: rename function msg_get_wrapped() to msg_inner_hdr()
We rename the inline function msg_get_wrapped() to the more
comprehensible msg_inner_hdr().
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Maloy [Tue, 25 Jun 2019 16:08:13 +0000 (18:08 +0200)]
tipc: eliminate unnecessary skb expansion during retransmission
We increase the allocated headroom for the buffer copies to be
retransmitted. This eliminates the need for the lower stack levels
(UDP/IP/L2) to expand the headroom in order to add their own headers.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Maloy [Tue, 25 Jun 2019 15:36:43 +0000 (17:36 +0200)]
tipc: simplify stale link failure criteria
In commit
a4dc70d46cf1 ("tipc: extend link reset criteria for stale
packet retransmission") we made link retransmission failure events
dependent on the link tolerance, and not only of the number of failed
retransmission attempts, as we did earlier. This works well. However,
keeping the original, additional criteria of 99 failed retransmissions
is now redundant, and may in some cases lead to failure detection
times in the order of minutes instead of the expected 1.5 sec link
tolerance value.
We now remove this criteria altogether.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Lucas Bates [Tue, 25 Jun 2019 01:00:27 +0000 (21:00 -0400)]
tc-testing: Restore original behaviour for namespaces in tdc
This patch restores the original behaviour for tdc prior to the
introduction of the plugin system, where the network namespace
functionality was split from the main script.
It introduces the concept of required plugins for testcases,
and will automatically load any plugin that isn't already
enabled when said plugin is required by even one testcase.
Additionally, the -n option for the nsPlugin is deprecated
so the default action is to make use of the namespaces.
Instead, we introduce -N to not use them, but still create
the veth pair.
buildebpfPlugin's -B option is also deprecated.
If a test cases requires the features of a specific plugin
in order to pass, it should instead include a new key/value
pair describing plugin interactions:
"plugins": {
"requires": "buildebpfPlugin"
},
A test case can have more than one required plugin: a list
can be inserted as the value for 'requires'.
Signed-off-by: Lucas Bates <lucasb@mojatatu.com>
Acked-by: Davide Caratti <dcaratti@redhat.com>
Tested-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Tue, 25 Jun 2019 19:42:12 +0000 (12:42 -0700)]
Merge git://git./linux/kernel/git/pablo/nf-next
Pablo Neira Ayuso says:
====================
Netfilter updates for net-next
The following patches contains Netfilter updates for net-next:
1) .br_defrag indirection depends on CONFIG_NF_DEFRAG_IPV6, from wenxu.
2) Remove unnecessary memset() in ipset, from Florent Fourcot.
3) Merge control plane addition and deletion in ipset, also from Florent.
4) A few missing check for nla_parse() in ipset, from Aditya Pakki
and Jozsef Kadlecsik.
5) Incorrect cleanup in error path of xt_set version 3, from Jozsef.
6) Memory accounting problems when resizing in ipset, from Stefano Brivio.
7) Jozsef updates his email to @netfilter.org, this batch comes with a
conflict resolution with recent SPDX header updates.
8) Add to create custom conntrack expectations via nftables, from
Stephane Veyret.
9) A lookup optimization for conntrack, from Florian Westphal.
10) Check for supported flags in xt_owner.
11) Support for pernet sysctl in br_netfilter, patches
from Christian Brauner.
12) Patches to move common synproxy infrastructure to nf_synproxy.c,
to prepare the synproxy support for nf_tables, patches from
Fernando Fernandez Mancera.
13) Support to restore expiration time in set element, from Laura Garcia.
14) Fix recent rewrite of netfilter IPv6 to avoid indirections
when CONFIG_IPV6 is unset, from Arnd Bergmann.
15) Always reset vlan tag on skbuff fraglist when refragmenting in
bridge conntrack, from wenxu.
16) Support to match IPv4 options in nf_tables, from Stephen Suryaputra.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Ard Biesheuvel [Mon, 17 Jun 2019 08:43:38 +0000 (10:43 +0200)]
airo: switch to skcipher interface
The AIRO driver applies a ctr(aes) on a buffer of considerable size
(2400 bytes), and instead of invoking the crypto API to handle this
in its entirety, it open codes the counter manipulation and invokes
the AES block cipher directly.
Let's fix this, by switching to the sync skcipher API instead.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Stanislaw Gruszka [Sat, 15 Jun 2019 10:01:00 +0000 (12:01 +0200)]
rt2800: do not enable watchdog by default
Make watchdog disabled by default and add module parameter to enable it.
User will have to create file in /etc/modprobe.d/ with
options rt2800lib watchdog=1
to enable the watchdog or load "rt2800lib watchdog=1" module manually
before loading rt2800{soc,pci,usb} module.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Stanislaw Gruszka [Sat, 15 Jun 2019 10:00:59 +0000 (12:00 +0200)]
rt2x00: add restart hw
Add ieee80211_restart_hw() to watchdog and debugfs file for testing
if restart works as expected.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Stanislaw Gruszka [Sat, 15 Jun 2019 10:00:58 +0000 (12:00 +0200)]
rt2800: do not nullify initialization vector data
If we restart hw we should keep existing IV (initialization vector)
otherwise HW encryption will be broken after restart.
Also fix some coding style issues on the way.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Stanislaw Gruszka [Sat, 15 Jun 2019 10:00:57 +0000 (12:00 +0200)]
rt2800: add pre_reset_hw callback
Add routine to cleanup interfaces data before hw reset as
ieee80211_restart_hw() will do setup interfaces again.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Stanislaw Gruszka [Sat, 15 Jun 2019 10:00:56 +0000 (12:00 +0200)]
rt2800: initial watchdog implementation
Add watchdog for rt2800 devices. For now it only detect hung
and print error.
[Note: I verified that printing messages from process context is
fine on MT7620 (WT3020) platform that have problem when printk
is called from interrupt context].
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Stanislaw Gruszka [Sat, 15 Jun 2019 10:00:55 +0000 (12:00 +0200)]
rt2800: add helpers for reading dma done index
For mmio we do not properlly trace dma done Q_INDEX_DMA_DONE index
for TX queues. That would require implementing INT_SOURCE_CSR_*_DMA_DONE
interrupts, what is rather not worth to do due to adding extra
CPU load (small but still somewhat not necessary otherwise).
We can just read TX DMA done indexes from registers directly. What
will be used by watchdog.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Stanislaw Gruszka [Sat, 15 Jun 2019 10:00:54 +0000 (12:00 +0200)]
rt2x00: allow to specify watchdog interval
Allow subdriver to change watchdog interval by intialize
link->watchdog_interval value before rt2x00link_register().
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christian Lamparter [Sat, 15 Jun 2019 10:00:09 +0000 (12:00 +0200)]
p54: remove dead branch in op_conf_tx callback
This patch removes the error branch for (queue > dev->queues).
It is no longer needed anymore as the "queue" value is validated by
cfg80211's parse_txq_params() before the driver code gets called.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Tzu-En Huang [Fri, 14 Jun 2019 07:24:15 +0000 (15:24 +0800)]
rtw88: fix typo rtw_writ16_set
rtw_writ16_set should be rtw_write16_set
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Fri, 14 Jun 2019 07:24:14 +0000 (15:24 +0800)]
rtw88: rsvd page should go though management queue
The hardware default uses management queue to transmit frames that are
downloaded into reserved page, so we need to clearly assign the frames
to use qsel in TX_DESC_QSEL_MGMT to avoid using wrong queue.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Fri, 14 Jun 2019 07:24:13 +0000 (15:24 +0800)]
rtw88: restore DACK results to save time
DACK is done right after the hardware has been turned on, which
means it will be done every time we leave the IDLE state.
But it takes ~2 seconds to finish DACK.
We can back up the results and restore them. And it only takes a few
milliseconds to restore the results to the hardware, saving a lot of
time.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Fri, 14 Jun 2019 07:24:12 +0000 (15:24 +0800)]
rtw88: power on again if it was already on
We could fail to power on because it was already on. If the return
value is -EALREADY, power off and then power on again to turn on the
hardware as expected.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Fri, 14 Jun 2019 07:24:11 +0000 (15:24 +0800)]
rtw88: 8822c: use more accurate ofdm fa counting
8822c used to count OFDM FA count by subtracting tx count from FA count.
But it need to substract more counters to be accurate.
However, we can count it by adding up all of the FA counters we want.
And it is simpler to add than list all of the components to substract.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Fri, 14 Jun 2019 07:24:10 +0000 (15:24 +0800)]
rtw88: 8822c: disable rx clock gating before counter reset
Driver Could fail to reset counter if rx clock gating is not disabled.
So we need to disable rx clock gating before resetting counters.
Otherwise counters may increase unexpected.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Chien-Hsun Liao [Fri, 14 Jun 2019 07:24:09 +0000 (15:24 +0800)]
rtw88: 8822c: update channel and bandwidth BB setting
In 2G channels, the cck source and rxagc should be set to different
values based on different bandwidth to increase the performance of rx
sensitivity.
To improve rx throughput performance, the values of sbd subtune and
pt_opt should be changed in different bandwidth.
Signed-off-by: Chien-Hsun Liao <ben.liao@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Chien-Hsun Liao [Fri, 14 Jun 2019 07:24:08 +0000 (15:24 +0800)]
rtw88: 8822c: add rf write protection when switching channel
Collision of writing rf registers could occur if the driver writes
rf registers by direct write while the hardware is writing other rf
registers by pi write simultaneously.
Hardware pi write can be triggered by rf calibrations sometimes, so
the driver can not always write rf registers by direct write
protection. Direct write protection can make sure that there is no
hardware pi write during the direct write.
According to some experiments, if we add direct write protection
when switching channel, the performance of rf calibration will not
be affected.
Signed-off-by: Chien-Hsun Liao <ben.liao@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Chin-Yen Lee [Fri, 14 Jun 2019 07:24:07 +0000 (15:24 +0800)]
rtw88: add beacon function setting
Add beacon function setting routines for each hardware port.
If beacon function is not enabled, the hardware is not able
to synchronize with AP's beacon and can miss the beacons
under some scenarios such as PS mode.
For AP and Adhoc modes that require to send beacons, do not
update the TSF, otherwise the beacon interval may be affected.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Fri, 14 Jun 2019 07:24:06 +0000 (15:24 +0800)]
rtw88: add support for random mac scan
When driver uses random mac address to scan, the unicast probe response
will not be received because the addr1 is not matched. Configure port
address by requested mac address to receive probe response from AP.
To support random mac scan, we need to configure the mac address during
scan period to receive unicast prop_resp. After scan is completed,
configure the mac address back to the original one that the port used.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Fri, 14 Jun 2019 07:24:05 +0000 (15:24 +0800)]
rtw88: add fast xmit support
With dynamic power save support, rtw88 is able to support fast tx
path, claim it to mac80211.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Greg Kroah-Hartman [Wed, 12 Jun 2019 14:26:55 +0000 (16:26 +0200)]
iwlegacy: 4965: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. This driver was saving the debugfs file away to be
removed at a later time. However, the 80211 core would delete the whole
directory that the debugfs files are created in, after it asks the
driver to do the deletion, so just rely on the 80211 core to do all of
the cleanup for us, making us not need to keep a pointer to the dentries
around at all.
This cleans up the structure of the driver data a bit and makes the code
a tiny bit smaller.
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Greg Kroah-Hartman [Wed, 12 Jun 2019 14:26:54 +0000 (16:26 +0200)]
iwlegacy: 3945: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. This driver was saving the debugfs file away to be
removed at a later time. However, the 80211 core would delete the whole
directory that the debugfs files are created in, after it asks the
driver to do the deletion, so just rely on the 80211 core to do all of
the cleanup for us, making us not need to keep a pointer to the dentries
around at all.
This cleans up the structure of the driver data a bit and makes the code
a tiny bit smaller.
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Michael Büsch [Mon, 10 Jun 2019 18:49:27 +0000 (20:49 +0200)]
ssb/gpio: Remove unnecessary WARN_ON from driver_gpio
The WARN_ON triggers on older BCM4401-B0 100Base-TX ethernet controllers.
The warning serves no purpose. So let's just remove it.
Reported-by: H Buus <ubuntu@hbuus.com>
Signed-off-by: Michael Büsch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Colin Ian King [Sat, 8 Jun 2019 10:58:00 +0000 (11:58 +0100)]
rtlwifi: rtl8188ee: remove redundant assignment to rtstatus
Variable rtstatus is being initialized with a value that is never read
as rtstatus is being re-assigned a little later on. The assignment is
redundant and hence can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Gustavo A. R. Silva [Fri, 7 Jun 2019 19:17:45 +0000 (14:17 -0500)]
qtnfmac: Use struct_size() in kzalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct ieee80211_regdomain {
...
struct ieee80211_reg_rule reg_rules[];
};
instance = kzalloc(sizeof(*mac->rd) +
sizeof(struct ieee80211_reg_rule) *
count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, reg_rules, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Lorenzo Bianconi [Fri, 7 Jun 2019 11:48:10 +0000 (13:48 +0200)]
mt7601u: fix possible memory leak when the device is disconnected
When the device is disconnected while passing traffic it is possible
to receive out of order urbs causing a memory leak since the skb linked
to the current tx urb is not removed. Fix the issue deallocating the skb
cleaning up the tx ring. Moreover this patch fixes the following kernel
warning
[ 57.480771] usb 1-1: USB disconnect, device number 2
[ 57.483451] ------------[ cut here ]------------
[ 57.483462] TX urb mismatch
[ 57.483481] WARNING: CPU: 1 PID: 32 at drivers/net/wireless/mediatek/mt7601u/dma.c:245 mt7601u_complete_tx+0x165/00
[ 57.483483] Modules linked in:
[ 57.483496] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 5.2.0-rc1+ #72
[ 57.483498] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-2.fc30 04/01/2014
[ 57.483502] Workqueue: usb_hub_wq hub_event
[ 57.483507] RIP: 0010:mt7601u_complete_tx+0x165/0x1e0
[ 57.483510] Code: 8b b5 10 04 00 00 8b 8d 14 04 00 00 eb 8b 80 3d b1 cb e1 00 00 75 9e 48 c7 c7 a4 ea 05 82 c6 05 f
[ 57.483513] RSP: 0000:
ffffc900000a0d28 EFLAGS:
00010092
[ 57.483516] RAX:
000000000000000f RBX:
ffff88802c0a62c0 RCX:
ffffc900000a0c2c
[ 57.483518] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffffffff810a8371
[ 57.483520] RBP:
ffff88803ced6858 R08:
0000000000000000 R09:
0000000000000001
[ 57.483540] R10:
0000000000000002 R11:
0000000000000000 R12:
0000000000000046
[ 57.483542] R13:
ffff88802c0a6c88 R14:
ffff88803baab540 R15:
ffff88803a0cc078
[ 57.483548] FS:
0000000000000000(0000) GS:
ffff88803eb00000(0000) knlGS:
0000000000000000
[ 57.483550] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 57.483552] CR2:
000055e7f6780100 CR3:
0000000028c86000 CR4:
00000000000006a0
[ 57.483554] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 57.483556] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 57.483559] Call Trace:
[ 57.483561] <IRQ>
[ 57.483565] __usb_hcd_giveback_urb+0x77/0xe0
[ 57.483570] xhci_giveback_urb_in_irq.isra.0+0x8b/0x140
[ 57.483574] handle_cmd_completion+0xf5b/0x12c0
[ 57.483577] xhci_irq+0x1f6/0x1810
[ 57.483581] ? lockdep_hardirqs_on+0x9e/0x180
[ 57.483584] ? _raw_spin_unlock_irq+0x24/0x30
[ 57.483588] __handle_irq_event_percpu+0x3a/0x260
[ 57.483592] handle_irq_event_percpu+0x1c/0x60
[ 57.483595] handle_irq_event+0x2f/0x4c
[ 57.483599] handle_edge_irq+0x7e/0x1a0
[ 57.483603] handle_irq+0x17/0x20
[ 57.483607] do_IRQ+0x54/0x110
[ 57.483610] common_interrupt+0xf/0xf
[ 57.483612] </IRQ>
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Lorenzo Bianconi [Fri, 7 Jun 2019 11:48:09 +0000 (13:48 +0200)]
mt7601u: do not schedule rx_tasklet when the device has been disconnected
Do not schedule rx_tasklet when the usb dongle is disconnected.
Moreover do not grub rx_lock in mt7601u_kill_rx since usb_poison_urb
can run concurrently with urb completion and we can unlink urbs from rx
ring in any order.
This patch fixes the common kernel warning reported when
the device is removed.
[ 24.921354] usb 3-14: USB disconnect, device number 7
[ 24.921593] ------------[ cut here ]------------
[ 24.921594] RX urb mismatch
[ 24.921675] WARNING: CPU: 4 PID: 163 at drivers/net/wireless/mediatek/mt7601u/dma.c:200 mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
[ 24.921769] CPU: 4 PID: 163 Comm: kworker/4:2 Tainted: G OE 4.19.31-041931-generic #
201903231635
[ 24.921770] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P1.30 05/23/2014
[ 24.921782] Workqueue: usb_hub_wq hub_event
[ 24.921797] RIP: 0010:mt7601u_complete_rx+0xcb/0xd0 [mt7601u]
[ 24.921800] RSP: 0018:
ffff9bd9cfd03d08 EFLAGS:
00010086
[ 24.921802] RAX:
0000000000000000 RBX:
ffff9bd9bf043540 RCX:
0000000000000006
[ 24.921803] RDX:
0000000000000007 RSI:
0000000000000096 RDI:
ffff9bd9cfd16420
[ 24.921804] RBP:
ffff9bd9cfd03d28 R08:
0000000000000002 R09:
00000000000003a8
[ 24.921805] R10:
0000002f485fca34 R11:
0000000000000000 R12:
ffff9bd9bf043c1c
[ 24.921806] R13:
ffff9bd9c62fa3c0 R14:
0000000000000082 R15:
0000000000000000
[ 24.921807] FS:
0000000000000000(0000) GS:
ffff9bd9cfd00000(0000) knlGS:
0000000000000000
[ 24.921808] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 24.921808] CR2:
00007fb2648b0000 CR3:
0000000142c0a004 CR4:
00000000001606e0
[ 24.921809] Call Trace:
[ 24.921812] <IRQ>
[ 24.921819] __usb_hcd_giveback_urb+0x8b/0x140
[ 24.921821] usb_hcd_giveback_urb+0xca/0xe0
[ 24.921828] xhci_giveback_urb_in_irq.isra.42+0x82/0xf0
[ 24.921834] handle_cmd_completion+0xe02/0x10d0
[ 24.921837] xhci_irq+0x274/0x4a0
[ 24.921838] xhci_msi_irq+0x11/0x20
[ 24.921851] __handle_irq_event_percpu+0x44/0x190
[ 24.921856] handle_irq_event_percpu+0x32/0x80
[ 24.921861] handle_irq_event+0x3b/0x5a
[ 24.921867] handle_edge_irq+0x80/0x190
[ 24.921874] handle_irq+0x20/0x30
[ 24.921889] do_IRQ+0x4e/0xe0
[ 24.921891] common_interrupt+0xf/0xf
[ 24.921892] </IRQ>
[ 24.921900] RIP: 0010:usb_hcd_flush_endpoint+0x78/0x180
[ 24.921354] usb 3-14: USB disconnect, device number 7
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Colin Ian King [Fri, 31 May 2019 14:14:12 +0000 (15:14 +0100)]
rtlwifi: remove redundant assignment to variable k
The assignment of 0 to variable k is never read once we break out of
the loop, so the assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Colin Ian King [Thu, 30 May 2019 18:40:44 +0000 (19:40 +0100)]
rtlwifi: remove redundant assignment to variable badworden
The variable badworden is assigned with a value that is never read and
it is re-assigned a new value immediately afterwards. The assignment is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Ping-Ke Shih [Wed, 29 May 2019 06:57:30 +0000 (14:57 +0800)]
rtlwifi: rtl8192cu: fix error handle when usb probe failed
rtl_usb_probe() must do error handle rtl_deinit_core() only if
rtl_init_core() is done, otherwise goto error_out2.
| usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
| rtl_usb: reg 0xf0, usbctrl_vendorreq TimeOut! status:0xffffffb9 value=0x0
| rtl8192cu: Chip version 0x10
| rtl_usb: reg 0xa, usbctrl_vendorreq TimeOut! status:0xffffffb9 value=0x0
| rtl_usb: Too few input end points found
| INFO: trying to register non-static key.
| the code is fine but needs lockdep annotation.
| turning off the locking correctness validator.
| CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted
5.1.0-rc4-319354-g9a33b36 #3
| Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
| Google 01/01/2011
| Workqueue: usb_hub_wq hub_event
| Call Trace:
| __dump_stack lib/dump_stack.c:77 [inline]
| dump_stack+0xe8/0x16e lib/dump_stack.c:113
| assign_lock_key kernel/locking/lockdep.c:786 [inline]
| register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
| __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
| lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
| __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
| _raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
| rtl_c2hcmd_launcher+0xd1/0x390
| drivers/net/wireless/realtek/rtlwifi/base.c:2344
| rtl_deinit_core+0x25/0x2d0 drivers/net/wireless/realtek/rtlwifi/base.c:574
| rtl_usb_probe.cold+0x861/0xa70
| drivers/net/wireless/realtek/rtlwifi/usb.c:1093
| usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
| really_probe+0x2da/0xb10 drivers/base/dd.c:509
| driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
| __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
| bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
| __device_attach+0x223/0x3a0 drivers/base/dd.c:844
| bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
| device_add+0xad2/0x16e0 drivers/base/core.c:2106
| usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
| generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
| usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
| really_probe+0x2da/0xb10 drivers/base/dd.c:509
| driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
| __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
| bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
| __device_attach+0x223/0x3a0 drivers/base/dd.c:844
| bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
| device_add+0xad2/0x16e0 drivers/base/core.c:2106
| usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
| hub_port_connect drivers/usb/core/hub.c:5089 [inline]
| hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
| port_event drivers/usb/core/hub.c:5350 [inline]
| hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
| process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
| worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
| kthread+0x313/0x420 kernel/kthread.c:253
| ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Reported-by: syzbot+1fcc5ef45175fc774231@syzkaller.appspotmail.com
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Swati Kushwaha [Fri, 21 Jun 2019 14:14:44 +0000 (19:44 +0530)]
mwifiex: ignore processing invalid command response
Firmware can send invalid command response, the processing of
which can attempt to modify unexpected context and cause issues.
To fix this, driver should check that the command response ID is
same as the one it downloaded, and ignore processing of invalid
response.
Signed-off-by: Swati Kushwaha <swatiuma@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Sharvari Harisangam [Wed, 12 Jun 2019 15:12:11 +0000 (20:42 +0530)]
mwifiex: update set_mac_address logic
In set_mac_address, driver check for interfaces with same bss_type
For first STA entry, this would return 3 interfaces since all priv's have
bss_type as 0 due to kzalloc. Thus mac address gets changed for STA
unexpected. This patch adds check for first STA and avoids mac address
change. This patch also adds mac_address change for p2p based on bss_num
type.
Signed-off-by: Sharvari Harisangam <sharvari@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Brian Norris [Tue, 4 Jun 2019 17:31:44 +0000 (10:31 -0700)]
mwifiex: print PCI mmap with %pK
Unadorned '%p' has restrictive policies these days, such that it usually
just prints garbage at early boot (see
Documentation/core-api/printk-formats.rst, "kernel will print
``(ptrval)`` until it gathers enough entropy"). Annotating with %pK
(for "kernel pointer") allows the kptr_restrict sysctl to control
printing policy better.
We might just as well drop this message entirely, but this fix was easy
enough for now.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Brian Norris [Tue, 4 Jun 2019 17:28:58 +0000 (10:28 -0700)]
mwifiex: drop 'set_consistent_dma_mask' log message
This message is pointless.
While we're at it, include the error code in the error message, which is
not pointless.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Alan Stern [Mon, 20 May 2019 14:44:21 +0000 (10:44 -0400)]
p54usb: Fix race between disconnect and firmware loading
The syzbot fuzzer found a bug in the p54 USB wireless driver. The
issue involves a race between disconnect and the firmware-loader
callback routine, and it has several aspects.
One big problem is that when the firmware can't be loaded, the
callback routine tries to unbind the driver from the USB _device_ (by
calling device_release_driver) instead of from the USB _interface_ to
which it is actually bound (by calling usb_driver_release_interface).
The race involves access to the private data structure. The driver's
disconnect handler waits for a completion that is signalled by the
firmware-loader callback routine. As soon as the completion is
signalled, you have to assume that the private data structure may have
been deallocated by the disconnect handler -- even if the firmware was
loaded without errors. However, the callback routine does access the
private data several times after that point.
Another problem is that, in order to ensure that the USB device
structure hasn't been freed when the callback routine runs, the driver
takes a reference to it. This isn't good enough any more, because now
that the callback routine calls usb_driver_release_interface, it has
to ensure that the interface structure hasn't been freed.
Finally, the driver takes an unnecessary reference to the USB device
structure in the probe function and drops the reference in the
disconnect handler. This extra reference doesn't accomplish anything,
because the USB core already guarantees that a device structure won't
be deallocated while a driver is still bound to any of its interfaces.
To fix these problems, this patch makes the following changes:
Call usb_driver_release_interface() rather than
device_release_driver().
Don't signal the completion until after the important
information has been copied out of the private data structure,
and don't refer to the private data at all thereafter.
Lock udev (the interface's parent) before unbinding the driver
instead of locking udev->parent.
During the firmware loading process, take a reference to the
USB interface instead of the USB device.
Don't take an unnecessary reference to the device during probe
(and then don't drop it during disconnect).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com
CC: <stable@vger.kernel.org>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>