Date: Tue, 14 Mar 2017 18:44:25 +0000
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Lee Jones <lee.jones@linaro.org>
CC: <linux-kernel@vger.kernel.org>, <patches@opensource.wolfsonmicro.com>
Subject: Re: [PATCH RESEND 4/4] mfd: arizona: Use regmap_read_poll_timeout
 instead of hard coding it
Message-ID: <20170314184425.GE6986@localhost.localdomain>
References: <1489051715-4774-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
 <1489051715-4774-4-git-send-email-ckeepax@opensource.wolfsonmicro.com>
 <20170314170704.yfxy73v5jc2vj7zh@dell>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170314170704.yfxy73v5jc2vj7zh@dell>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1214
Lines: 29

On Tue, Mar 14, 2017 at 05:07:04PM +0000, Lee Jones wrote:
> On Thu, 09 Mar 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.
> > 
> > Whilst we are doing this make the timeouts a little more generous as the
> > previous system had a bit more slack as it was done as a delay per
> > iteration of the loop whereas regmap_read_poll_timeout compares ktime's.
> > 
> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> > ---
> >  drivers/mfd/arizona-core.c | 38 ++++++++++++++------------------------
> >  1 file changed, 14 insertions(+), 24 deletions(-)
> 
> Apart from patch count, is there any technical reason why this patch
> shouldn't just be rolled into patch 3?
> 

I prefer it as two patches as its clearer what happened from the
history. One patch changes the interface for the function, the
other updates the implementation. Can squash if you feel strongly
about it though?

Thanks,
Charles