[PATCH 00/18] ARM: use const and __initconst for smp_operations

[PATCH 00/18] ARM: use const and __initconst for smp_operations

[Masahiro Yamada]

Currently, SoC code can not add const qualifier to smp_operations
structures although they are never over-written.

01/18 and 02/18 add small changes to the ARM core to fix that.
The rest of this series replace "__initdata" with "const ... __initconst"
for each of SoC code.

I split this series into per-SoC so that each sub-arch maintainer
can easily give their Acked-by.  (Is this better?)

Russell, Olof, and Arnd:

How should this series be applied (if it looks good)?
The first two are ARM-tree wide and looks like in the field of Russell.
The rest are highly SoC-related.



Masahiro Yamada (18):
  ARM: add const qualifier to the argument of smp_set_ops()
  ARM: add const qualifier to smp_operations member in structures
  ARM: alpine: use const and __initconst for smp_operations
  ARM: axxia: use const and __initconst for smp_operations
  ARM: BCM: use const and __initconst for smp_operations
  ARM: berlin: use const and __initconst for smp_operations
  ARM: EXYNOS: use const and __initconst for smp_operations
  ARM: hisi: do not export smp_operations structures
  ARM: hisi: use const and __initconst for smp_operations
  ARM: mvebu: use const and __initconst for smp_operations
  ARM: qcom: use const and __initconst for smp_operations
  ARM: rockchip: use const and __initconst for smp_operations
  ARM: socfpga: use const and __initconst for smp_operations
  ARM: sunxi: use const and __initconst for smp_operations
  ARM: uniphier: use const and __initconst for smp_operations
  ARM: zx: use const and __initconst for smp_operations
  ARM: zynq: use const and __initconst for smp_operations
  ARM: mcpm: use const and __initconst for smp_operations

 arch/arm/common/mcpm_platsmp.c      | 2 +-
 arch/arm/include/asm/mach/arch.h    | 2 +-
 arch/arm/include/asm/smp.h          | 4 ++--
 arch/arm/kernel/smp.c               | 2 +-
 arch/arm/mach-alpine/platsmp.c      | 2 +-
 arch/arm/mach-axxia/platsmp.c       | 2 +-
 arch/arm/mach-bcm/bcm63xx_smp.c     | 2 +-
 arch/arm/mach-bcm/kona_smp.c        | 2 +-
 arch/arm/mach-bcm/platsmp-brcmstb.c | 2 +-
 arch/arm/mach-berlin/platsmp.c      | 2 +-
 arch/arm/mach-exynos/common.h       | 2 +-
 arch/arm/mach-exynos/platsmp.c      | 2 +-
 arch/arm/mach-hisi/core.h           | 3 ---
 arch/arm/mach-hisi/platsmp.c        | 6 +++---
 arch/arm/mach-mvebu/armada-370-xp.h | 2 +-
 arch/arm/mach-mvebu/platsmp-a9.c    | 4 ++--
 arch/arm/mach-mvebu/platsmp.c       | 2 +-
 arch/arm/mach-qcom/platsmp.c        | 6 +++---
 arch/arm/mach-rockchip/platsmp.c    | 2 +-
 arch/arm/mach-socfpga/platsmp.c     | 4 ++--
 arch/arm/mach-sunxi/platsmp.c       | 4 ++--
 arch/arm/mach-uniphier/platsmp.c    | 2 +-
 arch/arm/mach-zx/platsmp.c          | 2 +-
 arch/arm/mach-zynq/common.h         | 2 +-
 arch/arm/mach-zynq/platsmp.c        | 2 +-
 25 files changed, 32 insertions(+), 35 deletions(-)

-- 
1.9.1

[PATCH 11/18] ARM: qcom: use const and __initconst for smp_operations

[Masahiro Yamada]

The smp_operations structure is not over-written, so add const
qualifier and replace __initdata with __initconst.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 arch/arm/mach-qcom/platsmp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-qcom/platsmp.c b/arch/arm/mach-qcom/platsmp.c
index 5cde63a..11847cd 100644
--- a/arch/arm/mach-qcom/platsmp.c
+++ b/arch/arm/mach-qcom/platsmp.c
@@ -332,7 +332,7 @@ static void __init qcom_smp_prepare_cpus(unsigned int max_cpus)
 	}
 }
 
