[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <97f02ddd-5e9a-440a-bda8-82c2fd7957d5@sirena.org.uk>
Date: Tue, 9 Jul 2024 17:33:46 +0100
From: Mark Brown <broonie@...nel.org>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
David Abdurachmanov <david.abdurachmanov@...il.com>,
Sudeep Holla <sudeep.holla@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Ross Burton <ross.burton@....com>
Subject: Re: [PATCH v2] clocksource: sp804: Make user selectable
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:
> > > 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.
That's not what the changelog claimed was the reason for adding the
dependency, and we have other number of Kconfig options (eg,
TEGRA186_TIMER or ARM_ARCH_TIMER_EVTSTREAM) which don't. There does
seem to be a bit of a randomness if the options are only visible with
COMPILE_TEST too, quite a few depend on an arch or COMPILE_TEST.
> My suggestion was to provide the option in the platforms Kconfig and
> [un]select the ARM_TIMER_SP804 from there
I can't parse what that means, sorry. The goal here is to not have the
FVP platforms depend on the driver since they don't actually depend on
it, it's merely physially present.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists