From: Jean Delvare <jdelvare@suse.de>
To: "Andreas Färber" <afaerber@suse.de>
Cc: linux-clk@vger.kernel.org, linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
James Liao <jamesjj.liao@mediatek.com>,
Erin Lo <erin.lo@mediatek.com>,
Stephen Boyd <sboyd@codeaurora.org>,
Shunli Wang <shunli.wang@mediatek.com>,
Michael Turquette <mturquette@baylibre.com>
Subject: Re: [PATCH] clk: mediatek: Fix MT2701 dependencies
Date: Tue, 24 Jan 2017 13:58:36 +0100 [thread overview]
Message-ID: <20170124135836.17f32ade@endymion> (raw)
In-Reply-To: <c3da261a-eb85-9b30-d5e2-05863d2efad2@suse.de>
Hallo Andreas,
On Mon, 9 Jan 2017 21:08:50 +0100, Andreas F=C3=A4rber wrote:
> Another aspect here is that this is a 32-bit SoC but it propagates into
> the arm64 configs, so maybe (ARCH_MEDIATEK && !ARM64) || COMPILE_TEST?
>=20
> Same for mt2701 pinctrl.
I took a look and the pinctrl situation is different:
config PINCTRL_MT2701
bool "Mediatek MT2701 pin control" if COMPILE_TEST && !MACH_MT2701
(...)
default MACH_MT2701
So the user will not be prompt about it on ARM64 (unless build-testing)
because MACH_MT2701 isn't set on ARM64. The only issue with this
construct is that you end up with useless symbols defined in the
configuration file (they can only be "n".) So I would argue that the
following is preferred:
config PINCTRL_MT2701
bool "Mediatek MT2701 pin control"
(...)
depends on MACH_MT2701 || COMPILE_TEST
default MACH_MT2701
And same for the other 3 PINCTRL_MT* options. Yes, that means the user
will be asked about the options on Mediatek kernels, but actually I
believe this is desirable, as advanced users should be allowed to
disable specific drivers if they know what they are doing. Other users
can just stick to the default.
--=20
Jean Delvare
SUSE L3 Support
WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <jdelvare@suse.de>
To: "Andreas Färber" <afaerber@suse.de>
Cc: linux-clk@vger.kernel.org, linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
James Liao <jamesjj.liao@mediatek.com>,
Erin Lo <erin.lo@mediatek.com>,
Stephen Boyd <sboyd@codeaurora.org>,
Shunli Wang <shunli.wang@mediatek.com>,
Michael Turquette <mturquette@baylibre.com>
Subject: Re: [PATCH] clk: mediatek: Fix MT2701 dependencies
Date: Tue, 24 Jan 2017 13:58:36 +0100 [thread overview]
Message-ID: <20170124135836.17f32ade@endymion> (raw)
In-Reply-To: <c3da261a-eb85-9b30-d5e2-05863d2efad2@suse.de>
Hallo Andreas,
On Mon, 9 Jan 2017 21:08:50 +0100, Andreas Färber wrote:
> Another aspect here is that this is a 32-bit SoC but it propagates into
> the arm64 configs, so maybe (ARCH_MEDIATEK && !ARM64) || COMPILE_TEST?
>
> Same for mt2701 pinctrl.
I took a look and the pinctrl situation is different:
config PINCTRL_MT2701
bool "Mediatek MT2701 pin control" if COMPILE_TEST && !MACH_MT2701
(...)
default MACH_MT2701
So the user will not be prompt about it on ARM64 (unless build-testing)
because MACH_MT2701 isn't set on ARM64. The only issue with this
construct is that you end up with useless symbols defined in the
configuration file (they can only be "n".) So I would argue that the
following is preferred:
config PINCTRL_MT2701
bool "Mediatek MT2701 pin control"
(...)
depends on MACH_MT2701 || COMPILE_TEST
default MACH_MT2701
And same for the other 3 PINCTRL_MT* options. Yes, that means the user
will be asked about the options on Mediatek kernels, but actually I
believe this is desirable, as advanced users should be allowed to
disable specific drivers if they know what they are doing. Other users
can just stick to the default.
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2017-01-24 12:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-09 10:36 [PATCH] clk: mediatek: Fix MT2701 dependencies Jean Delvare
2017-01-09 20:08 ` Andreas Färber
2017-01-10 12:03 ` Jean Delvare
2017-01-10 12:03 ` Jean Delvare
2017-01-11 1:56 ` James Liao
2017-01-11 12:41 ` Jean Delvare
2017-01-11 12:41 ` Jean Delvare
2017-01-11 14:05 ` Yingjoe Chen
2017-01-11 14:42 ` Jean Delvare
2017-01-12 3:39 ` James Liao
2017-01-12 8:40 ` Jean Delvare
2017-01-12 8:40 ` Jean Delvare
2017-01-20 23:22 ` Stephen Boyd
2017-01-24 9:46 ` Jean Delvare
2017-01-24 12:58 ` Jean Delvare [this message]
2017-01-24 12:58 ` Jean Delvare
2017-01-10 2:32 ` James Liao
2017-01-10 2:32 ` James Liao
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=20170124135836.17f32ade@endymion \
--to=jdelvare@suse.de \
--cc=afaerber@suse.de \
--cc=erin.lo@mediatek.com \
--cc=jamesjj.liao@mediatek.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.org \
--cc=shunli.wang@mediatek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.