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

[John Baldwin]

On Thursday 11 September 2008 10:14:46 am Bruce M Simpson wrote:
> Jeremy Chadwick wrote:
> > ...
> > Might mention this to jhb@ to see if it's related to the SMBus changes
> > made 1.5 years ago:
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c
> >   
> 
> Thanks for the pointers. The other reports sound like duplicate reports 
> of the same issue.
> 
> I'm not sure that backing out the last change is going to help. The BIOS 
> has generally set up the I/O resource before FreeBSD boots; the 
> bus_set_resource() call might only be useful in those cases where that 
> hasn't happened.
> In any event, in alpm_attach(), the rman is going to notice that the bus 
> space is already allocated by acpi(4), and will balk.
> 
> I'm sure there has been some kind of override mechanism in place for 
> certain other drivers; but they seem to boil down to using an ACPI 
> attachment of some kind, which won't work here as alpm(4) is a PCI 
> function and needs to attach to the pcib parent.
> 
> It would be really, really useful to have working SMBus drivers right 
> now on a machine I can actually touch...

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.  That's what this chunk of 
code in acpi_alloc_resource() does:

    /*
     * If this is an allocation of a specific range, see if we can satisfy
     * the request from our system resource regions.  If we can't, pass the
     * request up to the parent.
     */
    if (start + count - 1 == end && rm != NULL)
        res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE,
            child);

I'm not sure why you are having issues with SMBus.  I know I've been able to 
use IPMI over SSIF (IPMI over SMBus) using ichsmb0 on some Intel boxes that 
were new about 2 years ago.

-- 
John Baldwin