[PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Will McVicker]

This patch series tries to address the issue of ARCH_EXYNOS force selecting
a handful of drivers without allowing the vendor to override any of the
default configs. This takes away from the flexibilty of compiling a generic
kernel with exynos kernel modules. For example, it doesn't allow vendors to
modularize these drivers out of the core kernel in order to share a generic
kernel image across multiple devices that require device-specific kernel
modules.

To address this without impacting the existing behavior, this series
switches the default config logic for the offending configs to use "default
y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select them. I have
verified that these patches do not impact the default aarch64 .config.

Will McVicker (4):
  clk: samsung: change COMMON_CLK_SAMSUNG default config logic
  soc: samsung: change SOC_SAMSUNG default config logic
  pinctrl: samsung: change PINCTRL_EXYNOS default config logic
  rtc: change HAVE_S3C_RTC default config logic

 arch/arm64/Kconfig.platforms    | 7 -------
 drivers/clk/samsung/Kconfig     | 1 +
 drivers/pinctrl/samsung/Kconfig | 1 +
 drivers/rtc/Kconfig             | 1 +
 drivers/soc/samsung/Kconfig     | 4 ++++
 5 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.33.0.464.g1972c5931b-goog

[PATCH v1 4/4] rtc: change HAVE_S3C_RTC default config logic

[Will McVicker]

Switches the default config logic of HAVE_S3C_RTC to use "default y if
(ARCH_EXYNOS && RTC_CLASS)" versus having ARCH_EXYNOS directly select
it. This provides vendors flexibility to disable the config if desired
or modularize it in the presence of a generic kernel.

Verified this change doesn't impact the .config.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm64/Kconfig.platforms | 1 -
 drivers/rtc/Kconfig          | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index a884e5da8b0f..f9f829aab511 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
 	help
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e1bc5214494e..40afdb37d2a5 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1406,6 +1406,7 @@ config RTC_DRV_OMAP
 
 config HAVE_S3C_RTC
 	bool
+	default y if (ARCH_EXYNOS && RTC_CLASS)
 	help
 	  This will include RTC support for Samsung SoCs. If
 	  you want to include RTC support for any machine, kindly
-- 
2.33.0.464.g1972c5931b-goog

Re: [PATCH v1 4/4] rtc: change HAVE_S3C_RTC default config logic

[Alexandre Belloni]

On 20/09/2021 19:03:49+0000, Will McVicker wrote:
> Switches the default config logic of HAVE_S3C_RTC to use "default y if
> (ARCH_EXYNOS && RTC_CLASS)" versus having ARCH_EXYNOS directly select
> it. This provides vendors flexibility to disable the config if desired
> or modularize it in the presence of a generic kernel.
> 
> Verified this change doesn't impact the .config.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

> ---
>  arch/arm64/Kconfig.platforms | 1 -
>  drivers/rtc/Kconfig          | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index a884e5da8b0f..f9f829aab511 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
>  	help
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index e1bc5214494e..40afdb37d2a5 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1406,6 +1406,7 @@ config RTC_DRV_OMAP
>  
>  config HAVE_S3C_RTC
>  	bool
> +	default y if (ARCH_EXYNOS && RTC_CLASS)
>  	help
>  	  This will include RTC support for Samsung SoCs. If
>  	  you want to include RTC support for any machine, kindly
> -- 
> 2.33.0.464.g1972c5931b-goog
> 

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

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Mon, 20 Sep 2021, Will McVicker wrote:

> This patch series tries to address the issue of ARCH_EXYNOS force selecting
> a handful of drivers without allowing the vendor to override any of the
> default configs. This takes away from the flexibilty of compiling a generic
> kernel with exynos kernel modules. For example, it doesn't allow vendors to
> modularize these drivers out of the core kernel in order to share a generic
> kernel image across multiple devices that require device-specific kernel
> modules.
> 
> To address this without impacting the existing behavior, this series
> switches the default config logic for the offending configs to use "default
> y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select them. I have
> verified that these patches do not impact the default aarch64 .config.
> 
> Will McVicker (4):
>   clk: samsung: change COMMON_CLK_SAMSUNG default config logic
>   soc: samsung: change SOC_SAMSUNG default config logic
>   pinctrl: samsung: change PINCTRL_EXYNOS default config logic
>   rtc: change HAVE_S3C_RTC default config logic
> 
>  arch/arm64/Kconfig.platforms    | 7 -------
>  drivers/clk/samsung/Kconfig     | 1 +
>  drivers/pinctrl/samsung/Kconfig | 1 +
>  drivers/rtc/Kconfig             | 1 +
>  drivers/soc/samsung/Kconfig     | 4 ++++
>  5 files changed, 7 insertions(+), 7 deletions(-)

For all patches in the series:

Reviewed-by: Lee Jones <lee.jones@linaro.org>

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

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 20/09/2021 21:03, Will McVicker wrote:
> This patch series tries to address the issue of ARCH_EXYNOS force selecting
> a handful of drivers without allowing the vendor to override any of the
> default configs. This takes away from the flexibilty of compiling a generic
> kernel with exynos kernel modules. For example, it doesn't allow vendors to
> modularize these drivers out of the core kernel in order to share a generic
> kernel image across multiple devices that require device-specific kernel
> modules.

You do not address the issue in these patches. The problem you describe
is that drivers are not modules and you are not changing them into modules.

> 
> To address this without impacting the existing behavior, this series
> switches the default config logic for the offending configs to use "default
> y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select them. I have
> verified that these patches do not impact the default aarch64 .config.

Yep, this is what you did but it does not match the described problem.
You are not solving it but doing something else.

> 
> Will McVicker (4):
>   clk: samsung: change COMMON_CLK_SAMSUNG default config logic
>   soc: samsung: change SOC_SAMSUNG default config logic
>   pinctrl: samsung: change PINCTRL_EXYNOS default config logic
>   rtc: change HAVE_S3C_RTC default config logic
> 


I received only two patches from this set. Please resend following
get_maintainers.pl script.


Best regards,
Krzysztof

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 21/09/2021 09:19, Krzysztof Kozlowski wrote:
> On 20/09/2021 21:03, Will McVicker wrote:
>> This patch series tries to address the issue of ARCH_EXYNOS force selecting
>> a handful of drivers without allowing the vendor to override any of the
>> default configs. This takes away from the flexibilty of compiling a generic
>> kernel with exynos kernel modules. For example, it doesn't allow vendors to
>> modularize these drivers out of the core kernel in order to share a generic
>> kernel image across multiple devices that require device-specific kernel
>> modules.
> 
> You do not address the issue in these patches. The problem you describe
> is that drivers are not modules and you are not changing them into modules.
> 
>>
>> To address this without impacting the existing behavior, this series
>> switches the default config logic for the offending configs to use "default
>> y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select them. I have
>> verified that these patches do not impact the default aarch64 .config.
> 
> Yep, this is what you did but it does not match the described problem.
> You are not solving it but doing something else.
> 
>>
>> Will McVicker (4):
>>   clk: samsung: change COMMON_CLK_SAMSUNG default config logic
>>   soc: samsung: change SOC_SAMSUNG default config logic
>>   pinctrl: samsung: change PINCTRL_EXYNOS default config logic
>>   rtc: change HAVE_S3C_RTC default config logic
>>
> 
> 
> I received only two patches from this set. Please resend following
> get_maintainers.pl script.

For the record - samsung-soc list also did not get all your patches.

NAK, please use get_maintainers.pl.

Best regards,
Krzysztof

Re: [PATCH v1 4/4] rtc: change HAVE_S3C_RTC default config logic

[Krzysztof Kozlowski]

On 20/09/2021 21:03, Will McVicker wrote:
> Switches the default config logic of HAVE_S3C_RTC to use "default y if
> (ARCH_EXYNOS && RTC_CLASS)" versus having ARCH_EXYNOS directly select
> it. This provides vendors flexibility to disable the config if desired
> or modularize it in the presence of a generic kernel.
> 
> Verified this change doesn't impact the .config.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms | 1 -
>  drivers/rtc/Kconfig          | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 

It took me some effort to find this patch because you did not send it to
neither me, nor Samsung SoC list.

Since you touch arm64 code, this should go either via SoC tree or with
SoC ack, therefore you should simply use get_maintainers.pl on entire
patchset, not on some pieces.

> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index a884e5da8b0f..f9f829aab511 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

Just remove HAVE_S3C_RTC entirely like in commit:
7dd3cae90d856e97e93bc1c32904e5aed7210f7b

>  	select PINCTRL
>  	select PM_GENERIC_DOMAINS if PM
>  	help
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index e1bc5214494e..40afdb37d2a5 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1406,6 +1406,7 @@ config RTC_DRV_OMAP
>  
>  config HAVE_S3C_RTC
>  	bool
> +	default y if (ARCH_EXYNOS && RTC_CLASS)
>  	help
>  	  This will include RTC support for Samsung SoCs. If
>  	  you want to include RTC support for any machine, kindly
> 


Best regards,
Krzysztof

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 20/09/2021 21:03, Will McVicker wrote:
> > This patch series tries to address the issue of ARCH_EXYNOS force selecting
> > a handful of drivers without allowing the vendor to override any of the
> > default configs. This takes away from the flexibilty of compiling a generic
> > kernel with exynos kernel modules. For example, it doesn't allow vendors to
> > modularize these drivers out of the core kernel in order to share a generic
> > kernel image across multiple devices that require device-specific kernel
> > modules.
> 
> You do not address the issue in these patches. The problem you describe
> is that drivers are not modules and you are not changing them into modules.

The wording is unfortunate.  The reason for this change doesn't have
much to do with kernel modules.

Let's go back in time 18 months or so when Greg KH submitted this [0]
patch, which you Acked.  Greg was trying to solve the problem of not
having to enable ARCH_EXYNOS on kernels which are designed to be
platform agnostic (sometimes called Generic Kernels).  For some reason
SERIAL_SAMSUNG is the only symbol with these dependencies, so the
solution seemed simple and straight forward at the time.

However, For sound reasons Geert NACKed the patch.

Quoting from [1] he says:

  "A generic kernel will include Samsung SoC support, hence
  PLAT_SAMSUNG or ARCH_EXYNOS will be enabled."

However, since the entry for ARCH_EXYNOS *insists* on building-in a
bunch of other symbols (via 'select') which will be unused in most
cases, this is not a currently acceptable approach for many Generic
Kernels due to size constraints.

What this patch does is migrates those symbols from being 'select'ed
(always built-in with no recourse) to 'default y'.  Where the former
cannot be over-ridden, but the latter can be via a vendor's
defconfig/fragment.

I doubt many (any?) of these symbols can be converted to kernel
modules anyway, as they are required very early on in the boot
sequence.

> > To address this without impacting the existing behavior, this series
> > switches the default config logic for the offending configs to use "default
> > y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select them. I have
> > verified that these patches do not impact the default aarch64 .config.
> 
> Yep, this is what you did but it does not match the described problem.
> You are not solving it but doing something else.
> 
> > Will McVicker (4):
> >   clk: samsung: change COMMON_CLK_SAMSUNG default config logic
> >   soc: samsung: change SOC_SAMSUNG default config logic
> >   pinctrl: samsung: change PINCTRL_EXYNOS default config logic
> >   rtc: change HAVE_S3C_RTC default config logic

[0] https://lore.kernel.org/lkml/20200220102628.3371996-1-gregkh@linuxfoundation.org/
[1] https://lore.kernel.org/lkml/CAMuHMdVrVe37JyUNFSf9KRZTcndrvDaZvrVoBxzm_7J2nhg1kg@mail.gmail.com/

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

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 21/09/2021 10:11, Lee Jones wrote:
> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> 
>> On 20/09/2021 21:03, Will McVicker wrote:
>>> This patch series tries to address the issue of ARCH_EXYNOS force selecting
>>> a handful of drivers without allowing the vendor to override any of the
>>> default configs. This takes away from the flexibilty of compiling a generic
>>> kernel with exynos kernel modules. For example, it doesn't allow vendors to
>>> modularize these drivers out of the core kernel in order to share a generic
>>> kernel image across multiple devices that require device-specific kernel
>>> modules.
>>
>> You do not address the issue in these patches. The problem you describe
>> is that drivers are not modules and you are not changing them into modules.
> 
> The wording is unfortunate.  The reason for this change doesn't have
> much to do with kernel modules.
> 
> Let's go back in time 18 months or so when Greg KH submitted this [0]
> patch, which you Acked.  Greg was trying to solve the problem of not
> having to enable ARCH_EXYNOS on kernels which are designed to be
> platform agnostic (sometimes called Generic Kernels).  For some reason
> SERIAL_SAMSUNG is the only symbol with these dependencies, so the
> solution seemed simple and straight forward at the time.
> 
> However, For sound reasons Geert NACKed the patch.
> 
> Quoting from [1] he says:
> 
>   "A generic kernel will include Samsung SoC support, hence
>   PLAT_SAMSUNG or ARCH_EXYNOS will be enabled."

Yes, it's correct reasoning. There is also one more use-case -
non-upstreamed (out of tree) platform which wants to use Exynos-specific
drivers. Something like was happening with Apple M1 except that it got
upstreamed and we do not care much about out-of-tree.

> 
> However, since the entry for ARCH_EXYNOS *insists* on building-in a
> bunch of other symbols (via 'select') which will be unused in most
> cases, this is not a currently acceptable approach for many Generic
> Kernels due to size constraints.

In the mainline kernel there is no such use case. If you want to have
Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should
select ARCH_EXYNOS because otherwise it does not make any sense. Zero
sense. Such kernel won't work.

It makes sense only if there is some other work, hidden here, where
someone might want to have SERIAL_SAMSUNG or S3C RTC without
ARCH_EXYNOS. Although GKI is not that work because GKI kernel will
select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support
Exynos platforms.

Therefore I expect first to bring this "some other work, hidden here" to
broader audience, so we can review its use case.

> 
> What this patch does is migrates those symbols from being 'select'ed
> (always built-in with no recourse) to 'default y'.  Where the former
> cannot be over-ridden, but the latter can be via a vendor's
> defconfig/fragment.

It cannot be overridden by vendor fragment because options are not
visible. You cannot change them.

The patch does nothing in this regard (making them selectable/possible
to disable), which is why I complained.

> 
> I doubt many (any?) of these symbols can be converted to kernel
> modules anyway, as they are required very early on in the boot
> sequence.

True, some could, some not. Also some platforms are set up via
bootloader, so actually could "survive" till module is loaded from some
initrd.


Best regards,
Krzysztof

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 21/09/2021 10:11, Lee Jones wrote:
> > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> > 
> >> On 20/09/2021 21:03, Will McVicker wrote:
> >>> This patch series tries to address the issue of ARCH_EXYNOS force selecting
> >>> a handful of drivers without allowing the vendor to override any of the
> >>> default configs. This takes away from the flexibilty of compiling a generic
> >>> kernel with exynos kernel modules. For example, it doesn't allow vendors to
> >>> modularize these drivers out of the core kernel in order to share a generic
> >>> kernel image across multiple devices that require device-specific kernel
> >>> modules.
> >>
> >> You do not address the issue in these patches. The problem you describe
> >> is that drivers are not modules and you are not changing them into modules.
> > 
> > The wording is unfortunate.  The reason for this change doesn't have
> > much to do with kernel modules.
> > 
> > Let's go back in time 18 months or so when Greg KH submitted this [0]
> > patch, which you Acked.  Greg was trying to solve the problem of not
> > having to enable ARCH_EXYNOS on kernels which are designed to be
> > platform agnostic (sometimes called Generic Kernels).  For some reason
> > SERIAL_SAMSUNG is the only symbol with these dependencies, so the
> > solution seemed simple and straight forward at the time.
> > 
> > However, For sound reasons Geert NACKed the patch.
> > 
> > Quoting from [1] he says:
> > 
> >   "A generic kernel will include Samsung SoC support, hence
> >   PLAT_SAMSUNG or ARCH_EXYNOS will be enabled."
> 
> Yes, it's correct reasoning. There is also one more use-case -
> non-upstreamed (out of tree) platform which wants to use Exynos-specific
> drivers. Something like was happening with Apple M1 except that it got
> upstreamed and we do not care much about out-of-tree.
> 
> > However, since the entry for ARCH_EXYNOS *insists* on building-in a
> > bunch of other symbols (via 'select') which will be unused in most
> > cases, this is not a currently acceptable approach for many Generic
> > Kernels due to size constraints.
> 
> In the mainline kernel there is no such use case. If you want to have
> Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should
> select ARCH_EXYNOS because otherwise it does not make any sense. Zero
> sense. Such kernel won't work.
> 
> It makes sense only if there is some other work, hidden here, where
> someone might want to have SERIAL_SAMSUNG or S3C RTC without
> ARCH_EXYNOS. Although GKI is not that work because GKI kernel will
> select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support
> Exynos platforms.
> 
> Therefore I expect first to bring this "some other work, hidden here" to
> broader audience, so we can review its use case.

AFAIA, there really isn't any GKI specific code.  Everything that can
be upstreamed, is upstreamed.  The delta consists of some vendor
over-rides (implemented using trace events/hooks spread out over the
code-base), lots of function exports (non-upstreamable due to no
upstream user) and some defconfig/fragments.  There really is nothing
else to share/upstream/unhide.

The only thing GKI needs is a little Kconfig flexibility above what is
currently offered.

> > What this patch does is migrates those symbols from being 'select'ed
> > (always built-in with no recourse) to 'default y'.  Where the former
> > cannot be over-ridden, but the latter can be via a vendor's
> > defconfig/fragment.
> 
> It cannot be overridden by vendor fragment because options are not
> visible. You cannot change them.
> 
> The patch does nothing in this regard (making them selectable/possible
> to disable), which is why I complained.

100% agree.  As I commented in the other patch, this was a good point
that should be addressed 

> > I doubt many (any?) of these symbols can be converted to kernel
> > modules anyway, as they are required very early on in the boot
> > sequence.
> 
> True, some could, some not. Also some platforms are set up via
> bootloader, so actually could "survive" till module is loaded from some
> initrd.

If these could be turned into modules, that would be even better!

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

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Saravana Kannan]

