<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet, branch v5.4.113</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.113</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.113'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-04-14T06:24:17+00:00</updated>
<entry>
<title>net: hns3: clear VF down state bit before request link status</title>
<updated>2021-04-14T06:24:17+00:00</updated>
<author>
<name>Guangbin Huang</name>
<email>huangguangbin2@huawei.com</email>
</author>
<published>2021-04-06T13:10:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9716aac1741970f299c0b1680c29baf90d2630ce'/>
<id>urn:sha1:9716aac1741970f299c0b1680c29baf90d2630ce</id>
<content type='text'>
[ Upstream commit ed7bedd2c3ca040f1e8ea02c6590a93116b1ec78 ]

Currently, the VF down state bit is cleared after VF sending
link status request command. There is problem that when VF gets
link status replied from PF, the down state bit may still set
as 1. In this case, the link status replied from PF will be
ignored and always set VF link status to down.

To fix this problem, clear VF down state bit before VF requests
link status.

Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
Signed-off-by: Guangbin Huang &lt;huangguangbin2@huawei.com&gt;
Signed-off-by: Huazhong Tan &lt;tanhuazhong@huawei.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: macb: restore cmp registers on resume path</title>
<updated>2021-04-14T06:24:16+00:00</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea@microchip.com</email>
</author>
<published>2021-04-02T12:42:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b3717885865c6d07d5b541a62958b46120e7646d'/>
<id>urn:sha1:b3717885865c6d07d5b541a62958b46120e7646d</id>
<content type='text'>
[ Upstream commit a14d273ba15968495896a38b7b3399dba66d0270 ]

Restore CMP screener registers on resume path.

Fixes: c1e85c6ce57ef ("net: macb: save/restore the remaining registers and features")
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i40e: Fix display statistics for veb_tc</title>
<updated>2021-04-14T06:24:16+00:00</updated>
<author>
<name>Eryk Rybak</name>
<email>eryk.roch.rybak@intel.com</email>
</author>
<published>2021-03-02T07:46:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e22ce1d21b42a9232c1faf38c03be30a6d7984b8'/>
<id>urn:sha1:e22ce1d21b42a9232c1faf38c03be30a6d7984b8</id>
<content type='text'>
[ Upstream commit c3214de929dbf1b7374add8bbed30ce82b197bbb ]

If veb-stats was enabled, the ethtool stats triggered a warning
due to invalid size: 'unexpected stat size for veb.tc_%u_tx_packets'.
This was due to an incorrect structure definition for the statistics.
Structures and functions have been improved in line with requirements
for the presentation of statistics, in particular for the functions:
'i40e_add_ethtool_stats' and 'i40e_add_stat_strings'.

Fixes: 1510ae0be2a4 ("i40e: convert VEB TC stats to use an i40e_stats array")
Signed-off-by: Eryk Rybak &lt;eryk.roch.rybak@intel.com&gt;
Signed-off-by: Grzegorz Szczurek &lt;grzegorzx.szczurek@intel.com&gt;
Reviewed-by: Aleksandr Loktionov &lt;aleksandr.loktionov@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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: Don't request more than supported EQs</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Daniel Jurgens</name>
<email>danielj@mellanox.com</email>
</author>
<published>2019-12-05T22:58:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=73f88cc2bf5c1385bfe20169572fdb4c8a8f12df'/>
<id>urn:sha1:73f88cc2bf5c1385bfe20169572fdb4c8a8f12df</id>
<content type='text'>
[ Upstream commit a7b76002ae78cd230ee652ccdfedf21aa94fcecc ]

Calculating the number of compeltion EQs based on the number of
available IRQ vectors doesn't work now that all async EQs share one IRQ.
Thus the max number of EQs can be exceeded on systems with more than
approximately 256 CPUs. Take this into account when calculating the
number of available completion EQs.

Fixes: 81bfa206032a ("net/mlx5: Use a single IRQ for all async EQs")
Signed-off-by: Daniel Jurgens &lt;danielj@mellanox.com&gt;
Reviewed-by: Parav Pandit &lt;parav@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/mlx5e: Fix ethtool indication of connector type</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Aya Levin</name>
<email>ayal@nvidia.com</email>
</author>
<published>2021-03-24T10:25:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=029416e14be2276cca6d1d46b09129f044646308'/>
<id>urn:sha1:029416e14be2276cca6d1d46b09129f044646308</id>
<content type='text'>
[ Upstream commit 3211434dfe7a66fcf55e43961ea524b78336c04c ]

Use connector_type read from PTYS register when it's valid, based on
corresponding capability bit.

