Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
On Tue 23 Mar 13:27 CDT 2021, Elliot Berman wrote: > On 3/22/2021 8:36 PM, Stephen Boyd wrote: > > Quoting Bjorn Andersson (2021-03-07 09:42:45) > > > On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote: > > > > > > > Quoting Elliot Berman (2021-03-05 10:18:09) > > > > > On 3/3/2021 10:14 PM, Stephen Boyd wrote: > > > > > > Quoting Elliot Berman (2021-03-03 19:35:08) > > > > > > > > > > > +desc.args[0] = flags; > > > > > > +desc.args[1] = virt_to_phys(entry); > > > > > > + > > > > > > +return scm_legacy_call_atomic(NULL, , NULL); > > > > > > +} > > > > > > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr); > > > > > > > > > > This should still be qcom_scm_call. > > > > > > > > You mean s/scm_legacy_call_atomic/qcom_scm_call/ right? > > > > > > > > I don't really want to resend the rest of the patches if this last one > > > > is the only one that needs an update. This was a semi-RFC anyway so > > > > maybe it's fine if the first 5 patches get merged and then I can resend > > > > this one? Otherwise I will resend this again next week or so with less > > > > diff for this patch. > > > > > > I'm fine with merging the first 5, but was hoping that Elliot could > > > provide either a "Reviewed-by" or at least an "Acked-by" on these. > > > > > > > I'll take the silence as I should resend the whole series? > > > > I thought Bjorn was accepting the first 5 already, my apologies. > > Patches 1-5: > Acked-by: Elliot Berman Thanks Elliot. I'll pick up the first 5, so please skip these in your repost, Stephen. Regards, Bjorn
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
On 3/22/2021 8:36 PM, Stephen Boyd wrote: Quoting Bjorn Andersson (2021-03-07 09:42:45) On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote: Quoting Elliot Berman (2021-03-05 10:18:09) On 3/3/2021 10:14 PM, Stephen Boyd wrote: Quoting Elliot Berman (2021-03-03 19:35:08) > +desc.args[0] = flags; > +desc.args[1] = virt_to_phys(entry); > + > +return scm_legacy_call_atomic(NULL, , NULL); > +} > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr); This should still be qcom_scm_call. You mean s/scm_legacy_call_atomic/qcom_scm_call/ right? I don't really want to resend the rest of the patches if this last one is the only one that needs an update. This was a semi-RFC anyway so maybe it's fine if the first 5 patches get merged and then I can resend this one? Otherwise I will resend this again next week or so with less diff for this patch. I'm fine with merging the first 5, but was hoping that Elliot could provide either a "Reviewed-by" or at least an "Acked-by" on these. I'll take the silence as I should resend the whole series? I thought Bjorn was accepting the first 5 already, my apologies. Patches 1-5: Acked-by: Elliot Berman
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
Quoting Bjorn Andersson (2021-03-07 09:42:45) > On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote: > > > Quoting Elliot Berman (2021-03-05 10:18:09) > > > On 3/3/2021 10:14 PM, Stephen Boyd wrote: > > > > Quoting Elliot Berman (2021-03-03 19:35:08) > > > > > > > +desc.args[0] = flags; > > > > +desc.args[1] = virt_to_phys(entry); > > > > + > > > > +return scm_legacy_call_atomic(NULL, , NULL); > > > > +} > > > > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr); > > > > > > This should still be qcom_scm_call. > > > > You mean s/scm_legacy_call_atomic/qcom_scm_call/ right? > > > > I don't really want to resend the rest of the patches if this last one > > is the only one that needs an update. This was a semi-RFC anyway so > > maybe it's fine if the first 5 patches get merged and then I can resend > > this one? Otherwise I will resend this again next week or so with less > > diff for this patch. > > I'm fine with merging the first 5, but was hoping that Elliot could > provide either a "Reviewed-by" or at least an "Acked-by" on these. > I'll take the silence as I should resend the whole series?
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote:
> Quoting Elliot Berman (2021-03-05 10:18:09)
> > On 3/3/2021 10:14 PM, Stephen Boyd wrote:
> > > Quoting Elliot Berman (2021-03-03 19:35:08)
> > >>
> > >> On 2/23/2021 1:45 PM, Stephen Boyd wrote:
> > >>> These scm calls are never used outside of legacy ARMv7 based platforms.
> > >>> That's because PSCI, mandated on arm64, implements them for modern SoCs
> > >>> via the PSCI spec. Let's move them to the legacy file and only compile
> > >>> the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
> > >>> stubs and fail the calls. This saves a little bit of space in an
> > >>> arm64 allmodconfig >
> > >>>$ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
> > >>>add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
> > >>>Function old new delta
> > >>>__qcom_scm_set_dload_mode.constprop 312 452+140
> > >>>qcom_scm_qsmmu500_wait_safe_toggle 288 416+128
> > >>>qcom_scm_io_writel 288 408+120
> > >>>qcom_scm_io_readl376 492+116
> > >>>__param_str_download_mode 23 28 +5
> > >>>__warned43274326 -1
> > >>>qcom_iommu_init 272 268 -4
> > >>>e843419@0b3f_00010432_324 8 - -8
> > >>>qcom_scm_call228 208 -20
> > >>>CSWTCH 59255877 -48
> > >>>_sub_I_65535_1163100 163040 -60
> > >>>_sub_D_65535_0163100 163040 -60
> > >>>qcom_scm_wb 64 - -64
> > >>>qcom_scm_lock320 160-160
> > >>>qcom_scm_call_atomic 212 --212
> > >>>qcom_scm_cpu_power_down 308 --308
> > >>>scm_legacy_call_atomic 520 --520
> > >>>qcom_scm_set_warm_boot_addr 720 --720
> > >>>qcom_scm_set_cold_boot_addr 728 --728
> > >>>scm_legacy_call 1492 - -1492
> > >>>Total: Before=66737642, After=66733746, chg -0.01%
> > >>>
> > >>> Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
> > >>> legacy conventions") didn't mention any motivating factors for keeping
> > >>> the legacy code around on arm64 kernels, i.e. presumably that commit
> > >>> wasn't trying to support these legacy APIs on arm64 kernels.
> > >>
> > >> There are arm targets which support SMCCC convention and use some of
> > >> these removed functions. Can these functions be kept in qcom-scm.c and
> > >> wrapped with #if IS_ENABLED(CONFIG_ARM)?
> > >>
> > >
> > > It can be wrapped in qcom-scm.c, but why? It's all the same object file
> > > so I'm lost why it matters. I suppose it would make it so the struct
> > > doesn't have to be moved around and declared in the header? Any other
> > > reason? I moved it to the legacy file so that it was very obvious that
> > > the API wasn't to be used except for "legacy" platforms that don't use
> > > PSCI.
> > >
> >
> > There are "legacy" arm platforms that use the SMCCC (scm_smc_call) and
> > use the qcom_scm_set_{warm,cold}_boot_addr and qcom_scm_cpu_power_down
> > functions.
>
> Ah ok. Weird, but I get it. Amazing that SMCCC was adopted there but
> PSCI wasn't!
>
> >
> > > +desc.args[0] = flags;
> > > +desc.args[1] = virt_to_phys(entry);
> > > +
> > > +return scm_legacy_call_atomic(NULL, , NULL);
> > > +}
> > > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr);
> >
> > This should still be qcom_scm_call.
>
> You mean s/scm_legacy_call_atomic/qcom_scm_call/ right?
>
> I don't really want to resend the rest of the patches if this last one
> is the only one that needs an update. This was a semi-RFC anyway so
> maybe it's fine if the first 5 patches get merged and then I can resend
> this one? Otherwise I will resend this again next week or so with less
> diff for this patch.
I'm fine with merging the first 5, but was hoping that Elliot could
provide either a "Reviewed-by" or at least an "Acked-by" on these.
Regards,
Bjorn
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
Quoting Elliot Berman (2021-03-05 10:18:09)
> On 3/3/2021 10:14 PM, Stephen Boyd wrote:
> > Quoting Elliot Berman (2021-03-03 19:35:08)
> >>
> >> On 2/23/2021 1:45 PM, Stephen Boyd wrote:
> >>> These scm calls are never used outside of legacy ARMv7 based platforms.
> >>> That's because PSCI, mandated on arm64, implements them for modern SoCs
> >>> via the PSCI spec. Let's move them to the legacy file and only compile
> >>> the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
> >>> stubs and fail the calls. This saves a little bit of space in an
> >>> arm64 allmodconfig >
> >>>$ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
> >>>add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
> >>>Function old new delta
> >>>__qcom_scm_set_dload_mode.constprop 312 452+140
> >>>qcom_scm_qsmmu500_wait_safe_toggle 288 416+128
> >>>qcom_scm_io_writel 288 408+120
> >>>qcom_scm_io_readl376 492+116
> >>>__param_str_download_mode 23 28 +5
> >>>__warned43274326 -1
> >>>qcom_iommu_init 272 268 -4
> >>>e843419@0b3f_00010432_324 8 - -8
> >>>qcom_scm_call228 208 -20
> >>>CSWTCH 59255877 -48
> >>>_sub_I_65535_1163100 163040 -60
> >>>_sub_D_65535_0163100 163040 -60
> >>>qcom_scm_wb 64 - -64
> >>>qcom_scm_lock320 160-160
> >>>qcom_scm_call_atomic 212 --212
> >>>qcom_scm_cpu_power_down 308 --308
> >>>scm_legacy_call_atomic 520 --520
> >>>qcom_scm_set_warm_boot_addr 720 --720
> >>>qcom_scm_set_cold_boot_addr 728 --728
> >>>scm_legacy_call 1492 - -1492
> >>>Total: Before=66737642, After=66733746, chg -0.01%
> >>>
> >>> Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
> >>> legacy conventions") didn't mention any motivating factors for keeping
> >>> the legacy code around on arm64 kernels, i.e. presumably that commit
> >>> wasn't trying to support these legacy APIs on arm64 kernels.
> >>
> >> There are arm targets which support SMCCC convention and use some of
> >> these removed functions. Can these functions be kept in qcom-scm.c and
> >> wrapped with #if IS_ENABLED(CONFIG_ARM)?
> >>
> >
> > It can be wrapped in qcom-scm.c, but why? It's all the same object file
> > so I'm lost why it matters. I suppose it would make it so the struct
> > doesn't have to be moved around and declared in the header? Any other
> > reason? I moved it to the legacy file so that it was very obvious that
> > the API wasn't to be used except for "legacy" platforms that don't use
> > PSCI.
> >
>
> There are "legacy" arm platforms that use the SMCCC (scm_smc_call) and
> use the qcom_scm_set_{warm,cold}_boot_addr and qcom_scm_cpu_power_down
> functions.
Ah ok. Weird, but I get it. Amazing that SMCCC was adopted there but
PSCI wasn't!
>
> > +desc.args[0] = flags;
> > +desc.args[1] = virt_to_phys(entry);
> > +
> > +return scm_legacy_call_atomic(NULL, , NULL);
> > +}
> > +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr);
>
> This should still be qcom_scm_call.
You mean s/scm_legacy_call_atomic/qcom_scm_call/ right?
I don't really want to resend the rest of the patches if this last one
is the only one that needs an update. This was a semi-RFC anyway so
maybe it's fine if the first 5 patches get merged and then I can resend
this one? Otherwise I will resend this again next week or so with less
diff for this patch.
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
On 3/3/2021 10:14 PM, Stephen Boyd wrote:
Quoting Elliot Berman (2021-03-03 19:35:08)
On 2/23/2021 1:45 PM, Stephen Boyd wrote:
These scm calls are never used outside of legacy ARMv7 based platforms.
That's because PSCI, mandated on arm64, implements them for modern SoCs
via the PSCI spec. Let's move them to the legacy file and only compile
the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
stubs and fail the calls. This saves a little bit of space in an
arm64 allmodconfig >
$ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
Function old new delta
__qcom_scm_set_dload_mode.constprop 312 452+140
qcom_scm_qsmmu500_wait_safe_toggle 288 416+128
qcom_scm_io_writel 288 408+120
qcom_scm_io_readl376 492+116
__param_str_download_mode 23 28 +5
__warned43274326 -1
qcom_iommu_init 272 268 -4
e843419@0b3f_00010432_324 8 - -8
qcom_scm_call228 208 -20
CSWTCH 59255877 -48
_sub_I_65535_1163100 163040 -60
_sub_D_65535_0163100 163040 -60
qcom_scm_wb 64 - -64
qcom_scm_lock320 160-160
qcom_scm_call_atomic 212 --212
qcom_scm_cpu_power_down 308 --308
scm_legacy_call_atomic 520 --520
qcom_scm_set_warm_boot_addr 720 --720
qcom_scm_set_cold_boot_addr 728 --728
scm_legacy_call 1492 - -1492
Total: Before=66737642, After=66733746, chg -0.01%
Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
legacy conventions") didn't mention any motivating factors for keeping
the legacy code around on arm64 kernels, i.e. presumably that commit
wasn't trying to support these legacy APIs on arm64 kernels.
There are arm targets which support SMCCC convention and use some of
these removed functions. Can these functions be kept in qcom-scm.c and
wrapped with #if IS_ENABLED(CONFIG_ARM)?
It can be wrapped in qcom-scm.c, but why? It's all the same object file
so I'm lost why it matters. I suppose it would make it so the struct
doesn't have to be moved around and declared in the header? Any other
reason? I moved it to the legacy file so that it was very obvious that
the API wasn't to be used except for "legacy" platforms that don't use
PSCI.
There are "legacy" arm platforms that use the SMCCC (scm_smc_call) and
use the qcom_scm_set_{warm,cold}_boot_addr and qcom_scm_cpu_power_down
functions.
> + desc.args[0] = flags;
> + desc.args[1] = virt_to_phys(entry);
> +
> + return scm_legacy_call_atomic(NULL, , NULL);
> +}
> +EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr);
This should still be qcom_scm_call.
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
Quoting Elliot Berman (2021-03-03 19:35:08)
>
> On 2/23/2021 1:45 PM, Stephen Boyd wrote:
> > These scm calls are never used outside of legacy ARMv7 based platforms.
> > That's because PSCI, mandated on arm64, implements them for modern SoCs
> > via the PSCI spec. Let's move them to the legacy file and only compile
> > the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
> > stubs and fail the calls. This saves a little bit of space in an
> > arm64 allmodconfig >
> > $ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
> > add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
> > Function old new delta
> > __qcom_scm_set_dload_mode.constprop 312 452+140
> > qcom_scm_qsmmu500_wait_safe_toggle 288 416+128
> > qcom_scm_io_writel 288 408+120
> > qcom_scm_io_readl376 492+116
> > __param_str_download_mode 23 28 +5
> > __warned43274326 -1
> > qcom_iommu_init 272 268 -4
> > e843419@0b3f_00010432_324 8 - -8
> > qcom_scm_call228 208 -20
> > CSWTCH 59255877 -48
> > _sub_I_65535_1163100 163040 -60
> > _sub_D_65535_0163100 163040 -60
> > qcom_scm_wb 64 - -64
> > qcom_scm_lock320 160-160
> > qcom_scm_call_atomic 212 --212
> > qcom_scm_cpu_power_down 308 --308
> > scm_legacy_call_atomic 520 --520
> > qcom_scm_set_warm_boot_addr 720 --720
> > qcom_scm_set_cold_boot_addr 728 --728
> > scm_legacy_call 1492 - -1492
> > Total: Before=66737642, After=66733746, chg -0.01%
> >
> > Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
> > legacy conventions") didn't mention any motivating factors for keeping
> > the legacy code around on arm64 kernels, i.e. presumably that commit
> > wasn't trying to support these legacy APIs on arm64 kernels.
>
> There are arm targets which support SMCCC convention and use some of
> these removed functions. Can these functions be kept in qcom-scm.c and
> wrapped with #if IS_ENABLED(CONFIG_ARM)?
>
It can be wrapped in qcom-scm.c, but why? It's all the same object file
so I'm lost why it matters. I suppose it would make it so the struct
doesn't have to be moved around and declared in the header? Any other
reason? I moved it to the legacy file so that it was very obvious that
the API wasn't to be used except for "legacy" platforms that don't use
PSCI.
Re: [PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
On 2/23/2021 1:45 PM, Stephen Boyd wrote:
These scm calls are never used outside of legacy ARMv7 based platforms.
That's because PSCI, mandated on arm64, implements them for modern SoCs
via the PSCI spec. Let's move them to the legacy file and only compile
the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
stubs and fail the calls. This saves a little bit of space in an
arm64 allmodconfig >
$ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
Function old new delta
__qcom_scm_set_dload_mode.constprop 312 452+140
qcom_scm_qsmmu500_wait_safe_toggle 288 416+128
qcom_scm_io_writel 288 408+120
qcom_scm_io_readl376 492+116
__param_str_download_mode 23 28 +5
__warned43274326 -1
qcom_iommu_init 272 268 -4
e843419@0b3f_00010432_324 8 - -8
qcom_scm_call228 208 -20
CSWTCH 59255877 -48
_sub_I_65535_1163100 163040 -60
_sub_D_65535_0163100 163040 -60
qcom_scm_wb 64 - -64
qcom_scm_lock320 160-160
qcom_scm_call_atomic 212 --212
qcom_scm_cpu_power_down 308 --308
scm_legacy_call_atomic 520 --520
qcom_scm_set_warm_boot_addr 720 --720
qcom_scm_set_cold_boot_addr 728 --728
scm_legacy_call 1492 - -1492
Total: Before=66737642, After=66733746, chg -0.01%
Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
legacy conventions") didn't mention any motivating factors for keeping
the legacy code around on arm64 kernels, i.e. presumably that commit
wasn't trying to support these legacy APIs on arm64 kernels.
There are arm targets which support SMCCC convention and use some of
these removed functions. Can these functions be kept in qcom-scm.c and
wrapped with #if IS_ENABLED(CONFIG_ARM)?
[PATCH 6/6] firmware: qcom_scm: Only compile legacy calls on ARM
These scm calls are never used outside of legacy ARMv7 based platforms.
That's because PSCI, mandated on arm64, implements them for modern SoCs
via the PSCI spec. Let's move them to the legacy file and only compile
the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
stubs and fail the calls. This saves a little bit of space in an
arm64 allmodconfig.
$ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
add/remove: 0/8 grow/shrink: 5/7 up/down: 509/-4405 (-3896)
Function old new delta
__qcom_scm_set_dload_mode.constprop 312 452+140
qcom_scm_qsmmu500_wait_safe_toggle 288 416+128
qcom_scm_io_writel 288 408+120
qcom_scm_io_readl376 492+116
__param_str_download_mode 23 28 +5
__warned43274326 -1
qcom_iommu_init 272 268 -4
e843419@0b3f_00010432_324 8 - -8
qcom_scm_call228 208 -20
CSWTCH 59255877 -48
_sub_I_65535_1163100 163040 -60
_sub_D_65535_0163100 163040 -60
qcom_scm_wb 64 - -64
qcom_scm_lock320 160-160
qcom_scm_call_atomic 212 --212
qcom_scm_cpu_power_down 308 --308
scm_legacy_call_atomic 520 --520
qcom_scm_set_warm_boot_addr 720 --720
qcom_scm_set_cold_boot_addr 728 --728
scm_legacy_call 1492 - -1492
Total: Before=66737642, After=66733746, chg -0.01%
Commit 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and
legacy conventions") didn't mention any motivating factors for keeping
the legacy code around on arm64 kernels, i.e. presumably that commit
wasn't trying to support these legacy APIs on arm64 kernels.
Cc: Elliot Berman
Cc: Brian Masney
Cc: Stephan Gerhold
Cc: Jeffrey Hugo
Cc: Douglas Anderson
Signed-off-by: Stephen Boyd
---
drivers/firmware/Makefile | 4 +-
drivers/firmware/qcom_scm-legacy.c | 133 ++
drivers/firmware/qcom_scm.c| 145 +
drivers/firmware/qcom_scm.h| 33 +++
include/linux/qcom_scm.h | 21 +++--
5 files changed, 183 insertions(+), 153 deletions(-)
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 5e013b6a3692..0b7b3a6c 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -17,7 +17,9 @@ obj-$(CONFIG_ISCSI_IBFT) += iscsi_ibft.o
obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o
obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
obj-$(CONFIG_FW_CFG_SYSFS) += qemu_fw_cfg.o
-obj-$(CONFIG_QCOM_SCM) += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
+obj-$(CONFIG_QCOM_SCM) += qcom_scm_objs.o
+qcom_scm_objs-$(CONFIG_ARM)+= qcom_scm-legacy.o
+qcom_scm_objs-$(CONFIG_QCOM_SCM) += qcom_scm.o qcom_scm-smc.o
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o
diff --git a/drivers/firmware/qcom_scm-legacy.c
b/drivers/firmware/qcom_scm-legacy.c
index 1829ba220576..d909fa2716bc 100644
--- a/drivers/firmware/qcom_scm-legacy.c
+++ b/drivers/firmware/qcom_scm-legacy.c
@@ -3,6 +3,7 @@
* Copyright (C) 2015 Linaro Ltd.
*/
+#include
#include
#include
#include
@@ -240,3 +241,135 @@ int scm_legacy_call_atomic(struct device *unused,
return smc_res.a0;
}
+
+#define QCOM_SCM_FLAG_COLDBOOT_CPU00x00
+#define QCOM_SCM_FLAG_COLDBOOT_CPU10x01
+#define QCOM_SCM_FLAG_COLDBOOT_CPU20x08
+#define QCOM_SCM_FLAG_COLDBOOT_CPU30x20
+
+#define QCOM_SCM_FLAG_WARMBOOT_CPU00x04
+#define QCOM_SCM_FLAG_WARMBOOT_CPU10x02
+#define QCOM_SCM_FLAG_WARMBOOT_CPU20x10
+#define QCOM_SCM_FLAG_WARMBOOT_CPU30x40
+
+struct qcom_scm_wb_entry {
+ int flag;
+ void *entry;
+};
+
+static struct qcom_scm_wb_entry qcom_scm_wb[] = {
+ { .flag = QCOM_SCM_FLAG_WARMBOOT_CPU0 },
+ { .flag = QCOM_SCM_FLAG_WARMBOOT_CPU1 },
+ { .flag = QCOM_SCM_FLAG_WARMBOOT_CPU2 },
+ { .flag = QCOM_SCM_FLAG_WARMBOOT_CPU3 },
+};
+
+/**
+ * qcom_scm_set_warm_boot_addr() - Set the warm boot address for cpus
+ * @entry: Entry point function for the cpus
+ * @cpus: The cpumask of cpus that will use the entry point
+ *
+ * Set the Linux entry point for the SCM to transfer control to when coming
+ * out of a power down. CPU power down may be executed on cpuidle or hotplug.
+ */
+int qcom_scm_set_warm_boot_addr(void *entry, const cpumask_t *cpus)
+{
+ int ret;
+
