[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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[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 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Will McVicker]

COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
"default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
or modularize this driver.

I verified the .config is identical with and without this change.

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

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index b0ce18d4cc98..3a66ed43088d 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_CHIPID
 	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 	select EXYNOS_PMU
diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index 0441c4f73ac9..f3e189a06b03 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -2,6 +2,7 @@
 # Recent Exynos platforms should just select COMMON_CLK_SAMSUNG:
 config COMMON_CLK_SAMSUNG
 	bool "Samsung Exynos clock controller support" if COMPILE_TEST
+	default y if ARCH_EXYNOS
 	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
-- 
2.33.0.464.g1972c5931b-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Will McVicker]

COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
"default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
or modularize this driver.

I verified the .config is identical with and without this change.

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

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index b0ce18d4cc98..3a66ed43088d 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_CHIPID
 	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
 	select EXYNOS_PMU
diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index 0441c4f73ac9..f3e189a06b03 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -2,6 +2,7 @@
 # Recent Exynos platforms should just select COMMON_CLK_SAMSUNG:
 config COMMON_CLK_SAMSUNG
 	bool "Samsung Exynos clock controller support" if COMPILE_TEST
+	default y if ARCH_EXYNOS
 	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
-- 
2.33.0.464.g1972c5931b-goog

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 20/09/2021 21:03, Will McVicker wrote:
> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> or modularize this driver.

The clock drivers are essential, you cannot disable them for a generic
kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.

> 
> I verified the .config is identical with and without this change.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms | 1 -
>  drivers/clk/samsung/Kconfig  | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 

NAK, please use get_maintainers.pl to Cc necessary folks.



Best regards,
Krzysztof

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 20/09/2021 21:03, Will McVicker wrote:
> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> or modularize this driver.

The clock drivers are essential, you cannot disable them for a generic
kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.

> 
> I verified the .config is identical with and without this change.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms | 1 -
>  drivers/clk/samsung/Kconfig  | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 

NAK, please use get_maintainers.pl to Cc necessary folks.



Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Geert Uytterhoeven]

On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 20/09/2021 21:03, Will McVicker wrote:
> > COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> > to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> > "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> > or modularize this driver.
>
> The clock drivers are essential, you cannot disable them for a generic
> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.

Obviously it's not gonna work if the clock driver is not enabled
at all.  But does it work if you make the clock driver modular, and
put it with all other essential driver modules in initramfs?  Debugging
would be hard, as the serial console driver also relies on clocks
and PM Domains etc.

If not, this patch should be NAKed, until it works with a modular
clock driver.

If yes, perhaps another line should be added (_before_ the other line)?

  + default m if ARCH_EXYNOS && MODULES
    default y if ARCH_EXYNOS

However, many developers may want MODULES=y, but not want to bother
with an initramfs.  So perhaps we need a new symbol
MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
driver default to m if that is enabled?

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 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Geert Uytterhoeven]

On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 20/09/2021 21:03, Will McVicker wrote:
> > COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> > to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> > "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> > or modularize this driver.
>
> The clock drivers are essential, you cannot disable them for a generic
> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.

Obviously it's not gonna work if the clock driver is not enabled
at all.  But does it work if you make the clock driver modular, and
put it with all other essential driver modules in initramfs?  Debugging
would be hard, as the serial console driver also relies on clocks
and PM Domains etc.

If not, this patch should be NAKed, until it works with a modular
clock driver.

If yes, perhaps another line should be added (_before_ the other line)?

  + default m if ARCH_EXYNOS && MODULES
    default y if ARCH_EXYNOS

However, many developers may want MODULES=y, but not want to bother
with an initramfs.  So perhaps we need a new symbol
MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
driver default to m if that is enabled?

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 20/09/2021 21:03, Will McVicker wrote:
>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
>>> or modularize this driver.
>>
>> The clock drivers are essential, you cannot disable them for a generic
>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
> 
> Obviously it's not gonna work if the clock driver is not enabled
> at all.  But does it work if you make the clock driver modular, and
> put it with all other essential driver modules in initramfs?  Debugging
> would be hard, as the serial console driver also relies on clocks
> and PM Domains etc.

The kernel could boot without clock drivers (default settings from
bootloader), probe clocks from initramfs and proceed with rootfs from
eMMC/SD/net.

In theory.

However I have no reports that it ever worked. If there is such working
upstream configuration, I don't mind here. Just please explain this in
the commit msg.

> 
> If not, this patch should be NAKed, until it works with a modular
> clock driver.
> 
> If yes, perhaps another line should be added (_before_ the other line)?
> 
>   + default m if ARCH_EXYNOS && MODULES
>     default y if ARCH_EXYNOS
> 
> However, many developers may want MODULES=y, but not want to bother
> with an initramfs.  So perhaps we need a new symbol
> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
> driver default to m if that is enabled?

Yeah, that's indeed a problem to solve. For most users (and distros)
building kernel for Exynos this should be built-in by default.

Anyway, the option is non-selectable so it cannot be converted to "m" or
disabled. And this is claimed in the commit msg:
"provide flexibilty for vendors to disable or modularize this driver."

The commit does not achieve it.

Best regards,
Krzysztof

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 20/09/2021 21:03, Will McVicker wrote:
>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
>>> or modularize this driver.
>>
>> The clock drivers are essential, you cannot disable them for a generic
>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
> 
> Obviously it's not gonna work if the clock driver is not enabled
> at all.  But does it work if you make the clock driver modular, and
> put it with all other essential driver modules in initramfs?  Debugging
> would be hard, as the serial console driver also relies on clocks
> and PM Domains etc.

The kernel could boot without clock drivers (default settings from
bootloader), probe clocks from initramfs and proceed with rootfs from
eMMC/SD/net.

In theory.

However I have no reports that it ever worked. If there is such working
upstream configuration, I don't mind here. Just please explain this in
the commit msg.

> 
> If not, this patch should be NAKed, until it works with a modular
> clock driver.
> 
> If yes, perhaps another line should be added (_before_ the other line)?
> 
>   + default m if ARCH_EXYNOS && MODULES
>     default y if ARCH_EXYNOS
> 
> However, many developers may want MODULES=y, but not want to bother
> with an initramfs.  So perhaps we need a new symbol
> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
> driver default to m if that is enabled?

Yeah, that's indeed a problem to solve. For most users (and distros)
building kernel for Exynos this should be built-in by default.

Anyway, the option is non-selectable so it cannot be converted to "m" or
disabled. And this is claimed in the commit msg:
"provide flexibilty for vendors to disable or modularize this driver."

The commit does not achieve it.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Will McVicker]

On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
>
> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> > On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On 20/09/2021 21:03, Will McVicker wrote:
> >>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> >>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> >>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> >>> or modularize this driver.
> >>
> >> The clock drivers are essential, you cannot disable them for a generic
> >> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
> >
> > Obviously it's not gonna work if the clock driver is not enabled
> > at all.  But does it work if you make the clock driver modular, and
> > put it with all other essential driver modules in initramfs?  Debugging
> > would be hard, as the serial console driver also relies on clocks
> > and PM Domains etc.
>
> The kernel could boot without clock drivers (default settings from
> bootloader), probe clocks from initramfs and proceed with rootfs from
> eMMC/SD/net.
>
> In theory.
>
> However I have no reports that it ever worked. If there is such working
> upstream configuration, I don't mind here. Just please explain this in
> the commit msg.
>
> >
> > If not, this patch should be NAKed, until it works with a modular
> > clock driver.
> >
> > If yes, perhaps another line should be added (_before_ the other line)?
> >
> >   + default m if ARCH_EXYNOS && MODULES
> >     default y if ARCH_EXYNOS
> >
> > However, many developers may want MODULES=y, but not want to bother
> > with an initramfs.  So perhaps we need a new symbol
> > MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
> > driver default to m if that is enabled?
>
> Yeah, that's indeed a problem to solve. For most users (and distros)
> building kernel for Exynos this should be built-in by default.
>
> Anyway, the option is non-selectable so it cannot be converted to "m" or
> disabled. And this is claimed in the commit msg:
> "provide flexibilty for vendors to disable or modularize this driver."
>
> The commit does not achieve it.
>
> Best regards,
> Krzysztof

Thanks for the reviews! As Lee has explained in his replies, the
intent of this series is to provide config flexibility to create a
defconfig that allows us to move out SoC specific drivers in order to
create a generic kernel that can be used across multiple devices with
different SoCs. I'm sorry I added confusion by mentioning
modularization. All of these drivers that I am modifying in this
series can be modularized which is an ongoing effort, but is not
addressed here and I don't believe that modularizing them should be a
requirement before supporting enabling/disabling them.

I will update the series with my patch that refactors the Samsung SoC
drivers menuconfig to make these visible as well.

Thanks,
Will

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Will McVicker]

On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
>
> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> > On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On 20/09/2021 21:03, Will McVicker wrote:
> >>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> >>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> >>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> >>> or modularize this driver.
> >>
> >> The clock drivers are essential, you cannot disable them for a generic
> >> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
> >
> > Obviously it's not gonna work if the clock driver is not enabled
> > at all.  But does it work if you make the clock driver modular, and
> > put it with all other essential driver modules in initramfs?  Debugging
> > would be hard, as the serial console driver also relies on clocks
> > and PM Domains etc.
>
> The kernel could boot without clock drivers (default settings from
> bootloader), probe clocks from initramfs and proceed with rootfs from
> eMMC/SD/net.
>
> In theory.
>
> However I have no reports that it ever worked. If there is such working
> upstream configuration, I don't mind here. Just please explain this in
> the commit msg.
>
> >
> > If not, this patch should be NAKed, until it works with a modular
> > clock driver.
> >
> > If yes, perhaps another line should be added (_before_ the other line)?
> >
> >   + default m if ARCH_EXYNOS && MODULES
> >     default y if ARCH_EXYNOS
> >
> > However, many developers may want MODULES=y, but not want to bother
> > with an initramfs.  So perhaps we need a new symbol
> > MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
> > driver default to m if that is enabled?
>
> Yeah, that's indeed a problem to solve. For most users (and distros)
> building kernel for Exynos this should be built-in by default.
>
> Anyway, the option is non-selectable so it cannot be converted to "m" or
> disabled. And this is claimed in the commit msg:
> "provide flexibilty for vendors to disable or modularize this driver."
>
> The commit does not achieve it.
>
> Best regards,
> Krzysztof

Thanks for the reviews! As Lee has explained in his replies, the
intent of this series is to provide config flexibility to create a
defconfig that allows us to move out SoC specific drivers in order to
create a generic kernel that can be used across multiple devices with
different SoCs. I'm sorry I added confusion by mentioning
modularization. All of these drivers that I am modifying in this
series can be modularized which is an ongoing effort, but is not
addressed here and I don't believe that modularizing them should be a
requirement before supporting enabling/disabling them.

I will update the series with my patch that refactors the Samsung SoC
drivers menuconfig to make these visible as well.

Thanks,
Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 21/09/2021 19:58, Will McVicker wrote:
> On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
>>
>> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
>>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
>>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
>>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
>>>>> or modularize this driver.
>>>>
>>>> The clock drivers are essential, you cannot disable them for a generic
>>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
>>>
>>> Obviously it's not gonna work if the clock driver is not enabled
>>> at all.  But does it work if you make the clock driver modular, and
>>> put it with all other essential driver modules in initramfs?  Debugging
>>> would be hard, as the serial console driver also relies on clocks
>>> and PM Domains etc.
>>
>> The kernel could boot without clock drivers (default settings from
>> bootloader), probe clocks from initramfs and proceed with rootfs from
>> eMMC/SD/net.
>>
>> In theory.
>>
>> However I have no reports that it ever worked. If there is such working
>> upstream configuration, I don't mind here. Just please explain this in
>> the commit msg.
>>
>>>
>>> If not, this patch should be NAKed, until it works with a modular
>>> clock driver.
>>>
>>> If yes, perhaps another line should be added (_before_ the other line)?
>>>
>>>   + default m if ARCH_EXYNOS && MODULES
>>>     default y if ARCH_EXYNOS
>>>
>>> However, many developers may want MODULES=y, but not want to bother
>>> with an initramfs.  So perhaps we need a new symbol
>>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
>>> driver default to m if that is enabled?
>>
>> Yeah, that's indeed a problem to solve. For most users (and distros)
>> building kernel for Exynos this should be built-in by default.
>>
>> Anyway, the option is non-selectable so it cannot be converted to "m" or
>> disabled. And this is claimed in the commit msg:
>> "provide flexibilty for vendors to disable or modularize this driver."
>>
>> The commit does not achieve it.
>>
>> Best regards,
>> Krzysztof
> 
> Thanks for the reviews! As Lee has explained in his replies, the
> intent of this series is to provide config flexibility to create a
> defconfig that allows us to move out SoC specific drivers in order to
> create a generic kernel that can be used across multiple devices with
> different SoCs.

That's quite generic statement... or let me put it that way - we already
have this ability to create a generic kernel supporting different SoCs.
Exynos and other ARMv7 and ARMv8 platforms are multiplatform.

Task is done.

Please be more specific about use case and describe what exactly in
current upstream multiplatform kernel is missing, what is not
multiplatform enough.


> I'm sorry I added confusion by mentioning
> modularization. All of these drivers that I am modifying in this
> series can be modularized which is an ongoing effort, but is not
> addressed here and I don't believe that modularizing them should be a
> requirement before supporting enabling/disabling them.

Since the disabling the driver for a kernel supporting Exynos does not
make any sense, then making it at least modular unfortunately it is a
requirement.

> I will update the series with my patch that refactors the Samsung SoC
> drivers menuconfig to make these visible as well.

I would first recommend to really describe your use case because my
questions about this are still unanswered.

Best regards,
Krzysztof

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 21/09/2021 19:58, Will McVicker wrote:
> On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
>>
>> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
>>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
>>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
>>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
>>>>> or modularize this driver.
>>>>
>>>> The clock drivers are essential, you cannot disable them for a generic
>>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
>>>
>>> Obviously it's not gonna work if the clock driver is not enabled
>>> at all.  But does it work if you make the clock driver modular, and
>>> put it with all other essential driver modules in initramfs?  Debugging
>>> would be hard, as the serial console driver also relies on clocks
>>> and PM Domains etc.
>>
>> The kernel could boot without clock drivers (default settings from
>> bootloader), probe clocks from initramfs and proceed with rootfs from
>> eMMC/SD/net.
>>
>> In theory.
>>
>> However I have no reports that it ever worked. If there is such working
>> upstream configuration, I don't mind here. Just please explain this in
>> the commit msg.
>>
>>>
>>> If not, this patch should be NAKed, until it works with a modular
>>> clock driver.
>>>
>>> If yes, perhaps another line should be added (_before_ the other line)?
>>>
>>>   + default m if ARCH_EXYNOS && MODULES
>>>     default y if ARCH_EXYNOS
>>>
>>> However, many developers may want MODULES=y, but not want to bother
>>> with an initramfs.  So perhaps we need a new symbol
>>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
>>> driver default to m if that is enabled?
>>
>> Yeah, that's indeed a problem to solve. For most users (and distros)
>> building kernel for Exynos this should be built-in by default.
>>
>> Anyway, the option is non-selectable so it cannot be converted to "m" or
>> disabled. And this is claimed in the commit msg:
>> "provide flexibilty for vendors to disable or modularize this driver."
>>
>> The commit does not achieve it.
>>
>> Best regards,
>> Krzysztof
> 
> Thanks for the reviews! As Lee has explained in his replies, the
> intent of this series is to provide config flexibility to create a
> defconfig that allows us to move out SoC specific drivers in order to
> create a generic kernel that can be used across multiple devices with
> different SoCs.

That's quite generic statement... or let me put it that way - we already
have this ability to create a generic kernel supporting different SoCs.
Exynos and other ARMv7 and ARMv8 platforms are multiplatform.

Task is done.

Please be more specific about use case and describe what exactly in
current upstream multiplatform kernel is missing, what is not
multiplatform enough.


> I'm sorry I added confusion by mentioning
> modularization. All of these drivers that I am modifying in this
> series can be modularized which is an ongoing effort, but is not
> addressed here and I don't believe that modularizing them should be a
> requirement before supporting enabling/disabling them.

Since the disabling the driver for a kernel supporting Exynos does not
make any sense, then making it at least modular unfortunately it is a
requirement.

> I will update the series with my patch that refactors the Samsung SoC
> drivers menuconfig to make these visible as well.

