[PATCH v5 0/7] Microsoft Surface Pro 11 support

[PATCH v5 0/7] Microsoft Surface Pro 11 support

[Jérôme de Bretagne via B4 Relay]

This series brings support for the Qualcomm-based Microsoft Surface
Pro 11 covering both the OLED and LCD variants.

Signed-off-by: Dale Whinham <daleyo@gmail.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
Changes in v5:
- Move the OLED variant description to keep the logical order [Krzysztof]
- Remove a T-b: tag as not applicable for a binding [Krzysztof]
- Remove another T-b: tag already covered by authorship [Krzysztof]
- Reference disable-rfkill in qcom,ath12k.yaml to fix dtbs_check failure [Krzysztof]
- Remove erroneously copied Copyright lines [Krzysztof]
- Add the R-b: tag from Dmitry for the aggregator_registry patch
- Link to v4: https://lore.kernel.org/r/20251218-surface-sp11-for-next-v4-0-7bcf83c1504a@gmail.com

Changes in v4:
- Re-order the denali entry in the aggregator_registry acpi_match table [Dmitry]
- Improve the bindings by splitting the LCD and OLED variants into 2 entries [Konrad]
- Enable i2c4 to make it accessible through i2c-tools [Konrad]
- Document the addresses for i2c0 and i2c4 like in romulus.dtsi [Konrad]
- Fix the clock-frequency for i2c0 based on DSDT/SSDT
- Drop i2c5 which is not found in the DSDT after double-checking
- Add the R-b: tag from Konrad for the SP11 device trees
- Link to v3: https://lore.kernel.org/r/20251218-surface-sp11-for-next-v3-0-875afc7bd3b7@gmail.com

Changes in v3:
- Update the compatible strings to document both the OLED and LCD variants
- Move the disable-rfkill property into ieee80211.yaml [Rob,Krzysztof]
- Reference commit c6a7c0b09d5f and detail the disable-rfkill patch description [Rob,Krzysztof]
- Switch to the renamed hamoa.dtsi and hamoa-pmics.dtsi [Dale]
- Improve the comments describing the 2 USB Type-C port location
- Update the speaker definition to describe only 2-speakers [Konrad]
- Drop output-low from the speaker definition [Konrad]
- Enable i2c0 to make it accessible through i2c-tools [Konrad]
- Delete a non-applicable comment about removable WLAN card [Konrad]
- Re-order a few nodes and fix indentation issues [Konrad]
- Squash one of the patches as suggested [Krzysztof]
- Drop the NAKed patch patch about a dpcd link rate quirk [Dmitry]
- Include the Reviewed-by: tags
- Link to v2: https://lore.kernel.org/all/20251201011457.17422-1-daleyo@gmail.com/

Changes in v2:
  - Dropped ATNA30DW01 patch as it was merged.
  - Split device tree into x1e (OLED)/x1p (LCD) specific *.dts files and move common code into x1-microsoft-denali.dtsi (patch 4).
  - Device tree now enables higher external monitor refresh rates/resolutions (patch 4).
  - Device tree now enables partially working audio output; requires alsa-ucm-conf and audioreach-topology definitions in userspace (patch 4).
  - Replaced 'Work around bogus maximum link rate' with a quirk-based approach (patch 5).
  - Improve the commit message about the disable-rfkill property in response to feedback (patch 6).

---
Dale Whinham (4):
      firmware: qcom: scm: allow QSEECOM on Surface Pro 11
      platform/surface: aggregator_registry: Add Surface Pro 11 (QCOM)
      arm64: dts: qcom: Add support for Surface Pro 11
      wifi: ath12k: Add support for disabling rfkill via devicetree

Jérôme de Bretagne (3):
      dt-bindings: arm: qcom: Document Microsoft Surface Pro 11
      dt-bindings: wireless: ieee80211: Add disable-rfkill property
      dt-bindings: wireless: ath12k: Allow disable-rfkill property

 Documentation/devicetree/bindings/arm/qcom.yaml    |   11 +
 .../bindings/net/wireless/ieee80211.yaml           |    6 +
 .../bindings/net/wireless/qcom,ath12k.yaml         |    5 +
 arch/arm64/boot/dts/qcom/Makefile                  |    4 +
 arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi  | 1324 ++++++++++++++++++++
 .../dts/qcom/x1e80100-microsoft-denali-oled.dts    |   19 +
 .../boot/dts/qcom/x1p64100-microsoft-denali.dts    |   15 +
 drivers/firmware/qcom/qcom_scm.c                   |    1 +
 drivers/net/wireless/ath/ath12k/core.c             |    3 +
 .../platform/surface/surface_aggregator_registry.c |   18 +
 10 files changed, 1406 insertions(+)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251218-surface-sp11-for-next-626e327f7b33

Best regards,
-- 
Jérôme de Bretagne <jerome.debretagne@gmail.com>

[PATCH v5 1/7] dt-bindings: arm: qcom: Document Microsoft Surface Pro 11

[Jérôme de Bretagne via B4 Relay]

From: Jérôme de Bretagne <jerome.debretagne@gmail.com>

Add the compatibles for the Qualcomm-based Microsoft Surface Pro 11,
using its Denali codename.

The LCD models are using the Qualcomm Snapdragon X1 Plus (X1P64100),
the OLED ones are using the Qualcomm Snapdragon X1 Elite (X1E80100).

Due to the difference in how the built-in panel is being handled
between the OLED variant and LCD one, it is required to have two
separate DTBs, so document the compatible string for both variants.

Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d84bd3bca2010508a8225b9549d8c634efa06531..4e94776b8c4cd915d7779628c005a021d27aab63 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1067,6 +1067,12 @@ properties:
           - const: qcom,x1e78100
           - const: qcom,x1e80100
 
+      - items:
+          - const: microsoft,denali-lcd
+          - const: microsoft,denali
+          - const: qcom,x1p64100
+          - const: qcom,x1e80100
+
       - items:
           - enum:
               - asus,vivobook-s15
@@ -1089,6 +1095,11 @@ properties:
           - const: qcom,hamoa-iot-som
           - const: qcom,x1e80100
 
+      - items:
+          - const: microsoft,denali-oled
+          - const: microsoft,denali
+          - const: qcom,x1e80100
+
       - items:
           - enum:
               - asus,zenbook-a14-ux3407qa-lcd

-- 
2.47.3

[PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Jérôme de Bretagne via B4 Relay]

From: Jérôme de Bretagne <jerome.debretagne@gmail.com>

For some devices, Wi-Fi is entirely hard blocked by default making
the Wi-Fi radio unusable, except if rfkill is disabled as expected
on those models.

Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
disabling specific features based on ACPI bitflag") added a way to
support features set via ACPI, including the DISABLE_RFKILL bit.

Add a disable-rfkill property to expose the DISABLE_RFKILL bit
equivalent for devices described by a Devicetree instead of ACPI.

Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
 Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
--- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
@@ -29,6 +29,12 @@ properties:
       different 5 GHz subbands. Using them incorrectly could not work or
       decrease performance noticeably
 
+  disable-rfkill:
+    type: boolean
+    description:
+      Disable rfkill for some devices on which Wi-Fi would be entirely hard
+      blocked by default otherwise
+
 additionalProperties: true
 
 examples:

-- 
2.47.3

[PATCH v5 3/7] dt-bindings: wireless: ath12k: Allow disable-rfkill property

[Jérôme de Bretagne via B4 Relay]

From: Jérôme de Bretagne <jerome.debretagne@gmail.com>

Reference the ieee80211.yaml schema to allow disable-rfkill to
be used for models that need to disable the rfkill feature,
otherwise the Wi-Fi radio is unusable.

This is required by the Surface Pro 11 with WCN7850.

Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
 Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
index dc68dd59988fc757e8f53e809128cb4e820d66d1..e18c87b21777bc6642e551f23feff69bfb7fb435 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
@@ -21,6 +21,8 @@ properties:
   reg:
     maxItems: 1
 
+  disable-rfkill: true
+
   firmware-name:
     maxItems: 1
     description:
@@ -69,6 +71,9 @@ required:
 
 additionalProperties: false
 
+allOf:
+  - $ref: ieee80211.yaml#
+
 examples:
   - |
     #include <dt-bindings/clock/qcom,rpmh.h>

-- 
2.47.3

[PATCH v5 4/7] firmware: qcom: scm: allow QSEECOM on Surface Pro 11

[Jérôme de Bretagne via B4 Relay]

From: Dale Whinham <daleyo@gmail.com>

Enables access to EFI variables on this machine.

Signed-off-by: Dale Whinham <daleyo@gmail.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/firmware/qcom/qcom_scm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 1a6f85e463e06a12814614cea20719c90a371b69..3dabb04094f91811a430e84998d3c6c759b5c747 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2007,6 +2007,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "lenovo,yoga-slim7x" },
 	{ .compatible = "microsoft,arcata", },
 	{ .compatible = "microsoft,blackrock" },
+	{ .compatible = "microsoft,denali", },
 	{ .compatible = "microsoft,romulus13", },
 	{ .compatible = "microsoft,romulus15", },
 	{ .compatible = "qcom,hamoa-iot-evk" },

-- 
2.47.3

[PATCH v5 5/7] platform/surface: aggregator_registry: Add Surface Pro 11 (QCOM)

[Jérôme de Bretagne via B4 Relay]

From: Dale Whinham <daleyo@gmail.com>

This enables support for the Qualcomm-based Surface Pro 11.

Signed-off-by: Dale Whinham <daleyo@gmail.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/platform/surface/surface_aggregator_registry.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/platform/surface/surface_aggregator_registry.c b/drivers/platform/surface/surface_aggregator_registry.c
index 78ac3a8fbb736384f7e50f1888a71297a892a7c3..0599d5adf02e61583cf3e1fc11000070f51f7be3 100644
--- a/drivers/platform/surface/surface_aggregator_registry.c
+++ b/drivers/platform/surface/surface_aggregator_registry.c
@@ -406,6 +406,22 @@ static const struct software_node *ssam_node_group_sp9_5g[] = {
 	NULL,
 };
 
+/* Devices for Surface Pro 11 (ARM/QCOM) */
+static const struct software_node *ssam_node_group_sp11[] = {
+	&ssam_node_root,
+	&ssam_node_hub_kip,
+	&ssam_node_bat_ac,
+	&ssam_node_bat_main,
+	&ssam_node_tmp_sensors,
+	&ssam_node_hid_kip_keyboard,
+	&ssam_node_hid_kip_penstash,
+	&ssam_node_hid_kip_touchpad,
+	&ssam_node_hid_kip_fwupd,
+	&ssam_node_hid_sam_sensors,
+	&ssam_node_kip_tablet_switch,
+	NULL,
+};
+
 /* -- SSAM platform/meta-hub driver. ---------------------------------------- */
 
 static const struct acpi_device_id ssam_platform_hub_acpi_match[] = {
@@ -482,6 +498,8 @@ MODULE_DEVICE_TABLE(acpi, ssam_platform_hub_acpi_match);
 static const struct of_device_id ssam_platform_hub_of_match[] __maybe_unused = {
 	/* Surface Pro 9 5G (ARM/QCOM) */
 	{ .compatible = "microsoft,arcata", (void *)ssam_node_group_sp9_5g },
+	/* Surface Pro 11 (ARM/QCOM) */
+	{ .compatible = "microsoft,denali", (void *)ssam_node_group_sp11 },
 	/* Surface Laptop 7 */
 	{ .compatible = "microsoft,romulus13", (void *)ssam_node_group_sl7 },
 	{ .compatible = "microsoft,romulus15", (void *)ssam_node_group_sl7 },

-- 
2.47.3

[PATCH v5 6/7] arm64: dts: qcom: Add support for Surface Pro 11

[Jérôme de Bretagne via B4 Relay]

From: Dale Whinham <daleyo@gmail.com>

Add device trees for the Qualcomm X1E and X1P-based Microsoft Surface
Pro 11 machines (codenamed 'Denali').

This device is very similar to the Surface Laptop 7 ('Romulus').

Use a similar strategy to x1-asus-zenbook-a14.dtsi so that we can create
x1e and x1p-specific flavors of the device tree without too much code
duplication.

Hardware support is similar to other X1 machines. The most notable
missing features are:

- Touchscreen and pen
- Cameras (and status LEDs)

Signed-off-by: Dale Whinham <daleyo@gmail.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile                  |    4 +
 arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi  | 1324 ++++++++++++++++++++
 .../dts/qcom/x1e80100-microsoft-denali-oled.dts    |   19 +
 .../boot/dts/qcom/x1p64100-microsoft-denali.dts    |   15 +
 4 files changed, 1362 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f34d5ed331c4cc5ec01de7a0ecbc45f64c3ee15..3641f9371aae0f856e9f2050b48027a998b0c2c2 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -346,6 +346,8 @@ x1e80100-hp-omnibook-x14-el2-dtbs	:= x1e80100-hp-omnibook-x14.dtb x1-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-hp-omnibook-x14.dtb x1e80100-hp-omnibook-x14-el2.dtb
 x1e80100-lenovo-yoga-slim7x-el2-dtbs	:= x1e80100-lenovo-yoga-slim7x.dtb x1-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-lenovo-yoga-slim7x.dtb x1e80100-lenovo-yoga-slim7x-el2.dtb
+x1e80100-microsoft-denali-oled-el2-dtbs	:= x1e80100-microsoft-denali-oled.dtb x1-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-microsoft-denali-oled.dtb x1e80100-microsoft-denali-oled-el2.dtb
 x1e80100-microsoft-romulus13-el2-dtbs	:= x1e80100-microsoft-romulus13.dtb x1-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e80100-microsoft-romulus13.dtb x1e80100-microsoft-romulus13-el2.dtb
 x1e80100-microsoft-romulus15-el2-dtbs	:= x1e80100-microsoft-romulus15.dtb x1-el2.dtbo
@@ -362,3 +364,5 @@ x1p42100-hp-omnibook-x14-el2-dtbs := x1p42100-hp-omnibook-x14.dtb x1-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= x1p42100-hp-omnibook-x14.dtb x1p42100-hp-omnibook-x14-el2.dtb
 x1p42100-lenovo-thinkbook-16-el2-dtbs	:= x1p42100-lenovo-thinkbook-16.dtb x1-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= x1p42100-lenovo-thinkbook-16.dtb x1p42100-lenovo-thinkbook-16-el2.dtb
+x1p64100-microsoft-denali-el2-dtbs	:= x1p64100-microsoft-denali.dtb x1-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM)	+= x1p64100-microsoft-denali.dtb x1p64100-microsoft-denali-el2.dtb
diff --git a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
new file mode 100644
index 0000000000000000000000000000000000000000..072b7618e1976261b7d0fdf0d87098cc89babcf7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
@@ -0,0 +1,1324 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2025 Dale Whinham <daleyo@gmail.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "hamoa-pmics.dtsi"
+
+/ {
+	aliases {
+		serial0 = &uart2;
+		serial1 = &uart14;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		pinctrl-0 = <&hall_int_n_default>;
+		pinctrl-names = "default";
+
+		switch-lid {
+			gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_LID>;
+			wakeup-source;
+			wakeup-event-action = <EV_ACT_DEASSERTED>;
+		};
+	};
+
+	pmic-glink {
+		compatible = "qcom,x1e80100-pmic-glink",
+			     "qcom,sm8550-pmic-glink",
+			     "qcom,pmic-glink";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		orientation-gpios = <&tlmm 121 GPIO_ACTIVE_HIGH>,
+				    <&tlmm 123 GPIO_ACTIVE_HIGH>;
+
+		/* Left-side bottom port */
+		connector@0 {
+			compatible = "usb-c-connector";
+			reg = <0>;
+			power-role = "dual";
+			data-role = "dual";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+
+					pmic_glink_ss0_hs_in: endpoint {
+						remote-endpoint = <&usb_1_ss0_dwc3_hs>;
+					};
+				};
+
+				port@1 {
+					reg = <1>;
+
+					pmic_glink_ss0_ss_in: endpoint {
+						remote-endpoint = <&retimer_ss0_ss_out>;
+					};
+				};
+
+				port@2 {
+					reg = <2>;
+
+					pmic_glink_ss0_con_sbu_in: endpoint {
+						remote-endpoint = <&retimer_ss0_con_sbu_out>;
+					};
+				};
+			};
+		};
+
+		/* Left-side top port */
+		connector@1 {
+			compatible = "usb-c-connector";
+			reg = <1>;
+			power-role = "dual";
+			data-role = "dual";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+
+					pmic_glink_ss1_hs_in: endpoint {
+						remote-endpoint = <&usb_1_ss1_dwc3_hs>;
+					};
+				};
+
+				port@1 {
+					reg = <1>;
+
+					pmic_glink_ss1_ss_in: endpoint {
+						remote-endpoint = <&retimer_ss1_ss_out>;
+					};
+				};
+
+				port@2 {
+					reg = <2>;
+
+					pmic_glink_ss1_con_sbu_in: endpoint {
+						remote-endpoint = <&retimer_ss1_con_sbu_out>;
+					};
+				};
+			};
+		};
+	};
+
+	reserved-memory {
+		linux,cma {
+			compatible = "shared-dma-pool";
+			size = <0x0 0x8000000>;
+			reusable;
+			linux,cma-default;
+		};
+	};
+
+	vreg_edp_3p3: regulator-edp-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_EDP_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&edp_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr0_1p15: regulator-rtmr0-1p15 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR0_1P15";
+
+		regulator-min-microvolt = <1150000>;
+		regulator-max-microvolt = <1150000>;
+
+		gpio = <&pmc8380_5_gpios 8 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&rtmr0_1p15_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr0_1p8: regulator-rtmr0-1p8 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR0_1P8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		gpio = <&pm8550ve_9_gpios 8 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&rtmr0_1p8_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr0_3p3: regulator-rtmr0-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR0_3P3";
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&rtmr0_3p3_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr1_1p15: regulator-rtmr1-1p15 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR1_1P15";
+
+		regulator-min-microvolt = <1150000>;
+		regulator-max-microvolt = <1150000>;
+
+		gpio = <&tlmm 188 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&rtmr1_1p15_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr1_1p8: regulator-rtmr1-1p8 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR1_1P8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		gpio = <&tlmm 175 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&rtmr1_1p8_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_rtmr1_3p3: regulator-rtmr1-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_RTMR1_3P3";
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 186 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&rtmr1_3p3_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_nvme: regulator-nvme {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_NVME_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 18 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&nvme_reg_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vph_pwr: regulator-vph-pwr {
+		compatible = "regulator-fixed";
+
+		regulator-name = "vph_pwr";
+		regulator-min-microvolt = <3700000>;
+		regulator-max-microvolt = <3700000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vreg_wcn_3p3: regulator-wcn-3p3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_WCN_3P3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 214 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-0 = <&wcn_sw_en>;
+		pinctrl-names = "default";
+
+		regulator-boot-on;
+	};
+
+	vreg_wcn_0p95: regulator-wcn-0p95 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_WCN_0P95";
+		regulator-min-microvolt = <950000>;
+		regulator-max-microvolt = <950000>;
+
+		vin-supply = <&vreg_wcn_3p3>;
+	};
+
+	vreg_wcn_1p9: regulator-wcn-1p9 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "VREG_WCN_1P9";
+		regulator-min-microvolt = <1900000>;
+		regulator-max-microvolt = <1900000>;
+
+		vin-supply = <&vreg_wcn_3p3>;
+	};
+
+	sound {
+		compatible = "qcom,x1e80100-sndcard";
+		model = "X1E80100-Microsoft-Surface-Pro-11";
+		audio-routing = "SpkrLeft IN", "WSA WSA_SPK1 OUT",
+				"SpkrRight IN", "WSA WSA_SPK2 OUT",
+				"VA DMIC0", "vdd-micb",
+				"VA DMIC1", "vdd-micb";
+
+		wsa-dai-link {
+			link-name = "WSA Playback";
+
+			codec {
+				sound-dai = <&left_spkr>, <&right_spkr>,
+					    <&swr0 0>, <&lpass_wsamacro 0>;
+			};
+
+			cpu {
+				sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
+			};
+
+			platform {
+				sound-dai = <&q6apm>;
+			};
+		};
+
+		va-dai-link {
+			link-name = "VA Capture";
+
+			codec {
+				sound-dai = <&lpass_vamacro 0>;
+			};
+
+			cpu {
+				sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
+			};
+
+			platform {
+				sound-dai = <&q6apm>;
+			};
+		};
+	};
+
+	wcn7850-pmu {
+		compatible = "qcom,wcn7850-pmu";
+
+		vdd-supply = <&vreg_wcn_0p95>;
+		vddio-supply = <&vreg_l15b_1p8>;
+		vddaon-supply = <&vreg_wcn_0p95>;
+		vdddig-supply = <&vreg_wcn_0p95>;
+		vddrfa1p2-supply = <&vreg_wcn_1p9>;
+		vddrfa1p8-supply = <&vreg_wcn_1p9>;
+
+		wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+		bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
+
+		pinctrl-0 = <&wcn_wlan_bt_en>;
+		pinctrl-names = "default";
+
+		regulators {
+			vreg_pmu_rfa_cmn: ldo0 {
+				regulator-name = "vreg_pmu_rfa_cmn";
+			};
+
+			vreg_pmu_aon_0p59: ldo1 {
+				regulator-name = "vreg_pmu_aon_0p59";
+			};
+
+			vreg_pmu_wlcx_0p8: ldo2 {
+				regulator-name = "vreg_pmu_wlcx_0p8";
+			};
+
+			vreg_pmu_wlmx_0p85: ldo3 {
+				regulator-name = "vreg_pmu_wlmx_0p85";
+			};
+
+			vreg_pmu_btcmx_0p85: ldo4 {
+				regulator-name = "vreg_pmu_btcmx_0p85";
+			};
+
+			vreg_pmu_rfa_0p8: ldo5 {
+				regulator-name = "vreg_pmu_rfa_0p8";
+			};
+
+			vreg_pmu_rfa_1p2: ldo6 {
+				regulator-name = "vreg_pmu_rfa_1p2";
+			};
+
+			vreg_pmu_rfa_1p8: ldo7 {
+				regulator-name = "vreg_pmu_rfa_1p8";
+			};
+
+			vreg_pmu_pcie_0p9: ldo8 {
+				regulator-name = "vreg_pmu_pcie_0p9";
+			};
+
+			vreg_pmu_pcie_1p8: ldo9 {
+				regulator-name = "vreg_pmu_pcie_1p8";
+			};
+		};
+	};
+};
+
+&apps_rsc {
+	regulators-0 {
+		compatible = "qcom,pm8550-rpmh-regulators";
+		qcom,pmic-id = "b";
+
+		vdd-bob1-supply = <&vph_pwr>;
+		vdd-bob2-supply = <&vph_pwr>;
+		vdd-l1-l4-l10-supply = <&vreg_s4c_1p8>;
+		vdd-l2-l13-l14-supply = <&vreg_bob1>;
+		vdd-l5-l16-supply = <&vreg_bob1>;
+		vdd-l6-l7-supply = <&vreg_bob2>;
+		vdd-l8-l9-supply = <&vreg_bob1>;
+		vdd-l12-supply = <&vreg_s5j_1p2>;
+		vdd-l15-supply = <&vreg_s4c_1p8>;
+		vdd-l17-supply = <&vreg_bob2>;
+
+		vreg_bob1: bob1 {
+			regulator-name = "vreg_bob1";
+			regulator-min-microvolt = <3008000>;
+			regulator-max-microvolt = <3960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_bob2: bob2 {
+			regulator-name = "vreg_bob2";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1b_1p8: ldo1 {
+			regulator-name = "vreg_l1b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2b_3p0: ldo2 {
+			regulator-name = "vreg_l2b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l4b_1p8: ldo4 {
+			regulator-name = "vreg_l4b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6b_1p8: ldo6 {
+			regulator-name = "vreg_l6b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8b_3p0: ldo8 {
+			regulator-name = "vreg_l8b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9b_2p9: ldo9 {
+			regulator-name = "vreg_l9b_2p9";
+			regulator-min-microvolt = <2960000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10b_1p8: ldo10 {
+			regulator-name = "vreg_l10b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l12b_1p2: ldo12 {
+			regulator-name = "vreg_l12b_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l13b_3p0: ldo13 {
+			regulator-name = "vreg_l13b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l14b_3p0: ldo14 {
+			regulator-name = "vreg_l14b_3p0";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l15b_1p8: ldo15 {
+			regulator-name = "vreg_l15b_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l17b_2p5: ldo17 {
+			regulator-name = "vreg_l17b_2p5";
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <2504000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-1 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vdd-l1-supply = <&vreg_s5j_1p2>;
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s4-supply = <&vph_pwr>;
+
+		vreg_s4c_1p8: smps4 {
+			regulator-name = "vreg_s4c_1p8";
+			regulator-min-microvolt = <1856000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1c_1p2: ldo1 {
+			regulator-name = "vreg_l1c_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2c_0p8: ldo2 {
+			regulator-name = "vreg_l2c_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3c_0p8: ldo3 {
+			regulator-name = "vreg_l3c_0p8";
+			regulator-min-microvolt = <912000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-2 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "d";
+
+		vdd-l1-supply = <&vreg_s1f_0p7>;
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s4c_1p8>;
+		vdd-s1-supply = <&vph_pwr>;
+
+		vreg_l1d_0p8: ldo1 {
+			regulator-name = "vreg_l1d_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2d_0p9: ldo2 {
+			regulator-name = "vreg_l2d_0p9";
+			regulator-min-microvolt = <912000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3d_1p8: ldo3 {
+			regulator-name = "vreg_l3d_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-3 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "e";
+
+		vdd-l2-supply = <&vreg_s1f_0p7>;
+		vdd-l3-supply = <&vreg_s5j_1p2>;
+
+		vreg_l2e_0p8: ldo2 {
+			regulator-name = "vreg_l2e_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3e_1p2: ldo3 {
+			regulator-name = "vreg_l3e_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-4 {
+		compatible = "qcom,pmc8380-rpmh-regulators";
+		qcom,pmic-id = "f";
+
+		vdd-l1-supply = <&vreg_s5j_1p2>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s5j_1p2>;
+		vdd-s1-supply = <&vph_pwr>;
+
+		vreg_s1f_0p7: smps1 {
+			regulator-name = "vreg_s1f_0p7";
+			regulator-min-microvolt = <700000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-6 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "i";
+
+		vdd-l1-supply = <&vreg_s4c_1p8>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s1-supply = <&vph_pwr>;
+		vdd-s2-supply = <&vph_pwr>;
+
+		vreg_s1i_0p9: smps1 {
+			regulator-name = "vreg_s1i_0p9";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s2i_1p0: smps2 {
+			regulator-name = "vreg_s2i_1p0";
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1i_1p8: ldo1 {
+			regulator-name = "vreg_l1i_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2i_1p2: ldo2 {
+			regulator-name = "vreg_l2i_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3i_0p8: ldo3 {
+			regulator-name = "vreg_l3i_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	regulators-7 {
+		compatible = "qcom,pm8550ve-rpmh-regulators";
+		qcom,pmic-id = "j";
+
+		vdd-l1-supply = <&vreg_s1f_0p7>;
+		vdd-l2-supply = <&vreg_s5j_1p2>;
+		vdd-l3-supply = <&vreg_s1f_0p7>;
+		vdd-s5-supply = <&vph_pwr>;
+
+		vreg_s5j_1p2: smps5 {
+			regulator-name = "vreg_s5j_1p2";
+			regulator-min-microvolt = <1256000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1j_0p8: ldo1 {
+			regulator-name = "vreg_l1j_0p8";
+			regulator-min-microvolt = <912000>;
+			regulator-max-microvolt = <912000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2j_1p2: ldo2 {
+			regulator-name = "vreg_l2j_1p2";
+			regulator-min-microvolt = <1256000>;
+			regulator-max-microvolt = <1256000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3j_0p8: ldo3 {
+			regulator-name = "vreg_l3j_0p8";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+};
+
+&gpu {
+	status = "okay";
+
+	zap-shader {
+		memory-region = <&gpu_microcode_mem>;
+		firmware-name = "qcom/x1e80100/microsoft/qcdxkmsuc8380.mbn";
+	};
+};
+
+&i2c0 {
+	clock-frequency = <100000>;
+
+	status = "okay";
+
+	/* Something @39, @3e, @44 */
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+
+	status = "okay";
+
+	/* Left-side bottom port */
+	typec-mux@8 {
+		compatible = "parade,ps8830";
+		reg = <0x8>;
+
+		reset-gpios = <&pm8550_gpios 10 GPIO_ACTIVE_LOW>;
+
+		clocks = <&rpmhcc RPMH_RF_CLK3>;
+
+		vdd-supply = <&vreg_rtmr0_1p15>;
+		vdd33-supply = <&vreg_rtmr0_3p3>;
+		vdd33-cap-supply = <&vreg_rtmr0_3p3>;
+		vddar-supply = <&vreg_rtmr0_1p15>;
+		vddat-supply = <&vreg_rtmr0_1p15>;
+		vddio-supply = <&vreg_rtmr0_1p8>;
+
+		pinctrl-0 = <&rtmr0_default>;
+		pinctrl-names = "default";
+
+		retimer-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				retimer_ss0_ss_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss0_ss_in>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				retimer_ss0_ss_in: endpoint {
+					remote-endpoint = <&usb_1_ss0_qmpphy_out>;
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+
+				retimer_ss0_con_sbu_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss0_con_sbu_in>;
+				};
+			};
+		};
+	};
+};
+
+&i2c4 {
+	clock-frequency = <400000>;
+
+	status = "okay";
+
+	/* Something @12, @14, @16, @18, @1a */
+};
+
+&i2c7 {
+	clock-frequency = <400000>;
+
+	status = "okay";
+
+	/* Left-side top port */
+	typec-mux@8 {
+		compatible = "parade,ps8830";
+		reg = <0x8>;
+
+		reset-gpios = <&tlmm 176 GPIO_ACTIVE_LOW>;
+
+		clocks = <&rpmhcc RPMH_RF_CLK4>;
+
+		vdd-supply = <&vreg_rtmr1_1p15>;
+		vdd33-supply = <&vreg_rtmr1_3p3>;
+		vdd33-cap-supply = <&vreg_rtmr1_3p3>;
+		vddar-supply = <&vreg_rtmr1_1p15>;
+		vddat-supply = <&vreg_rtmr1_1p15>;
+		vddio-supply = <&vreg_rtmr1_1p8>;
+
+		retimer-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				retimer_ss1_ss_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss1_ss_in>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				retimer_ss1_ss_in: endpoint {
+					remote-endpoint = <&usb_1_ss1_qmpphy_out>;
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+
+				retimer_ss1_con_sbu_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss1_con_sbu_in>;
+				};
+			};
+		};
+	};
+};
+
+&lpass_tlmm {
+	spkr_01_sd_n_active: spkr-01-sd-n-active-state {
+		pins = "gpio12";
+		function = "gpio";
+		drive-strength = <16>;
+		bias-disable;
+	};
+};
+
+&lpass_vamacro {
+	pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
+	pinctrl-names = "default";
+
+	vdd-micb-supply = <&vreg_l1b_1p8>;
+	qcom,dmic-sample-rate = <4800000>;
+};
+
+&mdss {
+	status = "okay";
+};
+
+&mdss_dp0 {
+	status = "okay";
+};
+
+&mdss_dp0_out {
+	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp1 {
+	status = "okay";
+};
+
+&mdss_dp1_out {
+	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp3 {
+	compatible = "qcom,x1e80100-dp";
+	/delete-property/ #sound-dai-cells;
+
+	status = "okay";
+
+	aux-bus {
+		panel: panel {
+			compatible = "edp-panel";
+			enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
+			power-supply = <&vreg_edp_3p3>;
+
+			pinctrl-0 = <&edp_bl_en>;
+			pinctrl-names = "default";
+
+			port {
+				edp_panel_in: endpoint {
+					remote-endpoint = <&mdss_dp3_out>;
+				};
+			};
+		};
+	};
+
+	ports {
+		port@1 {
+			reg = <1>;
+
+			mdss_dp3_out: endpoint {
+				data-lanes = <0 1 2 3>;
+				link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+
+				remote-endpoint = <&edp_panel_in>;
+			};
+		};
+	};
+};
+
+&mdss_dp3_phy {
+	vdda-phy-supply = <&vreg_l3j_0p8>;
+	vdda-pll-supply = <&vreg_l2j_1p2>;
+
+	status = "okay";
+};
+
+&pcie4 {
+	status = "okay";
+};
+
+&pcie4_phy {
+	vdda-phy-supply = <&vreg_l3i_0p8>;
+	vdda-pll-supply = <&vreg_l3e_1p2>;
+
+	status = "okay";
+};
+
+&pcie4_port0 {
+	wifi@0 {
+		compatible = "pci17cb,1107";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+		vddaon-supply = <&vreg_pmu_aon_0p59>;
+		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+		vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+		vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+
+		disable-rfkill;
+	};
+};
+
+&pcie6a {
+	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+
+	vddpe-3v3-supply = <&vreg_nvme>;
+
+	pinctrl-0 = <&pcie6a_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&pcie6a_phy {
+	vdda-phy-supply = <&vreg_l1d_0p8>;
+	vdda-pll-supply = <&vreg_l2j_1p2>;
+
+	status = "okay";
+};
+
+&pm8550_gpios {
+	rtmr0_default: rtmr0-reset-n-active-state {
+		pins = "gpio10";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+	};
+
+	rtmr0_3p3_reg_en: rtmr0-3p3-reg-en-state {
+		pins = "gpio11";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+	};
+};
+
+&pm8550ve_9_gpios {
+	rtmr0_1p8_reg_en: rtmr0-1p8-reg-en-state {
+		pins = "gpio8";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+	};
+};
+
+&pmc8380_3_gpios {
+	edp_bl_en: edp-bl-en-state {
+		pins = "gpio4";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+		input-disable;
+		output-enable;
+	};
+};
+
+&pmc8380_5_gpios {
+	rtmr0_1p15_reg_en: rtmr0-1p15-reg-en-state {
+		pins = "gpio8";
+		function = "normal";
+		power-source = <1>; /* 1.8V */
+	};
+};
+
+&qupv3_0 {
+	status = "okay";
+};
+
+&qupv3_1 {
+	status = "okay";
+};
+
+&qupv3_2 {
+	status = "okay";
+};
+
+&remoteproc_adsp {
+	firmware-name = "qcom/x1e80100/microsoft/Denali/qcadsp8380.mbn",
+			"qcom/x1e80100/microsoft/Denali/adsp_dtb.mbn";
+
+	status = "okay";
+};
+
+&remoteproc_cdsp {
+	firmware-name = "qcom/x1e80100/microsoft/Denali/qccdsp8380.mbn",
+			"qcom/x1e80100/microsoft/Denali/cdsp_dtb.mbn";
+
+	status = "okay";
+};
+
+&smb2360_0 {
+	status = "okay";
+};
+
+&smb2360_0_eusb2_repeater {
+	vdd18-supply = <&vreg_l3d_1p8>;
+	vdd3-supply = <&vreg_l2b_3p0>;
+};
+
+&smb2360_1 {
+	status = "okay";
+};
+
+&smb2360_1_eusb2_repeater {
+	vdd18-supply = <&vreg_l3d_1p8>;
+	vdd3-supply = <&vreg_l14b_3p0>;
+};
+
+&smb2360_2 {
+	status = "okay";
+};
+
+&smb2360_2_eusb2_repeater {
+	vdd18-supply = <&vreg_l3d_1p8>;
+	vdd3-supply = <&vreg_l8b_3p0>;
+};
+
+&swr0 {
+	status = "okay";
+
+	pinctrl-0 = <&wsa_swr_active>, <&spkr_01_sd_n_active>;
+	pinctrl-names = "default";
+
+	/* WSA8845, Left Speaker */
+	left_spkr: speaker@0,0 {
+		compatible = "sdw20217020400";
+		reg = <0 0>;
+		reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+		#sound-dai-cells = <0>;
+		sound-name-prefix = "SpkrLeft";
+		vdd-1p8-supply = <&vreg_l15b_1p8>;
+		vdd-io-supply = <&vreg_l12b_1p2>;
+		qcom,port-mapping = <1 2 3 7 10 13>;
+	};
+
+	/* WSA8845, Right Speaker */
+	right_spkr: speaker@0,1 {
+		compatible = "sdw20217020400";
+		reg = <0 1>;
+		reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+		#sound-dai-cells = <0>;
+		sound-name-prefix = "SpkrRight";
+		vdd-1p8-supply = <&vreg_l15b_1p8>;
+		vdd-io-supply = <&vreg_l12b_1p2>;
+		qcom,port-mapping = <4 5 6 7 11 13>;
+	};
+};
+
+&tlmm {
+	gpio-reserved-ranges = <44 4>, /* SPI (TPM) */
+			       <238 1>; /* UFS Reset */
+
+	hall_int_n_default: hall-int-n-state {
+		pins = "gpio2";
+		function = "gpio";
+		bias-disable;
+	};
+
+	nvme_reg_en: nvme-reg-en-state {
+		pins = "gpio18";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	edp_reg_en: edp-reg-en-state {
+		pins = "gpio70";
+		function = "gpio";
+		drive-strength = <16>;
+		bias-disable;
+	};
+
+	ssam_state: ssam-state-state {
+		pins = "gpio91";
+		function = "gpio";
+		bias-disable;
+	};
+
+	wcn_wlan_bt_en: wcn-wlan-bt-en-state {
+		pins = "gpio116", "gpio117";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	pcie4_default: pcie4-default-state {
+		clkreq-n-pins {
+			pins = "gpio147";
+			function = "pcie4_clk";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+
+		perst-n-pins {
+			pins = "gpio146";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-disable;
+		};
+
+		wake-n-pins {
+			pins = "gpio148";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+	};
+
+	pcie6a_default: pcie6a-default-state {
+		perst-n-pins {
+			pins = "gpio152";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-disable;
+		};
+
+		clkreq-n-pins {
+			pins = "gpio153";
+			function = "pcie6a_clk";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+
+		wake-n-pins {
+			pins = "gpio154";
+			function = "gpio";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+	};
+
+	rtmr1_1p8_reg_en: rtmr1-1p8-reg-en-state {
+		pins = "gpio175";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	rtmr1_3p3_reg_en: rtmr1-3p3-reg-en-state {
+		pins = "gpio186";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	rtmr1_1p15_reg_en: rtmr1-1p15-reg-en-state {
+		pins = "gpio188";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	wcn_sw_en: wcn-sw-en-state {
+		pins = "gpio214";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	cam_indicator_en: cam-indicator-en-state {
+		pins = "gpio225";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+	};
+};
+
+&uart2 {
+	status = "okay";
+
+	embedded-controller {
+		compatible = "microsoft,surface-sam";
+
+		interrupts-extended = <&tlmm 91 IRQ_TYPE_EDGE_RISING>;
+
+		current-speed = <4000000>;
+
+		pinctrl-0 = <&ssam_state>;
+		pinctrl-names = "default";
+	};
+};
+
+&uart14 {
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn7850-bt";
+		max-speed = <3200000>;
+
+		vddaon-supply = <&vreg_pmu_aon_0p59>;
+		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+	};
+};
+
+&usb_1_ss0_hsphy {
+	vdd-supply = <&vreg_l3j_0p8>;
+	vdda12-supply = <&vreg_l2j_1p2>;
+
+	phys = <&smb2360_0_eusb2_repeater>;
+
+	status = "okay";
+};
+
+&usb_1_ss0_qmpphy {
+	vdda-phy-supply = <&vreg_l2j_1p2>;
+	vdda-pll-supply = <&vreg_l1j_0p8>;
+
+	status = "okay";
+};
+
+&usb_1_ss0 {
+	status = "okay";
+};
+
+&usb_1_ss0_dwc3 {
+	dr_mode = "host";
+};
+
+&usb_1_ss0_dwc3_hs {
+	remote-endpoint = <&pmic_glink_ss0_hs_in>;
+};
+
+&usb_1_ss0_qmpphy_out {
+	remote-endpoint = <&retimer_ss0_ss_in>;
+};
+
+&usb_1_ss1_hsphy {
+	vdd-supply = <&vreg_l3j_0p8>;
+	vdda12-supply = <&vreg_l2j_1p2>;
+
+	phys = <&smb2360_1_eusb2_repeater>;
+
+	status = "okay";
+};
+
+&usb_1_ss1_qmpphy {
+	vdda-phy-supply = <&vreg_l2j_1p2>;
+	vdda-pll-supply = <&vreg_l2d_0p9>;
+
+	status = "okay";
+};
+
+&usb_1_ss1 {
+	status = "okay";
+};
+
+&usb_1_ss1_dwc3 {
+	dr_mode = "host";
+};
+
+&usb_1_ss1_dwc3_hs {
+	remote-endpoint = <&pmic_glink_ss1_hs_in>;
+};
+
+&usb_1_ss1_qmpphy_out {
+	remote-endpoint = <&retimer_ss1_ss_in>;
+};
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-denali-oled.dts b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-denali-oled.dts
new file mode 100644
index 0000000000000000000000000000000000000000..07ce43ccf39430b89f881f86e629fe69ca9baefd
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-denali-oled.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025 Dale Whinham <daleyo@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "hamoa.dtsi"
+#include "x1-microsoft-denali.dtsi"
+
+/ {
+	model = "Microsoft Surface Pro 11th Edition (OLED)";
+	compatible = "microsoft,denali-oled", "microsoft,denali",
+		     "qcom,x1e80100";
+};
+
+&panel {
+	compatible = "samsung,atna30dw01", "samsung,atna33xc20";
+};
diff --git a/arch/arm64/boot/dts/qcom/x1p64100-microsoft-denali.dts b/arch/arm64/boot/dts/qcom/x1p64100-microsoft-denali.dts
new file mode 100644
index 0000000000000000000000000000000000000000..d96202e2afc6179a08bd4267b7a14ac4a51e4a81
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1p64100-microsoft-denali.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025 Dale Whinham <daleyo@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "hamoa.dtsi"
+#include "x1-microsoft-denali.dtsi"
+
+/ {
+	model = "Microsoft Surface Pro 11th Edition (LCD)";
+	compatible = "microsoft,denali-lcd", "microsoft,denali",
+		     "qcom,x1p64100", "qcom,x1e80100";
+};

-- 
2.47.3

[PATCH v5 7/7] wifi: ath12k: Add support for disabling rfkill via devicetree

[Jérôme de Bretagne via B4 Relay]

From: Dale Whinham <daleyo@gmail.com>

Some devices (e.g. Microsoft Surface Pro 11) indicate that the rfkill
feature should be disabled by means of an ACPI bitflag.

If ACPI is not being used (i.e. booting using a devicetree) then this
property will not be read and therefore rfkill may be enabled and
the ath12k will be hard-blocked with no way to disable it.

Add a devicetree property that allows to disable the rfkill feature.

Signed-off-by: Dale Whinham <daleyo@gmail.com>
Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
---
 drivers/net/wireless/ath/ath12k/core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index cc352eef1939937ce902bee2fbd9737ca3ab5993..e10073bb975cfd2e9ee418edcc49d0d51cf93de1 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -77,6 +77,9 @@ static int ath12k_core_rfkill_config(struct ath12k_base *ab)
 	if (ath12k_acpi_get_disable_rfkill(ab))
 		return 0;
 
+	if (of_property_read_bool(ab->dev->of_node, "disable-rfkill"))
+		return 0;
+
 	for (i = 0; i < ab->num_radios; i++) {
 		ar = ab->pdevs[i].ar;
 

-- 
2.47.3

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Bryan O'Donoghue]

On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> 
> For some devices, Wi-Fi is entirely hard blocked by default making
> the Wi-Fi radio unusable, except if rfkill is disabled as expected
> on those models.
> 
> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> disabling specific features based on ACPI bitflag") added a way to
> support features set via ACPI, including the DISABLE_RFKILL bit.
> 
> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> equivalent for devices described by a Devicetree instead of ACPI.
> 
> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> ---
>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> @@ -29,6 +29,12 @@ properties:
>         different 5 GHz subbands. Using them incorrectly could not work or
>         decrease performance noticeably
> 
> +  disable-rfkill:
> +    type: boolean
> +    description:
> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> +      blocked by default otherwise
> +
>   additionalProperties: true
> 
>   examples:
> 
> --
> 2.47.3
> 
> 
> 

Is this really a hardware description though ?

Its really more of a logical/functional description. It tells the 
runtime what todo, not what the hardware is.

You could also have a list of quirks in ath12k for this or have a 
user-space utility look for the appropriate platform device string name 
and disable rfkill.

I think this logic belongs in drivers/net/wireless/ath/ath12k/ 
triggering on a compat string.

Should be achievable.

---
bod

Re: [PATCH v5 7/7] wifi: ath12k: Add support for disabling rfkill via devicetree

[Bryan O'Donoghue]

On 20/12/2025 00:22, Jérôme de Bretagne via B4 Relay wrote:
> From: Dale Whinham <daleyo@gmail.com>
> 
> Some devices (e.g. Microsoft Surface Pro 11) indicate that the rfkill
> feature should be disabled by means of an ACPI bitflag.
> 
> If ACPI is not being used (i.e. booting using a devicetree) then this
> property will not be read and therefore rfkill may be enabled and
> the ath12k will be hard-blocked with no way to disable it.
> 
> Add a devicetree property that allows to disable the rfkill feature.
> 
> Signed-off-by: Dale Whinham <daleyo@gmail.com>
> Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> ---
>   drivers/net/wireless/ath/ath12k/core.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
> index cc352eef1939937ce902bee2fbd9737ca3ab5993..e10073bb975cfd2e9ee418edcc49d0d51cf93de1 100644
> --- a/drivers/net/wireless/ath/ath12k/core.c
> +++ b/drivers/net/wireless/ath/ath12k/core.c
> @@ -77,6 +77,9 @@ static int ath12k_core_rfkill_config(struct ath12k_base *ab)
>   	if (ath12k_acpi_get_disable_rfkill(ab))
>   		return 0;
> 
> +	if (of_property_read_bool(ab->dev->of_node, "disable-rfkill"))
> +		return 0;
> +
>   	for (i = 0; i < ab->num_radios; i++) {
>   		ar = ab->pdevs[i].ar;
> 
> 
> --
> 2.47.3
> 
> 
> 

Just maintain a list of devices with the quirk. disable-rfkill won't fly 
because it doesn't describe hardware and DT != ACPI that way.

---
bod

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Krzysztof Kozlowski]

On Sat, Dec 20, 2025 at 06:04:00AM +0000, Bryan O'Donoghue wrote:
> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> > From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > 
> > For some devices, Wi-Fi is entirely hard blocked by default making
> > the Wi-Fi radio unusable, except if rfkill is disabled as expected
> > on those models.
> > 
> > Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> > disabling specific features based on ACPI bitflag") added a way to
> > support features set via ACPI, including the DISABLE_RFKILL bit.
> > 
> > Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> > equivalent for devices described by a Devicetree instead of ACPI.
> > 
> > Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > ---
> >   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
> >   1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> > --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > @@ -29,6 +29,12 @@ properties:
> >         different 5 GHz subbands. Using them incorrectly could not work or
> >         decrease performance noticeably
> > 
> > +  disable-rfkill:
> > +    type: boolean
> > +    description:
> > +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> > +      blocked by default otherwise
> > +
> >   additionalProperties: true
> > 
> >   examples:
> > 
> > --
> > 2.47.3
> > 
> > 
> > 
> 
> Is this really a hardware description though ?
> 
> Its really more of a logical/functional description. It tells the runtime
> what todo, not what the hardware is.
> 
> You could also have a list of quirks in ath12k for this or have a user-space
> utility look for the appropriate platform device string name and disable
> rfkill.
> 
> I think this logic belongs in drivers/net/wireless/ath/ath12k/ triggering on
> a compat string.

This is good point. Either this could be deducible from the compatible
or this should actually describe the hardware and whatever is there
wired/configured, not what OS should do.

Best regards,
Krzysztof

Re: [PATCH v5 1/7] dt-bindings: arm: qcom: Document Microsoft Surface Pro 11

[Krzysztof Kozlowski]

On Sat, Dec 20, 2025 at 01:21:58AM +0100, Jérôme de Bretagne wrote:
> Add the compatibles for the Qualcomm-based Microsoft Surface Pro 11,
> using its Denali codename.
> 
> The LCD models are using the Qualcomm Snapdragon X1 Plus (X1P64100),
> the OLED ones are using the Qualcomm Snapdragon X1 Elite (X1E80100).
> 
> Due to the difference in how the built-in panel is being handled
> between the OLED variant and LCD one, it is required to have two
> separate DTBs, so document the compatible string for both variants.
> 
> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 11 +++++++++++
>  1 file changed, 11 insertions(+)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Jérôme de Bretagne]

Le sam. 20 déc. 2025 à 10:12, Krzysztof Kozlowski <krzk@kernel.org> a écrit :
>
> On Sat, Dec 20, 2025 at 06:04:00AM +0000, Bryan O'Donoghue wrote:
> > On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> > > From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > >
> > > For some devices, Wi-Fi is entirely hard blocked by default making
> > > the Wi-Fi radio unusable, except if rfkill is disabled as expected
> > > on those models.
> > >
> > > Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> > > disabling specific features based on ACPI bitflag") added a way to
> > > support features set via ACPI, including the DISABLE_RFKILL bit.
> > >
> > > Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> > > equivalent for devices described by a Devicetree instead of ACPI.
> > >
> > > Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > > ---
> > >   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
> > >   1 file changed, 6 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > > index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> > > --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > > +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > > @@ -29,6 +29,12 @@ properties:
> > >         different 5 GHz subbands. Using them incorrectly could not work or
> > >         decrease performance noticeably
> > >
> > > +  disable-rfkill:
> > > +    type: boolean
> > > +    description:
> > > +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> > > +      blocked by default otherwise
> > > +
> > >   additionalProperties: true
> > >
> > >   examples:
> > >
> > > --
> > > 2.47.3
> > >
> > >
> > >
> >
> > Is this really a hardware description though ?
> >
> > Its really more of a logical/functional description. It tells the runtime
> > what todo, not what the hardware is.
> >
> > You could also have a list of quirks in ath12k for this or have a user-space
> > utility look for the appropriate platform device string name and disable
> > rfkill.
> >
> > I think this logic belongs in drivers/net/wireless/ath/ath12k/ triggering on
> > a compat string.
>
> This is good point. Either this could be deducible from the compatible

Thank you Bryan and Krzysztof for your feedback, I will drop the
disable-rfkill patches from this patchset in v6 then. I will work on
a separate patch using a list of quirks in ath12k as suggested.

> or this should actually describe the hardware and whatever is there
> wired/configured, not what OS should do.
>
> Best regards,
> Krzysztof

Best regards,
Jérôme

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Dmitry Baryshkov]

On Sat, Dec 20, 2025 at 10:12:14AM +0100, Krzysztof Kozlowski wrote:
> On Sat, Dec 20, 2025 at 06:04:00AM +0000, Bryan O'Donoghue wrote:
> > On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> > > From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > > 
> > > For some devices, Wi-Fi is entirely hard blocked by default making
> > > the Wi-Fi radio unusable, except if rfkill is disabled as expected
> > > on those models.
> > > 
> > > Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> > > disabling specific features based on ACPI bitflag") added a way to
> > > support features set via ACPI, including the DISABLE_RFKILL bit.
> > > 
> > > Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> > > equivalent for devices described by a Devicetree instead of ACPI.
> > > 
> > > Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > > ---
> > >   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
> > >   1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > > index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> > > --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > > +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > > @@ -29,6 +29,12 @@ properties:
> > >         different 5 GHz subbands. Using them incorrectly could not work or
> > >         decrease performance noticeably
> > > 
> > > +  disable-rfkill:
> > > +    type: boolean
> > > +    description:
> > > +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> > > +      blocked by default otherwise
> > > +
> > >   additionalProperties: true
> > > 
> > >   examples:
> > > 
> > > --
> > > 2.47.3
> > > 
> > > 
> > > 
> > 
> > Is this really a hardware description though ?
> > 
> > Its really more of a logical/functional description. It tells the runtime
> > what todo, not what the hardware is.
> > 
> > You could also have a list of quirks in ath12k for this or have a user-space
> > utility look for the appropriate platform device string name and disable
> > rfkill.
> > 
> > I think this logic belongs in drivers/net/wireless/ath/ath12k/ triggering on
> > a compat string.
> 
> This is good point. Either this could be deducible from the compatible
> or this should actually describe the hardware and whatever is there
> wired/configured, not what OS should do.

One of the examples _might_ be broken-rfkill, e.g. if the chip expects
to have the actual rfkill control from the EC, but the board doesn't
provide one.

-- 
With best wishes
Dmitry

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Konrad Dybcio]

On 12/20/25 5:05 PM, Dmitry Baryshkov wrote:
> On Sat, Dec 20, 2025 at 10:12:14AM +0100, Krzysztof Kozlowski wrote:
>> On Sat, Dec 20, 2025 at 06:04:00AM +0000, Bryan O'Donoghue wrote:
>>> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
>>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>>>
>>>> For some devices, Wi-Fi is entirely hard blocked by default making
>>>> the Wi-Fi radio unusable, except if rfkill is disabled as expected
>>>> on those models.
>>>>
>>>> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
>>>> disabling specific features based on ACPI bitflag") added a way to
>>>> support features set via ACPI, including the DISABLE_RFKILL bit.
>>>>
>>>> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
>>>> equivalent for devices described by a Devicetree instead of ACPI.
>>>>
>>>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>>> ---
>>>>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
>>>>   1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
>>>> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>> @@ -29,6 +29,12 @@ properties:
>>>>         different 5 GHz subbands. Using them incorrectly could not work or
>>>>         decrease performance noticeably
>>>>
>>>> +  disable-rfkill:
>>>> +    type: boolean
>>>> +    description:
>>>> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
>>>> +      blocked by default otherwise
>>>> +
>>>>   additionalProperties: true
>>>>
>>>>   examples:
>>>>
>>>> --
>>>> 2.47.3
>>>>
>>>>
>>>>
>>>
>>> Is this really a hardware description though ?
>>>
>>> Its really more of a logical/functional description. It tells the runtime
>>> what todo, not what the hardware is.
>>>
>>> You could also have a list of quirks in ath12k for this or have a user-space
>>> utility look for the appropriate platform device string name and disable
>>> rfkill.
>>>
>>> I think this logic belongs in drivers/net/wireless/ath/ath12k/ triggering on
>>> a compat string.
>>
>> This is good point. Either this could be deducible from the compatible
>> or this should actually describe the hardware and whatever is there
>> wired/configured, not what OS should do.
> 
> One of the examples _might_ be broken-rfkill, e.g. if the chip expects
> to have the actual rfkill control from the EC, but the board doesn't
> provide one.

Hm, I haven't thought about the EC being involved previously. Maybe
+Maximilian would have an idea whether this could be a factor that we
simply haven't implemented yet in the SAM driver..

Konrad

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Hans de Goede]

+Cc Mani

Hi,

On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
>> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>
>> For some devices, Wi-Fi is entirely hard blocked by default making
>> the Wi-Fi radio unusable, except if rfkill is disabled as expected
>> on those models.
>>
>> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
>> disabling specific features based on ACPI bitflag") added a way to
>> support features set via ACPI, including the DISABLE_RFKILL bit.
>>
>> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
>> equivalent for devices described by a Devicetree instead of ACPI.
>>
>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>> ---
>>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>> @@ -29,6 +29,12 @@ properties:
>>         different 5 GHz subbands. Using them incorrectly could not work or
>>         decrease performance noticeably
>>
>> +  disable-rfkill:
>> +    type: boolean
>> +    description:
>> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
>> +      blocked by default otherwise
>> +
>>   additionalProperties: true
>>
>>   examples:
>>
>> -- 
>> 2.47.3
>>
>>
>>
> 
> Is this really a hardware description though ?

I would say yes it is. The wifi chip has an rfkill input pin and
things will be broken when that pin is hardwired to a fixed value
rather then being actually connected to a GPIO from say
the embedded controller.

So I think that we would need here is not a disable-rfkill property
but some way to indicate in the DT-node that the rfkill input pin
is not connected and thus should be ignored.

This (the rfkill input pin being not-connected) IMHO very much
is hw-description.

Also see the
"[PATCH 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree"
series and then specifically:

https://lore.kernel.org/platform-driver-x86/20251112-pci-m2-e-v1-7-97413d6bf824@oss.qualcomm.com/

Which adds:

+  w_disable1-gpios:
+    description: GPIO controlled connection to W_DISABLE1# signal. This signal
+      is used by the system to disable WiFi radio in the M.2 card. Refer, PCI
+      Express M.2 Specification r4.0, sec 3.1.12.3 for more details.
+    maxItems: 1

What if there is no such GPIO, because the W_DISABLE1# signal is hardwired
in a specific implementation of the M.2 slot ?

In that case we will also need some way to propagate that info to the wifi
driver, having some sort of generic devicetree property for wifi-cards
which can be injected as a software-node property in the PCI-device being
instantiated for the WIFI card to let the driver no not to honor to
W_DISABLE1# signal will be useful here too and this is as hardware-description
as hardware-description can get.

So how about: "w_disable1-not-connected" + "w_disable2-not-connected" boolean
properties in a generic WIFI devicetree binding and also use that here?

> I think this logic belongs in drivers/net/wireless/ath/ath12k/ triggering on a compat string.

See above, I do not believe that abusing compat-strings for this is the way
to go.

Regards,

Hans

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Krzysztof Kozlowski]

On 22/12/2025 11:23, Hans de Goede wrote:
> +Cc Mani
> 
> Hi,
> 
> On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
>> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>>
>>> For some devices, Wi-Fi is entirely hard blocked by default making
>>> the Wi-Fi radio unusable, except if rfkill is disabled as expected
>>> on those models.
>>>
>>> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
>>> disabling specific features based on ACPI bitflag") added a way to
>>> support features set via ACPI, including the DISABLE_RFKILL bit.
>>>
>>> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
>>> equivalent for devices described by a Devicetree instead of ACPI.
>>>
>>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>> ---
>>>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
>>> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>> @@ -29,6 +29,12 @@ properties:
>>>         different 5 GHz subbands. Using them incorrectly could not work or
>>>         decrease performance noticeably
>>>
>>> +  disable-rfkill:
>>> +    type: boolean
>>> +    description:
>>> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
>>> +      blocked by default otherwise
>>> +
>>>   additionalProperties: true
>>>
>>>   examples:
>>>
>>> -- 
>>> 2.47.3
>>>
>>>
>>>
>>
>> Is this really a hardware description though ?
> 
> I would say yes it is. The wifi chip has an rfkill input pin and
> things will be broken when that pin is hardwired to a fixed value
> rather then being actually connected to a GPIO from say
> the embedded controller.

You still do not describe the hardware. Read my comment.

> 
> So I think that we would need here is not a disable-rfkill property
> but some way to indicate in the DT-node that the rfkill input pin
> is not connected and thus should be ignored.
> 
> This (the rfkill input pin being not-connected) IMHO very much
> is hw-description.
> 
> Also see the
> "[PATCH 0/9] Add support for handling PCIe M.2 Key E connectors in devicetree"
> series and then specifically:
> 
> https://lore.kernel.org/platform-driver-x86/20251112-pci-m2-e-v1-7-97413d6bf824@oss.qualcomm.com/
> 
> Which adds:
> 
> +  w_disable1-gpios:
> +    description: GPIO controlled connection to W_DISABLE1# signal. This signal
> +      is used by the system to disable WiFi radio in the M.2 card. Refer, PCI
> +      Express M.2 Specification r4.0, sec 3.1.12.3 for more details.
> +    maxItems: 1
> 
> What if there is no such GPIO, because the W_DISABLE1# signal is hardwired
> in a specific implementation of the M.2 slot ?
> 
> In that case we will also need some way to propagate that info to the wifi
> driver, having some sort of generic devicetree property for wifi-cards
> which can be injected as a software-node property in the PCI-device being
> instantiated for the WIFI card to let the driver no not to honor to
> W_DISABLE1# signal will be useful here too and this is as hardware-description
> as hardware-description can get.

Please do not use antipatterns as examples. Above patchset is obviously
wrong there, it's a terrible example but also completely different thing
(spec). This is not a spec here.


Best regards,
Krzysztof

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Manivannan Sadhasivam]

On Mon, Dec 22, 2025 at 11:23:18AM +0100, Hans de Goede wrote:
> +Cc Mani
> 
> Hi,
> 
> On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
> > On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> >> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> >>
> >> For some devices, Wi-Fi is entirely hard blocked by default making
> >> the Wi-Fi radio unusable, except if rfkill is disabled as expected
> >> on those models.
> >>
> >> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> >> disabling specific features based on ACPI bitflag") added a way to
> >> support features set via ACPI, including the DISABLE_RFKILL bit.
> >>
> >> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> >> equivalent for devices described by a Devicetree instead of ACPI.
> >>
> >> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> >> ---
> >>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
> >>   1 file changed, 6 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> >> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >> @@ -29,6 +29,12 @@ properties:
> >>         different 5 GHz subbands. Using them incorrectly could not work or
> >>         decrease performance noticeably
> >>
> >> +  disable-rfkill:
> >> +    type: boolean
> >> +    description:
> >> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> >> +      blocked by default otherwise
> >> +
> >>   additionalProperties: true
> >>
> >>   examples:
> >>
> >> -- 
> >> 2.47.3
> >>
> >>
> >>
> > 
> > Is this really a hardware description though ?
> 
> I would say yes it is. The wifi chip has an rfkill input pin and
> things will be broken when that pin is hardwired to a fixed value
> rather then being actually connected to a GPIO from say
> the embedded controller.
> 

IIUC, even if the M.2 slot has the W_DISABLE1# signal routed from the host,
the device won't make use of it as there is no physical connection. So you want
the WLAN driver to change the state through SW?

> So I think that we would need here is not a disable-rfkill property
> but some way to indicate in the DT-node that the rfkill input pin
> is not connected and thus should be ignored.
> 
> This (the rfkill input pin being not-connected) IMHO very much
> is hw-description.
> 

Though we can argue this way, I would prefer to handle it in the driver. For
example, with my M.2 series, we will end up describing the M.2 slot:

	connector {
		compatible = "pcie-m2-e-connector";
		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
		...
		ports {
			...
			endpoint@0 {
				reg = <0>;
				remote-endpoint = <&pcie4_port0_ep>;
			};
		};
	};

Then if we use a DT property to convey the RFKILL pin state of the device, we
would need to describe the endpoint device in DT and hardcode the state:

	&pcie4_port0 {
		...
		port {
			pcie4_port0_ep: endpoint {
				remote-endpoint = <&m2_e_pcie_ep>;
				disable-rfkill;
			};
		};
	};

So this will essentially make the M.2 device non-swappable unless you change the
DT since you've how hardcoded the device property in the binding. This is
something I try to avoid to make the M.2 slot really swappable.

For this reason, I would prefer to handle the RFKILL state in the WLAN driver
using the device specific compatible. This will be problematic only if multiple
cards of the same Device ID have different RFKILL state and the devices are not
distinguishable even with sub IDs.

FWIW, ACPI support added with commit c6a7c0b09d5f, suffers from the same
limitation.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Hans de Goede]

Hi Mani,

On 22-Dec-25 12:45, Manivannan Sadhasivam wrote:
> On Mon, Dec 22, 2025 at 11:23:18AM +0100, Hans de Goede wrote:
>> +Cc Mani
>>
>> Hi,
>>
>> On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
>>> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
>>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>>>
>>>> For some devices, Wi-Fi is entirely hard blocked by default making
>>>> the Wi-Fi radio unusable, except if rfkill is disabled as expected
>>>> on those models.
>>>>
>>>> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
>>>> disabling specific features based on ACPI bitflag") added a way to
>>>> support features set via ACPI, including the DISABLE_RFKILL bit.
>>>>
>>>> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
>>>> equivalent for devices described by a Devicetree instead of ACPI.
>>>>
>>>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>>> ---
>>>>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
>>>>   1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
>>>> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>> @@ -29,6 +29,12 @@ properties:
>>>>         different 5 GHz subbands. Using them incorrectly could not work or
>>>>         decrease performance noticeably
>>>>
>>>> +  disable-rfkill:
>>>> +    type: boolean
>>>> +    description:
>>>> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
>>>> +      blocked by default otherwise
>>>> +
>>>>   additionalProperties: true
>>>>
>>>>   examples:
>>>>
>>>> -- 
>>>> 2.47.3
>>>>
>>>>
>>>>
>>>
>>> Is this really a hardware description though ?
>>
>> I would say yes it is. The wifi chip has an rfkill input pin and
>> things will be broken when that pin is hardwired to a fixed value
>> rather then being actually connected to a GPIO from say
>> the embedded controller.
>>
> 
> IIUC, even if the M.2 slot has the W_DISABLE1# signal routed from the host,
> the device won't make use of it as there is no physical connection. So you want
> the WLAN driver to change the state through SW?
> 
>> So I think that we would need here is not a disable-rfkill property
>> but some way to indicate in the DT-node that the rfkill input pin
>> is not connected and thus should be ignored.
>>
>> This (the rfkill input pin being not-connected) IMHO very much
>> is hw-description.
>>
> 
> Though we can argue this way, I would prefer to handle it in the driver. For
> example, with my M.2 series, we will end up describing the M.2 slot:
> 
> 	connector {
> 		compatible = "pcie-m2-e-connector";
> 		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
> 		...
> 		ports {
> 			...
> 			endpoint@0 {
> 				reg = <0>;
> 				remote-endpoint = <&pcie4_port0_ep>;
> 			};
> 		};
> 	};
> 
> Then if we use a DT property to convey the RFKILL pin state of the device, we
> would need to describe the endpoint device in DT and hardcode the state:
> 
> 	&pcie4_port0 {
> 		...
> 		port {
> 			pcie4_port0_ep: endpoint {
> 				remote-endpoint = <&m2_e_pcie_ep>;
> 				disable-rfkill;
> 			};
> 		};
> 	};
> 
> So this will essentially make the M.2 device non-swappable unless you change the
> DT since you've how hardcoded the device property in the binding. This is
> something I try to avoid to make the M.2 slot really swappable.
> 
> For this reason, I would prefer to handle the RFKILL state in the WLAN driver
> using the device specific compatible. This will be problematic only if multiple
> cards of the same Device ID have different RFKILL state and the devices are not
> distinguishable even with sub IDs.

I think we're miscommunicating here. I'm not talking about the card having
a broken rfkill implementation, I'm talking about the M.2 slot on the mainboard
having e.g. W_DISABLE1# hardwired in such a way that cards would interpret it as
having to always disable their wifi radio which is very similar to what is
happening on the surface device. Except that on the Surface there is no M.2 slot,
the wifi is just soldered onto the mainboard I believe.

Based on experience I'm pretty sure we will encounter M.2 slots which such
a hardwired W_DISABLE1# signal sooner rather then later.

So my proposal is to come up with a generic way to solve the broken M.2 slot
case and then apply that to the Surface case.

Regards,

Hans

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Manivannan Sadhasivam]

On Mon, Dec 22, 2025 at 01:41:48PM +0100, Hans de Goede wrote:
> Hi Mani,
> 
> On 22-Dec-25 12:45, Manivannan Sadhasivam wrote:
> > On Mon, Dec 22, 2025 at 11:23:18AM +0100, Hans de Goede wrote:
> >> +Cc Mani
> >>
> >> Hi,
> >>
> >> On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
> >>> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> >>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> >>>>
> >>>> For some devices, Wi-Fi is entirely hard blocked by default making
> >>>> the Wi-Fi radio unusable, except if rfkill is disabled as expected
> >>>> on those models.
> >>>>
> >>>> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> >>>> disabling specific features based on ACPI bitflag") added a way to
> >>>> support features set via ACPI, including the DISABLE_RFKILL bit.
> >>>>
> >>>> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> >>>> equivalent for devices described by a Devicetree instead of ACPI.
> >>>>
> >>>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> >>>> ---
> >>>>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
> >>>>   1 file changed, 6 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >>>> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> >>>> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >>>> @@ -29,6 +29,12 @@ properties:
> >>>>         different 5 GHz subbands. Using them incorrectly could not work or
> >>>>         decrease performance noticeably
> >>>>
> >>>> +  disable-rfkill:
> >>>> +    type: boolean
> >>>> +    description:
> >>>> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> >>>> +      blocked by default otherwise
> >>>> +
> >>>>   additionalProperties: true
> >>>>
> >>>>   examples:
> >>>>
> >>>> -- 
> >>>> 2.47.3
> >>>>
> >>>>
> >>>>
> >>>
> >>> Is this really a hardware description though ?
> >>
> >> I would say yes it is. The wifi chip has an rfkill input pin and
> >> things will be broken when that pin is hardwired to a fixed value
> >> rather then being actually connected to a GPIO from say
> >> the embedded controller.
> >>
> > 
> > IIUC, even if the M.2 slot has the W_DISABLE1# signal routed from the host,
> > the device won't make use of it as there is no physical connection. So you want
> > the WLAN driver to change the state through SW?
> > 
> >> So I think that we would need here is not a disable-rfkill property
> >> but some way to indicate in the DT-node that the rfkill input pin
> >> is not connected and thus should be ignored.
> >>
> >> This (the rfkill input pin being not-connected) IMHO very much
> >> is hw-description.
> >>
> > 
> > Though we can argue this way, I would prefer to handle it in the driver. For
> > example, with my M.2 series, we will end up describing the M.2 slot:
> > 
> > 	connector {
> > 		compatible = "pcie-m2-e-connector";
> > 		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
> > 		...
> > 		ports {
> > 			...
> > 			endpoint@0 {
> > 				reg = <0>;
> > 				remote-endpoint = <&pcie4_port0_ep>;
> > 			};
> > 		};
> > 	};
> > 
> > Then if we use a DT property to convey the RFKILL pin state of the device, we
> > would need to describe the endpoint device in DT and hardcode the state:
> > 
> > 	&pcie4_port0 {
> > 		...
> > 		port {
> > 			pcie4_port0_ep: endpoint {
> > 				remote-endpoint = <&m2_e_pcie_ep>;
> > 				disable-rfkill;
> > 			};
> > 		};
> > 	};
> > 
> > So this will essentially make the M.2 device non-swappable unless you change the
> > DT since you've how hardcoded the device property in the binding. This is
> > something I try to avoid to make the M.2 slot really swappable.
> > 
> > For this reason, I would prefer to handle the RFKILL state in the WLAN driver
> > using the device specific compatible. This will be problematic only if multiple
> > cards of the same Device ID have different RFKILL state and the devices are not
> > distinguishable even with sub IDs.
> 
> I think we're miscommunicating here. I'm not talking about the card having
> a broken rfkill implementation, I'm talking about the M.2 slot on the mainboard
> having e.g. W_DISABLE1# hardwired in such a way that cards would interpret it as
> having to always disable their wifi radio which is very similar to what is
> happening on the surface device. Except that on the Surface there is no M.2 slot,
> the wifi is just soldered onto the mainboard I believe.
> 

Ah, sorry for the confusion. I did misinterpret what you said.

> Based on experience I'm pretty sure we will encounter M.2 slots which such
> a hardwired W_DISABLE1# signal sooner rather then later.
> 

But it makes no sense IMO. Vendors will usually connect unimplemented W_DISABL1#
GPIOs to a pull-up resistor so that the radios are operational all the time. I
don't see how they would expect a WLAN or any device with a radio to be
connected to the slot if they hardwire the pin to low.

Are you sure that on the surface the pin is actually hardwired to low and not
connected to a GPIO that drivers the signal low?

It is just hard to believe that board designers can do a blunder like this.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Hans de Goede]

Hi,

On 22-Dec-25 14:41, Manivannan Sadhasivam wrote:
> On Mon, Dec 22, 2025 at 01:41:48PM +0100, Hans de Goede wrote:
>> Hi Mani,
>>
>> On 22-Dec-25 12:45, Manivannan Sadhasivam wrote:
>>> On Mon, Dec 22, 2025 at 11:23:18AM +0100, Hans de Goede wrote:
>>>> +Cc Mani
>>>>
>>>> Hi,
>>>>
>>>> On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
>>>>> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
>>>>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>>>>>
>>>>>> For some devices, Wi-Fi is entirely hard blocked by default making
>>>>>> the Wi-Fi radio unusable, except if rfkill is disabled as expected
>>>>>> on those models.
>>>>>>
>>>>>> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
>>>>>> disabling specific features based on ACPI bitflag") added a way to
>>>>>> support features set via ACPI, including the DISABLE_RFKILL bit.
>>>>>>
>>>>>> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
>>>>>> equivalent for devices described by a Devicetree instead of ACPI.
>>>>>>
>>>>>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
>>>>>> ---
>>>>>>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
>>>>>>   1 file changed, 6 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>>>> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
>>>>>> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
>>>>>> @@ -29,6 +29,12 @@ properties:
>>>>>>         different 5 GHz subbands. Using them incorrectly could not work or
>>>>>>         decrease performance noticeably
>>>>>>
>>>>>> +  disable-rfkill:
>>>>>> +    type: boolean
>>>>>> +    description:
>>>>>> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
>>>>>> +      blocked by default otherwise
>>>>>> +
>>>>>>   additionalProperties: true
>>>>>>
>>>>>>   examples:
>>>>>>
>>>>>> -- 
>>>>>> 2.47.3
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Is this really a hardware description though ?
>>>>
>>>> I would say yes it is. The wifi chip has an rfkill input pin and
>>>> things will be broken when that pin is hardwired to a fixed value
>>>> rather then being actually connected to a GPIO from say
>>>> the embedded controller.
>>>>
>>>
>>> IIUC, even if the M.2 slot has the W_DISABLE1# signal routed from the host,
>>> the device won't make use of it as there is no physical connection. So you want
>>> the WLAN driver to change the state through SW?
>>>
>>>> So I think that we would need here is not a disable-rfkill property
>>>> but some way to indicate in the DT-node that the rfkill input pin
>>>> is not connected and thus should be ignored.
>>>>
>>>> This (the rfkill input pin being not-connected) IMHO very much
>>>> is hw-description.
>>>>
>>>
>>> Though we can argue this way, I would prefer to handle it in the driver. For
>>> example, with my M.2 series, we will end up describing the M.2 slot:
>>>
>>> 	connector {
>>> 		compatible = "pcie-m2-e-connector";
>>> 		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
>>> 		...
>>> 		ports {
>>> 			...
>>> 			endpoint@0 {
>>> 				reg = <0>;
>>> 				remote-endpoint = <&pcie4_port0_ep>;
>>> 			};
>>> 		};
>>> 	};
>>>
>>> Then if we use a DT property to convey the RFKILL pin state of the device, we
>>> would need to describe the endpoint device in DT and hardcode the state:
>>>
>>> 	&pcie4_port0 {
>>> 		...
>>> 		port {
>>> 			pcie4_port0_ep: endpoint {
>>> 				remote-endpoint = <&m2_e_pcie_ep>;
>>> 				disable-rfkill;
>>> 			};
>>> 		};
>>> 	};
>>>
>>> So this will essentially make the M.2 device non-swappable unless you change the
>>> DT since you've how hardcoded the device property in the binding. This is
>>> something I try to avoid to make the M.2 slot really swappable.
>>>
>>> For this reason, I would prefer to handle the RFKILL state in the WLAN driver
>>> using the device specific compatible. This will be problematic only if multiple
>>> cards of the same Device ID have different RFKILL state and the devices are not
>>> distinguishable even with sub IDs.
>>
>> I think we're miscommunicating here. I'm not talking about the card having
>> a broken rfkill implementation, I'm talking about the M.2 slot on the mainboard
>> having e.g. W_DISABLE1# hardwired in such a way that cards would interpret it as
>> having to always disable their wifi radio which is very similar to what is
>> happening on the surface device. Except that on the Surface there is no M.2 slot,
>> the wifi is just soldered onto the mainboard I believe.
>>
> 
> Ah, sorry for the confusion. I did misinterpret what you said.
> 
>> Based on experience I'm pretty sure we will encounter M.2 slots which such
>> a hardwired W_DISABLE1# signal sooner rather then later.
>>
> 
> But it makes no sense IMO. Vendors will usually connect unimplemented W_DISABL1#
> GPIOs to a pull-up resistor so that the radios are operational all the time. I
> don't see how they would expect a WLAN or any device with a radio to be
> connected to the slot if they hardwire the pin to low.

Pins which are considered "unused" are also often hardwired
to ground. If the m.2 slot is tested with a wifi-module where
the W_DISABLE1# signal is not used on the wifi-module I can
easily see this happen. I've seen a lot crazier / buggy stuff
happen.

> Are you sure that on the surface the pin is actually hardwired to low and not
> connected to a GPIO that drivers the signal low?

I don't know what is the exact problem on the Surface. I just
expect to see this more often, we've certainly seen lots of
issues like this on x86 laptops. Things end up looking like
the hard rfkill is activated all the time (and we often don't know
if this is a fw issue, or an actually hardwired problem).

Just an example from the top of my head the Broadcom windows
drivers use different BT fw files for the same wifi/bt combo
chip depending on the vend:prod id pair. One of the things which
is different is that some fw files invert the BT rfkill signal
because it is wired wrong (or there is an EC fw bug) and this
is then worked around in the bt fw.

As we see a growing proliferation of arm64 laptops I fully
expect all the fun from having a gazillion different designs
with a time to market rush behind them result in similar issues
on arm64.

Note I'm not saying we must tackle this today, we can wait
till we see the first case in the real world I guess.

I just thought that based on my experience this is more or
less bound to happen, we could comeup with a solution for
this now and then this solution could also nicely serve
the Surface case which started this thread.

But we can also delay tackling this and come up with some
bespoke solution for the Surface case, like as suggested
maybe a special compatible string ?

> It is just hard to believe that board designers can do a blunder like this.

Heh, you won't believe all the crap happening on cheap
x86 devices.

Regards,

Hans

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Manivannan Sadhasivam]

On Mon, Dec 22, 2025 at 03:22:55PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 22-Dec-25 14:41, Manivannan Sadhasivam wrote:
> > On Mon, Dec 22, 2025 at 01:41:48PM +0100, Hans de Goede wrote:
> >> Hi Mani,
> >>
> >> On 22-Dec-25 12:45, Manivannan Sadhasivam wrote:
> >>> On Mon, Dec 22, 2025 at 11:23:18AM +0100, Hans de Goede wrote:
> >>>> +Cc Mani
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
> >>>>> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> >>>>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> >>>>>>
> >>>>>> For some devices, Wi-Fi is entirely hard blocked by default making
> >>>>>> the Wi-Fi radio unusable, except if rfkill is disabled as expected
> >>>>>> on those models.
> >>>>>>
> >>>>>> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> >>>>>> disabling specific features based on ACPI bitflag") added a way to
> >>>>>> support features set via ACPI, including the DISABLE_RFKILL bit.
> >>>>>>
> >>>>>> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> >>>>>> equivalent for devices described by a Devicetree instead of ACPI.
> >>>>>>
> >>>>>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> >>>>>> ---
> >>>>>>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
> >>>>>>   1 file changed, 6 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >>>>>> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> >>>>>> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> >>>>>> @@ -29,6 +29,12 @@ properties:
> >>>>>>         different 5 GHz subbands. Using them incorrectly could not work or
> >>>>>>         decrease performance noticeably
> >>>>>>
> >>>>>> +  disable-rfkill:
> >>>>>> +    type: boolean
> >>>>>> +    description:
> >>>>>> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> >>>>>> +      blocked by default otherwise
> >>>>>> +
> >>>>>>   additionalProperties: true
> >>>>>>
> >>>>>>   examples:
> >>>>>>
> >>>>>> -- 
> >>>>>> 2.47.3
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Is this really a hardware description though ?
> >>>>
> >>>> I would say yes it is. The wifi chip has an rfkill input pin and
> >>>> things will be broken when that pin is hardwired to a fixed value
> >>>> rather then being actually connected to a GPIO from say
> >>>> the embedded controller.
> >>>>
> >>>
> >>> IIUC, even if the M.2 slot has the W_DISABLE1# signal routed from the host,
> >>> the device won't make use of it as there is no physical connection. So you want
> >>> the WLAN driver to change the state through SW?
> >>>
> >>>> So I think that we would need here is not a disable-rfkill property
> >>>> but some way to indicate in the DT-node that the rfkill input pin
> >>>> is not connected and thus should be ignored.
> >>>>
> >>>> This (the rfkill input pin being not-connected) IMHO very much
> >>>> is hw-description.
> >>>>
> >>>
> >>> Though we can argue this way, I would prefer to handle it in the driver. For
> >>> example, with my M.2 series, we will end up describing the M.2 slot:
> >>>
> >>> 	connector {
> >>> 		compatible = "pcie-m2-e-connector";
> >>> 		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
> >>> 		...
> >>> 		ports {
> >>> 			...
> >>> 			endpoint@0 {
> >>> 				reg = <0>;
> >>> 				remote-endpoint = <&pcie4_port0_ep>;
> >>> 			};
> >>> 		};
> >>> 	};
> >>>
> >>> Then if we use a DT property to convey the RFKILL pin state of the device, we
> >>> would need to describe the endpoint device in DT and hardcode the state:
> >>>
> >>> 	&pcie4_port0 {
> >>> 		...
> >>> 		port {
> >>> 			pcie4_port0_ep: endpoint {
> >>> 				remote-endpoint = <&m2_e_pcie_ep>;
> >>> 				disable-rfkill;
> >>> 			};
> >>> 		};
> >>> 	};
> >>>
> >>> So this will essentially make the M.2 device non-swappable unless you change the
> >>> DT since you've how hardcoded the device property in the binding. This is
> >>> something I try to avoid to make the M.2 slot really swappable.
> >>>
> >>> For this reason, I would prefer to handle the RFKILL state in the WLAN driver
> >>> using the device specific compatible. This will be problematic only if multiple
> >>> cards of the same Device ID have different RFKILL state and the devices are not
> >>> distinguishable even with sub IDs.
> >>
> >> I think we're miscommunicating here. I'm not talking about the card having
> >> a broken rfkill implementation, I'm talking about the M.2 slot on the mainboard
> >> having e.g. W_DISABLE1# hardwired in such a way that cards would interpret it as
> >> having to always disable their wifi radio which is very similar to what is
> >> happening on the surface device. Except that on the Surface there is no M.2 slot,
> >> the wifi is just soldered onto the mainboard I believe.
> >>
> > 
> > Ah, sorry for the confusion. I did misinterpret what you said.
> > 
> >> Based on experience I'm pretty sure we will encounter M.2 slots which such
> >> a hardwired W_DISABLE1# signal sooner rather then later.
> >>
> > 
> > But it makes no sense IMO. Vendors will usually connect unimplemented W_DISABL1#
> > GPIOs to a pull-up resistor so that the radios are operational all the time. I
> > don't see how they would expect a WLAN or any device with a radio to be
> > connected to the slot if they hardwire the pin to low.
> 
> Pins which are considered "unused" are also often hardwired
> to ground. If the m.2 slot is tested with a wifi-module where
> the W_DISABLE1# signal is not used on the wifi-module I can
> easily see this happen. I've seen a lot crazier / buggy stuff
> happen.
> 
> > Are you sure that on the surface the pin is actually hardwired to low and not
> > connected to a GPIO that drivers the signal low?
> 
> I don't know what is the exact problem on the Surface. I just
> expect to see this more often, we've certainly seen lots of
> issues like this on x86 laptops. Things end up looking like
> the hard rfkill is activated all the time (and we often don't know
> if this is a fw issue, or an actually hardwired problem).
> 
> Just an example from the top of my head the Broadcom windows
> drivers use different BT fw files for the same wifi/bt combo
> chip depending on the vend:prod id pair. One of the things which
> is different is that some fw files invert the BT rfkill signal
> because it is wired wrong (or there is an EC fw bug) and this
> is then worked around in the bt fw.
> 
> As we see a growing proliferation of arm64 laptops I fully
> expect all the fun from having a gazillion different designs
> with a time to market rush behind them result in similar issues
> on arm64.
> 
> Note I'm not saying we must tackle this today, we can wait
> till we see the first case in the real world I guess.
> 
> I just thought that based on my experience this is more or
> less bound to happen, we could comeup with a solution for
> this now and then this solution could also nicely serve
> the Surface case which started this thread.
> 
> But we can also delay tackling this and come up with some
> bespoke solution for the Surface case, like as suggested
> maybe a special compatible string ?
> 

Hmm. If we want to go with the DT property, I'd use something like
'broken-rfkill' or 'broken-w-disable1' or similar in the connector node, not in
the device node. This will convey the fact that the RFKILL switch is broken
in the connector or the hardware topology is not known.

But we do not have the connector binding merged yet. Until then, I'd suggest to
keep the hack in the WLAN driver by using the platform compatible and Device ID:

diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index cc352eef1939..481778eb2c95 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -77,6 +77,16 @@ static int ath12k_core_rfkill_config(struct ath12k_base *ab)
        if (ath12k_acpi_get_disable_rfkill(ab))
                return 0;
 
+       /*
+        * TODO: On Microsoft Surface Pro 11, OS is not able to control the
+        * RFKILL switch. So keep the RFKILL disabled until the OS learns about
+        * it. Ideally, this info should come from the connector node of the
+        * board DT file. But since the connector DT node is not available,
+        * implement the hack in the driver.
+        */
+       if (of_machine_is_compatible("microsoft,denali") && (ab->id.device == 0x1107))
+               return 0;
+
        for (i = 0; i < ab->num_radios; i++) {
                ar = ab->pdevs[i].ar;


Once the connector binding gets merged, hopefully we can add the DT property and
use it in the driver.

> > It is just hard to believe that board designers can do a blunder like this.
> 
> Heh, you won't believe all the crap happening on cheap
> x86 devices.
> 

Coming from the DT world, I thought the ACPI world is superior, but this reminds
of the fact "No world is superior to another" :)

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v5 2/7] dt-bindings: wireless: ieee80211: Add disable-rfkill property

[Jérôme de Bretagne]

Le mar. 23 déc. 2025 à 07:31, Manivannan Sadhasivam <mani@kernel.org> a écrit :
>
> On Mon, Dec 22, 2025 at 03:22:55PM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 22-Dec-25 14:41, Manivannan Sadhasivam wrote:
> > > On Mon, Dec 22, 2025 at 01:41:48PM +0100, Hans de Goede wrote:
> > >> Hi Mani,
> > >>
> > >> On 22-Dec-25 12:45, Manivannan Sadhasivam wrote:
> > >>> On Mon, Dec 22, 2025 at 11:23:18AM +0100, Hans de Goede wrote:
> > >>>> +Cc Mani
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> On 20-Dec-25 07:04, Bryan O'Donoghue wrote:
> > >>>>> On 20/12/2025 00:21, Jérôme de Bretagne via B4 Relay wrote:
> > >>>>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > >>>>>>
> > >>>>>> For some devices, Wi-Fi is entirely hard blocked by default making
> > >>>>>> the Wi-Fi radio unusable, except if rfkill is disabled as expected
> > >>>>>> on those models.
> > >>>>>>
> > >>>>>> Commit c6a7c0b09d5f ("wifi: ath12k: Add Support for enabling or
> > >>>>>> disabling specific features based on ACPI bitflag") added a way to
> > >>>>>> support features set via ACPI, including the DISABLE_RFKILL bit.
> > >>>>>>
> > >>>>>> Add a disable-rfkill property to expose the DISABLE_RFKILL bit
> > >>>>>> equivalent for devices described by a Devicetree instead of ACPI.
> > >>>>>>
> > >>>>>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > >>>>>> ---
> > >>>>>>   Documentation/devicetree/bindings/net/wireless/ieee80211.yaml | 6 ++++++
> > >>>>>>   1 file changed, 6 insertions(+)
> > >>>>>>
> > >>>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > >>>>>> index d89f7a3f88a71d45d6f4ab2ae909eae09cbcaf9a..c10a4675640be947cd0b5eaec2c7ff367fd93945 100644
> > >>>>>> --- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > >>>>>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
> > >>>>>> @@ -29,6 +29,12 @@ properties:
> > >>>>>>         different 5 GHz subbands. Using them incorrectly could not work or
> > >>>>>>         decrease performance noticeably
> > >>>>>>
> > >>>>>> +  disable-rfkill:
> > >>>>>> +    type: boolean
> > >>>>>> +    description:
> > >>>>>> +      Disable rfkill for some devices on which Wi-Fi would be entirely hard
> > >>>>>> +      blocked by default otherwise
> > >>>>>> +
> > >>>>>>   additionalProperties: true
> > >>>>>>
> > >>>>>>   examples:
> > >>>>>>
> > >>>>>> --
> > >>>>>> 2.47.3
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> Is this really a hardware description though ?
> > >>>>
> > >>>> I would say yes it is. The wifi chip has an rfkill input pin and
> > >>>> things will be broken when that pin is hardwired to a fixed value
> > >>>> rather then being actually connected to a GPIO from say
> > >>>> the embedded controller.
> > >>>>
> > >>>
> > >>> IIUC, even if the M.2 slot has the W_DISABLE1# signal routed from the host,
> > >>> the device won't make use of it as there is no physical connection. So you want
> > >>> the WLAN driver to change the state through SW?
> > >>>
> > >>>> So I think that we would need here is not a disable-rfkill property
> > >>>> but some way to indicate in the DT-node that the rfkill input pin
> > >>>> is not connected and thus should be ignored.
> > >>>>
> > >>>> This (the rfkill input pin being not-connected) IMHO very much
> > >>>> is hw-description.
> > >>>>
> > >>>
> > >>> Though we can argue this way, I would prefer to handle it in the driver. For
> > >>> example, with my M.2 series, we will end up describing the M.2 slot:
> > >>>
> > >>>   connector {
> > >>>           compatible = "pcie-m2-e-connector";
> > >>>           w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
> > >>>           ...
> > >>>           ports {
> > >>>                   ...
> > >>>                   endpoint@0 {
> > >>>                           reg = <0>;
> > >>>                           remote-endpoint = <&pcie4_port0_ep>;
> > >>>                   };
> > >>>           };
> > >>>   };
> > >>>
> > >>> Then if we use a DT property to convey the RFKILL pin state of the device, we
> > >>> would need to describe the endpoint device in DT and hardcode the state:
> > >>>
> > >>>   &pcie4_port0 {
> > >>>           ...
> > >>>           port {
> > >>>                   pcie4_port0_ep: endpoint {
> > >>>                           remote-endpoint = <&m2_e_pcie_ep>;
> > >>>                           disable-rfkill;
> > >>>                   };
> > >>>           };
> > >>>   };
> > >>>
> > >>> So this will essentially make the M.2 device non-swappable unless you change the
> > >>> DT since you've how hardcoded the device property in the binding. This is
> > >>> something I try to avoid to make the M.2 slot really swappable.
> > >>>
> > >>> For this reason, I would prefer to handle the RFKILL state in the WLAN driver
> > >>> using the device specific compatible. This will be problematic only if multiple
> > >>> cards of the same Device ID have different RFKILL state and the devices are not
> > >>> distinguishable even with sub IDs.
> > >>
> > >> I think we're miscommunicating here. I'm not talking about the card having
> > >> a broken rfkill implementation, I'm talking about the M.2 slot on the mainboard
> > >> having e.g. W_DISABLE1# hardwired in such a way that cards would interpret it as
> > >> having to always disable their wifi radio which is very similar to what is
> > >> happening on the surface device. Except that on the Surface there is no M.2 slot,
> > >> the wifi is just soldered onto the mainboard I believe.
> > >>
> > >
> > > Ah, sorry for the confusion. I did misinterpret what you said.
> > >
> > >> Based on experience I'm pretty sure we will encounter M.2 slots which such
> > >> a hardwired W_DISABLE1# signal sooner rather then later.
> > >>
> > >
> > > But it makes no sense IMO. Vendors will usually connect unimplemented W_DISABL1#
> > > GPIOs to a pull-up resistor so that the radios are operational all the time. I
> > > don't see how they would expect a WLAN or any device with a radio to be
> > > connected to the slot if they hardwire the pin to low.
> >
> > Pins which are considered "unused" are also often hardwired
> > to ground. If the m.2 slot is tested with a wifi-module where
> > the W_DISABLE1# signal is not used on the wifi-module I can
> > easily see this happen. I've seen a lot crazier / buggy stuff
> > happen.
> >
> > > Are you sure that on the surface the pin is actually hardwired to low and not
> > > connected to a GPIO that drivers the signal low?
> >
> > I don't know what is the exact problem on the Surface. I just
> > expect to see this more often, we've certainly seen lots of
> > issues like this on x86 laptops. Things end up looking like
> > the hard rfkill is activated all the time (and we often don't know
> > if this is a fw issue, or an actually hardwired problem).
> >
> > Just an example from the top of my head the Broadcom windows
> > drivers use different BT fw files for the same wifi/bt combo
> > chip depending on the vend:prod id pair. One of the things which
> > is different is that some fw files invert the BT rfkill signal
> > because it is wired wrong (or there is an EC fw bug) and this
> > is then worked around in the bt fw.
> >
> > As we see a growing proliferation of arm64 laptops I fully
> > expect all the fun from having a gazillion different designs
> > with a time to market rush behind them result in similar issues
> > on arm64.
> >
> > Note I'm not saying we must tackle this today, we can wait
> > till we see the first case in the real world I guess.
> >
> > I just thought that based on my experience this is more or
> > less bound to happen, we could comeup with a solution for
> > this now and then this solution could also nicely serve
> > the Surface case which started this thread.
> >
> > But we can also delay tackling this and come up with some
> > bespoke solution for the Surface case, like as suggested
> > maybe a special compatible string ?
> >
>
> Hmm. If we want to go with the DT property, I'd use something like
> 'broken-rfkill' or 'broken-w-disable1' or similar in the connector node, not in
> the device node. This will convey the fact that the RFKILL switch is broken
> in the connector or the hardware topology is not known.
>
> But we do not have the connector binding merged yet. Until then, I'd suggest to
> keep the hack in the WLAN driver by using the platform compatible and Device ID:

If that suggestion is accepted, please keep in mind that this
issue is also impacting the Surface Laptop 7 family, with the
"microsoft,romulus13" and "microsoft,romulus15" compatibles.

The SL7 rfkill issue is mentioned here:
   https://github.com/bryce-hoehn/linux-surface-laptop-7
or here:
   https://github.com/linux-surface/linux-surface/issues/1590
for reference.

> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
> index cc352eef1939..481778eb2c95 100644
> --- a/drivers/net/wireless/ath/ath12k/core.c
> +++ b/drivers/net/wireless/ath/ath12k/core.c
> @@ -77,6 +77,16 @@ static int ath12k_core_rfkill_config(struct ath12k_base *ab)
>         if (ath12k_acpi_get_disable_rfkill(ab))
>                 return 0;
>
> +       /*
> +        * TODO: On Microsoft Surface Pro 11, OS is not able to control the
> +        * RFKILL switch. So keep the RFKILL disabled until the OS learns about
> +        * it. Ideally, this info should come from the connector node of the
> +        * board DT file. But since the connector DT node is not available,
> +        * implement the hack in the driver.
> +        */
> +       if (of_machine_is_compatible("microsoft,denali") && (ab->id.device == 0x1107))
> +               return 0;
> +
>         for (i = 0; i < ab->num_radios; i++) {
>                 ar = ab->pdevs[i].ar;
>
>
> Once the connector binding gets merged, hopefully we can add the DT property and
> use it in the driver.
>
> > > It is just hard to believe that board designers can do a blunder like this.
> >
> > Heh, you won't believe all the crap happening on cheap
> > x86 devices.
> >
>
> Coming from the DT world, I thought the ACPI world is superior, but this reminds
> of the fact "No world is superior to another" :)
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்

Thank you,
Jérôme