On Tue, 3 Mar 2026, BALATON Zoltan wrote:
On Tue, 3 Mar 2026, Bernhard Beschow wrote:
Rather than requiring users of TYPE_SERIAL to initialize the MMIO region
themselves, make it generic enough to be configured via properties. This
makes TYPE_SERIAL more self-contained and prepares it for being turned
into a SysBusDevice.
Signed-off-by: Bernhard Beschow <[email protected]>
---
include/hw/char/serial-mm.h | 3 --
include/hw/char/serial.h | 4 +-
hw/char/diva-gsp.c | 5 ---
hw/char/serial-isa.c | 1 -
hw/char/serial-mm.c | 51 -------------------------
hw/char/serial-pci-multi.c | 5 ---
hw/char/serial-pci.c | 1 -
hw/char/serial.c | 76 ++++++++++++++++++++++++++++++-------
8 files changed, 66 insertions(+), 80 deletions(-)
diff --git a/include/hw/char/serial-mm.h b/include/hw/char/serial-mm.h
index 0076bdc061..4c18e2a609 100644
--- a/include/hw/char/serial-mm.h
+++ b/include/hw/char/serial-mm.h
@@ -39,9 +39,6 @@ struct SerialMM {
SysBusDevice parent;
SerialState serial;
-
- uint8_t regshift;
- uint8_t endianness;
};
This effectively makes TYPE_SERIAL the same as TYPE_SERIAL_MM so you could
just merge the two and have everything embed a SERIAL_MM device. But the idea
here is to make TYPE_SERIAL a superclass of all serial devices and SERIAL_MM
is the memory mapped version. Memory mapped devices are usually SysBusDevices
but others are not so this seems to be trying to model things in the wrong
way. Maybe you could just add accessor functions to TYPE_SERIAL to get the
memory regions and use that from subclasses to avoid poking in the state
struct and not try to reuse SysBusDevice for this.
Or instead of TYPE_SERIAL exporting memory regions it could export ops or
functions for it (like PCI IDE or PCI does) and let subclasses implement
the regions that call these exported functions with the register layout
they need?
Regards,
BALATON Zoltan