I would first recommend to really describe your use case because my
questions about this are still unanswered.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 21/09/2021 19:58, Will McVicker wrote:
> > On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@canonical.com> wrote:
> >>
> >> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> >>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> >>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> >>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> >>>>> or modularize this driver.
> >>>>
> >>>> The clock drivers are essential, you cannot disable them for a generic
> >>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
> >>>
> >>> Obviously it's not gonna work if the clock driver is not enabled
> >>> at all.  But does it work if you make the clock driver modular, and
> >>> put it with all other essential driver modules in initramfs?  Debugging
> >>> would be hard, as the serial console driver also relies on clocks
> >>> and PM Domains etc.
> >>
> >> The kernel could boot without clock drivers (default settings from
> >> bootloader), probe clocks from initramfs and proceed with rootfs from
> >> eMMC/SD/net.
> >>
> >> In theory.
> >>
> >> However I have no reports that it ever worked. If there is such working
> >> upstream configuration, I don't mind here. Just please explain this in
> >> the commit msg.
> >>
> >>>
> >>> If not, this patch should be NAKed, until it works with a modular
> >>> clock driver.
> >>>
> >>> If yes, perhaps another line should be added (_before_ the other line)?
> >>>
> >>>   + default m if ARCH_EXYNOS && MODULES
> >>>     default y if ARCH_EXYNOS
> >>>
> >>> However, many developers may want MODULES=y, but not want to bother
> >>> with an initramfs.  So perhaps we need a new symbol
> >>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
> >>> driver default to m if that is enabled?
> >>
> >> Yeah, that's indeed a problem to solve. For most users (and distros)
> >> building kernel for Exynos this should be built-in by default.
> >>
> >> Anyway, the option is non-selectable so it cannot be converted to "m" or
> >> disabled. And this is claimed in the commit msg:
> >> "provide flexibilty for vendors to disable or modularize this driver."
> >>
> >> The commit does not achieve it.
> >>
> >> Best regards,
> >> Krzysztof
> > 
> > Thanks for the reviews! As Lee has explained in his replies, the
> > intent of this series is to provide config flexibility to create a
> > defconfig that allows us to move out SoC specific drivers in order to
> > create a generic kernel that can be used across multiple devices with
> > different SoCs.
> 
> That's quite generic statement... or let me put it that way - we already
> have this ability to create a generic kernel supporting different SoCs.
> Exynos and other ARMv7 and ARMv8 platforms are multiplatform.
> 
> Task is done.

multi_v7_defconfig and ARMv8's defconfig are bloated monoliths which
provide limited flexibility.  Good for testing and messing around -
not much good for real products.

> Please be more specific about use case and describe what exactly in
> current upstream multiplatform kernel is missing, what is not
> multiplatform enough.

The use-case is GKI.  A realistic middle-ground between fully open
source and real-world usage of the Linux kernel in a competitive
technical arena.  GKI aims to be as close to Mainline as possible,
whilst allowing hardware vendors to supply their own software
containing their perceived competitive edge and/or supporting
not-yet-released hardware platforms.

If you end up over-constraining the ability to configure the kernel in
useful/meaningful ways, that makes one of the main (best intention)
aims of GKI, (i.e. to have an upstream first ethos in order to be as
close to upstream as possible) much more difficult.

I put in a lot of effort to ensure GKI doesn't end up as just another
fork of the Linux kernel.  So far, so good, but flexibility and
understanding is key.

> > I'm sorry I added confusion by mentioning
> > modularization. All of these drivers that I am modifying in this
> > series can be modularized which is an ongoing effort, but is not
> > addressed here and I don't believe that modularizing them should be a
> > requirement before supporting enabling/disabling them.
> 
> Since the disabling the driver for a kernel supporting Exynos does not
> make any sense, then making it at least modular unfortunately it is a
> requirement.

I can go with that.

> > I will update the series with my patch that refactors the Samsung SoC
> > drivers menuconfig to make these visible as well.
> 
> I would first recommend to really describe your use case because my
> questions about this are still unanswered.

Hopefully my replies have helped somewhat.

Happy to discuss further if required.

If all else fails, feel free to ping me on IRC (lag).

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

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 21/09/2021 19:58, Will McVicker wrote:
> > On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@canonical.com> wrote:
> >>
> >> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> >>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> >>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> >>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> >>>>> or modularize this driver.
> >>>>
> >>>> The clock drivers are essential, you cannot disable them for a generic
> >>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
> >>>
> >>> Obviously it's not gonna work if the clock driver is not enabled
> >>> at all.  But does it work if you make the clock driver modular, and
> >>> put it with all other essential driver modules in initramfs?  Debugging
> >>> would be hard, as the serial console driver also relies on clocks
> >>> and PM Domains etc.
> >>
> >> The kernel could boot without clock drivers (default settings from
> >> bootloader), probe clocks from initramfs and proceed with rootfs from
> >> eMMC/SD/net.
> >>
> >> In theory.
> >>
> >> However I have no reports that it ever worked. If there is such working
> >> upstream configuration, I don't mind here. Just please explain this in
> >> the commit msg.
> >>
> >>>
> >>> If not, this patch should be NAKed, until it works with a modular
> >>> clock driver.
> >>>
> >>> If yes, perhaps another line should be added (_before_ the other line)?
> >>>
> >>>   + default m if ARCH_EXYNOS && MODULES
> >>>     default y if ARCH_EXYNOS
> >>>
> >>> However, many developers may want MODULES=y, but not want to bother
> >>> with an initramfs.  So perhaps we need a new symbol
> >>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
> >>> driver default to m if that is enabled?
> >>
> >> Yeah, that's indeed a problem to solve. For most users (and distros)
> >> building kernel for Exynos this should be built-in by default.
> >>
> >> Anyway, the option is non-selectable so it cannot be converted to "m" or
> >> disabled. And this is claimed in the commit msg:
> >> "provide flexibilty for vendors to disable or modularize this driver."
> >>
> >> The commit does not achieve it.
> >>
> >> Best regards,
> >> Krzysztof
> > 
> > Thanks for the reviews! As Lee has explained in his replies, the
> > intent of this series is to provide config flexibility to create a
> > defconfig that allows us to move out SoC specific drivers in order to
> > create a generic kernel that can be used across multiple devices with
> > different SoCs.
> 
> That's quite generic statement... or let me put it that way - we already
> have this ability to create a generic kernel supporting different SoCs.
> Exynos and other ARMv7 and ARMv8 platforms are multiplatform.
> 
> Task is done.

multi_v7_defconfig and ARMv8's defconfig are bloated monoliths which
provide limited flexibility.  Good for testing and messing around -
not much good for real products.

> Please be more specific about use case and describe what exactly in
> current upstream multiplatform kernel is missing, what is not
> multiplatform enough.

The use-case is GKI.  A realistic middle-ground between fully open
source and real-world usage of the Linux kernel in a competitive
technical arena.  GKI aims to be as close to Mainline as possible,
whilst allowing hardware vendors to supply their own software
containing their perceived competitive edge and/or supporting
not-yet-released hardware platforms.

If you end up over-constraining the ability to configure the kernel in
useful/meaningful ways, that makes one of the main (best intention)
aims of GKI, (i.e. to have an upstream first ethos in order to be as
close to upstream as possible) much more difficult.

I put in a lot of effort to ensure GKI doesn't end up as just another
fork of the Linux kernel.  So far, so good, but flexibility and
understanding is key.

> > I'm sorry I added confusion by mentioning
> > modularization. All of these drivers that I am modifying in this
> > series can be modularized which is an ongoing effort, but is not
> > addressed here and I don't believe that modularizing them should be a
> > requirement before supporting enabling/disabling them.
> 
> Since the disabling the driver for a kernel supporting Exynos does not
> make any sense, then making it at least modular unfortunately it is a
> requirement.

I can go with that.

> > I will update the series with my patch that refactors the Samsung SoC
> > drivers menuconfig to make these visible as well.
> 
> I would first recommend to really describe your use case because my
> questions about this are still unanswered.

Hopefully my replies have helped somewhat.

Happy to discuss further if required.

If all else fails, feel free to ping me on IRC (lag).

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 23/09/2021 14:57, Lee Jones wrote:
> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> 
>> On 21/09/2021 19:58, Will McVicker wrote:
>>> On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@canonical.com> wrote:
>>>>
>>>> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
>>>>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
>>>>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
>>>>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
>>>>>>> or modularize this driver.
>>>>>>
>>>>>> The clock drivers are essential, you cannot disable them for a generic
>>>>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
>>>>>
>>>>> Obviously it's not gonna work if the clock driver is not enabled
>>>>> at all.  But does it work if you make the clock driver modular, and
>>>>> put it with all other essential driver modules in initramfs?  Debugging
>>>>> would be hard, as the serial console driver also relies on clocks
>>>>> and PM Domains etc.
>>>>
>>>> The kernel could boot without clock drivers (default settings from
>>>> bootloader), probe clocks from initramfs and proceed with rootfs from
>>>> eMMC/SD/net.
>>>>
>>>> In theory.
>>>>
>>>> However I have no reports that it ever worked. If there is such working
>>>> upstream configuration, I don't mind here. Just please explain this in
>>>> the commit msg.
>>>>
>>>>>
>>>>> If not, this patch should be NAKed, until it works with a modular
>>>>> clock driver.
>>>>>
>>>>> If yes, perhaps another line should be added (_before_ the other line)?
>>>>>
>>>>>   + default m if ARCH_EXYNOS && MODULES
>>>>>     default y if ARCH_EXYNOS
>>>>>
>>>>> However, many developers may want MODULES=y, but not want to bother
>>>>> with an initramfs.  So perhaps we need a new symbol
>>>>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
>>>>> driver default to m if that is enabled?
>>>>
>>>> Yeah, that's indeed a problem to solve. For most users (and distros)
>>>> building kernel for Exynos this should be built-in by default.
>>>>
>>>> Anyway, the option is non-selectable so it cannot be converted to "m" or
>>>> disabled. And this is claimed in the commit msg:
>>>> "provide flexibilty for vendors to disable or modularize this driver."
>>>>
>>>> The commit does not achieve it.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>
>>> Thanks for the reviews! As Lee has explained in his replies, the
>>> intent of this series is to provide config flexibility to create a
>>> defconfig that allows us to move out SoC specific drivers in order to
>>> create a generic kernel that can be used across multiple devices with
>>> different SoCs.
>>
>> That's quite generic statement... or let me put it that way - we already
>> have this ability to create a generic kernel supporting different SoCs.
>> Exynos and other ARMv7 and ARMv8 platforms are multiplatform.
>>
>> Task is done.
> 
> multi_v7_defconfig and ARMv8's defconfig are bloated monoliths which
> provide limited flexibility.  Good for testing and messing around -
> not much good for real products.

I am not saying about defconfigs. I am saying that ARMv8 platform is
multiplatform so we already solved the problem Will mentioned. :)

> 
>> Please be more specific about use case and describe what exactly in
>> current upstream multiplatform kernel is missing, what is not
>> multiplatform enough.
> 
> The use-case is GKI.  A realistic middle-ground between fully open
> source and real-world usage of the Linux kernel in a competitive
> technical arena.  GKI aims to be as close to Mainline as possible,
> whilst allowing hardware vendors to supply their own software
> containing their perceived competitive edge and/or supporting
> not-yet-released hardware platforms.

<grumpy mode>
Therefore the use case is to not contribute anything upstream around
ARCH_EXYNOS but use it in millions of devices downstream with hundreds
of out-of-tree modules. The use case is to make life easy for the vendor
and out-of-tree code, not for the upstream. Instead of promoting
upstreaming, or leaning towards usptream in some balanced way, the use
case is to entirely go to out-of-tree.

I am not thinking here about edge or not-yet-released platforms but
"ancient" in terms of current SoC business, e.g. 3-5 years old.
</grumpy mode>

> 
> If you end up over-constraining the ability to configure the kernel in
> useful/meaningful ways, that makes one of the main (best intention)
> aims of GKI, (i.e. to have an upstream first ethos in order to be as
> close to upstream as possible) much more difficult.

GKI encourages core kernel changes to be upstreamed but it is
effectively the nail in the coffin of upstreaming vendor SoC changes.
There is simply no incentive for less-cooperative vendor to upstream
it's modules (except usual benefits like code quality and user support
which are not important for less-cooperative vendors).

The kernel should be configured mainly towards mainline platforms. Not
the other way around. This of course does not stop it for supporting
out-of-tree code, but I guess you also know that what's out-of-tree, it
does not exist. :)

> 
> I put in a lot of effort to ensure GKI doesn't end up as just another
> fork of the Linux kernel.  So far, so good, but flexibility and
> understanding is key.
> 
>>> I'm sorry I added confusion by mentioning
>>> modularization. All of these drivers that I am modifying in this
>>> series can be modularized which is an ongoing effort, but is not
>>> addressed here and I don't believe that modularizing them should be a
>>> requirement before supporting enabling/disabling them.
>>
>> Since the disabling the driver for a kernel supporting Exynos does not
>> make any sense, then making it at least modular unfortunately it is a
>> requirement.
> 
> I can go with that.
> 
>>> I will update the series with my patch that refactors the Samsung SoC
>>> drivers menuconfig to make these visible as well.
>>
>> I would first recommend to really describe your use case because my
>> questions about this are still unanswered.
> 
> Hopefully my replies have helped somewhat.
> 
> Happy to discuss further if required.
> 
> If all else fails, feel free to ping me on IRC (lag).

Thanks Lee, you described the use case. In general I like it and support
it, except for what I wrote in the other mail.

Vendor does not contribute much therefore there is no balance in
upstreaming. Since none of other vendor's platforms are supported, I am
looking only at what is supported. From that perspective - the change
proposed by Will and previous guys, does not have much sense.

My perspective probably would change a lot if vendor did contribute some
of its non-edge platforms (3-5 years old)... especially that unlike few
community guys (e.g. PostmarketOS), vendor has shit-tons of money and
the hardware manuals. :)

Instead of pushing this change, please let's give some incentive to the
vendor for upstreaming anything.

Best regards,
Krzysztof

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 23/09/2021 14:57, Lee Jones wrote:
> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> 
>> On 21/09/2021 19:58, Will McVicker wrote:
>>> On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@canonical.com> wrote:
>>>>
>>>> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
>>>>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
>>>>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
>>>>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
>>>>>>> or modularize this driver.
>>>>>>
>>>>>> The clock drivers are essential, you cannot disable them for a generic
>>>>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
>>>>>
>>>>> Obviously it's not gonna work if the clock driver is not enabled
>>>>> at all.  But does it work if you make the clock driver modular, and
>>>>> put it with all other essential driver modules in initramfs?  Debugging
>>>>> would be hard, as the serial console driver also relies on clocks
>>>>> and PM Domains etc.
>>>>
>>>> The kernel could boot without clock drivers (default settings from
>>>> bootloader), probe clocks from initramfs and proceed with rootfs from
>>>> eMMC/SD/net.
>>>>
>>>> In theory.
>>>>
>>>> However I have no reports that it ever worked. If there is such working
>>>> upstream configuration, I don't mind here. Just please explain this in
>>>> the commit msg.
>>>>
>>>>>
>>>>> If not, this patch should be NAKed, until it works with a modular
>>>>> clock driver.
>>>>>
>>>>> If yes, perhaps another line should be added (_before_ the other line)?
>>>>>
>>>>>   + default m if ARCH_EXYNOS && MODULES
>>>>>     default y if ARCH_EXYNOS
>>>>>
>>>>> However, many developers may want MODULES=y, but not want to bother
>>>>> with an initramfs.  So perhaps we need a new symbol
>>>>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
>>>>> driver default to m if that is enabled?
>>>>
>>>> Yeah, that's indeed a problem to solve. For most users (and distros)
>>>> building kernel for Exynos this should be built-in by default.
>>>>
>>>> Anyway, the option is non-selectable so it cannot be converted to "m" or
>>>> disabled. And this is claimed in the commit msg:
>>>> "provide flexibilty for vendors to disable or modularize this driver."
>>>>
>>>> The commit does not achieve it.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>
>>> Thanks for the reviews! As Lee has explained in his replies, the
>>> intent of this series is to provide config flexibility to create a
>>> defconfig that allows us to move out SoC specific drivers in order to
>>> create a generic kernel that can be used across multiple devices with
>>> different SoCs.
>>
>> That's quite generic statement... or let me put it that way - we already
>> have this ability to create a generic kernel supporting different SoCs.
>> Exynos and other ARMv7 and ARMv8 platforms are multiplatform.
>>
>> Task is done.
> 
> multi_v7_defconfig and ARMv8's defconfig are bloated monoliths which
> provide limited flexibility.  Good for testing and messing around -
> not much good for real products.

I am not saying about defconfigs. I am saying that ARMv8 platform is
multiplatform so we already solved the problem Will mentioned. :)

> 
>> Please be more specific about use case and describe what exactly in
>> current upstream multiplatform kernel is missing, what is not
>> multiplatform enough.
> 
> The use-case is GKI.  A realistic middle-ground between fully open
> source and real-world usage of the Linux kernel in a competitive
> technical arena.  GKI aims to be as close to Mainline as possible,
> whilst allowing hardware vendors to supply their own software
> containing their perceived competitive edge and/or supporting
> not-yet-released hardware platforms.

<grumpy mode>
Therefore the use case is to not contribute anything upstream around
ARCH_EXYNOS but use it in millions of devices downstream with hundreds
of out-of-tree modules. The use case is to make life easy for the vendor
and out-of-tree code, not for the upstream. Instead of promoting
upstreaming, or leaning towards usptream in some balanced way, the use
case is to entirely go to out-of-tree.

I am not thinking here about edge or not-yet-released platforms but
"ancient" in terms of current SoC business, e.g. 3-5 years old.
</grumpy mode>

> 
> If you end up over-constraining the ability to configure the kernel in
> useful/meaningful ways, that makes one of the main (best intention)
> aims of GKI, (i.e. to have an upstream first ethos in order to be as
> close to upstream as possible) much more difficult.

GKI encourages core kernel changes to be upstreamed but it is
effectively the nail in the coffin of upstreaming vendor SoC changes.
There is simply no incentive for less-cooperative vendor to upstream
it's modules (except usual benefits like code quality and user support
which are not important for less-cooperative vendors).

The kernel should be configured mainly towards mainline platforms. Not
the other way around. This of course does not stop it for supporting
out-of-tree code, but I guess you also know that what's out-of-tree, it
does not exist. :)

> 
> I put in a lot of effort to ensure GKI doesn't end up as just another
> fork of the Linux kernel.  So far, so good, but flexibility and
> understanding is key.
> 
>>> I'm sorry I added confusion by mentioning
>>> modularization. All of these drivers that I am modifying in this
>>> series can be modularized which is an ongoing effort, but is not
>>> addressed here and I don't believe that modularizing them should be a
>>> requirement before supporting enabling/disabling them.
>>
>> Since the disabling the driver for a kernel supporting Exynos does not
>> make any sense, then making it at least modular unfortunately it is a
>> requirement.
> 
> I can go with that.
> 
>>> I will update the series with my patch that refactors the Samsung SoC
>>> drivers menuconfig to make these visible as well.
>>
>> I would first recommend to really describe your use case because my
>> questions about this are still unanswered.
> 
> Hopefully my replies have helped somewhat.
> 
> Happy to discuss further if required.
> 
> If all else fails, feel free to ping me on IRC (lag).

Thanks Lee, you described the use case. In general I like it and support
it, except for what I wrote in the other mail.

Vendor does not contribute much therefore there is no balance in
upstreaming. Since none of other vendor's platforms are supported, I am
looking only at what is supported. From that perspective - the change
proposed by Will and previous guys, does not have much sense.

My perspective probably would change a lot if vendor did contribute some
of its non-edge platforms (3-5 years old)... especially that unlike few
community guys (e.g. PostmarketOS), vendor has shit-tons of money and
the hardware manuals. :)

Instead of pushing this change, please let's give some incentive to the
vendor for upstreaming anything.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Lee Jones]

On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:

> On 23/09/2021 14:57, Lee Jones wrote:
> > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> > 
> >> On 21/09/2021 19:58, Will McVicker wrote:
> >>> On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@canonical.com> wrote:
> >>>>
> >>>> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> >>>>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>>>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> >>>>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> >>>>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> >>>>>>> or modularize this driver.
> >>>>>>
> >>>>>> The clock drivers are essential, you cannot disable them for a generic
> >>>>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
> >>>>>
> >>>>> Obviously it's not gonna work if the clock driver is not enabled
> >>>>> at all.  But does it work if you make the clock driver modular, and
> >>>>> put it with all other essential driver modules in initramfs?  Debugging
> >>>>> would be hard, as the serial console driver also relies on clocks
> >>>>> and PM Domains etc.
> >>>>
> >>>> The kernel could boot without clock drivers (default settings from
> >>>> bootloader), probe clocks from initramfs and proceed with rootfs from
> >>>> eMMC/SD/net.
> >>>>
> >>>> In theory.
> >>>>
> >>>> However I have no reports that it ever worked. If there is such working
> >>>> upstream configuration, I don't mind here. Just please explain this in
> >>>> the commit msg.
> >>>>
> >>>>>
> >>>>> If not, this patch should be NAKed, until it works with a modular
> >>>>> clock driver.
> >>>>>
> >>>>> If yes, perhaps another line should be added (_before_ the other line)?
> >>>>>
> >>>>>   + default m if ARCH_EXYNOS && MODULES
> >>>>>     default y if ARCH_EXYNOS
> >>>>>
> >>>>> However, many developers may want MODULES=y, but not want to bother
> >>>>> with an initramfs.  So perhaps we need a new symbol
> >>>>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
> >>>>> driver default to m if that is enabled?
> >>>>
> >>>> Yeah, that's indeed a problem to solve. For most users (and distros)
> >>>> building kernel for Exynos this should be built-in by default.
> >>>>
> >>>> Anyway, the option is non-selectable so it cannot be converted to "m" or
> >>>> disabled. And this is claimed in the commit msg:
> >>>> "provide flexibilty for vendors to disable or modularize this driver."
> >>>>
> >>>> The commit does not achieve it.
> >>>>
> >>>> Best regards,
> >>>> Krzysztof
> >>>
> >>> Thanks for the reviews! As Lee has explained in his replies, the
> >>> intent of this series is to provide config flexibility to create a
> >>> defconfig that allows us to move out SoC specific drivers in order to
> >>> create a generic kernel that can be used across multiple devices with
> >>> different SoCs.
> >>
> >> That's quite generic statement... or let me put it that way - we already
> >> have this ability to create a generic kernel supporting different SoCs.
> >> Exynos and other ARMv7 and ARMv8 platforms are multiplatform.
> >>
> >> Task is done.
> > 
> > multi_v7_defconfig and ARMv8's defconfig are bloated monoliths which
> > provide limited flexibility.  Good for testing and messing around -
> > not much good for real products.
> 
> I am not saying about defconfigs. I am saying that ARMv8 platform is
> multiplatform so we already solved the problem Will mentioned. :)
> 
> > 
> >> Please be more specific about use case and describe what exactly in
> >> current upstream multiplatform kernel is missing, what is not
> >> multiplatform enough.
> > 
> > The use-case is GKI.  A realistic middle-ground between fully open
> > source and real-world usage of the Linux kernel in a competitive
> > technical arena.  GKI aims to be as close to Mainline as possible,
> > whilst allowing hardware vendors to supply their own software
> > containing their perceived competitive edge and/or supporting
> > not-yet-released hardware platforms.
> 
> <grumpy mode>
> Therefore the use case is to not contribute anything upstream around
> ARCH_EXYNOS but use it in millions of devices downstream with hundreds
> of out-of-tree modules. The use case is to make life easy for the vendor
> and out-of-tree code, not for the upstream. Instead of promoting
> upstreaming, or leaning towards usptream in some balanced way, the use
> case is to entirely go to out-of-tree.
> 
> I am not thinking here about edge or not-yet-released platforms but
> "ancient" in terms of current SoC business, e.g. 3-5 years old.
> </grumpy mode>
> 
> > 
> > If you end up over-constraining the ability to configure the kernel in
> > useful/meaningful ways, that makes one of the main (best intention)
> > aims of GKI, (i.e. to have an upstream first ethos in order to be as
> > close to upstream as possible) much more difficult.
> 
> GKI encourages core kernel changes to be upstreamed but it is
> effectively the nail in the coffin of upstreaming vendor SoC changes.
> There is simply no incentive for less-cooperative vendor to upstream
> it's modules (except usual benefits like code quality and user support
> which are not important for less-cooperative vendors).
> 
> The kernel should be configured mainly towards mainline platforms. Not
> the other way around. This of course does not stop it for supporting
> out-of-tree code, but I guess you also know that what's out-of-tree, it
> does not exist. :)

I'm not sure you've thought the above points through. :)

How is that any of this different to Mainline?

So long as you have the headers for the kernel you wish to compile
against, you can create all the new modules you like in both cases.

> > I put in a lot of effort to ensure GKI doesn't end up as just another
> > fork of the Linux kernel.  So far, so good, but flexibility and
> > understanding is key.
> > 
> >>> I'm sorry I added confusion by mentioning
> >>> modularization. All of these drivers that I am modifying in this
> >>> series can be modularized which is an ongoing effort, but is not
> >>> addressed here and I don't believe that modularizing them should be a
> >>> requirement before supporting enabling/disabling them.
> >>
> >> Since the disabling the driver for a kernel supporting Exynos does not
> >> make any sense, then making it at least modular unfortunately it is a
> >> requirement.
> > 
> > I can go with that.
> > 
> >>> I will update the series with my patch that refactors the Samsung SoC
> >>> drivers menuconfig to make these visible as well.
> >>
> >> I would first recommend to really describe your use case because my
> >> questions about this are still unanswered.
> > 
> > Hopefully my replies have helped somewhat.
> > 
> > Happy to discuss further if required.
> > 
> > If all else fails, feel free to ping me on IRC (lag).
> 
> Thanks Lee, you described the use case. In general I like it and support
> it, except for what I wrote in the other mail.
> 
> Vendor does not contribute much therefore there is no balance in
> upstreaming. Since none of other vendor's platforms are supported, I am
> looking only at what is supported. From that perspective - the change
> proposed by Will and previous guys, does not have much sense.
> 
> My perspective probably would change a lot if vendor did contribute some
> of its non-edge platforms (3-5 years old)... especially that unlike few
> community guys (e.g. PostmarketOS), vendor has shit-tons of money and
> the hardware manuals. :)

But no incentive to upstream code old (dead) platforms that they no
longer make money from.  We're not talking about kind-hearted
individuals here.  These are business entities.

What is the business incentive to put hundreds of thousands of dollars
into something with no RoI?

> Instead of pushing this change, please let's give some incentive to the
> vendor for upstreaming anything.

Again, you're being specific.  We would also like/need to make the
same kinds of changes to other vendor configurations.  One's which do
contribute significantly at their own cost.

The technical reasoning cannot be different because you do or don't
like the way the company operates.  Try to detach a little from
your feelings during discussions which should be purely technical.

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

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Lee Jones]

On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:

> On 23/09/2021 14:57, Lee Jones wrote:
> > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> > 
> >> On 21/09/2021 19:58, Will McVicker wrote:
> >>> On Tue, Sep 21, 2021 at 1:35 AM Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@canonical.com> wrote:
> >>>>
> >>>> On 21/09/2021 09:50, Geert Uytterhoeven wrote:
> >>>>> On Tue, Sep 21, 2021 at 9:31 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>>>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>>>>> COMMON_CLK_SAMSUNG is selected by ARCH_EXYNOS which forces this config
> >>>>>>> to be built-in when ARCH_EXYNOS is enabled. Switch the logic to use a
> >>>>>>> "default y if ARCH_EXYNOS" to provide flexibilty for vendors to disable
> >>>>>>> or modularize this driver.
> >>>>>>
> >>>>>> The clock drivers are essential, you cannot disable them for a generic
> >>>>>> kernel supporting ARCH_EXYNOS. Such kernel won't work properly on platforms.
> >>>>>
> >>>>> Obviously it's not gonna work if the clock driver is not enabled
> >>>>> at all.  But does it work if you make the clock driver modular, and
> >>>>> put it with all other essential driver modules in initramfs?  Debugging
> >>>>> would be hard, as the serial console driver also relies on clocks
> >>>>> and PM Domains etc.
> >>>>
> >>>> The kernel could boot without clock drivers (default settings from
> >>>> bootloader), probe clocks from initramfs and proceed with rootfs from
> >>>> eMMC/SD/net.
> >>>>
> >>>> In theory.
> >>>>
> >>>> However I have no reports that it ever worked. If there is such working
> >>>> upstream configuration, I don't mind here. Just please explain this in
> >>>> the commit msg.
> >>>>
> >>>>>
> >>>>> If not, this patch should be NAKed, until it works with a modular
> >>>>> clock driver.
> >>>>>
> >>>>> If yes, perhaps another line should be added (_before_ the other line)?
> >>>>>
> >>>>>   + default m if ARCH_EXYNOS && MODULES
> >>>>>     default y if ARCH_EXYNOS
> >>>>>
> >>>>> However, many developers may want MODULES=y, but not want to bother
> >>>>> with an initramfs.  So perhaps we need a new symbol
> >>>>> MINIMUM_GENERIC_KERNEL or so, protected by EXPERT, and make the
> >>>>> driver default to m if that is enabled?
> >>>>
> >>>> Yeah, that's indeed a problem to solve. For most users (and distros)
> >>>> building kernel for Exynos this should be built-in by default.
> >>>>
> >>>> Anyway, the option is non-selectable so it cannot be converted to "m" or
> >>>> disabled. And this is claimed in the commit msg:
> >>>> "provide flexibilty for vendors to disable or modularize this driver."
> >>>>
> >>>> The commit does not achieve it.
> >>>>
> >>>> Best regards,
> >>>> Krzysztof
> >>>
> >>> Thanks for the reviews! As Lee has explained in his replies, the
> >>> intent of this series is to provide config flexibility to create a
> >>> defconfig that allows us to move out SoC specific drivers in order to
> >>> create a generic kernel that can be used across multiple devices with
> >>> different SoCs.
> >>
> >> That's quite generic statement... or let me put it that way - we already
> >> have this ability to create a generic kernel supporting different SoCs.
> >> Exynos and other ARMv7 and ARMv8 platforms are multiplatform.
> >>
> >> Task is done.
> > 
> > multi_v7_defconfig and ARMv8's defconfig are bloated monoliths which
> > provide limited flexibility.  Good for testing and messing around -
> > not much good for real products.
> 
> I am not saying about defconfigs. I am saying that ARMv8 platform is
> multiplatform so we already solved the problem Will mentioned. :)
> 
> > 
> >> Please be more specific about use case and describe what exactly in
> >> current upstream multiplatform kernel is missing, what is not
> >> multiplatform enough.
> > 
> > The use-case is GKI.  A realistic middle-ground between fully open
> > source and real-world usage of the Linux kernel in a competitive
> > technical arena.  GKI aims to be as close to Mainline as possible,
> > whilst allowing hardware vendors to supply their own software
> > containing their perceived competitive edge and/or supporting
> > not-yet-released hardware platforms.
> 
> <grumpy mode>
> Therefore the use case is to not contribute anything upstream around
> ARCH_EXYNOS but use it in millions of devices downstream with hundreds
> of out-of-tree modules. The use case is to make life easy for the vendor
> and out-of-tree code, not for the upstream. Instead of promoting
> upstreaming, or leaning towards usptream in some balanced way, the use
> case is to entirely go to out-of-tree.
> 
> I am not thinking here about edge or not-yet-released platforms but
> "ancient" in terms of current SoC business, e.g. 3-5 years old.
> </grumpy mode>
> 
> > 
> > If you end up over-constraining the ability to configure the kernel in
> > useful/meaningful ways, that makes one of the main (best intention)
> > aims of GKI, (i.e. to have an upstream first ethos in order to be as
> > close to upstream as possible) much more difficult.
> 
> GKI encourages core kernel changes to be upstreamed but it is
> effectively the nail in the coffin of upstreaming vendor SoC changes.
> There is simply no incentive for less-cooperative vendor to upstream
> it's modules (except usual benefits like code quality and user support
> which are not important for less-cooperative vendors).
> 
> The kernel should be configured mainly towards mainline platforms. Not
> the other way around. This of course does not stop it for supporting
> out-of-tree code, but I guess you also know that what's out-of-tree, it
> does not exist. :)

I'm not sure you've thought the above points through. :)

How is that any of this different to Mainline?

So long as you have the headers for the kernel you wish to compile
against, you can create all the new modules you like in both cases.

> > I put in a lot of effort to ensure GKI doesn't end up as just another
> > fork of the Linux kernel.  So far, so good, but flexibility and
> > understanding is key.
> > 
> >>> I'm sorry I added confusion by mentioning
> >>> modularization. All of these drivers that I am modifying in this
> >>> series can be modularized which is an ongoing effort, but is not
> >>> addressed here and I don't believe that modularizing them should be a
> >>> requirement before supporting enabling/disabling them.
> >>
> >> Since the disabling the driver for a kernel supporting Exynos does not
> >> make any sense, then making it at least modular unfortunately it is a
> >> requirement.
> > 
> > I can go with that.
> > 
> >>> I will update the series with my patch that refactors the Samsung SoC
> >>> drivers menuconfig to make these visible as well.
> >>
> >> I would first recommend to really describe your use case because my
> >> questions about this are still unanswered.
> > 
> > Hopefully my replies have helped somewhat.
> > 
> > Happy to discuss further if required.
> > 
> > If all else fails, feel free to ping me on IRC (lag).
> 
> Thanks Lee, you described the use case. In general I like it and support
> it, except for what I wrote in the other mail.
> 
> Vendor does not contribute much therefore there is no balance in
> upstreaming. Since none of other vendor's platforms are supported, I am
> looking only at what is supported. From that perspective - the change
> proposed by Will and previous guys, does not have much sense.
> 
> My perspective probably would change a lot if vendor did contribute some
> of its non-edge platforms (3-5 years old)... especially that unlike few
> community guys (e.g. PostmarketOS), vendor has shit-tons of money and
> the hardware manuals. :)

But no incentive to upstream code old (dead) platforms that they no
longer make money from.  We're not talking about kind-hearted
individuals here.  These are business entities.

What is the business incentive to put hundreds of thousands of dollars
into something with no RoI?

> Instead of pushing this change, please let's give some incentive to the
> vendor for upstreaming anything.

Again, you're being specific.  We would also like/need to make the
same kinds of changes to other vendor configurations.  One's which do
contribute significantly at their own cost.

The technical reasoning cannot be different because you do or don't
like the way the company operates.  Try to detach a little from
your feelings during discussions which should be purely technical.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 23/09/2021 16:18, Lee Jones wrote:
>> Thanks Lee, you described the use case. In general I like it and support
>> it, except for what I wrote in the other mail.
>>
>> Vendor does not contribute much therefore there is no balance in
>> upstreaming. Since none of other vendor's platforms are supported, I am
>> looking only at what is supported. From that perspective - the change
>> proposed by Will and previous guys, does not have much sense.
>>
>> My perspective probably would change a lot if vendor did contribute some
>> of its non-edge platforms (3-5 years old)... especially that unlike few
>> community guys (e.g. PostmarketOS), vendor has shit-tons of money and
>> the hardware manuals. :)
> 
> But no incentive to upstream code old (dead) platforms that they no
> longer make money from.  We're not talking about kind-hearted
> individuals here.  These are business entities.
> 
> What is the business incentive to put hundreds of thousands of dollars
> into something with no RoI?

Before you mentioned business entities refrain from upstreaming recent
hardware. You question upstreaming not that recent, so basically
business entity will claim it has zero incentives working with upstream.

Actually there are incentives for both cases - better code quality for
the pieces being base for future devices, selling mainline supported
hardware to other businesses, eventually less work for themselves around
keeping code in sync with mainline. All these are of course difficult to
measure from business perspective.

> 
>> Instead of pushing this change, please let's give some incentive to the
>> vendor for upstreaming anything.
> 
> Again, you're being specific.  We would also like/need to make the
> same kinds of changes to other vendor configurations.  One's which do
> contribute significantly at their own cost.

Yes, I am specific because we talk here about specfic Kconfig changes
for one specific ARM sub-architecture. Same set of changes can be
applied to other SoCs and usually have more sense there because number
of upstream platforms is bigger.

If you have 10 different pinctrl drivers, you might decide to narrow the
defconfigs to subset of it. If you have 2-3, the extra complexity does
not matter and you just enable all of them. That's also decision we made
few years ago internally in Samsung.

> The technical reasoning cannot be different because you do or don't
> like the way the company operates.  Try to detach a little from
> your feelings during discussions which should be purely technical.

I mentioned the less-contributing vendor arguments because you said:

>> Vendors are not able to upstream all functionality right away

That's the side-topic in this discussion.

Technically, all supported Exynos platforms require selecting
ARCH_EXYNOS and require all drivers selected by ARCH_EXYNOS. If you
mention some unsupported out-of-tree platforms, which I cannot
audit/see/use, it is not a valid reason to change statement above. Make
them supported, available to audit and check and statement above stops
being valid.

Best regards,
Krzysztof

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 23/09/2021 16:18, Lee Jones wrote:
>> Thanks Lee, you described the use case. In general I like it and support
>> it, except for what I wrote in the other mail.
>>
>> Vendor does not contribute much therefore there is no balance in
>> upstreaming. Since none of other vendor's platforms are supported, I am
>> looking only at what is supported. From that perspective - the change
>> proposed by Will and previous guys, does not have much sense.
>>
>> My perspective probably would change a lot if vendor did contribute some
>> of its non-edge platforms (3-5 years old)... especially that unlike few
>> community guys (e.g. PostmarketOS), vendor has shit-tons of money and
>> the hardware manuals. :)
> 
> But no incentive to upstream code old (dead) platforms that they no
> longer make money from.  We're not talking about kind-hearted
> individuals here.  These are business entities.
> 
> What is the business incentive to put hundreds of thousands of dollars
> into something with no RoI?

Before you mentioned business entities refrain from upstreaming recent
hardware. You question upstreaming not that recent, so basically
business entity will claim it has zero incentives working with upstream.

Actually there are incentives for both cases - better code quality for
the pieces being base for future devices, selling mainline supported
hardware to other businesses, eventually less work for themselves around
keeping code in sync with mainline. All these are of course difficult to
measure from business perspective.

> 
>> Instead of pushing this change, please let's give some incentive to the
>> vendor for upstreaming anything.
> 
> Again, you're being specific.  We would also like/need to make the
> same kinds of changes to other vendor configurations.  One's which do
> contribute significantly at their own cost.

Yes, I am specific because we talk here about specfic Kconfig changes
for one specific ARM sub-architecture. Same set of changes can be
applied to other SoCs and usually have more sense there because number
of upstream platforms is bigger.

If you have 10 different pinctrl drivers, you might decide to narrow the
defconfigs to subset of it. If you have 2-3, the extra complexity does
not matter and you just enable all of them. That's also decision we made
few years ago internally in Samsung.

> The technical reasoning cannot be different because you do or don't
> like the way the company operates.  Try to detach a little from
> your feelings during discussions which should be purely technical.

I mentioned the less-contributing vendor arguments because you said:

>> Vendors are not able to upstream all functionality right away

That's the side-topic in this discussion.

Technically, all supported Exynos platforms require selecting
ARCH_EXYNOS and require all drivers selected by ARCH_EXYNOS. If you
mention some unsupported out-of-tree platforms, which I cannot
audit/see/use, it is not a valid reason to change statement above. Make
them supported, available to audit and check and statement above stops
being valid.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 23/09/2021 18:27, Krzysztof Kozlowski wrote:
> On 23/09/2021 16:18, Lee Jones wrote:
>>> Thanks Lee, you described the use case. In general I like it and support
>>> it, except for what I wrote in the other mail.
>>>
>>> Vendor does not contribute much therefore there is no balance in
>>> upstreaming. Since none of other vendor's platforms are supported, I am
>>> looking only at what is supported. From that perspective - the change
>>> proposed by Will and previous guys, does not have much sense.
>>>
>>> My perspective probably would change a lot if vendor did contribute some
>>> of its non-edge platforms (3-5 years old)... especially that unlike few
>>> community guys (e.g. PostmarketOS), vendor has shit-tons of money and
>>> the hardware manuals. :)
>>
>> But no incentive to upstream code old (dead) platforms that they no
>> longer make money from.  We're not talking about kind-hearted
>> individuals here.  These are business entities.
>>
>> What is the business incentive to put hundreds of thousands of dollars
>> into something with no RoI?
> 
> Before you mentioned business entities refrain from upstreaming recent
> hardware. You question upstreaming not that recent, so basically
> business entity will claim it has zero incentives working with upstream.

Uh, this looks unparseable, I lost some words. Let me write again that part:

Before you mentioned business entities refrain from upstreaming recent
hardware. You question now upstreaming not that recent hardware, so
basically business entity has no incentives to work at all with upstream
on any platform. Neither newest, nor slightly older.


> Actually there are incentives for both cases - better code quality for
> the pieces being base for future devices, selling mainline supported
> hardware to other businesses, eventually less work for themselves around
> keeping code in sync with mainline. All these are of course difficult to
> measure from business perspective.
> 
>>
>>> Instead of pushing this change, please let's give some incentive to the
>>> vendor for upstreaming anything.
>>
>> Again, you're being specific.  We would also like/need to make the
>> same kinds of changes to other vendor configurations.  One's which do
>> contribute significantly at their own cost.
> 
> Yes, I am specific because we talk here about specfic Kconfig changes
> for one specific ARM sub-architecture. Same set of changes can be
> applied to other SoCs and usually have more sense there because number
> of upstream platforms is bigger.
> 
> If you have 10 different pinctrl drivers, you might decide to narrow the
> defconfigs to subset of it. If you have 2-3, the extra complexity does
> not matter and you just enable all of them. That's also decision we made
> few years ago internally in Samsung.
> 
>> The technical reasoning cannot be different because you do or don't
>> like the way the company operates.  Try to detach a little from
>> your feelings during discussions which should be purely technical.
> 
> I mentioned the less-contributing vendor arguments because you said:
> 
>>> Vendors are not able to upstream all functionality right away
> 
> That's the side-topic in this discussion.
> 
> Technically, all supported Exynos platforms require selecting
> ARCH_EXYNOS and require all drivers selected by ARCH_EXYNOS. If you
> mention some unsupported out-of-tree platforms, which I cannot
> audit/see/use, it is not a valid reason to change statement above. Make
> them supported, available to audit and check and statement above stops
> being valid.
> 
> Best regards,
> Krzysztof
> 


Best regards,
Krzysztof

Re: [PATCH v1 1/4] clk: samsung: change COMMON_CLK_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 23/09/2021 18:27, Krzysztof Kozlowski wrote:
> On 23/09/2021 16:18, Lee Jones wrote:
>>> Thanks Lee, you described the use case. In general I like it and support
>>> it, except for what I wrote in the other mail.
>>>
>>> Vendor does not contribute much therefore there is no balance in
>>> upstreaming. Since none of other vendor's platforms are supported, I am
>>> looking only at what is supported. From that perspective - the change
>>> proposed by Will and previous guys, does not have much sense.
>>>
>>> My perspective probably would change a lot if vendor did contribute some
>>> of its non-edge platforms (3-5 years old)... especially that unlike few
>>> community guys (e.g. PostmarketOS), vendor has shit-tons of money and
>>> the hardware manuals. :)
>>
>> But no incentive to upstream code old (dead) platforms that they no
>> longer make money from.  We're not talking about kind-hearted
>> individuals here.  These are business entities.
>>
>> What is the business incentive to put hundreds of thousands of dollars
>> into something with no RoI?
> 
> Before you mentioned business entities refrain from upstreaming recent
> hardware. You question upstreaming not that recent, so basically
> business entity will claim it has zero incentives working with upstream.

Uh, this looks unparseable, I lost some words. Let me write again that part:

Before you mentioned business entities refrain from upstreaming recent
hardware. You question now upstreaming not that recent hardware, so
basically business entity has no incentives to work at all with upstream
on any platform. Neither newest, nor slightly older.


> Actually there are incentives for both cases - better code quality for
> the pieces being base for future devices, selling mainline supported
> hardware to other businesses, eventually less work for themselves around
> keeping code in sync with mainline. All these are of course difficult to
> measure from business perspective.
> 
>>
>>> Instead of pushing this change, please let's give some incentive to the
>>> vendor for upstreaming anything.
>>
>> Again, you're being specific.  We would also like/need to make the
>> same kinds of changes to other vendor configurations.  One's which do
>> contribute significantly at their own cost.
> 
> Yes, I am specific because we talk here about specfic Kconfig changes
> for one specific ARM sub-architecture. Same set of changes can be
> applied to other SoCs and usually have more sense there because number
> of upstream platforms is bigger.
> 
> If you have 10 different pinctrl drivers, you might decide to narrow the
> defconfigs to subset of it. If you have 2-3, the extra complexity does
> not matter and you just enable all of them. That's also decision we made
> few years ago internally in Samsung.
> 
>> The technical reasoning cannot be different because you do or don't
>> like the way the company operates.  Try to detach a little from
>> your feelings during discussions which should be purely technical.
> 
> I mentioned the less-contributing vendor arguments because you said:
> 
>>> Vendors are not able to upstream all functionality right away
> 
> That's the side-topic in this discussion.
> 
> Technically, all supported Exynos platforms require selecting
> ARCH_EXYNOS and require all drivers selected by ARCH_EXYNOS. If you
> mention some unsupported out-of-tree platforms, which I cannot
> audit/see/use, it is not a valid reason to change statement above. Make
> them supported, available to audit and check and statement above stops
> being valid.
> 
> Best regards,
> Krzysztof
> 


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Will McVicker]

Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
be enabled by default via "default y if ARCH_EXYNOS" versus being
selected by the ARCH_EXYNOS config directly. This allows vendors to
disable these configs if they wish and provides additional flexibility
to modularize them in the presence of a generic kernel.

There are no .config differences with this change. The configs
SOC_SAMSUNG, EXYNOS_CHIPID, EXYNOS_PM_DOMAINS, and EXYNOS_PMU still
remain enabled by default.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm64/Kconfig.platforms | 4 ----
 drivers/soc/samsung/Kconfig  | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 3a66ed43088d..6a006490c9b9 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -91,14 +91,10 @@ config ARCH_BRCMSTB
 
 config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
-	select EXYNOS_CHIPID
-	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
-	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
 	  This enables support for ARMv8 based Samsung Exynos SoC family.
 
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 5745d7e5908e..9402c02bc9de 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -4,6 +4,7 @@
 #
 menuconfig SOC_SAMSUNG
 	bool "Samsung SoC driver support" if COMPILE_TEST
+	default y if ARCH_EXYNOS
 
 if SOC_SAMSUNG
 
@@ -15,6 +16,7 @@ config EXYNOS_ASV_ARM
 config EXYNOS_CHIPID
 	bool "Exynos ChipID controller and ASV driver" if COMPILE_TEST
 	depends on ARCH_EXYNOS || COMPILE_TEST
+	default y if ARCH_EXYNOS
 	select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
 	select MFD_SYSCON
 	select SOC_BUS
@@ -24,6 +26,7 @@ config EXYNOS_CHIPID
 config EXYNOS_PMU
 	bool "Exynos PMU controller driver" if COMPILE_TEST
 	depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
+	default y if ARCH_EXYNOS
 	select EXYNOS_PMU_ARM_DRIVERS if ARM && ARCH_EXYNOS
 
 # There is no need to enable these drivers for ARMv8
@@ -34,6 +37,7 @@ config EXYNOS_PMU_ARM_DRIVERS
 config EXYNOS_PM_DOMAINS
 	bool "Exynos PM domains" if COMPILE_TEST
 	depends on (ARCH_EXYNOS && PM_GENERIC_DOMAINS) || COMPILE_TEST
+	default y if (ARCH_EXYNOS && PM_GENERIC_DOMAINS)
 
 config SAMSUNG_PM_DEBUG
 	bool "Samsung PM Suspend debug"
-- 
2.33.0.464.g1972c5931b-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Will McVicker]

Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
be enabled by default via "default y if ARCH_EXYNOS" versus being
selected by the ARCH_EXYNOS config directly. This allows vendors to
disable these configs if they wish and provides additional flexibility
to modularize them in the presence of a generic kernel.

There are no .config differences with this change. The configs
SOC_SAMSUNG, EXYNOS_CHIPID, EXYNOS_PM_DOMAINS, and EXYNOS_PMU still
remain enabled by default.

Signed-off-by: Will McVicker <willmcvicker@google.com>
---
 arch/arm64/Kconfig.platforms | 4 ----
 drivers/soc/samsung/Kconfig  | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 3a66ed43088d..6a006490c9b9 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -91,14 +91,10 @@ config ARCH_BRCMSTB
 
 config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
-	select EXYNOS_CHIPID
-	select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
-	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
 	  This enables support for ARMv8 based Samsung Exynos SoC family.
 
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 5745d7e5908e..9402c02bc9de 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -4,6 +4,7 @@
 #
 menuconfig SOC_SAMSUNG
 	bool "Samsung SoC driver support" if COMPILE_TEST
+	default y if ARCH_EXYNOS
 
 if SOC_SAMSUNG
 
@@ -15,6 +16,7 @@ config EXYNOS_ASV_ARM
 config EXYNOS_CHIPID
 	bool "Exynos ChipID controller and ASV driver" if COMPILE_TEST
 	depends on ARCH_EXYNOS || COMPILE_TEST
+	default y if ARCH_EXYNOS
 	select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
 	select MFD_SYSCON
 	select SOC_BUS
@@ -24,6 +26,7 @@ config EXYNOS_CHIPID
 config EXYNOS_PMU
 	bool "Exynos PMU controller driver" if COMPILE_TEST
 	depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
+	default y if ARCH_EXYNOS
 	select EXYNOS_PMU_ARM_DRIVERS if ARM && ARCH_EXYNOS
 
 # There is no need to enable these drivers for ARMv8
@@ -34,6 +37,7 @@ config EXYNOS_PMU_ARM_DRIVERS
 config EXYNOS_PM_DOMAINS
 	bool "Exynos PM domains" if COMPILE_TEST
 	depends on (ARCH_EXYNOS && PM_GENERIC_DOMAINS) || COMPILE_TEST
+	default y if (ARCH_EXYNOS && PM_GENERIC_DOMAINS)
 
 config SAMSUNG_PM_DEBUG
 	bool "Samsung PM Suspend debug"
-- 
2.33.0.464.g1972c5931b-goog

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Will McVicker]

On Mon, Sep 20, 2021 at 12:04 PM Will McVicker <willmcvicker@google.com> wrote:
>
> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> be enabled by default via "default y if ARCH_EXYNOS" versus being
> selected by the ARCH_EXYNOS config directly. This allows vendors to
> disable these configs if they wish and provides additional flexibility
> to modularize them in the presence of a generic kernel.
>
> There are no .config differences with this change. The configs
> SOC_SAMSUNG, EXYNOS_CHIPID, EXYNOS_PM_DOMAINS, and EXYNOS_PMU still
> remain enabled by default.
>
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms | 4 ----
>  drivers/soc/samsung/Kconfig  | 4 ++++
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 3a66ed43088d..6a006490c9b9 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -91,14 +91,10 @@ config ARCH_BRCMSTB
>
>  config ARCH_EXYNOS
>         bool "ARMv8 based Samsung Exynos SoC family"
> -       select EXYNOS_CHIPID
> -       select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
> -       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
>           This enables support for ARMv8 based Samsung Exynos SoC family.
>
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 5745d7e5908e..9402c02bc9de 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -4,6 +4,7 @@
>  #
>  menuconfig SOC_SAMSUNG
>         bool "Samsung SoC driver support" if COMPILE_TEST
> +       default y if ARCH_EXYNOS
>
>  if SOC_SAMSUNG
>
> @@ -15,6 +16,7 @@ config EXYNOS_ASV_ARM
>  config EXYNOS_CHIPID
>         bool "Exynos ChipID controller and ASV driver" if COMPILE_TEST
>         depends on ARCH_EXYNOS || COMPILE_TEST
> +       default y if ARCH_EXYNOS
>         select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
>         select MFD_SYSCON
>         select SOC_BUS
> @@ -24,6 +26,7 @@ config EXYNOS_CHIPID
>  config EXYNOS_PMU
>         bool "Exynos PMU controller driver" if COMPILE_TEST
>         depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
> +       default y if ARCH_EXYNOS
>         select EXYNOS_PMU_ARM_DRIVERS if ARM && ARCH_EXYNOS
>
>  # There is no need to enable these drivers for ARMv8
> @@ -34,6 +37,7 @@ config EXYNOS_PMU_ARM_DRIVERS
>  config EXYNOS_PM_DOMAINS
>         bool "Exynos PM domains" if COMPILE_TEST
>         depends on (ARCH_EXYNOS && PM_GENERIC_DOMAINS) || COMPILE_TEST
> +       default y if (ARCH_EXYNOS && PM_GENERIC_DOMAINS)
>
>  config SAMSUNG_PM_DEBUG
>         bool "Samsung PM Suspend debug"
> --
> 2.33.0.464.g1972c5931b-goog
>

Sorry I didn't see this patch sent yesterday:
https://lore.kernel.org/lkml/CAGOxZ50i6URzUQ7o7V4m7MR=2TqSeD6qx5fQaQDs+5nEq4fa2A@mail.gmail.com/

Looks like Krzysztof's patch covers my portion of the patch related to
EXYNOS_CHIPID. I'll keep an eye on his patch as it goes through and
will modify mine as needed since it's likely to come in after.

Thanks,
Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Will McVicker]

On Mon, Sep 20, 2021 at 12:04 PM Will McVicker <willmcvicker@google.com> wrote:
>
> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> be enabled by default via "default y if ARCH_EXYNOS" versus being
> selected by the ARCH_EXYNOS config directly. This allows vendors to
> disable these configs if they wish and provides additional flexibility
> to modularize them in the presence of a generic kernel.
>
> There are no .config differences with this change. The configs
> SOC_SAMSUNG, EXYNOS_CHIPID, EXYNOS_PM_DOMAINS, and EXYNOS_PMU still
> remain enabled by default.
>
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms | 4 ----
>  drivers/soc/samsung/Kconfig  | 4 ++++
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 3a66ed43088d..6a006490c9b9 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -91,14 +91,10 @@ config ARCH_BRCMSTB
>
>  config ARCH_EXYNOS
>         bool "ARMv8 based Samsung Exynos SoC family"
> -       select EXYNOS_CHIPID
> -       select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
> -       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
>           This enables support for ARMv8 based Samsung Exynos SoC family.
>
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 5745d7e5908e..9402c02bc9de 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -4,6 +4,7 @@
>  #
>  menuconfig SOC_SAMSUNG
>         bool "Samsung SoC driver support" if COMPILE_TEST
> +       default y if ARCH_EXYNOS
>
>  if SOC_SAMSUNG
>
> @@ -15,6 +16,7 @@ config EXYNOS_ASV_ARM
>  config EXYNOS_CHIPID
>         bool "Exynos ChipID controller and ASV driver" if COMPILE_TEST
>         depends on ARCH_EXYNOS || COMPILE_TEST
> +       default y if ARCH_EXYNOS
>         select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
>         select MFD_SYSCON
>         select SOC_BUS
> @@ -24,6 +26,7 @@ config EXYNOS_CHIPID
>  config EXYNOS_PMU
>         bool "Exynos PMU controller driver" if COMPILE_TEST
>         depends on ARCH_EXYNOS || ((ARM || ARM64) && COMPILE_TEST)
> +       default y if ARCH_EXYNOS
>         select EXYNOS_PMU_ARM_DRIVERS if ARM && ARCH_EXYNOS
>
>  # There is no need to enable these drivers for ARMv8
> @@ -34,6 +37,7 @@ config EXYNOS_PMU_ARM_DRIVERS
>  config EXYNOS_PM_DOMAINS
>         bool "Exynos PM domains" if COMPILE_TEST
>         depends on (ARCH_EXYNOS && PM_GENERIC_DOMAINS) || COMPILE_TEST
> +       default y if (ARCH_EXYNOS && PM_GENERIC_DOMAINS)
>
>  config SAMSUNG_PM_DEBUG
>         bool "Samsung PM Suspend debug"
> --
> 2.33.0.464.g1972c5931b-goog
>

Sorry I didn't see this patch sent yesterday:
https://lore.kernel.org/lkml/CAGOxZ50i6URzUQ7o7V4m7MR=2TqSeD6qx5fQaQDs+5nEq4fa2A@mail.gmail.com/

Looks like Krzysztof's patch covers my portion of the patch related to
EXYNOS_CHIPID. I'll keep an eye on his patch as it goes through and
will modify mine as needed since it's likely to come in after.

Thanks,
Will

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 20/09/2021 21:03, Will McVicker wrote:
> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> be enabled by default via "default y if ARCH_EXYNOS" versus being
> selected by the ARCH_EXYNOS config directly. This allows vendors to
> disable these configs if they wish and provides additional flexibility
> to modularize them in the presence of a generic kernel.

This is not true. Vendors cannot disable these options as they are not
visible. Although I understand that Arnd prefers this way and I do not
object it, but your explanation is incorrect.
> 
> There are no .config differences with this change. The configs
> SOC_SAMSUNG, EXYNOS_CHIPID, EXYNOS_PM_DOMAINS, and EXYNOS_PMU still
> remain enabled by default.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms | 4 ----
>  drivers/soc/samsung/Kconfig  | 4 ++++
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 3a66ed43088d..6a006490c9b9 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -91,14 +91,10 @@ config ARCH_BRCMSTB
>  
>  config ARCH_EXYNOS
>  	bool "ARMv8 based Samsung Exynos SoC family"
> -	select EXYNOS_CHIPID

This will conflict with:
https://lore.kernel.org/linux-samsung-soc/CAGOxZ50i6URzUQ7o7V4m7MR=2TqSeD6qx5fQaQDs+5nEq4fa2A@mail.gmail.com/T/#t

Build on top of it, please.


Best regards,
Krzysztof

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 20/09/2021 21:03, Will McVicker wrote:
> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> be enabled by default via "default y if ARCH_EXYNOS" versus being
> selected by the ARCH_EXYNOS config directly. This allows vendors to
> disable these configs if they wish and provides additional flexibility
> to modularize them in the presence of a generic kernel.

This is not true. Vendors cannot disable these options as they are not
visible. Although I understand that Arnd prefers this way and I do not
object it, but your explanation is incorrect.
> 
> There are no .config differences with this change. The configs
> SOC_SAMSUNG, EXYNOS_CHIPID, EXYNOS_PM_DOMAINS, and EXYNOS_PMU still
> remain enabled by default.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms | 4 ----
>  drivers/soc/samsung/Kconfig  | 4 ++++
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 3a66ed43088d..6a006490c9b9 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -91,14 +91,10 @@ config ARCH_BRCMSTB
>  
>  config ARCH_EXYNOS
>  	bool "ARMv8 based Samsung Exynos SoC family"
> -	select EXYNOS_CHIPID

This will conflict with:
https://lore.kernel.org/linux-samsung-soc/CAGOxZ50i6URzUQ7o7V4m7MR=2TqSeD6qx5fQaQDs+5nEq4fa2A@mail.gmail.com/T/#t

Build on top of it, please.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 20/09/2021 21:03, Will McVicker wrote:
> > Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> > be enabled by default via "default y if ARCH_EXYNOS" versus being
> > selected by the ARCH_EXYNOS config directly. This allows vendors to
> > disable these configs if they wish and provides additional flexibility
> > to modularize them in the presence of a generic kernel.
> 
> This is not true. Vendors cannot disable these options as they are not
> visible.

Good point, well made.

> Although I understand that Arnd prefers this way and I do not
> object it, but your explanation is incorrect.

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

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 20/09/2021 21:03, Will McVicker wrote:
> > Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> > be enabled by default via "default y if ARCH_EXYNOS" versus being
> > selected by the ARCH_EXYNOS config directly. This allows vendors to
> > disable these configs if they wish and provides additional flexibility
> > to modularize them in the presence of a generic kernel.
> 
> This is not true. Vendors cannot disable these options as they are not
> visible.

Good point, well made.

> Although I understand that Arnd prefers this way and I do not
> object it, but your explanation is incorrect.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Will McVicker]

On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
>
> > On 20/09/2021 21:03, Will McVicker wrote:
> > > Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> > > be enabled by default via "default y if ARCH_EXYNOS" versus being
> > > selected by the ARCH_EXYNOS config directly. This allows vendors to
> > > disable these configs if they wish and provides additional flexibility
> > > to modularize them in the presence of a generic kernel.
> >
> > This is not true. Vendors cannot disable these options as they are not
> > visible.
>
> Good point, well made.
>
> > Although I understand that Arnd prefers this way and I do not
> > object it, but your explanation is incorrect.

Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
configs" part. I'll upload the series to include the fix that refactos
the Samsung SoC drivers menuconfig which will address that and allow
one to enable/disable those configs. I'm going to hold off though
until we hash out the rest of the discussion in the cover letter
email.

Thanks,
Will

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

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Will McVicker]

On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
>
> > On 20/09/2021 21:03, Will McVicker wrote:
> > > Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> > > be enabled by default via "default y if ARCH_EXYNOS" versus being
> > > selected by the ARCH_EXYNOS config directly. This allows vendors to
> > > disable these configs if they wish and provides additional flexibility
> > > to modularize them in the presence of a generic kernel.
> >
> > This is not true. Vendors cannot disable these options as they are not
> > visible.
>
> Good point, well made.
>
> > Although I understand that Arnd prefers this way and I do not
> > object it, but your explanation is incorrect.

Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
configs" part. I'll upload the series to include the fix that refactos
the Samsung SoC drivers menuconfig which will address that and allow
one to enable/disable those configs. I'm going to hold off though
until we hash out the rest of the discussion in the cover letter
email.

Thanks,
Will

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 21/09/2021 19:45, Will McVicker wrote:
> On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
>>
>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
>>
>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
>>>> be enabled by default via "default y if ARCH_EXYNOS" versus being
>>>> selected by the ARCH_EXYNOS config directly. This allows vendors to
>>>> disable these configs if they wish and provides additional flexibility
>>>> to modularize them in the presence of a generic kernel.
>>>
>>> This is not true. Vendors cannot disable these options as they are not
>>> visible.
>>
>> Good point, well made.
>>
>>> Although I understand that Arnd prefers this way and I do not
>>> object it, but your explanation is incorrect.
> 
> Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
> configs" part. I'll upload the series to include the fix that refactos
> the Samsung SoC drivers menuconfig which will address that and allow
> one to enable/disable those configs. I'm going to hold off though
> until we hash out the rest of the discussion in the cover letter
> email.

No, please first read our discussions, including Lee's and Geert's
comments. The drivers should not be converted to modules or made visible
if such configuration does not work. If it works, please describe your
testing setup.

All these drivers are *necessary* for a multiplatform kernel supporting
Exynos platforms, therefore disabling them does not make any sense (if
you support Exynos platform). If your kernel does not support Exynos
platform, just do not select ARCH_EXYNOS and problem disappears because
none of these drivers will be visible and selected.

Unless you describe here some out-of-tree kernel which wants
ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
want existing Exynos upstream drivers. We do not support such
configuration. Please push your lovely vendor to work with upstream.
That's the only solution.

It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
same as before - the vendor does not like to upstream stuff. There are
few guys trying to upstream recent Samsung SoC support by themself (ping
me for contacts if you would like to participate) but the one party
which should be doing it - the lovely vendor - does not actually
participate and instead sends ridiculous patches like this one here...
or like this [1] [2].

Nope, please work with upstreaming SoC support, instead of abusing
ARCH_EXYNOS for out of tree code from the vendor.

[1]
https://lore.kernel.org/linux-samsung-soc/001001d5a03d$05de1f70$119a5e50$@samsung.com/

[2]
https://lore.kernel.org/linux-usb/20210303022628.6540-1-taehyun.cho@samsung.com/

Best regards,
Krzysztof

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 21/09/2021 19:45, Will McVicker wrote:
> On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
>>
>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
>>
>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
>>>> be enabled by default via "default y if ARCH_EXYNOS" versus being
>>>> selected by the ARCH_EXYNOS config directly. This allows vendors to
>>>> disable these configs if they wish and provides additional flexibility
>>>> to modularize them in the presence of a generic kernel.
>>>
>>> This is not true. Vendors cannot disable these options as they are not
>>> visible.
>>
>> Good point, well made.
>>
>>> Although I understand that Arnd prefers this way and I do not
>>> object it, but your explanation is incorrect.
> 
> Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
> configs" part. I'll upload the series to include the fix that refactos
> the Samsung SoC drivers menuconfig which will address that and allow
> one to enable/disable those configs. I'm going to hold off though
> until we hash out the rest of the discussion in the cover letter
> email.

No, please first read our discussions, including Lee's and Geert's
comments. The drivers should not be converted to modules or made visible
if such configuration does not work. If it works, please describe your
testing setup.

All these drivers are *necessary* for a multiplatform kernel supporting
Exynos platforms, therefore disabling them does not make any sense (if
you support Exynos platform). If your kernel does not support Exynos
platform, just do not select ARCH_EXYNOS and problem disappears because
none of these drivers will be visible and selected.

Unless you describe here some out-of-tree kernel which wants
ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
want existing Exynos upstream drivers. We do not support such
configuration. Please push your lovely vendor to work with upstream.
That's the only solution.

It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
same as before - the vendor does not like to upstream stuff. There are
few guys trying to upstream recent Samsung SoC support by themself (ping
me for contacts if you would like to participate) but the one party
which should be doing it - the lovely vendor - does not actually
participate and instead sends ridiculous patches like this one here...
or like this [1] [2].

Nope, please work with upstreaming SoC support, instead of abusing
ARCH_EXYNOS for out of tree code from the vendor.

[1]
https://lore.kernel.org/linux-samsung-soc/001001d5a03d$05de1f70$119a5e50$@samsung.com/

[2]
https://lore.kernel.org/linux-usb/20210303022628.6540-1-taehyun.cho@samsung.com/

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 21/09/2021 19:45, Will McVicker wrote:
> > On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
> >>
> >> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> >>
> >>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> >>>> be enabled by default via "default y if ARCH_EXYNOS" versus being
> >>>> selected by the ARCH_EXYNOS config directly. This allows vendors to
> >>>> disable these configs if they wish and provides additional flexibility
> >>>> to modularize them in the presence of a generic kernel.
> >>>
> >>> This is not true. Vendors cannot disable these options as they are not
> >>> visible.
> >>
> >> Good point, well made.
> >>
> >>> Although I understand that Arnd prefers this way and I do not
> >>> object it, but your explanation is incorrect.
> > 
> > Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
> > configs" part. I'll upload the series to include the fix that refactos
> > the Samsung SoC drivers menuconfig which will address that and allow
> > one to enable/disable those configs. I'm going to hold off though
> > until we hash out the rest of the discussion in the cover letter
> > email.
> 
> No, please first read our discussions, including Lee's and Geert's
> comments. The drivers should not be converted to modules or made visible
> if such configuration does not work. If it works, please describe your
> testing setup.

Modules *should* work.  William is going to try it out.

Might need to lean-on for some testing on different H/W though.

> All these drivers are *necessary* for a multiplatform kernel supporting
> Exynos platforms, therefore disabling them does not make any sense (if
> you support Exynos platform). If your kernel does not support Exynos
> platform, just do not select ARCH_EXYNOS and problem disappears because
> none of these drivers will be visible and selected.
> 
> Unless you describe here some out-of-tree kernel which wants
> ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
> want existing Exynos upstream drivers. We do not support such
> configuration. Please push your lovely vendor to work with upstream.
> That's the only solution.
> 
> It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
> same as before - the vendor does not like to upstream stuff. There are
> few guys trying to upstream recent Samsung SoC support by themself (ping
> me for contacts if you would like to participate) but the one party
> which should be doing it - the lovely vendor - does not actually
> participate and instead sends ridiculous patches like this one here...
> or like this [1] [2].
> 
> Nope, please work with upstreaming SoC support, instead of abusing
> ARCH_EXYNOS for out of tree code from the vendor.

One of the on-going issues that GKI aims to solve pertains to the
disparity between what upstream engineers would like to be upstreamed
(i.e. everything) and what vendors can upstream (i.e. most things).

The old Open Source vs Business (i.e. products/real-life) struggle!

Vendors are not able to upstream all functionality right away, as it
would give away their perceived edge on the competition (i.e. other
vendors).  This is something we just have to accept as it will *never*
change.

GKI attempts to solve this issue by providing a generic core
containing all of the elements required to get every supported
platform bootstrapped to a point where modules can be loaded and
additional functionality can be brought in.  GKI provides all of the
modules available from the upstream kernel BUT allows them to be
overwritten/swapped-out by modules containing code (new/shiny
unreleased value-add) that the vendors do not wish to share (yet).

Clever, eh!

As I've explained before, the trigger for all of this was
SERIAL_SAMSUNG which is required for early console on supported
Samsung platforms i.e. this symbol *has* to be built-in.  In order for
this to built-in ARCH_EXYNOS has to be enabled due to the listed
dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
different extra symbols, it means they too will be built-in, meaning
that a) the core binary will be unnecessarily bloated and b) vendors
who wish to overwrite/replace this functionality with their
non-shareable value-add, are not able to do so.

