Make it clear that the maximum access size to the MMIO data register determines the full size of the memory region.
Currently the max access size is 1. Ensure that if a larger size were used in "fw_cfg_data_mem_ops.valid.max_access_size", the memory subsystem would split the access to byte-sized accesses internally, in increasing address order. fw_cfg_data_mem_read() and fw_cfg_data_mem_write() don't care about "address" or "size"; they just call the sequential fw_cfg_read() and fw_cfg_write() functions, correspondingly. Therefore the automatic splitting is just right. (The endianness of "fw_cfg_data_mem_ops" is native.) This patch doesn't change behavior. Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- Notes: v3: - new in v3 [Drew Jones] hw/nvram/fw_cfg.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c index a7122ee..23ea0fe 100644 --- a/hw/nvram/fw_cfg.c +++ b/hw/nvram/fw_cfg.c @@ -30,9 +30,8 @@ #include "qemu/error-report.h" #include "qemu/config-file.h" #define FW_CFG_SIZE 2 -#define FW_CFG_DATA_SIZE 1 #define TYPE_FW_CFG "fw_cfg" #define FW_CFG_NAME "fw_cfg" #define FW_CFG_PATH "/machine/" FW_CFG_NAME #define FW_CFG(obj) OBJECT_CHECK(FWCfgState, (obj), TYPE_FW_CFG) @@ -323,8 +322,9 @@ static const MemoryRegionOps fw_cfg_data_mem_ops = { .valid = { .min_access_size = 1, .max_access_size = 1, }, + .impl.max_access_size = 1, }; static const MemoryRegionOps fw_cfg_comb_mem_ops = { .read = fw_cfg_comb_read, @@ -608,9 +608,10 @@ static void fw_cfg_initfn(Object *obj) memory_region_init_io(&s->ctl_iomem, OBJECT(s), &fw_cfg_ctl_mem_ops, s, "fwcfg.ctl", FW_CFG_SIZE); sysbus_init_mmio(sbd, &s->ctl_iomem); memory_region_init_io(&s->data_iomem, OBJECT(s), &fw_cfg_data_mem_ops, s, - "fwcfg.data", FW_CFG_DATA_SIZE); + "fwcfg.data", + fw_cfg_data_mem_ops.valid.max_access_size); sysbus_init_mmio(sbd, &s->data_iomem); /* In case ctl and data overlap: */ memory_region_init_io(&s->comb_iomem, OBJECT(s), &fw_cfg_comb_mem_ops, s, "fwcfg", FW_CFG_SIZE); -- 1.8.3.1