[Ksummit-2012-discuss] [ATTEND] Complex dependencies in device model

Stephen Warren swarren at wwwdotorg.org
Wed Jun 20 17:23:50 UTC 2012

On 06/20/2012 11:02 AM, Matthew Garrett wrote:
> On Wed, Jun 20, 2012 at 10:54:56AM -0600, Stephen Warren wrote:
>> With all the recent focus on ARM cleanup and reviews, I hope we can
>> catch this kind of thing, so such restrictions wouldn't be necessary.
>> Not merging the architecture support unless the drivers are merged first
>> somewhat creates a chicken/egg problem; should the drivers be merged
>> without any architecture to run on? I can easily see someone else
>> wanting that restriction...
> The issue is that FDT and ACPI are two mechanisms for providing the same 
> data.

Well, this only affects probe() right, not the body of the driver?

On ARM, most drivers were historically platform devices, so use APIs
such as platform_get_resource() to retrieve at least their basic
platform data (IO/memory ranges, IRQs). When DT support was added,
rather than recode all these drivers to parse this information out of
DT, the DT core creates a platform_device for each DT node, and
populates the same IO/memory range and IRQ data into the platform
resources, so that drivers can run unchanged. Presumably a similar
technique can be used for ACPI.

Now, more complex platform data is another story; in the true
platform_device case, it comes from the platform_data structure, whereas
drivers had to grow new code to parse this from DT - but this didn't
cause new duplicate drivers, just a little extra code to be added to
existing drivers in probe().

Perhaps we can make APIs such as of_property_get() work with either DT
or ACPI (or wholesale replace everything with equivalent functions with
less OF-/DT-specific names, but have basically the same semantics).
Creating a DT from ACPI would be somewhat equivalent here. Note: both
these ideas have been mentioned before by people far more in the thick
of this than me; I'm mainly just repeating it!

More information about the Ksummit-2012-discuss mailing list