On Tue, Sep 21, 2021 at 1:25 AM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
>
> On 21/09/2021 10:11, Lee Jones wrote:
> > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> >
> >> On 20/09/2021 21:03, Will McVicker wrote:
> >>> This patch series tries to address the issue of ARCH_EXYNOS force selecting
> >>> a handful of drivers without allowing the vendor to override any of the
> >>> default configs. This takes away from the flexibilty of compiling a generic
> >>> kernel with exynos kernel modules. For example, it doesn't allow vendors to
> >>> modularize these drivers out of the core kernel in order to share a generic
> >>> kernel image across multiple devices that require device-specific kernel
> >>> modules.
> >>
> >> You do not address the issue in these patches. The problem you describe
> >> is that drivers are not modules and you are not changing them into modules.
> >
> > The wording is unfortunate.  The reason for this change doesn't have
> > much to do with kernel modules.
> >
> > Let's go back in time 18 months or so when Greg KH submitted this [0]
> > patch, which you Acked.  Greg was trying to solve the problem of not
> > having to enable ARCH_EXYNOS on kernels which are designed to be
> > platform agnostic (sometimes called Generic Kernels).  For some reason
> > SERIAL_SAMSUNG is the only symbol with these dependencies, so the
> > solution seemed simple and straight forward at the time.
> >
> > However, For sound reasons Geert NACKed the patch.
> >
> > Quoting from [1] he says:
> >
> >   "A generic kernel will include Samsung SoC support, hence
> >   PLAT_SAMSUNG or ARCH_EXYNOS will be enabled."
>
> Yes, it's correct reasoning. There is also one more use-case -
> non-upstreamed (out of tree) platform which wants to use Exynos-specific
> drivers. Something like was happening with Apple M1 except that it got
> upstreamed and we do not care much about out-of-tree.
>
> >
> > However, since the entry for ARCH_EXYNOS *insists* on building-in a
> > bunch of other symbols (via 'select') which will be unused in most
> > cases, this is not a currently acceptable approach for many Generic
> > Kernels due to size constraints.
>
> In the mainline kernel there is no such use case. If you want to have
> Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should
> select ARCH_EXYNOS because otherwise it does not make any sense. Zero
> sense. Such kernel won't work.
>
> It makes sense only if there is some other work, hidden here, where
> someone might want to have SERIAL_SAMSUNG or S3C RTC without
> ARCH_EXYNOS. Although GKI is not that work because GKI kernel will
> select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support
> Exynos platforms.
>
> Therefore I expect first to bring this "some other work, hidden here" to
> broader audience, so we can review its use case.
>
> >
> > What this patch does is migrates those symbols from being 'select'ed
> > (always built-in with no recourse) to 'default y'.  Where the former
> > cannot be over-ridden, but the latter can be via a vendor's
> > defconfig/fragment.
>
> It cannot be overridden by vendor fragment because options are not
> visible. You cannot change them.
>
> The patch does nothing in this regard (making them selectable/possible
> to disable), which is why I complained.
>
> >
> > I doubt many (any?) of these symbols can be converted to kernel
> > modules anyway, as they are required very early on in the boot
> > sequence.
>
> True, some could, some not. Also some platforms are set up via
> bootloader, so actually could "survive" till module is loaded from some
> initrd.

Hi Krzysztof,

I was trying to chime in, but the discussion got spread out across all
the patches. Since the cover letter seems to have everyone, I thought
I'd reply here. Hope you don't mind. I'll try to respond/chime in on
the various topics that were raised across the patches.

Yes, the next patch series would To/Cc folks correctly. William simply
forgot to use the --to-cover and --cc-cover options when using git
send-email.

I agree with you that it doesn't make sense to have ARCH_EXYNOS
enabled but to have all the clock drivers exynos compiled out. Then
one obviously can't boot an exynos platform using that kernel. I think
William is going to send out a new patch series with a few drivers
modularized. That'll ensure all the common exynos clock code is
modularized and we have a few examples of exynos clock modules.

Speaking of modules, a fully modularized generic ARM64 kernel where
everything is modularized out and we only load the necessary modules
is a great goal. And this is where I can chime in the most since I
wrote fw_devlink and tested this out. Such a kernel is not
hypothetical. IIRC hikey960 can already do this. There's an upstream
amlogic(?) board that can do this (Kevin Hilman has done that). A more
complex/recent/powerful, but downstream example is the Pixel 5 -- it
has a fully modular kernel. 320+ modules! Including interrupt
controllers, timers, pinctrl and clocks.

I can assure you any of the framework code related to pulling off
booting a fully modular ARM64 kernel is already upstreamed
(fw_devlink, irq framework changes, etc) or sent upstream (timer -- by
a SoC vendor, etc) and being worked on. As for fw_devlink, I've
extended it way past what GKI or Android would need. It would have
been super trivial if all I wanted to do was support Android devices.
I've also upstreamed changes that improve module loading time for all
ARM64 modules. All of this and more upstream work came out of GKI and
our push to be upstream first -- so I think it's reasonable to say the
GKI effort helps and cares to get more work upstreamed.

Speaking of GKI, let's not speak of it. It really doesn't matter.
Android is just yet another distribution (albeit a very popular one).
The part that's relevant to upstream/all the other distributions is
the fully modular generic ARM64 kernel and that's what we should focus
on.

In that context, I think William's attempts are reasonable and I think
he'll be glad to fix up any technical issues that people point out. So
hopefully we can focus on that?

Cheers,
Saravana

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Krzysztof Kozlowski]

