Patch: Defer bus_config_intr() until bus_alloc_resource()..

[Nate Lawson]

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