Date: Wed, 20 Apr 2016 06:55:51 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Mason <slash.tmp@free.fr>
Cc: Thomas Gleixner <tglx@linutronix.de>, Sebastian Frias <sf84@laposte.net>,
        Mans Rullgard <mans@mansr.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] clocksource/drivers/tango-xtal: Fix incorrect test
Message-ID: <20160420045551.GD5862@linaro.org>
References: <57162153.4070707@free.fr>
 <20160419131330.GA419@linaro.org>
 <57163B1F.7050402@free.fr>
 <20160419145946.GB419@linaro.org>
 <57166910.2080703@free.fr>
 <20160419173104.GA5862@linaro.org>
 <57167780.5040506@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57167780.5040506@free.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 984
Lines: 25

[ ... ]

> About the error handling... you advised against panic()
> because there might be other clock sources.
> 
> Does it makes sense to give up registering sched_clock
> and delay_timer when the clocksource registration fails?

Actually, all the problem is coming from the CLOCKSOURCE_OF_DECLARE where 
the init_func is a void (*init_func)(struct device_node *) signature, thus 
not allowing to return a value.

Because of that, the init code path of the different drivers are somewhat 
fuzzy when an error occurs.

If the function could return an error code, then the drivers would be 
written in a way to catch and handle the errors gracefully. That implies the 
clocksource-probe() routine will be able to detect when the init_func() is 
failing, trace it and count if one clocksource/clockevent succeed at boot 
time.

So because the latter, it would make sense to give up registering and leave 
a clean place in the init function when something is going wrong.

  -- Daniel