4. 上半部与下半部机制：上半部(硬中断)与下半部(Tasklet/Workqueue)的分工

中断处理的核心矛盾在于：响应速度与处理工作量之间的冲突。硬件中断发生时，处理器必须尽快响应，否则可能导致数据丢失或硬件超时；但中断处理程序往往需要完成大量工作，如数据拷贝、协议解析、设备状态查询等。若将所有工作都放在中断上下文中完成，会长时间关闭本地中断，导致系统实时性急剧下降。

Linux 内核通过将中断处理拆分为上半部（Top Half）和下半部（Bottom Half）来解决这一矛盾。上半部在硬中断上下文中执行，要求极短且不可睡眠；下半部在稍后的安全时机执行，允许延迟、可睡眠（取决于具体机制），从而在响应速度与处理能力之间取得平衡。

4.1 上半部（硬中断上下文）

上半部即注册到 request_irq() 或 request_threaded_irq() 的 handler 函数，它在硬件中断触发时立即执行，运行在硬中断上下文中。其核心约束如下：

4.2 下半部机制演进与选择

Linux 内核提供了多种下半部实现机制，从早期的 BH（Bottom Half）到软中断（Softirq）、Tasklet，再到 Workqueue。当前主流驱动开发中，Tasklet 和 Workqueue 是最常用的两种选择。

4.3 Tasklet 机制详解

Tasklet 基于 Softirq 实现，是驱动开发中最常用的下半部机制之一。其核心数据结构为 struct tasklet_struct：

struct tasklet_struct {
    struct tasklet_struct *next;
    unsigned long state;        /* TASKLET_STATE_SCHED / TASKLET_STATE_RUN */
    atomic_t count;             /* 0 表示激活，非 0 表示禁用 */
    void (*func)(unsigned long data);
    unsigned long data;
};

Tasklet 生命周期与使用步骤：

1. 声明与初始化：使用 DECLARE_TASKLET(name, func, data) 静态声明，或 tasklet_init() 动态初始化。
2. 调度：在上半部中调用 tasklet_schedule(&my_tasklet)，将 Tasklet 挂入当前 CPU 的待执行队列。
3. 执行：在 do_softirq() 中被调用，同一 Tasklet 在同一时刻最多在一个 CPU 上执行。
4. 禁用/启用：tasklet_disable() / tasklet_enable() 用于同步控制。
5. 销毁：tasklet_kill() 等待 Tasklet 执行完毕并移除。

4.4 Workqueue 机制详解

Workqueue 将下半部工作交给内核工作线程（kworker）在进程上下文中执行。对于需要睡眠、执行文件操作、使用信号量或进行大块内存分配的场景，Workqueue 是唯一选择。

Workqueue 核心 API：

4.5 上半部与下半部协作流程

下图展示了从硬件中断触发到下半部执行的完整协作流程：

4.6 实战代码模板：Tasklet 与 Workqueue 对比

以下代码展示了同一设备驱动中，分别使用 Tasklet 和 Workqueue 实现下半部的典型模式：

/* ========== Tasklet 版本 ========== */
static struct tasklet_struct my_tasklet;

/* 下半部处理函数（软中断上下文，不可睡眠） */
static void my_tasklet_handler(unsigned long data)
{
    struct my_device *dev = (struct my_device *)data;
    /* 快速处理：读取 FIFO、更新统计、唤醒等待队列 */
    spin_lock(&dev->lock);
    dev->rx_count += dev->fifo_level;
    spin_unlock(&dev->lock);
    wake_up_interruptible(&dev->wq);
}

/* 上半部 */
static irqreturn_t my_irq_handler(int irq, void *dev_id)
{
    struct my_device *dev = (struct my_device *)dev_id;
    /* 清除硬件中断标志 */
    writel(0, dev->regs + INT_CLR);
    /* 调度 Tasklet */
    tasklet_schedule(&my_tasklet);
    return IRQ_HANDLED;
}

/* 初始化 */
static int my_probe(struct platform_device *pdev)
{
    /* ... 分配设备结构、映射寄存器 ... */
    tasklet_init(&my_tasklet, my_tasklet_handler, (unsigned long)dev);
    return request_irq(dev->irq, my_irq_handler, IRQF_SHARED, "mydev", dev);
}

/* ========== Workqueue 版本 ========== */
static struct work_struct my_work;

/* 下半部处理函数（进程上下文，可睡眠） */
static void my_work_handler(struct work_struct *work)
{
    struct my_device *dev = container_of(work, struct my_device, work);
    /* 可睡眠操作：拷贝数据到用户空间、调用 USB 核心 API */
    struct my_data *data = kmalloc(sizeof(*data), GFP_KERNEL);
    if (data) {
        /* 处理数据 */
        kfree(data);
    }
}

/* 上半部 */
static irqreturn_t my_irq_handler_threaded(int irq, void *dev_id)
{
    struct my_device *dev = (struct my_device *)dev_id;
    writel(0, dev->regs + INT_CLR);
    schedule_work(&my_work);
    return IRQ_HANDLED;
}

/* 初始化 */
static int my_probe(struct platform_device *pdev)
{
    /* ... */
    INIT_WORK(&dev->work, my_work_handler);
    return request_irq(dev->irq, my_irq_handler_threaded,
                       IRQF_SHARED, "mydev", dev);
}

4.7 上半部与下半部的同步考量

上半部与下半部之间、下半部与其他上下文之间的数据共享必须谨慎处理同步问题：

4.8 下半部机制性能对比

下表从延迟、吞吐量和资源消耗三个维度对比 Tasklet 与 Workqueue：