From: Arnd Bergmann <arnd@arndb.de>
To: Joel Stanley <joel@jms.id.au>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/6] ARM: config: multi v7: Clean up enabled by default options
Date: Fri, 11 Jun 2021 12:14:17 +0200 [thread overview]
Message-ID: <CAK8P3a0H7ET7fESoySmmhpH6D3N3tjd0Ra-9zxaGAKpy-jEWJQ@mail.gmail.com> (raw)
In-Reply-To: <CACPK8Xd7g87gnGeOkMHnD+DfofcbEaxZHsb5kqkTc+txoj16PQ@mail.gmail.com>
On Fri, Jun 11, 2021 at 5:29 AM Joel Stanley <joel@jms.id.au> wrote:
>
> On Thu, 10 Jun 2021 at 07:58, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > > PTP_1588_CLOCK is implied by enabled drivers STMMAC_ETH, IGB, E1000E and FEC.
> >
> > I still feel a little uneasy about not enabling PTP_1588_CLOCK in case
> > we get rid of that
> > 'imply', the rest looks good.
>
> If we got rid of the imply, would it become a select?
>
> I realise that's bad form, but if these drivers need that functionality...
That would need some further discussion. I think we have two distinct
cases:
- some drivers can use the PTP_1588_CLOCK feature if that symbol
is built-in, or both the driver and the ptp support are loadable modules.
If the drivers are built-in, but PTP_1588_CLOCK=m, they currently
silently break, which is unfortunate and often unexpected.
The 'imply' keyword was originally intended to work around this
problem but doesn't do that any more.
- Some drivers have a separate Kconfig symbol for enabling PTP
support within a driver that is controlled separately. These tend to
use 'depends on PTP_1588_CLOCK'.
I would hope that we can at least be consistent with 'select'
vs 'depends on' here, but either solution is possible. One option
that would work is to have a global setting that decides whether
PTP support is available to drivers at all, and then another
symbol that gets selected by drivers to decide whether it ends
up built-in or in a loadable module.
> Happy to re-roll with that change dropped, just let me know.
That would be my preference, yes.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-11 10:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 3:54 [PATCH v2 0/6] ARM: config: Refresh multi v7 Joel Stanley
2021-06-10 3:54 ` [PATCH v2 1/6] ARM: config: multi v7: Drop unavailable options Joel Stanley
2021-06-10 7:49 ` Arnd Bergmann
2021-06-10 3:54 ` [PATCH v2 2/6] ARM: config: multi v7: Clean up enabled by default options Joel Stanley
2021-06-10 7:56 ` Arnd Bergmann
2021-06-11 3:29 ` Joel Stanley
2021-06-11 10:14 ` Arnd Bergmann [this message]
2021-06-10 3:54 ` [PATCH v2 3/6] ARM: config: multi v7: Add renamed symbols Joel Stanley
2021-06-10 7:51 ` Arnd Bergmann
2021-06-10 3:54 ` [PATCH v2 4/6] ARM: config: multi v7: Enable dependancies Joel Stanley
2021-06-10 7:51 ` Arnd Bergmann
2021-06-10 3:54 ` [PATCH v2 5/6] ARM: config: mutli v7: Reenable FB dependency Joel Stanley
2021-06-10 7:52 ` Arnd Bergmann
2021-06-10 3:54 ` [PATCH v2 6/6] ARM: config: multi v7: Regenerate defconifg Joel Stanley
2021-06-10 7:52 ` Arnd Bergmann
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=CAK8P3a0H7ET7fESoySmmhpH6D3N3tjd0Ra-9zxaGAKpy-jEWJQ@mail.gmail.com \
--to=arnd@arndb.de \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
/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).