Linux Device Drivers Interview (80 Questions)

-

 Section A – Linux Basics (1–10)

1.

What is a Linux Device Driver?

2.

Why are device drivers required?

3.

Explain the Linux Kernel architecture.

4.

Difference between

  • User Space
  • Kernel Space

5.

What is a system call?

How does it differ from a library function?

6.

Explain the Linux boot process from power-on until the login prompt.

7.

What is the difference between:

  • Monolithic Kernel
  • Microkernel

8.

Explain Loadable Kernel Modules (LKM).

9.

How do you insert and remove a kernel module?

10.

Difference between:

insmod
modprobe
rmmod
lsmod
modinfo

Section B – Kernel Modules (11–18)

11.

Write a simple Hello World Linux Kernel Module.

12.

What are:

module_init()

module_exit()

13.

Explain module licensing.

14.

What is printk()?

Difference between printk() and printf().

15.

Explain printk log levels.

16.

Where are kernel logs stored?

17.

How do you debug a kernel module?

18.

Why must floating-point operations be avoided inside the Linux kernel?

Section C – Character Device Drivers (19–30)

19.

What is a Character Device Driver?

20.

Difference between:

  • Character Device
  • Block Device
  • Network Device

21.

Explain:

register_chrdev()

22.

What is a Major Number?

What is a Minor Number?

23.

Difference between:

Static and Dynamic Major Numbers.

24.

Explain the purpose of:

struct file_operations

25.

Explain each callback:

  • open()
  • release()
  • read()
  • write()
  • ioctl()
  • mmap()

26.

What happens internally when a user executes:

open("/dev/mydevice")

27.

How does read() reach the driver?

28.

Explain copy_to_user() and copy_from_user().

29.

Why can't kernel code directly access user memory?

30.

Write a simple character driver that exchanges data with user space.

Section D – Platform Drivers (31–38)

31.

What is a Platform Driver?

32.

Why are Platform Drivers used in Embedded Linux?

33.

Explain:

platform_driver

34.

Explain:

platform_device

35.

Difference between:

Platform Driver

PCI Driver

USB Driver

36.

What is the probe() function?

37.

When is remove() called?

38.

How are Platform Drivers matched with Platform Devices?

Section E – Device Tree (39–46)

39.

What is Device Tree?

Why was it introduced?

40.

Difference between:

.dts

.dtsi

.dtb

41.

How does Linux parse the Device Tree?

42.

Explain:

Compatible String.

43.

How do drivers access Device Tree properties?

44.

Explain GPIO configuration in Device Tree.

45.

Explain Interrupt configuration in Device Tree.

46.

How do you debug Device Tree issues?

Section F – Linux Kernel APIs (47–54)

47.

Difference between:

kmalloc()

vmalloc()

48.

Difference between:

kfree()

free()

49.

Explain GFP flags.

50.

What is DMA?

51.

How do drivers allocate DMA memory?

52.

Difference between:

Physical

Virtual

Bus Address

53.

Explain Memory Mapping.

54.

Explain ioremap().

Section G – Interrupt Handling (55–62)

55.

Explain Linux Interrupt Handling.

56.

What is:

request_irq()

57.

Explain Shared Interrupts.

58.

Difference between:

Top Half

Bottom Half

59.

Explain:

  • Tasklets
  • Workqueues
  • SoftIRQ

60.

When should Workqueues be preferred?

61.

What is threaded IRQ?

62.

How do you debug interrupt latency?

Section H – Synchronization (63–68)

63.

Difference between:

Mutex

Spinlock

Semaphore

Completion

64.

When should Spinlocks be used?

65.

Why can't a Mutex be used inside an ISR?

66.

Explain Atomic Variables.

67.

What is RCU (Read-Copy-Update)?

68.

Explain Deadlock in Linux Kernel.

Section I – Driver Debugging (69–74)

69.

How do you debug a kernel panic?

70.

Explain Oops Message.

71.

What is a Kernel Crash Dump?

72.

How do you debug memory leaks in drivers?

73.

How do you measure driver performance?

74.

Explain Ftrace.

Section J – Advanced Topics (75–80)

75.

How does the Linux Scheduler work?

76.

Explain Context Switching in Linux.

77.

How would you write a Linux Driver for an I²C Temperature Sensor?

78.

How would you debug a driver that occasionally hangs after several hours of operation?

79.

How would you port a Linux Device Driver from one ARM Cortex-A SoC to another?

