[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v1 14/16] drivers/vuart: move simple MMIO-based UART emulator
On Wed, Jun 25, 2025 at 07:25:29AM +0200, Jan Beulich wrote: > On 25.06.2025 00:54, dmkhn@xxxxxxxxx wrote: > > On Tue, Jun 24, 2025 at 09:40:02AM +0200, Jan Beulich wrote: > >> On 24.06.2025 09:36, dmkhn@xxxxxxxxx wrote: > >>> On Tue, Jun 24, 2025 at 07:53:04AM +0200, Jan Beulich wrote: > >>>> On 24.06.2025 05:57, dmkhn@xxxxxxxxx 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 >
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |