linux-kernel - Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

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: <CAGb2v679L8fDbaE6dpEdo2q=fJdF=e6AfzOXvHLBuwZ_5YbDeQ@mail.gmail.com>
Date:   Wed, 13 Jan 2021 17:16:46 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Samuel Holland <samuel@...lland.org>
Cc:     Maxime Ripard <maxime@...no.tech>,
        André Przywara <andre.przywara@....com>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        Rob Herring <robh+dt@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use
 RSB for AXP805 PMIC connection

On Thu, Jan 7, 2021 at 6:27 PM Samuel Holland <samuel@...lland.org> wrote:
>
> On 1/6/21 5:38 AM, Chen-Yu Tsai wrote:
> > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard <maxime@...no.tech> wrote:
> >>
> >> On Mon, Jan 04, 2021 at 10:54:19AM +0000, André Przywara wrote:
> >>> On 03/01/2021 10:00, Samuel Holland wrote:
> >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers
> >>>> PMIC, configure the connection to use the RSB bus rather than the I2C
> >>>> bus. Compared to the I2C controller that shares the pins, the RSB
> >>>> controller allows a higher bus frequency, and it is more CPU-efficient.
> >>>
> >>> But is it really necessary to change the DTs for those boards in this
> >>> way? It means those newer DTs now become incompatible with older
> >>> kernels, and I don't know if those reasons above really justify this.
> >>>
> >>> I understand that we officially don't care about "newer DTs on older
> >>> kernels", but do we really need to break this deliberately, for no
> >>> pressing reasons?
> >>>
> >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs,
> >>> just want to avoid breaking existing ones.
> >>
> >> Doing so would also introduce some inconsistencies, one more thing to
> >> consider during reviews, and would require more testing effort.
> >>
> >> I'm not sure that stretching our - already fairly sparse - resources
> >> thin would be very wise here, especially for something that we don't
> >> have to do and for a setup that isn't really used that much.
> >
> > As soon as some software component starts running RSB, (which I assume
> > is what Samuel is planning to do in Crust?), there's a chance that it
> > doesn't switch the chip back to I2C. And then Linux won't be able to
> > access it.
>
> Crust can handle either way via a config option, which currently
> defaults to I2C for H6. It must use the same selection as Linux, not
> only because of the PMIC mode, but also because of the pinctrl.

Could Crust be made to also handle pinctrl?

> TF-A is already converted to use RSB[1], and it does switch the PMIC
> back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is
> fine. However, Linux currently does not switch the PMIC back. So the
> most likely problem from this patch is that, with new Linux + old TF-A,
> TF-A will be unable to power down the board or access regulators after
> an SoC reset.
>
> I expect there will be a TF-A release between now and when 5.12 hits
> stable, but people tend not upgrade their U-Boot/TF-A very often.
>
> We could solve this by having the Linux RSB driver switch all child
> devices back to I2C in .shutdown, or by dropping this patch and only
> using RSB for new boards (which would also address Andre's concern).

This will work for most cases, except in a kernel panic or IIRC direct
reboot using sysrq. So it's not robust as we'd like it to be.

ChenYu

> Cheers,
> Samuel
>
> [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576
> [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575
>
> > So I'm for keeping things consistent and converting all users to RSB.
> >
> >
> > ChenYu
> >
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@...glegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.