[PATCH 0/3] No longer default to HW_RANDOM when UML_RANDOM is the trigger

[PATCH 0/3] No longer default to HW_RANDOM when UML_RANDOM is the trigger

[Dragan Simic]

This is a small patch series that makes the already existing HW_RANDOM_*
options in the hw_random Kconfig selected by default only when the
UML_RANDOM option isn't already selected.  Having the HW_RANDOM_* options
selected doesn't make much sense for user-mode Linux (UML), which obviously
cannot make use of any HWRNG devices.

Along the way, some additional trivial cleanups of the hw_random Kconfig
file are also performed as spotted, in separate patches.

Dragan Simic (3):
  hwrng: Use tabs as leading whitespace consistently in Kconfig
  hwrng: Move one "tristate" Kconfig description to the usual place
  hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

 drivers/char/hw_random/Kconfig | 84 +++++++++++++++++-----------------
 1 file changed, 42 insertions(+), 42 deletions(-)

[PATCH 1/3] hwrng: Use tabs as leading whitespace consistently in Kconfig

[Dragan Simic]

Replace instances of leading size-eight groups of space characters with
the usual tab characters, as spotted in the hw_random Kconfig file.

No intended functional changes are introduced by this trivial cleanup.

Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
 drivers/char/hw_random/Kconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 17854f052386..e0244a66366b 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -579,10 +579,10 @@ config HW_RANDOM_ARM_SMCCC_TRNG
 	  module will be called arm_smccc_trng.
 
 config HW_RANDOM_CN10K
-       tristate "Marvell CN10K Random Number Generator support"
-       depends on HW_RANDOM && PCI && (ARM64 || (64BIT && COMPILE_TEST))
-       default HW_RANDOM if ARCH_THUNDER
-       help
+	tristate "Marvell CN10K Random Number Generator support"
+	depends on HW_RANDOM && PCI && (ARM64 || (64BIT && COMPILE_TEST))
+	default HW_RANDOM if ARCH_THUNDER
+	help
 	 This driver provides support for the True Random Number
 	 generator available in Marvell CN10K SoCs.
 

[PATCH 2/3] hwrng: Move one "tristate" Kconfig description to the usual place

[Dragan Simic]

It's pretty usual to have "tristate" descriptions in Kconfig files placed
immediately after the actual configuration options, so correct the position
of one misplaced "tristate" spotted in the hw_random Kconfig file.

No intended functional changes are introduced by this trivial cleanup.

Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
 drivers/char/hw_random/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index e0244a66366b..e84c7f431840 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -534,10 +534,10 @@ config HW_RANDOM_NPCM
 	  If unsure, say Y.
 
 config HW_RANDOM_KEYSTONE
+	tristate "TI Keystone NETCP SA Hardware random number generator"
 	depends on ARCH_KEYSTONE || COMPILE_TEST
 	depends on HAS_IOMEM && OF
 	default HW_RANDOM
-	tristate "TI Keystone NETCP SA Hardware random number generator"
 	help
 	  This option enables Keystone's hardware random generator.
 

[PATCH 3/3] hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

[Dragan Simic]

Since the commit 72d3e093afae (um: random: Register random as hwrng-core
device), selecting the UML_RANDOM option may result in various HW_RANDOM_*
options becoming selected as well, which doesn't make much sense for UML
that obviously cannot use any of those HWRNG devices.

Let's have the HW_RANDOM_* options selected by default only when UML_RANDOM
actually isn't already selected.  With that in place, selecting UML_RANDOM
no longer "triggers" the selection of various HW_RANDOM_* options.

