From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932848AbcJ2Iuv (ORCPT ); Sat, 29 Oct 2016 04:50:51 -0400 Received: from mail-qk0-f182.google.com ([209.85.220.182]:36315 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754180AbcJ2Iuq (ORCPT ); Sat, 29 Oct 2016 04:50:46 -0400 MIME-Version: 1.0 In-Reply-To: References: <20161026190054.11968-1-ahaslam@baylibre.com> <20161026190054.11968-2-ahaslam@baylibre.com> <20161028182250.df6p6setaauxsezu@sirena.org.uk> From: Axel Haslam Date: Sat, 29 Oct 2016 10:50:05 +0200 Message-ID: Subject: Re: [RFC 1/3] regulator: core: Add over current changed event To: Mark Brown Cc: Liam Girdwood , Kevin Hilman , Sekhar Nori , David Lechner , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On Fri, Oct 28, 2016 at 9:41 PM, Axel Haslam wrote: > Hi Mark, > > On Fri, Oct 28, 2016 at 8:22 PM, Mark Brown wrote: >> On Wed, Oct 26, 2016 at 09:00:52PM +0200, ahaslam@baylibre.com wrote: >>> From: Axel Haslam >>> >>> Regulator consumers may be interested to know when the >>> over current condition is over. >>> >>> Add an over currerent "changed" event. The registered useres >>> for this event can then check the over current flag to know >>> the status of the over current condition. >> >> Would a more general event for error conditions work as well? Thinking >> about this I'm unclear how interested consumers are going to be in the >> specific error condition as opposed to the fact that the regulator ran >> into trouble, and I can imagine that some regulators will report the >> same root cause differently - another regulator might detect an >> excessive current draw by seeing the output voltage collapse and the >> regulator go out of regulation for example. > After some more thought, I can change the logic a bit, and send an event named something like: REGULATOR_EVENT_ERRORS_CLEARED would that make more sense? -Axel. > Sorry if i misunderstood, but if we make the name generic, > i think it might change a bit the definition of the flags, > The flags will not represent events, but states. > > i think today each time an event occurs a notification is sent with the > corresponding flag(s) set. > > if we use a generic name, It means that each time the regulator driver > sends an event, it should check which "other" error conditons tied to the > generic flag are present and set the corresponding bits too. > > illustrative example: > today over current and over temp are two different events > we send one notification for each with only the bits tied to the > event that is happening set. > > if we add a generic error flag, it would mean that if over current happens > and we set the generic error flag, we would also have to check > if over temp is present to set or not that flag. similarly, when the over > temp event happens the regulator driver would have to check if over > current is present too. >