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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On Mon, 2024-10-14 at 13:12 -0700, Jakub Kicinski wrote:
> On Mon, 14 Oct 2024 08:25:35 +0100 David Woodhouse wrote:
> > On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote:
> > > On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote:  
> > > > +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? 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]