linux-kernel - Re: [PATCH 2/2] arm64: dts: qcom: Add X1E001DE Snapdragon Devkit for Windows

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: <utfifivkqt2mgejmycnyrw4aoy6rbxkifgaxajdbb7lgq76p25@i2zzpeksbwja>
Date: Wed, 16 Oct 2024 13:14:26 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Sibi Sankar <quic_sibis@...cinc.com>, 
	Bjorn Andersson <andersson@...nel.org>, konradybcio@...nel.org, krzk+dt@...nel.org, robh+dt@...nel.org, 
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, 
	conor+dt@...nel.org, abel.vesa@...aro.org, srinivas.kandagatla@...aro.org
Subject: Re: [PATCH 2/2] arm64: dts: qcom: Add X1E001DE Snapdragon Devkit for
 Windows

On Tue, Oct 15, 2024 at 08:57:36PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Oct 15, 2024 at 04:57:45PM +0300, Dmitry Baryshkov wrote:
> > On Tue, 15 Oct 2024 at 16:51, Manivannan Sadhasivam
> > <manivannan.sadhasivam@...aro.org> wrote:
> > >
> > > On Sun, Oct 06, 2024 at 11:31:52PM +0530, Manivannan Sadhasivam wrote:
> > > > On Sun, Oct 06, 2024 at 12:33:21AM +0530, Sibi Sankar wrote:
> > > > >
> > > > >
> > > > > On 10/1/24 14:21, Manivannan Sadhasivam wrote:
> > > > > > On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
> > > > > > > On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@...nel.org> wrote:
> > > > > > > > On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> > > > > > > > > On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> > > > > > > > [..]
> > > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> > > > > > > > [..]
> > > > > > > > > > +
> > > > > > > > > > +&pcie5 {
> > > > > > > > > > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> > > > > > > > > > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> > > > > > > > > > +
> > > > > > > > > > + vddpe-3v3-supply = <&vreg_wwan>;
> > > > > > > > >
> > > > > > > > > Please use pwrseq instead.
> > > > > > > > >
> > > > > > > >
> > > > > > > > What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
> > > > > > >
> > > > > > > First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
> > > > > > >
> > > > > >
> > > > > > Yeah, we should get into the details here. We were not paying attention till
> > > > > > now, but with the advent of pwrseq, we should describe the power supply properly
> > > > > > in DT.
> > > > > >
> > > > > > Here I believe the supply is to the PCIe Mini Card connector where a modem is
> > > > > > connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
> > > > > > connector and we should have a generic pwrseq driver for the mini cards.
> > > > > >
> > > > >
> > > > > Hey Mani, Dmitry,
> > > > >
> > > > > The schematics are identical to that of the X1E CRD with
> > > > > the exception of the pcie daughter card having the rtl8125g
> > > > > on it. Yes, the 3.3V supply is connected to the card as well.
> > > > >
> > > >
> > > > Is this connected to the 3.3vaux of the card? Please specify the actual rail
> > > > name as the 'PCI Express Mini Card Electromechanical Specification' specifies
> > > > only 3.3Vaux and 1.5v supplies.
> > > >
> > > > > Doesn't this mean all other x1e boards out there needs to be
> > > > > updated with pwrseq as well? Anway will get that addressed in
> > > > > v3.
> > > > >
> > > >
> > > > pwrseq is the kernel driver abstraction, nothing to do with DT. But for making
> > > > use of pwrseq, the supplies need to be described in the proper place. In this
> > > > case most likely under a separate node of PCIe bridge. Then you'd need a
> > > > separate pwrseq driver in kernel to parse the supply and take care of it.
> > > >
> > > > I'm currently writing a pwrseq driver for standard slots (x8 for X1E) and should
> > > > be able to post it early next week. So you or someone could use it as a
> > > > reference to add a new driver for m-pcie cards.
> > > >
> > > > If no one picks it up, I may just do it.
> > > >
> > >
> > > Hi,
> > >
> > > The slot driver is taking more time than anticipated due to the pwrctl rework.
> > > So please go ahead with the current binding and we would switch to pwrseq
> > > later once the driver is available.
> > 
> > I assume this applies only to the case of the actual 3.3V being used
> > to power up the PCIe slot? Or to all existing pending items using
> > vddpe-3v3-supply?
> > 
> 
> What do you mean by 'pending items using vddpe-3v3-supply'? I was referring to
> the slot supplies only.

As we've checked offline, it seems to be just a controlled 3.3V supply
for both NVMe and WWAN. I'm fine with using vddpe-3v3-supply.

-- 
With best wishes
Dmitry