[PATCH v1 1/1] riscv: sbi: Introduce system suspend support

Conor Dooley conor at kernel.org
Thu Oct 12 06:32:46 PDT 2023


On Thu, Oct 12, 2023 at 02:30:02PM +0100, Conor Dooley wrote:
> Yo,
> 
> On Thu, Oct 12, 2023 at 09:21:50AM +0200, Andrew Jones wrote:
> > When the SUSP SBI extension is present it implies that the standard
> > "suspend to RAM" type is available. Wire it up to the generic
> > platform suspend support, also applying the already present support
> > for non-retentive CPU suspend. When the kernel is built with
> > CONFIG_SUSPEND, one can do 'echo mem > /sys/power/state' to suspend.
> > Resumption will occur when a platform-specific wake-up event arrives.
> > 
> > Signed-off-by: Andrew Jones <ajones at ventanamicro.com>
> 
> > +static int __init sbi_system_suspend_init(void)
> > +{
> > +	if (!sbi_spec_is_0_1() && sbi_probe_extension(SBI_EXT_SUSP) > 0) {
> 
> Random thought I had reading this, was that it'll be possible to have a
> firmware that implements SBI < 2.0 that provides the SUSP extension.
> FWIW, I don't think that that is problematic, but maybe I am missing
> something that would make it so.

Hmm, next patch I look at is from Anup's debug console series, and he
does check that the SBI implementation is at least version 2.0 before
probing for the extension. We should probably have the same policy
everywhere.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20231012/9843e414/attachment.sig>


More information about the linux-riscv mailing list