On 25/09/2021 04:17, Saravana Kannan wrote:
> On Tue, Sep 21, 2021 at 1:25 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
>>
>> On 21/09/2021 10:11, Lee Jones wrote:
>>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
>>>
>>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>>> This patch series tries to address the issue of ARCH_EXYNOS force selecting
>>>>> a handful of drivers without allowing the vendor to override any of the
>>>>> default configs. This takes away from the flexibilty of compiling a generic
>>>>> kernel with exynos kernel modules. For example, it doesn't allow vendors to
>>>>> modularize these drivers out of the core kernel in order to share a generic
>>>>> kernel image across multiple devices that require device-specific kernel
>>>>> modules.
>>>>
>>>> You do not address the issue in these patches. The problem you describe
>>>> is that drivers are not modules and you are not changing them into modules.
>>>
>>> The wording is unfortunate.  The reason for this change doesn't have
>>> much to do with kernel modules.
>>>
>>> Let's go back in time 18 months or so when Greg KH submitted this [0]
>>> patch, which you Acked.  Greg was trying to solve the problem of not
>>> having to enable ARCH_EXYNOS on kernels which are designed to be
>>> platform agnostic (sometimes called Generic Kernels).  For some reason
>>> SERIAL_SAMSUNG is the only symbol with these dependencies, so the
>>> solution seemed simple and straight forward at the time.
>>>
>>> However, For sound reasons Geert NACKed the patch.
>>>
>>> Quoting from [1] he says:
>>>
>>>   "A generic kernel will include Samsung SoC support, hence
>>>   PLAT_SAMSUNG or ARCH_EXYNOS will be enabled."
>>
>> Yes, it's correct reasoning. There is also one more use-case -
>> non-upstreamed (out of tree) platform which wants to use Exynos-specific
>> drivers. Something like was happening with Apple M1 except that it got
>> upstreamed and we do not care much about out-of-tree.
>>
>>>
>>> However, since the entry for ARCH_EXYNOS *insists* on building-in a
>>> bunch of other symbols (via 'select') which will be unused in most
>>> cases, this is not a currently acceptable approach for many Generic
>>> Kernels due to size constraints.
>>
>> In the mainline kernel there is no such use case. If you want to have
>> Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should
>> select ARCH_EXYNOS because otherwise it does not make any sense. Zero
>> sense. Such kernel won't work.
>>
>> It makes sense only if there is some other work, hidden here, where
>> someone might want to have SERIAL_SAMSUNG or S3C RTC without
>> ARCH_EXYNOS. Although GKI is not that work because GKI kernel will
>> select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support
>> Exynos platforms.
>>
>> Therefore I expect first to bring this "some other work, hidden here" to
>> broader audience, so we can review its use case.
>>
>>>
>>> What this patch does is migrates those symbols from being 'select'ed
>>> (always built-in with no recourse) to 'default y'.  Where the former
>>> cannot be over-ridden, but the latter can be via a vendor's
>>> defconfig/fragment.
>>
>> It cannot be overridden by vendor fragment because options are not
>> visible. You cannot change them.
>>
>> The patch does nothing in this regard (making them selectable/possible
>> to disable), which is why I complained.
>>
>>>
>>> I doubt many (any?) of these symbols can be converted to kernel
>>> modules anyway, as they are required very early on in the boot
>>> sequence.
>>
>> True, some could, some not. Also some platforms are set up via
>> bootloader, so actually could "survive" till module is loaded from some
>> initrd.
> 
> Hi Krzysztof,
> 
> I was trying to chime in, but the discussion got spread out across all
> the patches. Since the cover letter seems to have everyone, I thought
> I'd reply here. Hope you don't mind. I'll try to respond/chime in on
> the various topics that were raised across the patches.
> 
> Yes, the next patch series would To/Cc folks correctly. William simply
> forgot to use the --to-cover and --cc-cover options when using git
> send-email.
> 
> I agree with you that it doesn't make sense to have ARCH_EXYNOS
> enabled but to have all the clock drivers exynos compiled out. Then
> one obviously can't boot an exynos platform using that kernel.

If downstream kernel does not use any upstream platforms (e.g.
Exynos5433 or Exynos7) and has its own drivers for everything, then
downstream does not even need ARCH_EXYNOS. Just disable it.

> I think
> William is going to send out a new patch series with a few drivers
> modularized. That'll ensure all the common exynos clock code is
> modularized and we have a few examples of exynos clock modules.

If it works on supported Exynos platforms: awesome!
If it does not work: not that good. I understand that downstream or
vendor do not want to mainline their SoC drivers and SoC support. Either
because HW is too new (do not disclose it) or it is too old (lost
interest). It's their right, they do not have to work with mainline on
this. However changing mainline kernel in such a case to affect it so
you can use your non-upstreamed drivers is wrong.

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.

> 
> Speaking of modules, a fully modularized generic ARM64 kernel where
> everything is modularized out and we only load the necessary modules
> is a great goal. And this is where I can chime in the most since I
> wrote fw_devlink and tested this out. Such a kernel is not
> hypothetical. IIRC hikey960 can already do this. There's an upstream
> amlogic(?) board that can do this (Kevin Hilman has done that). A more
> complex/recent/powerful, but downstream example is the Pixel 5 -- it
> has a fully modular kernel. 320+ modules! Including interrupt
> controllers, timers, pinctrl and clocks.

Awesome! I am in, if it works. :)

> I can assure you any of the framework code related to pulling off
> booting a fully modular ARM64 kernel is already upstreamed
> (fw_devlink, irq framework changes, etc) or sent upstream (timer -- by
> a SoC vendor, etc) and being worked on. As for fw_devlink, I've
> extended it way past what GKI or Android would need. It would have
> been super trivial if all I wanted to do was support Android devices.
> I've also upstreamed changes that improve module loading time for all
> ARM64 modules. All of this and more upstream work came out of GKI and
> our push to be upstream first -- so I think it's reasonable to say the
> GKI effort helps and cares to get more work upstreamed.

Except UFS driver and recent Linaro work on Exynos850, none of these
apply to the vendor discussed here.

> Speaking of GKI, let's not speak of it. It really doesn't matter.
> Android is just yet another distribution (albeit a very popular one).
> The part that's relevant to upstream/all the other distributions is
> the fully modular generic ARM64 kernel and that's what we should focus
> on.
> 
> In that context, I think William's attempts are reasonable and I think
> he'll be glad to fix up any technical issues that people point out. So
> hopefully we can focus on that?

Yes, we can focus on that. In technical issues, I do not agree to
affecting negatively supported platforms just because downstream/vendor
does not want to send upstream its drivers.

Please upstream your drivers. By "your" I mean all the drivers which you
want to enable after disabling ARCH_EXYNOS mainline drivers.

Best regards,
Krzysztof

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Krzysztof,

On Mon, Sep 27, 2021 at 10:08 AM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
> On 25/09/2021 04:17, Saravana Kannan wrote:
> > On Tue, Sep 21, 2021 at 1:25 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@canonical.com> wrote:
> >> On 21/09/2021 10:11, Lee Jones wrote:
> >>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> >>>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>>> This patch series tries to address the issue of ARCH_EXYNOS force selecting
> >>>>> a handful of drivers without allowing the vendor to override any of the
> >>>>> default configs. This takes away from the flexibilty of compiling a generic
> >>>>> kernel with exynos kernel modules. For example, it doesn't allow vendors to
> >>>>> modularize these drivers out of the core kernel in order to share a generic
> >>>>> kernel image across multiple devices that require device-specific kernel
> >>>>> modules.
> >>>>
> >>>> You do not address the issue in these patches. The problem you describe
> >>>> is that drivers are not modules and you are not changing them into modules.
> >>>
> >>> The wording is unfortunate.  The reason for this change doesn't have
> >>> much to do with kernel modules.
> >>>
> >>> Let's go back in time 18 months or so when Greg KH submitted this [0]
> >>> patch, which you Acked.  Greg was trying to solve the problem of not
> >>> having to enable ARCH_EXYNOS on kernels which are designed to be
> >>> platform agnostic (sometimes called Generic Kernels).  For some reason
> >>> SERIAL_SAMSUNG is the only symbol with these dependencies, so the
> >>> solution seemed simple and straight forward at the time.
> >>>
> >>> However, For sound reasons Geert NACKed the patch.
> >>>
> >>> Quoting from [1] he says:
> >>>
> >>>   "A generic kernel will include Samsung SoC support, hence
> >>>   PLAT_SAMSUNG or ARCH_EXYNOS will be enabled."
> >>
> >> Yes, it's correct reasoning. There is also one more use-case -
> >> non-upstreamed (out of tree) platform which wants to use Exynos-specific
> >> drivers. Something like was happening with Apple M1 except that it got
> >> upstreamed and we do not care much about out-of-tree.
> >>
> >>> However, since the entry for ARCH_EXYNOS *insists* on building-in a
> >>> bunch of other symbols (via 'select') which will be unused in most
> >>> cases, this is not a currently acceptable approach for many Generic
> >>> Kernels due to size constraints.
> >>
> >> In the mainline kernel there is no such use case. If you want to have
> >> Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should
> >> select ARCH_EXYNOS because otherwise it does not make any sense. Zero
> >> sense. Such kernel won't work.
> >>
> >> It makes sense only if there is some other work, hidden here, where
> >> someone might want to have SERIAL_SAMSUNG or S3C RTC without
> >> ARCH_EXYNOS. Although GKI is not that work because GKI kernel will
> >> select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support
> >> Exynos platforms.
> >>
> >> Therefore I expect first to bring this "some other work, hidden here" to
> >> broader audience, so we can review its use case.
> >>
> >>> What this patch does is migrates those symbols from being 'select'ed
> >>> (always built-in with no recourse) to 'default y'.  Where the former
> >>> cannot be over-ridden, but the latter can be via a vendor's
> >>> defconfig/fragment.
> >>
> >> It cannot be overridden by vendor fragment because options are not
> >> visible. You cannot change them.
> >>
> >> The patch does nothing in this regard (making them selectable/possible
> >> to disable), which is why I complained.
> >>
> >>> I doubt many (any?) of these symbols can be converted to kernel
> >>> modules anyway, as they are required very early on in the boot
> >>> sequence.
> >>
> >> True, some could, some not. Also some platforms are set up via
> >> bootloader, so actually could "survive" till module is loaded from some
> >> initrd.
> >
> > I was trying to chime in, but the discussion got spread out across all
> > the patches. Since the cover letter seems to have everyone, I thought
> > I'd reply here. Hope you don't mind. I'll try to respond/chime in on
> > the various topics that were raised across the patches.
> >
> > Yes, the next patch series would To/Cc folks correctly. William simply
> > forgot to use the --to-cover and --cc-cover options when using git
> > send-email.
> >
> > I agree with you that it doesn't make sense to have ARCH_EXYNOS
> > enabled but to have all the clock drivers exynos compiled out. Then
> > one obviously can't boot an exynos platform using that kernel.
>
> If downstream kernel does not use any upstream platforms (e.g.
> Exynos5433 or Exynos7) and has its own drivers for everything, then
> downstream does not even need ARCH_EXYNOS. Just disable it.

I guess that's how they got to "[PATCH 1/2] tty: serial: samsung_tty:
build it for any platform"...
https://lore.kernel.org/lkml/20200220102628.3371996-1-gregkh@linuxfoundation.org/

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 v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Saravana Kannan]

