alpm(4) I/O range is claimed by ACPI

[John Baldwin]

On Friday 12 September 2008 10:13:27 pm Bruce M Simpson wrote:
> John Baldwin wrote:
> > Umm, ACPI will allow children devices to allocate their resources out of
> > the "sysresource" pool.  IPMI has to do this on some systems where ACPI
> > claims the IPMI I/O ports as a system resource.
>
> But surely if alpm(4) were to attach to such a range in this way, it
> would need to be a child of the acpi bus device, yes?

No, the code in acpi_alloc_resources() does _not_ check for that.  Any child 
device with a specific allocation that falls in a system resource range will 
succeed the allocation.

> The IPMI driver 
> probes for a specific ACPI ID in the DSDT.

The IPMI driver also attaches on the isa0 device via the SMBIOS tables, and 
that is the case where the resources clash with ACPI's system resources.  
IPMI devices listed in the ACPI namespace don't have their resources listed 
in ACPI's system resources.

> PCI ID looks like this:
> alpm0 at pci0:0:30:1:      class=0x068000 card=0x81561043 chip=0x710110b9
> rev=0x00 hdr=0x00
>
> So I grabbed the M1543 datasheet off the web and looked in CSR space.
> Guess what: the AMI BIOS on the ASUS Vintage AH-1 does NOT set up the
> PMU. The function is still visible, it just has no active I/O mappings.
> No wonder alpm(4) does not attach.
>
> I tried looking for this device in the DSDT, I don't see anything which
> obviously resembles it. The equivalent Linux driver has a means of
> forcing the mapping to be set up if it isn't available:
>     http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3
>
> It looks like there used to be a means of doing this in the FreeBSD
> driver but it got nuked. And that ASUS didn't much care about power
> management support in this machine...

If you can re-enable it in such a way that it uses bus_alloc_resource(), then 
the driver will probably work fine.

> Oh well! I know ichsmb works on at least one machine that I have.
>
> cheers
> BMS

-- 
John Baldwin