* [PATCH][next] bpf: fix spelling mistake: "funcation"-> "function"
From: Colin King @ 2017-12-18 14:03 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in error message text.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 6d8e432453b8..2f6f09cd1925 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -772,7 +772,7 @@ static int check_subprogs(struct bpf_verifier_env *env)
return -EPERM;
}
if (bpf_prog_is_dev_bound(env->prog->aux)) {
- verbose(env, "funcation calls in offloaded programs are not supported yet\n");
+ verbose(env, "function calls in offloaded programs are not supported yet\n");
return -EINVAL;
}
ret = add_subprog(env, i + insn[i].imm + 1);
--
2.14.1
^ permalink raw reply related
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Rafael J. Wysocki @ 2017-12-18 14:09 UTC (permalink / raw)
To: Marcin Wojtas, linux-kernel, linux-arm-kernel, netdev
Cc: davem, linux, andrew, f.fainelli, antoine.tenart,
thomas.petazzoni, gregory.clement, ezequiel.garcia, nadavh, neta,
ard.biesheuvel, jaz, tn
In-Reply-To: <1513588684-15647-1-git-send-email-mw@semihalf.com>
On 12/18/2017 10:17 AM, Marcin Wojtas wrote:
> Hi,
>
> This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> First three patches introduce fwnode helpers for obtaining PHY
> information from nodes and also MDIO fwnode API for registering
> the bus with its PHY/devices.
>
> Following patches update code of the mvmdio and mvpp2 drivers
> to support ACPI tables handling. The latter is done in 4 steps,
> as can be seen in the commits. For the details, please
> refer to the commit messages.
>
> Drivers operation was tested on top of the net-next branch
> with both DT and ACPI. Although for compatibility reasons
> with older platforms, the mvmdio driver keeps using
> of_ MDIO registering, new fwnode_ one proved to fully work
> with DT as well (tested on MacchiatoBin board).
>
> mvpp2/mvmdio driver can work with the ACPI representation, as exposed
> on a public branch:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> It was compiled together with the most recent Tianocore EDK2 revision.
> Please refer to the firmware build instruction on MacchiatoBin board:
> http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>
> Above support configures 1G to use its PHY normally. 10G can work now
> only with the link interrupt mode. Somehow reading of the
> string property in fwnode_mdiobus_child_is_phy works only with
> DT and cannot cope with 10G PHY nodes as in:
> https://pastebin.com/3JnYpU0A
>
> Above root cause will be further checked. In the meantime I will
> appreciate any comments or remarks for the kernel patches.
>
> Best regards,
> Marcin
>
> Marcin Wojtas (8):
> device property: Introduce fwnode_get_mac_address()
> device property: Introduce fwnode_get_phy_mode()
> mdio_bus: Introduce fwnode MDIO helpers
> net: mvmdio: add ACPI support
> net: mvpp2: simplify maintaining enabled ports' list
> net: mvpp2: use device_*/fwnode_* APIs instead of of_*
> net: mvpp2: handle PHY with its fwnode
> net: mvpp2: enable ACPI support in the driver
>
> drivers/base/property.c | 52 +++--
> drivers/net/ethernet/marvell/mvmdio.c | 42 +++-
> drivers/net/ethernet/marvell/mvpp2.c | 246 ++++++++++++--------
> drivers/net/phy/mdio_bus.c | 218 +++++++++++++++++
> include/linux/mdio.h | 3 +
> include/linux/property.h | 3 +
> 6 files changed, 454 insertions(+), 110 deletions(-)
>
Please CC linux-acpi on all submissions of patches touching ACPI,
property.c or property.h.
Thanks!
^ permalink raw reply
* RE: [PATCH 25/27] qede: Use timecounter_reset interface
From: Kalluru, Sudarsana @ 2017-12-18 14:13 UTC (permalink / raw)
To: Sagar Arun Kamble, linux-kernel@vger.kernel.org
Cc: Richard Cochran, Elior, Ariel, Dept-Eng Everest Linux L2,
netdev@vger.kernel.org
In-Reply-To: <1513323522-15021-26-git-send-email-sagar.a.kamble@intel.com>
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
-----Original Message-----
From: Sagar Arun Kamble [mailto:sagar.a.kamble@intel.com]
Sent: 15 December 2017 13:09
To: linux-kernel@vger.kernel.org
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>; Richard Cochran <richardcochran@gmail.com>; Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>; netdev@vger.kernel.org
Subject: [PATCH 25/27] qede: Use timecounter_reset interface
With new interface timecounter_reset we can update the start time for timecounter. Update qede_ptp_settime with this new function.
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Ariel Elior <Ariel.Elior@cavium.com>
Cc: everest-linux-l2@cavium.com
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/qlogic/qede/qede_ptp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ptp.c b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
index 0d054dc..c2de311 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ptp.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
@@ -129,9 +129,9 @@ static int qede_ptp_settime(struct ptp_clock_info *info,
DP_VERBOSE(edev, QED_MSG_DEBUG, "PTP settime called, ns = %llu\n", ns);
- /* Re-init the timecounter */
+ /* Reset the timecounter */
spin_lock_bh(&ptp->lock);
- timecounter_init(&ptp->tc, ns);
+ timecounter_reset(&ptp->tc, ns);
spin_unlock_bh(&ptp->lock);
return 0;
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 18/27] bnx2x: Use timecounter_reset interface
From: Kalluru, Sudarsana @ 2017-12-18 14:13 UTC (permalink / raw)
To: Sagar Arun Kamble, linux-kernel@vger.kernel.org
Cc: Richard Cochran, Elior, Ariel, Dept-Eng Everest Linux L2,
netdev@vger.kernel.org
In-Reply-To: <1513323522-15021-19-git-send-email-sagar.a.kamble@intel.com>
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
-----Original Message-----
From: Sagar Arun Kamble [mailto:sagar.a.kamble@intel.com]
Sent: 15 December 2017 13:09
To: linux-kernel@vger.kernel.org
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>; Richard Cochran <richardcochran@gmail.com>; Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>; netdev@vger.kernel.org
Subject: [PATCH 18/27] bnx2x: Use timecounter_reset interface
With new interface timecounter_reset we can update the start time for timecounter. Update bnx2x_ptp_settime with this new function.
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Ariel Elior <ariel.elior@cavium.com>
Cc: everest-linux-l2@cavium.com
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 1e10a81..e30e736 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13849,8 +13849,8 @@ static int bnx2x_ptp_settime(struct ptp_clock_info *ptp,
DP(BNX2X_MSG_PTP, "PTP settime called, ns = %llu\n", ns);
- /* Re-init the timecounter */
- timecounter_init(&bp->timecounter, ns);
+ /* Reset the timecounter */
+ timecounter_reset(&bp->timecounter, ns);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] cxgb4: Report tid start range correctly for T6
From: Ganesh Goudar @ 2017-12-18 14:15 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Ganesh Goudar, Arjun Vynipadath
For T6, tid start range should be read from
LE_DB_ACTIVE_TABLE_START_INDEX_A register.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 4956e42..d8efcd9 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -2668,10 +2668,14 @@ static const struct file_operations mem_debugfs_fops = {
static int tid_info_show(struct seq_file *seq, void *v)
{
+ unsigned int tid_start = 0;
struct adapter *adap = seq->private;
const struct tid_info *t = &adap->tids;
enum chip_type chip = CHELSIO_CHIP_VERSION(adap->params.chip);
+ if (chip > CHELSIO_T5)
+ tid_start = t4_read_reg(adap, LE_DB_ACTIVE_TABLE_START_INDEX_A);
+
if (t4_read_reg(adap, LE_DB_CONFIG_A) & HASHEN_F) {
unsigned int sb;
seq_printf(seq, "Connections in use: %u\n",
@@ -2683,8 +2687,8 @@ static int tid_info_show(struct seq_file *seq, void *v)
sb = t4_read_reg(adap, LE_DB_SRVR_START_INDEX_A);
if (sb) {
- seq_printf(seq, "TID range: 0..%u/%u..%u", sb - 1,
- adap->tids.hash_base,
+ seq_printf(seq, "TID range: %u..%u/%u..%u", tid_start,
+ sb - 1, adap->tids.hash_base,
t->ntids - 1);
seq_printf(seq, ", in use: %u/%u\n",
atomic_read(&t->tids_in_use),
@@ -2709,7 +2713,8 @@ static int tid_info_show(struct seq_file *seq, void *v)
seq_printf(seq, "Connections in use: %u\n",
atomic_read(&t->conns_in_use));
- seq_printf(seq, "TID range: 0..%u", t->ntids - 1);
+ seq_printf(seq, "TID range: %u..%u", tid_start,
+ tid_start + t->ntids - 1);
seq_printf(seq, ", in use: %u\n",
atomic_read(&t->tids_in_use));
}
--
2.1.0
^ permalink raw reply related
* pull-request: wireless-drivers-next 2017-12-18
From: Kalle Valo @ 2017-12-18 14:17 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
luciano.coelho-ral2JQCrhuEAvxtiuMwx3w
Hi Dave,
a pull request for 4.16 to net-next tree. This is a big one, but on the
other hand most of the stuff here has been some time on linux-next so
hopefully there are no nasty surprises. Even though Arnd just send a
patch[1] five minutes ago about fixing a wcn36xx build warning, but I
don't think that's critical enough to hold up this, so I'll send it to
you in the next pull request.
But this time we actually have a merge conflict due to a000 hardware
rename in iwlwifi:
CONFLICT (content): Merge conflict in drivers/net/wireless/intel/iwlwifi/pcie/drv.c
The fix is quite straightforward, take the 22000 versions and manually
add an entry for 0xA0F0 device:
{IWL_PCI_DEVICE(0xA0F0, 0x0000, iwl22000_2ax_cfg_hr)},
I put the 'git diff' output of my test resolution below, hopefully it
helps. I'll also Cc Luca so he can correct any mistakes I did :)
Please let me know if you have any problems.
[1] https://patchwork.kernel.org/patch/10119565/
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@@ -652,20 -651,19 +652,20 @@@ static const struct pci_device_id iwl_h
{IWL_PCI_DEVICE(0xA370, 0x4034, iwl9560_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x40A4, iwl9462_2ac_cfg_soc)},
- /* a000 Series */
- {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x34F0, 0x0310, iwla000_2ac_cfg_jf)},
- {IWL_PCI_DEVICE(0x2720, 0x0000, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x34F0, 0x0070, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0078, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x0030, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x2720, 0x0090, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x2720, 0x0310, iwla000_2ac_cfg_hr_cdb)},
- {IWL_PCI_DEVICE(0x40C0, 0x0000, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwla000_2ax_cfg_hr)},
- {IWL_PCI_DEVICE(0xA0F0, 0x0000, iwla000_2ax_cfg_hr)},
+ /* 22000 Series */
+ {IWL_PCI_DEVICE(0x2720, 0x0A10, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x34F0, 0x0310, iwl22000_2ac_cfg_jf)},
+ {IWL_PCI_DEVICE(0x2720, 0x0000, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x34F0, 0x0070, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0078, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0070, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x0030, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x1080, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x2720, 0x0090, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x2720, 0x0310, iwl22000_2ac_cfg_hr_cdb)},
+ {IWL_PCI_DEVICE(0x40C0, 0x0000, iwl22000_2ax_cfg_hr)},
+ {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwl22000_2ax_cfg_hr)},
++ {IWL_PCI_DEVICE(0xA0F0, 0x0000, iwl22000_2ax_cfg_hr)},
#endif /* CONFIG_IWLMVM */
The following changes since commit 0fc66ddfaf8bb8f73c965f24928f8815b470304e:
Documentation: net: dsa: Cut set_addr() documentation (2017-11-30 10:10:16 -0500)
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-2017-12-18
for you to fetch changes up to 1dde35d0b8e3a9fbf24e13d16dc583f1cc5d027b:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-12-14 18:38:48 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.16
A bigger pull request this time, the most visible change being the new
driver mt76. But there's also Kconfig refactoring in ath9k and ath10k,
work beginning in iwlwifi to have rate scaling in firmware/hardware,
wcn3990 support getting closer in ath10k and lots of smaller changes.
mt76
* a new driver for MT76x2e, a 2x2 PCIe 802.11ac chipset by MediaTek
ath10k
* enable multiqueue support for all hw using mac80211 wake_tx_queue op
* new Kconfig option ATH10K_SPECTRAL to save RAM
* show tx stats on QCA9880
* new qcom,ath10k-calibration-variant DT entry
* WMI layer support for wcn3990
ath9k
* new Kconfig option ATH9K_COMMON_SPECTRAL to save RAM
wcn36xx
* hardware scan offload support
wil6210
* run-time PM support when interface is down
iwlwifi
* initial work for rate-scaling offload
* Support for new FW API version 36
* Rename the temporary hw name A000 to 22000
ssb
* make SSB a menuconfig to ease disabling it all
mwl8k
* enable non-DFS 5G channels 149-165
----------------------------------------------------------------
Anilkumar Kolli (3):
ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statistics
ath10k: move pktlog_filter out of ath10k_debug
ath10k: add per peer tx stats support for 10.2.4
Arnd Bergmann (3):
wlcore: use boottime for fw time sync
ath10k: use 64-bit crash dump timestamps
wlcore: fix unused function warning
Ashish Kalra (1):
bcma: Adjust block comment
Avraham Stern (1):
iwlwifi: mvm: add WFA vendor specific TPC report IE to probe request
Balaji Pothunoori (1):
ath10k: handling qos at STA side based on AP WMM enable/disable
Ben Greear (1):
ath10k: fix invalid STS_CAP_OFFSET_MASK
Bjorn Andersson (1):
wcn36xx: Reduce spinlock in indication handler
Colin Ian King (3):
rtlwifi: rtl818x: remove redundant check for cck_power > 15
wlcore, wl1251: fix spelling: "Couldnt" -> "Couldn't" and remove error on -ENOMEM
brcmsmac: use ARRAY_SIZE on rfseq_updategainu_events
Dan Carpenter (1):
ath9k_htc: Add a sanity check in ath9k_htc_ampdu_action()
Dedy Lansky (1):
wil6210: print human readable names of WMI commands and events
Emmanuel Grumbach (5):
iwlwifi: mvm: rs: don't override the rate history in the search cycle
iwlwifi: mvm: revert support new Coex firmware API
iwlwifi: print the version number of the firmware in hex
iwlwifi: fix the ALIVE notification layout
iwlwifi: mvm: remove set but unused variable in iwl_mvm_roc_done_wk
Eyal Ilsar (1):
wcn36xx: set default BTLE coexistence config
Felix Fietkau (3):
dt-bindings: net: add mt76 wireless device binding
mt76: add common code shared between multiple chipsets
mt76: add driver code for MT76x2e
Gregory Greenman (7):
iwlwifi: mvm: rs: introduce new API for rate scaling
iwlwifi: mvm: rs: add ops for the new rate scaling in the FW
iwlwifi: mvm: rs: add basic implementation of the new RS API handlers
iwlwifi: mvm: rs: new rate scale API - add FW notifications
iwlwifi: mvm: rs: new rate scale API - add debugfs hooks
iwlwifi: mvm: rs: add size checks when printing to a buffer
iwlwifi: mvm: rs: add sanity check when sending LQ command
Gustavo A. R. Silva (1):
ath9k: dfs: use swap macro in ath9k_check_chirping
Hamad Kadmany (1):
wil6210: abort properly in cfg suspend
Ian Molton (20):
brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
brcmfmac: Register sizes on hardware are not dependent on compiler types
brcmfmac: Split brcmf_sdiod_regrw_helper() up.
brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window()
brcmfmac: Remove dead IO code
brcmfmac: Remove bandaid for SleepCSR
brcmfmac: Remove brcmf_sdiod_request_data()
brcmfmac: Fix asymmetric IO functions.
brcmfmac: Remove noisy debugging.
brcmfmac: Rename bcmerror to err
brcmfmac: Split brcmf_sdiod_buffrw function up.
brcmfmac: whitespace fixes in brcmf_sdiod_send_buf()
brcmfmac: Clarify if using braces.
brcmfmac: Rename / replace old IO functions with simpler ones.
brcmfmac: Tidy register definitions a little
brcmfmac: Remove brcmf_sdiod_addrprep()
brcmfmac: remove unnecessary call to brcmf_sdiod_set_backplane_window()
brcmfmac: Cleanup offsetof()
brcmfmac: Remove unused macro.
brcmfmac: Remove repeated calls to brcmf_chip_get_core()
Johannes Berg (3):
iwlwifi: mvm: remove TCP wakeup support
iwlwifi: mvm: remove superfluous flush_work()
iwlwifi: mvm: request statistics when reading debugfs
Jérémy Lefaure (1):
wireless: use ARRAY_SIZE
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2017-11-29' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2017-12-05' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Kenneth Lu (2):
ath6kl: remove redundant variable ies_len
ath6kl: improve endianness handling
Larry Finger (1):
rtlwifi: Convert individual interrupt results to struct
Lazar Alexei (5):
wil6210: run-time PM when interface down
wil6210: get suspend reject reason and resume triggers from FW
wil6210: fix PCIe bus mastering in case of interface down
wil6210: remove suspend time statistics
wil6210: update statistics for suspend
Liad Kaufman (3):
iwlwifi: mvm: support MGMT frames in compressed BA
iwlwifi: dbg: allow wrt collection before ALIVE
iwlwifi: mvm: make init_dbg effective only on failure
Limin Zhu (1):
mwifiex: cfg80211: do not change virtual interface during scan processing
Lior David (5):
wil6210: refresh FW capabilities during interface up
wil6210: fix length check in __wmi_send
wil6210: add block size checks during FW load
wil6210: missing length check in wmi_set_ie
wil6210: missing length check in wil_cfg80211_mgmt_tx
Loic Poulain (1):
wcn36xx: Add hardware scan offload support
Luca Coelho (3):
iwlwifi: rename the temporary name of A000 to the official 22000
iwlwifi: bump FW API to 36 for 8000 and up
iwlwifi: mvm: fix wrong #ifdef that uses a macro from backports
Manikanta Pubbisetty (2):
ath10k: update tdls teardown state to target
ath10k: handle tdls peer events
Matthias Schiffer (2):
ath9k: move spectral scan support under a separate config symbol
ath10k: move spectral scan support under a separate config symbol
Nicolas Iooss (1):
rtlwifi: always initialize variables given to RT_TRACE()
Ping-Ke Shih (4):
rtlwifi: Reduce IO in RX interrupt to boost throughput
rtlwifi: fix the wrong size to calculate fifo space
rtlwifi: cleanup the code that check whether TX ring is available
rtlwifi: rtl_pci: 8822BE puts broadcast and multicast packet to HIQ
Rajkumar Manoharan (1):
ath10k: unify rx processing in napi_poll
Rakesh Pillai (4):
ath10k: wmi: modify svc bitmap parsing for wcn3990
ath10k: wmi: add management tx by reference support over wmi
ath10k: wmi: get wmi init parameter values from hw params
ath10k: wmi: add hw params entry for wcn3990
Reizer, Eyal (1):
wlcore: allow elp during wowlan suspend
Sara Sharon (2):
iwlwifi: mvm: check for short GI only for OFDM
iwlwifi: mvm: avoid dumping assert log when device is stopped
Sven Eckelmann (2):
dt: bindings: add new dt entry for ath10k calibration variant
ath10k: search DT for qcom,ath10k-calibration-variant
Toke Høiland-Jørgensen (1):
ath10k: re-enable TXQs for all devices
Tsang-Shian Lin (1):
rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
Vincent Legoll (1):
ssb: make SSB a menuconfig to ease disabling it all
Weixiao Zhang (1):
mwl8k: Expand non-DFS 5G channels
Wright Feng (1):
brcmfmac: enlarge buffer size of caps to 512 bytes
Xinming Hu (1):
mwifiex: do not support change AP interface to station mode
.../bindings/net/wireless/mediatek,mt76.txt | 32 +
.../bindings/net/wireless/qcom,ath10k.txt | 3 +
drivers/bcma/driver_pcie2.c | 3 +-
drivers/net/wireless/ath/ath10k/Kconfig | 9 +-
drivers/net/wireless/ath/ath10k/Makefile | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 95 ++-
drivers/net/wireless/ath/ath10k/core.h | 10 +-
drivers/net/wireless/ath/ath10k/debug.c | 18 +-
drivers/net/wireless/ath/ath10k/debug.h | 21 +-
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 27 -
drivers/net/wireless/ath/ath10k/htt.h | 19 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 181 +++--
drivers/net/wireless/ath/ath10k/hw.c | 2 +
drivers/net/wireless/ath/ath10k/hw.h | 14 +
drivers/net/wireless/ath/ath10k/mac.c | 65 +-
drivers/net/wireless/ath/ath10k/spectral.h | 4 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 9 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 146 +++-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 113 +++
drivers/net/wireless/ath/ath10k/wmi.c | 72 ++
drivers/net/wireless/ath/ath10k/wmi.h | 5 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 -
drivers/net/wireless/ath/ath6kl/txrx.c | 2 +-
drivers/net/wireless/ath/ath9k/Kconfig | 14 +-
drivers/net/wireless/ath/ath9k/Makefile | 4 +-
drivers/net/wireless/ath/ath9k/common-spectral.h | 4 +-
drivers/net/wireless/ath/ath9k/dfs.c | 8 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 +
drivers/net/wireless/ath/wcn36xx/hal.h | 107 ++-
drivers/net/wireless/ath/wcn36xx/main.c | 16 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 126 +++-
drivers/net/wireless/ath/wcn36xx/smd.h | 3 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 17 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 150 +++-
drivers/net/wireless/ath/wil6210/ethtool.c | 15 +
drivers/net/wireless/ath/wil6210/fw_inc.c | 79 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 22 +-
drivers/net/wireless/ath/wil6210/main.c | 26 +-
drivers/net/wireless/ath/wil6210/netdev.c | 18 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 97 ++-
drivers/net/wireless/ath/wil6210/pm.c | 104 ++-
drivers/net/wireless/ath/wil6210/wil6210.h | 40 +-
drivers/net/wireless/ath/wil6210/wmi.c | 304 +++++++-
drivers/net/wireless/ath/wil6210/wmi.h | 17 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 377 +++------
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 12 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 248 +++---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.h | 52 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 3 +-
.../broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 462 +++---------
drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 216 ++++++
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 216 ------
drivers/net/wireless/intel/iwlwifi/fw/api/alive.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/api/coex.h | 30 -
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 2 +-
.../net/wireless/intel/iwlwifi/fw/api/datapath.h | 15 +
drivers/net/wireless/intel/iwlwifi/fw/api/rs.h | 262 ++++++-
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 15 +-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 5 +-
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 8 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 20 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 11 +-
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 12 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/coex.c | 33 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 232 +-----
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 91 ++-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 14 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 43 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 18 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 314 ++++++++
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 234 +++---
drivers/net/wireless/intel/iwlwifi/mvm/rs.h | 48 ++
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 35 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 29 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 7 +-
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 15 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 20 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 14 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 36 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 4 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 7 +-
drivers/net/wireless/marvell/mwl8k.c | 7 +-
drivers/net/wireless/mediatek/Kconfig | 1 +
drivers/net/wireless/mediatek/Makefile | 1 +
drivers/net/wireless/mediatek/mt76/Kconfig | 10 +
drivers/net/wireless/mediatek/mt76/Makefile | 15 +
drivers/net/wireless/mediatek/mt76/debugfs.c | 77 ++
drivers/net/wireless/mediatek/mt76/dma.c | 451 +++++++++++
drivers/net/wireless/mediatek/mt76/dma.h | 38 +
drivers/net/wireless/mediatek/mt76/eeprom.c | 112 +++
drivers/net/wireless/mediatek/mt76/mac80211.c | 393 ++++++++++
drivers/net/wireless/mediatek/mt76/mmio.c | 61 ++
drivers/net/wireless/mediatek/mt76/mt76.h | 360 +++++++++
drivers/net/wireless/mediatek/mt76/mt76x2.h | 227 ++++++
drivers/net/wireless/mediatek/mt76/mt76x2_core.c | 88 +++
.../net/wireless/mediatek/mt76/mt76x2_debugfs.c | 133 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c | 493 ++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h | 80 ++
drivers/net/wireless/mediatek/mt76/mt76x2_dma.c | 183 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_dma.h | 68 ++
drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c | 647 ++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h | 182 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 839 +++++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 755 ++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.h | 190 +++++
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 545 +++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c | 451 +++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.h | 155 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_pci.c | 110 +++
drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 758 +++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_regs.h | 587 ++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76x2_trace.c | 23 +
drivers/net/wireless/mediatek/mt76/mt76x2_trace.h | 144 ++++
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 258 +++++++
drivers/net/wireless/mediatek/mt76/trace.c | 23 +
drivers/net/wireless/mediatek/mt76/trace.h | 71 ++
drivers/net/wireless/mediatek/mt76/tx.c | 511 +++++++++++++
drivers/net/wireless/mediatek/mt76/util.c | 78 ++
drivers/net/wireless/mediatek/mt76/util.h | 44 ++
.../net/wireless/realtek/rtl818x/rtl8187/rtl8225.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 75 +-
drivers/net/wireless/realtek/rtlwifi/pci.h | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 57 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 22 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/table.c | 14 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 11 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.h | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/table.c | 34 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 11 +-
drivers/net/wireless/ti/wl1251/init.c | 4 +-
drivers/net/wireless/ti/wlcore/acx.c | 2 +-
drivers/net/wireless/ti/wlcore/acx.h | 2 -
drivers/net/wireless/ti/wlcore/main.c | 41 +-
drivers/net/wireless/ti/wlcore/tx.c | 4 +-
drivers/ssb/Kconfig | 9 +-
159 files changed, 12700 insertions(+), 2097 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
create mode 100644 drivers/net/wireless/intel/iwlwifi/cfg/22000.c
delete mode 100644 drivers/net/wireless/intel/iwlwifi/cfg/a000.c
create mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
create mode 100644 drivers/net/wireless/mediatek/mt76/Kconfig
create mode 100644 drivers/net/wireless/mediatek/mt76/Makefile
create mode 100644 drivers/net/wireless/mediatek/mt76/debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mac80211.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mmio.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_core.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_dma.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_eeprom.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_init.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mac.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mac.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_main.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_mcu.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_pci.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_phy.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_regs.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_trace.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt76x2_tx.c
create mode 100644 drivers/net/wireless/mediatek/mt76/trace.c
create mode 100644 drivers/net/wireless/mediatek/mt76/trace.h
create mode 100644 drivers/net/wireless/mediatek/mt76/tx.c
create mode 100644 drivers/net/wireless/mediatek/mt76/util.c
create mode 100644 drivers/net/wireless/mediatek/mt76/util.h
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id
From: Nikolay Aleksandrov @ 2017-12-18 14:22 UTC (permalink / raw)
To: Toshiaki Makita, netdev; +Cc: roopa, davem, stephen, avagin, bridge
In-Reply-To: <0d66d7ab-2837-afcb-430f-32f6e4a5d675@lab.ntt.co.jp>
On 12/18/2017 04:24 AM, Toshiaki Makita wrote:
> On 2017/12/16 20:31, Nikolay Aleksandrov wrote:
[snip]
> ...
>> err = br_changelink(dev, tb, data, extack);
>> - if (err)
>> + if (err) {
>> + /* clean possible fdbs from br_stp_change_bridge_id above */
>> + br_fdb_delete_by_port(br, NULL, 0, 1);
>
> Don't we need to call br_dev_delete (br_link_ops.dellink) after
> successful register instead of br_fdb_delete?
> Particularly I'm wondering if not calling br_sysfs_delbr() is ok or not.
>
Funny, that is actually the only reason we need to call it (br_sysfs_delbr). :-)
Good catch, that is another leak - the bridge sysfs entries are registered when
NETDEV_REGISTER event happens (register_netdevice) but are not properly cleaned up
on error there. This has also been present since the introduction of changelink
during newlink, commit:
b6677449dff6 ("bridge: netlink: call br_changelink() during br_dev_newlink()")
I'll send v2 that does br_dev_delete(dev, NULL) instead of the current cleanup.
With kobject debug enabled and that I can see "brif" and the rest of the sysfs
files getting freed properly, while before they weren't.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id
From: Nikolay Aleksandrov @ 2017-12-18 14:23 UTC (permalink / raw)
To: Toshiaki Makita, netdev; +Cc: bridge, roopa, avagin, davem
In-Reply-To: <4b07ce51-177d-df6f-f5ac-321f85402b6c@cumulusnetworks.com>
On 12/18/2017 04:22 PM, Nikolay Aleksandrov wrote:
> On 12/18/2017 04:24 AM, Toshiaki Makita wrote:
>> On 2017/12/16 20:31, Nikolay Aleksandrov wrote:
> [snip]
>> ...
>>> err = br_changelink(dev, tb, data, extack);
>>> - if (err)
>>> + if (err) {
>>> + /* clean possible fdbs from br_stp_change_bridge_id above */
>>> + br_fdb_delete_by_port(br, NULL, 0, 1);
>>
>> Don't we need to call br_dev_delete (br_link_ops.dellink) after
>> successful register instead of br_fdb_delete?
>> Particularly I'm wondering if not calling br_sysfs_delbr() is ok or not.
>>
>
> Funny, that is actually the only reason we need to call it (br_sysfs_delbr). :-)
>
> Good catch, that is another leak - the bridge sysfs entries are registered when
> NETDEV_REGISTER event happens (register_netdevice) but are not properly cleaned up
> on error there. This has also been present since the introduction of changelink
> during newlink, commit:
> b6677449dff6 ("bridge: netlink: call br_changelink() during br_dev_newlink()")
err, since the changelink was fixed to be after device registration in commit:
5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink")
>
> I'll send v2 that does br_dev_delete(dev, NULL) instead of the current cleanup.
> With kobject debug enabled and that I can see "brif" and the rest of the sysfs
> files getting freed properly, while before they weren't.
>
> Thanks,
> Nik
>
^ permalink raw reply
* Re: [PATCH net] sctp: fix the issue that a __u16 variable may overflow in sctp_ulpq_renege
From: Neil Horman @ 2017-12-18 14:33 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <047a7d68a197ff748b48eb8cda4b08fd5b9623fe.1513577245.git.lucien.xin@gmail.com>
On Mon, Dec 18, 2017 at 02:07:25PM +0800, Xin Long wrote:
> Now when reneging events in sctp_ulpq_renege(), the variable freed
> could be increased by a __u16 value twice while freed is of __u16
> type. It means freed may overflow at the second addition.
>
> This patch is to fix it by using __u32 type for 'freed', while at
> it, also to remove 'if (chunk)' check, as all renege commands are
> generated in sctp_eat_data and it can't be NULL.
>
> Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/ulpqueue.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
> index a71be33..e36ec5d 100644
> --- a/net/sctp/ulpqueue.c
> +++ b/net/sctp/ulpqueue.c
> @@ -1084,29 +1084,21 @@ void sctp_ulpq_partial_delivery(struct sctp_ulpq *ulpq,
> void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
> gfp_t gfp)
> {
> - struct sctp_association *asoc;
> - __u16 needed, freed;
> -
> - asoc = ulpq->asoc;
> + struct sctp_association *asoc = ulpq->asoc;
> + __u32 freed = 0;
> + __u16 needed;
>
> - if (chunk) {
> - needed = ntohs(chunk->chunk_hdr->length);
> - needed -= sizeof(struct sctp_data_chunk);
> - } else
> - needed = SCTP_DEFAULT_MAXWINDOW;
> -
> - freed = 0;
> + needed = ntohs(chunk->chunk_hdr->length) -
> + sizeof(struct sctp_data_chunk);
>
> if (skb_queue_empty(&asoc->base.sk->sk_receive_queue)) {
> freed = sctp_ulpq_renege_order(ulpq, needed);
> - if (freed < needed) {
> + if (freed < needed)
> freed += sctp_ulpq_renege_frags(ulpq, needed - freed);
> - }
> }
> /* If able to free enough room, accept this chunk. */
> - if (chunk && (freed >= needed)) {
> - int retval;
> - retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
> + if (freed >= needed) {
> + int retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
> /*
> * Enter partial delivery if chunk has not been
> * delivered; otherwise, drain the reassembly queue.
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] wil6210: fix build warnings without CONFIG_PM
From: Kalle Valo @ 2017-12-18 14:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: qca_merez, QCA_ailizaro, qca_dlansky, QCA_hkadmany, qca_liord,
QCA_gidons, linux-wireless@vger.kernel.org, wil6210,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20171218134604.3087909-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> The #ifdef checks are hard to get right, in this case some functions
> should have been left inside a CONFIG_PM_SLEEP check as seen by this
> message:
>
> drivers/net/wireless/ath/wil6210/pcie_bus.c:489:12: error: 'wil6210_pm_resume' defined but not used [-Werror=unused-function]
> drivers/net/wireless/ath/wil6210/pcie_bus.c:484:12: error: 'wil6210_pm_suspend' defined but not used [-Werror=unused-function]
>
> Using an __maybe_unused is easier here, so I'm replacing all the
> other #ifdef in this file as well for consistency.
>
> Fixes: 94162666cd51 ("wil6210: run-time PM when interface down")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A note to myself (unfortunately patchwork doesn't have any way to add
notes to patches): 94162666cd51 is in wireless-drivers-next so this
patch should also go to -next.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net] sctp: add SCTP_CID_RECONF conversion in sctp_cname
From: Neil Horman @ 2017-12-18 14:37 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <ae9172b7dc432d6092ab2bc061a0cf322a3939b5.1513577597.git.lucien.xin@gmail.com>
On Mon, Dec 18, 2017 at 02:13:17PM +0800, Xin Long wrote:
> Whenever a new type of chunk is added, the corresp conversion in
> sctp_cname should be added. Otherwise, in some places, pr_debug
> will print it as "unknown chunk".
>
> Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/sctp/debug.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> index 3f619fd..291c97b 100644
> --- a/net/sctp/debug.c
> +++ b/net/sctp/debug.c
> @@ -78,6 +78,9 @@ const char *sctp_cname(const union sctp_subtype cid)
> case SCTP_CID_AUTH:
> return "AUTH";
>
> + case SCTP_CID_RECONF:
> + return "RECONF";
> +
> default:
> break;
> }
> --
> 2.1.0
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next] udp: handle gro_receive only when necessary
From: Paolo Abeni @ 2017-12-18 14:45 UTC (permalink / raw)
To: zhangliping; +Cc: davem, netdev, zhangliping
In-Reply-To: <1f4bfef5.b4c7.16069879c26.Coremail.zhanglkk1990@163.com>
On Mon, 2017-12-18 at 20:09 +0800, zhangliping wrote:
> My test case is very simple, two VMs were connected via ovs + dpdk.
> Inside VM, rps is enabled. Then one VM runs "iperf -s -u &", another
> VM runs "iperf -c 1.1.1.2 -P 12 -u -b 10Gbps -l 40 -t 36000".
Understood, thanks. Still the time spent in 'udp4_lib_lookup2' looks
quite different/higher than what I observe in my tests. Are you using
x86_64? if not, do you see many cache misses in udp4_lib_lookup2?
Thanks,
Paolo
^ permalink raw reply
* [PATCH RESEND] Bluetooth: Prevent stack info leak from the EFS element.
From: Greg Kroah-Hartman @ 2017-12-18 14:47 UTC (permalink / raw)
To: netdev
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Ben Seri,
linux-kernel
From: Ben Seri <ben@armis.com>
In the function l2cap_parse_conf_rsp and in the function
l2cap_parse_conf_req the following variable is declared without
initialization:
struct l2cap_conf_efs efs;
In addition, when parsing input configuration parameters in both of
these functions, the switch case for handling EFS elements may skip the
memcpy call that will write to the efs variable:
...
case L2CAP_CONF_EFS:
if (olen == sizeof(efs))
memcpy(&efs, (void *)val, olen);
...
The olen in the above if is attacker controlled, and regardless of that
if, in both of these functions the efs variable would eventually be
added to the outgoing configuration request that is being built:
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs);
So by sending a configuration request, or response, that contains an
L2CAP_CONF_EFS element, but with an element length that is not
sizeof(efs) - the memcpy to the uninitialized efs variable can be
avoided, and the uninitialized variable would be returned to the
attacker (16 bytes).
This issue has been assigned CVE-2017-1000410
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Ben Seri <ben@armis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bluetooth/l2cap_core.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
David, can you take this through your tree? It fixes a reported issue
and the bluetooth developers seem to be totally ignoring it for weeks
for some unknown reason :(
Or, I can take it through one of mine if you don't want to touch it.
thanks,
greg k-h
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 43ba91c440bc..fc6615d59165 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3363,9 +3363,10 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
break;
case L2CAP_CONF_EFS:
- remote_efs = 1;
- if (olen == sizeof(efs))
+ if (olen == sizeof(efs)) {
+ remote_efs = 1;
memcpy(&efs, (void *) val, olen);
+ }
break;
case L2CAP_CONF_EWS:
@@ -3584,16 +3585,17 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
break;
case L2CAP_CONF_EFS:
- if (olen == sizeof(efs))
+ if (olen == sizeof(efs)) {
memcpy(&efs, (void *)val, olen);
- if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
- efs.stype != L2CAP_SERV_NOTRAFIC &&
- efs.stype != chan->local_stype)
- return -ECONNREFUSED;
+ if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
+ efs.stype != L2CAP_SERV_NOTRAFIC &&
+ efs.stype != chan->local_stype)
+ return -ECONNREFUSED;
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
- (unsigned long) &efs, endptr - ptr);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
+ (unsigned long) &efs, endptr - ptr);
+ }
break;
case L2CAP_CONF_FCS:
^ permalink raw reply related
* Re: [PATCH net-next 2/2 v9] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Michał Mirosław @ 2017-12-18 14:48 UTC (permalink / raw)
To: Linus Walleij
Cc: netdev, David S . Miller, Janos Laube, Paulius Zaleckas,
Linux ARM, Hans Ulli Kroll, Florian Fainelli, Tobias Waldvogel
In-Reply-To: <CACRpkdZ3t9ZDB-GOoriq0Jm=-GtYzUX-qc36o_XbWO9NQzMUmA@mail.gmail.com>
On Mon, Dec 18, 2017 at 02:57:37PM +0100, Linus Walleij wrote:
> On Sat, Dec 16, 2017 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > The Gemini ethernet has been around for years as an out-of-tree
> > patch used with the NAS boxen and routers built on StorLink
> > SL3512 and SL3516, later Storm Semiconductor, later Cortina
> > Systems. These ASICs are still being deployed and brand new
> > off-the-shelf systems using it can easily be acquired.
[...]
> > ---
> > Changes from v8:
> > - Remove dependency guards in Kconfig to get a wider compile
> > coverage for the driver to detect broken APIs etc.
>
> I guess we need to hold this off for a while, the code does
> some weird stuff using the ARM-internal page DMA mapping
> API.
>
> I *think* what happens is that the driver allocates a global queue
> used for RX and TX on both interfaces, then initializes that with
> page pointers and gives that to the hardware to play with.
>
> When an RX packet comes in, the RX routine needs to figure
> out from the DMA (physical) address which remapped
> page/address this random physical address pointer
> corresponds to.
>
> The Linux DMA API assumption is that the driver keeps track
> of this mapping, not the hardware. So we need to figure out
> a way to reverse-map this. Preferably quickly, and without
> using any ARM-internal mapping APIs.
IIRC, the hardware copies descriptors from free queue (FREEQ)
to RX queues. FREEQ is shared among the two ethernet ports.
This platform is CPU bound, so every additional lookup will
hit performance here. In my version I had an #ifdef for
COMPILE_TEST that replaced ARM-specific calls with stubs.
Since the driver is not expected to work on other platforms,
this seemed like the best workaround to make it compile
on other arches.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-next 2/2 v9] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Russell King - ARM Linux @ 2017-12-18 14:54 UTC (permalink / raw)
To: Michał Mirosław
Cc: Linus Walleij, Tobias Waldvogel, Florian Fainelli,
Paulius Zaleckas, netdev, Hans Ulli Kroll, Janos Laube,
David S . Miller, Linux ARM
In-Reply-To: <20171218144817.GA25352@qmqm.qmqm.pl>
On Mon, Dec 18, 2017 at 03:48:17PM +0100, Michał Mirosław wrote:
> On Mon, Dec 18, 2017 at 02:57:37PM +0100, Linus Walleij wrote:
> > On Sat, Dec 16, 2017 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > > The Gemini ethernet has been around for years as an out-of-tree
> > > patch used with the NAS boxen and routers built on StorLink
> > > SL3512 and SL3516, later Storm Semiconductor, later Cortina
> > > Systems. These ASICs are still being deployed and brand new
> > > off-the-shelf systems using it can easily be acquired.
> [...]
> > > ---
> > > Changes from v8:
> > > - Remove dependency guards in Kconfig to get a wider compile
> > > coverage for the driver to detect broken APIs etc.
> >
> > I guess we need to hold this off for a while, the code does
> > some weird stuff using the ARM-internal page DMA mapping
> > API.
> >
> > I *think* what happens is that the driver allocates a global queue
> > used for RX and TX on both interfaces, then initializes that with
> > page pointers and gives that to the hardware to play with.
> >
> > When an RX packet comes in, the RX routine needs to figure
> > out from the DMA (physical) address which remapped
> > page/address this random physical address pointer
> > corresponds to.
> >
> > The Linux DMA API assumption is that the driver keeps track
> > of this mapping, not the hardware. So we need to figure out
> > a way to reverse-map this. Preferably quickly, and without
> > using any ARM-internal mapping APIs.
>
> IIRC, the hardware copies descriptors from free queue (FREEQ)
> to RX queues. FREEQ is shared among the two ethernet ports.
>
> This platform is CPU bound, so every additional lookup will
> hit performance here. In my version I had an #ifdef for
> COMPILE_TEST that replaced ARM-specific calls with stubs.
> Since the driver is not expected to work on other platforms,
> this seemed like the best workaround to make it compile
> on other arches.
Really. No. Stop going beneath the covers and using ARM private
implementation APIs in drivers.
Take that as a big NAK to that.
(I don't seem have the patch in question here to look at though.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH][next] ath10k: wmi: remove redundant integer fc
From: Colin King @ 2017-12-18 15:02 UTC (permalink / raw)
To: Kalle Valo, ath10k, linux-wireless, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable fc is being assigned but never used, so remove it. Cleans
up the clang warning:
warning: Value stored to 'fc' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 8d53063bd503..06fde53aa679 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2494,7 +2494,6 @@ ath10k_wmi_tlv_op_gen_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
void *ptr;
int len;
u32 buf_len = msdu->len;
- u16 fc;
struct ath10k_vif *arvif;
dma_addr_t mgmt_frame_dma;
u32 vdev_id;
@@ -2503,7 +2502,6 @@ ath10k_wmi_tlv_op_gen_mgmt_tx(struct ath10k *ar, struct sk_buff *msdu)
return ERR_PTR(-EINVAL);
hdr = (struct ieee80211_hdr *)msdu->data;
- fc = le16_to_cpu(hdr->frame_control);
arvif = (void *)cb->vif->drv_priv;
vdev_id = arvif->vdev_id;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH v10 3/5] bpf: add a bpf_override_function helper
From: Daniel Borkmann @ 2017-12-18 15:09 UTC (permalink / raw)
To: Masami Hiramatsu, Josef Bacik
Cc: rostedt, mingo, davem, netdev, linux-kernel, ast, kernel-team,
linux-btrfs, darrick.wong, Josef Bacik
In-Reply-To: <20171218185100.4a8174488dfebf93d28899c3@kernel.org>
On 12/18/2017 10:51 AM, Masami Hiramatsu wrote:
> On Fri, 15 Dec 2017 14:12:54 -0500
> Josef Bacik <josef@toxicpanda.com> wrote:
>> From: Josef Bacik <jbacik@fb.com>
>>
>> Error injection is sloppy and very ad-hoc. BPF could fill this niche
>> perfectly with it's kprobe functionality. We could make sure errors are
>> only triggered in specific call chains that we care about with very
>> specific situations. Accomplish this with the bpf_override_funciton
>> helper. This will modify the probe'd callers return value to the
>> specified value and set the PC to an override function that simply
>> returns, bypassing the originally probed function. This gives us a nice
>> clean way to implement systematic error injection for all of our code
>> paths.
>
> OK, got it. I think the error_injectable function list should be defined
> in kernel/trace/bpf_trace.c because only bpf calls it and needs to care
> the "safeness".
>
> [...]
>> diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
>> index 8dc0161cec8f..1ea748d682fd 100644
>> --- a/arch/x86/kernel/kprobes/ftrace.c
>> +++ b/arch/x86/kernel/kprobes/ftrace.c
>> @@ -97,3 +97,17 @@ int arch_prepare_kprobe_ftrace(struct kprobe *p)
>> p->ainsn.boostable = false;
>> return 0;
>> }
>> +
>> +asmlinkage void override_func(void);
>> +asm(
>> + ".type override_func, @function\n"
>> + "override_func:\n"
>> + " ret\n"
>> + ".size override_func, .-override_func\n"
>> +);
>> +
>> +void arch_ftrace_kprobe_override_function(struct pt_regs *regs)
>> +{
>> + regs->ip = (unsigned long)&override_func;
>> +}
>> +NOKPROBE_SYMBOL(arch_ftrace_kprobe_override_function);
>
> Calling this as "override_function" is meaningless. This is a function
> which just return. So I think combination of just_return_func() and
> arch_bpf_override_func_just_return() will be better.
>
> Moreover, this arch/x86/kernel/kprobes/ftrace.c is an archtecture
> dependent implementation of kprobes, not bpf.
Josef, please work out any necessary cleanups that would still need
to be addressed based on Masami's feedback and send them as follow-up
patches, thanks.
> Hmm, arch/x86/net/bpf_jit_comp.c will be better place?
(No, it's JIT only and I'd really prefer to keep it that way, mixing
this would result in a huge mess.)
^ permalink raw reply
* Re: [PATCH bpf-next 12/13] bpf: arm64: add JIT support for multi-function programs
From: Arnd Bergmann @ 2017-12-18 15:29 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S . Miller, Daniel Borkmann, John Fastabend, Edward Cree,
Jakub Kicinski, Networking, kernel-team
In-Reply-To: <20171215015517.409513-13-ast@kernel.org>
On Fri, Dec 15, 2017 at 2:55 AM, Alexei Starovoitov <ast@kernel.org> wrote:
> + if (jit_data->ctx.offset) {
> + ctx = jit_data->ctx;
> + image_ptr = jit_data->image;
> + header = jit_data->header;
> + extra_pass = true;
> + goto skip_init_ctx;
> + }
> memset(&ctx, 0, sizeof(ctx));
> ctx.prog = prog;
The 'goto' jumps over the 'image_size' initialization
> prog->bpf_func = (void *)ctx.image;
> prog->jited = 1;
> prog->jited_len = image_size;
so we now get a warning here, starting with linux-next-20171218:
arch/arm64/net/bpf_jit_comp.c: In function 'bpf_int_jit_compile':
arch/arm64/net/bpf_jit_comp.c:982:18: error: 'image_size' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
I could not figure out what the code should be doing instead, or if it is
indeed safe and the warning is a false-positive.
Arnd
^ permalink raw reply
* Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
From: Joe Perches @ 2017-12-18 15:30 UTC (permalink / raw)
To: Knut Omang, Jason Gunthorpe
Cc: Stephen Hemminger, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Mauro Carvalho Chehab, Nicolas Palix, Jonathan Corbet,
Santosh Shilimkar, Matthew Wilcox, cocci-/FJkirnvOdkvYVN+rsErww,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Doug Ledford,
Mickaël Salaün, Shuah Khan,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA, Michal Marek, Julia Lawall,
John Haxby, Åsmund Østvold, Masahiro Yamada
In-Reply-To: <1513602315.22938.49.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Mon, 2017-12-18 at 14:05 +0100, Knut Omang wrote:
> > Here is a list of the checkpatch messages for drivers/infiniband
> > sorted by type.
> >
> > Many of these might be corrected by using
> >
> > $ ./scripts/checkpatch.pl -f --fix-inplace --types=<TYPE> \
> > $(git ls-files drivers/infiniband/)
>
> Yes, and I already did that work piece by piece for individual types,
> just to test the runchecks tool, and want to post that set once the
> runchecks script and Makefile changes itself are in,
I think those are independent of any runcheck tool changes and
could be posted now. In general, don't keep patches in a local
tree waiting on some other unrelated patch.
Just fyi:
There is a script that helps automate checkpatch "by-type" conversions
with compilation, .o difference checking, and git commit editing.
https://lkml.org/lkml/2014/7/11/794
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net v2] net: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks
From: Nikolay Aleksandrov @ 2017-12-18 15:35 UTC (permalink / raw)
To: netdev
Cc: makita.toshiaki, roopa, davem, stephen, avagin, bridge, idosch,
Nikolay Aleksandrov
In-Reply-To: <e4948ab7-0f3b-a4f5-52ea-853a987f1abb@cumulusnetworks.com>
The early call to br_stp_change_bridge_id in bridge's newlink can cause
a memory leak if an error occurs during the newlink because the fdb
entries are not cleaned up if a different lladdr was specified, also
another minor issue is that it generates fdb notifications with
ifindex = 0. Another unrelated memory leak is the bridge sysfs entries
which get added on NETDEV_REGISTER event, but are not cleaned up in the
newlink error path. To remove this special case the call to
br_stp_change_bridge_id is done after netdev register and we cleanup the
bridge on changelink error via br_dev_delete to plug all leaks.
This patch makes netlink bridge destruction on newlink error the same as
dellink and ioctl del which is necessary since at that point we have a
fully initialized bridge device.
To reproduce the issue:
$ ip l add br0 address 00:11:22:33:44:55 type bridge group_fwd_mask 1
RTNETLINK answers: Invalid argument
$ rmmod bridge
[ 1822.142525] =============================================================================
[ 1822.143640] BUG bridge_fdb_cache (Tainted: G O ): Objects remaining in bridge_fdb_cache on __kmem_cache_shutdown()
[ 1822.144821] -----------------------------------------------------------------------------
[ 1822.145990] Disabling lock debugging due to kernel taint
[ 1822.146732] INFO: Slab 0x0000000092a844b2 objects=32 used=2 fp=0x00000000fef011b0 flags=0x1ffff8000000100
[ 1822.147700] CPU: 2 PID: 13584 Comm: rmmod Tainted: G B O 4.15.0-rc2+ #87
[ 1822.148578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 1822.150008] Call Trace:
[ 1822.150510] dump_stack+0x78/0xa9
[ 1822.151156] slab_err+0xb1/0xd3
[ 1822.151834] ? __kmalloc+0x1bb/0x1ce
[ 1822.152546] __kmem_cache_shutdown+0x151/0x28b
[ 1822.153395] shutdown_cache+0x13/0x144
[ 1822.154126] kmem_cache_destroy+0x1c0/0x1fb
[ 1822.154669] SyS_delete_module+0x194/0x244
[ 1822.155199] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 1822.155773] entry_SYSCALL_64_fastpath+0x23/0x9a
[ 1822.156343] RIP: 0033:0x7f929bd38b17
[ 1822.156859] RSP: 002b:00007ffd160e9a98 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0
[ 1822.157728] RAX: ffffffffffffffda RBX: 00005578316ba090 RCX: 00007f929bd38b17
[ 1822.158422] RDX: 00007f929bd9ec60 RSI: 0000000000000800 RDI: 00005578316ba0f0
[ 1822.159114] RBP: 0000000000000003 R08: 00007f929bff5f20 R09: 00007ffd160e8a11
[ 1822.159808] R10: 00007ffd160e9860 R11: 0000000000000202 R12: 00007ffd160e8a80
[ 1822.160513] R13: 0000000000000000 R14: 0000000000000000 R15: 00005578316ba090
[ 1822.161278] INFO: Object 0x000000007645de29 @offset=0
[ 1822.161666] INFO: Object 0x00000000d5df2ab5 @offset=128
Fixes: 30313a3d5794 ("bridge: Handle IFLA_ADDRESS correctly when creating bridge device")
Fixes: 5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
v2: it's better to use br_dev_delete to clean up because the sysfs entries
were leaked as well, basically we use it for the bridge fdb flush and sysfs
entries delete
Consequently this also would fix the null ptr deref due to the rhashtable
not being initialized in net-next when br_stp_change_bridge_id is called.
net/bridge/br_netlink.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index d0ef0a8e8831..015f465c514b 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1262,19 +1262,20 @@ static int br_dev_newlink(struct net *src_net, struct net_device *dev,
struct net_bridge *br = netdev_priv(dev);
int err;
+ err = register_netdevice(dev);
+ if (err)
+ return err;
+
if (tb[IFLA_ADDRESS]) {
spin_lock_bh(&br->lock);
br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
spin_unlock_bh(&br->lock);
}
- err = register_netdevice(dev);
- if (err)
- return err;
-
err = br_changelink(dev, tb, data, extack);
if (err)
- unregister_netdevice(dev);
+ br_dev_delete(dev, NULL);
+
return err;
}
--
2.14.3
^ permalink raw reply related
* [PATCH 4.4 095/115] l2tp: cleanup l2tp_tunnel_delete calls
From: Greg Kroah-Hartman @ 2017-12-18 15:49 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Slaby, Sabrina Dubroca,
Guillaume Nault, David S. Miller, netdev, Sasha Levin
In-Reply-To: <20171218152851.886086917@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ]
l2tp_tunnel_delete does not return anything since commit 62b982eeb458
("l2tp: fix race condition in l2tp_tunnel_delete"). But call sites of
l2tp_tunnel_delete still do casts to void to avoid unused return value
warnings.
Kill these now useless casts.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Sabrina Dubroca <sd@queasysnail.net>
Cc: Guillaume Nault <g.nault@alphalink.fr>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Acked-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 2 +-
net/l2tp/l2tp_netlink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1856,7 +1856,7 @@ static __net_exit void l2tp_exit_net(str
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- (void)l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
}
rcu_read_unlock_bh();
}
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -285,7 +285,7 @@ static int l2tp_nl_cmd_tunnel_delete(str
l2tp_tunnel_notify(&l2tp_nl_family, info,
tunnel, L2TP_CMD_TUNNEL_DELETE);
- (void) l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
out:
return ret;
^ permalink raw reply
* [PATCH 4.9 151/177] l2tp: cleanup l2tp_tunnel_delete calls
From: Greg Kroah-Hartman @ 2017-12-18 15:49 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Slaby, Sabrina Dubroca,
Guillaume Nault, David S. Miller, netdev, Sasha Levin
In-Reply-To: <20171218152909.823644066@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ]
l2tp_tunnel_delete does not return anything since commit 62b982eeb458
("l2tp: fix race condition in l2tp_tunnel_delete"). But call sites of
l2tp_tunnel_delete still do casts to void to avoid unused return value
warnings.
Kill these now useless casts.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Sabrina Dubroca <sd@queasysnail.net>
Cc: Guillaume Nault <g.nault@alphalink.fr>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Acked-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 2 +-
net/l2tp/l2tp_netlink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1944,7 +1944,7 @@ static __net_exit void l2tp_exit_net(str
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- (void)l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
}
rcu_read_unlock_bh();
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -287,7 +287,7 @@ static int l2tp_nl_cmd_tunnel_delete(str
l2tp_tunnel_notify(&l2tp_nl_family, info,
tunnel, L2TP_CMD_TUNNEL_DELETE);
- (void) l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
out:
return ret;
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2017-12-18 15:49 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Thomas Petazzoni, Andrew Lunn, Florian Fainelli,
Russell King - ARM Linux, Graeme Gregory,
<netdev@vger.kernel.org>, Antoine Ténart,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Nadav Haklai,
linux-acpi@vger.kernel.org, Neta Zur Hershkovits, Ezequiel Garcia,
Grzegorz Jaszczyk, Gregory CLEMENT, Tomasz Nowicki,
David S. Miller, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu8_6y3dU81ZS4WWCfpRZkfjGo_+_K--e3go_3_xXwBErQ@mail.gmail.com>
Hi Ard
2017-12-18 10:40 GMT+01:00 Ard Biesheuvel <ard.biesheuvel@linaro.org>:
> On 18 December 2017 at 10:17, Marcin Wojtas <mw@semihalf.com> wrote:
>> Hi,
>>
>> This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
>> First three patches introduce fwnode helpers for obtaining PHY
>> information from nodes and also MDIO fwnode API for registering
>> the bus with its PHY/devices.
>>
>> Following patches update code of the mvmdio and mvpp2 drivers
>> to support ACPI tables handling. The latter is done in 4 steps,
>> as can be seen in the commits. For the details, please
>> refer to the commit messages.
>>
>> Drivers operation was tested on top of the net-next branch
>> with both DT and ACPI. Although for compatibility reasons
>> with older platforms, the mvmdio driver keeps using
>> of_ MDIO registering, new fwnode_ one proved to fully work
>> with DT as well (tested on MacchiatoBin board).
>>
>> mvpp2/mvmdio driver can work with the ACPI representation, as exposed
>> on a public branch:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
>> It was compiled together with the most recent Tianocore EDK2 revision.
>> Please refer to the firmware build instruction on MacchiatoBin board:
>> http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>>
>> Above support configures 1G to use its PHY normally. 10G can work now
>> only with the link interrupt mode. Somehow reading of the
>> string property in fwnode_mdiobus_child_is_phy works only with
>> DT and cannot cope with 10G PHY nodes as in:
>> https://pastebin.com/3JnYpU0A
>>
>> Above root cause will be further checked. In the meantime I will
>> appreciate any comments or remarks for the kernel patches.
>>
>
> Hi Marcin,
>
> I have added linux-acpi and Graeme to cc. I think it makes sense to
> discuss the way you describe the device topology before looking at the
> patches in more detail.
>
Thanks. Tomasz Nowicki immediately pointed this to me off the lists.
> In particular, I would like to request feedback on the use of
> [redundant] 'reg' properties and the use of _DSD + compatible to
> describe PHYs. Usually, we try to avoid this, given that it is
> essentially a ACPI encapsulated DT dialect that is difficult to
> support in drivers unless they are based on DT to begin with. Also,
> non-standard _DSD properties require a vendor prefix, it is not
> freeform.
>
Already a lot of drivers use both DT + ACPI. Some have IMO very
fanciful bindings in both, mostly handled within the drivers with
custom functions. OF_ - only drivers can use of_mdio_ helper routines,
that assume a certain hierarchy:
MDIO device node with PHYs as children, which are referenced in the
ports node. I believe such approach could fit ACPI description too.
I'm aware however that my code is pretty much DT transposed into ACPI
environment and I'm of course open to discussion, how to do it in the
most proper way.
My main goal is to provide an fwnode-based glue code, that can be used
among the NIC/MDIO drivers (+ phylink) without multiple ifs
differentiating between ACPI/OF. What I sent has single calls in
mvpp2/mvmdio with a common bottom layers, but I don't see a problem,
that, e.g. when iterating over PHY subnodes, in case of OF
'reg'/'compatible' are used, whereas with ACPI some specific _ADR/_CID
objects.
I'd appreaciate any feedback.
Best regards,
Marcin
> For reference, the ACPI description is here (starting at line 175)
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/72d5ac23b20dd74d479daa5e40ba443264b31261/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl
^ permalink raw reply
* Re: pull-request: bpf 2017-12-17
From: David Miller @ 2017-12-18 15:49 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20171217200626.5478-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sun, 17 Dec 2017 21:06:26 +0100
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Fix a corner case in generic XDP where we have non-linear skbs
> but enough tailroom in the skb to not miss to linearizing there,
> from Song.
>
> 2) Fix BPF JIT bugs in s390x and ppc64 to not recache skb data when
> BPF context is not skb, from Daniel.
>
> 3) Fix a BPF JIT bug in sparc64 where recaching skb data after helper
> call would use the wrong register for the skb, from Daniel.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
^ permalink raw reply
* Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working
From: Neftin, Sasha @ 2017-12-18 15:50 UTC (permalink / raw)
To: Pavel Machek, jacob.e.keller
Cc: David Miller, bpoirier, nix.or.die, netdev, linux-kernel,
intel-wired-lan, lsorense
In-Reply-To: <20171218115817.GA17054@amd>
On 12/18/2017 13:58, Pavel Machek wrote:
> On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote:
>> On 12/18/2017 12:26, Pavel Machek wrote:
>>> Hi!
>>>
>>>>>>> In v4.15-rc2+, network manager can not see my ethernet card, and
>>>>>>> manual attempts to ifconfig it up did not really help, either.
>>>>>>>
>>>>>>> Card is:
>>>>>>>
>>>>>>> 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
>>>>>>> Controller
>>>>> ....
>>>>>>> Any ideas ?
>>>>>> Yes , 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 broke it.
>>>>>>
>>>>>> See:
>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=198047
>>>>>>
>>>>>> Fix there :
>>>>>> https://marc.info/?l=linux-kernel&m=151272209903675&w=2
>>>>> I don't see the patch in latest mainline. Not having ethernet
>>>>> is... somehow annoying. What is going on there?
>>>> Generally speaking, e1000 maintainence has been handled very poorly over
>>>> the past few years, I have to say.
>>>>
>>>> Fixes take forever to propagate even when someone other than the
>>>> maintainer provides a working and tested fix, just like this case.
>>>>
>>>> Jeff, please take e1000 maintainence seriously and get these critical
>>>> bug fixes propagated.
>>> No response AFAICT. I guess I should test reverting
>>> 19110cfbb34d4af0cdfe14cd243f3b09dc95b013, then ask you for revert?
>> Hello Pavel,
>>
>> Before ask for reverting 19110cfbb..., please, check if follow patch of
>> Benjamin work for you http://patchwork.ozlabs.org/patch/846825/
> Jacob said, in another email:
>
> # Digging into this, the problem is complicated. The original bug
> # assumed behavior of the .check_for_link call, which is universally not
> # implemented.
> #
> # I think the correct fix is to revert 19110cfbb34d ("e1000e: Separate
> # signaling for link check/link up", 2017-10-10) and find a more proper solution.
>
> ...which makes me think that revert is preffered?
>
> Pavel
>
Pavel, before ask for revert - let's check Benjamin's patch following to
his previous patch. Previous patch was not competed and latest one come
to complete changes.
^ 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