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: <0616585d-1459-b6ef-375b-890426004e01@loongson.cn>
Date:   Mon, 14 Aug 2023 15:57:17 +0800
From:   Yinbo Zhu <zhuyinbo@...ngson.cn>
To:     Arnd Bergmann <arnd@...db.de>, 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>,
        zhuyinbo@...ngson.cn
Subject: Re: [PATCH v6 1/2] soc: dt-bindings: add loongson-2 pm



在 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:
>>>
>>>> +  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)?


Pmon and uefi are two different firmware, and there is no connection
between them.

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

> 
> Is this executing directly from ROM then?


Yes.

Thanks,
Yinbo