Re: [PATCH 5/6] acpi: serial: don't use _STA method

[Gerd Hoffmann]

  Hi,

> > Hmm, I'm wondering whenever it would be useful to have ...
> > 
> >    ISADeviceClass->build_aml(Aml *scope, ISADevice *dev);
> 
> in relation to iqr, you said earlier that device doesn't know to which irq 
> it's mapped.
> that might be a problem in this case, likewise for (MM)IO

Right, this is a problem for sysbus, isa seems to not have this problem
though.

> > ... then just walk all isa devices and call the handler
> > (if present).  Maybe the same for sysbus.
> 
> There was already such idea (Paolo or Michael), i.e. to move AML code
> generation related to specific devices inside of device model (not
> only ISA or sysbus), so one would just have to enumerate present
> devices in generic way and ask them to provide AML descriptors and be
> done with building DSDT.
> 
> Not sure if it's doable in generic way though, especially when it comes to
> orchestrating _CRS between various devices.

I suspect fully generic is tricky, also because you have to get the
hierarchy right.  For isa I think it is doable without too much trouble
because all isa devices are within the same scope.

sysbus is more tricky I suspect.

> So it might take awhile to come up with approach which would work nice.
> 
> Simplest way to get job done in case of microvm is to make board
> fill in assigned resources in some helper data structure and pass that
> to acpi code.

Well, I'd try to avoid the helper data structure indirection ...

> (another approach - arm/virt uses static 'registry' to distribute
> address space/irq and then acpi code just fetches values from there if
> device is present + a bunch of shared PCI code to make up dynamic PCI
> description)

I suspect the reason for the registry on arm is that you can generate
both acpi and device tree from it.  But maybe that makes sense for
sysbus devices (fw_cfg + virtio-mmio for microvm).

cheers,
  Gerd