After thinking about it a bit more I still think a separateNope, no technical reason why it can't be done. I'll do what you
clk_register_divider_table is needed. Primarily this would reduce
needless churn in having to update all existing users of
clk_register_divider. I also think that clearly separating the two
functions will make it a bit easier on folks trying to port their clocks
trees over.
Unless there is a technical reason why having two registration functions
is a bad idea, can you send a V4 with that new registration function?
I'll take it into clk-next.