On Tue, Jun 24, 2025 at 09:40:02AM +0200, Jan Beulich wrote: > On 24.06.2025 09:36, dm...@proton.me wrote: > > On Tue, Jun 24, 2025 at 07:53:04AM +0200, Jan Beulich wrote: > >> On 24.06.2025 05:57, dm...@proton.me wrote: > >>> --- a/xen/drivers/vuart/Kconfig > >>> +++ b/xen/drivers/vuart/Kconfig > >>> @@ -3,6 +3,15 @@ config HAS_VUART > >>> > >>> if (ARM_32 || ARM_64) > >>> > >>> +config HAS_VUART_MMIO > >>> + bool "Simple MMIO-based emulated UART support" > >> > >> Perhaps in a separate change this should be renamed. HAS_* should never > >> have prompts. > > > > Oh, so HAS_ flags are non-interactive selectors by design? > > Well "has" simply by the word means "this is available". Any user-selectable > item > deriving from the mere availability would then have a "depends on HAS_...", > thus > hiding the option in situation where the functionality isn't available (be it > per > arch or for other reasons).
I see there's a lot of drivers (UARTs) which are selectable by the user via
HAS_ symbols (drivers/char/Kconfig), e.g:
CONFIG_HAS_NS16550:
│
│
│
│ This selects the 16550-series UART support. For most systems, say Y.
│
│
│
│ Symbol: HAS_NS16550 [=y]
│
│ Type : bool
│
│ Prompt: NS16550 UART driver
│
│ Location:
│
│ -> Device Drivers
│
│ Defined at drivers/char/Kconfig:4
>
> Jan
