[linux-oxnas] Re: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE

[Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>]

On Mon, May 29, 2017 at 11:57:25AM +0200, Arnd Bergmann wrote:
> On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano
> <daniel.lezcano@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx>
> >>
> >> 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.

Hmm, that sounds scary :)

There is no guarantee, when removing the alias, none of the above happens,
right?

If the timer branch is in linux-next, that could be caugth before any of the
above happens, no?

I'm not against adding an alias, just checking out if it is worth to.

-- 

 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog