From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034075AbdAEOpZ (ORCPT ); Thu, 5 Jan 2017 09:45:25 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:37805 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034060AbdAEOpP (ORCPT ); Thu, 5 Jan 2017 09:45:15 -0500 Date: Thu, 5 Jan 2017 14:48:22 +0000 From: Lee Jones To: Charles Keepax Cc: patches@opensource.wolfsonmicro.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] mfd: arizona: Use regmap_read_poll_timeout instead of hard coding it Message-ID: <20170105144822.GS24225@dell> References: <1483542655-19980-1-git-send-email-ckeepax@opensource.wolfsonmicro.com> <1483542655-19980-3-git-send-email-ckeepax@opensource.wolfsonmicro.com> <20170105080701.GJ24225@dell> <20170105100528.GS1867@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170105100528.GS1867@localhost.localdomain> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 05 Jan 2017, Charles Keepax wrote: > On Thu, Jan 05, 2017 at 08:07:01AM +0000, Lee Jones wrote: > > On Wed, 04 Jan 2017, Charles Keepax wrote: > > > > > arizona_poll_reg essentially hard-codes regmap_read_poll_timeout, this > > > patch updates the implementation to use regmap_read_poll_timeout. We > > > still keep arizona_poll_reg around as regmap_read_poll_timeout is a > > > macro so rather than expand this for each caller keep it wrapped in > > > arizona_poll_reg. > > > > > > Signed-off-by: Charles Keepax > > > --- > > > drivers/mfd/arizona-core.c | 28 +++++++++++----------------- > > > 1 file changed, 11 insertions(+), 17 deletions(-) > > > > > > diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c > > > index 4cb34c3..e6fae3c 100644 > > > --- a/drivers/mfd/arizona-core.c > > > +++ b/drivers/mfd/arizona-core.c > > > @@ -236,28 +236,22 @@ static irqreturn_t arizona_overclocked(int irq, void *data) > > > } > > > > > > static int arizona_poll_reg(struct arizona *arizona, > > > - int timeout, unsigned int reg, > > > + int npolls, unsigned int reg, > > > unsigned int mask, unsigned int target) > > > { > > > + const int poll_us = 7500; > > > > Get rid of this and replace its usage with a nice #define describing > > exactly what the timeout is for i.e what timed out. > > > > I can replace this with a define if you prefer although since the > value is only used locally I generally prefer a const variable as > it keeps all the relevant code together. I'd prefer a DEFINE, then you can rid the requirement for a variable altogether. > > ... okay, I just read the doc. This should really be 'SLEEP'. > > > > Where did 7500 come from anyway? Is it documented? > > > > To be fair this number is a little pulled from my ... err the > air. But basically provides a reasonable balance of timing > between polls for the various users of the function. It didn't > really seem worth having each user specify its own timing for > this part as we generally don't care down to a couple of mS here > or there. Very well. If you define it I'll ask no more questions. ;) > > > unsigned int val = 0; > > > - int ret, i; > > > - > > > - for (i = 0; i < timeout; i++) { > > > - ret = regmap_read(arizona->regmap, reg, &val); > > > - if (ret != 0) { > > > - dev_err(arizona->dev, "Failed to read reg 0x%x: %d\n", > > > - reg, ret); > > > - continue; > > > - } > > > - > > > - if ((val & mask) == target) > > > - return 0; > > > + int ret; > > > > > > - usleep_range(1000, 5000); > > > - } > > > + ret = regmap_read_poll_timeout(arizona->regmap, > > > + ARIZONA_INTERRUPT_RAW_STATUS_5, val, > > > + ((val & mask) == target), poll_us, > > > + npolls * poll_us); > > > > What's the relevance of npolls? Is this number documented, or was it > > pulled from your ... err, the air? > > > > Its an argument passed into the function, its called npolls in a > function that polls a register I really don't know how to make > the fact it is the number of polls to do any more clear than I can see what it's used for, I am more concerned about the number passed in. > that. As for the number passed into the function that depends on > how long that particular register should be polled for, this is a > function that is used in several places for polling for a > particular register state. I would have thought a consumer would be more likely to know how long it would poll for, rather than how many times to poll. Knowledge of time-between-polls in only known locally. Do you see where I'm going with this? > Would all these issues perhaps be best solved by my adding some > kernel doc for the function with some more description of what > everything is? I don't think so, to be honest. > > > + if (ret) > > > + dev_err(arizona->dev, "Polling reg 0x%x timed out: %x\n", > > > + reg, val); > > > > > > - dev_err(arizona->dev, "Polling reg 0x%x timed out: %x\n", reg, val); > > > - return -ETIMEDOUT; > > > + return ret; > > > } > > > > > > static int arizona_wait_for_boot(struct arizona *arizona) > > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog