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]

Date:   Sat, 12 Aug 2023 14:25:05 +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 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:
>> 
>>> +  loongson,suspend-address:
>>> +    $ref: /schemas/types.yaml#/definitions/uint64
>>> +    description:
>>> +      The "loongson,suspend-address" is a deep sleep state (Suspend To
>>> +      RAM) firmware entry address which was jumped from kernel and it's
>>> +      value was dependent on specific platform firmware code. In
>>> +      addition, the PM need according to it to indicate that current
>>> +      SoC whether support Suspend To RAM.
>>> +
>> 
>> I just commented on this in the driver patch, assuming this
>> was an MMIO address, but I'm even more confused now, since
>> we try hard to not rely on being able to just interface with
>> firmware like this.
>> 
>> If this is executable code, where does this actually reside?
>
>
> Pmon firmware code.
>
>> 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)?

>> 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.

Is this executing directly from ROM then?

       Arnd