On Saturday 29 March 2014 01:53:19 Grant Likely wrote:
I do understand the problem of what gets passed in then? acpi_device or device_node? Instead of trying to do that, I think it would be reasonable for the API to pass in the struct device pointer instead. The main user of this feature is going to be device drivers anyway, so by passing in the struct device, the API can choose whichever one is populated.
I agree. It might actually be useful to provide an extension to platform_device_register_full() to allow adding named properties to traditional platform devices, so the interface should at least be able to handle that if we get there. However, we also try to get away from traditional platform devices for most users, it would only be relevant for drivers that are shared with platforms or architectures that we don't plan to convert to DT anyway.
At the same time, I would really like to explore a decode descripter type of interface, where all of the desired properties are listed in a structure and the API takes care of error checking on each property. That would be a marked improvement on what we have to do right now for parsing data properties.
I had started working on something in November, see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/209031.h...
Al also wanted to take a closer look at whether he can get it to actually work, as I haven't done any work on it since the original post.
Arnd