From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752373AbbBKKiy (ORCPT ); Wed, 11 Feb 2015 05:38:54 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:51358 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751075AbbBKKix (ORCPT ); Wed, 11 Feb 2015 05:38:53 -0500 Date: Wed, 11 Feb 2015 11:38:45 +0100 From: Peter Zijlstra To: Viresh Kumar Cc: Thomas Gleixner , Linaro Kernel Mailman List , Linux Kernel Mailing List , Kevin Hilman , Frederic Weisbecker , Preeti U Murthy , Daniel Lezcano , Linaro Networking Subject: Re: [PATCH] clockevents: Introduce mode specific callbacks Message-ID: <20150211103845.GR23123@twins.programming.kicks-ass.net> References: <025ca1872df9ed8a9f7b6e0400e71ed296374183.1423034839.git.viresh.kumar@linaro.org> <20150210141541.GB7119@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 11, 2015 at 11:24:53AM +0800, Viresh Kumar wrote: > On 10 February 2015 at 22:15, Peter Zijlstra wrote: > > On Wed, Feb 04, 2015 at 01:06:23PM +0530, Viresh Kumar wrote: > >> + /* > >> + * Mode transition callback(s): Only one of the two groups should be > >> + * defined: > >> + * - set_mode(), only for modes <= CLOCK_EVT_MODE_RESUME. > >> + * - set_mode_{shutdown|periodic|oneshot|resume}(). > >> + */ > >> +static int clockevents_sanity_check(struct clock_event_device *dev) > >> +{ > >> +} > > > > It appears to me you've not actually checked that condition outlined > > above, a driver could set both the legacy and the new callbacks. > > Exactly for this reason I mentioned this in the logs: > > >> If the legacy ->set_mode() callback is provided, all mode specific > >> callbacks would be ignored. > > So, either we can mention that in the code as well OR add code to > check and WARN about that. Will do whatever looks better to you > guys. I think its better to be strict; esp. with new interfaces. It avoids confusion. Suppose a driver writer sees these new methods and thinks to use one while still having the set_mode() one -- ie. he didn't actually read the comment. We'd better make sure he fails and goes back to read it.