From: Srinivas Kandagatla <[email protected]>
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 <[email protected]>
---
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
On 05/31/2013 02:59 AM, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <[email protected]>
>
> 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 <[email protected]>
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
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
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