arch/arm64/boot/dts/qcom/lemans-evk.dts | 115 ++++++++++++++++++++++++ 1 file changed, 115 insertions(+)
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>;
--
2.25.1
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
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? -- With best wishes Dmitry
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. > -- Best Regards, Wei Deng
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
--
Best Regards,
Wei Deng
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
Hi Konrad,
Thanks for your comments.
On 11/12/2025 5:49 PM, Konrad Dybcio wrote:
> 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?
>
We add qup_uart17 config followed the changes referenced in the below
link and validated them on the hardware platform. Bluetooth functionality
works fine before and after the removal.
https://lore.kernel.org/all/20250509090443.4107378-1-quic_vdadhani@quicinc.com/
> Konrad
--
Best Regards,
Wei Deng
© 2016 - 2025 Red Hat, Inc.