Hi Krzysztof,

On Mon, Sep 27, 2021 at 10:08 AM Krzysztof Kozlowski
[off-list ref] wrote:

On 25/09/2021 04:17, Saravana Kannan wrote:

quoted

On Tue, Sep 21, 2021 at 1:25 AM Krzysztof Kozlowski
[off-list ref] wrote:

quoted

On 21/09/2021 10:11, Lee Jones wrote:

quoted

On Tue, 21 Sep 2021, Krzysztof Kozlowski wrote:

quoted

On 20/09/2021 21:03, Will McVicker wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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/ (local)

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