Re: [PATCH v4] staging: dgnc: replace udelay with usleep_range

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Feb 28, 2017 at 11:48:38AM +0530, Aishwarya Pant wrote:
> On Mon, Feb 27, 2017 at 10:04:45PM +0530, Aishwarya Pant wrote:
> > Fix checkpatch warning on dgnc_cls.c : CHECK usleep_range
> > is preferred over udelay. There is one ocurrence of udelay in
> > function cls_uart_init with non-atomic context that can be safely
> > replaced by usleep_range(t, t + delta) where delta is t (as t is
> > between 10 and 20 microseconds). Also replace usleep_range by udelay in
> > function cls_flush_uart_write as it is called under a channel lock.
> > 
> > Signed-off-by: Aishwarya Pant <aishpant@gmail.com>
> > ---
> > Changes in v4:
> > 	- Fix commit message formatting
> > 
> > Changes in v3:
> > 	- Replace usleep_range by udelay in cls_flush_uart_write
> > 	- Fix diff in commit message
> > 
> > Changes in v2:
> > 	- Revert usage of usleep_range in atomic context
> > 	- Cleanup the commit message
> > 
> >  drivers/staging/dgnc/dgnc_cls.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
> > index c20ffdd..7068c3b 100644
> > --- a/drivers/staging/dgnc/dgnc_cls.c
> > +++ b/drivers/staging/dgnc/dgnc_cls.c
> > @@ -609,7 +609,7 @@ static void cls_flush_uart_write(struct channel_t *ch)
> >  
> >  	writeb((UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_XMIT),
> >  	       &ch->ch_cls_uart->isr_fcr);
> > -	usleep_range(10, 20);
> > +	udelay(10);
> >  
> >  	ch->ch_flags |= (CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM);
> >  }
> > @@ -1096,7 +1096,7 @@ static void cls_uart_init(struct channel_t *ch)
> >  
> >  	writeb(UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
> >  	       &ch->ch_cls_uart->isr_fcr);
> > -	udelay(10);
> > +	usleep_range(10, 20);
> >  
> >  	ch->ch_flags |= (CH_FIFO_ENABLED | CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM);
> >  
> > -- 
> > 2.7.4
> >
> 
> 
> Since delays are something I cannot test if it works well on all
> hardware, should I move on to some other cleanup and not tamper with
> delays?

Yes please.