svn commit: r301451 - in head/sys: kern sys

[John Baldwin]

On Sunday, June 05, 2016 04:07:57 PM Svatopluk Kraus wrote:
> Author: skra
> Date: Sun Jun  5 16:07:57 2016
> New Revision: 301451
> URL: https://svnweb.freebsd.org/changeset/base/301451
> 
> Log:
>   (1) Add a new bus method to get a mapping data for an interrupt.
>   
>   BUS_MAP_INTR() is used to get an interrupt mapping data according
>   to provided hints. The hints could be modified afterwards, but only
>   if mapping data was allocated. This method is intended to be called
>   before BUS_ALLOC_RESOURCE().
>   
>   An interrupt mapping data describes an interrupt - hardware number,
>   type, configuration, cpu binding, and whatever is needed to setup it.
>   
>   (2) Introduce a method which allows storing of an additional data
>   in struct resource to be available for bus drivers. This method is
>   convenient in two ways:
>    - there is no need to rework existing bus drivers as they can simply
>      be extended to provide an additional data,
>    - there is no need to modify any existing bus methods as struct
>      resource is already passed to them as argument and thus stored data
>      is simply accessible by other bus drivers.
>   For now, implement this method only for INTRNG.
>   
>   This is motivated by needs of modern SOCs where hardware initialization
>   is not straightforward and resources descriptions are complex, opaque
>   for everyone but provider, and may vary from SOC to SOC. Typical
>   situation is that one bus driver can fetch a resource description for
>   its child device, but it's opaque for this driver. Another bus driver
>   knows a provider for this kind of resource and can pass this resource
>   description to it. In fact, something like device IVARS would be
>   perfect for that if implemented generally enough. Unfortunatelly, IVARS
>   are usable only by their owners now. Only owner knows its IVARS layout,
>   thus other bus drivers are not able to use them.
>   
>   Differential Revision:	https://reviews.freebsd.org/D6632

Does anything need to query this data besides the "nexus" or similar
driver at the top of bus_alloc_resource()?  If so, I'd much rather do
this by having an optional args structure passed to bus_alloc_resource
that is extensible ala make_dev_s() and bus_map_resource().  Previously
I had mentioned passing this as part of bus_setup_intr() rather than
bus_alloc_resource(), but it would actually work better for ACPI if
we did it for bus_alloc_resource() instead.

I guess my question is do you need access to this beyond the lifetime
of the call to bus_alloc_resource().  On x86 for example the state that
would needed to be passed up from ACPI (currently via bus_config_intr())
is stored in the interrupt source structure, so it doesn't need to be
attached to the resource directly, it just needs to be passed up with it
so it can be saved in the interrupt source structure.

-- 
John Baldwin