linux-kernel - Re: [PATCH 2/4] arm64: dts: qcom: Add support for X1E80100 Dell Latitude 7455

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aDXWcASIH92C3oKo@linaro.org>
Date: Tue, 27 May 2025 17:12:48 +0200
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
	Val Packett <val@...kett.cool>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Johan Hovold <johan@...nel.org>
Subject: Re: [PATCH 2/4] arm64: dts: qcom: Add support for X1E80100 Dell
 Latitude 7455

On Tue, May 27, 2025 at 05:54:49PM +0530, Manivannan Sadhasivam wrote:
> On May 25, 2025 6:55:42 PM GMT+05:30, Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com> wrote:
> >On Sun, May 25, 2025 at 06:53:34AM -0300, Val Packett wrote:
> >> Add a device tree for the Dell Latitude 7455 (X Elite) laptop.
> >> 
> >> Working:
> >> - Wi-Fi (WCN7850 hw2.0)
> >> - Bluetooth
> >> - USB Type-C x2 (with DP alt mode)
> >> - USB Type-A
> >> - USB Fingerprint reader
> >> - eDP Display (with brightness)
> >> - NVMe
> >> - SDHC (microSD slot)
> >> - Keyboard
> >> - Touchpad
> >> - Touchscreen
> >> - Battery
> >> 
> >> Not included:
> >> - Audio
> >> - Camera
> >> 
> >> Signed-off-by: Val Packett <val@...kett.cool>
> >> ---
> >>  arch/arm64/boot/dts/qcom/Makefile             |    2 +
> >>  .../dts/qcom/x1e80100-dell-latitude-7455.dts  | 1484 +++++++++++++++++
> >>  2 files changed, 1486 insertions(+)
> >>  create mode 100644 arch/arm64/boot/dts/qcom/x1e80100-dell-latitude-7455.dts
> >> 
> >
> [...]
> >> +
> >> +	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;
> >> +	};
> >> +
> >> +	/*
> >> +	 * TODO: These two regulators are actually part of the removable M.2
> >> +	 * card and not the mainboard. Need to describe this differently.
> >> +	 * Functionally it works correctly, because all we need to do is to
> >> +	 * turn on the actual 3.3V supply above.
> >> +	 */
> >
> >Indeed, it should be possible to describe just M.2 card, because in
> >theory nothing prevents you from swapping it with some other card.
> >I _think_, it should be possible to describe WiFI part by listing 3.3V
> >supply as slot supply. However I don't think we have a way "random BT
> >connected to the UART". So, this is probably suitable.
> 
> If it is *just* an M.2 card, then why the PMU node for WLAN is
> defined?

We keep discussing incomplete approaches for handling these M.2 cards,
but still haven't come up with a proper consensus for the whole setup.
This is why currently describing the PMU - even if it feels weird and
describes lots of redundant information - is the only working solution.

These are reasonably standard M.2 cards, with the following resources
that must be controlled:

 - Shared:
     - 3.3V supply
     - 1.8V supply
 - WiFi:
     - PCIe (discoverable)
     - wlan-enable-gpios (W_DISABLE1#)
 - Bluetooth
     - UART (non-discoverable, must be hardcoded in DT?)
     - bt-enable-gpios (W_DISABLE2#)

Currently, defining the PMU is required for the Bluetooth
(qcom,wcn7850-bt) and also the WiFi (pci17cb,1107) bindings. We need to
add proper alternatives for the M.2 case.

> PMU is defining the internal supplies of the M.2 cards. If
> that's not required, you'd be better off with defining the slot supply
> alone in the PCIe bridge node. Like,
> 
> In SoC dtsi:
> 
> pcieport0: pcie@0 {
> 	compatible "pciclass,0604"
> 	...
> };
> 
> In board dts:
> 
> &pcieport0 {
> 	vpcie3v3-supply = <&vreg_wcn_3p3>;
> };
>
> But I guess you are sticking with PMU for UART? Even in that case, the PCIe node should just define the slot supply.
>

Can this handle the standard 1.8V supply as well? What about the
wlan-enable-gpios (W_DISABLE1#)? I don't think it makes sense describing
the shared PMU only for Bluetooth. The question if the PMU really needs
to be modelled at all (rather than relying on reference counting for
regulators etc) is also still open though.

We need to start looking for solutions for the whole setup. We have
discussed lots of partial solutions over the last year, but eventually
always got stuck when putting things together for the whole M.2 card. :/

Thanks,
Stephan