- 21 Mar, 2019 18 commits
-
-
David S. Miller authored
Florian Fainelli says: ==================== net: phy: Move Omega PHY entry to Cygnus PHY driver In order to pave the way for adding some specific Omega PHY features that may not be desirable on other products covered by the bcm7xxx PHY driver, split the Omega PHY entry into the Cygnus PHY driver such that the PHY drivers are reflective of product lines/business units maintaining them within Broadcom. No functional changes intended. ==================== Acked-by:
Arun Parameswaran <arun.parameswaran@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Cygnus and Omega are part of the same business unit and product line, it makes sense to group PHY entries by products such that a platform can select only the drivers that it needs. Bring all the functionality that the BCM7XXX_28NM_GPHY() macro hides for us and remove the Omega PHY entry from bcm7xxx.c. As an added bonus, we now have a proper mdio_device_id entry to permit auto-loading. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
-
Florian Fainelli authored
The Omega PHY entry was added to bcm7xxx.c out of convenience and this breaks the one driver per product line paradigm that was applied up until now. Since the AFE initialization is shared between Omega and BCM7xxx move the relevant functions to bcm-phy-lib.[ch]. No functional changes introduced. Signed-off-by:
-
Julian Wiedmann authored
Get rid of some obsolete gc-related documentation and macros that were missed in commit 5b7c9a8f ("net: remove dst gc related code"). CC: Wei Wang <weiwan@google.com> Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Acked-by:
Wei Wang <weiwan@google.com> Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: broadcom: Remove print of base address Some broadcom MDIO/switch/Ethernet MAC drivers insist on printing the base register virtual address which has little value. ==================== Signed-off-by: -
Florian Fainelli authored
Since commit ad67b74d ("printk: hash addresses printed with %p") pointers are being hashed when printed. Displaying the virtual memory at bootup time is not helpful, especially given we use a dev_info() which already displays the platform device's address. Signed-off-by:
-
Florian Fainelli authored
Since commit ad67b74d ("printk: hash addresses printed with %p") pointers are being hashed when printed. Displaying the virtual memory at bootup time is not helpful, we use a dev_info() print which already displays the platform device's address. Signed-off-by:
-
Florian Fainelli authored
Since commit ad67b74d ("printk: hash addresses printed with %p") pointers are being hashed when printed. Displaying the virtual memory at bootup time is not helpful, especially given we use a dev_info() which already displays the platform device's address. Signed-off-by:
-
David Ahern authored
net and null_fallback are redundant. Remove null_fallback in favor of !net check. Signed-off-by:
David Ahern <dsahern@gmail.com> Acked-by:
-
David Ahern authored
fib_trie implementation calls synchronize_rcu when a certain amount of pages are dirty from freed entries. The number of pages was determined experimentally in 2009 (commit c3059477). At the current setting, synchronize_rcu is called often -- 51 times in a second in one test with an average of an 8 msec delay adding a fib entry. The total impact is a lot of slow down modifying the fib. This is seen in the output of 'time' - the difference between real time and sys+user. For example, using 720,022 single path routes and 'ip -batch'[1]: $ time ./ip -batch ipv4/routes-1-hops real 0m14.214s user 0m2.513s sys 0m6.783s So roughly 35% of the actual time to install the routes is from the ip command getting scheduled out, most notably due to synchronize_rcu (this is observed using 'perf sched timehist'). This patch makes the amount of dirty memory configurable between 64k where the synchronize_rcu is called often (small, low end systems that are memory sensitive) to 64M where synchronize_rcu is called rarely during a large FIB change (for high end systems with lots of memory). The default is 512kB which corresponds to the current setting of 128 pages with a 4kB page size. As an example, at 16MB the worst interval shows 4 calls to synchronize_rcu in a second blocking for up to 30 msec in a single instance, and a total of almost 100 msec across the 4 calls in the second. The trade off is allowing FIB entries to consume more memory in a given time window but but with much better fib insertion rates (~30% increase in prefixes/sec). With this patch and net.ipv4.fib_sync_mem set to 16MB, the same batch file runs in: $ time ./ip -batch ipv4/routes-1-hops real 0m9.692s user 0m2.491s sys 0m6.769s So the dead time is reduced to about 1/2 second or <5% of the real time. [1] 'ip' modified to not request ACK messages which improves route insertion times by about 20% Signed-off-by:
-
Kirill Tkhai authored
Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
-
Kirill Tkhai authored
In commit f2780d6d "tun: Add ioctl() SIOCGSKNS cmd to allow obtaining net ns of tun device" it was missed that tun may change its net ns, while net ns of socket remains the same as it was created initially. SIOCGSKNS returns net ns of socket, so it is not suitable for obtaining net ns of device. We may have two tun devices with the same names in two net ns, and in this case it's not possible to determ, which of them fd refers to (TUNGETIFF will return the same name). This patch adds new ioctl() cmd for obtaining net ns of a device. Reported-by:
Harald Albrecht <harald.albrecht@gmx.net> Signed-off-by:
-
David S. Miller authored
David Ahern says: ==================== ipv6: Change addrconf_f6i_alloc to use ip6_route_info_create addrconf_f6i_alloc is the last caller of fib6_info_alloc besides ip6_route_info_create. There really is no good reason for it do its own fib6_info initialization, so convert it to call ip6_route_info_create. ==================== Signed-off-by: -
David Ahern authored
Change addrconf_f6i_alloc to generate a fib6_config and call ip6_route_info_create. addrconf_f6i_alloc is the last caller to fib6_info_alloc besides ip6_route_info_create, and there is no reason for it to do its own initialization on a fib6_info. Host routes need to be created even if the device is down, so add a new flag, fc_ignore_dev_down, to fib6_config and update fib6_nh_init to not error out if device is not up. Notes on the conversion: - ip_fib_metrics_init is the same as fib6_config has fc_mx set to NULL and fc_mx_len set to 0 - dst_nocount is handled by the RTF_ADDRCONF flag - dst_host is handled by fc_dst_len = 128 nh_gw does not get set after the conversion to ip6_route_info_create but it should not be set in addrconf_f6i_alloc since this is a host route not a gateway route. Everything else is a straight forward map between fib6_info and fib6_config. Signed-off-by:
-
David Ahern authored
ip6_route_info_create is a low level function for ensuring fc_metric is set. Move the check and default setting to the 2 locations that do not already set fc_metric before calling ip6_route_info_create. This is required for the next patch which moves addrconf allocations to ip6_route_info_create and want the metric for host routes to be 0. Signed-off-by:
-
Vakul Garg authored
To free the skb in normal course of processing, consume_skb() should be used. Only for failure paths, skb_free() is intended to be used. https://www.kernel.org/doc/htmldocs/networking/API-consume-skb.htmlSigned-off-by:
Vakul Garg <vakul.garg@nxp.com> Signed-off-by:
-
Hoang Le authored
In commit c55c8eda ("tipc: smooth change between replicast and broadcast") we introduced new method to eliminate the risk of message reordering that happen in between different nodes. Unfortunately, we forgot checking at receiving side to ignore intra node. We fix this by checking and returning if arrived message from intra node. syzbot report: ================================================================== kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 7820 Comm: syz-executor418 Not tainted 5.0.0+ #61 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tipc_mcast_filter_msg+0x21b/0x13d0 net/tipc/bcast.c:782 Code: 45 c0 0f 84 39 06 00 00 48 89 5d 98 e8 ce ab a5 fa 49 8d bc 24 c8 00 00 00 48 b9 00 00 00 00 00 fc ff df 48 89 f8 48 c1 e8 03 <80> 3c 08 00 0f 85 9a 0e 00 00 49 8b 9c 24 c8 00 00 00 48 be 00 00 RSP: 0018:ffff8880959defc8 EFLAGS: 00010202 RAX: 0000000000000019 RBX: ffff888081258a48 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffffffff86cab862 RDI: 00000000000000c8 RBP: ffff8880959df030 R08: ffff8880813d0200 R09: ffffed1015d05bc8 R10: ffffed1015d05bc7 R11: ffff8880ae82de3b R12: 0000000000000000 R13: 000000000000002c R14: 0000000000000000 R15: ffff888081258a48 FS: 000000000106a880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020001cc0 CR3: 0000000094a20000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tipc_sk_filter_rcv+0x182d/0x34f0 net/tipc/socket.c:2168 tipc_sk_enqueue net/tipc/socket.c:2254 [inline] tipc_sk_rcv+0xc45/0x25a0 net/tipc/socket.c:2305 tipc_sk_mcast_rcv+0x724/0x1020 net/tipc/socket.c:1209 tipc_mcast_xmit+0x7fe/0x1200 net/tipc/bcast.c:410 tipc_sendmcast+0xb36/0xfc0 net/tipc/socket.c:820 __tipc_sendmsg+0x10df/0x18d0 net/tipc/socket.c:1358 tipc_sendmsg+0x53/0x80 net/tipc/socket.c:1291 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xdd/0x130 net/socket.c:661 ___sys_sendmsg+0x806/0x930 net/socket.c:2260 __sys_sendmsg+0x105/0x1d0 net/socket.c:2298 __do_sys_sendmsg net/socket.c:2307 [inline] __se_sys_sendmsg net/socket.c:2305 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2305 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4401c9 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffd887fa9d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401c9 RDX: 0000000000000000 RSI: 0000000020002140 RDI: 0000000000000003 RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401a50 R13: 0000000000401ae0 R14: 0000000000000000 R15: 0000000000000000 Modules linked in: ---[ end trace ba79875754e1708f ]--- Reported-by: syzbot+be4bdf2cc3e85e952c50@syzkaller.appspotmail.com Fixes: c55c8eda ("tipc: smooth change between replicast and broadcast") Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by:
-
Hoang Le authored
skb free-ed in: 1/ condition 1: tipc_sk_filter_rcv -> tipc_sk_proto_rcv 2/ condition 2: tipc_sk_filter_rcv -> tipc_group_filter_msg This leads to a "use-after-free" access in the next condition. We fix this by intializing the variable at declaration, then it is safe to check this variable to continue processing if condition matches. syzbot report: ================================================================== BUG: KASAN: use-after-free in tipc_sk_filter_rcv+0x2166/0x34f0 net/tipc/socket.c:2167 Read of size 4 at addr ffff88808ea58534 by task kworker/u4:0/7 CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.0.0+ #61 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: tipc_send tipc_conn_send_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 __asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131 tipc_sk_filter_rcv+0x2166/0x34f0 net/tipc/socket.c:2167 tipc_sk_enqueue net/tipc/socket.c:2254 [inline] tipc_sk_rcv+0xc45/0x25a0 net/tipc/socket.c:2305 tipc_topsrv_kern_evt+0x3b7/0x580 net/tipc/topsrv.c:610 tipc_conn_send_to_sock+0x43e/0x5f0 net/tipc/topsrv.c:283 tipc_conn_send_work+0x65/0x80 net/tipc/topsrv.c:303 process_one_work+0x98e/0x1790 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x357/0x430 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Reported-by: syzbot+e863893591cc7a622e40@syzkaller.appspotmail.com Fixes: c55c8eda ("tipc: smooth change between replicast and broadcast") Acked-by:
-
- 20 Mar, 2019 22 commits
-
-
Stephen Suryaputra authored
In addition to icmp_echo_ignore_multicast, there is a need to also prevent responding to pings to anycast addresses for security. Signed-off-by:
Stephen Suryaputra <ssuryaextr@gmail.com> Signed-off-by:
-
YueHaibing authored
Fix sparse warnings: drivers/isdn/i4l/isdn_ppp.c:1891:16: warning: symbol 'isdn_ppp_mp_discard' was not declared. Should it be static? drivers/isdn/i4l/isdn_ppp.c:1903:6: warning: symbol 'isdn_ppp_mp_reassembly' was not declared. Should it be static? Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
Fix sparse warning: drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c:414:6: warning: symbol 'hclge_destroy_cmd_queue' was not declared. Should it be static? Signed-off-by:
-
David S. Miller authored
Paolo Abeni says: ==================== net: refactor ndo_select_queue() Currently, on most devices implementing ndo_select_queue(), we get 2 indirect calls per xmit packet, at least in some scenarios. We can avoid one of such indirect calls refactoring the ndo_select_queue() usage so that we don't need anymore the 'fallback' argument. The first patch renames a helper used later as a public API, the second one changes the af packet implementation so that it uses the common infrastructure to select the xmit queue, and the second patch drops the now unneeded argument from ndo_select_queue(). Alternatively we could use the INDIRECT_CALL_WRAPPER infrastructure to avoid the fallback indirect call in the common case, but this solution allows also for some code cleanup. v1 -> v2: - renamed select queue helpers, as per Eric's and David's suggestions ==================== Signed-off-by: -
Paolo Abeni authored
After the previous patch, all the callers of ndo_select_queue() provide as a 'fallback' argument netdev_pick_tx. The only exceptions are nested calls to ndo_select_queue(), which pass down the 'fallback' available in the current scope - still netdev_pick_tx. We can drop such argument and replace fallback() invocation with netdev_pick_tx(). This avoids an indirect call per xmit packet in some scenarios (TCP syn, UDP unconnected, XDP generic, pktgen) with device drivers implementing such ndo. It also clean the code a bit. Tested with ixgbe and CONFIG_FCOE=m With pktgen using queue xmit: threads vanilla patched (kpps) (kpps) 1 2334 2428 2 4166 4278 4 7895 8100 v1 -> v2: - rebased after helper's name change Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
Currently packet_pick_tx_queue() is the only caller of ndo_select_queue() using a fallback argument other than netdev_pick_tx. Leveraging rx queue, we can obtain a similar queue selection behavior using core helpers. After this change, ndo_select_queue() is always invoked with netdev_pick_tx() as fallback. We can change ndo_select_queue() signature in a followup patch, dropping an indirect call per transmitted packet in some scenarios (e.g. TCP syn and XDP generic xmit) This changes slightly how af packet queue selection happens when PACKET_QDISC_BYPASS is set. It's now more similar to plan dev_queue_xmit() tacking in account both XPS and TC mapping. v1 -> v2: - rebased after helper name change RFC -> v1: - initialize sender_cpu to the expected value Signed-off-by:
-
Paolo Abeni authored
With the following patches, we are going to use __netdev_pick_tx() in many modules. Rename it to netdev_pick_tx(), to make it clear is a public API. Also rename the existing netdev_pick_tx() to netdev_core_pick_tx(), to avoid name clashes. Suggested-by:
Eric Dumazet <edumazet@google.com> Suggested-by:
-
David S. Miller authored
Sudarsana Reddy Kalluru says: ==================== qed* enhancements. The patch series adds couple of enhancements for qed/qede drivers. Please consider applying it to 'net-next' tree. ==================== Signed-off-by: -
Sudarsana Reddy Kalluru authored
The patch introduces a new Multi-Function bit for cases where firmware shouldn't perform the insertion of vlan-0 tag. The new bit is defined to abstract the implementation from the actual MF mode. Signed-off-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
Michal Kalderon <mkalderon@marvell.com> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
The patch adds support to display MBI image version in 'ethtool -i' output. Signed-off-by:
-
Hangbin Liu authored
Similiar to commit a6111d3c ("vlan: Pass SIOC[SG]HWTSTAMP ioctls to real device") and commit 37dd9255 ("vlan: Pass ethtool get_ts_info queries to real device."), add MACVlan HW ptp support. Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
-
Mao Wenan authored
This patch is to use eth_broadcast_addr() to assign broadcast address insetad of memset(). Signed-off-by:
Mao Wenan <maowenan@huawei.com> Signed-off-by:
-
Vakul Garg authored
Added support for AES128-CCM based record encryption. AES128-CCM is similar to AES128-GCM. Both of them have same salt/iv/mac size. The notable difference between the two is that while invoking AES128-CCM operation, the salt||nonce (which is passed as IV) has to be prefixed with a hardcoded value '2'. Further, CCM implementation in kernel requires IV passed in crypto_aead_request() to be full '16' bytes. Therefore, the record structure 'struct tls_rec' has been modified to reserve '16' bytes for IV. This works for both GCM and CCM based cipher. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: aquantia: add interface mode handling These two patches add interface mode handling for the AQR107/AQCS109. ==================== Signed-off-by: -
Nikita Yushchenko authored
Depending on the auto-negotiated speed the PHY may change the interface mode. Check for new mode and set phydev->interface accordingly. Signed-off-by:
Nikita Yushchenko <nikita.yoush@cogentembedded.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> [hkallweit1@gmail.com: picked from bigger patch and reworked] Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Andrew Lunn authored
Let config_init check for unsupported interface modes on AQR107/AQCS109. Signed-off-by:
-
Heiner Kallweit authored
Currently the Phy driver's link_change_notify callback is called whenever the state machine is run (every second if polling), no matter whether the state changed or not. This isn't needed and may confuse users considering the name of the callback. Actually it contradicts its kernel-doc description. Therefore let's change the behavior and call this callback only in case of an actual state change. This requires changes to the at803x and rockchip drivers. at803x can be simplified so that it reacts on a state change to PHY_NOLINK only. The rockchip driver can also be much simplified. We simply re-init the AFE/DSP registers whenever we change to PHY_RUNNING and speed is 100Mbps. This causes very small overhead because we do this even if the speed was 100Mbps already. But this is negligible and I think justified by the much simpler code. Changes are compile-tested only. A little bit problematic seems to be to find somebody with the hardware to test the changes to the two PHY drivers. See also [0]. David may be able to test the Rockchip driver. [0] https://marc.info/?t=153782508800006&r=1&w=2Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2019-03-19 This series contains updates to ice driver only. Michal adds support for the pruning enable flag to avoid seeing broadcast packets on different VLANs. Akeem fixes an issue with VF queues being disabled and the VF netdev network carrier being lost after reset. Fixed an issue issue when doing PFR and CORER resets, where all VF VSIs need to be reset and rebuilt with the main VSIs before replaying all VSIs. Resolved an issue to properly initialize VFs in the guest OS via PCI passthrough. Bruce adds a local variable to avoid unnecessary de-references throughout ice_probe(). Brett cleans up the code a bit by removing the need for a local variable and re-designs the loop to simply return when get a successful result. Cleans up the code to replace loop calls with a predefined macro to make the code more consistent. Updated the driver to ensure ITR granularity is always 2 usecs. Refactors the calculation of VSIs per PF into a general function that can calculate per PF allocations for not just VSIs but across multiple resource types. Improve the driver performance of the driver when using the default settings by determining the ring size and the number of descriptors for transmit and receive based on a calculation with the PAGE_SIZE, ICE_MAX_NUM_DESC, and ICE_REQ_DESC_MULTIPLE. Chinh fixes an issue, where a reserved bit was possibly being set when it should never be set. ==================== Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2019-03-19 This series contains updates to e100, e1000, e1000e, igb, igc and ixgbe. Serhey Popovych fixes the return value for several of our older drivers for netdev_update_features() to notify of changes applied. Kai-Heng Feng fixes the WoL setting for system suspend, which should not set to runtime suspend settings for igb. Then fixes a power management issue with e1000e for CNP+ devices. Colin Ian King fixes whitespace issue (indentation), which helps with readability. Sasha provides the remaining changes for igc, including the enabling of multi-queues to receive. Added support for displaying and configuring network flow classification (NFC) via ethtool. Added additional statistics and basic counters for igc. Fixed a typo, so it aligns with our other drivers. ==================== Signed-off-by: -
Brett Creeley authored
Currently we set the default number of Tx and Rx descriptors to 128 by default. For Rx this amounts to a full page (assuming 4K pages) because each Rx descriptor is 32 Bytes, but for Tx it only amounts to a half page because each Tx descriptor is 16 Bytes (assuming 4K pages). Instead of assuming 4K pages, determine the ring size and the number of descriptors for Tx and Rx based on a calculation using the PAGE_SIZE, ICE_MAX_NUM_DESC, and ICE_REQ_DESC_MULTIPLE. This change is being made to improve the performance of the driver when using the default settings. Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Akeem G Abodunrin authored
During SR-IOV initialization, we allocate and setup VFs with reset, and since we were going to inform Firmware about our intention to do VFLR by disabling LAN TX Queue, then we really have to complete VF reset flow with VFLR using appropriate registers - Otherwise, reset status bit for VF in the Guest OS might returns DEADBEEF. This resolves issue to properly initialize VFs in the Guest OS via PCI passthrough. Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Signed-off-by:
-
Brett Creeley authored
ice_get_guar_num_vsi currently calculates the number of VSIs per PF. Rework this into a general function ice_get_num_per_func, that can calculate per PF allocations for not just VSIs but across multiple resource types. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
-