Fixes: 72d3e093afae (um: random: Register random as hwrng-core device)
Reported-by: Diederik de Haas <didi.debian@cknow.org>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
 drivers/char/hw_random/Kconfig | 76 +++++++++++++++++-----------------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index e84c7f431840..283aba711af5 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -38,47 +38,47 @@ config HW_RANDOM_TIMERIOMEM
 config HW_RANDOM_INTEL
 	tristate "Intel HW Random Number Generator support"
 	depends on (X86 || COMPILE_TEST) && PCI
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Intel i8xx-based motherboards.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called intel-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_AMD
 	tristate "AMD HW Random Number Generator support"
 	depends on (X86 || COMPILE_TEST)
 	depends on PCI && HAS_IOPORT_MAP
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on AMD 76x-based motherboards.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called amd-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_AIROHA
 	tristate "Airoha True HW Random Number Generator support"
 	depends on ARCH_AIROHA || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the True Random Number
 	  Generator hardware found on Airoha SoC.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called airoha-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_ATMEL
 	tristate "Atmel Random Number Generator support"
 	depends on (ARCH_AT91 || COMPILE_TEST)
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Atmel AT91 devices.
@@ -102,139 +102,139 @@ config HW_RANDOM_BCM2835
 	tristate "Broadcom BCM2835/BCM63xx Random Number Generator support"
 	depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X || \
 		   ARCH_BCMBCA || BCM63XX || BMIPS_GENERIC || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on the Broadcom BCM2835 and BCM63xx SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called bcm2835-rng
 
 	  If unsure, say Y.
 
 config HW_RANDOM_BCM74110
 	tristate "Broadcom BCM74110 Random Number Generator support"
 	depends on ARCH_BRCMSTB || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on the Broadcom BCM74110 SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called bcm74110-rng
 
 	  If unsure, say Y.
 
 config HW_RANDOM_IPROC_RNG200
 	tristate "Broadcom iProc/STB RNG200 support"
 	depends on ARCH_BCM_IPROC || ARCH_BCM2835 || ARCH_BCMBCA || ARCH_BRCMSTB || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the RNG200
 	  hardware found on the Broadcom iProc and STB SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called iproc-rng200
 
 	  If unsure, say Y.
 
 config HW_RANDOM_GEODE
 	tristate "AMD Geode HW Random Number Generator support"
 	depends on (X86_32 || COMPILE_TEST)
 	depends on PCI
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on the AMD Geode LX.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called geode-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_N2RNG
 	tristate "Niagara2 Random Number Generator support"
 	depends on SPARC64
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Niagara2 cpus.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called n2-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_VIA
 	tristate "VIA HW Random Number Generator support"
 	depends on X86
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on VIA based motherboards.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called via-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_IXP4XX
 	tristate "Intel IXP4xx NPU HW Pseudo-Random Number Generator support"
 	depends on ARCH_IXP4XX || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Pseudo-Random
 	  Number Generator hardware found on the Intel IXP45x/46x NPU.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called ixp4xx-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_OMAP
 	tristate "OMAP Random Number Generator support"
 	depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || ARCH_MVEBU || ARCH_K3 || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on OMAP16xx, OMAP2/3/4/5, AM33xx/AM43xx
 	  multimedia processors, and Marvell Armada 7k/8k SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called omap-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_OMAP3_ROM
 	tristate "OMAP3 ROM Random Number Generator support"
 	depends on ARCH_OMAP3 || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on OMAP34xx processors.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called omap3-rom-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_OCTEON
 	tristate "Octeon Random Number Generator support"
 	depends on CAVIUM_OCTEON_SOC
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Octeon processors.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called octeon-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_PASEMI
 	tristate "PA Semi HW Random Number Generator support"
 	depends on PPC_PASEMI || (PPC && COMPILE_TEST)
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on PA Semi PWRficient SoCs.
@@ -257,114 +257,114 @@ config HW_RANDOM_VIRTIO
 config HW_RANDOM_MXC_RNGA
 	tristate "Freescale i.MX RNGA Random Number Generator"
 	depends on SOC_IMX31 || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Freescale i.MX processors.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called mxc-rnga.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_IMX_RNGC
 	tristate "Freescale i.MX RNGC Random Number Generator"
 	depends on HAS_IOMEM
 	depends on SOC_IMX25 || SOC_IMX6SL || SOC_IMX6SLL || SOC_IMX6UL || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator Version C hardware found on some Freescale i.MX
 	  processors. Version B is also supported by this driver.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called imx-rngc.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_INGENIC_RNG
 	tristate "Ingenic Random Number Generator support"
 	depends on MACH_JZ4780 || MACH_X1000 || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number Generator
 	  hardware found in ingenic JZ4780 and X1000 SoC. MIPS Creator CI20 uses
 	  JZ4780 SoC, YSH & ATIL CU1000-Neo uses X1000 SoC.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called ingenic-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_INGENIC_TRNG
 	tristate "Ingenic True Random Number Generator support"
 	depends on MACH_X1830 || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the True Random Number Generator
 	  hardware found in ingenic X1830 SoC. YSH & ATIL CU1830-Neo uses X1830 SoC.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called ingenic-trng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_NOMADIK
 	tristate "ST-Ericsson Nomadik Random Number Generator support"
 	depends on ARCH_NOMADIK || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on ST-Ericsson SoCs (8815 and 8500).
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called nomadik-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_PSERIES
 	tristate "pSeries HW Random Number Generator support"
 	depends on PPC64 && IBMVIO
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on POWER7+ machines and above
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called pseries-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_POWERNV
 	tristate "PowerNV Random Number Generator support"
 	depends on PPC_POWERNV
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This is the driver for Random Number Generator hardware found
 	  in POWER7+ and above machines for PowerNV platform.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called powernv-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_HISI
 	tristate "Hisilicon Random Number Generator support"
 	depends on ARCH_HISI || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Hisilicon Hip04 and Hip05 SoC.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called hisi-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_HISTB
 	tristate "Hisilicon STB Random Number Generator support"
 	depends on ARCH_HISI || COMPILE_TEST
-	default ARCH_HISI
+	default ARCH_HISI if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Hisilicon Hi37xx SoC.
@@ -385,34 +385,34 @@ config HW_RANDOM_ST
 config HW_RANDOM_XGENE
 	tristate "APM X-Gene True Random Number Generator (TRNG) support"
 	depends on ARCH_XGENE || COMPILE_TEST
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on APM X-Gene SoC.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called xgene_rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_STM32
 	tristate "STMicroelectronics STM32 random number generator"
 	depends on ARCH_STM32 || COMPILE_TEST
 	depends on HAS_IOMEM
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on STM32 microcontrollers.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called stm32-rng.
 
 	  If unsure, say N.
 
 config HW_RANDOM_PIC32
 	tristate "Microchip PIC32 Random Number Generator support"
 	depends on MACH_PIC32 || COMPILE_TEST
-	default HW_RANDOM if MACH_PIC32
+	default HW_RANDOM if MACH_PIC32 && !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on a PIC32.
@@ -439,105 +439,105 @@ config HW_RANDOM_MESON
 	tristate "Amlogic Meson Random Number Generator support"
 	depends on ARCH_MESON || COMPILE_TEST
 	depends on HAS_IOMEM && OF
-	default HW_RANDOM if ARCH_MESON
+	default HW_RANDOM if ARCH_MESON && !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Amlogic Meson SoCs.
 
 	  To compile this driver as a module, choose M here. the
 	  module will be called meson-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_CAVIUM
 	tristate "Cavium ThunderX Random Number Generator support"
 	depends on PCI
 	depends on ARCH_THUNDER || (ARM64 && COMPILE_TEST)
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Cavium SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called cavium_rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_MTK
 	tristate "Mediatek Random Number Generator support"
 	depends on ARCH_MEDIATEK || COMPILE_TEST
 	depends on HAS_IOMEM && OF
-	default HW_RANDOM if ARCH_MEDIATEK
+	default HW_RANDOM if ARCH_MEDIATEK && !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
 	  Generator hardware found on Mediatek SoCs.
 
 	  To compile this driver as a module, choose M here. the
 	  module will be called mtk-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_S390
 	tristate "S390 True Random Number Generator support"
 	depends on S390
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the True
 	  Random Number Generator available as CPACF extension
 	  on modern s390 hardware platforms.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called s390-trng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_EXYNOS
 	tristate "Samsung Exynos True Random Number Generator support"
 	depends on ARCH_EXYNOS || COMPILE_TEST
 	depends on HAS_IOMEM
