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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
>>>> ---
>>>> 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
