<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net, branch v6.3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.3</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-04-20T22:26:37Z</updated>
<entry>
<title>wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels()</title>
<updated>2023-04-20T22:26:37Z</updated>
<author>
<name>Toke Høiland-Jørgensen</name>
<email>toke@toke.dk</email>
</author>
<published>2023-04-13T21:41:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0f2a4af27b649c13ba76431552fe49c60120d0f6'/>
<id>urn:sha1:0f2a4af27b649c13ba76431552fe49c60120d0f6</id>
<content type='text'>
This partially reverts commit e161d4b60ae3a5356e07202e0bfedb5fad82c6aa.

Turns out the channelmap variable is not actually read-only, it's modified
through the MCI_GPM_CLR_CHANNEL_BIT() macro further down in the function,
so making it read-only causes page faults when that code is hit.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217183
Link: https://lore.kernel.org/r/20230413214118.153781-1-toke@toke.dk
Fixes: e161d4b60ae3 ("wifi: ath9k: Make arrays prof_prio and channelmap static const")
Cc: stable@vger.kernel.org
Signed-off-by: Toke Høiland-Jørgensen &lt;toke@toke.dk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "net/mlx5: Enable management PF initialization"</title>
<updated>2023-04-20T01:51:28Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2023-04-13T22:25:47Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f52cc627b832e08a7bcf1b7e81e650ec308fe1d8'/>
<id>urn:sha1:f52cc627b832e08a7bcf1b7e81e650ec308fe1d8</id>
<content type='text'>
This reverts commit fe998a3c77b9f989a30a2a01fb00d3729a6d53a4.

Paul reports that it causes a regression with IB on CX4
and FW 12.18.1000. In addition I think that the concept
of "management PF" is not fully accepted and requires
a discussion.

Fixes: fe998a3c77b9 ("net/mlx5: Enable management PF initialization")
Reported-by: Paul Moore &lt;paul@paul-moore.com&gt;
Link: https://lore.kernel.org/all/CAHC9VhQ7A4+msL38WpbOMYjAqLp0EtOjeLh4Dc6SQtD6OUvCQg@mail.gmail.com/
Link: https://lore.kernel.org/r/20230413222547.56901-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf</title>
<updated>2023-04-20T01:22:18Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2023-04-20T01:22:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9d94769081a65aacd54552dbdeeca2544f70442b'/>
<id>urn:sha1:9d94769081a65aacd54552dbdeeca2544f70442b</id>
<content type='text'>
Daniel Borkmann says:

====================
bpf 2023-04-19

We've added 3 non-merge commits during the last 6 day(s) which contain
a total of 3 files changed, 34 insertions(+), 9 deletions(-).

The main changes are:

1) Fix a crash on s390's bpf_arch_text_poke() under a NULL new_addr,
   from Ilya Leoshkevich.

2) Fix a bug in BPF verifier's precision tracker, from Daniel Borkmann
   and Andrii Nakryiko.

3) Fix a regression in veth's xdp_features which led to a broken BPF CI
   selftest, from Lorenzo Bianconi.

* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
  bpf: Fix incorrect verifier pruning due to missing register precision taints
  veth: take into account peer device for NETDEV_XDP_ACT_NDO_XMIT xdp_features flag
  s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL
====================

Link: https://lore.kernel.org/r/20230419195847.27060-1-daniel@iogearbox.net
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue</title>
<updated>2023-04-20T01:00:04Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2023-04-20T00:57:05Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7b97174d0ef798ba7f802c07527ae378923e5ebc'/>
<id>urn:sha1:7b97174d0ef798ba7f802c07527ae378923e5ebc</id>
<content type='text'>
Tony Nguyen says:

====================
Intel Wired LAN Driver Updates 2023-04-17 (i40e)

This series contains updates to i40e only.

Alex moves setting of active filters to occur under lock and checks/takes
error path in rebuild if re-initializing the misc interrupt vector
failed.

* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
  i40e: fix i40e_setup_misc_vector() error handling
  i40e: fix accessing vsi-&gt;active_filters without holding lock
====================

Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Link: https://lore.kernel.org/r/20230417205245.1030733-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>e1000e: Disable TSO on i219-LM card to increase speed</title>
<updated>2023-04-20T00:54:12Z</updated>
<author>
<name>Sebastian Basierski</name>
<email>sebastianx.basierski@intel.com</email>
</author>
<published>2023-04-17T20:53:45Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=67d47b95119ad589b0a0b16b88b1dd9a04061ced'/>
<id>urn:sha1:67d47b95119ad589b0a0b16b88b1dd9a04061ced</id>
<content type='text'>
While using i219-LM card currently it was only possible to achieve
about 60% of maximum speed due to regression introduced in Linux 5.8.
This was caused by TSO not being disabled by default despite commit
f29801030ac6 ("e1000e: Disable TSO for buffer overrun workaround").
Fix that by disabling TSO during driver probe.

Fixes: f29801030ac6 ("e1000e: Disable TSO for buffer overrun workaround")
Signed-off-by: Sebastian Basierski &lt;sebastianx.basierski@intel.com&gt;
Signed-off-by: Mateusz Palczewski &lt;mateusz.palczewski@intel.com&gt;
Tested-by: Naama Meir &lt;naamax.meir@linux.intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Link: https://lore.kernel.org/r/20230417205345.1030801-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: fix free-runnig PHC mode</title>
<updated>2023-04-20T00:43:07Z</updated>
<author>
<name>Vadim Fedorenko</name>
<email>vadfed@meta.com</email>
</author>
<published>2023-04-18T20:25:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8c154d272c3e03b100baaf1df473f22a78fa403e'/>
<id>urn:sha1:8c154d272c3e03b100baaf1df473f22a78fa403e</id>
<content type='text'>
The patch in fixes changed the way real-time mode is chosen for PHC on
the NIC. Apparently there is one more use case of the check outside of
ptp part of the driver which was not converted to the new macro and is
making a lot of noise in free-running mode.

Fixes: 131db4991622 ("bnxt_en: reset PHC frequency in free-running mode")
Signed-off-by: Vadim Fedorenko &lt;vadfed@meta.com&gt;
Reviewed-by: Michael Chan &lt;michael.chan@broadcom.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://lore.kernel.org/r/20230418202511.1544735-1-vadfed@meta.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: ksz8795: Correctly handle huge frame configuration</title>
<updated>2023-04-19T18:28:49Z</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2023-04-17T18:19:33Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3d2f8f1f184c60508f7af3022536651d7ac2dd07'/>
<id>urn:sha1:3d2f8f1f184c60508f7af3022536651d7ac2dd07</id>
<content type='text'>
Because of the logic in place, SW_HUGE_PACKET can never be set.
(If the first condition is true, then the 2nd one is also true, but is not
executed)

Change the logic and update each bit individually.

Fixes: 29d1e85f45e0 ("net: dsa: microchip: ksz8: add MTU configuration support")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Reviewed-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/43107d9e8b5b8b05f0cbd4e1f47a2bb88c8747b2.1681755535.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>hamradio: drop ISA_DMA_API dependency</title>
<updated>2023-04-19T12:11:41Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2023-04-17T20:50:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=fcd4843a19d50f9e59116b2643e1a7d171b6fca1'/>
<id>urn:sha1:fcd4843a19d50f9e59116b2643e1a7d171b6fca1</id>
<content type='text'>
It looks like the dependency got added accidentally in commit a553260618d8
("[PATCH] ISA DMA Kconfig fixes - part 3"). Unlike the previously removed
dmascc driver, the scc driver never used DMA.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>mlxsw: pci: Fix possible crash during initialization</title>
<updated>2023-04-19T12:06:10Z</updated>
<author>
<name>Ido Schimmel</name>
<email>idosch@nvidia.com</email>
</author>
<published>2023-04-17T16:52:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1f64757ee2bb22a93ec89b4c71707297e8cca0ba'/>
<id>urn:sha1:1f64757ee2bb22a93ec89b4c71707297e8cca0ba</id>
<content type='text'>
During initialization the driver issues a reset command via its command
interface in order to remove previous configuration from the device.

After issuing the reset, the driver waits for 200ms before polling on
the "system_status" register using memory-mapped IO until the device
reaches a ready state (0x5E). The wait is necessary because the reset
command only triggers the reset, but the reset itself happens
asynchronously. If the driver starts polling too soon, the read of the
"system_status" register will never return and the system will crash
[1].

The issue was discovered when the device was flashed with a development
firmware version where the reset routine took longer to complete. The
issue was fixed in the firmware, but it exposed the fact that the
current wait time is borderline.

Fix by increasing the wait time from 200ms to 400ms. With this patch and
the buggy firmware version, the issue did not reproduce in 10 reboots
whereas without the patch the issue is reproduced quite consistently.

[1]
mce: CPUs not responding to MCE broadcast (may include false positives): 0,4
mce: CPUs not responding to MCE broadcast (may include false positives): 0,4
Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
Shutting down cpus with NMI
Kernel Offset: 0x12000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

Fixes: ac004e84164e ("mlxsw: pci: Wait longer before accessing the device after reset")
Signed-off-by: Ido Schimmel &lt;idosch@nvidia.com&gt;
Reviewed-by: Petr Machata &lt;petrm@nvidia.com&gt;
Signed-off-by: Petr Machata &lt;petrm@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: vmxnet3: Fix NULL pointer dereference in vmxnet3_rq_rx_complete()</title>
<updated>2023-04-19T08:03:05Z</updated>
<author>
<name>Seiji Nishikawa</name>
<email>snishika@redhat.com</email>
</author>
<published>2023-04-17T12:21:27Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6f4833383e8514ea796d094e05c24889b8997fde'/>
<id>urn:sha1:6f4833383e8514ea796d094e05c24889b8997fde</id>
<content type='text'>
When vmxnet3_rq_create() fails to allocate rq-&gt;data_ring.base due to page
allocation failure, subsequent call to vmxnet3_rq_rx_complete() can result in
NULL pointer dereference.

To fix this bug, check not only that rxDataRingUsed is true but also that
adapter-&gt;rxdataring_enabled is true before calling memcpy() in
vmxnet3_rq_rx_complete().

[1728352.477993] ethtool: page allocation failure: order:9, mode:0x6000c0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0
...
[1728352.478009] Call Trace:
[1728352.478028]  dump_stack+0x41/0x60
[1728352.478035]  warn_alloc.cold.120+0x7b/0x11b
[1728352.478038]  ? _cond_resched+0x15/0x30
[1728352.478042]  ? __alloc_pages_direct_compact+0x15f/0x170
[1728352.478043]  __alloc_pages_slowpath+0xcd3/0xd10
[1728352.478047]  __alloc_pages_nodemask+0x2e2/0x320
[1728352.478049]  __dma_direct_alloc_pages.constprop.25+0x8a/0x120
[1728352.478053]  dma_direct_alloc+0x5a/0x2a0
[1728352.478056]  vmxnet3_rq_create.part.57+0x17c/0x1f0 [vmxnet3]
...
[1728352.478188] vmxnet3 0000:0b:00.0 ens192: rx data ring will be disabled
...
[1728352.515347] BUG: unable to handle kernel NULL pointer dereference at 0000000000000034
...
[1728352.515440] RIP: 0010:memcpy_orig+0x54/0x130
...
[1728352.515655] Call Trace:
[1728352.515665]  &lt;IRQ&gt;
[1728352.515672]  vmxnet3_rq_rx_complete+0x419/0xef0 [vmxnet3]
[1728352.515690]  vmxnet3_poll_rx_only+0x31/0xa0 [vmxnet3]
...

Signed-off-by: Seiji Nishikawa &lt;snishika@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
