All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.