STRUCT RESET_CONTROLLER_DEV(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ struct reset_controller_dev(9) β€” the kernel API manual, bestie edition πŸŽ€

okay so picture this: you're deep in struct reset_controller_dev(9) territory, straight out of the kernel API manual, and you need the tea on reset controllers. no worries babe, i got you πŸ’–


✨ NAME ✨

struct reset_controller_dev β€” the reset controller entity that might provide multiple reset controls πŸ‘‘

like, one struct, many reset controls. it's giving main character energy with a whole friend group.


🌸 SYNOPSIS 🌸

struct reset_controller_dev {
    const struct reset_control_ops *ops;
    struct module *owner;
    struct list_head list;
    struct list_head reset_control_head;
    struct device *dev;
    struct device_node *of_node;
    int of_reset_n_cells;
    int (*of_xlate)(struct reset_controller_dev *rcdev, const struct of_phandle_args *reset_spec);
    struct fwnode_handle *fwnode;
    int fwnode_reset_n_cells;
    int (*fwnode_xlate)(struct reset_controller_dev *rcdev, const struct fwnode_reference_args *reset_spec);
    unsigned int nr_resets;
    struct mutex lock;
 };

look at her. so many fields. so much structure. we stan a well-organized struct 🫢


πŸ¦‹ Members πŸ¦‹

  • ops β€” a pointer to the device specific struct reset_control_ops. this is where the actual vibe lives, the device-specific behaviour πŸ’…
  • owner β€” the kernel module of the reset controller driver. gotta know who's responsible, yk?
  • list β€” internal list of reset controller devices. lowkey bookkeeping, but make it iconic.
  • reset_control_head β€” head of the internal list of requested reset controls. yes bestie, head of the list, leading the whole squad.
  • dev β€” the corresponding driver model device struct. the actual device, no cap.
  • of_node β€” the corresponding device tree node, as a phandle target. tree node things 🌈
  • of_reset_n_cells β€” number of cells in reset line specifiers. count 'em.
  • of_xlate β€” translation function to translate from specifier as found in the device tree to id as given to the reset control ops. literally a translator bestie, fluent in devicetree 🧚
  • fwnode β€” firmware node associated with this device. firmware but make it node.
  • fwnode_reset_n_cells β€” number of cells in reset line specifiers. same energy, fwnode flavour ✨
  • fwnode_xlate β€” translation function to translate from firmware specifier to id as given to the reset control ops, defaults to :c:func:fwnode_reset_simple_xlate``. yes, there's a default, she's generous πŸ’–
  • nr_resets β€” number of reset controls in this reset controller device. how many resets? this many.
  • lock β€” protects the reset control list from concurrent access. she's the bouncer at the club, keeping the list safe πŸŽ€

πŸ’œ SEE ALSO πŸ’œ

  • Kernel file ./include/linux/reset-controller.h
  • struct reset_control_ops(9)

ok so quick vibe check: every field here is real and useful, please don't go inventing extra ones or renaming anything. the struct is perfect the way she is πŸ’€

and that's the whole page, bestie, you ate that πŸ“ this one lives in the kernel API manual and comes to you from ./include/linux, dated October 2026, filed under struct reset_controller_dev(9). slay, go reset something responsibly πŸ”₯πŸ‘‘

πŸ“¦ where this page comes from