🐧 Linuxデバイスドライバプログラミングを読んだ感想

読んだ本

著者: 平田豊

Kernel Maintainers Summit 2025でLinux kernelへのRust導入について、"experimental" な扱いを終えてよいのではという提案がありました。

Ojeda returned to his initial question: can the "experimental" status be ended? Torvalds said that, after nearly five years, the time had come.

The state of the kernel Rust experiment

その後、Rust subsystemのmaintainerであられる Miguel Ojeda氏による[PATCH] rust: conclude the Rust experimentで

But the experiment is done, i.e. Rust is here to stay.

として、Documentation/rust/index.rstから、 The Rust experiment sectionを削除する変更が提案されました。

このようなRust for Linuxの取り組みを機にLinux kernelについて調べてみたいと思うようになりました。 Rustのユースケースとして、driverをrustで書く取り組みがあることを知り、kernel driverの解説を探している中で本書を見つけ、読んでみておもしろかったので、感想を書きます。

本書が対象としているkernel versionは2.6.23.1ですが、記事中のコードは6.18.6で動かしました。

第1章 Linuxデバイスドライバの概要

Linux kernelの生い立ちや、コミュニティについて。また、デバイスドライバのkernel内における位置づけについて。

第2章 Linuxのライセンス

GPLライセンスやデバイスドライバのライセンスについて。 kernel moduleのMODULE_LICENSE macroの説明があります。過去のGPL違反の事例等も紹介されていました。

第3章デバイスドライバ開発の準備

実際にドライバを書くための環境構築方法について。自分はNixOSを使っているので以下のようなNixOS moduleを準備しました。

{ pkgs, config, ... }:
let
  kernel = config.boot.kernelPackages.kernel;
in
{
  environment.systemPackages = with pkgs; [
    kernel.dev
  ];
  environment.variables.KDIR = "${kernel.dev}/lib/modules/${kernel.modDirVersion}/build";
}

こうすると実行中のkernel versionに対応した、module build用のfileが揃うので、kernel自体をbuildせずに済みます。

cd $env.KDIR

pwd
/nix/store/cbc470bffdhc9wg1bgk54i6a3s5a1ygq-linux-6.18.6-dev/lib/modules/6.18.6/build

uname | get kernel-release
6.18.6

ls
 # |      name      |  type   |  size  |   modified
---+----------------+---------+--------+--------------
 0 | Makefile       | file    |  350 B | 56 years ago
 1 | Module.symvers | file    | 2.3 MB | 56 years ago
 2 | arch           | dir     | 4.0 kB | 56 years ago
 3 | include        | dir     | 4.0 kB | 56 years ago
 4 | kernel         | dir     | 4.0 kB | 56 years ago
 5 | rust           | dir     | 4.0 kB | 56 years ago
 6 | scripts        | dir     | 4.0 kB | 56 years ago
 7 | source         | symlink |    9 B | 56 years ago
 8 | tools          | dir     | 4.0 kB | 56 years ago

第4章デバイスドライバ開発の第一歩

本章からいよいよドライバ開発がはじまります。ログ出力だけを行うドライバ、hello

#include <linux/module.h>
#include <linux/kernel.h>

static int __init hello_init(void)
{
  pr_info("hello: loaded\n");
  return 0;
}

static void __exit hello_exit(void)
{
  pr_info("hello: unloaded\n");
}

module_init(hello_init);
module_exit(hello_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("ymgyt");
MODULE_DESCRIPTION("hello module");

Makefile

obj-m := hello.o
PWD := $(shell pwd)

modules:
	$(MAKE) -C $(KDIR) M=$(PWD) modules

clean:
	$(MAKE) -C $(KDIR) M=$(PWD) clean

make modulesでbuildしてみると

make modules
/nix/store/mkm3my2067305hdh7rzmi10npwr7y17f-gnumake-4.4.1/bin/make -C /nix/store/cbc470bffdhc9wg1bgk54i6a3s5a1ygq-linux-6.18.6-dev/lib/modules/6.18.6/build M=/home/ymgyt/rs/drivers/hello modules
make[1]: Entering directory '/nix/store/cbc470bffdhc9wg1bgk54i6a3s5a1ygq-linux-6.18.6-dev/lib/modules/6.18.6/build'
make[2]: Entering directory '/home/ymgyt/rs/drivers/hello'
  CC [M]  hello.o
  MODPOST Module.symvers
  CC [M]  hello.mod.o
  CC [M]  .module-common.o
  LD [M]  hello.ko
  BTF [M] hello.ko
Skipping BTF generation for hello.ko due to unavailability of vmlinux
make[2]: Leaving directory '/home/ymgyt/rs/drivers/hello'
make[1]: Leaving directory '/nix/store/cbc470bffdhc9wg1bgk54i6a3s5a1ygq-linux-6.18.6-dev/lib/modules/6.18.6/build'

ls
 # |      name      | type |   size   |    modified
---+----------------+------+----------+----------------
 0 | Makefile       | file |    262 B | 3 weeks ago
 1 | Module.symvers | file |      0 B | 19 seconds ago
 2 | hello.c        | file |    342 B | 3 weeks ago
 3 | hello.ko       | file | 179.6 kB | 18 seconds ago
 4 | hello.mod      | file |     10 B | 19 seconds ago
 5 | hello.mod.c    | file |    373 B | 19 seconds ago
 6 | hello.mod.o    | file | 106.5 kB | 18 seconds ago
 7 | hello.o        | file |  14.0 kB | 19 seconds ago
 8 | modules.order  | file |      8 B | 19 seconds ago

file hello.ko
hello.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=e328d799fd4e7da7538d9b81b324aac66b6ca788, with debug_info, not stripped

無事、hello.ko ELFが生成できました。

modinfoしてみると、MODULE_ マクロの内容が反映していることが確かめられます

modinfo hello.ko
filename:       /home/ymgyt/rs/drivers/hello/hello.ko
description:    hello module
author:         ymgyt
license:        GPL
depends:
name:           hello
retpoline:      Y
vermagic:       6.18.6 SMP preempt mod_unload

ちなみにrustだと、kernel crateにdriverの種別ごとにmacroが用意してあり、以下のようにしてmoduleのmetadataを定義できます。

kernel::module_usb_driver! {
    type: SampleDriver,
    name: "rust_driver_usb",
    authors: ["Daniel Almeida"],
    description: "Rust USB driver sample",
    license: "GPL v2",
}

作成したドライバをロードするには、insmodを実行します。

sudo insmod hello.ko

sudo dmesg | tail -n 10 | rg hello
[883897.532805] hello: loaded

無事ログを確認できました。

ロードしたドライバをアンロードするにはrmmodを使います。

sudo rmmod hello

sudo dmesg | tail -n 10 | rg hello
[883897.532805] hello: loaded
[883981.712000] hello: unloaded

ということでドライバのハローワールドができました。次に、関数を定義しているheaderにjumpできると便利なのでcode jumpの設定を行います。自分はclangd lang serverを利用しているので

bear --append --output -- make -C $KDIR M=$(pwd) HOSTCC=cc modules

を実行して、compile_commands.jsonを生成しました。ちなみにRustの場合は、kernelのmake targetにrust-analyzerがあります。

make help | rg rust-analyzer
  rust-analyzer   - Generate rust-project.json rust-analyzer support file

次にエントリーポイントについての解説があります。 insmod時に呼ばれる、module_init, rmmod時のmodule_exitだけでなく、systemcall(open, close, ioctl, epoll, ...)時のhandler, 割込み,timerからデバイスの処理が呼ばれます。

第6章ドライバプログラミングの実際

本章では、ioctlの実装方法の解説があります。 ioctlでは、ユーザスペースのプログラムとデータ構造を共有する必要があるので、まずheader fileを定義します。

devone_ioctl.h

#ifndef _DEVONE_IOCTL_H
#define _DEVONE_IOCTL_H

#include <linux/ioctl.h>

struct ioctl_cmd {
  unsigned int reg;
  unsigned int offset;
  unsigned int val;
};

#define IOC_MAGIC 'd'

enum {
  IOCTL_VALSET = _IOW(IOC_MAGIC, 1, struct ioctl_cmd),
  IOCTL_VALGET = _IOR(IOC_MAGIC, 2, struct ioctl_cmd),
};

#endif

ioctl handler

#include "devone_ioctl.h"

static long int devone_ioctl(struct file *filep, unsigned int cmd,
                             unsigned long arg)
{
  struct devone_data *dev = filep->private_data;
  struct ioctl_cmd data;
  struct ioctl_cmd __user *uarg = (struct ioctl_cmd __user *)arg;

  if (_IOC_TYPE(cmd) != IOC_MAGIC)
    return -ENOTTY;
  if (_IOC_SIZE(cmd) != sizeof(struct ioctl_cmd))
    return -EINVAL;

  memset(&data, 0, sizeof(data));

  switch (cmd) {
  /* userland write */
  case IOCTL_VALSET:
    if (!capable(CAP_SYS_ADMIN)) {
      return -EPERM;
    }
    if (copy_from_user(&data, uarg, sizeof(data))) {
      return -EFAULT;
    }

    write_lock(&dev->lock);
    dev->val = data.val;
    write_unlock(&dev->lock);
    break;

  /* userland read */
  case IOCTL_VALGET:
    read_lock(&dev->lock);
    data.val = dev->val;
    read_unlock(&dev->lock);

    if (copy_to_user(uarg, &data, sizeof(data))) {
      return -EFAULT;
    }
    break;

  default:
    return -ENOTTY;
    break;
  }

  return 0;
}

せっかくのioctlですがやっていることは、read/writeです。個人的には、

    if (!capable(CAP_SYS_ADMIN)) {
      return -EPERM;
    }

のように、capabilityのチェックがドライバのifで実装できるということを知れ、うれしかったです。

このioctlをプログラムから読んでみます。まず、devone_ioctl.hをRustから読めるように、bindingsでdevone_ioctl_bindings.rsを生成します。

その上で、ユーザ側から、libc::ioctl()を呼び出します。

use std::{fs::OpenOptions, io, os::fd::AsRawFd as _};
use tracing::info;
use uapp::bindings::devone_ioctl::{IOCTL_VALGET, IOCTL_VALSET, ioctl_cmd};

fn ioctl_valset(fd: i32, val: u32) -> io::Result<()> {
    let mut data = ioctl_cmd {
        reg: 0,
        offset: 0,
        val,
    };

    let rc = unsafe { libc::ioctl(fd, IOCTL_VALSET as libc::c_ulong, &mut data) };
    if rc < 0 {
        return Err(io::Error::last_os_error());
    }
    Ok(())
}

fn ioctl_valget(fd: i32) -> io::Result<u32> {
    let mut data = ioctl_cmd {
        reg: 0,
        offset: 0,
        val: 0,
    };

    let rc = unsafe { libc::ioctl(fd, IOCTL_VALGET as libc::c_ulong, &mut data) };
    if rc < 0 {
        return Err(io::Error::last_os_error());
    }
    Ok(data.val)
}

fn main() -> anyhow::Result<()> {
    tracing_subscriber::fmt::init();

    let f = OpenOptions::new()
        .read(true)
        .write(true)
        .open("/dev/devone0")?;
    let fd = f.as_raw_fd();

    let got = ioctl_valget(fd)?;
    info!("IOCTL_VALGET: got val=0x{got:02x}");

    let set_val = 2_u32;
    info!("IOCTL_VALSET: setting val=0x{set_val:02x}");
    ioctl_valset(fd, set_val)?;

    let got = ioctl_valget(fd)?;
    info!("IOCTL_VALGET: got val=0x{got:02x}");

    Ok(())
}

これを実行すると

2026-02-08T09:12:35.854053Z  INFO devone_ioctl: IOCTL_VALGET: got val=0xff
2026-02-08T09:12:35.854128Z  INFO devone_ioctl: IOCTL_VALSET: setting val=0x02
2026-02-08T09:12:35.854159Z  INFO devone_ioctl: IOCTL_VALGET: got val=0x02

無事ioctlできました。

次に、poll()です。device側は常にread/write可能な実装です

static unsigned int devone_poll(struct file *filp, poll_table *wait)
{
  struct devone_data *dev = filp->private_data;

  if (dev == NULL)
    return -EBADFD;

  return POLLIN | POLLRDNORM | POLLOUT | POLLWRNORM;
}

これを以下のようにして呼び出しました。

use std::{fs::OpenOptions, io, mem, os::fd::AsRawFd as _};
use anyhow::bail;
use tracing::info;

fn main() -> anyhow::Result<()> {
    tracing_subscriber::fmt::init();

    let f = OpenOptions::new()
        .read(true)
        .write(true)
        .open("/dev/devone0")?;
    let fd = f.as_raw_fd();

    let epfd = unsafe { libc::epoll_create1(0) };
    if epfd < 0 {
        bail!(io::Error::last_os_error());
    }

    let mut ev: libc::epoll_event = unsafe { mem::zeroed() };
    ev.events = libc::EPOLLIN as u32;
    ev.u64 = fd as u64;

    let rc = unsafe { libc::epoll_ctl(epfd, libc::EPOLL_CTL_ADD, fd, &mut ev as *mut _) };
    if rc < 0 {
        let err = io::Error::last_os_error();
        unsafe { libc::close(epfd) };
        bail!(err)
    }

    let mut events: [libc::epoll_event; 8] = unsafe { mem::zeroed() };
    let n = unsafe { libc::epoll_wait(epfd, events.as_mut_ptr(), events.len() as i32, 0) };
    if n < 0 {
        let err = io::Error::last_os_error();
        unsafe { libc::close(epfd) };
        bail!(err)
    }

    info!("epoll_wait returned n={n}");
    #[expect(clippy::needless_range_loop)]
    for i in 0..n as usize {
        let ev = &events[i];
        let ready = ev.events;
        let token = ev.u64;
        info!("event[{i}]: token={token} events=0x{ready:x}");
        if ready & (libc::EPOLLIN as u32) != 0 {
            info!("  => EPOLLIN (readable)");
        }
    }

    unsafe { libc::close(epfd) };
    Ok(())
}

epollの詳細は割愛しますが、これを実行すると無事readableであることを伝えられました

2026-02-08T09:24:22.709203Z  INFO devone_epoll: epoll_wait returned n=1
2026-02-08T09:24:22.709280Z  INFO devone_epoll: event[0]: token=123 events=0x1
2026-02-08T09:24:22.709301Z  INFO devone_epoll:   => EPOLLIN (readable)

この他にも、proc_fs, seq_file, sleepの解説があります。最後にドライバから直接、insmodを実行したユーザのターミナルにメッセージを出力する方法が紹介されていました。

static void pr_tty_console(char *msg)
{
  struct tty_struct *tty;

  tty = current -> signal -> tty;
  if (tty != NULL) {
    (tty->driver->ops->write)(tty, msg, strlen(msg));
    (tty->driver->ops->write)(tty, "\r\n", 2);
  }
}

static int __init devone_init(void) {
  /* ... */
  pr_tty_console("devone loaded(from tty console)\n");
  /* ... */
}

おそらく非常に危険な処理だと思いますが、実行してみると

sudo insmod ./devone.ko
devone loaded(from tty console)

と、表示に成功しました。タイマーに関するAPIは現在では変更されており、具体的な変更については、カーネルモジュール作成で学ぶLinuxカーネル開発の基礎知識：第3版がわかりやすかったです。

第7章ハードウェア制御

本章ではドライバから実際にデバイスを制御するために、I/OマップドI/O、メモリマップドI/Oについての解説があります。メモリマップドI/Oの場合、デバイスのレジスタに対応した物理アドレスを指定して命令を実行する必要がありますが、ドライバは仮想アドレスで動いているので、ioremap()が必要となります。

また、メモリアクセスに副作用や依存関係が暗黙的に生じるので、メモリバリアやvolatileの話がでてきます。

asm()の解説もあり、Rustのasm!() macroはここから来たのかと知れました。

第8章メモリ

カーネルのメモリ管理について。具体的には、kmalloc(),kfree()といったAPI、スラブアロケータ、バディシステム、カーネルスタックについての言及があります。

DMAについては、実際のドライバ(drivers/net/e100.c)での利用例や、キャッシュコヒーレンス問題の解説があります。

2.6時点での時間管理について。 jiffiesやdo_gettimeofday(), timevalがでてきます。 2038年問題や497日問題にもふれられています。ドライバでは、デバイスに対してDMAの開始を指示し、通常では完了時の割込みで処理をします。しかしこれは成功したケースで、デバイス側の不具合で割込みがあがってこないかもしれないので、必ずタイムアウト処理をいれる必要があります。

今回は以下のようにして、read時のレイテンシーをモックするためにタイムアウト処理をいれてみました。

struct devone_data {
  /* ... */
  
  /* mock read latency */
  wait_queue_head_t read_wq;
  atomic_t read_ready;
  struct timer_list read_timer;
};

static int devone_open(struct inode *inode, struct file *file) {
  struct devone_data *p;

  p = kmalloc(sizeof(struct devone_data), GFP_KERNEL);
  if (p == NULL) {
    printk("%s: No memory\n", __func__);
    return -ENOMEM;
  }

  p->val = 0xff;
  rwlock_init(&p->lock);

  /* prepare mock read latency */
  init_waitqueue_head(&p->read_wq);
  atomic_set(&p->read_ready, 1);
  timer_setup(&p->read_timer, devone_read_timer_cb, 0);

  file->private_data = p;
  return 0;
}

open時に、timer_setup()でtimer_listにcallback関数、devone_read_timer_cbを登録します。

static void devone_read_timer_cb(struct timer_list *t)
{
  struct devone_data *p = container_of(t, struct devone_data, read_timer);
  atomic_set(&p->read_ready, 1);
  pr_info("%s: Wake up!\n", __func__);
  wake_up(&p->read_wq);
}

devone_read_timer_cbはflag変数で完了を記録して、wake_up()を呼びます。

#define DEVONE_READ_DELAY_MS 1000

static ssize_t devone_read(struct file *filep, char __user *buf, size_t count,
                           loff_t *f_pos) {
  struct devone_data *p = filep->private_data;
  int i;
  unsigned char val;
  int retval;
  long wr;

  atomic_set(&p->read_ready,0);
  mod_timer(&p->read_timer, jiffies + msecs_to_jiffies(DEVONE_READ_DELAY_MS));
  
  wr = wait_event_interruptible_timeout(
    p->read_wq,
    atomic_read(&p->read_ready) != 0,
    msecs_to_jiffies(DEVONE_READ_DELAY_MS + 1000)
  );
  if (wr == 0)
    return -ETIMEDOUT;
  if (wr < 0)
    return wr;

  /* read処理 */
}

read時に、mod_timer()でtimeout処理を有効化して、wait_event_interruptible_timeout()でレイテンシをモックします。

#define DEVONE_READ_DELAY_MS 5000 で5秒を指定してみると無事、モックできました

time hexyl -n 1 /dev/devone0 out> /dev/null
0.00user 0.00system 0:05.13elapsed 0%CPU (0avgtext+0avgdata 2676maxresident)k
0inputs+0outputs (0major+130minor)pagefaults 0swaps

また、timerが発火する前にcloseでリソースが開放される場合があるので、timer_delete_sync()を呼び出しておく必要があります。

第10章同期と排他

共有リソースにアクセスする場合に、ロックをとったり、アトミック操作を行うのは、一般的なアプリケーションと同じです。ドライバで異なるのは、割込みコンテキストではsleepできないので、spin_lock系のAPIを用いる必要があるのと、割込みの有効/無効を意識する必要があるということがわかりました。 kthreadの説明もありました。動かすだけなら以下のようになりました。

#include <linux/module.h>
#include <linux/delay.h>
#include <linux/kthread.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("ymgyt");
MODULE_DESCRIPTION("kthread sample");

#define DRIVER_NAME "kthread"

static struct task_struct *kmain_task = NULL;

static int sample_thread(void *num)
{
  while (!kthread_should_stop()) {
    msleep_interruptible(3000);
  }
  return 0;
}

static int __init mykthread_init(void) {
  kmain_task = kthread_create(sample_thread, NULL, "sample mykthread");
  if (IS_ERR(kmain_task)) {
    return PTR_ERR(kmain_task);
  }
  wake_up_process(kmain_task);

  return 0;
}

static void __exit mykthread_exit(void) {
  if (kmain_task) {
    kthread_stop(kmain_task);
  }
}

module_init(mykthread_init);
module_exit(mykthread_exit);

sudo insmod ./"kthread".ko
ps | where name =~ "sample mykthread"
 # |   pid   | ppid |       name       |  status  | cpu  | mem | virtual
---+---------+------+------------------+----------+------+-----+---------
 0 | 1216364 |    2 | sample mykthread | Sleeping | 0.00 | 0 B |     0 B

第11章割込み

ドライバといえば割込みということで割込みの概念について説明されます。また実際の割込み処理として、drivers/net/8139too.cが取り上げられていました。以下は、drivers/net/ethernet/realtek/8139too.cのrtl8139_interrupt()処理です。本書のこれまでの知識で雰囲気ですが読めるようになっています。

/* The interrupt handler does all of the Rx thread work and cleans up
   after the Tx thread. */
static irqreturn_t rtl8139_interrupt (int irq, void *dev_instance)
{
	struct net_device *dev = (struct net_device *) dev_instance;
	struct rtl8139_private *tp = netdev_priv(dev);
	void __iomem *ioaddr = tp->mmio_addr;
	u16 status, ackstat;
	int link_changed = 0; /* avoid bogus "uninit" warning */
	int handled = 0;

引数から処理用のprivateなstructを取り出し、メモリマップドI/O用アドレスを保持します。

	spin_lock (&tp->lock);
	status = RTL_R16 (IntrStatus);

レジスタにアクセスするにあたって、lockを取得します。割込み処理内なので、irqsave等は不要と思われます。

#define RTL_R16(reg)		ioread16 (ioaddr + (reg))

/* Symbolic offsets to registers. */
enum RTL8139_registers {
  /* ... */
	IntrStatus	= 0x3E,

RTL_R16はレジスタをreadするマクロで、statusにおそらく割込み関連の情報が入っていると思われます。 ioaddrは事前にstackに確保している前提のようです。

	/* shared irq? */
	if (unlikely((status & rtl8139_intr_mask) == 0))
		goto out;

	handled = 1;

irq(割込みハンドラ)は、共有されうるので、処理が不要ならreturn

	/* h/w no longer present (hotplug?) or major error, bail */
	if (unlikely(status == 0xFFFF))
		goto out;

	/* close possible race's with dev_close */
	if (unlikely(!netif_running(dev))) {
		RTL_W16 (IntrMask, 0);
		goto out;
	}

処理を継続できるかの確認と思われます。

	ackstat = status & ~(RxAckBits | TxErr);
	if (ackstat)
		RTL_W16 (IntrStatus, ackstat);

割込み要因のクリア。RxAckBitsとTxErrはこのあとの処理で参照するのでそれ以外のACK処理でしょうか。

	/* Receive packets are processed by poll routine.
	   If not running start it now. */
	if (status & RxAckBits){
		if (napi_schedule_prep(&tp->napi)) {
			RTL_W16_F (IntrMask, rtl8139_norx_intr_mask);
			__napi_schedule(&tp->napi);
		}
	}

受信処理は、NAPI という仕組みを利用しているらしく、処理を移譲

	/* Check uncommon events with one test. */
	if (unlikely(status & (PCIErr | PCSTimeout | RxUnderrun | RxErr)))
		rtl8139_weird_interrupt (dev, tp, ioaddr,
					 status, link_changed);

Uncommonな割込みを処理

	if (status & (TxOK | TxErr)) {
		rtl8139_tx_interrupt (dev, tp, ioaddr);
		if (status & TxErr)
			RTL_W16 (IntrStatus, TxErr);
	}
 out:
	spin_unlock (&tp->lock);

	netdev_dbg(dev, "exiting interrupt, intr_status=%#4.4x\n",
		   RTL_R16(IntrStatus));
	return IRQ_RETVAL(handled);
}

送信が完了していた場合の後処理とlock開放。ということで雰囲気ですがどんなことをしているのかわかりました。

また、割込み処理では最低限の処理を行い、残りの処理を別の機構にまかせる仕組みとして、taskletとworkqueueの紹介もありました。割込み処理については、新Linuxカーネル解読室 - ソフト割り込み処理や、新Linuxカーネル解読室 - Workqueueの解説も非常にありがたかったです。

第12章 PCI

PCIデバイスとドライバの対応関係の調べ方から始まります。試しに、Wi-Fiのドライバを調べてみると

# -k   Show kernel drivers handling each device and also kernel modules capable of handling it.
# -nn  Show PCI vendor and device codes as both numbers and names.
lspci -knn | rg -i 'wireless network' -A 3
pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
01:00.0 Network controller [0280]: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:0616] (rev 02)
        Subsystem: MEDIATEK Corp. Device [14c3:223c]
        Kernel driver in use: mt7921e
        Kernel modules: mt7921e

Wireless Network Adapter [14c3:0616] からVendorIDが14c3 でdevice codeが0616とわかりました。また、moduleはmt7921eが利用されているので kernelの drivers/net/wireless/mediatek/mt76/mt7921/Makefileをみてみると

# ...
obj-$(CONFIG_MT7921E) += mt7921e.o
# ...
mt7921e-y := pci.o pci_mac.o pci_mcu.o

とmt7921e モジュールが定義されており、ドライバ側で対応するデバイスを宣言するpci_device_id[]をみると

rg 'static const struct pci_device_id mt7921_pci_device_table' -A 15 drivers/net/wireless/mediatek/mt76/mt7921/pci.c
16:static const struct pci_device_id mt7921_pci_device_table[] = {
17-     { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x7961),
18-             .driver_data = (kernel_ulong_t)MT7921_FIRMWARE_WM },
19-     { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x7922),
20-             .driver_data = (kernel_ulong_t)MT7922_FIRMWARE_WM },
21-     { PCI_DEVICE(PCI_VENDOR_ID_ITTIM, 0x7922),
22-             .driver_data = (kernel_ulong_t)MT7922_FIRMWARE_WM },
23-     { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0608),
24-             .driver_data = (kernel_ulong_t)MT7921_FIRMWARE_WM },
25-     { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0616),
26-             .driver_data = (kernel_ulong_t)MT7922_FIRMWARE_WM },
27-     { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x7920),
28-             .driver_data = (kernel_ulong_t)MT7920_FIRMWARE_WM },
29-     { },
30-};
31-

と定義されており、include/linux/pci_ids.hに

#define PCI_VENDOR_ID_MEDIATEK		0x14c3

が定義されています。また、pci_device_idはinclude/linux/mod_devicetable.hに以下のように定義されています。

struct pci_device_id {
	__u32 vendor, device;		/* Vendor and device ID or PCI_ANY_ID*/
	__u32 subvendor, subdevice;	/* Subsystem ID's or PCI_ANY_ID */
	__u32 class, class_mask;	/* (class,subclass,prog-if) triplet */
	kernel_ulong_t driver_data;	/* Data private to the driver */
	__u32 override_only;
};

ここから

25-     { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0616),
26-             .driver_data = (kernel_ulong_t)MT7922_FIRMWARE_WM },

のエントリーがlspciのWireless Network Adapter [14c3:0616]に対応していそうなことがわかりました。 (本書のおかげでドライバのコードちょっと見てみようという気持ちになれたのがうれしいです。)

このあと、MMIO, I/Oポート、PCIコンフィグレーション空間の詳しい解説が続きます。

PCIドライバの具体例として、8139too.cの解説があります。 PCIドライバの基本的な処理として、デバイスのレジスタにアクセスするために、PCIコンフィグレーション空間からBAR情報を取得して、ioremap()(BARは物理アドレスなのでそのままでは仮想アドレスとしてアクセスできないから)するとこれまでの説明でわかりました。そこで、8139too.cの実装をみてみると

drivers/net/ethernet/realtek/8139too.c

static struct net_device *rtl8139_init_board(struct pci_dev *pdev)
{
	struct device *d = &pdev->dev;
	void __iomem *ioaddr;
	struct net_device *dev;
	struct rtl8139_private *tp;
	unsigned int i, bar;

  /* omitted... */

	ioaddr = pci_iomap(pdev, bar, 0);
	if (!ioaddr) {
    /* omitted... */
		rc = -ENODEV;
		goto err_out;
	}
	tp->regs_len = io_len;
	tp->mmio_addr = ioaddr;

とpci_iomap()を利用しており、drivers/pci/iomap.cをみてみると

void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
{
	return pci_iomap_range(dev, bar, 0, maxlen);
}
EXPORT_SYMBOL(pci_iomap);

void __iomem *pci_iomap_range(struct pci_dev *dev,
			      int bar,
			      unsigned long offset,
			      unsigned long maxlen)
{
	resource_size_t start, len;
	unsigned long flags;

	if (!pci_bar_index_is_valid(bar))
		return NULL;

	start = pci_resource_start(dev, bar);
	len = pci_resource_len(dev, bar);
	flags = pci_resource_flags(dev, bar);

	if (len <= offset || !start)
		return NULL;

	len -= offset;
	start += offset;
	if (maxlen && len > maxlen)
		len = maxlen;
	if (flags & IORESOURCE_IO)
		return __pci_ioport_map(dev, start, len);
	if (flags & IORESOURCE_MEM)
		return ioremap(start, len);
	/* What? */
	return NULL;
}
EXPORT_SYMBOL(pci_iomap_range);

とpci_resource_{start,len}でBARを取得し、MMIO,I/Oポートを判定して、ioremap()を実行していました。

ここまでは、PCIの話でしたが、PCI Expressも説明されておりどういった拡張があったのかの解説があります。

🐧 Linuxデバイスドライバプログラミングを読んだ感想

読んだ本

第1章 Linuxデバイスドライバの概要

第2章 Linuxのライセンス

第3章デバイスドライバ開発の準備

第4章デバイスドライバ開発の第一歩

第5章ドライバプログラミングの基礎知識

第6章ドライバプログラミングの実際

第7章ハードウェア制御

第8章メモリ

第9章タイマ

第10章同期と排他

第11章割込み

第12章 PCI

第13章シリアルバス

第14章 ACPI

第15章 IPMI

第16章テストとデバッグ

第17章ドライバ設計と実装の実際

まとめ