Subject: Re: ISA direct config of ACPI devices
To: Quentin Garnier <>
From: Matthias Drochner <>
List: tech-kern
Date: 11/23/2007 19:52:23 said:
> that's where it is in the ACPI tree.  I only follow what is there.

Thanks -- that similarity to windows was too much to
be incidental...
This really looks like the way to go. One can use the ACPI information
where useful, but where the hardware knows better one can override
ACPI easily.

> at this
> point I have a separate API to allocate a device_t and attaching a
> driver, which means I can set the property before autoconf looks for
> drivers

Would it help to make subr_autoconf.c:config_devalloc() public?
(I also had some ideas into that direction, to increase the
chance that removed and reattached devices get the same unit
number, but I've kept it for me so far to give Jachym a chance
to finish his SOC project.)

> it goes do through acpippb

This looks a but ugly for me. Is it logically that different
from a standard ppb?

> and eventually an acpipcib

Since this can use all the ACPI ressource types it is logically
different indeed, so it makes sense to have it seperate from pcib+isa.
It doesn't make much sense for some devices (RTC, interrupt
controller etc) to appear here because they are much closer
to the processor logically. But we can always ignore that...

> it assumes the ACPI tree the vendor provides makes some kind of
> sense

It is, as the RTC example (and also serial ports built into the
chipset) shows some kind of high-level model of the PC. But
if the ACPI information is evaluated in parallel to the real
hardware, we should have a good chance to catch inconsistencies.

best regards

Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt