Разработка драйвера PCI устройства под Linux

В данной статье я рассматриваю процесс написания простого драйвера PCI устройства под OC Linux. Будет кратко изучено устройство программной модели PCI, написание собственно драйвера, тестовой пользовательской программы и запуск всей этой системы.

В качестве подопытного выступит интерфейс датчиков перемещения ЛИР940/941. Это устройство, отечественного производства, обеспечивает подключение до 4 энкодеров с помощью последовательного протокола SSI поверх физического интерфейса RS-422.

На сегодняшний день шина PCI (и её более новый вариант — PCI Express) является стандартным интерфейсом для подключения широкого спектра дополнительного оборудования к современным компьютерам и в особом представлении эта шина не нуждается.

Не редко именно в виде PCI адаптера реализуются различные специализированные интерфейсы ввода-вывода для подключения не менее специализированного внешнего оборудования.
Так же до сих пор не редки ситуации когда производитель оборудования предоставляет драйвер лишь под OC Windows.

Плата ЛИР941 была приобретена организацией, в которой я работаю, для получения данных с высокоточных абсолютных датчиков перемещения. Когда встал вопрос о работе под Linux оказалось, что производитель не предоставляет ничего под эту ОС. В сети так же ничего не нашлось, что впрочем нормально для такого редкого и специализированного устройства.

На самой плате находится FPGA фирмы Altera, в которой реализуется вся логика взаимодействия, а также несколько (от 2 до 4) интерфейсов RS-422 с гальванической развязкой.

Обычно в такой ситуации разработчики идут по пути обратного инженеринга, пытаясь разобраться как работает Windows драйвер.

Морально готовясь к этому развлечению я решил для начала попробовать самый простой и прямой способ — написал запрос непосредственно производителю оборудования.

Я спросил не могут ли они предоставить какую-нибудь документацию или спецификацию на их устройство, дабы я мог разработать открытый драйвер под Linux. К моему удивлению производитель пошел на встречу, мне ответили очень быстро и прислали всю необходимую документацию!

Шина PCI

Прежде чем переходить к разработке собственно драйвера предлагаю рассмотреть как устроена программная модель PCI и как вообще происходит взаимодействие с устройством.

Небольшая заметка по поводу PCI и PCI Express.
Несмотря на то, что аппаратно это два разных интерфейса — оба они используют одну программную модель, так что с точки зрения разработчика особой разницы нет и драйвер будет работать одинаково.

Шина PCI позволяет подключать одновременно большое количество устройств и нередко состоит из нескольких физических шин, соединяющихся между собой посредством специальных «мостов» — PCI Bridge. Каждая шина имеет свой номер, устройствам на шине так же присваивается свой уникальный номер. Так же каждое устройство может быть многофункциональным, как бы разделенным на отдельные устройства, реализующие какие-то отдельные функции, каждой такой функции аналогично присваивается свой номер.
Таким образом системный «путь» к конкретному функционалу устройства выглядит так:
<номер pci шины> <номер устройства> <номер функции>.

Что бы посмотреть какие устройства подключены к шине PCI в Linux достаточно выполнить команду lspci.

Вывод может оказаться неожиданно длинным, т. к. кроме устройств непосредственно физически подключенных через pci/pci express слоты (например видеоадаптера) есть множество системных устройств, распаянных (или же входящих в устройство микросхем чипсета) на материнской плате.
Первая колонка этого вывода, состоящая из чисел, как раз и представляет собой набор рассмотренных выше идентификаторов.

Например:

$ lspci
01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [GeForce GT 240]

Этот вывод означает, что видеоадаптер NVIDIA GT 240 находится на PCI шине 01, номер устройства — 00 и номер его единственной функции так же 0.

Следует еще добавить, что каждое PCI устройство имеет набор из двух уникальных идентификаторов — Vendor ID и Product ID, это позволяет драйверам однозначно идентифицировать устройства и правильно работать с ними.

Выдачей уникальных Vendor ID для производителей аппаратного обеспечения занимается специальный консорциум – PCI-SIG.

Что бы увидеть эти идентификаторы достаточно запустить lspci с ключами -nn:

$ lspci -nn
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT215 [GeForce GT 240] [10de:0ca3] 

Где 10de — идентификатор производителя, NVIDIA Corporation, а 0ca3 — идентификатор конкретного оборудования.

Узнать кто есть кто можно с помощью специальных сайтов, например The PCI ID Repository

Чтение служебной информации и конфигурация PCI устройства осуществляется посредством набора конфигурационных регистров. Каждое устройство обязано предоставлять стандартный набор таких регистров, которые будут рассмотрены далее.

Регистры отображаются в оперативную память компьютера во время загрузки и ядро операционной системы связывает с устройством особую структуру данных — pci_dev, а так же предоставляет набор функций для чтения и записи.

Помимо конфигурационных регистров PCI устройства могут иметь до 6 каналов ввода-вывода данных. Каждый канал так же отображается в оперативную память по некоему адресу, назначаемому ядром ОС.

Операции чтения-записи этой области памяти, с определенными параметрами размера блока и смещения, приводят непосредственно к записи-чтению в устройство.

Получается, что для написания драйвера PCI необходимо знать какие конфигурационные регистры использует устройство, а так же по каким смещениям (и что именно) нужно записывать/читать. В моем случае производитель предоставил всю необходимую информацию.

Конфигурационное пространство PCI

Первые 64 байта являются стандартизированными и должны предоставляться всеми устройствами, независимо от того требуются они или нет.



На картинке отмечены регистры являющиеся обязательными, они всегда должны содержать какие-либо осмысленные значения, остальные же могут содержать нули, если это не требуется в данном случае.

Порядок байт во всех регистрах PCI — little-endian, это следует учитывать, если разработка драйвера ведется для архитектуры с иным порядком.

Давайте посмотрим что из себя представляют некоторые регистры.

VendorID и ProductID — уже известные нам регистры, в которых хранятся идентификаторы производителя и оборудования. Каждый из регистров занимает 2 байта.

Command — этот регистр определяет некоторые возможности PCI устройства, например разрешает или запрещает доступ к памяти.


Инициализацией этих битов занимается операционная система.

Status — биты этого регистра хранят информацию о различных событиях PCI шины.


Эти значения выставляются оборудованием, в моём случае были сконфигурированы только биты 9, 10, определяющие время реакции платы.

Revision ID — число, ревизия конкретной платы. Полезно в тех случаях, когда есть несколько ревизий устройства и различия необходимо учитывать в коде драйвера.

Class Code — «волшебное» число, отображающее класс устройства, например: Network Controller, Display Controller и т. п. Список существующих кодов можно посмотреть тут.

Base Address Registers — эти регистры, в количестве 6 штук, служат для определения того как и сколько памяти выделется устройству для процедур ввода/вывода. Этот регистр используется pci подсистемой ядра и обычно не интересен разработчикам драйверов.

Теперь можно перейти к программирование и попробовать прочесть эти регистры и получить доступ к памяти ввода/вывода.

Разработка модуля ядра

Как наверное многие знают — точками входа и выхода в модуль ядра Linux являются специальные __init и __exit функции.

Определим эти функции и выполним процедуру регистрации нашего драйвера с помощью вызова специальной функции — pci_register_driver(struct pci_driver *drv), а так же процедуру выгрузки с помощью pci_unregister_driver(struct pci_driver *drv).

#include <linux/init.h>
#include <linux/module.h>
#include <linux/pci.h>

static int __init mypci_driver_init(void)
{
	return pci_register_driver(&my_driver);
}

static void __exit mypci_driver_exit(void)
{
	pci_unregister_driver(&my_driver);
}

module_init(mypci_driver_init);
module_exit(mypci_driver_exit);

Аргументом функций register и unregister является структура pci_driver, которую необходимо предварительно инициализировать, сделаем это в самом начале, объявив структуру статической.

static struct pci_driver my_driver = {
	.name = "my_pci_driver",
	.id_table = my_driver_id_table,
	.probe = my_driver_probe,
	.remove = my_driver_remove
};

Поля структуры, которые мы инициализируем:
name — уникальное имя драйвера, которое будет использовано ядром в /sys/bus/pci/drivers
id_table — таблица пар Vendor ID и Product ID, с которым может работать драйвер.
probe — функция вызываемая ядром после загрузки драйвера, служит для инициализации оборудования
remove — функция вызываемая ядром при выгрузке драйвера, служит для освобождения каких-либо ранее занятых ресурсов

Так же в структуре pci_driver предусмотрены дополнительные функции, которые мы не будем использовать в данном примере:
suspend — эта функция вызывается при засыпании устройства
resume — эта функция вызывается при пробуждении устройства

Рассмотрим как определяется таблица пар Vendor ID и Product ID.
Это простая структура со списком идентификаторов.

static struct pci_device_id my_driver_id_table[] = {
	{ PCI_DEVICE(0x0F0F, 0x0F0E) },
	{ PCI_DEVICE(0x0F0F, 0x0F0D) },
	{0,}
};

Где 0x0F0F — Vendor ID, а 0x0F0E и 0x0F0D — пара Product ID этого вендора.
Пар идентификаторов может быть как одна, так и несколько.
Обязательно завершать список с помощью пустого идентификатора {0,}

После объявления заполненной структуры необходимо передать её макросу

MODULE_DEVICE_TABLE(pci, my_driver_id_table);

В функции my_driver_probe() мы можем делать, собственно, все что нам хочется.

static int my_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
	...
}

Например можно попробовать прочитать конфигурационные регистры, описанные выше, с целью проверки корректности идентификаторов или выяснения ревизии платы.

В случае каких-либо проблем или несоответствий можно вернуть отрицательное значение кода ошибки и ядро прервет загрузку модуля. О чтении регистров конфигурации будет рассказано ниже.

Также обычно в этом месте выполняют инициализацию памяти ввода/вывода устройства для последующей работы с ней.

Полезным будет в этом месте определить некоторую «приватную» структуру драйвера в которой будут храниться данные, полезные во всех функциях драйвера. Например это может быть указатель на ту же память ввода/вывода устройства.

struct my_driver_priv {
	u8 __iomem *hwmem;
}

После инициализации приватной структуры необходимо выполнить её регистрацию

pci_set_drvdata(pdev, drv_priv);

В функции my_driver_remove() удобно выполнять освобождение занятых ресурсов, например можно освободить память ввода/вывода.

Так же тут необходимо освобождать саму структуру struct pci_dev

static void my_driver_remove(struct pci_dev *pdev)
{
	struct my_driver_priv *drv_priv = pci_get_drvdata(pdev);

	if (drv_priv) {
		kfree(drv_priv);
	}

	pci_disable_device(pdev);
}

Работа с регистрами конфигурации

Для выполнения процедур чтения/записи регистров в ядре Linux предусмотрены несколько функций. Все эти функции, связанные с PCI подсистемой, доступны в заголовочном файле <linux/pci.h>

Чтение 8, 16 и 32 бит регистров соответственно:

int pci_read_config_byte(struct pci_dev *dev, int where, u8 *ptr);
int pci_read_config_word(struct pci_dev *dev, int where, u16 *ptr);
int pci_read_config_dword(struct pci_dev *dev, int where, u32 *ptr);

Запись 8, 16 и 32 бит регистров соответственно:

int pci_write_config_byte (struct pci_dev *dev, int where, u8 val);
int pci_write_config_word (struct pci_dev *dev, int where, u16 val);
int pci_write_config_dword (struct pci_dev *dev, int where, u32 val);

Первый аргумент всех этих функций — структура pci_dev, которая непосредственно связана с конкретным устройством PCI. Инициализация этой структуры будет рассмотрена далее.

Например мы хотим прочитать значения регистров Vendor ID, Product ID и Revision ID:

#include <linux/pci.h>

….

u16 vendor, device, revision;

pci_read_config_word(pdev, PCI_VENDOR_ID, &vendor);
pci_read_config_word(pdev, PCI_DEVICE_ID, &device);
pci_read_config_word(pdev, PCI_REVISION_ID, &revision);

Как видно — все предельно просто, подставляя необходимое значение аргумента whrere мы можем получить доступ к любому конфигурационному регистру конкретного pci_dev.

С чтением/записью памяти устройства все несколько сложнее.

Мы должны указать какой тип ресурса хотим получить, определиться с размером и смещением, выделить необходимый кусок памяти и отобразить этот кусок памяти на устройство.
После этого мы можем писать и читать данную память как нам угодно, взаимодействуя непосредственно с устройством.

#include <linux/pci.h>

int bar;	
unsigned long mmio_start, mmio_len;
u8 __iomem *hwmem;

struct pci_dev *pdev;

...

// определяем какой именно кусок памяти мы хотим получить, в данном случае этот ресурс ввода/вывода
bar = pci_select_bars(pdev, IORESOURCE_MEM); 

// "включаем" память устройства
pci_enable_device_mem(pdev);

// запрашиваем необходимый регион памяти, с определенным ранее типом
pci_request_region(pdev, bar, "My PCI driver");

// получаем адрес начала блока памяти устройства и общую длину этого блока
mmio_start = pci_resource_start(pdev, 0);
mmio_len = pci_resource_len(pdev, 0);

// мапим выделенную память к аппаратуре
hwmem = ioremap(mmio_start, mmio_len);

Дальше мы можем свободно работать с памятью, на которую указывает hwmem.
Правильнее всего использовать для этой цели специальные функции ядра.

Запись 8, 16 и 32 бит в память устройства:

void iowrite8(u8 b, void __iomem *addr)
void iowrite16(u16 b, void __iomem *addr)
void iowrite32(u16 b, void __iomem *addr)

Чтение 8, 16 и 32 бит из памяти устройства:

unsigned int ioread8(void __iomem *addr)
unsigned int ioread16(void __iomem *addr)
unsigned int ioread32(void __iomem *addr)

Убедитесь, что у вас установлены заголовочные файлы ядра. Для Debian/Ubuntu установка необходимого пакета выполняется так:

sudo apt-get install linux-headers-$(uname -r)

Компиляция модуля выполняется простой командой make, попробовать загрузить модуль можно командой

sudo insmod test_pci_module.ko

Скорее всего просто тихо ничего не произойдет, разве что у вас действительно окажется устройство с Vendor и Product ID из нашего примера.

Теперь я хотел бы вернуться к конкретному устройству, для которого разрабатывался драйвер.
Вот какую информацию про IO мне прислали разработчики платы ЛИР-941:

RgStatus:
b7 — Флаг паузы между транзакциями SSI (1 — пауза) (см. протокол SSI)
b6 — Флаг текущей трансакции (1- происходит передача данных) (см. протокол SSI)
b5 — Ext4 (Произошла защелка данных по сигналу Ext4)
b4 — Ext3 (Произошла защелка данных по сигналу Ext3)
b3 — Ext2 (Произошла защелка данных по сигналу Ext2)
b2 — Ext1 (Произошла защелка данных по сигналу Ext1)
b1 — Режим непрерывного опроса (По окончании передачи кода, аппаратно вырабатывается новый запрос)
b0 — По запросу от компьютера (Однократный запрос текущего положения)

Это значит, что если я хочу, например, прочитать данные от энкодера, подключенного к каналу 3 мне необходимо проверить седьмой бит блока RgStatus3, дождаться там еденички (пауза между транзакциями — значит уже ранее получили информацию от датчика и записали её в память платы, идет подготовка к следующему запросу) и прочитать число, хранящееся в третьем куске памяти длиной 32 бита.

Всё сводится к вычислению необходимо сдвига от начала куска памяти и чтения необходимого количества байт.

Из таблицы ясно, что данные каналов хранятся в виде 32 битных значений, а данные RgStatus — в виде значений длиной 8 бит.

Значит для чтения RgStatus3 необходимо сдвинуться 4 раза 32 бита и два раза по 8 бит и затем прочесть 8 бит из этой позиции.

А для чтения данных третьего канала необходимо сдвинуться 2 раза по 32 бита и прочесть значение длиной 32 бита.

Для выполнения всех этих операций можно написать удобные макросы:

#define CHANNEL_DATA_OFFSET(chnum) (sizeof(uint32_t) * chnum)
#define CHANNEL_RG_ST_OFFSET(chnum) ((sizeof(uint32_t) * 4) + (sizeof(uint8_t) * chnum))

Где chnum — номер требуемого канала, начиная с нуля.

Также не лишним в данном деле будет и такой простой макрос, определяющий «включен» ли бит на определенной позиции.

#define CHECK_BIT(var,pos) ((var) & (1 << (pos)))

Получается такой код для чтения третьего канала данных:

#include <linux/pci.h>
…
uint8_t chnum = 2;
uint32_t enc_data;

//  hwmem — память устройства, которую мы получили ранее
// r_addr указывает на точку в памяти, где находится RgStatus3
void* r_addr = hwmem + CHANNEL_RG_ST_OFFSET(chnum);

// ждем паузы между транзакциями
while(1) {
	// читаем 8 бит по указателю  r_addr
	reg = ioread8(r_addr);

	// когда 7 бит «включен» - пауза между транзакциями, прерываем цикл
	if (!CHECK_BIT(reg, 7)) {
		break;
	}
}

// теперь прыгаем в точку, где лежат данные датчика
r_addr = hwmem + CHANNEL_DATA_OFFSET(chnum);

// читаем 32 битное значение
enc_data = ioread32(r_addr);

Все, мы получили от платы данные датчика, подключенного к третьему каналу и записали их в переменную enc_data.

Касательно записи в устройство производитель прислал уже другую табличку.
Видно, что на запись структура немного другая и придется писать новые макросы, с новыми смещениями.

DATA WIDTH — Определяет максимальное количество бит в одной трансакции SSI. (разрядность приемного регистра). Допустимые значения – от 1 до 32

CLOCK RATE – Порт, определяющий коэффициент деления системного Clk (33 МГц) для формирования Сlock SSI.
Kдел = (CLOCK RATE)*2+2
PAUSE RATE Порт, определяющий величину паузы после транзакции, в периодах Clk (30 нс)
CONTROL 1:
b7 — Режим SSI (0 – обычный режим, 1 – режим 16 разрядного абс. Датчика, с ожиданием стартового бита (устаревший вариант выдачи данных, нужен только для совместимости)).
b6 — Зарезервировано
b5 — Разрешение внешнего сигнала Ext4
b4 — Разрешение внешнего сигнала Ext3
b3 — Разрешение внешнего сигнала Ext2
b2 — Разрешение внешнего сигнала Ext1
b1 — Разрешение непрерывного опроса датчика
b0 — Выработать однократный опрос

Тут все аналогично — считаем сдвиг для необходимой области и записываем значение соответствующей функцией iowriteX

Взаимодействие пользовательского окружения с PCI драйвером

Существует несколько путей общения вышестоящего ПО с нашим драйвером. Одним из самых старых, простых и популярных способов является символьное устройство, character device.
Character device — это виртуальное устройство, которое может быть добавлено в каталог /dev, его можно будет открывать, что-то записывать, читать, выполнять вызовы ioctl для задания каких-либо параметров.

Хороший пример подобного устройства — драйвер последовательного порта с его /dev/ttySX

Регистрацию character device удобно вынести в отдельную функцию

int create_char_devs(struct my_driver_priv* drv);

Указатель на нашу приватную структуру необходим для последующей инициализации файлового объекта, так что при каждом пользовательском вызове open/read/write/ioctl/close мы будем иметь доступ к нашей приватной структуре и сможем выполнять операции чтения/записи в PCI устройство.

Вызывать create_char_devs() удобно в функции my_driver_probe(), после всех инициализаций и проверок.

В моём случае эта функция называется именно create_char_devs(), во множественном числе. Дело в том, что драйвер создает несколько одноименных (но с разными цифровыми индексами в конце имени) character device, по одному на канал платы ЛИР941, это позволяет удобно, независимо и одноврменно работать сразу с несколькими подключенными датчиками.

Создать символьное устройство довольно просто.

Определяемся с количеством устройств, выделяем память и инициализируем каждое устройство настроенной структурой file_operations. Эта структура содержит ссылки на наши функции файловых операций, которые будут вызываться ядром при работе с файлом устройства в пространстве пользователя.

Внутри ядра все /dev устройства идентифицируются с помощью пары идентификаторов

<major>:<minor>

Некоторые идентификаторы major являются зарезервированными и всегда назначаются определенным устройствам, остальные идентификаторы являются динамическими.
Значение major разделяют все устройства конкретного драйвера, отличаются они лишь идентификаторами minor.

При инициализации своего устройства можно задать значение major руками, ну лучше этого не делать, т. к. можно устроить конфликт. Самый лучший вариант — использовать макрос MAJOR().

Его применение будет показано в коде ниже.

В случае с minor значение обычно совпадает с порядковым номером устройства, при создании, начиная с нуля. Это позволяет узнать к какому именно устройству /dev/device-X обращаются из пространстрва ядра — достаточно посмотреть на minor доступный в обработчике файловых операций.

Идентификтаоры : отображаются утилитой ls с ключем -l
например если выполнить:

$ ls -l /dev/i2c-*
crw------- 1 root root 89, 0 янв.  30 21:59 /dev/i2c-0
crw------- 1 root root 89, 1 янв.  30 21:59 /dev/i2c-1
crw------- 1 root root 89, 2 янв.  30 21:59 /dev/i2c-2
crw------- 1 root root 89, 3 янв.  30 21:59 /dev/i2c-3
crw------- 1 root root 89, 4 янв.  30 21:59 /dev/i2c-4

Число 89 — это major идентификатор драйвера контроллера i2c шины, оно общее для всех каналов i2c, а 0,1,2,3,4 — minor идентификаторы.

Пример создания набора устройств.

#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/uaccess.h>
#include <linux/fs.h>

// создаем 4 устройства
#define MAX_DEV 4

// определение функций файловых операций
static int mydev_open(struct inode *inode, struct file *file);
static int mydev_release(struct inode *inode, struct file *file);
static long mydev_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
static ssize_t mydev_read(struct file *file, char __user *buf, size_t count, loff_t *offset);
static ssize_t mydev_write(struct file *file, const char __user *buf, size_t count, loff_t *offset);

// настраиваем структуру file_operations
static const struct file_operations mydev_fops = {
	.owner      = THIS_MODULE,
	.open       = mydev_open,
	.release    = mydev_release,
	.unlocked_ioctl = mydev_ioctl,
	.read       = mydev_read,
	.write       = mydev_write
};

// структура устройства, необходимая для инициализации
struct my_device_data {
	struct device* mydev;
	struct cdev cdev;
};

// в этой переменной хранится уникальный номер нашего символьного устройства
// номер создается с помощью макроса ядра и используется в операциях инициализации
// и уничтожения устройства, поэтому его необходимо объявлять глобально и статически 
static int dev_major = 0;

// структура класса устройства, необходимая для появления устройства в /sys
// это дает возможность взаимодействовать с udev
static struct class *mydevclass = NULL;

// каждое устройство инициализируется своим экземпляром структуры my_device_data, иначе возникнет путаница
// поэтому необходимо создать массив таких структур, размер массива определяется количеством устройств
static struct lir_device_data mydev_data[MAX_DEV];

int create_char_devs()
{
	int err, i;
	dev_t dev;

	// выделяем память под необходимое количество устройств
	err = alloc_chrdev_region(&dev, 0, MAX_DEV, "mydev");

	// создаем major идентификатор для нашей группы устройств
	dev_major = MAJOR(dev);

	// регистрируем sysfs класс под названием mydev
	mydevclass = class_create(THIS_MODULE, "mydev");

	// в цикле создаем все устройства по порядку
	for (i = 0; i < MAX_DEV; i++) {
		//инициализируем новое устройство с заданием структуры file_operations
		cdev_init(&mydev_data[i].cdev, &mydev_fops);

		//указываем владельца устройства - текущий модуль ядра
		mydev_data[i].cdev.owner = THIS_MODULE;

		// добавляем в ядро новое символьное устройство
		cdev_add(&mydev_data[i].cdev, MKDEV(dev_major, i), 1);

		// и наконец создаем файл устройства /dev/mydev-<i>
		// где вместо <i> будет порядковый номер устройства
		mydev_data[i].mydev = device_create(mydevclass, NULL, MKDEV(dev_major, i), NULL, "mydev-%d", i);
	}

	return 0;
}

Функция mydev_open() будет вызываться, если кто-то попробует открыть наше устройство в пространстве пользователя.

Очень удобно в этой функции инициализировать приватную структуру для открытого файла устройства. В ней можно сохранить значение minor для текущего открытого устройства
Также туда можно поместить указатель на какие-то более глобальные структуры, помогающие взаимодействовать с остальным драйвером, например, мы можем в этом месте сохранить указатель на my_driver_priv, с которым мы работали ранее. Указатель на эту структуру можно использовать в операциях ioctl/read/write для выполнения запросов к аппаратуре.

Мы можем определить такую структуру:

struct my_device_private {
	uint8_t chnum;
	struct my_driver_priv * drv;
};

Функция открытия

static int mydev_open(struct inode *inode, struct file *file)
{
	struct my_device_private* dev_priv;

	// получаем значение minor из текущего узла файловой системы
	unsigned int minor = iminor(inode);

	// выделяем память под структуру и инициализируем её поля
	dev_priv = kzalloc(sizeof(struct lir_device_private), GFP_KERNEL);

	//  drv_access — глобальный указатель на структуру  my_device_private, которая была
	// инициализирована ранее в коде, работающим с PCI
	dev_priv->drv = drv_access;
	dev_priv ->chnum = minor;

	// сохраняем указатель на структуру как приватные данные открытого файла
	// теперь эта структура будет доступна внутри всех операций, выполняемых над этим файлом
	file->private_data = dev_priv;

	// просто возвращаем 0, вызов open() завершается успешно
	return 0;
}

Операции чтения и записи являются довольно простыми, единственный «нюанс» — небезопаность (а то и невозможность) прямого доступа пользовательского приложения к памяти ядра и наоборот.
В связи с этим для получения данных, записиваемых с помощью функции write() необходимо использовать функцию ядра copy_from_user().

А при выполнении read() необходимо пользоваться copy_to_user().

Обе функции оснащены различными проверками и обеспечивают безопасное копирование данных между ядром и пользовательским пространством

static ssize_t mydev_read(struct file *file, char __user *buf, size_t count, loff_t *offset)
{
	// получаем доступ к приватной структуре, сохраненной в функции open()
	struct my_device_private* drv = file->private_data;
	uint32_t result;

	// выполняем какой-то запрос к оборудованию с помощью нашей функции  	
	// get_data_from_hardware, передав ей данные драйвера
	result = get_data_from_hardware(drv->drv, drv->chnum);

	// копируем результат в пользовательское пространство
	if (copy_to_user(buf, &data, count)) {
		return -EFAULT;
	}

	// возвращаем количество отданных байт
	return count;
}

static ssize_t mydev_write(struct file *file, const char __user *buf, size_t count, loff_t *offset)
{
	ssize_t count = 42;
	char data[count];

	if (copy_from_user(data, buf, count) != 0) {
		return -EFAULT;
	}

	// в массив data, размером 42 байта получили какие-то данные от пользователя 
	// и теперь можем безопасно с ним работать

	// возвращаем количество принятых байт
	return count;
}

Обработчик вызова ioctl() принимает в качестве аргументов собственно номер ioctl операции и какие-то переданные данные в качестве аргументов (если они необходимы).
Номера операций ioctl() определяются разработчиком драйвера. Это просто некие «волшебные» числа, скрывающиеся за читабельными define.

Об этих номерах должна знать пользовательская программа, поэтому удобно выносить их куда-то в виде отдельного заголовочного файла.

Пример обработчика ioctl

static long mydev_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
	struct my_device_private* drv = file->private_data;

	switch (cmd) {
		case MY_IOCTL_OP_1:
			do_hardware_op_1(drv->drv, drv->chnum);
			break;

		case MY_IOCTL_OP_2:
			do_hardware_op_2(drv->drv, drv->chnum);
			break;

		....

		default:
			return -EINVAL;
	};

	return 0;
}

Функция mydev_release() вызывается при закрыти файла-устройства.

В нашем случае достаточно лишь освободить память нашей приватной файловой структуры

static int mydev_release(struct inode *inode, struct file *file)
{
	struct my_device_private* priv = file->private_data;

	kfree(priv);

	priv = NULL;

	return 0;
}

В функции уничтожения символьного устройства необходимо удалить все созданные устройства, уничтожить sysfs class и освободить память.

int destroy_char_devs(void)
{
	int i;

	for (i = 0; i < MAX_DEV; i++) {
		device_destroy(mydevclass, MKDEV(dev_major, i));
	}

	class_unregister(mydevclass);
	class_destroy(mydevclass);
	unregister_chrdev_region(MKDEV(dev_major, 0), MINORMASK);

	return 0;
}

Эту функцию следует вызывать в __exit методе модуля ядра, так что бы символьное устройство уничтожалось при выгрузке.

Вся остальная работа сводится к налаживанию взаимодействия между символьным устройством и фактической аппаратурой, а так же написанию различного вспомогательного кода.

Полный исходный код драйвера платы ЛИР941 можно посмотреть на Github.

А тут лежит простая тестовая утилита, работающая с этим драйвером.

Тестирование драйвера на настоящем железе :)


Что почитать:
wiki.osdev.org/PCI
www.tldp.org/LDP/tlk/dd/pci.html
lwn.net/Kernel/LDD3

Спасибо за внимание!
Надеюсь этот материал будет полезен тем, кто решить написать свой драйвер для чего-нибудь.