--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 22, 2007 at 05:53:53PM +0100, Matthias Drochner wrote:
>=20
> jmcneill@invisible.ca said:
> > Any suggestions? "dev/isa/acpidevs" seemed a bit out of place...=20
>=20
> Well, "acpi-isadevs" perhaps...
>=20
> 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.
>=20
> The problem is of course how to do this without making a mess
> of the autoconf system.
>=20
> 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.

--=20
Quentin Garnier - cube@cubidou.net - 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.

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iQEVAwUBR0YJ2tgoQloHrPnoAQJRTgf/bvEaqBTyQcfD+IPz+rJvUTr1XxnIaE0T
BG7xZCeyr/sE95yev27yabrXYoCKvSLh/+GVe9r5HvKvdm3/MtUmdivT31dQum9b
hM5ozIlQ+s1d0Zl8lqGpCx9Yp0X8R4QWBvdOuZu8nkQFcrYNY5tUybeSkdFmyueH
2GuY8KCbr8KkDIuyJ28u7MEVnbfqgZvd75PPk9DTqKQKxIKaRhm4NkYkJaxK8UKc
MGiurB20eQCrZkCeBq+1pRJIdvj/wO11cUBLUSywGz6pfnXzVdQ0OmZONJsmQ2LK
Hnk+s3lwIVyhFAjF9YUvWHrOHOH9v2qCXQSQ5tF8NHo4GEfIrYLnuQ==
=Ai4V
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--