On Mon, Sep 27, 2021 at 1:08 AM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
>
> On 25/09/2021 04:17, Saravana Kannan wrote:
> > On Tue, Sep 21, 2021 at 1:25 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@canonical.com> wrote:
> >>
> >> On 21/09/2021 10:11, Lee Jones wrote:
> >>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> >>>
> >>>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>>> This patch series tries to address the issue of ARCH_EXYNOS force selecting
> >>>>> a handful of drivers without allowing the vendor to override any of the
> >>>>> default configs. This takes away from the flexibilty of compiling a generic
> >>>>> kernel with exynos kernel modules. For example, it doesn't allow vendors to
> >>>>> modularize these drivers out of the core kernel in order to share a generic
> >>>>> kernel image across multiple devices that require device-specific kernel
> >>>>> modules.
> >>>>
> >>>> You do not address the issue in these patches. The problem you describe
> >>>> is that drivers are not modules and you are not changing them into modules.
> >>>
> >>> The wording is unfortunate.  The reason for this change doesn't have
> >>> much to do with kernel modules.
> >>>
> >>> Let's go back in time 18 months or so when Greg KH submitted this [0]
> >>> patch, which you Acked.  Greg was trying to solve the problem of not
> >>> having to enable ARCH_EXYNOS on kernels which are designed to be
> >>> platform agnostic (sometimes called Generic Kernels).  For some reason
> >>> SERIAL_SAMSUNG is the only symbol with these dependencies, so the
> >>> solution seemed simple and straight forward at the time.
> >>>
> >>> However, For sound reasons Geert NACKed the patch.
> >>>
> >>> Quoting from [1] he says:
> >>>
> >>>   "A generic kernel will include Samsung SoC support, hence
> >>>   PLAT_SAMSUNG or ARCH_EXYNOS will be enabled."
> >>
> >> Yes, it's correct reasoning. There is also one more use-case -
> >> non-upstreamed (out of tree) platform which wants to use Exynos-specific
> >> drivers. Something like was happening with Apple M1 except that it got
> >> upstreamed and we do not care much about out-of-tree.
> >>
> >>>
> >>> However, since the entry for ARCH_EXYNOS *insists* on building-in a
> >>> bunch of other symbols (via 'select') which will be unused in most
> >>> cases, this is not a currently acceptable approach for many Generic
> >>> Kernels due to size constraints.
> >>
> >> In the mainline kernel there is no such use case. If you want to have
> >> Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should
> >> select ARCH_EXYNOS because otherwise it does not make any sense. Zero
> >> sense. Such kernel won't work.
> >>
> >> It makes sense only if there is some other work, hidden here, where
> >> someone might want to have SERIAL_SAMSUNG or S3C RTC without
> >> ARCH_EXYNOS. Although GKI is not that work because GKI kernel will
> >> select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support
> >> Exynos platforms.
> >>
> >> Therefore I expect first to bring this "some other work, hidden here" to
> >> broader audience, so we can review its use case.
> >>
> >>>
> >>> What this patch does is migrates those symbols from being 'select'ed
> >>> (always built-in with no recourse) to 'default y'.  Where the former
> >>> cannot be over-ridden, but the latter can be via a vendor's
> >>> defconfig/fragment.
> >>
> >> It cannot be overridden by vendor fragment because options are not
> >> visible. You cannot change them.
> >>
> >> The patch does nothing in this regard (making them selectable/possible
> >> to disable), which is why I complained.
> >>
> >>>
> >>> I doubt many (any?) of these symbols can be converted to kernel
> >>> modules anyway, as they are required very early on in the boot
> >>> sequence.
> >>
> >> True, some could, some not. Also some platforms are set up via
> >> bootloader, so actually could "survive" till module is loaded from some
> >> initrd.
> >
> > Hi Krzysztof,
> >
> > I was trying to chime in, but the discussion got spread out across all
> > the patches. Since the cover letter seems to have everyone, I thought
> > I'd reply here. Hope you don't mind. I'll try to respond/chime in on
> > the various topics that were raised across the patches.
> >
> > Yes, the next patch series would To/Cc folks correctly. William simply
> > forgot to use the --to-cover and --cc-cover options when using git
> > send-email.
> >
> > I agree with you that it doesn't make sense to have ARCH_EXYNOS
> > enabled but to have all the clock drivers exynos compiled out. Then
> > one obviously can't boot an exynos platform using that kernel.
>
> If downstream kernel does not use any upstream platforms (e.g.
> Exynos5433 or Exynos7) and has its own drivers for everything, then
> downstream does not even need ARCH_EXYNOS. Just disable it.

As Geert pointed out in another reply, that prevents the use of
earlyconsole on an exynos SoC + fully modular generic kernel. Are we
okay with removing the ARCH_EXYNOS dependency on the early console
driver now?

> > I think
> > William is going to send out a new patch series with a few drivers
> > modularized. That'll ensure all the common exynos clock code is
> > modularized and we have a few examples of exynos clock modules.
>
> If it works on supported Exynos platforms: awesome!

Yes, that's the idea :) What's the point of sending a module upstream
if it doesn't work with upstream? And this is where William would need
help with testing.

> If it does not work: not that good. I understand that downstream or
> vendor do not want to mainline their SoC drivers and SoC support. Either
> because HW is too new (do not disclose it) or it is too old (lost
> interest). It's their right, they do not have to work with mainline on
> this. However changing mainline kernel in such a case to affect it so
> you can use your non-upstreamed drivers is wrong.

Since the goal is to have some of the existing clock drivers work as
modules, we wouldn't be running into this situation above.

> 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.
>
> >
> > Speaking of modules, a fully modularized generic ARM64 kernel where
> > everything is modularized out and we only load the necessary modules
> > is a great goal. And this is where I can chime in the most since I
> > wrote fw_devlink and tested this out. Such a kernel is not
> > hypothetical. IIRC hikey960 can already do this. There's an upstream
> > amlogic(?) board that can do this (Kevin Hilman has done that). A more
> > complex/recent/powerful, but downstream example is the Pixel 5 -- it
> > has a fully modular kernel. 320+ modules! Including interrupt
> > controllers, timers, pinctrl and clocks.
>
> Awesome! I am in, if it works. :)

Great!

> > I can assure you any of the framework code related to pulling off
> > booting a fully modular ARM64 kernel is already upstreamed
> > (fw_devlink, irq framework changes, etc) or sent upstream (timer -- by
> > a SoC vendor, etc) and being worked on. As for fw_devlink, I've
> > extended it way past what GKI or Android would need. It would have
> > been super trivial if all I wanted to do was support Android devices.
> > I've also upstreamed changes that improve module loading time for all
> > ARM64 modules. All of this and more upstream work came out of GKI and
> > our push to be upstream first -- so I think it's reasonable to say the
> > GKI effort helps and cares to get more work upstreamed.
>
> Except UFS driver and recent Linaro work on Exynos850, none of these
> apply to the vendor discussed here.

I obviously can't force a vendor to upstream their stuff and I can't
speak for them. However the Android kernel team's goal is to have the
core Android kernel be the upstream kernel (we are making progress
every year). This will also have the nice effect that vendor
downstream drivers written for Android would automatically be
compatible with upstream and way more likely to get upstreamed.

> > Speaking of GKI, let's not speak of it. It really doesn't matter.
> > Android is just yet another distribution (albeit a very popular one).
> > The part that's relevant to upstream/all the other distributions is
> > the fully modular generic ARM64 kernel and that's what we should focus
> > on.
> >
> > In that context, I think William's attempts are reasonable and I think
> > he'll be glad to fix up any technical issues that people point out. So
> > hopefully we can focus on that?
>
> Yes, we can focus on that.

Thanks!

> In technical issues, I do not agree to
> affecting negatively supported platforms just because downstream/vendor
> does not want to send upstream its drivers.
>
> Please upstream your drivers. By "your" I mean all the drivers which you
> want to enable after disabling ARCH_EXYNOS mainline drivers.

I'm not sure I fully understood this part. But if your point is that
we shouldn't have a negative impact on hardware supported in upstream
just so a downstream driver can work, I completely agree with you.

At the same time, it also doesn't make sense to have a negative impact
on upstream (rejecting patches that are working towards a fully
modular generic ARM64 kernel) just because it might also help
downstream drivers. That is like cutting your nose to spite your face.

