On Mon, 24 Jun 2019, Michael Kelley wrote: > From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> Sent: Sunday, June 23, 2019 3:13 PM > > > > I have no objections if you collect hyper-v stuff, quite the contrary, but > > changes which touch other subsystems need to be coordinated upfront. That's > > all I'm asking for. > > > > Btw, that clocksource stuff looks good code wise, just the change logs need > > some care and after the VDSO stuff hits next we need to sort out the > > logistics. I hope these changes are completely self contained. If not we'll > > find a solution. > > > > In my view, the only thing that potentially needs a solution is where the > Hyper-V clock code used by VDSO ends up in the code tree. I think the > right long term place is include/clocksource/hyperv_timer.h. That location > is architecture neutral, and the same Hyper-V clock code will be shared by > the Hyper-V on ARM64 support that's in process. > > Vincenzo's patch set creates a new file arch/x86/include/asm/mshyperv-tsc.h, > which I will want to move when creating the separate Hyper-V clocksource > driver. If you're OK with that file existing for a release and then going away, > that's fine. Alternatively, put the code in include/clocksource/hyperv_timer.h > now as part of the VDSO patch set so it's in the right place from the start. My > subsequent patch set will add a few additional tweaks to remove x86-isms > and fully integrate with the separate Hyper-V clocksource driver. I don't care whether this goes into 5.3 or later. If you can provide me rebased self contained patches on top of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso I'm happy to pull them in on top. Thanks, tglx
