- 15 Jan, 2020 13 commits
-
-
Ido Schimmel authored
In commit a72afb68 ("mlxsw: Enforce firmware version for Spectrum-2") I added a required firmware version for Spectrum-2, but missed the fact that mlxsw_sp2_init() is used by both Spectrum-2 and Spectrum-3. This means that the same firmware version will be used for both, which is wrong. Fix this by creating a new init() callback for Spectrum-3. Fixes: a72afb68 ("mlxsw: Enforce firmware version for Spectrum-2") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Tested-by:
Shalom Toledo <shalomt@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'mac80211-for-net-2020-01-15' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== A few fixes: * -O3 enablement fallout, thanks to Arnd who ran this * fixes for a few leaks, thanks to Felix * channel 12 regulatory fix for custom regdomains * check for a crash reported by syzbot (NULL function is called on drivers that don't have it) * fix TKIP replay protection after setup with some APs (from Jouni) * restrict obtaining some mesh data to avoid WARN_ONs * fix deadlocks with auto-disconnect (socket owner) * fix radar detection events with multiple devices ==================== Signed-off-by:
-
Felix Fietkau authored
The fragments attached to a skb can be part of a compound page. In that case, page_ref_inc will increment the refcount for the wrong page. Fix this by using get_page instead, which calls page_ref_inc on the compound head and also checks for overflow. Fixes: 2b67f944 ("cfg80211: reuse existing page fragments in A-MSDU rx") Cc: stable@vger.kernel.org Signed-off-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20200113182107.20461-1-nbd@nbd.nameSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Check if set_wiphy_params is assigned and return an error if not, some drivers (e.g. virt_wifi where syzbot reported it) don't have it. Reported-by: syzbot+e8a797964a4180eb57d5@syzkaller.appspotmail.com Reported-by: syzbot+34b582cf32c1db008f8e@syzkaller.appspotmail.com Signed-off-by:
-
Felix Fietkau authored
The per-tid statistics need to be released after the call to rdev_get_station Cc: stable@vger.kernel.org Fixes: 8689c051 ("cfg80211: dynamically allocate per-tid stats for station info") Signed-off-by:
-
Felix Fietkau authored
The per-tid statistics need to be released after the call to rdev_get_station Cc: stable@vger.kernel.org Fixes: 5ab92e7f ("cfg80211: add support to probe unexercised mesh link") Signed-off-by:
-
Markus Theil authored
Use methods which do not try to acquire the wdev lock themselves. Cc: stable@vger.kernel.org Fixes: 37b1c004 ("cfg80211: Support all iftypes in autodisconnect_wk") Signed-off-by:
Markus Theil <markus.theil@tu-ilmenau.de> Link: https://lore.kernel.org/r/20200108115536.2262-1-markus.theil@tu-ilmenau.deSigned-off-by:
-
Arnd Bergmann authored
After the introduction of CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, the wext code produces a bogus warning: In function 'iw_handler_get_iwstats', inlined from 'ioctl_standard_call' at net/wireless/wext-core.c:1015:9, inlined from 'wireless_process_ioctl' at net/wireless/wext-core.c:935:10, inlined from 'wext_ioctl_dispatch.part.8' at net/wireless/wext-core.c:986:8, inlined from 'wext_handle_ioctl': net/wireless/wext-core.c:671:3: error: argument 1 null where non-null expected [-Werror=nonnull] memcpy(extra, stats, sizeof(struct iw_statistics)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from arch/x86/include/asm/string.h:5, net/wireless/wext-core.c: In function 'wext_handle_ioctl': arch/x86/include/asm/string_64.h:14:14: note: in a call to function 'memcpy' declared here The problem is that ioctl_standard_call() sometimes calls the handler with a NULL argument that would cause a problem for iw_handler_get_iwstats. However, iw_handler_get_iwstats never actually gets called that way. Marking that function as noinline avoids the warning and leads to slightly smaller object code as well. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200107200741.3588770-1-arnd@arndb.deSigned-off-by:
-
Jouni Malinen authored
TKIP replay protection was skipped for the very first frame received after a new key is configured. While this is potentially needed to avoid dropping a frame in some cases, this does leave a window for replay attacks with group-addressed frames at the station side. Any earlier frame sent by the AP using the same key would be accepted as a valid frame and the internal RSC would then be updated to the TSC from that frame. This would allow multiple previously transmitted group-addressed frames to be replayed until the next valid new group-addressed frame from the AP is received by the station. Fix this by limiting the no-replay-protection exception to apply only for the case where TSC=0, i.e., when this is for the very first frame protected using the new key, and the local RSC had not been set to a higher value when configuring the key (which may happen with GTK). Signed-off-by:
Jouni Malinen <j@w1.fi> Link: https://lore.kernel.org/r/20200107153545.10934-1-j@w1.fiSigned-off-by:
-
Orr Mazor authored
In case a radar event of CAC_FINISHED or RADAR_DETECTED happens during another phy is during CAC we might need to cancel that CAC. If we got a radar in a channel that another phy is now doing CAC on then the CAC should be canceled there. If, for example, 2 phys doing CAC on the same channels, or on comptable channels, once on of them will finish his CAC the other might need to cancel his CAC, since it is no longer relevant. To fix that the commit adds an callback and implement it in mac80211 to end CAC. This commit also adds a call to said callback if after a radar event we see the CAC is no longer relevant Signed-off-by:
Orr Mazor <Orr.Mazor@tandemg.com> Reviewed-by:
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Link: https://lore.kernel.org/r/20191222145449.15792-1-Orr.Mazor@tandemg.com [slightly reformat/reword commit message] Signed-off-by:
-
Ganapathi Bhat authored
Commit e33e2241 ("Revert "cfg80211: Use 5MHz bandwidth by default when checking usable channels"") fixed a broken regulatory (leaving channel 12 open for AP where not permitted). Apply a similar fix to custom regulatory domain processing. Signed-off-by:
Cathy Luo <xiaohua.luo@nxp.com> Signed-off-by:
Ganapathi Bhat <ganapathi.bhat@nxp.com> Link: https://lore.kernel.org/r/1576836859-8945-1-git-send-email-ganapathi.bhat@nxp.com [reword commit message, fix coding style, add a comment] Signed-off-by:
-
Lorenzo Bianconi authored
Page pool API will start syncing (if requested) starting from page->dma_addr + pool->p.offset. Fix dma sync length in mvneta_run_xdp since we do not need to account xdp headroom Fixes: 07e13edb ("net: mvneta: get rid of huge dma sync in mvneta_rx_refill") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Johan Hovold authored
Add missing endpoint sanity check to probe in order to prevent a NULL-pointer dereference (or slab out-of-bounds access) when retrieving the interrupt-endpoint bInterval on ndo_open() in case a device lacks the expected endpoints. Fixes: 40a82917 ("net/usb/r8152: enable interrupt transfer") Cc: hayeswang <hayeswang@realtek.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
- 14 Jan, 2020 6 commits
-
-
Sunil Muthuswamy authored
Currently, hv_sock restricts the port the guest socket can accept connections on. hv_sock divides the socket port namespace into two parts for server side (listening socket), 0-0x7FFFFFFF & 0x80000000-0xFFFFFFFF (there are no restrictions on client port namespace). The first part (0-0x7FFFFFFF) is reserved for sockets where connections can be accepted. The second part (0x80000000-0xFFFFFFFF) is reserved for allocating ports for the peer (host) socket, once a connection is accepted. This reservation of the port namespace is specific to hv_sock and not known by the generic vsock library (ex: af_vsock). This is problematic because auto-binds/ephemeral ports are handled by the generic vsock library and it has no knowledge of this port reservation and could allocate a port that is not compatible with hv_sock (and legitimately so). The issue hasn't surfaced so far because the auto-bind code of vsock (__vsock_bind_stream) prior to the change 'VSOCK: bind to random port for VMADDR_PORT_ANY' would start walking up from LAST_RESERVED_PORT (1023) and start assigning ports. That will take a large number of iterations to hit 0x7FFFFFFF. But, after the above change to randomize port selection, the issue has started coming up more frequently. There has really been no good reason to have this port reservation logic in hv_sock from the get go. Reserving a local port for peer ports is not how things are handled generally. Peer ports should reflect the peer port. This fixes the issue by lifting the port reservation, and also returns the right peer port. Since the code converts the GUID to the peer port (by using the first 4 bytes), there is a possibility of conflicts, but that seems like a reasonable risk to take, given this is limited to vsock and that only applies to all local sockets. Signed-off-by:
Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by:
-
Eric Dumazet authored
lan78xx_tx_bh() makes sure to not exceed MAX_SINGLE_PACKET_SIZE bytes in the aggregated packets it builds, but does nothing to prevent large GSO packets being submitted. Pierre-Francois reported various hangs when/if TSO is enabled. For localy generated packets, we can use netif_set_gso_max_size() to limit the size of TSO packets. Note that forwarded packets could still hit the issue, so a complete fix might require implementing .ndo_features_check for this driver, forcing a software segmentation if the size of the TSO packet exceeds MAX_SINGLE_PACKET_SIZE. Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
RENARD Pierre-Francois <pfrenard@gmail.com> Tested-by:
-
Vladis Dronov authored
There is a bug in ptp_clock_unregister(), where ptp_cleanup_pin_groups() first frees ptp->pin_{,dev_}attr, but then posix_clock_unregister() needs them to destroy a related sysfs device. These functions can not be just swapped, as posix_clock_unregister() frees ptp which is needed in the ptp_cleanup_pin_groups(). Fix this by calling ptp_cleanup_pin_groups() in ptp_clock_release(), right before ptp is freed. This makes this patch fix an UAF bug in a patch which fixes an UAF bug. Reported-by:Antti Laakso <antti.laakso@intel.com> Fixes: a33121e5 ("ptp: fix the race between the release of ptp_clock and cdev") Link: https://lore.kernel.org/netdev/3d2bd09735dbdaf003585ca376b7c1e5b69a19bd.camel@intel.com/Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Johan Hovold authored
The driver was doing a synchronous uninterruptible bulk-transfer without using a timeout. This could lead to the driver hanging on probe due to a malfunctioning (or malicious) device until the device is physically disconnected. While sleeping in probe the driver prevents other devices connected to the same hub from being added to (or removed from) the bus. An arbitrary limit of five seconds should be more than enough. Fixes: dbafc289 ("NFC: pn533: don't send USB data off of the stack") Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Kristian Evensen authored
RM500Q is a 5G module from Quectel, supporting both standalone and non-standalone modes. The normal Quectel quirks apply (DTR and dynamic interface numbers). Signed-off-by:
Kristian Evensen <kristian.evensen@gmail.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Milind Parab authored
This patch fix the issue with fixed link. With fixed-link device opening fails due to macb_phylink_connect not handling fixed-link mode, in which case no MAC-PHY connection is needed and phylink_connect return success (0), however in current driver attempt is made to search and connect to PHY even for fixed-link. Fixes: 7897b071 ("net: macb: convert to phylink") Signed-off-by:
Milind Parab <mparab@cadence.com> Reviewed-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
-
- 11 Jan, 2020 7 commits
-
-
Jakub Kicinski authored
My Netronome email address may become inactive soon. Signed-off-by:
-
Jacob Keller authored
A couple of locations accidentally misspelled snapshot as shapshot. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Jacob Keller authored
The function to obtain a unique snapshot id was mistakenly typo'd as devlink_region_shapshot_id_get. Fix this typo by renaming the function and all of its users. Signed-off-by:
-
David S. Miller authored
Dan Murphy says: ==================== DP83822 and DP83TC811 Fixes Two fixes on net/phy/Kconfig for the TI ethernet PHYs. First fixed the typo in the Kconfig for the DP83TC811 where it incorretly stated that the support was for a DP83TC822 which does not exist. Second fix was to update the DP83822 Kconfig entry to indicate support for the DP83825 devices in the description and the prompt. ==================== Signed-off-by: -
Dan Murphy authored
Update the Kconfig description to indicate support for the DP83825I device as well. Fixes: 32b12dc8fde1 ("net: phy: Add DP83825I to the DP83822 driver") Reviewed-by:Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Dan Murphy <dmurphy@ti.com> Signed-off-by:
-
Dan Murphy authored
Fix typo in the Kconfig for the DP83TC811 as it indicates support for the DP83TC822 which is incorrect. Fixes: 6d749428788b {"net: phy: DP83TC811: Introduce support for the DP83TC811 phy") Reviewed-by: -
Ido Schimmel authored
The commit cited below causes devlink to emit a warning if a type was not set on a devlink port for longer than 30 seconds to "prevent misbehavior of drivers". This proved to be problematic when unregistering the backing netdev. The flow is always: devlink_port_type_clear() // schedules the warning unregister_netdev() // blocking devlink_port_unregister() // cancels the warning The call to unregister_netdev() can block for long periods of time for various reasons: RTNL lock is contended, large amounts of configuration to unroll following dismantle of the netdev, etc. This results in devlink emitting a warning despite the driver behaving correctly. In emulated environments (of future hardware) which are usually very slow, the warning can also be emitted during port creation as more than 30 seconds can pass between the time the devlink port is registered and when its type is set. In addition, syzbot has hit this warning [1] 1974 times since 07/11/19 without being able to produce a reproducer. Probably because reproduction depends on the load or other bugs (e.g., RTNL not being released). To prevent bogus warnings, increase the timeout to 1 hour. [1] https://syzkaller.appspot.com/bug?id=e99b59e9c024a666c9f7450dc162a4b74d09d9cb Fixes: 136bf27f ("devlink: add warning in case driver does not set port type") Signed-off-by:
Alex Veber <alexve@mellanox.com> Tested-by:
-
- 10 Jan, 2020 9 commits
-
-
David Ahern authored
Sven-Haegar reported looping on fib dumps when 255.255.255.255 route has been added to a table. The looping is caused by the key rolling over from FFFFFFFF to 0. When dumping a specific table only, we need a means to detect when the table dump is done. The key and count saved to cb args are both 0 only at the start of the table dump. If key is 0 and count > 0, then we are in the rollover case. Detect and return to avoid looping. This only affects dumps of a specific table; for dumps of all tables (the case prior to the change in the Fixes tag) inet_dump_fib moved the entry counter to the next table and reset the cb args used by fib_table_dump and fn_trie_dump_leaf, so the rollover ffffffff back to 0 did not cause looping with the dumps. Fixes: effe6792 ("net: Enable kernel side filtering of route dumps") Reported-by:
Sven-Haegar Koch <haegar@sdinet.de> Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David S. Miller authored
Jose Abreu says: ==================== net: stmmac: Filtering fixes Two single fixes for the L3 and L4 filtering in stmmac. 1) Updates the internal status of RSS when disabling it in order to keep internal driver status consistent. 2) Do not lets user add a filter if RSS is enabled because the filter will not work correctly as RSS bypasses this mechanism. ==================== Signed-off-by: -
Jose Abreu authored
RSS, when enabled, will bypass the L3 and L4 filtering causing it not to work. Add a check before trying to setup the filters. Fixes: 425eabdd ("net: stmmac: Implement L3/L4 Filters using TC Flower") Signed-off-by:
Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by:
-
Jose Abreu authored
We are disabling RSS on HW but not updating the internal private status to the 'disabled' state. This is needed for next tc commit that will check if RSS is disabled before trying to apply filters. Fixes: 4647e021 ("net: stmmac: selftests: Add selftest for L3/L4 Filters") Signed-off-by:
-
Jakub Kicinski authored
Mallesham reports the TLS with async accelerator was broken by commit d10523d0 ("net/tls: free the record on encryption error") because encryption can return -EINPROGRESS in such setups, which should not be treated as an error. The error is also present in the BPF path (likely copied from there). Reported-by:
Mallesham Jatharakonda <mallesham.jatharakonda@oneconvergence.com> Fixes: d3b18ad3 ("tls: add bpf support to sk_msg handling") Fixes: d10523d0 ("net/tls: free the record on encryption error") Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
When device loses sync mid way through a record - kernel has to re-encrypt the part of the record which the device already decrypted to be able to decrypt and authenticate the record in its entirety. The re-encryption piggy backs on the decryption routine, but obviously because the partially decrypted record can't be authenticated crypto API returns an error which is then ignored by tls_device_reencrypt(). Commit 5c5ec668 ("net/tls: add TlsDecryptError stat") added a statistic to count decryption errors, this statistic can't be incremented when we see the expected re-encryption error. Move the inc to the caller. Reported-and-tested-by:
David Beckett <david.beckett@netronome.com> Fixes: 5c5ec668 ("net/tls: add TlsDecryptError stat") Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queueDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2020-01-09 This series contains fixes to e1000e, igb, ixgbe, ixgbevf, i40e and iavf drivers. Brett fixes the validation of the virtchnl queue select bitmaps by comparing the bitmaps against BIT(I40E_MAX_VF_QUEUES). Radoslaw removes the limitation of only 10 filter entries for a VF and allows use of all free RAR entries for the forwarding database, if needed. Cambda Zhu fixes the calculation of queue when restoring flow director filters after resetting the adapter for ixgbe. Manfred Rudigier fixes the SGMIISFP module discovery for 100FX/LX modules for igb. Stefan Assmann fixes iavf where during a VF reset event, MAC filters were not altered, which could lead to a stale filter when an administratively set MAC address is forced by the PF. Adam adds the missing code to set the PHY access flag on X722 devices, which supports accessing PHY registers with the admin queue command. Revert a previous commit for e1000e to use "delayed work" which was causing connections to reset unexpectedly and possible driver crashes. ==================== Signed-off-by: -
Martin Schiller authored
This patch fixes 2 issues in x25_connect(): 1. It makes absolutely no sense to reset the neighbour and the connection state after a (successful) nonblocking call of x25_connect. This prevents any connection from being established, since the response (call accept) cannot be processed. 2. Any further calls to x25_connect() while a call is pending should simply return, instead of creating new Call Request (on different logical channels). This patch should also fix the "KASAN: null-ptr-deref Write in x25_connect" and "BUG: unable to handle kernel NULL pointer dereference in x25_connect" bugs reported by syzbot. Signed-off-by:
Martin Schiller <ms@dev.tdt.de> Reported-by: syzbot+429c200ffc8772bfe070@syzkaller.appspotmail.com Reported-by: syzbot+eec0c87f31a7c3b66f7b@syzkaller.appspotmail.com Signed-off-by:
-
Sergei Shtylyov authored
When adding the sh_eth_cpu_data::dual_port flag I forgot to add the flag checks to __sh_eth_get_regs(), causing the non-existing TSU registers to be dumped by 'ethtool' on the single port Ether controllers having TSU... Fixes: a94cf2a6 ("sh_eth: fix TSU init on SH7734/R8A7740") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
- 09 Jan, 2020 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hidLinus Torvalds authored
Pull HID fixes from Jiri Kosina: - fix for OOB in hiddev, from Dmitry Torokhov - _poll API fixes for hidraw, from Marcel Holtmann - functional fix for Steam driver, from Rodrigo Rivas Costa - a few new device IDs / device-specific quirks and other assorted smaller fixes * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: steam: Fix input device disappearing HID: intel-ish-hid: ipc: Add Tiger Lake PCI device ID drivers/hid/hid-multitouch.c: fix a possible null pointer access. HID: wacom: Recognize new MobileStudio Pro PID HID: intel-ish-hid: ipc: add CMP device id HID: hiddev: fix mess in hiddev_open() HID: hid-input: clear unmapped usages HID: Add quirk for incorrect input length on Lenovo Y720 HID: asus: Ignore Asus vendor-page usage-code 0xff events HID: ite: Add USB id match for Acer SW5-012 keyboard dock HID: Add quirk for Xin-Mo Dual Controller HID: Fix slab-out-of-bounds read in hid_field_extract HID: multitouch: Add LG MELF0410 I2C touchscreen support HID: uhid: Fix returning EPOLLOUT from uhid_char_poll HID: hidraw: Fix returning EPOLLOUT from hidraw_poll
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Missing netns pointer init in arp_tables, from Florian Westphal. 2) Fix normal tcp SACK being treated as D-SACK, from Pengcheng Yang. 3) Fix divide by zero in sch_cake, from Wen Yang. 4) Len passed to skb_put_padto() is wrong in qrtr code, from Carl Huang. 5) cmd->obj.chunk is leaked in sctp code error paths, from Xin Long. 6) cgroup bpf programs can be released out of order, fix from Roman Gushchin. 7) Make sure stmmac debugfs entry name is changed when device name changes, from Jiping Ma. 8) Fix memory leak in vlan_dev_set_egress_priority(), from Eric Dumazet. 9) SKB leak in lan78xx usb driver, also from Eric Dumazet. 10) Ridiculous TCA_FQ_QUANTUM values configured can cause loops in fq packet scheduler, reject them. From Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (69 commits) tipc: fix wrong connect() return code tipc: fix link overflow issue at socket shutdown netfilter: ipset: avoid null deref when IPSET_ATTR_LINENO is present netfilter: conntrack: dccp, sctp: handle null timeout argument atm: eni: fix uninitialized variable warning macvlan: do not assume mac_header is set in macvlan_broadcast() net: sch_prio: When ungrafting, replace with FIFO mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO MAINTAINERS: Remove myself as co-maintainer for qcom-ethqos gtp: fix bad unlock balance in gtp_encap_enable_socket pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM tipc: remove meaningless assignment in Makefile tipc: do not add socket.o to tipc-y twice net: stmmac: dwmac-sun8i: Allow all RGMII modes net: stmmac: dwmac-sunxi: Allow all RGMII modes net: usb: lan78xx: fix possible skb leak net: stmmac: Fixed link does not need MDIO Bus vlan: vlan_changelink() should propagate errors vlan: fix memory leak in vlan_dev_set_egress_priority stmmac: debugfs entry name is not be changed when udev rename device name. ... -
Jeff Kirsher authored
This reverts commit 59653e64. This is due to this commit causing driver crashes and connections to reset unexpectedly. Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com>
-
Adam Ludkiewicz authored
The X722 FW API version 1.9 adds support for accessing PHY registers with Admin Queue Command. This enables reading EEPROM data from (Q)SFP+ transceivers, what was previously possible only on X710 devices. Signed-off-by:
Adam Ludkiewicz <adam.ludkiewicz@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Stefan Assmann authored
Currently MAC filters are not altered during a VF reset event. This may lead to a stale filter when an administratively set MAC is forced by the PF. For an administratively set MAC the PF driver deletes the VFs filters, overwrites the VFs MAC address and triggers a VF reset. However the VF driver itself is not aware of the filter removal, which is what the VF reset is for. The VF reset queues all filters present in the VF driver to be re-added to the PF filter list (including the filter for the now stale VF MAC address) and triggers a VIRTCHNL_OP_GET_VF_RESOURCES event, which provides the new MAC address to the VF. When this happens i40e will complain and reject the stale MAC filter, at least in the untrusted VF case. i40e 0000:08:00.0: Setting MAC 3c:fa:fa:fa:fa:01 on VF 0 iavf 0000:08:02.0: Reset warning received from the PF iavf 0000:08:02.0: Scheduling reset task i40e 0000:08:00.0: Bring down and up the VF interface to make this change effective. i40e 0000:08:00.0: VF attempting to override administratively set MAC address, bring down and up the VF interface to resume normal operation i40e 0000:08:00.0: VF 0 failed opcode 10, retval: -1 iavf 0000:08:02.0: Failed to add MAC filter, error IAVF_ERR_NVM To avoid re-adding the stale MAC filter it needs to be removed from the VF driver's filter list before queuing the existing filters. Then during the VIRTCHNL_OP_GET_VF_RESOURCES event the correct filter needs to be added again, at which point the MAC address has been updated. As a bonus this change makes bringing the VF down and up again superfluous for the administratively set MAC case. Signed-off-by:
Stefan Assmann <sassmann@kpanic.de> Tested-by:
-
