[PATCH] firmware: arm_scmi: pm: use SIMPLE_DEV_PM_OPS for pm struct

[PATCH] firmware: arm_scmi: pm: use SIMPLE_DEV_PM_OPS for pm struct

[Li Jun]

use SIMPLE_DEV_PM_OPS for scmi_dev_pm_ops,and add the value of
.freeze .thaw .poweroff .restore.if these address are null, may cause
error in s4.

Signed-off-by: Li Jun <lijun01@kylinos.cn>
---
 drivers/firmware/arm_scmi/bus.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index e060edbe7e83..4ab32f1eed4f 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -13,6 +13,7 @@
 #include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/device.h>
+#include <linux/pm.h>
 
 #include "common.h"
 
@@ -361,10 +362,7 @@ static int scmi_pm_resume(struct device *dev)
 	return 0;
 }
 
-static const struct dev_pm_ops scmi_dev_pm_ops = {
-	.suspend = pm_sleep_ptr(scmi_pm_suspend),
-	.resume = pm_sleep_ptr(scmi_pm_resume),
-};
+static SIMPLE_DEV_PM_OPS(scmi_dev_pm_ops, scmi_pm_suspend, scmi_pm_resume);
 
 const struct bus_type scmi_bus_type = {
 	.name =	"scmi_protocol",
-- 
2.25.1

Re: [PATCH] firmware: arm_scmi: pm: use SIMPLE_DEV_PM_OPS for pm struct

[Kohei Enju]

On 08/19 14:15, Li Jun wrote:
> use SIMPLE_DEV_PM_OPS for scmi_dev_pm_ops,and add the value of
> .freeze .thaw .poweroff .restore.if these address are null, may cause
> error in s4.

Could you elaborate on the S4 error you observed?

Also, the concerns raised by Sashiko look valid to me.

Re: [PATCH] firmware: arm_scmi: pm: use SIMPLE_DEV_PM_OPS for pm struct

[Jonathan Cameron]

On Wed, 19 Aug 2026 14:15:30 +0800
Li Jun <lijun01@kylinos.cn> wrote:

> use SIMPLE_DEV_PM_OPS for scmi_dev_pm_ops,and add the value of
> .freeze .thaw .poweroff .restore.if these address are null, may cause
> error in s4.
> 
Read the note immediately above the definition of SIMPLE_DEV_PM_OPS

That is slowly going away so I doubt we want to introduce more instances of
it.  So as part of this change, flip to DEFINE_SIMPLE_DEV_PM_OPS()
and make the other changes necessary for that to work correctly

Jonathan


> Signed-off-by: Li Jun <lijun01@kylinos.cn>
> ---
>  drivers/firmware/arm_scmi/bus.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> index e060edbe7e83..4ab32f1eed4f 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -13,6 +13,7 @@
>  #include <linux/kernel.h>
>  #include <linux/slab.h>
>  #include <linux/device.h>
> +#include <linux/pm.h>
>  
>  #include "common.h"
>  
> @@ -361,10 +362,7 @@ static int scmi_pm_resume(struct device *dev)
>  	return 0;
>  }
>  
> -static const struct dev_pm_ops scmi_dev_pm_ops = {
> -	.suspend = pm_sleep_ptr(scmi_pm_suspend),
> -	.resume = pm_sleep_ptr(scmi_pm_resume),
> -};
> +static SIMPLE_DEV_PM_OPS(scmi_dev_pm_ops, scmi_pm_suspend, scmi_pm_resume);
>  
>  const struct bus_type scmi_bus_type = {
>  	.name =	"scmi_protocol",

Re: [PATCH] firmware: arm_scmi: pm: use SIMPLE_DEV_PM_OPS for pm struct

[lijun]

These are the patches where I first discovered this issue
after execute s4, the spi error,
[ 1104.754246][ 4] [    T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110
[ 1104.761503][ 4] [    T1] spi_master spi1: failed to transfer one message from queue
[ 1104.769201][ 4] [    T1] spi_master spi1: noqueue transfer failed
[ 1104.776344][ 4] [    T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110
[ 1104.783609][ 4] [    T1] spi_master spi1: failed to transfer one message from queue
[ 1104.791308][ 4] [    T1] spi_master spi1: noqueue transfer failed
[ 1104.797446][ 4] [    T1] gttadd tpm_chip_start1 ret = -110
and in s4 the loongson_spi_resume&suspend are not
called at all. use SIMPLE_DEV_PM_OPS() add .freeze .poweroff
.thaw .restore, after s4 the spi communication is normal.

Signed-off-by: Li Jun<lijun01@kylinos.cn>
---
  drivers/spi/spi-loongson-core.c | 6 ++----
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-loongson-core.c b/drivers/spi/spi-loongson-core.c
index 30b6a7176ce9..34982c8d85a4 100644
--- a/drivers/spi/spi-loongson-core.c
+++ b/drivers/spi/spi-loongson-core.c
@@ -269,10 +269,8 @@ static int loongson_spi_resume(struct device *dev)
  	return 0;
  }
  
-const struct dev_pm_ops loongson_spi_dev_pm_ops = {
-	.suspend = loongson_spi_suspend,
-	.resume = loongson_spi_resume,
-};
+SIMPLE_DEV_PM_OPS(loongson_spi_dev_pm_ops, loongson_spi_suspend, loongson_spi_resume);
+
  EXPORT_SYMBOL_NS_GPL(loongson_spi_dev_pm_ops, "SPI_LOONGSON_CORE");
  
  MODULE_DESCRIPTION("Loongson SPI core driver");


[  249.388986][ 7] [T12151] loongson-spi-pci 0000:00:16.0: PM: calling pci_pm_poweroff+0x0/0x134 @ 12151, parent: pci0000:00
[  249.388992][ 7] [T12151] gttadd loongson_spi_suspend0.0
[  249.388993][ 7] [T12148] pcieport 0000:00:0d.0: PM: pci_pm_poweroff+0x0/0x134 returned 0 after 1 usecs

[  241.681971][ 2] [T12058] loongson-spi PRP0001:00: PM: calling acpi_subsys_freeze+0x0/0x34 @ 12058, parent: pci0000:00
[  241.681974][ 2] [T12058] gttadd loongson_spi_suspend0.0
[  241.681976][ 2] [T12058] loongson-spi PRP0001:00: PM: acpi_subsys_freeze+0x0/0x34 returned 0 after 2 usecs

[  244.535396][ 5] [T12082] loongson-spi-pci 0000:00:16.0: PM: calling pci_pm_thaw+0x0/0xd4 @ 12082, parent: pci0000:00
[  244.535399][ 6] [T12082] gttadd loongson_spi_resume0.0
[  244.535408][ 3] [T12082] loongson-spi-pci 0000:00:16.0: PM: pci_pm_thaw+0x0/0xd4 returned 0 after 8 usecs

[  245.213317][ 4] [ T2766] loongson-spi-pci 0000:00:16.0: PM: calling pci_pm_restore+0x0/0x12c @ 2766, parent: pci0000:00
[  245.213321][ 4] [ T2766] gttadd loongson_spi_resume0.0
[  245.213327][ 7] [ T2766] loongson-spi-pci 0000:00:16.0: PM: pci_pm_restore+0x0/0x12c returned 0 after 6 usecs


2026/8/19 15:55, Kohei Enju :
> On 08/19 14:15, Li Jun wrote:
>> use SIMPLE_DEV_PM_OPS for scmi_dev_pm_ops,and add the value of
>> .freeze .thaw .poweroff .restore.if these address are null, may cause
>> error in s4.
> Could you elaborate on the S4 error you observed?
>
> Also, the concerns raised by Sashiko look valid to me.