Messages in this thread Patch in this message | | | Date | Fri, 6 Jan 2017 09:28:44 +0000 | From | Charles Keepax <> | Subject | Re: [PATCH 3/3] mfd: arizona: Use regmap_read_poll_timeout instead of hard coding it |
| |
On Thu, Jan 05, 2017 at 02:48:22PM +0000, Lee Jones wrote: > 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 <ckeepax@opensource.wolfsonmicro.com> > > > > --- > > > > 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. >
Fair enough I will respin.
> > 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?
Yeah that's a fair point I will switch it around so the user specifies the total time out and npolls is worked out internally.
Thanks, Charles
| |