Going forward, it sounds like the best approach that will make
everyone happy, providing it's technically feasible, is to enable
these added (sometimes required, other times superfluous) symbols as
loadable modules.

> [1]
> https://lore.kernel.org/linux-samsung-soc/001001d5a03d$05de1f70$119a5e50$@samsung.com/
> 
> [2]
> https://lore.kernel.org/linux-usb/20210303022628.6540-1-taehyun.cho@samsung.com/
> 
> Best regards,
> Krzysztof

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

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 21/09/2021 19:45, Will McVicker wrote:
> > On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
> >>
> >> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> >>
> >>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> >>>> be enabled by default via "default y if ARCH_EXYNOS" versus being
> >>>> selected by the ARCH_EXYNOS config directly. This allows vendors to
> >>>> disable these configs if they wish and provides additional flexibility
> >>>> to modularize them in the presence of a generic kernel.
> >>>
> >>> This is not true. Vendors cannot disable these options as they are not
> >>> visible.
> >>
> >> Good point, well made.
> >>
> >>> Although I understand that Arnd prefers this way and I do not
> >>> object it, but your explanation is incorrect.
> > 
> > Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
> > configs" part. I'll upload the series to include the fix that refactos
> > the Samsung SoC drivers menuconfig which will address that and allow
> > one to enable/disable those configs. I'm going to hold off though
> > until we hash out the rest of the discussion in the cover letter
> > email.
> 
> No, please first read our discussions, including Lee's and Geert's
> comments. The drivers should not be converted to modules or made visible
> if such configuration does not work. If it works, please describe your
> testing setup.

Modules *should* work.  William is going to try it out.

Might need to lean-on for some testing on different H/W though.

> All these drivers are *necessary* for a multiplatform kernel supporting
> Exynos platforms, therefore disabling them does not make any sense (if
> you support Exynos platform). If your kernel does not support Exynos
> platform, just do not select ARCH_EXYNOS and problem disappears because
> none of these drivers will be visible and selected.
> 
> Unless you describe here some out-of-tree kernel which wants
> ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
> want existing Exynos upstream drivers. We do not support such
> configuration. Please push your lovely vendor to work with upstream.
> That's the only solution.
> 
> It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
> same as before - the vendor does not like to upstream stuff. There are
> few guys trying to upstream recent Samsung SoC support by themself (ping
> me for contacts if you would like to participate) but the one party
> which should be doing it - the lovely vendor - does not actually
> participate and instead sends ridiculous patches like this one here...
> or like this [1] [2].
> 
> Nope, please work with upstreaming SoC support, instead of abusing
> ARCH_EXYNOS for out of tree code from the vendor.

One of the on-going issues that GKI aims to solve pertains to the
disparity between what upstream engineers would like to be upstreamed
(i.e. everything) and what vendors can upstream (i.e. most things).

The old Open Source vs Business (i.e. products/real-life) struggle!

Vendors are not able to upstream all functionality right away, as it
would give away their perceived edge on the competition (i.e. other
vendors).  This is something we just have to accept as it will *never*
change.

GKI attempts to solve this issue by providing a generic core
containing all of the elements required to get every supported
platform bootstrapped to a point where modules can be loaded and
additional functionality can be brought in.  GKI provides all of the
modules available from the upstream kernel BUT allows them to be
overwritten/swapped-out by modules containing code (new/shiny
unreleased value-add) that the vendors do not wish to share (yet).

Clever, eh!

As I've explained before, the trigger for all of this was
SERIAL_SAMSUNG which is required for early console on supported
Samsung platforms i.e. this symbol *has* to be built-in.  In order for
this to built-in ARCH_EXYNOS has to be enabled due to the listed
dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
different extra symbols, it means they too will be built-in, meaning
that a) the core binary will be unnecessarily bloated and b) vendors
who wish to overwrite/replace this functionality with their
non-shareable value-add, are not able to do so.

Going forward, it sounds like the best approach that will make
everyone happy, providing it's technically feasible, is to enable
these added (sometimes required, other times superfluous) symbols as
loadable modules.

> [1]
> https://lore.kernel.org/linux-samsung-soc/001001d5a03d$05de1f70$119a5e50$@samsung.com/
> 
> [2]
> https://lore.kernel.org/linux-usb/20210303022628.6540-1-taehyun.cho@samsung.com/
> 
> Best regards,
> Krzysztof

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 23/09/2021 14:39, Lee Jones wrote:
> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> 
>> On 21/09/2021 19:45, Will McVicker wrote:
>>> On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
>>>>
>>>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
>>>>
>>>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
>>>>>> be enabled by default via "default y if ARCH_EXYNOS" versus being
>>>>>> selected by the ARCH_EXYNOS config directly. This allows vendors to
>>>>>> disable these configs if they wish and provides additional flexibility
>>>>>> to modularize them in the presence of a generic kernel.
>>>>>
>>>>> This is not true. Vendors cannot disable these options as they are not
>>>>> visible.
>>>>
>>>> Good point, well made.
>>>>
>>>>> Although I understand that Arnd prefers this way and I do not
>>>>> object it, but your explanation is incorrect.
>>>
>>> Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
>>> configs" part. I'll upload the series to include the fix that refactos
>>> the Samsung SoC drivers menuconfig which will address that and allow
>>> one to enable/disable those configs. I'm going to hold off though
>>> until we hash out the rest of the discussion in the cover letter
>>> email.
>>
>> No, please first read our discussions, including Lee's and Geert's
>> comments. The drivers should not be converted to modules or made visible
>> if such configuration does not work. If it works, please describe your
>> testing setup.
> 
> Modules *should* work.  William is going to try it out.
> 
> Might need to lean-on for some testing on different H/W though.

I can help, few other folks from Samsung can help as well.

> 
>> All these drivers are *necessary* for a multiplatform kernel supporting
>> Exynos platforms, therefore disabling them does not make any sense (if
>> you support Exynos platform). If your kernel does not support Exynos
>> platform, just do not select ARCH_EXYNOS and problem disappears because
>> none of these drivers will be visible and selected.
>>
>> Unless you describe here some out-of-tree kernel which wants
>> ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
>> want existing Exynos upstream drivers. We do not support such
>> configuration. Please push your lovely vendor to work with upstream.
>> That's the only solution.
>>
>> It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
>> same as before - the vendor does not like to upstream stuff. There are
>> few guys trying to upstream recent Samsung SoC support by themself (ping
>> me for contacts if you would like to participate) but the one party
>> which should be doing it - the lovely vendor - does not actually
>> participate and instead sends ridiculous patches like this one here...
>> or like this [1] [2].
>>
>> Nope, please work with upstreaming SoC support, instead of abusing
>> ARCH_EXYNOS for out of tree code from the vendor.
> 
> One of the on-going issues that GKI aims to solve pertains to the
> disparity between what upstream engineers would like to be upstreamed
> (i.e. everything) and what vendors can upstream (i.e. most things).
> 
> The old Open Source vs Business (i.e. products/real-life) struggle!
> 
> Vendors are not able to upstream all functionality right away, as it
> would give away their perceived edge on the competition (i.e. other
> vendors).  This is something we just have to accept as it will *never*
> change.

Sure, I understand. Balance, compromise, not perfectness.

However now it is heavily in-balanced since vendor did upstream only one
change - UFS drivers for new SoC - since 2017. One change. Nothing else,
nothing for older SoC, nothing for newer.

All other work is done by the community, not by the vendor.

Not sure how to qualify Sam's Exynos850 work, but even if counting it,
there will be just two changes from vendor.

This is not acceptable, this is not a balanced approach.

> 
> GKI attempts to solve this issue by providing a generic core
> containing all of the elements required to get every supported
> platform bootstrapped to a point where modules can be loaded and
> additional functionality can be brought in.  GKI provides all of the
> modules available from the upstream kernel BUT allows them to be
> overwritten/swapped-out by modules containing code (new/shiny
> unreleased value-add) that the vendors do not wish to share (yet).
> 
> Clever, eh!
> 
> As I've explained before, the trigger for all of this was
> SERIAL_SAMSUNG which is required for early console on supported
> Samsung platforms i.e. this symbol *has* to be built-in.  

Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
for built-in only for debugging or development, not for real products.

Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
or heavily tested whether setup from initrd works. Plus not breaking
distros who like to have everything as module (solution from Geert?)...

> In order for
> this to built-in ARCH_EXYNOS has to be enabled due to the listed
> dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
> different extra symbols, it means they too will be built-in, meaning
> that a) the core binary will be unnecessarily bloated and b) vendors
> who wish to overwrite/replace this functionality with their
> non-shareable value-add, are not able to do so.

I am sorry, but this is not reflecting status we want to have in
usptream. Everything selected by ARCH_EXYNOS *has to be selected* for
supported platforms. Since vendor does not contribute anything new
(except mentioned one work for UFS), we are not going to sacrifice
supported mainline platforms for a non-cooperative out-of-tree unknown
platforms.

> Going forward, it sounds like the best approach that will make
> everyone happy, providing it's technically feasible, is to enable
> these added (sometimes required, other times superfluous) symbols as
> loadable modules.

Not entirely. What actually would make everyone happy and it is still
technically feasible is for a multi-billion company with thousands of
engineers to contribute something. Let's start with a little bit. From
billions of dollars and thousands of engineers we won't expect too much,
right?


Best regards,
Krzysztof

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Krzysztof Kozlowski]

On 23/09/2021 14:39, Lee Jones wrote:
> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> 
>> On 21/09/2021 19:45, Will McVicker wrote:
>>> On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
>>>>
>>>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
>>>>
>>>>> On 20/09/2021 21:03, Will McVicker wrote:
>>>>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
>>>>>> be enabled by default via "default y if ARCH_EXYNOS" versus being
>>>>>> selected by the ARCH_EXYNOS config directly. This allows vendors to
>>>>>> disable these configs if they wish and provides additional flexibility
>>>>>> to modularize them in the presence of a generic kernel.
>>>>>
>>>>> This is not true. Vendors cannot disable these options as they are not
>>>>> visible.
>>>>
>>>> Good point, well made.
>>>>
>>>>> Although I understand that Arnd prefers this way and I do not
>>>>> object it, but your explanation is incorrect.
>>>
>>> Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
>>> configs" part. I'll upload the series to include the fix that refactos
>>> the Samsung SoC drivers menuconfig which will address that and allow
>>> one to enable/disable those configs. I'm going to hold off though
>>> until we hash out the rest of the discussion in the cover letter
>>> email.
>>
>> No, please first read our discussions, including Lee's and Geert's
>> comments. The drivers should not be converted to modules or made visible
>> if such configuration does not work. If it works, please describe your
>> testing setup.
> 
> Modules *should* work.  William is going to try it out.
> 
> Might need to lean-on for some testing on different H/W though.

I can help, few other folks from Samsung can help as well.

> 
>> All these drivers are *necessary* for a multiplatform kernel supporting
>> Exynos platforms, therefore disabling them does not make any sense (if
>> you support Exynos platform). If your kernel does not support Exynos
>> platform, just do not select ARCH_EXYNOS and problem disappears because
>> none of these drivers will be visible and selected.
>>
>> Unless you describe here some out-of-tree kernel which wants
>> ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
>> want existing Exynos upstream drivers. We do not support such
>> configuration. Please push your lovely vendor to work with upstream.
>> That's the only solution.
>>
>> It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
>> same as before - the vendor does not like to upstream stuff. There are
>> few guys trying to upstream recent Samsung SoC support by themself (ping
>> me for contacts if you would like to participate) but the one party
>> which should be doing it - the lovely vendor - does not actually
>> participate and instead sends ridiculous patches like this one here...
>> or like this [1] [2].
>>
>> Nope, please work with upstreaming SoC support, instead of abusing
>> ARCH_EXYNOS for out of tree code from the vendor.
> 
> One of the on-going issues that GKI aims to solve pertains to the
> disparity between what upstream engineers would like to be upstreamed
> (i.e. everything) and what vendors can upstream (i.e. most things).
> 
> The old Open Source vs Business (i.e. products/real-life) struggle!
> 
> Vendors are not able to upstream all functionality right away, as it
> would give away their perceived edge on the competition (i.e. other
> vendors).  This is something we just have to accept as it will *never*
> change.

Sure, I understand. Balance, compromise, not perfectness.

However now it is heavily in-balanced since vendor did upstream only one
change - UFS drivers for new SoC - since 2017. One change. Nothing else,
nothing for older SoC, nothing for newer.

All other work is done by the community, not by the vendor.

Not sure how to qualify Sam's Exynos850 work, but even if counting it,
there will be just two changes from vendor.

This is not acceptable, this is not a balanced approach.

> 
> GKI attempts to solve this issue by providing a generic core
> containing all of the elements required to get every supported
> platform bootstrapped to a point where modules can be loaded and
> additional functionality can be brought in.  GKI provides all of the
> modules available from the upstream kernel BUT allows them to be
> overwritten/swapped-out by modules containing code (new/shiny
> unreleased value-add) that the vendors do not wish to share (yet).
> 
> Clever, eh!
> 
> As I've explained before, the trigger for all of this was
> SERIAL_SAMSUNG which is required for early console on supported
> Samsung platforms i.e. this symbol *has* to be built-in.  

Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
for built-in only for debugging or development, not for real products.

Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
or heavily tested whether setup from initrd works. Plus not breaking
distros who like to have everything as module (solution from Geert?)...

> In order for
> this to built-in ARCH_EXYNOS has to be enabled due to the listed
> dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
> different extra symbols, it means they too will be built-in, meaning
> that a) the core binary will be unnecessarily bloated and b) vendors
> who wish to overwrite/replace this functionality with their
> non-shareable value-add, are not able to do so.

I am sorry, but this is not reflecting status we want to have in
usptream. Everything selected by ARCH_EXYNOS *has to be selected* for
supported platforms. Since vendor does not contribute anything new
(except mentioned one work for UFS), we are not going to sacrifice
supported mainline platforms for a non-cooperative out-of-tree unknown
platforms.

> Going forward, it sounds like the best approach that will make
> everyone happy, providing it's technically feasible, is to enable
> these added (sometimes required, other times superfluous) symbols as
> loadable modules.

Not entirely. What actually would make everyone happy and it is still
technically feasible is for a multi-billion company with thousands of
engineers to contribute something. Let's start with a little bit. From
billions of dollars and thousands of engineers we won't expect too much,
right?


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Lee Jones]

On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:

> On 23/09/2021 14:39, Lee Jones wrote:
> > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> > 
> >> On 21/09/2021 19:45, Will McVicker wrote:
> >>> On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
> >>>>
> >>>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> >>>>
> >>>>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> >>>>>> be enabled by default via "default y if ARCH_EXYNOS" versus being
> >>>>>> selected by the ARCH_EXYNOS config directly. This allows vendors to
> >>>>>> disable these configs if they wish and provides additional flexibility
> >>>>>> to modularize them in the presence of a generic kernel.
> >>>>>
> >>>>> This is not true. Vendors cannot disable these options as they are not
> >>>>> visible.
> >>>>
> >>>> Good point, well made.
> >>>>
> >>>>> Although I understand that Arnd prefers this way and I do not
> >>>>> object it, but your explanation is incorrect.
> >>>
> >>> Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
> >>> configs" part. I'll upload the series to include the fix that refactos
> >>> the Samsung SoC drivers menuconfig which will address that and allow
> >>> one to enable/disable those configs. I'm going to hold off though
> >>> until we hash out the rest of the discussion in the cover letter
> >>> email.
> >>
> >> No, please first read our discussions, including Lee's and Geert's
> >> comments. The drivers should not be converted to modules or made visible
> >> if such configuration does not work. If it works, please describe your
> >> testing setup.
> > 
> > Modules *should* work.  William is going to try it out.
> > 
> > Might need to lean-on for some testing on different H/W though.
> 
> I can help, few other folks from Samsung can help as well.

Thanks.  I'd really appreciate it.

> >> All these drivers are *necessary* for a multiplatform kernel supporting
> >> Exynos platforms, therefore disabling them does not make any sense (if
> >> you support Exynos platform). If your kernel does not support Exynos
> >> platform, just do not select ARCH_EXYNOS and problem disappears because
> >> none of these drivers will be visible and selected.
> >>
> >> Unless you describe here some out-of-tree kernel which wants
> >> ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
> >> want existing Exynos upstream drivers. We do not support such
> >> configuration. Please push your lovely vendor to work with upstream.
> >> That's the only solution.
> >>
> >> It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
> >> same as before - the vendor does not like to upstream stuff. There are
> >> few guys trying to upstream recent Samsung SoC support by themself (ping
> >> me for contacts if you would like to participate) but the one party
> >> which should be doing it - the lovely vendor - does not actually
> >> participate and instead sends ridiculous patches like this one here...
> >> or like this [1] [2].
> >>
> >> Nope, please work with upstreaming SoC support, instead of abusing
> >> ARCH_EXYNOS for out of tree code from the vendor.
> > 
> > One of the on-going issues that GKI aims to solve pertains to the
> > disparity between what upstream engineers would like to be upstreamed
> > (i.e. everything) and what vendors can upstream (i.e. most things).
> > 
> > The old Open Source vs Business (i.e. products/real-life) struggle!
> > 
> > Vendors are not able to upstream all functionality right away, as it
> > would give away their perceived edge on the competition (i.e. other
> > vendors).  This is something we just have to accept as it will *never*
> > change.
> 
> Sure, I understand. Balance, compromise, not perfectness.
> 
> However now it is heavily in-balanced since vendor did upstream only one
> change - UFS drivers for new SoC - since 2017. One change. Nothing else,
> nothing for older SoC, nothing for newer.
> 
> All other work is done by the community, not by the vendor.
> 
> Not sure how to qualify Sam's Exynos850 work, but even if counting it,
> there will be just two changes from vendor.
> 
> This is not acceptable, this is not a balanced approach.

