[lkml]   [2019]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3

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?


Could you point me to a better place for enabling?

- 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]
> [2]

 \ /
  Last update: 2019-07-11 07:50    [W:0.043 / U:31.136 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site