<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/net/ethernet, branch linux-5.18.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.18.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.18.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2022-08-17T12:42:02+00:00</updated>
<entry>
<title>net/ice: fix initializing the bitmap in the switch code</title>
<updated>2022-08-17T12:42:02+00:00</updated>
<author>
<name>Alexander Lobakin</name>
<email>alexandr.lobakin@intel.com</email>
</author>
<published>2022-06-24T12:13:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=06b930278edf0f8580bf0ec7a5946fbb4b8178b9'/>
<id>urn:sha1:06b930278edf0f8580bf0ec7a5946fbb4b8178b9</id>
<content type='text'>
[ Upstream commit 2f7ee2a72ccec8b85a05c4644d7ec9f40c1c50c8 ]

Kbuild spotted the following bug during the testing of one of
the optimizations:

In file included from include/linux/cpumask.h:12,
[...]
                from drivers/net/ethernet/intel/ice/ice_switch.c:4:
drivers/net/ethernet/intel/ice/ice_switch.c: In function 'ice_find_free_recp_res_idx.constprop':
include/linux/bitmap.h:447:22: warning: 'possible_idx[0]' is used uninitialized [-Wuninitialized]
  447 |                 *map |= GENMASK(start + nbits - 1, start);
      |                      ^~
In file included from drivers/net/ethernet/intel/ice/ice.h:7,
                 from drivers/net/ethernet/intel/ice/ice_lib.h:7,
                 from drivers/net/ethernet/intel/ice/ice_switch.c:4:
drivers/net/ethernet/intel/ice/ice_switch.c:4929:24: note: 'possible_idx[0]' was declared here
 4929 |         DECLARE_BITMAP(possible_idx, ICE_MAX_FV_WORDS);
      |                        ^~~~~~~~~~~~
include/linux/types.h:11:23: note: in definition of macro 'DECLARE_BITMAP'
   11 |         unsigned long name[BITS_TO_LONGS(bits)]
      |                       ^~~~

%ICE_MAX_FV_WORDS is 48, so bitmap_set() here was initializing only
48 bits, leaving a junk in the rest 16.
It was previously hidden due to that filling 48 bits makes
bitmap_set() call external __bitmap_set(), but after making it use
plain bit arithmetics on small bitmaps, compilers started seeing
the issue. It was still working because those 16 weren't used
anywhere anyhow.
bitmap_{clear,set}() are not really intended to initialize bitmaps,
rather to modify already initialized ones, as they don't do anything
past the passed number of bits. The correct function to do this in
that particular case is bitmap_fill(), so use it here. It will do
`*possible_idx = ~0UL` instead of `*possible_idx |= GENMASK(47, 0)`,
not leaving anything in an undefined state.

Fixes: fd2a6b71e300 ("ice: create advanced switch recipe")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Alexander Lobakin &lt;alexandr.lobakin@intel.com&gt;
Signed-off-by: Yury Norov &lt;yury.norov@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: Expose mlx5_sriov_blocking_notifier_register / unregister APIs</title>
<updated>2022-08-17T12:42:01+00:00</updated>
<author>
<name>Yishai Hadas</name>
<email>yishaih@nvidia.com</email>
</author>
<published>2022-05-10T09:02:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8bfde97fb1fe2f1893014de526c34cf406377c22'/>
<id>urn:sha1:8bfde97fb1fe2f1893014de526c34cf406377c22</id>
<content type='text'>
[ Upstream commit 846e437387e74c44ddc9f3eeec472fd37ca3cdb9 ]

Expose mlx5_sriov_blocking_notifier_register / unregister APIs to let a
VF register to be notified for its enablement / disablement by the PF.

Upon VF probe it will call mlx5_sriov_blocking_notifier_register() with
its notifier block and upon VF remove it will call
mlx5_sriov_blocking_notifier_unregister() to drop its registration.

This can give a VF the ability to clean some resources upon disable
before that the command interface goes down and on the other hand sets
some stuff before that it's enabled.

This may be used by a VF which is migration capable in few cases.(e.g.
PF load/unload upon an health recovery).

Link: https://lore.kernel.org/r/20220510090206.90374-2-yishaih@nvidia.com
Signed-off-by: Yishai Hadas &lt;yishaih@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5e: xsk: Discard unaligned XSK frames on striding RQ</title>
<updated>2022-08-17T12:41:16+00:00</updated>
<author>
<name>Maxim Mikityanskiy</name>
<email>maximmi@nvidia.com</email>
</author>
<published>2022-07-29T12:13:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=15e7a82753a0c7b52a8d5cb1cd16583bca16e9c4'/>
<id>urn:sha1:15e7a82753a0c7b52a8d5cb1cd16583bca16e9c4</id>
<content type='text'>
[ Upstream commit 8eaa1d110800fac050bab44001732747a1c39894 ]

Striding RQ uses MTT page mapping, where each page corresponds to an XSK
frame. MTT pages have alignment requirements, and XSK frames don't have
any alignment guarantees in the unaligned mode. Frames with improper
alignment must be discarded, otherwise the packet data will be written
at a wrong address.

Fixes: 282c0c798f8e ("net/mlx5e: Allow XSK frames smaller than a page")
Signed-off-by: Maxim Mikityanskiy &lt;maximmi@nvidia.com&gt;
Reviewed-by: Tariq Toukan &lt;tariqt@nvidia.com&gt;
Reviewed-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Reviewed-by: Maciej Fijalkowski &lt;maciej.fijalkowski@intel.com&gt;
Link: https://lore.kernel.org/r/20220729121356.3990867-1-maximmi@nvidia.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: ionic: fix error check for vlan flags in ionic_set_nic_features()</title>
<updated>2022-08-17T12:41:16+00:00</updated>
<author>
<name>Jian Shen</name>
<email>shenjian15@huawei.com</email>
</author>
<published>2022-07-29T10:17:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=69c82c0822331b94fc9ae032318f96894a78d1dc'/>
<id>urn:sha1:69c82c0822331b94fc9ae032318f96894a78d1dc</id>
<content type='text'>
[ Upstream commit a86e86db5e6d72c82724a63ca1c5293409a21518 ]

The prototype of input features of ionic_set_nic_features() is
netdev_features_t, but the vlan_flags is using the private
definition of ionic drivers. It should use the variable
ctx.cmd.lif_setattr.features, rather than features to check
the vlan flags. So fixes it.

Fixes: beead698b173 ("ionic: Add the basic NDO callbacks for netdev support")
Signed-off-by: Jian Shen &lt;shenjian15@huawei.com&gt;
Signed-off-by: Guangbin Huang &lt;huangguangbin2@huawei.com&gt;
Acked-by: Shannon Nelson &lt;snelson@pensando.io&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: ice: fix error NETIF_F_HW_VLAN_CTAG_FILTER check in ice_vsi_sync_fltr()</title>
<updated>2022-08-17T12:41:16+00:00</updated>
<author>
<name>Jian Shen</name>
<email>shenjian15@huawei.com</email>
</author>
<published>2022-07-29T10:17:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e0e752d4409085f2a7e10700fce38c3239ecad11'/>
<id>urn:sha1:e0e752d4409085f2a7e10700fce38c3239ecad11</id>
<content type='text'>
[ Upstream commit 7dc839fe47611e6995f370cae37b9797cf7d2672 ]

vsi-&gt;current_netdev_flags is used store the current net device
flags, not the active netdevice features. So it should use
vsi-&gt;netdev-&gt;featurs, rather than vsi-&gt;current_netdev_flags
to check NETIF_F_HW_VLAN_CTAG_FILTER.

Fixes: 1babaf77f49d ("ice: Advertise 802.1ad VLAN filtering and offloads for PF netdev")
Signed-off-by: Jian Shen &lt;shenjian15@huawei.com&gt;
Signed-off-by: Guangbin Huang &lt;huangguangbin2@huawei.com&gt;
Acked-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iavf: Fix 'tc qdisc show' listing too many queues</title>
<updated>2022-08-17T12:41:15+00:00</updated>
<author>
<name>Przemyslaw Patynowski</name>
<email>przemyslawx.patynowski@intel.com</email>
</author>
<published>2022-06-15T13:36:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=62ae3bb8aebd62904faff2dc3d345050b581326b'/>
<id>urn:sha1:62ae3bb8aebd62904faff2dc3d345050b581326b</id>
<content type='text'>
[ Upstream commit 93cb804edab1b9a5bb7bb7b6824012dbb20abf22 ]

