linux-kernel - Re: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm

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: <19feb595-e22a-4304-9b88-b5cb55949cd8@app.fastmail.com>
Date:   Mon, 14 Aug 2023 10:19:51 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Yinbo Zhu" <zhuyinbo@...ngson.cn>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        "Conor Dooley" <conor+dt@...nel.org>, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        soc@...nel.org, "Ulf Hansson" <ulf.hansson@...aro.org>
Cc:     "Jianmin Lv" <lvjianmin@...ngson.cn>, wanghongliang@...ngson.cn,
        "Liu Peibao" <liupeibao@...ngson.cn>,
        loongson-kernel@...ts.loongnix.cn, loongarch@...ts.linux.dev,
        "Liu Yun" <liuyun@...ngson.cn>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm

On Mon, Aug 14, 2023, at 09:57, Yinbo Zhu wrote:
> 在 2023/8/12 下午8:25, Arnd Bergmann 写道:
>> On Fri, Aug 4, 2023, at 04:54, Yinbo Zhu wrote:
>>> 在 2023/8/3 下午3:44, Arnd Bergmann 写道:
>>>> On Thu, Aug 3, 2023, at 08:37, Yinbo Zhu wrote:
>>>
>>>> Is this some SRAM that needs to execute the suspend logic
>>>> in order to shut down memory and cache controllers?
>>>
>>>
>>> Yes, The suspend-to-ram after into pmon firmware code and set
>>> self-refresh mode in memory controller and ensure that memory data is
>>> not lost then shut down memory controller.
>> 
>> I'm sorry I missed your reply earlier, getting back to the
>> thread now. So it's clear that this code needs to run in a
>> special memory from your description, but I'm still trying
>> to understand the details better.
>> 
>> I found https://github.com/loongson-community/pmon source
>> code, and a reference to its origin at LSI Logic at
>> https://www.linux-mips.org/wiki/PMON but otherwise have
>> no idea about what this actually is, or how it relates
>> to your UEFI firmware. Did you add UEFI support to PMON,
>> or do you use it as a first stage loader that loads
>> the actual UEFI implementation (EDK2 or u-boot, I guess)?
>
>
> Pmon and uefi are two different firmware, and there is no connection
> between them.

It sounds like we still have problems with terminology.

I don't think categorizing UEFI as a firmware is correct,
it's the interface used by various firmware implementations
to load the operating system. As far as I understand,
loongarch currently mandates the use of UEFI in whichever
firmware is used, so if you have Pmon installed in ROM,
and Pmon does not itself implement UEFI, it would have
to load some other firmware such as u-boot in order to
load a kernel through the UEFI protocol, right?

Has the assumption that loongarch requires UEFI changed?

>>>> Or is
>>>> this a runtime firmware interface similar to how UEFI handles
>>>> its runtime services to keep the implementation out of
>>>> the kernel?
>>>
>>>
>>> No, The main cpu and other cpu will offline that after into firmware and
>>> finished Corresponding operations, the pmon firmware will not run.
>> 
>> I'm still trying to understand your explanations here.
>> You say that pmon no longer runs, but that seems to contradict
>> what you said earlier about branching into pmon firmware code
>> for suspend.
>
>
> It's not contradictory.  The suspend-to-ram is that from kernel goto to
> pmon firmware code, then pmon finished corresponding operations, which
> was to set self-refresh mode in memory controller, then memory HW will
> maintain its own data and no longer requires software processing, pmon
> firmware will not run.

That is what I mean with a "runtime firmware interface", i.e. you
jump into firmware in order to request services from it. Clearly the
firmware itself does not run while the OS is executing code, but it is
still there and waiting to be called here, which is similar to
things like UEFI runtime services, PowerPC RTAS, Arm EL3/trustzone
based firmware or x86 SMM firmware, except that this is much less
formalized and only consists of an entry point with undocument
calling conventions.

>> Is this executing directly from ROM then?
>
> Yes.

Is this the only runtime call into the firmware, or are there
others that are either already called from mainline kernels
or in your downsteam implementation?

How do you ensure that the DTB matches the actual ROM code
after rebuilding Pmon? Does Pmon itself fill that field with
the correct address, or do you rely on it being a hardcoded
constant?

     Arnd