Hi Darren, On Thu, 27 Apr 2017 14:13:22 -0700, Darren Hart wrote: > On Tue, Apr 25, 2017 at 12:19:39PM +0200, Jean Delvare wrote: > > Thanks for the pointer Andy. OK, I can understand the argument of > > Dmitry that platform-specific quirks do not belong to the device > > drivers, even though in practice I'm not sure the cost of having a > > separate platform driver for the purpose is always worth it - depends > > on how "popular" the device is, I suppose. > > > > But still, this can't justify non-modular platform code that will run > > on every X86 system out there. Any piece of platform-specific quirks, > > we should be able to build as a module, otherwise it simply doesn't > > scale. PCI quirks and such are enough pain already without inventing > > more flavors of bloat :-( > > Jean makes a good point. I would insist on this if the Kconfig default was y or > if distros were likely to enable this by default. However, this is for the still > very rare x86 tablet and is likely to only be enabled for those systems which > require it. The problem is that there is no clear line of what hardware openSUSE kernels should support or not. I don't know if other general purpose Linux distributions have made any statement on the matter, but we have not. As a matter of fact, the person in charge of deciding what to do with new kernel drivers did enable both Silead touchscreen options in our standard i386 and x86_64 kernels. There are also people working on getting openSUSE to run on odd hardware such as the GPD Win, and we have ARM kernels running on embedded platforms. As X86-based embedded platforms are getting popular, what sense would it make to support everything from X86 servers to embedded ARM but rule out X86 tablets? Especially when hybrid laptop/tablet designs are becoming more popular as well. The same touchscreen device used for pure tablets may be used for hybrid models tomorrow. This is one of the reasons why modular drivers are a must. If we enable them when we shouldn't have, the cost stays low. Of course it would be better if we could just enable what we really need, but in practice this is terribly hard to achieve. This is also the reason why I am actively promoting the mentioning of intended target hardware on new drivers, to limit the risks of us enabling drivers on kernels that don't need it. > (...) > While the default for Kconfig is n if not explicitly set to m or y, perhaps > "default n" should be added to TOUCHSCREEN_SILEAD and SILEAD_DMI to make it more > explicit. I don't know if there is an official preference on "default n" > statements or not. I wondered before as well. But given that n is the default default, and an explicit default is not listed by "make config" nor "make menuconfig", I can't see the value of "default n". It makes no difference for the user. In fact my never-ending project list has a point "Kconfig: kill all default n and add a test to checkpatch so they don't come back". Chances that I get to that one before retirement are low though. I am not convinced that a default value for a device driver makes any sense in the first place. If you don't need support for the device, you don't enable the driver, period. I can't see how a default answer can be relevant. In this specific case, the default answer should be n if not building a kernel for tablets. But would become y if building a kernel for tablets. What reason would there be to favor one scenario over the other? I believe default values are only useful for driver feature options, general kernel configuration options, or automatic selection of hidden options. -- Jean Delvare SUSE L3 Support
