Message ID | 3d3f93bd1f8b9629e48b9ad96099e33069a455c1.1736946020.git.dsimic@manjaro.org (mailing list archive) |
---|---|
State | Changes Requested |
Delegated to: | Herbert Xu |
Headers | show |
Series | No longer default to HW_RANDOM when UML_RANDOM is the trigger | expand |
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
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
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,
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/
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,
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.
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.
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(-)