<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/net/ethernet, branch dev-5.7</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.7</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.7'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2020-08-04T07:58:36+00:00</updated>
<entry>
<title>Merge tag 'v5.7.12' into dev-5.7</title>
<updated>2020-08-04T07:58:36+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2020-08-04T07:58:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9524588381df213554a10d3661a9200a4b7f6db2'/>
<id>urn:sha1:9524588381df213554a10d3661a9200a4b7f6db2</id>
<content type='text'>
This is the 5.7.12 stable release

Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>enetc: Remove the mdio bus on PF probe bailout</title>
<updated>2020-07-29T08:19:47+00:00</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@nxp.com</email>
</author>
<published>2020-07-22T14:40:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f0654ffe11889137ff857026e0d0e12e90953c61'/>
<id>urn:sha1:f0654ffe11889137ff857026e0d0e12e90953c61</id>
<content type='text'>
[ Upstream commit 26cb7085c8984e5b71d65c374a135134ed8cabb3 ]

For ENETC ports that register an external MDIO bus,
the bus doesn't get removed on the error bailout path
of enetc_pf_probe().

This issue became much more visible after recent:
commit 07095c025ac2 ("net: enetc: Use DT protocol information to set up the ports")
Before this commit, one could make probing fail on the error
path only by having register_netdev() fail, which is unlikely.
But after this commit, because it moved the enetc_of_phy_get()
call up in the probing sequence, now we can trigger an mdiobus_free()
bug just by forcing enetc_alloc_msix() to return error, i.e. with the
'pci=nomsi' kernel bootarg (since ENETC relies on MSI support to work),
as the calltrace below shows:

kernel BUG at /home/eiz/work/enetc/net/drivers/net/phy/mdio_bus.c:648!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[...]
Hardware name: LS1028A RDB Board (DT)
pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--)
pc : mdiobus_free+0x50/0x58
lr : devm_mdiobus_free+0x14/0x20
[...]
Call trace:
 mdiobus_free+0x50/0x58
 devm_mdiobus_free+0x14/0x20
 release_nodes+0x138/0x228
 devres_release_all+0x38/0x60
 really_probe+0x1c8/0x368
 driver_probe_device+0x5c/0xc0
 device_driver_attach+0x74/0x80
 __driver_attach+0x8c/0xd8
 bus_for_each_dev+0x7c/0xd8
 driver_attach+0x24/0x30
 bus_add_driver+0x154/0x200
 driver_register+0x64/0x120
 __pci_register_driver+0x44/0x50
 enetc_pf_driver_init+0x24/0x30
 do_one_initcall+0x60/0x1c0
 kernel_init_freeable+0x1fc/0x274
 kernel_init+0x14/0x110
 ret_from_fork+0x10/0x34

Fixes: ebfcb23d62ab ("enetc: Add ENETC PF level external MDIO support")
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>net: ethernet: ave: Fix error returns in ave_init</title>
<updated>2020-07-29T08:19:47+00:00</updated>
<author>
<name>Wang Hai</name>
<email>wanghai38@huawei.com</email>
</author>
<published>2020-07-17T02:50:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=99002ddeed7755f1788824a846815281ab11831e'/>
<id>urn:sha1:99002ddeed7755f1788824a846815281ab11831e</id>
<content type='text'>
[ Upstream commit 1264d7fa3a64d8bea7aebb77253f917947ffda25 ]

When regmap_update_bits failed in ave_init(), calls of the functions
reset_control_assert() and clk_disable_unprepare() were missed.
Add goto out_reset_assert to do this.

Fixes: 57878f2f4697 ("net: ethernet: ave: add support for phy-mode setting of system controller")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Wang Hai &lt;wanghai38@huawei.com&gt;
Reviewed-by: Kunihiko Hayashi &lt;hayashi.kunihiko@socionext.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>qed: suppress false-positives interrupt error messages on HW init</title>
<updated>2020-07-29T08:19:46+00:00</updated>
<author>
<name>Alexander Lobakin</name>
<email>alobakin@marvell.com</email>
</author>
<published>2020-07-21T14:41:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=03d5aa4017616fd22651f0d9a40eac300ec0e782'/>
<id>urn:sha1:03d5aa4017616fd22651f0d9a40eac300ec0e782</id>
<content type='text'>
[ Upstream commit eb61c2d69903e977ffa2b80b1da9d1f758cf228d ]

It was found that qed_pglueb_rbc_attn_handler() can produce a lot of
false-positive error detections on driver load/reload (especially after
crashes/recoveries) and spam the kernel log:

[    4.958275] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d00ff0
[ 2079.146764] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0
[ 2116.374631] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0
[ 2135.250564] [qed_pglueb_rbc_attn_handler:324()]ICPL error - 00d80ff0
[...]

Reduce the logging level of two false-positive prone error messages from
notice to verbose on initialization (only) to not mix it with real error
attentions while debugging.

Fixes: 666db4862f2d ("qed: Revise load sequence to avoid PCI errors")
Signed-off-by: Alexander Lobakin &lt;alobakin@marvell.com&gt;
Signed-off-by: Igor Russkikh &lt;irusskikh@marvell.com&gt;
Signed-off-by: Michal Kalderon &lt;michal.kalderon@marvell.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>qed: suppress "don't support RoCE &amp; iWARP" flooding on HW init</title>
<updated>2020-07-29T08:19:46+00:00</updated>
<author>
<name>Alexander Lobakin</name>
<email>alobakin@marvell.com</email>
</author>
<published>2020-07-21T14:41:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=86b411838f1ae233ac2d703a54ce1b94bab8209e'/>
<id>urn:sha1:86b411838f1ae233ac2d703a54ce1b94bab8209e</id>
<content type='text'>
[ Upstream commit 1ea999039fe7c7953da2fbb7ca7c3ef00064d328 ]

Change the verbosity of the "don't support RoCE &amp; iWARP simultaneously"
warning to debug level to stop flooding on driver/hardware initialization:

[    4.783230] qede 01:00.00: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth0]
[    4.810020] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE &amp; iWARP simultaneously on the same PF. Default to RoCE-only
[    4.861186] qede 01:00.01: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth1]
[    4.893311] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE &amp; iWARP simultaneously on the same PF. Default to RoCE-only
[    5.181713] qede a1:00.00: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth2]
[    5.224740] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE &amp; iWARP simultaneously on the same PF. Default to RoCE-only
[    5.276449] qede a1:00.01: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth3]
[    5.318671] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE &amp; iWARP simultaneously on the same PF. Default to RoCE-only
[    5.369548] qede a1:00.02: Storm FW 8.37.7.0, Management FW 8.52.9.0
[MBI 15.10.6] [eth4]
[    5.411645] [qed_rdma_set_pf_params:2076()]Current day drivers don't
support RoCE &amp; iWARP simultaneously on the same PF. Default to RoCE-only

Fixes: e0a8f9de16fc ("qed: Add iWARP enablement support")
Signed-off-by: Alexander Lobakin &lt;alobakin@marvell.com&gt;
Signed-off-by: Igor Russkikh &lt;irusskikh@marvell.com&gt;
Signed-off-by: Michal Kalderon &lt;michal.kalderon@marvell.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: hns3: fix return value error when query MAC link status fail</title>
<updated>2020-07-29T08:19:46+00:00</updated>
<author>
<name>Jian Shen</name>
<email>shenjian15@huawei.com</email>
</author>
<published>2020-07-21T11:03:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2e6940ea402c8d8529b9a3be1c0c42e39d8f66c3'/>
<id>urn:sha1:2e6940ea402c8d8529b9a3be1c0c42e39d8f66c3</id>
<content type='text'>
[ Upstream commit fac24df7b9a6d9363abdff0e351ade041dd16daa ]

Currently, PF queries the MAC link status per second by calling
function hclge_get_mac_link_status(). It return the error code
when failed to send cmdq command to firmware. It's incorrect,
because this return value is used as the MAC link status, which
0 means link down, and none-zero means link up. So fixes it.

Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine &amp; Compatibility Layer Support")
Signed-off-by: Jian Shen &lt;shenjian15@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: hns3: fix error handling for desc filling</title>
<updated>2020-07-29T08:19:45+00:00</updated>
<author>
<name>Yunsheng Lin</name>
<email>linyunsheng@huawei.com</email>
</author>
<published>2020-07-21T11:03:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3c237fa1a5b4fef7b5fe100d3356f79d13b77b00'/>
<id>urn:sha1:3c237fa1a5b4fef7b5fe100d3356f79d13b77b00</id>
<content type='text'>
[ Upstream commit 8ceca59fb3ed48a693171bd571c4fcbd555b7f1f ]