Also, by taking this position, you are just making it even harder to
upstream the downstream drivers while also hurting upstream. Which is
clearly not what we want. Almost all vendors have engineers working
for them that'd like to see more of their code upstream. Treating them
as one monolithic "vendor" entity doesn't help. You are just making it
harder for the pro-upstream engineers to make a case for upstreaming
their drivers.


-Saravana

Re: [PATCH v1 0/4] arm64: Kconfig: Update ARCH_EXYNOS select configs

[Geert Uytterhoeven]

Hi Saravana,

On Mon, Sep 27, 2021 at 8:07 PM Saravana Kannan <saravanak@google.com> wrote:
> On Mon, Sep 27, 2021 at 1:08 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
> > On 25/09/2021 04:17, Saravana Kannan wrote:
> > > On Tue, Sep 21, 2021 at 1:25 AM Krzysztof Kozlowski
> > > <krzysztof.kozlowski@canonical.com> wrote:
> > >> On 21/09/2021 10:11, Lee Jones wrote:
> > >>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> > >>>> On 20/09/2021 21:03, Will McVicker wrote:
> > >>>>> This patch series tries to address the issue of ARCH_EXYNOS force selecting
> > >>>>> a handful of drivers without allowing the vendor to override any of the
> > >>>>> default configs. This takes away from the flexibilty of compiling a generic
> > >>>>> kernel with exynos kernel modules. For example, it doesn't allow vendors to
> > >>>>> modularize these drivers out of the core kernel in order to share a generic
> > >>>>> kernel image across multiple devices that require device-specific kernel
> > >>>>> modules.
> > >>>>
> > >>>> You do not address the issue in these patches. The problem you describe
> > >>>> is that drivers are not modules and you are not changing them into modules.
> > >>>
> > >>> The wording is unfortunate.  The reason for this change doesn't have
> > >>> much to do with kernel modules.
> > >>>
> > >>> Let's go back in time 18 months or so when Greg KH submitted this [0]
> > >>> patch, which you Acked.  Greg was trying to solve the problem of not
> > >>> having to enable ARCH_EXYNOS on kernels which are designed to be
> > >>> platform agnostic (sometimes called Generic Kernels).  For some reason
> > >>> SERIAL_SAMSUNG is the only symbol with these dependencies, so the
> > >>> solution seemed simple and straight forward at the time.
> > >>>
> > >>> However, For sound reasons Geert NACKed the patch.
> > >>>
> > >>> Quoting from [1] he says:
> > >>>
> > >>>   "A generic kernel will include Samsung SoC support, hence
> > >>>   PLAT_SAMSUNG or ARCH_EXYNOS will be enabled."
> > >>
> > >> Yes, it's correct reasoning. There is also one more use-case -
> > >> non-upstreamed (out of tree) platform which wants to use Exynos-specific
> > >> drivers. Something like was happening with Apple M1 except that it got
> > >> upstreamed and we do not care much about out-of-tree.
> > >>
> > >>>
> > >>> However, since the entry for ARCH_EXYNOS *insists* on building-in a
> > >>> bunch of other symbols (via 'select') which will be unused in most
> > >>> cases, this is not a currently acceptable approach for many Generic
> > >>> Kernels due to size constraints.
> > >>
> > >> In the mainline kernel there is no such use case. If you want to have
> > >> Exynos-whatever-driver (e.g. SERIAL_SAMSUNG or S3C RTC), you should
> > >> select ARCH_EXYNOS because otherwise it does not make any sense. Zero
> > >> sense. Such kernel won't work.
> > >>
> > >> It makes sense only if there is some other work, hidden here, where
> > >> someone might want to have SERIAL_SAMSUNG or S3C RTC without
> > >> ARCH_EXYNOS. Although GKI is not that work because GKI kernel will
> > >> select ARCH_EXYNOS. It must select ARCH_EXYNOS if it wants to support
> > >> Exynos platforms.
> > >>
> > >> Therefore I expect first to bring this "some other work, hidden here" to
> > >> broader audience, so we can review its use case.
> > >>
> > >>>
> > >>> What this patch does is migrates those symbols from being 'select'ed
> > >>> (always built-in with no recourse) to 'default y'.  Where the former
> > >>> cannot be over-ridden, but the latter can be via a vendor's
> > >>> defconfig/fragment.
> > >>
> > >> It cannot be overridden by vendor fragment because options are not
> > >> visible. You cannot change them.
> > >>
> > >> The patch does nothing in this regard (making them selectable/possible
> > >> to disable), which is why I complained.
> > >>
> > >>>
> > >>> I doubt many (any?) of these symbols can be converted to kernel
> > >>> modules anyway, as they are required very early on in the boot
> > >>> sequence.
> > >>
> > >> True, some could, some not. Also some platforms are set up via
> > >> bootloader, so actually could "survive" till module is loaded from some
> > >> initrd.
> > >
> > > I was trying to chime in, but the discussion got spread out across all
> > > the patches. Since the cover letter seems to have everyone, I thought
> > > I'd reply here. Hope you don't mind. I'll try to respond/chime in on
> > > the various topics that were raised across the patches.
> > >
> > > Yes, the next patch series would To/Cc folks correctly. William simply
> > > forgot to use the --to-cover and --cc-cover options when using git
> > > send-email.
> > >
> > > I agree with you that it doesn't make sense to have ARCH_EXYNOS
> > > enabled but to have all the clock drivers exynos compiled out. Then
> > > one obviously can't boot an exynos platform using that kernel.
> >
> > If downstream kernel does not use any upstream platforms (e.g.
> > Exynos5433 or Exynos7) and has its own drivers for everything, then
> > downstream does not even need ARCH_EXYNOS. Just disable it.
>
> As Geert pointed out in another reply, that prevents the use of
> earlyconsole on an exynos SoC + fully modular generic kernel. Are we
> okay with removing the ARCH_EXYNOS dependency on the early console
> driver now?

IMHO not in upstream, as there is no upstream use yet for not having
the dependencies.

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".

Greg says that's what defconfig files are for, but the arm64 policy is
to have a single defconfig file only.  But thanks to the ARCH_* symbol,
you can take arm64 defconfig, disable the ARCH_* symbols not applicable
to your platform, and have a good start for a config file tailored to
your platform. Note that works for the arm multi_v*_defconfigs, too.

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