linux-kernel

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]

Date:   Tue, 29 Mar 2022 20:45:56 +0200
From:   Stephen Boyd <swboyd@...omium.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Joseph Barrera <joebar@...gle.com>
Subject: 

Quoting Doug Anderson (2022-03-28 09:05:05)
> Hi,
>
> On Fri, Mar 25, 2022 at 4:43 PM Stephen Boyd <swboyd@...omium.org> wrote:
> >
> > We had to do this spi0/spi6 flip-flop on trogdor-r0 because the spi
> > buses got swizzled between r0 and r1. The swizzle stopped after r1, but
> > we kept this around to support either hardware possibility and to keep
> > trogdor-r0 working.
> >
> > trogdor-r0 isn't supported upstream, so this swizzle is not doing
> > anything besides making a pattern that others try to copy for the EC and
> > H1 nodes. Let's remove it and simplify the dts files.
> >
> > Cc: Joseph Barrera <joebar@...gle.com>
> > Cc: Douglas Anderson <dianders@...omium.org>
> > Signed-off-by: Stephen Boyd <swboyd@...omium.org>
> > ---
> >  arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi   | 5 -----
> >  arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar.dtsi | 3 ---
> >  arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi    | 3 ---
> >  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi          | 5 +++--
> >  4 files changed, 3 insertions(+), 13 deletions(-)
>
> What about pompom?
> What about trogdor-r1?
>
>
> > diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
> > index 75df5d1633b2..fe2369c29aad 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
> > @@ -5,9 +5,6 @@
> >   * Copyright 2020 Google LLC.
> >   */
> >
> > -ap_ec_spi: &spi6 {};
> > -ap_h1_spi: &spi0 {};
> > -
> >  #include "sc7180-trogdor.dtsi"
> >
> >  &ap_sar_sensor {
> > diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> > index 3bf40b6abcba..3123665f6c3c 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> > @@ -11,6 +11,7 @@
> >  #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> >  #include <dt-bindings/sound/sc7180-lpass.h>
> >
> > +#include "sc7180.dtsi"
>
> If we're going to move the "sc7180.dtsi" to trogdor then we should
> move it for everyone, right? Right now you're _only_ removing it from
> coachz. I think that means that for every other board the
> "sc7180.dtsi" file is included more than once. These aren't like C
> header files where there's a convention to have header guards.

Yes that was the intention. I didn't notice that there were so many
other includes of sc7180.dtsi though.

>
> I _think_ that could actually cause problems too, right? So if you
> include it once and then you override a status to "okay" and then you
> included it again it might get changed back to "disabled" ?
>
> The easiest solution would be to just leave the sc7180.dtsi include
> where it was. If you want to try to do better, I _think_ (but haven't
> tried) that you can change all of the existing includes of
> "sc7180.dtsi" to be includes of "sc7180-trogdor.dtsi" and then remove
> the existing includes of "sc7180-trogdor.dtsi". IIRC the reason that
> the sc7180.dtsi include is scattered everywhere is that we needed the
> i2c bus before we could define the parade / ti bridge but then we
> needed the parade / ti bridge before we included the board specific
> bits so we could define the panel.

Yeah let me try that.