平台总线---深入分析

阅读引言：本文会从平台总线的介绍，注册平台设备和驱动， 源码分析， 总结五个部分展开， 源码分析platform放在了最后面。

目录

一、平台总线介绍

二、平台总线如何使用

三、平台总线是如何工作的

四、注册platform设备

五、注册platform驱动

六、编写probe函数

七、平台总线源码分析

---

一、平台总线介绍

        平台总线模型也叫platform总线模型。平台总线是Linux系统虚拟出来的总线。所谓虚拟出来的总线其实就是使用软件来模拟物理总线的一些性质， linux各种子系统还是别的， 都特别爱玩匹配这套东西， 挺好。

二、平台总线如何使用

        平台总线模型将一个驱动分成了俩个部分，分别是device.c和driver.c，用来描述device.c硬件，driver. c 用来控制硬件。这样做的目的主要是为了提高代码的重复利用性， 降低耦合度。

三、平台总线是如何工作的

        平台总线通过字符串比较，将name相同的device.c和driver.c匹配到一起来控制硬件。平台总线原则：先分离，后搭档。

        note：源码分析这个位置放在后面些

四、注册platform设备

        platform设备驱动（device.c）里面写的是硬件资源。这里的硬件资源指的是寄存器地址，中断号以及其他硬件资源等。在linux内核里面用struct platform_device结构体来描述硬件资源。这个结构体定义在include/linux/platform_device.h文件当中，结构体原型如下：

struct platform_device {const char	*name;int		id;bool		id_auto;struct device	dev;u64		platform_dma_mask;struct device_dma_parameters dma_parms;u32		num_resources;struct resource	*resource;const struct platform_device_id	*id_entry;/** Driver name to force a match.  Do not set directly, because core* frees it.  Use driver_set_override() to set or clear it.*/const char *driver_override;/* MFD cell pointer */struct mfd_cell *mfd_cell;/* arch specific additions */struct pdev_archdata	archdata;
};

        name可以匹配， 也可以在sys/bus/devices下展示。

/** Resources are tree-like, allowing* nesting etc..*/
struct resource {resource_size_t start;resource_size_t end;const char *name;unsigned long flags;unsigned long desc;struct resource *parent, *sibling, *child;
};

资源的种类：ioport.h文件中

使用struct resource描述硬件资源信息示例：

struct resource my_dev_resource[] = {[0] = {.start = 0x1000, .end = 0x1000, .flags = IORESOURCE_MEM},[1] = {.start = 13, .end = 13, .flags = IORESOURCE_IRQ}
};

在my_dev_resource这个结构体数字中包含了俩组资源，第一组资源的类型是IORESOURCE_MEM，表示这组资源是一组内存类型的资源。起始地址是0xFDD60000，终止地址是0xFDD60004。第二组资源的类型是IORESOURCE_IRQ，表示这是一组中断资源， 中断很号是13。

platform设备加载和卸载函数

1. platform设备加载函数： 函数原型:int platform_device_register(struct platform_device *device) 函数作用：加载platform设备。

2. platform设备卸载函数： 函数原型:void platform_device_unregister(struct platform_device *device) 函数作用：卸载platform设备。

代码结构：

void my_dev_release(struct device *dev)
{printk("%s is called",__func__);
}struct resource my_dev_resource[] = {[0] = {.start = 0xFDD60000, .end = 0xFDD60004, .flags = IORESOURCE_MEM},[1] = {.start = 13, .end = 13, .flags = IORESOURCE_IRQ}
};struct platform_device my_dev = {.name = "mydev",.id = -1,.resource = my_dev_resource,.num_resources = ARRAY_SIZE(my_dev_resource),.dev = {.release = my_dev_release},
};int __init my_dev_init(void)
{platform_device_register(&my_dev);
}void __exit my_dev_exit(void)
{platform_device_unregister(&my_dev);
}

五、注册platform驱动

        关键数据结构, platform设备驱动（driver.c）里面写的软件驱动。在driver.c文件中首先需要定义一个platform_driver结构体。然后去实现这个结构体中的各个成员变量。当driver.c和device.c匹配成功以后，会执行driver.c里面的probe函数。platform_driver这个结构体定义在include/linux/platform_device.h文件当中，结构体原型如下：

          匹配过程和调用驱动中的probe函数后面会再说。

platform设备加载和卸载函数
1.platform设备加载函数：
        函数原型:intIlatform_driver_registepr(struct platform_driver *driver)
        函数作用：加载platform设备。
2. platform设备卸载函数：
        函数原型:void platform_driver_register(struct platform_driver *driver)
        函数作用：卸载platform设备。

int my_probe(struct platform_device *)
{}int my_remove(struct platform_device *)
{}const struct platform_device_id my_id_table = {.name = "my_driver",
};static struct platform_driver my_driver = {.probe = my_probe,.remove = my_remove,.driver = {.name = "my_driver",.owner = THIS_MODULE,},.id_table = &my_id_table,
};int __init my_input_init(void)
{platform_driver_register(&my_driver);return ret;
}void __exit my_input_exit(void)
{platform_driver_unregister(&my_driver);
}

        注册平台驱动框架如上。

        三种匹配方式， 名称匹配， id匹配， 设备树匹配。优先级由低到高。

• 设备与驱动的名称匹配

 

• 设备与驱动的ID匹配

• 设备树匹配

        设备树匹配是不需要设备端的代码的， 由系统启动的时候解析设备树， 得到的device_node，满足条件的再转为平台设备。后面可能还会再出设备树， 设备模型相关的文章。

六、编写probe函数

        驱动是要控制硬件的。但是平台总线模型对硬件的描述是在设备（device）中的。所以在驱动（driver）中，我们需要得到设备（device）中的硬件资源。当设备（device）和驱动（driver）匹配成功以后，会执行驱动（driver）中的probe函数，所以我们要在probe函数中拿到设备（device）中的硬件资源。所以，重点是怎么拿到这些硬件资源呢？

函数原型:extern struct resource *platform_get_resource(struct platform_device *,unsigned int,
unsigned int);
函数作用：获取device中的硬件资源。
函数参数：第一个参数platform_device结构体。第二个参数：资源的类型。第三个参数：索引号。资源处在同类资源的哪个位置上。同类资源指的是flags是一样的同类资源。

返回资源数组中的指定的哪一个的地址。

int my_probe(struct platform_device *dev)
{if (dev == NULL){goto err_probe;}struct resource dev_source;dev_source = platform_get_resource(dev, IORESOURCE_MEM, 0)if (dev_source == NULL) {printk("platform_get_resource failed\r\n");return -2;}/* use dev_source */err_probe:return -1;
}

        拿到resource结构体之后， 使用gpio， 内存， 中断都是有相应的函数的， 根据不同的功能去选择。

七、平台总线源码分析

        先从注册设备端的源码入手。设备基类数据结构如下

/*** struct device - The basic device structure* @parent:	The device's "parent" device, the device to which it is attached.* 		In most cases, a parent device is some sort of bus or host* 		controller. If parent is NULL, the device, is a top-level device,* 		which is not usually what you want.* @p:		Holds the private data of the driver core portions of the device.* 		See the comment of the struct device_private for detail.* @kobj:	A top-level, abstract class from which other classes are derived.* @init_name:	Initial name of the device.* @type:	The type of device.* 		This identifies the device type and carries type-specific* 		information.* @mutex:	Mutex to synchronize calls to its driver.* @bus:	Type of bus device is on.* @driver:	Which driver has allocated this* @platform_data: Platform data specific to the device.* 		Example: For devices on custom boards, as typical of embedded* 		and SOC based hardware, Linux often uses platform_data to point* 		to board-specific structures describing devices and how they* 		are wired.  That can include what ports are available, chip* 		variants, which GPIO pins act in what additional roles, and so* 		on.  This shrinks the "Board Support Packages" (BSPs) and* 		minimizes board-specific #ifdefs in drivers.* @driver_data: Private pointer for driver specific info.* @links:	Links to suppliers and consumers of this device.* @power:	For device power management.*		See Documentation/driver-api/pm/devices.rst for details.* @pm_domain:	Provide callbacks that are executed during system suspend,* 		hibernation, system resume and during runtime PM transitions* 		along with subsystem-level and driver-level callbacks.* @em_pd:	device's energy model performance domain* @pins:	For device pin management.*		See Documentation/driver-api/pin-control.rst for details.* @msi:	MSI related data* @numa_node:	NUMA node this device is close to.* @dma_ops:    DMA mapping operations for this device.* @dma_mask:	Dma mask (if dma'ble device).* @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all* 		hardware supports 64-bit addresses for consistent allocations* 		such descriptors.* @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller*		DMA limit than the device itself supports.* @dma_range_map: map for DMA memory ranges relative to that of RAM* @dma_parms:	A low level driver may set these to teach IOMMU code about* 		segment limitations.* @dma_pools:	Dma pools (if dma'ble device).* @dma_mem:	Internal for coherent mem override.* @cma_area:	Contiguous memory area for dma allocations* @dma_io_tlb_mem: Software IO TLB allocator.  Not for driver use.* @dma_io_tlb_pools:	List of transient swiotlb memory pools.* @dma_io_tlb_lock:	Protects changes to the list of active pools.* @dma_uses_io_tlb: %true if device has used the software IO TLB.* @archdata:	For arch-specific additions.* @of_node:	Associated device tree node.* @fwnode:	Associated device node supplied by platform firmware.* @devt:	For creating the sysfs "dev".* @id:		device instance* @devres_lock: Spinlock to protect the resource of the device.* @devres_head: The resources list of the device.* @knode_class: The node used to add the device to the class list.* @class:	The class of the device.* @groups:	Optional attribute groups.* @release:	Callback to free the device after all references have* 		gone away. This should be set by the allocator of the* 		device (i.e. the bus driver that discovered the device).* @iommu_group: IOMMU group the device belongs to.* @iommu:	Per device generic IOMMU runtime data* @physical_location: Describes physical location of the device connection*		point in the system housing.* @removable:  Whether the device can be removed from the system. This*              should be set by the subsystem / bus driver that discovered*              the device.** @offline_disabled: If set, the device is permanently online.* @offline:	Set after successful invocation of bus type's .offline().* @of_node_reused: Set if the device-tree node is shared with an ancestor*              device.* @state_synced: The hardware state of this device has been synced to match*		  the software state of this device by calling the driver/bus*		  sync_state() callback.* @can_match:	The device has matched with a driver at least once or it is in*		a bus (like AMBA) which can't check for matching drivers until*		other devices probe successfully.* @dma_coherent: this particular device is dma coherent, even if the*		architecture supports non-coherent devices.* @dma_ops_bypass: If set to %true then the dma_ops are bypassed for the*		streaming DMA operations (->map_* / ->unmap_* / ->sync_*),*		and optionall (if the coherent mask is large enough) also*		for dma allocations.  This flag is managed by the dma ops*		instance from ->dma_supported.** At the lowest level, every device in a Linux system is represented by an* instance of struct device. The device structure contains the information* that the device model core needs to model the system. Most subsystems,* however, track additional information about the devices they host. As a* result, it is rare for devices to be represented by bare device structures;* instead, that structure, like kobject structures, is usually embedded within* a higher-level representation of the device.*/
struct device {struct kobject kobj;struct device		*parent;struct device_private	*p;const char		*init_name; /* initial name of the device */const struct device_type *type;const struct bus_type	*bus;	/* type of bus device is on */struct device_driver *driver;	/* which driver has allocated thisdevice */void		*platform_data;	/* Platform specific data, devicecore doesn't touch it */void		*driver_data;	/* Driver data, set and get withdev_set_drvdata/dev_get_drvdata */struct mutex		mutex;	/* mutex to synchronize calls to* its driver.*/struct dev_links_info	links;struct dev_pm_info	power;struct dev_pm_domain	*pm_domain;#ifdef CONFIG_ENERGY_MODELstruct em_perf_domain	*em_pd;
#endif#ifdef CONFIG_PINCTRLstruct dev_pin_info	*pins;
#endifstruct dev_msi_info	msi;
#ifdef CONFIG_DMA_OPSconst struct dma_map_ops *dma_ops;
#endifu64		*dma_mask;	/* dma mask (if dma'able device) */u64		coherent_dma_mask;/* Like dma_mask, but foralloc_coherent mappings asnot all hardware supports64 bit addresses for consistentallocations such descriptors. */u64		bus_dma_limit;	/* upstream dma constraint */const struct bus_dma_region *dma_range_map;struct device_dma_parameters *dma_parms;struct list_head	dma_pools;	/* dma pools (if dma'ble) */#ifdef CONFIG_DMA_DECLARE_COHERENTstruct dma_coherent_mem	*dma_mem; /* internal for coherent memoverride */
#endif
#ifdef CONFIG_DMA_CMAstruct cma *cma_area;		/* contiguous memory area for dmaallocations */
#endif
#ifdef CONFIG_SWIOTLBstruct io_tlb_mem *dma_io_tlb_mem;
#endif
#ifdef CONFIG_SWIOTLB_DYNAMICstruct list_head dma_io_tlb_pools;spinlock_t dma_io_tlb_lock;bool dma_uses_io_tlb;
#endif/* arch specific additions */struct dev_archdata	archdata;struct device_node	*of_node; /* associated device tree node */struct fwnode_handle	*fwnode; /* firmware device node */#ifdef CONFIG_NUMAint		numa_node;	/* NUMA node this device is close to */
#endifdev_t			devt;	/* dev_t, creates the sysfs "dev" */u32			id;	/* device instance */spinlock_t		devres_lock;struct list_head	devres_head;const struct class	*class;const struct attribute_group **groups;	/* optional groups */void	(*release)(struct device *dev);struct iommu_group	*iommu_group;struct dev_iommu	*iommu;struct device_physical_location *physical_location;enum device_removable	removable;bool			offline_disabled:1;bool			offline:1;bool			of_node_reused:1;bool			state_synced:1;bool			can_match:1;
#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)bool			dma_coherent:1;
#endif
#ifdef CONFIG_DMA_OPS_BYPASSbool			dma_ops_bypass : 1;
#endif
};

        注册平台设备调用了三个函数， 按照顺序查看。

        这里涉及到了很多的sys， 也就是设备模型的东西， 后面单独出文章讲讲这个sys， 也随便我自己梳理一下这个sys设备模型这块的东西。重点还是看这个函数platform_device_add， 文件路径drivers\base\platform.c

