[PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
daniel.lezcano at linaro.org
Mon May 29 03:55:09 PDT 2017
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 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.
Hmm, that sounds scary :)
There is no guarantee, when removing the alias, none of the above happens,
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 |
More information about the linux-amlogic