devm_of_clk_add_hw_provider(9)
π devm_of_clk_add_hw_provider(9) β like, the whole glow-up guide
okay so bestie, we're in the Kernel API Manual (that's the manual name, mwah) and today's main character is devm_of_clk_add_hw_provider(9). Buckle up, it's giving "clock provider registration but make it managed" π
β¨ NAME β¨
devm_of_clk_add_hw_provider β managed clk provider node registration π
πΈ SYNOPSIS πΈ
int devm_of_clk_add_hw_provider (struct device *dev , struct clk_hw
*(*get)(struct of_phandle_args *clkspec, void *data) , void *data );
yes it's a whole mouthful, no I will not be apologising π
π¦ ARGUMENTS π¦
devβ the Device that's acting as the clock provider. it's the one used for the DT node and for the lifetime, so like... it's kind of the whole personality here π«Άgetβ the callback for decodingclk_hw. your little decoder ring π₯dataβ context pointer for thegetcallback. it's giving "bring your own vibes" π
π DESCRIPTION π
So what's the tea β: this registers a clock provider for the given device's node.
And here's the plot twist β if the device has no DT node, or if the device node is missing its clock provider info (#clock-cells), then the parent device's node gets scanned for that info instead. And if the parent node does have #clock-cells, that's the one used in registration. iconic inheritance behaviour, honestly π
And the best part? The provider is automatically released at device exit. no manual cleanup, no messy breakup, devm said "i gotchu" β¨
π RETURN π
0 on success, or an errno on failure. simple as that, bestie π
π SEE ALSO π
like a whole friend group, fr fr. the kernel file is ./drivers/clk/clk.c and here's everybody:
struct clk_core(9)clk_pm_runtime_get_all(9)clk_pm_runtime_put_all(9)clk_core_get(9)clk_determine_rate_noop(9)clk_rate_exclusive_put(9)clk_rate_exclusive_get(9)clk_unprepare(9)clk_prepare(9)clk_disable(9)clk_gate_restore_context(9)clk_save_context(9)clk_restore_context(9)clk_enable(9)clk_is_enabled_when_prepared(9)clk_hw_init_rate_request(9)clk_hw_forward_rate_request(9)__clk_determine_rate(9)clk_hw_round_rate(9)clk_round_rate(9)__clk_notify(9)__clk_recalc_accuracies(9)clk_get_accuracy(9)__clk_recalc_rates(9)clk_get_rate(9)clk_hw_get_parent_index(9)__clk_speculate_rates(9)clk_set_rate(9)clk_set_rate_exclusive(9)clk_set_rate_range(9)clk_set_min_rate(9)clk_set_max_rate(9)clk_get_parent(9)clk_has_parent(9)clk_set_parent(9)clk_set_phase(9)clk_get_phase(9)clk_set_duty_cycle(9)clk_get_scaled_duty_cycle(9)clk_is_match(9)clk_debug_register(9)clk_debug_init(9)__clk_core_init(9)clk_core_link_consumer(9)clk_core_unlink_consumer(9)alloc_clk(9)free_clk(9)clk_hw_create_clk(9)clk_hw_get_clk(9)dev_or_parent_of_node(9)clk_register(9)clk_hw_register(9)clk_unregister(9)clk_hw_unregister(9)devm_clk_register(9)devm_clk_hw_register(9)devm_clk_hw_get_clk(9)clk_notifier_register(9)clk_notifier_unregister(9)struct of_clk_provider(9)of_clk_add_provider(9)of_clk_add_hw_provider(9)of_clk_del_provider(9)of_parse_clkspec(9)of_clk_get_from_provider(9)of_clk_get_by_name(9)of_clk_get_parent_count(9)of_clk_parent_fill(9)of_clk_detect_critical(9)of_clk_init(9)
ngl that's a long list but every single one of them is a real one, no cap. go read them, i'll wait π
and that's the page!! π§ from ./drivers/clk, dated October 2026, and the header's name is devm_of_clk_add_hw_provider(9) in case you forgot already π love u, go register some clocks responsibly, periodt π
π
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms