Re: [PATCH v2] clocksource: sp804: Make user selectable

[Mark Rutland <mark.rutland@arm.com>]

On Tue, Jul 09, 2024 at 06:15:40PM +0200, Daniel Lezcano wrote:
> On 08/07/2024 19:44, Mark Brown wrote:
> > On Mon, Jul 08, 2024 at 06:49:38PM +0200, Daniel Lezcano wrote:
> > > On 29/05/2024 21:48, Mark Brown wrote:
> > 
> > > > The sp804 is currently only user selectable if COMPILE_TEST, this was
> > > > done by commit dfc82faad725 ("clocksource/drivers/sp804: Add
> > > > COMPILE_TEST to CONFIG_ARM_TIMER_SP804") in order to avoid it being
> > > > spuriously offered on platforms that won't have the hardware since it's
> > > > generally only seen on Arm based platforms.  This config is overly
> > > > restrictive, while platforms that rely on the SP804 do select it in
> > > > their Kconfig there are others such as the Arm fast models which have a
> > > > SP804 available but currently unused by Linux.  Relax the dependency to
> > > > allow it to be user selectable on arm and arm64 to avoid surprises and
> > > > in case someone comes up with a use for extra timer hardware.
> > 
> > > Would it make sense to add the option in the platform so it selects the
> > > timer ?
> > 
> > As the commit log says far as I'm aware all the platforms that rely on
> > the sp804 timer already select it (they wouldn't otherwise be able to
> > work unless COMPILE_TEST was enabled).  The Arm models and possibly
> > other platforms have the sp804 but it will currently be ignored by Linux
> > and the architected timers used instead so it would be wasteful to force
> > it on for them.
> 
> The policy of the Kconfig is we should keep the option silent.

Why?

I can understand hiding an option when it *really* depends on something
that isn't available, but the kernel not having knowledge of a specific
soc/platform isn't the same thing -- it's an entirely synthetic
dependency.

What problem is solved by not allowing the user to select this?

> My suggestion was to provide the option in the platforms Kconfig and
> [un]select the ARM_TIMER_SP804 from there

As above, that means that the kernel needs to have knowledge of the
specific platform, which in general we've been moving *away* form (e.g.
with DT and ACPI tables). For virtial platformas specifically that's a
massive pain because they're *so* configurable -- there's not much the
kernel can rely on being present/absent, and users will want to enable
specific features depending on what they're trying to test, at which
point they'd have to hack Kconfig files...

Mark.

> 
> 
> -- 
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
> 
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
> 
>