attribute_co...r_add_device(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– attribute_co...r_add_device(9) πŸ’–

okay bestie, welcome to this Kernel API Manual moment β€” yes, the title is literally attribute_co...r_add_device(9), and we’re about to make attribute_container_add_device make sense. 🫢

🌸 NAME 🌸

attribute_container_add_device β€” see if any container is interested in dev. πŸ‘€

✨ SYNOPSIS ✨

void attribute_container_add_device (struct device *dev , int (*fn)(struct attribute_container *, struct device *, struct device *) );

πŸŽ€ ARGUMENTS πŸŽ€

  • dev β€” device to add attributes to. πŸ› οΈ
  • fn β€” function to trigger addition of class device. πŸ””

πŸ’… DESCRIPTION πŸ’…

So this function allocates storage for the class device(s) that are gonna be attached to dev β€” one for each matching attribute_container. No cap. πŸ’–

If no fn is provided, the code will simply register the class device via device_add. easy peasy. ✨

If a function is provided, it is expected to add the class device at the appropriate time. One of the things that might be necessary is to allocate and initialise the classdev and then add it a later time. To do this, call this routine for allocation and initialisation and then use attribute_container_device_trigger to call device_add on it. πŸŒ€

Note: after this, the class device contains a reference to dev which is not relinquished until the release of the classdev. Keep that in mind, bestie β€” that reference is staying put until the classdev gets released. πŸ’€

πŸ”₯ SEE ALSO πŸ”₯


okay that’s the whole vibe πŸ’… signed off from ./drivers/base, October 2026, in the Kernel API Manual β€” mwah! πŸ’–βœ¨

πŸ“¦ where this page comes from