On Tue, Aug 25, 2020 at 11:20 PM Michael Kelley [off-list ref] wrote:

From: Arnd Bergmann <arnd@arndb.de> Sent: Monday, August 24, 2020 11:34 AM

quoted

On Mon, Aug 24, 2020 at 6:48 PM Michael Kelley [off-list ref] wrote:

I think this has come up before, and I still don't consider it an acceptable
hack to hook platform initialization code into the timer code.

Please split out the timer into a standalone driver in drivers/clocksource
that can get reviewed by the clocksource maintainers.

I see two related topics here.

Agreed

 First, the Hyper-V clocksource driver is
drivers/clocksource/hyperv_timer.c.  The code is architecture independent
and is used today on the x86 side and for ARM64 in this patch series.  A few
architecture specific calls are satisfied by code under arch/x86, and in this
patch series, under arch/arm64.  Is there some aspect of this driver that
needs reconsideration?  I just want to make sure to understand what you
are getting at.

For the clocksource driver, I would like to see the arm64 specific bits
(the code you add in arch/arm64 that are only relevant to this driver)
moved out of arch/arm64 and into drivers/clocksource, in whatever
form the clocksource maintainers prefer. I would suggest having a
separate file that can get linked along with the architecture-independent
part of that driver.

Second is the question of where/how to do Hyper-V specific initialization.
I agree that hanging it off the timer initialization isn't a great approach.
Should I add a Hyper-V specific initialization call at the appropriate point
in the ARM64 init sequence?  The x86 side has some structure for handling
multiple hypervisors, and the Hyper-V initialization code naturally plugs into
that structure.  I'm certainly open to suggestions on the best way to handle
it for ARM64.

Yes, that is where I was getting at. Maybe the x86 abstraction for handling
multiple hypervisors can be lifted out of arch/x86/ into common code?

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel