On 7 October 2014 22:15, Simon Glass sjg@chromium.org wrote:
On 6 October 2014 23:51, Masahiro Yamada yamada.m@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 yamada.m@jp.panasonic.com
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-dm/next, thanks!