On Sat, Jul 09, 2022 at 12:30:51PM +0200, Greg KH wrote: > On Sat, Jul 09, 2022 at 01:06:56PM +0300, Christos Kollintzas wrote: > > Adhere to Linux kernel coding style. > > > > Reported by checkpatch: > > > > CHECK: usleep_range is preferred over udelay > > > > Signed-off-by: Christos Kollintzas <c.kollintzas.92@xxxxxxxxx> > > --- > > drivers/staging/fbtft/fb_upd161704.c | 18 +++++++++--------- > > 1 file changed, 9 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c > > index c680160d6380..eeafbab4ace1 100644 > > --- a/drivers/staging/fbtft/fb_upd161704.c > > +++ b/drivers/staging/fbtft/fb_upd161704.c > > @@ -32,27 +32,27 @@ static int init_display(struct fbtft_par *par) > > > > /* oscillator start */ > > write_reg(par, 0x003A, 0x0001); /*Oscillator 0: stop, 1: operation */ > > - udelay(100); > > + usleep_range(100, 110); > > When doing these types of changes, you really need access to the > hardware involved in order to be able to properly test it. > > Especially for this type of function which is trying to do timing > changes which the hardware requires. > > Did you test this on the real hardware and did it work properly? > > thanks, > > greg k-h I did not. I will try to find the hardware and send a patch that is properly tested. thanks, Christos Kollintzas
