Re: [Qemu-devel] [PATCH 3/3] sun4u: expose NVRAM on ebus PCI IO address space

[Mark Cave-Ayland]

On 10/06/17 19:05, Philippe Mathieu-Daudé wrote:

> Hi Mark,
> 
> I'm not sure having this patch split from the previous (2/3) really
> helps bisecting, I'd rather squash them altogether.
> 
> Either way:
> 
> Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
> 
> On 06/10/2017 10:00 AM, Mark Cave-Ayland wrote:
>> To allow future changes to the sun4u PCI topology.
>>
>> Signed-off-by: Mark Cave-Ayland <address@hidden>
>> ---
>>  hw/sparc64/sun4u.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
>> index 19e64be..bf738f8 100644
>> --- a/hw/sparc64/sun4u.c
>> +++ b/hw/sparc64/sun4u.c
>> @@ -492,7 +492,7 @@ static void sun4uv_init(MemoryRegion
>> *address_space_mem,
>>      /* Map NVRAM into I/O (ebus) space */
>>      nvram = m48t59_init(NULL, 0, 0, NVRAM_SIZE, 1968, 59);
>>      s = SYS_BUS_DEVICE(nvram);
>> -    memory_region_add_subregion(get_system_io(), 0x2000,
>> +    memory_region_add_subregion(pci_address_space_io(ebus), 0x2000,
>>                                  sysbus_mmio_get_region(s, 0));
>>
>>      initrd_size = 0;
>>

Yes I could probably do that (unless Artyom objects). I agree there
isn't that much in to the patch, and until the PCI topology changes it's
effectively a no-op.


ATB,

Mark.