DEVICE_LIFESPAN(9)

✨ DEVICE_LIFESPAN ✨

okay bestie, welcome to DEVICE_LIFESPAN(9) from the Kernel API Manual — this one is giving “who owns this memory?” energy, and the answer is very much the registering driver. 💅

🫶 the whole memory-ownership vibe

The registering driver is the entity that allocates memory for the auxiliary_device and registers it on the auxiliary bus. Important note: as opposed to the platform bus, the registering driver is wholly responsible for the management of the memory used for the device object. No cap, that’s all on them. 💖

To be clear: the memory for the auxiliary_device is freed in the release callback defined by the registering driver. The registering driver should only call auxiliary_device_delete and then auxiliary_device_uninit when it is done with the device. The release function is then automatically called if and when other code releases their reference to the devices. 🦋

🎀 parent object + shared object(s)

A parent object, defined in the shared header file, contains the auxiliary_device. It also contains a pointer to the shared object(s), which also is defined in the shared header. Both the parent object and the shared object(s) are allocated by the registering driver. This layout allows the auxiliary_driver’s registering module to perform a container_of call to go from the pointer to the auxiliary_device, that is passed during the call to the auxiliary_driver’s probe function, up to the parent object, and then have access to the shared object(s). obsessed with this little pointer journey, honestly. ✨

🌸 lifespan rules (do not skip)

The memory for the shared object(s) must have a lifespan equal to, or greater than, the lifespan of the memory for the auxiliary_device. The auxiliary_driver should only consider that the shared object is valid as long as the auxiliary_device is still registered on the auxiliary bus. It is up to the registering driver to manage (e.g. free or keep available) the memory for the shared object beyond the life of the auxiliary_device. 🫶

The registering driver must unregister all auxiliary devices before its own driver.remove is completed. An easy way to ensure this is to use the devm_add_action_or_reset call to register a function against the parent device which unregisters the auxiliary device object(s). 🧚

Finally, any operations which operate on the auxiliary devices must continue to function (if only to return an error) after the registering driver unregisters the auxiliary device. yes bestie, even the error-return era still counts. 💀

👀 SEE ALSO 👀

• Kernel file ./include/linux/auxiliary_bus.h
• struct auxiliary_device(9)
• struct auxiliary_driver(9)
• module_auxiliary_driver(9)

that’s the whole vibe 💖 — source: ./include/linux, date: October 2026. bye bestie, go forth and manage that lifespan responsibly 🎀🦋