On 09:08-20190628, Keerthy wrote: [..] > > > + select GPIO_SYSFS > > > + select GPIO_DAVINCI > > > > > > Could you help explain the logic of doing this? commit message is > > basically the diff in English. To me, this does NOT make sense. > > > > I understand GPIO_DAVINCI is the driver compatible, but we cant do this for > > every single SoC driver that is NOT absolutely mandatory for basic > > functionality. > > In case of ARM64 could you help me find the right place to enable > such SoC specific configs?
Is'nt that what defconfig is supposed to be all about? arch/arm64/configs/defconfig > > > > > Also keep in mind the impact to arm64/configs/defconfig -> every single > > SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force > > that? > > This was the practice in arm32 soc specific configs like > omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i totally > understand your concern about every single SoC rebuilding but now where do > we need to enable the bare minimal GPIO_DAVINCI config? Well, SYSFS, I cannot agree testing as the rationale in Kconfig.platform. And, looking at [1], I see majority being mandatory components for the SoC bootup. However, most of the "optional" drivers go into arm64 as defconfig (preferably as a module?) and if you find a rationale for recommending DEBUG_GPIO, you could propose that to the community as well. Now, Thinking about this, I'd even challenge the current list of configs as being "select". I'd rather do an "imply"[2] - yes, you need this for the default dtb to boot, however a carefully carved dtb could boot with lesser driver set to get a smaller (and less functional) kernel. > > v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i > shifted to this approach. I noticed that you were posting a v2, for future reference, please use diffstat section to point to lore/patchworks link to point at v1 (I did notice you mentioned you had an update, thanks - link will help catch up on older discussions). This helps a later revision reviewer like me to get context. Tero, would you be able to help with a better rationale as to where the boundaries are to be in your mind, rather than risk every single peripheral driver getting into ARCH_K3? As of right now, I'd rather we do not explode the current list out of bounds. NAK unless we can find a better rationale. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Kconfig.platforms [2] https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt -- Regards, Nishanth Menon
