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] [day] [month] [year] [list]
Message-ID: <CAE-0n519PbRr6vzpkK9dL-gEp=QCHYPipZUTAAyC4YfCSpNjPw@mail.gmail.com>
Date:   Thu, 16 Feb 2023 19:47:58 +0100
From:   Stephen Boyd <swboyd@...omium.org>
To:     Bjorn Andersson <andersson@...nel.org>,
        Douglas Anderson <dianders@...omium.org>
Cc:     amstan@...omium.org, mka@...omium.org,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Clark <robdclark@...omium.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Fix trogdor qspi pull direction

Quoting Stephen Boyd (2023-02-15 21:46:52)
> Quoting Douglas Anderson (2023-02-13 16:57:51)
> > Though it shouldn't matter very much, we've decided that it's slightly
> > better to park the qspi lines for trogdor with an internal pulldown
> > instead of an internal pullup. There was a footnote that Cr50 (which
> > connects to these lines too) may have pulldowns configured on one of
> > the data lines and we don't want to have fighting pulls.
>
> Ok.
>
> > This also
> > means that if the pulls somehow get left powered in S3 (which I'm
> > uncertain about) that they won't be pulling up lines on an unpowered
> > SPI part.
>
> As far as I know, the pulls are maintained in S3. There's verbage about
> "keeper" on the pins.
>
> The SPI part is powered in S3 though. I believe it only loses power in
> S5. Can you reword this statement?

I see that we list pp1800_l13a in sc7180-trogdor.dtsi but don't mark it
always on. I suspect it is turned off at late init, but then wifi turns
it on itself because it is the IO voltage for the wcn chip. We're at the
mercy of the wifi firmware here? Shouldn't we just mark it always on and
boot on? I wonder how this is working.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