On Wed, 26 May 2021 09:18:27 +0100,
Geert Uytterhoeven [off-list ref] wrote:

Hi Marc,

On Wed, May 26, 2021 at 10:01 AM Marc Zyngier [off-list ref] wrote:

quoted

On Wed, 26 May 2021 08:52:42 +0100,
Geert Uytterhoeven [off-list ref] wrote:

quoted

On Tue, May 11, 2021 at 11:13 AM Marc Zyngier [off-list ref] wrote:

quoted

On 2021-05-11 10:07, Geert Uytterhoeven wrote:

quoted

On Tue, Mar 30, 2021 at 4:56 PM Marc Zyngier [off-list ref] wrote:

quoted

From: Jianyong Wu <redacted>

quoted

--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig

@@ -108,7 +108,7 @@ config PTP_1588_CLOCK_PCH
 config PTP_1588_CLOCK_KVM
        tristate "KVM virtual PTP clock"
        depends on PTP_1588_CLOCK
-       depends on KVM_GUEST && X86
+       depends on (KVM_GUEST && X86) || (HAVE_ARM_SMCCC_DISCOVERY &&

ARM_ARCH_TIMER)

Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:

    KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))

?

arm/arm64 do not select KVM_GUEST. Any kernel can be used for a guest,
and KVM/arm64 doesn't know about this configuration symbol.

OK.

Does PTP_1588_CLOCK_KVM need to default to yes?
Perhaps only on X86, to maintain the status quo?

I think I don't really understand the problem you are trying to
solve. Is it that 'make oldconfig' now asks you about this new driver?
Why is that an issue?

My first "problem" was that it asked about this new driver on
arm/arm64, while I assumed there were some missing dependencies
(configuring a kernel should not ask useless questions).  That turned
out to be a wrong assumption, so there is no such problem here.

The second problem is "default y": code that is not critical should
not be enabled by default.  Hence my last question.

I think consistency between architectures is important. Certainly,
distributions depend on that, and we otherwise end-up with distro
kernels missing functionalities.

The notion of "critical" is also pretty relative. defconfig contains a
gazillion of things that are not critical to most people, for example,
and yet misses a bunch of things that are needed to boot on some of my
systems.

That's just to say that I find it difficult to make that choice from
the PoV of a kernel hacker. I'm personally more inclined to leave
things enabled and let people *disable* things if they want to reduce
the footprint of their kernel.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

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