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

[Igor Mammedov]

On Tue, 31 Mar 2020 17:23:42 +0200
Gerd Hoffmann <address@hidden> wrote:

> > > -static Aml *build_com_device_aml(uint8_t uid)
> > > +static void build_com_device_aml(Aml *scope, uint8_t uid)
> > >  {
> > >      Aml *dev;
> > >      Aml *crs;
> > > -    Aml *method;
> > > -    Aml *if_ctx;
> > > -    Aml *else_ctx;
> > > -    Aml *zero = aml_int(0);
> > > -    Aml *is_present = aml_local(0);
> > > -    const char *enabled_field = "CAEN";
> > >      uint8_t irq = 4;
> > >      uint16_t io_port = 0x03F8;
> > >  
> > >      assert(uid == 1 || uid == 2);
> > >      if (uid == 2) {
> > > -        enabled_field = "CBEN";
> > >          irq = 3;
> > >          io_port = 0x02F8;
> > >      }
> > > +    if (!memory_region_present(get_system_io(), io_port)) {  
> >                                   ^^^^^^
> > even though acpi_setup() is a part of board code, usually it's not 
> > recommended to 
> > use get_system_foo() outside of machine_init()
> > 
> > how about fishing out present serial ports from isa device in a helper
> > like acpi_get_misc_info(), and then generalize AML like
> >    build_com_device_aml(Aml *scope, uint8_t uid, io_port, irq)  
> 
> 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

> ... 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.
(while linux might still boot with resource conflicts, Windows 
BSODs occasionally instead). Maybe there are other complications
I don't recall.

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. (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)

> cheers,
>   Gerd
>