有了设备树后，不再需要大量的板级信息，譬如过去经常在arch/arm/plat-xxx和arch/arm/mach-xxx中实施如下事情。
下面展示的都是改变了的，有个对比可以让你对设备树的影响更加的深刻。
参考资料：《Linux设备驱动开发详解》
1、注册platform_device，绑定resource，即内存、IRQ等板级信息
通过设备树后，形如：
static struct resource xxx_resources[] = { [0] = { .start = …, .end = …, .flags = IORESOURCE_MEM, }, [1] = { .start = …, .end = …, .flags = IORESOURCE_IRQ, }, }; static struct platform_device xxx_device = { .name = "xxx", .id = -1, .dev = { .platform_data = &xxx_data, }, .resource = xxx_resources, .num_resources = ARRAY_SIZE(xxx_resources), };
之类的platform_device代码都不再需要，其中**platform_device会由内核自动展开。**而这些resource实际来源于.dts 中设备节点的reg、interrupts属性。
典型的，大多数总线都与“simple_bus”兼容，而在与SoC对应的设备的.init_machine成员函数中，调用of_platform_bus_probe（NULL，xxx_of_bus_ids，NULL）；即可自动展开所有的platform_device。
2、注册i2c_board_info，指定IRQ等板级信息
形如：
static struct i2c_board_info __initdata afeb9260_i2c_devices[] = { { I2C_BOARD_INFO("tlv320aic23", 0x1a), }, { I2C_BOARD_INFO("fm3130", 0x68), }, { I2C_BOARD_INFO("24c64", 0x50), }, };
之类的i2c_board_info代码目前不再需要出现，现在只需要把tlv320aic23、fm3130、24c64这些设备节点填充作为相应的I2C控制器节点的子节点即可，类似于前面的代码：
i2c@1,0 { compatible = "acme,a1234-i2c-bus"; … rtc@58 { compatible = "maxim,ds1338"; reg = <58>; interrupts = < 7 3 >; }; };
设备树中的I2C客户端会通过在I2C host驱动的probe（）函数中调用的of_i2c_register_devices（&i2c_dev->adapter）；被自动展开。
3、注册spi_board_info，指定IRQ等板级信息
static struct spi_board_info afeb9260_spi_devices[] = { { /* DataFlash chip */ .modalias = "mtd_dataflash", .chip_select = 1, .max_speed_hz = 15 * 1000 * 1000, .bus_num = 0, }, };
之类的spi_board_info代码目前不再需要出现，与I2C类似，现在只需要把mtd_dataflash之类的节点作为SPI控制器的子节点即可，SPI host驱动的probe（）函数通过spi_register_master（）注册主机的时候，会自动展开依附于它的从机，spear1310-evb.dts中的st，m25p80SPI接口的NOR Flash节点如下：
之类的spi_board_info代码目前不再需要出现，与I2C类似，现在只需要把mtd_dataflash之类的节点作为SPI控制器的子节点即可，SPI host驱动的probe（）函数通过spi_register_master（）注册主机的时候，会自动展开依附于它的从机，spear1310-evb.dts中的st，m25p80SPI接口的NOR Flash节点如下：
4、多个针对不同电路板的设备，以及相关的回调函数
在过去，ARM Linux针对不同的电路板会建立由MACHINE_START和MACHINE_END包围的设备，引入设备树之后，MACHINE_START变更为DT_MACHINE_START，其中含有一个.dt_compat成员，用于表明相关的设备与.dts中根节点的兼容属性的兼容关系。
这样可以显著改善代码的结构并减少冗余的代码，在不支持设备树的情况下，光是一个S3C24xx就存在多个板文件，譬如mach-amlm5900.c、mach-gta02.c、mach-smdk2410.c、mach-qt2410.c、mach-rx3715.c等，其累计的代码量是相当大的，板级信息都用C语言来实现。
而采用设备树后，我们可以对多个SoC和板子使用同一个DT_MACHINE和板文件，板子和板子之间的差异更多只是通过不同的.dts文件来体现。
5、设备与驱动的匹配方式
使用设备树后，驱动需要与在.dts中描述的设备节点进行匹配，从而使驱动的probe（）函数执行。新的驱动、设备的匹配变成了设备树节点的兼容属性和设备驱动中的OF匹配表的匹配。（下篇看看OF是什么？）
6、设备的平台数据属性化
在Linux 2.6下，驱动习惯自定义platform_data，在arch/arm/mach-xxx注册platform_device、i2c_board_info、spi_board_info等的时候绑定platform_data，而后驱动通过标准API获取平台数据。
譬如，在arch/arm/mach-at91/board-sam9263ek.c下用如下代码注册gpio_keys设备，它通过gpio_keys_platform_data结构体来定义platform_data。
static struct gpio_keys_button ek_buttons[] = { { /* BP1, "leftclic" */ .code = BTN_LEFT, .gpio = AT91_PIN_PC5, .active_low = 1, .desc = "left_click", .wakeup = 1, }, { /* BP2, "rightclic" */ ... } }; static struct gpio_keys_platform_data ek_button_data = { .buttons = ek_buttons, .nbuttons = ARRAY_SIZE(ek_buttons), }; static struct platform_device ek_button_device = { .name = "gpio-keys", .id = -1, .num_resources = 0, .dev = { .platform_data= &ek_button_data, } };
设备驱动drivers/input/keyboard/gpio_keys.c则通过如下简单方法取得这个信息。
static int gpio_keys_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; const struct gpio_keys_platform_data *pdata = dev_get_platdata(dev); ... }
在转移到设备树后，platform_data便不再喜欢放在arch/arm/mach-xxx中了，它需要从设备树的属性中获取，比如一个电路板上有gpio_keys，则只需要在设备树中添加类似arch/arm/boot/dts/exynos4210-origen.dts中的如代码清单18.17所示的信息则可。
1 gpio_keys { 2 compatible = "gpio-keys"; 3 #address-cells = <1>; 4 #size-cells = <0>; 5 6 up { 7 label = "Up"; 8 gpios = <&gpx2 0 1>; 9 linux,code = <KEY_UP>; 10 gpio-key,wakeup; 11 }; 12 13 down { 14 label = "Down"; 15 gpios = <&gpx2 1 1>; 16 linux,code = <KEY_DOWN>; 17 gpio-key,wakeup; 18 }; 19 ... 20 };
而drivers/input/keyboard/gpio_keys.c则通过以of_开头的读属性的API来读取这些信息，并组织出gpio_keys_platform_data结构体，如代码清单18.18所示。
代码清单18.18 在GPIO按键驱动中获取.dts中的键描述
1 static struct gpio_keys_platform_data * 2 gpio_keys_get_devtree_pdata(struct device *dev) 3 { 4 struct device_node *node, *pp; 5 struct gpio_keys_platform_data *pdata; 6 struct gpio_keys_button *button; 7 int error; 8 int nbuttons; 9 int i; 10 11 node = dev->of_node; 12 if (!node) 13 return ERR_PTR(-ENODEV); 14 15 nbuttons = of_get_child_count(node); 16 if (nbuttons == 0) 17 return ERR_PTR(-ENODEV); 18 19 pdata = devm_kzalloc(dev, 20 sizeof(*pdata) + nbuttons * sizeof(*button), 21 GFP_KERNEL); 22 if (!pdata) 23 return ERR_PTR(-ENOMEM); 24 25 pdata->buttons = (struct gpio_keys_button *)(pdata + 1); 26 pdata->nbuttons = nbuttons; 27 28 pdata->rep = !!of_get_property(node, "autorepeat", NULL); 29 30 i = 0; 31 for_each_child_of_node(node, pp) { 32 int gpio; 33 enum of_gpio_flags flags; 34 35 if (!of_find_property(pp, "gpios", NULL)) { 36 pdata->nbuttons--; 37 dev_warn(dev, "Found button without gpios\n"); 38 continue; 39 } 40 41 gpio = of_get_gpio_flags(pp, 0, &flags); 42 if (gpio < 0) { 43 error = gpio; 44 if (error != -EPROBE_DEFER) 45 dev_err(dev, 46 "Failed to get gpio flags, error: %d\n", 47 error); 48 return ERR_PTR(error); 49 } 50 51 button = &pdata->buttons[i++]; 52 53 button->gpio = gpio; 54 button->active_low = flags & OF_GPIO_ACTIVE_LOW; 55 56 if (of_property_read_u32(pp, "linux,code", &button->code)) { 57 dev_err(dev, "Button without keycode: 0x%x\n", 58 button->gpio); 59 return ERR_PTR(-EINVAL); 60 } 61 62 button->desc = of_get_property(pp, "label", NULL); 63 64 if (of_property_read_u32(pp, "linux,input-type", &button->type)) 65 button->type = EV_KEY; 66 67 button->wakeup = !!of_get_property(pp, "gpio-key,wakeup", NULL); 68 69 if (of_property_read_u32(pp, "debounce-interval", 70 &button->debounce_interval)) 71 button->debounce_interval = 5; 72 } 73 74 if (pdata->nbuttons == 0) 75 return ERR_PTR(-EINVAL); 76 77 return pdata; 78 }
上述代码通过第31行的for_each_child_of_node（）遍历gpio_keys节点下的所有子节点，并通过of_get_gpio_flags（）、of_property_read_u32（）等API读取出来与各个子节点对应的GPIO、与每个GPIO对应的键盘键值等。
