[RFC] clocksource: Add clocksource drivers menu.

[RFC] clocksource: Add clocksource drivers menu.

[Srinivas KANDAGATLA]

From: Srinivas Kandagatla <srinivas.kandagatla@st.com>

This patch adds "Clocksource drivers" menu to clocksource drivers.
The reason to add this is because, some of the clocksource Kconfig
options like *SHED_CLK ones are selectable and they appear at random
places in the device drivers menu.
These options can be more than one option for multiplatform case, so I
think it will be neat to get a menu to clocksource drivers itself.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
Hi All, 
I noticed that if my clock source has a selectable option, it appears as an
option under device drivers menu without any sub-menu, which seems to be bit
confusing and un-usual.

Having a dedicated menu for clock source makes much sense as these options might
grow as we have more than one clocksource driver as part of multi-platform
builds.

Thanks,
srini

 drivers/clocksource/Kconfig |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index f151c6c..2e0f37b 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -1,3 +1,5 @@
+menu "Clocksource drivers"
+
 config CLKSRC_OF
 	bool
 
@@ -85,3 +87,5 @@ config CLKSRC_SAMSUNG_PWM
 	  Samsung S3C, S5P and Exynos SoCs, replacing an earlier driver
 	  for all devicetree enabled platforms. This driver will be
 	  needed only on systems that do not have the Exynos MCT available.
+
+endmenu
-- 
1.7.6.5

Re: [RFC] clocksource: Add clocksource drivers menu.

[John Stultz]

On 05/31/2013 02:59 AM, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> This patch adds "Clocksource drivers" menu to clocksource drivers.
> The reason to add this is because, some of the clocksource Kconfig
> options like *SHED_CLK ones are selectable and they appear at random
> places in the device drivers menu.
> These options can be more than one option for multiplatform case, so I
> think it will be neat to get a menu to clocksource drivers itself.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>

Sigh. So I've done a poor job at being a maintainer[1], and sort of left 
the barn door open here.

I'd *really* like to avoid having a clocksource config menu. Looking at 
the existing RTC menu as an example, there's just a ton of random 
hardware names that the user has to try to figure out if it applies to 
their system or not. For instance, on x86 I have to filter through 90% 
of the RTC drivers that aren't ever even an option on any x86 hardware.

It just turns into a needless config headache.

And only just now did I notice that there are user-prompts in the 
drivers/clocksource/Kconfig.

I suspect the platform support options can safely select the proper 
clocksource config options without requiring the user to configure it. 
For the most part this is the case, even so folks still introduced some 
unnecessary clocksource config options (unnecessary as they don't prompt 
the user, default to y and depend on another config).

It looks like only: CLKSRC_DBX500_PRCMU & 
CLKSRC_DBX500_PRCMU_SCHED_CLOCK prompt the user right now.

Can you explain why its necessary the user has to be prompted here?

I know the situation isn't your fault, and you're just trying to clean 
things up here. However I'd much prefer removing the user-prompt and 
trying to remove unnecessary configs over creating a new config menu. 
And if there must be a user-selected config, I'd much rather it be a 
platform config option rather then some generic-seeming driver config.

thanks
-john

[1] I'm no good at flames. Linus does a much better job covering this topic:
     http://lkml.indiana.edu/hypermail/linux/kernel/1304.3/02435.html

Re: [RFC] clocksource: Add clocksource drivers menu.

[Srinivas KANDAGATLA]

On 31/05/13 19:40, John Stultz wrote:
> 
> And only just now did I notice that there are user-prompts in the
> drivers/clocksource/Kconfig.
> 
> I suspect the platform support options can safely select the proper
> clocksource config options without requiring the user to configure it.
> For the most part this is the case, even so folks still introduced some
> unnecessary clocksource config options (unnecessary as they don't prompt
> the user, default to y and depend on another config).
> 
> It looks like only: CLKSRC_DBX500_PRCMU &
> CLKSRC_DBX500_PRCMU_SCHED_CLOCK prompt the user right now.
> 
> Can you explain why its necessary the user has to be prompted here?

The only reason is to do with "how we present *SCHED_CLOCK options"?

If we make the *SCHED_CLOCK options default without prompts, then we do
not need a menu. These options can be selected at platform level
Kconfigs. We could possible cleanup the existing prompts.

Or

Make *SCHED_CLOCK option as a prompt then we do need a menu as these
prompts appear randomly in the menuconfig.

Am happy with either approach.

Thanks,
srini

> 
> I know the situation isn't your fault, and you're just trying to clean
> things up here. However I'd much prefer removing the user-prompt and
> trying to remove unnecessary configs over creating a new config menu.
> And if there must be a user-selected config, I'd much rather it be a
> platform config option rather then some generic-seeming driver config.
> 
> thanks
> -john

Re: [RFC] clocksource: Add clocksource drivers menu.

[John Stultz]

On 06/03/2013 12:23 AM, Srinivas KANDAGATLA wrote:
> On 31/05/13 19:40, John Stultz wrote:
>> And only just now did I notice that there are user-prompts in the
>> drivers/clocksource/Kconfig.
>>
>> I suspect the platform support options can safely select the proper
>> clocksource config options without requiring the user to configure it.
>> For the most part this is the case, even so folks still introduced some
>> unnecessary clocksource config options (unnecessary as they don't prompt
>> the user, default to y and depend on another config).
>>
>> It looks like only: CLKSRC_DBX500_PRCMU &
>> CLKSRC_DBX500_PRCMU_SCHED_CLOCK prompt the user right now.
>>
>> Can you explain why its necessary the user has to be prompted here?
> The only reason is to do with "how we present *SCHED_CLOCK options"?
>
> If we make the *SCHED_CLOCK options default without prompts, then we do
> not need a menu. These options can be selected at platform level
> Kconfigs. We could possible cleanup the existing prompts.

Right. This is what I'm asking for. Since there are only two options 
that prompt the user, I'm asking if there is a reason the user needs to 
be prompted.

I not, we can just remove the prompts and simplify the config.

If there is a valid reason to prompt the user, then we may need to add a 
menu, but I'd probably prefer we add the option in the platform menu, 
rather then generate a new driver menu.

thanks
-john