Completely understand.  Been there, got frustrated by that!

However, GKI is your friend here, since it operates an upstream-first
philosophy.  Samsung would not be able to utilise GKI if its platform
wasn't supported by upstream.  Regardless of who did the work, (not my
concern at this point) the platform is supported in Mainline.

Volunteers (including Linaro) do a bunch of upstreaming on behalf of
vendors, including some of the very largest/most successful.
Sometimes that just the way it goes - try not to take it too
personally.

> > GKI attempts to solve this issue by providing a generic core
> > containing all of the elements required to get every supported
> > platform bootstrapped to a point where modules can be loaded and
> > additional functionality can be brought in.  GKI provides all of the
> > modules available from the upstream kernel BUT allows them to be
> > overwritten/swapped-out by modules containing code (new/shiny
> > unreleased value-add) that the vendors do not wish to share (yet).
> > 
> > Clever, eh!
> > 
> > As I've explained before, the trigger for all of this was
> > SERIAL_SAMSUNG which is required for early console on supported
> > Samsung platforms i.e. this symbol *has* to be built-in.  
> 
> Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
> for built-in only for debugging or development, not for real products.

Right.  And in the early stages, GKI is used for early (non-released)
H/W (this is also the part of the reason these differences can't be
upstreamed early/now/yet) and sometimes changes break things requiring
low-level debugging techniques to solve (inc. early console).

> Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
> or heavily tested whether setup from initrd works. Plus not breaking
> distros who like to have everything as module (solution from Geert?)...

We don't know which drivers *need* to be built-in yet.

Clocks is probably not a good example even, since the power-on default
is most likely all-on, which is fine.  Pinctrl remains to be seen.

> > In order for
> > this to built-in ARCH_EXYNOS has to be enabled due to the listed
> > dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
> > different extra symbols, it means they too will be built-in, meaning
> > that a) the core binary will be unnecessarily bloated and b) vendors
> > who wish to overwrite/replace this functionality with their
> > non-shareable value-add, are not able to do so.
> 
> I am sorry, but this is not reflecting status we want to have in
> usptream. Everything selected by ARCH_EXYNOS *has to be selected* for
> supported platforms. Since vendor does not contribute anything new
> (except mentioned one work for UFS), we are not going to sacrifice
> supported mainline platforms for a non-cooperative out-of-tree unknown
> platforms.

The is the part of the discussion that is the most contentious.

Ideally we wouldn't have to enable any ARCH_* explicitly.  Greg has
mentioned this publicly on a number of discussions.  However, removing
the dependencies (from Kconfig in this case) is in contention with
other user's use-cases.  No one wants to be asked seemingly irrelevant
configuration questions during the config stages of a kernel build.

So we are forced to enable ARCH_* to have our requirements built-in
(ARCH_EXYNOS for SAMSUNG_SERIAL [early console] in this case).
Unfortunately, this comes with additional cruft that we *might* not
want (resulting in bloat) or that we wish to overwrite with more
featureful driver modules.  We can't do that if these features are
built-in.

Please don't make this discussion about particular vendors.  Bringing
in emotional feelings pertaining to specific companies or individuals
does not make for a quality level-headed technical discussion.

The principles I'm discussing here are vendor agnostic.

> > Going forward, it sounds like the best approach that will make
> > everyone happy, providing it's technically feasible, is to enable
> > these added (sometimes required, other times superfluous) symbols as
> > loadable modules.
> 
> Not entirely. What actually would make everyone happy and it is still
> technically feasible is for a multi-billion company with thousands of
> engineers to contribute something. Let's start with a little bit. From
> billions of dollars and thousands of engineers we won't expect too much,
> right?

I understand your frustration, but it's orthogonal to this discussion.

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

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Lee Jones]

On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:

> On 23/09/2021 14:39, Lee Jones wrote:
> > On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> > 
> >> On 21/09/2021 19:45, Will McVicker wrote:
> >>> On Tue, Sep 21, 2021 at 1:19 AM Lee Jones <lee.jones@linaro.org> wrote:
> >>>>
> >>>> On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:
> >>>>
> >>>>> On 20/09/2021 21:03, Will McVicker wrote:
> >>>>>> Switch the default logic to enable SOC_SAMSUNG and it's sub-configs to
> >>>>>> be enabled by default via "default y if ARCH_EXYNOS" versus being
> >>>>>> selected by the ARCH_EXYNOS config directly. This allows vendors to
> >>>>>> disable these configs if they wish and provides additional flexibility
> >>>>>> to modularize them in the presence of a generic kernel.
> >>>>>
> >>>>> This is not true. Vendors cannot disable these options as they are not
> >>>>> visible.
> >>>>
> >>>> Good point, well made.
> >>>>
> >>>>> Although I understand that Arnd prefers this way and I do not
> >>>>> object it, but your explanation is incorrect.
> >>>
> >>> Thanks Krzysztof for the reviews! I'm sorry I missed the whole "hidden
> >>> configs" part. I'll upload the series to include the fix that refactos
> >>> the Samsung SoC drivers menuconfig which will address that and allow
> >>> one to enable/disable those configs. I'm going to hold off though
> >>> until we hash out the rest of the discussion in the cover letter
> >>> email.
> >>
> >> No, please first read our discussions, including Lee's and Geert's
> >> comments. The drivers should not be converted to modules or made visible
> >> if such configuration does not work. If it works, please describe your
> >> testing setup.
> > 
> > Modules *should* work.  William is going to try it out.
> > 
> > Might need to lean-on for some testing on different H/W though.
> 
> I can help, few other folks from Samsung can help as well.

Thanks.  I'd really appreciate it.

> >> All these drivers are *necessary* for a multiplatform kernel supporting
> >> Exynos platforms, therefore disabling them does not make any sense (if
> >> you support Exynos platform). If your kernel does not support Exynos
> >> platform, just do not select ARCH_EXYNOS and problem disappears because
> >> none of these drivers will be visible and selected.
> >>
> >> Unless you describe here some out-of-tree kernel which wants
> >> ARCH_EXYNOS, because vendor did not upstream it's code, but you do not
> >> want existing Exynos upstream drivers. We do not support such
> >> configuration. Please push your lovely vendor to work with upstream.
> >> That's the only solution.
> >>
> >> It's the third time this abuse re-usage of ARCH_EXYNOS appears and the
> >> same as before - the vendor does not like to upstream stuff. There are
> >> few guys trying to upstream recent Samsung SoC support by themself (ping
> >> me for contacts if you would like to participate) but the one party
> >> which should be doing it - the lovely vendor - does not actually
> >> participate and instead sends ridiculous patches like this one here...
> >> or like this [1] [2].
> >>
> >> Nope, please work with upstreaming SoC support, instead of abusing
> >> ARCH_EXYNOS for out of tree code from the vendor.
> > 
> > One of the on-going issues that GKI aims to solve pertains to the
> > disparity between what upstream engineers would like to be upstreamed
> > (i.e. everything) and what vendors can upstream (i.e. most things).
> > 
> > The old Open Source vs Business (i.e. products/real-life) struggle!
> > 
> > Vendors are not able to upstream all functionality right away, as it
> > would give away their perceived edge on the competition (i.e. other
> > vendors).  This is something we just have to accept as it will *never*
> > change.
> 
> Sure, I understand. Balance, compromise, not perfectness.
> 
> However now it is heavily in-balanced since vendor did upstream only one
> change - UFS drivers for new SoC - since 2017. One change. Nothing else,
> nothing for older SoC, nothing for newer.
> 
> All other work is done by the community, not by the vendor.
> 
> Not sure how to qualify Sam's Exynos850 work, but even if counting it,
> there will be just two changes from vendor.
> 
> This is not acceptable, this is not a balanced approach.

Completely understand.  Been there, got frustrated by that!

However, GKI is your friend here, since it operates an upstream-first
philosophy.  Samsung would not be able to utilise GKI if its platform
wasn't supported by upstream.  Regardless of who did the work, (not my
concern at this point) the platform is supported in Mainline.

Volunteers (including Linaro) do a bunch of upstreaming on behalf of
vendors, including some of the very largest/most successful.
Sometimes that just the way it goes - try not to take it too
personally.

> > GKI attempts to solve this issue by providing a generic core
> > containing all of the elements required to get every supported
> > platform bootstrapped to a point where modules can be loaded and
> > additional functionality can be brought in.  GKI provides all of the
> > modules available from the upstream kernel BUT allows them to be
> > overwritten/swapped-out by modules containing code (new/shiny
> > unreleased value-add) that the vendors do not wish to share (yet).
> > 
> > Clever, eh!
> > 
> > As I've explained before, the trigger for all of this was
> > SERIAL_SAMSUNG which is required for early console on supported
> > Samsung platforms i.e. this symbol *has* to be built-in.  
> 
> Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
> for built-in only for debugging or development, not for real products.

Right.  And in the early stages, GKI is used for early (non-released)
H/W (this is also the part of the reason these differences can't be
upstreamed early/now/yet) and sometimes changes break things requiring
low-level debugging techniques to solve (inc. early console).

> Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
> or heavily tested whether setup from initrd works. Plus not breaking
> distros who like to have everything as module (solution from Geert?)...

We don't know which drivers *need* to be built-in yet.

Clocks is probably not a good example even, since the power-on default
is most likely all-on, which is fine.  Pinctrl remains to be seen.

> > In order for
> > this to built-in ARCH_EXYNOS has to be enabled due to the listed
> > dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
> > different extra symbols, it means they too will be built-in, meaning
> > that a) the core binary will be unnecessarily bloated and b) vendors
> > who wish to overwrite/replace this functionality with their
> > non-shareable value-add, are not able to do so.
> 
> I am sorry, but this is not reflecting status we want to have in
> usptream. Everything selected by ARCH_EXYNOS *has to be selected* for
> supported platforms. Since vendor does not contribute anything new
> (except mentioned one work for UFS), we are not going to sacrifice
> supported mainline platforms for a non-cooperative out-of-tree unknown
> platforms.

The is the part of the discussion that is the most contentious.

Ideally we wouldn't have to enable any ARCH_* explicitly.  Greg has
mentioned this publicly on a number of discussions.  However, removing
the dependencies (from Kconfig in this case) is in contention with
other user's use-cases.  No one wants to be asked seemingly irrelevant
configuration questions during the config stages of a kernel build.

So we are forced to enable ARCH_* to have our requirements built-in
(ARCH_EXYNOS for SAMSUNG_SERIAL [early console] in this case).
Unfortunately, this comes with additional cruft that we *might* not
want (resulting in bloat) or that we wish to overwrite with more
featureful driver modules.  We can't do that if these features are
built-in.

Please don't make this discussion about particular vendors.  Bringing
in emotional feelings pertaining to specific companies or individuals
does not make for a quality level-headed technical discussion.

The principles I'm discussing here are vendor agnostic.

> > Going forward, it sounds like the best approach that will make
> > everyone happy, providing it's technically feasible, is to enable
> > these added (sometimes required, other times superfluous) symbols as
> > loadable modules.
> 
> Not entirely. What actually would make everyone happy and it is still
> technically feasible is for a multi-billion company with thousands of
> engineers to contribute something. Let's start with a little bit. From
> billions of dollars and thousands of engineers we won't expect too much,
> right?

I understand your frustration, but it's orthogonal to this discussion.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Geert Uytterhoeven]

Hi Lee,

On Thu, Sep 23, 2021 at 3:42 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:
> > On 23/09/2021 14:39, Lee Jones wrote:
> > > As I've explained before, the trigger for all of this was
> > > SERIAL_SAMSUNG which is required for early console on supported
> > > Samsung platforms i.e. this symbol *has* to be built-in.
> >
> > Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
> > for built-in only for debugging or development, not for real products.
>
> Right.  And in the early stages, GKI is used for early (non-released)
> H/W (this is also the part of the reason these differences can't be
> upstreamed early/now/yet) and sometimes changes break things requiring
> low-level debugging techniques to solve (inc. early console).
>
> > Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
> > or heavily tested whether setup from initrd works. Plus not breaking
> > distros who like to have everything as module (solution from Geert?)...
>
> We don't know which drivers *need* to be built-in yet.
>
> Clocks is probably not a good example even, since the power-on default
> is most likely all-on, which is fine.  Pinctrl remains to be seen.

Clocks is an excellent example: if a clock is missing, the driver
will fail to probe (unless the clock is considered optional by
the driver), regardless of the power-on or boot loader defaults.
With fw_devlinks=on (which is the default now, and developed by a
Google engineer (GKI or another division?)), the driver won't even
get to the probing point.

Pinctrl is different, as unless I'm mistaken, drivers will still
probe if the pin control driver is missing, so they will work if the
power-on or boot loader defaults of pin control are fine.

> > > In order for
> > > this to built-in ARCH_EXYNOS has to be enabled due to the listed
> > > dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
> > > different extra symbols, it means they too will be built-in, meaning
> > > that a) the core binary will be unnecessarily bloated and b) vendors
> > > who wish to overwrite/replace this functionality with their
> > > non-shareable value-add, are not able to do so.
> >
> > I am sorry, but this is not reflecting status we want to have in
> > usptream. Everything selected by ARCH_EXYNOS *has to be selected* for
> > supported platforms. Since vendor does not contribute anything new
> > (except mentioned one work for UFS), we are not going to sacrifice
> > supported mainline platforms for a non-cooperative out-of-tree unknown
> > platforms.
>
> The is the part of the discussion that is the most contentious.
>
> Ideally we wouldn't have to enable any ARCH_* explicitly.  Greg has
> mentioned this publicly on a number of discussions.  However, removing
> the dependencies (from Kconfig in this case) is in contention with
> other user's use-cases.  No one wants to be asked seemingly irrelevant
> configuration questions during the config stages of a kernel build.
>
> So we are forced to enable ARCH_* to have our requirements built-in
> (ARCH_EXYNOS for SAMSUNG_SERIAL [early console] in this case).
> Unfortunately, this comes with additional cruft that we *might* not
> want (resulting in bloat) or that we wish to overwrite with more
> featureful driver modules.  We can't do that if these features are
> built-in.

The question is if Linux can actually boot on the affected platform
without this "additional cruft" builtin, for which we still haven't
received any confirmation yet...

So claiming to be "upstream first", and submitting patches, is great,
but only if the changes you're upstreaming actually work.
If they don't, and if you insist on keeping on upstreaming them,
without providing evidence that they don't break the affected platform
completely, perhaps this should be treated similar to the UMN patches?

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 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Geert Uytterhoeven]

Hi Lee,

On Thu, Sep 23, 2021 at 3:42 PM Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:
> > On 23/09/2021 14:39, Lee Jones wrote:
> > > As I've explained before, the trigger for all of this was
> > > SERIAL_SAMSUNG which is required for early console on supported
> > > Samsung platforms i.e. this symbol *has* to be built-in.
> >
> > Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
> > for built-in only for debugging or development, not for real products.
>
> Right.  And in the early stages, GKI is used for early (non-released)
> H/W (this is also the part of the reason these differences can't be
> upstreamed early/now/yet) and sometimes changes break things requiring
> low-level debugging techniques to solve (inc. early console).
>
> > Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
> > or heavily tested whether setup from initrd works. Plus not breaking
> > distros who like to have everything as module (solution from Geert?)...
>
> We don't know which drivers *need* to be built-in yet.
>
> Clocks is probably not a good example even, since the power-on default
> is most likely all-on, which is fine.  Pinctrl remains to be seen.

Clocks is an excellent example: if a clock is missing, the driver
will fail to probe (unless the clock is considered optional by
the driver), regardless of the power-on or boot loader defaults.
With fw_devlinks=on (which is the default now, and developed by a
Google engineer (GKI or another division?)), the driver won't even
get to the probing point.

Pinctrl is different, as unless I'm mistaken, drivers will still
probe if the pin control driver is missing, so they will work if the
power-on or boot loader defaults of pin control are fine.

> > > In order for
> > > this to built-in ARCH_EXYNOS has to be enabled due to the listed
> > > dependencies in Kconfig.  And since ARCH_EXYNOS 'selects' all of these
> > > different extra symbols, it means they too will be built-in, meaning
> > > that a) the core binary will be unnecessarily bloated and b) vendors
> > > who wish to overwrite/replace this functionality with their
> > > non-shareable value-add, are not able to do so.
> >
> > I am sorry, but this is not reflecting status we want to have in
> > usptream. Everything selected by ARCH_EXYNOS *has to be selected* for
> > supported platforms. Since vendor does not contribute anything new
> > (except mentioned one work for UFS), we are not going to sacrifice
> > supported mainline platforms for a non-cooperative out-of-tree unknown
> > platforms.
>
> The is the part of the discussion that is the most contentious.
>
> Ideally we wouldn't have to enable any ARCH_* explicitly.  Greg has
> mentioned this publicly on a number of discussions.  However, removing
> the dependencies (from Kconfig in this case) is in contention with
> other user's use-cases.  No one wants to be asked seemingly irrelevant
> configuration questions during the config stages of a kernel build.
>
> So we are forced to enable ARCH_* to have our requirements built-in
> (ARCH_EXYNOS for SAMSUNG_SERIAL [early console] in this case).
> Unfortunately, this comes with additional cruft that we *might* not
> want (resulting in bloat) or that we wish to overwrite with more
> featureful driver modules.  We can't do that if these features are
> built-in.

The question is if Linux can actually boot on the affected platform
without this "additional cruft" builtin, for which we still haven't
received any confirmation yet...

So claiming to be "upstream first", and submitting patches, is great,
but only if the changes you're upstreaming actually work.
If they don't, and if you insist on keeping on upstreaming them,
without providing evidence that they don't break the affected platform
completely, perhaps this should be treated similar to the UMN patches?

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Geert Uytterhoeven]

On Thu, Sep 23, 2021 at 6:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Sep 23, 2021 at 3:42 PM Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:
> > > On 23/09/2021 14:39, Lee Jones wrote:
> > > > As I've explained before, the trigger for all of this was
> > > > SERIAL_SAMSUNG which is required for early console on supported
> > > > Samsung platforms i.e. this symbol *has* to be built-in.
> > >
> > > Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
> > > for built-in only for debugging or development, not for real products.
> >
> > Right.  And in the early stages, GKI is used for early (non-released)
> > H/W (this is also the part of the reason these differences can't be
> > upstreamed early/now/yet) and sometimes changes break things requiring
> > low-level debugging techniques to solve (inc. early console).
> >
> > > Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
> > > or heavily tested whether setup from initrd works. Plus not breaking
> > > distros who like to have everything as module (solution from Geert?)...
> >
> > We don't know which drivers *need* to be built-in yet.
> >
> > Clocks is probably not a good example even, since the power-on default
> > is most likely all-on, which is fine.  Pinctrl remains to be seen.
>
> Clocks is an excellent example: if a clock is missing, the driver
> will fail to probe (unless the clock is considered optional by
> the driver), regardless of the power-on or boot loader defaults.
> With fw_devlinks=on (which is the default now, and developed by a
> Google engineer (GKI or another division?)), the driver won't even
> get to the probing point.
>
> Pinctrl is different, as unless I'm mistaken, drivers will still
> probe if the pin control driver is missing, so they will work if the
> power-on or boot loader defaults of pin control are fine.

In addition, relying on implicit power-on or boot loader state comes
with its own set of pitfalls, which may break other use cases.
On a heavily power-managed mobile device, clocks and/or power domains
can be turned off, so a kernel launched from kexec or kdump may start
in a state not adhering to these implicit dependencies.

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 2/4] soc: samsung: change SOC_SAMSUNG default config logic

[Geert Uytterhoeven]

On Thu, Sep 23, 2021 at 6:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Sep 23, 2021 at 3:42 PM Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 23 Sep 2021, Krzysztof Kozlowski wrote:
> > > On 23/09/2021 14:39, Lee Jones wrote:
> > > > As I've explained before, the trigger for all of this was
> > > > SERIAL_SAMSUNG which is required for early console on supported
> > > > Samsung platforms i.e. this symbol *has* to be built-in.
> > >
> > > Actually SERIAL_SAMSUNG does not have to be built-in. It is necessary
> > > for built-in only for debugging or development, not for real products.
> >
> > Right.  And in the early stages, GKI is used for early (non-released)
> > H/W (this is also the part of the reason these differences can't be
> > upstreamed early/now/yet) and sometimes changes break things requiring
> > low-level debugging techniques to solve (inc. early console).
> >
> > > Unlike other drivers which have to be built-in, e.g. clocks or pinctrl,
> > > or heavily tested whether setup from initrd works. Plus not breaking
> > > distros who like to have everything as module (solution from Geert?)...
> >
> > We don't know which drivers *need* to be built-in yet.
> >
> > Clocks is probably not a good example even, since the power-on default
> > is most likely all-on, which is fine.  Pinctrl remains to be seen.
>
> Clocks is an excellent example: if a clock is missing, the driver
> will fail to probe (unless the clock is considered optional by
> the driver), regardless of the power-on or boot loader defaults.
> With fw_devlinks=on (which is the default now, and developed by a
> Google engineer (GKI or another division?)), the driver won't even
> get to the probing point.
>
> Pinctrl is different, as unless I'm mistaken, drivers will still
> probe if the pin control driver is missing, so they will work if the
> power-on or boot loader defaults of pin control are fine.

In addition, relying on implicit power-on or boot loader state comes
with its own set of pitfalls, which may break other use cases.
On a heavily power-managed mobile device, clocks and/or power domains
can be turned off, so a kernel launched from kexec or kdump may start
in a state not adhering to these implicit dependencies.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS default config logic

[Will McVicker]

Switching the default config logic of PINCTRL_EXYNOS to use "default
y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select the config.
This gives vendors the flexibility to disable the config or modularize
it in the presence of a generic kernel.

Verified this change doesn't effect the .config.

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

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 6a006490c9b9..a884e5da8b0f 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -93,7 +93,6 @@ config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
 	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
-	select PINCTRL_EXYNOS
 	select PM_GENERIC_DOMAINS if PM
 	help
 	  This enables support for ARMv8 based Samsung Exynos SoC family.
diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
index dfd805e76862..483acb8ac1f6 100644
--- a/drivers/pinctrl/samsung/Kconfig
+++ b/drivers/pinctrl/samsung/Kconfig
@@ -12,6 +12,7 @@ config PINCTRL_EXYNOS
 	bool "Pinctrl common driver part for Samsung Exynos SoCs"
 	depends on OF_GPIO
 	depends on ARCH_EXYNOS || ARCH_S5PV210 || COMPILE_TEST
+	default y if ARCH_EXYNOS
 	select PINCTRL_SAMSUNG
 	select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210)
 	select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
-- 
2.33.0.464.g1972c5931b-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS default config logic

[Will McVicker]

Switching the default config logic of PINCTRL_EXYNOS to use "default
y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select the config.
This gives vendors the flexibility to disable the config or modularize
it in the presence of a generic kernel.

Verified this change doesn't effect the .config.

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

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 6a006490c9b9..a884e5da8b0f 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -93,7 +93,6 @@ config ARCH_EXYNOS
 	bool "ARMv8 based Samsung Exynos SoC family"
 	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
-	select PINCTRL_EXYNOS
 	select PM_GENERIC_DOMAINS if PM
 	help
 	  This enables support for ARMv8 based Samsung Exynos SoC family.
diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
index dfd805e76862..483acb8ac1f6 100644
--- a/drivers/pinctrl/samsung/Kconfig
+++ b/drivers/pinctrl/samsung/Kconfig
@@ -12,6 +12,7 @@ config PINCTRL_EXYNOS
 	bool "Pinctrl common driver part for Samsung Exynos SoCs"
 	depends on OF_GPIO
 	depends on ARCH_EXYNOS || ARCH_S5PV210 || COMPILE_TEST
+	default y if ARCH_EXYNOS
 	select PINCTRL_SAMSUNG
 	select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210)
 	select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
-- 
2.33.0.464.g1972c5931b-goog

Re: [PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS default config logic

[Krzysztof Kozlowski]

On 20/09/2021 21:03, Will McVicker wrote:
> Switching the default config logic of PINCTRL_EXYNOS to use "default
> y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select the config.
> This gives vendors the flexibility to disable the config or modularize
> it in the presence of a generic kernel.

Reasoning is incorrect. This is an essential driver which CANNOT be
disabled for any kernel having ARCH_EXYNOS or ARCH_S5PV210. You are
trying to prepare it for some out-of-tree code? Please, upstream your
code instead.

> 
> Verified this change doesn't effect the .config.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms    | 1 -
>  drivers/pinctrl/samsung/Kconfig | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 6a006490c9b9..a884e5da8b0f 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -93,7 +93,6 @@ config ARCH_EXYNOS
>  	bool "ARMv8 based Samsung Exynos SoC family"
>  	select HAVE_S3C_RTC if RTC_CLASS
>  	select PINCTRL
> -	select PINCTRL_EXYNOS
>  	select PM_GENERIC_DOMAINS if PM
>  	help
>  	  This enables support for ARMv8 based Samsung Exynos SoC family.
> diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
> index dfd805e76862..483acb8ac1f6 100644
> --- a/drivers/pinctrl/samsung/Kconfig
> +++ b/drivers/pinctrl/samsung/Kconfig
> @@ -12,6 +12,7 @@ config PINCTRL_EXYNOS
>  	bool "Pinctrl common driver part for Samsung Exynos SoCs"
>  	depends on OF_GPIO
>  	depends on ARCH_EXYNOS || ARCH_S5PV210 || COMPILE_TEST
> +	default y if ARCH_EXYNOS

default ARCH_EXYNOS || ARCH_S5PV210
... and update all mach Kconfigs.

>  	select PINCTRL_SAMSUNG
>  	select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210)
>  	select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
> 


Best regards,
Krzysztof

Re: [PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS default config logic

[Krzysztof Kozlowski]

On 20/09/2021 21:03, Will McVicker wrote:
> Switching the default config logic of PINCTRL_EXYNOS to use "default
> y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select the config.
> This gives vendors the flexibility to disable the config or modularize
> it in the presence of a generic kernel.

Reasoning is incorrect. This is an essential driver which CANNOT be
disabled for any kernel having ARCH_EXYNOS or ARCH_S5PV210. You are
trying to prepare it for some out-of-tree code? Please, upstream your
code instead.

> 
> Verified this change doesn't effect the .config.
> 
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  arch/arm64/Kconfig.platforms    | 1 -
>  drivers/pinctrl/samsung/Kconfig | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 6a006490c9b9..a884e5da8b0f 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -93,7 +93,6 @@ config ARCH_EXYNOS
>  	bool "ARMv8 based Samsung Exynos SoC family"
>  	select HAVE_S3C_RTC if RTC_CLASS
>  	select PINCTRL
> -	select PINCTRL_EXYNOS
>  	select PM_GENERIC_DOMAINS if PM
>  	help
>  	  This enables support for ARMv8 based Samsung Exynos SoC family.
> diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
> index dfd805e76862..483acb8ac1f6 100644
> --- a/drivers/pinctrl/samsung/Kconfig
> +++ b/drivers/pinctrl/samsung/Kconfig
> @@ -12,6 +12,7 @@ config PINCTRL_EXYNOS
>  	bool "Pinctrl common driver part for Samsung Exynos SoCs"
>  	depends on OF_GPIO
>  	depends on ARCH_EXYNOS || ARCH_S5PV210 || COMPILE_TEST
> +	default y if ARCH_EXYNOS

default ARCH_EXYNOS || ARCH_S5PV210
... and update all mach Kconfigs.

>  	select PINCTRL_SAMSUNG
>  	select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210)
>  	select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
> 


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS default config logic

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 20/09/2021 21:03, Will McVicker wrote:
> > Switching the default config logic of PINCTRL_EXYNOS to use "default
> > y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select the config.
> > This gives vendors the flexibility to disable the config or modularize
> > it in the presence of a generic kernel.
> 
> Reasoning is incorrect. This is an essential driver which CANNOT be
> disabled for any kernel having ARCH_EXYNOS or ARCH_S5PV210. You are
> trying to prepare it for some out-of-tree code? Please, upstream your
> code instead.

No additional code is required to build a generic kernel.  The only
difference would be a vendor's defconfig/fragment.

The aim of this set is to provide more flexibility around how driver
symbols can be configured via Kconfig.  Currently if ARCH_EXYNOS
(which is required if we wish to provide SERIAL_SAMSUNG as an option)
is enabled it blindly enables lots of symbols without recourse.

> > Verified this change doesn't effect the .config.
> > 
> > Signed-off-by: Will McVicker <willmcvicker@google.com>
> > ---
> >  arch/arm64/Kconfig.platforms    | 1 -
> >  drivers/pinctrl/samsung/Kconfig | 1 +
> >  2 files changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index 6a006490c9b9..a884e5da8b0f 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -93,7 +93,6 @@ config ARCH_EXYNOS
> >  	bool "ARMv8 based Samsung Exynos SoC family"
> >  	select HAVE_S3C_RTC if RTC_CLASS
> >  	select PINCTRL
> > -	select PINCTRL_EXYNOS
> >  	select PM_GENERIC_DOMAINS if PM
> >  	help
> >  	  This enables support for ARMv8 based Samsung Exynos SoC family.
> > diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
> > index dfd805e76862..483acb8ac1f6 100644
> > --- a/drivers/pinctrl/samsung/Kconfig
> > +++ b/drivers/pinctrl/samsung/Kconfig
> > @@ -12,6 +12,7 @@ config PINCTRL_EXYNOS
> >  	bool "Pinctrl common driver part for Samsung Exynos SoCs"
> >  	depends on OF_GPIO
> >  	depends on ARCH_EXYNOS || ARCH_S5PV210 || COMPILE_TEST
> > +	default y if ARCH_EXYNOS
> 
> default ARCH_EXYNOS || ARCH_S5PV210
> ... and update all mach Kconfigs.
> 
> >  	select PINCTRL_SAMSUNG
> >  	select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210)
> >  	select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
> > 
> 
> 
> Best regards,
> Krzysztof

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

Re: [PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS default config logic

[Lee Jones]

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

> On 20/09/2021 21:03, Will McVicker wrote:
> > Switching the default config logic of PINCTRL_EXYNOS to use "default
> > y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select the config.
> > This gives vendors the flexibility to disable the config or modularize
> > it in the presence of a generic kernel.
> 
> Reasoning is incorrect. This is an essential driver which CANNOT be
> disabled for any kernel having ARCH_EXYNOS or ARCH_S5PV210. You are
> trying to prepare it for some out-of-tree code? Please, upstream your
> code instead.

No additional code is required to build a generic kernel.  The only
difference would be a vendor's defconfig/fragment.

The aim of this set is to provide more flexibility around how driver
symbols can be configured via Kconfig.  Currently if ARCH_EXYNOS
(which is required if we wish to provide SERIAL_SAMSUNG as an option)
is enabled it blindly enables lots of symbols without recourse.

> > Verified this change doesn't effect the .config.
> > 
> > Signed-off-by: Will McVicker <willmcvicker@google.com>
> > ---
> >  arch/arm64/Kconfig.platforms    | 1 -
> >  drivers/pinctrl/samsung/Kconfig | 1 +
> >  2 files changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index 6a006490c9b9..a884e5da8b0f 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -93,7 +93,6 @@ config ARCH_EXYNOS
> >  	bool "ARMv8 based Samsung Exynos SoC family"
> >  	select HAVE_S3C_RTC if RTC_CLASS
> >  	select PINCTRL
> > -	select PINCTRL_EXYNOS
> >  	select PM_GENERIC_DOMAINS if PM
> >  	help
> >  	  This enables support for ARMv8 based Samsung Exynos SoC family.
> > diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
> > index dfd805e76862..483acb8ac1f6 100644
> > --- a/drivers/pinctrl/samsung/Kconfig
> > +++ b/drivers/pinctrl/samsung/Kconfig
> > @@ -12,6 +12,7 @@ config PINCTRL_EXYNOS
> >  	bool "Pinctrl common driver part for Samsung Exynos SoCs"
> >  	depends on OF_GPIO
> >  	depends on ARCH_EXYNOS || ARCH_S5PV210 || COMPILE_TEST
> > +	default y if ARCH_EXYNOS
> 
> default ARCH_EXYNOS || ARCH_S5PV210
> ... and update all mach Kconfigs.
> 
> >  	select PINCTRL_SAMSUNG
> >  	select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210)
> >  	select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS
> > 
> 
> 
> Best regards,
> Krzysztof

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS default config logic

[Linus Walleij]

On Mon, Sep 20, 2021 at 9:04 PM Will McVicker <willmcvicker@google.com> wrote:

> Switching the default config logic of PINCTRL_EXYNOS to use "default
> y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select the config.
> This gives vendors the flexibility to disable the config or modularize
> it in the presence of a generic kernel.
>
> Verified this change doesn't effect the .config.
>
> Signed-off-by: Will McVicker <willmcvicker@google.com>

Krzysztof is collecting and sending pull requests for the Samsung
pinctrl portions so I expect him to merge this once you reach consensus.

Yours,
Linus Walleij

Re: [PATCH v1 3/4] pinctrl: samsung: change PINCTRL_EXYNOS default config logic

[Linus Walleij]

On Mon, Sep 20, 2021 at 9:04 PM Will McVicker <willmcvicker@google.com> wrote:

> Switching the default config logic of PINCTRL_EXYNOS to use "default
> y if ARCH_EXYNOS" versus having ARCH_EXYNOS directly select the config.
> This gives vendors the flexibility to disable the config or modularize
> it in the presence of a generic kernel.
>
> Verified this change doesn't effect the .config.
>
> Signed-off-by: Will McVicker <willmcvicker@google.com>

Krzysztof is collecting and sending pull requests for the Samsung
pinctrl portions so I expect him to merge this once you reach consensus.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[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 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel