<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/ethernet/broadcom, branch linux-5.19.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.19.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.19.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-10-24T07:58:14Z</updated>
<entry>
<title>bnxt_en: replace reset with config timestamps</title>
<updated>2022-10-24T07:58:14Z</updated>
<author>
<name>Vadim Fedorenko</name>
</author>
<published>2022-09-22T19:10:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c72dad9a1d37302f09b12b8c6cca68bbd51ccae5'/>
<id>urn:sha1:c72dad9a1d37302f09b12b8c6cca68bbd51ccae5</id>
<content type='text'>
[ Upstream commit 8db3d514e96715c897fe793c4d5fc0fd86aca517 ]

Any change to the hardware timestamps configuration triggers nic restart,
which breaks transmition and reception of network packets for a while.
But there is no need to fully restart the device because while configuring
hardware timestamps. The code for changing configuration runs after all
of the initialisation, when the NIC is actually up and running. This patch
changes the code that ioctl will only update configuration registers and
will not trigger carrier status change, but in case of timestamps for
all rx packetes it fallbacks to close()/open() sequnce because of
synchronization issues in the hardware. Tested on BCM57504.

Cc: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: Vadim Fedorenko &lt;vfedorenko@novek.ru&gt;
Reviewed-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Link: https://lore.kernel.org/r/20220922191038.29921-1-vfedorenko@novek.ru
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnx2x: fix potential memory leak in bnx2x_tpa_stop()</title>
<updated>2022-10-24T07:57:16Z</updated>
<author>
<name>Jianglei Nie</name>
</author>
<published>2022-09-30T06:28:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=96c0c14135f5803f9e94e6da2ee9c4b012fdcb20'/>
<id>urn:sha1:96c0c14135f5803f9e94e6da2ee9c4b012fdcb20</id>
<content type='text'>
[ Upstream commit b43f9acbb8942b05252be83ac25a81cec70cc192 ]

bnx2x_tpa_stop() allocates a memory chunk from new_data with
bnx2x_frag_alloc(). The new_data should be freed when gets some error.
But when "pad + len &gt; fp-&gt;rx_buf_size" is true, bnx2x_tpa_stop() returns
without releasing the new_data, which will lead to a memory leak.

We should free the new_data with bnx2x_frag_free() when "pad + len &gt;
fp-&gt;rx_buf_size" is true.

Fixes: 07b0f00964def8af9321cfd6c4a7e84f6362f728 ("bnx2x: fix possible panic under memory stress")
Signed-off-by: Jianglei Nie &lt;niejianglei2021@163.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>bnxt: prevent skb UAF after handing over to PTP worker</title>
<updated>2022-09-28T09:32:21Z</updated>
<author>
<name>Jakub Kicinski</name>
</author>
<published>2022-09-21T20:10:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=32afa1f23e42cc635ccf4c39f24514d03d1e8338'/>
<id>urn:sha1:32afa1f23e42cc635ccf4c39f24514d03d1e8338</id>
<content type='text'>
[ Upstream commit c31f26c8f69f776759cbbdfb38e40ea91aa0dd65 ]

When reading the timestamp is required bnxt_tx_int() hands
over the ownership of the completed skb to the PTP worker.
The skb should not be used afterwards, as the worker may
run before the rest of our code and free the skb, leading
to a use-after-free.

Since dev_kfree_skb_any() accepts NULL make the loss of
ownership more obvious and set skb to NULL.

Fixes: 83bb623c968e ("bnxt_en: Transmit and retrieve packet timestamps")
Reviewed-by: Andy Gospodarek &lt;gospo@broadcom.com&gt;
Reviewed-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Link: https://lore.kernel.org/r/20220921201005.335390-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: fix flags to check for supported fw version</title>
<updated>2022-09-28T09:32:16Z</updated>
<author>
<name>Vadim Fedorenko</name>
</author>
<published>2022-09-15T23:49:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e969486525bea38de46383b88c2b1653398cc977'/>
<id>urn:sha1:e969486525bea38de46383b88c2b1653398cc977</id>
<content type='text'>
[ Upstream commit ae8ffba8baad651af706538e8c47d0a049d406c6 ]

The warning message of unsupported FW appears every time RX timestamps
are disabled on the interface. The patch fixes the flags to correct set
for the check.

Fixes: 66ed81dcedc6 ("bnxt_en: Enable packet timestamping for all RX packets")
Cc: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: Vadim Fedorenko &lt;vfedorenko@novek.ru&gt;
Reviewed-by: Andy Gospodarek &lt;gospo@broadcom.com&gt;
Reviewed-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Link: https://lore.kernel.org/r/20220915234932.25497-1-vfedorenko@novek.ru
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tg3: Disable tg3 device on system reboot to avoid triggering AER</title>
<updated>2022-09-20T10:43:47Z</updated>
<author>
<name>Kai-Heng Feng</name>
</author>
<published>2022-08-26T00:25:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=84d8959393a0d30d58688ca96b88760bdfd53943'/>
<id>urn:sha1:84d8959393a0d30d58688ca96b88760bdfd53943</id>
<content type='text'>
[ Upstream commit 2ca1c94ce0b65a2ce7512b718f3d8a0fe6224bca ]

Commit d60cd06331a3 ("PM: ACPI: reboot: Use S5 for reboot") caused a
reboot hang on one Dell servers so the commit was reverted.

Someone managed to collect the AER log and it's caused by MSI:
[ 148.762067] ACPI: Preparing to enter system sleep state S5
[ 148.794638] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5
[ 148.803731] {1}[Hardware Error]: event severity: recoverable
[ 148.810191] {1}[Hardware Error]: Error 0, type: fatal
[ 148.816088] {1}[Hardware Error]: section_type: PCIe error
[ 148.822391] {1}[Hardware Error]: port_type: 0, PCIe end point
[ 148.829026] {1}[Hardware Error]: version: 3.0
[ 148.834266] {1}[Hardware Error]: command: 0x0006, status: 0x0010
[ 148.841140] {1}[Hardware Error]: device_id: 0000:04:00.0
[ 148.847309] {1}[Hardware Error]: slot: 0
[ 148.852077] {1}[Hardware Error]: secondary_bus: 0x00
[ 148.857876] {1}[Hardware Error]: vendor_id: 0x14e4, device_id: 0x165f
[ 148.865145] {1}[Hardware Error]: class_code: 020000
[ 148.870845] {1}[Hardware Error]: aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00010000
[ 148.879842] {1}[Hardware Error]: aer_uncor_severity: 0x000ef030
[ 148.886575] {1}[Hardware Error]: TLP Header: 40000001 0000030f 90028090 00000000
[ 148.894823] tg3 0000:04:00.0: AER: aer_status: 0x00100000, aer_mask: 0x00010000
[ 148.902795] tg3 0000:04:00.0: AER: [20] UnsupReq (First)
[ 148.910234] tg3 0000:04:00.0: AER: aer_layer=Transaction Layer, aer_agent=Requester ID
[ 148.918806] tg3 0000:04:00.0: AER: aer_uncor_severity: 0x000ef030
[ 148.925558] tg3 0000:04:00.0: AER: TLP Header: 40000001 0000030f 90028090 00000000

The MSI is probably raised by incoming packets, so power down the device
and disable bus mastering to stop the traffic, as user confirmed this
approach works.

In addition to that, be extra safe and cancel reset task if it's running.

Cc: Josef Bacik &lt;josef@toxicpanda.com&gt;
Link: https://lore.kernel.org/all/b8db79e6857c41dab4ef08bdf826ea7c47e3bafc.1615947283.git.josef@toxicpanda.com/
BugLink: https://bugs.launchpad.net/bugs/1917471
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Reviewed-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Link: https://lore.kernel.org/r/20220826002530.1153296-1-kai.heng.feng@canonical.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: fix LRO/GRO_HW features in ndo_fix_features callback</title>
<updated>2022-08-31T15:18:06Z</updated>
<author>
<name>Vikas Gupta</name>
</author>
<published>2022-08-22T15:06:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c5101ebeb2edb19b8659030e56ec0ef3e80b7f3b'/>
<id>urn:sha1:c5101ebeb2edb19b8659030e56ec0ef3e80b7f3b</id>
<content type='text'>
[ Upstream commit 366c304741729e64d778c80555d9eb422cf5cc89 ]

LRO/GRO_HW should be disabled if there is an attached XDP program.
BNXT_FLAG_TPA is the current setting of the LRO/GRO_HW.  Using
BNXT_FLAG_TPA to disable LRO/GRO_HW will cause these features to be
permanently disabled once they are disabled.

Fixes: 1dc4c557bfed ("bnxt: adding bnxt_xdp_build_skb to build skb from multibuffer xdp_buff")
Signed-off-by: Vikas Gupta &lt;vikas.gupta@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.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>bnxt_en: fix NQ resource accounting during vf creation on 57500 chips</title>
<updated>2022-08-31T15:18:06Z</updated>
<author>
<name>Vikas Gupta</name>
</author>
<published>2022-08-22T15:06:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2ec3dc278d97a10879cf763644f90fdd1ddc159b'/>
<id>urn:sha1:2ec3dc278d97a10879cf763644f90fdd1ddc159b</id>
<content type='text'>
[ Upstream commit 09a89cc59ad67794a11e1d3dd13c5b3172adcc51 ]

There are 2 issues:

1. We should decrement hw_resc-&gt;max_nqs instead of hw_resc-&gt;max_irqs
   with the number of NQs assigned to the VFs.  The IRQs are fixed
   on each function and cannot be re-assigned.  Only the NQs are being
   assigned to the VFs.

2. vf_msix is the total number of NQs to be assigned to the VFs.  So
   we should decrement vf_msix from hw_resc-&gt;max_nqs.

Fixes: b16b68918674 ("bnxt_en: Add SR-IOV support for 57500 chips.")
Signed-off-by: Vikas Gupta &lt;vikas.gupta@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.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>bnxt_en: set missing reload flag in devlink features</title>
<updated>2022-08-31T15:18:06Z</updated>
<author>
<name>Vikas Gupta</name>
</author>
<published>2022-08-22T15:06:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=46195aec8631af94b8afc34fb1eadb09f02f2ec0'/>
<id>urn:sha1:46195aec8631af94b8afc34fb1eadb09f02f2ec0</id>
<content type='text'>
[ Upstream commit 574b2bb9692fd3d45ed631ac447176d4679f3010 ]

Add missing devlink_set_features() API for callbacks reload_down
and reload_up to function.

Fixes: 228ea8c187d8 ("bnxt_en: implement devlink dev reload driver_reinit")
Reviewed-by: Somnath Kotur &lt;somnath.kotur@broadcom.com&gt;
Signed-off-by: Vikas Gupta &lt;vikas.gupta@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.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>bnxt_en: Use PAGE_SIZE to init buffer when multi buffer XDP is not in use</title>
<updated>2022-08-31T15:18:06Z</updated>
<author>
<name>Pavan Chebbi</name>
</author>
<published>2022-08-22T15:06:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=51ca62d3274c710441cdfea37cfe5ac4296867c7'/>
<id>urn:sha1:51ca62d3274c710441cdfea37cfe5ac4296867c7</id>
<content type='text'>
[ Upstream commit 7dd3de7cb1d657a918c6b2bc673c71e318aa0c05 ]

Using BNXT_PAGE_MODE_BUF_SIZE + offset as buffer length value is not
sufficient when running single buffer XDP programs doing redirect
operations. The stack will complain on missing skb tail room. Fix it
by using PAGE_SIZE when calling xdp_init_buff() for single buffer
programs.

Fixes: b231c3f3414c ("bnxt: refactor bnxt_rx_xdp to separate xdp_init_buff/xdp_prepare_buff")
Reviewed-by: Somnath Kotur &lt;somnath.kotur@broadcom.com&gt;
Signed-off-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.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>net: bgmac: Fix a BUG triggered by wrong bytes_compl</title>
<updated>2022-08-25T09:45:16Z</updated>
<author>
<name>Sandor Bodo-Merle</name>
</author>
<published>2022-08-08T17:39:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=da1421a29d3b8681ba6a7f686bd0b40dda5acaf3'/>
<id>urn:sha1:da1421a29d3b8681ba6a7f686bd0b40dda5acaf3</id>
<content type='text'>
commit 1b7680c6c1f6de9904f1d9b05c952f0c64a03350 upstream.

On one of our machines we got:

kernel BUG at lib/dynamic_queue_limits.c:27!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G        W  O    4.14.275-rt132 #1
Hardware name: BRCM XGS iProc
task: ee3415c0 task.stack: ee32a000
PC is at dql_completed+0x168/0x178
LR is at bgmac_poll+0x18c/0x6d8
pc : [&lt;c03b9430&gt;]    lr : [&lt;c04b5a18&gt;]    psr: 800a0313
sp : ee32be14  ip : 000005ea  fp : 00000bd4
r10: ee558500  r9 : c0116298  r8 : 00000002
r7 : 00000000  r6 : ef128810  r5 : 01993267  r4 : 01993851
r3 : ee558000  r2 : 000070e1  r1 : 00000bd4  r0 : ee52c180
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 12c5387d  Table: 8e88c04a  DAC: 00000051
Process irq/41-bgmac (pid: 1166, stack limit = 0xee32a210)
Stack: (0xee32be14 to 0xee32c000)
be00:                                              ee558520 ee52c100 ef128810
be20: 00000000 00000002 c0116298 c04b5a18 00000000 c0a0c8c4 c0951780 00000040
be40: c0701780 ee558500 ee55d520 ef05b340 ef6f9780 ee558520 00000001 00000040
be60: ffffe000 c0a56878 ef6fa040 c0952040 0000012c c0528744 ef6f97b0 fffcfb6a
be80: c0a04104 2eda8000 c0a0c4ec c0a0d368 ee32bf44 c0153534 ee32be98 ee32be98
bea0: ee32bea0 ee32bea0 ee32bea8 ee32bea8 00000000 c01462e4 ffffe000 ef6f22a8
bec0: ffffe000 00000008 ee32bee4 c0147430 ffffe000 c094a2a8 00000003 ffffe000
bee0: c0a54528 00208040 0000000c c0a0c8c4 c0a65980 c0124d3c 00000008 ee558520
bf00: c094a23c c0a02080 00000000 c07a9910 ef136970 ef136970 ee30a440 ef136900
bf20: ee30a440 00000001 ef136900 ee30a440 c016d990 00000000 c0108db0 c012500c
bf40: ef136900 c016da14 ee30a464 ffffe000 00000001 c016dd14 00000000 c016db28
bf60: ffffe000 ee21a080 ee30a400 00000000 ee32a000 ee30a440 c016dbfc ee25fd70
bf80: ee21a09c c013edcc ee32a000 ee30a400 c013ec7c 00000000 00000000 00000000
bfa0: 00000000 00000000 00000000 c0108470 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[&lt;c03b9430&gt;] (dql_completed) from [&lt;c04b5a18&gt;] (bgmac_poll+0x18c/0x6d8)
[&lt;c04b5a18&gt;] (bgmac_poll) from [&lt;c0528744&gt;] (net_rx_action+0x1c4/0x494)
[&lt;c0528744&gt;] (net_rx_action) from [&lt;c0124d3c&gt;] (do_current_softirqs+0x1ec/0x43c)
[&lt;c0124d3c&gt;] (do_current_softirqs) from [&lt;c012500c&gt;] (__local_bh_enable+0x80/0x98)
[&lt;c012500c&gt;] (__local_bh_enable) from [&lt;c016da14&gt;] (irq_forced_thread_fn+0x84/0x98)
[&lt;c016da14&gt;] (irq_forced_thread_fn) from [&lt;c016dd14&gt;] (irq_thread+0x118/0x1c0)
[&lt;c016dd14&gt;] (irq_thread) from [&lt;c013edcc&gt;] (kthread+0x150/0x158)
[&lt;c013edcc&gt;] (kthread) from [&lt;c0108470&gt;] (ret_from_fork+0x14/0x24)
Code: a83f15e0 0200001a 0630a0e1 c3ffffea (f201f0e7)

The issue seems similar to commit 90b3b339364c ("net: hisilicon: Fix a BUG
trigered by wrong bytes_compl") and potentially introduced by commit
b38c83dd0866 ("bgmac: simplify tx ring index handling").

If there is an RX interrupt between setting ring-&gt;end
and netdev_sent_queue() we can hit the BUG_ON as bgmac_dma_tx_free()
can miscalculate the queue size while called from bgmac_poll().

The machine which triggered the BUG runs a v4.14 RT kernel - but the issue
seems present in mainline too.

Fixes: b38c83dd0866 ("bgmac: simplify tx ring index handling")
Signed-off-by: Sandor Bodo-Merle &lt;sbodomerle@gmail.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20220808173939.193804-1-sbodomerle@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
