From: "Heiko Stübner" <heiko@sntech.de> To: Peter Geis <pgwipeout@gmail.com> Cc: Robin Murphy <robin.murphy@arm.com>, Anand Moon <linux.amoon@gmail.com>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Jagan Teki <jagan@amarulasolutions.com>, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>, Daniel Schultz <d.schultz@phytec.de>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org> Subject: Re: [RFCv1 0/8] RK3399 clean shutdown issue Date: Mon, 09 Dec 2019 14:53:52 +0100 [thread overview] Message-ID: <8087758.JvhXzBlCRf@diego> (raw) In-Reply-To: <CAMdYzYoZY5gau=DGtPhk9CPV_WcyM4wjR9o+rPyaQfOzoy2Y=Q@mail.gmail.com> Hi, Am Montag, 9. Dezember 2019, 14:37:28 CET schrieb Peter Geis: > On Mon, Dec 9, 2019 at 8:29 AM Robin Murphy <robin.murphy@arm.com> wrote: > > > > On 06/12/2019 6:45 pm, Anand Moon wrote: > > > Most of the RK3399 SBC boards do not perform clean > > > shutdown and clean reboot. > > > > FWIW reboot problems on RK3399 have been tracked down to issues in > > upstream ATF, and are unrelated to the PMIC. > > > > > These patches try to help resolve the issue with proper > > > shutdown by turning off the PMIC. > > > > As mentioned elsewhere[1], although this is what the BSP kernel seems to > > do, and in practice it's unlikely to matter for the majority of devboard > > users like you and me, I still feel a bit uncomfortable with this > > solution for systems using ATF as in principle the secure world might > > want to know about orderly shutdowns, and this effectively makes every > > shutdown an unexpected power loss from secure software's point of view. > > > > Robin. > > Since ATF is operating completely in volatile memory, and shouldn't be > touching hardware once it passes off control to the kernel anyways, > what is the harm of pulling the rug out from under it? Secure-world doesn't end with ATF :-) There can also be an instance of OP-TEE or another TEE on top and they often actually do secure storage encrypted onto the hosts mass storage (see kernel's optee module). > If this idea is to prevent issues in the future, such as if ATF does > gain the ability to preempt hardware control, then at that time ATF > will need to be able to handle actually powering off devices using the > same functionality. > > But as we discussed previously, ATF doesn't have this capability, so > in this case any board without a dedicated power-off gpio will be > unable to power off at all. > Also it seems that giving ATF this functionality, with the current > state of ATF, would be cost prohibitive. > > I personally feel that allowing the kernel to do this is a solution to > the problem we have now. For the rest I guess I'll just point to Robin's text and Ack under your system-power-controller patch ;-) Heiko > > [1] > > http://lists.infradead.org/pipermail/linux-rockchip/2019-December/028183.html > > > > > For reference > > > RK805 PMCI data sheet: > > > [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf > > > RK808 PMIC data sheet: > > > [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf > > > RK817 PMIC data sheet: > > > [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf > > > RK818 PMIC data sheet: > > > [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf > > > > > > Reboot issue: > > > My guess is that we need to some proper sequence of > > > setting to PMCI to perform clean. > > > > > > If you have any input please share them. > > > > > > Tested on SBC > > > Rock960 Model A > > > Odroid N1 > > > Rock64 > > > > > > -Anand Moon > > > > > > Anand Moon (8): > > > mfd: rk808: Refactor shutdown functions > > > mfd: rk808: use syscore for RK805 PMIC shutdown > > > mfd: rk808: use syscore for RK808 PMIC shutdown > > > mfd: rk808: use syscore for RK818 PMIC shutdown > > > mfd: rk808: cleanup unused function pointer > > > mfd: rk808: use common syscore for all PMCI for clean shutdown > > > arm64: rockchip: drop unused field from rk8xx i2c node > > > arm: rockchip: drop unused field from rk8xx i2c node > > > > > > arch/arm/boot/dts/rk3036-kylin.dts | 1 - > > > arch/arm/boot/dts/rk3188-px3-evb.dts | 1 - > > > arch/arm/boot/dts/rk3288-evb-rk808.dts | 1 - > > > arch/arm/boot/dts/rk3288-phycore-som.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-popmetal.dts | 1 - > > > arch/arm/boot/dts/rk3288-tinker.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-veyron.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-vyasa.dts | 1 - > > > arch/arm/boot/dts/rv1108-elgin-r1.dts | 1 - > > > arch/arm/boot/dts/rv1108-evb.dts | 1 - > > > arch/arm64/boot/dts/rockchip/px30-evb.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 1 - > > > .../arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 1 - > > > .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 1 - > > > .../boot/dts/rockchip/rk3368-geekbox.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 1 - > > > .../boot/dts/rockchip/rk3368-px5-evb.dts | 1 - > > > .../boot/dts/rockchip/rk3399-firefly.dts | 1 - > > > .../boot/dts/rockchip/rk3399-hugsun-x99.dts | 1 - > > > .../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-leez-p710.dts | 1 - > > > .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-orangepi.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-roc-pc.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-rock-pi-4.dts | 1 - > > > .../boot/dts/rockchip/rk3399-rock960.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-rockpro64.dts | 1 - > > > .../boot/dts/rockchip/rk3399-sapphire.dtsi | 1 - > > > drivers/mfd/rk808.c | 144 +++++------------- > > > include/linux/mfd/rk808.h | 2 - > > > 32 files changed, 42 insertions(+), 134 deletions(-) > > > > > > > _______________________________________________ > > Linux-rockchip mailing list > > Linux-rockchip@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-rockchip >
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de> To: Peter Geis <pgwipeout@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, Daniel Schultz <d.schultz@phytec.de>, linux-kernel@vger.kernel.org, "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>, Rob Herring <robh+dt@kernel.org>, Jagan Teki <jagan@amarulasolutions.com>, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>, Robin Murphy <robin.murphy@arm.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [RFCv1 0/8] RK3399 clean shutdown issue Date: Mon, 09 Dec 2019 14:53:52 +0100 [thread overview] Message-ID: <8087758.JvhXzBlCRf@diego> (raw) In-Reply-To: <CAMdYzYoZY5gau=DGtPhk9CPV_WcyM4wjR9o+rPyaQfOzoy2Y=Q@mail.gmail.com> Hi, Am Montag, 9. Dezember 2019, 14:37:28 CET schrieb Peter Geis: > On Mon, Dec 9, 2019 at 8:29 AM Robin Murphy <robin.murphy@arm.com> wrote: > > > > On 06/12/2019 6:45 pm, Anand Moon wrote: > > > Most of the RK3399 SBC boards do not perform clean > > > shutdown and clean reboot. > > > > FWIW reboot problems on RK3399 have been tracked down to issues in > > upstream ATF, and are unrelated to the PMIC. > > > > > These patches try to help resolve the issue with proper > > > shutdown by turning off the PMIC. > > > > As mentioned elsewhere[1], although this is what the BSP kernel seems to > > do, and in practice it's unlikely to matter for the majority of devboard > > users like you and me, I still feel a bit uncomfortable with this > > solution for systems using ATF as in principle the secure world might > > want to know about orderly shutdowns, and this effectively makes every > > shutdown an unexpected power loss from secure software's point of view. > > > > Robin. > > Since ATF is operating completely in volatile memory, and shouldn't be > touching hardware once it passes off control to the kernel anyways, > what is the harm of pulling the rug out from under it? Secure-world doesn't end with ATF :-) There can also be an instance of OP-TEE or another TEE on top and they often actually do secure storage encrypted onto the hosts mass storage (see kernel's optee module). > If this idea is to prevent issues in the future, such as if ATF does > gain the ability to preempt hardware control, then at that time ATF > will need to be able to handle actually powering off devices using the > same functionality. > > But as we discussed previously, ATF doesn't have this capability, so > in this case any board without a dedicated power-off gpio will be > unable to power off at all. > Also it seems that giving ATF this functionality, with the current > state of ATF, would be cost prohibitive. > > I personally feel that allowing the kernel to do this is a solution to > the problem we have now. For the rest I guess I'll just point to Robin's text and Ack under your system-power-controller patch ;-) Heiko > > [1] > > http://lists.infradead.org/pipermail/linux-rockchip/2019-December/028183.html > > > > > For reference > > > RK805 PMCI data sheet: > > > [0] http://rockchip.fr/RK805%20datasheet%20V1.3.pdf > > > RK808 PMIC data sheet: > > > [1] http://rockchip.fr/RK808%20datasheet%20V1.4.pdf > > > RK817 PMIC data sheet: > > > [2] http://rockchip.fr/RK817%20datasheet%20V1.01.pdf > > > RK818 PMIC data sheet: > > > [3] http://rockchip.fr/RK818%20datasheet%20V1.0.pdf > > > > > > Reboot issue: > > > My guess is that we need to some proper sequence of > > > setting to PMCI to perform clean. > > > > > > If you have any input please share them. > > > > > > Tested on SBC > > > Rock960 Model A > > > Odroid N1 > > > Rock64 > > > > > > -Anand Moon > > > > > > Anand Moon (8): > > > mfd: rk808: Refactor shutdown functions > > > mfd: rk808: use syscore for RK805 PMIC shutdown > > > mfd: rk808: use syscore for RK808 PMIC shutdown > > > mfd: rk808: use syscore for RK818 PMIC shutdown > > > mfd: rk808: cleanup unused function pointer > > > mfd: rk808: use common syscore for all PMCI for clean shutdown > > > arm64: rockchip: drop unused field from rk8xx i2c node > > > arm: rockchip: drop unused field from rk8xx i2c node > > > > > > arch/arm/boot/dts/rk3036-kylin.dts | 1 - > > > arch/arm/boot/dts/rk3188-px3-evb.dts | 1 - > > > arch/arm/boot/dts/rk3288-evb-rk808.dts | 1 - > > > arch/arm/boot/dts/rk3288-phycore-som.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-popmetal.dts | 1 - > > > arch/arm/boot/dts/rk3288-tinker.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-veyron.dtsi | 1 - > > > arch/arm/boot/dts/rk3288-vyasa.dts | 1 - > > > arch/arm/boot/dts/rv1108-elgin-r1.dts | 1 - > > > arch/arm/boot/dts/rv1108-evb.dts | 1 - > > > arch/arm64/boot/dts/rockchip/px30-evb.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3328-a1.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 1 - > > > .../arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 1 - > > > .../arm64/boot/dts/rockchip/rk3328-rock64.dts | 1 - > > > .../boot/dts/rockchip/rk3368-geekbox.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi | 1 - > > > .../boot/dts/rockchip/rk3368-px5-evb.dts | 1 - > > > .../boot/dts/rockchip/rk3399-firefly.dts | 1 - > > > .../boot/dts/rockchip/rk3399-hugsun-x99.dts | 1 - > > > .../boot/dts/rockchip/rk3399-khadas-edge.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-leez-p710.dts | 1 - > > > .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-orangepi.dts | 1 - > > > arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-roc-pc.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-rock-pi-4.dts | 1 - > > > .../boot/dts/rockchip/rk3399-rock960.dtsi | 1 - > > > .../boot/dts/rockchip/rk3399-rockpro64.dts | 1 - > > > .../boot/dts/rockchip/rk3399-sapphire.dtsi | 1 - > > > drivers/mfd/rk808.c | 144 +++++------------- > > > include/linux/mfd/rk808.h | 2 - > > > 32 files changed, 42 insertions(+), 134 deletions(-) > > > > > > > _______________________________________________ > > Linux-rockchip mailing list > > Linux-rockchip@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-rockchip > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-12-09 13:54 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-06 18:45 [RFCv1 0/8] RK3399 clean shutdown issue Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-06 18:45 ` [RFCv1 1/8] mfd: rk808: Refactor shutdown functions Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-16 11:11 ` Lee Jones 2019-12-16 11:11 ` Lee Jones 2019-12-06 18:45 ` [RFCv1 2/8] mfd: rk808: use syscore for RK805 PMIC shutdown Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-09 13:34 ` Robin Murphy 2019-12-09 13:34 ` Robin Murphy 2019-12-09 15:38 ` Anand Moon 2019-12-09 15:38 ` Anand Moon 2019-12-06 18:45 ` [RFCv1 3/8] mfd: rk808: use syscore for RK808 " Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-06 18:45 ` [RFCv1 4/8] mfd: rk808: use syscore for RK818 " Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-06 18:45 ` [RFCv1 5/8] mfd: rk808: cleanup unused function pointer Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-06 18:45 ` [RFCv1 6/8] mfd: rk808: use common syscore for all PMCI for clean shutdown Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-06 18:45 ` [RFCv1 7/8] arm64: rockchip: drop unused field from rk8xx i2c node Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-06 18:45 ` [RFCv1 8/8] arm: " Anand Moon 2019-12-06 18:45 ` Anand Moon 2019-12-06 22:32 ` [RFCv1 0/8] RK3399 clean shutdown issue Heiko Stuebner 2019-12-06 22:32 ` Heiko Stuebner 2019-12-07 5:07 ` Anand Moon 2019-12-07 5:07 ` Anand Moon 2019-12-07 11:45 ` Heiko Stuebner 2019-12-07 11:45 ` Heiko Stuebner 2019-12-09 13:29 ` Robin Murphy 2019-12-09 13:29 ` Robin Murphy 2019-12-09 13:37 ` Peter Geis 2019-12-09 13:37 ` Peter Geis 2019-12-09 13:53 ` Heiko Stübner [this message] 2019-12-09 13:53 ` Heiko Stübner 2019-12-09 13:58 ` Robin Murphy 2019-12-09 13:58 ` Robin Murphy 2019-12-09 14:51 ` Tobias Schramm 2019-12-09 14:51 ` Tobias Schramm 2019-12-09 14:56 ` Anand Moon 2019-12-09 14:56 ` Anand Moon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8087758.JvhXzBlCRf@diego \ --to=heiko@sntech.de \ --cc=d.schultz@phytec.de \ --cc=devicetree@vger.kernel.org \ --cc=jagan@amarulasolutions.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=linux.amoon@gmail.com \ --cc=manivannan.sadhasivam@linaro.org \ --cc=mark.rutland@arm.com \ --cc=pgwipeout@gmail.com \ --cc=robh+dt@kernel.org \ --cc=robin.murphy@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.