Fix tc qdisc show dev &lt;ethX&gt; root displaying too many fq_codel qdiscs.
tc_modify_qdisc, which is caller of ndo_setup_tc, expects driver to call
netif_set_real_num_tx_queues, which prepares qdiscs.
Without this patch, fq_codel qdiscs would not be adjusted to number of
queues on VF.
e.g.:
tc qdisc show dev &lt;ethX&gt;
qdisc mq 0: root
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
tc qdisc add dev &lt;ethX&gt; root mqprio num_tc 2 map 1 0 0 0 0 0 0 0 queues 1@0 1@1 hw 1 mode channel shaper bw_rlimit max_rate 5000Mbit 150Mbit
tc qdisc show dev &lt;ethX&gt;
qdisc mqprio 8003: root tc 2 map 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
             queues:(0:0) (1:1)
             mode:channel
             shaper:bw_rlimit   max_rate:5Gbit 150Mbit
qdisc fq_codel 0: parent 8003:4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent 8003:3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent 8003:2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent 8003:1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64

While after fix:
tc qdisc add dev &lt;ethX&gt; root mqprio num_tc 2 map 1 0 0 0 0 0 0 0 queues 1@0 1@1 hw 1 mode channel shaper bw_rlimit max_rate 5000Mbit 150Mbit
tc qdisc show dev &lt;ethX&gt; #should show 2, shows 4
qdisc mqprio 8004: root tc 2 map 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
             queues:(0:0) (1:1)
             mode:channel
             shaper:bw_rlimit   max_rate:5Gbit 150Mbit
qdisc fq_codel 0: parent 8004:2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent 8004:1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64

Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf")
Signed-off-by: Przemyslaw Patynowski &lt;przemyslawx.patynowski@intel.com&gt;
Co-developed-by: Grzegorz Szczurek &lt;grzegorzx.szczurek@intel.com&gt;
Signed-off-by: Grzegorz Szczurek &lt;grzegorzx.szczurek@intel.com&gt;
Co-developed-by: Kiran Patil &lt;kiran.patil@intel.com&gt;
Signed-off-by: Kiran Patil &lt;kiran.patil@intel.com&gt;
Signed-off-by: Jedrzej Jagielski &lt;jedrzej.jagielski@intel.com&gt;
Tested-by: Bharathi Sreenivas &lt;bharathi.sreenivas@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iavf: Fix max_rate limiting</title>
<updated>2022-08-17T12:41:15+00:00</updated>
<author>
<name>Przemyslaw Patynowski</name>
<email>przemyslawx.patynowski@intel.com</email>
</author>
<published>2022-06-13T22:41:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0b7afdf2ce9cc21f73a4822b1ab74e811959d21e'/>
<id>urn:sha1:0b7afdf2ce9cc21f73a4822b1ab74e811959d21e</id>
<content type='text'>
[ Upstream commit ec60d54cb9a3d43a02c5612a03093c18233e6601 ]

Fix max_rate option in TC, check for proper quanta boundaries.
Check for minimum value provided and if it fits expected 50Mbps
quanta.

Without this patch, iavf could send settings for max_rate limiting
that would be accepted from by PF even the max_rate option is less
than expected 50Mbps quanta. It results in no rate limiting
on traffic as rate limiting will be floored to 0.

Example:
tc qdisc add dev $vf root mqprio num_tc 3 map 0 2 1 queues \
2@0 2@2 2@4 hw 1 mode channel shaper bw_rlimit \
max_rate 50Mbps 500Mbps 500Mbps

Should limit TC0 to circa 50 Mbps

tc qdisc add dev $vf root mqprio num_tc 3 map 0 2 1 queues \
2@0 2@2 2@4 hw 1 mode channel shaper bw_rlimit \
max_rate 0Mbps 100Kbit 500Mbps

