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: <CAMRc=Mc9jMe=hSXmcRLLX61abUjetCRZVeOK3G31vdx5JQNNMQ@mail.gmail.com>
Date: Thu, 3 Oct 2024 13:38:35 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Johan Hovold <johan@...nel.org>
Cc: 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>, 
	Kalle Valo <kvalo@...nel.org>, linux-arm-msm@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Steev Klimaszewski <steev@...i.org>
Subject: Re: [PATCH v4 3/3] arm64: dts: qcom: sc8280xp-x13s: model the PMU of
 the on-board wcn6855

On Thu, Oct 3, 2024 at 1:07 PM Johan Hovold <johan@...nel.org> wrote:
>
> On Mon, Sep 30, 2024 at 12:30:39PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >
> > Add a node for the PMU of the WCN6855 and rework the inputs of the wifi
> > and bluetooth nodes to consume the PMU's outputs.
> >
> > With this we can drop the regulator-always-on properties from vreg_s11b
> > and vreg_s12b as they will now be enabled by the power sequencing
> > driver.
> >
> > Tested-by: Steev Klimaszewski <steev@...i.org> # Thinkpad X13s
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
>
> Without this patch I'm seeing an indefinite probe deferral with
> 6.12-rc1:
>
>         platform 1c00000.pcie:pcie@0:wifi@0: deferred probe pending: pci-pwrctl-pwrseq: Failed to get the power sequencer
>
> Can you please look into that and make sure that the existing DT
> continues to work without such warnings.
>

Ah, dammit, I missed the fact that X13s already has this node defined
so PCI pwrctl will consume it and try to get the power sequencer
handle. I'm wondering how to tackle it though... It will most likely
require some kind of a driver quirk where we check if we have the PMU
node and if not, then don't try to set up power sequencing. Any other
ideas?

> > -
> > -             enable-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
> > -             swctrl-gpios = <&tlmm 132 GPIO_ACTIVE_HIGH>;
>
> What about swctrl? You're just removing this pin from DT now without any
> comment on why you think that is the right thing to do.
>
> Should this one also be an input to the PMU block?
>

I recently added it to the bindings as an optional property. It's
technically an output of the PMU to the host indicating the state of
the clock supply to the BT module. We're not really using it but I can
keep it here if you prefer.

Bart

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