* Re: [PATCH v3 7/8] arm64: dts: qcom: sdm845-db845c: describe WiFi/BT properly
From: Konrad Dybcio @ 2026-03-26 9:01 UTC (permalink / raw)
To: Dmitry Baryshkov, David Heidelberg
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul, linux-arm-msm,
Liam Girdwood, linux-kernel, devicetree, Luiz Augusto von Dentz,
Rob Herring, linux-bluetooth, Balakrishna Godavarthi,
Matthias Kaehlcke, linux-wireless, Jeff Johnson, ath10k, linux-pm,
Bartosz Golaszewski, Krzysztof Kozlowski, Mark Brown,
Krzysztof Kozlowski, Bartosz Golaszewski, Marcel Holtmann,
Conor Dooley, Manivannan Sadhasivam
In-Reply-To: <CAO9ioeVLy_Uzn7L9MyET5wg8CMR132+Dda5JzjdAB=6vz2NEMg@mail.gmail.com>
On 3/26/26 2:59 AM, Dmitry Baryshkov wrote:
> On Thu, 26 Mar 2026 at 02:02, David Heidelberg <david@ixit.cz> wrote:
>>
>> On 19/01/2026 18:08, Dmitry Baryshkov wrote:
>>
>> [...]
>>
>>> + wcn3990-pmu {
>>> + compatible = "qcom,wcn3990-pmu";
>>> +
>>> + pinctrl-0 = <&sw_ctrl_default>;
>>> + pinctrl-names = "default";
>>> +
>>> + vddio-supply = <&vreg_s4a_1p8>;
>>> + vddxo-supply = <&vreg_l7a_1p8>;
>>> + vddrf-supply = <&vreg_l17a_1p3>;
>>> + vddch0-supply = <&vreg_l25a_3p3>;
>>> + vddch1-supply = <&vreg_l23a_3p3>;
>>> +
>>> + swctrl-gpios = <&pm8998_gpios 3 GPIO_ACTIVE_HIGH>;
>>
>> Do you know if the GPIO is common for whole sdm845, or it's only recommended as
>> reference design, or nothing?
>>
>> I did test defaulting to GPIO 3 on Pixel 3 and WiFi works as before, but since
>> previous downstream kernel didn't touched GPIO 3 at all, I'm worried about
>> toggling unrelated GPIO.
>
> It is an input-only GPIO, but nevertheless, if you are not sure, just skip it.
I think you should be able to observe its state and deduce based on that
On a sidenote, 99.5% of reference design choices seem to hold true on at
least 90% of devices
Konrad
^ permalink raw reply
* Re: [PATCH v4 9/9] arm64: dts: amlogic: t7: khadas-vim4: Add MMC nodes
From: Neil Armstrong @ 2026-03-26 8:54 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-9-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Enable and configure the three MMC controllers for the Khadas VIM4 board:
> - sd_emmc_a: SDIO interface for the BCM43752 Wi-Fi module
> - sd_emmc_b: SD card slot
> - sd_emmc_c: eMMC storage
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 +++++++++++++++++++++-
> 1 file changed, 89 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index 770f06b0b16c7..5a73ae081036c 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -14,7 +14,10 @@ / {
> compatible = "khadas,vim4", "amlogic,a311d2", "amlogic,t7";
>
> aliases {
> - serial0 = &uart_a;
> + serial0 = &uart_a;
Spurious change
> + mmc0 = &sd_emmc_c;
> + mmc1 = &sd_emmc_b;
> + mmc2 = &sd_emmc_a;
> };
>
> memory@0 {
> @@ -159,6 +162,91 @@ &pwm_ab {
> pinctrl-names = "default";
> };
>
> +/* SDIO */
> +&sd_emmc_a {
> + status = "okay";
> + pinctrl-0 = <&sdio_pins>;
> + pinctrl-1 = <&sdio_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + cap-sdio-irq;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + no-mmc;
> + no-sd;
> +
> + power-domains = <&pwrc PWRC_T7_SDIO_A_ID>;
> +
> + keep-power-in-suspend;
> +
> + mmc-pwrseq = <&sdio_pwrseq>;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddao_1v8>;
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm43752-fmac", "brcm,bcm4329-fmac";
> + };
> +};
> +
> +/* SD card */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-1 = <&sdcard_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + max-frequency = <200000000>;
> + disable-wp;
> + no-sdio;
> + no-mmc;
> +
> + power-domains = <&pwrc PWRC_T7_SDIO_B_ID>;
> +
> + cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
> + vmmc-supply = <&sd_3v3>;
> + vqmmc-supply = <&vddio_c>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_ctrl_pins>, <&emmc_data_8b_pins>, <&emmc_ds_pins>;
> + pinctrl-1 = <&emmc_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> +
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + max-frequency = <200000000>;
> + disable-wp;
> + non-removable;
> + no-sdio;
> + no-sd;
> +
> + power-domains = <&pwrc PWRC_T7_EMMC_ID>;
> +
> + vmmc-supply = <&vddio_3v3>;
> + vqmmc-supply = <&vddio_1v8>;
> +};
> +
> &uart_a {
> status = "okay";
> clocks = <&xtal>, <&xtal>, <&xtal>;
>
With that:
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 7/9] arm64: dts: amlogic: t7: khadas-vim4: Add SDIO power sequence and WiFi clock
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-7-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add the SDIO power sequence node using mmc-pwrseq-simple and a
> 32.768kHz PWM-based clock required by the Wi-Fi module.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index 2450084d37642..770f06b0b16c7 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -67,6 +67,15 @@ sd_3v3: regulator-sdcard-3v3 {
> regulator-always-on;
> };
>
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
> + post-power-on-delay-ms = <500>;
> + power-off-delay-us = <200000>;
> + clocks = <&wifi32k>;
> + clock-names = "ext_clock";
> + };
> +
> vcc5v: regulator-vcc-5v {
> compatible = "regulator-fixed";
> regulator-name = "VCC5V";
> @@ -135,6 +144,19 @@ vddio_c: regulator-gpio-c {
> states = <1800000 1
> 3300000 0>;
> };
> +
> + wifi32k: wifi32k {
> + compatible = "pwm-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + pwms = <&pwm_ab 0 30518 0>;
> + };
> +};
> +
> +&pwm_ab {
> + status = "okay";
> + pinctrl-0 = <&pwm_a_pins>;
> + pinctrl-names = "default";
> };
>
> &uart_a {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-6-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add voltage regulator nodes describing the VIM4 power tree,
> required by peripheral nodes such as the SD card controller.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index fffdab96b12eb..2450084d37642 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -6,6 +6,8 @@
> /dts-v1/;
>
> #include "amlogic-t7.dtsi"
> +#include <dt-bindings/gpio/amlogic,t7-periphs-pinctrl.h>
> +#include <dt-bindings/gpio/gpio.h>
>
> / {
> model = "Khadas vim4";
> @@ -45,6 +47,94 @@ xtal: xtal-clk {
> #clock-cells = <0>;
> };
>
> + dc_in: regulator-dc-in {
> + compatible = "regulator-fixed";
> + regulator-name = "DC_IN";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +
> + sd_3v3: regulator-sdcard-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "SD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddao_3v3>;
> + gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
> + regulator-boot-on;
> + enable-active-low;
> + regulator-always-on;
> + };
> +
> + vcc5v: regulator-vcc-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_in>;
> +
> + gpio = <&gpio GPIOH_4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vcc5v0_usb: regulator-vcc-usb {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC5V0_USB";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc5v>;
> +
> + gpio = <&gpio GPIOY_5 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vddao_1v8: regulator-vddao-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + vddao_3v3: regulator-vddao-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&dc_in>;
> + regulator-always-on;
> + };
> +
> + vddio_1v8: regulator-vddio-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddio_3v3>;
> + regulator-always-on;
> + };
> +
> + vddio_3v3: regulator-vddio-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + vddio_c: regulator-gpio-c {
> + compatible = "regulator-gpio";
> + regulator-name = "VDDIO_C";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddio_3v3>;
> + gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
> + states = <1800000 1
> + 3300000 0>;
> + };
> };
>
> &uart_a {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 5/9] arm64: dts: amlogic: t7: Add PWM controller nodes
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Nick Xie
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-5-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add device tree nodes for the seven PWM controllers available
> on the Amlogic T7 SoC, using amlogic,meson-s4-pwm as fallback compatible.
> All nodes are disabled by default and should be
> enabled in the board-specific DTS file.
>
> Co-developed-by: Nick Xie <nick@khadas.com>
> Signed-off-by: Nick Xie <nick@khadas.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 63 +++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index eb09a26bcd0e0..581cdaebfe637 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -511,6 +511,69 @@ sec_ao: ao-secure@10220 {
> amlogic,has-chip-id;
> };
>
> + pwm_ao_ef: pwm@30000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x30000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_E>,
> + <&clkc_periphs CLKID_PWM_AO_F>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_gh: pwm@32000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x32000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_G>,
> + <&clkc_periphs CLKID_PWM_AO_H>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ab: pwm@58000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x58000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_A>,
> + <&clkc_periphs CLKID_PWM_B>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_cd: pwm@5a000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5a000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_C>,
> + <&clkc_periphs CLKID_PWM_D>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ef: pwm@5c000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5c000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_E>,
> + <&clkc_periphs CLKID_PWM_F>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_ab: pwm@5e000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5e000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_A>,
> + <&clkc_periphs CLKID_PWM_AO_B>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_cd: pwm@60000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x60000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_C>,
> + <&clkc_periphs CLKID_PWM_AO_D>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> sd_emmc_a: mmc@88000 {
> compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> reg = <0x0 0x88000 0x0 0x800>;
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-4-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> These pinctrl nodes are required by the PWM drivers to configure
> pin muxing at runtime.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 136 ++++++++++++++++++++++++++++
> 1 file changed, 136 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 62c87d0ef7065..eb09a26bcd0e0 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -307,6 +307,142 @@ mux {
> };
> };
>
> + pwm_a_pins: pwm-a {
> + mux {
> + groups = "pwm_a";
> + function = "pwm_a";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_a_pins: pwm-ao-a {
> + mux {
> + groups = "pwm_ao_a";
> + function = "pwm_ao_a";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_b_pins: pwm-ao-b {
> + mux {
> + groups = "pwm_ao_b";
> + function = "pwm_ao_b";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_c_pins: pwm-ao-c {
> + mux {
> + groups = "pwm_ao_c";
> + function = "pwm_ao_c";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_c_hiz_pins: pwm-ao-c-hiz {
> + mux {
> + groups = "pwm_ao_c_hiz";
> + function = "pwm_ao_c_hiz";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_d_pins: pwm-ao-d {
> + mux {
> + groups = "pwm_ao_d";
> + function = "pwm_ao_d";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_e_pins: pwm-ao-e {
> + mux {
> + groups = "pwm_ao_e";
> + function = "pwm_ao_e";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_f_pins: pwm-ao-f {
> + mux {
> + groups = "pwm_ao_f";
> + function = "pwm_ao_f";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_g_pins: pwm-ao-g {
> + mux {
> + groups = "pwm_ao_g";
> + function = "pwm_ao_g";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_g_hiz_pins: pwm-ao-g-hiz {
> + mux {
> + groups = "pwm_ao_g_hiz";
> + function = "pwm_ao_g_hiz";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_h_pins: pwm-ao-h {
> + mux {
> + groups = "pwm_ao_h";
> + function = "pwm_ao_h";
> + bias-disable;
> + };
> + };
> +
> + pwm_b_pins: pwm-b {
> + mux {
> + groups = "pwm_b";
> + function = "pwm_b";
> + bias-disable;
> + };
> + };
> +
> + pwm_c_pins: pwm-c {
> + mux {
> + groups = "pwm_c";
> + function = "pwm_c";
> + bias-disable;
> + };
> + };
> +
> + pwm_d_pins: pwm-d {
> + mux {
> + groups = "pwm_d";
> + function = "pwm_d";
> + bias-disable;
> + };
> + };
> +
> + pwm_e_pins: pwm-e {
> + mux {
> + groups = "pwm_e";
> + function = "pwm_e";
> + bias-disable;
> + };
> + };
> +
> + pwm_f_pins: pwm-f {
> + mux {
> + groups = "pwm_f";
> + function = "pwm_f";
> + bias-disable;
> + };
> + };
> +
> + pwm_vs_pins: pwm-vs {
> + mux {
> + groups = "pwm_vs";
> + function = "pwm_vs";
> + bias-disable;
> + };
> + };
> +
> sdcard_pins: sdcard {
> mux {
> groups = "sdcard_d0",
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-3-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add device tree nodes for the three MMC controllers available
> on the Amlogic T7 SoC, using amlogic,meson-axg-mmc as fallback compatible.
> All nodes are disabled by default and should be
> enabled in the board-specific DTS file.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 39 +++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 016b5429c8d1b..62c87d0ef7065 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -374,6 +374,45 @@ sec_ao: ao-secure@10220 {
> reg = <0x0 0x10220 0x0 0x140>;
> amlogic,has-chip-id;
> };
> +
> + sd_emmc_a: mmc@88000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x88000 0x0 0x800>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
move disabled at the end of the properties
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_A>,
> + <&clkc_periphs CLKID_SD_EMMC_A>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> +
> + sd_emmc_b: mmc@8a000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8a000 0x0 0x800>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
Ditto
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_B>,
> + <&clkc_periphs CLKID_SD_EMMC_B>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> +
> + sd_emmc_c: mmc@8c000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8c000 0x0 0x800>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
Ditto
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_C>,
> + <&clkc_periphs CLKID_SD_EMMC_C>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> };
>
> };
>
^ permalink raw reply
* Re: [PATCH v4 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-1-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
> to configure pin muxing at runtime.
>
> - eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
> - SD card: data, clock, command and clock gate pins
> - SDIO: data, clock, command and clock gate pins
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 6510068bcff92..016b5429c8d1b 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -250,6 +250,104 @@ gpio: bank@4000 {
> #gpio-cells = <2>;
> gpio-ranges = <&periphs_pinctrl 0 0 157>;
> };
> +
> + emmc_ctrl_pins: emmc-ctrl {
> + mux-0 {
> + groups = "emmc_cmd";
> + function = "emmc";
> + bias-pull-up;
> + };
> +
> + mux-1 {
> + groups = "emmc_clk";
> + function = "emmc";
> + bias-disable;
> + };
> + };
> +
> + emmc_data_4b_pins: emmc-data-4b {
> + mux-0 {
No need for "-0"
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_data_8b_pins: emmc-data-8b {
> + mux-0 {
No need for "-0"
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3",
> + "emmc_nand_d4",
> + "emmc_nand_d5",
> + "emmc_nand_d6",
> + "emmc_nand_d7";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_ds_pins: emmc-ds {
> + mux {
> + groups = "emmc_nand_ds";
> + function = "emmc";
> + bias-pull-down;
> + };
> + };
> +
> + emmc_clk_gate_pins: emmc-clk-gate {
> + mux {
> + groups = "GPIOB_8";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdcard_pins: sdcard {
> + mux {
> + groups = "sdcard_d0",
> + "sdcard_d1",
> + "sdcard_d2",
> + "sdcard_d3",
> + "sdcard_clk",
> + "sdcard_cmd";
> + function = "sdcard";
> + bias-pull-up;
> + };
> + };
> +
> + sdcard_clk_gate_pins: sdcard-clk-gate {
> + mux {
> + groups = "GPIOC_4";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdio_pins: sdio {
> + mux-0 {
No need for "-0"
> + groups = "sdio_d0",
> + "sdio_d1",
> + "sdio_d2",
> + "sdio_d3",
> + "sdio_clk",
> + "sdio_cmd";
> + function = "sdio";
> + bias-pull-up;
> + };
> + };
> +
> + sdio_clk_gate_pins: sdio-clk-gate {
> + mux {
> + groups = "GPIOX_4";
> + function = "gpio_periphs";
> + bias-pull-up;
> + };
> + };
> };
>
> gpio_intc: interrupt-controller@4080 {
>
^ permalink raw reply
* Re: [PATCH 10/14] drm/msm: Switch to generic PAS TZ APIs
From: Sumit Garg @ 2026-03-26 8:50 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
Sumit Garg
In-Reply-To: <v4ffww2r4ljqqbmvsc5jcr4ztqjbpfb42xryjeuz4abqiwup3a@2gfeelhjzzz4>
On Wed, Mar 25, 2026 at 06:34:18AM +0200, Dmitry Baryshkov wrote:
> On Fri, Mar 06, 2026 at 04:20:23PM +0530, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Switch drm/msm client drivers over to generic PAS TZ APIs. Generic PAS
> > TZ service allows to support multiple TZ implementation backends like QTEE
> > based SCM PAS service, OP-TEE based PAS service and any further future TZ
> > backend service.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 ++++++-----
> > 2 files changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > index ef9fd6171af7..3283852f9a14 100644
> > --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> > @@ -5,7 +5,7 @@
> > #include <linux/kernel.h>
> > #include <linux/types.h>
> > #include <linux/cpumask.h>
> > -#include <linux/firmware/qcom/qcom_scm.h>
> > +#include <linux/firmware/qcom/qcom_pas.h>
>
> Missing `select QCOM_PAS`.
Sure, I will add that in next spin.
-Sumit
>
>
> > #include <linux/pm_opp.h>
> > #include <linux/nvmem-consumer.h>
> > #include <linux/slab.h>
> > @@ -653,7 +653,7 @@ static int a5xx_zap_shader_resume(struct msm_gpu *gpu)
> > if (adreno_is_a506(adreno_gpu))
> > return 0;
> >
> > - ret = qcom_scm_set_remote_state(SCM_GPU_ZAP_SHADER_RESUME, GPU_PAS_ID);
> > + ret = qcom_pas_set_remote_state(SCM_GPU_ZAP_SHADER_RESUME, GPU_PAS_ID);
> > if (ret)
> > DRM_ERROR("%s: zap-shader resume failed: %d\n",
> > gpu->name, ret);
>
> --
> With best wishes
> Dmitry
>
^ permalink raw reply
* Re: [PATCH ath-next v4] wifi: ath12k: avoid dynamic alloc when parsing wmi tb
From: Nicolas Escande @ 2026-03-26 8:37 UTC (permalink / raw)
To: Jeff Johnson, Rameshkumar Sundaram, Nicolas Escande, ath12k
Cc: linux-wireless
In-Reply-To: <edf86c6a-fb09-4524-9b47-3061c3d6e68f@oss.qualcomm.com>
On Tue Mar 24, 2026 at 5:55 PM CET, Jeff Johnson wrote:
> On 3/23/2026 5:40 AM, Rameshkumar Sundaram wrote:
>> On 3/19/2026 9:29 PM, Jeff Johnson wrote:
>>> On 3/19/2026 7:35 AM, Nicolas Escande wrote:
>>>> On Thu Mar 19, 2026 at 12:08 PM CET, Rameshkumar Sundaram wrote:
>>>>> Or may be have this allocated on first device probe and free it on last
>>>>> device deinit ?
>>>>
>>>> That seems even more involved. It would be easier to go back to the previous
>>>> version and simply, alloc it once per ath12k_base
>>>>
>>>> What do you guys think ?
>>>>
>>>
>>> Going back to that may be the better solution. It isn't nice that this current
>>> solution may allocate memory when the driver isn't actually used. But I'll let
>>> others on the team weigh in as well.
>>>
>>
>> Yeah, allocating once per ath12k_base is definitely the simpler
>> ownership model.
>> I was only wondering whether sharing it across devices might be worth a
>> look, since this is per-CPU scratch space and the table itself is fairly
>> large.
>
> The other alternative is to still have a single global allocation, but also
> keep a reference count that starts at 0. when each ar starts it calls a single
> api to alloc the memory and when it stops it calls another api to dealloc the
> memory
>
> when the first ar starts and calls the alloc api, the refcount will be 0 so it
> will allocate the memory and increment the refcount to 1. when any subsequent
> ars start and call the alloc api, it will just increment the ref count. on
> deinit each ar will call the dealloc api. this api will just decrement the
> refcount until it reaches 0 at which time the memory is freed.
We can do that, but we'll need a lock to protect this shared ressource:
- The clean way would mean adding yet another lock to protect this, but it
feels like there are already enough locks in ath12k.
- The other way would be to piggy back another existing one.
ath12k_hw_group_mutex would be a good candidate to be honest
What do you prefer ?
^ permalink raw reply
* [wireless:for-next] BUILD SUCCESS 789b06f9f39cdc7e895bdab2c034e39c41c8f8d6
From: kernel test robot @ 2026-03-26 8:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git for-next
branch HEAD: 789b06f9f39cdc7e895bdab2c034e39c41c8f8d6 wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free
elapsed time: 747m
configs tested: 168
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260326 gcc-8.5.0
arc randconfig-002-20260326 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm keystone_defconfig gcc-15.2.0
arm randconfig-001-20260326 gcc-8.5.0
arm randconfig-002-20260326 gcc-8.5.0
arm randconfig-003-20260326 gcc-8.5.0
arm randconfig-004-20260326 gcc-8.5.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260326 clang-19
arm64 randconfig-002-20260326 clang-19
arm64 randconfig-003-20260326 clang-19
arm64 randconfig-004-20260326 clang-19
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260326 clang-19
csky randconfig-002-20260326 clang-19
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260326 gcc-8.5.0
hexagon randconfig-002-20260326 gcc-8.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260326 gcc-14
i386 buildonly-randconfig-002-20260326 gcc-14
i386 buildonly-randconfig-003-20260326 gcc-14
i386 buildonly-randconfig-004-20260326 gcc-14
i386 buildonly-randconfig-005-20260326 gcc-14
i386 buildonly-randconfig-006-20260326 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260326 gcc-14
i386 randconfig-002-20260326 gcc-14
i386 randconfig-003-20260326 gcc-14
i386 randconfig-004-20260326 gcc-14
i386 randconfig-005-20260326 gcc-14
i386 randconfig-006-20260326 gcc-14
i386 randconfig-007-20260326 gcc-14
i386 randconfig-011-20260326 clang-20
i386 randconfig-012-20260326 clang-20
i386 randconfig-013-20260326 clang-20
i386 randconfig-014-20260326 clang-20
i386 randconfig-015-20260326 clang-20
i386 randconfig-016-20260326 clang-20
i386 randconfig-017-20260326 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260326 gcc-8.5.0
loongarch randconfig-002-20260326 gcc-8.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip30_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260326 gcc-8.5.0
nios2 randconfig-002-20260326 gcc-8.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260326 clang-19
parisc randconfig-002-20260326 clang-19
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260326 clang-19
powerpc randconfig-002-20260326 clang-19
powerpc64 randconfig-001-20260326 clang-19
powerpc64 randconfig-002-20260326 clang-19
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260326 clang-23
riscv randconfig-002-20260326 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260326 clang-23
s390 randconfig-002-20260326 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260326 clang-23
sh randconfig-002-20260326 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260326 gcc-14
sparc randconfig-002-20260326 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260326 gcc-14
sparc64 randconfig-002-20260326 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260326 gcc-14
um randconfig-002-20260326 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260326 clang-20
x86_64 buildonly-randconfig-002-20260326 clang-20
x86_64 buildonly-randconfig-003-20260326 clang-20
x86_64 buildonly-randconfig-004-20260326 clang-20
x86_64 buildonly-randconfig-005-20260326 clang-20
x86_64 buildonly-randconfig-006-20260326 clang-20
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260326 clang-20
x86_64 randconfig-002-20260326 clang-20
x86_64 randconfig-003-20260326 clang-20
x86_64 randconfig-004-20260326 clang-20
x86_64 randconfig-005-20260326 clang-20
x86_64 randconfig-006-20260326 clang-20
x86_64 randconfig-011-20260326 gcc-14
x86_64 randconfig-012-20260326 gcc-14
x86_64 randconfig-013-20260326 gcc-14
x86_64 randconfig-014-20260326 gcc-14
x86_64 randconfig-015-20260326 gcc-14
x86_64 randconfig-016-20260326 gcc-14
x86_64 randconfig-071-20260326 gcc-14
x86_64 randconfig-072-20260326 gcc-14
x86_64 randconfig-073-20260326 gcc-14
x86_64 randconfig-074-20260326 gcc-14
x86_64 randconfig-075-20260326 gcc-14
x86_64 randconfig-076-20260326 gcc-14
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260326 gcc-14
xtensa randconfig-002-20260326 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 13/13] wifi: mt76: mt7925: enable MT7927 PCI device IDs
From: Sean Wang @ 2026-03-26 6:26 UTC (permalink / raw)
To: Javier Tia
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, Marcin FM,
Cristian-Florin Radoi, George Salukvadze, Evgeny Kapusta,
Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-13-5ca66c97a755@jetm.me>
Hi, Javier
On Wed, Mar 25, 2026 at 5:14 PM Javier Tia <floss@jetm.me> wrote:
>
> Add PCI device table entries for MT7927 hardware variants:
> - 14c3:7927 (ASUS ROG Crosshair X870E Hero, Lenovo Legion Pro 7)
> - 14c3:6639 (Foxconn/Azurewave modules)
> - 14c3:0738 (AMD RZ738 / MediaTek MT7927)
>
> This is the final patch in the series, enabling MT7927 device
> enumeration after all infrastructure (DMA, IRQ, HW init, band index,
> power management) is in place.
>
> Tested-by: Marcin FM <marcin@lgic.pl>
> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
> Tested-by: George Salukvadze <giosal90@gmail.com>
> Tested-by: Evgeny Kapusta <3193631@gmail.com>
> Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
> Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
> Tested-by: Thibaut François <tibo@humeurlibre.fr>
> Tested-by: 张旭涵 <Loong.0x00@gmail.com>
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
> drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 29 +++++++++++++++----------
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> index 693e08f35d68..00c3601f14ff 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> @@ -16,6 +16,12 @@ static const struct pci_device_id mt7925_pci_device_table[] = {
> .driver_data = (kernel_ulong_t)MT7925_FIRMWARE_WM },
> { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0717),
> .driver_data = (kernel_ulong_t)MT7925_FIRMWARE_WM },
> + { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x7927),
> + .driver_data = (kernel_ulong_t)MT7927_FIRMWARE_WM },
> + { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x6639),
> + .driver_data = (kernel_ulong_t)MT7927_FIRMWARE_WM },
> + { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0738),
> + .driver_data = (kernel_ulong_t)MT7927_FIRMWARE_WM },
> { },
> };
>
> @@ -530,7 +536,8 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
> if (ret)
> goto err_free_pci_vec;
>
> - is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
> + is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927 ||
> + pdev->device == 0x0738);
>
> /* MT7927: CONNINFRA power domain and WFDMA register access are
> * unreliable with PCIe L1 active, causing throughput to drop
> @@ -546,16 +553,16 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
> goto err_free_pci_vec;
> }
>
> - /* MT7927 firmware lacks the connac2 feature trailer, so
> - * mt792x_get_mac80211_ops() can't detect CNM support and
> - * replaces chanctx/ROC/mgd_prepare_tx ops with stubs.
> - * Force CNM and restore the original mt7925 ops.
> - */
> - if ((pdev->device == 0x6639 || pdev->device == 0x7927) &&
> - !(features & MT792x_FW_CAP_CNM)) {
> - features |= MT792x_FW_CAP_CNM;
> - memcpy(ops, &mt7925_ops, sizeof(*ops));
> - }
> + /* MT7927 firmware lacks the connac2 feature trailer, so
> + * mt792x_get_mac80211_ops() can't detect CNM support and
> + * replaces chanctx/ROC/mgd_prepare_tx ops with stubs.
> + * Force CNM and restore the original mt7925 ops.
> + */
> + if ((pdev->device == 0x6639 || pdev->device == 0x7927 ||
> + pdev->device == 0x0738) && !(features & MT792x_FW_CAP_CNM)) {
> + features |= MT792x_FW_CAP_CNM;
> + memcpy(ops, &mt7925_ops, sizeof(*ops));
> + }
I think the quirk should be applied before the CNM check in
mt792x_get_mac80211_ops().
That helper already owns the fw_features detection and the ops rewrite,
so adding another memcpy() later to restore mt7925_ops feels fragile.
The final ops selection is no longer decided in one place, and the extra
full memcpy() depends on the current call flow and implementation
details of mt792x_get_mac80211_ops().
If MT7927 should force MT792x_FW_CAP_CNM despite the missing trailer,
please fold that into mt792x_get_mac80211_ops() and keep the ops
selection in one place.
>
> mdev = mt76_alloc_device(&pdev->dev, sizeof(*dev), ops, &drv_ops);
> if (!mdev) {
>
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH v3 12/13] wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
From: Sean Wang @ 2026-03-26 6:14 UTC (permalink / raw)
To: Javier Tia
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-12-5ca66c97a755@jetm.me>
Hi, Javier
On Wed, Mar 25, 2026 at 5:13 PM Javier Tia <floss@jetm.me> wrote:
>
> Disable PCIe ASPM unconditionally for MT7927. The CONNINFRA power
> domain and WFDMA register access are unreliable with PCIe L1 active,
> causing throughput to drop from 1+ Gbps to ~200 Mbps.
>
> Disable runtime PM and deep sleep for MT7927. The combo chip shares
> a CONNINFRA power domain between WiFi (PCIe) and BT (USB).
> SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT
> firmware, requiring a full power cycle to recover. PM enablement will
> be addressed in a follow-up once safe power state transitions are
> determined.
>
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
> drivers/net/wireless/mediatek/mt76/mt7925/init.c | 6 +++++-
> drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 9 +++++++--
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/init.c b/drivers/net/wireless/mediatek/mt76/mt7925/init.c
> index c4c99380f5b5..89140fc6a2b6 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7925/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7925/init.c
> @@ -243,7 +243,11 @@ int mt7925_register_device(struct mt792x_dev *dev)
> dev->pm.idle_timeout = MT792x_PM_TIMEOUT;
> dev->pm.stats.last_wake_event = jiffies;
> dev->pm.stats.last_doze_event = jiffies;
> - if (!mt76_is_usb(&dev->mt76)) {
> + /* MT7927: runtime PM disabled. The combo chip shares a CONNINFRA
> + * power domain between WiFi (PCIe) and BT (USB). SET_OWN/CLR_OWN
> + * transitions on the LPCTL register crash BT firmware.
> + */
I think this level of detail is better kept in the commit message. For
the code itself, a short comment should be enough, or even no comment
if the condition is already clear enough.
> + if (!mt76_is_usb(&dev->mt76) && !is_mt7927(&dev->mt76)) {
> dev->pm.enable_user = true;
> dev->pm.enable = true;
> dev->pm.ds_enable_user = true;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> index 393d9f408b84..693e08f35d68 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
> @@ -530,7 +530,13 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
> if (ret)
> goto err_free_pci_vec;
>
> - if (mt7925_disable_aspm)
> + is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
> +
> + /* MT7927: CONNINFRA power domain and WFDMA register access are
> + * unreliable with PCIe L1 active, causing throughput to drop
> + * from 1+ Gbps to ~200 Mbps. Disable ASPM unconditionally.
> + */
Ditto
> + if (mt7925_disable_aspm || is_mt7927_hw)
> mt76_pci_disable_aspm(pdev);
>
> ops = mt792x_get_mac80211_ops(&pdev->dev, &mt7925_ops,
> @@ -562,7 +568,6 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
> dev = container_of(mdev, struct mt792x_dev, mt76);
> dev->fw_features = features;
> dev->hif_ops = &mt7925_pcie_ops;
> - is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
> dev->irq_map = is_mt7927_hw ? &mt7927_irq_map : &irq_map;
> dev->dma_config = is_mt7927_hw ? &mt7927_dma_cfg : &mt7925_dma_cfg;
> mt76_mmio_init(&dev->mt76, pcim_iomap_table(pdev)[0]);
>
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH v3 05/13] wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
From: Sean Wang @ 2026-03-26 6:08 UTC (permalink / raw)
To: Javier Tia
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, Marcin FM,
Cristian-Florin Radoi, George Salukvadze, Evgeny Kapusta,
Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-5-5ca66c97a755@jetm.me>
Hi, Javier
On Wed, Mar 25, 2026 at 5:14 PM Javier Tia <floss@jetm.me> wrote:
>
> mt7925_init_eht_caps() only populates EHT MCS/NSS maps for BW <= 80
> and BW = 160, but never sets BW = 320. This means iw phy shows no
> 320MHz MCS map entries even though the hardware supports 320MHz
> operation in the 6GHz band.
>
> Add the missing 320MHz capability bits for 6GHz:
> - PHY_CAP0: IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ
> - PHY_CAP1: beamformee SS for 320MHz
> - PHY_CAP2: sounding dimensions for 320MHz
> - PHY_CAP6: MCS15 support for 320MHz width
> - MCS/NSS: populate bw._320 maps for 6GHz band
>
> Introduce is_320mhz_supported() to gate 320MHz on MT7927 only, since
> MT7925 does not support 320MHz operation.
>
> Tested-by: Marcin FM <marcin@lgic.pl>
> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
> Tested-by: George Salukvadze <giosal90@gmail.com>
> Tested-by: Evgeny Kapusta <3193631@gmail.com>
> Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
> Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
> Tested-by: Thibaut François <tibo@humeurlibre.fr>
> Tested-by: 张旭涵 <Loong.0x00@gmail.com>
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
> drivers/net/wireless/mediatek/mt76/mt76_connac.h | 5 +++++
> drivers/net/wireless/mediatek/mt76/mt7925/main.c | 22 +++++++++++++++++++++-
> 2 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac.h b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
> index 813d61bffc2c..3785fbf5ac99 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76_connac.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
> @@ -177,6 +177,11 @@ static inline bool is_mt7925(struct mt76_dev *dev)
> return mt76_chip(dev) == 0x7925;
> }
>
> +static inline bool is_320mhz_supported(struct mt76_dev *dev)
> +{
> + return is_mt7927(dev);
This looks like it would cause a build error since is_mt7927() is not
introduced until patch 6.
> +}
> +
> static inline bool is_mt7920(struct mt76_dev *dev)
> {
> return mt76_chip(dev) == 0x7920;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> index f128a198f81d..cfce851a94e2 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
> @@ -183,6 +183,10 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> IEEE80211_EHT_PHY_CAP0_SU_BEAMFORMER |
> IEEE80211_EHT_PHY_CAP0_SU_BEAMFORMEE;
>
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
> + eht_cap_elem->phy_cap_info[0] |=
> + IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
> +
> eht_cap_elem->phy_cap_info[0] |=
> u8_encode_bits(u8_get_bits(sts - 1, BIT(0)),
> IEEE80211_EHT_PHY_CAP0_BEAMFORMEE_SS_80MHZ_MASK);
> @@ -193,10 +197,20 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> u8_encode_bits(sts - 1,
> IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_160MHZ_MASK);
>
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
> + eht_cap_elem->phy_cap_info[1] |=
> + u8_encode_bits(sts - 1,
> + IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK);
> +
> eht_cap_elem->phy_cap_info[2] =
> u8_encode_bits(sts - 1, IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_80MHZ_MASK) |
> u8_encode_bits(sts - 1, IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_160MHZ_MASK);
>
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
> + eht_cap_elem->phy_cap_info[2] |=
> + u8_encode_bits(sts - 1,
> + IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK);
> +
> eht_cap_elem->phy_cap_info[3] =
> IEEE80211_EHT_PHY_CAP3_NG_16_SU_FEEDBACK |
> IEEE80211_EHT_PHY_CAP3_NG_16_MU_FEEDBACK |
> @@ -217,7 +231,8 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> u8_encode_bits(u8_get_bits(0x11, GENMASK(1, 0)),
> IEEE80211_EHT_PHY_CAP5_MAX_NUM_SUPP_EHT_LTF_MASK);
>
> - val = width == NL80211_CHAN_WIDTH_160 ? 0x7 :
> + val = width == NL80211_CHAN_WIDTH_320 ? 0xf :
> + width == NL80211_CHAN_WIDTH_160 ? 0x7 :
> width == NL80211_CHAN_WIDTH_80 ? 0x3 : 0x1;
> eht_cap_elem->phy_cap_info[6] =
> u8_encode_bits(u8_get_bits(0x11, GENMASK(4, 2)),
> @@ -239,6 +254,11 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
> eht_nss->bw._160.rx_tx_mcs9_max_nss = val;
> eht_nss->bw._160.rx_tx_mcs11_max_nss = val;
> eht_nss->bw._160.rx_tx_mcs13_max_nss = val;
> + if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76)) {
> + eht_nss->bw._320.rx_tx_mcs9_max_nss = val;
> + eht_nss->bw._320.rx_tx_mcs11_max_nss = val;
> + eht_nss->bw._320.rx_tx_mcs13_max_nss = val;
> + }
> }
>
> int mt7925_init_mlo_caps(struct mt792x_phy *phy)
>
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH v3 00/13] This series adds support for the MediaTek MT7927 (Filogic 380) combo
From: Sean Wang @ 2026-03-26 5:56 UTC (permalink / raw)
To: Javier Tia
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, Marcin FM,
Cristian-Florin Radoi, George Salukvadze, Evgeny Kapusta,
Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-0-5ca66c97a755@jetm.me>
Hi, Javier
Sorry for the late reply. This version already looks better than v1
overall, and the patch order is cleaner. I still think a few areas
could be refined further, as this would also be a good opportunity to
refactor the code a bit so mt7927 support fits more naturally and
future chips are easier to handle as well.
On Wed, Mar 25, 2026 at 5:11 PM Javier Tia <floss@jetm.me> wrote:
>
> WiFi 7 + BT 5.4 module to the mt7925 driver. The MT7927 uses PCI ID
> 14c3:7927 (some hardware reports 14c3:6639) and shares the mt7925
> firmware interface but requires different DMA ring layout, IRQ mapping,
> chip initialization, and power management handling.
>
> Tested hardware:
> - ASUS ROG Crosshair X870E Hero (BT 0489:e13a, WiFi 14c3:6639)
> - ASUS ProArt X870E-Creator WiFi (BT 0489:e13a / 13d3:3588, WiFi 14c3:6639)
> - ASUS ROG Strix X870-I (WiFi 14c3:7927)
> - ASUS ROG Strix X870-F Gaming WiFi (BT 0489:e13a, WiFi 14c3:7927)
> - ASUS ROG Strix X870E-E (BT 13d3:3588, WiFi 14c3:7927)
> - Gigabyte X870E Aorus Master X3D (BT 0489:e10f, WiFi 14c3:7927)
> - Gigabyte Z790 AORUS MASTER X (BT 0489:e10f, WiFi 14c3:7927)
> - Gigabyte Z790 AORUS ELITE X WiFi7 (BT 0489:e10f, WiFi 14c3:7927)
> - MSI MEG X870E ACE MAX (BT 0489:e110, WiFi 14c3:7927)
> - Lenovo Legion Pro 7 16ARX9 (BT 0489:e0fa, WiFi 14c3:7927)
> - Lenovo Legion Pro 7 16AFR10H (BT 0489:e0fa, WiFi 14c3:7927)
> - TP-Link Archer TBE550E PCIe (BT 0489:e116, WiFi 14c3:7927)
> - EDUP EP-MT7927BE M.2 card (WiFi 14c3:7927)
> - Foxconn/Azurewave M.2 modules (WiFi 14c3:6639)
> - AMD RZ738 reference design (WiFi 14c3:0738)
>
> Tested on Arch Linux, CachyOS, EndeavourOS, Fedora (Bazzite), NixOS,
> openSUSE Tumbleweed, and Ubuntu across kernels 6.13-6.19.
>
> What works:
> - WiFi 7 with EHT 320MHz on 2.4/5/6 GHz bands
> - 320MHz data path verified at 841 Mbps (iperf3 -t30 -P8)
> - PCIe initialization with CBTOP remap and MT7927-specific DMA layout
> - System suspend/resume (S3)
> - DBDC (dual-band concurrent) mode
> - Explicit band_idx assignment for stable 5GHz/6GHz operation
> - ASPM and runtime PM disabled for MT7927 (see below)
>
> Known limitations (planned as follow-up series):
> - Runtime PM: disabled for MT7927 because the combo chip shares a
> CONNINFRA power domain between WiFi (PCIe) and BT (USB).
> SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT
> firmware, requiring a full power cycle to recover. PM enablement
> will be addressed once safe power state transitions are determined.
> - mac_reset returns -EOPNOTSUPP (DMA recovery not yet implemented)
> - MLO (Multi-Link Operation): tested working on 5GHz+2.4GHz STR
> (776 Mbps) but requires additional patches for link lifetime
> and error handling. Sean Wang's series [1] addresses these;
> MLO support will be submitted as a follow-up on top of that.
> - TX retransmissions: elevated retry rate on all bands, firmware-side
> rate adaptation issue not addressable in the driver.
>
> [1] https://lore.kernel.org/linux-wireless/20260306232238.2039675-1-sean.wang@kernel.org/
>
> Patches 1-5 add generic 320MHz EHT support (no MT7927 references).
> Patches 6-7 introduce MT7927 chip ID helpers and firmware paths.
> Patch 8 adds per-chip IRQ map handling.
This part patch 1-8 looks good overall. My only concern was a possible
regression on mt7925, but now that the incorrect mt7925 320 MHz
support has been fixed in the version, this should be fine.
> Patch 9 introduces mt792x_dma_config struct for chip-specific DMA.
> Patch 10 combines CBTOP remap, chip init, DBDC, CNM, and mac_reset.
> Patch 11 adds mt7925_band_idx() helper for stable 5/6 GHz operation.
I am still thinking a bit more about patches 9-11. My current
preference is to introduce the generic layer first, and then migrate
the mt7925 and mt7927-specific parts on top of it.
I will handle this part on my side, since I want to carefully compare
the vendor driver with your changes first, and make sure the mt7925
side is solid before moving the mt7927-related changes forward. For
the mt7927-related work, I will make sure your contribution, as well
as the work from the other volunteers, is properly preserved when I
carry this forward.
> Patch 12 disables ASPM and runtime PM for MT7927.
> Patch 13 enables the MT7927 PCI device table entries.
>
> The WiFi firmware path and filename in linux-firmware have not been
> finalized yet. The driver currently requests mediatek/mt6639/ (the
> mobile SoC codename), but this may change based on the linux-firmware
> review.
Similar to the BT side, I would prefer to have a dedicated Linux
firmware for mt7927 WiFi. I am not sure yet whether the current
changes will work seamlessly with that, so we can revisit it later and
see what further adjustments are needed.
>
> Changes since v2 (suggested by Sean Wang):
> - Fixed is_320mhz_supported() to check for MT7927 only, not the
> entire mt7925 family. MT7925 does not support 320MHz (patch 5).
> - Dropped phy_cap_info[7] 320MHz additions (NON_OFDMA_UL_MU_MIMO
> and MU_BEAMFORMER) to keep capabilities conservative (patch 5).
> - Disabled runtime PM for MT7927 (patch 12). The combo chip shares a
> CONNINFRA power domain between WiFi and BT; SET_OWN/CLR_OWN
> transitions crash BT firmware. Discovered via user reports of BT
> lockups after enabling power_save=1 (Reported-by: Nitin Gurram).
> - Added tested hardware: MSI MEG X870E ACE MAX, Gigabyte Z790 AORUS
> ELITE X WiFi7, Lenovo Legion Pro 7 16AFR10H.
>
> Changes since v1 (suggested by Sean Wang):
> - Reorganized from 18 patches into 13 across 8 logical groups
> - Common 320MHz patches first, chip-specific changes later
> - Introduced mt792x_dma_config struct to reuse mt7925_dma_init()
> instead of duplicating as mt7927_dma_init()
> - Replaced is_mt7927() with is_320mhz_supported() in common patches
> - Added mt7925_band_idx() helper replacing scattered if/else patterns
> - Renamed MT7927-specific registers with MT7927_ prefix
> - Added PCI ID 0x0738 for AMD RZ738 hardware
> - Moved GLO_CFG_EXT1 register address into dma_config struct to
> eliminate is_mt7927() from shared mt792x_dma.c
>
> Link to v2: https://lore.kernel.org/linux-wireless/20260319-mt7927-wifi-support-v2-v2-0-d627a7fad70d@jetm.me/
> Link to v1: https://lore.kernel.org/linux-wireless/20260306-mt7927-wifi-support-v1-0-c77e7445511d@jetm.me/
>
> Assisted-by: Claude (Anthropic)
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
> Javier Tia (13):
> wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links
> wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv
> wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS
> wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
> wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
> wifi: mt76: mt7925: add MT7927 chip ID helpers
> wifi: mt76: mt7925: add MT7927 firmware paths
> wifi: mt76: mt7925: use irq_map for chip-specific interrupt handling
> wifi: mt76: mt7925: add chip-specific DMA configuration
> wifi: mt76: mt7925: add MT7927 hardware initialization
> wifi: mt76: mt7925: fix band_idx for stable 5GHz/6GHz operation
> wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
> wifi: mt76: mt7925: enable MT7927 PCI device IDs
>
> drivers/net/wireless/mediatek/mt76/mt76_connac.h | 13 +-
> drivers/net/wireless/mediatek/mt76/mt7925/init.c | 19 +-
> drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 9 +
> drivers/net/wireless/mediatek/mt76/mt7925/main.c | 61 ++++-
> drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 55 +++-
> drivers/net/wireless/mediatek/mt76/mt7925/mt7925.h | 7 +
> drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 277 +++++++++++++++++++--
> .../net/wireless/mediatek/mt76/mt7925/pci_mac.c | 14 +-
> .../net/wireless/mediatek/mt76/mt7925/pci_mcu.c | 20 +-
> drivers/net/wireless/mediatek/mt76/mt792x.h | 27 ++
> drivers/net/wireless/mediatek/mt76/mt792x_dma.c | 68 ++---
> drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 33 +++
> 12 files changed, 528 insertions(+), 75 deletions(-)
> ---
> base-commit: 9ac76f3d0bb2940db3a9684d596b9c8f301ef315
> change-id: 20260319-mt7927-wifi-support-v2-e89d779b28f4
>
> Best regards,
> --
> Javier Tia <floss@jetm.me>
>
>
^ permalink raw reply
* Re: [PATCH ath-next v2 2/5] wifi: ath12k: Add ath12k_hw_params for IPQ5424
From: Raj Kumar Bhagat @ 2026-03-26 5:10 UTC (permalink / raw)
To: Jeff Johnson, Raj Kumar Bhagat, Johannes Berg, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy
In-Reply-To: <12cb2f34-2142-4a38-9e73-49c2cf66d8f8@oss.qualcomm.com>
On 20-05-2025 21:29, Jeff Johnson wrote:
> On 5/18/2025 11:22 AM, Raj Kumar Bhagat wrote:
>> diff --git a/drivers/net/wireless/ath/ath12k/hw.c b/drivers/net/wireless/ath/ath12k/hw.c
>> index 7e2cf0fb2085ab014fc14a5c81074802674b154e..866de53f37bb5af94e16c796a0052fda39eb4ea8 100644
>> --- a/drivers/net/wireless/ath/ath12k/hw.c
>> +++ b/drivers/net/wireless/ath/ath12k/hw.c
>> @@ -1590,6 +1590,84 @@ static const struct ath12k_hw_params ath12k_hw_params[] = {
>> .ce_remap = &ath12k_ce_remap_ipq5332,
>> .bdf_addr_offset = 0xC00000,
>>
>> + .dp_primary_link_only = true,
>> + },
>> + {
>> + .name = "ipq5424 hw1.0",
>> + .hw_rev = ATH12K_HW_IPQ5424_HW10,
>> + .fw = {
>> + .dir = "IPQ5424/hw1.0",
>> + .board_size = 256 * 1024,
>> + .cal_offset = 128 * 1024,
>> + .m3_loader = ath12k_m3_fw_loader_remoteproc,
>
> Until the firmware is available in linux-firmware I cannot accept this series.
> Please work with the firmware team to make sure I get firmware via the
> internal release process so that I can stage it.
>
Hi Jeff,
The Firmware binaries are now uploaded to CLO:
https://git.codelinaro.org/clo/ath-firmware/ath12k-firmware/-/tree/main/IPQ5424/hw1.0?ref_type=heads
Will send the next version and resume this series.
^ permalink raw reply
* [PATCH ath-next] wifi: ath12k: Support channel change stats
From: Roopni Devanathan @ 2026-03-26 5:06 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Harish Rachakonda, Roopni Devanathan
From: Harish Rachakonda <quic_rachakon@quicinc.com>
Add support to request channel change stats from the firmware through
HTT stats type 76. These stats give channel switch details like the
channel that the radio changed to, its center frequency, time taken
for the switch, chainmask details, etc.
Sample output:
echo 76 > /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/htt_stats_type
cat /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/htt_stats
Channel Change Timings:
|PRIMARY CHANNEL FREQ|BANDWIDTH CENTER FREQ|PHYMODE|TX_CHAINMASK|RX_CHAINMASK|SWITCH TIME(us)|INI(us)|TPC+CTL(us)|CAL(us)|MISC(us)|CTL(us)|SW PROFILE|
| 5200| 5200| 24| 15| 15| 448850| 2410| 10546| 434593| 1071| 1100| 4|
| 5240| 5240| 24| 15| 15| 450730| 4106| 10524| 434528| 1306| 1150| 4|
| 5180| 5210| 26| 15| 15| 467894| 4764| 10438| 451101| 1337| 1508| 4|
| 5200| 5200| 0| 15| 15| 13838| 2692| 1736| 8558| 686| 802| 6|
| 5180| 5180| 0| 15| 15| 13465| 3207| 855| 8579| 578| 760| 6|
| 5200| 5200| 24| 15| 15| 570321| 2441| 10439| 555661| 1574| 949| 4|
Note: WCN7850 firmware does not support HTT stats type 76.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1
Signed-off-by: Harish Rachakonda <quic_rachakon@quicinc.com>
Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com>
---
.../wireless/ath/ath12k/debugfs_htt_stats.c | 72 +++++++++++++++++++
.../wireless/ath/ath12k/debugfs_htt_stats.h | 26 +++++++
2 files changed, 98 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/debugfs_htt_stats.c b/drivers/net/wireless/ath/ath12k/debugfs_htt_stats.c
index 7f6ca07fb335..b772181a496e 100644
--- a/drivers/net/wireless/ath/ath12k/debugfs_htt_stats.c
+++ b/drivers/net/wireless/ath/ath12k/debugfs_htt_stats.c
@@ -5722,6 +5722,75 @@ ath12k_htt_print_tx_hwq_stats_cmn_tlv(const void *tag_buf, u16 tag_len,
stats_req->buf_len = len;
}
+static void
+ath12k_htt_print_chan_switch_stats_tlv(const void *tag_buf, u16 tag_len,
+ struct debug_htt_stats_req *stats_req)
+{
+ const struct ath12k_htt_chan_switch_stats_tlv *sbuf = tag_buf;
+ u32 buf_len = ATH12K_HTT_STATS_BUF_SIZE;
+ u32 switch_freq, switch_profile;
+ u32 len = stats_req->buf_len;
+ u8 *buf = stats_req->buf;
+ u8 i;
+
+ if (tag_len < sizeof(*sbuf))
+ return;
+
+ i = min(le32_to_cpu(sbuf->switch_count), ATH12K_HTT_CHAN_SWITCH_STATS_BUF_LEN);
+ if (!i)
+ return;
+
+ len += scnprintf(buf + len, buf_len - len, "Channel Change Timings:\n");
+ len += scnprintf(buf + len, buf_len - len,
+ "|%-20s|%-21s|%-7s|%-12s|%-12s|%-15s|",
+ "PRIMARY CHANNEL FREQ", "BANDWIDTH CENTER FREQ", "PHYMODE",
+ "TX_CHAINMASK", "RX_CHAINMASK", "SWITCH TIME(us)");
+ len += scnprintf(buf + len, buf_len - len,
+ "%-7s|%-11s|%-7s|%-8s|%-7s|%-10s|\n",
+ "INI(us)", "TPC+CTL(us)", "CAL(us)", "MISC(us)", "CTL(us)",
+ "SW PROFILE");
+
+ /*
+ * sbuf->switch_count has the number of successful channel changes. The firmware
+ * sends the record of channel change in such a way that sbuf->chan_stats[0] will
+ * point to the channel change that occurred first and the recent channel change
+ * records will be stored in sbuf->chan_stats[9]. As and when new channel change
+ * occurs, sbuf->chan_stats[0] will be replaced by records from the next index,
+ * sbuf->chan_stats[1]. While printing the records, reverse chronological order
+ * is followed, i.e., the most recent channel change records are printed first
+ * and the oldest one, last.
+ */
+ while (i--) {
+ switch_freq = le32_to_cpu(sbuf->chan_stats[i].chan_switch_freq);
+ switch_profile = le32_to_cpu(sbuf->chan_stats[i].chan_switch_profile);
+
+ len += scnprintf(buf + len, buf_len - len,
+ "|%20u|%21u|%7u|%12u|%12u|%15u|",
+ u32_get_bits(switch_freq,
+ ATH12K_HTT_STATS_CHAN_SWITCH_BW_MHZ),
+ u32_get_bits(switch_freq,
+ ATH12K_HTT_STATS_CHAN_SWITCH_BAND_FREQ),
+ u32_get_bits(switch_profile,
+ ATH12K_HTT_STATS_CHAN_SWITCH_PHY_MODE),
+ u32_get_bits(switch_profile,
+ ATH12K_HTT_STATS_CHAN_SWITCH_TX_CHAINMASK),
+ u32_get_bits(switch_profile,
+ ATH12K_HTT_STATS_CHAN_SWITCH_RX_CHAINMASK),
+ le32_to_cpu(sbuf->chan_stats[i].chan_switch_time));
+ len += scnprintf(buf + len, buf_len - len,
+ "%7u|%11u|%7u|%8u|%7u|%10u|\n",
+ le32_to_cpu(sbuf->chan_stats[i].ini_module_time),
+ le32_to_cpu(sbuf->chan_stats[i].tpc_module_time),
+ le32_to_cpu(sbuf->chan_stats[i].cal_module_time),
+ le32_to_cpu(sbuf->chan_stats[i].misc_module_time),
+ le32_to_cpu(sbuf->chan_stats[i].ctl_module_time),
+ u32_get_bits(switch_profile,
+ ATH12K_HTT_STATS_CHAN_SWITCH_SW_PROFILE));
+ }
+
+ stats_req->buf_len = len;
+}
+
static int ath12k_dbg_htt_ext_stats_parse(struct ath12k_base *ab,
u16 tag, u16 len, const void *tag_buf,
void *user_data)
@@ -6024,6 +6093,9 @@ static int ath12k_dbg_htt_ext_stats_parse(struct ath12k_base *ab,
case HTT_STATS_TX_HWQ_CMN_TAG:
ath12k_htt_print_tx_hwq_stats_cmn_tlv(tag_buf, len, stats_req);
break;
+ case HTT_STATS_CHAN_SWITCH_STATS_TAG:
+ ath12k_htt_print_chan_switch_stats_tlv(tag_buf, len, stats_req);
+ break;
default:
break;
}
diff --git a/drivers/net/wireless/ath/ath12k/debugfs_htt_stats.h b/drivers/net/wireless/ath/ath12k/debugfs_htt_stats.h
index bfabe6500d44..82ab7b9e4db9 100644
--- a/drivers/net/wireless/ath/ath12k/debugfs_htt_stats.h
+++ b/drivers/net/wireless/ath/ath12k/debugfs_htt_stats.h
@@ -164,6 +164,7 @@ enum ath12k_dbg_htt_ext_stats_type {
ATH12K_DBG_HTT_PDEV_MLO_IPC_STATS = 64,
ATH12K_DBG_HTT_EXT_PDEV_RTT_RESP_STATS = 65,
ATH12K_DBG_HTT_EXT_PDEV_RTT_INITIATOR_STATS = 66,
+ ATH12K_DBG_HTT_EXT_CHAN_SWITCH_STATS = 76,
/* keep this last */
ATH12K_DBG_HTT_NUM_EXT_STATS,
@@ -267,6 +268,7 @@ enum ath12k_dbg_htt_tlv_tag {
HTT_STATS_PDEV_RTT_HW_STATS_TAG = 196,
HTT_STATS_PDEV_RTT_TBR_SELFGEN_QUEUED_STATS_TAG = 197,
HTT_STATS_PDEV_RTT_TBR_CMD_RESULT_STATS_TAG = 198,
+ HTT_STATS_CHAN_SWITCH_STATS_TAG = 213,
HTT_STATS_MAX_TAG,
};
@@ -2156,4 +2158,28 @@ struct htt_tx_hwq_stats_cmn_tlv {
__le32 txq_timeout;
} __packed;
+#define ATH12K_HTT_CHAN_SWITCH_STATS_BUF_LEN 10
+
+#define ATH12K_HTT_STATS_CHAN_SWITCH_BW_MHZ GENMASK(15, 0)
+#define ATH12K_HTT_STATS_CHAN_SWITCH_BAND_FREQ GENMASK(31, 16)
+#define ATH12K_HTT_STATS_CHAN_SWITCH_PHY_MODE GENMASK(7, 0)
+#define ATH12K_HTT_STATS_CHAN_SWITCH_TX_CHAINMASK GENMASK(15, 8)
+#define ATH12K_HTT_STATS_CHAN_SWITCH_RX_CHAINMASK GENMASK(23, 16)
+#define ATH12K_HTT_STATS_CHAN_SWITCH_SW_PROFILE GENMASK(31, 24)
+
+struct ath12k_htt_chan_switch_stats_tlv {
+ struct {
+ __le32 chan_switch_freq;
+ __le32 chan_switch_profile;
+ __le32 chan_switch_time;
+ __le32 cal_module_time;
+ __le32 ini_module_time;
+ __le32 tpc_module_time;
+ __le32 misc_module_time;
+ __le32 ctl_module_time;
+ __le32 reserved;
+ } chan_stats[ATH12K_HTT_CHAN_SWITCH_STATS_BUF_LEN];
+ __le32 switch_count; /* shows how many channel changes have occurred */
+} __packed;
+
#endif
base-commit: 37538641dac955f6690372f0ebb94e5e14a23418
--
2.43.0
^ permalink raw reply related
* RE: [PATCH rtw-next] wifi: rtw88: coex: Ignore BT info byte 5 from RTL8821A
From: Ping-Ke Shih @ 2026-03-26 2:20 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <bbf06c83-d2ee-4205-8fbb-829e2347586f@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Sometimes while watching a Youtube video with Bluetooth headphones the
> audio has a lot of interruptions, because the 5th byte of the BT info
> sent by RTL8821AU has strange values, which result in
> coex_stat->bt_hid_pair_num being 2 or 3. When this happens
> rtw_coex_freerun_check() returns true, which causes
> rtw_coex_action_wl_connected() to call rtw_coex_action_freerun() instead
> of rtw_coex_action_bt_a2dp().
>
> The RTL8821AU vendor driver doesn't do anything with the 5th byte of the
> BT info, so ignore it here as well.
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply
* Re: [PATCH v3 7/8] arm64: dts: qcom: sdm845-db845c: describe WiFi/BT properly
From: Dmitry Baryshkov @ 2026-03-26 1:59 UTC (permalink / raw)
To: David Heidelberg
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul, linux-arm-msm,
Liam Girdwood, linux-kernel, devicetree, Luiz Augusto von Dentz,
Rob Herring, linux-bluetooth, Balakrishna Godavarthi,
Matthias Kaehlcke, linux-wireless, Jeff Johnson, ath10k, linux-pm,
Bartosz Golaszewski, Krzysztof Kozlowski, Mark Brown,
Krzysztof Kozlowski, Bartosz Golaszewski, Marcel Holtmann,
Conor Dooley, Manivannan Sadhasivam
In-Reply-To: <a75f80bc-d2fa-41f6-91aa-8252fbb415e6@ixit.cz>
On Thu, 26 Mar 2026 at 02:02, David Heidelberg <david@ixit.cz> wrote:
>
> On 19/01/2026 18:08, Dmitry Baryshkov wrote:
>
> [...]
>
> > + wcn3990-pmu {
> > + compatible = "qcom,wcn3990-pmu";
> > +
> > + pinctrl-0 = <&sw_ctrl_default>;
> > + pinctrl-names = "default";
> > +
> > + vddio-supply = <&vreg_s4a_1p8>;
> > + vddxo-supply = <&vreg_l7a_1p8>;
> > + vddrf-supply = <&vreg_l17a_1p3>;
> > + vddch0-supply = <&vreg_l25a_3p3>;
> > + vddch1-supply = <&vreg_l23a_3p3>;
> > +
> > + swctrl-gpios = <&pm8998_gpios 3 GPIO_ACTIVE_HIGH>;
>
> Do you know if the GPIO is common for whole sdm845, or it's only recommended as
> reference design, or nothing?
>
> I did test defaulting to GPIO 3 on Pixel 3 and WiFi works as before, but since
> previous downstream kernel didn't touched GPIO 3 at all, I'm worried about
> toggling unrelated GPIO.
It is an input-only GPIO, but nevertheless, if you are not sure, just skip it.
--
With best wishes
Dmitry
^ permalink raw reply
* RE: [PATCH rtw-next] wifi: rtw88: WARN only once in rtw_phy_get_tx_power_limit()
From: Ping-Ke Shih @ 2026-03-26 1:58 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <491d5140-f16d-44a6-bf01-8f35e43e2fdf@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>
> On 09/02/2026 10:01, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> This function WARNs when the wifi band, channel number, channel width,
> >> rate, or RF path are invalid. Two or three people have reported that it
> >> floods the kernel log with warnings because they try to switch to
> >> invalid channel numbers, like 130.
> >>
> >> One warning is probably enough, so turn WARN into WARN_ONCE.
> >>
> >> Closes: https://github.com/lwfinger/rtw88/issues/428
> >
> > As the issue says "invalid arguments, band=1, bw=2, path=1, rate=83, ch=130",
> > I think it operates on bandwidth 80MHz and primary channel 130.
> > But I don't see 20MHz primary channel, for example [1].
> >
> > Can we stop using this channel at set_channel() ahead to avoid this error?
> >
> > [1] https://en.wikipedia.org/wiki/List_of_WLAN_channels
> >
>
> Is there a standard which says what channels are allowed?
>
> Six weeks ago I asked people to test another patch which adds a check
> in rtw_set_channel() like you said, but no one replied. I guess I will
> send it as v2.
We are working on a patch to stop this kind of channels. I'd send a RFC
in coming week.
>
> By the way, there is another patch related to this problem:
>
> https://lore.kernel.org/linux-wireless/20260306-rtw88_channel130-v1-1-ff25a5
> bc930a@igalia.com/
>
I see.
Ping-Ke
^ permalink raw reply
* RE: [PATCH rtw-next] wifi: rtw89: Fill fw_version member of struct wiphy
From: Ping-Ke Shih @ 2026-03-26 1:55 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <60bdb2f8-d5dd-46a3-8679-5b4a5fd0604b@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Let userspace tools like lshw show the firmware version by filling the
> fw_version member of struct wiphy.
>
> Before:
>
> configuration: broadcast=yes driver=rtw89_8852au
> driverversion=6.19.6-arch1-1 firmware=N/A link=no multicast=yes
> wireless=IEEE 802.11
>
> After:
>
> configuration: broadcast=yes driver=rtw89_8852au
> driverversion=6.19.6-arch1-1 firmware=0.13.36.2 link=no multicast=yes
> wireless=IEEE 802.11
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> ---
> drivers/net/wireless/realtek/rtw89/fw.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/fw.c
> b/drivers/net/wireless/realtek/rtw89/fw.c
> index 45d8c5e70084..55aee6eb8478 100644
> --- a/drivers/net/wireless/realtek/rtw89/fw.c
> +++ b/drivers/net/wireless/realtek/rtw89/fw.c
> @@ -755,6 +755,14 @@ static int rtw89_fw_update_ver(struct rtw89_dev *rtwdev,
> fw_suit->major_ver, fw_suit->minor_ver, fw_suit->sub_ver,
> fw_suit->sub_idex, fw_suit->commitid, fw_suit->cmd_ver,
> type);
>
> + if (type == RTW89_FW_NORMAL || type == RTW89_FW_NORMAL_CE ||
> + type == RTW89_FW_NORMAL_B)
> + snprintf(rtwdev->hw->wiphy->fw_version,
> + sizeof(rtwdev->hw->wiphy->fw_version),
nit: how about defining a local variable wiphy? as well as rtw88.
> + "%u.%u.%u.%u",
> + fw_suit->major_ver, fw_suit->minor_ver,
> + fw_suit->sub_ver, fw_suit->sub_idex);
> +
> return 0;
> }
>
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v2] wifi: mac80211: fix the issue of NULL pointer access when deleting the virtual interface
From: 傅继晗 @ 2026-03-26 1:37 UTC (permalink / raw)
To: oscar.alfonso.diaz
Cc: fjhhz1997, johannes, linux-kernel, linux-wireless, stable
In-Reply-To: <CA+bbHrW0Z6NdFsUwycvRhLbe3xnbXSwmb24EW4FKFtn=0TVzBw@mail.gmail.com>
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: wifi: rtw89: rtw8922ae: HWSI bus lockup during RF recalibration on AP bandwidth change
From: Ping-Ke Shih @ 2026-03-26 0:23 UTC (permalink / raw)
To: Jeffrey Wälti; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <uyjP590fzro7xuECRhUp6nlegi4hnWSBbrrFd-tcCcKeeKbDaoUThi7EkMNUMC2LYibyA0jaAqR7GrIchbJcGVh5CSgiGa39jMQkLq5F9QY=@waelti.dev>
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
> > 2) reference and install
> https://github.com/lwfinger/rtw89/blob/main/70-rtw89.conf
> > and then cold reboot.
Have you tested with these conditions?
[...]
> >
> > 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?
> >
> > 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
^ permalink raw reply
* Re: [PATCH v2 05/13] wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
From: Javier Tia @ 2026-03-26 0:18 UTC (permalink / raw)
To: Sean Wang
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno, Deren Wu,
Ming Yen Hsieh, linux-wireless, linux-kernel, linux-arm-kernel,
linux-mediatek, Marcin FM, Cristian-Florin Radoi,
George Salukvadze, Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld,
Chapuis Dario, Thibaut François, 张旭涵
Hi Sean,
On Mon, Mar 24, 2026 Sean Wang wrote:
> I don't think this is correct for mt7925, and it will cause a
> regression there. Was this tested on actual mt7925 hardware?
You are right. I do not have mt7925 hardware to verify against.
In v3, is_320mhz_supported() now checks is_mt7927() only, so
mt7925 behavior is unchanged.
> I don't think this should be copied from mt7996 as-is for mt7927. I'd
> suggest dropping the eht_cap_elem->phy_cap_info[7] change and keeping
> it conservative for now.
Agreed. The phy_cap_info[7] additions (NON_OFDMA_UL_MU_MIMO_320MHZ
and MU_BEAMFORMER_320MHZ) are dropped in v3. Only the MCS/NSS maps
and per-BW beamformee SS/sounding dimensions for 320MHz remain.
Both changes are in v3, sent today.
Best,
Javier
^ permalink raw reply
* Re: [PATCH v3 7/8] arm64: dts: qcom: sdm845-db845c: describe WiFi/BT properly
From: David Heidelberg @ 2026-03-26 0:02 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Vinod Koul
Cc: linux-arm-msm, Liam Girdwood, linux-kernel, devicetree,
Luiz Augusto von Dentz, Rob Herring, linux-bluetooth,
Balakrishna Godavarthi, Matthias Kaehlcke, linux-wireless,
Jeff Johnson, ath10k, linux-pm, Bartosz Golaszewski,
Krzysztof Kozlowski, Mark Brown, Krzysztof Kozlowski,
Bartosz Golaszewski, Marcel Holtmann, Conor Dooley,
Manivannan Sadhasivam
In-Reply-To: <20260119-wcn3990-pwrctl-v3-7-948df19f5ec2@oss.qualcomm.com>
On 19/01/2026 18:08, Dmitry Baryshkov wrote:
[...]
> + wcn3990-pmu {
> + compatible = "qcom,wcn3990-pmu";
> +
> + pinctrl-0 = <&sw_ctrl_default>;
> + pinctrl-names = "default";
> +
> + vddio-supply = <&vreg_s4a_1p8>;
> + vddxo-supply = <&vreg_l7a_1p8>;
> + vddrf-supply = <&vreg_l17a_1p3>;
> + vddch0-supply = <&vreg_l25a_3p3>;
> + vddch1-supply = <&vreg_l23a_3p3>;
> +
> + swctrl-gpios = <&pm8998_gpios 3 GPIO_ACTIVE_HIGH>;
Do you know if the GPIO is common for whole sdm845, or it's only recommended as
reference design, or nothing?
I did test defaulting to GPIO 3 on Pixel 3 and WiFi works as before, but since
previous downstream kernel didn't touched GPIO 3 at all, I'm worried about
toggling unrelated GPIO.
Thanks!
David
> +
> + regulators {
> + vreg_pmu_io: ldo0 {
> + regulator-name = "vreg_pmu_io";
> + };
> +
> + vreg_pmu_xo: ldo1 {
> + regulator-name = "vreg_pmu_xo";
> + };
> +
> + vreg_pmu_rf: ldo2 {
> + regulator-name = "vreg_pmu_rf";
> + };
> +
> + vreg_pmu_ch0: ldo3 {
> + regulator-name = "vreg_pmu_ch0";
> + };
> +
> + vreg_pmu_ch1: ldo4 {
> + regulator-name = "vreg_pmu_ch1";
> + };
--
David Heidelberg
^ 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