The content of the TX desc is automatically cleared by the HW
when the HW has sent out the packet to the wire. When desc filling
fails in hns3_nic_net_xmit(), it will call hns3_clear_desc() to do
the error handling, which miss zeroing of the TX desc and the
checking if a unmapping is needed.

So add the zeroing and checking in hns3_clear_desc() to avoid the
above problem. Also add DESC_TYPE_UNKNOWN to indicate the info in
desc_cb is not valid, because hns3_nic_reclaim_desc() may treat
the desc_cb-&gt;type of zero as packet and add to the sent pkt
statistics accordingly.

Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Yunsheng Lin &lt;linyunsheng@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: hns3: fix for not calculating TX BD send size correctly</title>
<updated>2020-07-29T08:19:45+00:00</updated>
<author>
<name>Yunsheng Lin</name>
<email>linyunsheng@huawei.com</email>
</author>
<published>2020-07-21T11:03:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9d121fc033a18513d4113cc23e835d5bac264a0a'/>
<id>urn:sha1:9d121fc033a18513d4113cc23e835d5bac264a0a</id>
<content type='text'>
[ Upstream commit 48ae74c9d89f827b39b5c07a1f02fc13637a3cd6 ]

With GRO and fraglist support, the SKB can be aggregated to
a total size of 65535, and when that SKB is forwarded through
a bridge, the size of the SKB may be pushed to exceed the size
of 65535 when br_dev_queue_push_xmit() is called.

The max send size of BD supported by the HW is 65535, when a SKB
with a headlen of over 65535 is sent to the driver, the driver
needs to use multi BD to send the linear data, and the send size
of the last BD is calculated incorrectly by the driver who is
using '&amp;' operation, which causes a TX error.

Use '%' operation to fix this problem.

Fixes: 3fe13ed95dd3 ("net: hns3: avoid mult + div op in critical data path")
Signed-off-by: Yunsheng Lin &lt;linyunsheng@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: ag71xx: add missed clk_disable_unprepare in error path of probe</title>
<updated>2020-07-29T08:19:45+00:00</updated>
<author>
<name>Huang Guobin</name>
<email>huangguobin4@huawei.com</email>
</author>
<published>2020-07-20T01:46:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=80016f31549d393aa5d2fd7ceacfcf15af7ca8b5'/>
<id>urn:sha1:80016f31549d393aa5d2fd7ceacfcf15af7ca8b5</id>
<content type='text'>
[ Upstream commit befc113c56a76ae7be3986034a0e476d3385e265 ]

The ag71xx_mdio_probe() forgets to call clk_disable_unprepare() when
of_reset_control_get_exclusive() failed. Add the missed call to fix it.

Fixes: d51b6ce441d3 ("net: ethernet: add ag71xx driver")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Huang Guobin &lt;huangguobin4@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>ionic: use mutex to protect queue operations</title>
<updated>2020-07-29T08:19:45+00:00</updated>
<author>
<name>Shannon Nelson</name>
<email>snelson@pensando.io</email>
</author>
<published>2020-07-20T23:00:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=79a7ab49b1c80939d89c21e3b738642834356118'/>
<id>urn:sha1:79a7ab49b1c80939d89c21e3b738642834356118</id>
<content type='text'>
[ Upstream commit 0925e9db4dc86daf666d9a3d53c7db14ac6d5d00 ]

The ionic_wait_on_bit_lock() was a open-coded mutex knock-off
used only for protecting the queue reset operations, and there
was no reason not to use the real thing.  We can use the lock
more correctly and to better protect the queue stop and start
operations from cross threading.  We can also remove a useless
and expensive bit operation from the Rx path.

This fixes a case found where the link_status_check from a link
flap could run into an MTU change and cause a crash.

Fixes: beead698b173 ("ionic: Add the basic NDO callbacks for netdev support")
Signed-off-by: Shannon Nelson &lt;snelson@pensando.io&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
