* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: Jakub Kicinski @ 2026-04-02 0:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Woodhouse, Eric Dumazet, Saeed Mahameed, Leon Romanovsky,
Tariq Toukan, Mark Bloch, Andrew Lunn, David S. Miller,
Paolo Abeni, Simon Horman, Nikolay Aleksandrov, Ido Schimmel,
Martin KaFai Lau, Daniel Borkmann, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Andrii Nakryiko,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Johannes Berg, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Guillaume Nault, Kees Cook, Alexei Lazar,
Gal Pressman, Paul Moore, netdev, linux-rdma, linux-kernel,
oss-drivers, bridge, bpf, linux-wireless, netfilter-devel,
coreteam, torvalds
In-Reply-To: <20260401080657.70cd9bd1@phoenix.local>
On Wed, 1 Apr 2026 08:06:57 -0700 Stephen Hemminger wrote:
> On Wed, 01 Apr 2026 10:28:23 +0100
> David Woodhouse <dwmw2@infradead.org> wrote:
>
> > > Some kernels are built without CONFIG_IPV6, so this warning would be
> > > quite misleading.
> >
> > Maybe on this date next year, we could make it not possible to build
> > the kernel *without* IPv6... ?
>
> There are some government agencies that used to require that IPV6 was disabled
> for security reasons. Yes they had broken old firewalls
Which is why we sadly have to keep the ipv6_mod_enabled()
sillilitude around. But that's a runtime thing.
^ permalink raw reply
* Re: [PATCH v2] wifi: mac80211: fix the issue of NULL pointer access when deleting the virtual interface
From: Óscar Alfonso Díaz @ 2026-04-02 0:06 UTC (permalink / raw)
To: 傅继晗; +Cc: johannes, linux-kernel, linux-wireless, stable
In-Reply-To: <CA+bbHrUkGP5bX6SFVXLS-bTyHWUiRyHaSojvMW6RGPz+T55yHg@mail.gmail.com>
Hello everyone, a member of the airgeddon team made a kernel
modification that seems to work. I’ve tested it on VMware and also on
bare metal with a 7.0.0-rc5 kernel, using both a Fenvi AX1800
(MT7921U) and an Alfa AWUS036AXML (MT7921AUN), and it appears to work
well. Deauthentication during VIF operation (evil twin attack) is now
working for MediaTek.
Everything is documented at this comment in the GitHub thread
(https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4167080451),
including the patch used. A patch that is modifying these three files
(tx.c, chan.c and ieee80211_i.h). Take a look at it on the Github
thread please.
Regards.
--
Oscar
OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El dom, 29 mar 2026 a las 23:55, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Please review my latest messages in the GitHub thread.
> https://github.com/morrownr/USB-WiFi/issues/682
>
> There you’ll even find a link to a video I recorded so you can see
> that even on bare metal with Kali Linux installed natively, it still
> doesn’t work. It behaves exactly the same as it does in the VM.
>
> Here is the link
> https://www.dropbox.com/scl/fi/i6h8xbls5xkvae0pitrbg/video_2026-03-29_23-44-36.mp4?rlkey=jm48ly9tjwbhsi4aauml2auh9&dl=1
>
> Regards.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 ||
> https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
>
> El jue, 26 mar 2026 a las 13:16, Óscar Alfonso Díaz
> (<oscar.alfonso.diaz@gmail.com>) escribió:
> >
> > Hi, in response to the three points:
> >
> > 1. VMware
> >
> > 2. This is the output of the lsusb command: "Bus 004 Device 002: ID
> > 0e8d:7961 MediaTek Inc. Wireless_Device". The adapter is very cheap,
> > it’s a Fenvi AX1800 (MT7921U), this one:
> > https://s.click.aliexpress.com/e/_okxhxNl . But as I said, the bug
> > also happens when using the Alfa AWUS036AXML (MT7921AUN).
> >
> > 3. I’m not sure about this right now. I’d say everything dies. I’ll
> > test that to see if SSH is still available (I don’t think so, but I’m
> > not 100% sure at the moment).
> >
> > Give me a few days. I’ll test this again over the weekend. I’ll also
> > run a test on bare metal (not in a VM). That said, like me, many
> > people use VMs for pentesting. So even if it works on bare metal,
> > which I’ll test this weekend, I think it would still be worth
> > investigating whether it can be fixed for VMs, since many people,
> > myself included, use them for work. If it works with other WiFi
> > adapters, it would be a big drawback if it didn’t work with MediaTek
> > adapters.
> >
> > I’ll also reply with a similar message in the thread.
> >
> > Thanks and regards.
> > --
> > Oscar
> >
> > OpenPGP Key: DA9C60E9 ||
> > https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> > 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> > --
> >
> > El jue, 26 mar 2026 a las 2:37, 傅继晗 (<fjhhz1997@gmail.com>) escribió:
> > >
> > > Hi Óscar,
> > >
> > > Lucid-Duck spent some time trying to reproduce your crash and wasn't able
> > > to trigger it. Here's a summary of what was tested:
> > >
> > > - Kali 2025.4 (kernel 6.18.12+kali-amd64) VM on QEMU/KVM, with my v2
> > > patch applied
> > > - MT7921AU USB adapter, passthrough to VM
> > > - Full airgeddon evil twin flow: monitor VIF + hostapd AP + continuous
> > > deauth via aireplay-ng
> > > - Also tested on bare metal Fedora 6.19.8 with the same adapter
> > >
> > > All tests were stable -- no crash, no dmesg errors, load stayed low. The
> > > deauth frames were confirmed sending for 30+ seconds under the v2 patch
> > > without issues.
> > >
> > > The one variable that couldn't be matched was the VM hypervisor.
> > > Lucid-Duck used QEMU/KVM, which handles USB passthrough at the kernel
> > > level (xHCI). If you're using VirtualBox or VMware, the USB passthrough
> > > path is quite different (userspace proxy), and that could potentially
> > > explain a total VM freeze that isn't a kernel panic.
> > >
> > > Could you please reply to Lucid-Duck directly on GitHub with the
> > > following information? Here's the link:
> > > https://github.com/morrownr/USB-WiFi/issues/682#issuecomment-4129198757
> > >
> > > 1. Which hypervisor are you using? (VirtualBox, VMware, QEMU/KVM, etc.)
> > > 2. Your exact USB adapter model and ID? (0e8d:7961 covers several
> > > MT7921 variants)
> > > 3. If possible, try SSHing into the VM from the host while the display
> > > is frozen -- if SSH still works, the issue is at the hypervisor/display
> > > level, not the kernel.
> > >
> > > Thanks,
> > > 傅继晗
^ permalink raw reply
* Re: [BUG] mt7925e: MSI Vector A16 HX A8WHG-004US reports permanent hardware rfkill block under Linux; ACPI GPPA.WLAN AE_ALREADY_EXISTS
From: Sean Wang @ 2026-04-01 23:33 UTC (permalink / raw)
To: Ross
Cc: linux-mediatek, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
deren.wu, linux-wireless
In-Reply-To: <CAEoHs0hONW_X8POryv-YC8ahGAVoOsvXXJw9VnDOguSgq52v=Q@mail.gmail.com>
Hi,
On Mon, Mar 9, 2026 at 2:20 PM Ross <rosspayant@gmail.com> wrote:
>
> Hello, I want to report a wifi bug. This bug makes the wifi hard lock
> on my computer under Arch Linux as well as Fedora. Wifi does work on
> Linux LTE and Windows 11. The computer is a Vector A16 HX A8WHG-004US
> and this it's actually the second I bought. I returned the first one
> because of the exact same bug. Since I got the second one I've stuck
> it through hoping there would be a fix, it's been three months now.
> I've tried all the possible fixes (on both machines), nothing. "sudo
> rfkill unblock all" and "sudo rfkill unblock wifi" do not work. There
> is no switch in the bios or "airplane mode" hotkey to toggle either.
> The wifi just does not work in Linux (apart from LTE). I've updated
> the bios to the new version every time a new one drops (including the
> most recent one from a couple days ago) and nothing has changed
> anything. I've updated everything else frequently. No dice.
>
> Anyway, I suppose this is where I go to file report bugs like this?
> I've never issued a bug report before so I'm not sure. Thank you so
> much for giving this the time of day, as well as all the other work
> you do on the LInux project. If you need further information I'll give
> you whatever you need.
>
> I had the following written for me by AI but I can confirm it's
> accurate to the problem:
>
>
> I am reporting what appears to be an MSI-platform-specific MT7925
> hard-rfkill issue on Linux.
>
> Hardware
> - Laptop: MSI Vector A16 HX A8WHG-004US
> - WLAN: MEDIATEK MT7925 802.11be 160MHz 2x2 PCIe Wireless Network
> Adapter [14c3:7925]
> - Subsystem: Foxconn International, Inc. Device [105b:e138]
>
> Software
> - BIOS: E15MMAMS.107
> - Kernel: 6.19.6-arch1-1
> - linux-firmware: 20260221-1
> - Distro: Arch Linux
>
> Problem
> - The Wi-Fi device is detected correctly.
> - The mt7925e driver binds successfully.
> - Firmware appears to load.
> - The interface is created/renamed to wlp5s0.
> - However, rfkill always reports the WLAN as hard blocked.
>
> Current rfkill state
> - Bluetooth: Soft blocked: no / Hard blocked: no
> - Wireless LAN: Soft blocked: no / Hard blocked: yes
>
> Attempted commands
> - sudo rfkill unblock wifi
> - sudo rfkill unblock all
>
> Neither command changes the WLAN hard block.
>
> Relevant observations
> - lspci shows:
> MEDIATEK Corp. MT7925 802.11be 160MHz 2x2 PCIe Wireless Network
> Adapter [Filogic 360] [14c3:7925]
> Kernel driver in use: mt7925e
> - The boot log shows the device being enabled, ASIC revision detected,
> firmware information printed, and the interface renamed from wlan0 to
> wlp5s0.
> - The same boot log also shows repeated ACPI errors involving WLAN
> objects under \_SB.PCI0.GPPA.WLAN..., including repeated
> AE_ALREADY_EXISTS failures.
>
> This makes it look like:
> - the device is present,
> - the mt7925e driver is loading,
> - but platform/ACPI state may be forcing or misreporting hardware rfkill.
>
> Relevant kernel log excerpt
>
> mt7925e 0000:05:00.0: enabling device (0000 -> 0002)
> mt7925e 0000:05:00.0: ASIC revision: 79250000
> mt7925e 0000:05:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> mt7925e 0000:05:00.0: WM Firmware Version: ____000000, Build Time:
> 20260106153120
> mt7925e 0000:05:00.0 wlp5s0: renamed from wlan0
>
From the logs so far, this does not look like a basic mt7925e
initialization failure. The device probes normally, firmware loads,
and the interface is created, but the WLAN still ends up reported as
hard blocked, so Wi-Fi never becomes usable. Typically, this kind of
blocked state comes from a platform-level source, such as a hardware
radio switch or platform-provided radio state, rather than from the
mt7925e path itself.
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN._S0W], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN._S4W], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN._DSM], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN.PCIF], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN.NVID], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN.NDID], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN.PWR1], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN._PR0], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN._PR2], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN._PR3], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN.PWFR], AE_ALREADY_EXISTS
> ACPI BIOS Error (bug): Failure creating named object
> [\_SB.PCI0.GPPA.WLAN._PRR], AE_ALREADY_EXISTS
>
> Reproduction
> 1. Boot Linux normally.
> 2. Run:
> rfkill list all
> 3. Wireless LAN is always reported as:
> Soft blocked: no
> Hard blocked: yes
>
> Additional notes
> - Windows 11 on the same laptop can use Wi-Fi normally.
> - Updating BIOS from E15MMAMS.106 to E15MMAMS.107 did not resolve the issue.
> - This may be similar in shape to other MT7925 hard-rfkill issues that
> required a machine-specific quirk, but on this MSI model the prominent
> clue is the repeated ACPI GPPA.WLAN object collision.
>
> Please let me know if you want:
> - full lspci -nnk output
> - full dmesg/journalctl -b -k
> - acpidump / decoded DSDT
> - additional testing with a proposed patch or boot parameter
>
> --
> Ross Payant
>
^ permalink raw reply
* Re: [BUG] mt7921e: Intermittent connection failure
From: Sean Wang @ 2026-04-01 22:58 UTC (permalink / raw)
To: silverducks
Cc: linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
matthias.bgg, angelogioacchino.delregno,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <f264b392-37bc-4b31-ac0e-768466f2b962@altlinux.org>
Hi,
On Tue, Mar 31, 2026 at 2:40 AM silverducks <silverducks@altlinux.org> wrote:
>
> Greetings!
>
> I apologize for poor formatting in the previous email. I did not realize all
> plain text files' contents would be visible on the mailing list.
> I am attaching an archive containing the same files as in previous email for
> convenience.
> Given compression, I can also avoid using external hosting, which I
> presume is
> preferred, so I am including all relevant logs in the archive as well.
> I am also including original email text just in case.
I think the current test setup is still mixing too many variables, so
it is hard to tell what is actually triggering the issue.
In particular, if the goal is to test the NetworkManager path, the
script should not also manually manage wpa_supplicant, and iwd should
not be part of the same test either. NetworkManager normally manages
the Wi-Fi backend itself, so mixing manual wpa_supplicant handling,
iwd, and NetworkManager in one setup makes the result difficult to
interpret.
Could you first simplify the setup and test one path at a time?
If you want to test NetworkManager, use only NetworkManager, for
example by using nmcli to explicitly control the connection steps.
If you want to test plain wpa_supplicant, stop NetworkManager
completely and use only wpa_supplicant + wpa_cli. I would suggest
starting with this path, since that is also the setup I usually use
for testing.
If you want to test iwd, please test it separately as well.
Also suggest to avoid suspend/resume or hibernation for now.
The log you shared includes a clear S4 resume path (ACPI: PM: Waking
up from system sleep state S4 and pci_pm_restore returns -110), which
does not match a simple reconnect or module reload test.
^ permalink raw reply
* Re: [PATCH rtw-next 06/12] wifi: rtw89: usb: Enable RX aggregation for RTL8922AU
From: Bitterblue Smith @ 2026-04-01 22:58 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <5853e0d8036840b89080229ed1aa4deb@realtek.com>
On 30/03/2026 06:46, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> It uses the same settings as RTL8852CU.
>
> Though the values are the same, I'd prefer listing them individually, since
> naming is different in vendor driver.
>
> #define R_AX_RXAGG_0_V1 0x6000
> #define R_BE_RXAGG_0_V1 0x6000
>
> How about you? (I don't strictly request to this change)
>
Okay, I will do that for v2.
^ permalink raw reply
* [PATCH v2 2/2] wifi: mt76: mt7921u: escalate broken USB transport to device reset
From: Sean Wang @ 2026-04-01 19:06 UTC (permalink / raw)
To: nbd, lorenzo.bianconi
Cc: linux-wireless, linux-mediatek, Sean Wang, Bryam Vargas
In-Reply-To: <20260401190632.147042-1-sean.wang@kernel.org>
From: Sean Wang <sean.wang@mediatek.com>
Check the USB control path before running the normal WFSYS reset flow.
If USB access is no longer reliable, stop the WFSYS-only reset path,
mark the device as bus_hung, and queue a USB device reset instead.
Reuse the existing bus_hung state to represent transport-level failure,
keeping the semantics consistent with the SDIO path.
Also initialize bus_hung explicitly during probe for consistency.
Reported-by: Bryam Vargas <bryamestebanvargas@gmail.com>
Closes: https://lore.kernel.org/r/CANAPQziOh3sB7B8G+U3AZsFfeFN1uAg4munhwA_feZi56D7W+Q@mail.gmail.com
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
v2:
- Rebased onto the latest mt76 tree
- Added the proper Reported-by tag
---
.../net/wireless/mediatek/mt76/mt7921/mac.c | 4 ++-
.../net/wireless/mediatek/mt76/mt7921/usb.c | 5 ++++
drivers/net/wireless/mediatek/mt76/mt792x.h | 1 +
.../net/wireless/mediatek/mt76/mt792x_usb.c | 26 +++++++++++++++++++
4 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mac.c b/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
index 03b4960db73f..d27dbee8df1b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
@@ -675,7 +675,9 @@ void mt7921_mac_reset_work(struct work_struct *work)
if (!ret)
break;
}
- if (mt76_is_sdio(&dev->mt76) && atomic_read(&dev->mt76.bus_hung))
+
+ if ((mt76_is_sdio(&dev->mt76) || mt76_is_usb(&dev->mt76)) &&
+ atomic_read(&dev->mt76.bus_hung))
return;
if (i == 10)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
index 6be28f4152ed..8c0f0e4ef87b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
@@ -88,6 +88,10 @@ static int mt7921u_mac_reset(struct mt792x_dev *dev)
{
int err;
+ mt792xu_reset_on_bus_error(dev);
+ if (atomic_read(&dev->mt76.bus_hung))
+ return 0;
+
mt76_txq_schedule_all(&dev->mphy);
mt76_worker_disable(&dev->mt76.tx_worker);
@@ -196,6 +200,7 @@ static int mt7921u_probe(struct usb_interface *usb_intf,
dev = container_of(mdev, struct mt792x_dev, mt76);
dev->fw_features = features;
dev->hif_ops = &hif_ops;
+ atomic_set(&dev->mt76.bus_hung, false);
mt792xu_reset_work_init(dev);
udev = usb_get_dev(udev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x.h b/drivers/net/wireless/mediatek/mt76/mt792x.h
index 5f06074591ca..74222c507b81 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x.h
+++ b/drivers/net/wireless/mediatek/mt76/mt792x.h
@@ -494,6 +494,7 @@ int mt792xu_init_reset(struct mt792x_dev *dev);
void mt792xu_reset_work_init(struct mt792x_dev *dev);
void mt792xu_reset_work_cleanup(struct mt792x_dev *dev);
int mt792xu_check_bus(struct mt792x_dev *dev);
+int mt792xu_reset_on_bus_error(struct mt792x_dev *dev);
u32 mt792xu_rr(struct mt76_dev *dev, u32 addr);
void mt792xu_wr(struct mt76_dev *dev, u32 addr, u32 val);
u32 mt792xu_rmw(struct mt76_dev *dev, u32 addr, u32 mask, u32 val);
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
index 2558d87b1e0f..6b10d035bcbc 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
@@ -60,6 +60,32 @@ int mt792xu_check_bus(struct mt792x_dev *dev)
}
EXPORT_SYMBOL_GPL(mt792xu_check_bus);
+int mt792xu_reset_on_bus_error(struct mt792x_dev *dev)
+{
+ int err = 0;
+
+ if (!atomic_read(&dev->mt76.bus_hung))
+ err = mt792xu_check_bus(dev);
+
+ if (err) {
+ atomic_set(&dev->mt76.bus_hung, true);
+
+ if (!atomic_xchg(&dev->usb_reset_pending, 1)) {
+ dev_warn(dev->mt76.dev,
+ "USB transport access failed (%d), queueing device reset\n",
+ err);
+
+ schedule_work(&dev->usb_reset_work);
+ }
+
+ return err;
+ }
+
+ atomic_set(&dev->mt76.bus_hung, false);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mt792xu_reset_on_bus_error);
+
u32 mt792xu_rr(struct mt76_dev *dev, u32 addr)
{
u32 ret;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/2] wifi: mt76: mt792x: add common USB transport reset helpers
From: Sean Wang @ 2026-04-01 19:06 UTC (permalink / raw)
To: nbd, lorenzo.bianconi; +Cc: linux-wireless, linux-mediatek, Sean Wang
From: Sean Wang <sean.wang@mediatek.com>
Add per-device USB reset work and a control-path access check helper
for mt7921u and mt7925u.
This prepares common infrastructure for transport-level recovery while
keeping the reset state per-device for correct lifetime handling.
No functional change intended.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
v2:
- Rebased onto the latest mt76 tree
---
.../net/wireless/mediatek/mt76/mt7921/usb.c | 2 +
.../net/wireless/mediatek/mt76/mt7925/usb.c | 2 +
drivers/net/wireless/mediatek/mt76/mt792x.h | 5 ++
.../net/wireless/mediatek/mt76/mt792x_usb.c | 50 +++++++++++++++++++
4 files changed, 59 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
index 17057e68bf21..6be28f4152ed 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
@@ -196,6 +196,7 @@ static int mt7921u_probe(struct usb_interface *usb_intf,
dev = container_of(mdev, struct mt792x_dev, mt76);
dev->fw_features = features;
dev->hif_ops = &hif_ops;
+ mt792xu_reset_work_init(dev);
udev = usb_get_dev(udev);
usb_reset_device(udev);
@@ -244,6 +245,7 @@ static int mt7921u_probe(struct usb_interface *usb_intf,
error:
mt76u_queues_deinit(&dev->mt76);
+ mt792xu_reset_work_cleanup(dev);
usb_set_intfdata(usb_intf, NULL);
usb_put_dev(interface_to_usbdev(usb_intf));
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
index d9968f03856d..8b5d58125352 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
@@ -184,6 +184,7 @@ static int mt7925u_probe(struct usb_interface *usb_intf,
dev = container_of(mdev, struct mt792x_dev, mt76);
dev->fw_features = features;
dev->hif_ops = &hif_ops;
+ mt792xu_reset_work_init(dev);
udev = usb_get_dev(udev);
usb_reset_device(udev);
@@ -232,6 +233,7 @@ static int mt7925u_probe(struct usb_interface *usb_intf,
error:
mt76u_queues_deinit(&dev->mt76);
+ mt792xu_reset_work_cleanup(dev);
usb_set_intfdata(usb_intf, NULL);
usb_put_dev(interface_to_usbdev(usb_intf));
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x.h b/drivers/net/wireless/mediatek/mt76/mt792x.h
index 4ff93f2cd624..5f06074591ca 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x.h
+++ b/drivers/net/wireless/mediatek/mt76/mt792x.h
@@ -243,6 +243,8 @@ struct mt792x_dev {
wait_queue_head_t wait;
struct work_struct init_work;
+ struct work_struct usb_reset_work;
+ atomic_t usb_reset_pending;
u8 fw_debug;
u8 fw_features;
@@ -489,6 +491,9 @@ int mt792xu_dma_init(struct mt792x_dev *dev, bool resume);
int mt792xu_mcu_power_on(struct mt792x_dev *dev);
int mt792xu_wfsys_reset(struct mt792x_dev *dev);
int mt792xu_init_reset(struct mt792x_dev *dev);
+void mt792xu_reset_work_init(struct mt792x_dev *dev);
+void mt792xu_reset_work_cleanup(struct mt792x_dev *dev);
+int mt792xu_check_bus(struct mt792x_dev *dev);
u32 mt792xu_rr(struct mt76_dev *dev, u32 addr);
void mt792xu_wr(struct mt76_dev *dev, u32 addr, u32 val);
u32 mt792xu_rmw(struct mt76_dev *dev, u32 addr, u32 mask, u32 val);
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
index 47827d1c5ccb..2558d87b1e0f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
@@ -11,6 +11,55 @@
#include "mt792x.h"
#include "mt76_connac2_mac.h"
+static int mt792xu_read32(struct mt76_dev *dev, u32 addr, void *buf)
+{
+ return __mt76u_vendor_request(dev, MT_VEND_READ_EXT,
+ USB_DIR_IN | MT_USB_TYPE_VENDOR,
+ (u16)(addr >> 16), (u16)addr,
+ buf, sizeof(__le32));
+}
+
+static void mt792xu_reset_work(struct work_struct *work)
+{
+ struct mt792x_dev *dev =
+ container_of(work, struct mt792x_dev, usb_reset_work);
+ struct usb_interface *usb_intf = to_usb_interface(dev->mt76.dev);
+
+ if (usb_intf && usb_get_intfdata(usb_intf) == dev)
+ usb_queue_reset_device(usb_intf);
+
+ atomic_set(&dev->usb_reset_pending, 0);
+}
+
+void mt792xu_reset_work_init(struct mt792x_dev *dev)
+{
+ INIT_WORK(&dev->usb_reset_work, mt792xu_reset_work);
+ atomic_set(&dev->usb_reset_pending, 0);
+}
+EXPORT_SYMBOL_GPL(mt792xu_reset_work_init);
+
+void mt792xu_reset_work_cleanup(struct mt792x_dev *dev)
+{
+ cancel_work_sync(&dev->usb_reset_work);
+ atomic_set(&dev->usb_reset_pending, 0);
+}
+EXPORT_SYMBOL_GPL(mt792xu_reset_work_cleanup);
+
+int mt792xu_check_bus(struct mt792x_dev *dev)
+{
+ int ret;
+
+ mutex_lock(&dev->mt76.usb.usb_ctrl_mtx);
+ ret = mt792xu_read32(&dev->mt76, MT_HW_CHIPID, dev->mt76.usb.data);
+ mutex_unlock(&dev->mt76.usb.usb_ctrl_mtx);
+
+ if (ret == sizeof(__le32))
+ return 0;
+
+ return ret < 0 ? ret : -EIO;
+}
+EXPORT_SYMBOL_GPL(mt792xu_check_bus);
+
u32 mt792xu_rr(struct mt76_dev *dev, u32 addr)
{
u32 ret;
@@ -333,6 +382,7 @@ void mt792xu_disconnect(struct usb_interface *usb_intf)
{
struct mt792x_dev *dev = usb_get_intfdata(usb_intf);
+ mt792xu_reset_work_cleanup(dev);
cancel_work_sync(&dev->init_work);
if (!test_bit(MT76_STATE_INITIALIZED, &dev->mphy.state))
return;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/3] wifi: mt76: mt792x: report txpower for the requested vif link
From: Sean Wang @ 2026-04-01 18:23 UTC (permalink / raw)
To: nbd, lorenzo.bianconi
Cc: linux-wireless, linux-mediatek, Sean Wang, Devin Wittmayer,
Satadru Pramanik
In-Reply-To: <20260401182322.64355-1-sean.wang@kernel.org>
From: Sean Wang <sean.wang@mediatek.com>
mt792x currently reports txpower from the generic PHY cached state,
which may not match the requested vif/link context.
Resolve the requested link channel and derive txpower from that channel
instead, with fallback to the current PHY chandef if no valid chanctx is
available.
Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Closes: https://lore.kernel.org/linux-wireless/20260130215839.53270-1-lucid_duck@justthetip.ca/
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Tested-by: Satadru Pramanik <satadru@gmail.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
v2:
- Rebased onto the latest mt76 tree
- Added Reported-by, Tested-by, Co-developed-by and Signed-off-by tags
---
.../net/wireless/mediatek/mt76/mt7921/main.c | 2 +-
.../net/wireless/mediatek/mt76/mt7925/main.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt792x.h | 2 +
.../net/wireless/mediatek/mt76/mt792x_core.c | 41 +++++++++++++++++++
4 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/main.c b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
index 3d74fabe7408..2e7cdf8edc12 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
@@ -1552,7 +1552,7 @@ const struct ieee80211_ops mt7921_ops = {
.wake_tx_queue = mt76_wake_tx_queue,
.release_buffered_frames = mt76_release_buffered_frames,
.channel_switch_beacon = mt7921_channel_switch_beacon,
- .get_txpower = mt76_get_txpower,
+ .get_txpower = mt792x_get_txpower,
.get_stats = mt792x_get_stats,
.get_et_sset_count = mt792x_get_et_sset_count,
.get_et_strings = mt792x_get_et_strings,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 73d3722739d0..53e1a93c6976 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -2433,7 +2433,7 @@ const struct ieee80211_ops mt7925_ops = {
.wake_tx_queue = mt76_wake_tx_queue,
.release_buffered_frames = mt76_release_buffered_frames,
.channel_switch_beacon = mt7925_channel_switch_beacon,
- .get_txpower = mt76_get_txpower,
+ .get_txpower = mt792x_get_txpower,
.get_stats = mt792x_get_stats,
.get_et_sset_count = mt792x_get_et_sset_count,
.get_et_strings = mt792x_get_et_strings,
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x.h b/drivers/net/wireless/mediatek/mt76/mt792x.h
index 4ff93f2cd624..65eba18bc3a1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x.h
+++ b/drivers/net/wireless/mediatek/mt76/mt792x.h
@@ -397,6 +397,8 @@ void mt792x_roc_timer(struct timer_list *timer);
void mt792x_csa_timer(struct timer_list *timer);
void mt792x_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u32 queues, bool drop);
+int mt792x_get_txpower(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ unsigned int link_id, int *dbm);
int mt792x_assign_vif_chanctx(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *link_conf,
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_core.c b/drivers/net/wireless/mediatek/mt76/mt792x_core.c
index 152cfcca2f90..3fd1be7db1f4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_core.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_core.c
@@ -329,6 +329,47 @@ void mt792x_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
}
EXPORT_SYMBOL_GPL(mt792x_flush);
+int mt792x_get_txpower(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ unsigned int link_id, int *dbm)
+{
+ struct mt76_power_limits limits = {};
+ struct ieee80211_bss_conf *link_conf;
+ struct ieee80211_channel *chan;
+ struct mt792x_bss_conf *mconf;
+ struct mt792x_vif *mvif;
+ struct mt76_phy *phy;
+ s8 max_power;
+
+ if (!vif)
+ return mt76_get_txpower(hw, vif, link_id, dbm);
+
+ mvif = (struct mt792x_vif *)vif->drv_priv;
+ phy = mvif->phy->mt76;
+
+ mt792x_mutex_acquire(mvif->phy->dev);
+
+ link_conf = mt792x_vif_to_bss_conf(vif, link_id);
+ mconf = link_conf ? mt792x_link_conf_to_mconf(link_conf) : NULL;
+ if (mconf && mconf->mt76.ctx && mconf->mt76.ctx->def.chan)
+ chan = mconf->mt76.ctx->def.chan;
+ else
+ /* Fall back to the current PHY chandef if the requested link
+ * does not have a valid channel context.
+ */
+ chan = phy->chandef.chan;
+
+ mt792x_mutex_release(mvif->phy->dev);
+
+ if (!chan)
+ return -EINVAL;
+
+ max_power = mt76_connac_get_rate_power_limit(phy, chan, &limits);
+ *dbm = DIV_ROUND_UP(max_power, 2);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mt792x_get_txpower);
+
int mt792x_assign_vif_chanctx(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *link_conf,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] wifi: mt76: connac: factor out rate power limit calculation
From: Sean Wang @ 2026-04-01 18:23 UTC (permalink / raw)
To: nbd, lorenzo.bianconi
Cc: linux-wireless, linux-mediatek, Sean Wang, Devin Wittmayer,
Satadru Pramanik
In-Reply-To: <20260401182322.64355-1-sean.wang@kernel.org>
From: Sean Wang <sean.wang@mediatek.com>
Factor out the per-channel rate power limit calculation into a shared
helper.
This avoids duplicating the same regulatory, SAR and rate-limit logic in
multiple paths.
Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Closes: https://lore.kernel.org/linux-wireless/20260130215839.53270-1-lucid_duck@justthetip.ca/
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Tested-by: Satadru Pramanik <satadru@gmail.com>
Co-developed-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
v2:
- Rebased onto the latest mt76 tree
- Added Reported-by, Tested-by, Co-developed-by and Signed-off-by tags
---
.../net/wireless/mediatek/mt76/mt76_connac.h | 3 ++
.../wireless/mediatek/mt76/mt76_connac_mcu.c | 28 +++++++++++++------
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac.h b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
index d0953e02810b..1549a97873ee 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
@@ -421,6 +421,9 @@ void mt76_connac_gen_ppe_thresh(u8 *he_ppet, int nss, enum nl80211_band band);
int mt76_connac_init_tx_queues(struct mt76_phy *phy, int idx, int n_desc,
int ring_base, void *wed, u32 flags);
void mt76_connac_set_txpower_cur(struct mt76_phy *phy, s8 max_power);
+s8 mt76_connac_get_rate_power_limit(struct mt76_phy *phy,
+ struct ieee80211_channel *chan,
+ struct mt76_power_limits *limits);
void mt76_connac_write_hw_txp(struct mt76_dev *dev,
struct mt76_tx_info *tx_info,
void *txp_ptr, u32 id);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
index 897b065a2be6..1117a22c70ac 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
@@ -2223,15 +2223,10 @@ mt76_connac_mcu_rate_txpower_band(struct mt76_phy *phy,
.hw_value = ch_list[idx],
.band = band,
};
- s8 reg_power, sar_power, max_power;
-
- reg_power = mt76_connac_get_ch_power(phy, &chan,
- tx_power);
- sar_power = mt76_get_sar_power(phy, &chan, reg_power);
-
- max_power = mt76_get_rate_power_limits(phy, &chan, limits,
- sar_power);
+ s8 max_power;
+ max_power = mt76_connac_get_rate_power_limit(phy, &chan,
+ limits);
if (phy->chandef.chan &&
phy->chandef.chan->hw_value == ch_list[idx] &&
phy->chandef.chan->band == band)
@@ -2967,6 +2962,23 @@ int mt76_connac_mcu_rdd_cmd(struct mt76_dev *dev, int cmd, u8 index,
}
EXPORT_SYMBOL_GPL(mt76_connac_mcu_rdd_cmd);
+s8 mt76_connac_get_rate_power_limit(struct mt76_phy *phy,
+ struct ieee80211_channel *chan,
+ struct mt76_power_limits *limits)
+{
+ s8 reg_power, sar_power;
+ int tx_power;
+
+ tx_power = 2 * phy->hw->conf.power_level;
+ if (!tx_power)
+ tx_power = 127;
+
+ reg_power = mt76_connac_get_ch_power(phy, chan, tx_power);
+ sar_power = mt76_get_sar_power(phy, chan, reg_power);
+ return mt76_get_rate_power_limits(phy, chan, limits, sar_power);
+}
+EXPORT_SYMBOL_GPL(mt76_connac_get_rate_power_limit);
+
static int
mt76_connac_mcu_send_ram_firmware(struct mt76_dev *dev,
const struct mt76_connac2_fw_trailer *hdr,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] wifi: mt76: connac: use a helper to cache txpower_cur
From: Sean Wang @ 2026-04-01 18:23 UTC (permalink / raw)
To: nbd, lorenzo.bianconi
Cc: linux-wireless, linux-mediatek, Sean Wang, Devin Wittmayer,
Satadru Pramanik
From: Sean Wang <sean.wang@mediatek.com>
The cached txpower value is derived from the bounded channel power after
applying the chainmask path delta.
Use a helper for that conversion so callers do not open-code it.
Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Closes: https://lore.kernel.org/linux-wireless/20260130215839.53270-1-lucid_duck@justthetip.ca/
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Tested-by: Satadru Pramanik <satadru@gmail.com>
Co-developed-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
--
v2:
- Rebased onto the latest mt76 tree
- Added Reported-by, Tested-by, Co-developed-by and Signed-off-by tags
---
drivers/net/wireless/mediatek/mt76/mt76_connac.h | 2 +-
drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c | 9 +++++++++
drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 11 ++++++++---
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac.h b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
index 51423c7740bd..d0953e02810b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
@@ -420,7 +420,7 @@ mt76_connac_mutex_release(struct mt76_dev *dev, struct mt76_connac_pm *pm)
void mt76_connac_gen_ppe_thresh(u8 *he_ppet, int nss, enum nl80211_band band);
int mt76_connac_init_tx_queues(struct mt76_phy *phy, int idx, int n_desc,
int ring_base, void *wed, u32 flags);
-
+void mt76_connac_set_txpower_cur(struct mt76_phy *phy, s8 max_power);
void mt76_connac_write_hw_txp(struct mt76_dev *dev,
struct mt76_tx_info *tx_info,
void *txp_ptr, u32 id);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
index 0339e2e7ab60..b2daa6c7d061 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
@@ -275,6 +275,15 @@ int mt76_connac_init_tx_queues(struct mt76_phy *phy, int idx, int n_desc,
}
EXPORT_SYMBOL_GPL(mt76_connac_init_tx_queues);
+void mt76_connac_set_txpower_cur(struct mt76_phy *phy, s8 max_power)
+{
+ int delta;
+
+ delta = mt76_tx_power_path_delta(hweight16(phy->chainmask));
+ phy->txpower_cur = max_power - delta;
+}
+EXPORT_SYMBOL_GPL(mt76_connac_set_txpower_cur);
+
#define __bitrate_mask_check(_mcs, _mode) \
({ \
u8 i = 0; \
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
index 89bd52ea8bf7..897b065a2be6 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
@@ -2223,14 +2223,19 @@ mt76_connac_mcu_rate_txpower_band(struct mt76_phy *phy,
.hw_value = ch_list[idx],
.band = band,
};
- s8 reg_power, sar_power;
+ s8 reg_power, sar_power, max_power;
reg_power = mt76_connac_get_ch_power(phy, &chan,
tx_power);
sar_power = mt76_get_sar_power(phy, &chan, reg_power);
- mt76_get_rate_power_limits(phy, &chan, limits,
- sar_power);
+ max_power = mt76_get_rate_power_limits(phy, &chan, limits,
+ sar_power);
+
+ if (phy->chandef.chan &&
+ phy->chandef.chan->hw_value == ch_list[idx] &&
+ phy->chandef.chan->band == band)
+ mt76_connac_set_txpower_cur(phy, max_power);
tx_power_tlv.last_msg = ch_list[idx] == last_ch;
sku_tlbv.channel = ch_list[idx];
--
2.43.0
^ permalink raw reply related
* Re: [PATCH rtw-next 00/12] wifi: rtw89: Add support for RTL8922AU
From: Bitterblue Smith @ 2026-04-01 17:43 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless@vger.kernel.org
In-Reply-To: <25781f4aa6cc427caf396374ca46d380@realtek.com>
On 30/03/2026 05:53, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> Often one or more of these messages appears when the chip powers on:
>>
>> [ +2.167037] rtw89_8922au 1-2:1.0: failed to wait RF DACK
>>
>> [ +2.942749] rtw89_8922au 1-2:1.0: failed to wait RF TSSI
>>
>> [ +0.019006] rtw89_8922au 2-4:1.0: failed to wait RF PRE_NTFY
>>
>> [ +5.985900] rtw89_8922au 2-4:1.0: failed to wait RF DPK
>>
>> It's unclear why.
>
> RTL8922D done RF calibrations by firmware one by one, so driver should
> wait for previous one done, and trigger next one. However, it'd be
> well to just do waiting at the last to wait for all calibrations.
>
> Try to enlarge waiting time in rtw8922a_rfk_channel().
>
I was convinced I tried that already, but no.
After increasing all delays a bit the warnings are much more rare.
>>
>> It seems to work well anyway.
>>
>
> If you can yield the highest rate (MCS13), I'd say it is fine.
>
> Ping-Ke
>
Testing with RTL8832CU (Brostrend AX8) in AP mode, the RTL8912AU can
reach 1.5 Gbps (MCS10) RX, 1 Gbps TX.
I used the RTL8832CU because my router is not working well with 160
MHz.
^ permalink raw reply
* [PATCH] mac80211_hwsim: change hwsim_class to a const struct
From: Jori Koolstra @ 2026-04-01 16:59 UTC (permalink / raw)
To: Johannes Berg
Cc: Jori Koolstra, Greg Kroah-Hartman, open list:MAC80211, open list
The class_create() call has been deprecated in favor of class_register()
as the driver core now allows for a struct class to be in read-only
memory. Change hwsim_class to be a const struct class and drop the
class_create() call.
Link: https://lore.kernel.org/all/2023040244-duffel-pushpin-f738@gregkh/
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
---
drivers/net/wireless/virtual/mac80211_hwsim.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index e89173f91637..506f865075b1 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -337,7 +337,9 @@ static inline void hwsim_net_set_wmediumd(struct net *net, u32 portid)
hwsim_net->wmediumd = portid;
}
-static struct class *hwsim_class;
+static const struct class hwsim_class = {
+ .name = "mac80211_hwsim"
+};
static struct net_device *hwsim_mon; /* global monitor netdev */
@@ -5424,7 +5426,7 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,
data = hw->priv;
data->hw = hw;
- data->dev = device_create(hwsim_class, NULL, 0, hw, "hwsim%d", idx);
+ data->dev = device_create(&hwsim_class, NULL, 0, hw, "hwsim%d", idx);
if (IS_ERR(data->dev)) {
printk(KERN_DEBUG
"mac80211_hwsim: device_create failed (%ld)\n",
@@ -5978,7 +5980,7 @@ static void mac80211_hwsim_free(void)
spin_lock_bh(&hwsim_radio_lock);
}
spin_unlock_bh(&hwsim_radio_lock);
- class_destroy(hwsim_class);
+ class_unregister(&hwsim_class);
}
static const struct net_device_ops hwsim_netdev_ops = {
@@ -7083,11 +7085,9 @@ static int __init init_mac80211_hwsim(void)
if (err)
goto out_exit_netlink;
- hwsim_class = class_create("mac80211_hwsim");
- if (IS_ERR(hwsim_class)) {
- err = PTR_ERR(hwsim_class);
+ err = class_register(&hwsim_class);
+ if (err)
goto out_exit_virtio;
- }
hwsim_init_s1g_channels(hwsim_channels_s1g);
base-commit: d466c332e106fe666d1e2f5a24d08e308bebbfa1
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/6] Deprecate Legacy IP
From: Bjoern A. Zeeb @ 2026-04-01 16:35 UTC (permalink / raw)
To: David Woodhouse
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Nikolay Aleksandrov, Ido Schimmel,
Martin KaFai Lau, Daniel Borkmann, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Andrii Nakryiko,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Johannes Berg, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Guillaume Nault, David Woodhouse, Kees Cook,
Alexei Lazar, Gal Pressman, Paul Moore, netdev, linux-rdma,
linux-kernel, oss-drivers, bridge, bpf, linux-wireless,
netfilter-devel, coreteam, torvalds, jon.maddog.hall
In-Reply-To: <20260401074509.1897527-1-dwmw2@infradead.org>
On 4/1/26 07:44, David Woodhouse wrote:
Hi David,
(fun fishing this out from nntp.lore.kernel.org needing NAT64)
> RFC1883, the IPv6 standard, was published in the final decade of the 1900s.
> That's closer in time to the Apollo 11 moon landing than it was to today.
>
> Even our esteemed Maddog has worked with computers for longer in the IPv6
> era, than he ever did before it.
>
> Yet Linux still can't even be *built* with only IPv6 support and without
> support for Legacy IP. This long overdue patch series fixes that, and
> ...
This is very interesting; I'll be happy to read the more serious
discussions for 6/6 this year then :)
That said, I've been there 15 years ago and done that for real,
just not for Linux:
https://freebsdfoundation.org/blog/freebsd-foundation-and-ixsystems-announce-ipv6-only-testing-versions-of-freebsd-and-pc-bsd/
A lot of parts (e.g., PC-BSD,the IPv6-only snapshots we published
back then, websites) are long gone, but FreeBSD today still has NO-INET
(as well as NO-INET6 and NO-IP) kernel configs which are regularly tested
as part of a universe build to make sure the status-quo stayed, along with
options to build (large parts) of userspace without IPv4 support.
I have since run real IPv6-only machines :]]
EAFNOSUPPORT and EPROTONOSUPPORT are (were) a good friend of mine.
It helped a lot back then to find applications which had real trouble
working without IPv4.
It was fun sitting in a UKNOF presentation years later to hear about
all these applications just working on IPv6-only and knowing why, whereas
the presenter was unaware, and still had a 127.1 on his loopback *sigh*
IPv6-only is something a lot of people will not understand and someone
just has to do it! It is a worthwhile goal, even if late, as you say.
My reminder to people these days is: DNSsec is even older than IPv6.
I have moved on (though would love to go back to more IPv6);
please feel free to get in touch in case you want me to go and swap in
some more memories from that time to share experience and help.
To the global deployment of IPv6!
/bz
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: Linus Torvalds @ 2026-04-01 16:25 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Woodhouse, Eric Dumazet, Saeed Mahameed, Leon Romanovsky,
Tariq Toukan, Mark Bloch, Andrew Lunn, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman, Nikolay Aleksandrov,
Ido Schimmel, Martin KaFai Lau, Daniel Borkmann, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Andrii Nakryiko,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Johannes Berg, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Guillaume Nault, Kees Cook, Alexei Lazar,
Gal Pressman, Paul Moore, netdev, linux-rdma, linux-kernel,
oss-drivers, bridge, bpf, linux-wireless, netfilter-devel,
coreteam
In-Reply-To: <20260401080657.70cd9bd1@phoenix.local>
On Wed, 1 Apr 2026 at 08:07, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Wed, 01 Apr 2026 10:28:23 +0100
> David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > Maybe on this date next year, we could make it not possible to build
> > the kernel *without* IPv6... ?
>
> There are some government agencies that used to require that IPV6 was disabled
> for security reasons. Yes they had broken old firewalls
I think you missed the big clue here. "This date".
Sigh. It's going to be a long long day.
Linus
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: Stanislav Fomichev @ 2026-04-01 16:20 UTC (permalink / raw)
To: David Woodhouse
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Nikolay Aleksandrov, Ido Schimmel,
Martin KaFai Lau, Daniel Borkmann, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Andrii Nakryiko,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Johannes Berg, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Guillaume Nault, David Woodhouse, Kees Cook,
Alexei Lazar, Gal Pressman, Paul Moore, netdev, linux-rdma,
linux-kernel, oss-drivers, bridge, bpf, linux-wireless,
netfilter-devel, coreteam, torvalds, jon.maddog.hall
In-Reply-To: <20260401074509.1897527-7-dwmw2@infradead.org>
On 04/01, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> There is no need to listen on AF_INET sockets; a modern application can
> listen on IPv6 (without IPV6_V6ONLY) and will accept connections from
> the 20th century via IPv4-mapped addresses (::ffff:x.x.x.x) on the IPv6
> socket.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> net/ipv4/af_inet.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index dc358faa1647..3838782a8437 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -240,6 +240,9 @@ int inet_listen(struct socket *sock, int backlog)
> struct sock *sk = sock->sk;
> int err = -EINVAL;
>
> + pr_warn_once("process '%s' (pid %d) is listening on an AF_INET socket. Consider using AF_INET6 with IPV6_V6ONLY=0 instead.\n",
> + current->comm, task_pid_nr(current));
> +
> lock_sock(sk);
>
> if (sock->state != SS_UNCONNECTED || sock->type != SOCK_STREAM)
> --
> 2.51.0
>
Does this also need to look at the proto? inet6_stream_ops seem to be
using inet_listen as well.
const struct proto_ops inet6_stream_ops = {
.family = PF_INET6,
.owner = THIS_MODULE,
.release = inet6_release,
.bind = inet6_bind,
.connect = inet_stream_connect, /* ok */
.socketpair = sock_no_socketpair, /* a do nothing */
.accept = inet_accept, /* ok */
.getname = inet6_getname,
.poll = tcp_poll, /* ok */
.ioctl = inet6_ioctl, /* must change */
.gettstamp = sock_gettstamp,
.listen = inet_listen, /* ok */
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: Stephen Hemminger @ 2026-04-01 15:06 UTC (permalink / raw)
To: David Woodhouse
Cc: Eric Dumazet, Saeed Mahameed, Leon Romanovsky, Tariq Toukan,
Mark Bloch, Andrew Lunn, David S. Miller, Jakub Kicinski,
Paolo Abeni, Simon Horman, Nikolay Aleksandrov, Ido Schimmel,
Martin KaFai Lau, Daniel Borkmann, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Andrii Nakryiko,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Johannes Berg, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Guillaume Nault, Kees Cook, Alexei Lazar,
Gal Pressman, Paul Moore, netdev, linux-rdma, linux-kernel,
oss-drivers, bridge, bpf, linux-wireless, netfilter-devel,
coreteam, torvalds
In-Reply-To: <252823d75e9221647e7f8ccef6105432aabe8d6f.camel@infradead.org>
On Wed, 01 Apr 2026 10:28:23 +0100
David Woodhouse <dwmw2@infradead.org> wrote:
> > Some kernels are built without CONFIG_IPV6, so this warning would be
> > quite misleading.
>
> Maybe on this date next year, we could make it not possible to build
> the kernel *without* IPv6... ?
There are some government agencies that used to require that IPV6 was disabled
for security reasons. Yes they had broken old firewalls
^ permalink raw reply
* 0x1A: Dates And Location for upcoming conference
From: Jamal Hadi Salim @ 2026-04-01 13:30 UTC (permalink / raw)
To: people
Cc: Linux Kernel Network Developers, Christie Geldart,
Kimberley Jeffries, LWN, board@netdevconf.org, linux-wireless,
netfilter-devel, lartc, Stefano Salsano, Andrea Mayer,
Carlo Filippi
Hi,
This is a pre-announcement so folks can plan travel etc.
Netdev conf 0x1A will be a hybrid conference. We will update you with
the exact coordinates in the near future.
Either watch https://netdevconf.info/0x1A/ or join people@ mailing
list[1] for more frequent updates.
Netdev 0x1A is scheduled to be in Rome - Italy July 13th-16th.
Location: Università Roma TRE - Via Ostiense, 236, 00144 Rome RM, Italy
Be ready to share your work with the community. CFS coming soon.
sincerely,
Netdev Society Board:
PJ, Roopa Prabhu, Shrijeet Mukherjee, Tom Herbert, Jamal Hadi Salim
[1] https://lists.netdevconf.info/postorius/lists/people.netdevconf.info/
^ permalink raw reply
* RE: wifi: rtw89: rtw8922ae: HWSI bus lockup during RF recalibration on AP bandwidth change
From: Jeffrey Wälti @ 2026-04-01 11:24 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <f387614466ce497fb59d4ad98ef641f5@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> Jeffrey Wälti <jeffrey@waelti.dev> wrote:
> >
> > <pkshih@realtek.com> wrote:
> >
> > >
> > > Please try to disable power save and ASPM by
> > > 1) iw wlan0 set power_save off
I'm sorry, this is my first time interacting with the mailing list and I overlooked the other instructions. It seems like disabling power save gets rid of the issue of Wi-Fi timeouts. I haven't been able to reproduce the issue with `iw wlan0 set power_save off` yet, even without any of the other fixes on kernel 6.19.10 and 7.0-rc6.
> > > 2) reference and install
> > https://github.com/lwfinger/rtw89/blob/main/70-rtw89.conf
> > > and then cold reboot.
>
> Have you tested with these conditions?
Using this patch eliminates the issue of Bluetooth devices disconnecting, when switching between networks.
> [...]
>
> > >
> > > Please help to test the latest kernel 7.0-rc with additional patch [1].
> > >
> > > [1]
> > https://lore.kernel.org/linux-wireless/20260310080146.31113-4-pkshih@realtek
> > .com/
>
> Have you also applied this patch?
I tested kernel 7.0-rc6 with this patch applied on top for ~1 day now and haven't been able to reproduce, even with power save enabled. However, it is a bit difficult to reliably trigger the issue as it seems to trigger more on certain networks than others etc.
> > >
> > > Ping-Ke
> > >
> > >
> >
> > Thank you for coming back to me so quickly, I just encountered the same thing
> > with kernel 7.0-rc5.
> >
>
> Please confirm my questions above.
>
> Ping-Ke
>
>
In summary:
- Disabling power save seems to stop the timeouts but Bluetooth issues remain
- Disabling ASPM features fixes the Bluetooth issue
- kernel 7.0-rc6 with the additional patch fixes Wi-Fi timeouts but not the Bluetooth disconnects
I hope that answers your questions.
Jeffrey
^ permalink raw reply
* Re: [PATCH 3/6] net: Guard Legacy IP entry points with CONFIG_LEGACY_IP
From: bot+bpf-ci @ 2026-04-01 9:38 UTC (permalink / raw)
To: dwmw2, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, razor, idosch, martin.lau, daniel,
john.fastabend, sdf, ast, andrii, eddyz87, song, yonghong.song,
kpsingh, haoluo, jolsa, kuniyu, willemb, dsahern, ncardwell,
johannes, pablo, fw, phil, gnault, dwmw, kees, alazar, gal, paul,
netdev, linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260401074509.1897527-4-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1922,7 +1922,15 @@ static int __init inet_init(void)
> /*
> * Tell SOCKET that we are alive...
> */
> + /* Initialize the socket-side protocol switch tables. */
> + for (r = &inetsw[0]; r < &inetsw[SOCK_MAX]; ++r)
> + INIT_LIST_HEAD(r);
> +
> +#ifdef CONFIG_XFRM
> + xfrm_init();
> +#endif
>
> +#ifdef CONFIG_LEGACY_IP
> (void)sock_register(&inet_family_ops);
Moving xfrm_init() here places it before sock_register(), but
xfrm_init() calls xfrm_nat_keepalive_init(AF_INET) which creates
per-cpu PF_INET sockets via this chain:
xfrm_init()
xfrm_nat_keepalive_init(AF_INET)
nat_keepalive_sk_init(&nat_keepalive_sk_ipv4, PF_INET)
inet_ctl_sock_create(&sk, PF_INET, ...)
sock_create_kern()
__sock_create()
pf = rcu_dereference(net_families[PF_INET]);
if (!pf) -> returns -EAFNOSUPPORT
Since sock_register(&inet_family_ops) has not been called yet,
net_families[PF_INET] is still NULL at this point. This causes
xfrm_nat_keepalive_init(AF_INET) to silently fail (the return
value is not checked by xfrm_init()), leaving the IPv4 XFRM NAT
keepalive sockets uninitialized.
This affects the default CONFIG_LEGACY_IP=y configuration as
well, not just IPv6-only builds. Would it be better to leave
xfrm_init() after sock_register(), or move the
xfrm_nat_keepalive_init(AF_INET) call into xfrm4_init() where
it would run after IPv4 socket registration is complete?
Previously, xfrm_init() was called from ip_rt_init() which ran
well after sock_register():
inet_init()
sock_register(&inet_family_ops) <-- AF_INET available
...
ip_init()
ip_rt_init()
xfrm_init() <-- worked fine
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23838411859
^ permalink raw reply
* Re: [PATCH 3/6] net: Guard Legacy IP entry points with CONFIG_LEGACY_IP
From: David Woodhouse @ 2026-04-01 9:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
Kees Cook, Alexei Lazar, Gal Pressman, Paul Moore, netdev,
linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds
In-Reply-To: <CANn89i+iRUgqtd+eirfSUM3k+keNZKzLwsHxZtwE+vHdv7H5PQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Wed, 2026-04-01 at 02:14 -0700, Eric Dumazet wrote:
>
> >
> > /* Add UDP-Lite (RFC 3828) */
> > - udplite4_register();
> > + if (IS_ENABLED(CONFIG_LEGACY_IP))
> > + udplite4_register();
>
> udplite has been removed in net-next.
>
> I would think your patch series is net-next material ?
A more conservative variant of the patch series on another day of the
year, sure. It also probably wants to land after
https://lore.kernel.org/lkml/20260310153506.5181-1-fmancera@suse.de/
turns CONFIG_IPV6 into a boolean.
I'll need to take a closer look at CONFIG_INET too; it ends up being
possible to configure with INET && !LEGACY_IP && !IPV6 which isn't a
combination that makes sense (and I obviously didn't test).
As discussed, some of this series *is* realistic for another day, and
I'll happily work on whatever direction we think makes sense.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: David Woodhouse @ 2026-04-01 9:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
Kees Cook, Alexei Lazar, Gal Pressman, Paul Moore, netdev,
linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds
In-Reply-To: <CANn89i+GHkkubJp3MTKZ_r4tde1qLejfsxUh+w0gPZ3ec+YdjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On Wed, 2026-04-01 at 02:11 -0700, Eric Dumazet wrote:
> On Wed, Apr 1, 2026 at 12:45 AM David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > There is no need to listen on AF_INET sockets; a modern application can
> > listen on IPv6 (without IPV6_V6ONLY) and will accept connections from
> > the 20th century via IPv4-mapped addresses (::ffff:x.x.x.x) on the IPv6
> > socket.
> >
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > ---
> > net/ipv4/af_inet.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> > index dc358faa1647..3838782a8437 100644
> > --- a/net/ipv4/af_inet.c
> > +++ b/net/ipv4/af_inet.c
> > @@ -240,6 +240,9 @@ int inet_listen(struct socket *sock, int backlog)
> > struct sock *sk = sock->sk;
> > int err = -EINVAL;
> >
> > + pr_warn_once("process '%s' (pid %d) is listening on an AF_INET socket. Consider using AF_INET6 with IPV6_V6ONLY=0 instead.\n",
> > + current->comm, task_pid_nr(current));
> > +
>
> Some kernels are built without CONFIG_IPV6, so this warning would be
> quite misleading.
Maybe on this date next year, we could make it not possible to build
the kernel *without* IPv6... ?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: bot+bpf-ci @ 2026-04-01 9:26 UTC (permalink / raw)
To: dwmw2, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, razor, idosch, martin.lau, daniel,
john.fastabend, sdf, ast, andrii, eddyz87, song, yonghong.song,
kpsingh, haoluo, jolsa, kuniyu, willemb, dsahern, ncardwell,
johannes, pablo, fw, phil, gnault, dwmw, kees, alazar, gal, paul,
netdev, linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260401074509.1897527-7-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index dc358faa1647..3838782a8437 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -240,6 +240,9 @@ int inet_listen(struct socket *sock, int backlog)
> struct sock *sk = sock->sk;
> int err = -EINVAL;
>
> + pr_warn_once("process '%s' (pid %d) is listening on an AF_INET socket. Consider using AF_INET6 with IPV6_V6ONLY=0 instead.\n",
> + current->comm, task_pid_nr(current));
inet_listen() is the .listen handler for both inet_stream_ops
(AF_INET) and inet6_stream_ops (AF_INET6):
net/ipv4/af_inet.c:
.listen = inet_listen,
net/ipv6/af_inet6.c:
.listen = inet_listen, /* ok */
Since pr_warn_once fires on the first listen() call regardless of
address family, won't this warn about "listening on an AF_INET
socket" when an AF_INET6 socket calls listen() first? Many services
(e.g. systemd socket activation) create AF_INET6 sockets before
AF_INET ones. Should there be a check for sk->sk_family == AF_INET
before printing?
Separately, the warning suggests using AF_INET6 with IPV6_V6ONLY=0,
but when CONFIG_IPV6 is disabled, AF_INET6 sockets are not available.
Should the warning be conditional on IS_ENABLED(CONFIG_IPV6)?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23838411859
^ permalink raw reply
* Re: [PATCH 3/6] net: Guard Legacy IP entry points with CONFIG_LEGACY_IP
From: Eric Dumazet @ 2026-04-01 9:14 UTC (permalink / raw)
To: David Woodhouse
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
David Woodhouse, Kees Cook, Alexei Lazar, Gal Pressman,
Paul Moore, netdev, linux-rdma, linux-kernel, oss-drivers, bridge,
bpf, linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
In-Reply-To: <20260401074509.1897527-4-dwmw2@infradead.org>
On Wed, Apr 1, 2026 at 12:45 AM David Woodhouse <dwmw2@infradead.org> wrote:
>
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> Wrap the IPv4-specific registrations in inet_init() with
> CONFIG_LEGACY_IP guards. When LEGACY_IP is disabled, the kernel
> will not:
> - Register the AF_INET socket family
> - Register the ETH_P_IP packet handler (ip_rcv)
> - Initialize ARP, ICMP, IGMP, or IPv4 routing
> - Register IPv4 protocol handlers (TCP/UDP/ICMP over IPv4)
> - Initialize IPv4 multicast routing, proc entries, or fragmentation
>
> The shared INET infrastructure (tcp_prot, udp_prot, tcp_init, etc.)
> remains initialized for use by IPv6.
>
...
>
> /* Add UDP-Lite (RFC 3828) */
> - udplite4_register();
> + if (IS_ENABLED(CONFIG_LEGACY_IP))
> + udplite4_register();
udplite has been removed in net-next.
I would think your patch series is net-next material ?
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: Eric Dumazet @ 2026-04-01 9:11 UTC (permalink / raw)
To: David Woodhouse
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
David Woodhouse, Kees Cook, Alexei Lazar, Gal Pressman,
Paul Moore, netdev, linux-rdma, linux-kernel, oss-drivers, bridge,
bpf, linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
In-Reply-To: <20260401074509.1897527-7-dwmw2@infradead.org>
On Wed, Apr 1, 2026 at 12:45 AM David Woodhouse <dwmw2@infradead.org> wrote:
>
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> There is no need to listen on AF_INET sockets; a modern application can
> listen on IPv6 (without IPV6_V6ONLY) and will accept connections from
> the 20th century via IPv4-mapped addresses (::ffff:x.x.x.x) on the IPv6
> socket.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> net/ipv4/af_inet.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index dc358faa1647..3838782a8437 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -240,6 +240,9 @@ int inet_listen(struct socket *sock, int backlog)
> struct sock *sk = sock->sk;
> int err = -EINVAL;
>
> + pr_warn_once("process '%s' (pid %d) is listening on an AF_INET socket. Consider using AF_INET6 with IPV6_V6ONLY=0 instead.\n",
> + current->comm, task_pid_nr(current));
> +
Some kernels are built without CONFIG_IPV6, so this warning would be
quite misleading.
^ permalink raw reply
* Re: [PATCH 5/6] net: Change CONFIG_INET to CONFIG_LEGACY_IP for IPv4-only code
From: bot+bpf-ci @ 2026-04-01 9:01 UTC (permalink / raw)
To: dwmw2, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, razor, idosch, martin.lau, daniel,
john.fastabend, sdf, ast, andrii, eddyz87, song, yonghong.song,
kpsingh, haoluo, jolsa, kuniyu, willemb, dsahern, ncardwell,
johannes, pablo, fw, phil, gnault, dwmw, kees, alazar, gal, paul,
netdev, linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260401074509.1897527-6-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
> diff --git a/net/core/filter.c b/net/core/filter.c
> index ad71ceefcb5e..ef99bd9fddd6 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
[ ... ]
> @@ -6095,7 +6095,7 @@ static int bpf_fib_set_fwd_params(struct bpf_fib_lookup *params, u32 mtu)
> }
> #endif
>
> -#if IS_ENABLED(CONFIG_INET)
> +#if IS_ENABLED(CONFIG_LEGACY_IP)
> static int bpf_ipv4_fib_lookup(struct net *net, struct bpf_fib_lookup *params,
> u32 flags, bool check_mtu)
bpf_fib_set_fwd_params() above this hunk is still guarded by
CONFIG_INET, and its only two callers are bpf_ipv4_fib_lookup()
(now CONFIG_LEGACY_IP) and bpf_ipv6_fib_lookup() (CONFIG_IPV6).
When CONFIG_INET=y with both CONFIG_LEGACY_IP=n and CONFIG_IPV6=n,
bpf_fib_set_fwd_params() becomes an unused static function, which
will produce a -Wunused-function warning and break CONFIG_WERROR
builds.
Should the guard on bpf_fib_set_fwd_params() be changed to
something like:
#if IS_ENABLED(CONFIG_LEGACY_IP) || IS_ENABLED(CONFIG_IPV6)
to match its actual callers?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23838411859
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox