[Ksummit-2012-discuss] [ATTEND] Complex dependencies in device model
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
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