linux-kernel - Re: [PATCH RESEND 3/4] mfd: arizona: Update arizona_poll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Feb 2017 11:18:38 +0000
From:   Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:     Lee Jones <lee.jones@...aro.org>
CC:     <linux-kernel@...r.kernel.org>,
        <patches@...nsource.wolfsonmicro.com>
Subject: Re: [PATCH RESEND 3/4] mfd: arizona: Update arizona_poll_reg to take
 a timeout in milliseconds

On Wed, Feb 08, 2017 at 10:04:58AM +0000, Lee Jones wrote:
> On Tue, 31 Jan 2017, Charles Keepax wrote:
> 
> > Currently, we specify the timeout in terms of the number of polls but it
> > is more clear from a user of the functions perspective to specify the
> > timeout directly in milliseconds, as such update the function to these new
> > semantics.
> > 
> > Signed-off-by: Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
> > ---
> >  drivers/mfd/arizona-core.c | 17 +++++++++++------
> >  1 file changed, 11 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> > index 4cb34c3..ae4cdc4 100644
> > --- a/drivers/mfd/arizona-core.c
> > +++ b/drivers/mfd/arizona-core.c
> > @@ -235,14 +235,18 @@ static irqreturn_t arizona_overclocked(int irq, void *data)
> >  	return IRQ_HANDLED;
> >  }
> >  
> > +#define ARIZONA_REG_POLL_DELAY_MS 5
> > +
> >  static int arizona_poll_reg(struct arizona *arizona,
> > -			    int timeout, unsigned int reg,
> > +			    int timeout_ms, unsigned int reg,
> >  			    unsigned int mask, unsigned int target)
> >  {
> > +	unsigned int npolls = (timeout_ms + ARIZONA_REG_POLL_DELAY_MS - 1) /
> > +			      ARIZONA_REG_POLL_DELAY_MS;
> 
> Why the over-complication?
> 
> Shouldn't this just be "timeout_ms / ARIZONA_REG_POLL_DELAY_MS"?

This will often give you less than the requested timeout if the
requested timeout is not an exact multiple of
ARIZONA_REG_POLL_DELAY_MS. We should never give less timeout than
requested although more is always going to be fine.

> 
> >  	unsigned int val = 0;
> >  	int ret, i;
> >  
> > -	for (i = 0; i < timeout; i++) {
> > +	for (i = 0; i < npolls; i++) {
> >  		ret = regmap_read(arizona->regmap, reg, &val);
> >  		if (ret != 0) {
> >  			dev_err(arizona->dev, "Failed to read reg 0x%x: %d\n",
> > @@ -253,7 +257,8 @@ static int arizona_poll_reg(struct arizona *arizona,
> >  		if ((val & mask) == target)
> >  			return 0;
> >  
> > -		usleep_range(1000, 5000);
> > +		usleep_range((ARIZONA_REG_POLL_DELAY_MS * 1000) / 2,
> > +			     ARIZONA_REG_POLL_DELAY_MS * 1000);
> 
> I'm sure there is a macro for conversion from ms to us.
> 

I will have a look see if I can find it.

> By using such a wide range, you are now not honouring the timeout set
> by the caller by as much as 50%.
> 

Yes apologies my fault here, we really should be applying the
adjustment to the maximum not the minimum here. I don't see a
problem with the wide range, getting more timeout than we asked
for is never going to be a problem but less is. I will respin.

Thanks,
Charles