Subject: Re: ISA direct config of ACPI devices
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: Quentin Garnier <email@example.com>
Date: 11/22/2007 23:59:38
Content-Type: text/plain; charset=us-ascii
On Thu, Nov 22, 2007 at 05:53:53PM +0100, Matthias Drochner wrote:
> firstname.lastname@example.org said:
> > Any suggestions? "dev/isa/acpidevs" seemed a bit out of place...=20
> Well, "acpi-isadevs" perhaps...
> After sleeping over this, I'd say it would be better to do it
> differently. While attaching acpi devices at isa solves the
> immediate problem with reserved unit numbers, it is a step
> into the wrong direction. In the long term, we should be able
> to run a system without an ISA bus configured at all. That's
> why I'd say we should keep these devices attaching at acpi,
> but somehow work around the reserved unit numbers.
> The problem is of course how to do this without making a mess
> of the autoconf system.
> I can imagine 3 approaches:
> a) "steal" the unit numbers from isa: If an acpi node is found,
> and NISA>0, call a special function within the isa code which
> tells if an FSTATE_NOTFOUND entry exists, makes it FOUND and
> returns the unit number for use by the acpi attachment.
> b) Defer potential isa devices:
> If an acpi node is found, use some heuristic (address range
> based, or a table of pnp IDs) which tells whether it could be
> an ISA device. In that case, put it onto a waiting list.
> After ISA configuration, come back to that list and attach
> the devices which were not handled by isa.
> c) Use some pseudo-bus (an interface attribute in terms of the
> autoconf system) which abstracts from the ISA semantics.
> (There is some "isabus" attribute already which could do it
> perhaps, but it would have to be checked.)
> Both the "isa" bus and "acpi" would carry that attribute,
> and the com etc devices would have that attribute as parent
> in the kernel config file.
> If an acpi node is found, first a config_found() with the
> isa-like attribute is tried, and if this doesn't attach
> anything the standard acpi call is done.
FWIW, I have a d) in the local tree of my laptop. It maps the ACPI tree
on our device tree with the result of attaching those devices to the
"acpipcib" device (because that's where they appear in the ACPI tree).
The main issue I see in Jared's approach is that there is no meaningful
way to carry ACPI information to the driver, if needed. Otherwise it
doesn't strike me as incorrect.
Quentin Garnier - email@example.com - cube@NetBSD.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)
-----END PGP SIGNATURE-----