Hey there! Let's walk through the best approach for your RISC-V FPGA IP driver development—since you're dealing with custom hardware with interrupt and data registers, here's what you need to know:

For your custom FPGA IP running on RISC-V Linux, the ideal combination is:

• Platform Driver Framework: This is perfect for non-standard, bus-independent hardware like your FPGA IP. It seamlessly integrates with device tree (the standard way to describe RISC-V hardware) to discover your IP, fetch resources (register addresses, interrupt numbers), and manage the device lifecycle (probe/remove).
• Character Device Driver: This provides the user-space interface your CPU/other processes will use to interact with the IP. You'll create a /dev node that allows userspace programs to open, read, write, and send control commands to your hardware.

Break down your driver development into these core areas, with corresponding APIs:

1. Hardware Resource Mapping & Register Access #

• platform_get_resource(): Fetch your IP's register memory region and interrupt number directly from the device tree (no hardcoding addresses!).
• ioremap(): Convert the physical register address (from device tree) to a kernel virtual address, so the kernel can safely access the hardware.
• iounmap(): Clean up the virtual address mapping when the device is removed.
• readl()/writel() (or readq()/writeq() for 64-bit registers): Safe, bus-width-aware functions to read/write your IP's registers—avoid raw pointer dereferencing, which can cause unaligned access issues on RISC-V.

2. Interrupt Handling #

• request_irq(): Register your interrupt handler function with the kernel, specifying the interrupt number, trigger type (edge/level), and flags (e.g., IRQF_SHARED if sharing the line).
• free_irq(): Release the interrupt line when the device is removed.
• irqreturn_t: The required return type for your interrupt handler—use IRQ_HANDLED if you processed the interrupt, IRQ_NONE otherwise.
• enable_irq()/disable_irq(): Dynamically turn interrupts on/off as needed.
• tasklet or workqueue: If your interrupt needs to do time-consuming work (like copying data to userspace), offload that to a tasklet (soft interrupt context) or workqueue (process context) to avoid blocking the interrupt handler (which must be fast!).

3. User-Space Interface (Character Device) #

• alloc_chrdev_region(): Allocate a major/minor device number for your character device.
• cdev_init() & cdev_add(): Initialize and register your character device with the kernel's device model.
• cdev_del(): Remove the character device when cleaning up.
• class_create() & device_create(): Automatically create a /dev node for your device—no need to manually run mknod.
• struct file_operations: Define the core functions userspace will call:
  • open/release: Handle device open/close operations.
  • read/write: Transfer data between userspace and your IP's data registers.
  • unlocked_ioctl: Implement custom control commands (e.g., configure interrupt triggers, read/write specific control registers).

4. Synchronization & Race Prevention #

• mutex_lock()/mutex_unlock(): Use mutexes to protect register access from concurrent userspace processes (safe for process context, allows sleeping).
• spin_lock_irqsave()/spin_unlock_irqrestore(): Use spin locks when accessing registers from both interrupt context and process context—they're fast but don't allow sleeping.

• Device Tree First: Describe your IP's registers, interrupts, and compatible string in the device tree. Your platform driver will match against the compatible string to detect the hardware.
• Test Hardware First: Use the devmem tool to directly read/write your IP's physical registers before writing the driver—this confirms your hardware is working as expected.
• Keep Interrupt Handlers Lean: Only do the bare minimum in the interrupt handler (e.g., clear the interrupt flag, trigger a workqueue) to avoid delaying other system interrupts.

内容的提问来源于stack exchange，提问作者Z-Buffer