<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/ethernet/broadcom, branch linux-6.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.3.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.3.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2023-06-14T09:16:52Z</updated>
<entry>
<title>bnxt_en: Implement .set_port / .unset_port UDP tunnel callbacks</title>
<updated>2023-06-14T09:16:52Z</updated>
<author>
<name>Somnath Kotur</name>
</author>
<published>2023-06-07T07:54:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=11c6580cc31538bf202f7646523d3089f0cb9275'/>
<id>urn:sha1:11c6580cc31538bf202f7646523d3089f0cb9275</id>
<content type='text'>
[ Upstream commit 1eb4ef12591348c440ac9d6efcf7521e73cf2b10 ]

As per the new udp tunnel framework, drivers which need to know the
details of a port entry (i.e. port type) when it gets deleted should
use the .set_port / .unset_port callbacks.

Implementing the current .udp_tunnel_sync callback would mean that the
deleted tunnel port entry would be all zeros.  This used to work on
older firmware because it would not check the input when deleting a
tunnel port.  With newer firmware, the delete will now fail and
subsequent tunnel port allocation will fail as a result.

Fixes: 442a35a5a7aa ("bnxt: convert to new udp_tunnel_nic infra")
Reviewed-by: Kalesh Anakkur Purayil &lt;kalesh-anakkur.purayil@broadcom.com&gt;
Signed-off-by: Somnath Kotur &lt;somnath.kotur@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Prevent kernel panic when receiving unexpected PHC_UPDATE event</title>
<updated>2023-06-14T09:16:52Z</updated>
<author>
<name>Pavan Chebbi</name>
</author>
<published>2023-06-07T07:54:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=637fa17e6efabd0092e870dca38545ea47660cee'/>
<id>urn:sha1:637fa17e6efabd0092e870dca38545ea47660cee</id>
<content type='text'>
[ Upstream commit 319a7827df9784048abe072afe6b4fb4501d8de4 ]

The firmware can send PHC_RTC_UPDATE async event on a PF that may not
have PTP registered. In such a case, there will be a null pointer
deference for bp-&gt;ptp_cfg when we try to handle the event.

Fix it by not registering for this event with the firmware if !bp-&gt;ptp_cfg.
Also, check that bp-&gt;ptp_cfg is valid before proceeding when we receive
the event.

Fixes: 8bcf6f04d4a5 ("bnxt_en: Handle async event when the PHC is updated in RTC mode")
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: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Skip firmware fatal error recovery if chip is not accessible</title>
<updated>2023-06-14T09:16:52Z</updated>
<author>
<name>Vikas Gupta</name>
</author>
<published>2023-06-07T07:54:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b41a23551ed8d688ec9fcc54758e476fe925cc9e'/>
<id>urn:sha1:b41a23551ed8d688ec9fcc54758e476fe925cc9e</id>
<content type='text'>
[ Upstream commit 83474a9b252ab23e6003865c2775024344cb9c09 ]

Driver starts firmware fatal error recovery by detecting
heartbeat failure or fw reset count register changing.  But
these checks are not reliable if the device is not accessible.
This can happen while DPC (Downstream Port containment) is in
progress.  Skip firmware fatal recovery if pci_device_is_present()
returns false.

Fixes: acfb50e4e773 ("bnxt_en: Add FW fatal devlink_health_reporter.")
Reviewed-by: Somnath Kotur &lt;somnath.kotur@broadcom.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@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: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Query default VLAN before VNIC setup on a VF</title>
<updated>2023-06-14T09:16:52Z</updated>
<author>
<name>Somnath Kotur</name>
</author>
<published>2023-06-07T07:54:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0d4a88949a32dc03acb25684daba5e784fd27cc0'/>
<id>urn:sha1:0d4a88949a32dc03acb25684daba5e784fd27cc0</id>
<content type='text'>
[ Upstream commit 1a9e4f501bc6ff1b6ecb60df54fbf2b54db43bfe ]

We need to call bnxt_hwrm_func_qcfg() on a VF to query the default
VLAN that may be setup by the PF.  If a default VLAN is enabled,
the VF cannot support VLAN acceleration on the receive side and
the VNIC must be setup to strip out the default VLAN tag.  If a
default VLAN is not enabled, the VF can support VLAN acceleration
on the receive side.  The VNIC should be set up to strip or not
strip the VLAN based on the RX VLAN acceleration setting.

Without this call to determine the default VLAN before calling
bnxt_setup_vnic(), the VNIC may not be set up correctly.  For
example, bnxt_setup_vnic() may set up to strip the VLAN tag based
on stale default VLAN information.  If RX VLAN acceleration is
not enabled, the VLAN tag will be incorrectly stripped and the
RX data path will not work correctly.

Fixes: cf6645f8ebc6 ("bnxt_en: Add function for VF driver to query default VLAN.")
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Signed-off-by: Somnath Kotur &lt;somnath.kotur@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Don't issue AP reset during ethtool's reset operation</title>
<updated>2023-06-14T09:16:52Z</updated>
<author>
<name>Sreekanth Reddy</name>
</author>
<published>2023-06-07T07:54:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=55dd3c2db8805014f0b9a6a464a2cdda73a6d7b1'/>
<id>urn:sha1:55dd3c2db8805014f0b9a6a464a2cdda73a6d7b1</id>
<content type='text'>
[ Upstream commit 1d997801c7cc6a7f542e46d5a6bf16f893ad3fe9 ]

Only older NIC controller's firmware uses the PROC AP reset type.
Firmware on 5731X/5741X and newer chips does not support this reset
type.  When bnxt_reset() issues a series of resets, this PROC AP
reset may actually fail on these newer chips because the firmware
is not ready to accept this unsupported command yet.  Avoid this
unnecessary error by skipping this reset type on chips that don't
support it.

Fixes: 7a13240e3718 ("bnxt_en: fix ethtool_reset_flags ABI violations")
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Signed-off-by: Sreekanth Reddy &lt;sreekanth.reddy@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Fix bnxt_hwrm_update_rss_hash_cfg()</title>
<updated>2023-06-14T09:16:51Z</updated>
<author>
<name>Pavan Chebbi</name>
</author>
<published>2023-06-07T07:54:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7965d918047f39b130e01691c1d870661b58d011'/>
<id>urn:sha1:7965d918047f39b130e01691c1d870661b58d011</id>
<content type='text'>
[ Upstream commit 095d5dc0c1d9f3284e3c575ccf4c0e8b04b548f8 ]

We must specify the vnic id of the vnic in the input structure of this
firmware message.  Otherwise we will get an error from the firmware.

Fixes: 98a4322b70e8 ("bnxt_en: update RSS config using difference algorithm")
Reviewed-by: Kalesh Anakkur Purayil &lt;kalesh-anakkur.purayil@broadcom.com&gt;
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: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: bcmgenet: Fix EEE implementation</title>
<updated>2023-06-14T09:16:51Z</updated>
<author>
<name>Florian Fainelli</name>
</author>
<published>2023-06-06T21:43:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cb459a104b8c3a23242668d99863cf52f7686337'/>
<id>urn:sha1:cb459a104b8c3a23242668d99863cf52f7686337</id>
<content type='text'>
[ Upstream commit a9f31047baca57d47440c879cf259b86f900260c ]

We had a number of short comings:

- EEE must be re-evaluated whenever the state machine detects a link
  change as wight be switching from a link partner with EEE
  enabled/disabled

- tx_lpi_enabled controls whether EEE should be enabled/disabled for the
  transmit path, which applies to the TBUF block

- We do not need to forcibly enable EEE upon system resume, as the PHY
  state machine will trigger a link event that will do that, too

Fixes: 6ef398ea60d9 ("net: bcmgenet: add EEE support")
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Reviewed-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Link: https://lore.kernel.org/r/20230606214348.2408018-1-florian.fainelli@broadcom.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>net: bcmgenet: Restore phy_stop() depending upon suspend/close</title>
<updated>2023-05-24T16:30:17Z</updated>
<author>
<name>Florian Fainelli</name>
</author>
<published>2023-05-15T02:56:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1e4b5e722ba5a358d6964de16fec455229aaf360'/>
<id>urn:sha1:1e4b5e722ba5a358d6964de16fec455229aaf360</id>
<content type='text'>
[ Upstream commit 225c657945c4a6307741cb3cc89467eadcc26e9b ]

Removing the phy_stop() from bcmgenet_netif_stop() ended up causing
warnings from the PHY library that phy_start() is called from the
RUNNING state since we are no longer stopping the PHY state machine
during bcmgenet_suspend().

Restore the call to phy_stop() but make it conditional on being called
from the close or suspend path.

Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine")
Fixes: 93e0401e0fc0 ("net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://lore.kernel.org/r/20230515025608.2587012-1-f.fainelli@gmail.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: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()</title>
<updated>2023-05-24T16:30:17Z</updated>
<author>
<name>Florian Fainelli</name>
</author>
<published>2023-05-04T23:07:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=970ea2284d32292572ea2c3f68c3089656088043'/>
<id>urn:sha1:970ea2284d32292572ea2c3f68c3089656088043</id>
<content type='text'>
[ Upstream commit 93e0401e0fc0c54b0ac05b687cd135c2ac38187c ]

The call to phy_stop() races with the later call to phy_disconnect(),
resulting in concurrent phy_suspend() calls being run from different
CPUs. The final call to phy_disconnect() ensures that the PHY is
stopped and suspended, too.

Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Stable-dep-of: 225c657945c4 ("net: bcmgenet: Restore phy_stop() depending upon suspend/close")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt: avoid overflow in bnxt_get_nvram_directory()</title>
<updated>2023-05-24T16:30:05Z</updated>
<author>
<name>Maxim Korotkov</name>
</author>
<published>2023-03-09T17:43:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=17e0453a7523ad7a25bb47af941b150a6c66d7b6'/>
<id>urn:sha1:17e0453a7523ad7a25bb47af941b150a6c66d7b6</id>
<content type='text'>
[ Upstream commit 7c6dddc239abe660598c49ec95ea0ed6399a4b2a ]

The value of an arithmetic expression is subject
of possible overflow due to a failure to cast operands to a larger data
type before performing arithmetic. Used macro for multiplication instead
operator for avoiding overflow.

Found by Security Code and Linux Verification
Center (linuxtesting.org) with SVACE.

Signed-off-by: Maxim Korotkov &lt;korotkov.maxim.s@gmail.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://lore.kernel.org/r/20230309174347.3515-1-korotkov.maxim.s@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
