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: <193f9138-57e0-4d4b-8225-54d38be9bfbc@app.fastmail.com>
Date:   Thu, 03 Aug 2023 09:44:52 +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 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?
Is this some SRAM that needs to execute the suspend logic
in order to shut down memory and cache controllers? Or is
this a runtime firmware interface similar to how UEFI handles
its runtime services to keep the implementation out of
the kernel?

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

      Arnd