[PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE

[Arnd Bergmann]

On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> On Mon, May 29, 2017 at 10:41:52AM +0200, Arnd Bergmann wrote:
>> On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
>> <daniel.lezcano at linaro.org> wrote:
>> > The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
>> > clocksource at early stage. However, this macro is also used to initialize
>> > the clockevent if any, or the clockevent only.
>> >
>> > It was originally suggested to declare another macro to initialize a
>> > clockevent, so in order to separate the two entities even they belong to the
>> > same IP. This was not accepted because of the impact on the DT where splitting
>> > a clocksource/clockevent definition does not make sense as it is a Linux
>> > concept not a hardware description.
>> >
>> > On the other side, the clocksource has not interrupt declared while the
>> > clockevent has, so it is easy from the driver to know if the description is
>> > for a clockevent or a clocksource, IOW it could be implemented at the driver
>> > level.
>> >
>> > So instead of dealing with a named clocksource macro, let's use a more generic
>> > one: TIMER_OF_DECLARE.
>> >
>> > The patch has not functional changes.
>> >
>> > Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>
>> Could you either leave the old name as an alias for one release, or introduce
>> the new name as an alias now for 4.13?
>>
>> I think that that would make it easier to merge new drivers. Otherwise this
>> looks good to me,
>
>
> New drivers should go through my tree, so I can catch them with the old macro
> name and do the change.

Sure, they should, and it's quite likely that you won't even need the fallback,
I've just seen too many cases where a similar assumption turned out wrong,
that I'd just pick the safer option just in case whenever I do an API change.

Things that could go wrong include:

- A platform maintainer wants to add a new platform and has a for-next
  branch that gets merged into linux-next, with parts of it going through
  different maintainers, and now they have to choose between a branch
  that doesn't build without the timer branch, or one that break for-next
  unless Stephen applies a fixup

- Some architecture maintainer didn't get the memo and adds an instance of
  CLOCKSOUCE_OF_DECLARE in architecture specific code without asking
  having the patch reviewed first

- A platform has a branch with complex cross-tree dependencies and
  it need to get merged in an unconventional way.

- You make a mistake and accidentally merge one driver for an unusual
  architecture that escapes your test matrix.

While those all are unlikely to happen in a particular merge window, they do
happen occasionally and tend to cause a lot of pain.

       Arnd