From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752629AbbBJHum (ORCPT ); Tue, 10 Feb 2015 02:50:42 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:58548 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752389AbbBJHuk (ORCPT ); Tue, 10 Feb 2015 02:50:40 -0500 Date: Tue, 10 Feb 2015 15:08:47 +0800 From: Mark Brown To: Bjorn Andersson Cc: Bjorn Andersson , Liam Girdwood , "agross@codeaurora.org" , "linux-arm-msm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "patches@opensource.wolfsonmicro.com" Message-ID: <20150210070847.GH2593@finisterre.sirena.org.uk> References: <1422413199-17273-1-git-send-email-bjorn.andersson@sonymobile.com> <1422413199-17273-3-git-send-email-bjorn.andersson@sonymobile.com> <20150128195204.GN21293@sirena.org.uk> <20150130000741.GP11960@sonymobile.com> <20150130122714.GA26617@finisterre.sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lrvsYIebpInmECXG" Content-Disposition: inline In-Reply-To: X-Cookie: What is the sound of one hand clapping? User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 210.177.145.249 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 2/9] regulator: core: Introduce set_optimum_mode op X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --lrvsYIebpInmECXG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 09, 2015 at 02:08:41PM -0800, Bjorn Andersson wrote: > You said something when we talked that I interpreted to > regulator_set_optimum_mode() is not a good name for the consumer API; > was that a correct interpretation or was your comment limited to the > driver facing API? > Should we go ahead and rename it to regulator_notify_load() > (regulator_set_load() perhaps?) before we get more consumers as well? > (would be a separate patch set) This can be _set_load() I think since we are actually telling the framework about the expected load but yes, we should rename it to reflect what we're actually doing. > But if we're only considering load in drms_uA_update() does it make > sense to check this against the valid ranges of min_uA, max_uA and > hence instead of checking REGULATOR_CHANGE_DRMS just check for > REGULATOR_CHANGE_CURRENT? > We have reduced the interface to not necessarily be dynamic _mode_ setting. No, _CHANGE_CURRENT is about current reglators which are a different thing to voltage regulators. > >> I think this covers your concern about patch 3-7 as well, please let me > >> know what you think. > > Possibly. > Well, my question is still there: > Unless we replace the get_optimum_mode()/set_mode() pair with > notify_load() the driver API logic will become confusing; so for the > regulators that to day implement that combo I think we need patch 3-7 > as well. That's not a question, that's a statement... Since we don't currently have a notify_load() interface we obviously don't have any drivers using it so I'm not sure what drivers will become confusing here or how this addresses the part about keeping the operations split for the common pattern? --lrvsYIebpInmECXG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU2a56AAoJECTWi3JdVIfQGqgH/2O5E15Z9eJmA+qzYvg6eiiU rm1JQ2a+1cUP6IFRsL6r0ChgTkQa7IK6fGAF61Eo5h3u03JUzt/sfeW3auBu5XvC sd1ZBSFtwNWhCG6MGXBHsJuhd2DGuzTmgdSdSJ6qLdOWYVQi+2YRzFSKyyMe2eeP uskFupS9ljeukuPG0CR/65nYkpBfYTlTz5xCNcOZlyPAX/L6w6b0Ixt4WYNIbADY bppeDi5zNJISdQPtOKD0hxYzDhs1VtJzKLxIVU8NkFAgktDu/9iEUr3TccL0297V 11x8CiZHU6p3XGVMoy7aKhJXl/dpgsbyLzoZl+QgUGp9RgInVswVOGgcJkuY3lk= =nSy0 -----END PGP SIGNATURE----- --lrvsYIebpInmECXG--