Thread (9 messages) 9 messages, 4 authors, 2024-10-28

Re: [PATCH net-next v7] ptp: Add support for the AMZNC10C 'vmclock' device

From: David Woodhouse <dwmw2@infradead.org>
Date: 2024-10-19 17:49:32
Also in: linux-arm-kernel, linux-rtc, lkml, qemu-devel, virtualization

On Mon, 2024-10-14 at 13:12 -0700, Jakub Kicinski wrote:
On Mon, 14 Oct 2024 08:25:35 +0100 David Woodhouse wrote:
quoted
On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote:
quoted
On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:  
quoted
+config PTP_1588_CLOCK_VMCLOCK
+       tristate "Virtual machine PTP clock"
+       depends on X86_TSC || ARM_ARCH_TIMER
+       depends on PTP_1588_CLOCK && ACPI && ARCH_SUPPORTS_INT128
+       default y  
Why default to enabled? Linus will not be happy..  
Want an incremental patch to change that?
Yes please and thank you! We gotta straighten it out before 
the merge window.
Hm, as I (finally) come to do that, I realise that many of the others
defined in drivers/ptp/Kconfig are also 'default y'. Which is only
really 'default PTP_1588_CLOCK' in practice since they all depend on
that.

Most importantly, PTP_1588_CLOCK_KVM is 'default y'. And that one is
fundamentally broken (at least in the presence of live migration if
guests care about their clock suddenly being wrong) which is why it's
being superseded by the new VMCLOCK thing. We absolutely don't want to
leave the _KVM one enabled by default and not its _VMCLOCK replacement.

Please advise... I suspect the best answer is to leave it as it is? 

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help