RFC - platform device, IRQs and SoC devices

[Ian Molton <spyro@f2s.com>]

Hi there.

Im working on some SoC type devices attached to the system bus of my ARM 
devboard in an isa-like way.

The devices are small SoC (System On Chip) types, with one IRQ routed to 
the half dozen (sub)devices on board the SoC.

At present, I am using a platform driver for the 'core' which handles 
IRQ routing and device enumeration, and is currently passing the IRQ to 
be used by the subdevices in a struct resource (along with two or three 
IOMEM resources).

this, however means that the subdevice resource definitions must be 
copied in order that the IRQ field can be set dynamically.

One solution would be for there to be a method by which the subdevice 
can query the SoC core device for the base of its IRQ range, which would 
allow the subdevice data to be declared as a constant and not copied. 
This makes the declaration of the subdevices in the main driver very 
neat and compact.

can this be done with a 'platform device' or is this simply not possible?

the real problem seems (to me) to be that struct resource is held as an 
array. If it were a linked list, then I could hold all but the subdevice 
IRQ in const data and simply 'tack on' a single dynamically created IRQ 
resource to it.

I propose that a 'next' field be added to the struct resource. All 
existing code could remain the same for now, and continue to work, 
whilst newer device drivers could use the next-> field to taverse the 
list rather than treat it as an array.

if all 'linked' entries come before 'array style' ones, then the 
num_resources field would change to mean 'num_array_style_resources' and 
the last 'linked' type resource would point to the head of the array. 
The traversal routines would simply count the array offset from the 
first 'array style' entry (with a NULL next field) or, if num_resources 
is not set, assume all resources are linked, and the NULL ends the list 
of resources.

This would allow for both statically allocated const arrays of struct 
resource as we use now, and dynamically allocated resources, or a mix of 
both for the few weird cases like my problem above.

Summary:

add struct resource *next; to struct resource.
rename num_resources as resource_array_len to indicate it only counts 
the number of resources listed in an array
allow resources to be added dynamically by altering the pointer to the 
firts resource and using that resources next pointer to point to the old 
list head (OR) the old array head.

possible enhancements:

get_first_resource() - return first resource added, making it easy to 
locate the first array type entry (if present)
remove_resource() - obvious, but perhaps not very useful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/