On 25.06.2025 00:54, dm...@proton.me wrote: > 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:
Iirc it was prompt-less up to some point. And when the prompt was added, the name wasn't changed / split. Other UARTs then followed suit (when they shouldn't have). Jan
