_setup_postsetup(9)

💅 _setup_postsetup(9) — Kernel API Manual, bestie 💅

okay so this is _setup_postsetup(9) from the Kernel API Manual, and it's literally the little function that handles the glow-up after _setup is done. 🦋

🎀 NAME 🎀

_setup_postsetup — transition to the appropriate state after _setup. That's the whole vibe. ✨

🌸 SYNOPSIS 🌸

void _setup_postsetup (struct omap_hwmod *oh );

🧚 ARGUMENTS 🧚

• oh — struct omap_hwmod *. Your IP block's main character struct 💅

🔥 DESCRIPTION 🔥

So _setup_postsetup takes the IP block represented by oh and puts it into a "post-setup" state — and that state is either IDLE, ENABLED, or DISABLED. And bestie, "post-setup" just means this function gets called at the end of _setup. That's it. No secret lore. 🫶

The postsetup state for an IP block can be changed by calling omap_hwmod_enter_postsetup_state early in the boot process, before one of the omap_hwmod_setup*() functions are called for that IP block. Timing matters, iykyk. ⏰

The IP block stays in this state until a PM runtime-based driver is loaded for that IP block. Here's the state tea:

• A post-setup state of IDLE is appropriate for almost all IP blocks with runtime PM-enabled drivers, since those drivers are able to enable the IP block. Very slay, very flexible. 💖
• A post-setup state of ENABLED is appropriate for kernels with PM runtime disabled.
• The DISABLED state is appropriate for unusual IP blocks such as the MPU WDTIMER on kernels without WDTIMER drivers included, since the WDTIMER starts running on reset and will reset the MPU if left active. Ma'am, that's dangerous — do not leave the WDTIMER active. 💀

This post-setup mechanism is deprecated. Not me being dramatic — it's literally deprecated. 😭

Once all of the OMAP drivers have been converted to use PM runtime, and all of the IP block data and interconnect data is available to the hwmod code, it should be possible to replace this mechanism with a "lazy reset" arrangement. In a lazy reset setup, each IP block is enabled when the driver first probes, then all remaining IP blocks without drivers are either shut down or enabled after the drivers have loaded. That's the future dream scenario. 🌈

But this cannot take place until the above preconditions have been met, since otherwise the late reset code has no way of knowing which IP blocks are in use by drivers, and which ones are unused. So like, no skipping steps. 🧚

No return value. Nothing comes back out. The function is void. Periodt. 👑

🦋 SEE ALSO 🦋

• Kernel file ./arch/arm/mach-omap2/omap_hwmod.c
• struct clkctrl_provider(9), struct omap_hwmod_reset(9), struct omap_hwmod_soc_ops(9), _update_sysc_cache(9), _write_sysconfig(9), _set_master_standbymode(9), _set_slave_idlemode(9), _set_clockactivity(9), _set_softreset(9), _clear_softreset(9), _wait_softreset_complete(9), _set_dmadisable(9), _set_module_autoidle(9), _enable_wakeup(9), _add_initiator_dep(9), _del_initiator_dep(9), _init_main_clk(9), _init_interface_clks(9), _init_opt_clks(9), _enable_clocks(9)
• _omap4_clkctrl_managed_by_clkfwk(9), _omap4_has_clkctrl_clock(9), _disable_clocks(9), _omap4_enable_module(9), _omap4_wait_target_disable(9), _save_mpu_port_index(9), _find_mpu_rt_port(9), _enable_sysc(9), _idle_sysc(9), _shutdown_sysc(9), _lookup(9), _init_clkdm(9), _init_clocks(9), _lookup_hardreset(9), _assert_hardreset(9), _deassert_hardreset(9), _read_hardreset(9), _are_all_hardreset_lines_asserted(9), _are_any_hardreset_lines_asserted(9), _omap4_disable_module(9)
• _ocp_softreset(9), _reset(9), _omap4_update_context_lost(9), _omap4_get_context_lost(9), _enable(9), _idle(9), _shutdown(9), of_dev_hwmod_lookup(9), omap_hwmod_fix_mpu_rt_idx(9), omap_hwmod_parse_module_range(9), _init_mpu_rt_base(9), _init(9), _setup_iclk_autoidle(9), _setup_reset(9), _setup(9), _register(9), _add_link(9), _register_link(9)
• _omap2xxx_3xxx_wait_target_ready(9), _omap4_wait_target_ready(9), _omap2_assert_hardreset(9), _omap2_deassert_hardreset(9), _omap2_is_hardreset_asserted(9), _omap4_assert_hardreset(9), _omap4_deassert_hardreset(9), _omap4_is_hardreset_asserted(9), _omap4_disable_direct_prcm(9), _am33xx_deassert_hardreset(9), omap_hwmod_softreset(9), omap_hwmod_lookup(9), omap_hwmod_for_each(9), omap_hwmod_register_links(9), _ensure_mpu_hwmod_is_setup(9)
• omap_hwmod_setup_one(9), omap_hwmod_check_sysc(9), omap_hwmod_init_regbits(9), omap_hwmod_init_reg_offs(9), omap_hwmod_init_sysc_flags(9), omap_hwmod_init_idlemodes(9), omap_hwmod_check_module(9), omap_hwmod_allocate_module(9), omap_hwmod_init_module(9), omap_hwmod_setup_earlycon_flags(9), omap_hwmod_setup_all(9), omap_hwmod_enable(9), omap_hwmod_idle(9), omap_hwmod_shutdown(9), omap_hwmod_get_mpu_rt_va(9), omap_hwmod_assert_hardreset(9), omap_hwmod_deassert_hardreset(9), omap_hwmod_for_each_by_class(9), omap_hwmod_set_postsetup_state(9), omap_hwmod_init(9)

---

and that's the page, bestie 🫶 it lives in the ./arch/arm/mach-omap2 corner of the source tree, it's the October 2026 edition, and it's called _setup_postsetup(9) — byeee 💅✨