80.

Design a Linux Driver Architecture for an Automotive ECU with:

  • SPI Flash
  • CAN Controller
  • EEPROM
  • Ethernet PHY
  • Watchdog
  • GPIO Expander

Explain:

  • Driver layering
  • Device Tree
  • Interrupt handling
  • DMA
  • Power Management
  • Error handling
  • Testing strategy

Coding Questions (Very Frequently Asked)

These are common hands-on tasks during Linux device driver interviews:

  1. Write a Character Device Driver.
  2. Implement read() and write() operations.
  3. Add an ioctl() interface.
  4. Register an interrupt handler.
  5. Read a GPIO from Device Tree.
  6. Toggle an LED using a kernel driver.
  7. Develop a simple I²C driver.
  8. Develop a simple SPI driver.
  9. Implement a circular buffer in kernel space.
  10. Add blocking I/O support using wait queues.

Debugging Scenarios (Senior Engineer)

Given your experience, interviewers may focus on practical debugging:

  • The probe() function is never called. What would you check?
  • The driver loads successfully, but /dev/mydevice is not created.
  • copy_to_user() returns -EFAULT. What are the likely causes?
  • An interrupt never triggers. How do you debug it?
  • kmalloc() occasionally fails under heavy load.
  • A kernel panic occurs during module removal.
  • Memory usage keeps increasing after repeated insmod/rmmod cycles.
  • An I²C device is detected on the bus, but the driver does not bind to it.
  • The driver works in a debug build but fails in an optimized release build.
  • The board boots, but none of the peripheral drivers are initialized. How would you systematically diagnose the issue?

Comments

Post a Comment

Popular posts from this blog

Fundamental Secure Features in Automotive ECUs

-
Image
 With increasing connectivity and functionality in modern vehicles and IoT devices, security has become a non-negotiable aspect of embedded system design. Automotive ECUs and IoT MCUs are now exposed to threats that can compromise safety, privacy, and system integrity. To mitigate these risks, a suite of fundamental secure features is implemented across the lifecycle of embedded software. This blog outlines six core security pillars that serve as the foundation for robust ECU security: Fundamental Secure Feature I: Secure Boot Fundamental Secure Feature II: Secure Flash Fundamental Secure Feature III: Secure JTAG Fundamental Secure Feature IV: Secure LOG Fundamental Secure Feature V: Secure UDS Fundamental Secure Feature VI: Secure On-Board Communication (SecOC) These six foundational security features—Secure Boot, Secure Flash, Secure JTAG, Secure Log, Secure UDS, and Secure On-Board Communication (SecOC)—are critical for building a trustworthy embedded system. Whether in automoti...
Read more

Overview of ISO/SAE 21434 Standard

-
Image
ISO/SAE 21434, jointly published by the International Standardization Organization (ISO) and the Society of Automotive Engineers (SAE), serves as a comprehensive cybersecurity framework for electronic systems within road vehicles. Developed to bolster cybersecurity across the entire lifecycle of automotive products, this standard outlines essential vocabulary, objectives, requirements, and guidelines. Purpose and Scope: The primary objective of ISO/SAE 21434 is to enhance cybersecurity measures for vehicles throughout their lifecycle. By providing a standardized framework, this standard facilitates the establishment of cybersecurity policies, risk management practices, and a cybersecurity-oriented culture within organizations operating in the automotive industry. Three Pillars: ISO/SAE 21434 is structured around three main pillars: Cyber Security Governance:   Establishing policies, processes, and cultural norms to govern cybersecurity activities within organizations. Risk Man...
Read more

Fundamental Secure Feature I: Secure Boot

-
Image
What is it? Secure Boot is a mechanism that verifies the authenticity and integrity of software code stored in flash memory before allowing the system to execute it. The MCU will only boot the application if the code has not been tampered with. Why is it needed? Prevents unauthorized firmware execution. Protects against malicious code injection during the boot process. Blocks attempts to bypass security checks by tampering with the bootloader. Ensures the ECU does not boot into a compromised or corrupted state. 🔍 For example, an attacker might modify the bootloader to disable security features after boot. Secure Boot prevents this by enforcing integrity checks from the very first instruction. Types of Secure Boot: Symmetric-Based Secure Boot Uses shared keys for both signing and verification. Easier to implement, but key management is critical. Asymmetric-Based Secure Boot Uses a private-public key pair. The bootloader verifies the signature of the firmware using a public key, while t...
Read more