-static struct smp_operations smp_msm8660_ops __initdata = {
+static const struct smp_operations smp_msm8660_ops __initconst = {
 	.smp_prepare_cpus	= qcom_smp_prepare_cpus,
 	.smp_secondary_init	= qcom_secondary_init,
 	.smp_boot_secondary	= msm8660_boot_secondary,
@@ -342,7 +342,7 @@ static struct smp_operations smp_msm8660_ops __initdata = {
 };
 CPU_METHOD_OF_DECLARE(qcom_smp, "qcom,gcc-msm8660", &smp_msm8660_ops);
 
-static struct smp_operations qcom_smp_kpssv1_ops __initdata = {
+static const struct smp_operations qcom_smp_kpssv1_ops __initconst = {
 	.smp_prepare_cpus	= qcom_smp_prepare_cpus,
 	.smp_secondary_init	= qcom_secondary_init,
 	.smp_boot_secondary	= kpssv1_boot_secondary,
@@ -352,7 +352,7 @@ static struct smp_operations qcom_smp_kpssv1_ops __initdata = {
 };
 CPU_METHOD_OF_DECLARE(qcom_smp_kpssv1, "qcom,kpss-acc-v1", &qcom_smp_kpssv1_ops);
 
-static struct smp_operations qcom_smp_kpssv2_ops __initdata = {
+static const struct smp_operations qcom_smp_kpssv2_ops __initconst = {
 	.smp_prepare_cpus	= qcom_smp_prepare_cpus,
 	.smp_secondary_init	= qcom_secondary_init,
 	.smp_boot_secondary	= kpssv2_boot_secondary,
-- 
1.9.1

Re: [PATCH 11/18] ARM: qcom: use const and __initconst for smp_operations

[Andy Gross]

On Mon, Aug 24, 2015 at 01:36:11PM +0900, Masahiro Yamada wrote:
> The smp_operations structure is not over-written, so add const
> qualifier and replace __initdata with __initconst.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---

Thanks!

Reviewed-by: Andy Gross <agross@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations

[Olof Johansson]

On Sun, Aug 23, 2015 at 9:36 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Currently, SoC code can not add const qualifier to smp_operations
> structures although they are never over-written.
>
> 01/18 and 02/18 add small changes to the ARM core to fix that.
> The rest of this series replace "__initdata" with "const ... __initconst"
> for each of SoC code.
>
> I split this series into per-SoC so that each sub-arch maintainer
> can easily give their Acked-by.  (Is this better?)

When you split, chances are each sub-arch maintainer will apply
instead of ack. If that's what you want, that's fine.

> Russell, Olof, and Arnd:
>
> How should this series be applied (if it looks good)?
> The first two are ARM-tree wide and looks like in the field of Russell.
> The rest are highly SoC-related.

Easiest of all would probably be to get the sub-arch patches into one
release, then switch the prototypes and function definitions in the
next. If you switch prototypes first you'll get a bunch of warnings,
right?


-Olof

Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations

[Russell King - ARM Linux]

On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote:
> Easiest of all would probably be to get the sub-arch patches into one
> release, then switch the prototypes and function definitions in the
> next. If you switch prototypes first you'll get a bunch of warnings,
> right?

Wrong way around. :)

If you change the sub-arches to declare the smp operations as const,
and try and pass them into a function which doesn't take a const-pointer,
you'll get a warning.  The core bits need to go in first before the
sub-arch patches.

I think the series has limited value - it allows us to (a) check that a
small quantity of code doesn't write to these things, and (b) allows us
to move the SMP operations structure from __initdata to __initconstdata.
It's still going to end up in the init region which is read/write in any
case, and still gets thrown away.

Given where we are, I don't think we need to rush this in during the
last week before the merge window opens, even though it's trivial.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations

[Olof Johansson]

On Mon, Aug 24, 2015 at 2:21 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote:
>> Easiest of all would probably be to get the sub-arch patches into one
>> release, then switch the prototypes and function definitions in the
>> next. If you switch prototypes first you'll get a bunch of warnings,
>> right?
>
> Wrong way around. :)
>
> If you change the sub-arches to declare the smp operations as const,
> and try and pass them into a function which doesn't take a const-pointer,
> you'll get a warning.  The core bits need to go in first before the
> sub-arch patches.

Ah yes, my bad.

> I think the series has limited value - it allows us to (a) check that a
> small quantity of code doesn't write to these things, and (b) allows us
> to move the SMP operations structure from __initdata to __initconstdata.
> It's still going to end up in the init region which is read/write in any
> case, and still gets thrown away.
>
> Given where we are, I don't think we need to rush this in during the
> last week before the merge window opens, even though it's trivial.

Agreed. So if you pick it up for 4.4, we'll get the rest for 4.5.


-Olof

Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations

[Masahiro Yamada]

Hi Russell, Olof,

2015-08-25 6:44 GMT+09:00 Olof Johansson <olof@lixom.net>:
> On Mon, Aug 24, 2015 at 2:21 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote:
>>> Easiest of all would probably be to get the sub-arch patches into one
>>> release, then switch the prototypes and function definitions in the
>>> next. If you switch prototypes first you'll get a bunch of warnings,
>>> right?
>>
>> Wrong way around. :)
>>
>> If you change the sub-arches to declare the smp operations as const,
>> and try and pass them into a function which doesn't take a const-pointer,
>> you'll get a warning.  The core bits need to go in first before the
>> sub-arch patches.
>
> Ah yes, my bad.
>
>> I think the series has limited value - it allows us to (a) check that a
>> small quantity of code doesn't write to these things, and (b) allows us
>> to move the SMP operations structure from __initdata to __initconstdata.
>> It's still going to end up in the init region which is read/write in any
>> case, and still gets thrown away.
>>
>> Given where we are, I don't think we need to rush this in during the
>> last week before the merge window opens, even though it's trivial.
>
> Agreed. So if you pick it up for 4.4, we'll get the rest for 4.5.
>

OK.

I will put 01 and 02 to Russell's patch tracker
(after waiting for a bit more comments just in case).

I will do the rest later.





-- 
Best Regards
Masahiro Yamada