[PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Will McVicker]

This is v2 of the series of patches that modularizes a number of core
ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
modularized all of the drivers that are removed from the ARCH_EXYNOS
series of "select XXX". This includes setting the following configs as
tristate:

 * COMMON_CLK_SAMSUNG
 * EXYNOS_ARM64_COMMON_CLK
 * PINCTRL_SAMSUNG
 * PINCTRL_EXYNOS
 * EXYNOS_PMU_ARM64
 * EXYNOS_PM_DOMAINS

Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
The reason for these new configs is because we are not able to easily
modularize the ARMv7 PMU driver due to built-in arch dependencies on
pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
the ARM and ARM64 portions into two separate configs.

Overall, these drivers didn't require much refactoring and converted to
modules relatively easily. However, due to my lack of exynos hardware, I
was not able to boot test these changes. I'm mostly concerned about the
CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
requesting help for testing these changes on the respective hardware.

Lastly, this series is based off of [1] since there are dependencies on
EXYNOS_CHIPID from that series..

[1] https://lore.kernel.org/lkml/20210919093114.35987-1-krzysztof.kozlowski@canonical.com/

* From v1:
  - Fixed modifying hidden configs
  - Modularized all the drivers that were touched
  - Removed HAVE_S3C_RTC
  - Updated all Samsung ARCH_XXX configs as suggested from reviews
  - Rebased on top of 5.15-rc3 and pulled in [1]

Will McVicker (12):
  arm64: don't have ARCH_EXYNOS select EXYNOS_CHIPID
  timekeeping: add API for getting timekeeping_suspended
  clk: samsung: add support for CPU clocks
  clk: samsung: exynos5433: update apollo and atlas clock probing
  clk: export __clk_lookup
  clk: samsung: modularize exynos arm64 clk drivers
  clk: samsung: set exynos arm64 clk driver as tristate
  pinctrl: samsung: modularize the ARM and ARM64 pinctrls
  pinctrl: samsung: set PINCTRL_EXYNOS and PINCTRL_SAMSUNG as tristate
  soc: samsung: pmu: modularize the Exynos ARMv8 PMU driver
  soc: samsung: pm_domains: modularize EXYNOS_PM_DOMAINS
  ARM: rtc: remove HAVE_S3C_RTC in favor of direct dependencies

 arch/arm/Kconfig                              |   1 -
 arch/arm/mach-exynos/Kconfig                  |   6 +-
 arch/arm/mach-s3c/Kconfig.s3c64xx             |   1 -
 arch/arm/mach-s5pv210/Kconfig                 |   3 -
 arch/arm64/Kconfig.platforms                  |   6 -
 drivers/clk/clk.c                             |   1 +
 drivers/clk/samsung/Kconfig                   |   5 +-
 drivers/clk/samsung/Makefile                  |   3 +-
 drivers/clk/samsung/clk-cpu.c                 |  28 +-
 drivers/clk/samsung/clk-cpu.h                 |   2 +-
 drivers/clk/samsung/clk-exynos5433.c          | 465 ++++++++----------
 drivers/clk/samsung/clk-exynos7.c             | 177 +++----
 drivers/clk/samsung/clk-pll.c                 |   6 +-
 drivers/clk/samsung/clk.c                     |  35 +-
 drivers/clk/samsung/clk.h                     |  50 +-
 drivers/pinctrl/samsung/Kconfig               |   5 +-
 drivers/pinctrl/samsung/Makefile              |  13 +-
 drivers/pinctrl/samsung/pinctrl-exynos-arm.c  | 102 ++--
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  73 +--
 drivers/pinctrl/samsung/pinctrl-exynos.c      |  17 +-
 drivers/pinctrl/samsung/pinctrl-samsung.c     |  11 +-
 drivers/rtc/Kconfig                           |  10 +-
 drivers/soc/samsung/Kconfig                   |  18 +-
 drivers/soc/samsung/Makefile                  |   8 +-
 drivers/soc/samsung/exynos-pmu.c              |  13 +-
 drivers/soc/samsung/exynos-pmu.h              |   2 +-
 drivers/soc/samsung/pm_domains.c              |  12 +-
 include/linux/soc/samsung/exynos-pmu.h        |   2 +-
 include/linux/timekeeping.h                   |   1 +
 kernel/time/timekeeping.c                     |  11 +
 30 files changed, 553 insertions(+), 534 deletions(-)

-- 
2.33.0.685.g46640cef36-goog

[PATCH v2 01/12] arm64: don't have ARCH_EXYNOS select EXYNOS_CHIPID

[Will McVicker]

Now that EXYNOS_CHIPID can be a module and is enabled by default via
ARCH_EXYNOS, we don't need to have ARCH_EXYNOS directly select it. So
remove that.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm64/Kconfig.platforms | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index b0ce18d4cc98..90c5cf4856e1 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -92,7 +92,6 @@ config ARCH_BRCMSTB
 config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
 	select COMMON_CLK_SAMSUNG
-	select EXYNOS_CHIPID
 	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 	select EXYNOS_PMU
 	select HAVE_S3C_RTC if RTC_CLASS
-- 
2.33.0.685.g46640cef36-goog

Re: (subset) [PATCH v2 01/12] arm64: don't have ARCH_EXYNOS select EXYNOS_CHIPID

[Krzysztof Kozlowski]

On Tue, 28 Sep 2021 23:56:18 +0000, Will McVicker wrote:
> Now that EXYNOS_CHIPID can be a module and is enabled by default via
> ARCH_EXYNOS, we don't need to have ARCH_EXYNOS directly select it. So
> remove that.
> 
> 

Applied, thanks!

[01/12] arm64: don't have ARCH_EXYNOS select EXYNOS_CHIPID
        commit: 6ad4185220e6e3b7ebac7c7a5f55197aedd000da

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>

Re: [PATCH v2 01/12] arm64: don't have ARCH_EXYNOS select EXYNOS_CHIPID

[Krzysztof Kozlowski]

On 29/09/2021 01:56, Will McVicker wrote:
> Now that EXYNOS_CHIPID can be a module and is enabled by default via
> ARCH_EXYNOS, we don't need to have ARCH_EXYNOS directly select it. So
> remove that.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index b0ce18d4cc98..90c5cf4856e1 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -92,7 +92,6 @@ config ARCH_BRCMSTB
>  config ARCH_EXYNOS
>  	bool "ARMv8 based Samsung Exynos SoC family"
>  	select COMMON_CLK_SAMSUNG
> -	select EXYNOS_CHIPID
>  	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
>  	select EXYNOS_PMU
>  	select HAVE_S3C_RTC if RTC_CLASS
> 

This actually should be part of my series converting ChipID driver to a
module:
https://lore.kernel.org/linux-samsung-soc/4aee1b0d-91a1-75ac-d2b7-6dab3d7a301f@kernel.org/T/#t

Applied it, thanks.

Best regards,
Krzysztof

[PATCH v2 02/12] timekeeping: add API for getting timekeeping_suspended

[Will McVicker]

This allows modules to access the value of timekeeping_suspended without
giving them write access to the variable.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 include/linux/timekeeping.h |  1 +
 kernel/time/timekeeping.c   | 11 +++++++++++
 2 files changed, 12 insertions(+)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 78a98bdff76d..cdc84421d77b 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -8,6 +8,7 @@
 /* Included from linux/ktime.h */
 
 void timekeeping_init(void);
+extern bool timekeeping_is_suspended(void);
 extern int timekeeping_suspended;
 
 /* Architecture timer tick functions: */
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index b348749a9fc6..27873c052e57 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -57,6 +57,17 @@ static struct timekeeper shadow_timekeeper;
 /* flag for if timekeeping is suspended */
 int __read_mostly timekeeping_suspended;
 
+/**
+ * timekeeping_is_suspended - query for timekeeping_suspended
+ *
+ * Returns the true/false based on the value of timekeeping_suspened.
+ */
+bool timekeeping_is_suspended(void)
+{
+	return timekeeping_suspended ? true : false;
+}
+EXPORT_SYMBOL_GPL(timekeeping_is_suspended);
+
 /**
  * struct tk_fast - NMI safe timekeeper
  * @seq:	Sequence counter for protecting updates. The lowest bit
-- 
2.33.0.685.g46640cef36-goog

Re: [PATCH v2 02/12] timekeeping: add API for getting timekeeping_suspended

[John Stultz]

On Tue, Sep 28, 2021 at 4:56 PM Will McVicker <willmcvicker@google.com> wrote:
>
> This allows modules to access the value of timekeeping_suspended without
> giving them write access to the variable.
>

It's important to cover "the why" not "the what" in these commit
messages, so you might add a note as to what code will be the user of
this (the samsung/clk-pll.c code changed later in this series).

thanks
-john

Re: [PATCH v2 02/12] timekeeping: add API for getting timekeeping_suspended

[Will McVicker]

On Tue, Sep 28, 2021 at 8:42 PM John Stultz <john.stultz@linaro.org> wrote:
>
> On Tue, Sep 28, 2021 at 4:56 PM Will McVicker <willmcvicker@google.com> wrote:
> >
> > This allows modules to access the value of timekeeping_suspended without
> > giving them write access to the variable.
> >
>
> It's important to cover "the why" not "the what" in these commit
> messages, so you might add a note as to what code will be the user of
> this (the samsung/clk-pll.c code changed later in this series).
>
> thanks
> -john

Thanks John for the tip. I will try to be better at that in the followup.

For this specific patch, I am adding this new API because the Samsung
PLL driver (drivers/clk/samsung/clk-pll.c) currently is using the
variable 'timekeeping_suspended' to detect timeouts before the
clocksource is initialized or timekeeping itself is suspended. My
patch series aims to modularize the Samsung PLL driver. So to keep the
driver's functionality intact, I need to add this additional API.

--Will

Re: [PATCH v2 02/12] timekeeping: add API for getting timekeeping_suspended

[John Stultz]

On Wed, Sep 29, 2021 at 1:01 PM Will McVicker <willmcvicker@google.com> wrote:
> On Tue, Sep 28, 2021 at 8:42 PM John Stultz <john.stultz@linaro.org> wrote:
> > On Tue, Sep 28, 2021 at 4:56 PM Will McVicker <willmcvicker@google.com> wrote:
> > >
> > > This allows modules to access the value of timekeeping_suspended without
> > > giving them write access to the variable.
> > >
> >
> > It's important to cover "the why" not "the what" in these commit
> > messages, so you might add a note as to what code will be the user of
> > this (the samsung/clk-pll.c code changed later in this series).
> >
> > thanks
> > -john
>
> Thanks John for the tip. I will try to be better at that in the followup.

I have to remind myself regularly as well. :)  Apologies if my quick
reply above seemed curt (as it does to me re-reading it now). Wasn't
my intent.

> For this specific patch, I am adding this new API because the Samsung
> PLL driver (drivers/clk/samsung/clk-pll.c) currently is using the
> variable 'timekeeping_suspended' to detect timeouts before the
> clocksource is initialized or timekeeping itself is suspended. My
> patch series aims to modularize the Samsung PLL driver. So to keep the
> driver's functionality intact, I need to add this additional API.

Sounds good!

Another small/medium suggestion:  Since you're adding a new interface
for non-core users of timekeeping_suspended, it might be good to
switch the other users as well (seems like just
drivers/clk/ti/clkctrl.c and kernel/sched/clock.c), then also remove
the extern in include/linux/timekeeping.h (so there's one consistent
method to access it)?  I know it's a sort of scope creep, so apologies
for asking, but it would make the series more attractive if it's not
leaving something for others to clean up later.

thanks
-john

Re: [PATCH v2 02/12] timekeeping: add API for getting timekeeping_suspended

[Will McVicker]

Thanks for the suggestion. That makes sense. I'll look into that for
the next version.

--Will

On Wed, Sep 29, 2021 at 1:46 PM John Stultz <john.stultz@linaro.org> wrote:
>
> On Wed, Sep 29, 2021 at 1:01 PM Will McVicker <willmcvicker@google.com> wrote:
> > On Tue, Sep 28, 2021 at 8:42 PM John Stultz <john.stultz@linaro.org> wrote:
> > > On Tue, Sep 28, 2021 at 4:56 PM Will McVicker <willmcvicker@google.com> wrote:
> > > >
> > > > This allows modules to access the value of timekeeping_suspended without
> > > > giving them write access to the variable.
> > > >
> > >
> > > It's important to cover "the why" not "the what" in these commit
> > > messages, so you might add a note as to what code will be the user of
> > > this (the samsung/clk-pll.c code changed later in this series).
> > >
> > > thanks
> > > -john
> >
> > Thanks John for the tip. I will try to be better at that in the followup.
>
> I have to remind myself regularly as well. :)  Apologies if my quick
> reply above seemed curt (as it does to me re-reading it now). Wasn't
> my intent.
>
> > For this specific patch, I am adding this new API because the Samsung
> > PLL driver (drivers/clk/samsung/clk-pll.c) currently is using the
> > variable 'timekeeping_suspended' to detect timeouts before the
> > clocksource is initialized or timekeeping itself is suspended. My
> > patch series aims to modularize the Samsung PLL driver. So to keep the
> > driver's functionality intact, I need to add this additional API.
>
> Sounds good!
>
> Another small/medium suggestion:  Since you're adding a new interface
> for non-core users of timekeeping_suspended, it might be good to
> switch the other users as well (seems like just
> drivers/clk/ti/clkctrl.c and kernel/sched/clock.c), then also remove
> the extern in include/linux/timekeeping.h (so there's one consistent
> method to access it)?  I know it's a sort of scope creep, so apologies
> for asking, but it would make the series more attractive if it's not
> leaving something for others to clean up later.
>
> thanks
> -john

[PATCH v2 03/12] clk: samsung: add support for CPU clocks

[Will McVicker]

Adds 'struct samsung_cpu_clock' and correpsonding code to the samsung
common clk driver. This allows drivers to register their CPU clocks with
the samsung_cmu_register_one() API.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 drivers/clk/samsung/clk-cpu.c | 26 ++++++++++++++++++++++++++
 drivers/clk/samsung/clk.c     |  2 ++
 drivers/clk/samsung/clk.h     | 26 ++++++++++++++++++++++++++
 3 files changed, 54 insertions(+)

diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
index 00ef4d1b0888..b5017934fc41 100644
--- a/drivers/clk/samsung/clk-cpu.c
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -469,3 +469,29 @@ int __init exynos_register_cpu_clock(struct samsung_clk_provider *ctx,
 	kfree(cpuclk);
 	return ret;
 }
+
+void samsung_clk_register_cpu(struct samsung_clk_provider *ctx,
+		const struct samsung_cpu_clock *list, unsigned int nr_clk)
+{
+	unsigned int idx;
+	unsigned int num_cfgs;
+	struct clk *parent_clk, *alt_parent_clk;
+	const struct clk_hw *parent_clk_hw = NULL;
+	const struct clk_hw *alt_parent_clk_hw = NULL;
+
+	for (idx = 0; idx < nr_clk; idx++, list++) {
+		/* find count of configuration rates in cfg */
+		for (num_cfgs = 0; list->cfg[num_cfgs].prate != 0; )
+			num_cfgs++;
+
+		parent_clk = __clk_lookup(list->parent_name);
+		if (parent_clk)
+			parent_clk_hw = __clk_get_hw(parent_clk);
+		alt_parent_clk = __clk_lookup(list->alt_parent_name);
+		if (alt_parent_clk)
+			alt_parent_clk_hw = __clk_get_hw(alt_parent_clk);
+
+		exynos_register_cpu_clock(ctx, list->id, list->name, parent_clk_hw,
+				alt_parent_clk_hw, list->offset, list->cfg, num_cfgs, list->flags);
+	}
+}
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 1949ae7851b2..336243c6f120 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -378,6 +378,8 @@ struct samsung_clk_provider * __init samsung_cmu_register_one(
 		samsung_clk_extended_sleep_init(reg_base,
 			cmu->clk_regs, cmu->nr_clk_regs,
 			cmu->suspend_regs, cmu->nr_suspend_regs);
+	if (cmu->cpu_clks)
+		samsung_clk_register_cpu(ctx, cmu->cpu_clks, cmu->nr_cpu_clks);
 
 	samsung_clk_of_add_provider(np, ctx);
 
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index c1e1a6b2f499..a52a38cc1740 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -271,6 +271,27 @@ struct samsung_pll_clock {
 	__PLL(_typ, _id, _name, _pname, CLK_GET_RATE_NOCACHE, _lock,	\
 	      _con, _rtable)
 
+struct samsung_cpu_clock {
+	unsigned int		id;
+	const char		*name;
+	const char		*parent_name;
+	const char		*alt_parent_name;
+	unsigned long		flags;
+	int			offset;
+	const struct exynos_cpuclk_cfg_data *cfg;
+};
+
+#define CPU_CLK(_id, _name, _pname, _apname, _flags, _offset, _cfg) \
+	{							    \
+		.id		  = _id,			    \
+		.name		  = _name,			    \
+		.parent_name	  = _pname,			    \
+		.alt_parent_name  = _apname,			    \
+		.flags		  = _flags,			    \
+		.offset		  = _offset,			    \
+		.cfg		  = _cfg,			    \
+	}
+
 struct samsung_clock_reg_cache {
 	struct list_head node;
 	void __iomem *reg_base;
@@ -301,6 +322,9 @@ struct samsung_cmu_info {
 	unsigned int nr_fixed_factor_clks;
 	/* total number of clocks with IDs assigned*/
 	unsigned int nr_clk_ids;
+	/* list of cpu clocks and respective count */
+	const struct samsung_cpu_clock *cpu_clks;
+	unsigned int nr_cpu_clks;
 
 	/* list and number of clocks registers */
 	const unsigned long *clk_regs;
@@ -350,6 +374,8 @@ extern void __init samsung_clk_register_gate(struct samsung_clk_provider *ctx,
 extern void __init samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 			const struct samsung_pll_clock *pll_list,
 			unsigned int nr_clk, void __iomem *base);
+extern void __init samsung_clk_register_cpu(struct samsung_clk_provider *ctx,
+		const struct samsung_cpu_clock *list, unsigned int nr_clk);
 
 extern struct samsung_clk_provider __init *samsung_cmu_register_one(
 			struct device_node *,
-- 
2.33.0.685.g46640cef36-goog

[PATCH v2 04/12] clk: samsung: exynos5433: update apollo and atlas clock probing

[Will McVicker]

Use the samsung common clk driver to initialize and probe the apollo and
atlas clocks. This removes their dedicated init functions and uses the
platform driver to handle the probing.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 drivers/clk/samsung/clk-exynos5433.c | 130 ++++++++++-----------------
 1 file changed, 49 insertions(+), 81 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5433.c b/drivers/clk/samsung/clk-exynos5433.c
index f203074d858b..b45f6a65ba64 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -3675,47 +3675,28 @@ static const struct exynos_cpuclk_cfg_data exynos5433_apolloclk_d[] __initconst
 	{  0 },
 };
 
-static void __init exynos5433_cmu_apollo_init(struct device_node *np)
-{
-	void __iomem *reg_base;
-	struct samsung_clk_provider *ctx;
-	struct clk_hw **hws;
-
-	reg_base = of_iomap(np, 0);
-	if (!reg_base) {
-		panic("%s: failed to map registers\n", __func__);
-		return;
-	}
-
-	ctx = samsung_clk_init(np, reg_base, APOLLO_NR_CLK);
-	if (!ctx) {
-		panic("%s: unable to allocate ctx\n", __func__);
-		return;
-	}
-
-	samsung_clk_register_pll(ctx, apollo_pll_clks,
-				 ARRAY_SIZE(apollo_pll_clks), reg_base);
-	samsung_clk_register_mux(ctx, apollo_mux_clks,
-				 ARRAY_SIZE(apollo_mux_clks));
-	samsung_clk_register_div(ctx, apollo_div_clks,
-				 ARRAY_SIZE(apollo_div_clks));
-	samsung_clk_register_gate(ctx, apollo_gate_clks,
-				  ARRAY_SIZE(apollo_gate_clks));
-
-	hws = ctx->clk_data.hws;
-
-	exynos_register_cpu_clock(ctx, CLK_SCLK_APOLLO, "apolloclk",
-		hws[CLK_MOUT_APOLLO_PLL], hws[CLK_MOUT_BUS_PLL_APOLLO_USER], 0x200,
-		exynos5433_apolloclk_d, ARRAY_SIZE(exynos5433_apolloclk_d),
-		CLK_CPU_HAS_E5433_REGS_LAYOUT);
-
-	samsung_clk_sleep_init(reg_base, apollo_clk_regs,
-			       ARRAY_SIZE(apollo_clk_regs));
-
-	samsung_clk_of_add_provider(np, ctx);
-}
-CLK_OF_DECLARE(exynos5433_cmu_apollo, "samsung,exynos5433-cmu-apollo",
-		exynos5433_cmu_apollo_init);
+static const struct samsung_cpu_clock apollo_cpu_clks[] __initconst = {
+	CPU_CLK(CLK_SCLK_APOLLO, "apolloclk", "mout_apollo_pll",
+			"mout_bus_pll_apollo_user",
+			CLK_CPU_HAS_E5433_REGS_LAYOUT, 0x200,
+			exynos5433_apolloclk_d),
+};
+
+static const struct samsung_cmu_info apollo_cmu_info __initconst = {
+	.pll_clks	= apollo_pll_clks,
+	.nr_pll_clks	= ARRAY_SIZE(apollo_pll_clks),
+	.mux_clks	= apollo_mux_clks,
+	.nr_mux_clks	= ARRAY_SIZE(apollo_mux_clks),
+	.div_clks	= apollo_div_clks,
+	.nr_div_clks	= ARRAY_SIZE(apollo_div_clks),
+	.gate_clks	= apollo_gate_clks,
+	.nr_gate_clks	= ARRAY_SIZE(apollo_gate_clks),
+	.cpu_clks	= apollo_cpu_clks,
+	.nr_cpu_clks	= ARRAY_SIZE(apollo_cpu_clks),
+	.nr_clk_ids	= APOLLO_NR_CLK,
+	.clk_regs	= apollo_clk_regs,
+	.nr_clk_regs	= ARRAY_SIZE(apollo_clk_regs),
+};
 
 /*
  * Register offset definitions for CMU_ATLAS
@@ -3932,47 +3913,28 @@ static const struct exynos_cpuclk_cfg_data exynos5433_atlasclk_d[] __initconst =
 	{  0 },
 };
 
-static void __init exynos5433_cmu_atlas_init(struct device_node *np)
-{
-	void __iomem *reg_base;
-	struct samsung_clk_provider *ctx;
-	struct clk_hw **hws;
-
-	reg_base = of_iomap(np, 0);
-	if (!reg_base) {
-		panic("%s: failed to map registers\n", __func__);
-		return;
-	}
-
-	ctx = samsung_clk_init(np, reg_base, ATLAS_NR_CLK);
-	if (!ctx) {
-		panic("%s: unable to allocate ctx\n", __func__);
-		return;
-	}
-
-	samsung_clk_register_pll(ctx, atlas_pll_clks,
-				 ARRAY_SIZE(atlas_pll_clks), reg_base);
-	samsung_clk_register_mux(ctx, atlas_mux_clks,
-				 ARRAY_SIZE(atlas_mux_clks));
-	samsung_clk_register_div(ctx, atlas_div_clks,
-				 ARRAY_SIZE(atlas_div_clks));
-	samsung_clk_register_gate(ctx, atlas_gate_clks,
-				  ARRAY_SIZE(atlas_gate_clks));
-
-	hws = ctx->clk_data.hws;
-
-	exynos_register_cpu_clock(ctx, CLK_SCLK_ATLAS, "atlasclk",
-		hws[CLK_MOUT_ATLAS_PLL], hws[CLK_MOUT_BUS_PLL_ATLAS_USER], 0x200,
-		exynos5433_atlasclk_d, ARRAY_SIZE(exynos5433_atlasclk_d),
-		CLK_CPU_HAS_E5433_REGS_LAYOUT);
-
-	samsung_clk_sleep_init(reg_base, atlas_clk_regs,
-			       ARRAY_SIZE(atlas_clk_regs));
+static const struct samsung_cpu_clock atlas_cpu_clks[] __initconst = {
+	CPU_CLK(CLK_SCLK_ATLAS, "atlasclk", "mout_atlas_pll",
+			"mout_bus_pll_atlas_user",
+			CLK_CPU_HAS_E5433_REGS_LAYOUT, 0x200,
+			exynos5433_atlasclk_d),
+};
 
-	samsung_clk_of_add_provider(np, ctx);
-}
-CLK_OF_DECLARE(exynos5433_cmu_atlas, "samsung,exynos5433-cmu-atlas",
-		exynos5433_cmu_atlas_init);
+static const struct samsung_cmu_info atlas_cmu_info __initconst = {
+	.pll_clks	= atlas_pll_clks,
+	.nr_pll_clks	= ARRAY_SIZE(atlas_pll_clks),
+	.mux_clks	= atlas_mux_clks,
+	.nr_mux_clks	= ARRAY_SIZE(atlas_mux_clks),
+	.div_clks	= atlas_div_clks,
+	.nr_div_clks	= ARRAY_SIZE(atlas_div_clks),
+	.gate_clks	= atlas_gate_clks,
+	.nr_gate_clks	= ARRAY_SIZE(atlas_gate_clks),
+	.cpu_clks	= atlas_cpu_clks,
+	.nr_cpu_clks	= ARRAY_SIZE(atlas_cpu_clks),
+	.nr_clk_ids	= ATLAS_NR_CLK,
+	.clk_regs	= atlas_clk_regs,
+	.nr_clk_regs	= ARRAY_SIZE(atlas_clk_regs),
+};
 
 /*
  * Register offset definitions for CMU_MSCL
@@ -5700,6 +5662,12 @@ static const struct of_device_id exynos5433_cmu_of_match[] = {
 	}, {
 		.compatible = "samsung,exynos5433-cmu-imem",
 		.data = &imem_cmu_info,
+	}, {
+		.compatible = "samsung,exynos5433-cmu-atlas",
+		.data = &atlas_cmu_info,
+	}, {
+		.compatible = "samsung,exynos5433-cmu-apollo",
+		.data = &apollo_cmu_info,
 	}, {
 	},
 };
-- 
2.33.0.685.g46640cef36-goog

[PATCH v2 05/12] clk: export __clk_lookup

[Will McVicker]

This symbol is needed to modularize the samsung clk drivers. It's used
to get the clock using the clock name.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 drivers/clk/clk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 65508eb89ec9..f2aa4b49adfc 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -612,6 +612,7 @@ struct clk *__clk_lookup(const char *name)
 
 	return !core ? NULL : core->hw->clk;
 }
+EXPORT_SYMBOL_GPL(__clk_lookup);
 
 static void clk_core_get_boundaries(struct clk_core *core,
 				    unsigned long *min_rate,
-- 
2.33.0.685.g46640cef36-goog

Re: [PATCH v2 05/12] clk: export __clk_lookup

[Stephen Boyd]

Quoting Will McVicker (2021-09-28 16:56:22)
> This symbol is needed to modularize the samsung clk drivers. It's used
> to get the clock using the clock name.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  drivers/clk/clk.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 65508eb89ec9..f2aa4b49adfc 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -612,6 +612,7 @@ struct clk *__clk_lookup(const char *name)
>  
>         return !core ? NULL : core->hw->clk;
>  }
> +EXPORT_SYMBOL_GPL(__clk_lookup);

I'd prefer we deleted this API. Can you make the samsung clk driver stop
using it instead?

[PATCH v2 06/12] clk: samsung: modularize exynos arm64 clk drivers

[Will McVicker]

This modularizes the Exynos ARM64 clock drivers. The change consolidates
the clock devices into the of match table so that the platform driver
probes all the clocks (per driver) as well as exports the necessary
functions for each driver.

With this, we now have 3 separate kernel modules (pending Kconfig
changes):

1) clk-common-exynos.ko: the common exynos clock driver
2) clk-exynos5433.ko: the Exynos5433 clock driver
3) clk-exynos7.ko: the Exynos7 clock driver

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 drivers/clk/samsung/Makefile         |   3 +-
 drivers/clk/samsung/clk-cpu.c        |   2 +-
 drivers/clk/samsung/clk-cpu.h        |   2 +-
 drivers/clk/samsung/clk-exynos5433.c | 349 +++++++++++++--------------
 drivers/clk/samsung/clk-exynos7.c    | 177 ++++++--------
 drivers/clk/samsung/clk-pll.c        |   6 +-
 drivers/clk/samsung/clk.c            |  33 ++-
 drivers/clk/samsung/clk.h            |  26 +-
 8 files changed, 287 insertions(+), 311 deletions(-)

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 028b2e27a37e..33f07ee87d90 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -3,7 +3,8 @@
 # Samsung Clock specific Makefile
 #
 
-obj-$(CONFIG_COMMON_CLK)	+= clk.o clk-pll.o clk-cpu.o
+obj-$(CONFIG_COMMON_CLK_SAMSUNG)	+= clk-common-exynos.o
+clk-common-exynos-y += clk.o clk-pll.o clk-cpu.o
 obj-$(CONFIG_EXYNOS_3250_COMMON_CLK)	+= clk-exynos3250.o
 obj-$(CONFIG_EXYNOS_4_COMMON_CLK)	+= clk-exynos4.o
 obj-$(CONFIG_EXYNOS_4_COMMON_CLK)	+= clk-exynos4412-isp.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
index b5017934fc41..ab3d0c073031 100644
--- a/drivers/clk/samsung/clk-cpu.c
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -400,7 +400,7 @@ static int exynos5433_cpuclk_notifier_cb(struct notifier_block *nb,
 }
 
 /* helper function to register a CPU clock */
-int __init exynos_register_cpu_clock(struct samsung_clk_provider *ctx,
+int exynos_register_cpu_clock(struct samsung_clk_provider *ctx,
 		unsigned int lookup_id, const char *name,
 		const struct clk_hw *parent, const struct clk_hw *alt_parent,
 		unsigned long offset, const struct exynos_cpuclk_cfg_data *cfg,
diff --git a/drivers/clk/samsung/clk-cpu.h b/drivers/clk/samsung/clk-cpu.h
index af74686db9ef..fd885d2bf74c 100644
--- a/drivers/clk/samsung/clk-cpu.h
+++ b/drivers/clk/samsung/clk-cpu.h
@@ -62,7 +62,7 @@ struct exynos_cpuclk {
 #define CLK_CPU_HAS_E5433_REGS_LAYOUT	(1 << 2)
 };
 
-int __init exynos_register_cpu_clock(struct samsung_clk_provider *ctx,
+int exynos_register_cpu_clock(struct samsung_clk_provider *ctx,
 			unsigned int lookup_id, const char *name,
 			const struct clk_hw *parent, const struct clk_hw *alt_parent,
 			unsigned long offset,
diff --git a/drivers/clk/samsung/clk-exynos5433.c b/drivers/clk/samsung/clk-exynos5433.c
index b45f6a65ba64..885e38c1d487 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -8,6 +8,7 @@
 
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_device.h>
@@ -112,7 +113,7 @@
 #define ENABLE_CMU_TOP			0x0c00
 #define ENABLE_CMU_TOP_DIV_STAT		0x0c04
 
-static const unsigned long top_clk_regs[] __initconst = {
+static const unsigned long top_clk_regs[] = {
 	ISP_PLL_LOCK,
 	AUD_PLL_LOCK,
 	ISP_PLL_CON0,
@@ -233,11 +234,11 @@ PNAME(mout_sclk_audio0_p)	= { "ioclk_audiocdclk0", "oscclk",
 
 PNAME(mout_sclk_hdmi_spdif_p)	= { "sclk_audio1", "ioclk_spdif_extclk", };
 
-static const struct samsung_fixed_factor_clock top_fixed_factor_clks[] __initconst = {
+static const struct samsung_fixed_factor_clock top_fixed_factor_clks[] = {
 	FFACTOR(0, "oscclk_efuse_common", "oscclk", 1, 1, 0),
 };
 
-static const struct samsung_fixed_rate_clock top_fixed_clks[] __initconst = {
+static const struct samsung_fixed_rate_clock top_fixed_clks[] = {
 	/* Xi2s{0|1}CDCLK input clock for I2S/PCM */
 	FRATE(0, "ioclk_audiocdclk1", NULL, 0, 100000000),
 	FRATE(0, "ioclk_audiocdclk0", NULL, 0, 100000000),
@@ -253,7 +254,7 @@ static const struct samsung_fixed_rate_clock top_fixed_clks[] __initconst = {
 	FRATE(0, "ioclk_i2s1_bclk_in", NULL, 0, 12288000),
 };
 
-static const struct samsung_mux_clock top_mux_clks[] __initconst = {
+static const struct samsung_mux_clock top_mux_clks[] = {
 	/* MUX_SEL_TOP0 */
 	MUX(CLK_MOUT_AUD_PLL, "mout_aud_pll", mout_aud_pll_p, MUX_SEL_TOP0,
 			4, 1),
@@ -389,7 +390,7 @@ static const struct samsung_mux_clock top_mux_clks[] __initconst = {
 			mout_sclk_hdmi_spdif_p, MUX_SEL_TOP_DISP, 0, 1),
 };
 
-static const struct samsung_div_clock top_div_clks[] __initconst = {
+static const struct samsung_div_clock top_div_clks[] = {
 	/* DIV_TOP0 */
 	DIV(CLK_DIV_ACLK_CAM1_333, "div_aclk_cam1_333", "mout_aclk_cam1_333",
 			DIV_TOP0, 28, 3),
@@ -553,7 +554,7 @@ static const struct samsung_div_clock top_div_clks[] __initconst = {
 			DIV_TOP_PERIC4, 0, 4),
 };
 
-static const struct samsung_gate_clock top_gate_clks[] __initconst = {
+static const struct samsung_gate_clock top_gate_clks[] = {
 	/* ENABLE_ACLK_TOP */
 	GATE(CLK_ACLK_G3D_400, "aclk_g3d_400", "div_aclk_g3d_400",
 			ENABLE_ACLK_TOP, 30, CLK_IS_CRITICAL, 0),
@@ -711,7 +712,7 @@ static const struct samsung_gate_clock top_gate_clks[] __initconst = {
  * ATLAS_PLL & APOLLO_PLL & MEM0_PLL & MEM1_PLL & BUS_PLL & MFC_PLL
  * & MPHY_PLL & G3D_PLL & DISP_PLL & ISP_PLL
  */
-static const struct samsung_pll_rate_table exynos5433_pll_rates[] __initconst = {
+static const struct samsung_pll_rate_table exynos5433_pll_rates[] = {
 	PLL_35XX_RATE(24 * MHZ, 2500000000U, 625, 6,  0),
 	PLL_35XX_RATE(24 * MHZ, 2400000000U, 500, 5,  0),
 	PLL_35XX_RATE(24 * MHZ, 2300000000U, 575, 6,  0),
@@ -764,7 +765,7 @@ static const struct samsung_pll_rate_table exynos5433_pll_rates[] __initconst =
 };
 
 /* AUD_PLL */
-static const struct samsung_pll_rate_table exynos5433_aud_pll_rates[] __initconst = {
+static const struct samsung_pll_rate_table exynos5433_aud_pll_rates[] = {
 	PLL_36XX_RATE(24 * MHZ, 400000000U, 200, 3, 2,      0),
 	PLL_36XX_RATE(24 * MHZ, 393216003U, 197, 3, 2, -25690),
 	PLL_36XX_RATE(24 * MHZ, 384000000U, 128, 2, 2,      0),
@@ -778,14 +779,14 @@ static const struct samsung_pll_rate_table exynos5433_aud_pll_rates[] __initcons
 	{ /* sentinel */ }
 };
 
-static const struct samsung_pll_clock top_pll_clks[] __initconst = {
+static const struct samsung_pll_clock top_pll_clks[] = {
 	PLL(pll_35xx, CLK_FOUT_ISP_PLL, "fout_isp_pll", "oscclk",
 		ISP_PLL_LOCK, ISP_PLL_CON0, exynos5433_pll_rates),
 	PLL(pll_36xx, CLK_FOUT_AUD_PLL, "fout_aud_pll", "oscclk",
 		AUD_PLL_LOCK, AUD_PLL_CON0, exynos5433_aud_pll_rates),
 };
 
-static const struct samsung_cmu_info top_cmu_info __initconst = {
+static const struct samsung_cmu_info top_cmu_info = {
 	.pll_clks		= top_pll_clks,
 	.nr_pll_clks		= ARRAY_SIZE(top_pll_clks),
 	.mux_clks		= top_mux_clks,
@@ -805,13 +806,6 @@ static const struct samsung_cmu_info top_cmu_info __initconst = {
 	.nr_suspend_regs	= ARRAY_SIZE(top_suspend_regs),
 };
 
-static void __init exynos5433_cmu_top_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &top_cmu_info);
-}
-CLK_OF_DECLARE(exynos5433_cmu_top, "samsung,exynos5433-cmu-top",
-		exynos5433_cmu_top_init);
-
 /*
  * Register offset definitions for CMU_CPIF
  */
@@ -823,7 +817,7 @@ CLK_OF_DECLARE(exynos5433_cmu_top, "samsung,exynos5433-cmu-top",
 #define DIV_CPIF		0x0600
 #define ENABLE_SCLK_CPIF	0x0a00
 
-static const unsigned long cpif_clk_regs[] __initconst = {
+static const unsigned long cpif_clk_regs[] = {
 	MPHY_PLL_LOCK,
 	MPHY_PLL_CON0,
 	MPHY_PLL_CON1,
@@ -843,24 +837,24 @@ static const struct samsung_clk_reg_dump cpif_suspend_regs[] = {
 /* list of all parent clock list */
 PNAME(mout_mphy_pll_p)		= { "oscclk", "fout_mphy_pll", };
 
-static const struct samsung_pll_clock cpif_pll_clks[] __initconst = {
+static const struct samsung_pll_clock cpif_pll_clks[] = {
 	PLL(pll_35xx, CLK_FOUT_MPHY_PLL, "fout_mphy_pll", "oscclk",
 		MPHY_PLL_LOCK, MPHY_PLL_CON0, exynos5433_pll_rates),
 };
 
-static const struct samsung_mux_clock cpif_mux_clks[] __initconst = {
+static const struct samsung_mux_clock cpif_mux_clks[] = {
 	/* MUX_SEL_CPIF0 */
 	MUX(CLK_MOUT_MPHY_PLL, "mout_mphy_pll", mout_mphy_pll_p, MUX_SEL_CPIF0,
 			0, 1),
 };
 
-static const struct samsung_div_clock cpif_div_clks[] __initconst = {
+static const struct samsung_div_clock cpif_div_clks[] = {
 	/* DIV_CPIF */
 	DIV(CLK_DIV_SCLK_MPHY, "div_sclk_mphy", "mout_mphy_pll", DIV_CPIF,
 			0, 6),
 };
 
-static const struct samsung_gate_clock cpif_gate_clks[] __initconst = {
+static const struct samsung_gate_clock cpif_gate_clks[] = {
 	/* ENABLE_SCLK_CPIF */
 	GATE(CLK_SCLK_MPHY_PLL, "sclk_mphy_pll", "mout_mphy_pll",
 			ENABLE_SCLK_CPIF, 9, CLK_IGNORE_UNUSED, 0),
@@ -868,7 +862,7 @@ static const struct samsung_gate_clock cpif_gate_clks[] __initconst = {
 			ENABLE_SCLK_CPIF, 4, 0, 0),
 };
 
-static const struct samsung_cmu_info cpif_cmu_info __initconst = {
+static const struct samsung_cmu_info cpif_cmu_info = {
 	.pll_clks		= cpif_pll_clks,
 	.nr_pll_clks		= ARRAY_SIZE(cpif_pll_clks),
 	.mux_clks		= cpif_mux_clks,
@@ -884,13 +878,6 @@ static const struct samsung_cmu_info cpif_cmu_info __initconst = {
 	.nr_suspend_regs	= ARRAY_SIZE(cpif_suspend_regs),
 };
 
-static void __init exynos5433_cmu_cpif_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &cpif_cmu_info);
-}
-CLK_OF_DECLARE(exynos5433_cmu_cpif, "samsung,exynos5433-cmu-cpif",
-		exynos5433_cmu_cpif_init);
-
 /*
  * Register offset definitions for CMU_MIF
  */
@@ -971,7 +958,7 @@ CLK_OF_DECLARE(exynos5433_cmu_cpif, "samsung,exynos5433-cmu-cpif",
 #define PAUSE				0x1008
 #define DDRPHY_LOCK_CTRL		0x100c
 
-static const unsigned long mif_clk_regs[] __initconst = {
+static const unsigned long mif_clk_regs[] = {
 	MEM0_PLL_LOCK,
 	MEM1_PLL_LOCK,
 	BUS_PLL_LOCK,
@@ -1036,7 +1023,7 @@ static const unsigned long mif_clk_regs[] __initconst = {
 	DDRPHY_LOCK_CTRL,
 };
 
-static const struct samsung_pll_clock mif_pll_clks[] __initconst = {
+static const struct samsung_pll_clock mif_pll_clks[] = {
 	PLL(pll_35xx, CLK_FOUT_MEM0_PLL, "fout_mem0_pll", "oscclk",
 		MEM0_PLL_LOCK, MEM0_PLL_CON0, exynos5433_pll_rates),
 	PLL(pll_35xx, CLK_FOUT_MEM1_PLL, "fout_mem1_pll", "oscclk",
@@ -1097,7 +1084,7 @@ PNAME(mout_sclk_decon_tv_vclk_b_p) = { "mout_sclk_decon_tv_vclk_a",
 PNAME(mout_sclk_dsim1_c_p)	= { "mout_sclk_dsim1_b", "sclk_mphy_pll", };
 PNAME(mout_sclk_dsim1_b_p)	= { "mout_sclk_dsim1_a", "mout_mfc_pll_div2",};
 
-static const struct samsung_fixed_factor_clock mif_fixed_factor_clks[] __initconst = {
+static const struct samsung_fixed_factor_clock mif_fixed_factor_clks[] = {
 	/* dout_{mfc|bus|mem1|mem0}_pll is half fixed rate from parent mux */
 	FFACTOR(CLK_DOUT_MFC_PLL, "dout_mfc_pll", "mout_mfc_pll", 1, 1, 0),
 	FFACTOR(CLK_DOUT_BUS_PLL, "dout_bus_pll", "mout_bus_pll", 1, 1, 0),
@@ -1105,7 +1092,7 @@ static const struct samsung_fixed_factor_clock mif_fixed_factor_clks[] __initcon
 	FFACTOR(CLK_DOUT_MEM0_PLL, "dout_mem0_pll", "mout_mem0_pll", 1, 1, 0),
 };
 
-static const struct samsung_mux_clock mif_mux_clks[] __initconst = {
+static const struct samsung_mux_clock mif_mux_clks[] = {
 	/* MUX_SEL_MIF0 */
 	MUX(CLK_MOUT_MFC_PLL_DIV2, "mout_mfc_pll_div2", mout_mfc_pll_div2_p,
 			MUX_SEL_MIF0, 28, 1),
@@ -1201,7 +1188,7 @@ static const struct samsung_mux_clock mif_mux_clks[] __initconst = {
 			MUX_SEL_MIF7, 0, 1),
 };
 
-static const struct samsung_div_clock mif_div_clks[] __initconst = {
+static const struct samsung_div_clock mif_div_clks[] = {
 	/* DIV_MIF1 */
 	DIV(CLK_DIV_SCLK_HPM_MIF, "div_sclk_hpm_mif", "div_clk2x_phy",
 			DIV_MIF1, 16, 2),
@@ -1255,7 +1242,7 @@ static const struct samsung_div_clock mif_div_clks[] __initconst = {
 			0, 3),
 };
 
-static const struct samsung_gate_clock mif_gate_clks[] __initconst = {
+static const struct samsung_gate_clock mif_gate_clks[] = {
 	/* ENABLE_ACLK_MIF0 */
 	GATE(CLK_CLK2X_PHY1, "clk2k_phy1", "div_clk2x_phy", ENABLE_ACLK_MIF0,
 			19, CLK_IGNORE_UNUSED, 0),
@@ -1520,7 +1507,7 @@ static const struct samsung_gate_clock mif_gate_clks[] __initconst = {
 			ENABLE_SCLK_MIF, 0, CLK_IGNORE_UNUSED, 0),
 };
 
-static const struct samsung_cmu_info mif_cmu_info __initconst = {
+static const struct samsung_cmu_info mif_cmu_info = {
 	.pll_clks		= mif_pll_clks,
 	.nr_pll_clks		= ARRAY_SIZE(mif_pll_clks),
 	.mux_clks		= mif_mux_clks,
@@ -1536,13 +1523,6 @@ static const struct samsung_cmu_info mif_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(mif_clk_regs),
 };
 
-static void __init exynos5433_cmu_mif_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &mif_cmu_info);
-}
-CLK_OF_DECLARE(exynos5433_cmu_mif, "samsung,exynos5433-cmu-mif",
-		exynos5433_cmu_mif_init);
-
 /*
  * Register offset definitions for CMU_PERIC
  */
@@ -1556,7 +1536,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif, "samsung,exynos5433-cmu-mif",
 #define ENABLE_IP_PERIC1		0x0B04
 #define ENABLE_IP_PERIC2		0x0B08
 
-static const unsigned long peric_clk_regs[] __initconst = {
+static const unsigned long peric_clk_regs[] = {
 	DIV_PERIC,
 	ENABLE_ACLK_PERIC,
 	ENABLE_PCLK_PERIC0,
@@ -1574,13 +1554,13 @@ static const struct samsung_clk_reg_dump peric_suspend_regs[] = {
 	{ ENABLE_SCLK_PERIC, 0x7 },
 };
 
-static const struct samsung_div_clock peric_div_clks[] __initconst = {
+static const struct samsung_div_clock peric_div_clks[] = {
 	/* DIV_PERIC */
 	DIV(CLK_DIV_SCLK_SCI, "div_sclk_sci", "oscclk", DIV_PERIC, 4, 4),
 	DIV(CLK_DIV_SCLK_SC_IN, "div_sclk_sc_in", "oscclk", DIV_PERIC, 0, 4),
 };
 
-static const struct samsung_gate_clock peric_gate_clks[] __initconst = {
+static const struct samsung_gate_clock peric_gate_clks[] = {
 	/* ENABLE_ACLK_PERIC */
 	GATE(CLK_ACLK_AHB2APB_PERIC2P, "aclk_ahb2apb_peric2p", "aclk_peric_66",
 			ENABLE_ACLK_PERIC, 3, CLK_IGNORE_UNUSED, 0),
@@ -1725,7 +1705,7 @@ static const struct samsung_gate_clock peric_gate_clks[] __initconst = {
 			CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
 };
 
-static const struct samsung_cmu_info peric_cmu_info __initconst = {
+static const struct samsung_cmu_info peric_cmu_info = {
 	.div_clks		= peric_div_clks,
 	.nr_div_clks		= ARRAY_SIZE(peric_div_clks),
 	.gate_clks		= peric_gate_clks,
@@ -1737,14 +1717,6 @@ static const struct samsung_cmu_info peric_cmu_info __initconst = {
 	.nr_suspend_regs	= ARRAY_SIZE(peric_suspend_regs),
 };
 
-static void __init exynos5433_cmu_peric_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &peric_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos5433_cmu_peric, "samsung,exynos5433-cmu-peric",
-		exynos5433_cmu_peric_init);
-
 /*
  * Register offset definitions for CMU_PERIS
  */
@@ -1774,7 +1746,7 @@ CLK_OF_DECLARE(exynos5433_cmu_peric, "samsung,exynos5433-cmu-peric",
 #define ENABLE_IP_PERIS_SECURE_ANTIBRK_CNT		0x0b1c
 #define ENABLE_IP_PERIS_SECURE_OTP_CON			0x0b20
 
-static const unsigned long peris_clk_regs[] __initconst = {
+static const unsigned long peris_clk_regs[] = {
 	ENABLE_ACLK_PERIS,
 	ENABLE_PCLK_PERIS,
 	ENABLE_PCLK_PERIS_SECURE_TZPC,
@@ -1802,7 +1774,7 @@ static const unsigned long peris_clk_regs[] __initconst = {
 	ENABLE_IP_PERIS_SECURE_OTP_CON,
 };
 
-static const struct samsung_gate_clock peris_gate_clks[] __initconst = {
+static const struct samsung_gate_clock peris_gate_clks[] = {
 	/* ENABLE_ACLK_PERIS */
 	GATE(CLK_ACLK_AHB2APB_PERIS1P, "aclk_ahb2apb_peris1p", "aclk_peris_66",
 			ENABLE_ACLK_PERIS, 2, CLK_IGNORE_UNUSED, 0),
@@ -1921,7 +1893,7 @@ static const struct samsung_gate_clock peris_gate_clks[] __initconst = {
 			ENABLE_SCLK_PERIS_SECURE_OTP_CON, 0, 0, 0),
 };
 
-static const struct samsung_cmu_info peris_cmu_info __initconst = {
+static const struct samsung_cmu_info peris_cmu_info = {
 	.gate_clks		= peris_gate_clks,
 	.nr_gate_clks		= ARRAY_SIZE(peris_gate_clks),
 	.nr_clk_ids		= PERIS_NR_CLK,
@@ -1929,14 +1901,6 @@ static const struct samsung_cmu_info peris_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(peris_clk_regs),
 };
 
-static void __init exynos5433_cmu_peris_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &peris_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos5433_cmu_peris, "samsung,exynos5433-cmu-peris",
-		exynos5433_cmu_peris_init);
-
 /*
  * Register offset definitions for CMU_FSYS
  */
@@ -2005,7 +1969,7 @@ PNAME(mout_sclk_mphy_p)
 		= { "mout_sclk_ufs_mphy_user",
 			    "mout_phyclk_lli_mphy_to_ufs_user", };
 
-static const unsigned long fsys_clk_regs[] __initconst = {
+static const unsigned long fsys_clk_regs[] = {
 	MUX_SEL_FSYS0,
 	MUX_SEL_FSYS1,
 	MUX_SEL_FSYS2,
@@ -2034,7 +1998,7 @@ static const struct samsung_clk_reg_dump fsys_suspend_regs[] = {
 	{ MUX_SEL_FSYS4, 0 },
 };
 
-static const struct samsung_fixed_rate_clock fsys_fixed_clks[] __initconst = {
+static const struct samsung_fixed_rate_clock fsys_fixed_clks[] = {
 	/* PHY clocks from USBDRD30_PHY */
 	FRATE(CLK_PHYCLK_USBDRD30_UDRD30_PHYCLOCK_PHY,
 			"phyclk_usbdrd30_udrd30_phyclock_phy", NULL,
@@ -2074,7 +2038,7 @@ static const struct samsung_fixed_rate_clock fsys_fixed_clks[] __initconst = {
 			NULL, 0, 26000000),
 };
 
-static const struct samsung_mux_clock fsys_mux_clks[] __initconst = {
+static const struct samsung_mux_clock fsys_mux_clks[] = {
 	/* MUX_SEL_FSYS0 */
 	MUX(CLK_MOUT_SCLK_UFS_MPHY_USER, "mout_sclk_ufs_mphy_user",
 			mout_sclk_ufs_mphy_user_p, MUX_SEL_FSYS0, 4, 1),
@@ -2158,7 +2122,7 @@ static const struct samsung_mux_clock fsys_mux_clks[] __initconst = {
 			MUX_SEL_FSYS4, 0, 1),
 };
 
-static const struct samsung_gate_clock fsys_gate_clks[] __initconst = {
+static const struct samsung_gate_clock fsys_gate_clks[] = {
 	/* ENABLE_ACLK_FSYS0 */
 	GATE(CLK_ACLK_PCIE, "aclk_pcie", "mout_aclk_fsys_200_user",
 			ENABLE_ACLK_FSYS0, 13, CLK_IGNORE_UNUSED, 0),
@@ -2329,7 +2293,7 @@ static const struct samsung_gate_clock fsys_gate_clks[] __initconst = {
 	GATE(CLK_PDMA0, "pdma0", "aclk_pdma0", ENABLE_IP_FSYS0, 0, 0, 0),
 };
 
-static const struct samsung_cmu_info fsys_cmu_info __initconst = {
+static const struct samsung_cmu_info fsys_cmu_info = {
 	.mux_clks		= fsys_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(fsys_mux_clks),
 	.gate_clks		= fsys_gate_clks,
@@ -2360,7 +2324,7 @@ static const struct samsung_cmu_info fsys_cmu_info __initconst = {
 #define DIV_ENABLE_IP_G2D1			0x0b04
 #define DIV_ENABLE_IP_G2D_SECURE_SMMU_G2D	0x0b08
 
-static const unsigned long g2d_clk_regs[] __initconst = {
+static const unsigned long g2d_clk_regs[] = {
 	MUX_SEL_G2D0,
 	MUX_SEL_ENABLE_G2D0,
 	DIV_G2D,
@@ -2381,7 +2345,7 @@ static const struct samsung_clk_reg_dump g2d_suspend_regs[] = {
 PNAME(mout_aclk_g2d_266_user_p)		= { "oscclk", "aclk_g2d_266", };
 PNAME(mout_aclk_g2d_400_user_p)		= { "oscclk", "aclk_g2d_400", };
 
-static const struct samsung_mux_clock g2d_mux_clks[] __initconst = {
+static const struct samsung_mux_clock g2d_mux_clks[] = {
 	/* MUX_SEL_G2D0 */
 	MUX(CLK_MUX_ACLK_G2D_266_USER, "mout_aclk_g2d_266_user",
 			mout_aclk_g2d_266_user_p, MUX_SEL_G2D0, 4, 1),
@@ -2389,13 +2353,13 @@ static const struct samsung_mux_clock g2d_mux_clks[] __initconst = {
 			mout_aclk_g2d_400_user_p, MUX_SEL_G2D0, 0, 1),
 };
 
-static const struct samsung_div_clock g2d_div_clks[] __initconst = {
+static const struct samsung_div_clock g2d_div_clks[] = {
 	/* DIV_G2D */
 	DIV(CLK_DIV_PCLK_G2D, "div_pclk_g2d", "mout_aclk_g2d_266_user",
 			DIV_G2D, 0, 2),
 };
 
-static const struct samsung_gate_clock g2d_gate_clks[] __initconst = {
+static const struct samsung_gate_clock g2d_gate_clks[] = {
 	/* DIV_ENABLE_ACLK_G2D */
 	GATE(CLK_ACLK_SMMU_MDMA1, "aclk_smmu_mdma1", "mout_aclk_g2d_266_user",
 			DIV_ENABLE_ACLK_G2D, 12, 0, 0),
@@ -2452,7 +2416,7 @@ static const struct samsung_gate_clock g2d_gate_clks[] __initconst = {
 		DIV_ENABLE_PCLK_G2D_SECURE_SMMU_G2D, 0, 0, 0),
 };
 
-static const struct samsung_cmu_info g2d_cmu_info __initconst = {
+static const struct samsung_cmu_info g2d_cmu_info = {
 	.mux_clks		= g2d_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(g2d_mux_clks),
 	.div_clks		= g2d_div_clks,
@@ -2503,7 +2467,7 @@ static const struct samsung_cmu_info g2d_cmu_info __initconst = {
 #define CLKOUT_CMU_DISP			0x0c00
 #define CLKOUT_CMU_DISP_DIV_STAT	0x0c04
 
-static const unsigned long disp_clk_regs[] __initconst = {
+static const unsigned long disp_clk_regs[] = {
 	DISP_PLL_LOCK,
 	DISP_PLL_CON0,
 	DISP_PLL_CON1,
@@ -2588,12 +2552,12 @@ PNAME(mout_sclk_decon_tv_vclk_c_disp_p)	= {
 PNAME(mout_sclk_decon_tv_vclk_b_disp_p)	= { "mout_sclk_decon_tv_vclk_a_disp",
 					    "mout_sclk_decon_tv_vclk_user", };
 
-static const struct samsung_pll_clock disp_pll_clks[] __initconst = {
+static const struct samsung_pll_clock disp_pll_clks[] = {
 	PLL(pll_35xx, CLK_FOUT_DISP_PLL, "fout_disp_pll", "oscclk",
 		DISP_PLL_LOCK, DISP_PLL_CON0, exynos5433_pll_rates),
 };
 
-static const struct samsung_fixed_factor_clock disp_fixed_factor_clks[] __initconst = {
+static const struct samsung_fixed_factor_clock disp_fixed_factor_clks[] = {
 	/*
 	 * sclk_rgb_{vclk|tv_vclk} is half clock of sclk_decon_{vclk|tv_vclk}.
 	 * The divider has fixed value (2) between sclk_rgb_{vclk|tv_vclk}
@@ -2605,7 +2569,7 @@ static const struct samsung_fixed_factor_clock disp_fixed_factor_clks[] __initco
 			1, 2, 0),
 };
 
-static const struct samsung_fixed_rate_clock disp_fixed_clks[] __initconst = {
+static const struct samsung_fixed_rate_clock disp_fixed_clks[] = {
 	/* PHY clocks from MIPI_DPHY1 */
 	FRATE(0, "phyclk_mipidphy1_bitclkdiv8_phy", NULL, 0, 188000000),
 	FRATE(0, "phyclk_mipidphy1_rxclkesc0_phy", NULL, 0, 100000000),
@@ -2621,7 +2585,7 @@ static const struct samsung_fixed_rate_clock disp_fixed_clks[] __initconst = {
 			NULL, 0, 166000000),
 };
 
-static const struct samsung_mux_clock disp_mux_clks[] __initconst = {
+static const struct samsung_mux_clock disp_mux_clks[] = {
 	/* MUX_SEL_DISP0 */
 	MUX(CLK_MOUT_DISP_PLL, "mout_disp_pll", mout_disp_pll_p, MUX_SEL_DISP0,
 			0, 1),
@@ -2696,7 +2660,7 @@ static const struct samsung_mux_clock disp_mux_clks[] __initconst = {
 			mout_sclk_decon_vclk_p, MUX_SEL_DISP4, 0, 1),
 };
 
-static const struct samsung_div_clock disp_div_clks[] __initconst = {
+static const struct samsung_div_clock disp_div_clks[] = {
 	/* DIV_DISP */
 	DIV(CLK_DIV_SCLK_DSIM1_DISP, "div_sclk_dsim1_disp",
 			"mout_sclk_dsim1_b_disp", DIV_DISP, 24, 3),
@@ -2714,7 +2678,7 @@ static const struct samsung_div_clock disp_div_clks[] __initconst = {
 			DIV_DISP, 0, 2),
 };
 
-static const struct samsung_gate_clock disp_gate_clks[] __initconst = {
+static const struct samsung_gate_clock disp_gate_clks[] = {
 	/* ENABLE_ACLK_DISP0 */
 	GATE(CLK_ACLK_DECON_TV, "aclk_decon_tv", "mout_aclk_disp_333_user",
 			ENABLE_ACLK_DISP0, 2, 0, 0),
@@ -2874,7 +2838,7 @@ static const struct samsung_gate_clock disp_gate_clks[] __initconst = {
 			"div_sclk_decon_eclk_disp", ENABLE_SCLK_DISP, 2, 0, 0),
 };
 
-static const struct samsung_cmu_info disp_cmu_info __initconst = {
+static const struct samsung_cmu_info disp_cmu_info = {
 	.pll_clks		= disp_pll_clks,
 	.nr_pll_clks		= ARRAY_SIZE(disp_pll_clks),
 	.mux_clks		= disp_mux_clks,
@@ -2914,7 +2878,7 @@ static const struct samsung_cmu_info disp_cmu_info __initconst = {
 #define ENABLE_IP_AUD0			0x0b00
 #define ENABLE_IP_AUD1			0x0b04
 
-static const unsigned long aud_clk_regs[] __initconst = {
+static const unsigned long aud_clk_regs[] = {
 	MUX_SEL_AUD0,
 	MUX_SEL_AUD1,
 	MUX_ENABLE_AUD0,
@@ -2938,13 +2902,13 @@ static const struct samsung_clk_reg_dump aud_suspend_regs[] = {
 PNAME(mout_aud_pll_user_aud_p)	= { "oscclk", "fout_aud_pll", };
 PNAME(mout_sclk_aud_pcm_p)	= { "mout_aud_pll_user", "ioclk_audiocdclk0",};
 
-static const struct samsung_fixed_rate_clock aud_fixed_clks[] __initconst = {
+static const struct samsung_fixed_rate_clock aud_fixed_clks[] = {
 	FRATE(0, "ioclk_jtag_tclk", NULL, 0, 33000000),
 	FRATE(0, "ioclk_slimbus_clk", NULL, 0, 25000000),
 	FRATE(0, "ioclk_i2s_bclk", NULL, 0, 50000000),
 };
 
-static const struct samsung_mux_clock aud_mux_clks[] __initconst = {
+static const struct samsung_mux_clock aud_mux_clks[] = {
 	/* MUX_SEL_AUD0 */
 	MUX(CLK_MOUT_AUD_PLL_USER, "mout_aud_pll_user",
 			mout_aud_pll_user_aud_p, MUX_SEL_AUD0, 0, 1),
@@ -2956,7 +2920,7 @@ static const struct samsung_mux_clock aud_mux_clks[] __initconst = {
 			MUX_SEL_AUD1, 0, 1),
 };
 
-static const struct samsung_div_clock aud_div_clks[] __initconst = {
+static const struct samsung_div_clock aud_div_clks[] = {
 	/* DIV_AUD0 */
 	DIV(CLK_DIV_ATCLK_AUD, "div_atclk_aud", "div_aud_ca5", DIV_AUD0,
 			12, 4),
@@ -2978,7 +2942,7 @@ static const struct samsung_div_clock aud_div_clks[] __initconst = {
 			DIV_AUD1, 0, 4),
 };
 
-static const struct samsung_gate_clock aud_gate_clks[] __initconst = {
+static const struct samsung_gate_clock aud_gate_clks[] = {
 	/* ENABLE_ACLK_AUD */
 	GATE(CLK_ACLK_INTR_CTRL, "aclk_intr_ctrl", "div_aclk_aud",
 			ENABLE_ACLK_AUD, 12, 0, 0),
@@ -3048,7 +3012,7 @@ static const struct samsung_gate_clock aud_gate_clks[] __initconst = {
 			ENABLE_SCLK_AUD1, 0, CLK_IGNORE_UNUSED, 0),
 };
 
-static const struct samsung_cmu_info aud_cmu_info __initconst = {
+static const struct samsung_cmu_info aud_cmu_info = {
 	.mux_clks		= aud_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(aud_mux_clks),
 	.div_clks		= aud_div_clks,
@@ -3089,24 +3053,24 @@ PNAME(mout_aclk_bus2_400_p)	= { "oscclk", "aclk_bus2_400", };
 	ENABLE_IP_BUS0,		\
 	ENABLE_IP_BUS1
 
-static const unsigned long bus01_clk_regs[] __initconst = {
+static const unsigned long bus01_clk_regs[] = {
 	CMU_BUS_COMMON_CLK_REGS,
 };
 
-static const unsigned long bus2_clk_regs[] __initconst = {
+static const unsigned long bus2_clk_regs[] = {
 	MUX_SEL_BUS2,
 	MUX_ENABLE_BUS2,
 	CMU_BUS_COMMON_CLK_REGS,
 };
 
-static const struct samsung_div_clock bus0_div_clks[] __initconst = {
+static const struct samsung_div_clock bus0_div_clks[] = {
 	/* DIV_BUS0 */
 	DIV(CLK_DIV_PCLK_BUS_133, "div_pclk_bus0_133", "aclk_bus0_400",
 			DIV_BUS, 0, 3),
 };
 
 /* CMU_BUS0 clocks */
-static const struct samsung_gate_clock bus0_gate_clks[] __initconst = {
+static const struct samsung_gate_clock bus0_gate_clks[] = {
 	/* ENABLE_ACLK_BUS0 */
 	GATE(CLK_ACLK_AHB2APB_BUSP, "aclk_ahb2apb_bus0p", "div_pclk_bus0_133",
 			ENABLE_ACLK_BUS, 4, CLK_IGNORE_UNUSED, 0),
@@ -3125,13 +3089,13 @@ static const struct samsung_gate_clock bus0_gate_clks[] __initconst = {
 };
 
 /* CMU_BUS1 clocks */
-static const struct samsung_div_clock bus1_div_clks[] __initconst = {
+static const struct samsung_div_clock bus1_div_clks[] = {
 	/* DIV_BUS1 */
 	DIV(CLK_DIV_PCLK_BUS_133, "div_pclk_bus1_133", "aclk_bus1_400",
 			DIV_BUS, 0, 3),
 };
 
-static const struct samsung_gate_clock bus1_gate_clks[] __initconst = {
+static const struct samsung_gate_clock bus1_gate_clks[] = {
 	/* ENABLE_ACLK_BUS1 */
 	GATE(CLK_ACLK_AHB2APB_BUSP, "aclk_ahb2apb_bus1p", "div_pclk_bus1_133",
 			ENABLE_ACLK_BUS, 4, CLK_IGNORE_UNUSED, 0),
@@ -3150,19 +3114,19 @@ static const struct samsung_gate_clock bus1_gate_clks[] __initconst = {
 };
 
 /* CMU_BUS2 clocks */
-static const struct samsung_mux_clock bus2_mux_clks[] __initconst = {
+static const struct samsung_mux_clock bus2_mux_clks[] = {
 	/* MUX_SEL_BUS2 */
 	MUX(CLK_MOUT_ACLK_BUS2_400_USER, "mout_aclk_bus2_400_user",
 			mout_aclk_bus2_400_p, MUX_SEL_BUS2, 0, 1),
 };
 
-static const struct samsung_div_clock bus2_div_clks[] __initconst = {
+static const struct samsung_div_clock bus2_div_clks[] = {
 	/* DIV_BUS2 */
 	DIV(CLK_DIV_PCLK_BUS_133, "div_pclk_bus2_133",
 			"mout_aclk_bus2_400_user", DIV_BUS, 0, 3),
 };
 
-static const struct samsung_gate_clock bus2_gate_clks[] __initconst = {
+static const struct samsung_gate_clock bus2_gate_clks[] = {
 	/* ENABLE_ACLK_BUS2 */
 	GATE(CLK_ACLK_AHB2APB_BUSP, "aclk_ahb2apb_bus2p", "div_pclk_bus2_133",
 			ENABLE_ACLK_BUS, 3, CLK_IGNORE_UNUSED, 0),
@@ -3191,19 +3155,19 @@ static const struct samsung_gate_clock bus2_gate_clks[] __initconst = {
 	.nr_gate_clks		= ARRAY_SIZE(bus##id##_gate_clks),	\
 	.nr_clk_ids		= BUSx_NR_CLK
 
-static const struct samsung_cmu_info bus0_cmu_info __initconst = {
+static const struct samsung_cmu_info bus0_cmu_info = {
 	CMU_BUS_INFO_CLKS(0),
 	.clk_regs		= bus01_clk_regs,
 	.nr_clk_regs		= ARRAY_SIZE(bus01_clk_regs),
 };
 
-static const struct samsung_cmu_info bus1_cmu_info __initconst = {
+static const struct samsung_cmu_info bus1_cmu_info = {
 	CMU_BUS_INFO_CLKS(1),
 	.clk_regs		= bus01_clk_regs,
 	.nr_clk_regs		= ARRAY_SIZE(bus01_clk_regs),
 };
 
-static const struct samsung_cmu_info bus2_cmu_info __initconst = {
+static const struct samsung_cmu_info bus2_cmu_info = {
 	CMU_BUS_INFO_CLKS(2),
 	.mux_clks		= bus2_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(bus2_mux_clks),
@@ -3211,19 +3175,6 @@ static const struct samsung_cmu_info bus2_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(bus2_clk_regs),
 };
 
-#define exynos5433_cmu_bus_init(id)					\
-static void __init exynos5433_cmu_bus##id##_init(struct device_node *np)\
-{									\
-	samsung_cmu_register_one(np, &bus##id##_cmu_info);		\
-}									\
-CLK_OF_DECLARE(exynos5433_cmu_bus##id,					\
-		"samsung,exynos5433-cmu-bus"#id,			\
-		exynos5433_cmu_bus##id##_init)
-
-exynos5433_cmu_bus_init(0);
-exynos5433_cmu_bus_init(1);
-exynos5433_cmu_bus_init(2);
-
 /*
  * Register offset definitions for CMU_G3D
  */
@@ -3247,7 +3198,7 @@ exynos5433_cmu_bus_init(2);
 #define CLKOUT_CMU_G3D_DIV_STAT		0x0c04
 #define CLK_STOPCTRL			0x1000
 
-static const unsigned long g3d_clk_regs[] __initconst = {
+static const unsigned long g3d_clk_regs[] = {
 	G3D_PLL_LOCK,
 	G3D_PLL_CON0,
 	G3D_PLL_CON1,
@@ -3274,12 +3225,12 @@ static const struct samsung_clk_reg_dump g3d_suspend_regs[] = {
 PNAME(mout_aclk_g3d_400_p)	= { "mout_g3d_pll", "aclk_g3d_400", };
 PNAME(mout_g3d_pll_p)		= { "oscclk", "fout_g3d_pll", };
 
-static const struct samsung_pll_clock g3d_pll_clks[] __initconst = {
+static const struct samsung_pll_clock g3d_pll_clks[] = {
 	PLL(pll_35xx, CLK_FOUT_G3D_PLL, "fout_g3d_pll", "oscclk",
 		G3D_PLL_LOCK, G3D_PLL_CON0, exynos5433_pll_rates),
 };
 
-static const struct samsung_mux_clock g3d_mux_clks[] __initconst = {
+static const struct samsung_mux_clock g3d_mux_clks[] = {
 	/* MUX_SEL_G3D */
 	MUX_F(CLK_MOUT_ACLK_G3D_400, "mout_aclk_g3d_400", mout_aclk_g3d_400_p,
 			MUX_SEL_G3D, 8, 1, CLK_SET_RATE_PARENT, 0),
@@ -3287,7 +3238,7 @@ static const struct samsung_mux_clock g3d_mux_clks[] __initconst = {
 			MUX_SEL_G3D, 0, 1, CLK_SET_RATE_PARENT, 0),
 };
 
-static const struct samsung_div_clock g3d_div_clks[] __initconst = {
+static const struct samsung_div_clock g3d_div_clks[] = {
 	/* DIV_G3D */
 	DIV(CLK_DIV_SCLK_HPM_G3D, "div_sclk_hpm_g3d", "mout_g3d_pll", DIV_G3D,
 			8, 2),
@@ -3297,7 +3248,7 @@ static const struct samsung_div_clock g3d_div_clks[] __initconst = {
 			0, 3, CLK_SET_RATE_PARENT, 0),
 };
 
-static const struct samsung_gate_clock g3d_gate_clks[] __initconst = {
+static const struct samsung_gate_clock g3d_gate_clks[] = {
 	/* ENABLE_ACLK_G3D */
 	GATE(CLK_ACLK_BTS_G3D1, "aclk_bts_g3d1", "div_aclk_g3d",
 			ENABLE_ACLK_G3D, 7, 0, 0),
@@ -3331,7 +3282,7 @@ static const struct samsung_gate_clock g3d_gate_clks[] __initconst = {
 			ENABLE_SCLK_G3D, 0, 0, 0),
 };
 
-static const struct samsung_cmu_info g3d_cmu_info __initconst = {
+static const struct samsung_cmu_info g3d_cmu_info = {
 	.pll_clks		= g3d_pll_clks,
 	.nr_pll_clks		= ARRAY_SIZE(g3d_pll_clks),
 	.mux_clks		= g3d_mux_clks,
@@ -3368,7 +3319,7 @@ static const struct samsung_cmu_info g3d_cmu_info __initconst = {
 #define ENABLE_IP_GSCL_SECURE_SMMU_GSCL1	0x0b0c
 #define ENABLE_IP_GSCL_SECURE_SMMU_GSCL2	0x0b10
 
-static const unsigned long gscl_clk_regs[] __initconst = {
+static const unsigned long gscl_clk_regs[] = {
 	MUX_SEL_GSCL,
 	MUX_ENABLE_GSCL,
 	ENABLE_ACLK_GSCL,
@@ -3396,7 +3347,7 @@ static const struct samsung_clk_reg_dump gscl_suspend_regs[] = {
 PNAME(aclk_gscl_111_user_p)	= { "oscclk", "aclk_gscl_111", };
 PNAME(aclk_gscl_333_user_p)	= { "oscclk", "aclk_gscl_333", };
 
-static const struct samsung_mux_clock gscl_mux_clks[] __initconst = {
+static const struct samsung_mux_clock gscl_mux_clks[] = {
 	/* MUX_SEL_GSCL */
 	MUX(CLK_MOUT_ACLK_GSCL_111_USER, "mout_aclk_gscl_111_user",
 			aclk_gscl_111_user_p, MUX_SEL_GSCL, 4, 1),
@@ -3404,7 +3355,7 @@ static const struct samsung_mux_clock gscl_mux_clks[] __initconst = {
 			aclk_gscl_333_user_p, MUX_SEL_GSCL, 0, 1),
 };
 
-static const struct samsung_gate_clock gscl_gate_clks[] __initconst = {
+static const struct samsung_gate_clock gscl_gate_clks[] = {
 	/* ENABLE_ACLK_GSCL */
 	GATE(CLK_ACLK_BTS_GSCL2, "aclk_bts_gscl2", "mout_aclk_gscl_333_user",
 			ENABLE_ACLK_GSCL, 11, 0, 0),
@@ -3478,7 +3429,7 @@ static const struct samsung_gate_clock gscl_gate_clks[] __initconst = {
 		ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL2, 0, 0, 0),
 };
 
-static const struct samsung_cmu_info gscl_cmu_info __initconst = {
+static const struct samsung_cmu_info gscl_cmu_info = {
 	.mux_clks		= gscl_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(gscl_mux_clks),
 	.gate_clks		= gscl_gate_clks,
@@ -3527,7 +3478,7 @@ static const struct samsung_cmu_info gscl_cmu_info __initconst = {
 #define APOLLO_INTR_SPREAD_USE_STANDBYWFI	0x1084
 #define APOLLO_INTR_SPREAD_BLOCKING_DURATION	0x1088
 
-static const unsigned long apollo_clk_regs[] __initconst = {
+static const unsigned long apollo_clk_regs[] = {
 	APOLLO_PLL_LOCK,
 	APOLLO_PLL_CON0,
 	APOLLO_PLL_CON1,
@@ -3562,12 +3513,12 @@ PNAME(mout_bus_pll_apollo_user_p)	= { "oscclk", "sclk_bus_pll_apollo", };
 PNAME(mout_apollo_p)			= { "mout_apollo_pll",
 					    "mout_bus_pll_apollo_user", };
 
-static const struct samsung_pll_clock apollo_pll_clks[] __initconst = {
+static const struct samsung_pll_clock apollo_pll_clks[] = {
 	PLL(pll_35xx, CLK_FOUT_APOLLO_PLL, "fout_apollo_pll", "oscclk",
 		APOLLO_PLL_LOCK, APOLLO_PLL_CON0, exynos5433_pll_rates),
 };
 
-static const struct samsung_mux_clock apollo_mux_clks[] __initconst = {
+static const struct samsung_mux_clock apollo_mux_clks[] = {
 	/* MUX_SEL_APOLLO0 */
 	MUX_F(CLK_MOUT_APOLLO_PLL, "mout_apollo_pll", mout_apollo_pll_p,
 			MUX_SEL_APOLLO0, 0, 1, CLK_SET_RATE_PARENT |
@@ -3582,7 +3533,7 @@ static const struct samsung_mux_clock apollo_mux_clks[] __initconst = {
 			0, 1, CLK_SET_RATE_PARENT, 0),
 };
 
-static const struct samsung_div_clock apollo_div_clks[] __initconst = {
+static const struct samsung_div_clock apollo_div_clks[] = {
 	/* DIV_APOLLO0 */
 	DIV_F(CLK_DIV_CNTCLK_APOLLO, "div_cntclk_apollo", "div_apollo2",
 			DIV_APOLLO0, 24, 3, CLK_GET_RATE_NOCACHE,
@@ -3613,7 +3564,7 @@ static const struct samsung_div_clock apollo_div_clks[] __initconst = {
 			CLK_DIVIDER_READ_ONLY),
 };
 
-static const struct samsung_gate_clock apollo_gate_clks[] __initconst = {
+static const struct samsung_gate_clock apollo_gate_clks[] = {
 	/* ENABLE_ACLK_APOLLO */
 	GATE(CLK_ACLK_ASATBSLV_APOLLO_3_CSSYS, "aclk_asatbslv_apollo_3_cssys",
 			"div_atclk_apollo", ENABLE_ACLK_APOLLO,
@@ -3661,7 +3612,7 @@ static const struct samsung_gate_clock apollo_gate_clks[] __initconst = {
 #define E5433_APOLLO_DIV1(hpm, copy) \
 		(((hpm) << 4) | ((copy) << 0))
 
-static const struct exynos_cpuclk_cfg_data exynos5433_apolloclk_d[] __initconst = {
+static const struct exynos_cpuclk_cfg_data exynos5433_apolloclk_d[] = {
 	{ 1300000, E5433_APOLLO_DIV0(3, 7, 7, 7, 2), E5433_APOLLO_DIV1(7, 1), },
 	{ 1200000, E5433_APOLLO_DIV0(3, 7, 7, 7, 2), E5433_APOLLO_DIV1(7, 1), },
 	{ 1100000, E5433_APOLLO_DIV0(3, 7, 7, 7, 2), E5433_APOLLO_DIV1(7, 1), },
@@ -3672,17 +3623,17 @@ static const struct exynos_cpuclk_cfg_data exynos5433_apolloclk_d[] __initconst
 	{  600000, E5433_APOLLO_DIV0(3, 7, 7, 7, 1), E5433_APOLLO_DIV1(7, 1), },
 	{  500000, E5433_APOLLO_DIV0(3, 7, 7, 7, 1), E5433_APOLLO_DIV1(7, 1), },
 	{  400000, E5433_APOLLO_DIV0(3, 7, 7, 7, 1), E5433_APOLLO_DIV1(7, 1), },
-	{  0 },
+	{  /* sentinel */ },
 };
 
-static const struct samsung_cpu_clock apollo_cpu_clks[] __initconst = {
+static const struct samsung_cpu_clock apollo_cpu_clks[] = {
 	CPU_CLK(CLK_SCLK_APOLLO, "apolloclk", "mout_apollo_pll",
 			"mout_bus_pll_apollo_user",
 			CLK_CPU_HAS_E5433_REGS_LAYOUT, 0x200,
 			exynos5433_apolloclk_d),
 };
 
-static const struct samsung_cmu_info apollo_cmu_info __initconst = {
+static const struct samsung_cmu_info apollo_cmu_info = {
 	.pll_clks	= apollo_pll_clks,
 	.nr_pll_clks	= ARRAY_SIZE(apollo_pll_clks),
 	.mux_clks	= apollo_mux_clks,
@@ -3734,7 +3685,7 @@ static const struct samsung_cmu_info apollo_cmu_info __initconst = {
 #define ATLAS_INTR_SPREAD_USE_STANDBYWFI	0x1084
 #define ATLAS_INTR_SPREAD_BLOCKING_DURATION	0x1088
 
-static const unsigned long atlas_clk_regs[] __initconst = {
+static const unsigned long atlas_clk_regs[] = {
 	ATLAS_PLL_LOCK,
 	ATLAS_PLL_CON0,
 	ATLAS_PLL_CON1,
@@ -3769,12 +3720,12 @@ PNAME(mout_bus_pll_atlas_user_p)	= { "oscclk", "sclk_bus_pll_atlas", };
 PNAME(mout_atlas_p)			= { "mout_atlas_pll",
 					    "mout_bus_pll_atlas_user", };
 
-static const struct samsung_pll_clock atlas_pll_clks[] __initconst = {
+static const struct samsung_pll_clock atlas_pll_clks[] = {
 	PLL(pll_35xx, CLK_FOUT_ATLAS_PLL, "fout_atlas_pll", "oscclk",
 		ATLAS_PLL_LOCK, ATLAS_PLL_CON0, exynos5433_pll_rates),
 };
 
-static const struct samsung_mux_clock atlas_mux_clks[] __initconst = {
+static const struct samsung_mux_clock atlas_mux_clks[] = {
 	/* MUX_SEL_ATLAS0 */
 	MUX_F(CLK_MOUT_ATLAS_PLL, "mout_atlas_pll", mout_atlas_pll_p,
 			MUX_SEL_ATLAS0, 0, 1, CLK_SET_RATE_PARENT |
@@ -3789,7 +3740,7 @@ static const struct samsung_mux_clock atlas_mux_clks[] __initconst = {
 			0, 1, CLK_SET_RATE_PARENT, 0),
 };
 
-static const struct samsung_div_clock atlas_div_clks[] __initconst = {
+static const struct samsung_div_clock atlas_div_clks[] = {
 	/* DIV_ATLAS0 */
 	DIV_F(CLK_DIV_CNTCLK_ATLAS, "div_cntclk_atlas", "div_atlas2",
 			DIV_ATLAS0, 24, 3, CLK_GET_RATE_NOCACHE,
@@ -3820,7 +3771,7 @@ static const struct samsung_div_clock atlas_div_clks[] __initconst = {
 			CLK_DIVIDER_READ_ONLY),
 };
 
-static const struct samsung_gate_clock atlas_gate_clks[] __initconst = {
+static const struct samsung_gate_clock atlas_gate_clks[] = {
 	/* ENABLE_ACLK_ATLAS */
 	GATE(CLK_ACLK_ATB_AUD_CSSYS, "aclk_atb_aud_cssys",
 			"div_atclk_atlas", ENABLE_ACLK_ATLAS,
@@ -3894,7 +3845,7 @@ static const struct samsung_gate_clock atlas_gate_clks[] __initconst = {
 #define E5433_ATLAS_DIV1(hpm, copy) \
 		(((hpm) << 4) | ((copy) << 0))
 
-static const struct exynos_cpuclk_cfg_data exynos5433_atlasclk_d[] __initconst = {
+static const struct exynos_cpuclk_cfg_data exynos5433_atlasclk_d[] = {
 	{ 1900000, E5433_ATLAS_DIV0(7, 7, 7, 7, 4), E5433_ATLAS_DIV1(7, 1), },
 	{ 1800000, E5433_ATLAS_DIV0(7, 7, 7, 7, 4), E5433_ATLAS_DIV1(7, 1), },
 	{ 1700000, E5433_ATLAS_DIV0(7, 7, 7, 7, 4), E5433_ATLAS_DIV1(7, 1), },
@@ -3910,17 +3861,17 @@ static const struct exynos_cpuclk_cfg_data exynos5433_atlasclk_d[] __initconst =
 	{  700000, E5433_ATLAS_DIV0(7, 7, 7, 7, 2), E5433_ATLAS_DIV1(7, 1), },
 	{  600000, E5433_ATLAS_DIV0(7, 7, 7, 7, 2), E5433_ATLAS_DIV1(7, 1), },
 	{  500000, E5433_ATLAS_DIV0(7, 7, 7, 7, 2), E5433_ATLAS_DIV1(7, 1), },
-	{  0 },
+	{  /* sentinel */ },
 };
 
-static const struct samsung_cpu_clock atlas_cpu_clks[] __initconst = {
+static const struct samsung_cpu_clock atlas_cpu_clks[] = {
 	CPU_CLK(CLK_SCLK_ATLAS, "atlasclk", "mout_atlas_pll",
 			"mout_bus_pll_atlas_user",
 			CLK_CPU_HAS_E5433_REGS_LAYOUT, 0x200,
 			exynos5433_atlasclk_d),
 };
 
-static const struct samsung_cmu_info atlas_cmu_info __initconst = {
+static const struct samsung_cmu_info atlas_cmu_info = {
 	.pll_clks	= atlas_pll_clks,
 	.nr_pll_clks	= ARRAY_SIZE(atlas_pll_clks),
 	.mux_clks	= atlas_mux_clks,
@@ -3962,7 +3913,7 @@ static const struct samsung_cmu_info atlas_cmu_info __initconst = {
 #define ENABLE_IP_MSCL_SECURE_SMMU_M2MSCALER1		0x0b0c
 #define ENABLE_IP_MSCL_SECURE_SMMU_JPEG			0x0b10
 
-static const unsigned long mscl_clk_regs[] __initconst = {
+static const unsigned long mscl_clk_regs[] = {
 	MUX_SEL_MSCL0,
 	MUX_SEL_MSCL1,
 	MUX_ENABLE_MSCL0,
@@ -3995,7 +3946,7 @@ PNAME(mout_aclk_mscl_400_user_p)	= { "oscclk", "aclk_mscl_400", };
 PNAME(mout_sclk_jpeg_p)			= { "mout_sclk_jpeg_user",
 					"mout_aclk_mscl_400_user", };
 
-static const struct samsung_mux_clock mscl_mux_clks[] __initconst = {
+static const struct samsung_mux_clock mscl_mux_clks[] = {
 	/* MUX_SEL_MSCL0 */
 	MUX(CLK_MOUT_SCLK_JPEG_USER, "mout_sclk_jpeg_user",
 			mout_sclk_jpeg_user_p, MUX_SEL_MSCL0, 4, 1),
@@ -4007,13 +3958,13 @@ static const struct samsung_mux_clock mscl_mux_clks[] __initconst = {
 			MUX_SEL_MSCL1, 0, 1),
 };
 
-static const struct samsung_div_clock mscl_div_clks[] __initconst = {
+static const struct samsung_div_clock mscl_div_clks[] = {
 	/* DIV_MSCL */
 	DIV(CLK_DIV_PCLK_MSCL, "div_pclk_mscl", "mout_aclk_mscl_400_user",
 			DIV_MSCL, 0, 3),
 };
 
-static const struct samsung_gate_clock mscl_gate_clks[] __initconst = {
+static const struct samsung_gate_clock mscl_gate_clks[] = {
 	/* ENABLE_ACLK_MSCL */
 	GATE(CLK_ACLK_BTS_JPEG, "aclk_bts_jpeg", "mout_aclk_mscl_400_user",
 			ENABLE_ACLK_MSCL, 9, 0, 0),
@@ -4091,7 +4042,7 @@ static const struct samsung_gate_clock mscl_gate_clks[] __initconst = {
 			CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
 };
 
-static const struct samsung_cmu_info mscl_cmu_info __initconst = {
+static const struct samsung_cmu_info mscl_cmu_info = {
 	.mux_clks		= mscl_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(mscl_mux_clks),
 	.div_clks		= mscl_div_clks,
@@ -4122,7 +4073,7 @@ static const struct samsung_cmu_info mscl_cmu_info __initconst = {
 #define ENABLE_IP_MFC1				0x0b04
 #define ENABLE_IP_MFC_SECURE_SMMU_MFC		0x0b08
 
-static const unsigned long mfc_clk_regs[] __initconst = {
+static const unsigned long mfc_clk_regs[] = {
 	MUX_SEL_MFC,
 	MUX_ENABLE_MFC,
 	DIV_MFC,
@@ -4141,19 +4092,19 @@ static const struct samsung_clk_reg_dump mfc_suspend_regs[] = {
 
 PNAME(mout_aclk_mfc_400_user_p)		= { "oscclk", "aclk_mfc_400", };
 
-static const struct samsung_mux_clock mfc_mux_clks[] __initconst = {
+static const struct samsung_mux_clock mfc_mux_clks[] = {
 	/* MUX_SEL_MFC */
 	MUX(CLK_MOUT_ACLK_MFC_400_USER, "mout_aclk_mfc_400_user",
 			mout_aclk_mfc_400_user_p, MUX_SEL_MFC, 0, 0),
 };
 
-static const struct samsung_div_clock mfc_div_clks[] __initconst = {
+static const struct samsung_div_clock mfc_div_clks[] = {
 	/* DIV_MFC */
 	DIV(CLK_DIV_PCLK_MFC, "div_pclk_mfc", "mout_aclk_mfc_400_user",
 			DIV_MFC, 0, 2),
 };
 
-static const struct samsung_gate_clock mfc_gate_clks[] __initconst = {
+static const struct samsung_gate_clock mfc_gate_clks[] = {
 	/* ENABLE_ACLK_MFC */
 	GATE(CLK_ACLK_BTS_MFC_1, "aclk_bts_mfc_1", "mout_aclk_mfc_400_user",
 			ENABLE_ACLK_MFC, 6, 0, 0),
@@ -4199,7 +4150,7 @@ static const struct samsung_gate_clock mfc_gate_clks[] __initconst = {
 			0, CLK_IGNORE_UNUSED, 0),
 };
 
-static const struct samsung_cmu_info mfc_cmu_info __initconst = {
+static const struct samsung_cmu_info mfc_cmu_info = {
 	.mux_clks		= mfc_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(mfc_mux_clks),
 	.div_clks		= mfc_div_clks,
@@ -4230,7 +4181,7 @@ static const struct samsung_cmu_info mfc_cmu_info __initconst = {
 #define ENABLE_IP_HEVC1				0x0b04
 #define ENABLE_IP_HEVC_SECURE_SMMU_HEVC		0x0b08
 
-static const unsigned long hevc_clk_regs[] __initconst = {
+static const unsigned long hevc_clk_regs[] = {
 	MUX_SEL_HEVC,
 	MUX_ENABLE_HEVC,
 	DIV_HEVC,
@@ -4249,19 +4200,19 @@ static const struct samsung_clk_reg_dump hevc_suspend_regs[] = {
 
 PNAME(mout_aclk_hevc_400_user_p)	= { "oscclk", "aclk_hevc_400", };
 
-static const struct samsung_mux_clock hevc_mux_clks[] __initconst = {
+static const struct samsung_mux_clock hevc_mux_clks[] = {
 	/* MUX_SEL_HEVC */
 	MUX(CLK_MOUT_ACLK_HEVC_400_USER, "mout_aclk_hevc_400_user",
 			mout_aclk_hevc_400_user_p, MUX_SEL_HEVC, 0, 0),
 };
 
-static const struct samsung_div_clock hevc_div_clks[] __initconst = {
+static const struct samsung_div_clock hevc_div_clks[] = {
 	/* DIV_HEVC */
 	DIV(CLK_DIV_PCLK_HEVC, "div_pclk_hevc", "mout_aclk_hevc_400_user",
 			DIV_HEVC, 0, 2),
 };
 
-static const struct samsung_gate_clock hevc_gate_clks[] __initconst = {
+static const struct samsung_gate_clock hevc_gate_clks[] = {
 	/* ENABLE_ACLK_HEVC */
 	GATE(CLK_ACLK_BTS_HEVC_1, "aclk_bts_hevc_1", "mout_aclk_hevc_400_user",
 			ENABLE_ACLK_HEVC, 6, 0, 0),
@@ -4309,7 +4260,7 @@ static const struct samsung_gate_clock hevc_gate_clks[] __initconst = {
 			0, CLK_IGNORE_UNUSED, 0),
 };
 
-static const struct samsung_cmu_info hevc_cmu_info __initconst = {
+static const struct samsung_cmu_info hevc_cmu_info = {
 	.mux_clks		= hevc_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(hevc_mux_clks),
 	.div_clks		= hevc_div_clks,
@@ -4342,7 +4293,7 @@ static const struct samsung_cmu_info hevc_cmu_info __initconst = {
 #define ENABLE_IP_ISP2			0x0b08
 #define ENABLE_IP_ISP3			0x0b0c
 
-static const unsigned long isp_clk_regs[] __initconst = {
+static const unsigned long isp_clk_regs[] = {
 	MUX_SEL_ISP,
 	MUX_ENABLE_ISP,
 	DIV_ISP,
@@ -4364,7 +4315,7 @@ static const struct samsung_clk_reg_dump isp_suspend_regs[] = {
 PNAME(mout_aclk_isp_dis_400_user_p)	= { "oscclk", "aclk_isp_dis_400", };
 PNAME(mout_aclk_isp_400_user_p)		= { "oscclk", "aclk_isp_400", };
 
-static const struct samsung_mux_clock isp_mux_clks[] __initconst = {
+static const struct samsung_mux_clock isp_mux_clks[] = {
 	/* MUX_SEL_ISP */
 	MUX(CLK_MOUT_ACLK_ISP_DIS_400_USER, "mout_aclk_isp_dis_400_user",
 			mout_aclk_isp_dis_400_user_p, MUX_SEL_ISP, 4, 0),
@@ -4372,7 +4323,7 @@ static const struct samsung_mux_clock isp_mux_clks[] __initconst = {
 			mout_aclk_isp_400_user_p, MUX_SEL_ISP, 0, 0),
 };
 
-static const struct samsung_div_clock isp_div_clks[] __initconst = {
+static const struct samsung_div_clock isp_div_clks[] = {
 	/* DIV_ISP */
 	DIV(CLK_DIV_PCLK_ISP_DIS, "div_pclk_isp_dis",
 			"mout_aclk_isp_dis_400_user", DIV_ISP, 12, 3),
@@ -4384,7 +4335,7 @@ static const struct samsung_div_clock isp_div_clks[] __initconst = {
 			"mout_aclk_isp_400_user", DIV_ISP, 0, 3),
 };
 
-static const struct samsung_gate_clock isp_gate_clks[] __initconst = {
+static const struct samsung_gate_clock isp_gate_clks[] = {
 	/* ENABLE_ACLK_ISP0 */
 	GATE(CLK_ACLK_ISP_D_GLUE, "aclk_isp_d_glue", "mout_aclk_isp_400_user",
 			ENABLE_ACLK_ISP0, 6, CLK_IGNORE_UNUSED, 0),
@@ -4562,7 +4513,7 @@ static const struct samsung_gate_clock isp_gate_clks[] __initconst = {
 			0, CLK_IGNORE_UNUSED, 0),
 };
 
-static const struct samsung_cmu_info isp_cmu_info __initconst = {
+static const struct samsung_cmu_info isp_cmu_info = {
 	.mux_clks		= isp_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(isp_mux_clks),
 	.div_clks		= isp_div_clks,
@@ -4614,7 +4565,7 @@ static const struct samsung_cmu_info isp_cmu_info __initconst = {
 #define ENABLE_IP_CAM02			0X0b08
 #define ENABLE_IP_CAM03			0X0b0C
 
-static const unsigned long cam0_clk_regs[] __initconst = {
+static const unsigned long cam0_clk_regs[] = {
 	MUX_SEL_CAM00,
 	MUX_SEL_CAM01,
 	MUX_SEL_CAM02,
@@ -4707,14 +4658,14 @@ PNAME(mout_sclk_pixelasync_lite_c_init_a_p) = {
 					"mout_aclk_cam0_552_user",
 					"mout_aclk_cam0_400_user", };
 
-static const struct samsung_fixed_rate_clock cam0_fixed_clks[] __initconst = {
+static const struct samsung_fixed_rate_clock cam0_fixed_clks[] = {
 	FRATE(CLK_PHYCLK_RXBYTEECLKHS0_S4_PHY, "phyclk_rxbyteclkhs0_s4_phy",
 			NULL, 0, 100000000),
 	FRATE(CLK_PHYCLK_RXBYTEECLKHS0_S2A_PHY, "phyclk_rxbyteclkhs0_s2a_phy",
 			NULL, 0, 100000000),
 };
 
-static const struct samsung_mux_clock cam0_mux_clks[] __initconst = {
+static const struct samsung_mux_clock cam0_mux_clks[] = {
 	/* MUX_SEL_CAM00 */
 	MUX(CLK_MOUT_ACLK_CAM0_333_USER, "mout_aclk_cam0_333_user",
 			mout_aclk_cam0_333_user_p, MUX_SEL_CAM00, 8, 1),
@@ -4788,7 +4739,7 @@ static const struct samsung_mux_clock cam0_mux_clks[] __initconst = {
 			MUX_SEL_CAM04, 0, 1),
 };
 
-static const struct samsung_div_clock cam0_div_clks[] __initconst = {
+static const struct samsung_div_clock cam0_div_clks[] = {
 	/* DIV_CAM00 */
 	DIV(CLK_DIV_PCLK_CAM0_50, "div_pclk_cam0_50", "div_aclk_cam0_200",
 			DIV_CAM00, 8, 2),
@@ -4835,7 +4786,7 @@ static const struct samsung_div_clock cam0_div_clks[] __initconst = {
 			"mout_sclk_pixelasync_lite_c_init_b", DIV_CAM03, 0, 3),
 };
 
-static const struct samsung_gate_clock cam0_gate_clks[] __initconst = {
+static const struct samsung_gate_clock cam0_gate_clks[] = {
 	/* ENABLE_ACLK_CAM00 */
 	GATE(CLK_ACLK_CSIS1, "aclk_csis1", "div_aclk_csis1", ENABLE_ACLK_CAM00,
 			6, 0, 0),
@@ -5042,7 +4993,7 @@ static const struct samsung_gate_clock cam0_gate_clks[] __initconst = {
 			ENABLE_SCLK_CAM0, 0, 0, 0),
 };
 
-static const struct samsung_cmu_info cam0_cmu_info __initconst = {
+static const struct samsung_cmu_info cam0_cmu_info = {
 	.mux_clks		= cam0_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(cam0_mux_clks),
 	.div_clks		= cam0_div_clks,
@@ -5085,7 +5036,7 @@ static const struct samsung_cmu_info cam0_cmu_info __initconst = {
 #define ENABLE_IP_CAM11			0X0b04
 #define ENABLE_IP_CAM12			0X0b08
 
-static const unsigned long cam1_clk_regs[] __initconst = {
+static const unsigned long cam1_clk_regs[] = {
 	MUX_SEL_CAM10,
 	MUX_SEL_CAM11,
 	MUX_SEL_CAM12,
@@ -5137,12 +5088,12 @@ PNAME(mout_aclk_lite_c_b_p)		= { "mout_aclk_lite_c_a",
 PNAME(mout_aclk_lite_c_a_p)		= { "mout_aclk_cam1_552_user",
 					    "mout_aclk_cam1_400_user", };
 
-static const struct samsung_fixed_rate_clock cam1_fixed_clks[] __initconst = {
+static const struct samsung_fixed_rate_clock cam1_fixed_clks[] = {
 	FRATE(CLK_PHYCLK_RXBYTEECLKHS0_S2B, "phyclk_rxbyteclkhs0_s2b_phy", NULL,
 			0, 100000000),
 };
 
-static const struct samsung_mux_clock cam1_mux_clks[] __initconst = {
+static const struct samsung_mux_clock cam1_mux_clks[] = {
 	/* MUX_SEL_CAM10 */
 	MUX(CLK_MOUT_SCLK_ISP_UART_USER, "mout_sclk_isp_uart_user",
 			mout_sclk_isp_uart_user_p, MUX_SEL_CAM10, 20, 1),
@@ -5178,7 +5129,7 @@ static const struct samsung_mux_clock cam1_mux_clks[] __initconst = {
 			MUX_SEL_CAM12, 0, 1),
 };
 
-static const struct samsung_div_clock cam1_div_clks[] __initconst = {
+static const struct samsung_div_clock cam1_div_clks[] = {
 	/* DIV_CAM10 */
 	DIV(CLK_DIV_SCLK_ISP_MPWM, "div_sclk_isp_mpwm",
 			"div_pclk_cam1_83", DIV_CAM10, 16, 2),
@@ -5202,7 +5153,7 @@ static const struct samsung_div_clock cam1_div_clks[] __initconst = {
 			DIV_CAM11, 0, 3),
 };
 
-static const struct samsung_gate_clock cam1_gate_clks[] __initconst = {
+static const struct samsung_gate_clock cam1_gate_clks[] = {
 	/* ENABLE_ACLK_CAM10 */
 	GATE(CLK_ACLK_ISP_GIC, "aclk_isp_gic", "mout_aclk_cam1_333_user",
 			ENABLE_ACLK_CAM10, 4, 0, 0),
@@ -5417,7 +5368,7 @@ static const struct samsung_gate_clock cam1_gate_clks[] __initconst = {
 			ENABLE_SCLK_CAM1, 0, 0, 0),
 };
 
-static const struct samsung_cmu_info cam1_cmu_info __initconst = {
+static const struct samsung_cmu_info cam1_cmu_info = {
 	.mux_clks		= cam1_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(cam1_mux_clks),
 	.div_clks		= cam1_div_clks,
@@ -5440,12 +5391,12 @@ static const struct samsung_cmu_info cam1_cmu_info __initconst = {
 #define ENABLE_ACLK_IMEM_SLIMSSS		0x080c
 #define ENABLE_PCLK_IMEM_SLIMSSS		0x0908
 
-static const unsigned long imem_clk_regs[] __initconst = {
+static const unsigned long imem_clk_regs[] = {
 	ENABLE_ACLK_IMEM_SLIMSSS,
 	ENABLE_PCLK_IMEM_SLIMSSS,
 };
 
-static const struct samsung_gate_clock imem_gate_clks[] __initconst = {
+static const struct samsung_gate_clock imem_gate_clks[] = {
 	/* ENABLE_ACLK_IMEM_SLIMSSS */
 	GATE(CLK_ACLK_SLIMSSS, "aclk_slimsss", "aclk_imem_sssx_266",
 			ENABLE_ACLK_IMEM_SLIMSSS, 0, CLK_IGNORE_UNUSED, 0),
@@ -5455,7 +5406,7 @@ static const struct samsung_gate_clock imem_gate_clks[] __initconst = {
 			ENABLE_PCLK_IMEM_SLIMSSS, 0, CLK_IGNORE_UNUSED, 0),
 };
 
-static const struct samsung_cmu_info imem_cmu_info __initconst = {
+static const struct samsung_cmu_info imem_cmu_info = {
 	.gate_clks		= imem_gate_clks,
 	.nr_gate_clks		= ARRAY_SIZE(imem_gate_clks),
 	.nr_clk_ids		= IMEM_NR_CLK,
@@ -5520,7 +5471,7 @@ static int __maybe_unused exynos5433_cmu_resume(struct device *dev)
 	return 0;
 }
 
-static int __init exynos5433_cmu_probe(struct platform_device *pdev)
+static int exynos5433_cmu_probe(struct platform_device *pdev)
 {
 	const struct samsung_cmu_info *info;
 	struct exynos5433_cmu_data *data;
@@ -5663,11 +5614,35 @@ static const struct of_device_id exynos5433_cmu_of_match[] = {
 		.compatible = "samsung,exynos5433-cmu-imem",
 		.data = &imem_cmu_info,
 	}, {
-		.compatible = "samsung,exynos5433-cmu-atlas",
-		.data = &atlas_cmu_info,
+		.compatible = "samsung,exynos5433-cmu-top",
+		.data = &top_cmu_info
+	}, {
+		.compatible = "samsung,exynos5433-cmu-cpif",
+		.data = &cpif_cmu_info
+	}, {
+		.compatible = "samsung,exynos5433-cmu-mif",
+		.data = &mif_cmu_info
+	}, {
+		.compatible = "samsung,exynos5433-cmu-peric",
+		.data = &peric_cmu_info,
+	}, {
+		.compatible = "samsung,exynos5433-cmu-peris",
+		.data = &peris_cmu_info,
+	}, {
+		.compatible = "samsung,exynos5433-cmu-bus0",
+		.data = &bus0_cmu_info,
+	}, {
+		.compatible = "samsung,exynos5433-cmu-bus1",
+		.data = &bus1_cmu_info,
+	}, {
+		.compatible = "samsung,exynos5433-cmu-bus2",
+		.data = &bus2_cmu_info,
 	}, {
 		.compatible = "samsung,exynos5433-cmu-apollo",
 		.data = &apollo_cmu_info,
+	}, {
+		.compatible = "samsung,exynos5433-cmu-atlas",
+		.data = &atlas_cmu_info,
 	}, {
 	},
 };
@@ -5689,8 +5664,8 @@ static struct platform_driver exynos5433_cmu_driver __refdata = {
 	.probe = exynos5433_cmu_probe,
 };
 
-static int __init exynos5433_cmu_init(void)
-{
-	return platform_driver_register(&exynos5433_cmu_driver);
-}
-core_initcall(exynos5433_cmu_init);
+module_platform_driver(exynos5433_cmu_driver);
+
+MODULE_AUTHOR("Chanwoo Choi <cw00.choi@samsung.com>");
+MODULE_DESCRIPTION("Samsung Exynos5433 ARMv8-family clock driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/clk/samsung/clk-exynos7.c b/drivers/clk/samsung/clk-exynos7.c
index 4a5d2a914bd6..d2cdd3eec190 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -6,6 +6,9 @@
 
 #include <linux/clk-provider.h>
 #include <linux/of.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
 
 #include "clk.h"
 #include <dt-bindings/clock/exynos7-clk.h>
@@ -183,7 +186,7 @@ static const struct samsung_pll_clock topc_pll_clks[] __initconst = {
 		AUD_PLL_CON0, pll1460x_24mhz_tbl),
 };
 
-static const struct samsung_cmu_info topc_cmu_info __initconst = {
+static const struct samsung_cmu_info topc_cmu_info = {
 	.pll_clks		= topc_pll_clks,
 	.nr_pll_clks		= ARRAY_SIZE(topc_pll_clks),
 	.mux_clks		= topc_mux_clks,
@@ -199,14 +202,6 @@ static const struct samsung_cmu_info topc_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(topc_clk_regs),
 };
 
-static void __init exynos7_clk_topc_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &topc_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_topc, "samsung,exynos7-clock-topc",
-	exynos7_clk_topc_init);
-
 /* Register Offset definitions for CMU_TOP0 (0x105D0000) */
 #define MUX_SEL_TOP00			0x0200
 #define MUX_SEL_TOP01			0x0204
@@ -377,7 +372,7 @@ static const struct samsung_fixed_factor_clock top0_fixed_factor_clks[] __initco
 	FFACTOR(0, "ffac_top0_mfc_pll_div2", "mout_top0_mfc_pll_user", 1, 2, 0),
 };
 
-static const struct samsung_cmu_info top0_cmu_info __initconst = {
+static const struct samsung_cmu_info top0_cmu_info = {
 	.mux_clks		= top0_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(top0_mux_clks),
 	.div_clks		= top0_div_clks,
@@ -391,14 +386,6 @@ static const struct samsung_cmu_info top0_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(top0_clk_regs),
 };
 
-static void __init exynos7_clk_top0_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &top0_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_top0, "samsung,exynos7-clock-top0",
-	exynos7_clk_top0_init);
-
 /* Register Offset definitions for CMU_TOP1 (0x105E0000) */
 #define MUX_SEL_TOP10			0x0200
 #define MUX_SEL_TOP11			0x0204
@@ -559,7 +546,7 @@ static const struct samsung_fixed_factor_clock top1_fixed_factor_clks[] __initco
 	FFACTOR(0, "ffac_top1_mfc_pll_div2", "mout_top1_mfc_pll_user", 1, 2, 0),
 };
 
-static const struct samsung_cmu_info top1_cmu_info __initconst = {
+static const struct samsung_cmu_info top1_cmu_info = {
 	.mux_clks		= top1_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(top1_mux_clks),
 	.div_clks		= top1_div_clks,
@@ -573,14 +560,6 @@ static const struct samsung_cmu_info top1_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(top1_clk_regs),
 };
 
-static void __init exynos7_clk_top1_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &top1_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_top1, "samsung,exynos7-clock-top1",
-	exynos7_clk_top1_init);
-
 /* Register Offset definitions for CMU_CCORE (0x105B0000) */
 #define MUX_SEL_CCORE			0x0200
 #define DIV_CCORE			0x0600
@@ -608,7 +587,7 @@ static const struct samsung_gate_clock ccore_gate_clks[] __initconst = {
 		ENABLE_PCLK_CCORE, 8, 0, 0),
 };
 
-static const struct samsung_cmu_info ccore_cmu_info __initconst = {
+static const struct samsung_cmu_info ccore_cmu_info = {
 	.mux_clks		= ccore_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(ccore_mux_clks),
 	.gate_clks		= ccore_gate_clks,
@@ -618,14 +597,6 @@ static const struct samsung_cmu_info ccore_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(ccore_clk_regs),
 };
 
-static void __init exynos7_clk_ccore_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &ccore_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_ccore, "samsung,exynos7-clock-ccore",
-	exynos7_clk_ccore_init);
-
 /* Register Offset definitions for CMU_PERIC0 (0x13610000) */
 #define MUX_SEL_PERIC0			0x0200
 #define ENABLE_PCLK_PERIC0		0x0900
@@ -675,7 +646,7 @@ static const struct samsung_gate_clock peric0_gate_clks[] __initconst = {
 	GATE(SCLK_PWM, "sclk_pwm", "fin_pll", ENABLE_SCLK_PERIC0, 21, 0, 0),
 };
 
-static const struct samsung_cmu_info peric0_cmu_info __initconst = {
+static const struct samsung_cmu_info peric0_cmu_info = {
 	.mux_clks		= peric0_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(peric0_mux_clks),
 	.gate_clks		= peric0_gate_clks,
@@ -685,11 +656,6 @@ static const struct samsung_cmu_info peric0_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(peric0_clk_regs),
 };
 
-static void __init exynos7_clk_peric0_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &peric0_cmu_info);
-}
-
 /* Register Offset definitions for CMU_PERIC1 (0x14C80000) */
 #define MUX_SEL_PERIC10			0x0200
 #define MUX_SEL_PERIC11			0x0204
@@ -697,8 +663,6 @@ static void __init exynos7_clk_peric0_init(struct device_node *np)
 #define ENABLE_PCLK_PERIC1		0x0900
 #define ENABLE_SCLK_PERIC10		0x0A00
 
-CLK_OF_DECLARE(exynos7_clk_peric0, "samsung,exynos7-clock-peric0",
-	exynos7_clk_peric0_init);
 
 /* List of parent clocks for Muxes in CMU_PERIC1 */
 PNAME(mout_aclk_peric1_66_user_p)	= { "fin_pll", "aclk_peric1_66" };
@@ -799,7 +763,7 @@ static const struct samsung_gate_clock peric1_gate_clks[] __initconst = {
 		ENABLE_SCLK_PERIC10, 19, CLK_SET_RATE_PARENT, 0),
 };
 
-static const struct samsung_cmu_info peric1_cmu_info __initconst = {
+static const struct samsung_cmu_info peric1_cmu_info = {
 	.mux_clks		= peric1_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(peric1_mux_clks),
 	.gate_clks		= peric1_gate_clks,
@@ -809,14 +773,6 @@ static const struct samsung_cmu_info peric1_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(peric1_clk_regs),
 };
 
-static void __init exynos7_clk_peric1_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &peric1_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_peric1, "samsung,exynos7-clock-peric1",
-	exynos7_clk_peric1_init);
-
 /* Register Offset definitions for CMU_PERIS (0x10040000) */
 #define MUX_SEL_PERIS			0x0200
 #define ENABLE_PCLK_PERIS		0x0900
@@ -854,7 +810,7 @@ static const struct samsung_gate_clock peris_gate_clks[] __initconst = {
 	GATE(SCLK_TMU, "sclk_tmu", "fin_pll", ENABLE_SCLK_PERIS, 10, 0, 0),
 };
 
-static const struct samsung_cmu_info peris_cmu_info __initconst = {
+static const struct samsung_cmu_info peris_cmu_info = {
 	.mux_clks		= peris_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(peris_mux_clks),
 	.gate_clks		= peris_gate_clks,
@@ -864,14 +820,6 @@ static const struct samsung_cmu_info peris_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(peris_clk_regs),
 };
 
-static void __init exynos7_clk_peris_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &peris_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_peris, "samsung,exynos7-clock-peris",
-	exynos7_clk_peris_init);
-
 /* Register Offset definitions for CMU_FSYS0 (0x10E90000) */
 #define MUX_SEL_FSYS00			0x0200
 #define MUX_SEL_FSYS01			0x0204
@@ -962,7 +910,7 @@ static const struct samsung_gate_clock fsys0_gate_clks[] __initconst = {
 		ENABLE_SCLK_FSYS04, 28, 0, 0),
 };
 
-static const struct samsung_cmu_info fsys0_cmu_info __initconst = {
+static const struct samsung_cmu_info fsys0_cmu_info = {
 	.fixed_clks		= fixed_rate_clks_fsys0,
 	.nr_fixed_clks		= ARRAY_SIZE(fixed_rate_clks_fsys0),
 	.mux_clks		= fsys0_mux_clks,
@@ -974,14 +922,6 @@ static const struct samsung_cmu_info fsys0_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(fsys0_clk_regs),
 };
 
-static void __init exynos7_clk_fsys0_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &fsys0_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_fsys0, "samsung,exynos7-clock-fsys0",
-	exynos7_clk_fsys0_init);
-
 /* Register Offset definitions for CMU_FSYS1 (0x156E0000) */
 #define MUX_SEL_FSYS10			0x0200
 #define MUX_SEL_FSYS11			0x0204
@@ -1091,7 +1031,7 @@ static const struct samsung_gate_clock fsys1_gate_clks[] __initconst = {
 		ENABLE_SCLK_FSYS13, 24, CLK_IGNORE_UNUSED, 0),
 };
 
-static const struct samsung_cmu_info fsys1_cmu_info __initconst = {
+static const struct samsung_cmu_info fsys1_cmu_info = {
 	.fixed_clks		= fixed_rate_clks_fsys1,
 	.nr_fixed_clks		= ARRAY_SIZE(fixed_rate_clks_fsys1),
 	.mux_clks		= fsys1_mux_clks,
@@ -1105,14 +1045,6 @@ static const struct samsung_cmu_info fsys1_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(fsys1_clk_regs),
 };
 
-static void __init exynos7_clk_fsys1_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &fsys1_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_fsys1, "samsung,exynos7-clock-fsys1",
-	exynos7_clk_fsys1_init);
-
 #define MUX_SEL_MSCL			0x0200
 #define DIV_MSCL			0x0600
 #define ENABLE_ACLK_MSCL		0x0800
@@ -1206,7 +1138,7 @@ static const struct samsung_gate_clock mscl_gate_clks[] __initconst = {
 			ENABLE_PCLK_MSCL, 20, 0, 0),
 };
 
-static const struct samsung_cmu_info mscl_cmu_info __initconst = {
+static const struct samsung_cmu_info mscl_cmu_info = {
 	.mux_clks		= mscl_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(mscl_mux_clks),
 	.div_clks		= mscl_div_clks,
@@ -1218,14 +1150,6 @@ static const struct samsung_cmu_info mscl_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(mscl_clk_regs),
 };
 
-static void __init exynos7_clk_mscl_init(struct device_node *np)
-{
-	samsung_cmu_register_one(np, &mscl_cmu_info);
-}
-
-CLK_OF_DECLARE(exynos7_clk_mscl, "samsung,exynos7-clock-mscl",
-		exynos7_clk_mscl_init);
-
 /* Register Offset definitions for CMU_AUD (0x114C0000) */
 #define	MUX_SEL_AUD			0x0200
 #define	DIV_AUD0			0x0600
@@ -1240,7 +1164,7 @@ CLK_OF_DECLARE(exynos7_clk_mscl, "samsung,exynos7-clock-mscl",
 PNAME(mout_aud_pll_user_p) = { "fin_pll", "fout_aud_pll" };
 PNAME(mout_aud_group_p) = { "dout_aud_cdclk", "ioclk_audiocdclk0" };
 
-static const unsigned long aud_clk_regs[] __initconst = {
+static const unsigned long aud_clk_regs[] = {
 	MUX_SEL_AUD,
 	DIV_AUD0,
 	DIV_AUD1,
@@ -1249,13 +1173,13 @@ static const unsigned long aud_clk_regs[] __initconst = {
 	ENABLE_SCLK_AUD,
 };
 
-static const struct samsung_mux_clock aud_mux_clks[] __initconst = {
+static const struct samsung_mux_clock aud_mux_clks[] = {
 	MUX(0, "mout_sclk_i2s", mout_aud_group_p, MUX_SEL_AUD, 12, 1),
 	MUX(0, "mout_sclk_pcm", mout_aud_group_p, MUX_SEL_AUD, 16, 1),
 	MUX(0, "mout_aud_pll_user", mout_aud_pll_user_p, MUX_SEL_AUD, 20, 1),
 };
 
-static const struct samsung_div_clock aud_div_clks[] __initconst = {
+static const struct samsung_div_clock aud_div_clks[] = {
 	DIV(0, "dout_aud_ca5", "mout_aud_pll_user", DIV_AUD0, 0, 4),
 	DIV(0, "dout_aclk_aud", "dout_aud_ca5", DIV_AUD0, 4, 4),
 	DIV(0, "dout_aud_pclk_dbg", "dout_aud_ca5", DIV_AUD0, 8, 4),
@@ -1267,7 +1191,7 @@ static const struct samsung_div_clock aud_div_clks[] __initconst = {
 	DIV(0, "dout_aud_cdclk", "mout_aud_pll_user", DIV_AUD1, 24, 4),
 };
 
-static const struct samsung_gate_clock aud_gate_clks[] __initconst = {
+static const struct samsung_gate_clock aud_gate_clks[] = {
 	GATE(SCLK_PCM, "sclk_pcm", "dout_sclk_pcm",
 			ENABLE_SCLK_AUD, 27, CLK_SET_RATE_PARENT, 0),
 	GATE(SCLK_I2S, "sclk_i2s", "dout_sclk_i2s",
@@ -1295,7 +1219,7 @@ static const struct samsung_gate_clock aud_gate_clks[] __initconst = {
 	GATE(ACLK_ADMA, "aclk_dmac", "dout_aclk_aud", ENABLE_ACLK_AUD, 31, 0, 0),
 };
 
-static const struct samsung_cmu_info aud_cmu_info __initconst = {
+static const struct samsung_cmu_info aud_cmu_info = {
 	.mux_clks		= aud_mux_clks,
 	.nr_mux_clks		= ARRAY_SIZE(aud_mux_clks),
 	.div_clks		= aud_div_clks,
@@ -1307,10 +1231,67 @@ static const struct samsung_cmu_info aud_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(aud_clk_regs),
 };
 
-static void __init exynos7_clk_aud_init(struct device_node *np)
+static int exynos7_cmu_probe(struct platform_device *pdev)
 {
-	samsung_cmu_register_one(np, &aud_cmu_info);
+	struct device *dev = &pdev->dev;
+	const struct samsung_cmu_info *info;
+
+	info = of_device_get_match_data(dev);
+	if (info)
+		samsung_cmu_register_one(dev->of_node, info);
+
+	return 0;
 }
 
-CLK_OF_DECLARE(exynos7_clk_aud, "samsung,exynos7-clock-aud",
-		exynos7_clk_aud_init);
+static const struct of_device_id exynos7_cmu_of_match[] = {
+	{
+		.compatible = "samsung,exynos7-clock-aud",
+		.data = &aud_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-mscl",
+		.data = &mscl_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-fsys1",
+		.data = &fsys1_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-fsys0",
+		.data = &fsys0_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-peris",
+		.data = &peris_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-peric1",
+		.data = &peric1_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-peric0",
+		.data = &peric0_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-ccore",
+		.data = &ccore_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-top1",
+		.data = &top1_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-top0",
+		.data = &top0_cmu_info,
+	}, {
+		.compatible = "samsung,exynos7-clock-topc",
+		.data = &topc_cmu_info,
+	},
+};
+
+static struct platform_driver exynos7_cmu_driver __refdata = {
+	.driver	= {
+		.name = "exynos7-clock",
+		.of_match_table = exynos7_cmu_of_match,
+		.suppress_bind_attrs = true,
+	},
+	.probe = exynos7_cmu_probe,
+};
+
+module_platform_driver(exynos7_cmu_driver);
+
+MODULE_DESCRIPTION("Samsung Exynos7 ARMv8-family clock driver");
+MODULE_AUTHOR("Naveen Krishna Ch <naveenkrishna.ch@gmail.com>");
+MODULE_AUTHOR("Alim Akhtar <alim.akhtar@samsung.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 5873a9354b50..7124d831d484 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -6,6 +6,7 @@
  * This file contains the utility functions to register the pll clocks.
 */
 
+#include <linux/module.h>
 #include <linux/errno.h>
 #include <linux/hrtimer.h>
 #include <linux/iopoll.h>
@@ -93,7 +94,7 @@ static int samsung_pll_lock_wait(struct samsung_clk_pll *pll,
 	 * Exynos SoC variants. Single register read time was usually in range
 	 * 0.4...1.5 us, never less than 0.4 us.
 	 */
-	if (pll_early_timeout || timekeeping_suspended) {
+	if (pll_early_timeout || timekeeping_is_suspended()) {
 		i = PLL_TIMEOUT_LOOPS;
 		while (i-- > 0) {
 			if (readl_relaxed(pll->con_reg) & reg_mask)
@@ -1392,7 +1393,7 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 	samsung_clk_add_lookup(ctx, &pll->hw, pll_clk->id);
 }
 
-void __init samsung_clk_register_pll(struct samsung_clk_provider *ctx,
+void samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 			const struct samsung_pll_clock *pll_list,
 			unsigned int nr_pll, void __iomem *base)
 {
@@ -1401,3 +1402,4 @@ void __init samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 	for (cnt = 0; cnt < nr_pll; cnt++)
 		_samsung_clk_register_pll(ctx, &pll_list[cnt], base);
 }
+EXPORT_SYMBOL_GPL(samsung_clk_register_pll);
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 336243c6f120..478a25ac763b 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -13,6 +13,7 @@
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/io.h>
+#include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/syscore_ops.h>
 
@@ -27,6 +28,7 @@ void samsung_clk_save(void __iomem *base,
 	for (; num_regs > 0; --num_regs, ++rd)
 		rd->value = readl(base + rd->offset);
 }
+EXPORT_SYMBOL_GPL(samsung_clk_save);
 
 void samsung_clk_restore(void __iomem *base,
 				      const struct samsung_clk_reg_dump *rd,
@@ -35,6 +37,7 @@ void samsung_clk_restore(void __iomem *base,
 	for (; num_regs > 0; --num_regs, ++rd)
 		writel(rd->value, base + rd->offset);
 }
+EXPORT_SYMBOL_GPL(samsung_clk_restore);
 
 struct samsung_clk_reg_dump *samsung_clk_alloc_reg_dump(
 						const unsigned long *rdump,
@@ -52,9 +55,10 @@ struct samsung_clk_reg_dump *samsung_clk_alloc_reg_dump(
 
 	return rd;
 }
+EXPORT_SYMBOL_GPL(samsung_clk_alloc_reg_dump);
 
 /* setup the essentials required to support clock lookup using ccf */
-struct samsung_clk_provider *__init samsung_clk_init(struct device_node *np,
+struct samsung_clk_provider *samsung_clk_init(struct device_node *np,
 			void __iomem *base, unsigned long nr_clks)
 {
 	struct samsung_clk_provider *ctx;
@@ -74,7 +78,7 @@ struct samsung_clk_provider *__init samsung_clk_init(struct device_node *np,
 	return ctx;
 }
 
-void __init samsung_clk_of_add_provider(struct device_node *np,
+void samsung_clk_of_add_provider(struct device_node *np,
 				struct samsung_clk_provider *ctx)
 {
 	if (np) {
@@ -83,6 +87,7 @@ void __init samsung_clk_of_add_provider(struct device_node *np,
 			panic("could not register clk provider\n");
 	}
 }
+EXPORT_SYMBOL_GPL(samsung_clk_of_add_provider);
 
 /* add a clock instance to the clock lookup table used for dt based lookup */
 void samsung_clk_add_lookup(struct samsung_clk_provider *ctx,
@@ -123,7 +128,7 @@ void __init samsung_clk_register_alias(struct samsung_clk_provider *ctx,
 }
 
 /* register a list of fixed clocks */
-void __init samsung_clk_register_fixed_rate(struct samsung_clk_provider *ctx,
+void samsung_clk_register_fixed_rate(struct samsung_clk_provider *ctx,
 		const struct samsung_fixed_rate_clock *list,
 		unsigned int nr_clk)
 {
@@ -151,9 +156,10 @@ void __init samsung_clk_register_fixed_rate(struct samsung_clk_provider *ctx,
 				__func__, list->name);
 	}
 }
+EXPORT_SYMBOL_GPL(samsung_clk_register_fixed_rate);
 
 /* register a list of fixed factor clocks */
-void __init samsung_clk_register_fixed_factor(struct samsung_clk_provider *ctx,
+void samsung_clk_register_fixed_factor(struct samsung_clk_provider *ctx,
 		const struct samsung_fixed_factor_clock *list, unsigned int nr_clk)
 {
 	struct clk_hw *clk_hw;
@@ -171,9 +177,10 @@ void __init samsung_clk_register_fixed_factor(struct samsung_clk_provider *ctx,
 		samsung_clk_add_lookup(ctx, clk_hw, list->id);
 	}
 }
+EXPORT_SYMBOL_GPL(samsung_clk_register_fixed_factor);
 
 /* register a list of mux clocks */
-void __init samsung_clk_register_mux(struct samsung_clk_provider *ctx,
+void samsung_clk_register_mux(struct samsung_clk_provider *ctx,
 				const struct samsung_mux_clock *list,
 				unsigned int nr_clk)
 {
@@ -194,9 +201,10 @@ void __init samsung_clk_register_mux(struct samsung_clk_provider *ctx,
 		samsung_clk_add_lookup(ctx, clk_hw, list->id);
 	}
 }
+EXPORT_SYMBOL_GPL(samsung_clk_register_mux);
 
 /* register a list of div clocks */
-void __init samsung_clk_register_div(struct samsung_clk_provider *ctx,
+void samsung_clk_register_div(struct samsung_clk_provider *ctx,
 				const struct samsung_div_clock *list,
 				unsigned int nr_clk)
 {
@@ -224,9 +232,10 @@ void __init samsung_clk_register_div(struct samsung_clk_provider *ctx,
 		samsung_clk_add_lookup(ctx, clk_hw, list->id);
 	}
 }
+EXPORT_SYMBOL_GPL(samsung_clk_register_div);
 
 /* register a list of gate clocks */
-void __init samsung_clk_register_gate(struct samsung_clk_provider *ctx,
+void samsung_clk_register_gate(struct samsung_clk_provider *ctx,
 				const struct samsung_gate_clock *list,
 				unsigned int nr_clk)
 {
@@ -246,6 +255,7 @@ void __init samsung_clk_register_gate(struct samsung_clk_provider *ctx,
 		samsung_clk_add_lookup(ctx, clk_hw, list->id);
 	}
 }
+EXPORT_SYMBOL_GPL(samsung_clk_register_gate);
 
 /*
  * obtain the clock speed of all external fixed clock sources from device
@@ -342,7 +352,7 @@ void samsung_clk_extended_sleep_init(void __iomem *reg_base,
  * Common function which registers plls, muxes, dividers and gates
  * for each CMU. It also add CMU register list to register cache.
  */
-struct samsung_clk_provider * __init samsung_cmu_register_one(
+struct samsung_clk_provider *samsung_cmu_register_one(
 			struct device_node *np,
 			const struct samsung_cmu_info *cmu)
 {
@@ -385,3 +395,10 @@ struct samsung_clk_provider * __init samsung_cmu_register_one(
 
 	return ctx;
 }
+EXPORT_SYMBOL_GPL(samsung_cmu_register_one);
+
+MODULE_DESCRIPTION("Samsung Exynos clock controller support");
+MODULE_AUTHOR("Thomas Abraham <thomas.ab@samsung.com>");
+MODULE_AUTHOR("Marek Szyprowski <m.szyprowski@samsung.com>");
+MODULE_AUTHOR("Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index a52a38cc1740..b82709696751 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -222,7 +222,7 @@ struct samsung_gate_clock {
 #define GATE(_id, cname, pname, o, b, f, gf)			\
 	__GATE(_id, cname, pname, o, b, f, gf)
 
-#define PNAME(x) static const char * const x[] __initconst
+#define PNAME(x) static const char * const x[]
 
 /**
  * struct samsung_clk_reg_dump: register dump of clock controller registers.
@@ -337,10 +337,10 @@ struct samsung_cmu_info {
 	const char *clk_name;
 };
 
-extern struct samsung_clk_provider *__init samsung_clk_init(
+extern struct samsung_clk_provider *samsung_clk_init(
 			struct device_node *np, void __iomem *base,
 			unsigned long nr_clks);
-extern void __init samsung_clk_of_add_provider(struct device_node *np,
+extern void samsung_clk_of_add_provider(struct device_node *np,
 			struct samsung_clk_provider *ctx);
 extern void __init samsung_clk_of_register_fixed_ext(
 			struct samsung_clk_provider *ctx,
@@ -354,32 +354,32 @@ extern void samsung_clk_add_lookup(struct samsung_clk_provider *ctx,
 extern void __init samsung_clk_register_alias(struct samsung_clk_provider *ctx,
 			const struct samsung_clock_alias *list,
 			unsigned int nr_clk);
-extern void __init samsung_clk_register_fixed_rate(
+extern void samsung_clk_register_fixed_rate(
 			struct samsung_clk_provider *ctx,
 			const struct samsung_fixed_rate_clock *clk_list,
 			unsigned int nr_clk);
-extern void __init samsung_clk_register_fixed_factor(
+extern void samsung_clk_register_fixed_factor(
 			struct samsung_clk_provider *ctx,
 			const struct samsung_fixed_factor_clock *list,
 			unsigned int nr_clk);
-extern void __init samsung_clk_register_mux(struct samsung_clk_provider *ctx,
+extern void samsung_clk_register_mux(struct samsung_clk_provider *ctx,
 			const struct samsung_mux_clock *clk_list,
 			unsigned int nr_clk);
-extern void __init samsung_clk_register_div(struct samsung_clk_provider *ctx,
+extern void samsung_clk_register_div(struct samsung_clk_provider *ctx,
 			const struct samsung_div_clock *clk_list,
 			unsigned int nr_clk);
-extern void __init samsung_clk_register_gate(struct samsung_clk_provider *ctx,
+extern void samsung_clk_register_gate(struct samsung_clk_provider *ctx,
 			const struct samsung_gate_clock *clk_list,
 			unsigned int nr_clk);
-extern void __init samsung_clk_register_pll(struct samsung_clk_provider *ctx,
+extern void samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 			const struct samsung_pll_clock *pll_list,
 			unsigned int nr_clk, void __iomem *base);
-extern void __init samsung_clk_register_cpu(struct samsung_clk_provider *ctx,
+extern void samsung_clk_register_cpu(struct samsung_clk_provider *ctx,
 		const struct samsung_cpu_clock *list, unsigned int nr_clk);
 
-extern struct samsung_clk_provider __init *samsung_cmu_register_one(
-			struct device_node *,
-			const struct samsung_cmu_info *);
+extern struct samsung_clk_provider *samsung_cmu_register_one(
+			struct device_node *np,
+			const struct samsung_cmu_info *cmu);
 
 extern unsigned long _get_rate(const char *clk_name);
 
-- 
2.33.0.685.g46640cef36-goog

[PATCH v2 07/12] clk: samsung: set exynos arm64 clk driver as tristate

[Will McVicker]

This sets the COMMON_CLK_SAMSUNG and EXYNOS_ARM64_COMMON_CLK drivers as
tristate so that we can compile them as modules.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm/mach-exynos/Kconfig      | 1 -
 arch/arm/mach-s3c/Kconfig.s3c64xx | 1 -
 arch/arm/mach-s5pv210/Kconfig     | 1 -
 arch/arm64/Kconfig.platforms      | 1 -
 drivers/clk/samsung/Kconfig       | 5 +++--
 5 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 30f930e20599..01b8e8b8d95d 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -12,7 +12,6 @@ menuconfig ARCH_EXYNOS
 	select ARM_AMBA
 	select ARM_GIC
 	select EXYNOS_IRQ_COMBINER
-	select COMMON_CLK_SAMSUNG
 	select EXYNOS_THERMAL
 	select EXYNOS_PMU
 	select EXYNOS_SROM
diff --git a/arch/arm/mach-s3c/Kconfig.s3c64xx b/arch/arm/mach-s3c/Kconfig.s3c64xx
index f3fcb570edf5..f65117bb9f4c 100644
--- a/arch/arm/mach-s3c/Kconfig.s3c64xx
+++ b/arch/arm/mach-s3c/Kconfig.s3c64xx
@@ -9,7 +9,6 @@ menuconfig ARCH_S3C64XX
 	select ARM_AMBA
 	select ARM_VIC
 	select CLKSRC_SAMSUNG_PWM
-	select COMMON_CLK_SAMSUNG
 	select GPIO_SAMSUNG if ATAGS
 	select GPIOLIB
 	select HAVE_S3C2410_I2C if I2C
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index d644b45bc29d..3d7e0b5739d8 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -10,7 +10,6 @@ config ARCH_S5PV210
 	depends on ARCH_MULTI_V7
 	select ARM_VIC
 	select CLKSRC_SAMSUNG_PWM
-	select COMMON_CLK_SAMSUNG
 	select GPIOLIB
 	select HAVE_S3C2410_I2C if I2C
 	select HAVE_S3C_RTC if RTC_CLASS
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 90c5cf4856e1..e6d4abadacd8 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -91,7 +91,6 @@ config ARCH_BRCMSTB
 
 config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
-	select COMMON_CLK_SAMSUNG
 	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 	select EXYNOS_PMU
 	select HAVE_S3C_RTC if RTC_CLASS
diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index 0441c4f73ac9..f987d386979d 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -1,7 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0-only
 # Recent Exynos platforms should just select COMMON_CLK_SAMSUNG:
 config COMMON_CLK_SAMSUNG
-	bool "Samsung Exynos clock controller support" if COMPILE_TEST
+	tristate "Samsung Exynos clock controller support"
+	default y if ARCH_EXYNOS || ARCH_S5PV210 || ARCH_S3C64XX
 	select S3C64XX_COMMON_CLK if ARM && ARCH_S3C64XX
 	select S5PV210_COMMON_CLK if ARM && ARCH_S5PV210
 	select EXYNOS_3250_COMMON_CLK if ARM && SOC_EXYNOS3250
@@ -70,7 +71,7 @@ config EXYNOS_5420_COMMON_CLK
 	  Exynos5420 SoCs. Choose Y here only if you build for this SoC.
 
 config EXYNOS_ARM64_COMMON_CLK
-	bool "Samsung Exynos ARMv8-family clock controller support" if COMPILE_TEST
+	tristate "Samsung Exynos ARMv8-family clock controller support"
 	depends on COMMON_CLK_SAMSUNG
 
 config EXYNOS_AUDSS_CLK_CON
-- 
2.33.0.685.g46640cef36-goog

Re: [PATCH v2 07/12] clk: samsung: set exynos arm64 clk driver as tristate

[Krzysztof Kozlowski]

On 29/09/2021 01:56, Will McVicker wrote:
> This sets the COMMON_CLK_SAMSUNG and EXYNOS_ARM64_COMMON_CLK drivers as
> tristate so that we can compile them as modules.

This is not the only thing you are doing. You are removing the enforced
built-in and this must be here explained and tested. The policy so far
was that all S3C, S5P and Exynos supported platforms select (enforce)
necessary drivers. Please explain in commit msg reasoning why this is
being changed and what's the impact (whether it actually works).

What is more, it seems you entirely ignored Geert's comments. I pointed
attention to it last time and you just said you will send v2 instead of
joining discussion.

It's a NAK for this reason - ignoring what Geert brought: you just broke
distro configs for Exynos.

Best regards,
Krzysztof

[PATCH v2 08/12] pinctrl: samsung: modularize the ARM and ARM64 pinctrls

[Will McVicker]

This patch modularizes the Samsung Exynos ARM and ARM64 pinctrl drivers.
It creates 2 kernel modules (pending Kconfig changes):

1) pinctrl-samsung.ko: common pinctrl driver for all the samsung pinctrl
   drivers.
2) pinctrl_exynos.ko: ARM and ARM64 pinctrl driver.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 drivers/pinctrl/samsung/Makefile              |  13 +--
 drivers/pinctrl/samsung/pinctrl-exynos-arm.c  | 102 ++++++++++--------
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  73 +++++++------
 drivers/pinctrl/samsung/pinctrl-exynos.c      |  17 +--
 drivers/pinctrl/samsung/pinctrl-samsung.c     |  11 +-
 5 files changed, 117 insertions(+), 99 deletions(-)

diff --git a/drivers/pinctrl/samsung/Makefile b/drivers/pinctrl/samsung/Makefile
index ed951df6a112..767ce3357a19 100644
--- a/drivers/pinctrl/samsung/Makefile
+++ b/drivers/pinctrl/samsung/Makefile
@@ -1,9 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0
 # Samsung pin control drivers
 
-obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
-obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
-obj-$(CONFIG_PINCTRL_EXYNOS_ARM)	+= pinctrl-exynos-arm.o
-obj-$(CONFIG_PINCTRL_EXYNOS_ARM64)	+= pinctrl-exynos-arm64.o
-obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
-obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
+obj-$(CONFIG_PINCTRL_SAMSUNG)			+= pinctrl-samsung.o
+obj-$(CONFIG_PINCTRL_EXYNOS)			+= pinctrl_exynos.o
+pinctrl_exynos-y				+= pinctrl-exynos.o
+pinctrl_exynos-$(CONFIG_PINCTRL_EXYNOS_ARM)	+= pinctrl-exynos-arm.o
+pinctrl_exynos-$(CONFIG_PINCTRL_EXYNOS_ARM64)	+= pinctrl-exynos-arm64.o
+obj-$(CONFIG_PINCTRL_S3C24XX)			+= pinctrl-s3c24xx.o
+obj-$(CONFIG_PINCTRL_S3C64XX)			+= pinctrl-s3c64xx.o
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
index 85ddf49a5188..f3bd8cf1bbb6 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
@@ -83,12 +83,12 @@ s5pv210_retention_init(struct samsung_pinctrl_drv_data *drvdata,
 	return ctrl;
 }
 
-static const struct samsung_retention_data s5pv210_retention_data __initconst = {
+static const struct samsung_retention_data s5pv210_retention_data = {
 	.init	 = s5pv210_retention_init,
 };
 
 /* pin banks of s5pv210 pin-controller */
-static const struct samsung_pin_bank_data s5pv210_pin_bank[] __initconst = {
+static const struct samsung_pin_bank_data s5pv210_pin_bank[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpa1", 0x04),
@@ -126,7 +126,7 @@ static const struct samsung_pin_bank_data s5pv210_pin_bank[] __initconst = {
 	EXYNOS_PIN_BANK_EINTW(8, 0xc60, "gph3", 0x0c),
 };
 
-static const struct samsung_pin_ctrl s5pv210_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl s5pv210_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= s5pv210_pin_bank,
@@ -139,16 +139,17 @@ static const struct samsung_pin_ctrl s5pv210_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data s5pv210_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data s5pv210_of_data = {
 	.ctrl		= s5pv210_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(s5pv210_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(s5pv210_of_data);
 
 /* Pad retention control code for accessing PMU regmap */
 static atomic_t exynos_shared_retention_refcnt;
 
 /* pin banks of exynos3250 pin-controller 0 */
-static const struct samsung_pin_bank_data exynos3250_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos3250_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
@@ -160,7 +161,7 @@ static const struct samsung_pin_bank_data exynos3250_pin_banks0[] __initconst =
 };
 
 /* pin banks of exynos3250 pin-controller 1 */
-static const struct samsung_pin_bank_data exynos3250_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos3250_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTN(8, 0x120, "gpe0"),
 	EXYNOS_PIN_BANK_EINTN(8, 0x140, "gpe1"),
@@ -196,7 +197,7 @@ static const u32 exynos3250_retention_regs[] = {
 	S5P_PAD_RET_SPI_OPTION,
 };
 
-static const struct samsung_retention_data exynos3250_retention_data __initconst = {
+static const struct samsung_retention_data exynos3250_retention_data = {
 	.regs	 = exynos3250_retention_regs,
 	.nr_regs = ARRAY_SIZE(exynos3250_retention_regs),
 	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
@@ -208,7 +209,7 @@ static const struct samsung_retention_data exynos3250_retention_data __initconst
  * Samsung pinctrl driver data for Exynos3250 SoC. Exynos3250 SoC includes
  * two gpio/pin-mux/pinconfig controllers.
  */
-static const struct samsung_pin_ctrl exynos3250_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= exynos3250_pin_banks0,
@@ -229,13 +230,14 @@ static const struct samsung_pin_ctrl exynos3250_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos3250_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos3250_of_data = {
 	.ctrl		= exynos3250_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos3250_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos3250_of_data);
 
 /* pin banks of exynos4210 pin-controller 0 */
-static const struct samsung_pin_bank_data exynos4210_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
@@ -256,7 +258,7 @@ static const struct samsung_pin_bank_data exynos4210_pin_banks0[] __initconst =
 };
 
 /* pin banks of exynos4210 pin-controller 1 */
-static const struct samsung_pin_bank_data exynos4210_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpj0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(5, 0x020, "gpj1", 0x04),
@@ -281,7 +283,7 @@ static const struct samsung_pin_bank_data exynos4210_pin_banks1[] __initconst =
 };
 
 /* pin banks of exynos4210 pin-controller 2 */
-static const struct samsung_pin_bank_data exynos4210_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos4210_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTN(7, 0x000, "gpz"),
 };
@@ -296,7 +298,7 @@ static const u32 exynos4_retention_regs[] = {
 	S5P_PAD_RET_EBIB_OPTION,
 };
 
-static const struct samsung_retention_data exynos4_retention_data __initconst = {
+static const struct samsung_retention_data exynos4_retention_data = {
 	.regs	 = exynos4_retention_regs,
 	.nr_regs = ARRAY_SIZE(exynos4_retention_regs),
 	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
@@ -309,7 +311,7 @@ static const u32 exynos4_audio_retention_regs[] = {
 	S5P_PAD_RET_MAUDIO_OPTION,
 };
 
-static const struct samsung_retention_data exynos4_audio_retention_data __initconst = {
+static const struct samsung_retention_data exynos4_audio_retention_data = {
 	.regs	 = exynos4_audio_retention_regs,
 	.nr_regs = ARRAY_SIZE(exynos4_audio_retention_regs),
 	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
@@ -320,7 +322,7 @@ static const struct samsung_retention_data exynos4_audio_retention_data __initco
  * Samsung pinctrl driver data for Exynos4210 SoC. Exynos4210 SoC includes
  * three gpio/pin-mux/pinconfig controllers.
  */
-static const struct samsung_pin_ctrl exynos4210_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos4210_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= exynos4210_pin_banks0,
@@ -346,13 +348,14 @@ static const struct samsung_pin_ctrl exynos4210_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos4210_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos4210_of_data = {
 	.ctrl		= exynos4210_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos4210_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos4210_of_data);
 
 /* pin banks of exynos4x12 pin-controller 0 */
-static const struct samsung_pin_bank_data exynos4x12_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
@@ -370,7 +373,7 @@ static const struct samsung_pin_bank_data exynos4x12_pin_banks0[] __initconst =
 };
 
 /* pin banks of exynos4x12 pin-controller 1 */
-static const struct samsung_pin_bank_data exynos4x12_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x040, "gpk0", 0x08),
 	EXYNOS_PIN_BANK_EINTG(7, 0x060, "gpk1", 0x0c),
@@ -398,13 +401,13 @@ static const struct samsung_pin_bank_data exynos4x12_pin_banks1[] __initconst =
 };
 
 /* pin banks of exynos4x12 pin-controller 2 */
-static const struct samsung_pin_bank_data exynos4x12_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
 };
 
 /* pin banks of exynos4x12 pin-controller 3 */
-static const struct samsung_pin_bank_data exynos4x12_pin_banks3[] __initconst = {
+static const struct samsung_pin_bank_data exynos4x12_pin_banks3[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04),
@@ -417,7 +420,7 @@ static const struct samsung_pin_bank_data exynos4x12_pin_banks3[] __initconst =
  * Samsung pinctrl driver data for Exynos4x12 SoC. Exynos4x12 SoC includes
  * four gpio/pin-mux/pinconfig controllers.
  */
-static const struct samsung_pin_ctrl exynos4x12_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= exynos4x12_pin_banks0,
@@ -453,13 +456,14 @@ static const struct samsung_pin_ctrl exynos4x12_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos4x12_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos4x12_of_data = {
 	.ctrl		= exynos4x12_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos4x12_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos4x12_of_data);
 
 /* pin banks of exynos5250 pin-controller 0 */
-static const struct samsung_pin_bank_data exynos5250_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos5250_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
@@ -489,7 +493,7 @@ static const struct samsung_pin_bank_data exynos5250_pin_banks0[] __initconst =
 };
 
 /* pin banks of exynos5250 pin-controller 1 */
-static const struct samsung_pin_bank_data exynos5250_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos5250_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpe0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(2, 0x020, "gpe1", 0x04),
@@ -503,7 +507,7 @@ static const struct samsung_pin_bank_data exynos5250_pin_banks1[] __initconst =
 };
 
 /* pin banks of exynos5250 pin-controller 2 */
-static const struct samsung_pin_bank_data exynos5250_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos5250_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04),
@@ -513,7 +517,7 @@ static const struct samsung_pin_bank_data exynos5250_pin_banks2[] __initconst =
 };
 
 /* pin banks of exynos5250 pin-controller 3 */
-static const struct samsung_pin_bank_data exynos5250_pin_banks3[] __initconst = {
+static const struct samsung_pin_bank_data exynos5250_pin_banks3[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
 };
@@ -522,7 +526,7 @@ static const struct samsung_pin_bank_data exynos5250_pin_banks3[] __initconst =
  * Samsung pinctrl driver data for Exynos5250 SoC. Exynos5250 SoC includes
  * four gpio/pin-mux/pinconfig controllers.
  */
-static const struct samsung_pin_ctrl exynos5250_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos5250_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= exynos5250_pin_banks0,
@@ -558,13 +562,14 @@ static const struct samsung_pin_ctrl exynos5250_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos5250_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos5250_of_data = {
 	.ctrl		= exynos5250_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos5250_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos5250_of_data);
 
 /* pin banks of exynos5260 pin-controller 0 */
-static const struct samsung_pin_bank_data exynos5260_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos5260_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(7, 0x020, "gpa1", 0x04),
@@ -590,7 +595,7 @@ static const struct samsung_pin_bank_data exynos5260_pin_banks0[] __initconst =
 };
 
 /* pin banks of exynos5260 pin-controller 1 */
-static const struct samsung_pin_bank_data exynos5260_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos5260_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpc0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpc1", 0x04),
@@ -600,7 +605,7 @@ static const struct samsung_pin_bank_data exynos5260_pin_banks1[] __initconst =
 };
 
 /* pin banks of exynos5260 pin-controller 2 */
-static const struct samsung_pin_bank_data exynos5260_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos5260_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
@@ -610,7 +615,7 @@ static const struct samsung_pin_bank_data exynos5260_pin_banks2[] __initconst =
  * Samsung pinctrl driver data for Exynos5260 SoC. Exynos5260 SoC includes
  * three gpio/pin-mux/pinconfig controllers.
  */
-static const struct samsung_pin_ctrl exynos5260_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos5260_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= exynos5260_pin_banks0,
@@ -636,13 +641,14 @@ static const struct samsung_pin_ctrl exynos5260_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos5260_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos5260_of_data = {
 	.ctrl		= exynos5260_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos5260_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos5260_of_data);
 
 /* pin banks of exynos5410 pin-controller 0 */
-static const struct samsung_pin_bank_data exynos5410_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos5410_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
@@ -682,7 +688,7 @@ static const struct samsung_pin_bank_data exynos5410_pin_banks0[] __initconst =
 };
 
 /* pin banks of exynos5410 pin-controller 1 */
-static const struct samsung_pin_bank_data exynos5410_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos5410_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(5, 0x000, "gpj0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpj1", 0x04),
@@ -696,7 +702,7 @@ static const struct samsung_pin_bank_data exynos5410_pin_banks1[] __initconst =
 };
 
 /* pin banks of exynos5410 pin-controller 2 */
-static const struct samsung_pin_bank_data exynos5410_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos5410_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04),
@@ -706,7 +712,7 @@ static const struct samsung_pin_bank_data exynos5410_pin_banks2[] __initconst =
 };
 
 /* pin banks of exynos5410 pin-controller 3 */
-static const struct samsung_pin_bank_data exynos5410_pin_banks3[] __initconst = {
+static const struct samsung_pin_bank_data exynos5410_pin_banks3[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
 };
@@ -715,7 +721,7 @@ static const struct samsung_pin_bank_data exynos5410_pin_banks3[] __initconst =
  * Samsung pinctrl driver data for Exynos5410 SoC. Exynos5410 SoC includes
  * four gpio/pin-mux/pinconfig controllers.
  */
-static const struct samsung_pin_ctrl exynos5410_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos5410_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= exynos5410_pin_banks0,
@@ -748,13 +754,14 @@ static const struct samsung_pin_ctrl exynos5410_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos5410_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos5410_of_data = {
 	.ctrl		= exynos5410_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos5410_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos5410_of_data);
 
 /* pin banks of exynos5420 pin-controller 0 */
-static const struct samsung_pin_bank_data exynos5420_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos5420_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpy7", 0x00),
 	EXYNOS_PIN_BANK_EINTW(8, 0xC00, "gpx0", 0x00),
@@ -764,7 +771,7 @@ static const struct samsung_pin_bank_data exynos5420_pin_banks0[] __initconst =
 };
 
 /* pin banks of exynos5420 pin-controller 1 */
-static const struct samsung_pin_bank_data exynos5420_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos5420_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpc0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpc1", 0x04),
@@ -782,7 +789,7 @@ static const struct samsung_pin_bank_data exynos5420_pin_banks1[] __initconst =
 };
 
 /* pin banks of exynos5420 pin-controller 2 */
-static const struct samsung_pin_bank_data exynos5420_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos5420_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpe0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(2, 0x020, "gpe1", 0x04),
@@ -795,7 +802,7 @@ static const struct samsung_pin_bank_data exynos5420_pin_banks2[] __initconst =
 };
 
 /* pin banks of exynos5420 pin-controller 3 */
-static const struct samsung_pin_bank_data exynos5420_pin_banks3[] __initconst = {
+static const struct samsung_pin_bank_data exynos5420_pin_banks3[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
@@ -809,7 +816,7 @@ static const struct samsung_pin_bank_data exynos5420_pin_banks3[] __initconst =
 };
 
 /* pin banks of exynos5420 pin-controller 4 */
-static const struct samsung_pin_bank_data exynos5420_pin_banks4[] __initconst = {
+static const struct samsung_pin_bank_data exynos5420_pin_banks4[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
 };
@@ -830,7 +837,7 @@ static const u32 exynos5420_retention_regs[] = {
 	EXYNOS5420_PAD_RET_DRAM_COREBLK_OPTION,
 };
 
-static const struct samsung_retention_data exynos5420_retention_data __initconst = {
+static const struct samsung_retention_data exynos5420_retention_data = {
 	.regs	 = exynos5420_retention_regs,
 	.nr_regs = ARRAY_SIZE(exynos5420_retention_regs),
 	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
@@ -842,7 +849,7 @@ static const struct samsung_retention_data exynos5420_retention_data __initconst
  * Samsung pinctrl driver data for Exynos5420 SoC. Exynos5420 SoC includes
  * four gpio/pin-mux/pinconfig controllers.
  */
-static const struct samsung_pin_ctrl exynos5420_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos5420_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= exynos5420_pin_banks0,
@@ -887,7 +894,8 @@ static const struct samsung_pin_ctrl exynos5420_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos5420_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos5420_of_data = {
 	.ctrl		= exynos5420_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos5420_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos5420_of_data);
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index fe5f6046fbd5..9fb658c65b96 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -62,7 +62,7 @@ static const struct samsung_pin_bank_type exynos850_bank_type_alive = {
 static atomic_t exynos_shared_retention_refcnt;
 
 /* pin banks of exynos5433 pin-controller - ALIVE */
-static const struct samsung_pin_bank_data exynos5433_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
 	EXYNOS5433_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
@@ -76,32 +76,32 @@ static const struct samsung_pin_bank_data exynos5433_pin_banks0[] __initconst =
 };
 
 /* pin banks of exynos5433 pin-controller - AUD */
-static const struct samsung_pin_bank_data exynos5433_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
 	EXYNOS5433_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
 };
 
 /* pin banks of exynos5433 pin-controller - CPIF */
-static const struct samsung_pin_bank_data exynos5433_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - eSE */
-static const struct samsung_pin_bank_data exynos5433_pin_banks3[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks3[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - FINGER */
-static const struct samsung_pin_bank_data exynos5433_pin_banks4[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks4[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - FSYS */
-static const struct samsung_pin_bank_data exynos5433_pin_banks5[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks5[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
 	EXYNOS5433_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04),
@@ -112,19 +112,19 @@ static const struct samsung_pin_bank_data exynos5433_pin_banks5[] __initconst =
 };
 
 /* pin banks of exynos5433 pin-controller - IMEM */
-static const struct samsung_pin_bank_data exynos5433_pin_banks6[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks6[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(8, 0x000, "gpf0", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - NFC */
-static const struct samsung_pin_bank_data exynos5433_pin_banks7[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks7[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(3, 0x000, "gpj0", 0x00),
 };
 
 /* pin banks of exynos5433 pin-controller - PERIC */
-static const struct samsung_pin_bank_data exynos5433_pin_banks8[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks8[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(6, 0x000, "gpv7", 0x00),
 	EXYNOS5433_PIN_BANK_EINTG(5, 0x020, "gpb0", 0x04),
@@ -146,7 +146,7 @@ static const struct samsung_pin_bank_data exynos5433_pin_banks8[] __initconst =
 };
 
 /* pin banks of exynos5433 pin-controller - TOUCH */
-static const struct samsung_pin_bank_data exynos5433_pin_banks9[] __initconst = {
+static const struct samsung_pin_bank_data exynos5433_pin_banks9[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS5433_PIN_BANK_EINTG(3, 0x000, "gpj1", 0x00),
 };
@@ -165,7 +165,7 @@ static const u32 exynos5433_retention_regs[] = {
 	EXYNOS5433_PAD_RETENTION_FSYSGENIO_OPTION,
 };
 
-static const struct samsung_retention_data exynos5433_retention_data __initconst = {
+static const struct samsung_retention_data exynos5433_retention_data = {
 	.regs	 = exynos5433_retention_regs,
 	.nr_regs = ARRAY_SIZE(exynos5433_retention_regs),
 	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
@@ -178,7 +178,7 @@ static const u32 exynos5433_audio_retention_regs[] = {
 	EXYNOS5433_PAD_RETENTION_AUD_OPTION,
 };
 
-static const struct samsung_retention_data exynos5433_audio_retention_data __initconst = {
+static const struct samsung_retention_data exynos5433_audio_retention_data = {
 	.regs	 = exynos5433_audio_retention_regs,
 	.nr_regs = ARRAY_SIZE(exynos5433_audio_retention_regs),
 	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
@@ -192,7 +192,7 @@ static const u32 exynos5433_fsys_retention_regs[] = {
 	EXYNOS5433_PAD_RETENTION_MMC2_OPTION,
 };
 
-static const struct samsung_retention_data exynos5433_fsys_retention_data __initconst = {
+static const struct samsung_retention_data exynos5433_fsys_retention_data = {
 	.regs	 = exynos5433_fsys_retention_regs,
 	.nr_regs = ARRAY_SIZE(exynos5433_fsys_retention_regs),
 	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
@@ -203,7 +203,7 @@ static const struct samsung_retention_data exynos5433_fsys_retention_data __init
  * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC includes
  * ten gpio/pin-mux/pinconfig controllers.
  */
-static const struct samsung_pin_ctrl exynos5433_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 data */
 		.pin_banks	= exynos5433_pin_banks0,
@@ -288,13 +288,14 @@ static const struct samsung_pin_ctrl exynos5433_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos5433_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos5433_of_data = {
 	.ctrl		= exynos5433_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos5433_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos5433_of_data);
 
 /* pin banks of exynos7 pin-controller - ALIVE */
-static const struct samsung_pin_bank_data exynos7_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
 	EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
@@ -303,7 +304,7 @@ static const struct samsung_pin_bank_data exynos7_pin_banks0[] __initconst = {
 };
 
 /* pin banks of exynos7 pin-controller - BUS0 */
-static const struct samsung_pin_bank_data exynos7_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(5, 0x000, "gpb0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpc0", 0x04),
@@ -323,37 +324,37 @@ static const struct samsung_pin_bank_data exynos7_pin_banks1[] __initconst = {
 };
 
 /* pin banks of exynos7 pin-controller - NFC */
-static const struct samsung_pin_bank_data exynos7_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj0", 0x00),
 };
 
 /* pin banks of exynos7 pin-controller - TOUCH */
-static const struct samsung_pin_bank_data exynos7_pin_banks3[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks3[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj1", 0x00),
 };
 
 /* pin banks of exynos7 pin-controller - FF */
-static const struct samsung_pin_bank_data exynos7_pin_banks4[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks4[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpg4", 0x00),
 };
 
 /* pin banks of exynos7 pin-controller - ESE */
-static const struct samsung_pin_bank_data exynos7_pin_banks5[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks5[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(5, 0x000, "gpv7", 0x00),
 };
 
 /* pin banks of exynos7 pin-controller - FSYS0 */
-static const struct samsung_pin_bank_data exynos7_pin_banks6[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks6[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpr4", 0x00),
 };
 
 /* pin banks of exynos7 pin-controller - FSYS1 */
-static const struct samsung_pin_bank_data exynos7_pin_banks7[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks7[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpr0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpr1", 0x04),
@@ -362,7 +363,7 @@ static const struct samsung_pin_bank_data exynos7_pin_banks7[] __initconst = {
 };
 
 /* pin banks of exynos7 pin-controller - BUS1 */
-static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
@@ -376,13 +377,13 @@ static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
 	EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
 };
 
-static const struct samsung_pin_bank_data exynos7_pin_banks9[] __initconst = {
+static const struct samsung_pin_bank_data exynos7_pin_banks9[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
 	EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
 };
 
-static const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos7_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 Alive data */
 		.pin_banks	= exynos7_pin_banks0,
@@ -436,13 +437,14 @@ static const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos7_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos7_of_data = {
 	.ctrl		= exynos7_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos7_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos7_of_data);
 
 /* pin banks of exynos850 pin-controller 0 (ALIVE) */
-static const struct samsung_pin_bank_data exynos850_pin_banks0[] __initconst = {
+static const struct samsung_pin_bank_data exynos850_pin_banks0[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS850_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
 	EXYNOS850_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
@@ -453,7 +455,7 @@ static const struct samsung_pin_bank_data exynos850_pin_banks0[] __initconst = {
 };
 
 /* pin banks of exynos850 pin-controller 1 (CMGP) */
-static const struct samsung_pin_bank_data exynos850_pin_banks1[] __initconst = {
+static const struct samsung_pin_bank_data exynos850_pin_banks1[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS850_PIN_BANK_EINTW(1, 0x000, "gpm0", 0x00),
 	EXYNOS850_PIN_BANK_EINTW(1, 0x020, "gpm1", 0x04),
@@ -466,27 +468,27 @@ static const struct samsung_pin_bank_data exynos850_pin_banks1[] __initconst = {
 };
 
 /* pin banks of exynos850 pin-controller 2 (AUD) */
-static const struct samsung_pin_bank_data exynos850_pin_banks2[] __initconst = {
+static const struct samsung_pin_bank_data exynos850_pin_banks2[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS850_PIN_BANK_EINTG(5, 0x000, "gpb0", 0x00),
 	EXYNOS850_PIN_BANK_EINTG(5, 0x020, "gpb1", 0x04),
 };
 
 /* pin banks of exynos850 pin-controller 3 (HSI) */
-static const struct samsung_pin_bank_data exynos850_pin_banks3[] __initconst = {
+static const struct samsung_pin_bank_data exynos850_pin_banks3[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS850_PIN_BANK_EINTG(6, 0x000, "gpf2", 0x00),
 };
 
 /* pin banks of exynos850 pin-controller 4 (CORE) */
-static const struct samsung_pin_bank_data exynos850_pin_banks4[] __initconst = {
+static const struct samsung_pin_bank_data exynos850_pin_banks4[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS850_PIN_BANK_EINTG(4, 0x000, "gpf0", 0x00),
 	EXYNOS850_PIN_BANK_EINTG(8, 0x020, "gpf1", 0x04),
 };
 
 /* pin banks of exynos850 pin-controller 5 (PERI) */
-static const struct samsung_pin_bank_data exynos850_pin_banks5[] __initconst = {
+static const struct samsung_pin_bank_data exynos850_pin_banks5[] = {
 	/* Must start with EINTG banks, ordered by EINT group number. */
 	EXYNOS850_PIN_BANK_EINTG(2, 0x000, "gpg0", 0x00),
 	EXYNOS850_PIN_BANK_EINTG(6, 0x020, "gpp0", 0x04),
@@ -499,7 +501,7 @@ static const struct samsung_pin_bank_data exynos850_pin_banks5[] __initconst = {
 	EXYNOS850_PIN_BANK_EINTG(6, 0x100, "gpc1", 0x20),
 };
 
-static const struct samsung_pin_ctrl exynos850_pin_ctrl[] __initconst = {
+static const struct samsung_pin_ctrl exynos850_pin_ctrl[] = {
 	{
 		/* pin-controller instance 0 ALIVE data */
 		.pin_banks	= exynos850_pin_banks0,
@@ -534,7 +536,8 @@ static const struct samsung_pin_ctrl exynos850_pin_ctrl[] __initconst = {
 	},
 };
 
-const struct samsung_pinctrl_of_match_data exynos850_of_data __initconst = {
+const struct samsung_pinctrl_of_match_data exynos850_of_data = {
 	.ctrl		= exynos850_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(exynos850_pin_ctrl),
 };
+EXPORT_SYMBOL_GPL(exynos850_of_data);
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 0489c899b401..628c6e94d08c 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -20,6 +20,7 @@
 #include <linux/irqchip/chained_irq.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
+#include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/regmap.h>
@@ -207,7 +208,7 @@ static void exynos_irq_release_resources(struct irq_data *irqd)
 /*
  * irq_chip for gpio interrupts.
  */
-static const struct exynos_irq_chip exynos_gpio_irq_chip __initconst = {
+static const struct exynos_irq_chip exynos_gpio_irq_chip = {
 	.chip = {
 		.name = "exynos_gpio_irq_chip",
 		.irq_unmask = exynos_irq_unmask,
@@ -275,7 +276,7 @@ struct exynos_eint_gpio_save {
  * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
  * @d: driver data of samsung pinctrl driver.
  */
-__init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
+int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
 {
 	struct samsung_pin_bank *bank;
 	struct device *dev = d->dev;
@@ -399,7 +400,7 @@ static u32 eint_wake_mask_value = EXYNOS_EINT_WAKEUP_MASK_DISABLED;
 /*
  * irq_chip for wakeup interrupts
  */
-static const struct exynos_irq_chip s5pv210_wkup_irq_chip __initconst = {
+static const struct exynos_irq_chip s5pv210_wkup_irq_chip = {
 	.chip = {
 		.name = "s5pv210_wkup_irq_chip",
 		.irq_unmask = exynos_irq_unmask,
@@ -419,7 +420,7 @@ static const struct exynos_irq_chip s5pv210_wkup_irq_chip __initconst = {
 	.set_eint_wakeup_mask = s5pv210_pinctrl_set_eint_wakeup_mask,
 };
 
-static const struct exynos_irq_chip exynos4210_wkup_irq_chip __initconst = {
+static const struct exynos_irq_chip exynos4210_wkup_irq_chip = {
 	.chip = {
 		.name = "exynos4210_wkup_irq_chip",
 		.irq_unmask = exynos_irq_unmask,
@@ -438,7 +439,7 @@ static const struct exynos_irq_chip exynos4210_wkup_irq_chip __initconst = {
 	.set_eint_wakeup_mask = exynos_pinctrl_set_eint_wakeup_mask,
 };
 
-static const struct exynos_irq_chip exynos7_wkup_irq_chip __initconst = {
+static const struct exynos_irq_chip exynos7_wkup_irq_chip = {
 	.chip = {
 		.name = "exynos7_wkup_irq_chip",
 		.irq_unmask = exynos_irq_unmask,
@@ -521,7 +522,7 @@ static void exynos_irq_demux_eint16_31(struct irq_desc *desc)
  * exynos_eint_wkup_init() - setup handling of external wakeup interrupts.
  * @d: driver data of samsung pinctrl driver.
  */
-__init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
+int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
 {
 	struct device *dev = d->dev;
 	struct device_node *wkup_np = NULL;
@@ -760,3 +761,7 @@ exynos_retention_init(struct samsung_pinctrl_drv_data *drvdata,
 
 	return ctrl;
 }
+
+MODULE_DESCRIPTION("Pinctrl common driver for Exynos, S3C24XX, and S3C64XX SoCs");
+MODULE_AUTHOR("Thomas Abraham <thomas.ab@samsung.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 2a0fc63516f1..7a5f1363d0d1 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -18,6 +18,7 @@
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
+#include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/err.h>
 #include <linux/gpio/driver.h>
@@ -1299,8 +1300,8 @@ static struct platform_driver samsung_pinctrl_driver = {
 	},
 };
 
-static int __init samsung_pinctrl_drv_register(void)
-{
-	return platform_driver_register(&samsung_pinctrl_driver);
-}
-postcore_initcall(samsung_pinctrl_drv_register);
+module_platform_driver(samsung_pinctrl_driver);
+
+MODULE_DESCRIPTION("Pinctrl common driver for Exynos, S3C24XX, and S3C64XX SoCs");
+MODULE_AUTHOR("Thomas Abraham <thomas.ab@samsung.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.33.0.685.g46640cef36-goog

RE: [PATCH v2 08/12] pinctrl: samsung: modularize the ARM and ARM64 pinctrls

[Chanho Park]

> This patch modularizes the Samsung Exynos ARM and ARM64 pinctrl drivers.
> It creates 2 kernel modules (pending Kconfig changes):

Hmm. I think we can use pinctrl-samsung.ko as a super module because chip-specific objects can be selectable by Kconfig option.
So, we don't need to separate them.

> 
> 1) pinctrl-samsung.ko: common pinctrl driver for all the samsung pinctrl
>    drivers.
> 2) pinctrl_exynos.ko: ARM and ARM64 pinctrl driver.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  drivers/pinctrl/samsung/Makefile              |  13 +--
>  drivers/pinctrl/samsung/pinctrl-exynos-arm.c  | 102 ++++++++++--------
>  .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  73 +++++++------
>  drivers/pinctrl/samsung/pinctrl-exynos.c      |  17 +--
>  drivers/pinctrl/samsung/pinctrl-samsung.c     |  11 +-
>  5 files changed, 117 insertions(+), 99 deletions(-)
> 
> diff --git a/drivers/pinctrl/samsung/Makefile
> b/drivers/pinctrl/samsung/Makefile
> index ed951df6a112..767ce3357a19 100644
> --- a/drivers/pinctrl/samsung/Makefile
> +++ b/drivers/pinctrl/samsung/Makefile
> @@ -1,9 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0
>  # Samsung pin control drivers
> 
> -obj-$(CONFIG_PINCTRL_SAMSUNG)	+= pinctrl-samsung.o
> -obj-$(CONFIG_PINCTRL_EXYNOS)	+= pinctrl-exynos.o
> -obj-$(CONFIG_PINCTRL_EXYNOS_ARM)	+= pinctrl-exynos-arm.o
> -obj-$(CONFIG_PINCTRL_EXYNOS_ARM64)	+= pinctrl-exynos-arm64.o
> -obj-$(CONFIG_PINCTRL_S3C24XX)	+= pinctrl-s3c24xx.o
> -obj-$(CONFIG_PINCTRL_S3C64XX)	+= pinctrl-s3c64xx.o
> +obj-$(CONFIG_PINCTRL_SAMSUNG)			+= pinctrl-samsung.o
> +obj-$(CONFIG_PINCTRL_EXYNOS)			+= pinctrl_exynos.o
> +pinctrl_exynos-y				+= pinctrl-exynos.o
> +pinctrl_exynos-$(CONFIG_PINCTRL_EXYNOS_ARM)	+= pinctrl-exynos-arm.o
> +pinctrl_exynos-$(CONFIG_PINCTRL_EXYNOS_ARM64)	+= pinctrl-exynos-arm64.o
> +obj-$(CONFIG_PINCTRL_S3C24XX)			+= pinctrl-s3c24xx.o
> +obj-$(CONFIG_PINCTRL_S3C64XX)			+= pinctrl-s3c64xx.o
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
> b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
> index 85ddf49a5188..f3bd8cf1bbb6 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
> @@ -83,12 +83,12 @@ s5pv210_retention_init(struct samsung_pinctrl_drv_data
> *drvdata,
>  	return ctrl;
>  }
> 
> -static const struct samsung_retention_data s5pv210_retention_data
> __initconst = {
> +static const struct samsung_retention_data s5pv210_retention_data = {
>  	.init	 = s5pv210_retention_init,
>  };

Any reason why do we need to drop __initconst and __init?
AFAIK, they will be automatically converted in case of MODULE.

> 
>  /* pin banks of s5pv210 pin-controller */ -static const struct
> samsung_pin_bank_data s5pv210_pin_bank[] __initconst = {
> +static const struct samsung_pin_bank_data s5pv210_pin_bank[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpa1", 0x04), @@ -126,7 +126,7 @@
> static const struct samsung_pin_bank_data s5pv210_pin_bank[] __initconst =
> {
>  	EXYNOS_PIN_BANK_EINTW(8, 0xc60, "gph3", 0x0c),  };
> 
> -static const struct samsung_pin_ctrl s5pv210_pin_ctrl[] __initconst = {
> +static const struct samsung_pin_ctrl s5pv210_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= s5pv210_pin_bank,
> @@ -139,16 +139,17 @@ static const struct samsung_pin_ctrl
> s5pv210_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data s5pv210_of_data __initconst =
> {
> +const struct samsung_pinctrl_of_match_data s5pv210_of_data = {
>  	.ctrl		= s5pv210_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(s5pv210_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(s5pv210_of_data);
> 
>  /* Pad retention control code for accessing PMU regmap */  static
> atomic_t exynos_shared_retention_refcnt;
> 
>  /* pin banks of exynos3250 pin-controller 0 */ -static const struct
> samsung_pin_bank_data exynos3250_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos3250_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04), @@ -160,7 +161,7 @@
> static const struct samsung_pin_bank_data exynos3250_pin_banks0[]
> __initconst =  };
> 
>  /* pin banks of exynos3250 pin-controller 1 */ -static const struct
> samsung_pin_bank_data exynos3250_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos3250_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTN(8, 0x120, "gpe0"),
>  	EXYNOS_PIN_BANK_EINTN(8, 0x140, "gpe1"), @@ -196,7 +197,7 @@ static
> const u32 exynos3250_retention_regs[] = {
>  	S5P_PAD_RET_SPI_OPTION,
>  };
> 
> -static const struct samsung_retention_data exynos3250_retention_data
> __initconst = {
> +static const struct samsung_retention_data exynos3250_retention_data =
> +{
>  	.regs	 = exynos3250_retention_regs,
>  	.nr_regs = ARRAY_SIZE(exynos3250_retention_regs),
>  	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
> @@ -208,7 +209,7 @@ static const struct samsung_retention_data
> exynos3250_retention_data __initconst
>   * Samsung pinctrl driver data for Exynos3250 SoC. Exynos3250 SoC
> includes
>   * two gpio/pin-mux/pinconfig controllers.
>   */
> -static const struct samsung_pin_ctrl exynos3250_pin_ctrl[] __initconst =
> {
> +static const struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= exynos3250_pin_banks0,
> @@ -229,13 +230,14 @@ static const struct samsung_pin_ctrl
> exynos3250_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos3250_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos3250_of_data = {
>  	.ctrl		= exynos3250_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos3250_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos3250_of_data);
> 
>  /* pin banks of exynos4210 pin-controller 0 */ -static const struct
> samsung_pin_bank_data exynos4210_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos4210_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04), @@ -256,7 +258,7 @@
> static const struct samsung_pin_bank_data exynos4210_pin_banks0[]
> __initconst =  };
> 
>  /* pin banks of exynos4210 pin-controller 1 */ -static const struct
> samsung_pin_bank_data exynos4210_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos4210_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpj0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(5, 0x020, "gpj1", 0x04), @@ -281,7 +283,7 @@
> static const struct samsung_pin_bank_data exynos4210_pin_banks1[]
> __initconst =  };
> 
>  /* pin banks of exynos4210 pin-controller 2 */ -static const struct
> samsung_pin_bank_data exynos4210_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos4210_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTN(7, 0x000, "gpz"),  }; @@ -296,7 +298,7 @@
> static const u32 exynos4_retention_regs[] = {
>  	S5P_PAD_RET_EBIB_OPTION,
>  };
> 
> -static const struct samsung_retention_data exynos4_retention_data
> __initconst = {
> +static const struct samsung_retention_data exynos4_retention_data = {
>  	.regs	 = exynos4_retention_regs,
>  	.nr_regs = ARRAY_SIZE(exynos4_retention_regs),
>  	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
> @@ -309,7 +311,7 @@ static const u32 exynos4_audio_retention_regs[] = {
>  	S5P_PAD_RET_MAUDIO_OPTION,
>  };
> 
> -static const struct samsung_retention_data exynos4_audio_retention_data
> __initconst = {
> +static const struct samsung_retention_data exynos4_audio_retention_data
> += {
>  	.regs	 = exynos4_audio_retention_regs,
>  	.nr_regs = ARRAY_SIZE(exynos4_audio_retention_regs),
>  	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
> @@ -320,7 +322,7 @@ static const struct samsung_retention_data
> exynos4_audio_retention_data __initco
>   * Samsung pinctrl driver data for Exynos4210 SoC. Exynos4210 SoC
> includes
>   * three gpio/pin-mux/pinconfig controllers.
>   */
> -static const struct samsung_pin_ctrl exynos4210_pin_ctrl[] __initconst =
> {
> +static const struct samsung_pin_ctrl exynos4210_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= exynos4210_pin_banks0,
> @@ -346,13 +348,14 @@ static const struct samsung_pin_ctrl
> exynos4210_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos4210_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos4210_of_data = {
>  	.ctrl		= exynos4210_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos4210_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos4210_of_data);
> 
>  /* pin banks of exynos4x12 pin-controller 0 */ -static const struct
> samsung_pin_bank_data exynos4x12_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos4x12_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04), @@ -370,7 +373,7 @@
> static const struct samsung_pin_bank_data exynos4x12_pin_banks0[]
> __initconst =  };
> 
>  /* pin banks of exynos4x12 pin-controller 1 */ -static const struct
> samsung_pin_bank_data exynos4x12_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos4x12_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x040, "gpk0", 0x08),
>  	EXYNOS_PIN_BANK_EINTG(7, 0x060, "gpk1", 0x0c), @@ -398,13 +401,13
> @@ static const struct samsung_pin_bank_data exynos4x12_pin_banks1[]
> __initconst =  };
> 
>  /* pin banks of exynos4x12 pin-controller 2 */ -static const struct
> samsung_pin_bank_data exynos4x12_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos4x12_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),  };
> 
>  /* pin banks of exynos4x12 pin-controller 3 */ -static const struct
> samsung_pin_bank_data exynos4x12_pin_banks3[] __initconst = {
> +static const struct samsung_pin_bank_data exynos4x12_pin_banks3[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04), @@ -417,7 +420,7 @@
> static const struct samsung_pin_bank_data exynos4x12_pin_banks3[]
> __initconst =
>   * Samsung pinctrl driver data for Exynos4x12 SoC. Exynos4x12 SoC
> includes
>   * four gpio/pin-mux/pinconfig controllers.
>   */
> -static const struct samsung_pin_ctrl exynos4x12_pin_ctrl[] __initconst =
> {
> +static const struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= exynos4x12_pin_banks0,
> @@ -453,13 +456,14 @@ static const struct samsung_pin_ctrl
> exynos4x12_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos4x12_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos4x12_of_data = {
>  	.ctrl		= exynos4x12_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos4x12_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos4x12_of_data);
> 
>  /* pin banks of exynos5250 pin-controller 0 */ -static const struct
> samsung_pin_bank_data exynos5250_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5250_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04), @@ -489,7 +493,7 @@
> static const struct samsung_pin_bank_data exynos5250_pin_banks0[]
> __initconst =  };
> 
>  /* pin banks of exynos5250 pin-controller 1 */ -static const struct
> samsung_pin_bank_data exynos5250_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5250_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpe0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(2, 0x020, "gpe1", 0x04), @@ -503,7 +507,7 @@
> static const struct samsung_pin_bank_data exynos5250_pin_banks1[]
> __initconst =  };
> 
>  /* pin banks of exynos5250 pin-controller 2 */ -static const struct
> samsung_pin_bank_data exynos5250_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5250_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04), @@ -513,7 +517,7 @@
> static const struct samsung_pin_bank_data exynos5250_pin_banks2[]
> __initconst =  };
> 
>  /* pin banks of exynos5250 pin-controller 3 */ -static const struct
> samsung_pin_bank_data exynos5250_pin_banks3[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5250_pin_banks3[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),  }; @@ -522,7 +526,7
> @@ static const struct samsung_pin_bank_data exynos5250_pin_banks3[]
> __initconst =
>   * Samsung pinctrl driver data for Exynos5250 SoC. Exynos5250 SoC
> includes
>   * four gpio/pin-mux/pinconfig controllers.
>   */
> -static const struct samsung_pin_ctrl exynos5250_pin_ctrl[] __initconst =
> {
> +static const struct samsung_pin_ctrl exynos5250_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= exynos5250_pin_banks0,
> @@ -558,13 +562,14 @@ static const struct samsung_pin_ctrl
> exynos5250_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos5250_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos5250_of_data = {
>  	.ctrl		= exynos5250_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos5250_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos5250_of_data);
> 
>  /* pin banks of exynos5260 pin-controller 0 */ -static const struct
> samsung_pin_bank_data exynos5260_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5260_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(7, 0x020, "gpa1", 0x04), @@ -590,7 +595,7 @@
> static const struct samsung_pin_bank_data exynos5260_pin_banks0[]
> __initconst =  };
> 
>  /* pin banks of exynos5260 pin-controller 1 */ -static const struct
> samsung_pin_bank_data exynos5260_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5260_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpc0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpc1", 0x04), @@ -600,7 +605,7 @@
> static const struct samsung_pin_bank_data exynos5260_pin_banks1[]
> __initconst =  };
> 
>  /* pin banks of exynos5260 pin-controller 2 */ -static const struct
> samsung_pin_bank_data exynos5260_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5260_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04), @@ -610,7 +615,7 @@
> static const struct samsung_pin_bank_data exynos5260_pin_banks2[]
> __initconst =
>   * Samsung pinctrl driver data for Exynos5260 SoC. Exynos5260 SoC
> includes
>   * three gpio/pin-mux/pinconfig controllers.
>   */
> -static const struct samsung_pin_ctrl exynos5260_pin_ctrl[] __initconst =
> {
> +static const struct samsung_pin_ctrl exynos5260_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= exynos5260_pin_banks0,
> @@ -636,13 +641,14 @@ static const struct samsung_pin_ctrl
> exynos5260_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos5260_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos5260_of_data = {
>  	.ctrl		= exynos5260_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos5260_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos5260_of_data);
> 
>  /* pin banks of exynos5410 pin-controller 0 */ -static const struct
> samsung_pin_bank_data exynos5410_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5410_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04), @@ -682,7 +688,7 @@
> static const struct samsung_pin_bank_data exynos5410_pin_banks0[]
> __initconst =  };
> 
>  /* pin banks of exynos5410 pin-controller 1 */ -static const struct
> samsung_pin_bank_data exynos5410_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5410_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(5, 0x000, "gpj0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpj1", 0x04), @@ -696,7 +702,7 @@
> static const struct samsung_pin_bank_data exynos5410_pin_banks1[]
> __initconst =  };
> 
>  /* pin banks of exynos5410 pin-controller 2 */ -static const struct
> samsung_pin_bank_data exynos5410_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5410_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04), @@ -706,7 +712,7 @@
> static const struct samsung_pin_bank_data exynos5410_pin_banks2[]
> __initconst =  };
> 
>  /* pin banks of exynos5410 pin-controller 3 */ -static const struct
> samsung_pin_bank_data exynos5410_pin_banks3[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5410_pin_banks3[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),  }; @@ -715,7 +721,7
> @@ static const struct samsung_pin_bank_data exynos5410_pin_banks3[]
> __initconst =
>   * Samsung pinctrl driver data for Exynos5410 SoC. Exynos5410 SoC
> includes
>   * four gpio/pin-mux/pinconfig controllers.
>   */
> -static const struct samsung_pin_ctrl exynos5410_pin_ctrl[] __initconst =
> {
> +static const struct samsung_pin_ctrl exynos5410_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= exynos5410_pin_banks0,
> @@ -748,13 +754,14 @@ static const struct samsung_pin_ctrl
> exynos5410_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos5410_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos5410_of_data = {
>  	.ctrl		= exynos5410_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos5410_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos5410_of_data);
> 
>  /* pin banks of exynos5420 pin-controller 0 */ -static const struct
> samsung_pin_bank_data exynos5420_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5420_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpy7", 0x00),
>  	EXYNOS_PIN_BANK_EINTW(8, 0xC00, "gpx0", 0x00), @@ -764,7 +771,7 @@
> static const struct samsung_pin_bank_data exynos5420_pin_banks0[]
> __initconst =  };
> 
>  /* pin banks of exynos5420 pin-controller 1 */ -static const struct
> samsung_pin_bank_data exynos5420_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5420_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpc0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpc1", 0x04), @@ -782,7 +789,7 @@
> static const struct samsung_pin_bank_data exynos5420_pin_banks1[]
> __initconst =  };
> 
>  /* pin banks of exynos5420 pin-controller 2 */ -static const struct
> samsung_pin_bank_data exynos5420_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5420_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpe0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(2, 0x020, "gpe1", 0x04), @@ -795,7 +802,7 @@
> static const struct samsung_pin_bank_data exynos5420_pin_banks2[]
> __initconst =  };
> 
>  /* pin banks of exynos5420 pin-controller 3 */ -static const struct
> samsung_pin_bank_data exynos5420_pin_banks3[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5420_pin_banks3[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04), @@ -809,7 +816,7 @@
> static const struct samsung_pin_bank_data exynos5420_pin_banks3[]
> __initconst =  };
> 
>  /* pin banks of exynos5420 pin-controller 4 */ -static const struct
> samsung_pin_bank_data exynos5420_pin_banks4[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5420_pin_banks4[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),  }; @@ -830,7 +837,7
> @@ static const u32 exynos5420_retention_regs[] = {
>  	EXYNOS5420_PAD_RET_DRAM_COREBLK_OPTION,
>  };
> 
> -static const struct samsung_retention_data exynos5420_retention_data
> __initconst = {
> +static const struct samsung_retention_data exynos5420_retention_data =
> +{
>  	.regs	 = exynos5420_retention_regs,
>  	.nr_regs = ARRAY_SIZE(exynos5420_retention_regs),
>  	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
> @@ -842,7 +849,7 @@ static const struct samsung_retention_data
> exynos5420_retention_data __initconst
>   * Samsung pinctrl driver data for Exynos5420 SoC. Exynos5420 SoC
> includes
>   * four gpio/pin-mux/pinconfig controllers.
>   */
> -static const struct samsung_pin_ctrl exynos5420_pin_ctrl[] __initconst =
> {
> +static const struct samsung_pin_ctrl exynos5420_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= exynos5420_pin_banks0,
> @@ -887,7 +894,8 @@ static const struct samsung_pin_ctrl
> exynos5420_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos5420_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos5420_of_data = {
>  	.ctrl		= exynos5420_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos5420_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos5420_of_data);
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> index fe5f6046fbd5..9fb658c65b96 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
> @@ -62,7 +62,7 @@ static const struct samsung_pin_bank_type
> exynos850_bank_type_alive = {  static atomic_t
> exynos_shared_retention_refcnt;
> 
>  /* pin banks of exynos5433 pin-controller - ALIVE */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
>  	EXYNOS5433_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04), @@ -76,32 +76,32
> @@ static const struct samsung_pin_bank_data exynos5433_pin_banks0[]
> __initconst =  };
> 
>  /* pin banks of exynos5433 pin-controller - AUD */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
>  	EXYNOS5433_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),  };
> 
>  /* pin banks of exynos5433 pin-controller - CPIF */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),  };
> 
>  /* pin banks of exynos5433 pin-controller - eSE */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks3[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks3[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),  };
> 
>  /* pin banks of exynos5433 pin-controller - FINGER */ -static const
> struct samsung_pin_bank_data exynos5433_pin_banks4[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks4[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),  };
> 
>  /* pin banks of exynos5433 pin-controller - FSYS */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks5[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks5[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
>  	EXYNOS5433_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04), @@ -112,19
> +112,19 @@ static const struct samsung_pin_bank_data
> exynos5433_pin_banks5[] __initconst =  };
> 
>  /* pin banks of exynos5433 pin-controller - IMEM */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks6[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks6[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(8, 0x000, "gpf0", 0x00),  };
> 
>  /* pin banks of exynos5433 pin-controller - NFC */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks7[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks7[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(3, 0x000, "gpj0", 0x00),  };
> 
>  /* pin banks of exynos5433 pin-controller - PERIC */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks8[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks8[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(6, 0x000, "gpv7", 0x00),
>  	EXYNOS5433_PIN_BANK_EINTG(5, 0x020, "gpb0", 0x04), @@ -146,7 +146,7
> @@ static const struct samsung_pin_bank_data exynos5433_pin_banks8[]
> __initconst =  };
> 
>  /* pin banks of exynos5433 pin-controller - TOUCH */ -static const struct
> samsung_pin_bank_data exynos5433_pin_banks9[] __initconst = {
> +static const struct samsung_pin_bank_data exynos5433_pin_banks9[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS5433_PIN_BANK_EINTG(3, 0x000, "gpj1", 0x00),  }; @@ -165,7
> +165,7 @@ static const u32 exynos5433_retention_regs[] = {
>  	EXYNOS5433_PAD_RETENTION_FSYSGENIO_OPTION,
>  };
> 
> -static const struct samsung_retention_data exynos5433_retention_data
> __initconst = {
> +static const struct samsung_retention_data exynos5433_retention_data =
> +{
>  	.regs	 = exynos5433_retention_regs,
>  	.nr_regs = ARRAY_SIZE(exynos5433_retention_regs),
>  	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
> @@ -178,7 +178,7 @@ static const u32 exynos5433_audio_retention_regs[] = {
>  	EXYNOS5433_PAD_RETENTION_AUD_OPTION,
>  };
> 
> -static const struct samsung_retention_data
> exynos5433_audio_retention_data __initconst = {
> +static const struct samsung_retention_data
> +exynos5433_audio_retention_data = {
>  	.regs	 = exynos5433_audio_retention_regs,
>  	.nr_regs = ARRAY_SIZE(exynos5433_audio_retention_regs),
>  	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
> @@ -192,7 +192,7 @@ static const u32 exynos5433_fsys_retention_regs[] = {
>  	EXYNOS5433_PAD_RETENTION_MMC2_OPTION,
>  };
> 
> -static const struct samsung_retention_data exynos5433_fsys_retention_data
> __initconst = {
> +static const struct samsung_retention_data
> +exynos5433_fsys_retention_data = {
>  	.regs	 = exynos5433_fsys_retention_regs,
>  	.nr_regs = ARRAY_SIZE(exynos5433_fsys_retention_regs),
>  	.value	 = EXYNOS_WAKEUP_FROM_LOWPWR,
> @@ -203,7 +203,7 @@ static const struct samsung_retention_data
> exynos5433_fsys_retention_data __init
>   * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC
> includes
>   * ten gpio/pin-mux/pinconfig controllers.
>   */
> -static const struct samsung_pin_ctrl exynos5433_pin_ctrl[] __initconst =
> {
> +static const struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 data */
>  		.pin_banks	= exynos5433_pin_banks0,
> @@ -288,13 +288,14 @@ static const struct samsung_pin_ctrl
> exynos5433_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos5433_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos5433_of_data = {
>  	.ctrl		= exynos5433_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos5433_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos5433_of_data);
> 
>  /* pin banks of exynos7 pin-controller - ALIVE */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
>  	EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04), @@ -303,7 +304,7 @@
> static const struct samsung_pin_bank_data exynos7_pin_banks0[] __initconst
> = {  };
> 
>  /* pin banks of exynos7 pin-controller - BUS0 */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(5, 0x000, "gpb0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpc0", 0x04), @@ -323,37 +324,37
> @@ static const struct samsung_pin_bank_data exynos7_pin_banks1[]
> __initconst = {  };
> 
>  /* pin banks of exynos7 pin-controller - NFC */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj0", 0x00),  };
> 
>  /* pin banks of exynos7 pin-controller - TOUCH */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks3[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks3[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj1", 0x00),  };
> 
>  /* pin banks of exynos7 pin-controller - FF */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks4[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks4[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpg4", 0x00),  };
> 
>  /* pin banks of exynos7 pin-controller - ESE */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks5[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks5[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(5, 0x000, "gpv7", 0x00),  };
> 
>  /* pin banks of exynos7 pin-controller - FSYS0 */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks6[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks6[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpr4", 0x00),  };
> 
>  /* pin banks of exynos7 pin-controller - FSYS1 */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks7[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks7[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpr0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpr1", 0x04), @@ -362,7 +363,7 @@
> static const struct samsung_pin_bank_data exynos7_pin_banks7[] __initconst
> = {  };
> 
>  /* pin banks of exynos7 pin-controller - BUS1 */ -static const struct
> samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04), @@ -376,13 +377,13
> @@ static const struct samsung_pin_bank_data exynos7_pin_banks8[]
> __initconst = {
>  	EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),  };
> 
> -static const struct samsung_pin_bank_data exynos7_pin_banks9[]
> __initconst = {
> +static const struct samsung_pin_bank_data exynos7_pin_banks9[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
>  	EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),  };
> 
> -static const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
> +static const struct samsung_pin_ctrl exynos7_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 Alive data */
>  		.pin_banks	= exynos7_pin_banks0,
> @@ -436,13 +437,14 @@ static const struct samsung_pin_ctrl
> exynos7_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos7_of_data __initconst =
> {
> +const struct samsung_pinctrl_of_match_data exynos7_of_data = {
>  	.ctrl		= exynos7_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos7_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos7_of_data);
> 
>  /* pin banks of exynos850 pin-controller 0 (ALIVE) */ -static const
> struct samsung_pin_bank_data exynos850_pin_banks0[] __initconst = {
> +static const struct samsung_pin_bank_data exynos850_pin_banks0[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS850_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
>  	EXYNOS850_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04), @@ -453,7 +455,7
> @@ static const struct samsung_pin_bank_data exynos850_pin_banks0[]
> __initconst = {  };
> 
>  /* pin banks of exynos850 pin-controller 1 (CMGP) */ -static const struct
> samsung_pin_bank_data exynos850_pin_banks1[] __initconst = {
> +static const struct samsung_pin_bank_data exynos850_pin_banks1[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS850_PIN_BANK_EINTW(1, 0x000, "gpm0", 0x00),
>  	EXYNOS850_PIN_BANK_EINTW(1, 0x020, "gpm1", 0x04), @@ -466,27
> +468,27 @@ static const struct samsung_pin_bank_data exynos850_pin_banks1[]
> __initconst = {  };
> 
>  /* pin banks of exynos850 pin-controller 2 (AUD) */ -static const struct
> samsung_pin_bank_data exynos850_pin_banks2[] __initconst = {
> +static const struct samsung_pin_bank_data exynos850_pin_banks2[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS850_PIN_BANK_EINTG(5, 0x000, "gpb0", 0x00),
>  	EXYNOS850_PIN_BANK_EINTG(5, 0x020, "gpb1", 0x04),  };
> 
>  /* pin banks of exynos850 pin-controller 3 (HSI) */ -static const struct
> samsung_pin_bank_data exynos850_pin_banks3[] __initconst = {
> +static const struct samsung_pin_bank_data exynos850_pin_banks3[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS850_PIN_BANK_EINTG(6, 0x000, "gpf2", 0x00),  };
> 
>  /* pin banks of exynos850 pin-controller 4 (CORE) */ -static const struct
> samsung_pin_bank_data exynos850_pin_banks4[] __initconst = {
> +static const struct samsung_pin_bank_data exynos850_pin_banks4[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS850_PIN_BANK_EINTG(4, 0x000, "gpf0", 0x00),
>  	EXYNOS850_PIN_BANK_EINTG(8, 0x020, "gpf1", 0x04),  };
> 
>  /* pin banks of exynos850 pin-controller 5 (PERI) */ -static const struct
> samsung_pin_bank_data exynos850_pin_banks5[] __initconst = {
> +static const struct samsung_pin_bank_data exynos850_pin_banks5[] = {
>  	/* Must start with EINTG banks, ordered by EINT group number. */
>  	EXYNOS850_PIN_BANK_EINTG(2, 0x000, "gpg0", 0x00),
>  	EXYNOS850_PIN_BANK_EINTG(6, 0x020, "gpp0", 0x04), @@ -499,7 +501,7
> @@ static const struct samsung_pin_bank_data exynos850_pin_banks5[]
> __initconst = {
>  	EXYNOS850_PIN_BANK_EINTG(6, 0x100, "gpc1", 0x20),  };
> 
> -static const struct samsung_pin_ctrl exynos850_pin_ctrl[] __initconst = {
> +static const struct samsung_pin_ctrl exynos850_pin_ctrl[] = {
>  	{
>  		/* pin-controller instance 0 ALIVE data */
>  		.pin_banks	= exynos850_pin_banks0,
> @@ -534,7 +536,8 @@ static const struct samsung_pin_ctrl
> exynos850_pin_ctrl[] __initconst = {
>  	},
>  };
> 
> -const struct samsung_pinctrl_of_match_data exynos850_of_data __initconst
> = {
> +const struct samsung_pinctrl_of_match_data exynos850_of_data = {
>  	.ctrl		= exynos850_pin_ctrl,
>  	.num_ctrl	= ARRAY_SIZE(exynos850_pin_ctrl),
>  };
> +EXPORT_SYMBOL_GPL(exynos850_of_data);
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
> b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index 0489c899b401..628c6e94d08c 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -20,6 +20,7 @@
>  #include <linux/irqchip/chained_irq.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
> +#include <linux/module.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
>  #include <linux/regmap.h>
> @@ -207,7 +208,7 @@ static void exynos_irq_release_resources(struct
> irq_data *irqd)
>  /*
>   * irq_chip for gpio interrupts.
>   */
> -static const struct exynos_irq_chip exynos_gpio_irq_chip __initconst = {
> +static const struct exynos_irq_chip exynos_gpio_irq_chip = {
>  	.chip = {
>  		.name = "exynos_gpio_irq_chip",
>  		.irq_unmask = exynos_irq_unmask,
> @@ -275,7 +276,7 @@ struct exynos_eint_gpio_save {
>   * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
>   * @d: driver data of samsung pinctrl driver.
>   */
> -__init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
> +int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
>  {
>  	struct samsung_pin_bank *bank;
>  	struct device *dev = d->dev;
> @@ -399,7 +400,7 @@ static u32 eint_wake_mask_value =
> EXYNOS_EINT_WAKEUP_MASK_DISABLED;
>  /*
>   * irq_chip for wakeup interrupts
>   */
> -static const struct exynos_irq_chip s5pv210_wkup_irq_chip __initconst = {
> +static const struct exynos_irq_chip s5pv210_wkup_irq_chip = {
>  	.chip = {
>  		.name = "s5pv210_wkup_irq_chip",
>  		.irq_unmask = exynos_irq_unmask,
> @@ -419,7 +420,7 @@ static const struct exynos_irq_chip
> s5pv210_wkup_irq_chip __initconst = {
>  	.set_eint_wakeup_mask = s5pv210_pinctrl_set_eint_wakeup_mask,
>  };
> 
> -static const struct exynos_irq_chip exynos4210_wkup_irq_chip __initconst
> = {
> +static const struct exynos_irq_chip exynos4210_wkup_irq_chip = {
>  	.chip = {
>  		.name = "exynos4210_wkup_irq_chip",
>  		.irq_unmask = exynos_irq_unmask,
> @@ -438,7 +439,7 @@ static const struct exynos_irq_chip
> exynos4210_wkup_irq_chip __initconst = {
>  	.set_eint_wakeup_mask = exynos_pinctrl_set_eint_wakeup_mask,
>  };
> 
> -static const struct exynos_irq_chip exynos7_wkup_irq_chip __initconst = {
> +static const struct exynos_irq_chip exynos7_wkup_irq_chip = {
>  	.chip = {
>  		.name = "exynos7_wkup_irq_chip",
>  		.irq_unmask = exynos_irq_unmask,
> @@ -521,7 +522,7 @@ static void exynos_irq_demux_eint16_31(struct irq_desc
> *desc)
>   * exynos_eint_wkup_init() - setup handling of external wakeup interrupts.
>   * @d: driver data of samsung pinctrl driver.
>   */
> -__init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
> +int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
>  {
>  	struct device *dev = d->dev;
>  	struct device_node *wkup_np = NULL;
> @@ -760,3 +761,7 @@ exynos_retention_init(struct samsung_pinctrl_drv_data
> *drvdata,
> 
>  	return ctrl;
>  }
> +
> +MODULE_DESCRIPTION("Pinctrl common driver for Exynos, S3C24XX, and
> +S3C64XX SoCs"); MODULE_AUTHOR("Thomas Abraham
> +<thomas.ab@samsung.com>"); MODULE_LICENSE("GPL v2");
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c
> b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 2a0fc63516f1..7a5f1363d0d1 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -18,6 +18,7 @@
>  #include <linux/init.h>
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
> +#include <linux/module.h>
>  #include <linux/slab.h>
>  #include <linux/err.h>
>  #include <linux/gpio/driver.h>
> @@ -1299,8 +1300,8 @@ static struct platform_driver samsung_pinctrl_driver
> = {
>  	},
>  };
> 
> -static int __init samsung_pinctrl_drv_register(void)
> -{
> -	return platform_driver_register(&samsung_pinctrl_driver);
> -}
> -postcore_initcall(samsung_pinctrl_drv_register);
> +module_platform_driver(samsung_pinctrl_driver);

To keep previous initcall order, please do not use module_platform_driver macro.

Best Regards,
Chanho Park

[PATCH v2 09/12] pinctrl: samsung: set PINCTRL_EXYNOS and PINCTRL_SAMSUNG as tristate

[Will McVicker]

Make PINCTRL_EXYNOS and PINCTRL_SAMSUNG tristate so that we can compile
them as modules. Also don't have ARCH_EXYNOS directly select them, but
use "default y if ARCH_EXYNOS || ARCH_S5PV210" instead.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm/mach-exynos/Kconfig    | 1 -
 arch/arm/mach-s5pv210/Kconfig   | 1 -
 arch/arm64/Kconfig.platforms    | 1 -
 drivers/pinctrl/samsung/Kconfig | 5 +++--
 4 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 01b8e8b8d95d..afc8cd062605 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -22,7 +22,6 @@ menuconfig ARCH_EXYNOS
 	select HAVE_S3C2410_I2C if I2C
 	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
-	select PINCTRL_EXYNOS
 	select PM_GENERIC_DOMAINS if PM
 	select S5P_DEV_MFC
 	select SAMSUNG_MC
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 3d7e0b5739d8..62b90dda571f 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -14,7 +14,6 @@ config ARCH_S5PV210
 	select HAVE_S3C2410_I2C if I2C
 	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
-	select PINCTRL_EXYNOS
 	select SOC_SAMSUNG
 	help
 	  Samsung S5PV210/S5PC110 series based systems
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index e6d4abadacd8..67f60cc3c723 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -95,7 +95,6 @@ config ARCH_EXYNOS
 	select EXYNOS_PMU
 	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
-	select PINCTRL_EXYNOS
 	select PM_GENERIC_DOMAINS if PM
 	select SOC_SAMSUNG
 	help
diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
index dfd805e76862..caeb865cfa21 100644
--- a/drivers/pinctrl/samsung/Kconfig
+++ b/drivers/pinctrl/samsung/Kconfig
@@ -3,15 +3,16 @@
 # Samsung Pin control drivers
 #
 config PINCTRL_SAMSUNG
-	bool
+	tristate "Pinctrl common driver for Exynos, S3C24XX, and S3C64XX SoCs" if COMPILE_TEST
 	depends on OF_GPIO
 	select PINMUX
 	select PINCONF
 
 config PINCTRL_EXYNOS
-	bool "Pinctrl common driver part for Samsung Exynos SoCs"
+	tristate "Pinctrl common driver part for Samsung Exynos ARM and ARM64 SoCs"
 	depends on OF_GPIO
 	depends on ARCH_EXYNOS || ARCH_S5PV210 || COMPILE_TEST
+	default y if (ARCH_EXYNOS || ARCH_S5PV210)
 	select PINCTRL_SAMSUNG
 	select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210)
 	select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
-- 
2.33.0.685.g46640cef36-goog

[PATCH v2 10/12] soc: samsung: pmu: modularize the Exynos ARMv8 PMU driver

[Will McVicker]

In order to only modularize the Exynos ARMv8 PMU driver, we have to
split it up from the ARM PMU driver. So make the following Kconfig
changes:
  * EXYNOS_PMU -> EXYNOS_PMU_ARM64
  * EXYNOS_PMU_ARM_DRIVERS -> EXYNOS_PMU_ARM

This patch also includes the necessary modularization changes.

Lastly, have EXYNOS_PMU_ARM64 use "default y if ARCH_EXYNOS && ARM64"
instead of having ARCH_EXYNOS select it directly.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm/mach-exynos/Kconfig           |  2 +-
 arch/arm64/Kconfig.platforms           |  1 -
 drivers/soc/samsung/Kconfig            | 15 +++++++++------
 drivers/soc/samsung/Makefile           |  8 +++++---
 drivers/soc/samsung/exynos-pmu.c       | 13 +++++++------
 drivers/soc/samsung/exynos-pmu.h       |  2 +-
 include/linux/soc/samsung/exynos-pmu.h |  2 +-
 7 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index afc8cd062605..e97e1d8f7b00 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -13,7 +13,7 @@ menuconfig ARCH_EXYNOS
 	select ARM_GIC
 	select EXYNOS_IRQ_COMBINER
 	select EXYNOS_THERMAL
-	select EXYNOS_PMU
+	select EXYNOS_PMU_ARM
 	select EXYNOS_SROM
 	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 	select GPIOLIB
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 67f60cc3c723..e5e4b9b2fb97 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -92,7 +92,6 @@ config ARCH_BRCMSTB
 config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
 	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
-	select EXYNOS_PMU
 	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
 	select PM_GENERIC_DOMAINS if PM
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index d3746415be72..fdf1162ec98b 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -23,15 +23,18 @@ config EXYNOS_CHIPID
 	  Support for Samsung Exynos SoC ChipID and Adaptive Supply Voltage.
 	  This driver can also be built as module (exynos_chipid).
 
-config EXYNOS_PMU
-	bool "Exynos PMU controller driver" if COMPILE_TEST
-	depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
-	select EXYNOS_PMU_ARM_DRIVERS if ARM && ARCH_EXYNOS
+config EXYNOS_PMU_ARM64
+	tristate "Exynos PMU controller driver"
+	depends on ARCH_EXYNOS || (ARM64 && COMPILE_TEST)
+	default y if (ARCH_EXYNOS && ARM64)
+	help
+	  Support for Samsung Exynos ARMv8 PMU controller. This driver can be
+	  built-in or as a module (exynos-pmu).
 
 # There is no need to enable these drivers for ARMv8
-config EXYNOS_PMU_ARM_DRIVERS
+config EXYNOS_PMU_ARM
 	bool "Exynos PMU ARMv7-specific driver extensions" if COMPILE_TEST
-	depends on EXYNOS_PMU
+	depends on ARCH_EXYNOS || (ARM && COMPILE_TEST)
 
 config EXYNOS_PM_DOMAINS
 	bool "Exynos PM domains" if COMPILE_TEST
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 2ae4bea804cf..cd55c72a052d 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -4,10 +4,12 @@ obj-$(CONFIG_EXYNOS_ASV_ARM)	+= exynos5422-asv.o
 obj-$(CONFIG_EXYNOS_CHIPID)	+= exynos_chipid.o
 exynos_chipid-y			+= exynos-chipid.o exynos-asv.o
 
-obj-$(CONFIG_EXYNOS_PMU)	+= exynos-pmu.o
+obj-$(CONFIG_EXYNOS_PMU_ARM64)	+= exynos-pmu.o
+
+obj-$(CONFIG_EXYNOS_PMU_ARM)	+= exynos-pmu32.o
+exynos-pmu32-y			+= exynos-pmu.o exynos3250-pmu.o \
+			exynos4-pmu.o exynos5250-pmu.o exynos5420-pmu.o
 
-obj-$(CONFIG_EXYNOS_PMU_ARM_DRIVERS)	+= exynos3250-pmu.o exynos4-pmu.o \
-					exynos5250-pmu.o exynos5420-pmu.o
 obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
 obj-$(CONFIG_EXYNOS_REGULATOR_COUPLER) += exynos-regulator-coupler.o
 
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index a18c93a4646c..3dd0219c908c 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -8,6 +8,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_device.h>
+#include <linux/module.h>
 #include <linux/mfd/core.h>
 #include <linux/mfd/syscon.h>
 #include <linux/platform_device.h>
@@ -63,7 +64,7 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
  * Split the data between ARM architectures because it is relatively big
  * and useless on other arch.
  */
-#ifdef CONFIG_EXYNOS_PMU_ARM_DRIVERS
+#ifdef CONFIG_EXYNOS_PMU_ARM
 #define exynos_pmu_data_arm_ptr(data)	(&data)
 #else
 #define exynos_pmu_data_arm_ptr(data)	NULL
@@ -154,9 +155,9 @@ static struct platform_driver exynos_pmu_driver = {
 	.probe = exynos_pmu_probe,
 };
 
-static int __init exynos_pmu_init(void)
-{
-	return platform_driver_register(&exynos_pmu_driver);
+module_platform_driver(exynos_pmu_driver);
 
-}
-postcore_initcall(exynos_pmu_init);
+MODULE_DESCRIPTION("Exynos PMU controller driver");
+MODULE_AUTHOR("Marek Szyprowski <m.szyprowski@samsung.com>");
+MODULE_AUTHOR("Krzysztof Kozlowski <krzk@kernel.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index 5e851f32307e..4a7f03c79dd0 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -28,7 +28,7 @@ struct exynos_pmu_data {
 
 extern void __iomem *pmu_base_addr;
 
-#ifdef CONFIG_EXYNOS_PMU_ARM_DRIVERS
+#ifdef CONFIG_EXYNOS_PMU_ARM
 /* list of all exported SoC specific data */
 extern const struct exynos_pmu_data exynos3250_pmu_data;
 extern const struct exynos_pmu_data exynos4210_pmu_data;
diff --git a/include/linux/soc/samsung/exynos-pmu.h b/include/linux/soc/samsung/exynos-pmu.h
index a4f5516cc956..d7317e0902b8 100644
--- a/include/linux/soc/samsung/exynos-pmu.h
+++ b/include/linux/soc/samsung/exynos-pmu.h
@@ -19,7 +19,7 @@ enum sys_powerdown {
 };
 
 extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
-#ifdef CONFIG_EXYNOS_PMU
+#if IS_ENABLED(CONFIG_EXYNOS_PMU_ARM64) || IS_ENABLED(CONFIG_EXYNOS_PMU_ARM)
 extern struct regmap *exynos_get_pmu_regmap(void);
 #else
 static inline struct regmap *exynos_get_pmu_regmap(void)
-- 
2.33.0.685.g46640cef36-goog

Re: [PATCH v2 10/12] soc: samsung: pmu: modularize the Exynos ARMv8 PMU driver

[Krzysztof Kozlowski]

On 29/09/2021 01:56, Will McVicker wrote:
> In order to only modularize the Exynos ARMv8 PMU driver, we have to
> split it up from the ARM PMU driver. So make the following Kconfig
> changes:
>   * EXYNOS_PMU -> EXYNOS_PMU_ARM64
>   * EXYNOS_PMU_ARM_DRIVERS -> EXYNOS_PMU_ARM
> 
> This patch also includes the necessary modularization changes.
> 
> Lastly, have EXYNOS_PMU_ARM64 use "default y if ARCH_EXYNOS && ARM64"
> instead of having ARCH_EXYNOS select it directly.

The same comments as for clocks patch:
1. You missed to explain the most important change - removed enforcing
of built-in.
2. You ignored Geert's comments and broke distros configs for Exynos
platforms.



Best regards,
Krzysztof

[PATCH v2 11/12] soc: samsung: pm_domains: modularize EXYNOS_PM_DOMAINS

[Will McVicker]

Convert the Exynos PM Domains driver into a module. This includes
setting EXYNOS_PM_DOMAINS as tristate and removing it from being
auto-selected by ARCH_EXYNOS. Instead, the config will use
"default y if ARCH_EXYNOS" which allows us to set it to a module via the
defconfig now.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm/mach-exynos/Kconfig     |  1 -
 arch/arm64/Kconfig.platforms     |  1 -
 drivers/soc/samsung/Kconfig      |  3 ++-
 drivers/soc/samsung/pm_domains.c | 12 +++++++-----
 4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index e97e1d8f7b00..2ad19a08bf06 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -15,7 +15,6 @@ menuconfig ARCH_EXYNOS
 	select EXYNOS_THERMAL
 	select EXYNOS_PMU_ARM
 	select EXYNOS_SROM
-	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 	select GPIOLIB
 	select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5
 	select HAVE_ARM_SCU if SMP
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index e5e4b9b2fb97..e44d5e9f5058 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -91,7 +91,6 @@ config ARCH_BRCMSTB
 
 config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
-	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
 	select PM_GENERIC_DOMAINS if PM
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index fdf1162ec98b..e4743c29f73c 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -37,8 +37,9 @@ config EXYNOS_PMU_ARM
 	depends on ARCH_EXYNOS || (ARM && COMPILE_TEST)
 
 config EXYNOS_PM_DOMAINS
-	bool "Exynos PM domains" if COMPILE_TEST
+	tristate "Exynos PM domains"
 	depends on (ARCH_EXYNOS && PM_GENERIC_DOMAINS) || COMPILE_TEST
+	default y if ARCH_EXYNOS
 
 config SAMSUNG_PM_DEBUG
 	bool "Samsung PM Suspend debug"
diff --git a/drivers/soc/samsung/pm_domains.c b/drivers/soc/samsung/pm_domains.c
index 5ec0c13f0aaf..6144733fa3c2 100644
--- a/drivers/soc/samsung/pm_domains.c
+++ b/drivers/soc/samsung/pm_domains.c
@@ -14,6 +14,7 @@
 #include <linux/slab.h>
 #include <linux/pm_domain.h>
 #include <linux/delay.h>
+#include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
 #include <linux/pm_runtime.h>
@@ -160,8 +161,9 @@ static struct platform_driver exynos_pd_driver = {
 	}
 };
 
-static __init int exynos4_pm_init_power_domain(void)
-{
-	return platform_driver_register(&exynos_pd_driver);
-}
-core_initcall(exynos4_pm_init_power_domain);
+module_platform_driver(exynos_pd_driver);
+
+MODULE_DESCRIPTION("Exynos PM domains driver");
+MODULE_AUTHOR("Marek Szyprowski <m.szyprowski@samsung.com>");
+MODULE_AUTHOR("Krzysztof Kozlowski <krzk@kernel.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.33.0.685.g46640cef36-goog

Re: [PATCH v2 11/12] soc: samsung: pm_domains: modularize EXYNOS_PM_DOMAINS

[Krzysztof Kozlowski]

On 29/09/2021 01:56, Will McVicker wrote:
> Convert the Exynos PM Domains driver into a module. This includes
> setting EXYNOS_PM_DOMAINS as tristate and removing it from being
> auto-selected by ARCH_EXYNOS. Instead, the config will use
> "default y if ARCH_EXYNOS" which allows us to set it to a module via the
> defconfig now.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm/mach-exynos/Kconfig     |  1 -
>  arch/arm64/Kconfig.platforms     |  1 -
>  drivers/soc/samsung/Kconfig      |  3 ++-
>  drivers/soc/samsung/pm_domains.c | 12 +++++++-----
>  4 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index e97e1d8f7b00..2ad19a08bf06 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -15,7 +15,6 @@ menuconfig ARCH_EXYNOS
>  	select EXYNOS_THERMAL
>  	select EXYNOS_PMU_ARM
>  	select EXYNOS_SROM
> -	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
>  	select GPIOLIB
>  	select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5
>  	select HAVE_ARM_SCU if SMP
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index e5e4b9b2fb97..e44d5e9f5058 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -91,7 +91,6 @@ config ARCH_BRCMSTB
>  
>  config ARCH_EXYNOS
>  	bool "ARMv8 based Samsung Exynos SoC family"
> -	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
>  	select HAVE_S3C_RTC if RTC_CLASS
>  	select PINCTRL
>  	select PM_GENERIC_DOMAINS if PM
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index fdf1162ec98b..e4743c29f73c 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -37,8 +37,9 @@ config EXYNOS_PMU_ARM
>  	depends on ARCH_EXYNOS || (ARM && COMPILE_TEST)
>  
>  config EXYNOS_PM_DOMAINS
> -	bool "Exynos PM domains" if COMPILE_TEST
> +	tristate "Exynos PM domains"

+Cc Arnd and Olof,

Unlike in clocks and soc drivers changes, you mentioned the removal of
"if", however it is not explained why you do it.

Why is the most important part of commit message, not "what". Because
"What" we can easily see. But "why" is sometimes trickier.

Please also explain why Exynos is so special that we deviate from the
policy for all SoC that critical SoC-related drivers have to be enabled
(built-in or as module).
https://lore.kernel.org/lkml/CAK8P3a1TY+XT1vF=wAh0XA5BXU5Z6Ab1d4DekXbVsN9aj3aL5w@mail.gmail.com/

We follow specific convention or policy and changing it requires some
discussion, not silently under the "modularize" hood. It really looks
like you want to sneak it in.

P.S. I recommend also to Cc Soc maintainers, because their point of view
here is crucial.

>  	depends on (ARCH_EXYNOS && PM_GENERIC_DOMAINS) || COMPILE_TEST
> +	default y if ARCH_EXYNOS


Best regards,
Krzysztof

[PATCH v2 12/12] ARM: rtc: remove HAVE_S3C_RTC in favor of direct dependencies

[Will McVicker]

The config HAVE_S3C_RTC is not really needed since we can simply just
add the dependencies directly to RTC_DRV_S3C. Also, one less config to
keep track of!

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm/Kconfig              |  1 -
 arch/arm/mach-exynos/Kconfig  |  1 -
 arch/arm/mach-s5pv210/Kconfig |  1 -
 arch/arm64/Kconfig.platforms  |  1 -
 drivers/rtc/Kconfig           | 10 ++--------
 5 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fc196421b2ce..5ed6b5de981e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -475,7 +475,6 @@ config ARCH_S3C24XX
 	select GPIOLIB
 	select GENERIC_IRQ_MULTI_HANDLER
 	select HAVE_S3C2410_I2C if I2C
-	select HAVE_S3C_RTC if RTC_CLASS
 	select NEED_MACH_IO_H
 	select S3C2410_WATCHDOG
 	select SAMSUNG_ATAGS
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 2ad19a08bf06..8b72a70b6c43 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -19,7 +19,6 @@ menuconfig ARCH_EXYNOS
 	select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5
 	select HAVE_ARM_SCU if SMP
 	select HAVE_S3C2410_I2C if I2C
-	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
 	select PM_GENERIC_DOMAINS if PM
 	select S5P_DEV_MFC
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 62b90dda571f..681823687018 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -12,7 +12,6 @@ config ARCH_S5PV210
 	select CLKSRC_SAMSUNG_PWM
 	select GPIOLIB
 	select HAVE_S3C2410_I2C if I2C
-	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
 	select SOC_SAMSUNG
 	help
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index e44d5e9f5058..02c8637d3f09 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -91,7 +91,6 @@ config ARCH_BRCMSTB
 
 config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
-	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
 	select PM_GENERIC_DOMAINS if PM
 	select SOC_SAMSUNG
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e1bc5214494e..7208eeb8459a 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1404,16 +1404,10 @@ config RTC_DRV_OMAP
 	  This driver can also be built as a module, if so, module
 	  will be called rtc-omap.
 
-config HAVE_S3C_RTC
-	bool
-	help
-	  This will include RTC support for Samsung SoCs. If
-	  you want to include RTC support for any machine, kindly
-	  select this in the respective mach-XXXX/Kconfig file.
-
 config RTC_DRV_S3C
 	tristate "Samsung S3C series SoC RTC"
-	depends on ARCH_S3C64XX || HAVE_S3C_RTC || COMPILE_TEST
+	depends on ARCH_EXYNOS || ARCH_S3C64XX || ARCH_S3C24XX || ARCH_S5PV210 || \
+		   COMPILE_TEST
 	help
 	  RTC (Realtime Clock) driver for the clock inbuilt into the
 	  Samsung S3C24XX series of SoCs. This can provide periodic
-- 
2.33.0.685.g46640cef36-goog

Re: [PATCH v2 12/12] ARM: rtc: remove HAVE_S3C_RTC in favor of direct dependencies

[Alexandre Belloni]

Hi,

I'd argue that the subject should be rtc: s3c: ...

On 28/09/2021 23:56:29+0000, Will McVicker wrote:
> The config HAVE_S3C_RTC is not really needed since we can simply just
> add the dependencies directly to RTC_DRV_S3C. Also, one less config to
> keep track of!
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

> ---
>  arch/arm/Kconfig              |  1 -
>  arch/arm/mach-exynos/Kconfig  |  1 -
>  arch/arm/mach-s5pv210/Kconfig |  1 -
>  arch/arm64/Kconfig.platforms  |  1 -
>  drivers/rtc/Kconfig           | 10 ++--------
>  5 files changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index fc196421b2ce..5ed6b5de981e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -475,7 +475,6 @@ config ARCH_S3C24XX
>  	select GPIOLIB
>  	select GENERIC_IRQ_MULTI_HANDLER
>  	select HAVE_S3C2410_I2C if I2C
> -	select HAVE_S3C_RTC if RTC_CLASS
>  	select NEED_MACH_IO_H
>  	select S3C2410_WATCHDOG
>  	select SAMSUNG_ATAGS
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 2ad19a08bf06..8b72a70b6c43 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -19,7 +19,6 @@ menuconfig ARCH_EXYNOS
>  	select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5
>  	select HAVE_ARM_SCU if SMP
>  	select HAVE_S3C2410_I2C if I2C
> -	select HAVE_S3C_RTC if RTC_CLASS
>  	select PINCTRL
>  	select PM_GENERIC_DOMAINS if PM
>  	select S5P_DEV_MFC
> diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
> index 62b90dda571f..681823687018 100644
> --- a/arch/arm/mach-s5pv210/Kconfig
> +++ b/arch/arm/mach-s5pv210/Kconfig
> @@ -12,7 +12,6 @@ config ARCH_S5PV210
>  	select CLKSRC_SAMSUNG_PWM
>  	select GPIOLIB
>  	select HAVE_S3C2410_I2C if I2C
> -	select HAVE_S3C_RTC if RTC_CLASS
>  	select PINCTRL
>  	select SOC_SAMSUNG
>  	help
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index e44d5e9f5058..02c8637d3f09 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -91,7 +91,6 @@ config ARCH_BRCMSTB
>  
>  config ARCH_EXYNOS
>  	bool "ARMv8 based Samsung Exynos SoC family"
> -	select HAVE_S3C_RTC if RTC_CLASS
>  	select PINCTRL
>  	select PM_GENERIC_DOMAINS if PM
>  	select SOC_SAMSUNG
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index e1bc5214494e..7208eeb8459a 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1404,16 +1404,10 @@ config RTC_DRV_OMAP
>  	  This driver can also be built as a module, if so, module
>  	  will be called rtc-omap.
>  
> -config HAVE_S3C_RTC
> -	bool
> -	help
> -	  This will include RTC support for Samsung SoCs. If
> -	  you want to include RTC support for any machine, kindly
> -	  select this in the respective mach-XXXX/Kconfig file.
> -
>  config RTC_DRV_S3C
>  	tristate "Samsung S3C series SoC RTC"
> -	depends on ARCH_S3C64XX || HAVE_S3C_RTC || COMPILE_TEST
> +	depends on ARCH_EXYNOS || ARCH_S3C64XX || ARCH_S3C24XX || ARCH_S5PV210 || \
> +		   COMPILE_TEST
>  	help
>  	  RTC (Realtime Clock) driver for the clock inbuilt into the
>  	  Samsung S3C24XX series of SoCs. This can provide periodic
> -- 
> 2.33.0.685.g46640cef36-goog
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 29/09/2021 01:56, Will McVicker wrote:
> This is v2 of the series of patches that modularizes a number of core
> ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> modularized all of the drivers that are removed from the ARCH_EXYNOS
> series of "select XXX". This includes setting the following configs as
> tristate:
> 
>  * COMMON_CLK_SAMSUNG
>  * EXYNOS_ARM64_COMMON_CLK
>  * PINCTRL_SAMSUNG
>  * PINCTRL_EXYNOS
>  * EXYNOS_PMU_ARM64
>  * EXYNOS_PM_DOMAINS
> 
> Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> The reason for these new configs is because we are not able to easily
> modularize the ARMv7 PMU driver due to built-in arch dependencies on
> pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> the ARM and ARM64 portions into two separate configs.
> 
> Overall, these drivers didn't require much refactoring and converted to
> modules relatively easily. However, due to my lack of exynos hardware, I
> was not able to boot test these changes. I'm mostly concerned about the
> CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> requesting help for testing these changes on the respective hardware.
> 

These are all not tested at all? In such case, since these are not
trivial changes, please mark the series as RFT.

I will not be able to test these for some days, so it must wait.


Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Will McVicker]

On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
>
> On 29/09/2021 01:56, Will McVicker wrote:
> > This is v2 of the series of patches that modularizes a number of core
> > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> > modularized all of the drivers that are removed from the ARCH_EXYNOS
> > series of "select XXX". This includes setting the following configs as
> > tristate:
> >
> >  * COMMON_CLK_SAMSUNG
> >  * EXYNOS_ARM64_COMMON_CLK
> >  * PINCTRL_SAMSUNG
> >  * PINCTRL_EXYNOS
> >  * EXYNOS_PMU_ARM64
> >  * EXYNOS_PM_DOMAINS
> >
> > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> > The reason for these new configs is because we are not able to easily
> > modularize the ARMv7 PMU driver due to built-in arch dependencies on
> > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> > the ARM and ARM64 portions into two separate configs.
> >
> > Overall, these drivers didn't require much refactoring and converted to
> > modules relatively easily. However, due to my lack of exynos hardware, I
> > was not able to boot test these changes. I'm mostly concerned about the
> > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> > requesting help for testing these changes on the respective hardware.
> >
>
> These are all not tested at all? In such case, since these are not
> trivial changes, please mark the series as RFT.
>
> I will not be able to test these for some days, so it must wait.
>
>
> Best regards,
> Krzysztof

+Cc Arnd and Olof,

Hi Krzysztof,

To avoid the scrambled conversation from the first patchset, I'm going
to address all your general questions here in the cover letter thread
so that it's easier for everyone to follow and reference in the
future.

>What is more, it seems you entirely ignored Geert's comments. I pointed
>attention to it last time and you just said you will send v2 instead of
>joining discussion.
>
>It's a NAK for this reason - ignoring what Geert brought: you just broke
>distro configs for Exynos.

First off I did want to chime into the discussion from the previous
patchset, but I felt that Lee and Saravana addressed all your concerns
regarding the intent and feasibility. You also made it clear what the
next steps were that I needed to take.

>Please also explain why Exynos is so special that we deviate from the
>policy for all SoC that critical SoC-related drivers have to be enabled
>(built-in or as module).

I am not actually changing ANY default build configurations here and
I'm not removing any existing configuration. I tried to make it pretty
clear in my original patch series commit messages that none of my
changes modify the default behavior. The .config is the same with and
without my patches. All of these drivers remain enabled as built-in.
So if there is a distro that requires all of these drivers to be
built-in, then they can continue as is without noticing any
difference. IOW, all of these changes are/should be backwards
compatible.

I really appreciate yours and John Stultz's comments regarding
including the "why" in my commit message wording. I will spend more
time on the next series on trying to write a more meaningful commit
message, but before that we can surely discuss the "why" here.

As mentioned by Lee and Saravana, our common goal is to make it easier
for everyone to contribute upstream. In particular, this series of
patches is laying the ground work for distros to have more flexibility
in supporting a wider range of platforms without forcing everyone to
include unnecessary drivers. You said that upstream supports a generic
kernel, but I argue that the upstream "generic" arm64 kernel can't be
considered generic if it builds in SoC specific drivers that can be
modules. This patch series is addressing exactly that -- allow distros
to move SoC specific drivers out of the core kernel and into modules.
Ultimately, our goal is to be able to directly develop with the
upstream kernel on new and old SoCs by not including SoC specific
drivers in our generic kernel distro. This helps the upstream
community in a number of ways:

(1) It makes the ARM64 generic kernel smaller by converting more
drivers into modules
(2) It makes it a lot easier for everyone to develop upstream if they
can directly use the upstream kernel without carrying downstream
changes.

>Even if there was, I think it is good to have dependencies like
>ARCH_EXYNOS, as they let us partition the (19000, as Arnd said recently)
>Kconfig symbols into better manageable groups.  Without these, we cannot
>do better than "depends on ARM || ARM64 || COMPILE_TEST".

My patch series still keeps the dependencies on ARCH_EXYNOS. I am
totally fine with "depends on ARCH_EXYNOS" and totally fine with
"default ARCH_EXYNOS". The problem we have is that ARCH_EXYNOS
forcefully selects SoC specific drivers to be built-in because it just
adds more and more SoC-specific drivers to a generic kernel.

I know you are asking for me to only push changes that have proven to
work. The theory behind these changes has been proven downstream on
other devices and I'm more than willing to help debug any issues that
arise out of this patch series, but since I don't have the hardware
myself I do need help with device testing these changes. We are not
trying to trick upstream in anyway to accept something that is not
functional or going to hurt the upstream community. I am more than
willing to help upstream and am totally willing to work with upstream
to verify all of these changes before they are accepted (feel free to
send me any dusty, unused hardware lying around if you want the extra
help with device testing).

I hope that helps clarifies things! I will address other patch
specific comments in those threads as well.

Thanks,
Will

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 29/09/2021 21:48, Will McVicker wrote:
> On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
>>
>> On 29/09/2021 01:56, Will McVicker wrote:
>>> This is v2 of the series of patches that modularizes a number of core
>>> ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
>>> modularized all of the drivers that are removed from the ARCH_EXYNOS
>>> series of "select XXX". This includes setting the following configs as
>>> tristate:
>>>
>>>  * COMMON_CLK_SAMSUNG
>>>  * EXYNOS_ARM64_COMMON_CLK
>>>  * PINCTRL_SAMSUNG
>>>  * PINCTRL_EXYNOS
>>>  * EXYNOS_PMU_ARM64
>>>  * EXYNOS_PM_DOMAINS
>>>
>>> Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
>>> which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
>>> The reason for these new configs is because we are not able to easily
>>> modularize the ARMv7 PMU driver due to built-in arch dependencies on
>>> pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
>>> the ARM and ARM64 portions into two separate configs.
>>>
>>> Overall, these drivers didn't require much refactoring and converted to
>>> modules relatively easily. However, due to my lack of exynos hardware, I
>>> was not able to boot test these changes. I'm mostly concerned about the
>>> CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
>>> requesting help for testing these changes on the respective hardware.
>>>
>>
>> These are all not tested at all? In such case, since these are not
>> trivial changes, please mark the series as RFT.
>>
>> I will not be able to test these for some days, so it must wait.
>>
>>
>> Best regards,
>> Krzysztof
> 
> +Cc Arnd and Olof,
> 
> Hi Krzysztof,
> 
> To avoid the scrambled conversation from the first patchset, I'm going
> to address all your general questions here in the cover letter thread
> so that it's easier for everyone to follow and reference in the
> future.
> 
>> What is more, it seems you entirely ignored Geert's comments. I pointed
>> attention to it last time and you just said you will send v2 instead of
>> joining discussion.
>>
>> It's a NAK for this reason - ignoring what Geert brought: you just broke
>> distro configs for Exynos.
> 
> First off I did want to chime into the discussion from the previous
> patchset, but I felt that Lee and Saravana addressed all your concerns
> regarding the intent and feasibility. You also made it clear what the
> next steps were that I needed to take.

One of the steps was problem with distros using everything as modules.
They should not receive these drivers as modules.
Reminder: these are essential drivers and all Exynos platforms must have
them as built-in (at least till someone really tests this on multiple
setups).

> 
>> Please also explain why Exynos is so special that we deviate from the
>> policy for all SoC that critical SoC-related drivers have to be enabled
>> (built-in or as module).
> 
> I am not actually changing ANY default build configurations here and
> I'm not removing any existing configuration.

You are changing not default, but selectability which is part of the
enforced configuration to make platforms working. The distros do not
always choose defaults but rather all as modules. Kernel configuration
is huge and complex, so by mistake they could now even disable
potentially essential driver. There is no need to disable for example
essential clock driver on a supported Exynos platform.

> I tried to make it pretty
> clear in my original patch series commit messages that none of my
> changes modify the default behavior. The .config is the same with and
> without my patches. All of these drivers remain enabled as built-in.
> So if there is a distro that requires all of these drivers to be
> built-in, then they can continue as is without noticing any
> difference. IOW, all of these changes are/should be backwards
> compatible.

I was not referring to default neither to backwards compatibility.
Please explain why Exynos is special that it does not require essential
drivers to be selected as built-in. For example why aren't same changes
done for Renesas?

Is that now a new global approach that all SoC drivers should be allowed
to be disabled for ARCH_XXX?

> 
> I really appreciate yours and John Stultz's comments regarding
> including the "why" in my commit message wording. I will spend more
> time on the next series on trying to write a more meaningful commit
> message, but before that we can surely discuss the "why" here.
> 
> As mentioned by Lee and Saravana, our common goal is to make it easier
> for everyone to contribute upstream. In particular, this series of
> patches is laying the ground work for distros to have more flexibility
> in supporting a wider range of platforms without forcing everyone to
> include unnecessary drivers. 

The drivers are usually necessary. Actually, you admitted you didn't
test patchset, so how do you even know that they are unnecessary? How do
 you judge?

> You said that upstream supports a generic
> kernel, but I argue that the upstream "generic" arm64 kernel can't be
> considered generic if it builds in SoC specific drivers that can be
> modules.

Good point, but since having them as modules was not tested, I consider
it as theoretical topic.

> This patch series is addressing exactly that -- allow distros
> to move SoC specific drivers out of the core kernel and into modules.
> Ultimately, our goal is to be able to directly develop with the
> upstream kernel on new and old SoCs by not including SoC specific
> drivers in our generic kernel distro. This helps the upstream
> community in a number of ways:
> 
> (1) It makes the ARM64 generic kernel smaller by converting more
> drivers into modules
> (2) It makes it a lot easier for everyone to develop upstream if they
> can directly use the upstream kernel without carrying downstream
> changes.

I don't understand the point (2) here. Anyone can use upstream kernel
for supported and unsupported platforms. How upstream benefits from a
change affecting supported platforms made for unsupported, downstream
platforms.

> 
>> Even if there was, I think it is good to have dependencies like
>> ARCH_EXYNOS, as they let us partition the (19000, as Arnd said recently)
>> Kconfig symbols into better manageable groups.  Without these, we cannot
>> do better than "depends on ARM || ARM64 || COMPILE_TEST".
> 
> My patch series still keeps the dependencies on ARCH_EXYNOS. I am
> totally fine with "depends on ARCH_EXYNOS" and totally fine with
> "default ARCH_EXYNOS". The problem we have is that ARCH_EXYNOS
> forcefully selects SoC specific drivers to be built-in because it just
> adds more and more SoC-specific drivers to a generic kernel.

The selected drivers are essential for supported platforms. We don't
even know what are these unsupported, downstream platforms you want
customize kernel for. They cannot be audited, cannot be compared.

Therefore I don't agree with calling it a "problem" that we select
*necessary* drivers for supported platforms. It's by design - supported
platforms should receive them without ability to remove.

If you want to change it, let me paste from previous discussion:

Affecting upstream platforms just because vendor/downstream does not
want to mainline some code is unacceptable. Please upstream your drivers
and DTS.

Everyone else are working like this. NXP, Renesas, Xilinx, TI, Rockchip,
AllWinner. Samsung or Google is not special to receive an exception for
this.


> 
> I know you are asking for me to only push changes that have proven to
> work. 

Yep, tested.

> The theory behind these changes has been proven downstream on
> other devices and I'm more than willing to help debug any issues that
> arise out of this patch series, but since I don't have the hardware
> myself I do need help with device testing these changes.

Downstream uses very specific Linux "distro" or fork - Android - with
changes not present in others. Although tests on other
(unsupported/unupstreamed) devices is good, but it's not sufficient. For
example I guess that half or most of Odroid devices are running standard
Linux distro (Arch, Ubuntu).

You also mentioned downstream devices but without actually ever defining
them. Please be more specific. What SoC, what hardware?

Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Arnd Bergmann]

On Thu, Sep 30, 2021 at 8:15 AM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
> On 29/09/2021 21:48, Will McVicker wrote:
> > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
> >> What is more, it seems you entirely ignored Geert's comments. I pointed
> >> attention to it last time and you just said you will send v2 instead of
> >> joining discussion.
> >>
> >> It's a NAK for this reason - ignoring what Geert brought: you just broke
> >> distro configs for Exynos.
> >
> > First off I did want to chime into the discussion from the previous
> > patchset, but I felt that Lee and Saravana addressed all your concerns
> > regarding the intent and feasibility. You also made it clear what the
> > next steps were that I needed to take.
>
> One of the steps was problem with distros using everything as modules.
> They should not receive these drivers as modules.
> Reminder: these are essential drivers and all Exynos platforms must have
> them as built-in (at least till someone really tests this on multiple
> setups).

Agreed. I absolutely love the work of the GKI developers to turn more
drivers into loadable modules, but the "correctness-first" principle is
not up for negotiation. If you are uncomfortable with the code or the
amount of testing because you think it breaks something, you should
reject the patches. Moving core platform functionality is fundamentally
hard and it can go wrong in all possible ways where it used to work
by accident because the init order was fixed.

> >> Please also explain why Exynos is so special that we deviate from the
> >> policy for all SoC that critical SoC-related drivers have to be enabled
> >> (built-in or as module).
> >
> > I am not actually changing ANY default build configurations here and
> > I'm not removing any existing configuration.
>
> You are changing not default, but selectability which is part of the
> enforced configuration to make platforms working. The distros do not
> always choose defaults but rather all as modules. Kernel configuration
> is huge and complex, so by mistake they could now even disable
> potentially essential driver. There is no need to disable for example
> essential clock driver on a supported Exynos platform.

I'm not overly worried about the defaults. If the drivers work as loadable
modules, I'm happy with them being loadable modules in distros.
If they don't work this way, then the patches are broken and should
not get merged.

I don't even mind having essential drivers that can be turned off,
since we already have a ton of those (e.g. serial ports on most platforms).
It's up to distros to know which drivers to enable, though having
either reasonable defaults or fail-safe Kconfig dependencies (e.g.
making it impossible to turn off but allowing modules) is clearly
best.

> > I tried to make it pretty
> > clear in my original patch series commit messages that none of my
> > changes modify the default behavior. The .config is the same with and
> > without my patches. All of these drivers remain enabled as built-in.
> > So if there is a distro that requires all of these drivers to be
> > built-in, then they can continue as is without noticing any
> > difference. IOW, all of these changes are/should be backwards
> > compatible.
>
> I was not referring to default neither to backwards compatibility.
> Please explain why Exynos is special that it does not require essential
> drivers to be selected as built-in. For example why aren't same changes
> done for Renesas?
>
> Is that now a new global approach that all SoC drivers should be allowed
> to be disabled for ARCH_XXX?

I wouldn't enforce it either way across platforms. I would prefer drivers
to be loadable modules where possible (and tested), rather than
selected by the platform Kconfig. If you want to ensure the exynos
drivers are impossible to turn into a nonworking state, that's up to you.

> > You said that upstream supports a generic
> > kernel, but I argue that the upstream "generic" arm64 kernel can't be
> > considered generic if it builds in SoC specific drivers that can be
> > modules.
>
> Good point, but since having them as modules was not tested, I consider
> it as theoretical topic.

I actually disagree strongly with labelling the kernel as "non-generic"
just because it requires platform specific support to be built-in rather than
a loadable module. This has never been possible on any platform
I'm aware of, and likely never will, except for minor variations of
an existing platform.

Look at x86 as an example: there are less than a dozen SoC platforms
supported and they are incredibly similar hardware-wise, but the kernel
is anything but "generic" in the sense that was mentioned above.
Most of the platform specific drivers in arch/x86/platform and the
corresponding bits in drivers/{irqchip,clocksource,iommu} are always
built-in, and a lot more is hardwired in architecture code as PCI
quirks or conditional on cpuid or dmi firmware checks.

> >> Even if there was, I think it is good to have dependencies like
> >> ARCH_EXYNOS, as they let us partition the (19000, as Arnd said recently)
> >> Kconfig symbols into better manageable groups.  Without these, we cannot
> >> do better than "depends on ARM || ARM64 || COMPILE_TEST".
> >
> > My patch series still keeps the dependencies on ARCH_EXYNOS. I am
> > totally fine with "depends on ARCH_EXYNOS" and totally fine with
> > "default ARCH_EXYNOS". The problem we have is that ARCH_EXYNOS
> > forcefully selects SoC specific drivers to be built-in because it just
> > adds more and more SoC-specific drivers to a generic kernel.
>
> The selected drivers are essential for supported platforms. We don't
> even know what are these unsupported, downstream platforms you want
> customize kernel for. They cannot be audited, cannot be compared.
>
> Therefore I don't agree with calling it a "problem" that we select
> *necessary* drivers for supported platforms. It's by design - supported
> platforms should receive them without ability to remove.
>
> If you want to change it, let me paste from previous discussion:
>
> Affecting upstream platforms just because vendor/downstream does not
> want to mainline some code is unacceptable. Please upstream your drivers
> and DTS.

Agreed. I understand that it would be convenient for SoC vendors to
never have to upstream their platform code again, and that Android
would benefit from this in the short run.

From my upstream perspective, this is absolutely a non-goal. If it becomes
easier as a side-effect of making the kernel more modular, that's fine.
The actual goal should be to get more people to contribute upstream so
devices run code that has been reviewed and integrated into new kernels.

> > I know you are asking for me to only push changes that have proven to
> > work.
>
> Yep, tested.

I'm generally fine with "obviously correct" ones as well, but it's up to
you to categorize them ;-)

         Arnd

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Arnd Bergmann wrote:

> On Thu, Sep 30, 2021 at 8:15 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
> > On 29/09/2021 21:48, Will McVicker wrote:
> > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
> > >> What is more, it seems you entirely ignored Geert's comments. I pointed
> > >> attention to it last time and you just said you will send v2 instead of
> > >> joining discussion.
> > >>
> > >> It's a NAK for this reason - ignoring what Geert brought: you just broke
> > >> distro configs for Exynos.
> > >
> > > First off I did want to chime into the discussion from the previous
> > > patchset, but I felt that Lee and Saravana addressed all your concerns
> > > regarding the intent and feasibility. You also made it clear what the
> > > next steps were that I needed to take.
> >
> > One of the steps was problem with distros using everything as modules.
> > They should not receive these drivers as modules.
> > Reminder: these are essential drivers and all Exynos platforms must have
> > them as built-in (at least till someone really tests this on multiple
> > setups).
> 
> Agreed. I absolutely love the work of the GKI developers to turn more
> drivers into loadable modules, but the "correctness-first" principle is
> not up for negotiation. If you are uncomfortable with the code or the
> amount of testing because you think it breaks something, you should
> reject the patches. Moving core platform functionality is fundamentally
> hard and it can go wrong in all possible ways where it used to work
> by accident because the init order was fixed.
> 
> > >> Please also explain why Exynos is so special that we deviate from the
> > >> policy for all SoC that critical SoC-related drivers have to be enabled
> > >> (built-in or as module).
> > >
> > > I am not actually changing ANY default build configurations here and
> > > I'm not removing any existing configuration.
> >
> > You are changing not default, but selectability which is part of the
> > enforced configuration to make platforms working. The distros do not
> > always choose defaults but rather all as modules. Kernel configuration
> > is huge and complex, so by mistake they could now even disable
> > potentially essential driver. There is no need to disable for example
> > essential clock driver on a supported Exynos platform.
> 
> I'm not overly worried about the defaults. If the drivers work as loadable
> modules, I'm happy with them being loadable modules in distros.
> If they don't work this way, then the patches are broken and should
> not get merged.
> 
> I don't even mind having essential drivers that can be turned off,
> since we already have a ton of those (e.g. serial ports on most platforms).
> It's up to distros to know which drivers to enable, though having
> either reasonable defaults or fail-safe Kconfig dependencies (e.g.
> making it impossible to turn off but allowing modules) is clearly
> best.
> 
> > > I tried to make it pretty
> > > clear in my original patch series commit messages that none of my
> > > changes modify the default behavior. The .config is the same with and
> > > without my patches. All of these drivers remain enabled as built-in.
> > > So if there is a distro that requires all of these drivers to be
> > > built-in, then they can continue as is without noticing any
> > > difference. IOW, all of these changes are/should be backwards
> > > compatible.
> >
> > I was not referring to default neither to backwards compatibility.
> > Please explain why Exynos is special that it does not require essential
> > drivers to be selected as built-in. For example why aren't same changes
> > done for Renesas?
> >
> > Is that now a new global approach that all SoC drivers should be allowed
> > to be disabled for ARCH_XXX?
> 
> I wouldn't enforce it either way across platforms. I would prefer drivers
> to be loadable modules where possible (and tested), rather than
> selected by the platform Kconfig. If you want to ensure the exynos
> drivers are impossible to turn into a nonworking state, that's up to you.
> 
> > > You said that upstream supports a generic
> > > kernel, but I argue that the upstream "generic" arm64 kernel can't be
> > > considered generic if it builds in SoC specific drivers that can be
> > > modules.
> >
> > Good point, but since having them as modules was not tested, I consider
> > it as theoretical topic.
> 
> I actually disagree strongly with labelling the kernel as "non-generic"
> just because it requires platform specific support to be built-in rather than
> a loadable module. This has never been possible on any platform
> I'm aware of, and likely never will, except for minor variations of
> an existing platform.
> 
> Look at x86 as an example: there are less than a dozen SoC platforms
> supported and they are incredibly similar hardware-wise, but the kernel
> is anything but "generic" in the sense that was mentioned above.
> Most of the platform specific drivers in arch/x86/platform and the
> corresponding bits in drivers/{irqchip,clocksource,iommu} are always
> built-in, and a lot more is hardwired in architecture code as PCI
> quirks or conditional on cpuid or dmi firmware checks.
> 
> > >> Even if there was, I think it is good to have dependencies like
> > >> ARCH_EXYNOS, as they let us partition the (19000, as Arnd said recently)
> > >> Kconfig symbols into better manageable groups.  Without these, we cannot
> > >> do better than "depends on ARM || ARM64 || COMPILE_TEST".
> > >
> > > My patch series still keeps the dependencies on ARCH_EXYNOS. I am
> > > totally fine with "depends on ARCH_EXYNOS" and totally fine with
> > > "default ARCH_EXYNOS". The problem we have is that ARCH_EXYNOS
> > > forcefully selects SoC specific drivers to be built-in because it just
> > > adds more and more SoC-specific drivers to a generic kernel.
> >
> > The selected drivers are essential for supported platforms. We don't
> > even know what are these unsupported, downstream platforms you want
> > customize kernel for. They cannot be audited, cannot be compared.
> >
> > Therefore I don't agree with calling it a "problem" that we select
> > *necessary* drivers for supported platforms. It's by design - supported
> > platforms should receive them without ability to remove.
> >
> > If you want to change it, let me paste from previous discussion:
> >
> > Affecting upstream platforms just because vendor/downstream does not
> > want to mainline some code is unacceptable. Please upstream your drivers
> > and DTS.
> 
> Agreed. I understand that it would be convenient for SoC vendors to
> never have to upstream their platform code again, and that Android
> would benefit from this in the short run.
> 
> From my upstream perspective, this is absolutely a non-goal. If it becomes
> easier as a side-effect of making the kernel more modular, that's fine.
> The actual goal should be to get more people to contribute upstream so
> devices run code that has been reviewed and integrated into new kernels.
> 
> > > I know you are asking for me to only push changes that have proven to
> > > work.
> >
> > Yep, tested.
> 
> I'm generally fine with "obviously correct" ones as well, but it's up to
> you to categorize them ;-)

Arnd,

  FWIW, I agree with all of your points.

Krzysztof,

  It sounds like a lack of testing is your main concern.

  How can I help here?  What H/W do I need to be able to fully test this?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 30/09/2021 11:30, Lee Jones wrote:
> On Thu, 30 Sep 2021, Arnd Bergmann wrote:
> 
>> On Thu, Sep 30, 2021 at 8:15 AM Krzysztof Kozlowski
>> <krzysztof.kozlowski@canonical.com> wrote:
>>> On 29/09/2021 21:48, Will McVicker wrote:
>>>> On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
>>>>> What is more, it seems you entirely ignored Geert's comments. I pointed
>>>>> attention to it last time and you just said you will send v2 instead of
>>>>> joining discussion.
>>>>>
>>>>> It's a NAK for this reason - ignoring what Geert brought: you just broke
>>>>> distro configs for Exynos.
>>>>
>>>> First off I did want to chime into the discussion from the previous
>>>> patchset, but I felt that Lee and Saravana addressed all your concerns
>>>> regarding the intent and feasibility. You also made it clear what the
>>>> next steps were that I needed to take.
>>>
>>> One of the steps was problem with distros using everything as modules.
>>> They should not receive these drivers as modules.
>>> Reminder: these are essential drivers and all Exynos platforms must have
>>> them as built-in (at least till someone really tests this on multiple
>>> setups).
>>
>> Agreed. I absolutely love the work of the GKI developers to turn more
>> drivers into loadable modules, but the "correctness-first" principle is
>> not up for negotiation. If you are uncomfortable with the code or the
>> amount of testing because you think it breaks something, you should
>> reject the patches. Moving core platform functionality is fundamentally
>> hard and it can go wrong in all possible ways where it used to work
>> by accident because the init order was fixed.
>>
>>>>> Please also explain why Exynos is so special that we deviate from the
>>>>> policy for all SoC that critical SoC-related drivers have to be enabled
>>>>> (built-in or as module).
>>>>
>>>> I am not actually changing ANY default build configurations here and
>>>> I'm not removing any existing configuration.
>>>
>>> You are changing not default, but selectability which is part of the
>>> enforced configuration to make platforms working. The distros do not
>>> always choose defaults but rather all as modules. Kernel configuration
>>> is huge and complex, so by mistake they could now even disable
>>> potentially essential driver. There is no need to disable for example
>>> essential clock driver on a supported Exynos platform.
>>
>> I'm not overly worried about the defaults. If the drivers work as loadable
>> modules, I'm happy with them being loadable modules in distros.
>> If they don't work this way, then the patches are broken and should
>> not get merged.
>>
>> I don't even mind having essential drivers that can be turned off,
>> since we already have a ton of those (e.g. serial ports on most platforms).
>> It's up to distros to know which drivers to enable, though having
>> either reasonable defaults or fail-safe Kconfig dependencies (e.g.
>> making it impossible to turn off but allowing modules) is clearly
>> best.
>>
>>>> I tried to make it pretty
>>>> clear in my original patch series commit messages that none of my
>>>> changes modify the default behavior. The .config is the same with and
>>>> without my patches. All of these drivers remain enabled as built-in.
>>>> So if there is a distro that requires all of these drivers to be
>>>> built-in, then they can continue as is without noticing any
>>>> difference. IOW, all of these changes are/should be backwards
>>>> compatible.
>>>
>>> I was not referring to default neither to backwards compatibility.
>>> Please explain why Exynos is special that it does not require essential
>>> drivers to be selected as built-in. For example why aren't same changes
>>> done for Renesas?
>>>
>>> Is that now a new global approach that all SoC drivers should be allowed
>>> to be disabled for ARCH_XXX?
>>
>> I wouldn't enforce it either way across platforms. I would prefer drivers
>> to be loadable modules where possible (and tested), rather than
>> selected by the platform Kconfig. If you want to ensure the exynos
>> drivers are impossible to turn into a nonworking state, that's up to you.
>>
>>>> You said that upstream supports a generic
>>>> kernel, but I argue that the upstream "generic" arm64 kernel can't be
>>>> considered generic if it builds in SoC specific drivers that can be
>>>> modules.
>>>
>>> Good point, but since having them as modules was not tested, I consider
>>> it as theoretical topic.
>>
>> I actually disagree strongly with labelling the kernel as "non-generic"
>> just because it requires platform specific support to be built-in rather than
>> a loadable module. This has never been possible on any platform
>> I'm aware of, and likely never will, except for minor variations of
>> an existing platform.
>>
>> Look at x86 as an example: there are less than a dozen SoC platforms
>> supported and they are incredibly similar hardware-wise, but the kernel
>> is anything but "generic" in the sense that was mentioned above.
>> Most of the platform specific drivers in arch/x86/platform and the
>> corresponding bits in drivers/{irqchip,clocksource,iommu} are always
>> built-in, and a lot more is hardwired in architecture code as PCI
>> quirks or conditional on cpuid or dmi firmware checks.
>>
>>>>> Even if there was, I think it is good to have dependencies like
>>>>> ARCH_EXYNOS, as they let us partition the (19000, as Arnd said recently)
>>>>> Kconfig symbols into better manageable groups.  Without these, we cannot
>>>>> do better than "depends on ARM || ARM64 || COMPILE_TEST".
>>>>
>>>> My patch series still keeps the dependencies on ARCH_EXYNOS. I am
>>>> totally fine with "depends on ARCH_EXYNOS" and totally fine with
>>>> "default ARCH_EXYNOS". The problem we have is that ARCH_EXYNOS
>>>> forcefully selects SoC specific drivers to be built-in because it just
>>>> adds more and more SoC-specific drivers to a generic kernel.
>>>
>>> The selected drivers are essential for supported platforms. We don't
>>> even know what are these unsupported, downstream platforms you want
>>> customize kernel for. They cannot be audited, cannot be compared.
>>>
>>> Therefore I don't agree with calling it a "problem" that we select
>>> *necessary* drivers for supported platforms. It's by design - supported
>>> platforms should receive them without ability to remove.
>>>
>>> If you want to change it, let me paste from previous discussion:
>>>
>>> Affecting upstream platforms just because vendor/downstream does not
>>> want to mainline some code is unacceptable. Please upstream your drivers
>>> and DTS.
>>
>> Agreed. I understand that it would be convenient for SoC vendors to
>> never have to upstream their platform code again, and that Android
>> would benefit from this in the short run.
>>
>> From my upstream perspective, this is absolutely a non-goal. If it becomes
>> easier as a side-effect of making the kernel more modular, that's fine.
>> The actual goal should be to get more people to contribute upstream so
>> devices run code that has been reviewed and integrated into new kernels.
>>
>>>> I know you are asking for me to only push changes that have proven to
>>>> work.
>>>
>>> Yep, tested.
>>
>> I'm generally fine with "obviously correct" ones as well, but it's up to
>> you to categorize them ;-)

Thanks Arnd!

> 
> Arnd,
> 
>   FWIW, I agree with all of your points.>
> Krzysztof,
> 
>   It sounds like a lack of testing is your main concern.
> 
>   How can I help here?  What H/W do I need to be able to fully test this?

The changes here need to be tested on affected platforms (ARMv7 and
ARMv8), when built as a modules on some types of regular distros (e.g.
Arch, Ubuntu). From each of such boot I would be happy to see number of
new dmesg warnings/errors plus number of probe deferrals.

Since the drivers could be switched to modules (and some distros might
do it), they might be hit by surprise regressions in boot performance
due to probe deferrals. This should be also checked on these platforms.
Geert pointed out before that clocks in many cases are not optional -
driver needs them and will wait defer.

Assuming of course that boot succeeds. Minor differences in boot speed
should not be a problem, I think, because distro anyway chosen
all-module approach so it accepts the penalty.

Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> >   It sounds like a lack of testing is your main concern.
> > 
> >   How can I help here?  What H/W do I need to be able to fully test this?
> 
> The changes here need to be tested on affected platforms (ARMv7 and
> ARMv8), when built as a modules on some types of regular distros (e.g.
> Arch, Ubuntu). From each of such boot I would be happy to see number of
> new dmesg warnings/errors plus number of probe deferrals.
> 
> Since the drivers could be switched to modules (and some distros might
> do it), they might be hit by surprise regressions in boot performance
> due to probe deferrals. This should be also checked on these platforms.
> Geert pointed out before that clocks in many cases are not optional -
> driver needs them and will wait defer.
> 
> Assuming of course that boot succeeds. Minor differences in boot speed
> should not be a problem, I think, because distro anyway chosen
> all-module approach so it accepts the penalty.

Do you have any suggestions in terms of devboards?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 30/09/2021 14:34, Lee Jones wrote:
> On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
>>>   It sounds like a lack of testing is your main concern.
>>>
>>>   How can I help here?  What H/W do I need to be able to fully test this?
>>
>> The changes here need to be tested on affected platforms (ARMv7 and
>> ARMv8), when built as a modules on some types of regular distros (e.g.
>> Arch, Ubuntu). From each of such boot I would be happy to see number of
>> new dmesg warnings/errors plus number of probe deferrals.
>>
>> Since the drivers could be switched to modules (and some distros might
>> do it), they might be hit by surprise regressions in boot performance
>> due to probe deferrals. This should be also checked on these platforms.
>> Geert pointed out before that clocks in many cases are not optional -
>> driver needs them and will wait defer.
>>
>> Assuming of course that boot succeeds. Minor differences in boot speed
>> should not be a problem, I think, because distro anyway chosen
>> all-module approach so it accepts the penalty.
> 
> Do you have any suggestions in terms of devboards?

Minimal set:
1. Something with Exynos4 (e.g. Odroid U3 with Exynos4412).
2. Something with Exynos 5422/5800 (e.g. Odroid XU3/XU4/HC1/MC1 or
Chromebook Peach Pi).
3. Exynos5433 - TM2 or TM2E. Boards are not widely available, so we need
to rely on provided testing by Samsung.

What would be good is to also test Exynos3 boards, but this is also not
widely available.


Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

On Thu, Sep 30, 2021 at 11:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Sep 30, 2021 at 8:15 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
> > On 29/09/2021 21:48, Will McVicker wrote:
> > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
> > >> What is more, it seems you entirely ignored Geert's comments. I pointed
> > >> attention to it last time and you just said you will send v2 instead of
> > >> joining discussion.
> > >>
> > >> It's a NAK for this reason - ignoring what Geert brought: you just broke
> > >> distro configs for Exynos.
> > >
> > > First off I did want to chime into the discussion from the previous
> > > patchset, but I felt that Lee and Saravana addressed all your concerns
> > > regarding the intent and feasibility. You also made it clear what the
> > > next steps were that I needed to take.
> >
> > One of the steps was problem with distros using everything as modules.
> > They should not receive these drivers as modules.
> > Reminder: these are essential drivers and all Exynos platforms must have
> > them as built-in (at least till someone really tests this on multiple
> > setups).
>
> Agreed. I absolutely love the work of the GKI developers to turn more
> drivers into loadable modules, but the "correctness-first" principle is
> not up for negotiation. If you are uncomfortable with the code or the
> amount of testing because you think it breaks something, you should
> reject the patches. Moving core platform functionality is fundamentally
> hard and it can go wrong in all possible ways where it used to work
> by accident because the init order was fixed.

Exactly.
And patches to change this that haven't been tested at all should be
very clearly marked that way.

> > > You said that upstream supports a generic
> > > kernel, but I argue that the upstream "generic" arm64 kernel can't be
> > > considered generic if it builds in SoC specific drivers that can be
> > > modules.
> >
> > Good point, but since having them as modules was not tested, I consider
> > it as theoretical topic.
>
> I actually disagree strongly with labelling the kernel as "non-generic"
> just because it requires platform specific support to be built-in rather than
> a loadable module. This has never been possible on any platform
> I'm aware of, and likely never will, except for minor variations of
> an existing platform.

There seem to be two different meanings for a "generic" kernel:
  1. To me, a generic kernel is a kernel that can boot on a variety of
     hardware platforms. and will operate correctly with all expected
     functionality.  That is, it should include[1] drivers for all that
     hardware.
     Examples of this are arm/multi_v7_defconfig and arm64/defconfig.
  2. To GKI, a generic kernel is a minimal kernel that doesn't include
     any[2] hardware-specific drivers, and has loadable modules for
     all[2] hardware-specific drivers. Before loading these modules, it
     can run an application on the CPU, but it cannot do any I/O to real
     hardware.

[1] Developers usually want the drivers builtin, distros want them
     modular.
[2] On arm/arm64, this must rely on the GIC and architectured timer
    being built-in (AFAIK these cannot be modules yet), and thus
    precludes booting on Cortex A9 and older that lack GIC and/or
    architectured timer as their primary interrupt controller and timer.
    I'm wondering how this works on other architectures with
    less-standardized interrupt controllers and timers?

> Look at x86 as an example: there are less than a dozen SoC platforms
> supported and they are incredibly similar hardware-wise, but the kernel
> is anything but "generic" in the sense that was mentioned above.
> Most of the platform specific drivers in arch/x86/platform and the
> corresponding bits in drivers/{irqchip,clocksource,iommu} are always
> built-in, and a lot more is hardwired in architecture code as PCI
> quirks or conditional on cpuid or dmi firmware checks.

Indeed. X86 has less variability in the hardware than other
architectures, and has all the critical drivers built-in or in firmware.
Where there have been big differences (remember Voyager?), x86 never
had the option to have a generic (in the meaning of 1 above) kernel
(but James did try, cfr. https://lwn.net/Articles/328469/).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

I've taken the liberty of cherry-picking some of the points you have
reiteratted a few times.  Hopefully I can help to address them
adequently.

On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> Reminder: these are essential drivers and all Exynos platforms must have
> them as built-in (at least till someone really tests this on multiple
> setups).

> Therefore I don't agree with calling it a "problem" that we select
> *necessary* drivers for supported platforms. It's by design - supported
> platforms should receive them without ability to remove.

> The selected drivers are essential for supported platforms.

SoC specific drivers are only essential/necessary/required in
images designed to execute solely on a platform that requires them.
For a kernel image which is designed to be generic i.e. one that has
the ability to boot on vast array of platforms, the drivers simply
have to be *available*.

Forcing all H/W drivers that are only *potentially* utilised on *some*
platforms as core binary built-ins doesn't make any technical sense.
The two most important issues this causes are image size and a lack of
configurability/flexibility relating to real-world application i.e.
the one issue we already agreed upon; H/W or features that are too
new (pre-release).

Bloating a generic kernel with potentially hundreds of unnecessary
drivers that will never be executed in the vast majority of instances
doesn't achieve anything.  If we have a kernel image that has the
ability to boot on 10's of architectures which have 10's of platforms
each, that's a whole host of unused/wasted executable space.

In order for vendors to work more closely with upstream, they need the
ability to over-ride a *few* drivers to supplement them with some
functionality which they believe provides them with a competitive edge
(I think you called this "value-add" before) prior to the release of a
device.  This is a requirement that cannot be worked around.

By insisting on drivers (most of which will not be executed in the
vast majority of cases) to be built-in, you are insisting on a
downstream kernel fork, which all of us would like to avoid [0].

[0] Full disclosure: part of my role at Linaro is to keep the Android
kernel running as close to Mainline as possible and encourage/push the
upstream-first mantra, hence my involvement with this and other sets.
I assure you all intentions are good and honourable.  If you haven't
already seen it, please see Todd's most recent update on the goals and
status of GKI:

  Article: https://tinyurl.com/saaen3sp
  Video:   https://youtu.be/O_lCFGinFPM

> We don't even know what are these unsupported, downstream platforms
> you want customize kernel for. They cannot be audited, cannot be
> compared.  Affecting upstream platforms just because
> vendor/downstream does not want to mainline some code is
> unacceptable. Please upstream your drivers and DTS.

> You also mentioned downstream devices but without actually ever defining
> them. Please be more specific. What SoC, what hardware?

Accepting changes based on the proviso that vendors upstream all of
their work-in-progress solutions is an unfair position.  We already
discussed why upstreaming support for bleeding edge H/W and
functionality is unrealistic in terms of competitive advantage.

Besides, we might not be talking about new silicon at all (I don't
believe anyone alluded to that).  The flexibility in configuration
simply allows for generic upstream drivers to be swapped out for ones
which may have more or slightly different functionality (that can't be
publicly shared until release).

> Please explain why Exynos is special that it does not require essential
> drivers to be selected as built-in. For example why aren't same changes
> done for Renesas?

> Everyone else are working like this. NXP, Renesas, Xilinx, TI, Rockchip,
> AllWinner. Samsung or Google is not special to receive an exception for
> this.

Exynos isn't special in this regard.  This applies to any vendor who
releases Android images and wishes to be solve all of the issues the
GKI project addresses (please read the article above for more about
this).

I truly hope this has helped to align my thoughts with yours.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Lee,

On Thu, Sep 30, 2021 at 11:23 AM Lee Jones <lee.jones@linaro.org> wrote:
> I've taken the liberty of cherry-picking some of the points you have
> reiteratted a few times.  Hopefully I can help to address them
> adequently.
>
> On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > Reminder: these are essential drivers and all Exynos platforms must have
> > them as built-in (at least till someone really tests this on multiple
> > setups).
>
> > Therefore I don't agree with calling it a "problem" that we select
> > *necessary* drivers for supported platforms. It's by design - supported
> > platforms should receive them without ability to remove.
>
> > The selected drivers are essential for supported platforms.
>
> SoC specific drivers are only essential/necessary/required in
> images designed to execute solely on a platform that requires them.

Why?

> For a kernel image which is designed to be generic i.e. one that has
> the ability to boot on vast array of platforms, the drivers simply
> have to be *available*.

If the drivers are really essential/necessary/required, this precludes
running the generic kernel image on the platform that requires them,
making the kernel not sufficiently generic.

> Forcing all H/W drivers that are only *potentially* utilised on *some*
> platforms as core binary built-ins doesn't make any technical sense.
> The two most important issues this causes are image size and a lack of
> configurability/flexibility relating to real-world application i.e.
> the one issue we already agreed upon; H/W or features that are too
> new (pre-release).

True, if "potentially".  If not potentially, they must be included.

> Bloating a generic kernel with potentially hundreds of unnecessary
> drivers that will never be executed in the vast majority of instances
> doesn't achieve anything.  If we have a kernel image that has the
> ability to boot on 10's of architectures which have 10's of platforms
> each, that's a whole host of unused/wasted executable space.

The key here is if the driver is required or not to use the platform,
and why it is required.  If the requirement comes from some deficiency
in the kernel code or config system, it should be fixed, if possible.
And the fix should be tested.
If it cannot be fixed, the driver should be included, else it would
preclude running the generic kernel on the affected platform.

> In order for vendors to work more closely with upstream, they need the
> ability to over-ride a *few* drivers to supplement them with some
> functionality which they believe provides them with a competitive edge
> (I think you called this "value-add" before) prior to the release of a
> device.  This is a requirement that cannot be worked around.
>
> By insisting on drivers (most of which will not be executed in the
> vast majority of cases) to be built-in, you are insisting on a
> downstream kernel fork, which all of us would like to avoid [0].
>
> [0] Full disclosure: part of my role at Linaro is to keep the Android
> kernel running as close to Mainline as possible and encourage/push the
> upstream-first mantra, hence my involvement with this and other sets.
> I assure you all intentions are good and honourable.  If you haven't
> already seen it, please see Todd's most recent update on the goals and
> status of GKI:
>
>   Article: https://tinyurl.com/saaen3sp
>   Video:   https://youtu.be/O_lCFGinFPM
>
> > We don't even know what are these unsupported, downstream platforms
> > you want customize kernel for. They cannot be audited, cannot be
> > compared.  Affecting upstream platforms just because
> > vendor/downstream does not want to mainline some code is
> > unacceptable. Please upstream your drivers and DTS.
>
> > You also mentioned downstream devices but without actually ever defining
> > them. Please be more specific. What SoC, what hardware?
>
> Accepting changes based on the proviso that vendors upstream all of
> their work-in-progress solutions is an unfair position.  We already
> discussed why upstreaming support for bleeding edge H/W and
> functionality is unrealistic in terms of competitive advantage.
>
> Besides, we might not be talking about new silicon at all (I don't
> believe anyone alluded to that).  The flexibility in configuration
> simply allows for generic upstream drivers to be swapped out for ones
> which may have more or slightly different functionality (that can't be
> publicly shared until release).

The replacement drivers are already a downstream kernel fork, which you
would like to avoid?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:

> Hi Lee,
> 
> On Thu, Sep 30, 2021 at 11:23 AM Lee Jones <lee.jones@linaro.org> wrote:
> > I've taken the liberty of cherry-picking some of the points you have
> > reiteratted a few times.  Hopefully I can help to address them
> > adequently.
> >
> > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > Reminder: these are essential drivers and all Exynos platforms must have
> > > them as built-in (at least till someone really tests this on multiple
> > > setups).
> >
> > > Therefore I don't agree with calling it a "problem" that we select
> > > *necessary* drivers for supported platforms. It's by design - supported
> > > platforms should receive them without ability to remove.
> >
> > > The selected drivers are essential for supported platforms.
> >
> > SoC specific drivers are only essential/necessary/required in
> > images designed to execute solely on a platform that requires them.
> 
> Why?

Because without them the image wouldn't functional on any level.

But you're right, there is still no requirement for it to be built-in.

> > For a kernel image which is designed to be generic i.e. one that has
> > the ability to boot on vast array of platforms, the drivers simply
> > have to be *available*.
> 
> If the drivers are really essential/necessary/required, this precludes
> running the generic kernel image on the platform that requires them,
> making the kernel not sufficiently generic.

If they are not at all present, then yes.  However that is not what is
being suggested.  The essential functionality will be provided.  Just
not built-in.

> > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > platforms as core binary built-ins doesn't make any technical sense.
> > The two most important issues this causes are image size and a lack of
> > configurability/flexibility relating to real-world application i.e.
> > the one issue we already agreed upon; H/W or features that are too
> > new (pre-release).
> 
> True, if "potentially".  If not potentially, they must be included.

I'm not sure what you're trying to say here.  Would you mind elaborating?

> > Bloating a generic kernel with potentially hundreds of unnecessary
> > drivers that will never be executed in the vast majority of instances
> > doesn't achieve anything.  If we have a kernel image that has the
> > ability to boot on 10's of architectures which have 10's of platforms
> > each, that's a whole host of unused/wasted executable space.
> 
> The key here is if the driver is required or not to use the platform,
> and why it is required.  If the requirement comes from some deficiency
> in the kernel code or config system, it should be fixed, if possible.
> And the fix should be tested.
> If it cannot be fixed, the driver should be included, else it would
> preclude running the generic kernel on the affected platform.

Sorry, I'm not following.

> > In order for vendors to work more closely with upstream, they need the
> > ability to over-ride a *few* drivers to supplement them with some
> > functionality which they believe provides them with a competitive edge
> > (I think you called this "value-add" before) prior to the release of a
> > device.  This is a requirement that cannot be worked around.
> >
> > By insisting on drivers (most of which will not be executed in the
> > vast majority of cases) to be built-in, you are insisting on a
> > downstream kernel fork, which all of us would like to avoid [0].
> >
> > [0] Full disclosure: part of my role at Linaro is to keep the Android
> > kernel running as close to Mainline as possible and encourage/push the
> > upstream-first mantra, hence my involvement with this and other sets.
> > I assure you all intentions are good and honourable.  If you haven't
> > already seen it, please see Todd's most recent update on the goals and
> > status of GKI:
> >
> >   Article: https://tinyurl.com/saaen3sp
> >   Video:   https://youtu.be/O_lCFGinFPM
> >
> > > We don't even know what are these unsupported, downstream platforms
> > > you want customize kernel for. They cannot be audited, cannot be
> > > compared.  Affecting upstream platforms just because
> > > vendor/downstream does not want to mainline some code is
> > > unacceptable. Please upstream your drivers and DTS.
> >
> > > You also mentioned downstream devices but without actually ever defining
> > > them. Please be more specific. What SoC, what hardware?
> >
> > Accepting changes based on the proviso that vendors upstream all of
> > their work-in-progress solutions is an unfair position.  We already
> > discussed why upstreaming support for bleeding edge H/W and
> > functionality is unrealistic in terms of competitive advantage.
> >
> > Besides, we might not be talking about new silicon at all (I don't
> > believe anyone alluded to that).  The flexibility in configuration
> > simply allows for generic upstream drivers to be swapped out for ones
> > which may have more or slightly different functionality (that can't be
> > publicly shared until release).
> 
> The replacement drivers are already a downstream kernel fork, which you
> would like to avoid?

Avoid, yes, absolutely.

However, in the real world of competitive tech, other than in extreme
cases such as; fully open source, community driven, cute embedded
hobby platforms, there will always be changes required on-top of
upstream projects.  Even as upstream kernel developers we need to
understand and respect that.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Lee,

On Thu, Sep 30, 2021 at 12:56 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > On Thu, Sep 30, 2021 at 11:23 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > I've taken the liberty of cherry-picking some of the points you have
> > > reiteratted a few times.  Hopefully I can help to address them
> > > adequently.
> > >
> > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > Reminder: these are essential drivers and all Exynos platforms must have
> > > > them as built-in (at least till someone really tests this on multiple
> > > > setups).
> > >
> > > > Therefore I don't agree with calling it a "problem" that we select
> > > > *necessary* drivers for supported platforms. It's by design - supported
> > > > platforms should receive them without ability to remove.
> > >
> > > > The selected drivers are essential for supported platforms.
> > >
> > > SoC specific drivers are only essential/necessary/required in
> > > images designed to execute solely on a platform that requires them.
> >
> > Why?
>
> Because without them the image wouldn't functional on any level.
>
> But you're right, there is still no requirement for it to be built-in.
>
> > > For a kernel image which is designed to be generic i.e. one that has
> > > the ability to boot on vast array of platforms, the drivers simply
> > > have to be *available*.
> >
> > If the drivers are really essential/necessary/required, this precludes
> > running the generic kernel image on the platform that requires them,
> > making the kernel not sufficiently generic.
>
> If they are not at all present, then yes.  However that is not what is
> being suggested.  The essential functionality will be provided.  Just
> not built-in.

I really meant "essential/necessary/required to be built-in".

> > > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > > platforms as core binary built-ins doesn't make any technical sense.
> > > The two most important issues this causes are image size and a lack of
> > > configurability/flexibility relating to real-world application i.e.
> > > the one issue we already agreed upon; H/W or features that are too
> > > new (pre-release).
> >
> > True, if "potentially".  If not potentially, they must be included.
>
> I'm not sure what you're trying to say here.  Would you mind elaborating?

It was a comment to your "*potentially* utilised on *some* platforms".
It is clear they are not used on the other ("not *some*") platforms, but your
sentence was unclear whether they are always or only sometimes used on
"*some*" platforms.
"always" => "not potentially"
"sometimes" => "potentially".

I hope this makes it more clear.

> > > Bloating a generic kernel with potentially hundreds of unnecessary
> > > drivers that will never be executed in the vast majority of instances
> > > doesn't achieve anything.  If we have a kernel image that has the
> > > ability to boot on 10's of architectures which have 10's of platforms
> > > each, that's a whole host of unused/wasted executable space.
> >
> > The key here is if the driver is required or not to use the platform,
> > and why it is required.  If the requirement comes from some deficiency
> > in the kernel code or config system, it should be fixed, if possible.
> > And the fix should be tested.
> > If it cannot be fixed, the driver should be included, else it would
> > preclude running the generic kernel on the affected platform.
>
> Sorry, I'm not following.

It all depends on why the driver is "required to be built-in".
Depending on the reason behind that requirement, the driver can be
changed from built-in to modular without ill effects on functionality.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:

> Hi Lee,
> 
> On Thu, Sep 30, 2021 at 12:56 PM Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > > On Thu, Sep 30, 2021 at 11:23 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > I've taken the liberty of cherry-picking some of the points you have
> > > > reiteratted a few times.  Hopefully I can help to address them
> > > > adequently.
> > > >
> > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > > Reminder: these are essential drivers and all Exynos platforms must have
> > > > > them as built-in (at least till someone really tests this on multiple
> > > > > setups).
> > > >
> > > > > Therefore I don't agree with calling it a "problem" that we select
> > > > > *necessary* drivers for supported platforms. It's by design - supported
> > > > > platforms should receive them without ability to remove.
> > > >
> > > > > The selected drivers are essential for supported platforms.
> > > >
> > > > SoC specific drivers are only essential/necessary/required in
> > > > images designed to execute solely on a platform that requires them.
> > >
> > > Why?
> >
> > Because without them the image wouldn't functional on any level.
> >
> > But you're right, there is still no requirement for it to be built-in.
> >
> > > > For a kernel image which is designed to be generic i.e. one that has
> > > > the ability to boot on vast array of platforms, the drivers simply
> > > > have to be *available*.
> > >
> > > If the drivers are really essential/necessary/required, this precludes
> > > running the generic kernel image on the platform that requires them,
> > > making the kernel not sufficiently generic.
> >
> > If they are not at all present, then yes.  However that is not what is
> > being suggested.  The essential functionality will be provided.  Just
> > not built-in.
> 
> I really meant "essential/necessary/required to be built-in".

Then I agree with you.  My position is that if they don't *have* to be
built-in, then why force it?

> > > > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > > > platforms as core binary built-ins doesn't make any technical sense.
> > > > The two most important issues this causes are image size and a lack of
> > > > configurability/flexibility relating to real-world application i.e.
> > > > the one issue we already agreed upon; H/W or features that are too
> > > > new (pre-release).
> > >
> > > True, if "potentially".  If not potentially, they must be included.
> >
> > I'm not sure what you're trying to say here.  Would you mind elaborating?
> 
> It was a comment to your "*potentially* utilised on *some* platforms".
> It is clear they are not used on the other ("not *some*") platforms, but your
> sentence was unclear whether they are always or only sometimes used on
> "*some*" platforms.
> "always" => "not potentially"
> "sometimes" => "potentially".
> 
> I hope this makes it more clear.

Not really, but I'll try to clean mine up:

The aim is to have a single kernel (image + modules) that can be
booted on a plethora of platforms.  For the sake of argument say 10.
Let's also say that each of the platforms are equal and will be booted
the same amount of times.

Taking the example above, when I say that the H/W specific drivers
will only be *potentially* utilised, I mean that they will only be
bound and probed 1/10 times i.e. when booted on the associated
platform.  Which means that in the vast majority of boots (9/10) they
will lie dormant, taking up unnecessary space.

Another way to say this would be; the kernel needs to have the
capability to boot all of the supported platforms, but it will only
ever be utilised on one at a time.

> > > > Bloating a generic kernel with potentially hundreds of unnecessary
> > > > drivers that will never be executed in the vast majority of instances
> > > > doesn't achieve anything.  If we have a kernel image that has the
> > > > ability to boot on 10's of architectures which have 10's of platforms
> > > > each, that's a whole host of unused/wasted executable space.
> > >
> > > The key here is if the driver is required or not to use the platform,
> > > and why it is required.  If the requirement comes from some deficiency
> > > in the kernel code or config system, it should be fixed, if possible.
> > > And the fix should be tested.
> > > If it cannot be fixed, the driver should be included, else it would
> > > preclude running the generic kernel on the affected platform.
> >
> > Sorry, I'm not following.
> 
> It all depends on why the driver is "required to be built-in".
> Depending on the reason behind that requirement, the driver can be
> changed from built-in to modular without ill effects on functionality.

Absolutely.

There are cases where drivers simply can't be built as modules.  These
unavoidable situations are legitimate use-cases and the technology/
code-base will have to work around these as required.

The argument here is that if they can be separated and have been shown
to work well in either use-case, then it is my opinion that placing an
artificial barrier up based mostly on politics is not the correct
approach. 

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Lee,

On Thu, Sep 30, 2021 at 2:08 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > On Thu, Sep 30, 2021 at 12:56 PM Lee Jones <lee.jones@linaro.org> wrote:
> > > On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > > > On Thu, Sep 30, 2021 at 11:23 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > I've taken the liberty of cherry-picking some of the points you have
> > > > > reiteratted a few times.  Hopefully I can help to address them
> > > > > adequently.
> > > > >
> > > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > > > Reminder: these are essential drivers and all Exynos platforms must have
> > > > > > them as built-in (at least till someone really tests this on multiple
> > > > > > setups).
> > > > >
> > > > > > Therefore I don't agree with calling it a "problem" that we select
> > > > > > *necessary* drivers for supported platforms. It's by design - supported
> > > > > > platforms should receive them without ability to remove.
> > > > >
> > > > > > The selected drivers are essential for supported platforms.
> > > > >
> > > > > SoC specific drivers are only essential/necessary/required in
> > > > > images designed to execute solely on a platform that requires them.
> > > >
> > > > Why?
> > >
> > > Because without them the image wouldn't functional on any level.
> > >
> > > But you're right, there is still no requirement for it to be built-in.
> > >
> > > > > For a kernel image which is designed to be generic i.e. one that has
> > > > > the ability to boot on vast array of platforms, the drivers simply
> > > > > have to be *available*.
> > > >
> > > > If the drivers are really essential/necessary/required, this precludes
> > > > running the generic kernel image on the platform that requires them,
> > > > making the kernel not sufficiently generic.
> > >
> > > If they are not at all present, then yes.  However that is not what is
> > > being suggested.  The essential functionality will be provided.  Just
> > > not built-in.
> >
> > I really meant "essential/necessary/required to be built-in".
>
> Then I agree with you.  My position is that if they don't *have* to be
> built-in, then why force it?
>
> > > > > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > > > > platforms as core binary built-ins doesn't make any technical sense.
> > > > > The two most important issues this causes are image size and a lack of
> > > > > configurability/flexibility relating to real-world application i.e.
> > > > > the one issue we already agreed upon; H/W or features that are too
> > > > > new (pre-release).
> > > >
> > > > True, if "potentially".  If not potentially, they must be included.
> > >
> > > I'm not sure what you're trying to say here.  Would you mind elaborating?
> >
> > It was a comment to your "*potentially* utilised on *some* platforms".
> > It is clear they are not used on the other ("not *some*") platforms, but your
> > sentence was unclear whether they are always or only sometimes used on
> > "*some*" platforms.
> > "always" => "not potentially"
> > "sometimes" => "potentially".
> >
> > I hope this makes it more clear.
>
> Not really, but I'll try to clean mine up:
>
> The aim is to have a single kernel (image + modules) that can be
> booted on a plethora of platforms.  For the sake of argument say 10.
> Let's also say that each of the platforms are equal and will be booted
> the same amount of times.
>
> Taking the example above, when I say that the H/W specific drivers
> will only be *potentially* utilised, I mean that they will only be
> bound and probed 1/10 times i.e. when booted on the associated
> platform.  Which means that in the vast majority of boots (9/10) they
> will lie dormant, taking up unnecessary space.
>
> Another way to say this would be; the kernel needs to have the
> capability to boot all of the supported platforms, but it will only
> ever be utilised on one at a time.

That's true even for drivers for "generic" hardware, right?
E.g. arm64 selects ARM_GIC and ARM_GIC_V3, where most (all?)
platforms have at most one of them.

> > > > > Bloating a generic kernel with potentially hundreds of unnecessary
> > > > > drivers that will never be executed in the vast majority of instances
> > > > > doesn't achieve anything.  If we have a kernel image that has the
> > > > > ability to boot on 10's of architectures which have 10's of platforms
> > > > > each, that's a whole host of unused/wasted executable space.
> > > >
> > > > The key here is if the driver is required or not to use the platform,
> > > > and why it is required.  If the requirement comes from some deficiency
> > > > in the kernel code or config system, it should be fixed, if possible.
> > > > And the fix should be tested.
> > > > If it cannot be fixed, the driver should be included, else it would
> > > > preclude running the generic kernel on the affected platform.
> > >
> > > Sorry, I'm not following.
> >
> > It all depends on why the driver is "required to be built-in".
> > Depending on the reason behind that requirement, the driver can be
> > changed from built-in to modular without ill effects on functionality.
>
> Absolutely.
>
> There are cases where drivers simply can't be built as modules.  These
> unavoidable situations are legitimate use-cases and the technology/
> code-base will have to work around these as required.
>
> The argument here is that if they can be separated and have been shown
> to work well in either use-case, then it is my opinion that placing an
> artificial barrier up based mostly on politics is not the correct
> approach.

Agreed.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 30/09/2021 11:23, Lee Jones wrote:
> I've taken the liberty of cherry-picking some of the points you have
> reiteratted a few times.  Hopefully I can help to address them
> adequently.
> 
> On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
>> Reminder: these are essential drivers and all Exynos platforms must have
>> them as built-in (at least till someone really tests this on multiple
>> setups).
> 
>> Therefore I don't agree with calling it a "problem" that we select
>> *necessary* drivers for supported platforms. It's by design - supported
>> platforms should receive them without ability to remove.
> 
>> The selected drivers are essential for supported platforms.
> 
> SoC specific drivers are only essential/necessary/required in
> images designed to execute solely on a platform that requires them.
> For a kernel image which is designed to be generic i.e. one that has
> the ability to boot on vast array of platforms, the drivers simply
> have to be *available*.

By "essential", I meant drivers which are needed for supported platform
to boot properly. Also without significant performance penalty due to
probe deferrals.

Therefore if someone selects ARCH_EXYNOS in mainline kernel, it means
he/she wants such devices to be working fine with generic kernel.

This is the difference with term "drivers have to be available".

> 
> Forcing all H/W drivers that are only *potentially* utilised on *some*
> platforms as core binary built-ins doesn't make any technical sense.
> The two most important issues this causes are image size and a lack of
> configurability/flexibility relating to real-world application i.e.
> the one issue we already agreed upon; H/W or features that are too
> new (pre-release).

Geert responded here. If drivers are essential for supported platforms
to boot, having them built-in has technical sense.
For other drivers not and we do not discuss such cases.

> 
> Bloating a generic kernel with potentially hundreds of unnecessary
> drivers that will never be executed in the vast majority of instances
> doesn't achieve anything.  If we have a kernel image that has the
> ability to boot on 10's of architectures which have 10's of platforms
> each, that's a whole host of unused/wasted executable space.

Geert responded here.

> 
> In order for vendors to work more closely with upstream, they need the
> ability to over-ride a *few* drivers to supplement them with some
> functionality which they believe provides them with a competitive edge
> (I think you called this "value-add" before) prior to the release of a
> device.  This is a requirement that cannot be worked around.
> 
> By insisting on drivers (most of which will not be executed in the
> vast majority of cases) to be built-in, you are insisting on a
> downstream kernel fork, which all of us would like to avoid [0].

The same with all the DTS and hundreds of drivers you keep out of tree.

> 
> [0] Full disclosure: part of my role at Linaro is to keep the Android
> kernel running as close to Mainline as possible and encourage/push the
> upstream-first mantra, hence my involvement with this and other sets.
> I assure you all intentions are good and honourable.  If you haven't
> already seen it, please see Todd's most recent update on the goals and
> status of GKI:
> 
>   Article: https://tinyurl.com/saaen3sp
>   Video:   https://youtu.be/O_lCFGinFPM
> 
>> We don't even know what are these unsupported, downstream platforms
>> you want customize kernel for. They cannot be audited, cannot be
>> compared.  Affecting upstream platforms just because
>> vendor/downstream does not want to mainline some code is
>> unacceptable. Please upstream your drivers and DTS.
> 
>> You also mentioned downstream devices but without actually ever defining
>> them. Please be more specific. What SoC, what hardware?
> 
> Accepting changes based on the proviso that vendors upstream all of
> their work-in-progress solutions is an unfair position.  

You twisted (or ignored) my words here. I said before - sacrificing any
mainline platform (e.g. reliable boot for distro) for an out-of-tree
vendor which does no want to upstream drivers is the unfair position.
One of the incentives of upstreaming is to be able to shape kernel and
be considered in kernel upstream decisions. That's the privileged for
upstreamed platforms - they have an impact.

Vendor decides to stay out - fine, vendor's choice. You loose impact.
Any sad words like "oh upstream does not want to change for me" should
receive a message: "please join the upstream :), so we will change
together".

> We already
> discussed why upstreaming support for bleeding edge H/W and
> functionality is unrealistic in terms of competitive advantage.

Nope, my last point was not responded to. You said that there is no
point for vendor to upstream bleeding edge HW. Then you said that there
is also little point to upstream older HW.

Basically following this approach you agree that vendor does not have to
do anything because it is inconvenient for him.

However upstream has to adapt to downstream vendor, right?

No, this is *unfair to all the platforms we upstreamed*.

> 
> Besides, we might not be talking about new silicon at all (I don't
> believe anyone alluded to that).  The flexibility in configuration
> simply allows for generic upstream drivers to be swapped out for ones
> which may have more or slightly different functionality (that can't be
> publicly shared until release).
> 
>> Please explain why Exynos is special that it does not require essential
>> drivers to be selected as built-in. For example why aren't same changes
>> done for Renesas?
> 
>> Everyone else are working like this. NXP, Renesas, Xilinx, TI, Rockchip,
>> AllWinner. Samsung or Google is not special to receive an exception for
>> this.
> 
> Exynos isn't special in this regard.  This applies to any vendor who
> releases Android images and wishes to be solve all of the issues the
> GKI project addresses (please read the article above for more about
> this).

We have then slightly different goals, because you are driven by Android
release images and this is why you are less interested in NXP and
Renesas. Only some vendors should receive such changes? No, in upstream
we are not focusing on any specific distro and there are other uses of
Exynos (and NXP and Renesas) platforms. Therefore the choice/policy and
overall design tries to match all vendors, not only some subset
convenient to Android.

If Android (or some vendor) wants to have exception for a specific
driver/platform, it must do it in upstream way, by contributing, not by
changing to match downstream needs while ignoring other users.

Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:

> On 30/09/2021 11:23, Lee Jones wrote:
> > I've taken the liberty of cherry-picking some of the points you have
> > reiteratted a few times.  Hopefully I can help to address them
> > adequently.
> > 
> > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> >> Reminder: these are essential drivers and all Exynos platforms must have
> >> them as built-in (at least till someone really tests this on multiple
> >> setups).
> > 
> >> Therefore I don't agree with calling it a "problem" that we select
> >> *necessary* drivers for supported platforms. It's by design - supported
> >> platforms should receive them without ability to remove.
> > 
> >> The selected drivers are essential for supported platforms.
> > 
> > SoC specific drivers are only essential/necessary/required in
> > images designed to execute solely on a platform that requires them.
> > For a kernel image which is designed to be generic i.e. one that has
> > the ability to boot on vast array of platforms, the drivers simply
> > have to be *available*.
> 
> By "essential", I meant drivers which are needed for supported platform
> to boot properly.

Yes, I know what you meant by essential.

My comment still stands.  As long as they are provided, it should work.

> Also without significant performance penalty due to
> probe deferrals.

Agreed.  We will try to find a way to test this.

> > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > platforms as core binary built-ins doesn't make any technical sense.
> > The two most important issues this causes are image size and a lack of
> > configurability/flexibility relating to real-world application i.e.
> > the one issue we already agreed upon; H/W or features that are too
> > new (pre-release).
> 
> Geert responded here. If drivers are essential for supported platforms
> to boot, having them built-in has technical sense.

We're going to have to agree to disagree here.

None of us are currently aware of any technical reasons why these
particular drivers have to be built-in.  Hopefully we can prove this
out with testing.

> > By insisting on drivers (most of which will not be executed in the
> > vast majority of cases) to be built-in, you are insisting on a
> > downstream kernel fork, which all of us would like to avoid [0].
> 
> The same with all the DTS and hundreds of drivers you keep out of tree.

I do not keep any drivers out of tree. :)

> >> We don't even know what are these unsupported, downstream platforms
> >> you want customize kernel for. They cannot be audited, cannot be
> >> compared.  Affecting upstream platforms just because
> >> vendor/downstream does not want to mainline some code is
> >> unacceptable.
> >>
> >> Please upstream your drivers and DTS.
> > 
> > Accepting changes based on the proviso that vendors upstream all of
> > their work-in-progress solutions is an unfair position.  
> 
> You twisted (or ignored) my words here. I said before - sacrificing any
> mainline platform (e.g. reliable boot for distro) for an out-of-tree
> vendor which does no want to upstream drivers is the unfair position.
> One of the incentives of upstreaming is to be able to shape kernel and
> be considered in kernel upstream decisions. That's the privileged for
> upstreamed platforms - they have an impact.
> 
> Vendor decides to stay out - fine, vendor's choice. You loose impact.
> Any sad words like "oh upstream does not want to change for me" should
> receive a message: "please join the upstream :), so we will change
> together".

No one is proposing to sacrifice anything.

This change is believed to be benign.

> > We already
> > discussed why upstreaming support for bleeding edge H/W and
> > functionality is unrealistic in terms of competitive advantage.
> 
> Nope, my last point was not responded to. You said that there is no
> point for vendor to upstream bleeding edge HW. Then you said that there
> is also little point to upstream older HW.

The driver in question is already upstream.

It is my hope that the vendor will realign with Mainline and upstream
the differences (providing the current competitive edge).  Although I
have no real influence in this regard, as I have no contact with
them.

> Basically following this approach you agree that vendor does not have to
> do anything because it is inconvenient for him.
> 
> However upstream has to adapt to downstream vendor, right?
> 
> No, this is *unfair to all the platforms we upstreamed*.

The point here is that this change should not be a determent to
anyone.

> > Exynos isn't special in this regard.  This applies to any vendor who
> > releases Android images and wishes to be solve all of the issues the
> > GKI project addresses (please read the article above for more about
> > this).
> 
> We have then slightly different goals, because you are driven by Android
> release images and this is why you are less interested in NXP and
> Renesas. Only some vendors should receive such changes? No, in upstream
> we are not focusing on any specific distro and there are other uses of
> Exynos (and NXP and Renesas) platforms. Therefore the choice/policy and
> overall design tries to match all vendors, not only some subset
> convenient to Android.
> 
> If Android (or some vendor) wants to have exception for a specific
> driver/platform, it must do it in upstream way, by contributing, not by
> changing to match downstream needs while ignoring other users.

No users are being ignored.  No damaging changes are being proposed.

This has little to do with Android and everything to do with the
possibly of a more generic kernel.  Moving drivers out of platform
code and into /drivers along with enabling components as modules has
been an on-going effort for many years now.

I'm struggling to see how this is different.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Tomasz Figa]

2021年9月30日(木) 18:23 Lee Jones <lee.jones@linaro.org>:
>
> I've taken the liberty of cherry-picking some of the points you have
> reiteratted a few times.  Hopefully I can help to address them
> adequently.
>
> On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > Reminder: these are essential drivers and all Exynos platforms must have
> > them as built-in (at least till someone really tests this on multiple
> > setups).
>
> > Therefore I don't agree with calling it a "problem" that we select
> > *necessary* drivers for supported platforms. It's by design - supported
> > platforms should receive them without ability to remove.
>
> > The selected drivers are essential for supported platforms.
>
> SoC specific drivers are only essential/necessary/required in
> images designed to execute solely on a platform that requires them.
> For a kernel image which is designed to be generic i.e. one that has
> the ability to boot on vast array of platforms, the drivers simply
> have to be *available*.
>
> Forcing all H/W drivers that are only *potentially* utilised on *some*
> platforms as core binary built-ins doesn't make any technical sense.
> The two most important issues this causes are image size and a lack of
> configurability/flexibility relating to real-world application i.e.
> the one issue we already agreed upon; H/W or features that are too
> new (pre-release).
>
> Bloating a generic kernel with potentially hundreds of unnecessary
> drivers that will never be executed in the vast majority of instances
> doesn't achieve anything.  If we have a kernel image that has the
> ability to boot on 10's of architectures which have 10's of platforms
> each, that's a whole host of unused/wasted executable space.
>
> In order for vendors to work more closely with upstream, they need the
> ability to over-ride a *few* drivers to supplement them with some
> functionality which they believe provides them with a competitive edge
> (I think you called this "value-add" before) prior to the release of a
> device.  This is a requirement that cannot be worked around.

[Chiming in as a clock driver sub-maintainer and someone who spent a
non-insignificant part of his life on SoC driver bring-up - not as a
Google employee.]

I'd argue that the proper way for them to achieve it would be to
extend the upstream frameworks and/or existing drivers with
appropriate APIs to allow their downstream modules to plug into what's
already available upstream.

Best regards,
Tomasz

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Tomasz,

On Thu, Sep 30, 2021 at 1:01 PM Tomasz Figa <tomasz.figa@gmail.com> wrote:
> 2021年9月30日(木) 18:23 Lee Jones <lee.jones@linaro.org>:
> > I've taken the liberty of cherry-picking some of the points you have
> > reiteratted a few times.  Hopefully I can help to address them
> > adequently.
> >
> > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > Reminder: these are essential drivers and all Exynos platforms must have
> > > them as built-in (at least till someone really tests this on multiple
> > > setups).
> >
> > > Therefore I don't agree with calling it a "problem" that we select
> > > *necessary* drivers for supported platforms. It's by design - supported
> > > platforms should receive them without ability to remove.
> >
> > > The selected drivers are essential for supported platforms.
> >
> > SoC specific drivers are only essential/necessary/required in
> > images designed to execute solely on a platform that requires them.
> > For a kernel image which is designed to be generic i.e. one that has
> > the ability to boot on vast array of platforms, the drivers simply
> > have to be *available*.
> >
> > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > platforms as core binary built-ins doesn't make any technical sense.
> > The two most important issues this causes are image size and a lack of
> > configurability/flexibility relating to real-world application i.e.
> > the one issue we already agreed upon; H/W or features that are too
> > new (pre-release).
> >
> > Bloating a generic kernel with potentially hundreds of unnecessary
> > drivers that will never be executed in the vast majority of instances
> > doesn't achieve anything.  If we have a kernel image that has the
> > ability to boot on 10's of architectures which have 10's of platforms
> > each, that's a whole host of unused/wasted executable space.
> >
> > In order for vendors to work more closely with upstream, they need the
> > ability to over-ride a *few* drivers to supplement them with some
> > functionality which they believe provides them with a competitive edge
> > (I think you called this "value-add" before) prior to the release of a
> > device.  This is a requirement that cannot be worked around.
>
> [Chiming in as a clock driver sub-maintainer and someone who spent a
> non-insignificant part of his life on SoC driver bring-up - not as a
> Google employee.]
>
> I'd argue that the proper way for them to achieve it would be to
> extend the upstream frameworks and/or existing drivers with
> appropriate APIs to allow their downstream modules to plug into what's
> already available upstream.

Yes, that's one possible solution.
We do have to be careful this would not just become some fishy API
to touch deeply buried internals, and for which there are no valid use
cases in upstream.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Tomasz Figa wrote:

> 2021年9月30日(木) 18:23 Lee Jones <lee.jones@linaro.org>:
> >
> > I've taken the liberty of cherry-picking some of the points you have
> > reiteratted a few times.  Hopefully I can help to address them
> > adequently.
> >
> > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > Reminder: these are essential drivers and all Exynos platforms must have
> > > them as built-in (at least till someone really tests this on multiple
> > > setups).
> >
> > > Therefore I don't agree with calling it a "problem" that we select
> > > *necessary* drivers for supported platforms. It's by design - supported
> > > platforms should receive them without ability to remove.
> >
> > > The selected drivers are essential for supported platforms.
> >
> > SoC specific drivers are only essential/necessary/required in
> > images designed to execute solely on a platform that requires them.
> > For a kernel image which is designed to be generic i.e. one that has
> > the ability to boot on vast array of platforms, the drivers simply
> > have to be *available*.
> >
> > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > platforms as core binary built-ins doesn't make any technical sense.
> > The two most important issues this causes are image size and a lack of
> > configurability/flexibility relating to real-world application i.e.
> > the one issue we already agreed upon; H/W or features that are too
> > new (pre-release).
> >
> > Bloating a generic kernel with potentially hundreds of unnecessary
> > drivers that will never be executed in the vast majority of instances
> > doesn't achieve anything.  If we have a kernel image that has the
> > ability to boot on 10's of architectures which have 10's of platforms
> > each, that's a whole host of unused/wasted executable space.
> >
> > In order for vendors to work more closely with upstream, they need the
> > ability to over-ride a *few* drivers to supplement them with some
> > functionality which they believe provides them with a competitive edge
> > (I think you called this "value-add" before) prior to the release of a
> > device.  This is a requirement that cannot be worked around.
> 
> [Chiming in as a clock driver sub-maintainer and someone who spent a
> non-insignificant part of his life on SoC driver bring-up - not as a
> Google employee.]
> 
> I'd argue that the proper way for them to achieve it would be to
> extend the upstream frameworks and/or existing drivers with
> appropriate APIs to allow their downstream modules to plug into what's
> already available upstream.

Is that the same as exporting symbols to framework APIs?

Since this is already a method GKI uses to allow external modules to
interact with the core kernel/frameworks.  However, it's not possible
to upstream these without an upstream user for each one.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Tomasz Figa]

2021年9月30日(木) 20:51 Lee Jones <lee.jones@linaro.org>:
>
> On Thu, 30 Sep 2021, Tomasz Figa wrote:
>
> > 2021年9月30日(木) 18:23 Lee Jones <lee.jones@linaro.org>:
> > >
> > > I've taken the liberty of cherry-picking some of the points you have
> > > reiteratted a few times.  Hopefully I can help to address them
> > > adequently.
> > >
> > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > Reminder: these are essential drivers and all Exynos platforms must have
> > > > them as built-in (at least till someone really tests this on multiple
> > > > setups).
> > >
> > > > Therefore I don't agree with calling it a "problem" that we select
> > > > *necessary* drivers for supported platforms. It's by design - supported
> > > > platforms should receive them without ability to remove.
> > >
> > > > The selected drivers are essential for supported platforms.
> > >
> > > SoC specific drivers are only essential/necessary/required in
> > > images designed to execute solely on a platform that requires them.
> > > For a kernel image which is designed to be generic i.e. one that has
> > > the ability to boot on vast array of platforms, the drivers simply
> > > have to be *available*.
> > >
> > > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > > platforms as core binary built-ins doesn't make any technical sense.
> > > The two most important issues this causes are image size and a lack of
> > > configurability/flexibility relating to real-world application i.e.
> > > the one issue we already agreed upon; H/W or features that are too
> > > new (pre-release).
> > >
> > > Bloating a generic kernel with potentially hundreds of unnecessary
> > > drivers that will never be executed in the vast majority of instances
> > > doesn't achieve anything.  If we have a kernel image that has the
> > > ability to boot on 10's of architectures which have 10's of platforms
> > > each, that's a whole host of unused/wasted executable space.
> > >
> > > In order for vendors to work more closely with upstream, they need the
> > > ability to over-ride a *few* drivers to supplement them with some
> > > functionality which they believe provides them with a competitive edge
> > > (I think you called this "value-add" before) prior to the release of a
> > > device.  This is a requirement that cannot be worked around.
> >
> > [Chiming in as a clock driver sub-maintainer and someone who spent a
> > non-insignificant part of his life on SoC driver bring-up - not as a
> > Google employee.]
> >
> > I'd argue that the proper way for them to achieve it would be to
> > extend the upstream frameworks and/or existing drivers with
> > appropriate APIs to allow their downstream modules to plug into what's
> > already available upstream.
>
> Is that the same as exporting symbols to framework APIs?
>
> Since this is already a method GKI uses to allow external modules to
> interact with the core kernel/frameworks.  However, it's not possible
> to upstream these without an upstream user for each one.

Not necessary the core frameworks, could also be changing the ways the
existing drivers register to allow additional drivers to extend the
functionality rather than completely overwrite them. It's really hard
to tell what the right way would be without knowing the exact things
they find missing in the upstream drivers. As for upstream users, this
is exactly the point - upstream is a bidirectional effort, one takes
from it and should contribute things back.

Generally, the subsystems being mentioned here are so basic (clock,
pinctrl, rtc), that I really can't imagine what kind of rocket science
one might want to hide for competitive reasons... If it's for an
entire SoC, I wonder why Intel and AMD don't have similar concerns and
contribute support for their newest hardware far before the release.

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 30/09/2021 14:10, Tomasz Figa wrote:
> 2021年9月30日(木) 20:51 Lee Jones <lee.jones@linaro.org>:
>>
>> On Thu, 30 Sep 2021, Tomasz Figa wrote:
>>
>>
>> Is that the same as exporting symbols to framework APIs?
>>
>> Since this is already a method GKI uses to allow external modules to
>> interact with the core kernel/frameworks.  However, it's not possible
>> to upstream these without an upstream user for each one.
> 
> Not necessary the core frameworks, could also be changing the ways the
> existing drivers register to allow additional drivers to extend the
> functionality rather than completely overwrite them. 

Yes, the first user could be within the kernel after modifying some of
the drivers.

> It's really hard
> to tell what the right way would be without knowing the exact things
> they find missing in the upstream drivers. As for upstream users, this
> is exactly the point - upstream is a bidirectional effort, one takes
> from it and should contribute things back.
> 
> Generally, the subsystems being mentioned here are so basic (clock,
> pinctrl, rtc), that I really can't imagine what kind of rocket science
> one might want to hide for competitive reasons... If it's for an
> entire SoC, I wonder why Intel and AMD don't have similar concerns and
> contribute support for their newest hardware far before the release.

Lee used the argument of not-disclosing-edge-hw but I also don't see
much of it in the case of few drivers needed to be overridden. Just
bunch of registers for the same stuff we have sine 8 years. Rather the
vendor does not want to commit effort towards upstreaming these...


Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Tomasz Figa wrote:

> 2021年9月30日(木) 20:51 Lee Jones <lee.jones@linaro.org>:
> >
> > On Thu, 30 Sep 2021, Tomasz Figa wrote:
> >
> > > 2021年9月30日(木) 18:23 Lee Jones <lee.jones@linaro.org>:
> > > >
> > > > I've taken the liberty of cherry-picking some of the points you have
> > > > reiteratted a few times.  Hopefully I can help to address them
> > > > adequently.
> > > >
> > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > > Reminder: these are essential drivers and all Exynos platforms must have
> > > > > them as built-in (at least till someone really tests this on multiple
> > > > > setups).
> > > >
> > > > > Therefore I don't agree with calling it a "problem" that we select
> > > > > *necessary* drivers for supported platforms. It's by design - supported
> > > > > platforms should receive them without ability to remove.
> > > >
> > > > > The selected drivers are essential for supported platforms.
> > > >
> > > > SoC specific drivers are only essential/necessary/required in
> > > > images designed to execute solely on a platform that requires them.
> > > > For a kernel image which is designed to be generic i.e. one that has
> > > > the ability to boot on vast array of platforms, the drivers simply
> > > > have to be *available*.
> > > >
> > > > Forcing all H/W drivers that are only *potentially* utilised on *some*
> > > > platforms as core binary built-ins doesn't make any technical sense.
> > > > The two most important issues this causes are image size and a lack of
> > > > configurability/flexibility relating to real-world application i.e.
> > > > the one issue we already agreed upon; H/W or features that are too
> > > > new (pre-release).
> > > >
> > > > Bloating a generic kernel with potentially hundreds of unnecessary
> > > > drivers that will never be executed in the vast majority of instances
> > > > doesn't achieve anything.  If we have a kernel image that has the
> > > > ability to boot on 10's of architectures which have 10's of platforms
> > > > each, that's a whole host of unused/wasted executable space.
> > > >
> > > > In order for vendors to work more closely with upstream, they need the
> > > > ability to over-ride a *few* drivers to supplement them with some
> > > > functionality which they believe provides them with a competitive edge
> > > > (I think you called this "value-add" before) prior to the release of a
> > > > device.  This is a requirement that cannot be worked around.
> > >
> > > [Chiming in as a clock driver sub-maintainer and someone who spent a
> > > non-insignificant part of his life on SoC driver bring-up - not as a
> > > Google employee.]
> > >
> > > I'd argue that the proper way for them to achieve it would be to
> > > extend the upstream frameworks and/or existing drivers with
> > > appropriate APIs to allow their downstream modules to plug into what's
> > > already available upstream.
> >
> > Is that the same as exporting symbols to framework APIs?
> >
> > Since this is already a method GKI uses to allow external modules to
> > interact with the core kernel/frameworks.  However, it's not possible
> > to upstream these without an upstream user for each one.
> 
> Not necessary the core frameworks, could also be changing the ways the
> existing drivers register to allow additional drivers to extend the
> functionality rather than completely overwrite them. It's really hard
> to tell what the right way would be without knowing the exact things
> they find missing in the upstream drivers. As for upstream users, this
> is exactly the point - upstream is a bidirectional effort, one takes
> from it and should contribute things back.
> 
> Generally, the subsystems being mentioned here are so basic (clock,
> pinctrl, rtc), that I really can't imagine what kind of rocket science
> one might want to hide for competitive reasons... If it's for an
> entire SoC, I wonder why Intel and AMD don't have similar concerns and
> contribute support for their newest hardware far before the release.

I don't have visibility into the driver-overrides I'm afraid.

I do know that code-space can be a problem though.  So any way we can
make the core binary smaller (i.e. remove anything that can be built
as a module) will have a positive effect.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Christoph Hellwig]

On Thu, Sep 30, 2021 at 09:10:31PM +0900, Tomasz Figa wrote:
> Generally, the subsystems being mentioned here are so basic (clock,
> pinctrl, rtc), that I really can't imagine what kind of rocket science
> one might want to hide for competitive reasons... If it's for an
> entire SoC, I wonder why Intel and AMD don't have similar concerns and
> contribute support for their newest hardware far before the release.

There is no reason at all, and to be honest this whole discussion with
these bullshit arguments from the Google/Linaro/SoC vendor crowd just
shows how on crack these people are, and shows a good example of why
we should not support these models at all.  There is no good reason
to "overide" uptream functionality EVER.  Stop digging yourselves into
your ever bigger holes and just f***king contribute upstream NOW.  Just
as we always have we should not give you more rope to shoot yoursel
while ausing us extra overhead.

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Saravana Kannan]

On Thu, Sep 30, 2021 at 9:02 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Sep 30, 2021 at 09:10:31PM +0900, Tomasz Figa wrote:
> > Generally, the subsystems being mentioned here are so basic (clock,
> > pinctrl, rtc), that I really can't imagine what kind of rocket science
> > one might want to hide for competitive reasons... If it's for an
> > entire SoC, I wonder why Intel and AMD don't have similar concerns and
> > contribute support for their newest hardware far before the release.
>
> There is no reason at all, and to be honest this whole discussion with
> these bullshit arguments from the Google/Linaro/SoC vendor crowd just
> shows how on crack these people are, and shows a good example of why
> we should not support these models at all.  There is no good reason
> to "overide" uptream functionality EVER.  Stop digging yourselves into
> your ever bigger holes and just f***king contribute upstream NOW.  Just
> as we always have we should not give you more rope to shoot yoursel
> while ausing us extra overhead.

Maybe you need to read up the code of conduct again.

-Saravana

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Christoph Hellwig]

On Thu, Sep 30, 2021 at 09:52:12PM -0700, Saravana Kannan wrote:
> Maybe you need to read up the code of conduct again.

*plonk*

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 30/09/2021 11:23, Lee Jones wrote:
> [0] Full disclosure: part of my role at Linaro is to keep the Android
> kernel running as close to Mainline as possible and encourage/push the
> upstream-first mantra, hence my involvement with this and other sets.
> I assure you all intentions are good and honourable.  If you haven't
> already seen it, please see Todd's most recent update on the goals and
> status of GKI:
> 
>   Article: https://tinyurl.com/saaen3sp
>   Video:   https://youtu.be/O_lCFGinFPM
> 

Side topic, why this patchset is in your scope or Will's/Google's scope?
Just drop it from Android main kernel, it will not be your problem. I
mean, really, you don't need this patchset in your tree at all. The only
platform which needs it, the only platform which will loose something
will be one specific vendor. Therefore this will be an incentive for
them to join both discussions and upstream development. :)

Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:

> On 30/09/2021 11:23, Lee Jones wrote:
> > [0] Full disclosure: part of my role at Linaro is to keep the Android
> > kernel running as close to Mainline as possible and encourage/push the
> > upstream-first mantra, hence my involvement with this and other sets.
> > I assure you all intentions are good and honourable.  If you haven't
> > already seen it, please see Todd's most recent update on the goals and
> > status of GKI:
> > 
> >   Article: https://tinyurl.com/saaen3sp
> >   Video:   https://youtu.be/O_lCFGinFPM
> > 
> 
> Side topic, why this patchset is in your scope or Will's/Google's scope?
> Just drop it from Android main kernel, it will not be your problem. I
> mean, really, you don't need this patchset in your tree at all. The only
> platform which needs it, the only platform which will loose something
> will be one specific vendor. Therefore this will be an incentive for
> them to join both discussions and upstream development. :)

How would they fix this besides upstreaming support for unreleased
work-in-progress H/W?

Haven't I explained this several times already? :)

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 30/09/2021 14:39, Lee Jones wrote:
> On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> 
>> On 30/09/2021 11:23, Lee Jones wrote:
>>> [0] Full disclosure: part of my role at Linaro is to keep the Android
>>> kernel running as close to Mainline as possible and encourage/push the
>>> upstream-first mantra, hence my involvement with this and other sets.
>>> I assure you all intentions are good and honourable.  If you haven't
>>> already seen it, please see Todd's most recent update on the goals and
>>> status of GKI:
>>>
>>>   Article: https://tinyurl.com/saaen3sp
>>>   Video:   https://youtu.be/O_lCFGinFPM
>>>
>>
>> Side topic, why this patchset is in your scope or Will's/Google's scope?
>> Just drop it from Android main kernel, it will not be your problem. I
>> mean, really, you don't need this patchset in your tree at all. The only
>> platform which needs it, the only platform which will loose something
>> will be one specific vendor. Therefore this will be an incentive for
>> them to join both discussions and upstream development. :)
> 
> How would they fix this besides upstreaming support for unreleased
> work-in-progress H/W?
> 
> Haven't I explained this several times already? :)

Either that way or the same as Will's doing but that's not my question.
I understand you flush the queue of your GKI patches to be closer to
upstream. Reduce the backlog/burden. you can achieve your goal by simply
dropping such patch and making it not your problem. :)


Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:

> On 30/09/2021 14:39, Lee Jones wrote:
> > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > 
> >> On 30/09/2021 11:23, Lee Jones wrote:
> >>> [0] Full disclosure: part of my role at Linaro is to keep the Android
> >>> kernel running as close to Mainline as possible and encourage/push the
> >>> upstream-first mantra, hence my involvement with this and other sets.
> >>> I assure you all intentions are good and honourable.  If you haven't
> >>> already seen it, please see Todd's most recent update on the goals and
> >>> status of GKI:
> >>>
> >>>   Article: https://tinyurl.com/saaen3sp
> >>>   Video:   https://youtu.be/O_lCFGinFPM
> >>>
> >>
> >> Side topic, why this patchset is in your scope or Will's/Google's scope?
> >> Just drop it from Android main kernel, it will not be your problem. I
> >> mean, really, you don't need this patchset in your tree at all. The only
> >> platform which needs it, the only platform which will loose something
> >> will be one specific vendor. Therefore this will be an incentive for
> >> them to join both discussions and upstream development. :)
> > 
> > How would they fix this besides upstreaming support for unreleased
> > work-in-progress H/W?
> > 
> > Haven't I explained this several times already? :)
> 
> Either that way or the same as Will's doing but that's not my question.
> I understand you flush the queue of your GKI patches to be closer to
> upstream. Reduce the backlog/burden. you can achieve your goal by simply
> dropping such patch and making it not your problem. :)

git reset --hard mainline/master   # job done - tea break  :)

Seriously though, we wish to encourage the use of GKI so all vendors
can enjoy the benefits of more easily updateable/secure code-bases.

I can't see how pushing back on seamlessly benign changes would
benefit them or anyone else.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Lee,

On Thu, Sep 30, 2021 at 3:29 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > On 30/09/2021 14:39, Lee Jones wrote:
> > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > >> On 30/09/2021 11:23, Lee Jones wrote:
> > >>> [0] Full disclosure: part of my role at Linaro is to keep the Android
> > >>> kernel running as close to Mainline as possible and encourage/push the
> > >>> upstream-first mantra, hence my involvement with this and other sets.
> > >>> I assure you all intentions are good and honourable.  If you haven't
> > >>> already seen it, please see Todd's most recent update on the goals and
> > >>> status of GKI:
> > >>>
> > >>>   Article: https://tinyurl.com/saaen3sp
> > >>>   Video:   https://youtu.be/O_lCFGinFPM
> > >>>
> > >>
> > >> Side topic, why this patchset is in your scope or Will's/Google's scope?
> > >> Just drop it from Android main kernel, it will not be your problem. I
> > >> mean, really, you don't need this patchset in your tree at all. The only
> > >> platform which needs it, the only platform which will loose something
> > >> will be one specific vendor. Therefore this will be an incentive for
> > >> them to join both discussions and upstream development. :)
> > >
> > > How would they fix this besides upstreaming support for unreleased
> > > work-in-progress H/W?
> > >
> > > Haven't I explained this several times already? :)
> >
> > Either that way or the same as Will's doing but that's not my question.
> > I understand you flush the queue of your GKI patches to be closer to
> > upstream. Reduce the backlog/burden. you can achieve your goal by simply
> > dropping such patch and making it not your problem. :)
>
> git reset --hard mainline/master   # job done - tea break  :)
>
> Seriously though, we wish to encourage the use of GKI so all vendors
> can enjoy the benefits of more easily updateable/secure code-bases.
>
> I can't see how pushing back on seamlessly benign changes would
> benefit them or anyone else.

I like your wording ;-)

Indeed, seamlessly benign changes, which are (1) not tested, and (2)
some believed by the platform maintainer to break the platform.
What can possibly go wrong? ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:

> Hi Lee,
> 
> On Thu, Sep 30, 2021 at 3:29 PM Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > On 30/09/2021 14:39, Lee Jones wrote:
> > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > >> On 30/09/2021 11:23, Lee Jones wrote:
> > > >>> [0] Full disclosure: part of my role at Linaro is to keep the Android
> > > >>> kernel running as close to Mainline as possible and encourage/push the
> > > >>> upstream-first mantra, hence my involvement with this and other sets.
> > > >>> I assure you all intentions are good and honourable.  If you haven't
> > > >>> already seen it, please see Todd's most recent update on the goals and
> > > >>> status of GKI:
> > > >>>
> > > >>>   Article: https://tinyurl.com/saaen3sp
> > > >>>   Video:   https://youtu.be/O_lCFGinFPM
> > > >>>
> > > >>
> > > >> Side topic, why this patchset is in your scope or Will's/Google's scope?
> > > >> Just drop it from Android main kernel, it will not be your problem. I
> > > >> mean, really, you don't need this patchset in your tree at all. The only
> > > >> platform which needs it, the only platform which will loose something
> > > >> will be one specific vendor. Therefore this will be an incentive for
> > > >> them to join both discussions and upstream development. :)
> > > >
> > > > How would they fix this besides upstreaming support for unreleased
> > > > work-in-progress H/W?
> > > >
> > > > Haven't I explained this several times already? :)
> > >
> > > Either that way or the same as Will's doing but that's not my question.
> > > I understand you flush the queue of your GKI patches to be closer to
> > > upstream. Reduce the backlog/burden. you can achieve your goal by simply
> > > dropping such patch and making it not your problem. :)
> >
> > git reset --hard mainline/master   # job done - tea break  :)
> >
> > Seriously though, we wish to encourage the use of GKI so all vendors
> > can enjoy the benefits of more easily updateable/secure code-bases.
> >
> > I can't see how pushing back on seamlessly benign changes would
> > benefit them or anyone else.
> 
> I like your wording ;-)
> 
> Indeed, seamlessly benign changes, which are (1) not tested, and (2)
> some believed by the platform maintainer to break the platform.
> What can possibly go wrong? ;-)

William has already shown a willingness to test the series.

There is already a downstream proof-of-concept of this working.

I am hopeful. :)

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Lee,

On Thu, Sep 30, 2021 at 6:21 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > On Thu, Sep 30, 2021 at 3:29 PM Lee Jones <lee.jones@linaro.org> wrote:
> > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > On 30/09/2021 14:39, Lee Jones wrote:
> > > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > >> On 30/09/2021 11:23, Lee Jones wrote:
> > > > >>> [0] Full disclosure: part of my role at Linaro is to keep the Android
> > > > >>> kernel running as close to Mainline as possible and encourage/push the
> > > > >>> upstream-first mantra, hence my involvement with this and other sets.
> > > > >>> I assure you all intentions are good and honourable.  If you haven't
> > > > >>> already seen it, please see Todd's most recent update on the goals and
> > > > >>> status of GKI:
> > > > >>>
> > > > >>>   Article: https://tinyurl.com/saaen3sp
> > > > >>>   Video:   https://youtu.be/O_lCFGinFPM
> > > > >>>
> > > > >>
> > > > >> Side topic, why this patchset is in your scope or Will's/Google's scope?
> > > > >> Just drop it from Android main kernel, it will not be your problem. I
> > > > >> mean, really, you don't need this patchset in your tree at all. The only
> > > > >> platform which needs it, the only platform which will loose something
> > > > >> will be one specific vendor. Therefore this will be an incentive for
> > > > >> them to join both discussions and upstream development. :)
> > > > >
> > > > > How would they fix this besides upstreaming support for unreleased
> > > > > work-in-progress H/W?
> > > > >
> > > > > Haven't I explained this several times already? :)
> > > >
> > > > Either that way or the same as Will's doing but that's not my question.
> > > > I understand you flush the queue of your GKI patches to be closer to
> > > > upstream. Reduce the backlog/burden. you can achieve your goal by simply
> > > > dropping such patch and making it not your problem. :)
> > >
> > > git reset --hard mainline/master   # job done - tea break  :)
> > >
> > > Seriously though, we wish to encourage the use of GKI so all vendors
> > > can enjoy the benefits of more easily updateable/secure code-bases.
> > >
> > > I can't see how pushing back on seamlessly benign changes would
> > > benefit them or anyone else.
> >
> > I like your wording ;-)
> >
> > Indeed, seamlessly benign changes, which are (1) not tested, and (2)
> > some believed by the platform maintainer to break the platform.
> > What can possibly go wrong? ;-)
>
> William has already shown a willingness to test the series.

I'm looking forward to the results!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Will McVicker]

On Thu, Sep 30, 2021 at 9:26 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Lee,
>
> On Thu, Sep 30, 2021 at 6:21 PM Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 30 Sep 2021, Geert Uytterhoeven wrote:
> > > On Thu, Sep 30, 2021 at 3:29 PM Lee Jones <lee.jones@linaro.org> wrote:
> > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > > On 30/09/2021 14:39, Lee Jones wrote:
> > > > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote:
> > > > > >> On 30/09/2021 11:23, Lee Jones wrote:
> > > > > >>> [0] Full disclosure: part of my role at Linaro is to keep the Android
> > > > > >>> kernel running as close to Mainline as possible and encourage/push the
> > > > > >>> upstream-first mantra, hence my involvement with this and other sets.
> > > > > >>> I assure you all intentions are good and honourable.  If you haven't
> > > > > >>> already seen it, please see Todd's most recent update on the goals and
> > > > > >>> status of GKI:
> > > > > >>>
> > > > > >>>   Article: https://tinyurl.com/saaen3sp
> > > > > >>>   Video:   https://youtu.be/O_lCFGinFPM
> > > > > >>>
> > > > > >>
> > > > > >> Side topic, why this patchset is in your scope or Will's/Google's scope?
> > > > > >> Just drop it from Android main kernel, it will not be your problem. I
> > > > > >> mean, really, you don't need this patchset in your tree at all. The only
> > > > > >> platform which needs it, the only platform which will loose something
> > > > > >> will be one specific vendor. Therefore this will be an incentive for
> > > > > >> them to join both discussions and upstream development. :)
> > > > > >
> > > > > > How would they fix this besides upstreaming support for unreleased
> > > > > > work-in-progress H/W?
> > > > > >
> > > > > > Haven't I explained this several times already? :)
> > > > >
> > > > > Either that way or the same as Will's doing but that's not my question.
> > > > > I understand you flush the queue of your GKI patches to be closer to
> > > > > upstream. Reduce the backlog/burden. you can achieve your goal by simply
> > > > > dropping such patch and making it not your problem. :)
> > > >
> > > > git reset --hard mainline/master   # job done - tea break  :)
> > > >
> > > > Seriously though, we wish to encourage the use of GKI so all vendors
> > > > can enjoy the benefits of more easily updateable/secure code-bases.
> > > >
> > > > I can't see how pushing back on seamlessly benign changes would
> > > > benefit them or anyone else.
> > >
> > > I like your wording ;-)
> > >
> > > Indeed, seamlessly benign changes, which are (1) not tested, and (2)
> > > some believed by the platform maintainer to break the platform.
> > > What can possibly go wrong? ;-)
> >
> > William has already shown a willingness to test the series.
>
> I'm looking forward to the results!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Hi Krzysztof and Geert,

Thanks for all the responses! There are a few things I want to respond
to. Since this thread is 32 responses deep, I'm copying and pasting
the parts I'm responding to. I hope that isn't an issue.

>You are changing not default, but selectability which is part of the
>enforced configuration to make platforms working. The distros do not
>always choose defaults but rather all as modules.

I'm guessing you are referring to distros using the "allmodconfig". I
agree that this would affect their platforms in the sense that they
would get a module vs built-in, but obviously that is the choice they
are making by using "allmodconfig". I also agree that my changes
should not break any distros. I definitely don't want you or anyone
else to accept these without them being tested and verified.

>I don't understand the point (2) here. Anyone can use upstream kernel
>for supported and unsupported platforms. How upstream benefits from a
>change affecting supported platforms made for unsupported, downstream
>platforms.

We believe that if we make it easier for SoC vendors to directly use
the upstream kernel during bring-up and during the development stages
of their project, then that will decrease the friction of working with
upstream (less downstream changes) and increase the upstream
contributions. As mentioned in the LPC talk by Todd, the Android
kernel team is constantly pushing to reduce the number of out-of-tree
changes we carry so that we can ultimately use the upstream kernel
directly.

>You also mentioned downstream devices but without actually ever defining
>them. Please be more specific. What SoC, what hardware?

Saravana provided 2 platforms in his response. The first one is
hikey960 devboard and the second one is the Pixel 5 which uses the
Qualcomm sm7250 chipset. In particular the Pixel 5 is running a fully
modular kernel. It has 320+ modules including interrupt controllers,
timers, pinctrl and clocks.

To address your question regarding if Exynos is special? No, Exynos
isn't special. There is a long road ahead of us to get to where we'd
ultimately like to be and ARCH_EXYNOS happens to be along the way.
Currently, we are working through the arm64 ARCH_XXX configs that are
supported by Android to make sure that all drivers included by any
ARCH_XXX are modularized if they can be which benefits all parties.
From my understanding upstream does support modularizing drivers and
we can help with that. I believe this also kind of addresses Geert's
comments regarding what a generic kernel is. We look at it as a kernel
that only includes the absolutely necessary SoC drivers as built-in.
Obviously we can't go back and change older hardware like Cortex A9 to
support this, but we can do our best to support future SoCs.

Lastly, you mentioned a couple of times that we should just disable
ARCH_EXYNOS and move on. At the moment we are not able to do that
because some SoC specific drivers actually do need to be built-in to
the kernel (tainting it's generic-ness unfortunately) and are
protected by these ARCH_XXX configs. One example that you or Geert
pointed out is the early console serial driver which Greg did try to
decouple from ARCH_EXYNOS but was turned down. There are likely other
reasons as well that I don't know of off hand.

I hope Lee and I answered all your questions. Ultimately, I think we
all understand what is being debated here and it sounds like we all
agree that we are okay with modules as long as (1) they are proven to
work as both built-in and as modules and (2) can't be disabled if they
are required by the platform, but can be built-in or modular. Let me
know if I misunderstood that.

Regarding the testing, I will look around for a devboard that I can
test my clock driver changes on since those are the most contested
ones. I obviously am not going to be able to find all the HW variants
you mentioned, but I will try to find an ARM64 Exynos7 or Exynos5433
devboard since my patchset only modifies the clocks for these SoCs
which seem to be the most contested. Once I provide some testing
results, I'm hoping someone upstream can help verify that on the other
affected hardware. Of course this will take some time though.

In the meantime, I will try to push some of these easier patches that
don't need extensive testing, but are required before modularizing the
drivers.

Thanks,
Will

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Christoph Hellwig]

On Thu, Sep 30, 2021 at 01:39:35PM +0100, Lee Jones wrote:
> How would they fix this besides upstreaming support for unreleased
> work-in-progress H/W?
> 
> Haven't I explained this several times already? :)

No you haven't.  Mostly likely because there is absolutely no good
explanation.  And if google/Linaro think they want to create hooks
for stupid vendor modules we need to do whatever we can to make your
life as miserable as possible.

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Wed, Sep 29, 2021 at 12:48 PM Will McVicker <willmcvicker@google.com> wrote:
>
> On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
> >
> > On 29/09/2021 01:56, Will McVicker wrote:
> > > This is v2 of the series of patches that modularizes a number of core
> > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> > > modularized all of the drivers that are removed from the ARCH_EXYNOS
> > > series of "select XXX". This includes setting the following configs as
> > > tristate:
> > >
> > >  * COMMON_CLK_SAMSUNG
> > >  * EXYNOS_ARM64_COMMON_CLK
> > >  * PINCTRL_SAMSUNG
> > >  * PINCTRL_EXYNOS
> > >  * EXYNOS_PMU_ARM64
> > >  * EXYNOS_PM_DOMAINS
> > >
> > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> > > The reason for these new configs is because we are not able to easily
> > > modularize the ARMv7 PMU driver due to built-in arch dependencies on
> > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> > > the ARM and ARM64 portions into two separate configs.
> > >
> > > Overall, these drivers didn't require much refactoring and converted to
> > > modules relatively easily. However, due to my lack of exynos hardware, I
> > > was not able to boot test these changes. I'm mostly concerned about the
> > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> > > requesting help for testing these changes on the respective hardware.
> > >
> >
> > These are all not tested at all? In such case, since these are not
> > trivial changes, please mark the series as RFT.
> >
> > I will not be able to test these for some days, so it must wait.
> >
> >
> > Best regards,
> > Krzysztof
>
> +Cc Arnd and Olof,
>
> Hi Krzysztof,
>
> To avoid the scrambled conversation from the first patchset, I'm going
> to address all your general questions here in the cover letter thread
> so that it's easier for everyone to follow and reference in the
> future.

This patchset shouldn't go in.

GKI is a fantastic effort, since it finally seems like Google has the
backbone to put pressure on the vendors to upstream all their stuff.

This patcheset dilutes and undermines all of that by opening up a
truck-size loophole, reducing the impact of GKI, and overall removes
leverage to get vendors to do the right thing.

It's against our interest as a community to have this happen, since
there's no other reasonably justifiable reason to do this.


-Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Saravana Kannan]

On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson <olof@lixom.net> wrote:
>
> On Wed, Sep 29, 2021 at 12:48 PM Will McVicker <willmcvicker@google.com> wrote:
> >
> > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@canonical.com> wrote:
> > >
> > > On 29/09/2021 01:56, Will McVicker wrote:
> > > > This is v2 of the series of patches that modularizes a number of core
> > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> > > > modularized all of the drivers that are removed from the ARCH_EXYNOS
> > > > series of "select XXX". This includes setting the following configs as
> > > > tristate:
> > > >
> > > >  * COMMON_CLK_SAMSUNG
> > > >  * EXYNOS_ARM64_COMMON_CLK
> > > >  * PINCTRL_SAMSUNG
> > > >  * PINCTRL_EXYNOS
> > > >  * EXYNOS_PMU_ARM64
> > > >  * EXYNOS_PM_DOMAINS
> > > >
> > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> > > > The reason for these new configs is because we are not able to easily
> > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on
> > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> > > > the ARM and ARM64 portions into two separate configs.
> > > >
> > > > Overall, these drivers didn't require much refactoring and converted to
> > > > modules relatively easily. However, due to my lack of exynos hardware, I
> > > > was not able to boot test these changes. I'm mostly concerned about the
> > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> > > > requesting help for testing these changes on the respective hardware.
> > > >
> > >
> > > These are all not tested at all? In such case, since these are not
> > > trivial changes, please mark the series as RFT.
> > >
> > > I will not be able to test these for some days, so it must wait.
> > >
> > >
> > > Best regards,
> > > Krzysztof
> >
> > +Cc Arnd and Olof,
> >
> > Hi Krzysztof,
> >
> > To avoid the scrambled conversation from the first patchset, I'm going
> > to address all your general questions here in the cover letter thread
> > so that it's easier for everyone to follow and reference in the
> > future.
>
> This patchset shouldn't go in.
>
> GKI is a fantastic effort, since it finally seems like Google has the
> backbone to put pressure on the vendors to upstream all their stuff.
>
> This patcheset dilutes and undermines all of that by opening up a
> truck-size loophole, reducing the impact of GKI, and overall removes
> leverage to get vendors to do the right thing.
>
> It's against our interest as a community to have this happen, since
> there's no other reasonably justifiable reason to do this.

Oolf, Geert, Krzysztof, Arnd,

I skimmed through the emails and you all make a lot of good points. It
looks like you all at least like the idea of being able to have a
minimal generic kernel where everything that can be a module is a
module. Please correct me if I'm wrong on that.

I was thinking about this patch series and I was wondering if it'd be
good to come at it from the other end. Instead of taking the mostly
builtin generic kernel and trying to rip out drivers as modules (and
not having enough hardware to test them all) and hitting all these
issues, we could come at it from the other end.

A config like ARM64_MINIMAL_GENERIC_KERNEL that's off by default. But
if it's selected, all the "selects" done by the various ARCH_XXX are
not done any more. Something like:

ARCH_XXX
    select XXX_CLK1 if !ARM64_MINIMAL_GENERIC_KERNEL
    select XXX_PINCTRL1 if !ARM64_MINIMAL_GENERIC_KERNEL

ARCH_YYY
    select YYY_CLK1 if !ARM64_MINIMAL_GENERIC_KERNEL
    select YYY_PINCTRL1 if !ARM64_MINIMAL_GENERIC_KERNEL

And ARM64_MINIMAL_GENERIC_KERNEL itself would select the absolutely
mandatory stuff that can never be made into a module like the GIC,
architectured timer (as Geert mentioned) and UART early console
driver. I'm not sure if ARM32 has an equivalent to the standardized
GIC and arch timer. Basically the minimal kernel would need a timer
for the scheduler tick and IRQ controller to get the timer IRQ and the
fixed clock driver if the archtimer uses one to get its frequency and
the early UART console is pointless as a module (so build it in to
allow debugging/development).

And then all new drivers, we should make sure are implemented as
tristate drivers. And we can go back and slowly work on converting
existing drivers to modules (community effort -- not one person or
entity) -- at least the ones where the author has hardware or ones
where the change is very likely to be correct and someone else is
willing to test it. We'll never be able to support some/all ARM32 (do
they even have a GIC/arch timer standard?), but at least for ARM64,
this seems like a viable goal.

This way, we'll keep the existing model working, while working on a
fully modular kernel from the other end.

Thoughts?

-Saravana

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Thu, Sep 30, 2021 at 10:24 PM Saravana Kannan <saravanak@google.com> wrote:
>
> On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Wed, Sep 29, 2021 at 12:48 PM Will McVicker <willmcvicker@google.com> wrote:
> > >
> > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
> > > <krzysztof.kozlowski@canonical.com> wrote:
> > > >
> > > > On 29/09/2021 01:56, Will McVicker wrote:
> > > > > This is v2 of the series of patches that modularizes a number of core
> > > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> > > > > modularized all of the drivers that are removed from the ARCH_EXYNOS
> > > > > series of "select XXX". This includes setting the following configs as
> > > > > tristate:
> > > > >
> > > > >  * COMMON_CLK_SAMSUNG
> > > > >  * EXYNOS_ARM64_COMMON_CLK
> > > > >  * PINCTRL_SAMSUNG
> > > > >  * PINCTRL_EXYNOS
> > > > >  * EXYNOS_PMU_ARM64
> > > > >  * EXYNOS_PM_DOMAINS
> > > > >
> > > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> > > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> > > > > The reason for these new configs is because we are not able to easily
> > > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on
> > > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> > > > > the ARM and ARM64 portions into two separate configs.
> > > > >
> > > > > Overall, these drivers didn't require much refactoring and converted to
> > > > > modules relatively easily. However, due to my lack of exynos hardware, I
> > > > > was not able to boot test these changes. I'm mostly concerned about the
> > > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> > > > > requesting help for testing these changes on the respective hardware.
> > > > >
> > > >
> > > > These are all not tested at all? In such case, since these are not
> > > > trivial changes, please mark the series as RFT.
> > > >
> > > > I will not be able to test these for some days, so it must wait.
> > > >
> > > >
> > > > Best regards,
> > > > Krzysztof
> > >
> > > +Cc Arnd and Olof,
> > >
> > > Hi Krzysztof,
> > >
> > > To avoid the scrambled conversation from the first patchset, I'm going
> > > to address all your general questions here in the cover letter thread
> > > so that it's easier for everyone to follow and reference in the
> > > future.
> >
> > This patchset shouldn't go in.
> >
> > GKI is a fantastic effort, since it finally seems like Google has the
> > backbone to put pressure on the vendors to upstream all their stuff.
> >
> > This patcheset dilutes and undermines all of that by opening up a
> > truck-size loophole, reducing the impact of GKI, and overall removes
> > leverage to get vendors to do the right thing.
> >
> > It's against our interest as a community to have this happen, since
> > there's no other reasonably justifiable reason to do this.
>
> Oolf, Geert, Krzysztof, Arnd,

So close.

> I skimmed through the emails and you all make a lot of good points.

I skimmed through this email and I think it adds a lot of new
complexity and fragility to solve a problem that doesn't really exist
for upstream, adding yet more config parameter combinations to build
and test for.

A much more valuable approach would be to work towards being able to
free up memory by un-probed drivers at the end of boot. That would
possibly benefit all platforms on all architectures.


-Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Will McVicker]

On Thu, Sep 30, 2021 at 10:36 PM Olof Johansson <olof@lixom.net> wrote:
>
> On Thu, Sep 30, 2021 at 10:24 PM Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson <olof@lixom.net> wrote:
> > >
> > > On Wed, Sep 29, 2021 at 12:48 PM Will McVicker <willmcvicker@google.com> wrote:
> > > >
> > > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
> > > > <krzysztof.kozlowski@canonical.com> wrote:
> > > > >
> > > > > On 29/09/2021 01:56, Will McVicker wrote:
> > > > > > This is v2 of the series of patches that modularizes a number of core
> > > > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> > > > > > modularized all of the drivers that are removed from the ARCH_EXYNOS
> > > > > > series of "select XXX". This includes setting the following configs as
> > > > > > tristate:
> > > > > >
> > > > > >  * COMMON_CLK_SAMSUNG
> > > > > >  * EXYNOS_ARM64_COMMON_CLK
> > > > > >  * PINCTRL_SAMSUNG
> > > > > >  * PINCTRL_EXYNOS
> > > > > >  * EXYNOS_PMU_ARM64
> > > > > >  * EXYNOS_PM_DOMAINS
> > > > > >
> > > > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> > > > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> > > > > > The reason for these new configs is because we are not able to easily
> > > > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on
> > > > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> > > > > > the ARM and ARM64 portions into two separate configs.
> > > > > >
> > > > > > Overall, these drivers didn't require much refactoring and converted to
> > > > > > modules relatively easily. However, due to my lack of exynos hardware, I
> > > > > > was not able to boot test these changes. I'm mostly concerned about the
> > > > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> > > > > > requesting help for testing these changes on the respective hardware.
> > > > > >
> > > > >
> > > > > These are all not tested at all? In such case, since these are not
> > > > > trivial changes, please mark the series as RFT.
> > > > >
> > > > > I will not be able to test these for some days, so it must wait.
> > > > >
> > > > >
> > > > > Best regards,
> > > > > Krzysztof
> > > >
> > > > +Cc Arnd and Olof,
> > > >
> > > > Hi Krzysztof,
> > > >
> > > > To avoid the scrambled conversation from the first patchset, I'm going
> > > > to address all your general questions here in the cover letter thread
> > > > so that it's easier for everyone to follow and reference in the
> > > > future.
> > >
> > > This patchset shouldn't go in.
> > >
> > > GKI is a fantastic effort, since it finally seems like Google has the
> > > backbone to put pressure on the vendors to upstream all their stuff.
> > >
> > > This patcheset dilutes and undermines all of that by opening up a
> > > truck-size loophole, reducing the impact of GKI, and overall removes
> > > leverage to get vendors to do the right thing.
> > >
> > > It's against our interest as a community to have this happen, since
> > > there's no other reasonably justifiable reason to do this.

Are you saying that modularizing drivers is opening up a loophole? How
is this different from Krysztof pushing changes to modularize the
Exynos ChipId driver just last week [1].  I understand the push back
on "these aren't tested yet" and I agree that we should not merge them
until they are (I've re-iterated that multiple times and have
requested for testing help multiple times since I can't get my hands
on any Exynos arm64 hardware), but are you saying that if I gather the
test data to prove that these drivers can actually be made into
modules that you will still deny them out of the interest of the
community?

[1] https://lore.kernel.org/linux-samsung-soc/4aee1b0d-91a1-75ac-d2b7-6dab3d7a301f@kernel.org/T/#t

--Will

>
> >
> > Oolf, Geert, Krzysztof, Arnd,
>
> So close.
>
> > I skimmed through the emails and you all make a lot of good points.
>
> I skimmed through this email and I think it adds a lot of new
> complexity and fragility to solve a problem that doesn't really exist
> for upstream, adding yet more config parameter combinations to build
> and test for.
>
> A much more valuable approach would be to work towards being able to
> free up memory by un-probed drivers at the end of boot. That would
> possibly benefit all platforms on all architectures.
>
>
> -Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 01/10/2021 07:59, Will McVicker wrote:
> On Thu, Sep 30, 2021 at 10:36 PM Olof Johansson <olof@lixom.net> wrote:
>>
>>>>
>>>> GKI is a fantastic effort, since it finally seems like Google has the
>>>> backbone to put pressure on the vendors to upstream all their stuff.
>>>>
>>>> This patcheset dilutes and undermines all of that by opening up a
>>>> truck-size loophole, reducing the impact of GKI, and overall removes
>>>> leverage to get vendors to do the right thing.
>>>>
>>>> It's against our interest as a community to have this happen, since
>>>> there's no other reasonably justifiable reason to do this.
> 
> Are you saying that modularizing drivers is opening up a loophole? How
> is this different from Krysztof pushing changes to modularize the
> Exynos ChipId driver just last week [1].  

Modularizing drivers, which can work as modules or even can be disabled
because they are not essential for platform boot, is not opening
loophole and is helping upstream platforms. Modularizing everything,
even essential drivers, because downstream does not want to contribute
rest of its drivers, is not beneficial to the upstream project. Since
downstream does want to contribute its platforms and drivers, it decides
to change mainline project to fits its needs. Only its needs, not others.

I was repeating this multiple times - there is no point, no incentive
for the mainline to allow disabling essential SoC drivers. It's only
downstream interest without any benefit to the upstream.


Best regards,
Krzysztof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Saravana Kannan]

On Thu, Sep 30, 2021 at 10:36 PM Olof Johansson <olof@lixom.net> wrote:
>
> On Thu, Sep 30, 2021 at 10:24 PM Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson <olof@lixom.net> wrote:
> > >
> > > On Wed, Sep 29, 2021 at 12:48 PM Will McVicker <willmcvicker@google.com> wrote:
> > > >
> > > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
> > > > <krzysztof.kozlowski@canonical.com> wrote:
> > > > >
> > > > > On 29/09/2021 01:56, Will McVicker wrote:
> > > > > > This is v2 of the series of patches that modularizes a number of core
> > > > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> > > > > > modularized all of the drivers that are removed from the ARCH_EXYNOS
> > > > > > series of "select XXX". This includes setting the following configs as
> > > > > > tristate:
> > > > > >
> > > > > >  * COMMON_CLK_SAMSUNG
> > > > > >  * EXYNOS_ARM64_COMMON_CLK
> > > > > >  * PINCTRL_SAMSUNG
> > > > > >  * PINCTRL_EXYNOS
> > > > > >  * EXYNOS_PMU_ARM64
> > > > > >  * EXYNOS_PM_DOMAINS
> > > > > >
> > > > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> > > > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> > > > > > The reason for these new configs is because we are not able to easily
> > > > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on
> > > > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> > > > > > the ARM and ARM64 portions into two separate configs.
> > > > > >
> > > > > > Overall, these drivers didn't require much refactoring and converted to
> > > > > > modules relatively easily. However, due to my lack of exynos hardware, I
> > > > > > was not able to boot test these changes. I'm mostly concerned about the
> > > > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> > > > > > requesting help for testing these changes on the respective hardware.
> > > > > >
> > > > >
> > > > > These are all not tested at all? In such case, since these are not
> > > > > trivial changes, please mark the series as RFT.
> > > > >
> > > > > I will not be able to test these for some days, so it must wait.
> > > > >
> > > > >
> > > > > Best regards,
> > > > > Krzysztof
> > > >
> > > > +Cc Arnd and Olof,
> > > >
> > > > Hi Krzysztof,
> > > >
> > > > To avoid the scrambled conversation from the first patchset, I'm going
> > > > to address all your general questions here in the cover letter thread
> > > > so that it's easier for everyone to follow and reference in the
> > > > future.
> > >
> > > This patchset shouldn't go in.
> > >
> > > GKI is a fantastic effort, since it finally seems like Google has the
> > > backbone to put pressure on the vendors to upstream all their stuff.
> > >
> > > This patcheset dilutes and undermines all of that by opening up a
> > > truck-size loophole, reducing the impact of GKI, and overall removes
> > > leverage to get vendors to do the right thing.
> > >
> > > It's against our interest as a community to have this happen, since
> > > there's no other reasonably justifiable reason to do this.
> >
> > Oolf, Geert, Krzysztof, Arnd,
>
> So close.

I'm sorry, it's pretty late here and I'm sleepy and messed it up.

>
> > I skimmed through the emails and you all make a lot of good points.
>
> I skimmed through this email and I think it adds a lot of new
> complexity and fragility to solve a problem that doesn't really exist
> for upstream, adding yet more config parameter combinations to build
> and test for.

How is this not an upstream problem? Having a minimal kernel with as
many drivers as modules is of interest to upstream. And what's the
complexity in having a config to easily disable a bunch of configs?
The new config gives a clear config against which new
platforms/systems should be developed against.

>
> A much more valuable approach would be to work towards being able to
> free up memory by un-probed drivers at the end of boot. That would
> possibly benefit all platforms on all architectures.

Sure it would help memory after boot, but it won't help with size on
"disk", kernel load time, etc. And some of the devices have very tight
boot requirements. Think battery operated outdoor cameras for example.

-Saravana

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Thu, Sep 30, 2021 at 11:03 PM Saravana Kannan <saravanak@google.com> wrote:
>
> On Thu, Sep 30, 2021 at 10:36 PM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Thu, Sep 30, 2021 at 10:24 PM Saravana Kannan <saravanak@google.com> wrote:
> > >
> > > On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson <olof@lixom.net> wrote:
> > > >
> > > > On Wed, Sep 29, 2021 at 12:48 PM Will McVicker <willmcvicker@google.com> wrote:
> > > > >
> > > > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
> > > > > <krzysztof.kozlowski@canonical.com> wrote:
> > > > > >
> > > > > > On 29/09/2021 01:56, Will McVicker wrote:
> > > > > > > This is v2 of the series of patches that modularizes a number of core
> > > > > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> > > > > > > modularized all of the drivers that are removed from the ARCH_EXYNOS
> > > > > > > series of "select XXX". This includes setting the following configs as
> > > > > > > tristate:
> > > > > > >
> > > > > > >  * COMMON_CLK_SAMSUNG
> > > > > > >  * EXYNOS_ARM64_COMMON_CLK
> > > > > > >  * PINCTRL_SAMSUNG
> > > > > > >  * PINCTRL_EXYNOS
> > > > > > >  * EXYNOS_PMU_ARM64
> > > > > > >  * EXYNOS_PM_DOMAINS
> > > > > > >
> > > > > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> > > > > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> > > > > > > The reason for these new configs is because we are not able to easily
> > > > > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on
> > > > > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> > > > > > > the ARM and ARM64 portions into two separate configs.
> > > > > > >
> > > > > > > Overall, these drivers didn't require much refactoring and converted to
> > > > > > > modules relatively easily. However, due to my lack of exynos hardware, I
> > > > > > > was not able to boot test these changes. I'm mostly concerned about the
> > > > > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> > > > > > > requesting help for testing these changes on the respective hardware.
> > > > > > >
> > > > > >
> > > > > > These are all not tested at all? In such case, since these are not
> > > > > > trivial changes, please mark the series as RFT.
> > > > > >
> > > > > > I will not be able to test these for some days, so it must wait.
> > > > > >
> > > > > >
> > > > > > Best regards,
> > > > > > Krzysztof
> > > > >
> > > > > +Cc Arnd and Olof,
> > > > >
> > > > > Hi Krzysztof,
> > > > >
> > > > > To avoid the scrambled conversation from the first patchset, I'm going
> > > > > to address all your general questions here in the cover letter thread
> > > > > so that it's easier for everyone to follow and reference in the
> > > > > future.
> > > >
> > > > This patchset shouldn't go in.
> > > >
> > > > GKI is a fantastic effort, since it finally seems like Google has the
> > > > backbone to put pressure on the vendors to upstream all their stuff.
> > > >
> > > > This patcheset dilutes and undermines all of that by opening up a
> > > > truck-size loophole, reducing the impact of GKI, and overall removes
> > > > leverage to get vendors to do the right thing.
> > > >
> > > > It's against our interest as a community to have this happen, since
> > > > there's no other reasonably justifiable reason to do this.
> > >
> > > Oolf, Geert, Krzysztof, Arnd,
> >
> > So close.
>
> I'm sorry, it's pretty late here and I'm sleepy and messed it up.

This email thread will be here in the morning too, this is the last
reply I will make tonight myself.

> > > I skimmed through the emails and you all make a lot of good points.
> >
> > I skimmed through this email and I think it adds a lot of new
> > complexity and fragility to solve a problem that doesn't really exist
> > for upstream, adding yet more config parameter combinations to build
> > and test for.
>
> How is this not an upstream problem? Having a minimal kernel with as
> many drivers as modules is of interest to upstream. And what's the
> complexity in having a config to easily disable a bunch of configs?
> The new config gives a clear config against which new
> platforms/systems should be developed against.

The approach for general kernel upstream has been to have the built-in
drivers needed to reach rootfs and runtime load the rest from there.
For downstream embedded kernels, the right answer is to just exclude
the drivers you don't need.

I agree, some of this is probably useful work but
1) It was posted as a burden on the maintainers of the legacy
platforms to test and make sure it's not broken
2) It regresses distro configs, which we do care about
3) Based on the above, it's unclear whether the people pushing for
this patchset cares about the existing platforms, they're looking to
solve a different problem

I didn't go back and look at who and where, but the person who started
justifying this work with making it easier for out-of-tree vendors to
integrate their non-contributed code killed this patchset.

Would the out-of-tree argument on its own kill it? No, but the above
complexities/cost, plus the actual intent behind the patchset did.

> > A much more valuable approach would be to work towards being able to
> > free up memory by un-probed drivers at the end of boot. That would
> > possibly benefit all platforms on all architectures.
>
> Sure it would help memory after boot, but it won't help with size on
> "disk", kernel load time, etc. And some of the devices have very tight
> boot requirements. Think battery operated outdoor cameras for example.

I would question the choices made if someone ships a camera with a
generic kernel (without a generic filesystem which at that point also
needs sufficient storage such that the kernel image size becomes a
secondary consideration). Once your storage is that constrained the
balance shifts towards a custom minimal config.


-Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Thu, Sep 30, 2021 at 11:27 PM Olof Johansson <olof@lixom.net> wrote:
>
> On Thu, Sep 30, 2021 at 11:03 PM Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Thu, Sep 30, 2021 at 10:36 PM Olof Johansson <olof@lixom.net> wrote:
> > >
> > > On Thu, Sep 30, 2021 at 10:24 PM Saravana Kannan <saravanak@google.com> wrote:
> > > >
> > > > On Thu, Sep 30, 2021 at 9:52 PM Olof Johansson <olof@lixom.net> wrote:
> > > > >
> > > > > On Wed, Sep 29, 2021 at 12:48 PM Will McVicker <willmcvicker@google.com> wrote:
> > > > > >
> > > > > > On Wed, Sep 29, 2021 at 6:02 AM Krzysztof Kozlowski
> > > > > > <krzysztof.kozlowski@canonical.com> wrote:
> > > > > > >
> > > > > > > On 29/09/2021 01:56, Will McVicker wrote:
> > > > > > > > This is v2 of the series of patches that modularizes a number of core
> > > > > > > > ARCH_EXYNOS drivers. Based off of the feedback from the v1 series, I have
> > > > > > > > modularized all of the drivers that are removed from the ARCH_EXYNOS
> > > > > > > > series of "select XXX". This includes setting the following configs as
> > > > > > > > tristate:
> > > > > > > >
> > > > > > > >  * COMMON_CLK_SAMSUNG
> > > > > > > >  * EXYNOS_ARM64_COMMON_CLK
> > > > > > > >  * PINCTRL_SAMSUNG
> > > > > > > >  * PINCTRL_EXYNOS
> > > > > > > >  * EXYNOS_PMU_ARM64
> > > > > > > >  * EXYNOS_PM_DOMAINS
> > > > > > > >
> > > > > > > > Additionally, it introduces the config EXYNOS_PMU_ARM64 and EXYNOS_PMU_ARM
> > > > > > > > which was previously EXYNOS_PMU and EXYNOS_PMU_ARM_DRIVERS respectively.
> > > > > > > > The reason for these new configs is because we are not able to easily
> > > > > > > > modularize the ARMv7 PMU driver due to built-in arch dependencies on
> > > > > > > > pmu_base_addr under arch/arm/mach-exynos/*. So the new configs split up
> > > > > > > > the ARM and ARM64 portions into two separate configs.
> > > > > > > >
> > > > > > > > Overall, these drivers didn't require much refactoring and converted to
> > > > > > > > modules relatively easily. However, due to my lack of exynos hardware, I
> > > > > > > > was not able to boot test these changes. I'm mostly concerned about the
> > > > > > > > CLK_OF_DECLARE() changes having dependencies on early timers. So I'm
> > > > > > > > requesting help for testing these changes on the respective hardware.
> > > > > > > >
> > > > > > >
> > > > > > > These are all not tested at all? In such case, since these are not
> > > > > > > trivial changes, please mark the series as RFT.
> > > > > > >
> > > > > > > I will not be able to test these for some days, so it must wait.
> > > > > > >
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Krzysztof
> > > > > >
> > > > > > +Cc Arnd and Olof,
> > > > > >
> > > > > > Hi Krzysztof,
> > > > > >
> > > > > > To avoid the scrambled conversation from the first patchset, I'm going
> > > > > > to address all your general questions here in the cover letter thread
> > > > > > so that it's easier for everyone to follow and reference in the
> > > > > > future.
> > > > >
> > > > > This patchset shouldn't go in.
> > > > >
> > > > > GKI is a fantastic effort, since it finally seems like Google has the
> > > > > backbone to put pressure on the vendors to upstream all their stuff.
> > > > >
> > > > > This patcheset dilutes and undermines all of that by opening up a
> > > > > truck-size loophole, reducing the impact of GKI, and overall removes
> > > > > leverage to get vendors to do the right thing.
> > > > >
> > > > > It's against our interest as a community to have this happen, since
> > > > > there's no other reasonably justifiable reason to do this.
> > > >
> > > > Oolf, Geert, Krzysztof, Arnd,
> > >
> > > So close.
> >
> > I'm sorry, it's pretty late here and I'm sleepy and messed it up.
>
> This email thread will be here in the morning too, this is the last
> reply I will make tonight myself.
>
> > > > I skimmed through the emails and you all make a lot of good points.
> > >
> > > I skimmed through this email and I think it adds a lot of new
> > > complexity and fragility to solve a problem that doesn't really exist
> > > for upstream, adding yet more config parameter combinations to build
> > > and test for.
> >
> > How is this not an upstream problem? Having a minimal kernel with as
> > many drivers as modules is of interest to upstream. And what's the
> > complexity in having a config to easily disable a bunch of configs?
> > The new config gives a clear config against which new
> > platforms/systems should be developed against.
>
> The approach for general kernel upstream has been to have the built-in
> drivers needed to reach rootfs and runtime load the rest from there.

Correction: The intent for our own multiconfigs have been this. If
people want to go more granular and allow for modules of their core
drivers, we have never pushed back (but the rest of the argument still
stands).

> For downstream embedded kernels, the right answer is to just exclude
> the drivers you don't need.
>
> I agree, some of this is probably useful work but
> 1) It was posted as a burden on the maintainers of the legacy
> platforms to test and make sure it's not broken
> 2) It regresses distro configs, which we do care about
> 3) Based on the above, it's unclear whether the people pushing for
> this patchset cares about the existing platforms, they're looking to
> solve a different problem
>
> I didn't go back and look at who and where, but the person who started
> justifying this work with making it easier for out-of-tree vendors to
> integrate their non-contributed code killed this patchset.
>
> Would the out-of-tree argument on its own kill it? No, but the above
> complexities/cost, plus the actual intent behind the patchset did.
>
> > > A much more valuable approach would be to work towards being able to
> > > free up memory by un-probed drivers at the end of boot. That would
> > > possibly benefit all platforms on all architectures.
> >
> > Sure it would help memory after boot, but it won't help with size on
> > "disk", kernel load time, etc. And some of the devices have very tight
> > boot requirements. Think battery operated outdoor cameras for example.
>
> I would question the choices made if someone ships a camera with a
> generic kernel (without a generic filesystem which at that point also
> needs sufficient storage such that the kernel image size becomes a
> secondary consideration). Once your storage is that constrained the
> balance shifts towards a custom minimal config.
>
>
> -Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Arnd Bergmann]

On Fri, Oct 1, 2021 at 8:02 AM Saravana Kannan <saravanak@google.com> wrote:

> > A much more valuable approach would be to work towards being able to
> > free up memory by un-probed drivers at the end of boot. That would
> > possibly benefit all platforms on all architectures.
>
> Sure it would help memory after boot, but it won't help with size on
> "disk", kernel load time, etc. And some of the devices have very tight
> boot requirements. Think battery operated outdoor cameras for example.

I think we can draw a clear line (or several lines) between devices that boot
from strictly constrained NOR flash and those that run a platform-independent
kernel.

Also, when I look at a distro kernel, I see over 5000 kernel modules that
need to be stored on disk, but only a small fraction of those are platform
specific while most are for general-purpose pluggable devices, network
features or file systems that could be used on any system.

The vmlinux file is clearly too big and includes too much stuff that should
be in loadable modules, but I'm not really that worried about disk space
for the platform specific code.

         Arnd

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Fri, 01 Oct 2021, Arnd Bergmann wrote:
> The vmlinux file is clearly too big and includes too much stuff that should
> be in loadable modules

This for me is the crux of the matter.

The ability to replace modules was only brought to light as an "and
also, this is possible".  However in retrospect, given the attention
this has received, it probably shouldn't have even mentioned, as it's
not that important.

We should focus on the benefits of making parts of the kernel modular
if technically possible.  The most prominent of those is core binary
size, since this has a direct impact on boot-time and RAM usage.

Reclaiming dead code after boot is certainly one way to tackle part of
the problem.  Ensuring that it's not even loaded into RAM in the first
place is a better more encompassing solution to both issues IMHO.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Fri, Oct 1, 2021 at 5:31 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Fri, 01 Oct 2021, Arnd Bergmann wrote:
> > The vmlinux file is clearly too big and includes too much stuff that should
> > be in loadable modules
>
> This for me is the crux of the matter.
>
> The ability to replace modules was only brought to light as an "and
> also, this is possible".  However in retrospect, given the attention
> this has received, it probably shouldn't have even mentioned, as it's
> not that important.

Too late, unfortunately.

I would actually argue that given the benefit of needing more vendor
engagement upstream for GKI to be smooth, it's in our interest to
welcome those engagements and make the most of it and help vendors get
there, and it's against those interests to make it easier to be
out-of-tree if it comes at the expense of our in-tree users and
maintainers which this does.

> We should focus on the benefits of making parts of the kernel modular
> if technically possible.  The most prominent of those is core binary
> size, since this has a direct impact on boot-time and RAM usage.

The way forward here should be to focus on the problem that needs to
be solved (vmlinux size) and not overly fixate on whether this
patchset is what needs to be merged to reach there, given the
downsides observed. I'm not saying let's not improve vmlinux binary
size, but this particular approach isn't appealing.

> Reclaiming dead code after boot is certainly one way to tackle part of
> the problem.  Ensuring that it's not even loaded into RAM in the first
> place is a better more encompassing solution to both issues IMHO.

See my reply to Arnd; the reason some of these drivers aren't modules
today is because they are needed during early boot to bring the
platform to a stable operating point. Work on fixing the binary size
is terrific, but this approach seems to be shortsighted and it's been
done in a way that rubs the maintainers the wrong way.


-Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Linus Walleij]

On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson <olof@lixom.net> wrote:

> A much more valuable approach would be to work towards being able to
> free up memory by un-probed drivers at the end of boot. That would
> possibly benefit all platforms on all architectures.

This would be really neat.

Also the ages-old problem of discarding unreferenced strings which
apparently still isn't possible would be great to have solved. E.g.
to couple strings to the file/module it belongs with and discard them
if the code is not probed.

Yours,
Linus Walleij

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Olof,

On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson <olof@lixom.net> wrote:
> A much more valuable approach would be to work towards being able to
> free up memory by un-probed drivers at the end of boot. That would
> possibly benefit all platforms on all architectures.

We used to have such a functionality in arch/ppc (not arch/powerpc!),
where code/data could be tagged __prep, __chrp, or __pmac, to put it
in a special section, and to be freed with initdata when unused.  It
was removed in v2.6.15[1], as the savings weren't worth the hassle.
In a more fragmented space like arm the memory lost due to alignment
of the sections would be even more substantial.

Another problem is to know when is the end of the boot, especially
with deferred probing.

[1] 6c45ab992e4299c8 ("[PATCH] powerpc: Remove section free() and
linker script bits")

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Olof,
>
> On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson <olof@lixom.net> wrote:
> > A much more valuable approach would be to work towards being able to
> > free up memory by un-probed drivers at the end of boot. That would
> > possibly benefit all platforms on all architectures.
>
> We used to have such a functionality in arch/ppc (not arch/powerpc!),
> where code/data could be tagged __prep, __chrp, or __pmac, to put it
> in a special section, and to be freed with initdata when unused.  It
> was removed in v2.6.15[1], as the savings weren't worth the hassle.
> In a more fragmented space like arm the memory lost due to alignment
> of the sections would be even more substantial.

Yeah, the balance between per-platform code size and overall kernel
code size shifted over time to a point where it wasn't as meaningful
on ppc.

> Another problem is to know when is the end of the boot, especially
> with deferred probing.

Most of this code either has a module_init() or an initcall that
actually registers the drivers and/or probes for the platform and does
the work.

This means you can have a late equivalent hook/initcall that
determines whether this path ended up being probed/used. If it wasn't,
you can then unregister and flag the corresponding memory to be freed
at the end, and would take out the heuristics and guessing on needing
to do it automatically from the code path that's doing said freeing.


-Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Will McVicker]

On Fri, Oct 1, 2021 at 9:00 AM Olof Johansson <olof@lixom.net> wrote:
>
> On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > Hi Olof,
> >
> > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson <olof@lixom.net> wrote:
> > > A much more valuable approach would be to work towards being able to
> > > free up memory by un-probed drivers at the end of boot. That would
> > > possibly benefit all platforms on all architectures.
> >
> > We used to have such a functionality in arch/ppc (not arch/powerpc!),
> > where code/data could be tagged __prep, __chrp, or __pmac, to put it
> > in a special section, and to be freed with initdata when unused.  It
> > was removed in v2.6.15[1], as the savings weren't worth the hassle.
> > In a more fragmented space like arm the memory lost due to alignment
> > of the sections would be even more substantial.
>
> Yeah, the balance between per-platform code size and overall kernel
> code size shifted over time to a point where it wasn't as meaningful
> on ppc.
>
> > Another problem is to know when is the end of the boot, especially
> > with deferred probing.
>
> Most of this code either has a module_init() or an initcall that
> actually registers the drivers and/or probes for the platform and does
> the work.
>
> This means you can have a late equivalent hook/initcall that
> determines whether this path ended up being probed/used. If it wasn't,
> you can then unregister and flag the corresponding memory to be freed
> at the end, and would take out the heuristics and guessing on needing
> to do it automatically from the code path that's doing said freeing.
>
>
> -Olof

First off, I appreciate the constructive conversations and I
understand the ask here. So I'd like to close the "we don't want this"
and "this isn't possible" conversation. We have already proven
downstream that it is in fact possible to modularize these drivers on
other SoCs (mentioned earlier if you missed it) and I'd like to direct
the conversation towards verifying/testing here instead of negatively
arguing about how SoC vendors aren't upstreaming their drivers. I
think everyone understands that, but unfortunately I have no control
over that even though I would love everyone to work upstream directly.

I am fine with forcing these drivers to always be enabled in some form
upstream even though it doesn't really make much sense for a generic
kernel that will run on Qualcomm, Exynos, Mediatek, (you name it) SoC
devices. I thought about how to do this yesterday and wasn't able to
come up with a proper solution that didn't always force this driver to
be a module when CONFIG_MODULES is enabled.

For example, if I do this below, then we will be forcing all builds to
use CONFIG_XXX as a module if they want just one driver as a module.

config XXX
  tristate "blah blah" if COMPILE_TEST
  default m if (ARCH_XXX && MODULES)
  default ARCH_XXX

The best I was able to come up with was this below which would allow
the driver to be a module or built-in; however, obviously it lets you
disable it in EXPERT mode.

config XXX
  tristate "blah blah" if COMPILE_TEST || EXPERT
  default ARCH_XXX

Let me know if you have a better solution that doesn't force the
driver to be a module when CONFIG_MODULES=y. Saravana did propose a
MINIMUM_ARM64_GENERIC_KERNEL config that could solve this, but that
too was shot down.

Thanks,
Will

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Fri, Oct 1, 2021 at 9:51 AM Will McVicker <willmcvicker@google.com> wrote:
>
> On Fri, Oct 1, 2021 at 9:00 AM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >
> > > Hi Olof,
> > >
> > > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson <olof@lixom.net> wrote:
> > > > A much more valuable approach would be to work towards being able to
> > > > free up memory by un-probed drivers at the end of boot. That would
> > > > possibly benefit all platforms on all architectures.
> > >
> > > We used to have such a functionality in arch/ppc (not arch/powerpc!),
> > > where code/data could be tagged __prep, __chrp, or __pmac, to put it
> > > in a special section, and to be freed with initdata when unused.  It
> > > was removed in v2.6.15[1], as the savings weren't worth the hassle.
> > > In a more fragmented space like arm the memory lost due to alignment
> > > of the sections would be even more substantial.
> >
> > Yeah, the balance between per-platform code size and overall kernel
> > code size shifted over time to a point where it wasn't as meaningful
> > on ppc.
> >
> > > Another problem is to know when is the end of the boot, especially
> > > with deferred probing.
> >
> > Most of this code either has a module_init() or an initcall that
> > actually registers the drivers and/or probes for the platform and does
> > the work.
> >
> > This means you can have a late equivalent hook/initcall that
> > determines whether this path ended up being probed/used. If it wasn't,
> > you can then unregister and flag the corresponding memory to be freed
> > at the end, and would take out the heuristics and guessing on needing
> > to do it automatically from the code path that's doing said freeing.
> >
> >
> > -Olof
>
> First off, I appreciate the constructive conversations and I
> understand the ask here. So I'd like to close the "we don't want this"
> and "this isn't possible" conversation. We have already proven
> downstream that it is in fact possible to modularize these drivers on
> other SoCs (mentioned earlier if you missed it) and I'd like to direct
> the conversation towards verifying/testing here instead of negatively
> arguing about how SoC vendors aren't upstreaming their drivers. I
> think everyone understands that, but unfortunately I have no control
> over that even though I would love everyone to work upstream directly.
>
> I am fine with forcing these drivers to always be enabled in some form
> upstream even though it doesn't really make much sense for a generic
> kernel that will run on Qualcomm, Exynos, Mediatek, (you name it) SoC
> devices. I thought about how to do this yesterday and wasn't able to
> come up with a proper solution that didn't always force this driver to
> be a module when CONFIG_MODULES is enabled.

This line of reasoning: "I couldn't think of a better option" made us
merge a userspace ABI some time ago that within a few months was
replaced with a better solution. In that case it was the kernel
headers bundling with a build (extending the vmlinux size by a lot),
that seemed to have no concerns about binary growth. Not all that far
after that went in, the BPF folks came up with a solid solution for
CO-RE by introducing BTF, etc.

So, the argument "I can't think of a better solution" is a local
maxima that we shouldn't settle for if there's a likely better global
maxima available with a bit more time/effort. If we say "this problem
is worth solving but this doesn't seem to be the solution we want to
go for" we might actually be better off long-term.


-Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Will McVicker]

On Fri, Oct 1, 2021 at 10:16 AM Olof Johansson <olof@lixom.net> wrote:
>
> On Fri, Oct 1, 2021 at 9:51 AM Will McVicker <willmcvicker@google.com> wrote:
> >
> > On Fri, Oct 1, 2021 at 9:00 AM Olof Johansson <olof@lixom.net> wrote:
> > >
> > > On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > >
> > > > Hi Olof,
> > > >
> > > > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson <olof@lixom.net> wrote:
> > > > > A much more valuable approach would be to work towards being able to
> > > > > free up memory by un-probed drivers at the end of boot. That would
> > > > > possibly benefit all platforms on all architectures.
> > > >
> > > > We used to have such a functionality in arch/ppc (not arch/powerpc!),
> > > > where code/data could be tagged __prep, __chrp, or __pmac, to put it
> > > > in a special section, and to be freed with initdata when unused.  It
> > > > was removed in v2.6.15[1], as the savings weren't worth the hassle.
> > > > In a more fragmented space like arm the memory lost due to alignment
> > > > of the sections would be even more substantial.
> > >
> > > Yeah, the balance between per-platform code size and overall kernel
> > > code size shifted over time to a point where it wasn't as meaningful
> > > on ppc.
> > >
> > > > Another problem is to know when is the end of the boot, especially
> > > > with deferred probing.
> > >
> > > Most of this code either has a module_init() or an initcall that
> > > actually registers the drivers and/or probes for the platform and does
> > > the work.
> > >
> > > This means you can have a late equivalent hook/initcall that
> > > determines whether this path ended up being probed/used. If it wasn't,
> > > you can then unregister and flag the corresponding memory to be freed
> > > at the end, and would take out the heuristics and guessing on needing
> > > to do it automatically from the code path that's doing said freeing.
> > >
> > >
> > > -Olof
> >
> > First off, I appreciate the constructive conversations and I
> > understand the ask here. So I'd like to close the "we don't want this"
> > and "this isn't possible" conversation. We have already proven
> > downstream that it is in fact possible to modularize these drivers on
> > other SoCs (mentioned earlier if you missed it) and I'd like to direct
> > the conversation towards verifying/testing here instead of negatively
> > arguing about how SoC vendors aren't upstreaming their drivers. I
> > think everyone understands that, but unfortunately I have no control
> > over that even though I would love everyone to work upstream directly.
> >
> > I am fine with forcing these drivers to always be enabled in some form
> > upstream even though it doesn't really make much sense for a generic
> > kernel that will run on Qualcomm, Exynos, Mediatek, (you name it) SoC
> > devices. I thought about how to do this yesterday and wasn't able to
> > come up with a proper solution that didn't always force this driver to
> > be a module when CONFIG_MODULES is enabled.
>
> This line of reasoning: "I couldn't think of a better option" made us
> merge a userspace ABI some time ago that within a few months was
> replaced with a better solution. In that case it was the kernel
> headers bundling with a build (extending the vmlinux size by a lot),
> that seemed to have no concerns about binary growth. Not all that far
> after that went in, the BPF folks came up with a solid solution for
> CO-RE by introducing BTF, etc.
>
> So, the argument "I can't think of a better solution" is a local
> maxima that we shouldn't settle for if there's a likely better global
> maxima available with a bit more time/effort. If we say "this problem
> is worth solving but this doesn't seem to be the solution we want to
> go for" we might actually be better off long-term.
>
>
> -Olof

If the answer is, "we don't have a solution for that" then that's
fine. I'm not an expert at Kconfig configurations and am asking if
there is already a way to handle this. To me it sounded like there
might be a solution already due to this policy of "we don't allow
disabling drivers that are essential." I'll wait for Krysztof to
respond (or someone who has a potential solution) before I dig into
this deeper.

--Will

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Saravana,

On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@google.com> wrote:
> I skimmed through the emails and you all make a lot of good points. It
> looks like you all at least like the idea of being able to have a
> minimal generic kernel where everything that can be a module is a
> module. Please correct me if I'm wrong on that.
>
> I was thinking about this patch series and I was wondering if it'd be
> good to come at it from the other end. Instead of taking the mostly
> builtin generic kernel and trying to rip out drivers as modules (and
> not having enough hardware to test them all) and hitting all these
> issues, we could come at it from the other end.
>
> A config like ARM64_MINIMAL_GENERIC_KERNEL that's off by default. But
> if it's selected, all the "selects" done by the various ARCH_XXX are
> not done any more. Something like:
>
> ARCH_XXX
>     select XXX_CLK1 if !ARM64_MINIMAL_GENERIC_KERNEL
>     select XXX_PINCTRL1 if !ARM64_MINIMAL_GENERIC_KERNEL
>
> ARCH_YYY
>     select YYY_CLK1 if !ARM64_MINIMAL_GENERIC_KERNEL
>     select YYY_PINCTRL1 if !ARM64_MINIMAL_GENERIC_KERNEL
>
> And ARM64_MINIMAL_GENERIC_KERNEL itself would select the absolutely
> mandatory stuff that can never be made into a module like the GIC,
> architectured timer (as Geert mentioned) and UART early console
> driver. I'm not sure if ARM32 has an equivalent to the standardized

While the UART early console can work (assuming the related hardware
setup has been done by the boot loader), the actual serial driver
usually cannot, as it relies on clocks, PM Domains, pin control, which
won't be available until the corresponding modular drivers are loaded.
Actually earlycon is a debug feature, so I'm wondering if you actually
want that in your GKI kernel?

> GIC and arch timer. Basically the minimal kernel would need a timer
> for the scheduler tick and IRQ controller to get the timer IRQ and the
> fixed clock driver if the archtimer uses one to get its frequency and
> the early UART console is pointless as a module (so build it in to
> allow debugging/development).
>
> And then all new drivers, we should make sure are implemented as
> tristate drivers. And we can go back and slowly work on converting
> existing drivers to modules (community effort -- not one person or
> entity) -- at least the ones where the author has hardware or ones
> where the change is very likely to be correct and someone else is
> willing to test it. We'll never be able to support some/all ARM32 (do
> they even have a GIC/arch timer standard?), but at least for ARM64,
> this seems like a viable goal.

Cortex-A7/A15 and later have GIC and architectured timer, so it should
work for contemporary systems.
Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
seen SoCs where the interrupt for the latter was not wired :-(.

What are the plans for other architectures?
I've seen similar patches being applied for e.g. MIPS.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Arnd Bergmann]

On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@google.com> wrote:
> > GIC and arch timer. Basically the minimal kernel would need a timer
> > for the scheduler tick and IRQ controller to get the timer IRQ and the
> > fixed clock driver if the archtimer uses one to get its frequency and
> > the early UART console is pointless as a module (so build it in to
> > allow debugging/development).
> >
> > And then all new drivers, we should make sure are implemented as
> > tristate drivers. And we can go back and slowly work on converting
> > existing drivers to modules (community effort -- not one person or
> > entity) -- at least the ones where the author has hardware or ones
> > where the change is very likely to be correct and someone else is
> > willing to test it. We'll never be able to support some/all ARM32 (do
> > they even have a GIC/arch timer standard?), but at least for ARM64,
> > this seems like a viable goal.
>
> Cortex-A7/A15 and later have GIC and architectured timer, so it should
> work for contemporary systems.
> Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
> seen SoCs where the interrupt for the latter was not wired :-(.

There are a number of well-known examples even with 64-bit chips or
Cortex-A7/A15 based SoCs that can't use the architected timer,
irqchip or iommu.

Apple M1, Broadcom BCM283x, Samsung Exynos5 and
some Hisilicon server parts come to mind, I'm sure there
are more.

> What are the plans for other architectures?
> I've seen similar patches being applied for e.g. MIPS.

There is some work in the more actively maintained MIPS
platforms to make those behave more like Arm/powerpc/riscv/m68k
platforms, using a single image and moving drivers into modules.
Most MIPS platforms seem unlikely to get updated to this,
and will continue to require a SoC specific kernel binary forever,
similar to the renesas superh platforms. Most of the less
common architectures (arc, csky, hexagon, nios2, xtensa,
microblaze, nds32, openrisc, sparc/leon) are way behind that
though, and generally don't work at all without out-of-tree
code.

      Arnd

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@google.com> wrote:
> > > GIC and arch timer. Basically the minimal kernel would need a timer
> > > for the scheduler tick and IRQ controller to get the timer IRQ and the
> > > fixed clock driver if the archtimer uses one to get its frequency and
> > > the early UART console is pointless as a module (so build it in to
> > > allow debugging/development).
> > >
> > > And then all new drivers, we should make sure are implemented as
> > > tristate drivers. And we can go back and slowly work on converting
> > > existing drivers to modules (community effort -- not one person or
> > > entity) -- at least the ones where the author has hardware or ones
> > > where the change is very likely to be correct and someone else is
> > > willing to test it. We'll never be able to support some/all ARM32 (do
> > > they even have a GIC/arch timer standard?), but at least for ARM64,
> > > this seems like a viable goal.
> >
> > Cortex-A7/A15 and later have GIC and architectured timer, so it should
> > work for contemporary systems.
> > Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
> > seen SoCs where the interrupt for the latter was not wired :-(.
>
> There are a number of well-known examples even with 64-bit chips or
> Cortex-A7/A15 based SoCs that can't use the architected timer,
> irqchip or iommu.
>
> Apple M1, Broadcom BCM283x, Samsung Exynos5 and
> some Hisilicon server parts come to mind, I'm sure there
> are more.

There's also more and more movement towards having coprocessors with
standardized interfaces dealing with this functionality. We're
currently at the point where they have coprocessors with
non-standardized interfaces, and it's useful to keep encouraging
convergence in this area to everybody's benefit. I don't find it
particularly useful to make life easier for the custom solutions at
the expense of others like this patchset does, when that's (just
beyond? on?) the horizon.

> > What are the plans for other architectures?
> > I've seen similar patches being applied for e.g. MIPS.
>
> There is some work in the more actively maintained MIPS
> platforms to make those behave more like Arm/powerpc/riscv/m68k
> platforms, using a single image and moving drivers into modules.
> Most MIPS platforms seem unlikely to get updated to this,
> and will continue to require a SoC specific kernel binary forever,
> similar to the renesas superh platforms. Most of the less
> common architectures (arc, csky, hexagon, nios2, xtensa,
> microblaze, nds32, openrisc, sparc/leon) are way behind that
> though, and generally don't work at all without out-of-tree
> code.

One of the arguments for needing some of these core drivers in-kernel
is that some platforms boot at very conservative DVFS operating
points, to a degree that you really want to turn up the CPU clocks
fairly early during boot.

If you don't have the drivers built-in, you can't do that and/or you
create possible fragile or awkward inter-module dependencies with
deferred probing, etc. We do care about boot time enough to prefer to
just build them in for this reason.

If vmlinux binary size is a concern, maybe it's time to consider
splitting the drivers into a bare-minimum piece that's not a module
for early setup, and the rest that can be loaded post-boot.


-Olof

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Saravana Kannan]

On Fri, Oct 1, 2021 at 8:27 AM Olof Johansson <olof@lixom.net> wrote:
>
> On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@google.com> wrote:
> > > > GIC and arch timer. Basically the minimal kernel would need a timer
> > > > for the scheduler tick and IRQ controller to get the timer IRQ and the
> > > > fixed clock driver if the archtimer uses one to get its frequency and
> > > > the early UART console is pointless as a module (so build it in to
> > > > allow debugging/development).
> > > >
> > > > And then all new drivers, we should make sure are implemented as
> > > > tristate drivers. And we can go back and slowly work on converting
> > > > existing drivers to modules (community effort -- not one person or
> > > > entity) -- at least the ones where the author has hardware or ones
> > > > where the change is very likely to be correct and someone else is
> > > > willing to test it. We'll never be able to support some/all ARM32 (do
> > > > they even have a GIC/arch timer standard?), but at least for ARM64,
> > > > this seems like a viable goal.
> > >
> > > Cortex-A7/A15 and later have GIC and architectured timer, so it should
> > > work for contemporary systems.
> > > Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
> > > seen SoCs where the interrupt for the latter was not wired :-(.
> >
> > There are a number of well-known examples even with 64-bit chips or
> > Cortex-A7/A15 based SoCs that can't use the architected timer,
> > irqchip or iommu.
> >
> > Apple M1, Broadcom BCM283x, Samsung Exynos5 and
> > some Hisilicon server parts come to mind, I'm sure there
> > are more.
>
> There's also more and more movement towards having coprocessors with
> standardized interfaces dealing with this functionality. We're
> currently at the point where they have coprocessors with
> non-standardized interfaces, and it's useful to keep encouraging
> convergence in this area to everybody's benefit. I don't find it
> particularly useful to make life easier for the custom solutions at
> the expense of others like this patchset does, when that's (just
> beyond? on?) the horizon.
>
> > > What are the plans for other architectures?
> > > I've seen similar patches being applied for e.g. MIPS.
> >
> > There is some work in the more actively maintained MIPS
> > platforms to make those behave more like Arm/powerpc/riscv/m68k
> > platforms, using a single image and moving drivers into modules.
> > Most MIPS platforms seem unlikely to get updated to this,
> > and will continue to require a SoC specific kernel binary forever,
> > similar to the renesas superh platforms. Most of the less
> > common architectures (arc, csky, hexagon, nios2, xtensa,
> > microblaze, nds32, openrisc, sparc/leon) are way behind that
> > though, and generally don't work at all without out-of-tree
> > code.
>
> One of the arguments for needing some of these core drivers in-kernel
> is that some platforms boot at very conservative DVFS operating
> points, to a degree that you really want to turn up the CPU clocks
> fairly early during boot.
>
> If you don't have the drivers built-in, you can't do that and/or you
> create possible fragile or awkward inter-module dependencies with
> deferred probing, etc. We do care about boot time enough to prefer to
> just build them in for this reason.

Go look at a Pixel 5, we got this working just fine with all these
drivers as modules and we definitely care about boot time. You just
need to load your CPU freq driver and the other ones it needs early
on. And with fw_devlink=on (default in upstream), there's hardly any
deferred probing.

> If vmlinux binary size is a concern, maybe it's time to consider
> splitting the drivers into a bare-minimum piece that's not a module
> for early setup, and the rest that can be loaded post-boot.

Isn't this literally what I was suggesting with my
ARM64_MINIMAL_GENERIC_KERNEL suggestion? Build in all the bare minimum
drivers that are needed before module loading can happen? You'd just
select them all under that config. And any existing platform that
wants to use it would break up their drivers into modules and switch
to it.

-Saravana

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Tomasz Figa]

2021年10月2日(土) 4:26 Saravana Kannan <saravanak@google.com>:
>
> On Fri, Oct 1, 2021 at 8:27 AM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@google.com> wrote:
> > > > > GIC and arch timer. Basically the minimal kernel would need a timer
> > > > > for the scheduler tick and IRQ controller to get the timer IRQ and the
> > > > > fixed clock driver if the archtimer uses one to get its frequency and
> > > > > the early UART console is pointless as a module (so build it in to
> > > > > allow debugging/development).
> > > > >
> > > > > And then all new drivers, we should make sure are implemented as
> > > > > tristate drivers. And we can go back and slowly work on converting
> > > > > existing drivers to modules (community effort -- not one person or
> > > > > entity) -- at least the ones where the author has hardware or ones
> > > > > where the change is very likely to be correct and someone else is
> > > > > willing to test it. We'll never be able to support some/all ARM32 (do
> > > > > they even have a GIC/arch timer standard?), but at least for ARM64,
> > > > > this seems like a viable goal.
> > > >
> > > > Cortex-A7/A15 and later have GIC and architectured timer, so it should
> > > > work for contemporary systems.
> > > > Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
> > > > seen SoCs where the interrupt for the latter was not wired :-(.
> > >
> > > There are a number of well-known examples even with 64-bit chips or
> > > Cortex-A7/A15 based SoCs that can't use the architected timer,
> > > irqchip or iommu.
> > >
> > > Apple M1, Broadcom BCM283x, Samsung Exynos5 and
> > > some Hisilicon server parts come to mind, I'm sure there
> > > are more.
> >
> > There's also more and more movement towards having coprocessors with
> > standardized interfaces dealing with this functionality. We're
> > currently at the point where they have coprocessors with
> > non-standardized interfaces, and it's useful to keep encouraging
> > convergence in this area to everybody's benefit. I don't find it
> > particularly useful to make life easier for the custom solutions at
> > the expense of others like this patchset does, when that's (just
> > beyond? on?) the horizon.
> >
> > > > What are the plans for other architectures?
> > > > I've seen similar patches being applied for e.g. MIPS.
> > >
> > > There is some work in the more actively maintained MIPS
> > > platforms to make those behave more like Arm/powerpc/riscv/m68k
> > > platforms, using a single image and moving drivers into modules.
> > > Most MIPS platforms seem unlikely to get updated to this,
> > > and will continue to require a SoC specific kernel binary forever,
> > > similar to the renesas superh platforms. Most of the less
> > > common architectures (arc, csky, hexagon, nios2, xtensa,
> > > microblaze, nds32, openrisc, sparc/leon) are way behind that
> > > though, and generally don't work at all without out-of-tree
> > > code.
> >
> > One of the arguments for needing some of these core drivers in-kernel
> > is that some platforms boot at very conservative DVFS operating
> > points, to a degree that you really want to turn up the CPU clocks
> > fairly early during boot.
> >
> > If you don't have the drivers built-in, you can't do that and/or you
> > create possible fragile or awkward inter-module dependencies with
> > deferred probing, etc. We do care about boot time enough to prefer to
> > just build them in for this reason.
>
> Go look at a Pixel 5, we got this working just fine with all these
> drivers as modules and we definitely care about boot time. You just
> need to load your CPU freq driver and the other ones it needs early
> on. And with fw_devlink=on (default in upstream), there's hardly any
> deferred probing.
>
> > If vmlinux binary size is a concern, maybe it's time to consider
> > splitting the drivers into a bare-minimum piece that's not a module
> > for early setup, and the rest that can be loaded post-boot.
>
> Isn't this literally what I was suggesting with my
> ARM64_MINIMAL_GENERIC_KERNEL suggestion? Build in all the bare minimum
> drivers that are needed before module loading can happen? You'd just
> select them all under that config. And any existing platform that
> wants to use it would break up their drivers into modules and switch
> to it.

I think the point here is that pinctrl and clk are considered a part
of "bare minimum" for Exynos.

Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Olof Johansson]

On Fri, Oct 1, 2021 at 12:26 PM Saravana Kannan <saravanak@google.com> wrote:
>
> On Fri, Oct 1, 2021 at 8:27 AM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@google.com> wrote:
> > > > > GIC and arch timer. Basically the minimal kernel would need a timer
> > > > > for the scheduler tick and IRQ controller to get the timer IRQ and the
> > > > > fixed clock driver if the archtimer uses one to get its frequency and
> > > > > the early UART console is pointless as a module (so build it in to
> > > > > allow debugging/development).
> > > > >
> > > > > And then all new drivers, we should make sure are implemented as
> > > > > tristate drivers. And we can go back and slowly work on converting
> > > > > existing drivers to modules (community effort -- not one person or
> > > > > entity) -- at least the ones where the author has hardware or ones
> > > > > where the change is very likely to be correct and someone else is
> > > > > willing to test it. We'll never be able to support some/all ARM32 (do
> > > > > they even have a GIC/arch timer standard?), but at least for ARM64,
> > > > > this seems like a viable goal.
> > > >
> > > > Cortex-A7/A15 and later have GIC and architectured timer, so it should
> > > > work for contemporary systems.
> > > > Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
> > > > seen SoCs where the interrupt for the latter was not wired :-(.
> > >
> > > There are a number of well-known examples even with 64-bit chips or
> > > Cortex-A7/A15 based SoCs that can't use the architected timer,
> > > irqchip or iommu.
> > >
> > > Apple M1, Broadcom BCM283x, Samsung Exynos5 and
> > > some Hisilicon server parts come to mind, I'm sure there
> > > are more.
> >
> > There's also more and more movement towards having coprocessors with
> > standardized interfaces dealing with this functionality. We're
> > currently at the point where they have coprocessors with
> > non-standardized interfaces, and it's useful to keep encouraging
> > convergence in this area to everybody's benefit. I don't find it
> > particularly useful to make life easier for the custom solutions at
> > the expense of others like this patchset does, when that's (just
> > beyond? on?) the horizon.
> >
> > > > What are the plans for other architectures?
> > > > I've seen similar patches being applied for e.g. MIPS.
> > >
> > > There is some work in the more actively maintained MIPS
> > > platforms to make those behave more like Arm/powerpc/riscv/m68k
> > > platforms, using a single image and moving drivers into modules.
> > > Most MIPS platforms seem unlikely to get updated to this,
> > > and will continue to require a SoC specific kernel binary forever,
> > > similar to the renesas superh platforms. Most of the less
> > > common architectures (arc, csky, hexagon, nios2, xtensa,
> > > microblaze, nds32, openrisc, sparc/leon) are way behind that
> > > though, and generally don't work at all without out-of-tree
> > > code.
> >
> > One of the arguments for needing some of these core drivers in-kernel
> > is that some platforms boot at very conservative DVFS operating
> > points, to a degree that you really want to turn up the CPU clocks
> > fairly early during boot.
> >
> > If you don't have the drivers built-in, you can't do that and/or you
> > create possible fragile or awkward inter-module dependencies with
> > deferred probing, etc. We do care about boot time enough to prefer to
> > just build them in for this reason.
>
> Go look at a Pixel 5, we got this working just fine with all these
> drivers as modules and we definitely care about boot time. You just
> need to load your CPU freq driver and the other ones it needs early
> on. And with fw_devlink=on (default in upstream), there's hardly any
> deferred probing.

Unfortunately these problems are usually easier to fix on new
platforms, especially during new product development. The hard part is
making sure you haven't regressed any of the legacy platforms when
you're changing the implementation for them as well.


> > If vmlinux binary size is a concern, maybe it's time to consider
> > splitting the drivers into a bare-minimum piece that's not a module
> > for early setup, and the rest that can be loaded post-boot.
>
> Isn't this literally what I was suggesting with my
> ARM64_MINIMAL_GENERIC_KERNEL suggestion? Build in all the bare minimum
> drivers that are needed before module loading can happen? You'd just
> select them all under that config. And any existing platform that
> wants to use it would break up their drivers into modules and switch
> to it.

Do you understand the implications of your proposal on the complexity
for those who care about making sure different config combinations
keep building and working, i.e. both the minimal-generic-kernel and
the regular generic version? You've doubled the testing workload for
all of those folks. It's a different mindset from when you mostly need
to care about your one config and platform.


-Olof