[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/dev/acpi
"David Young" <dyoung%pobox.com@localhost> wrote in message
On Tue, Apr 07, 2009 at 09:20:23PM -0400, Jared D. McNeill wrote:
From: "David Young" <dyoung%netbsd.org@localhost>
Sent: Tuesday, April 07, 2009 8:23 PM
Subject: CVS commit: src/sys/dev/acpi
Module Name: src
Committed By: dyoung
Date: Wed Apr 8 00:23:30 UTC 2009
src/sys/dev/acpi: acpi.c acpivar.h
Refactor slightly to create acpi_rescan(), a hook for rescanning the
devices that attach at acpi(4).
Begin deriving an acpi(4) device-detachment hook, acpi_detach(), from
acpi_attach(). The code between #if 0 and #endif still needs to be
turned to the opposite calls (enables to disables, maps to unmaps,
attaches to detaches), which should be run in the opposite order.
Somebody with deep ACPI knowledge can probably finish this off without
too much trouble.
Detaching ACPI is more complicated than this because it is actually used
for much more than just device attachment; think about IRQ routing, PCI
bus discovery, PCI bus/addr/intr fixups, and CPU attachment as some
examples. It's probably not worth the effort.
How about I divide the ACPI functions between two devices, one that
provides "more than just device attachment," and another that provides
just the device attachment?
Do you think that in the long term, devices that attach today at the
interface attribute "acpinodebus" will attach, instead, at "pci" or
I would hope so, and actually sent patches for this a few years back. I
think you're still going to run into issues though. Suppose you detach
acpi(4); who is responsible for (one of many examples) PCI IRQ routing. What
happens to your wm(4), whose interrupt has been configured with ACPI PCI
link devices, when the OS wants to switch back to Legacy Mode?
Main Index |
Thread Index |