From: Nishanth Menon <nm@ti.com>
To: Keerthy <j-keerthy@ti.com>
Cc: <t-kristo@ti.com>, <will.deacon@arm.com>,
<catalin.marinas@arm.com>, <shawnguo@kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <lokeshvutla@ti.com>
Subject: Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
Date: Fri, 28 Jun 2019 15:37:52 -0500 [thread overview]
Message-ID: <20190628203752.rdb6vvc42qd5ofgd@kahuna> (raw)
In-Reply-To: <39f5e726-8542-b650-3bdb-7542e8fab8ac@ti.com>
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
next prev parent reply other threads:[~2019-06-28 20:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 11:09 [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3 Keerthy
2019-06-27 14:32 ` Nishanth Menon
2019-06-28 3:38 ` Keerthy
2019-06-28 20:37 ` Nishanth Menon [this message]
2019-07-11 5:49 ` Keerthy
2019-07-11 7:16 ` Tero Kristo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190628203752.rdb6vvc42qd5ofgd@kahuna \
--to=nm@ti.com \
--cc=catalin.marinas@arm.com \
--cc=j-keerthy@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=shawnguo@kernel.org \
--cc=t-kristo@ti.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).