Re: [PATCH v1 14/16] drivers/vuart: move simple MMIO-based UART emulator

[dmkhn@proton.me]

On Wed, Jun 25, 2025 at 07:25:29AM +0200, Jan Beulich wrote:
> On 25.06.2025 00:54, dmkhn@proton.me wrote:
> > On Tue, Jun 24, 2025 at 09:40:02AM +0200, Jan Beulich wrote:
> >> On 24.06.2025 09:36, dmkhn@proton.me wrote:
> >>> On Tue, Jun 24, 2025 at 07:53:04AM +0200, Jan Beulich wrote:
> >>>> On 24.06.2025 05:57, dmkhn@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).

I can submit a separate patch to address the naming, if there are no
objections.

> 
> Jan
>