RE: Educational Question - How does the device driver acquire that device's API?

FinnBiggs — Tue, 18 Jun 2024 18:27:21 GMT

Thank you very much, very clear answer!

RE: Educational Question - How does the device driver acquire that device's API?

Anthony Ambuehl — Sat, 20 Jan 2024 01:06:32 GMT

Every device in devicetree declares which driver it is compatible with.

The Cmake/Kconfig/Devicetree environment will automatically include the corresponding driver source file for example zephyr/drivers/sensor/lis2mdl/lis2mdl.c.

At the bottom of the device driver source file there are macros which declare a device object for each instance of a device declared in device tree. These macros automatically place the device struct in a named region that the kernel is aware. The kernel will automatically call the init function from the device drive struct according to the init phase and init priority declared in the device object.

This device object includes a pointer to the device's implementation of the API. It also may include pointers run time data and configuration constants data ojbects.

Taking LIS2MDL as an example:

#define LIS2MDL_DEVICE_INIT(inst)                                                                  \
	PM_DEVICE_DT_INST_DEFINE(inst, lis2mdl_pm_action);                                         \
                                                                                                   \
	SENSOR_DEVICE_DT_INST_DEFINE(inst, lis2mdl_init, PM_DEVICE_DT_INST_GET(inst),              \
				     &lis2mdl_data_##inst, &lis2mdl_config_##inst, POST_KERNEL,    \
				     CONFIG_SENSOR_INIT_PRIORITY, &lis2mdl_driver_api);

#define LIS2MDL_DEFINE(inst)                                                                       \
	static struct lis2mdl_data lis2mdl_data_##inst = {                                         \
		.single_mode = DT_INST_PROP(inst, single_mode),                                    \
	};                                                                                         \
	static const struct lis2mdl_config lis2mdl_config_##inst =                                 \
		COND_CODE_1(DT_INST_ON_BUS(inst, spi), (LIS2MDL_CONFIG_SPI(inst)),                 \
			    (LIS2MDL_CONFIG_I2C(inst)));                                           \
	LIS2MDL_DEVICE_INIT(inst)

DT_INST_FOREACH_STATUS_OKAY(LIS2MDL_DEFINE)

The macro's for all this are deeply layered but they are all triggering off of defines coming from:

build_dir/zephyr/include/generated/devicetree_generated.h

This actually touches on a flaw in zephyr.. there is no type checking on calls to device drivers. Its entirely possible to call sensor_attr_set on a device that does not follow the sensor API. Its up to the programmer to use the correct API functions with a driver of the same type.

I hope this helps!

Also I spent the last 7 months learning Zephyr and I'm now looking for a new gig so if you know anyone looking for a embedded software expert please share my linkedIn profile: