Replace the use of udelay by usleep_range as suggested by checkpatch:

CHECK: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst
+               udelay(30);

CHECK: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst
+               udelay(50);

Signed-off-by: Tanjuate Brunostar <tanjubrunostar0@gmail.com>
---

v2: changed the max values of the usleep_rage instances as they cannot
be equal to the min values as suggested by checkpatch

 drivers/staging/rts5208/ms.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
index 14449f8afad5..a9724ca5eccf 100644
--- a/drivers/staging/rts5208/ms.c
+++ b/drivers/staging/rts5208/ms.c
@@ -3235,7 +3235,7 @@ static int ms_write_multiple_pages(struct rtsx_chip *chip, u16 old_blk,
 			return STATUS_FAIL;
 		}
 
-		udelay(30);
+		usleep_range(30, 31);
 
 		rtsx_init_cmd(chip);
 
@@ -4157,7 +4157,7 @@ int mg_set_ICV(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 #ifdef MG_SET_ICV_SLOW
 	for (i = 0; i < 2; i++) {
-		udelay(50);
+		usleep_range(50, 51);
 
 		rtsx_init_cmd(chip);
 
-- 
2.34.1

On Tue, Oct 18, 2022 at 04:04:02PM +0000, Tanjuate Brunostar wrote:
> Replace the use of udelay by usleep_range as suggested by checkpatch:
> 
> CHECK: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst
> +               udelay(30);
> 
> CHECK: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst
> +               udelay(50);
> 

Hi Tanjuate,

I'd expect the commit log here to tell me why this is preferable, and
why this is safe to do - basically your summary of what you found
when you considered the checkpatch error report and then read
timers-howto.rst.  Including that this was found my Checkpatch is
good, but that's basically a footnote to the log message, not the
main point.

Having said all that, I see GregKH response and that is typical
for this change. This type of change, needs to be actually tested,
so it's not a good cleanup unless you have the device or some other 
convincing proof that what you are doing is safe.

Outreachy advice:  when you see a checkpatch error, and are
wondering how its fix will be received, search the Outreachy
mail archive for it. This one, I find repeated instances of
the change being NAK'd because the submitter cannot test it.

Alison

> Signed-off-by: Tanjuate Brunostar <tanjubrunostar0@gmail.com>
> ---
> 
> v2: changed the max values of the usleep_rage instances as they cannot
> be equal to the min values as suggested by checkpatch
> 
>  drivers/staging/rts5208/ms.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
> index 14449f8afad5..a9724ca5eccf 100644
> --- a/drivers/staging/rts5208/ms.c
> +++ b/drivers/staging/rts5208/ms.c
> @@ -3235,7 +3235,7 @@ static int ms_write_multiple_pages(struct rtsx_chip *chip, u16 old_blk,
>  			return STATUS_FAIL;
>  		}
>  
> -		udelay(30);
> +		usleep_range(30, 31);
>  
>  		rtsx_init_cmd(chip);
>  
> @@ -4157,7 +4157,7 @@ int mg_set_ICV(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>  
>  #ifdef MG_SET_ICV_SLOW
>  	for (i = 0; i < 2; i++) {
> -		udelay(50);
> +		usleep_range(50, 51);
>  
>  		rtsx_init_cmd(chip);
>  
> -- 
> 2.34.1
> 
>

On Tue, Oct 18, 2022 at 04:04:02PM +0000, Tanjuate Brunostar wrote:
> Replace the use of udelay by usleep_range as suggested by checkpatch:
> 
> CHECK: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst
> +               udelay(30);
> 
> CHECK: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst
> +               udelay(50);
> 
> Signed-off-by: Tanjuate Brunostar <tanjubrunostar0@gmail.com>
> ---
> 
> v2: changed the max values of the usleep_rage instances as they cannot
> be equal to the min values as suggested by checkpatch
> 
>  drivers/staging/rts5208/ms.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
> index 14449f8afad5..a9724ca5eccf 100644
> --- a/drivers/staging/rts5208/ms.c
> +++ b/drivers/staging/rts5208/ms.c
> @@ -3235,7 +3235,7 @@ static int ms_write_multiple_pages(struct rtsx_chip *chip, u16 old_blk,
>  			return STATUS_FAIL;
>  		}
>  
> -		udelay(30);
> +		usleep_range(30, 31);

Did you test this?  And making the range 1 really doesn't make any
sense, right?

thanks,

greg k-h

On Tue, Oct 18, 2022 at 07:06:27PM +0200, Greg KH wrote:

<snip>

For some reason you sent this only to me, which is a bit rude to
everyone else on the mailing list.  I'll be glad to respond if you
resend it to everyone.

thanks,

greg k-h

On Tue, Oct 18, 2022 at 07:49:33PM +0200, Greg KH wrote:
> On Tue, Oct 18, 2022 at 07:06:27PM +0200, Greg KH wrote:
> 
> <snip>
> 
> For some reason you sent this only to me, which is a bit rude to
> everyone else on the mailing list.  I'll be glad to respond if you
> resend it to everyone.

Oops, wrong response, I'll send this to the private response that was
sent to me, not this one :)