On 3/6/20 2:03 PM, Greg Kroah-Hartman wrote:

On Fri, Mar 06, 2020 at 01:53:01PM +0100, Geert Uytterhoeven wrote:

quoted

Hi Greg,

On Fri, Mar 6, 2020 at 1:29 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

On Fri, Mar 06, 2020 at 11:23:01AM +0100, Geert Uytterhoeven wrote:

quoted

This reverts commit 175b558d0efb8b4f33aa7bd2c1b5389b912d3019.

When the user configures a kernel without support for Samsung SoCs, it
makes no sense to ask the user about enabling "Samsung SoC serial
support", as Samsung serial ports can only be found on Samsung SoCs.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 880b962015302dca..932ad51099deae7d 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig

@@ -237,6 +237,7 @@ config SERIAL_CLPS711X_CONSOLE

 config SERIAL_SAMSUNG
      tristate "Samsung SoC serial support"
+     depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
      select SERIAL_CORE
      help
        Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,

{sigh}

[...]

quoted

Dropping those dependencies is similar to always having a simple PCI
core without any host PCI bridges, dropping "depends on PCI" from all
PCI drivers, and building an all*config kernel for your old i386 that
predates PCI (you can replace PCI by ACPI to modernize the example).

What am I missing?!?

"depends on PCI" describes the hardware bus that a driver depends on.

PLAT_FOO is just trying to somehow classify that this type of driver
only shows up on this vendor's devices.  It is not defining the hardware
at all.  We try to always describe functionality of hardware, not try to
declare specific vendor's hardware choices, right?

PLAT_FOO is interesting, but given that a specific driver is really not
tied to that platform logically, only by virtue that no one else might
not happen to have that hardware, it seems odd to have that.

Your particular patch is not about removing PLAT_FOO dependency but
about removing actual architecture/platform specific dependencies.

Please look at your patch and note that in addition to removing
PLAT_SAMSUNG dependency (even ignoring for a moment that it can be
replaced by a few ARCH_* dependencies and PLAT_SAMSUNG was used only
because it was shorter) has also removed ARCH_EXYNOS dependency.

How do you explain this?

Yes, asking lots of questions is tough, but we passed that problem so
long ago.  Are we now trying to add PLAT_FOO entries to all hardware
drivers in order to make this type of selection easier?  I thought we

We are not going to add anything because for the vast majority of
the drivers the needed entries are already there:

$ find drivers/ -name 'Kconfig*'|xargs cat|grep "depends on"|grep ARCH_|wc -l
1310

were just doing that by providing defconfig files to make the initial
selection saner.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

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