On Wednesday, August 29, 2018 1, Daniel Lezcano wrote: > My concern is if we can avoid changing the TIMER_OF_DECLARE because of > the boot order, it would be better. > > Can returning EPROBE_DEFER fix this issue? Or use the 'complex > dependencies' [1]?
So I tried just returning -EPROBE_DEFER, but it didn't work. The main reason is ostm_init() is called from timer_probe(). start_kernel() -> time_init() -> timer_probe() -> ostm_init() If you look at timer_probe, it only looks to see if the return value was non-zero to know if something went wrong. It doesn't really care what the actual value was, or do anything different, so returning -EPROBE_DEFER does you no good. When you use TIMER_OF_DECLARE, that puts your driver into the __timer_of_table, and start_kernel/time_init/timer_probe is your only shot at getting your driver running. You don't get another chance later in boot. So, even if that boot constraint did exist, it wouldn't work for timers that used TIMER_OF_DECLARE. I guess as a rule of thumb, if your timer requires a clock, that clock driver has to be an OF clock because it needs to reside in the __clk_of_table. Chris
