* Re: [PATCH net-next] can: dev: call netif_carrier_off() in register_candev()
From: David Miller @ 2019-06-26 16:03 UTC (permalink / raw)
To: rasmus.villemoes
Cc: willemdebruijn.kernel, wg, mkl, Rasmus.Villemoes, linux-can,
netdev, linux-kernel
In-Reply-To: <ff8160d4-3357-9b4f-1840-bbe46195da5a@prevas.dk>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date: Wed, 26 Jun 2019 09:31:39 +0000
> Perhaps I've misunderstood when to use the net-next prefix - is that
> only for things that should be applied directly to the net-next
> tree?
Yes, it is.
^ permalink raw reply
* Re: [PATCH net-next 00/11] net: hns3: some code optimizations & bugfixes
From: David Miller @ 2019-06-26 15:59 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <573582a3-23fc-8591-f71b-af977ed6fd0e@huawei.com>
From: tanhuazhong <tanhuazhong@huawei.com>
Date: Wed, 26 Jun 2019 15:44:05 +0800
> Hi, david, has this patchset merged into net-next, why I cannot see it
> after pulling net-next? Or is there some problem about this patchset I
> have missed?
Sorry, I forgot to push it out from my laptop while traveling.
It should be there now.
^ permalink raw reply
* pull-request: wireless-drivers-next 2019-06-26
From: Kalle Valo @ 2019-06-26 15:59 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next for 5.3, more info below. Please let
me know if there are any problems.
Kalle
The following changes since commit f4aa80129ff71909380ee0bde8be36c5cc031d4c:
cxgb4: Make t4_get_tp_e2c_map static (2019-05-26 22:16:26 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2019-06-26
for you to fetch changes up to e5db0ad7563c38b7b329504836c9a64ae025a47a:
airo: switch to skcipher interface (2019-06-25 08:12:20 +0300)
----------------------------------------------------------------
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
----------------------------------------------------------------
Ahmad Masri (1):
wil6210: fix overwriting max_assoc_sta module param
Alagu Sankar (3):
ath10k: htt: don't use txdone_fifo with SDIO
ath10k: htt: support MSDU ids with SDIO
ath10k: add initialization of HTC header
Alan Stern (1):
p54usb: Fix race between disconnect and firmware loading
Alexei Avshalom Lazar (1):
wil6210: fix _desc access in __wil_tx_vring_tso
Anilkumar Kolli (1):
ath: DFS JP domain W56 fixed pulse type 3 RADAR detection
Ard Biesheuvel (1):
airo: switch to skcipher interface
Arend van Spriel (6):
brcm80211: switch common header files to using SPDX license identifier
brcmutil: switch source files to using SPDX license identifier
brcmsmac: switch phy source files to using SPDX license identifier
brcmfmac: switch source files to using SPDX license identifier
brcmfmac: use separate Kconfig file for brcmfmac
brcm80211: select WANT_DEV_COREDUMP conditionally for brcmfmac
Arnd Bergmann (1):
wireless: carl9170: fix clang build warning
Balaji Pothunoori (1):
ath10k: rx_duration update for fw_stats debugfs entry
Brandon Huang (1):
ath10k: Fix the tx stats bytes & packets parsing
Brian Norris (2):
mwifiex: drop 'set_consistent_dma_mask' log message
mwifiex: print PCI mmap with %pK
Chien-Hsun Liao (2):
rtw88: 8822c: add rf write protection when switching channel
rtw88: 8822c: update channel and bandwidth BB setting
Chin-Yen Lee (1):
rtw88: add beacon function setting
Christian Lamparter (3):
p54: fix crash during initialization
p54: Support boottime in scan results
p54: remove dead branch in op_conf_tx callback
Colin Ian King (5):
ath6kl: remove redundant check of status != 0
libertas: fix spelling mistake "Donwloading" -> "Downloading"
rtlwifi: remove redundant assignment to variable badworden
rtlwifi: remove redundant assignment to variable k
rtlwifi: rtl8188ee: remove redundant assignment to rtstatus
Dan Carpenter (1):
ath6kl: add some bounds checking
Dedy Lansky (3):
wil6210: add printout of platform capabilities
wil6210: enhancements for descriptor and status ring debugfs
wil6210: check rx_buff_mgmt before accessing it
Erik Stromdahl (1):
ath10k: sdio: add missing error check
Govind Singh (2):
ath10k: Move board id and fw version logging to info level
ath10k: Modify CE4 src buffer entries to 2048 for WCN3990
Greg Kroah-Hartman (2):
iwlegacy: 3945: no need to check return value of debugfs_create functions
iwlegacy: 4965: no need to check return value of debugfs_create functions
Gustavo A. R. Silva (6):
ath6kl: debug: Use struct_size() helper
ath6kl: wmi: use struct_size() helper
wil6210: fix potential out-of-bounds read
ath10k: Use struct_size() helper
ath10k: coredump: use struct_size() helper
qtnfmac: Use struct_size() in kzalloc()
Jia-Ju Bai (1):
b43: Avoid possible double calls to b43_one_core_detach()
Kalle Valo (3):
ath10k: initialise struct ath10k_bus params to zero
ath10k: fix use-after-free on SDIO data frames
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Larry Finger (4):
rtlwifi: rtl8821ae: Remove unused GET_XXX and SET_XXX descriptor macros
rtlwifi: rtl8821ae: Replace local bit manipulation macros
rtlwifi: rtl8821ae: Convert macros that set descriptor
rtlwifi: rtl8821ae: Convert inline routines to little-endian words
Lorenzo Bianconi (2):
mt7601u: do not schedule rx_tasklet when the device has been disconnected
mt7601u: fix possible memory leak when the device is disconnected
Maharaja Kennadyrajan (2):
ath10k: Extended the HTT stats support to retrieve Mu-MIMO related stats
ath10k: Added support to reset HTT stats in debugfs
Maya Erez (4):
wil6210: fix spurious interrupts in 3-msi
wil6210: add support for multiple sections in brd file
wil6210: fix missed MISC mbox interrupt
wil6210: remove HALP for Talyn devices
Michael Buesch (1):
ssb/gpio: Remove unnecessary WARN_ON from driver_gpio
Neo Jou (1):
brcmfmac: use strlcpy() instead of strcpy()
Ping-Ke Shih (5):
rtlwifi: 8192de: Reduce indentation and fix coding style
rtlwifi: 8192de: make tables to be 'static const'
rtlwifi: 8192de: Fix used uninitialized variables in power tracking
rtlwifi: 8192de: use le32 to access cckswing tables
rtlwifi: rtl8192cu: fix error handle when usb probe failed
Pradeep kumar Chitrapu (1):
ath10k: fix incorrect multicast/broadcast rate setting
Rakesh Pillai (1):
ath10k: Fix encoding for protected management frames
Sharvari Harisangam (1):
mwifiex: update set_mac_address logic
Stanislaw Gruszka (7):
rt2x00: allow to specify watchdog interval
rt2800: add helpers for reading dma done index
rt2800: initial watchdog implementation
rt2800: add pre_reset_hw callback
rt2800: do not nullify initialization vector data
rt2x00: add restart hw
rt2800: do not enable watchdog by default
Surabhi Vishnoi (4):
ath10k: Fix the wrong value of enums for wmi tlv stats id
ath10k: Add wmi tlv vdev subtype for mesh in WCN3990
ath10k: Do not send probe response template for mesh
ath10k: Add wmi tlv service map for mesh 11s
Sven Eckelmann (1):
ath9k: Differentiate between max combined and per chain power
Swati Kushwaha (1):
mwifiex: ignore processing invalid command response
Tim Schumacher (1):
ath9k: Check for errors when reading SREV register
Toke Høiland-Jørgensen (1):
ath9k: Don't trust TX status TID number when reporting airtime
Tomislav Požega (2):
ath: drop duplicated define
ath9k: drop redundant code in ar9003_hw_set_channel
Tzu-En Huang (1):
rtw88: fix typo rtw_writ16_set
Weitao Hou (1):
brcmfmac: fix typos in code comments
Wen Gong (9):
ath10k: sdio: workaround firmware UART pin configuration bug
ath10k: don't disable interrupts in ath10k_sdio_remove()
ath10k: add struct for high latency PN replay protection
ath10k: add handler for HTT_T2H_MSG_TYPE_SEC_IND event
ath10k: add PN replay protection for high latency devices
ath10k: add fragmentation handler for high latency devices
ath10k: enable QCA6174 hw3.2 SDIO hardware
ath10k: change swap mail box config for UTF mode of SDIO
ath10k: add peer id check in ath10k_peer_find_by_id
Yan-Hsuan Chuang (10):
rtw88: pci: use ieee80211_ac_numbers instead of 0-3
rtw88: pci: check if queue mapping exceeds size of ac_to_hwq
rtw88: more descriptions about LPS
rtw88: add fast xmit support
rtw88: add support for random mac scan
rtw88: 8822c: disable rx clock gating before counter reset
rtw88: 8822c: use more accurate ofdm fa counting
rtw88: power on again if it was already on
rtw88: restore DACK results to save time
rtw88: rsvd page should go though management queue
Yingying Tang (1):
ath10k: Check tx_stats before use it
YueHaibing (4):
ath9k: Remove some set but not used variables
rtlwifi: rtl8821ae: Remove set but not used variables 'cur_txokcnt' and 'b_last_is_cur_rdl_state'
rtlwifi: btcoex: Remove set but not used variable 'len' and 'asso_type_v2'
rtlwifi: btcoex: remove unused function exhalbtc_stack_operation_notify
drivers/net/wireless/ath/ath10k/ahb.c | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 48 +-
drivers/net/wireless/ath/ath10k/core.h | 12 +-
drivers/net/wireless/ath/ath10k/coredump.c | 4 +-
drivers/net/wireless/ath/ath10k/debug.c | 50 +-
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 7 +
drivers/net/wireless/ath/ath10k/htc.c | 1 +
drivers/net/wireless/ath/ath10k/htt.h | 60 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 387 ++++++++++-
drivers/net/wireless/ath/ath10k/htt_tx.c | 29 +-
drivers/net/wireless/ath/ath10k/hw.h | 6 +
drivers/net/wireless/ath/ath10k/mac.c | 14 +-
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
drivers/net/wireless/ath/ath10k/qmi.c | 15 +-
drivers/net/wireless/ath/ath10k/sdio.c | 18 +-
drivers/net/wireless/ath/ath10k/snoc.c | 4 +-
drivers/net/wireless/ath/ath10k/txrx.c | 3 +
drivers/net/wireless/ath/ath10k/usb.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 28 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 12 +
drivers/net/wireless/ath/ath10k/wmi.c | 37 +-
drivers/net/wireless/ath/ath10k/wmi.h | 7 +-
drivers/net/wireless/ath/ath6kl/debug.c | 3 +-
drivers/net/wireless/ath/ath6kl/htc_pipe.c | 3 -
drivers/net/wireless/ath/ath6kl/wmi.c | 13 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 24 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 1 +
drivers/net/wireless/ath/ath9k/hw.c | 40 +-
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 18 +-
drivers/net/wireless/ath/carl9170/mac.c | 2 +-
drivers/net/wireless/ath/carl9170/rx.c | 2 +-
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
drivers/net/wireless/ath/regd.h | 1 -
drivers/net/wireless/ath/wil6210/cfg80211.c | 4 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 70 +-
drivers/net/wireless/ath/wil6210/fw.h | 11 +-
drivers/net/wireless/ath/wil6210/fw_inc.c | 148 +++--
drivers/net/wireless/ath/wil6210/interrupt.c | 67 +-
drivers/net/wireless/ath/wil6210/main.c | 18 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 2 +
drivers/net/wireless/ath/wil6210/rx_reorder.c | 2 +-
drivers/net/wireless/ath/wil6210/txrx.c | 26 +-
drivers/net/wireless/ath/wil6210/txrx_edma.c | 10 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 33 +-
drivers/net/wireless/ath/wil6210/wmi.c | 14 +-
drivers/net/wireless/broadcom/b43/main.c | 7 +-
drivers/net/wireless/broadcom/brcm80211/Kconfig | 52 +-
drivers/net/wireless/broadcom/brcm80211/Makefile | 14 +-
.../wireless/broadcom/brcm80211/brcmfmac/Kconfig | 50 ++
.../wireless/broadcom/brcm80211/brcmfmac/Makefile | 14 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/btcoex.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/btcoex.h | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 13 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 13 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/chip.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/chip.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 15 +-
.../wireless/broadcom/brcm80211/brcmfmac/common.h | 16 +-
.../broadcom/brcm80211/brcmfmac/commonring.c | 16 +-
.../broadcom/brcm80211/brcmfmac/commonring.h | 16 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/debug.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/debug.h | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/dmi.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/feature.h | 13 +-
.../broadcom/brcm80211/brcmfmac/firmware.c | 13 +-
.../broadcom/brcm80211/brcmfmac/firmware.h | 13 +-
.../broadcom/brcm80211/brcmfmac/flowring.c | 16 +-
.../broadcom/brcm80211/brcmfmac/flowring.h | 16 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/fwil.c | 15 +-
.../wireless/broadcom/brcm80211/brcmfmac/fwil.h | 13 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 13 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 13 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.h | 14 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 16 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h | 16 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/of.c | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/of.h | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 16 +-
.../wireless/broadcom/brcm80211/brcmfmac/pcie.h | 16 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.h | 13 +-
.../broadcom/brcm80211/brcmfmac/tracepoint.c | 13 +-
.../broadcom/brcm80211/brcmfmac/tracepoint.h | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 13 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.h | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/vendor.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/vendor.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_hal.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_int.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_lcn.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_radio.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phyreg_n.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.h | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 13 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_n.h | 13 +-
.../wireless/broadcom/brcm80211/brcmutil/Makefile | 13 +-
.../net/wireless/broadcom/brcm80211/brcmutil/d11.c | 13 +-
.../wireless/broadcom/brcm80211/brcmutil/utils.c | 13 +-
.../broadcom/brcm80211/include/brcm_hw_ids.h | 13 +-
.../broadcom/brcm80211/include/brcmu_d11.h | 13 +-
.../broadcom/brcm80211/include/brcmu_utils.h | 13 +-
.../broadcom/brcm80211/include/brcmu_wifi.h | 13 +-
.../broadcom/brcm80211/include/chipcommon.h | 13 +-
.../net/wireless/broadcom/brcm80211/include/defs.h | 13 +-
.../net/wireless/broadcom/brcm80211/include/soc.h | 13 +-
drivers/net/wireless/cisco/Kconfig | 2 +
drivers/net/wireless/cisco/airo.c | 57 +-
drivers/net/wireless/intel/iwlegacy/3945-rs.c | 14 +-
drivers/net/wireless/intel/iwlegacy/3945.h | 3 -
drivers/net/wireless/intel/iwlegacy/4965-rs.c | 31 +-
drivers/net/wireless/intel/iwlegacy/common.h | 4 -
drivers/net/wireless/intersil/p54/main.c | 9 +-
drivers/net/wireless/intersil/p54/p54usb.c | 43 +-
drivers/net/wireless/intersil/p54/txrx.c | 11 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 +-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 27 +-
drivers/net/wireless/marvell/mwifiex/main.c | 6 +-
drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 5 +-
drivers/net/wireless/mediatek/mt7601u/dma.c | 54 +-
drivers/net/wireless/mediatek/mt7601u/tx.c | 4 +-
drivers/net/wireless/quantenna/qtnfmac/commands.c | 5 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 96 ++-
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 11 +
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 31 +
drivers/net/wireless/ralink/rt2x00/rt2800mmio.h | 2 +
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 3 +
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 3 +
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 11 +
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 10 +
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 35 +
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 10 +-
drivers/net/wireless/ralink/rt2x00/rt2x00link.c | 15 +-
drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 6 +
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 35 +-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 1 -
.../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/efuse.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/dm.c | 695 ++++++++++----------
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 253 ++++----
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 708 +++++++++++----------
drivers/net/wireless/realtek/rtlwifi/usb.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 +
drivers/net/wireless/realtek/rtw88/hci.h | 2 +-
drivers/net/wireless/realtek/rtw88/mac.c | 8 +-
drivers/net/wireless/realtek/rtw88/mac80211.c | 32 +
drivers/net/wireless/realtek/rtw88/main.c | 10 +-
drivers/net/wireless/realtek/rtw88/main.h | 11 +
drivers/net/wireless/realtek/rtw88/pci.c | 10 +-
drivers/net/wireless/realtek/rtw88/phy.c | 13 +-
drivers/net/wireless/realtek/rtw88/rtw8822c.c | 436 ++++++++++++-
drivers/net/wireless/realtek/rtw88/rtw8822c.h | 23 +
drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
drivers/ssb/driver_gpio.c | 6 -
181 files changed, 2885 insertions(+), 2322 deletions(-)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig
^ permalink raw reply
* [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems
From: Ivan Khoronzhuk @ 2019-06-26 15:59 UTC (permalink / raw)
To: bjorn.topel, magnus.karlsson, davem
Cc: ast, daniel, hawk, john.fastabend, netdev, bpf, xdp-newbies,
linux-kernel, Ivan Khoronzhuk
Use kmap instead of page_address as it's not always in low memory.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
net/xdp/xdp_umem.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 9c6de4f114f8..d3c1411420fd 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -169,6 +169,14 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
}
}
+static void xdp_umem_unmap_pages(struct xdp_umem *umem)
+{
+ unsigned int i;
+
+ for (i = 0; i < umem->npgs; i++)
+ kunmap(umem->pgs[i]);
+}
+
static void xdp_umem_unpin_pages(struct xdp_umem *umem)
{
unsigned int i;
@@ -210,6 +218,7 @@ static void xdp_umem_release(struct xdp_umem *umem)
xsk_reuseq_destroy(umem);
+ xdp_umem_unmap_pages(umem);
xdp_umem_unpin_pages(umem);
kfree(umem->pages);
@@ -372,7 +381,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
}
for (i = 0; i < umem->npgs; i++)
- umem->pages[i].addr = page_address(umem->pgs[i]);
+ umem->pages[i].addr = kmap(umem->pgs[i]);
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 3/4] net: sched: em_ipt: keep the user-specified nfproto and use it
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190626155615.16639-1-nikolay@cumulusnetworks.com>
For NFPROTO_UNSPEC xt_matches there's no way to restrict the matching to a
specific family, in order to do so we record the user-specified family
and later enforce it while doing the match.
v2: adjust changes to missing patch, was patch 04 in v1
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/sched/em_ipt.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index fd7f5b288c31..ce91f3cea0bd 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -21,6 +21,7 @@
struct em_ipt_match {
const struct xt_match *match;
u32 hook;
+ u8 nfproto;
u8 match_data[0] __aligned(8);
};
@@ -115,6 +116,7 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
struct em_ipt_match *im = NULL;
struct xt_match *match;
int mdata_len, ret;
+ u8 nfproto;
ret = nla_parse_deprecated(tb, TCA_EM_IPT_MAX, data, data_len,
em_ipt_policy, NULL);
@@ -125,6 +127,16 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
!tb[TCA_EM_IPT_MATCH_DATA] || !tb[TCA_EM_IPT_NFPROTO])
return -EINVAL;
+ nfproto = nla_get_u8(tb[TCA_EM_IPT_NFPROTO]);
+ switch (nfproto) {
+ case NFPROTO_IPV4:
+ case NFPROTO_IPV6:
+ case NFPROTO_UNSPEC:
+ break;
+ default:
+ return -EINVAL;
+ }
+
match = get_xt_match(tb);
if (IS_ERR(match)) {
pr_err("unable to load match\n");
@@ -140,6 +152,7 @@ static int em_ipt_change(struct net *net, void *data, int data_len,
im->match = match;
im->hook = nla_get_u32(tb[TCA_EM_IPT_HOOK]);
+ im->nfproto = nfproto;
nla_memcpy(im->match_data, tb[TCA_EM_IPT_MATCH_DATA], mdata_len);
ret = check_match(net, im, mdata_len);
@@ -182,8 +195,8 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
const struct em_ipt_match *im = (const void *)em->data;
struct xt_action_param acpar = {};
struct net_device *indev = NULL;
- u8 nfproto = im->match->family;
struct nf_hook_state state;
+ u8 nfproto = im->nfproto;
int ret;
switch (tc_skb_protocol(skb)) {
@@ -231,7 +244,7 @@ static int em_ipt_dump(struct sk_buff *skb, struct tcf_ematch *em)
return -EMSGSIZE;
if (nla_put_u8(skb, TCA_EM_IPT_MATCH_REVISION, im->match->revision) < 0)
return -EMSGSIZE;
- if (nla_put_u8(skb, TCA_EM_IPT_NFPROTO, im->match->family) < 0)
+ if (nla_put_u8(skb, TCA_EM_IPT_NFPROTO, im->nfproto) < 0)
return -EMSGSIZE;
if (nla_put(skb, TCA_EM_IPT_MATCH_DATA,
im->match->usersize ?: im->match->matchsize,
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 4/4] net: sched: em_ipt: add support for addrtype matching
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190626155615.16639-1-nikolay@cumulusnetworks.com>
Allow em_ipt to use addrtype for matching. Restrict the use only to
revision 1 which has IPv6 support. Since it's a NFPROTO_UNSPEC xt match
we use the user-specified nfproto for matching, in case it's unspecified
both v4/v6 will be matched by the rule.
v2: no changes, was patch 5 in v1
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/sched/em_ipt.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index ce91f3cea0bd..b08d87bd120b 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -72,11 +72,25 @@ static int policy_validate_match_data(struct nlattr **tb, u8 mrev)
return 0;
}
+static int addrtype_validate_match_data(struct nlattr **tb, u8 mrev)
+{
+ if (mrev != 1) {
+ pr_err("only addrtype match revision 1 supported");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct em_ipt_xt_match em_ipt_xt_matches[] = {
{
.match_name = "policy",
.validate_match_data = policy_validate_match_data
},
+ {
+ .match_name = "addrtype",
+ .validate_match_data = addrtype_validate_match_data
+ },
{}
};
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 2/4] net: sched: em_ipt: set the family based on the packet if it's unspecified
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190626155615.16639-1-nikolay@cumulusnetworks.com>
Set the family based on the packet if it's unspecified otherwise
protocol-neutral matches will have wrong information (e.g. NFPROTO_UNSPEC).
In preparation for using NFPROTO_UNSPEC xt matches.
v2: set the nfproto only when unspecified
Suggested-by: Eyal Birger <eyal.birger@gmail.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/sched/em_ipt.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 64dbafe4e94c..fd7f5b288c31 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -182,6 +182,7 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
const struct em_ipt_match *im = (const void *)em->data;
struct xt_action_param acpar = {};
struct net_device *indev = NULL;
+ u8 nfproto = im->match->family;
struct nf_hook_state state;
int ret;
@@ -189,10 +190,14 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
case htons(ETH_P_IP):
if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
return 0;
+ if (nfproto == NFPROTO_UNSPEC)
+ nfproto = NFPROTO_IPV4;
break;
case htons(ETH_P_IPV6):
if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
return 0;
+ if (nfproto == NFPROTO_UNSPEC)
+ nfproto = NFPROTO_IPV6;
break;
default:
return 0;
@@ -203,7 +208,7 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
if (skb->skb_iif)
indev = dev_get_by_index_rcu(em->net, skb->skb_iif);
- nf_hook_state_init(&state, im->hook, im->match->family,
+ nf_hook_state_init(&state, im->hook, nfproto,
indev ?: skb->dev, skb->dev, NULL, em->net, NULL);
acpar.match = im->match;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 1/4] net: sched: em_ipt: match only on ip/ipv6 traffic
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
In-Reply-To: <20190626155615.16639-1-nikolay@cumulusnetworks.com>
Restrict matching only to ip/ipv6 traffic and make sure we can use the
headers, otherwise matches will be attempted on any protocol which can
be unexpected by the xt matches. Currently policy supports only ipv4/6.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/sched/em_ipt.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/sched/em_ipt.c b/net/sched/em_ipt.c
index 243fd22f2248..64dbafe4e94c 100644
--- a/net/sched/em_ipt.c
+++ b/net/sched/em_ipt.c
@@ -185,6 +185,19 @@ static int em_ipt_match(struct sk_buff *skb, struct tcf_ematch *em,
struct nf_hook_state state;
int ret;
+ switch (tc_skb_protocol(skb)) {
+ case htons(ETH_P_IP):
+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ return 0;
+ break;
+ case htons(ETH_P_IPV6):
+ if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+ return 0;
+ break;
+ default:
+ return 0;
+ }
+
rcu_read_lock();
if (skb->skb_iif)
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 0/4] em_ipt: add support for addrtype
From: Nikolay Aleksandrov @ 2019-06-26 15:56 UTC (permalink / raw)
To: netdev
Cc: roopa, pablo, xiyou.wangcong, davem, jiri, jhs, eyal.birger,
Nikolay Aleksandrov
Hi,
We would like to be able to use the addrtype from tc for ACL rules and
em_ipt seems the best place to add support for the already existing xt
match. The biggest issue is that addrtype revision 1 (with ipv6 support)
is NFPROTO_UNSPEC and currently em_ipt can't differentiate between v4/v6
if such xt match is used because it passes the match's family instead of
the user-specified one. The first 3 patches make em_ipt match only on IP
traffic (currently both policy and addrtype recognize such traffic
only) and make it pass the actual packet's protocol instead of the xt
match family when it's unspecified. They also add support for NFPROTO_UNSPEC
xt matches. The last patch allows to add addrtype rules via em_ipt.
v2: change patch 02 to set the nfproto only when unspecified and drop
patch 04 from v1 (Eyal Birger)
Thank you,
Nikolay Aleksandrov
Nikolay Aleksandrov (4):
net: sched: em_ipt: match only on ip/ipv6 traffic
net: sched: em_ipt: set the family based on the packet if it's
unspecified
net: sched: em_ipt: keep the user-specified nfproto and use it
net: sched: em_ipt: add support for addrtype matching
net/sched/em_ipt.c | 49 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 47 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH net-next 12/18] ionic: Add async link status check and basic stats
From: Shannon Nelson @ 2019-06-26 15:54 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625164713.00ecc9aa@cakuba.netronome.com>
On 6/25/19 4:47 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:18 -0700, Shannon Nelson wrote:
>> + /* filter out the no-change cases */
>> + if ((link_up && netif_carrier_ok(netdev)) ||
>> + (!link_up && !netif_carrier_ok(netdev)))
> nit: these are both bools, you can compare them:
>
> if (link_up == netif_carrier_ok(netdev))
>
>> + return;
Yep - thanks.
sln
^ permalink raw reply
* Re: [PATCH net-next 11/18] ionic: Add Rx filter and rx_mode nod support
From: Shannon Nelson @ 2019-06-26 15:53 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625164456.606dd40a@cakuba.netronome.com>
On 6/25/19 4:44 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:17 -0700, Shannon Nelson wrote:
>> Add the Rx filtering and rx_mode NDO callbacks. Also add
>> the deferred work thread handling needed to manage the filter
>> requests otuside of the netif_addr_lock spinlock.
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
>> static int ionic_vlan_rx_kill_vid(struct net_device *netdev, __be16 proto,
>> u16 vid)
>> {
>> - netdev_info(netdev, "%s: stubbed\n", __func__);
>> + struct lif *lif = netdev_priv(netdev);
>> + struct ionic_admin_ctx ctx = {
>> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
>> + .cmd.rx_filter_del = {
>> + .opcode = CMD_OPCODE_RX_FILTER_DEL,
>> + .lif_index = cpu_to_le16(lif->index),
>> + },
>> + };
>> + struct rx_filter *f;
>> + int err;
>> +
>> + spin_lock_bh(&lif->rx_filters.lock);
>> +
>> + f = ionic_rx_filter_by_vlan(lif, vid);
>> + if (!f) {
>> + spin_unlock_bh(&lif->rx_filters.lock);
>> + return -ENOENT;
>> + }
>> +
>> + netdev_dbg(netdev, "rx_filter del VLAN %d (id %d)\n", vid,
>> + le32_to_cpu(ctx.cmd.rx_filter_del.filter_id));
>> +
>> + ctx.cmd.rx_filter_del.filter_id = cpu_to_le32(f->filter_id);
>> + ionic_rx_filter_free(lif, f);
>> + spin_unlock_bh(&lif->rx_filters.lock);
>> +
>> + err = ionic_adminq_post_wait(lif, &ctx);
>> + if (err)
>> + return err;
>>
>> return 0;
> nit: return directly?
Sure.
>
>> }
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.h b/drivers/net/ethernet/pensando/ionic/ionic_lif.h
>> index 8129fa20695a..c3ecf1df9c2c 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic_lif.h
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.h
>> @@ -60,6 +60,29 @@ struct qcq {
>> #define napi_to_qcq(napi) container_of(napi, struct qcq, napi)
>> #define napi_to_cq(napi) (&napi_to_qcq(napi)->cq)
>>
>> +enum deferred_work_type {
>> + DW_TYPE_RX_MODE,
>> + DW_TYPE_RX_ADDR_ADD,
>> + DW_TYPE_RX_ADDR_DEL,
>> + DW_TYPE_LINK_STATUS,
>> + DW_TYPE_LIF_RESET,
>> +};
>> +
>> +struct deferred_work {
> If you don't mind prefixing these structures with ionic_ that'd be
> great. I'm worried deferred_work is too close to delayed_work..
Yes.
>
>> + struct list_head list;
>> + enum deferred_work_type type;
>> + union {
>> + unsigned int rx_mode;
>> + u8 addr[ETH_ALEN];
>> + };
>> +};
>> +
>> +struct deferred {
>> + spinlock_t lock; /* lock for deferred work list */
>> + struct list_head list;
>> + struct work_struct work;
>> +};
^ permalink raw reply
* Re: [PATCH net-next 10/18] ionic: Add management of rx filters
From: Shannon Nelson @ 2019-06-26 15:52 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625163729.617346e0@cakuba.netronome.com>
On 6/25/19 4:37 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:16 -0700, Shannon Nelson wrote:
>> +int ionic_rx_filter_save(struct lif *lif, u32 flow_id, u16 rxq_index,
>> + u32 hash, struct ionic_admin_ctx *ctx)
>> +{
>> + struct device *dev = lif->ionic->dev;
>> + struct hlist_head *head;
>> + struct rx_filter *f;
>> + unsigned int key;
>> +
>> + f = devm_kzalloc(dev, sizeof(*f), GFP_KERNEL);
>> + if (!f)
>> + return -ENOMEM;
>> +
>> + f->flow_id = flow_id;
>> + f->filter_id = le32_to_cpu(ctx->comp.rx_filter_add.filter_id);
>> + f->rxq_index = rxq_index;
>> + memcpy(&f->cmd, &ctx->cmd, sizeof(f->cmd));
>> +
>> + INIT_HLIST_NODE(&f->by_hash);
>> + INIT_HLIST_NODE(&f->by_id);
>> +
>> + switch (le16_to_cpu(f->cmd.match)) {
>> + case RX_FILTER_MATCH_VLAN:
>> + key = le16_to_cpu(f->cmd.vlan.vlan) & RX_FILTER_HLISTS_MASK;
>> + break;
>> + case RX_FILTER_MATCH_MAC:
>> + key = *(u32 *)f->cmd.mac.addr & RX_FILTER_HLISTS_MASK;
>> + break;
>> + case RX_FILTER_MATCH_MAC_VLAN:
>> + key = le16_to_cpu(f->cmd.mac_vlan.vlan) & RX_FILTER_HLISTS_MASK;
>> + break;
>> + default:
> I know you use devm_kzalloc() but can't this potentially keep arbitrary
> amounts of memory held until the device is removed (and it's the entire
> device not just a LIF)?
Yes, but we're freeing this memory when objects are deleted. We're
trying to be tidy with our allocations, but used devm_kzalloc to be more
sure that things went away when the device did.
>
>> + return -ENOTSUPP;
> EOPNOTSUPP, please do not use ENOTSUPP in the drivers. It's a high
> error code, unknown to libc. We should use EOPNOTSUPP or EINVAL.
Sure.
>
>> + }
^ permalink raw reply
* [PATCH net 1/2] net/smc: hold conns_lock before calling smc_lgr_register_conn()
From: Ursula Braun @ 2019-06-26 15:47 UTC (permalink / raw)
To: davem
Cc: netdev, linux-s390, gor, heiko.carstens, raspl, kgraul, ubraun,
zhp, yuehaibing
In-Reply-To: <20190626154750.46127-1-ubraun@linux.ibm.com>
From: Huaping Zhou <zhp@smail.nju.edu.cn>
After smc_lgr_create(), the newly created link group is added
to smc_lgr_list, thus is accessible from other context.
Although link group creation is serialized by
smc_create_lgr_pending, the new link group may still be accessed
concurrently. For example, if ib_device is no longer active,
smc_ib_port_event_work() will call smc_port_terminate(), which
in turn will call __smc_lgr_terminate() on every link group of
this device. So conns_lock is required here.
Signed-off-by: Huaping Zhou <zhp@smail.nju.edu.cn>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/smc_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
index 2d2850adc2a3..4ca50ddf8d16 100644
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -652,7 +652,10 @@ int smc_conn_create(struct smc_sock *smc, struct smc_init_info *ini)
rc = smc_lgr_create(smc, ini);
if (rc)
goto out;
+ lgr = conn->lgr;
+ write_lock_bh(&lgr->conns_lock);
smc_lgr_register_conn(conn); /* add smc conn to lgr */
+ write_unlock_bh(&lgr->conns_lock);
}
conn->local_tx_ctrl.common.type = SMC_CDC_MSG_TYPE;
conn->local_tx_ctrl.len = SMC_WR_TX_SIZE;
--
2.17.1
^ permalink raw reply related
* [PATCH net 0/2] net/smc: fixes 2019-06-26
From: Ursula Braun @ 2019-06-26 15:47 UTC (permalink / raw)
To: davem
Cc: netdev, linux-s390, gor, heiko.carstens, raspl, kgraul, ubraun,
zhp, yuehaibing
Dave,
here are 2 small smc fixes for the net tree.
Thanks, Ursula
Huaping Zhou (1):
net/smc: hold conns_lock before calling smc_lgr_register_conn()
YueHaibing (1):
net/smc: Fix error path in smc_init
net/smc/af_smc.c | 5 ++++-
net/smc/smc_core.c | 3 +++
2 files changed, 7 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply
* [PATCH net 2/2] net/smc: Fix error path in smc_init
From: Ursula Braun @ 2019-06-26 15:47 UTC (permalink / raw)
To: davem
Cc: netdev, linux-s390, gor, heiko.carstens, raspl, kgraul, ubraun,
zhp, yuehaibing
In-Reply-To: <20190626154750.46127-1-ubraun@linux.ibm.com>
From: YueHaibing <yuehaibing@huawei.com>
If register_pernet_subsys success in smc_init,
we should cleanup it in case any other error.
Fixes: 64e28b52c7a6 (net/smc: add pnet table namespace support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 0c874e996f85..7621ec2f539c 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -2029,7 +2029,7 @@ static int __init smc_init(void)
rc = smc_pnet_init();
if (rc)
- return rc;
+ goto out_pernet_subsys;
rc = smc_llc_init();
if (rc) {
@@ -2080,6 +2080,9 @@ static int __init smc_init(void)
proto_unregister(&smc_proto);
out_pnet:
smc_pnet_exit();
+out_pernet_subsys:
+ unregister_pernet_subsys(&smc_net_ops);
+
return rc;
}
--
2.17.1
^ permalink raw reply related
* Re: [EXT] [PATCH net-next 03/16] qlge: Deduplicate lbq_buf_size
From: Willem de Bruijn @ 2019-06-26 15:42 UTC (permalink / raw)
To: Benjamin Poirier; +Cc: Manish Chopra, GR-Linux-NIC-Dev, netdev@vger.kernel.org
In-Reply-To: <20190626113726.GB27420@f1>
On Wed, Jun 26, 2019 at 7:37 AM Benjamin Poirier <bpoirier@suse.com> wrote:
>
> On 2019/06/26 09:24, Manish Chopra wrote:
> > > -----Original Message-----
> > > From: Benjamin Poirier <bpoirier@suse.com>
> > > Sent: Monday, June 17, 2019 1:19 PM
> > > To: Manish Chopra <manishc@marvell.com>; GR-Linux-NIC-Dev <GR-Linux-
> > > NIC-Dev@marvell.com>; netdev@vger.kernel.org
> > > Subject: [EXT] [PATCH net-next 03/16] qlge: Deduplicate lbq_buf_size
> > >
> > > External Email
> > >
> > > ----------------------------------------------------------------------
> > > lbq_buf_size is duplicated to every rx_ring structure whereas lbq_buf_order is
> > > present once in the ql_adapter structure. All rings use the same buf size, keep
> > > only one copy of it. Also factor out the calculation of lbq_buf_size instead of
> > > having two copies.
> > >
> > > Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
> > > ---
> [...]
> >
> > Not sure if this change is really required, I think fields relevant to rx_ring should be present in the rx_ring structure.
> > There are various other fields like "lbq_len" and "lbq_size" which would be same for all rx rings but still under the relevant rx_ring structure.
The one argument against deduplicating might be if the original fields
are in a hot cacheline and the new location adds a cacheline access to
a hot path. Not sure if that is relevant here. But maybe something to
double check.
^ permalink raw reply
* Re: [PATCH net-next 09/18] ionic: Add the basic NDO callbacks for netdev support
From: Shannon Nelson @ 2019-06-26 15:41 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625162738.15049dc7@cakuba.netronome.com>
On 6/25/19 4:27 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:15 -0700, Shannon Nelson wrote:
>> +static int ionic_set_features(struct net_device *netdev,
>> + netdev_features_t features)
>> +{
>> + struct lif *lif = netdev_priv(netdev);
>> + int err;
>> +
>> + netdev_dbg(netdev, "%s: lif->features=0x%08llx new_features=0x%08llx\n",
>> + __func__, (u64)lif->netdev->features, (u64)features);
>> +
>> + err = ionic_set_nic_features(lif, features);
> Presumably something gets added here in later patch?
This is a pass-through to the lif-specific function which does most of
the work.
>
>> + return err;
>> +}
>> +
>> +static int ionic_set_mac_address(struct net_device *netdev, void *sa)
>> +{
>> + netdev_info(netdev, "%s: stubbed\n", __func__);
>> + return 0;
>> +}
>> +
>> +static int ionic_change_mtu(struct net_device *netdev, int new_mtu)
>> +{
>> + struct lif *lif = netdev_priv(netdev);
>> + struct ionic_admin_ctx ctx = {
>> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
>> + .cmd.lif_setattr = {
>> + .opcode = CMD_OPCODE_LIF_SETATTR,
>> + .index = cpu_to_le16(lif->index),
>> + .attr = IONIC_LIF_ATTR_MTU,
>> + .mtu = cpu_to_le32(new_mtu),
>> + },
>> + };
>> + int err;
>> +
>> + if (new_mtu < IONIC_MIN_MTU || new_mtu > IONIC_MAX_MTU) {
>> + netdev_err(netdev, "Invalid MTU %d\n", new_mtu);
>> + return -EINVAL;
>> + }
> We do the min/max checks in the core now (netdev->min_mtu,
> netdev->max_mtu). You'll have to keep this if out of tree,
> unfortunately.
Got it.
>
>> + err = ionic_adminq_post_wait(lif, &ctx);
>> + if (err)
>> + return err;
>> +
>> + netdev->mtu = new_mtu;
>> + err = ionic_reset_queues(lif);
>> +
>> + return err;
>> +}
^ permalink raw reply
* Re: [EXT] [PATCH net-next 05/16] qlge: Remove rx_ring.sbq_buf_size
From: Willem de Bruijn @ 2019-06-26 15:35 UTC (permalink / raw)
To: Benjamin Poirier; +Cc: Manish Chopra, GR-Linux-NIC-Dev, netdev@vger.kernel.org
In-Reply-To: <20190626113959.GC27420@f1>
On Wed, Jun 26, 2019 at 7:40 AM Benjamin Poirier <bpoirier@suse.com> wrote:
>
> On 2019/06/26 09:36, Manish Chopra wrote:
> > > -----Original Message-----
> > > From: Benjamin Poirier <bpoirier@suse.com>
> > > Sent: Monday, June 17, 2019 1:19 PM
> > > To: Manish Chopra <manishc@marvell.com>; GR-Linux-NIC-Dev <GR-Linux-
> > > NIC-Dev@marvell.com>; netdev@vger.kernel.org
> > > Subject: [EXT] [PATCH net-next 05/16] qlge: Remove rx_ring.sbq_buf_size
> > >
> > > External Email
> > >
> > > ----------------------------------------------------------------------
> > > Tx rings have sbq_buf_size = 0 but there's no case where the code actually
> > > tests on that value. We can remove sbq_buf_size and use a constant instead.
> > >
> >
> > Seems relevant to RX ring, not the TX ring ?
>
> qlge uses "struct rx_ring" for rx and for tx completion rings.
>
> The driver's author is probably laughing now at the success of his plan
> to confuse those who would follow in his footsteps.
:-)
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH 1/2] net: stmmac: Fix possible deadlock when disabling EEE support
From: Willem de Bruijn @ 2019-06-26 15:29 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Network Development, linux-kernel, linux-tegra
In-Reply-To: <20190626104525.GH6362@ulmo>
On Wed, Jun 26, 2019 at 6:45 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Jun 26, 2019 at 11:23:21AM +0100, Jon Hunter wrote:
> > 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>
> > ---
> > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH] bonding: Always enable vlan tx offload
From: Yuehaibing @ 2019-06-26 15:29 UTC (permalink / raw)
To: Jiri Pirko
Cc: davem, sdf, jianbol, jiri, mirq-linux, willemb, sdf, j.vosburgh,
vfalico, andy, linux-kernel, netdev
In-Reply-To: <20190626152505.GB2424@nanopsycho>
On 2019/6/26 23:25, Jiri Pirko wrote:
> Wed, Jun 26, 2019 at 10:08:44AM CEST, yuehaibing@huawei.com wrote:
>> We build vlan on top of bonding interface, which vlan offload
>> is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
>> BOND_XMIT_POLICY_ENCAP34.
>>
>> Because vlan tx offload is off, vlan tci is cleared and skb push
>> the vlan header in validate_xmit_vlan() while sending from vlan
>> devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
>> get information from protocol headers encapsulated within vlan,
>> because 'nhoff' is points to IP header, so bond hashing is based
>> on layer 2 info, which fails to distribute packets across slaves.
>>
>> This patch always enable bonding's vlan tx offload, pass the vlan
>> packets to the slave devices with vlan tci, let them to handle
>> vlan implementation.
>>
>> Fixes: 278339a42a1b ("bonding: propogate vlan_features to bonding master")
>> Suggested-by: Jiri Pirko <jiri@resnulli.us>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
>
> Could you please do the same for team? Thanks!
Sure, will send it, thank you!
>
> .
>
^ permalink raw reply
* Re: [PATCH bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Lorenz Bauer @ 2019-06-26 15:26 UTC (permalink / raw)
To: Song Liu
Cc: Networking, bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team
In-Reply-To: <3AE4213C-9DFA-407F-B8D4-DB00950E577D@fb.com>
On Wed, 26 Jun 2019 at 16:19, Song Liu <songliubraving@fb.com> wrote:
> > I know nothing about the scheduler, so pardon my ignorance. Does
> > TASK_BPF_FLAG_PERMITTED apply per user-space process, or per thread?
>
> It is per thread. clone() also clears the bit. I will make it more
> clear int the commit log.
In that case this is going to be very hard if not impossible to use
from languages that
don't allow controlling threads, aka Go. I'm sure there are other
examples as well.
Is it possible to make this per-process instead?
--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
www.cloudflare.com
^ permalink raw reply
* Re: XDP multi-buffer incl. jumbo-frames (Was: [RFC V1 net-next 1/1] net: ena: implement XDP drop support)
From: Willem de Bruijn @ 2019-06-26 15:20 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Jesper Dangaard Brouer, Machulsky, Zorik, Jubran, Samih,
davem@davemloft.net, netdev@vger.kernel.org, Woodhouse, David,
Matushevsky, Alexander, Bshara, Saeed, Wilson, Matt,
Liguori, Anthony, Bshara, Nafea, Tzalik, Guy, Belgazal, Netanel,
Saidi, Ali, Herrenschmidt, Benjamin, Kiyanovski, Arthur,
Daniel Borkmann, Ilias Apalodimas, Alexei Starovoitov,
Jakub Kicinski, xdp-newbies@vger.kernel.org
In-Reply-To: <87h88cbdbe.fsf@toke.dk>
On Wed, Jun 26, 2019 at 11:01 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Jesper Dangaard Brouer <brouer@redhat.com> writes:
>
> > On Wed, 26 Jun 2019 13:52:16 +0200
> > Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> >
> >> Jesper Dangaard Brouer <brouer@redhat.com> writes:
> >>
> >> > On Tue, 25 Jun 2019 03:19:22 +0000
> >> > "Machulsky, Zorik" <zorik@amazon.com> wrote:
> >> >
> >> >> On 6/23/19, 7:21 AM, "Jesper Dangaard Brouer" <brouer@redhat.com> wrote:
> >> >>
> >> >> On Sun, 23 Jun 2019 10:06:49 +0300 <sameehj@amazon.com> wrote:
> >> >>
> >> >> > This commit implements the basic functionality of drop/pass logic in the
> >> >> > ena driver.
> >> >>
> >> >> Usually we require a driver to implement all the XDP return codes,
> >> >> before we accept it. But as Daniel and I discussed with Zorik during
> >> >> NetConf[1], we are going to make an exception and accept the driver
> >> >> if you also implement XDP_TX.
> >> >>
> >> >> As we trust that Zorik/Amazon will follow and implement XDP_REDIRECT
> >> >> later, given he/you wants AF_XDP support which requires XDP_REDIRECT.
> >> >>
> >> >> Jesper, thanks for your comments and very helpful discussion during
> >> >> NetConf! That's the plan, as we agreed. From our side I would like to
> >> >> reiterate again the importance of multi-buffer support by xdp frame.
> >> >> We would really prefer not to see our MTU shrinking because of xdp
> >> >> support.
> >> >
> >> > Okay we really need to make a serious attempt to find a way to support
> >> > multi-buffer packets with XDP. With the important criteria of not
> >> > hurting performance of the single-buffer per packet design.
> >> >
> >> > I've created a design document[2], that I will update based on our
> >> > discussions: [2] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org
> >> >
> >> > The use-case that really convinced me was Eric's packet header-split.
Thanks for starting this discussion Jesper!
> >> >
> >> >
> >> > Lets refresh: Why XDP don't have multi-buffer support:
> >> >
> >> > XDP is designed for maximum performance, which is why certain driver-level
> >> > use-cases were not supported, like multi-buffer packets (like jumbo-frames).
> >> > As it e.g. complicated the driver RX-loop and memory model handling.
> >> >
> >> > The single buffer per packet design, is also tied into eBPF Direct-Access
> >> > (DA) to packet data, which can only be allowed if the packet memory is in
> >> > contiguous memory. This DA feature is essential for XDP performance.
> >> >
> >> >
> >> > One way forward is to define that XDP only get access to the first
> >> > packet buffer, and it cannot see subsequent buffers. For XDP_TX and
> >> > XDP_REDIRECT to work then XDP still need to carry pointers (plus
> >> > len+offset) to the other buffers, which is 16 bytes per extra buffer.
> >>
> >> Yeah, I think this would be reasonable. As long as we can have a
> >> metadata field with the full length + still give XDP programs the
> >> ability to truncate the packet (i.e., discard the subsequent pages)
> >
> > You touch upon some interesting complications already:
> >
> > 1. It is valuable for XDP bpf_prog to know "full" length?
> > (if so, then we need to extend xdp ctx with info)
>
> Valuable, quite likely. A hard requirement, probably not (for all use
> cases).
Agreed.
One common validation use would be to drop any packets whose header
length disagrees with the actual packet length.
> > But if we need to know the full length, when the first-buffer is
> > processed. Then realize that this affect the drivers RX-loop, because
> > then we need to "collect" all the buffers before we can know the
> > length (although some HW provide this in first descriptor).
> >
> > We likely have to change drivers RX-loop anyhow, as XDP_TX and
> > XDP_REDIRECT will also need to "collect" all buffers before the packet
> > can be forwarded. (Although this could potentially happen later in
> > driver loop when it meet/find the End-Of-Packet descriptor bit).
Yes, this might be quite a bit of refactoring of device driver code.
Should we move forward with some initial constraints, e.g., no
XDP_REDIRECT, no "full" length and no bpf_xdp_adjust_tail?
That already allows many useful programs.
As long as we don't arrive at a design that cannot be extended with
those features later.
> >
> >
> > 2. Can we even allow helper bpf_xdp_adjust_tail() ?
> >
> > Wouldn't it be easier to disallow a BPF-prog with this helper, when
> > driver have configured multi-buffer?
>
> Easier, certainly. But then it's even easier to not implement this at
> all ;)
>
> > Or will it be too restrictive, if jumbo-frame is very uncommon and
> > only enabled because switch infra could not be changed (like Amazon
> > case).
Header-split, LRO and jumbo frame are certainly not limited to the Amazon case.
> I think it would be preferable to support it; but maybe we can let that
> depend on how difficult it actually turns out to be to allow it?
>
> > Perhaps it is better to let bpf_xdp_adjust_tail() fail runtime?
>
> If we do disallow it, I think I'd lean towards failing the call at
> runtime...
Disagree. I'd rather have a program fail at load if it depends on
multi-frag support while the (driver) implementation does not yet
support it.
^ permalink raw reply
* Re: [PATCH net-next 08/18] ionic: Add notifyq support
From: Shannon Nelson @ 2019-06-26 15:26 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20190625162100.77a81054@cakuba.netronome.com>
On 6/25/19 4:21 PM, Jakub Kicinski wrote:
> On Thu, 20 Jun 2019 13:24:14 -0700, Shannon Nelson wrote:
>> + case EVENT_OPCODE_HEARTBEAT:
>> + netdev_info(netdev, "Notifyq EVENT_OPCODE_HEARTBEAT eid=%lld\n",
>> + eid);
>> + break;
> I wonder how often this gets sent and whether the info log level is
> really necessary for a correctly working heartbeat?
Now that our FW folks have just recently settled on a proper heartbeat
mechanism, this will be removed and replaced.
sln
^ permalink raw reply
* Re: [PATCH] bonding: Always enable vlan tx offload
From: Jiri Pirko @ 2019-06-26 15:25 UTC (permalink / raw)
To: YueHaibing
Cc: davem, sdf, jianbol, jiri, mirq-linux, willemb, sdf, j.vosburgh,
vfalico, andy, linux-kernel, netdev
In-Reply-To: <20190626080844.20796-1-yuehaibing@huawei.com>
Wed, Jun 26, 2019 at 10:08:44AM CEST, yuehaibing@huawei.com wrote:
>We build vlan on top of bonding interface, which vlan offload
>is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
>BOND_XMIT_POLICY_ENCAP34.
>
>Because vlan tx offload is off, vlan tci is cleared and skb push
>the vlan header in validate_xmit_vlan() while sending from vlan
>devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
>get information from protocol headers encapsulated within vlan,
>because 'nhoff' is points to IP header, so bond hashing is based
>on layer 2 info, which fails to distribute packets across slaves.
>
>This patch always enable bonding's vlan tx offload, pass the vlan
>packets to the slave devices with vlan tci, let them to handle
>vlan implementation.
>
>Fixes: 278339a42a1b ("bonding: propogate vlan_features to bonding master")
>Suggested-by: Jiri Pirko <jiri@resnulli.us>
>Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Could you please do the same for team? Thanks!
^ permalink raw reply
* Re: [PATCH bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Song Liu @ 2019-06-26 15:19 UTC (permalink / raw)
To: Lorenz Bauer
Cc: Networking, bpf, Alexei Starovoitov, Daniel Borkmann, Kernel Team
In-Reply-To: <CACAyw99isFcFhnrmagmzPPR1vNGqcmDU+Pq7SWeeZV8RSpeBug@mail.gmail.com>
> On Jun 26, 2019, at 6:45 AM, Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> On Tue, 25 Jun 2019 at 19:23, Song Liu <songliubraving@fb.com> wrote:
>>
>> This patch introduce unprivileged BPF access. The access control is
>> achieved via device /dev/bpf. Users with access to /dev/bpf are able
>> to access BPF syscall.
>>
>> Two ioctl command are added to /dev/bpf:
>>
>> The first two commands get/put permission to access sys_bpf. This
>> permission is noted by setting bit TASK_BPF_FLAG_PERMITTED of
>> current->bpf_flags. This permission cannot be inherited via fork().
>
> I know nothing about the scheduler, so pardon my ignorance. Does
> TASK_BPF_FLAG_PERMITTED apply per user-space process, or per thread?
It is per thread. clone() also clears the bit. I will make it more
clear int the commit log.
Thanks,
Song
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox