RE: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux