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:   Fri, 4 Aug 2023 10:54:36 +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/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.

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

> 
> Does the code work with both traditional suspend-to-ram and
> modern suspend-to-idle logic?


Yes, It can support suspend-to-ram and suspend-to-idle.

Thanks,
Yinbo