Fixes: 5b4793f81745 ("net/mlx5e: Add support for reading connector type from PTYS")
Signed-off-by: Aya Levin &lt;ayal@nvidia.com&gt;
Reviewed-by: Eran Ben Elisha &lt;eranbe@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>nfp: flower: ignore duplicate merge hints from FW</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Yinjun Zhang</name>
<email>yinjun.zhang@corigine.com</email>
</author>
<published>2021-03-30T08:30:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6aa7d2621b19da344ebcc56b2e00601c27272202'/>
<id>urn:sha1:6aa7d2621b19da344ebcc56b2e00601c27272202</id>
<content type='text'>
[ Upstream commit 2ea538dbee1c79f6f6c24a6f2f82986e4b7ccb78 ]

A merge hint message needs some time to process before the merged
flow actually reaches the firmware, during which we may get duplicate
merge hints if there're more than one packet that hit the pre-merged
flow. And processing duplicate merge hints will cost extra host_ctx's
which are a limited resource.

Avoid the duplicate merge by using hash table to store the sub_flows
to be merged.

Fixes: 8af56f40e53b ("nfp: flower: offload merge flows")
Signed-off-by: Yinjun Zhang &lt;yinjun.zhang@corigine.com&gt;
Signed-off-by: Louis Peens &lt;louis.peens@corigine.com&gt;
Signed-off-by: Simon Horman &lt;simon.horman@netronome.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cxgb4: avoid collecting SGE_QBASE regs during traffic</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Rahul Lakkireddy</name>
<email>rahul.lakkireddy@chelsio.com</email>
</author>
<published>2021-03-27T18:19:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=200c8453287f660d129222bff718e3d8da503fc4'/>
<id>urn:sha1:200c8453287f660d129222bff718e3d8da503fc4</id>
<content type='text'>
[ Upstream commit 1bfb3dea965ff9f6226fd1709338f227363b6061 ]

Accessing SGE_QBASE_MAP[0-3] and SGE_QBASE_INDEX registers can lead
to SGE missing doorbells under heavy traffic. So, only collect them
when adapter is idle. Also update the regdump range to skip collecting
these registers.

Fixes: 80a95a80d358 ("cxgb4: collect SGE PF/VF queue map")
Signed-off-by: Rahul Lakkireddy &lt;rahul.lakkireddy@chelsio.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gianfar: Handle error code at MAC address change</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@nxp.com</email>
</author>
<published>2021-03-29T14:08:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e9bdd3e45f0ecac310ba25bd977c2dbbfd63363d'/>
<id>urn:sha1:e9bdd3e45f0ecac310ba25bd977c2dbbfd63363d</id>
<content type='text'>
[ Upstream commit bff5b62585123823842833ab20b1c0a7fa437f8c ]

Handle return error code of eth_mac_addr();

Fixes: 3d23a05c75c7 ("gianfar: Enable changing mac addr when if up")
Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>amd-xgbe: Update DMA coherency values</title>
<updated>2021-04-14T06:24:14+00:00</updated>
<author>
<name>Shyam Sundar S K</name>
<email>Shyam-sundar.S-k@amd.com</email>
</author>
<published>2021-03-25T03:09:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=accb27006595cf4ce432f04b87f666f4284470e4'/>
<id>urn:sha1:accb27006595cf4ce432f04b87f666f4284470e4</id>
<content type='text'>
[ Upstream commit d75135082698140a26a56defe1bbc1b06f26a41f ]

Based on the IOMMU configuration, the current cache control settings can
result in possible coherency issues. The hardware team has recommended
new settings for the PCI device path to eliminate the issue.

Fixes: 6f595959c095 ("amd-xgbe: Adjust register settings to improve performance")
Signed-off-by: Shyam Sundar S K &lt;Shyam-sundar.S-k@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i40e: Fix kernel oops when i40e driver removes VF's</title>
<updated>2021-04-14T06:24:14+00:00</updated>
<author>
<name>Eryk Rybak</name>
<email>eryk.roch.rybak@intel.com</email>
</author>
<published>2021-02-18T11:15:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fec47d458add0fa14f37da023ea9aa35019a0998'/>
<id>urn:sha1:fec47d458add0fa14f37da023ea9aa35019a0998</id>
<content type='text'>
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]

Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch, it is possible to suspend the VFs reset by
releasing VFs resources procedure. Retrying the reset after the
timeout works on the freed VF memory causing a kernel oops.

Fixes: d43d60e5eb95 ("i40e: ensure reset occurs when disabling VF")
Signed-off-by: Eryk Rybak &lt;eryk.roch.rybak@intel.com&gt;
Signed-off-by: Grzegorz Szczurek &lt;grzegorzx.szczurek@intel.com&gt;
Reviewed-by: Aleksandr Loktionov &lt;aleksandr.loktionov@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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
