<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/ethernet/broadcom, branch linux-5.16.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-04-13T18:03:15Z</updated>
<entry>
<title>bnxt_en: Prevent XDP redirect from running when stopping TX queue</title>
<updated>2022-04-13T18:03:15Z</updated>
<author>
<name>Ray Jui</name>
</author>
<published>2022-04-02T00:21:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e89de1cd85b660c34ec66993b2022081773db32b'/>
<id>urn:sha1:e89de1cd85b660c34ec66993b2022081773db32b</id>
<content type='text'>
[ Upstream commit 27d4073f8d9af0340362554414f4961643a4f4de ]

Add checks in the XDP redirect callback to prevent XDP from running when
the TX ring is undergoing shutdown.

Also remove redundant checks in the XDP redirect callback to validate the
txr and the flag that indicates the ring supports XDP. The modulo
arithmetic on 'tx_nr_rings_xdp' already guarantees the derived TX
ring is an XDP ring.  txr is also guaranteed to be valid after checking
BNXT_STATE_OPEN and within RCU grace period.

Fixes: f18c2b77b2e4 ("bnxt_en: optimized XDP_REDIRECT support")
Reviewed-by: Vladimir Olovyannikov &lt;vladimir.olovyannikov@broadcom.com&gt;
Signed-off-by: Ray Jui &lt;ray.jui@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.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_en: reserve space inside receive page for skb_shared_info</title>
<updated>2022-04-13T18:03:15Z</updated>
<author>
<name>Andy Gospodarek</name>
</author>
<published>2022-04-02T00:21:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1d3475b8c0e0f9c6d862137122b8a6379c04132c'/>
<id>urn:sha1:1d3475b8c0e0f9c6d862137122b8a6379c04132c</id>
<content type='text'>
[ Upstream commit facc173cf700e55b2ad249ecbd3a7537f7315691 ]

Insufficient space was being reserved in the page used for packet
reception, so the interface MTU could be set too large to still have
room for the contents of the packet when doing XDP redirect.  This
resulted in the following message when redirecting a packet between
3520 and 3822 bytes with an MTU of 3822:

[311815.561880] XDP_WARN: xdp_update_frame_from_buff(line:200): Driver BUG: missing reserved tailroom

Fixes: f18c2b77b2e4 ("bnxt_en: optimized XDP_REDIRECT support")
Reviewed-by: Somnath Kotur &lt;somnath.kotur@broadcom.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Signed-off-by: Andy Gospodarek &lt;gospo@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.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_en: Synchronize tx when xdp redirects happen on same ring</title>
<updated>2022-04-13T18:03:14Z</updated>
<author>
<name>Pavan Chebbi</name>
</author>
<published>2022-04-02T00:21:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7d763170ae9034a69a194b50d7754162c03a8ad8'/>
<id>urn:sha1:7d763170ae9034a69a194b50d7754162c03a8ad8</id>
<content type='text'>
[ Upstream commit 4f81def272de17dc4bbd89ac38f49b2676c9b3d2 ]

If there are more CPUs than the number of TX XDP rings, multiple XDP
redirects can select the same TX ring based on the CPU on which
XDP redirect is called.  Add locking when needed and use static
key to decide whether to take the lock.

Fixes: f18c2b77b2e4 ("bnxt_en: optimized XDP_REDIRECT support")
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: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Eliminate unintended link toggle during FW reset</title>
<updated>2022-04-13T18:03:05Z</updated>
<author>
<name>Michael Chan</name>
</author>
<published>2022-03-05T08:54:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0aceee15b7331e3f52fb4c6bc2166e7719e481e3'/>
<id>urn:sha1:0aceee15b7331e3f52fb4c6bc2166e7719e481e3</id>
<content type='text'>
[ Upstream commit 7c492a2530c1f05441da541307c2534230dfd59b ]

If the flow control settings have been changed, a subsequent FW reset
may cause the ethernet link to toggle unnecessarily.  This link toggle
will increase the down time by a few seconds.

The problem is caused by bnxt_update_phy_setting() detecting a false
mismatch in the flow control settings between the stored software
settings and the current FW settings after the FW reset.  This mismatch
is caused by the AUTONEG bit added to link_info-&gt;req_flow_ctrl in an
inconsistent way in bnxt_set_pauseparam() in autoneg mode.  The AUTONEG
bit should not be added to link_info-&gt;req_flow_ctrl.

Reviewed-by: Colin Winegarden &lt;colin.winegarden@broadcom.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Signed-off-by: Michael Chan &lt;michael.chan@broadcom.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: bcmgenet: Use stronger register read/writes to assure ordering</title>
<updated>2022-04-08T12:06:19Z</updated>
<author>
<name>Jeremy Linton</name>
</author>
<published>2022-03-10T04:53:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1d717816189fd68f9e089cf89ed1f7327d2c2e71'/>
<id>urn:sha1:1d717816189fd68f9e089cf89ed1f7327d2c2e71</id>
<content type='text'>
[ Upstream commit 8d3ea3d402db94b61075617e71b67459a714a502 ]

GCC12 appears to be much smarter about its dependency tracking and is
aware that the relaxed variants are just normal loads and stores and
this is causing problems like:

[  210.074549] ------------[ cut here ]------------
[  210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out
[  210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240
[  210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat]
[  210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110
[  210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G            E     5.17.0-rc7G12+ #58
[  210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters
[  210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022
[  210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  210.161358] pc : dev_watchdog+0x234/0x240
[  210.161364] lr : dev_watchdog+0x234/0x240
[  210.161368] sp : ffff8000080a3a40
[  210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20
[  210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08
[  210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000
[  210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff
[  210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a
[  210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0
[  210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c
[  210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000
[  210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000
[  210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044
[  210.269682] Call trace:
[  210.272133]  dev_watchdog+0x234/0x240
[  210.275811]  call_timer_fn+0x3c/0x15c
[  210.279489]  __run_timers.part.0+0x288/0x310
[  210.283777]  run_timer_softirq+0x48/0x80
[  210.287716]  __do_softirq+0x128/0x360
[  210.291392]  __irq_exit_rcu+0x138/0x140
[  210.295243]  irq_exit_rcu+0x1c/0x30
[  210.298745]  el1_interrupt+0x38/0x54
[  210.302334]  el1h_64_irq_handler+0x18/0x24
[  210.306445]  el1h_64_irq+0x7c/0x80
[  210.309857]  arch_cpu_idle+0x18/0x2c
[  210.313445]  default_idle_call+0x4c/0x140
[  210.317470]  cpuidle_idle_call+0x14c/0x1a0
[  210.321584]  do_idle+0xb0/0x100
[  210.324737]  cpu_startup_entry+0x30/0x8c
[  210.328675]  secondary_start_kernel+0xe4/0x110
[  210.333138]  __secondary_switched+0x94/0x98

The assumption when these were relaxed seems to be that device memory
would be mapped non reordering, and that other constructs
(spinlocks/etc) would provide the barriers to assure that packet data
and in memory rings/queues were ordered with respect to device
register reads/writes. This itself seems a bit sketchy, but the real
problem with GCC12 is that it is moving the actual reads/writes around
at will as though they were independent operations when in truth they
are not, but the compiler can't know that. When looking at the
assembly dumps for many of these routines its possible to see very
clean, but not strictly in program order operations occurring as the
compiler would be free to do if these weren't actually register
reads/write operations.

Its possible to suppress the timeout with a liberal bit of dma_mb()'s
sprinkled around but the device still seems unable to reliably
send/receive data. A better plan is to use the safer readl/writel
everywhere.

Since this partially reverts an older commit, which notes the use of
the relaxed variants for performance reasons. I would suggest that
any performance problems with this commit are targeted at relaxing only
the performance critical code paths after assuring proper barriers.

Fixes: 69d2ea9c79898 ("net: bcmgenet: Use correct I/O accessors")
Reported-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Signed-off-by: Jeremy Linton &lt;jeremy.linton@arm.com&gt;
Acked-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Tested-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20220310045358.224350-1-jeremy.linton@arm.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: bnxt_ptp: fix compilation error</title>
<updated>2022-04-08T12:05:24Z</updated>
<author>
<name>Damien Le Moal</name>
</author>
<published>2022-03-28T06:27:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=210612367f7d631913bdf48357f654b946357872'/>
<id>urn:sha1:210612367f7d631913bdf48357f654b946357872</id>
<content type='text'>
commit dcf500065fabe27676dfe7b4ba521a4f1e0fc8ac upstream.

The Broadcom bnxt_ptp driver does not compile with GCC 11.2.2 when
CONFIG_WERROR is enabled. The following error is generated:

drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c: In function ‘bnxt_ptp_enable’:
drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:400:43: error: array
subscript 255 is above array bounds of ‘struct pps_pin[4]’
[-Werror=array-bounds]
  400 |  ptp-&gt;pps_info.pins[pin_id].event = BNXT_PPS_EVENT_EXTERNAL;
      |  ~~~~~~~~~~~~~~~~~~^~~~~~~~
In file included from drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:20:
drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.h:75:24: note: while
referencing ‘pins’
   75 |         struct pps_pin pins[BNXT_MAX_TSIO_PINS];
      |                        ^~~~
cc1: all warnings being treated as errors

This is due to the function ptp_find_pin() returning a pin ID of -1 when
a valid pin is not found and this error never being checked.
Change the TSIO_PIN_VALID() function to also check that a pin ID is not
negative and use this macro in bnxt_ptp_enable() to check the result of
the calls to ptp_find_pin() to return an error early for invalid pins.
This fixes the compilation error.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 9e518f25802c ("bnxt_en: 1PPS functions to configure TSIO pins")
Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Reviewed-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Link: https://lore.kernel.org/r/20220328062708.207079-1-damien.lemoal@opensource.wdc.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: bcmgenet: skip invalid partial checksums</title>
<updated>2022-03-23T08:18:49Z</updated>
<author>
<name>Doug Berger</name>
</author>
<published>2022-03-17T01:28:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=65a2e32de2d4d98f0b79a77992be4503a9f5a857'/>
<id>urn:sha1:65a2e32de2d4d98f0b79a77992be4503a9f5a857</id>
<content type='text'>
[ Upstream commit 0f643c88c8d240eba0ea25c2e095a46515ff46e9 ]

The RXCHK block will return a partial checksum of 0 if it encounters
a problem while receiving a packet. Since a 1's complement sum can
only produce this result if no bits are set in the received data
stream it is fair to treat it as an invalid partial checksum and
not pass it up the stack.

Fixes: 810155397890 ("net: bcmgenet: use CHECKSUM_COMPLETE for NETIF_F_RXCSUM")
Signed-off-by: Doug Berger &lt;opendmb@gmail.com&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20220317012812.1313196-1-opendmb@gmail.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>bnx2x: fix built-in kernel driver load failure</title>
<updated>2022-03-23T08:18:49Z</updated>
<author>
<name>Manish Chopra</name>
</author>
<published>2022-03-16T21:46:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=851edd04b16682a767f027ac8b3472a8247f2026'/>
<id>urn:sha1:851edd04b16682a767f027ac8b3472a8247f2026</id>
<content type='text'>
[ Upstream commit 424e7834e293936a54fcf05173f2884171adc5a3 ]

Commit b7a49f73059f ("bnx2x: Utilize firmware 7.13.21.0")
added request_firmware() logic in probe() which caused
load failure when firmware file is not present in initrd (below),
as access to firmware file is not feasible during probe.

  Direct firmware load for bnx2x/bnx2x-e2-7.13.15.0.fw failed with error -2
  Direct firmware load for bnx2x/bnx2x-e2-7.13.21.0.fw failed with error -2

This patch fixes this issue by -

1. Removing request_firmware() logic from the probe()
   such that .ndo_open() handle it as it used to handle
   it earlier

2. Given request_firmware() is removed from probe(), so
   driver has to relax FW version comparisons a bit against
   the already loaded FW version (by some other PFs of same
   adapter) to allow different compatible/close enough FWs with which
   multiple PFs may run with (in different environments), as the
   given PF who is in probe flow has no idea now with which firmware
   file version it is going to initialize the device in ndo_open()

Link: https://lore.kernel.org/all/46f2d9d9-ae7f-b332-ddeb-b59802be2bab@molgen.mpg.de/
Reported-by: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Tested-by: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Fixes: b7a49f73059f ("bnx2x: Utilize firmware 7.13.21.0")
Signed-off-by: Manish Chopra &lt;manishc@marvell.com&gt;
Signed-off-by: Ariel Elior &lt;aelior@marvell.com&gt;
Link: https://lore.kernel.org/r/20220316214613.6884-1-manishc@marvell.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>bnx2: Fix an error message</title>
<updated>2022-03-19T12:48:45Z</updated>
<author>
<name>Christophe JAILLET</name>
</author>
<published>2022-03-02T20:21:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0419fec09d17a3bded5867dcc2e6d73344cadd4b'/>
<id>urn:sha1:0419fec09d17a3bded5867dcc2e6d73344cadd4b</id>
<content type='text'>
[ Upstream commit 8ccffe9ac3239e549beaa0a9d5e1a1eac94e866c ]

Fix an error message and report the correct failing function.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&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: bcmgenet: Don't claim WOL when its not available</title>
<updated>2022-03-16T13:26:46Z</updated>
<author>
<name>Jeremy Linton</name>
</author>
<published>2022-03-10T04:55:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4b77baeddb66b2e8f75321840ea34b82e3944d64'/>
<id>urn:sha1:4b77baeddb66b2e8f75321840ea34b82e3944d64</id>
<content type='text'>
[ Upstream commit 00b022f8f876a3a036b0df7f971001bef6398605 ]

Some of the bcmgenet platforms don't correctly support WOL, yet
ethtool returns:

"Supports Wake-on: gsf"

which is false.

Ideally if there isn't a wol_irq, or there is something else that
keeps the device from being able to wakeup it should display:

"Supports Wake-on: d"

This patch checks whether the device can wakup, before using the
hard-coded supported flags. This corrects the ethtool reporting, as
well as the WOL configuration because ethtool verifies that the mode
is supported before attempting it.

Fixes: c51de7f3976b ("net: bcmgenet: add Wake-on-LAN support code")
Signed-off-by: Jeremy Linton &lt;jeremy.linton@arm.com&gt;
Tested-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20220310045535.224450-1-jeremy.linton@arm.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
