Hi Sidong, On Wed, Sep 23, 2026 at 10:14:51PM +0900, Sidong Yang wrote: > IMHO, handling rocket_devfreq_init() error as critical error to disable core > is > too much. How about just printing error for user?
Thanks for reading this far into it. Agreed: rocket_devfreq_init() runs from the probe of the core that binds last, which need not be the core the devfreq device hangs off, so a failure there takes down one NPU core while the remaining cores keep running without devfreq anyway. panfrost, lima and panthor do fail their probe at this point, but there it is the whole device; msm_devfreq_init() only logs, as you suggest. v3 will warn and carry on without devfreq. On that path the driver will hold no OPP table, no OPP configuration and no runtime PM references, the same as a board that describes no OPP table. -EPROBE_DEFER stays fatal: npu-supply is first requested there, through dev_pm_opp_set_config(), and swallowing a deferral would leave the board without frequency scaling for good. All of this is from reading the code; nothing was run for this mail. Igor
