* [PATCH v2] arm64: dts: mediatek: mt7988a-bananapi-bpi-r4: add ramoops region
From: Martino Dell'Ambrogio @ 2026-05-28 12:36 UTC (permalink / raw)
To: matthias.bgg, angelogioacchino.delregno
Cc: kees, tony.luck, gpiccoli, linux-mediatek, linux-arm-kernel,
devicetree, linux-kernel, Martino Dell'Ambrogio
In-Reply-To: <20260528093038.1945245-1-tillo@tillo.ch>
Reserve 1 MiB of RAM just below the ARM Trusted Firmware secmon region
(0x42f00000-0x43000000) for persistent kernel log storage via pstore/ramoops,
allowing post-panic console output and oops dumps to be recovered after a
reboot. Without it, kernel crash logs on this board are lost when the SoC
warm-resets and the on-chip console buffer is reinitialised.
With record-size=128 KiB, console-size=256 KiB, ftrace-size=64 KiB and
pmsg-size=64 KiB, ramoops_probe() carves the post-console remainder
(640 KiB) into five 128 KiB kmsg records, with the requested ecc-size=16
reserving a small Reed-Solomon parity block from each zone's own
allocation (per persistent_ram_new()). The ECC lets pstore recover dumps
even when the panic path truncates writes mid-record.
The no-map property is required so the reserved region is kept out of the
kernel linear map. ramoops remaps the carve-out write-combine via
ioremap_wc(); on arm64, leaving the same physical RAM mapped cacheable in
the linear map at the same time is an attribute-mismatch and risks losing
panic data to dirty cache evictions from the linear alias.
The carve-out sits immediately below the ATF region already declared at
0x43000000 in mt7988a.dtsi, so no other reserved-memory child is moved or
resized. BPI-R4 ships with at least 4 GiB of DRAM starting at 0x40000000,
so the region is well within installed memory on every variant.
For the carve-out to actually preserve content across a reset, the boot
loader must also avoid touching this region on warm reset; on standard
BPI-R4 boards with the stock OpenWrt U-Boot fork this already holds.
Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>
---
Changes in v2:
- Add no-map; to keep the carve-out out of the kernel linear map and
avoid the cacheable/write-combine attribute mismatch on arm64.
(sashiko-bot, gemini-3.1-pro)
- Rewrite the ECC paragraph in the commit log: ramoops carves ecc-size
from each zone's own allocation in persistent_ram_new() and the
post-console remainder is split into record-size'd kmsg records, not
one record plus a separate ECC pool. (sashiko-bot, gemini-3.1-pro)
v1: https://lore.kernel.org/all/20260528093038.1945245-1-tillo@tillo.ch/
.../boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
index 0ff69da..f7d4944 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
@@ -80,6 +80,19 @@ sfp1: sfp1 {
};
};
+&{/reserved-memory} {
+ ramoops@42f00000 {
+ compatible = "ramoops";
+ reg = <0 0x42f00000 0 0x100000>;
+ no-map;
+ record-size = <0x20000>;
+ console-size = <0x40000>;
+ ftrace-size = <0x10000>;
+ pmsg-size = <0x10000>;
+ ecc-size = <16>;
+ };
+};
+
&cci {
proc-supply = <&rt5190_buck3>;
};
--
2.47.3
^ permalink raw reply related
* [PATCH] arm64: dts: mediatek: mt7986a-bananapi-bpi-r3: add ramoops region
From: Martino Dell'Ambrogio @ 2026-05-28 9:30 UTC (permalink / raw)
To: matthias.bgg, angelogioacchino.delregno
Cc: kees, tony.luck, gpiccoli, linux-mediatek, linux-arm-kernel,
devicetree, linux-kernel, Martino Dell'Ambrogio
Reserve 64 KiB of RAM just below the ARM Trusted Firmware secmon region
(0x42ff0000-0x43000000) for persistent kernel log storage via pstore/ramoops,
allowing post-panic console output and oops dumps to be recovered after a
warm reset. Without it, kernel crash logs on this board are lost when the
SoC reboots.
The carve-out is divided into 8 KiB kmsg records, a 32 KiB rolling console,
8 KiB ftrace, and 8 KiB pmsg, leaving the remainder for the per-record
Reed-Solomon ECC parity (ecc-size=16) which significantly improves dump
readability when the panic path truncates writes mid-record.
The region sits immediately below the ATF block already declared at
0x43000000 in mt7986a.dtsi, so no other reserved-memory child is moved or
resized. BPI-R3 ships with 2 GiB of DRAM starting at 0x40000000, well above
0x43000000, so the region is always within installed memory.
For the carve-out to actually preserve content across a reset, the boot
loader must avoid touching this region on warm reset; on standard BPI-R3
boards with the stock OpenWrt U-Boot fork this already holds.
Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>
---
.../boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
index 19f538d..31ee189 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
@@ -140,6 +140,18 @@ sfp2: sfp-2 {
};
};
+&{/reserved-memory} {
+ ramoops@42ff0000 {
+ compatible = "ramoops";
+ reg = <0 0x42ff0000 0 0x10000>;
+ record-size = <0x2000>;
+ console-size = <0x8000>;
+ ftrace-size = <0x2000>;
+ pmsg-size = <0x2000>;
+ ecc-size = <16>;
+ };
+};
+
&cpu_thermal {
cooling-maps {
map-cpu-active-high {
--
2.47.3
^ permalink raw reply related
* [PATCH] arm64: dts: mediatek: mt7988a-bananapi-bpi-r4: add ramoops region
From: Martino Dell'Ambrogio @ 2026-05-28 9:28 UTC (permalink / raw)
To: matthias.bgg, angelogioacchino.delregno
Cc: kees, tony.luck, gpiccoli, linux-mediatek, linux-arm-kernel,
devicetree, linux-kernel, Martino Dell'Ambrogio
Reserve 1 MiB of RAM just below the ARM Trusted Firmware secmon region
(0x42f00000-0x43000000) for persistent kernel log storage via pstore/ramoops,
allowing post-panic console output and oops dumps to be recovered after a
reboot. Without it, kernel crash logs on this board are lost when the SoC
warm-resets and the on-chip console buffer is reinitialised.
The record sizes (128 KiB kmsg records, 256 KiB rolling console, 64 KiB
ftrace, 64 KiB pmsg) sum to 512 KiB; the remainder of the 1 MiB carve-out
is used for the ECC parity blocks (ecc-size=16, one Reed-Solomon block per
record) which significantly improves dump readability when the panic path
truncates writes mid-record.
The carve-out sits immediately below the ATF region already declared at
0x43000000 in mt7988a.dtsi, so no other reserved-memory child is moved or
resized. BPI-R4 ships with at least 4 GiB of DRAM starting at 0x40000000,
so the region is well within installed memory on every variant.
For the carve-out to actually preserve content across a reset, the boot
loader must also avoid touching this region on warm reset; on standard
BPI-R4 boards with the stock OpenWrt U-Boot fork this already holds.
Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>
---
.../boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
index 0ff69da..f7d4944 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi
@@ -80,6 +80,18 @@ sfp1: sfp1 {
};
};
+&{/reserved-memory} {
+ ramoops@42f00000 {
+ compatible = "ramoops";
+ reg = <0 0x42f00000 0 0x100000>;
+ record-size = <0x20000>;
+ console-size = <0x40000>;
+ ftrace-size = <0x10000>;
+ pmsg-size = <0x10000>;
+ ecc-size = <16>;
+ };
+};
+
&cci {
proc-supply = <&rt5190_buck3>;
};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/4] ASoC: codecs: mt6357: Drop unused assignment of platform_device_id driver data
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-28 9:06 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Jaroslav Kysela, Takashi Iwai, Matthias Brugger,
AngeloGioacchino Del Regno, Charles Keepax, Kuninori Morimoto,
linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1779958164.git.u.kleine-koenig@baylibre.com>
The driver explicitly set the .driver_data member of struct
platform_device_id to zero without relying on that value. Drop this
unused assignments.
While touching this array unify spacing, use a named initializer for
.name and drop a trailing comma after the list terminator.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
sound/soc/codecs/mt6357.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/mt6357.c b/sound/soc/codecs/mt6357.c
index 674cf7df9df4..3b07087e1cab 100644
--- a/sound/soc/codecs/mt6357.c
+++ b/sound/soc/codecs/mt6357.c
@@ -1834,8 +1834,8 @@ static int mt6357_platform_driver_probe(struct platform_device *pdev)
}
static const struct platform_device_id mt6357_platform_ids[] = {
- {"mt6357-sound", 0},
- { /* sentinel */ },
+ { .name = "mt6357-sound" },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(platform, mt6357_platform_ids);
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/4] ASoC: Use named initializers for platform_device_id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-28 9:05 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Jaroslav Kysela, Takashi Iwai, Matthias Brugger,
AngeloGioacchino Del Regno, Charles Keepax, Kuninori Morimoto,
linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-renesas-soc, Vijendar Mukunda, Venkata Prasad Potturu,
James Ogletree, Fred Treven, Ben Bright, David Rhodes,
Richard Fitzgerald, Cezary Rojewski, Peter Ujfalusi, Bard Liao,
Kai Vehmanen, Pierre-Louis Bossart, Syed Saba Kareem,
Mario Limonciello (AMD), Krzysztof Kozlowski, Mark Pearson,
Hasun Park, Li Qiang, Kees Cook, Ranjani Sridharan, Mac Chiang,
Maciej Strozek, patches, Lars-Peter Clausen, Nuno Sá,
Srinivas Kandagatla, Shengjiu Wang, Xiubo Li, Fabio Estevam,
Nicolin Chen, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Guilherme G. Piccoli, Mario Limonciello, Cristian Ciocaltea,
Amadeusz Sławiński, linux-arm-msm, linuxppc-dev, imx
Hello,
this series targets to use named initializers for platform_device_id
arrays. In general these are better readable for humans and more robust
to changes in the respective struct definition.
This robustness is needed as I want to do
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -610,4 +610,7 @@ struct dmi_system_id {
struct platform_device_id {
char name[PLATFORM_NAME_SIZE];
- kernel_ulong_t driver_data;
+ union {
+ kernel_ulong_t driver_data;
+ const void *driver_data_ptr;
+ };
};
which allows dropping several casts and eases porting CHERI to mainline
linux. When adapting e.g. sound/soc/amd/acp/acp-legacy-mach.c to that
and make use of driver_data_ptr, the added const makes it obvious that
acp_asoc_probe() modifies the structs linked in the id_table resulting
in issues if more than one device is probed using the same platform id.
sound/soc/amd/acp/acp-sof-mach.c has the same issue.
If you consider the last patch mostly churn, just drop it.
Best regards
Uwe
Uwe Kleine-König (The Capable Hub) (4):
ASoC: codecs: mt6357: Drop unused assignment of platform_device_id
driver data
ASoC: renesas: fsi: Simplify driver_data handling
ASoC: Use named initializers for platform_device_id arrays
ASOC: Unify code style for platform_device_id arrays
sound/soc/amd/acp/acp-sdw-legacy-mach.c | 4 ++--
sound/soc/amd/acp/acp-sdw-sof-mach.c | 4 ++--
sound/soc/amd/acp/acp-sof-mach.c | 14 +++++++-------
sound/soc/codecs/adau7118-hw.c | 2 +-
sound/soc/codecs/bt-sco.c | 10 +++-------
sound/soc/codecs/cs40l50-codec.c | 4 ++--
sound/soc/codecs/cs42l43.c | 4 ++--
sound/soc/codecs/mt6357.c | 4 ++--
sound/soc/codecs/wcd934x.c | 6 ++----
sound/soc/fsl/imx-pcm-rpmsg.c | 6 +++---
sound/soc/intel/avs/boards/da7219.c | 6 ++----
sound/soc/intel/avs/boards/dmic.c | 6 ++----
sound/soc/intel/avs/boards/es8336.c | 6 ++----
sound/soc/intel/avs/boards/hdaudio.c | 6 ++----
sound/soc/intel/avs/boards/i2s_test.c | 6 ++----
sound/soc/intel/avs/boards/max98357a.c | 6 ++----
sound/soc/intel/avs/boards/max98373.c | 6 ++----
sound/soc/intel/avs/boards/max98927.c | 6 ++----
sound/soc/intel/avs/boards/nau8825.c | 6 ++----
sound/soc/intel/avs/boards/pcm3168a.c | 6 ++----
sound/soc/intel/boards/sof_sdw.c | 4 ++--
sound/soc/renesas/fsi.c | 8 +++-----
22 files changed, 51 insertions(+), 79 deletions(-)
base-commit: e7d700e14934e68f86338c5610cf2ae76798b663
--
2.47.3
^ permalink raw reply
* Re: [PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks
From: Chen-Yu Tsai @ 2026-05-28 8:39 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel
In-Reply-To: <CAMRc=Me=ujnscSOKhHDLz+ccMDyLyCfZnpqobF2BJ4YowgXB5A@mail.gmail.com>
On Thu, May 28, 2026 at 10:36 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Wed, 27 May 2026 19:41:30 +0200, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> said:
> > On Wed, May 27, 2026 at 06:21:00PM +0200, Chen-Yu Tsai wrote:
>
> ...
>
> >>
> >> However this seems to completely decouple the power sequencing from the
> >> USB core. Take the USB A connector for example, it was recently added to
> >> the onboard USB devices driver. However the connector has a device node
> >> that is not a child node of any USB host controller or hub; it is connected
> >> through OF graph. At the same time, since it typically sits at the top
> >> level of the device tree, a platform device is directly created and the
> >> driver subsequently binds to that device. This is totally different from
> >> how the hub and other directly connected onboard USB devices work. In
> >> the onboard device case, the device node is a child node of the USB hub
> >> or controller, and the corresponding platform device only gets created
> >> when the USB hub driver probes, thereby sort of tying it into the USB
> >> device topology.
> >
> > Hm, did we mess this up? If so, we can always change it if you think
> > this should be done differently.
> >
> > Hubs should be dealing with the power issues for their ports, so maybe
> > rethinking this might be wise. I'm just loath to add hardware-specific
> > hacks to the hub common code for obvious reasons. Anything we can do to
> > pull it out to a separate driver is best so it doesn't affect the 99% of
> > the users that don't have that crazy hardware :)
> >
>
> IIUC what we discussed with Chen-Yu yesterday, the only thing that needs to be
> done in the USB hub driver is attaching the port firmware nodes (if present) to
> the port devices we instantiate. The rest can be handled elsewhere.
>
> Chen-Yu: correct me if I'm wrong.
The above, plus adding pwrseq_get(), pwrseq_power_on(), pwrseq_power_off()
calls to the appropriate places in the hub driver.
ChenYu
^ permalink raw reply
* Re: [PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks
From: Bartosz Golaszewski @ 2026-05-28 8:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Bartosz Golaszewski, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel, Chen-Yu Tsai
In-Reply-To: <2026052710-flagship-unsmooth-ce82@gregkh>
On Wed, 27 May 2026 19:41:30 +0200, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> said:
> On Wed, May 27, 2026 at 06:21:00PM +0200, Chen-Yu Tsai wrote:
...
>>
>> However this seems to completely decouple the power sequencing from the
>> USB core. Take the USB A connector for example, it was recently added to
>> the onboard USB devices driver. However the connector has a device node
>> that is not a child node of any USB host controller or hub; it is connected
>> through OF graph. At the same time, since it typically sits at the top
>> level of the device tree, a platform device is directly created and the
>> driver subsequently binds to that device. This is totally different from
>> how the hub and other directly connected onboard USB devices work. In
>> the onboard device case, the device node is a child node of the USB hub
>> or controller, and the corresponding platform device only gets created
>> when the USB hub driver probes, thereby sort of tying it into the USB
>> device topology.
>
> Hm, did we mess this up? If so, we can always change it if you think
> this should be done differently.
>
> Hubs should be dealing with the power issues for their ports, so maybe
> rethinking this might be wise. I'm just loath to add hardware-specific
> hacks to the hub common code for obvious reasons. Anything we can do to
> pull it out to a separate driver is best so it doesn't affect the 99% of
> the users that don't have that crazy hardware :)
>
IIUC what we discussed with Chen-Yu yesterday, the only thing that needs to be
done in the USB hub driver is attaching the port firmware nodes (if present) to
the port devices we instantiate. The rest can be handled elsewhere.
Chen-Yu: correct me if I'm wrong.
Bartosz
^ permalink raw reply
* Re: [PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks
From: Bartosz Golaszewski @ 2026-05-28 8:33 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Bartosz Golaszewski, Greg Kroah-Hartman, Manivannan Sadhasivam
In-Reply-To: <CAGXv+5GbW0bx3nKdZt2+tHuHyQ-J-1-Z79nMzHAwjmEPGKT02A@mail.gmail.com>
On Wed, 27 May 2026 18:21:00 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> On Tue, May 26, 2026 at 11:48 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>>
>> On Sun, May 24, 2026 at 10:06 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
>> >
>> > > >
>> > > > I expect some discussion on this patch, because a) it adds some
>> > > > OF-specific code into an otherwise generic (core) driver, and
>> > > > b) it doesn't yet handle USB 2.0 / 3.x shared ports; it ends up powering
>> > > > on the port twice, which negates the port reset part.
>> > > >
>> > >
>> > > I understand that you do this because the port device has no OF node
>> > > assigned. If we wanted to call pwrseq_get() for the port device, is
>> > > there really no other way to associate it with the correct pwrseq
>> > > provider?
>> >
>> > I suppose we could tie the "port@X" node to the usb port device, but
>> > AFAIK no other subsystem does this so we would be introducing a new
>> > pattern.
>> >
>> > In the M.2 pwrseq driver, we would have to match by port node instead
>> > of its parent device node. We may end up with different behavior for
>> > the USB target vs the other targets.
>> >
>>
>> I imagine, we can check the bus type of the parent device to know if
>> this is USB?
>
> The "bus type" type is probably not exported. However since the DT binding
> explicitly says which port on the M.2 slot is for which connection type,
> I think the matching can do a special case check for the USB port.
> The next obstacle is that the target string is not given to the provider
> match function.
>
>> > Also, the "port@X" nodes only exist for the OF graph connections to
>> > connectors and/or muxes (this series doesn't deal with the latter).
>> > For directly connected devices, there is a "device@X" child node
>> > directly under the USB hub node. That node is what gets tied to the
>> > the USB device.
>> >
>>
>> Is this a problem? I don't think I understand what you're saying here.
>
> It shouldn't be. I'm just saying there would be different behavior on
> the USB side for connectors vs onboard devices (like hubs) device nodes.
>
> I talked to Greg earlier, and he said not to touch the hub driver; the
> hub driver should only deal with features from the USB spec. The
> "onboard USB devices" driver is what should be used. And this would
> be a proper case of adding an auxiliary device to the M.2 slot driver.
>
The onboard USB device is what initially inspired the PCI pwrctl code so it
doesn't surprise me we circle back to it.
> However this seems to completely decouple the power sequencing from the
> USB core. Take the USB A connector for example, it was recently added to
> the onboard USB devices driver. However the connector has a device node
> that is not a child node of any USB host controller or hub; it is connected
> through OF graph. At the same time, since it typically sits at the top
> level of the device tree, a platform device is directly created and the
> driver subsequently binds to that device. This is totally different from
> how the hub and other directly connected onboard USB devices work. In
> the onboard device case, the device node is a child node of the USB hub
> or controller, and the corresponding platform device only gets created
> when the USB hub driver probes, thereby sort of tying it into the USB
> device topology.
>
Which is precisely what we do for PCI pwrctl. Though I'm not sure how we could
replicate this behavior without touching the hub driver.
> If the power sequencing ends up not connected to the USB subsystem, then
> maybe the M.2 slot driver could just check if the USB port (port@3) was
> used, and just enable the USB / BT pwrseq target at probe time? That
> would mean less changes needed.
>
That sounds sane to me.
Bartosz
^ permalink raw reply
* [PATCH v2 net] netfilter: flowtable: fix offloaded ct timeout never being extended
From: Adrian Bente @ 2026-05-28 7:08 UTC (permalink / raw)
To: pablo, kadlec, fw, netfilter-devel
Cc: phil, davem, edumazet, kuba, pabeni, horms, nbd, sean.wang,
lorenzo, andrew+netdev, matthias.bgg, angelogioacchino.delregno,
daniel, coreteam, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, Adrian Bente, stable
OpenWrt has recently migrated many platforms to kernel 6.18. On the
MediaTek platform, which supports hardware network offloading, WiFi
connections accelerated via the WED path were observed to drop after
roughly 300 seconds.
After several debugging sessions, assisted by the Claude LLM, the
problem was narrowed down as follows:
nf_flow_table_extend_ct_timeout() extends ct->timeout for offloaded
flows using:
cmpxchg(&ct->timeout, expires, new_timeout);
'expires' comes from nf_ct_expires(ct) and is a relative value, while
ct->timeout holds an absolute timestamp. The two are never equal, so
the cmpxchg always fails and the timeout is never extended.
This goes unnoticed for most flows, but a long-lived hardware (WED)
offloaded flow on MediaTek MT7986 eventually has ct->timeout decay to
zero, the conntrack entry is reaped and the connection breaks.
Open-code the relative value from a single READ_ONCE(ct->timeout)
snapshot and compare against that same absolute snapshot in the
cmpxchg, so the timeout extension actually takes effect while the
datapath remains authoritative if it updates ct->timeout concurrently.
Suggested-by: Florian Westphal <fw@strlen.de>
Fixes: 03428ca5cee9 ("netfilter: conntrack: rework offload nf_conn timeout extension logic")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Bente <adibente@gmail.com>
---
v2:
- open-code expires from an absolute READ_ONCE(ct->timeout) snapshot
instead of the relative nf_ct_expires() value (Florian Westphal)
- change min_timeout to s32 to keep the comparison signed
- initialise new_timeout to 1 instead of true
net/netfilter/nf_flow_table_core.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
index 3313f82..a2d08e5 100644
--- a/net/netfilter/nf_flow_table_core.c
+++ b/net/netfilter/nf_flow_table_core.c
@@ -500,8 +500,13 @@
*/
static void nf_flow_table_extend_ct_timeout(struct nf_conn *ct)
{
- static const u32 min_timeout = 5 * 60 * HZ;
- u32 expires = nf_ct_expires(ct);
+ static const s32 min_timeout = 5 * 60 * HZ;
+ u32 ct_timeout = READ_ONCE(ct->timeout);
+ s32 expires;
+
+ expires = ct_timeout - nfct_time_stamp;
+ if (expires <= 0) /* already expired */
+ return;
/* normal case: large enough timeout, nothing to do. */
if (likely(expires >= min_timeout))
@@ -519,7 +524,7 @@ static void nf_flow_table_extend_ct_timeout(struct nf_conn *ct)
if (nf_ct_is_confirmed(ct) &&
test_bit(IPS_OFFLOAD_BIT, &ct->status)) {
u8 l4proto = nf_ct_protonum(ct);
- u32 new_timeout = true;
+ u32 new_timeout = 1;
switch (l4proto) {
case IPPROTO_UDP:
@@ -544,7 +549,7 @@ static void nf_flow_table_extend_ct_timeout(struct nf_conn *ct)
*/
if (new_timeout) {
new_timeout += nfct_time_stamp;
- cmpxchg(&ct->timeout, expires, new_timeout);
+ cmpxchg(&ct->timeout, ct_timeout, new_timeout);
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH] ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365_afe_suspend()
From: Tuo Li @ 2026-05-28 6:41 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, matthias.bgg,
angelogioacchino.delregno, kuninori.morimoto.gx, ckeepax, vulab
Cc: linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek,
Tuo Li
mt8365_afe_suspend() allocates the register backup buffer with
devm_kcalloc(), but does not check for allocation failure before using the
returned pointer. This may lead to a NULL pointer dereference when
accessing afe->reg_back_up[i].
Add the missing NULL check and return -ENOMEM on allocation failure after
disabling the main clock.
Also propagate the return value of mt8365_afe_suspend() in
mt8365_afe_dev_runtime_suspend() so that the suspended state is not updated
when suspend fails.
Signed-off-by: Tuo Li <islituo@gmail.com>
---
sound/soc/mediatek/mt8365/mt8365-afe-pcm.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
index d01793394f22..5966ca18c7c9 100644
--- a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
+++ b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
@@ -1974,10 +1974,15 @@ static int mt8365_afe_suspend(struct device *dev)
mt8365_afe_enable_main_clk(afe);
- if (!afe->reg_back_up)
+ if (!afe->reg_back_up) {
afe->reg_back_up =
devm_kcalloc(dev, afe->reg_back_up_list_num,
sizeof(unsigned int), GFP_KERNEL);
+ if (!afe->reg_back_up) {
+ mt8365_afe_disable_main_clk(afe);
+ return -ENOMEM;
+ }
+ }
for (i = 0; i < afe->reg_back_up_list_num; i++)
regmap_read(regmap, afe->reg_back_up_list[i],
@@ -2011,11 +2016,15 @@ static int mt8365_afe_resume(struct device *dev)
static int mt8365_afe_dev_runtime_suspend(struct device *dev)
{
struct mtk_base_afe *afe = dev_get_drvdata(dev);
+ int ret;
if (pm_runtime_status_suspended(dev) || afe->suspended)
return 0;
- mt8365_afe_suspend(dev);
+ ret = mt8365_afe_suspend(dev);
+ if (ret)
+ return ret;
+
afe->suspended = true;
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH net] netfilter: flowtable: fix offloaded ct timeout never being extended
From: Florian Westphal @ 2026-05-28 5:22 UTC (permalink / raw)
To: Adrian Bențe
Cc: pablo, netfilter-devel, phil, nbd, sean.wang, lorenzo,
andrew+netdev, matthias.bgg, angelogioacchino.delregno, daniel,
coreteam, linux-mediatek
In-Reply-To: <CAC2HPwt_3D7k7tYr8OqNiguc-jMF3PEKtayFKmvOp37M2=QCZA@mail.gmail.com>
Adrian Bențe <adibente@gmail.com> wrote:
> adjustment: changed min_timeout from u32 to s32 so the
> "expires >= min_timeout" comparison has both operands signed.
> Compiles clean.
>
> Tested on MT7986 with the WED-offloaded flows that originally
> reproduced the 300s drop. The flows now stay up well past 300s with
> normal offloaded traffic, solution works fine.
>
> I'll send v2 with this diff and Suggested-by: you, unless you'd
> rather submit it yourself.
No, please go ahead.
^ permalink raw reply
* [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Jiajia Liu @ 2026-05-28 3:38 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Leon Yen
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Jiajia Liu
Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
to avoid reinitializing the wcid->poll_list.
Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
According to the corruption information, prev->next was changed to itself.
wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
mt76_wcid_add_poll+0x95/0xd0 [mt76]
mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
mt7925_rx_check+0xa7/0xc0 [mt7925_common]
mt76_dma_rx_poll+0x50d/0x790 [mt76]
mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
---
Changes in v2:
- use dev->wcid table instead of adding MT_WCID_FLAG_DRV_PUBLSH for
wcid publish check suggested by Sean
- subject and commit message update
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 4ae5e4715a9c..b78b4cd206e0 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -1576,6 +1576,7 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
{
struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
struct mt76_dev *dev = phy->dev;
+ struct mt76_wcid *published;
int ret;
int i;
@@ -1595,11 +1596,19 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
mtxq->wcid = wcid->idx;
}
- ewma_signal_init(&wcid->rssi);
- rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
+ published = rcu_dereference_protected(dev->wcid[wcid->idx],
+ lockdep_is_held(&dev->mutex));
+ if (published != wcid) {
+ WARN_ON_ONCE(published);
+ ewma_signal_init(&wcid->rssi);
+ rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
+ mt76_wcid_init(wcid, phy->band_idx);
+ } else {
+ wcid->phy_idx = phy->band_idx;
+ }
+
phy->num_sta++;
- mt76_wcid_init(wcid, phy->band_idx);
out:
mutex_unlock(&dev->mutex);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v5 0/6] Introduce Airoha AN8801R series Gigabit Ethernet PHY driver
From: patchwork-bot+netdevbpf @ 2026-05-28 1:50 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, angelogioacchino.delregno, andrew, hkallweit1, linux,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20260526-add-airoha-an8801-support-v5-0-01aea8dee69b@collabora.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 26 May 2026 16:58:05 +0200 you wrote:
> This series introduces the Airoha AN8801R Gigabit Ethernet PHY initial
> support.
>
> The Airoha AN8801R is a low power single-port Ethernet PHY Transceiver
> with Single-port serdes interface for 1000Base-X/RGMII.
> This chip is compliant with 10Base-T, 100Base-TX and 1000Base-T IEEE
> 802.3(u,ab) and supports:
> - Energy Efficient Ethernet (802.3az)
> - Full Duplex Control Flow (802.3x)
> - auto-negotiation
> - crossover detect and autocorrection,
> - Wake-on-LAN with Magic Packet
> - Jumbo Frame up to 9 Kilobytes.
> This PHY also supports up to three user-configurable LEDs, which are
> usually used for LAN Activity, 100M, 1000M indication.
>
> [...]
Here is the summary with links:
- [net-next,v5,1/6] dt-bindings: net: Add support for Airoha AN8801R GbE PHY
https://git.kernel.org/netdev/net-next/c/ed28bd094db3
- [net-next,v5,2/6] net: phy: Add Airoha phy library for shared code
https://git.kernel.org/netdev/net-next/c/dddfadd75197
- [net-next,v5,3/6] net: phy: air_phy_lib: Factorize BuckPBus register accessors
https://git.kernel.org/netdev/net-next/c/5226bb6634cd
- [net-next,v5,4/6] net: phy: Rename Airoha common BuckPBus register accessors
https://git.kernel.org/netdev/net-next/c/e08f0ea6daf2
- [net-next,v5,5/6] net: phy: Introduce Airoha AN8801R Gigabit Ethernet PHY driver
https://git.kernel.org/netdev/net-next/c/fdb9bf7f1658
- [net-next,v5,6/6] net: phy: air_an8801: ensure maximum available speed link use
https://git.kernel.org/netdev/net-next/c/f6465e36353f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v5 6/6] net: phy: air_an8801: ensure maximum available speed link use
From: Andrew Lunn @ 2026-05-28 1:30 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20260526-add-airoha-an8801-support-v5-6-01aea8dee69b@collabora.com>
On Tue, May 26, 2026 at 04:58:11PM +0200, Louis-Alexis Eyraud wrote:
> To ensure that the Airoha AN8801R PHY uses the maximum available link
> speed, an additional register write is needed to configure the function
> mode for either 1G or 100M/10M operation after link detection.
>
> So, in air_an8801 driver, implement a custom read_status callback, that
> after genphy_read_status determines the link speed, sets the bit 0 of
> the link mode register (REG_LINK_MODE) if the detected speed is 1Gbps,
> or unsets it otherwise.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v5 5/6] net: phy: Introduce Airoha AN8801R Gigabit Ethernet PHY driver
From: Andrew Lunn @ 2026-05-28 1:29 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20260526-add-airoha-an8801-support-v5-5-01aea8dee69b@collabora.com>
On Tue, May 26, 2026 at 04:58:10PM +0200, Louis-Alexis Eyraud wrote:
> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> Introduce a driver for the Airoha AN8801R Series Gigabit Ethernet
> PHY; this currently supports setting up PHY LEDs, 10/100M, 1000M
> speeds, and Wake on LAN and PHY interrupts.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [bug report] wifi: mt76: mt7921: mt7925monitor-mode per-channel retune emits narrowband RF burst
From: Sean Wang @ 2026-05-27 23:08 UTC (permalink / raw)
To: John Henry
Cc: Javier Tia, Bradley Pizzimenti, linux-wireless, linux-kernel, nbd,
lorenzo, ryder.lee, shayne.chen, sean.wang,
moderated list:ARM/Mediatek SoC support, Deren Wu, Nick Morrow
In-Reply-To: <CAN6xzWcVDRLVTV-SQcs6osZjnfhLM728NP7+W8+sFcTDmeVipw@mail.gmail.com>
Hi John,
On Wed, May 27, 2026 at 7:24 AM John Henry <jshenry1963@gmail.com> wrote:
>
> Just a kind reminder of this issue.
>
> Please advise if this is already taken up in a separate issue I am
> unaware of, but it is not directly related to the "iw set txpower
> fixed accepted but ignored" issue.
>
> On products available in the market, e.g. the Alfa AWUS036AXML
> consumer product and the Netgear Nighthawk A9000, in Monitor Mode
> there is RF generated when scanning through channels and we get to 5
> or more channels in succession.
> This does not seem to occur at all in managed mode.
>
> This means if we scan the 2.4GHz channel list, an RF Spectrum analyzer
> will show a narrow pulse generated on each channel as we progress
> through the channels.
> This can 100% be reproduced using standard iw set channel commands as
> shown below:
> FACE=$(iw dev | awk '/Interface wl/ {print $2; exit}')
> iw reg set US ; sleep 1
> ip link set "$IFACE" down
> iw dev "$IFACE" set type monitor
> ip link set "$IFACE" up
>
> # This triggers narrowband bursts at channel center on each retune:
> while true; do
> for f in 2412 2417 2422 2427 2432; do
> iw dev "$IFACE" set freq "$f" HT20
> done
> done
>
I have thought about this issue for a while. A possible workaround
would be to reset WFSYS / firmware after five consecutive `set
channel` operations in monitor mode, then restore the current monitor
channel context. The WFSYS reset may take hundreds of milliseconds to
complete, which is the cost we would need to pay.
> No special software required to reproduce.
> I have shown that this occurs on all MT7921 based products, along with
> MT7925 based products.
> It does not occur if the channel list is set to the same 4 over and
> over, no RF generated.
>
> There are no calibration channel commands going from the driver to the
> firmware, so I believe this is a firmware bug.
>
> Best Regards,
> John Henry
>
> On Sun, May 17, 2026 at 9:01 AM John Henry <jshenry1963@gmail.com> wrote:
> >
> > Just a kind reminder of this issue, has anyone been able to reproduce
> > this monitor mode issue?
> > When scanning through channels, and the list of channels is > 4, there
> > is a large transmit tick/burst coming from the MT7921u and the MT7925.
> > This can easily be seen on an RF Spectrum Analyzer.
> > Confirmed on an Alfa AWUS036AXML consumer product and the Netgear
> > Nighthawk A9000.
> > This can be reproduced with simple scripts.
> >
> > Reproduction with stock iw commands (no custom code):
> >
> > IFACE=$(iw dev | awk '/Interface wl/ {print $2; exit}')
> > iw reg set US ; sleep 1
> > ip link set "$IFACE" down
> > iw dev "$IFACE" set type monitor
> > ip link set "$IFACE" up
> >
> > # This triggers narrowband bursts at channel center on each retune:
> > while true; do
> > for f in 2412 2417 2422 2427 2432; do
> > iw dev "$IFACE" set freq "$f" HT20
> > done
> > done
> >
> > # This does NOT (only 4 frequencies):
> > while true; do
> > for f in 2412 2422 2462 2484; do
> > iw dev "$IFACE" set freq "$f" HT20
> > done
> > done
> >
> > Bursts are ~800 kHz wide at the base, -30 to -50 dBm OTA at close
> > range, brief (estimated few hundred microseconds), at channel
> > frequency. tx_stats counters remain zero throughout.
> > On Mon, May 11, 2026 at 1:58 PM John Henry <jshenry1963@gmail.com> wrote:
> > >
> > > Bradley/Sean,
> > >
> > > Thank you all very much for the information.
> > > I tested this on mt7921u based Alfa AWUS unit and also an mt7925 based
> > > Netgear Nighthawk unit.
> > > I can confirm that the RF tick issue is present on both models when in
> > > Monitor Mode. I'm assuming it is in the base mt76?
> > >
> > > I attempted sudo iw dev wlxxx set txpower fixed nn where nn is the
> > > minimum value, next few values up, and then a few near the max values,
> > > and see no change in the signal strength of the RF Ticks when scanning
> > > through 5 or more channels.
> > >
> > > Please keep this in mind when attempting to resolve the known txpower
> > > 3dBm issue if possible, or please generate a new bug report for that
> > > specifically so that I can track when it is patched, or in ??? version
> > > so that I can test here locally.
> > >
> > > Incidentally, I'd appreciate it if anyone could please attempt to
> > > repeat using the scripts I had shown in the previous posts and confirm
> > > it is indeed seen by others.
> > >
> > > Thank you very much for your time and assistance
> > >
> > > John Henry
> > >
> > >
> > >
> > >
> > > From: Bradley Pizzimenti <brad.pizzimenti@gmail.com>
> > > To: linux-wireless@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org, nbd@nbd.name, lorenzo@kernel.org,
> > > ryder.lee@mediatek.com, shayne.chen@mediatek.com,
> > > sean.wang@mediatek.com
> > > Subject: [bug report] wifi: mt76: mt7925: iw set txpower fixed
> > > accepted but ignored
> > > Date: Mon, 4 May 2026 15:04:35 -0700 [thread overview]
> > > Message-ID: <CACjnFagN9zeSkwEv3-CSPJDUENPcEcOLjKyQoLQ91Yjn=rq5ww@mail.gmail.com>
> > > (raw)
> > >
> > > Hi there maintainers,
> > >
> > > `iw dev <iface> set txpower fixed N` returns success on mt7925 for any
> > > N tested, but the reported txpower never changes from a stuck value of
> > > 3.00 dBm. The kernel accepts and ignores the call silently in both
> > > directions (above and below the displayed value), and well below the
> > > regulatory ceiling.
> > >
> > > I'm aware there's prior art on the cosmetic 3.00 dBm display issue
> > > (Razvan Grigore's v2 series, Feb 2025; Ming Yen Hsieh's txpower init
> > > refactor, Sept 2025). What seems potentially distinct here is that the
> > > user-issued `iw set txpower fixed N` itself is silently no-op'd,
> > > separate from the reported-value question. Reporting as breadcrumbs
> > > in case the second observation is a separate bug rather than the same
> > > one.
> > >
> > > Hardware
> > > --------
> > > MEDIATEK MT7925 [Filogic 360], 802.11be 2x2, PCI 14c3:7925
> > > ASIC revision 0x79250000
> > > Driver in use: mt7925e (in-tree)
> > >
> > > Firmware (from dmesg at probe)
> > > ------------------------------
> > > mt7925e 0000:01:00.0: HW/SW Version: 0x8a108a10,
> > > Build Time: 20260106153007a
> > > mt7925e 0000:01:00.0: WM Firmware Version: ____000000,
> > > Build Time: 20260106153120
> > > Files: mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin
> > > mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin
> > >
> > > Kernel
> > > ------
> > > 6.18.18-1-MANJARO (close to vanilla 6.18 stable; not yet tested on
> > > wireless-next or nbd168/wireless HEAD -- happy to retest if needed,
> > > but flagging the data point in case it helps as-is).
> > >
> > > Tools: iw version 6.17
> > >
> > > Regulatory
> > > ----------
> > > $ iw reg get
> > > country US: DFS-FCC
> > > ...
> > > (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
> > > ...
> > >
> > > Connection context: 5GHz channel 161 (5805 MHz), 80 MHz, VHT-MCS,
> > > NSS 1. So we are on a band with a 30 dBm regulatory cap.
> > >
> > > Observed
> > > --------
> > > $ iw dev wlp1s0 info | grep txpower
> > > txpower 3.00 dBm
> > >
> > > $ sudo iw dev wlp1s0 set txpower fixed 100 # 1 dBm
> > > $ iw dev wlp1s0 info | grep txpower
> > > txpower 3.00 dBm
> > >
> > > $ sudo iw dev wlp1s0 set txpower fixed 1500 # 15 dBm
> > > $ iw dev wlp1s0 info | grep txpower
> > > txpower 3.00 dBm
> > >
> > > $ sudo iw dev wlp1s0 set txpower auto
> > > $ iw dev wlp1s0 info | grep txpower
> > > txpower 3.00 dBm
> > >
> > > All four `set` invocations return exit code 0. The reported value
> > > never moves.
> > >
> > > Expected
> > > --------
> > > Either:
> > > - The reported txpower follows the requested value (or, where
> > > capped, the actual applied value with extack indicating the
> > > cap reason), or
> > > - The set call returns an error rather than silently ignoring the
> > > request.
> > >
> > > Caveats
> > > -------
> > > - Not yet tested on wireless-next or nbd168/wireless HEAD. If a
> > > reproduction on a current dev tree would be useful, I can do that.
> > > - I have not verified whether the actual radiated TX power changes
> > > in response to `set txpower fixed`; I am reporting only the
> > > user-visible behavior.
> > >
> > > Thanks,
> > > Bradley
> > >
> > > On Wed, May 6, 2026 at 8:12 PM Sean Wang <sean.wang@kernel.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > The TX power reporting issue has already been investigated by Lucid
> > > > from the Linux WiFi USB community, and there is a proposed solution.
> > > > I think we can continue checking whether there are any remaining
> > > > issues on top of that work. Please refer to the patches here:
> > > > https://lists.infradead.org/pipermail/linux-mediatek/2026-April/105726.html
> > > > Thanks everyone for reporting and raising these concerns.
> > > >
> > > > On Wed, May 6, 2026 at 3:09 PM Javier Tia <floss@jetm.me> wrote:
> > > > >
> > > > > On Sun May 4 22:04:48 2026 Bradley Pizzimenti wrote:
> > > > > > `iw dev <iface> set txpower fixed N` returns success on mt7925 for
> > > > > > any N tested, but the reported txpower never changes from a stuck
> > > > > > value of 3.00 dBm.
> > > > >
> > > > > Hi Bradley,
> > > > >
> > > > > The 3 dBm display bug is a known issue we have seen when using mt7927
> > > > > and a tested fix has been working well so far. The root cause is that
> > > > > mt7925_mcu_set_rate_txpower() programs the per-band SKU tables into
> > > > > firmware but never assigns phy->txpower_cur. mt76_get_txpower() then
> > > > > computes:
> > > > >
> > > > > DIV_ROUND_UP(0 + 6, 2) = 3
> > > > >
> > > > > regardless of the actual power level. The RF output is unaffected;
> > > > > it is a display-only bug.
> > > > >
> > > > > The fix reads the effective TX power back from the rate power limits
> > > > > after programming the SKU tables and writes it to phy->txpower_cur,
> > > > > following the same pattern used by mt7996:
> > > > >
> > > > > https://github.com/jetm/mediatek-mt7927-dkms/blob/master/mt7927-wifi-14-fix-reported-txpower-always-showing-3-db.patch
> > > > >
> > > > > This is part of a series we are targeting for wireless-next; not
> > > > > yet upstream.
> > > > >
> > > > > > What seems potentially distinct here is that the user-issued
> > > > > > `iw set txpower fixed N` itself is silently no-op'd, separate
> > > > > > from the reported-value question.
> > > > >
> > > > > Agreed those are two separate issues. Our patch addresses the
> > > > > display-only side: after applying it, iw will report the value the
> > > > > firmware is actually using based on the SKU tables, rather than
> > > > > always 3 dBm. Whether `set txpower fixed N` propagates to firmware
> > > > > to change actual output power is orthogonal and not addressed here.
> > > > >
> > > > > If you can test the patch on your MT7925 and confirm the displayed
> > > > > value reflects the correct power after association, a Tested-by
> > > > > would be appreciated.
> > > > >
> > > > > Best,
> > > > > Javier
> > > > >
> > > >
^ permalink raw reply
* [PATCH] Input: mtk-pmic-keys: Use flexible array member for keys
From: Rosen Penev @ 2026-05-27 22:38 UTC (permalink / raw)
To: linux-input
Cc: Dmitry Torokhov, Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Convert the fixed-size keys array to a flexible array member and use
struct_size() for allocation. Move the key count validation before
allocation and use for_each_available_child_of_node_scoped() to iterate
only over available child nodes as the allocation uses
of_get_available_child_count.
Also use a key variable in the loop for clarity.
Use of_device_get_match_data() to fetch the PMIC key register data directly
instead of open-coding an of_match_device() lookup.
This also lets the driver drop the of_device.h include.
Remove platform_set_drvdata. Unused anywhere.
Assisted-by: OpenCode:BigPickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/input/keyboard/mtk-pmic-keys.c | 55 ++++++++++++--------------
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
index c78d9f6d97c4..5b8650f46105 100644
--- a/drivers/input/keyboard/mtk-pmic-keys.c
+++ b/drivers/input/keyboard/mtk-pmic-keys.c
@@ -16,7 +16,6 @@
#include <linux/mfd/mt6397/core.h>
#include <linux/mfd/mt6397/registers.h>
#include <linux/module.h>
-#include <linux/of_device.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
@@ -147,7 +146,7 @@ struct mtk_pmic_keys {
struct input_dev *input_dev;
struct device *dev;
struct regmap *regmap;
- struct mtk_pmic_keys_info keys[MTK_PMIC_MAX_KEY_COUNT];
+ struct mtk_pmic_keys_info keys[];
};
enum mtk_pmic_keys_lp_mode {
@@ -332,17 +331,25 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
static const char *const irqnames_r[] = { "powerkey_r", "homekey_r" };
struct mtk_pmic_keys *keys;
const struct mtk_pmic_regs *mtk_pmic_regs;
+ struct mtk_pmic_keys_info *key;
struct input_dev *input_dev;
- const struct of_device_id *of_id =
- of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
- keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
+ keycount = of_get_available_child_count(node);
+ if (keycount > MTK_PMIC_MAX_KEY_COUNT ||
+ keycount > ARRAY_SIZE(irqnames)) {
+ dev_err(&pdev->dev, "too many keys defined (%d)\n", keycount);
+ return -EINVAL;
+ }
+
+ keys = devm_kzalloc(&pdev->dev, struct_size(keys, keys, keycount), GFP_KERNEL);
if (!keys)
return -ENOMEM;
keys->dev = &pdev->dev;
keys->regmap = pmic_chip->regmap;
- mtk_pmic_regs = of_id->data;
+ mtk_pmic_regs = of_device_get_match_data(&pdev->dev);
+ if (!mtk_pmic_regs)
+ return -EINVAL;
keys->input_dev = input_dev = devm_input_allocate_device(keys->dev);
if (!input_dev) {
@@ -356,31 +363,21 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
input_dev->id.product = 0x0001;
input_dev->id.version = 0x0001;
- keycount = of_get_available_child_count(node);
- if (keycount > MTK_PMIC_MAX_KEY_COUNT ||
- keycount > ARRAY_SIZE(irqnames)) {
- dev_err(keys->dev, "too many keys defined (%d)\n", keycount);
- return -EINVAL;
- }
+ for_each_available_child_of_node_scoped(node, child) {
+ key = &keys->keys[index];
+ key->regs = &mtk_pmic_regs->keys_regs[index];
- for_each_child_of_node_scoped(node, child) {
- keys->keys[index].regs = &mtk_pmic_regs->keys_regs[index];
-
- keys->keys[index].irq =
- platform_get_irq_byname(pdev, irqnames[index]);
- if (keys->keys[index].irq < 0)
- return keys->keys[index].irq;
+ key->irq = platform_get_irq_byname(pdev, irqnames[index]);
+ if (key->irq < 0)
+ return key->irq;
if (mtk_pmic_regs->key_release_irq) {
- keys->keys[index].irq_r = platform_get_irq_byname(pdev,
- irqnames_r[index]);
-
- if (keys->keys[index].irq_r < 0)
- return keys->keys[index].irq_r;
+ key->irq_r = platform_get_irq_byname(pdev, irqnames_r[index]);
+ if (key->irq_r < 0)
+ return key->irq_r;
}
- error = of_property_read_u32(child,
- "linux,keycodes", &keys->keys[index].keycode);
+ error = of_property_read_u32(child, "linux,keycodes", &key->keycode);
if (error) {
dev_err(keys->dev,
"failed to read key:%d linux,keycode property: %d\n",
@@ -389,9 +386,9 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
}
if (of_property_read_bool(child, "wakeup-source"))
- keys->keys[index].wakeup = true;
+ key->wakeup = true;
- error = mtk_pmic_key_setup(keys, &keys->keys[index]);
+ error = mtk_pmic_key_setup(keys, key);
if (error)
return error;
@@ -407,8 +404,6 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
mtk_pmic_keys_lp_reset_setup(keys, mtk_pmic_regs);
- platform_set_drvdata(pdev, keys);
-
return 0;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks
From: Chen-Yu Tsai @ 2026-05-27 21:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Bartosz Golaszewski, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel
In-Reply-To: <2026052710-flagship-unsmooth-ce82@gregkh>
On Wed, May 27, 2026 at 7:42 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, May 27, 2026 at 06:21:00PM +0200, Chen-Yu Tsai wrote:
> > On Tue, May 26, 2026 at 11:48 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > >
> > > On Sun, May 24, 2026 at 10:06 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> > > >
> > > > > >
> > > > > > I expect some discussion on this patch, because a) it adds some
> > > > > > OF-specific code into an otherwise generic (core) driver, and
> > > > > > b) it doesn't yet handle USB 2.0 / 3.x shared ports; it ends up powering
> > > > > > on the port twice, which negates the port reset part.
> > > > > >
> > > > >
> > > > > I understand that you do this because the port device has no OF node
> > > > > assigned. If we wanted to call pwrseq_get() for the port device, is
> > > > > there really no other way to associate it with the correct pwrseq
> > > > > provider?
> > > >
> > > > I suppose we could tie the "port@X" node to the usb port device, but
> > > > AFAIK no other subsystem does this so we would be introducing a new
> > > > pattern.
> > > >
> > > > In the M.2 pwrseq driver, we would have to match by port node instead
> > > > of its parent device node. We may end up with different behavior for
> > > > the USB target vs the other targets.
> > > >
> > >
> > > I imagine, we can check the bus type of the parent device to know if
> > > this is USB?
> >
> > The "bus type" type is probably not exported. However since the DT binding
> > explicitly says which port on the M.2 slot is for which connection type,
> > I think the matching can do a special case check for the USB port.
> > The next obstacle is that the target string is not given to the provider
> > match function.
> >
> > > > Also, the "port@X" nodes only exist for the OF graph connections to
> > > > connectors and/or muxes (this series doesn't deal with the latter).
> > > > For directly connected devices, there is a "device@X" child node
> > > > directly under the USB hub node. That node is what gets tied to the
> > > > the USB device.
> > > >
> > >
> > > Is this a problem? I don't think I understand what you're saying here.
> >
> > It shouldn't be. I'm just saying there would be different behavior on
> > the USB side for connectors vs onboard devices (like hubs) device nodes.
> >
> > I talked to Greg earlier, and he said not to touch the hub driver; the
> > hub driver should only deal with features from the USB spec. The
> > "onboard USB devices" driver is what should be used. And this would
> > be a proper case of adding an auxiliary device to the M.2 slot driver.
> >
> > However this seems to completely decouple the power sequencing from the
> > USB core. Take the USB A connector for example, it was recently added to
> > the onboard USB devices driver. However the connector has a device node
> > that is not a child node of any USB host controller or hub; it is connected
> > through OF graph. At the same time, since it typically sits at the top
> > level of the device tree, a platform device is directly created and the
> > driver subsequently binds to that device. This is totally different from
> > how the hub and other directly connected onboard USB devices work. In
> > the onboard device case, the device node is a child node of the USB hub
> > or controller, and the corresponding platform device only gets created
> > when the USB hub driver probes, thereby sort of tying it into the USB
> > device topology.
>
> Hm, did we mess this up? If so, we can always change it if you think
> this should be done differently.
>
> Hubs should be dealing with the power issues for their ports, so maybe
> rethinking this might be wise. I'm just loath to add hardware-specific
> hacks to the hub common code for obvious reasons. Anything we can do to
> pull it out to a separate driver is best so it doesn't affect the 99% of
> the users that don't have that crazy hardware :)
I understand. The way I have it in this series is that besides having
the port powered up initially, usb_hub_set_port_power() port power
control also extends to the pwrseq target for the M.2 slot or USB A
connector, just like if VBUS was controlled by the hub itself.
M.2 slots might be somewhat rarer, but I think many embedded devices
have USB A ports with VBUS that are controlled via GPIO, not wired
to the USB hub's (if any) port VBUS control pin. This is also present
on Chromebooks.
I think wiring up pwrseq to the USB port and using it for VBUS control
on these USB A ports is an improvement over the recent addition of USB
A connectors to the onboard device driver, which just turns on VBUS.
It would make the power cycle loop in hub_port_connect() actually work
on these devices.
Is it code for stuff outside of the hub itself? Yes. Is it crazy hardware?
Maybe not.
Thanks
ChenYu
^ permalink raw reply
* Re: [PATCH v1 2/3] regulator: Use named initializers for platform_device_id arrays
From: Karel Balej @ 2026-05-27 18:21 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Liam Girdwood,
Mark Brown
Cc: Matti Vaittinen, Marek Vasut, Chanwoo Choi, Krzysztof Kozlowski,
Matthias Brugger, AngeloGioacchino Del Regno, Samuel Kayode,
André Draszik, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, linux-kernel, linux-renesas-soc,
linux-arm-kernel, linux-mediatek, imx, linux-arm-msm,
linux-samsung-soc, linux-omap
In-Reply-To: <d02f55dfd5bdd743ae5cd76f2a5af0d346226a68.1779878004.git.u.kleine-koenig@baylibre.com>
Uwe Kleine-König (The Capable Hub), 2026-05-27T12:47:45+02:00:
> diff --git a/drivers/regulator/88pm886-regulator.c b/drivers/regulator/88pm886-regulator.c
> index a38bd4f312b7..7328cd1cf265 100644
> --- a/drivers/regulator/88pm886-regulator.c
> +++ b/drivers/regulator/88pm886-regulator.c
> @@ -373,7 +373,7 @@ static int pm886_regulator_probe(struct platform_device *pdev)
> }
>
> static const struct platform_device_id pm886_regulator_id_table[] = {
> - { "88pm886-regulator", },
> + { .name = "88pm886-regulator" },
> { }
> };
> MODULE_DEVICE_TABLE(platform, pm886_regulator_id_table);
Acked-by: Karel Balej <balejk@matfyz.cz> # for Marvell 88PM886
^ permalink raw reply
* Re: [PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks
From: Greg Kroah-Hartman @ 2026-05-27 17:41 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Bartosz Golaszewski, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel
In-Reply-To: <CAGXv+5GbW0bx3nKdZt2+tHuHyQ-J-1-Z79nMzHAwjmEPGKT02A@mail.gmail.com>
On Wed, May 27, 2026 at 06:21:00PM +0200, Chen-Yu Tsai wrote:
> On Tue, May 26, 2026 at 11:48 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >
> > On Sun, May 24, 2026 at 10:06 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> > >
> > > > >
> > > > > I expect some discussion on this patch, because a) it adds some
> > > > > OF-specific code into an otherwise generic (core) driver, and
> > > > > b) it doesn't yet handle USB 2.0 / 3.x shared ports; it ends up powering
> > > > > on the port twice, which negates the port reset part.
> > > > >
> > > >
> > > > I understand that you do this because the port device has no OF node
> > > > assigned. If we wanted to call pwrseq_get() for the port device, is
> > > > there really no other way to associate it with the correct pwrseq
> > > > provider?
> > >
> > > I suppose we could tie the "port@X" node to the usb port device, but
> > > AFAIK no other subsystem does this so we would be introducing a new
> > > pattern.
> > >
> > > In the M.2 pwrseq driver, we would have to match by port node instead
> > > of its parent device node. We may end up with different behavior for
> > > the USB target vs the other targets.
> > >
> >
> > I imagine, we can check the bus type of the parent device to know if
> > this is USB?
>
> The "bus type" type is probably not exported. However since the DT binding
> explicitly says which port on the M.2 slot is for which connection type,
> I think the matching can do a special case check for the USB port.
> The next obstacle is that the target string is not given to the provider
> match function.
>
> > > Also, the "port@X" nodes only exist for the OF graph connections to
> > > connectors and/or muxes (this series doesn't deal with the latter).
> > > For directly connected devices, there is a "device@X" child node
> > > directly under the USB hub node. That node is what gets tied to the
> > > the USB device.
> > >
> >
> > Is this a problem? I don't think I understand what you're saying here.
>
> It shouldn't be. I'm just saying there would be different behavior on
> the USB side for connectors vs onboard devices (like hubs) device nodes.
>
> I talked to Greg earlier, and he said not to touch the hub driver; the
> hub driver should only deal with features from the USB spec. The
> "onboard USB devices" driver is what should be used. And this would
> be a proper case of adding an auxiliary device to the M.2 slot driver.
>
> However this seems to completely decouple the power sequencing from the
> USB core. Take the USB A connector for example, it was recently added to
> the onboard USB devices driver. However the connector has a device node
> that is not a child node of any USB host controller or hub; it is connected
> through OF graph. At the same time, since it typically sits at the top
> level of the device tree, a platform device is directly created and the
> driver subsequently binds to that device. This is totally different from
> how the hub and other directly connected onboard USB devices work. In
> the onboard device case, the device node is a child node of the USB hub
> or controller, and the corresponding platform device only gets created
> when the USB hub driver probes, thereby sort of tying it into the USB
> device topology.
Hm, did we mess this up? If so, we can always change it if you think
this should be done differently.
Hubs should be dealing with the power issues for their ports, so maybe
rethinking this might be wise. I'm just loath to add hardware-specific
hacks to the hub common code for obvious reasons. Anything we can do to
pull it out to a separate driver is best so it doesn't affect the 99% of
the users that don't have that crazy hardware :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH mt76] wifi: mt76: mt7915: configure noise floor reporting on reset
From: David Bauer @ 2026-05-27 17:05 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <a83c9aca-da9e-4a5e-a364-382910388a68@nbd.name>
Hi Felix,
On 5/27/26 15:56, Felix Fietkau wrote:
> On 16.05.26 16:49, David Bauer wrote:
>> When performing a full system recovery of the MCU on a dual-phy
>> platform, band 0 (usually 2.4GHz) stops reading correct noise floor
>> data.
>>
>> This is due to noise floor reporting only being configured correctly
>> for the second device PHY.
>>
>> Configure the respective registers correctly after restarting the MCU
>> firmware to fix reported noise-floor values.
>>
>> Signed-off-by: David Bauer <mail@david-bauer.net>
> Have you considered clearing MT76_STATE_RUNNING in mt7915_mac_restart instead?
The call to mt7915_run is guarded by MT76_STATE_RUNNING being set per-phy.
I think this is to not start the second PHY in case it was never started due to
it not being present. We could in theory remove this check for the primary PHY
and clear the flag prior calling mt7915_run.
This seems a bit more hacky to me. Alternatively I can also refactor the entire
mechanism to make it easier to understand and resolve this indirection in the
process.
What do you think?
Best
David
>
> - Felix
^ permalink raw reply
* Re: [PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks
From: Chen-Yu Tsai @ 2026-05-27 16:21 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Manivannan Sadhasivam
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel
In-Reply-To: <CAMRc=Med-_0GSYzoFBRiwFzBCK0DZqJD8_SEBxi+zwR20GS-HA@mail.gmail.com>
On Tue, May 26, 2026 at 11:48 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Sun, May 24, 2026 at 10:06 AM Chen-Yu Tsai <wenst@chromium.org> wrote:
> >
> > > >
> > > > I expect some discussion on this patch, because a) it adds some
> > > > OF-specific code into an otherwise generic (core) driver, and
> > > > b) it doesn't yet handle USB 2.0 / 3.x shared ports; it ends up powering
> > > > on the port twice, which negates the port reset part.
> > > >
> > >
> > > I understand that you do this because the port device has no OF node
> > > assigned. If we wanted to call pwrseq_get() for the port device, is
> > > there really no other way to associate it with the correct pwrseq
> > > provider?
> >
> > I suppose we could tie the "port@X" node to the usb port device, but
> > AFAIK no other subsystem does this so we would be introducing a new
> > pattern.
> >
> > In the M.2 pwrseq driver, we would have to match by port node instead
> > of its parent device node. We may end up with different behavior for
> > the USB target vs the other targets.
> >
>
> I imagine, we can check the bus type of the parent device to know if
> this is USB?
The "bus type" type is probably not exported. However since the DT binding
explicitly says which port on the M.2 slot is for which connection type,
I think the matching can do a special case check for the USB port.
The next obstacle is that the target string is not given to the provider
match function.
> > Also, the "port@X" nodes only exist for the OF graph connections to
> > connectors and/or muxes (this series doesn't deal with the latter).
> > For directly connected devices, there is a "device@X" child node
> > directly under the USB hub node. That node is what gets tied to the
> > the USB device.
> >
>
> Is this a problem? I don't think I understand what you're saying here.
It shouldn't be. I'm just saying there would be different behavior on
the USB side for connectors vs onboard devices (like hubs) device nodes.
I talked to Greg earlier, and he said not to touch the hub driver; the
hub driver should only deal with features from the USB spec. The
"onboard USB devices" driver is what should be used. And this would
be a proper case of adding an auxiliary device to the M.2 slot driver.
However this seems to completely decouple the power sequencing from the
USB core. Take the USB A connector for example, it was recently added to
the onboard USB devices driver. However the connector has a device node
that is not a child node of any USB host controller or hub; it is connected
through OF graph. At the same time, since it typically sits at the top
level of the device tree, a platform device is directly created and the
driver subsequently binds to that device. This is totally different from
how the hub and other directly connected onboard USB devices work. In
the onboard device case, the device node is a child node of the USB hub
or controller, and the corresponding platform device only gets created
when the USB hub driver probes, thereby sort of tying it into the USB
device topology.
If the power sequencing ends up not connected to the USB subsystem, then
maybe the M.2 slot driver could just check if the USB port (port@3) was
used, and just enable the USB / BT pwrseq target at probe time? That
would mean less changes needed.
Thanks
ChenYu
^ permalink raw reply
* Re: [RFC PATCH net] netfilter: flowtable: fix offloaded ct timeout never being extended
From: Adrian Bențe @ 2026-05-27 16:14 UTC (permalink / raw)
To: Florian Westphal
Cc: pablo, netfilter-devel, phil, nbd, sean.wang, lorenzo,
andrew+netdev, matthias.bgg, angelogioacchino.delregno, daniel,
coreteam, linux-mediatek
In-Reply-To: <ahaek23tB7D8tQUe@strlen.de>
> I guess we need to open-code expires, something like this (not even
> compile tested). Also see https://sashiko.dev/#/patchset/20260526060138.3924-1-adibente%40gmail.com
>
> diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
> --- a/net/netfilter/nf_flow_table_core.c
> +++ b/net/netfilter/nf_flow_table_core.c
> @@ -506,7 +506,12 @@ static u32 nf_flow_table_tcp_timeout(const struct nf_conn *ct)
> static void nf_flow_table_extend_ct_timeout(struct nf_conn *ct)
> {
> static const u32 min_timeout = 5 * 60 * HZ;
> - u32 expires = nf_ct_expires(ct);
> + u32 ct_timeout = READ_ONCE(ct->timeout);
> + s32 expires;
> +
> + expires = ct_timeout - nfct_time_stamp;
> + if (expires <= 0) /* already expired */
> + return;
>
> /* normal case: large enough timeout, nothing to do. */
> if (likely(expires >= min_timeout))
> @@ -524,7 +529,7 @@ static void nf_flow_table_extend_ct_timeout(struct nf_conn *ct)
> if (nf_ct_is_confirmed(ct) &&
> test_bit(IPS_OFFLOAD_BIT, &ct->status)) {
> u8 l4proto = nf_ct_protonum(ct);
> - u32 new_timeout = true;
> + u32 new_timeout = 1;
>
> switch (l4proto) {
> case IPPROTO_UDP:
> @@ -549,7 +554,7 @@ static void nf_flow_table_extend_ct_timeout(struct nf_conn *ct)
> */
> if (new_timeout) {
> new_timeout += nfct_time_stamp;
> - cmpxchg(&ct->timeout, expires, new_timeout);
> + cmpxchg(&ct->timeout, ct_timeout, new_timeout);
> }
> }
>
Thanks. Applied your diff to my OpenWrt 6.18 tree with one small
adjustment: changed min_timeout from u32 to s32 so the
"expires >= min_timeout" comparison has both operands signed.
Compiles clean.
Tested on MT7986 with the WED-offloaded flows that originally
reproduced the 300s drop. The flows now stay up well past 300s with
normal offloaded traffic, solution works fine.
I'll send v2 with this diff and Suggested-by: you, unless you'd
rather submit it yourself.
^ permalink raw reply
* [PATCH wireless-next v2] wifi: mt76: mt7925: add Netgear A8500 USB device ID
From: Devin Wittmayer @ 2026-05-27 14:47 UTC (permalink / raw)
To: linux-wireless
Cc: Felix Fietkau, Lorenzo Bianconi, Sean Wang, Ryder Lee,
linux-mediatek, Nick Morrow, Devin Wittmayer
In-Reply-To: <20260326190346.415226-1-lucid_duck@justthetip.ca>
Add USB device ID for the Netgear A8500 (0846:9050) which uses
the mt7925 chipset.
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
Changes in v2 (Sean Wang):
- Drop the Cc: stable tag.
- Use full name in Signed-off-by.
v1: https://lore.kernel.org/linux-wireless/20260326190346.415226-1-lucid_duck@justthetip.ca/
---
drivers/net/wireless/mediatek/mt76/mt7925/usb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
index d9968f03856d..e44f0cafde01 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
@@ -12,6 +12,9 @@
static const struct usb_device_id mt7925u_device_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x0e8d, 0x7925, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM },
+ /* Netgear, Inc. A8500 */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9050, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM },
/* Netgear, Inc. A9000 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9072, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM },
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC net-next v2] net: airoha: Add TCP LRO support
From: Alexander Lobakin @ 2026-05-27 14:12 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev,
Madhur Agrawal
In-Reply-To: <ahYLvlIYH60cvkWB@lore-desk>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Date: Tue, 26 May 2026 23:08:14 +0200
>> From: Lorenzo Bianconi <lorenzo@kernel.org>
>> Date: Tue, 26 May 2026 08:58:05 +0200
[...]
>>> @@ -587,6 +630,85 @@ static int airoha_qdma_get_gdm_port(struct airoha_eth *eth,
>>> return port >= ARRAY_SIZE(eth->ports) ? -EINVAL : port;
>>> }
>>>
>>> +static int airoha_qdma_lro_rx_process(struct airoha_queue *q,
>>> + struct airoha_qdma_desc *desc)
>>> +{
>>> + u32 desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
>>> + u32 msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
>>> + u32 msg2 = le32_to_cpu(READ_ONCE(desc->msg2));
>>> + u32 msg3 = le32_to_cpu(READ_ONCE(desc->msg3));
>>
>> Why are these READ_ONCE()s needed? Does desc come from the HW (sorry I
>> didn't follow the whole code flow) or...?
>
> Correct, ctrl, msg1, msg2 and msg3 are subfields of the DMA descriptor read by
> airoha_qdma_rx_process() from the NIC. I guess here we have a similar issue as
> the one fixed in [0]
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4ae0604a0673e11e2075b178387151fcad5111b5
Hmm, I never believed that we need READ_ONCE()s when reading HW
descriptors, I always thought dma_alloc_coherent() is enough.
But maybe I've been mistaking...
[...]
>>> +
>>> + if (*topt == cpu_to_be32((TCPOPT_NOP << 24) |
>>
>> Shouldn't this be `((u32)TCPOPT_NOP) << 24` to avoid sign issues?
>
> I guess this is same approach used in [1]. Am I missing something?
>
> [1] https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_ipv4.c#L823
Yeah I also notice this in one more patch when scrolling netdev
yesterday. I guess it's okay here since TCPOPT_NOP is small and
constant and doesn't reach bit 31.
>
> Regards,
> Lorenzo
Thanks,
Olek
^ 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