Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3

[Tero Kristo]

On 11/07/2019 08:49, Keerthy wrote:
> On 29/06/19 2:07 AM, Nishanth Menon wrote:
> > 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?
>
> Tero,
>
> Could you point me to a better place for enabling?

Well, thinking about what Nishanth said, we should probably keep the 
defconfig to bare minimal and only enable peripherals that are 
absolutely necessary for boot. We should eventually support eth / mmc-sd 
boot modes for K3 devices, but limit the configs to that.

Rest we can carry within TI internal defconfigs, including this GPIO 
enabler. If GPIO becomes a must have for some future device / 
peripheral, we can re-consider this.

-Tero

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

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki