Analysis of Android Fingerprint Driver Initialization and DTS Matching in Linux Kernel 5.10

This article uses the Android fingerprint driver initialization as a starting point to thoroughly analyze the complete boot‑to‑initialization flow, clarify the relationship between Linux platform devices and the Device Tree (DTS), and draw parallels to other platform driver designs.

1. Boot Initialization Process

The boot sequence on an MTK Android phone follows the flow shown in Figure 1: power‑on → Boot ROM executes pre‑loader code → pre‑loader initializes DRAM and loads ATF → ATF loads LK → LK unpacks the boot image and loads the Linux kernel and ramdisk, then jumps to the kernel.

2. Timing of fp_init

During the early kernel initialization (see //kernel-5.10/arch/arm64/kernel/head.S and //kernel-5.10/init/main.c ), the C runtime environment is set up, after which start_kernel calls a chain of functions:

start_kernel → arch_call_rest_init(void) → rest_init() → kernel_init() → do_basic_setup() → do_initcalls()

Within do_initcalls , the driver’s initcall macro registers fp_init (e.g., xxx_initcall(fp_init) ), which later registers the fingerprint driver as a platform driver.

3. Timing of fp_probe

The probe function is invoked after the platform driver is registered. The call chain involves roughly twenty kernel functions, including:

platform_driver_register() → __platform_driver_register() → driver_register() → driver_find() → bus_add_driver() → driver_attach() → bus_for_each_dev() → __driver_attach() → driver_match_device() → driver_probe_device() → really_probe() → dev->bus->probe() → drv->probe()

When the device name from the DTS matches the driver’s of_match_table , drv->probe(dev) ultimately calls fp_probe .

4. Timing of DTS Processing

The Device Tree is parsed early in setup_arch() (see setup_machine_fdt() ), which calls unflatten_device_tree() to create device_node structures for each DTS node. In the second phase, these nodes are converted into platform_device objects via of_platform_default_populate_init() :

of_platform_default_populate_init() → of_platform_device_create() → of_platform_device_create_pdata() → of_device_alloc() → platform_device_alloc() → dev->dev.parent = parent ?: &platform_bus → dev->dev.bus = &platform_bus_type → platform_device_put()

All resulting platform devices are linked into the klist_devices list, which the bus traversal functions use for matching.

5. Driver‑DTS Matching Methods

The kernel provides three matching mechanisms (see kernel-5.10/drivers/base/platform.c ):

of_match_table – highest priority, matches the DTS compatible string with the driver’s table.

Device‑ID table – second priority, defined via platform_device_id array and MODULE_DEVICE_TABLE .

Driver name field – third priority, matches the driver name with the DTS compatible string.

6. Conclusion

The article starts from the fingerprint driver’s entry points, traces the Linux kernel boot process, and clarifies the interactions among fp_init , fp_probe , and DTS handling. The analysis can be generalized to other platform devices and DTS‑based initialization flows, helping readers understand and apply these concepts to similar driver development tasks.