<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet/intel, branch v5.19</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-07-26T20:15:36+00:00</updated>
<entry>
<title>ice: do not setup vlan for loopback VSI</title>
<updated>2022-07-26T20:15:36+00:00</updated>
<author>
<name>Maciej Fijalkowski</name>
<email>maciej.fijalkowski@intel.com</email>
</author>
<published>2022-07-07T10:20:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cc019545a238518fa9da1e2a889f6e1bb1005a63'/>
<id>urn:sha1:cc019545a238518fa9da1e2a889f6e1bb1005a63</id>
<content type='text'>
Currently loopback test is failiing due to the error returned from
ice_vsi_vlan_setup(). Skip calling it when preparing loopback VSI.

Fixes: 0e674aeb0b77 ("ice: Add handler for ethtool selftest")
Signed-off-by: Maciej Fijalkowski &lt;maciej.fijalkowski@intel.com&gt;
Tested-by: George Kuruvinakunnel &lt;george.kuruvinakunnel@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: check (DD | EOF) bits on Rx descriptor rather than (EOP | RS)</title>
<updated>2022-07-26T20:15:36+00:00</updated>
<author>
<name>Maciej Fijalkowski</name>
<email>maciej.fijalkowski@intel.com</email>
</author>
<published>2022-07-07T10:20:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=283d736ff7c7e96ac5b32c6c0de40372f8eb171e'/>
<id>urn:sha1:283d736ff7c7e96ac5b32c6c0de40372f8eb171e</id>
<content type='text'>
Tx side sets EOP and RS bits on descriptors to indicate that a
particular descriptor is the last one and needs to generate an irq when
it was sent. These bits should not be checked on completion path
regardless whether it's the Tx or the Rx. DD bit serves this purpose and
it indicates that a particular descriptor is either for Rx or was
successfully Txed. EOF is also set as loopback test does not xmit
fragmented frames.

Look at (DD | EOF) bits setting in ice_lbtest_receive_frames() instead
of EOP and RS pair.

Fixes: 0e674aeb0b77 ("ice: Add handler for ethtool selftest")
Signed-off-by: Maciej Fijalkowski &lt;maciej.fijalkowski@intel.com&gt;
Tested-by: George Kuruvinakunnel &lt;george.kuruvinakunnel@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: Fix VSIs unable to share unicast MAC</title>
<updated>2022-07-26T20:15:36+00:00</updated>
<author>
<name>Anirudh Venkataramanan</name>
<email>anirudh.venkataramanan@intel.com</email>
</author>
<published>2022-07-21T08:03:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c8e3c7ff3e7bd7b938659be704f75cc746b697f'/>
<id>urn:sha1:5c8e3c7ff3e7bd7b938659be704f75cc746b697f</id>
<content type='text'>
The driver currently does not allow two VSIs in the same PF domain
to have the same unicast MAC address. This is incorrect in the sense
that a policy decision is being made in the driver when it must be
left to the user. This approach was causing issues when rebooting
the system with VFs spawned not being able to change their MAC addresses.
Such errors were present in dmesg:

[ 7921.068237] ice 0000:b6:00.2 ens2f2: Unicast MAC 6a:0d:e4:70:ca:d1 already
exists on this PF. Preventing setting VF 7 unicast MAC address to 6a:0d:e4:70:ca:d1

Fix that by removing this restriction. Doing this also allows
us to remove some additional code that's checking if a unicast MAC
filter already exists.

Fixes: 47ebc7b02485 ("ice: Check if unicast MAC exists before setting VF MAC")
Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@intel.com&gt;
Signed-off-by: Sylwester Dziedziuch &lt;sylwesterx.dziedziuch@intel.com&gt;
Signed-off-by: Mateusz Palczewski &lt;mateusz.palczewski@intel.com&gt;
Signed-off-by: Jedrzej Jagielski &lt;jedrzej.jagielski@intel.com&gt;
Tested-by: Marek Szlosek &lt;marek.szlosek@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: Fix tunnel checksum offload with fragmented traffic</title>
<updated>2022-07-26T20:15:36+00:00</updated>
<author>
<name>Przemyslaw Patynowski</name>
<email>przemyslawx.patynowski@intel.com</email>
</author>
<published>2022-07-18T11:34:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=01658aeeada6f93c2924af94d895ff28d559690c'/>
<id>urn:sha1:01658aeeada6f93c2924af94d895ff28d559690c</id>
<content type='text'>
Fix checksum offload on VXLAN tunnels.
In case, when mpls protocol is not used, set l4 header to transport
header of skb. This fixes case, when user tries to offload checksums
of VXLAN tunneled traffic.

Steps for reproduction (requires link partner with tunnels):
ip l s enp130s0f0 up
ip a f enp130s0f0
ip a a 10.10.110.2/24 dev enp130s0f0
ip l s enp130s0f0 mtu 1600
ip link add vxlan12_sut type vxlan id 12 group 238.168.100.100 dev enp130s0f0 dstport 4789
ip l s vxlan12_sut up
ip a a 20.10.110.2/24 dev vxlan12_sut
iperf3 -c 20.10.110.1 #should connect

Offload params: td_offset, cd_tunnel_params were
corrupted, due to l4 header pointing wrong address. NIC would then drop
those packets internally, due to incorrect TX descriptor data,
which increased GLV_TEPC register.

Fixes: 69e66c04c672 ("ice: Add mpls+tso support")
Signed-off-by: Przemyslaw Patynowski &lt;przemyslawx.patynowski@intel.com&gt;
Signed-off-by: Mateusz Palczewski &lt;mateusz.palczewski@intel.com&gt;
Signed-off-by: Jedrzej Jagielski &lt;jedrzej.jagielski@intel.com&gt;
Tested-by: Gurucharan &lt;gurucharanx.g@intel.com&gt; (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: Fix max VLANs available for VF</title>
<updated>2022-07-26T20:15:18+00:00</updated>
<author>
<name>Przemyslaw Patynowski</name>
<email>przemyslawx.patynowski@intel.com</email>
</author>
<published>2022-07-04T13:46:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1e308c6fb7127371f48a0fb9770ea0b30a6b5698'/>
<id>urn:sha1:1e308c6fb7127371f48a0fb9770ea0b30a6b5698</id>
<content type='text'>
Legacy VLAN implementation allows for untrusted VF to have 8 VLAN
filters, not counting VLAN 0 filters. Current VLAN_V2 implementation
lowers available filters for VF, by counting in VLAN 0 filter for both
TPIDs.
Fix this by counting only non zero VLAN filters.
Without this patch, untrusted VF would not be able to access 8 VLAN
filters.

Fixes: cc71de8fa133 ("ice: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2")
Signed-off-by: Przemyslaw Patynowski &lt;przemyslawx.patynowski@intel.com&gt;
Signed-off-by: Mateusz Palczewski &lt;mateusz.palczewski@intel.com&gt;
Tested-by: Marek Szlosek &lt;marek.szlosek@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>i40e: Fix interface init with MSI interrupts (no MSI-X)</title>
<updated>2022-07-26T01:48:41+00:00</updated>
<author>
<name>Michal Maloszewski</name>
<email>michal.maloszewski@intel.com</email>
</author>
<published>2022-07-22T17:54:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5fcbb711024aac6d4db385623e6f2fdf019f7782'/>
<id>urn:sha1:5fcbb711024aac6d4db385623e6f2fdf019f7782</id>
<content type='text'>
Fix the inability to bring an interface up on a setup with
only MSI interrupts enabled (no MSI-X).
Solution is to add a default number of QPs = 1. This is enough,
since without MSI-X support driver enables only a basic feature set.

Fixes: bc6d33c8d93f ("i40e: Fix the number of queues available to be mapped for use")
Signed-off-by: Dawid Lukwinski &lt;dawid.lukwinski@intel.com&gt;
Signed-off-by: Michal Maloszewski &lt;michal.maloszewski@intel.com&gt;
Tested-by: Dave Switzer &lt;david.switzer@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Link: https://lore.kernel.org/r/20220722175401.112572-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue</title>
<updated>2022-07-20T00:43:02+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-07-20T00:43:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=48ea8ea32dbf3231882e9bc0b297fe1400785219'/>
<id>urn:sha1:48ea8ea32dbf3231882e9bc0b297fe1400785219</id>
<content type='text'>
Tony Nguyen says:

====================
Intel Wired LAN Driver Updates 2022-07-18

This series contains updates to iavf driver only.

Przemyslaw fixes handling of multiple VLAN requests to account for
individual errors instead of rejecting them all. He removes incorrect
implementations of ETHTOOL_COALESCE_MAX_FRAMES and
ETHTOOL_COALESCE_MAX_FRAMES_IRQ.

He also corrects an issue with NULL pointer caused by improper handling of
dummy receive descriptors. Finally, he corrects debug prints reporting an
unknown state.

* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
  iavf: Fix missing state logs
  iavf: Fix handling of dummy receive descriptors
  iavf: Disallow changing rx/tx-frames and rx/tx-frames-irq
  iavf: Fix VLAN_V2 addition/rejection
====================

Link: https://lore.kernel.org/r/20220718174807.4113582-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero</title>
<updated>2022-07-19T03:13:40+00:00</updated>
<author>
<name>Piotr Skajewski</name>
<email>piotrx.skajewski@intel.com</email>
</author>
<published>2022-07-15T21:44:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1e53834ce541d4fe271cdcca7703e50be0a44f8a'/>
<id>urn:sha1:1e53834ce541d4fe271cdcca7703e50be0a44f8a</id>
<content type='text'>
It is possible to disable VFs while the PF driver is processing requests
from the VF driver.  This can result in a panic.

BUG: unable to handle kernel paging request at 000000000000106c
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I      --------- -
Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020
RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe]
Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff
01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 &lt;41&gt; 80 7c 24 4c
00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a
RSP: 0018:ffffb337869f8df8 EFLAGS: 00010002
RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b
RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006
RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780
R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020
R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80
FS:  0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;IRQ&gt;
 ? ttwu_do_wakeup+0x19/0x140
 ? try_to_wake_up+0x1cd/0x550
 ? ixgbevf_update_xcast_mode+0x71/0xc0 [ixgbevf]
 ixgbe_msix_other+0x17e/0x310 [ixgbe]
 __handle_irq_event_percpu+0x40/0x180
 handle_irq_event_percpu+0x30/0x80
 handle_irq_event+0x36/0x53
 handle_edge_irq+0x82/0x190
 handle_irq+0x1c/0x30
 do_IRQ+0x49/0xd0
 common_interrupt+0xf/0xf

This can be eventually be reproduced with the following script:

while :
do
    echo 63 &gt; /sys/class/net/&lt;devname&gt;/device/sriov_numvfs
    sleep 1
    echo 0 &gt; /sys/class/net/&lt;devname&gt;/device/sriov_numvfs
    sleep 1
done

Add lock when disabling SR-IOV to prevent process VF mailbox communication.

Fixes: d773d1310625 ("ixgbe: Fix memory leak when SR-IOV VFs are direct assigned")
Signed-off-by: Piotr Skajewski &lt;piotrx.skajewski@intel.com&gt;
Tested-by: Marek Szlosek &lt;marek.szlosek@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Link: https://lore.kernel.org/r/20220715214456.2968711-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>i40e: Fix erroneous adapter reinitialization during recovery process</title>
<updated>2022-07-19T03:13:22+00:00</updated>
<author>
<name>Dawid Lukwinski</name>
<email>dawid.lukwinski@intel.com</email>
</author>
<published>2022-07-15T21:45:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f838a63369818faadec4ad1736cfbd20ab5da00e'/>
<id>urn:sha1:f838a63369818faadec4ad1736cfbd20ab5da00e</id>
<content type='text'>
Fix an issue when driver incorrectly detects state
of recovery process and erroneously reinitializes interrupts,
which results in a kernel error and call trace message.

The issue was caused by a combination of two factors:
1. Assuming the EMP reset issued after completing
firmware recovery means the whole recovery process is complete.
2. Erroneous reinitialization of interrupt vector after detecting
the above mentioned EMP reset.

Fixes (1) by changing how recovery state change is detected
and (2) by adjusting the conditional expression to ensure using proper
interrupt reinitialization method, depending on the situation.

Fixes: 4ff0ee1af016 ("i40e: Introduce recovery mode support")
Signed-off-by: Dawid Lukwinski &lt;dawid.lukwinski@intel.com&gt;
Signed-off-by: Jan Sokolowski &lt;jan.sokolowski@intel.com&gt;
Tested-by: Konrad Jankowski &lt;konrad0.jankowski@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Link: https://lore.kernel.org/r/20220715214542.2968762-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>iavf: Fix missing state logs</title>
<updated>2022-07-18T16:36:40+00:00</updated>
<author>
<name>Przemyslaw Patynowski</name>
<email>przemyslawx.patynowski@intel.com</email>
</author>
<published>2022-06-15T17:57:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d8fa2fd791a72087c1ce3336fbeefec4057c37c8'/>
<id>urn:sha1:d8fa2fd791a72087c1ce3336fbeefec4057c37c8</id>
<content type='text'>
Fix debug prints, by adding missing state prints.

Extend iavf_state_str by strings for __IAVF_INIT_EXTENDED_CAPS and
__IAVF_INIT_CONFIG_ADAPTER.

Without this patch, when enabling debug prints for iavf.h, user will
see:
iavf 0000:06:0e.0: state transition from:__IAVF_INIT_GET_RESOURCES to:__IAVF_UNKNOWN_STATE
iavf 0000:06:0e.0: state transition from:__IAVF_UNKNOWN_STATE to:__IAVF_UNKNOWN_STATE

Fixes: 605ca7c5c670 ("iavf: Fix kernel BUG in free_msi_irqs")
Signed-off-by: Przemyslaw Patynowski &lt;przemyslawx.patynowski@intel.com&gt;
Signed-off-by: Jun Zhang &lt;xuejun.zhang@intel.com&gt;
Tested-by: Konrad Jankowski &lt;konrad0.jankowski@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
</feed>
