On Sunday 28 August 2011 00:37:36 David Gibson wrote:

On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:

quoted

On Friday 26 August 2011, Arnd Bergmann wrote:

quoted

On Friday 26 August 2011, David Gibson wrote:

quoted

If you open code it this way then yes, it's silly.  But what about
something like this:

static struct of_device_id foodevice_of_match[] __devinitdata = {
        { .compatible = "foocorp,foodevice1234",
          .resource_names = {"base_regs", "extra_regs", }, },
        { .compatible = "foocorp,foodevice1239",
          .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
        { },
};

Hmm, I hadn't thought of that. This looks quite nice indeed. No objections
to this from my side.

Ah well, one objection on second thought:

This assumes that there is just one type of resource, but named resources
may be used for iomem, ioport and irq resources. If you have multiple
IRQs and multiple IOMEM resources, I don't see how the index in the 
resource_names array can be used for both of them.

Details, shmetails, so you have both 'reg_names' and 'interrupt_names'.

Right, and I guess we can simply ignore DMA and ioport resources because they
are extremely rare, right?

One more detail: IIRC struct of_device_id is exported to module_init_tools
for purposes of autoloading, so changing the structure breaks user space.

	Arnd