STRUCT DEVFREQ_PASSIVE_DATA(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct devfreq_passive_data(9) πŸ’–

okay so bestie, welcome to the Kernel API Manual ✨ β€” yes this is that kernel API manual, the one for Linux kernel internals, and today's main character is struct devfreq_passive_data. She's a little struct with a big job, and honestly? She ate. Let's get into it 🫢


🌸 NAME 🌸

struct devfreq_passive_data β€” the void *data that gets fed to struct devfreq and to devfreq_add_device. that's it, that's the whole vibe: she's the payload you hand over πŸ’…


✨ SYNOPSIS ✨

like literally, here's her whole shape, no cap:

struct devfreq_passive_data {
    struct devfreq *parent;
    int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
    enum devfreq_parent_dev_type parent_type;
    struct devfreq *this;
    struct notifier_block nb;
    struct list_head cpu_data_list;
 };

πŸŽ€ Members πŸŽ€

  • parent β€” the devfreq instance of the parent device. that's the parent device's devfreq instance, the one she's lowkey obsessed with πŸ‘‘
  • get_target_freq β€” an optional callback, and it returns the desired operating frequency for the device that's using the passive governor. it gets called when the passive governor needs to decide the next frequency, and it does that by using the new frequency of the parent devfreq device β€” using governors except for the passive governor. so if your devfreq device has its own specific method for deciding the next frequency, bestie, you should use this callback πŸ”₯
  • parent_type β€” the parent type of the device. simple as that 🌈
  • this β€” the devfreq instance of own device. yes, her own device, main character energy πŸ’€
  • nb β€” the notifier block for the DEVFREQ_TRANSITION_NOTIFIER or CPUFREQ_TRANSITION_NOTIFIER list. pick your list, she's on it ⭐
  • cpu_data_list β€” the list of cpu frequency data for all cpufreq_policy. all of them, fr fr πŸ¦‹

🧚 Description 🧚

so here's the tea πŸ“ β€” devfreq_passive_data has to set the devfreq instance of the parent device, and that parent device is using governors except for the passive governor. that part is mandatory, no skipping πŸ™ˆ

but the 'this' and 'nb' fields? you don't need to initialize those, because the devfreq core handles them for you. the kernel's got you, bestie πŸ’œ


πŸ’€ SEE ALSO πŸ’€

  • Kernel file ./include/linux/devfreq.h
  • struct devfreq_dev_status(9)
  • struct devfreq_dev_profile(9)
  • struct devfreq_stats(9)
  • struct devfreq(9)
  • struct devfreq_simple_ondemand_data(9)

all iconic, all worth a read, iykyk πŸ“šβœ¨


aaaand that's the whole page, bestie πŸŽ€ mwah πŸ’‹ β€” this came to you from ./include/linux, dated October 2026, and the title of the whole thing is struct devfreq_passive_data(9). slay, go read the other structs now πŸ¦‹πŸ’–

πŸ“¦ where this page comes from