Hi Krzysztof, On Mon, Mar 9, 2020 at 7:09 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > .On Fri, 6 Mar 2020 at 11:23, Geert Uytterhoeven > <geert+renesas@xxxxxxxxx> 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(+) > > > > Discussion about removal and then re-adding of PLAT_SAMSUNG and > ARCH_EXYNOS dependencies remind me [1]: "[RFC] Input: tm2-touchkey - > add hardware dependency". > > In both cases the driver is clearly only for Samsung SoC or even for > particular device, although one could argue that touchscreen could be > reused while re-usage of serial IP of SoC is highly unlikely. My > understanding, maybe not correct, of "depends on" syntax is a kernel > source code, building or running dependency. I do not see it as a > hardware dependency. Although Samsung S3C/Exynos serial driver will > not exist outside of Samsung SoC, there is no kernel dependency. > Unless I missed something... The touchscreen is something different: I can easily mount that type of touchscreen on my own board, while I cannot integrate a Samsung serial port on my board, unless I'm using a Samsung SoC. > I understand and agree with concerns mentioned in [1] and in the > thread here, that removal of this "depends on" makes life of > distributions and generic users more difficult. To solve this problem > I was thinking about adding weaker type of dependency. A hint about > hardware dependency. Something like the "imply" is for "select". This > did not happen, therefore I still stand on my understanding of > "depends on" thus I gave positive feedback to Greg's patch. A weak dependency can be expressed using "|| COMPILE_TESTING". <(not so) wild idea> During the past few days, I've been giving this more thought. And I realized we might as well get rid of pci_driver, and just have platform_drivers that match against "pci<VendorID>,<DeviceID>" (yes, this is what real Open Firmware had in the compatible property, cfr. http://users.telenet.be/geertu/Linux/PPC/pci/ethernetAT4/). That way there would be no longer a build dependency on CONFIG_PCI, and we can drop all "depends on PCI" from driver Kconfig symbols. But would dropping that dependency be welcomed? Perhaps, as "everybody" uses PCI. Now repeat the exercise for Zorro, TURBOchannel, NuBus, Sbus, PCMCIA, ..., and wait for the outcry from Linus suddenly seeing lots of questions about support for hardware he can't possibly have in his machine... </(not so) wild idea> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx 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
