[PATCH] staging: nvec: replace udelay with usleep_range

ShadowMonkee posted 1 patch 1 month, 2 weeks ago
drivers/staging/nvec/nvec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] staging: nvec: replace udelay with usleep_range
Posted by ShadowMonkee 1 month, 2 weeks ago
udelay() was used for a short delay in the NVEC I2C receive path.
Replace it with usleep_range(), which is preferred as it avoids
busy-waiting and allows the scheduler to run other tasks.

Signed-off-by: ShadowMonkee <sshadowmonkeyy@gmail.com>
---
 drivers/staging/nvec/nvec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 263774e6a78c..dd92f186e0db 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -648,7 +648,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
 		break;
 	case 2:		/* first byte after command */
 		if (status == (I2C_SL_IRQ | RNW | RCVD)) {
-			udelay(33);
+			usleep_range(33, 34);
 			if (nvec->rx->data[0] != 0x01) {
 				dev_err(nvec->dev,
 					"Read without prior read command\n");
-- 
2.52.0
Re: [PATCH] staging: nvec: replace udelay with usleep_range
Posted by Greg Kroah-Hartman 1 month, 2 weeks ago
On Wed, Dec 24, 2025 at 12:16:51PM +0100, ShadowMonkee wrote:
> udelay() was used for a short delay in the NVEC I2C receive path.
> Replace it with usleep_range(), which is preferred as it avoids
> busy-waiting and allows the scheduler to run other tasks.
> 
> Signed-off-by: ShadowMonkee <sshadowmonkeyy@gmail.com>
> ---
>  drivers/staging/nvec/nvec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
> index 263774e6a78c..dd92f186e0db 100644
> --- a/drivers/staging/nvec/nvec.c
> +++ b/drivers/staging/nvec/nvec.c
> @@ -648,7 +648,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>  		break;
>  	case 2:		/* first byte after command */
>  		if (status == (I2C_SL_IRQ | RNW | RCVD)) {
> -			udelay(33);
> +			usleep_range(33, 34);
>  			if (nvec->rx->data[0] != 0x01) {
>  				dev_err(nvec->dev,
>  					"Read without prior read command\n");
> -- 
> 2.52.0
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file,
  Documentation/process/submitting-patches.rst for how to do this
  correctly.

- You sent a patch that has been sent multiple times in the past and is
  identical to ones that has been recently rejected.  Please always look
  at the mailing list traffic to determine if you are duplicating other
  people's work.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
Re: [PATCH] staging: nvec: replace udelay with usleep_range
Posted by Marc Dietrich 1 month, 2 weeks ago
Hi all,

I don't remember anymore where this delay came from, but I think we can
get rid of it alltogether after the fix for i2c writes landed. Somehow I
had overlooked it at the time.
I will try without my machine and see if it works (and also send a patch
afterwards).

Best wishes,
Marc


On Wed, 24 Dec 2025, Greg Kroah-Hartman wrote:

> On Wed, Dec 24, 2025 at 12:16:51PM +0100, ShadowMonkee wrote:
>> udelay() was used for a short delay in the NVEC I2C receive path.
>> Replace it with usleep_range(), which is preferred as it avoids
>> busy-waiting and allows the scheduler to run other tasks.
>>
>> Signed-off-by: ShadowMonkee <sshadowmonkeyy@gmail.com>
>> ---
>>  drivers/staging/nvec/nvec.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
>> index 263774e6a78c..dd92f186e0db 100644
>> --- a/drivers/staging/nvec/nvec.c
>> +++ b/drivers/staging/nvec/nvec.c
>> @@ -648,7 +648,7 @@ static irqreturn_t nvec_interrupt(int irq, void *dev)
>>  		break;
>>  	case 2:		/* first byte after command */
>>  		if (status == (I2C_SL_IRQ | RNW | RCVD)) {
>> -			udelay(33);
>> +			usleep_range(33, 34);
>>  			if (nvec->rx->data[0] != 0x01) {
>>  				dev_err(nvec->dev,
>>  					"Read without prior read command\n");
>> --
>> 2.52.0
>>
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
> a patch that has triggered this response.  He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created.  Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - It looks like you did not use your "real" name for the patch on either
>  the Signed-off-by: line, or the From: line (both of which have to
>  match).  Please read the kernel file,
>  Documentation/process/submitting-patches.rst for how to do this
>  correctly.
>
> - You sent a patch that has been sent multiple times in the past and is
>  identical to ones that has been recently rejected.  Please always look
>  at the mailing list traffic to determine if you are duplicating other
>  people's work.
>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot
>
>