Message-ID: <41475b80-4a9a-b594-7f66-5bf9b94c0bf0@ti.com>
Date:   Thu, 11 Jul 2019 10:16:59 +0300
From:   Tero Kristo <t-kristo@...com>
To:     Keerthy <j-keerthy@...com>, Nishanth Menon <nm@...com>
CC:     <will.deacon@....com>, <catalin.marinas@....com>,
        <shawnguo@...nel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <lokeshvutla@...com>
Subject: Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for
 ARCH_K3

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

Powered by blists - more mailing lists