- 28 Aug, 2020 2 commits
-
-
Andre Edich authored
This patch removes arguments netdev and phy_id from the functions smsc95xx_mdio_read_nopm and smsc95xx_mdio_write_nopm. Both removed arguments are recovered from a new argument `struct usbnet *dev`. Signed-off-by:
Andre Edich <andre.edich@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2020-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== This time we have: * some code to support SAE (WPA3) offload in AP mode * many documentation (wording) fixes/updates * netlink policy updates, including the use of NLA_RANGE with binary attributes * regulatory improvements for adjacent frequency bands * and a few other small additions/refactorings/cleanups ==================== Signed-off-by:
-
- 27 Aug, 2020 34 commits
-
-
Nicolas Dichtel authored
Like all other network functions, let's notify gtp context on creation and deletion. Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Tested-by:
Gabriel Ganne <gabriel.ganne@6wind.com> Acked-by:
Harald Welte <laforge@gnumonks.org> Signed-off-by:
-
David S. Miller authored
Julian Wiedmann says: ==================== s390/qeth: updates 2020-08-27 please apply the following patch series for qeth to netdev's net-next tree. Patch 8 makes some improvements to how we handle HW address events, avoiding some uncertainty around processing stale events after we switched off the feature. Except for that it's all straight-forward cleanups. ==================== Signed-off-by: -
Julian Wiedmann authored
The current code for bridge address events has two shortcomings in its control sequence: 1. after disabling address events via PNSO, we don't flush the remaining events from the event_wq. So if the feature is re-enabled fast enough, stale events could leak over. 2. PNSO and the events' arrival via the READ ccw device are unordered. So even if we flushed the workqueue, it's difficult to say whether the READ device might produce more events onto the workqueue afterwards. Fix this by 1. explicitly fencing off the events when we no longer care, in the READ device's event handler. This ensures that once we flush the workqueue, it doesn't get additional address events. 2. Flush the workqueue after disabling the events & fencing them off. As the code that triggers the flush will typically hold the sbp_lock, we need to rework the worker code to avoid a deadlock here in case of a 'notifications-stopped' event. In case of lock contention, requeue such an event with a delay. We'll eventually aquire the lock, or spot that the feature has been disabled and the event can thus be discarded. This leaves the theoretical race that a stale event could arrive _after_ we re-enabled ourselves to receive events again. Such an event would be impossible to distinguish from a 'good' event, nothing we can do about it. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
The data returned from IPA_SBP_QUERY_BRIDGE_PORTS and IPA_SBP_BRIDGE_PORT_STATE_CHANGE has the same format. Use a single struct definition for it. Signed-off-by:
-
Julian Wiedmann authored
Current code copies _all_ entries from the event into a worker, when we later only need specific data from the first entry. Signed-off-by:
-
Julian Wiedmann authored
The only time that our Bridgeport role should change is when we change the configuration ourselves. In which case we also adjust our internal state tracking, no need to do it again when we receive the corresponding event. Removing the locked section helps a subsequent patch that needs to flush the workqueue while under sbp_lock. It would be nice to raise a warning here in case HW does weird things after all, but this could end up generating false-positives when we change the configuration ourselves. Suggested-by:
-
Julian Wiedmann authored
A newly initialized device is disabled for address events, there's no need to explicitly disable them. Signed-off-by:
-
Julian Wiedmann authored
queue->state is a ternary spinlock in disguise, used by OSA's TX completion path to lock the Output Queue and flush any pending packets on it to the device. If the Queue is already locked by our TX code, setting the lock word to QETH_OUT_Q_LOCKED_FLUSH lets the TX completion code move on - the TX path will later take care of things when it unlocks the Queue. This sort of DIY locking is a non-starter of course, just let the TX completion path block on the spinlock when necessary. If that ends up causing additional latency due to lock contention, then converting the OSA path to use xmit_more is the right way to go forward. Also slightly expand the locked section and capture all of qeth_do_send_packet(), so that the update for the 'bufs_pack' statistics is done race-free. While reworking the TX completion path's code, remove a barrier() that doesn't make any sense. Signed-off-by:
-
Julian Wiedmann authored
Avoid poking around in the delayed_work struct's internals. Signed-off-by:
-
Julian Wiedmann authored
Clarify that the 'ipacmd' parameter is an enum, and thus compatible to what qeth_ipa_alloc_cmd() expects as input. Signed-off-by:
-
Hoang Huu Le authored
Syzbot has reported those issues as: ================================================================== BUG: KASAN: use-after-free in tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 Read of size 1 at addr ffff88805e6b3571 by task kworker/0:6/3850 CPU: 0 PID: 3850 Comm: kworker/0:6 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Thread 1's call trace: [...] kfree+0x103/0x2c0 mm/slab.c:3757 <- bcbase releasing tipc_bcast_stop+0x1b0/0x2f0 net/tipc/bcast.c:721 tipc_exit_net+0x24/0x270 net/tipc/core.c:112 [...] Thread 2's call trace: [...] tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 <- bcbase has already been freed by Thread 1 tipc_node_broadcast+0x9e/0xcc0 net/tipc/node.c:1744 tipc_nametbl_publish+0x60b/0x970 net/tipc/name_table.c:752 tipc_net_finalize net/tipc/net.c:141 [inline] tipc_net_finalize+0x1fa/0x310 net/tipc/net.c:131 tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150 [...] ================================================================== BUG: KASAN: use-after-free in tipc_named_reinit+0xef/0x290 net/tipc/name_distr.c:344 Read of size 8 at addr ffff888052ab2000 by task kworker/0:13/30628 CPU: 0 PID: 30628 Comm: kworker/0:13 Not tainted 5.8.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1f0/0x31e lib/dump_stack.c:118 print_address_description+0x66/0x5a0 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report+0x132/0x1d0 mm/kasan/report.c:530 tipc_named_reinit+0xef/0x290 net/tipc/name_distr.c:344 tipc_net_finalize+0x85/0xe0 net/tipc/net.c:138 tipc_net_finalize_work+0x50/0x70 net/tipc/net.c:150 process_one_work+0x789/0xfc0 kernel/workqueue.c:2269 worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415 kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 [...] Freed by task 14058: save_stack mm/kasan/common.c:48 [inline] set_track mm/kasan/common.c:56 [inline] kasan_set_free_info mm/kasan/common.c:316 [inline] __kasan_slab_free+0x114/0x170 mm/kasan/common.c:455 __cache_free mm/slab.c:3426 [inline] kfree+0x10a/0x220 mm/slab.c:3757 tipc_exit_net+0x29/0x50 net/tipc/core.c:113 ops_exit_list net/core/net_namespace.c:186 [inline] cleanup_net+0x708/0xba0 net/core/net_namespace.c:603 process_one_work+0x789/0xfc0 kernel/workqueue.c:2269 worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415 kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Fix it by calling flush_scheduled_work() to make sure the tipc_net_finalize_work() stopped before releasing bcbase object. Reported-by: syzbot+6ea1f7a8df64596ef4d7@syzkaller.appspotmail.com Reported-by: syzbot+e9cc557752ab126c1b99@syzkaller.appspotmail.com Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
Hoang Huu Le <hoang.h.le@dektech.com.au> Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== Move MDIO drivers into their own directory The phy subdirectory is getting cluttered. It has both PHY drivers and MDIO drivers, plus a stray switch driver. Soon more PCS drivers are likely to appear. Move MDIO and PCS drivers into new directories. This requires fixing up the xgene driver which uses a relative include path. v2: Move the subdirs to drivers/net, rather than drivers/net/phy. v3: Add subdirectories under include/linux for mdio and pcs v4: there->their include path fix No new kconfig prompts ==================== Signed-off-by: -
Andrew Lunn authored
Sort the Kconfig based on the text shown in make menuconfig and sort the Makefile by CONFIG symbol. Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
Move all the MDIO drivers and multiplexers into drivers/net/mdio. The mdio core is however left in the phy directory, due to mutual dependencies between the MDIO core and the PHY core. Take this opportunity to sort the Kconfig based on the menuconfig strings, and move the multiplexers to the end with a separating comment. v2: Fix typo in commit message Acked-by:
-
Andrew Lunn authored
This header file is currently included into the ethernet driver via a relative path into the PHY subsystem. This is bad practice, and causes issues for the upcoming move of the MDIO driver. Move the header file into include/linux to clean this up. v2: Move header to include/linux/mdio Reviewed-by:
-
Andrew Lunn authored
In preparation for moving all MDIO drivers into drivers/net/mdio, move the mdio-i2c header file into include/linux/mdio so it can be used by both the MDIO driver and the SFP code which instantiates I2C MDIO busses. v2: Add include/linux/mdio Reviewed-by:
-
Andrew Lunn authored
Create drivers/net/pcs and move the Synopsys DesignWare XPCS into the new directory. Move the header file into a subdirectory include/linux/pcs Start a naming convention of all PCS files use the prefix pcs-, and rename the XPCS files to fit. v2: Add include/linux/pcs v4: Fix include path in stmmac. Remove PCS_DEVICES to avoid new prompts Cc: Jose Abreu <Jose.Abreu@synopsys.com> Reviewed-by:
-
Chung-Hsien Hsu authored
Let drivers advertise support for AP-mode SAE authentication offload with a new NL80211_EXT_FEATURE_SAE_OFFLOAD_AP flag. Signed-off-by:
Chung-Hsien Hsu <stanley.hsu@cypress.com> Signed-off-by:
Chi-Hsien Lin <chi-hsien.lin@cypress.com> Link: https://lore.kernel.org/r/20200817073316.33402-4-stanley.hsu@cypress.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
John Crispin authored
We want to reuse the functions and structs for other counters such as BSS color change. Rename them to more generic names. Signed-off-by:
John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20200811080107.3615705-2-john@phrozen.orgSigned-off-by:
-
John Crispin authored
We want to reuse the attributes for other counters such as BSS color change. Rename them to more generic names. Signed-off-by:
-
Miles Hu authored
This patch adds the nl80211 structs, definitions, policies and parsing code required to pass fixed HE rate, GI and LTF settings. Signed-off-by:
Miles Hu <milehu@codeaurora.org> Signed-off-by:
-
James Prestwood authored
The CMD_PORT_AUTHORIZED event was described as an event which indicated a successfully completed 4-way handshake. But the behavior was not as advertized. The only driver which uses this is brcmfmac, and this driver only sends the event after a successful 802.1X-FT roam. This prevents userspace applications from knowing if the 4-way completed on: 1. Normal 802.1X connects 2. Normal PSK connections 3. FT-PSK roams wpa_supplicant handles this incorrect behavior by just completing the connection after association, before the 4-way has completed. If the 4-way ends up failing it disconnects at that point. Since this behavior appears to be expected (wpa_s handles it this way) I have changed the wording in the API description to reflect the actual behavior. Signed-off-by:
James Prestwood <prestwoj@gmail.com> Link: https://lore.kernel.org/r/20200413162053.3711-1-prestwoj@gmail.com [fix spelling of 802.1X throughout ...] Signed-off-by:
-
Markus Theil authored
Some usable channels are located in the union of adjacent regulatory rules, for example channel 144 in Germany. Enable them, by also checking if a channel spans two adjacent regulatory rules/frequency ranges. All flags involved are disabling things, therefore we can build the maximum by or-ing them together. Furthermore, take the maximum of DFS CAC time values and the minimum of allowed power of both adjacent channels in order to comply with both regulatory rules at the same time. Signed-off-by:
Markus Theil <markus.theil@tu-ilmenau.de> Link: https://lore.kernel.org/r/20200803144353.305538-2-markus.theil@tu-ilmenau.de [remove unrelated comment changes] Signed-off-by:
-
Markus Theil authored
As a preparation to handle adjacent rule channels, factor out handling channels located in a single regulatory rule. Signed-off-by:
-
Johannes Berg authored
We have a few attributes with minimum and maximum lengths that are not the same, use the new feature of being able to specify both in the policy to validate them, removing code and allowing this to be advertised to userspace in the policy export. Signed-off-by:
-
Johannes Berg authored
Use the policy to validate minimum and exact lengths in some attributes that weren't previously covered in the right ways, and remove associated validation code. Signed-off-by:
-
Miaohe Lin authored
Convert the uses of fallthrough comments to fallthrough macro. Signed-off-by:
Miaohe Lin <linmiaohe@huawei.com> Link: https://lore.kernel.org/r/20200822082323.45495-1-linmiaohe@huawei.comSigned-off-by:
-
Randy Dunlap authored
Drop the repeated word "be". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Johannes Berg <johannes.berg@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: linux-wireless@vger.kernel.org Link: https://lore.kernel.org/r/20200822231953.465-8-rdunlap@infradead.orgSigned-off-by:
-
Randy Dunlap authored
Drop the repeated word "is". Signed-off-by:
-
Randy Dunlap authored
Drop repeated word "stored". Change "is is" to "it is". Signed-off-by:
-
Randy Dunlap authored
Drop duplicated words "was" and "does". Fix "let's" apostrophe. Signed-off-by:
-
Randy Dunlap authored
Drop the repeated word "Return" + fix verb. Signed-off-by:
-
Randy Dunlap authored
Drop the repeated word "address". Signed-off-by:
-
Randy Dunlap authored
Change "If if" to "If it". Signed-off-by:
-
- 26 Aug, 2020 4 commits
-
-
David S. Miller authored
Rikard Falkeborn says: ==================== drivers/net: constify static ops-variables This series constifies a number of static ops variables, to allow the compiler to put them in read-only memory. Compile-tested only. ==================== Signed-off-by: -
Rikard Falkeborn authored
The only usage of ath11k_thermal_ops is to pass its address to thermal_cooling_device_register() which takes a const pointer. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Rikard Falkeborn authored
The only usage of vsc8584_macsec_ops is to assign its address to the macsec_ops field in the phydev struct, which is a const pointer. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
-
Rikard Falkeborn authored
The only usage of vddio_regulator_ops and vddh_regulator_ops is to assign their address to the ops field in the regulator_desc struct, which is a const pointer. Make them const to allow the compiler to put them in read-only memory. Signed-off-by:
-
