Re: [PATCH] Revert "tty: serial: samsung_tty: build it for any platform"

[Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>]

On 3/6/20 2:03 PM, Greg Kroah-Hartman wrote:
> On Fri, Mar 06, 2020 at 01:53:01PM +0100, Geert Uytterhoeven wrote:
>> Hi Greg,
>>
>> On Fri, Mar 6, 2020 at 1:29 PM Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>> On Fri, Mar 06, 2020 at 11:23:01AM +0100, Geert Uytterhoeven wrote:
>>>> 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}

[...]

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