/*** platform_device_add - 将平台设备添加到设备层次结构中* @pdev: 要添加的平台设备** 这是 platform_device_register() 的第二部分，可以单独调用，但前提是 pdev 是通过 platform_device_alloc() 分配的。*/
int platform_device_add(struct platform_device *pdev)
{u32 i;  // 用于遍历资源的索引int ret;  // 返回值if (!pdev)return -EINVAL;  // 如果 pdev 为空，返回无效参数错误if (!pdev->dev.parent)pdev->dev.parent = &platform_bus;  // 设置设备的父设备为 platform_buspdev->dev.bus = &platform_bus_type;  // 设置设备的总线类型为 platform_bus_type// 根据设备 ID 设置设备名称switch (pdev->id) {default:dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);  // 设置设备名称为 "name.id"break;case PLATFORM_DEVID_NONE:dev_set_name(&pdev->dev, "%s", pdev->name);  // 设置设备名称为 "name"break;case PLATFORM_DEVID_AUTO:/** 自动分配的设备 ID。我们将其标记为自动分配，以便记住它需要被释放，并附加一个后缀* 以避免与显式 ID 的命名空间冲突。*/ret = ida_alloc(&platform_devid_ida, GFP_KERNEL);  // 分配一个新的设备 IDif (ret < 0)goto err_out;  // 如果分配失败，跳转到错误处理pdev->id = ret;  // 设置设备 IDpdev->id_auto = true;  // 标记为自动分配的 IDdev_set_name(&pdev->dev, "%s.%d.auto", pdev->name, pdev->id);  // 设置设备名称为 "name.id.auto"break;}// 遍历设备的资源并插入到资源树中for (i = 0; i < pdev->num_resources; i++) {struct resource *p, *r = &pdev->resource[i];  // 获取当前资源if (r->name == NULL)r->name = dev_name(&pdev->dev);  // 如果资源名称为空，设置为设备名称p = r->parent;  // 获取资源的父资源if (!p) {if (resource_type(r) == IORESOURCE_MEM)p = &iomem_resource;  // 如果是内存资源，父资源为 iomem_resourceelse if (resource_type(r) == IORESOURCE_IO)p = &ioport_resource;  // 如果是 I/O 资源，父资源为 ioport_resource}if (p) {ret = insert_resource(p, r);  // 将资源插入到资源树中if (ret) {dev_err(&pdev->dev, "failed to claim resource %d: %pR\n", i, r);  // 如果插入失败，记录错误goto failed;  // 跳转到错误处理}}}pr_debug("Registering platform device '%s'. Parent at %s\n",dev_name(&pdev->dev), dev_name(pdev->dev.parent));  // 打印调试信息ret = device_add(&pdev->dev);  // 将设备添加到设备层次结构中if (ret == 0)return ret;  // 如果成功，返回 0failed:if (pdev->id_auto) {ida_free(&platform_devid_ida, pdev->id);  // 如果 ID 是自动分配的，释放 IDpdev->id = PLATFORM_DEVID_AUTO;  // 重置 ID}// 释放所有已分配的资源while (i--) {struct resource *r = &pdev->resource[i];if (r->parent)release_resource(r);  // 释放资源}err_out:return ret;  // 返回错误码
}
EXPORT_SYMBOL_GPL(platform_device_add);  // 导出符号，使其可以被 GPL 模块使用

 

数据结构原型：

/*** struct bus_type - The bus type of the device** @name:	The name of the bus.* @dev_name:	Used for subsystems to enumerate devices like ("foo%u", dev->id).* @bus_groups:	Default attributes of the bus.* @dev_groups:	Default attributes of the devices on the bus.* @drv_groups: Default attributes of the device drivers on the bus.* @match:	Called, perhaps multiple times, whenever a new device or driver*		is added for this bus. It should return a positive value if the*		given device can be handled by the given driver and zero*		otherwise. It may also return error code if determining that*		the driver supports the device is not possible. In case of*		-EPROBE_DEFER it will queue the device for deferred probing.* @uevent:	Called when a device is added, removed, or a few other things*		that generate uevents to add the environment variables.* @probe:	Called when a new device or driver add to this bus, and callback*		the specific driver's probe to initial the matched device.* @sync_state:	Called to sync device state to software state after all the*		state tracking consumers linked to this device (present at*		the time of late_initcall) have successfully bound to a*		driver. If the device has no consumers, this function will*		be called at late_initcall_sync level. If the device has*		consumers that are never bound to a driver, this function*		will never get called until they do.* @remove:	Called when a device removed from this bus.* @shutdown:	Called at shut-down time to quiesce the device.** @online:	Called to put the device back online (after offlining it).* @offline:	Called to put the device offline for hot-removal. May fail.** @suspend:	Called when a device on this bus wants to go to sleep mode.* @resume:	Called to bring a device on this bus out of sleep mode.* @num_vf:	Called to find out how many virtual functions a device on this*		bus supports.* @dma_configure:	Called to setup DMA configuration on a device on*			this bus.* @dma_cleanup:	Called to cleanup DMA configuration on a device on*			this bus.* @pm:		Power management operations of this bus, callback the specific*		device driver's pm-ops.* @iommu_ops:  IOMMU specific operations for this bus, used to attach IOMMU*              driver implementations to a bus and allow the driver to do*              bus-specific setup* @need_parent_lock:	When probing or removing a device on this bus, the*			device core should lock the device's parent.** A bus is a channel between the processor and one or more devices. For the* purposes of the device model, all devices are connected via a bus, even if* it is an internal, virtual, "platform" bus. Buses can plug into each other.* A USB controller is usually a PCI device, for example. The device model* represents the actual connections between buses and the devices they control.* A bus is represented by the bus_type structure. It contains the name, the* default attributes, the bus' methods, PM operations, and the driver core's* private data.*/
struct bus_type {const char		*name;const char		*dev_name;const struct attribute_group **bus_groups;const struct attribute_group **dev_groups;const struct attribute_group **drv_groups;int (*match)(struct device *dev, struct device_driver *drv);int (*uevent)(const struct device *dev, struct kobj_uevent_env *env);int (*probe)(struct device *dev);void (*sync_state)(struct device *dev);void (*remove)(struct device *dev);void (*shutdown)(struct device *dev);int (*online)(struct device *dev);int (*offline)(struct device *dev);int (*suspend)(struct device *dev, pm_message_t state);int (*resume)(struct device *dev);int (*num_vf)(struct device *dev);int (*dma_configure)(struct device *dev);void (*dma_cleanup)(struct device *dev);const struct dev_pm_ops *pm;const struct iommu_ops *iommu_ops;bool need_parent_lock;
};

        后面设备和驱动匹配的时候就是调用了这些当中的一些函数。

调用过程关系

platform_device_register

        platform_device_add

                device_add

                        bus_probe_device

                                device_initial_probe

                                        __device_attach

                                                __device_attach_driver

                                                        driver_probe_device

                                                                __driver_probe_device

                                                                        really_probe

        在really_probe函数中调用找到的匹配上的驱动中的probe函数。这里看了驱动端的platform_driver_register函数的实现， 发现和设备端的实现差不多。直接上实现的原理

原理分析： 

        维护了两条链表，一个是设备的， 一个是驱动的， 当注册设备的时候， 调用总线的匹配函数， 这个匹配函数会根据规则匹配， 用当前注册的设备和驱动链表中的一 一做匹配， 匹配上之后， 调用驱动中的probe函数， 注册驱动也是一样的道理。