Date: Wed, 2 Jun 2004 16:27:19 -0700 (PDT) From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. Message-ID: <20040602160338.T38138@root.org> In-Reply-To: <200406021358.17521.jhb@FreeBSD.org> References: <20040601141424.I29932@root.org> <20040601.163316.88476133.imp@bsdimp.com> <200406021358.17521.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Jun 2004, John Baldwin wrote:
> Ok, summary of PITAs after an hour or so of looking into it:
I appreciate your efforts. Just to recap, we're trying to work around an
API design problem with bus_config_intr().
> - For the PIC mode on i386, we use bus_config_intr() after bus_setup_intr() to
> set the interrupt to level/low. This can be worked around by deferring
> handler setup until after acpica_machdep_init() and calling
> AcpiEnableSubsystem() twice.
> - There is no way (currently) to get a pointer to the resource structure
> associated with rid X w/o calling bus_alloc_resource(). In fact, there is
> no resource structure in which to place the IRQ configuration flags until
> bus_alloc_resource(), thus for the bus_config_intr() that sets the mode for
> the SCI for PIC mode above there is no resource (once you defer the
> interrupt setup) and for all of the resources set via bus_set_resource() in
> acpi_parse_resources() there is no resource to set the flags in, so that
> info is lost unless we also hack on the resource list items to add flag
> members and change that API to allow for flags to be passed around.
How about adding bus_{get,set}_resource_flags(dev, int rid, int flags) and
adding an "int flags" field to struct resource_list_entry? Or break the
API now and add flags to the normal bus_{get,set}_resource(). This is
going to be needed for other resource types in the future that have modes.
> I really don't want to spend a lot of time implementing all this. Does
> somebody else want to do this? The change I posted earlier is a _lot_
> simpler and smaller.
Just because bus_config_intr doesn't have a counterpart for storing the
config doesn't mean the right thing to do is to force every user of it to
re-parse/fetch the settings they already set. I understand this is a pain
but the time to contain the damage is now rather than letting it spread
more.
-Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040602160338.T38138>