linux-kernel - Re: [PATCH] arm64: dts: imx8mm-kontron-n801x-som: do not allow to switch off buck2

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: <d618c505-43e6-01a7-4d2a-847dad33b43e@kontron.de>
Date:   Mon, 20 Sep 2021 09:31:20 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Heiko Thiery <heiko.thiery@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>
Cc:     devicetree@...r.kernel.org,
        Guido Günther <agx@...xcpu.org>,
        Fabio Estevam <festevam@...il.com>,
        Shengjiu Wang <shengjiu.wang@....com>,
        "Angus Ainslie (Purism)" <angus@...ea.ca>,
        linux-kernel@...r.kernel.org,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Joakim Zhang <qiangqing.zhang@....com>,
        Michael Walle <michael@...le.cc>,
        Rob Herring <robh+dt@...nel.org>,
        NXP Linux Team <linux-imx@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm64: dts: imx8mm-kontron-n801x-som: do not allow to
 switch off buck2

On 17.09.21 18:10, Heiko Thiery wrote:
> Hi Lucas,
> 
> Am Fr., 17. Sept. 2021 um 13:44 Uhr schrieb Lucas Stach
> <l.stach@...gutronix.de>:
>>
>> Am Freitag, dem 17.09.2021 um 09:28 +0200 schrieb Heiko Thiery:
>>> Hi Frieder,
>>>
>>> Am Mi., 15. Sept. 2021 um 14:09 Uhr schrieb Frieder Schrempf
>>> <frieder.schrempf@...tron.de>:
>>>>
>>>> On 15.09.21 14:05, Michael Walle wrote:
>>>>> Am 2021-09-15 14:03, schrieb Heiko Thiery:
>>>>>> The buck2 output of the PMIC is the VDD core voltage of the cpu.
>>>>>> Switching off this will poweroff the CPU. Add the 'regulator-always-on'
>>>>>> property to avoid this.
>>>>>
>>>>> Mh, have this ever worked? Is there a commit which introduced a regression?
>>>>
>>>> Yes, this did work before, even without 'regulator-always-on'. I
>>>> currently don't understand why this is needed. The regulator is
>>>> referenced in the CPU nodes as 'cpu-supply'. This should be enough to
>>>> not disable it as long as the CPU is up.
>>>
>>> I rechecked that with 5.11, 5.10 and 5.9 and I see on all of them the
>>> same issue:
>>>
>>> [ 31.716031] vdd-5v: disabling
>>> [ 31.719032] rst-usb-eth2: disabling
>>> [ 31.722553] buck2: disabling
>>>
>>> While on that I tried to compare with other boards and see that they
>>> also have the cpu-voltage marked as "regulator-always-on". The only
>>> exception in dts/freescale is in imx8mq-librem5-devkit.dts [1] that
>>> has not set this property.
>>>
>>> I agree with you and don't understand why this is happening. Has
>>> anyone else an explanation?
>>>
>>> [1] https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Farch%2Farm64%2Fboot%2Fdts%2Ffreescale%2Fimx8mq-librem5-devkit.dts%23L319&amp;data=04%7C01%7Cfrieder.schrempf%40kontron.de%7Cce9d266ad78a4d06721008d979f5aeed%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637674918380815550%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=PsTKX4MXGwvvP6WxmQ1OWc8e32YI6Nsu%2FEkcNR4V8is%3D&amp;reserved=0
>>>
>> Maybe your kernel config is missing the cpufreq driver, so you don't
>> have a consumer of the regulator?
>>
>> Marking the regulator as always-on seems like the right thing to do,
>> you don't want to depend on a consumer showing up to make sure that
>> your CPU voltage isn't cut...
> 
> shouldn't it be that the node cpu-supply here is a consumer of the
> referenced voltage?

Yes, but as Michael and Lucas noted, the consumer is only active if the
cpufreq driver is loaded and we don't want to depend on this. In my
config I always had this compiled into the kernel so I didn't notice
that the always-on property is missing.

I'm not sure if shutting down the regulator is allowed to save power in
suspend, but that's something we could tackle later, for now:

Reviewed-by: Frieder Schrempf <frieder.schrempf@...tron.de>

Thanks Heiko for investigating and Michael and Lucas for helping!