From: Denis Mukhin <dmukhin@ford.com>
Move simple MMIO-based UART emulator under drivers/vuart and rename it to
vuart-mmio.c to keep "vuart" for the vUART framework.
No functional change intended.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
xen/arch/arm/Kconfig | 8 --------
xen/arch/arm/Makefile | 1 -
xen/drivers/vuart/Kconfig | 9 +++++++++
xen/drivers/vuart/Makefile | 1 +
xen/{arch/arm/vuart.c => drivers/vuart/vuart-mmio.c} | 0
5 files changed, 10 insertions(+), 9 deletions(-)
rename xen/{arch/arm/vuart.c => drivers/vuart/vuart-mmio.c} (100%)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 6eeae97293f2..7b915abc6f18 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -170,14 +170,6 @@ config NEW_VGIC
problems with the standard emulation.
At the moment this implementation is not security supported.
-config HAS_VUART_MMIO
- bool "Emulated UART for hardware domain"
- default y
- help
- Allows a hardware domain to use a minimalistic UART (single transmit
- and status register) which takes information from dtuart. Note that this
- UART is not intended to be exposed (e.g. via device-tree) to a domain.
-
config ARM_SSBD
bool "Speculative Store Bypass Disable" if EXPERT
depends on HAS_ALTERNATIVE
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 8475043d8701..24bc9c88f7ac 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -67,7 +67,6 @@ obj-$(CONFIG_VM_EVENT) += vm_event.o
obj-y += vtimer.o
obj-y += vsmc.o
obj-y += vpsci.o
-obj-$(CONFIG_HAS_VUART_MMIO) += vuart.o
extra-y += xen.lds
diff --git a/xen/drivers/vuart/Kconfig b/xen/drivers/vuart/Kconfig
index d8df0f6d1b3c..6002817152df 100644
--- 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"
+ default y
+ select HAS_VUART
+ help
+ Enables minimalistic UART (single transmit and status register) which
+ takes information from dtuart. Note that this UART is not intended to
+ be exposed (e.g. via device-tree) to a domain.
+
config HAS_VUART_PL011
bool "Emulated PL011 UART support"
default y
diff --git a/xen/drivers/vuart/Makefile b/xen/drivers/vuart/Makefile
index 3b7069f1cf95..1c775ffb7f1d 100644
--- a/xen/drivers/vuart/Makefile
+++ b/xen/drivers/vuart/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_HAS_VUART_MMIO) += vuart-mmio.o
obj-$(CONFIG_HAS_VUART_PL011) += vuart-pl011.o
diff --git a/xen/arch/arm/vuart.c b/xen/drivers/vuart/vuart-mmio.c
similarity index 100%
rename from xen/arch/arm/vuart.c
rename to xen/drivers/vuart/vuart-mmio.c
--
2.34.1On 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. > + default y > + select HAS_VUART This is questionable too (for still being controlled by a prompt), but may need to remain as is. Jan
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? I did not find explanation in the docs :-/ Can you please explain? (and I will add a note to docs for that) > > > + default y > > + select HAS_VUART > > This is questionable too (for still being controlled by a prompt), but > may need to remain as is. > > Jan
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). Jan
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: │ │ │ │ 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
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). Jan
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 >
© 2016 - 2026 Red Hat, Inc.