-	default HW_RANDOM if ARCH_EXYNOS
+	default HW_RANDOM if ARCH_EXYNOS && !UML_RANDOM
 	help
 	  This driver provides support for the True Random Number
 	  Generator available in Exynos SoCs.
 
 	  To compile this driver as a module, choose M here: the module
 	  will be called exynos-trng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_OPTEE
 	tristate "OP-TEE based Random Number Generator support"
 	depends on OPTEE
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This  driver provides support for OP-TEE based Random Number
 	  Generator on ARM SoCs where hardware entropy sources are not
 	  accessible to normal world (Linux).
 
 	  To compile this driver as a module, choose M here: the module
 	  will be called optee-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_NPCM
 	tristate "NPCM Random Number Generator support"
 	depends on ARCH_NPCM || COMPILE_TEST
 	depends on HAS_IOMEM
-	default HW_RANDOM if ARCH_NPCM
+	default HW_RANDOM if ARCH_NPCM && !UML_RANDOM
 	help
 	  This driver provides support for the Random Number
 	  Generator hardware available in Nuvoton NPCM SoCs.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called npcm-rng.
 
 	  If unsure, say Y.
 
 config HW_RANDOM_KEYSTONE
 	tristate "TI Keystone NETCP SA Hardware random number generator"
 	depends on ARCH_KEYSTONE || COMPILE_TEST
 	depends on HAS_IOMEM && OF
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This option enables Keystone's hardware random generator.
 
@@ -567,21 +567,21 @@ config HW_RANDOM_XIPHERA
 config HW_RANDOM_ARM_SMCCC_TRNG
 	tristate "Arm SMCCC TRNG firmware interface support"
 	depends on HAVE_ARM_SMCCC_DISCOVERY
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  Say 'Y' to enable the True Random Number Generator driver using
 	  the Arm SMCCC TRNG firmware interface. This reads entropy from
 	  higher exception levels (firmware, hypervisor). Uses SMCCC for
 	  communicating with the firmware:
 	  https://developer.arm.com/documentation/den0098/latest/
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called arm_smccc_trng.
 
 config HW_RANDOM_CN10K
 	tristate "Marvell CN10K Random Number Generator support"
 	depends on HW_RANDOM && PCI && (ARM64 || (64BIT && COMPILE_TEST))
-	default HW_RANDOM if ARCH_THUNDER
+	default HW_RANDOM if ARCH_THUNDER && !UML_RANDOM
 	help
 	 This driver provides support for the True Random Number
 	 generator available in Marvell CN10K SoCs.
@@ -603,7 +603,7 @@ config HW_RANDOM_ROCKCHIP
 	tristate "Rockchip True Random Number Generator"
 	depends on HW_RANDOM && (ARCH_ROCKCHIP || COMPILE_TEST)
 	depends on HAS_IOMEM
-	default HW_RANDOM
+	default HW_RANDOM if !UML_RANDOM
 	help
 	  This driver provides kernel-side support for the True Random Number
 	  Generator hardware found on some Rockchip SoC like RK3566 or RK3568.

Re: [PATCH 3/3] hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

[Diederik de Haas]

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

Hi,

On Wed Jan 15, 2025 at 2:07 PM CET, Dragan Simic wrote:
> Since the commit 72d3e093afae (um: random: Register random as hwrng-core
> device), selecting the UML_RANDOM option may result in various HW_RANDOM_*
> options becoming selected as well, which doesn't make much sense for UML
> that obviously cannot use any of those HWRNG devices.
>
> Let's have the HW_RANDOM_* options selected by default only when UML_RANDOM
> actually isn't already selected.  With that in place, selecting UML_RANDOM
> no longer "triggers" the selection of various HW_RANDOM_* options.
>
> Fixes: 72d3e093afae (um: random: Register random as hwrng-core device)
> Reported-by: Diederik de Haas <didi.debian@cknow.org>
> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> ---
>  drivers/char/hw_random/Kconfig | 76 +++++++++++++++++-----------------
>  1 file changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index e84c7f431840..283aba711af5 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -38,47 +38,47 @@ config HW_RANDOM_TIMERIOMEM
>  config HW_RANDOM_INTEL
>  	tristate "Intel HW Random Number Generator support"
>  	depends on (X86 || COMPILE_TEST) && PCI
> -	default HW_RANDOM
> +	default HW_RANDOM if !UML_RANDOM
>  	help
>  	  This driver provides kernel-side support for the Random Number
>  	  Generator hardware found on Intel i8xx-based motherboards.
>  
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called intel-rng.
>  
>  	  If unsure, say Y.
>  
>  config HW_RANDOM_AMD
>  	tristate "AMD HW Random Number Generator support"
>  	depends on (X86 || COMPILE_TEST)
>  	depends on PCI && HAS_IOPORT_MAP
> -	default HW_RANDOM
> +	default HW_RANDOM if !UML_RANDOM
>  	help
>  	  This driver provides kernel-side support for the Random Number
>  	  Generator hardware found on AMD 76x-based motherboards.
>  
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called amd-rng.
>  
>  	  If unsure, say Y.
>  
>  config HW_RANDOM_AIROHA
> ...
> @@ -603,7 +603,7 @@ config HW_RANDOM_ROCKCHIP
>  	tristate "Rockchip True Random Number Generator"
>  	depends on HW_RANDOM && (ARCH_ROCKCHIP || COMPILE_TEST)
>  	depends on HAS_IOMEM
> -	default HW_RANDOM
> +	default HW_RANDOM if !UML_RANDOM
>  	help
>  	  This driver provides kernel-side support for the True Random Number
>  	  Generator hardware found on some Rockchip SoC like RK3566 or RK3568.

Context:
I wanted to enable the HW_RANDOM_ROCKCHIP module in the Debian kernel
so I send a MR to enable it as module. One of the reviewers remarked
that this would *change* the module config from ``=y`` to ``=m`` as
``HW_RANDOM`` is configured ``=y`` due to Debian bug #1041007 [1].
IOW: if you don't say you want a HWRNG module, it will be built-in to
the Debian kernel, while Debian normally uses ``=m`` if possible.

So that's when I realized almost all modules have ``default HW_RANDOM``
and then found that UML_RANDOM selects HW_RANDOM which in turn would
enable (almost) all HWRNG modules unless you specify otherwise.
It's actually the depends which would mostly 'prevent' that.
This to me looks excessive, discussed the problem with Dragan which
resulted in this patch set.

But why not just remove (most of) the ``default HW_RANDOM`` lines
whereby a HWRNG module thus becomes opt-in instead of opt-out?

For ``HW_RANDOM_ROCKCHIP`` it's for the SoC found in *only* the rk3566
and rk3568 SoCs, but none of the others, and it's (currently) effective
only on rk3568 based devices (due to deliberate DT config).
In the help text of other modules I see mention of specific (series of)
motherboards, so also there it may not be useful for all.

I did a partial ``git blame`` to get an idea as to why those defaults
were there and found the following:

fed806f4072b ("[PATCH] allow hwrandom core to be a module")
from 2006-12-06 with the goal to have them modular

2d9cab5194c8 ("hwrng: Fix a few driver dependencies and defaults")
from 2014-04-08 which added several ... for consistency sake

e53ca8efcc5e ("hwrng: airoha - add support for Airoha EN7581 TRNG")
from 2024-10-17 with no explicit mention why it was done, so that was
most likely as that was used elsewhere (thus consistency)

So while this patch does prevent accidental enablement due to UML_RANDOM
enablement, it does seem to me to be needlessly complex and making it
opt-in, which was the assumption of my MR to begin with, much simpler.

I can be missing other considerations why the current solution would be
better, but I figured I'd mention my perspective.

Cheers,
  Diederik

[1] https://bugs.debian.org/1041007

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 3/3] hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

[Dragan Simic]

Hello Diederik,

On 2025-01-15 15:59, Diederik de Haas wrote:
> On Wed Jan 15, 2025 at 2:07 PM CET, Dragan Simic wrote:
>> Since the commit 72d3e093afae (um: random: Register random as 
>> hwrng-core
>> device), selecting the UML_RANDOM option may result in various 
>> HW_RANDOM_*
>> options becoming selected as well, which doesn't make much sense for 
>> UML
>> that obviously cannot use any of those HWRNG devices.
>> 
>> Let's have the HW_RANDOM_* options selected by default only when 
>> UML_RANDOM
>> actually isn't already selected.  With that in place, selecting 
>> UML_RANDOM
>> no longer "triggers" the selection of various HW_RANDOM_* options.
>> 
>> Fixes: 72d3e093afae (um: random: Register random as hwrng-core device)
>> Reported-by: Diederik de Haas <didi.debian@cknow.org>
>> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> ---
>>  drivers/char/hw_random/Kconfig | 76 
>> +++++++++++++++++-----------------
>>  1 file changed, 38 insertions(+), 38 deletions(-)
>> 
>> diff --git a/drivers/char/hw_random/Kconfig 
>> b/drivers/char/hw_random/Kconfig
>> index e84c7f431840..283aba711af5 100644
>> --- a/drivers/char/hw_random/Kconfig
>> +++ b/drivers/char/hw_random/Kconfig
>> @@ -38,47 +38,47 @@ config HW_RANDOM_TIMERIOMEM
>>  config HW_RANDOM_INTEL
>>  	tristate "Intel HW Random Number Generator support"
>>  	depends on (X86 || COMPILE_TEST) && PCI
>> -	default HW_RANDOM
>> +	default HW_RANDOM if !UML_RANDOM
>>  	help
>>  	  This driver provides kernel-side support for the Random Number
>>  	  Generator hardware found on Intel i8xx-based motherboards.
>> 
>>  	  To compile this driver as a module, choose M here: the
>>  	  module will be called intel-rng.
>> 
>>  	  If unsure, say Y.
>> 
>>  config HW_RANDOM_AMD
>>  	tristate "AMD HW Random Number Generator support"
>>  	depends on (X86 || COMPILE_TEST)
>>  	depends on PCI && HAS_IOPORT_MAP
>> -	default HW_RANDOM
>> +	default HW_RANDOM if !UML_RANDOM
>>  	help
>>  	  This driver provides kernel-side support for the Random Number
>>  	  Generator hardware found on AMD 76x-based motherboards.
>> 
>>  	  To compile this driver as a module, choose M here: the
>>  	  module will be called amd-rng.
>> 
>>  	  If unsure, say Y.
>> 
>>  config HW_RANDOM_AIROHA
>> ...
>> @@ -603,7 +603,7 @@ config HW_RANDOM_ROCKCHIP
>>  	tristate "Rockchip True Random Number Generator"
>>  	depends on HW_RANDOM && (ARCH_ROCKCHIP || COMPILE_TEST)
>>  	depends on HAS_IOMEM
>> -	default HW_RANDOM
>> +	default HW_RANDOM if !UML_RANDOM
>>  	help
>>  	  This driver provides kernel-side support for the True Random 
>> Number
>>  	  Generator hardware found on some Rockchip SoC like RK3566 or 
>> RK3568.
> 
> Context:
> I wanted to enable the HW_RANDOM_ROCKCHIP module in the Debian kernel
> so I send a MR to enable it as module. One of the reviewers remarked
> that this would *change* the module config from ``=y`` to ``=m`` as
> ``HW_RANDOM`` is configured ``=y`` due to Debian bug #1041007 [1].
> IOW: if you don't say you want a HWRNG module, it will be built-in to
> the Debian kernel, while Debian normally uses ``=m`` if possible.
> 
> So that's when I realized almost all modules have ``default HW_RANDOM``
> and then found that UML_RANDOM selects HW_RANDOM which in turn would
> enable (almost) all HWRNG modules unless you specify otherwise.
> It's actually the depends which would mostly 'prevent' that.
> This to me looks excessive, discussed the problem with Dragan which
> resulted in this patch set.

Thanks a lot for providing a detailed description of the series
of events that have led to this patch!

> But why not just remove (most of) the ``default HW_RANDOM`` lines
> whereby a HWRNG module thus becomes opt-in instead of opt-out?
> 
> For ``HW_RANDOM_ROCKCHIP`` it's for the SoC found in *only* the rk3566
> and rk3568 SoCs, but none of the others, and it's (currently) effective
> only on rk3568 based devices (due to deliberate DT config).
> In the help text of other modules I see mention of specific (series of)
> motherboards, so also there it may not be useful for all.

Removing the defaults from the Kconfig would be a much better
solution, but I'm afraid it would actually be quite disruptive,
requiring changes to various kernel configurations.

> I did a partial ``git blame`` to get an idea as to why those defaults
> were there and found the following:
> 
> fed806f4072b ("[PATCH] allow hwrandom core to be a module")
> from 2006-12-06 with the goal to have them modular
> 
> 2d9cab5194c8 ("hwrng: Fix a few driver dependencies and defaults")
> from 2014-04-08 which added several ... for consistency sake
> 
> e53ca8efcc5e ("hwrng: airoha - add support for Airoha EN7581 TRNG")
> from 2024-10-17 with no explicit mention why it was done, so that was
> most likely as that was used elsewhere (thus consistency)
> 
> So while this patch does prevent accidental enablement due to 
> UML_RANDOM
> enablement, it does seem to me to be needlessly complex and making it
> opt-in, which was the assumption of my MR to begin with, much simpler.
> 
> I can be missing other considerations why the current solution would be
> better, but I figured I'd mention my perspective.

The only upside of the current solution is that it represents
the least disruptive approach.

I'd suggest that this patch is kept as-is, and I'd add another
patch on top of it, which would remove the defaults from the
Kconfig and update the relevant default configs, of course if
the maintainers are fine with such an approach, and if there
is general agreement toward getting rid of the defaults.

Having two patches, as proposed above, would make the bisecting
later much easier, in case some unforeseen issues are discovered
in the future.

> [1] https://bugs.debian.org/1041007

Re: [PATCH 3/3] hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

[Herbert Xu]

On Wed, Jan 15, 2025 at 02:07:02PM +0100, Dragan Simic wrote:
> Since the commit 72d3e093afae (um: random: Register random as hwrng-core
> device), selecting the UML_RANDOM option may result in various HW_RANDOM_*
> options becoming selected as well, which doesn't make much sense for UML
> that obviously cannot use any of those HWRNG devices.
> 
> Let's have the HW_RANDOM_* options selected by default only when UML_RANDOM
> actually isn't already selected.  With that in place, selecting UML_RANDOM
> no longer "triggers" the selection of various HW_RANDOM_* options.
> 
> Fixes: 72d3e093afae (um: random: Register random as hwrng-core device)
> Reported-by: Diederik de Haas <didi.debian@cknow.org>
> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> ---
>  drivers/char/hw_random/Kconfig | 76 +++++++++++++++++-----------------
>  1 file changed, 38 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index e84c7f431840..283aba711af5 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -38,47 +38,47 @@ config HW_RANDOM_TIMERIOMEM
>  config HW_RANDOM_INTEL
>  	tristate "Intel HW Random Number Generator support"
>  	depends on (X86 || COMPILE_TEST) && PCI
> -	default HW_RANDOM
> +	default HW_RANDOM if !UML_RANDOM

This is disgusting.  Just remove all the defaults, and we can
add back the ones actually needed.  Just remember to set the
default to something sane like HW_RANDOM && dependencies.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 3/3] hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

[Dragan Simic]

Hello Herbert,

On 2025-02-09 10:15, Herbert Xu wrote:
> On Wed, Jan 15, 2025 at 02:07:02PM +0100, Dragan Simic wrote:
>> Since the commit 72d3e093afae (um: random: Register random as 
>> hwrng-core
>> device), selecting the UML_RANDOM option may result in various 
>> HW_RANDOM_*
>> options becoming selected as well, which doesn't make much sense for 
>> UML
>> that obviously cannot use any of those HWRNG devices.
>> 
>> Let's have the HW_RANDOM_* options selected by default only when 
>> UML_RANDOM
>> actually isn't already selected.  With that in place, selecting 
>> UML_RANDOM
>> no longer "triggers" the selection of various HW_RANDOM_* options.
>> 
>> Fixes: 72d3e093afae (um: random: Register random as hwrng-core device)
>> Reported-by: Diederik de Haas <didi.debian@cknow.org>
>> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> ---
>>  drivers/char/hw_random/Kconfig | 76 
>> +++++++++++++++++-----------------
>>  1 file changed, 38 insertions(+), 38 deletions(-)
>> 
>> diff --git a/drivers/char/hw_random/Kconfig 
>> b/drivers/char/hw_random/Kconfig
>> index e84c7f431840..283aba711af5 100644
>> --- a/drivers/char/hw_random/Kconfig
>> +++ b/drivers/char/hw_random/Kconfig
>> @@ -38,47 +38,47 @@ config HW_RANDOM_TIMERIOMEM
>>  config HW_RANDOM_INTEL
>>  	tristate "Intel HW Random Number Generator support"
>>  	depends on (X86 || COMPILE_TEST) && PCI
>> -	default HW_RANDOM
>> +	default HW_RANDOM if !UML_RANDOM
> 
> This is disgusting.  Just remove all the defaults, and we can
> add back the ones actually needed.  Just remember to set the
> default to something sane like HW_RANDOM && dependencies.

Could you, please, clarify why we need(ed) the defaults at all?
Also, I'm a bit puzzled about what would be the defaults that are
actually needed?  Are you actually referring to what I proposed
in my earlier response? [1]  I'd appreciate a clarification.

As a note, I tried to kind of "fix" it in a least intrusive way,
but I'll gladly have it fixed properly in the v2.  To me, getting
rid of the defaults completely would be the proper way.

[1] 
https://lore.kernel.org/linux-crypto/78b97c27314bfa1c7f0f17a90e623821@manjaro.org/

Re: [PATCH 3/3] hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

[Herbert Xu]

On Sun, Feb 09, 2025 at 10:37:52AM +0100, Dragan Simic wrote:
>
> Could you, please, clarify why we need(ed) the defaults at all?
> Also, I'm a bit puzzled about what would be the defaults that are
> actually needed?  Are you actually referring to what I proposed
> in my earlier response? [1]  I'd appreciate a clarification.

In general there shouldn't be any default.  The only exception
would be perhaps for embedded boards where the RNG is always
present given the dependencies.  But in that case the default
should be conditional on the dependency (or perhaps the whole
config should become unconditional).

The current defaults are mostly there for historical reasons.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 3/3] hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger

[Dragan Simic]

On 2025-02-09 10:54, Herbert Xu wrote:
> On Sun, Feb 09, 2025 at 10:37:52AM +0100, Dragan Simic wrote:
>> 
>> Could you, please, clarify why we need(ed) the defaults at all?
>> Also, I'm a bit puzzled about what would be the defaults that are
>> actually needed?  Are you actually referring to what I proposed
>> in my earlier response? [1]  I'd appreciate a clarification.
> 
> In general there shouldn't be any default.  The only exception
> would be perhaps for embedded boards where the RNG is always
> present given the dependencies.  But in that case the default
> should be conditional on the dependency (or perhaps the whole
> config should become unconditional).
> 
> The current defaults are mostly there for historical reasons.

Thanks for the clarification.

I think it would be the best to get rid of the current defaults
in the drivers/char/hw_random/Kconfig file entirely, together with
updating as many of the affected arch/*/configs/*_defconfig files
as possible to select the relevant HW_RANDOM_* config option(s)
whenever that's a sane thing to do.

Such an approach should be both proper and least disruptive.

Re: [PATCH 0/3] No longer default to HW_RANDOM when UML_RANDOM is the trigger

[Herbert Xu]

On Wed, Jan 15, 2025 at 02:06:59PM +0100, Dragan Simic wrote:
> This is a small patch series that makes the already existing HW_RANDOM_*
> options in the hw_random Kconfig selected by default only when the
> UML_RANDOM option isn't already selected.  Having the HW_RANDOM_* options
> selected doesn't make much sense for user-mode Linux (UML), which obviously
> cannot make use of any HWRNG devices.
> 
> Along the way, some additional trivial cleanups of the hw_random Kconfig
> file are also performed as spotted, in separate patches.
> 
> Dragan Simic (3):
>   hwrng: Use tabs as leading whitespace consistently in Kconfig
>   hwrng: Move one "tristate" Kconfig description to the usual place
>   hwrng: Don't default to HW_RANDOM when UML_RANDOM is the trigger
> 
>  drivers/char/hw_random/Kconfig | 84 +++++++++++++++++-----------------
>  1 file changed, 42 insertions(+), 42 deletions(-)

Patches 1-2 applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt