<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet/broadcom, branch linux-7.1.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.1.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.1.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-10T00:52:46+00:00</updated>
<entry>
<title>bnxt_en: Fix NULL pointer dereference</title>
<updated>2026-06-10T00:52:46+00:00</updated>
<author>
<name>Kyle Meyer</name>
<email>kyle.meyer@hpe.com</email>
</author>
<published>2026-06-05T22:25:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d930276f2cddd0b7294cac7a8fe7b877f6d9e08d'/>
<id>urn:sha1:d930276f2cddd0b7294cac7a8fe7b877f6d9e08d</id>
<content type='text'>
PCIe errors detected by a Root Port or Downstream Port cause error
recovery services to run on all subordinate devices regardless of
administrative state.

The .error_detected() callback, bnxt_io_error_detected(), disables
and synchronizes IRQs via bnxt_disable_int_sync(), which calls
bnxt_cp_num_to_irq_num() to map completion rings to IRQs using
bp-&gt;bnapi.

Since bp-&gt;bnapi is allocated on NIC open and freed on NIC close, PCIe
error recovery on a closed NIC can dereference a NULL pointer.

Check if bp-&gt;bnapi is NULL before disabling and synchronizing IRQs.

Fixes: e5811b8c09df ("bnxt_en: Add IRQ remapping logic.")
Cc: stable@vger.kernel.org
Signed-off-by: Kyle Meyer &lt;kyle.meyer@hpe.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://patch.msgid.link/aiNM1CY2-StPilxW@hpe.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnge: fix context mem iteration</title>
<updated>2026-06-06T01:35:50+00:00</updated>
<author>
<name>Vikas Gupta</name>
<email>vikas.gupta@broadcom.com</email>
</author>
<published>2026-06-04T16:37:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3847d94783c0b893c27ff0b26a3325796d9444c6'/>
<id>urn:sha1:3847d94783c0b893c27ff0b26a3325796d9444c6</id>
<content type='text'>
The firmware advertises context memory (backing store) types
through a linked list, with BNGE_CTX_INV serving as the
end-of-list sentinel.
However, the driver incorrectly assumes that the list is strictly
ordered and prematurely terminates traversal when it encounters
an unrecognized type (&gt;=BNGE_CTX_V2_MAX). As a result, any valid
context types that appear later in the chain are silently skipped,
leading to incomplete memory configuration and eventual driver load
failure.

Fix this by traversing the entire list until the BNGE_CTX_INV sentinel
is reached, while safely ignoring only those context types that fall
outside the supported range.

Fixes: 29c5b358f385 ("bng_en: Add backing store support")
Signed-off-by: Vikas Gupta &lt;vikas.gupta@broadcom.com&gt;
Reviewed-by: Dharmender Garg &lt;dharmender.garg@broadcom.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>Reapply "bnxt_en: bring back rtnl_lock() in the bnxt_open() path"</title>
<updated>2026-06-04T16:02:37+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2026-06-03T19:58:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b6197b386677ae5268d4702e23849d9ad53051ad'/>
<id>urn:sha1:b6197b386677ae5268d4702e23849d9ad53051ad</id>
<content type='text'>
This reverts commit 850d9248d2eac662f869c766a598c877690c74e5.
This reapplies commit 325eb217e41f ("bnxt_en: bring back rtnl_lock()
in the bnxt_open() path").

Breno reports a lockdep warning in bnxt. During FW reset the driver
may end up calling netif_set_real_num_tx_queues() (if queue count
changes), so calls to bnxt_open() still require rtnl_lock.

  net/sched/sch_generic.c:1416 suspicious rcu_dereference_protected() usage!

   dev_qdisc_change_real_num_tx+0x54/0xe0
   netif_set_real_num_tx_queues+0x4ed/0xa80
   __bnxt_open_nic+0x9cb/0x3490
   bnxt_open+0x1cb/0x370
   bnxt_fw_reset_task+0x80d/0x1e80
   process_scheduled_works+0x9c1/0x13b0

The reverted commit was just an optimization / experiment
so let's go back to taking the lock.

Reported-by: Breno Leitao &lt;leitao@debian.org&gt;
Link: https://lore.kernel.org/ah726OtFX-Qw3U-R@gmail.com
Fixes: 850d9248d2ea ("Revert "bnxt_en: bring back rtnl_lock() in the bnxt_open() path"")
Acked-by: Stanislav Fomichev &lt;sdf@fomichev.me&gt;
Reviewed-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Reviewed-by: Breno Leitao &lt;leitao@debian.org&gt;
Link: https://patch.msgid.link/20260603195845.2574426-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: bcmgenet: keep RBUF EEE/PM disabled</title>
<updated>2026-05-21T15:37:56+00:00</updated>
<author>
<name>Nicolai Buchwitz</name>
<email>nb@tipi-net.de</email>
</author>
<published>2026-05-20T18:43:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a1730245e416d11ad5c0f2c100061d61cc43f60'/>
<id>urn:sha1:9a1730245e416d11ad5c0f2c100061d61cc43f60</id>
<content type='text'>
Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX
path on GENET hardware once MAC EEE becomes active. RX traffic stops
flowing while the link stays up and the usual descriptor/RX error
counters remain quiet. In that state the MAC still accepts frames
(rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to
DMA, so rx_packets is no longer incremented at the netdev level. On
some boards the corruption ends up as a paging fault in
skb_release_data via bcmgenet_rx_poll on an LPI exit.

Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian
Fainelli on an internal Broadcom 4908-family board with the same crash
signature. RBUF_PM_EN is not publicly documented.

This shows up more often now that phy_support_eee() enables EEE by
default, but it also affects older kernels as soon as TX LPI is
turned on via ethtool, so it is not specific to recent changes.

Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so
the bits stay off across resets. UMAC and TBUF setup is left alone so
TX-side EEE keeps working.

Link: https://github.com/raspberrypi/linux/issues/7304
Fixes: 6ef398ea60d9 ("net: bcmgenet: add EEE support")
Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Buchwitz &lt;nb@tipi-net.de&gt;
Reviewed-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Link: https://patch.msgid.link/20260520184320.652053-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Use absolute target ns from ptp_clock_request</title>
<updated>2026-05-06T00:36:15+00:00</updated>
<author>
<name>Pavan Chebbi</name>
<email>pavan.chebbi@broadcom.com</email>
</author>
<published>2026-05-04T08:36:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bd279e104e5f5400307d56116a36756b35ab345a'/>
<id>urn:sha1:bd279e104e5f5400307d56116a36756b35ab345a</id>
<content type='text'>
There is no need to calculate the target PHC cycles required
to make phase adjustment on the PPS OUT signal. This is because
the application supplies absolute n_sec value in the future and
is already the actual desired target value.

Remove the unnecessary code.

Fixes: 9e518f25802c ("bnxt_en: 1PPS functions to configure TSIO pins")
Reviewed-by: Kalesh AP &lt;kalesh-anakkur.purayil@broadcom.com&gt;
Cc: Richard Cochran &lt;richardcochran@gmail.com&gt;
Signed-off-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Reviewed-by: Vadim Fedorenko &lt;vadim.fedorenko@linux.dev&gt;
Tested-by: Vadim Fedorenko &lt;vadim.fedorenko@linux.dev&gt;
Link: https://patch.msgid.link/20260504083611.1383776-5-pavan.chebbi@broadcom.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Check return value of bnxt_hwrm_vnic_cfg</title>
<updated>2026-05-06T00:36:14+00:00</updated>
<author>
<name>Kalesh AP</name>
<email>kalesh-anakkur.purayil@broadcom.com</email>
</author>
<published>2026-05-04T08:36:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=16517bc98a56004274472cc9949194cb4d2ad0b7'/>
<id>urn:sha1:16517bc98a56004274472cc9949194cb4d2ad0b7</id>
<content type='text'>
When the bnxt RDMA driver is loaded, it calls bnxt_register_dev().
As part of this, driver sends HWRM_VNIC_CFG firmware command
to configure the VNIC to operate in dual VNIC mode. Currently
the driver ignores the result of this firmware command. The RDMA
driver must know the result since it affects its functioning.

Check return value of call to bnxt_hwrm_vnic_cfg() in
bnxt_register_dev() and return failure on error.

Fixes: a588e4580a7e ("bnxt_en: Add interface to support RDMA driver.")
Reviewed-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: Kalesh AP &lt;kalesh-anakkur.purayil@broadcom.com&gt;
Signed-off-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://patch.msgid.link/20260504083611.1383776-4-pavan.chebbi@broadcom.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Set bp-&gt;max_tpa according to what the FW supports</title>
<updated>2026-05-06T00:36:14+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2026-05-04T08:36:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54c28fab2fa5afd681c9c4b10f4f6da1efdd397a'/>
<id>urn:sha1:54c28fab2fa5afd681c9c4b10f4f6da1efdd397a</id>
<content type='text'>
Fix the logic to set bp-&gt;max_tpa no higher than what the FW supports.
On P5 chips, some older FW sets max_tpa very low so we override it to
prevent performance regressions with the older FW.

Fixes: 79632e9ba386 ("bnxt_en: Expand bnxt_tpa_info struct to support 57500 chips.")
Reviewed-by: Kalesh AP &lt;kalesh-anakkur.purayil@broadcom.com&gt;
Reviewed-by: Colin Winegarden &lt;colin.winegarden@broadcom.com&gt;
Reviewed-by: Rukhsana Ansari &lt;rukhsana.ansari@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://patch.msgid.link/20260504083611.1383776-3-pavan.chebbi@broadcom.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Delay for 5 seconds after AER DPC for all chips</title>
<updated>2026-05-06T00:36:14+00:00</updated>
<author>
<name>Michael Chan</name>
<email>michael.chan@broadcom.com</email>
</author>
<published>2026-05-04T08:36:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07f44433355f70fa97d4c44b4c0d2e86adc082fb'/>
<id>urn:sha1:07f44433355f70fa97d4c44b4c0d2e86adc082fb</id>
<content type='text'>
The FW on all chips is requiring a 5-second delay after Downstream
Port Containment (DPC) AER.  The previously added 900 msec delay was
not long enough in all cases because the chip's CRS (Configuration
Request Retry Status) mechanism is not always reliable.

Fixes: d5ab32e9b02d ("bnxt_en: Add delay to handle Downstream Port Containment (DPC) AER")
Reviewed-by: Kalesh AP &lt;kalesh-anakkur.purayil@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://patch.msgid.link/20260504083611.1383776-2-pavan.chebbi@broadcom.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'net-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2026-04-23T23:50:42+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-04-23T23:50:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e728258debd553c95d2e70f9cd97c9fde27c7130'/>
<id>urn:sha1:e728258debd553c95d2e70f9cd97c9fde27c7130</id>
<content type='text'>
Pull  networking fixes from Jakub Kicinski:
 "Including fixes from Netfilter.

  Steady stream of fixes. Last two weeks feel comparable to the two
  weeks before the merge window. Lots of AI-aided bug discovery. A newer
  big source is Sashiko/Gemini (Roman Gushchin's system), which points
  out issues in existing code during patch review (maybe 25% of fixes
  here likely originating from Sashiko). Nice thing is these are often
  fixed by the respective maintainers, not drive-bys.

  Current release - new code bugs:

   - kconfig: MDIO_PIC64HPSC should depend on ARCH_MICROCHIP

  Previous releases - regressions:

   - add async ndo_set_rx_mode and switch drivers which we promised to
     be called under the per-netdev mutex to it

   - dsa: remove duplicate netdev_lock_ops() for conduit ethtool ops

   - hv_sock: report EOF instead of -EIO for FIN

   - vsock/virtio: fix MSG_PEEK calculation on bytes to copy

  Previous releases - always broken:

   - ipv6: fix possible UAF in icmpv6_rcv()

   - icmp: validate reply type before using icmp_pointers

   - af_unix: drop all SCM attributes for SOCKMAP

   - netfilter: fix a number of bugs in the osf (OS fingerprinting)

   - eth: intel: fix timestamp interrupt configuration for E825C

  Misc:

   - bunch of data-race annotations"

* tag 'net-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (148 commits)
  rxrpc: Fix error handling in rxgk_extract_token()
  rxrpc: Fix re-decryption of RESPONSE packets
  rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets
  rxrpc: Fix missing validation of ticket length in non-XDR key preparsing
  rxgk: Fix potential integer overflow in length check
  rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
  rxrpc: Fix potential UAF after skb_unshare() failure
  rxrpc: Fix rxkad crypto unalignment handling
  rxrpc: Fix memory leaks in rxkad_verify_response()
  net: rds: fix MR cleanup on copy error
  m68k: mvme147: Make me the maintainer
  net: txgbe: fix firmware version check
  selftests/bpf: check epoll readiness during reuseport migration
  tcp: call sk_data_ready() after listener migration
  vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll()
  ipv6: Cap TLV scan in ip6_tnl_parse_tlv_enc_lim
  tipc: fix double-free in tipc_buf_append()
  llc: Return -EINPROGRESS from llc_ui_connect()
  ipv4: icmp: validate reply type before using icmp_pointers
  selftests/net: packetdrill: cover RFC 5961 5.2 challenge ACK on both edges
  ...
</content>
</entry>
<entry>
<title>bnge: remove unsupported backing store type</title>
<updated>2026-04-23T03:30:46+00:00</updated>
<author>
<name>Vikas Gupta</name>
<email>vikas.gupta@broadcom.com</email>
</author>
<published>2026-04-18T02:34:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c6b34add67a5402f53359580956b5c318965a893'/>
<id>urn:sha1:c6b34add67a5402f53359580956b5c318965a893</id>
<content type='text'>
The backing store type, BNGE_CTX_MRAV, is not applicable in Thor Ultra
devices. Remove it from the backing store configuration, as the firmware
will not populate entities in this backing store type, due to which the
driver load fails.

Fixes: 29c5b358f385 ("bng_en: Add backing store support")
Signed-off-by: Vikas Gupta &lt;vikas.gupta@broadcom.com&gt;
Reviewed-by: Dharmender Garg &lt;dharmender.garg@broadcom.com&gt;
Link: https://patch.msgid.link/20260418023438.1597876-3-vikas.gupta@broadcom.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
</feed>
