There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies.
Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module.
The 3.3V supply for the module is assumed to come directly from the main board supply, which is 12V. To model this in the device tree, we add a fixed 12V regulator node as the DC-IN source and connect it to the 3.3V regulator node.
Signed-off-by: Wei Deng wei.deng@oss.qualcomm.com --- arch/arm64/boot/dts/qcom/lemans-evk.dts | 115 ++++++++++++++++++++++++ 1 file changed, 115 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts index b40fa203e4a2..c87291e3c6ac 100644 --- a/arch/arm64/boot/dts/qcom/lemans-evk.dts +++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts @@ -21,6 +21,7 @@ aliases { ethernet0 = ðernet0; mmc1 = &sdhc; serial0 = &uart10; + serial1 = &uart17; };
dmic: audio-codec-0 { @@ -110,6 +111,17 @@ vmmc_sdc: regulator-vmmc-sdc { regulator-max-microvolt = <2950000>; };
+ vreg_dcin_12v: regulator-dcin-12v { + compatible = "regulator-fixed"; + + regulator-name = "VREG_DCIN_12V"; + regulator-min-microvolt = <12000000>; + regulator-max-microvolt = <12000000>; + + regulator-boot-on; + regulator-always-on; + }; + vreg_sdc: regulator-vreg-sdc { compatible = "regulator-gpio";
@@ -123,6 +135,75 @@ vreg_sdc: regulator-vreg-sdc {
startup-delay-us = <100>; }; + + vreg_wcn_3p3: regulator-wcn-3p3 { + compatible = "regulator-fixed"; + + regulator-name = "VREG_WCN_3P3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + vin-supply = <&vreg_dcin_12v>; + + regulator-boot-on; + }; + + wcn6855-pmu { + compatible = "qcom,wcn6855-pmu"; + + vddio-supply = <&vreg_wcn_3p3>; + vddaon-supply = <&vreg_wcn_3p3>; + vddpmu-supply = <&vreg_wcn_3p3>; + vddpmumx-supply = <&vreg_wcn_3p3>; + vddpmucx-supply = <&vreg_wcn_3p3>; + vddrfa0p95-supply = <&vreg_wcn_3p3>; + vddrfa1p3-supply = <&vreg_wcn_3p3>; + vddrfa1p9-supply = <&vreg_wcn_3p3>; + vddpcielp3-supply = <&vreg_wcn_3p3>; + vddpcielp9-supply = <&vreg_wcn_3p3>; + + 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 { @@ -627,6 +708,22 @@ &qupv3_id_2 { status = "okay"; };
+&qup_uart17_cts { + bias-disable; +}; + +&qup_uart17_rts { + bias-pull-down; +}; + +&qup_uart17_tx { + bias-pull-up; +}; + +&qup_uart17_rx { + bias-pull-down; +}; + &remoteproc_adsp { firmware-name = "qcom/sa8775p/adsp.mbn";
@@ -761,6 +858,24 @@ &uart10 { status = "okay"; };
+&uart17 { + status = "okay"; + + bluetooth: bluetooth { + compatible = "qcom,wcn6855-bt"; + max-speed = <3200000>; + + vddrfacmn-supply = <&vreg_pmu_rfa_cmn>; + vddaon-supply = <&vreg_pmu_aon_0p59>; + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>; + vddwlmx-supply = <&vreg_pmu_wlmx_0p85>; + vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>; + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>; + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; + vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>; + }; +}; + &ufs_mem_hc { reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>; vcc-supply = <&vreg_l8a>;
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#opti...
Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree. Subject: [PATCH] arm64: dts: qcom: lemans-evk: Enable Bluetooth support Link: https://lore.kernel.org/stable/20251110055709.319587-1-wei.deng%40oss.qualco...
On 11/10/25 6:57 AM, Wei Deng wrote:
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies.
Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module.
The 3.3V supply for the module is assumed to come directly from the main board supply, which is 12V. To model this in the device tree, we add a fixed 12V regulator node as the DC-IN source and connect it to the 3.3V regulator node.
Signed-off-by: Wei Deng wei.deng@oss.qualcomm.com
[...]
&apps_rsc { @@ -627,6 +708,22 @@ &qupv3_id_2 { status = "okay"; }; +&qup_uart17_cts {
- bias-disable;
+};
+&qup_uart17_rts {
- bias-pull-down;
+};
+&qup_uart17_tx {
- bias-pull-up;
+};
+&qup_uart17_rx {
- bias-pull-down;
+};
This is notably different than all other platforms' bluetooth pin settings - for example pulling down RX sounds odd, since UART signal is supposed to be high at idle
see hamoa.dtsi : qup_uart14_default as an example
Konrad
Hi Konrad,
Thanks for your comments.
On 11/10/2025 7:49 PM, Konrad Dybcio wrote:
On 11/10/25 6:57 AM, Wei Deng wrote:
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies.
Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module.
The 3.3V supply for the module is assumed to come directly from the main board supply, which is 12V. To model this in the device tree, we add a fixed 12V regulator node as the DC-IN source and connect it to the 3.3V regulator node.
Signed-off-by: Wei Deng wei.deng@oss.qualcomm.com
[...]
&apps_rsc { @@ -627,6 +708,22 @@ &qupv3_id_2 { status = "okay"; }; +&qup_uart17_cts {
- bias-disable;
+};
+&qup_uart17_rts {
- bias-pull-down;
+};
+&qup_uart17_tx {
- bias-pull-up;
+};
+&qup_uart17_rx {
- bias-pull-down;
+};
This is notably different than all other platforms' bluetooth pin settings - for example pulling down RX sounds odd, since UART signal is supposed to be high at idle
see hamoa.dtsi : qup_uart14_default as an example
I followed the qup_uart17 settings from lemans-ride-common.dtsi. Since these configurations are not required for Bluetooth functionality. I will remove this configuration in the next patch.
Konrad
On 11/11/25 1:24 PM, Wei Deng wrote:
Hi Konrad,
Thanks for your comments.
On 11/10/2025 7:49 PM, Konrad Dybcio wrote:
On 11/10/25 6:57 AM, Wei Deng wrote:
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies.
Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module.
The 3.3V supply for the module is assumed to come directly from the main board supply, which is 12V. To model this in the device tree, we add a fixed 12V regulator node as the DC-IN source and connect it to the 3.3V regulator node.
Signed-off-by: Wei Deng wei.deng@oss.qualcomm.com
[...]
&apps_rsc { @@ -627,6 +708,22 @@ &qupv3_id_2 { status = "okay"; }; +&qup_uart17_cts {
- bias-disable;
+};
+&qup_uart17_rts {
- bias-pull-down;
+};
+&qup_uart17_tx {
- bias-pull-up;
+};
+&qup_uart17_rx {
- bias-pull-down;
+};
This is notably different than all other platforms' bluetooth pin settings - for example pulling down RX sounds odd, since UART signal is supposed to be high at idle
see hamoa.dtsi : qup_uart14_default as an example
I followed the qup_uart17 settings from lemans-ride-common.dtsi. Since these configurations are not required for Bluetooth functionality. I will remove this configuration in the next patch.
This feels like you're essentially saying you don't know/care why you did this before and don't know why you're changing it again. This doesn't give me a lot of confidence. Are you testing your changes on real hw, running an upstream kernel with some distro userland?
Konrad
On Mon, Nov 10, 2025 at 11:27:09AM +0530, Wei Deng wrote:
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies.
Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module.
The 3.3V supply for the module is assumed to come directly from the
Why do you need to assume anything?
main board supply, which is 12V. To model this in the device tree, we add a fixed 12V regulator node as the DC-IN source and connect it to the 3.3V regulator node.
Signed-off-by: Wei Deng wei.deng@oss.qualcomm.com
arch/arm64/boot/dts/qcom/lemans-evk.dts | 115 ++++++++++++++++++++++++ 1 file changed, 115 insertions(+)
Why do you cc stable for this patch?
Hi Dmitry, Thanks for your comments.
On 11/10/2025 8:39 PM, Dmitry Baryshkov wrote:
On Mon, Nov 10, 2025 at 11:27:09AM +0530, Wei Deng wrote:
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies.
Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module.
The 3.3V supply for the module is assumed to come directly from the
Why do you need to assume anything?
The M.2 interface provides a 3.3V supply, which originates from the main board’s 12V rail. To represent this power hierarchy in the device tree, add a fixed 12V regulator node as the DC-IN source and link it to the 3.3V regulator node. Will update commit message in the next patch.
main board supply, which is 12V. To model this in the device tree, we add a fixed 12V regulator node as the DC-IN source and connect it to the 3.3V regulator node.
Signed-off-by: Wei Deng wei.deng@oss.qualcomm.com
arch/arm64/boot/dts/qcom/lemans-evk.dts | 115 ++++++++++++++++++++++++ 1 file changed, 115 insertions(+)
Why do you cc stable for this patch?
I will remove the Cc: stable in the next patch.
On Mon, 10 Nov 2025 11:27:09 +0530, Wei Deng wrote:
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies.
Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module.
The 3.3V supply for the module is assumed to come directly from the main board supply, which is 12V. To model this in the device tree, we add a fixed 12V regulator node as the DC-IN source and connect it to the 3.3V regulator node.
Signed-off-by: Wei Deng wei.deng@oss.qualcomm.com
arch/arm64/boot/dts/qcom/lemans-evk.dts | 115 ++++++++++++++++++++++++ 1 file changed, 115 insertions(+)
My bot found new DTB warnings on the .dts files added or changed in this series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date:
pip3 install dtschema --upgrade
This patch series was applied (using b4) to base: Base: attempting to guess base-commit... Base: tags/next-20251107 (exact match) Base: tags/next-20251107 (use --merge-base to override)
If this is not the correct base, please add 'base-commit' tag (or use b4 which does this automatically)
New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20251110055709.319587-1-wei.deng@oss.qualcomm.com:
arch/arm64/boot/dts/qcom/lemans-evk.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpcielp3-supply', 'vddpcielp9-supply' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml arch/arm64/boot/dts/qcom/lemans-evk.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpcie1p3-supply' is a required property from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml arch/arm64/boot/dts/qcom/lemans-evk.dtb: wcn6855-pmu (qcom,wcn6855-pmu): 'vddpcie1p9-supply' is a required property from schema $id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml
linux-stable-mirror@lists.linaro.org
-
Dmitry Baryshkov -
kernel test robot -
Konrad Dybcio -
Rob Herring (Arm) -
Wei Deng