On 7 October 2014 22:15, Simon Glass <s...@chromium.org> wrote:
> On 6 October 2014 23:51, Masahiro Yamada <yamad...@jp.panasonic.com> wrote:
>> The driver model supports two ways for passing device parameters;
>> Device Tree and platform_data (board file).
>> Each driver should generally support both of them because some
>> popular IPs are used on various platforms.
>>
>> Assume the following scenario:
>> - The driver Foo is used on SoC Bar and SoC Baz
>> - The SoC Bar uses Device Tree control (CONFIG_OF_CONTROL=y)
>> - The SoC Baz does not support Device Tree; uses a board file
>>
>> In this situation, the device driver Foo should work with/without
>> the device tree control. The driver should have .of_match and
>> .ofdata_to_platdata members for SoC Bar, while they are meaningless
>> for SoC Baz; therefore those device-tree control code should go
>> inside #ifdef CONFIG_OF_CONTROL.
>>
>> The driver code will be like this:
>>
>> #ifdef CONFIG_OF_CONTROL
>> static const struct udevice_id foo_of_match = {
>> { .compatible = "foo_driver" },
>> {},
>> }
>>
>> static int foo_ofdata_to_platdata(struct udevice *dev)
>> {
>> ...
>> }
>> #endif
>>
>> U_BOOT_DRIVER(foo_driver) = {
>> ...
>> .of_match = of_match_ptr(foo_of_match),
>> .ofdata_to_platdata = of_match_ptr(foo_ofdata_to_platdata),
>> ...
>> }
>>
>> This idea has been borrowed from Linux.
>> (In Linux, this macro is defined in include/linux/of.h)
>>
>> Signed-off-by: Masahiro Yamada <yamad...@jp.panasonic.com>
>
> Acked-by: Simon Glass <s...@chromium.org>
Applied to u-boot-dm/next, thanks!
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
