Linux裝置模型分析之device_driver（基於3.10.1核心）
一、device_driver定義
- 181/**
- 182 * struct device_driver - The basic device driver structure
- 183 * @name: Name of the device driver.
- 184 * @bus: The bus which the device of this driver belongs to.
- 185 * @owner: The module owner.
- 186 * @mod_name: Used for built-in modules.
-
187 * @suppress_bind_attrs: Disables bind/unbind via sysfs.
- 188 * @of_match_table: The open firmware table.
- 189 * @acpi_match_table: The ACPI match table.
- 190 * @probe: Called to query the existence of a specific device,
- 191 * whether this driver can work with it, and bind the driver
- 192 * to a specific device.
-
193 * @remove: Called when the device is removed from the system to
- 194 * unbind a device from this driver.
- 195 * @shutdown: Called at shut-down time to quiesce the device.
- 196 * @suspend: Called to put the device to sleep mode. Usually to a
- 197 * low power state.
- 198 * @resume: Called to bring a device from sleep mode.
-
199 * @groups: Default attributes that get created by the driver core
- 200 * automatically.
- 201 * @pm: Power management operations of the device which matched
- 202 * this driver.
- 203 * @p: Driver core's private data, no one other than the driver
- 204 * core can touch this.
- 205 *
- 206 * The device driver-model tracks all of the drivers known to the system.
- 207 * The main reason for this tracking is to enable the driver core to match
- 208 * up drivers with new devices. Once drivers are known objects within the
- 209 * system, however, a number of other things become possible. Device drivers
- 210 * can export information and configuration variables that are independent
- 211 * of any specific device.
- 212 */
- 213struct device_driver {
- 214 constchar *name;
- 215 struct bus_type *bus;
- 216
- 217 struct module *owner;
- 218 constchar *mod_name; /* used for built-in modules */
- 219
- 220 bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
- 221
- 222 conststruct of_device_id *of_match_table;
- 223 conststruct acpi_device_id *acpi_match_table;
- 224
- 225 int (*probe) (struct device *dev);
- 226 int (*remove) (struct device *dev);
- 227 void (*shutdown) (struct device *dev);
- 228 int (*suspend) (struct device *dev, pm_message_t state);
- 229 int (*resume) (struct device *dev);
- 230 conststruct attribute_group **groups;
- 231
- 232 conststruct dev_pm_ops *pm;
- 233
- 234 struct driver_private *p;
- 235};
name，device_driver的名字。
bus，device_driver支援的device所依附的bus。
probe，探測device_drvier是否支援引數指定的device。如果支援，則繫結該device_driver和該device。
remove，該device被移除時呼叫該函式，解除該device與device_driver的繫結。
shutdown，當關機時呼叫該函式，以關閉引數指定的device。
suspend，當device進入休眠狀態時，呼叫該函式。
resume，當device從休眠狀態被喚醒時，呼叫該函式。
p，device_driver私有資料，它是struct driver_private型別，該型別定義在drivers/base/base.h檔案中，其內容如下：
- 46struct driver_private {
- 47 struct kobject kobj;
- 48 struct klist klist_devices;
- 49 struct klist_node knode_bus;
- 50 struct module_kobject *mkobj;
- 51 struct device_driver *driver;
- 52};
kobj，是其所屬的device_driver對應的kobject。
klist_devices，其所屬的device_driver支援的device連結串列。
driver，所屬的device_driver。
二、device_driver的註冊
device_driver的註冊是通過呼叫driver_register函式完成的，該函式定義在drivers/base/driver.c檔案中，其內容如下：
- 156/**
- 157 * driver_register - register driver with bus
- 158 * @drv: driver to register
- 159 *
- 160 * We pass off most of the work to the bus_add_driver() call,
- 161 * since most of the things we have to do deal with the bus
- 162 * structures.
- 163 */
- 164int driver_register(struct device_driver *drv)
- 165{
- 166 int ret;
- 167 struct device_driver *other;
- 168
- 169 BUG_ON(!drv->bus->p);
- 170
- 171 if ((drv->bus->probe && drv->probe) ||
- 172 (drv->bus->remove && drv->remove) ||
- 173 (drv->bus->shutdown && drv->shutdown))
- 174 printk(KERN_WARNING "Driver '%s' needs updating - please use "
- 175 "bus_type methods\n", drv->name);
- 176
- 177 other = driver_find(drv->name, drv->bus);
- 178 if (other) {
- 179 printk(KERN_ERR "Error: Driver '%s' is already registered, "
- 180 "aborting...\n", drv->name);
- 181 return -EBUSY;
- 182 }
- 183
- 184 ret = bus_add_driver(drv);
- 185 if (ret)
- 186 return ret;
- 187 ret = driver_add_groups(drv, drv->groups);
- 188 if (ret) {
- 189 bus_remove_driver(drv);
- 190 return ret;
- 191 }
- 192 kobject_uevent(&drv->p->kobj, KOBJ_ADD);
- 193
-
相關推薦
Linux裝置模型分析之device_driver（基於3.10.1核心）
一、device_driver定義 181/** 182 * struct device_driver - The basic device driver structure 183 * @name: Name of the device
Linux裝置模型分析之bus（基於3.10.1核心）
作者：劉昊昱 核心版本：3.10.1 一、bus定義 Linux裝置驅動模型中的bus，即可以是物理匯流排（如PCI、I2C匯流排）的抽象，也可以是出於裝置驅動模型架構需要而定義的虛擬的“platform”匯流排。一個符合Linux裝置驅動模型的device或devi
Linux裝置驅動程式架構分析之platform（基於3.10.1核心）
作者：劉昊昱 核心版本：3.10.1 一、platform bus的註冊 platform bus註冊是通過platform_bus_init函式完成的，該函式定義在drivers/base/platform.c檔案中，其內容如下： 904int __init pl
Linux裝置驅動程式架構分析之I2C架構（基於3.10.1核心）
作者：劉昊昱 核心版本：3.10.1 I2C體系架構的硬體實體包括兩部分： 硬體I2C Adapter：硬體I2C Adapter表示一個硬體I2C介面卡，也就是I2C控制器。一般是SOC中的一個介面，也可以用GPIO模擬。硬體I2C Adapter主要用來在I2
Linux晶片級移植與底層驅動（基於3.7.4核心）
1. SoC Linux底層驅動的組成和現狀 為了讓Linux在一個全新的ARM SoC上執行，需要提供大量的底層支撐，如定時器節拍、中斷控制器、SMP啟動、CPU hotplug以及底層的GPIO、clock、pinctrl和DMA硬體的封裝等。定時器
Linux晶片級移植與底層驅動（基於3.7.4核心）(GPIO&&pinctrl&&clk)
6. GPIO驅動 在drivers/gpio下實現了通用的基於gpiolib的GPIO驅動，其中定義了一個通用的用於描述底層GPIO控制器的gpio_chip結構體，並要求具體的SoC實現gpio_chip結構體的成員函式，最後透過gpiochip_add
學習《Linux裝置模型淺析之驅動篇》筆記(一)
原文中說了，核心版本為2.6.29；這裡都貼3.15的核心原始碼； 檔案/drivers/rtc/rtc-s3c.c static struct platform_driver s3c_rtc_driver = { .probe= s3c_rtc_pro
Linux裝置驅動分析之熱拔插
/*輔助函式uevent_helper(/sbin/mdev，mdev是busybox的傑作)用於對熱拔插裝置進行建立及刪除 */if (uevent_helper[0] && !kobj_usermode_filter(kobj)) {char *a
樹莓派3B+ 原始碼方式安裝opencv3（基於3.4.1）
身邊有朋友在樹莓派上安裝不上去opencv3，因此在這裡記錄了一下自己安裝opencv3的過程。 這位前輩的安裝步驟非常非常詳細，下邊所有過程都是參考此經驗，只不過添加了自己安裝過程的圖片，看著好理解一點。 非常感謝，謝謝謝謝謝謝！ 安裝過程 更換軟體源的時候建議
SMC-RTOS任務切換，棧空間初始化（基於CM3，CM4核心）
棧空間初始化 CM3核心是小端格式的，棧也是滿減棧，下面是任務TCB初始化的時候任務棧空間的初始化 （這部分內容與CM3核心緊密相連，需要讀者非常熟悉CM3堆疊機制（MSP PSP雙堆疊機制等），異常機制等處理） /** * This functio
Linux裝置模型之tty驅動架構分析
------------------------------------------ 本文系本站原創,歡迎轉載!轉載請註明出處:http://ericxiao.cublog.cn/------------------------------------------一：前言Tty這個名稱源於電傳打位元組的簡稱。
linux裝置模型之uart驅動架構分析
一:前言 接著前面的終端控制檯分析,接下來分析serial的驅動.在linux中,serial也對應著終端,通常被稱為串列埠終端.在shell上,我們看到的/dev/ttyS*就是串列埠終端所對應的裝置節點. 在分析具體的serial驅動之前.有必要先分析uart
Linux裝置模型之tty&&uart驅動架構分析
五: uart_add_one_port()操作 在前面提到.在對uart裝置檔案過程中.會將操作轉換到對應的port上,這個port跟uart_driver是怎麼關聯起來的呢?這就是uart_add_ont_port()的主要工作了. 顧名思義,這個函式是在uart_driver增加一個port.程式碼如
linux驅動由淺入深系列：camera驅動之二（基於高通平臺的V4L2結構及程式碼分析）
在上一篇文章中介紹了camera的基礎知識和相關概念，我們一起來了解一下驅動相關的程式碼結構。本文以高通+android平臺為示例，首先看一下整體框圖：這張圖是從整體上來看的1，圖中最下面的是kernel層的驅動，其中按照V4L2架構實現了camera sensor等驅動，向
Linux裝置驅動工程師之路——裝置模型（上）底層模型
Linux裝置驅動工程師之路——裝置模型（上）底層模型 K-Style 一、重要知識點 1.Sysfs檔案系統 Sysfs檔案系統是一種類似於proc檔案系統的特殊檔案系統，它存在於記憶體當中，當系統啟動時由核心掛載於記憶體當中。用於將
linux裝置模型之bus，device，driver分析二
=============================== 本文系本站原創,歡迎轉載! 轉載請註明出處:http://blog.csdn.net/gdt_a20 =============================== 上篇分析了bus，driver的註冊過程
【原創】linux裝置模型之kset/kobj/ktype分析
# 背 景 - `Read the fucking source code!` --By 魯迅 - `A picture is worth a thousand words.` --By 高爾基 說明： 1. Kernel版本：4.14 2. ARM64處理器，Contex-A53，雙核 3. 使用工具：
linux音頻alsa-uda134x驅動分析之二（時鐘)
lin pen play 個數 inter and 文本 ted word Audio Clocking音頻時鐘==============This text describes the audio clocking terms in ASoC and digital au
Linux 裝置驅動篇之-------I2c裝置驅動（待續）
Linux 裝置驅動篇之-------I2c裝置驅動 雖然I2C硬體體系結構和協議都很容易理解，但是Linux I2C驅動體系結構卻有相當的複雜度，它主要由3部分組成，即I2C裝置驅動、I2C匯流
linux裝置模型十（bus_device_driver總結）
前面九章分別對linux驅動模型中的細節部分進行了分析，本節作為小節，使用一個簡單的例子，分別使用前面分析的內容，實現一個簡單的匯流排，裝置，驅動之間的關係。 實現一條匯流排 #include <linux/device.h> #include <li