Should return error

Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf")
Signed-off-by: Przemyslaw Patynowski &lt;przemyslawx.patynowski@intel.com&gt;
Signed-off-by: Jun Zhang &lt;xuejun.zhang@intel.com&gt;
Tested-by: Bharathi Sreenivas &lt;bharathi.sreenivas@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: Fix driver use of uninitialized timeout</title>
<updated>2022-08-17T12:41:14+00:00</updated>
<author>
<name>Shay Drory</name>
<email>shayd@nvidia.com</email>
</author>
<published>2022-06-27T13:05:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c0f279a2f0520cda4d2d61c19d30b8ae8e79107b'/>
<id>urn:sha1:c0f279a2f0520cda4d2d61c19d30b8ae8e79107b</id>
<content type='text'>
[ Upstream commit 42b4f7f66a43cdb9216e76e595c8a9af154806da ]

Currently, driver is setting default values to all timeouts during
function setup. The offending commit is using a timeout before
function setup, meaning: the timeout is 0 (or garbage), since no
value have been set.
This may result in failure to probe the driver:
mlx5_function_setup:1034:(pid 69850): Firmware over 4294967296 MS in pre-initializing state, aborting
probe_one:1591:(pid 69850): mlx5_init_one failed with error code -16

Hence, set default values to timeouts during tout_init()

Fixes: 37ca95e62ee2 ("net/mlx5: Increase FW pre-init timeout for health recovery")
Signed-off-by: Shay Drory &lt;shayd@nvidia.com&gt;
Reviewed-by: Moshe Shemesh &lt;moshe@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: DR, Fix SMFS steering info dump format</title>
<updated>2022-08-17T12:41:14+00:00</updated>
<author>
<name>Yevgeny Kliteynik</name>
<email>kliteyn@nvidia.com</email>
</author>
<published>2022-07-24T21:06:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=587d7826e2d3f37dc5a133e05921316a50626f40'/>
<id>urn:sha1:587d7826e2d3f37dc5a133e05921316a50626f40</id>
<content type='text'>
[ Upstream commit 62d2664351ef37da34f6f3a3fd8ab34257d6fe30 ]

Fix several issues in SMFS steering info dump:
 - Fix outdated macro value for matcher mask in the SMFS debug dump format.
   The existing value denotes the old format of the matcher mask, as it was
   used during the early stages of development, and it results in wrong
   parsing by the steering dump parser - wrong fields are shown in the
   parsed output.
 - Add the missing destination table to the dumped action.
   The missing dest table handle breaks the ability to associate between
   the "go to table" action and the actual table in the steering info.

Fixes: 9222f0b27da2 ("net/mlx5: DR, Add support for dumping steering info")
Signed-off-by: Yevgeny Kliteynik &lt;kliteyn@nvidia.com&gt;
Signed-off-by: Muhammad Sammar &lt;muhammads@nvidia.com&gt;
Reviewed-by: Alex Vesker &lt;valex@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: Adjust log_max_qp to be 18 at most</title>
<updated>2022-08-17T12:41:13+00:00</updated>
<author>
<name>Maher Sanalla</name>
<email>msanalla@nvidia.com</email>
</author>
<published>2022-07-24T08:28:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fb8551b3a62e10a2dd12202dc4bb2f70688e8ff8'/>
<id>urn:sha1:fb8551b3a62e10a2dd12202dc4bb2f70688e8ff8</id>
<content type='text'>
[ Upstream commit a6e9085d791f8306084fd5bc44dd3fdd4e1ac27b ]

The cited commit limited log_max_qp to be 17 due to FW capabilities.
Recently, it turned out that there are old FW versions that supported
more than 17, so the cited commit caused a degradation.

Thus, set the maximum log_max_qp back to 18 as it was before the
cited commit.

Fixes: 7f839965b2d7 ("net/mlx5: Update log_max_qp value to be 17 at most")
Signed-off-by: Maher Sanalla &lt;msanalla@nvidia.com&gt;
Reviewed-by: Maor Gottlieb &lt;maorg@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
