* [PATCH] staging: greybus: Use fsleep() for delay @ 2026-10-22 11:02 pavankumaryalagada 2026-10-22 11:28 ` Johan Hovold 2026-10-22 13:28 ` Alex Elder 0 siblings, 2 replies; 5+ messages in thread From: pavankumaryalagada @ 2026-10-22 11:02 UTC (permalink / raw) To: greybus-dev, outreachy Cc: pure.logic, johan, elder, gregkh, linux-staging, linux-kernel, Yalagada Pavan Kumar, Alex Elder From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> In the loopback function, usleep_range() is used for short delays and msleep() for longer delays. This requires choosing the delay function based on the requested time and converting microseconds to milliseconds when using msleep(). Replace both functions with fsleep(), which selects a suitable delay method based on the requested time. This avoids the need to choose the delay function and convert the time manually. Suggested-by: Alex Elder <elder@riscstar.com> Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> --- drivers/staging/greybus/loopback.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c index efc69c10cffe..2fe845eaef29 100644 --- a/drivers/staging/greybus/loopback.c +++ b/drivers/staging/greybus/loopback.c @@ -898,12 +898,8 @@ static int gb_loopback_fn(void *data) gb->send_count++; mutex_unlock(&gb->mutex); - if (us_wait) { - if (us_wait < 20000) - usleep_range(us_wait, us_wait + 100); - else - msleep(us_wait / 1000); - } + if (us_wait) + fsleep(us_wait); } gb_pm_runtime_put_autosuspend(bundle); -- 2.43.0 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] staging: greybus: Use fsleep() for delay 2026-10-22 11:02 [PATCH] staging: greybus: Use fsleep() for delay pavankumaryalagada @ 2026-10-22 11:28 ` Johan Hovold 2026-10-22 13:28 ` Alex Elder 1 sibling, 0 replies; 5+ messages in thread From: Johan Hovold @ 2026-10-22 11:28 UTC (permalink / raw) To: pavankumaryalagada Cc: greybus-dev, outreachy, pure.logic, elder, gregkh, linux-staging, linux-kernel, Alex Elder On Thu, Oct 22, 2026 at 04:32:38PM +0530, pavankumaryalagada@gmail.com wrote: > From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> > > In the loopback function, usleep_range() is used for short delays > and msleep() for longer delays. This requires choosing the delay > function based on the requested time and converting microseconds > to milliseconds when using msleep(). Please include the module in Subject since this is not a subsystem wide change: staging: greybus: loopback: ... > Replace both functions with fsleep(), which selects a suitable > delay method based on the requested time. This avoids the need > to choose the delay function and convert the time manually. It probably doesn't matter here, but I think you should mentioned that fsleep() will likely make short sleeps longer (25% instead of 100 us slack). Johan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] staging: greybus: Use fsleep() for delay 2026-10-22 11:02 [PATCH] staging: greybus: Use fsleep() for delay pavankumaryalagada 2026-10-22 11:28 ` Johan Hovold @ 2026-10-22 13:28 ` Alex Elder 2026-10-22 19:14 ` Yalagada Pavan Kumar 1 sibling, 1 reply; 5+ messages in thread From: Alex Elder @ 2026-10-22 13:28 UTC (permalink / raw) To: pavankumaryalagada, greybus-dev, outreachy Cc: pure.logic, johan, elder, gregkh, linux-staging, linux-kernel On 10/22/26 6:02 AM, pavankumaryalagada@gmail.com wrote: > From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> > > In the loopback function, usleep_range() is used for short delays > and msleep() for longer delays. This requires choosing the delay > function based on the requested time and converting microseconds > to milliseconds when using msleep(). > > Replace both functions with fsleep(), which selects a suitable > delay method based on the requested time. This avoids the need > to choose the delay function and convert the time manually. > > Suggested-by: Alex Elder <elder@riscstar.com> > Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> Your description above is pretty good, but I agree with Johan's comment. In fact, you should think about and understand exactly how that behavior changes with the switch to using fsleep(). - When would the delay be different from before? - When it differs--by how much does it differ? - Is this amount significant? And the third question gets at exactly what Johan was saying should be included in the patch description. We want to know not just the mechanics of the change, but at a higher level, what is its effect? You don't need to provide a super high level of detail in this particular change, but you should demonstrate somehow that you've thought about these things. Please submit a new version of the patch and reword the description a bit to concisely capture why it makes sense to make the change, and why you believe that the change in behavior is likely harmless. Thanks. -Alex > --- > drivers/staging/greybus/loopback.c | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c > index efc69c10cffe..2fe845eaef29 100644 > --- a/drivers/staging/greybus/loopback.c > +++ b/drivers/staging/greybus/loopback.c > @@ -898,12 +898,8 @@ static int gb_loopback_fn(void *data) > gb->send_count++; > mutex_unlock(&gb->mutex); > > - if (us_wait) { > - if (us_wait < 20000) > - usleep_range(us_wait, us_wait + 100); > - else > - msleep(us_wait / 1000); > - } > + if (us_wait) > + fsleep(us_wait); > } > > gb_pm_runtime_put_autosuspend(bundle); ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] staging: greybus: Use fsleep() for delay 2026-10-22 13:28 ` Alex Elder @ 2026-10-22 19:14 ` Yalagada Pavan Kumar 2026-10-22 19:29 ` Alex Elder 0 siblings, 1 reply; 5+ messages in thread From: Yalagada Pavan Kumar @ 2026-10-22 19:14 UTC (permalink / raw) To: Alex Elder Cc: greybus-dev, outreachy, pure.logic, johan, elder, gregkh, linux-staging, linux-kernel On Thu, Oct 22, 2026 at 08:28:23AM -0500, Alex Elder wrote: > On 10/22/26 6:02 AM, pavankumaryalagada@gmail.com wrote: > > From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> > > > > In the loopback function, usleep_range() is used for short delays > > and msleep() for longer delays. This requires choosing the delay > > function based on the requested time and converting microseconds > > to milliseconds when using msleep(). > > > > Replace both functions with fsleep(), which selects a suitable > > delay method based on the requested time. This avoids the need > > to choose the delay function and convert the time manually. > > > > Suggested-by: Alex Elder <elder@riscstar.com> > > Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> > > Your description above is pretty good, but I agree with > Johan's comment. In fact, you should think about and > understand exactly how that behavior changes with the > switch to using fsleep(). > - When would the delay be different from before? > - When it differs--by how much does it differ? The current code uses usleep_range() for delays below 20 milliseconds and msleep() for longer delays. When using msleep(), it converts microseconds to milliseconds by rounding down, which can make the delay shorter than requested. For example, a requested delay of 20,500 microseconds becomes msleep(20), which requests a 20 millisecond sleep. With fsleep(), the kernel selects the delay method based on the requested time. For a 1000 microsecond delay, the current code allows 100 microseconds of extra time, while fsleep() allows up to 250 microseconds. > - Is this amount significant? > And the third question gets at exactly what Johan was > saying should be included in the patch description. > > We want to know not just the mechanics of the change, > but at a higher level, what is its effect? The change may affect the time between loopback operations and the reported performance. The code does not seem to need an exact delay, so i think using fsleep() is reasonable. However, testing is needed to confirm its actual effect. I do not have Greybus hardware to test the driver at runtime, so my assessment is based on reviewing the code and fsleep() implementation. If possible, could you please check the runtime behavior or and let me know if you find any issues with this change? Thanks, Pavan > > You don't need to provide a super high level of detail > in this particular change, but you should demonstrate > somehow that you've thought about these things. > > Please submit a new version of the patch and reword > the description a bit to concisely capture why it > makes sense to make the change, and why you believe > that the change in behavior is likely harmless. > > Thanks. > > -Alex > > > --- > > drivers/staging/greybus/loopback.c | 8 ++------ > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c > > index efc69c10cffe..2fe845eaef29 100644 > > --- a/drivers/staging/greybus/loopback.c > > +++ b/drivers/staging/greybus/loopback.c > > @@ -898,12 +898,8 @@ static int gb_loopback_fn(void *data) > > gb->send_count++; > > mutex_unlock(&gb->mutex); > > - if (us_wait) { > > - if (us_wait < 20000) > > - usleep_range(us_wait, us_wait + 100); > > - else > > - msleep(us_wait / 1000); > > - } > > + if (us_wait) > > + fsleep(us_wait); > > } > > gb_pm_runtime_put_autosuspend(bundle); > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] staging: greybus: Use fsleep() for delay 2026-10-22 19:14 ` Yalagada Pavan Kumar @ 2026-10-22 19:29 ` Alex Elder 0 siblings, 0 replies; 5+ messages in thread From: Alex Elder @ 2026-10-22 19:29 UTC (permalink / raw) To: Yalagada Pavan Kumar Cc: greybus-dev, outreachy, pure.logic, johan, elder, gregkh, linux-staging, linux-kernel On 10/22/26 2:14 PM, Yalagada Pavan Kumar wrote: > On Thu, Oct 22, 2026 at 08:28:23AM -0500, Alex Elder wrote: >> On 10/22/26 6:02 AM, pavankumaryalagada@gmail.com wrote: >>> From: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> >>> >>> In the loopback function, usleep_range() is used for short delays >>> and msleep() for longer delays. This requires choosing the delay >>> function based on the requested time and converting microseconds >>> to milliseconds when using msleep(). >>> >>> Replace both functions with fsleep(), which selects a suitable >>> delay method based on the requested time. This avoids the need >>> to choose the delay function and convert the time manually. >>> >>> Suggested-by: Alex Elder <elder@riscstar.com> >>> Signed-off-by: Yalagada Pavan Kumar <pavankumaryalagada@gmail.com> >> >> Your description above is pretty good, but I agree with >> Johan's comment. In fact, you should think about and >> understand exactly how that behavior changes with the >> switch to using fsleep(). >> - When would the delay be different from before? >> - When it differs--by how much does it differ? FYI, I was not really looking for a response here (other than you sending a new version of the patch that provides some additional information). I was simply suggesting the way you should approach making a change like this. > The current code uses usleep_range() for delays below 20 > milliseconds and msleep() for longer delays. When using > msleep(), it converts microseconds to milliseconds by > rounding down, which can make the delay shorter than > requested. > > For example, a requested delay of 20,500 microseconds > becomes msleep(20), which requests a 20 millisecond > sleep. > > With fsleep(), the kernel selects the delay method > based on the requested time. For a 1000 microsecond > delay, the current code allows 100 microseconds of > extra time, while fsleep() allows up to 250 microseconds. Well it depends on the value of HZ, but I think it's typically 1000. >> - Is this amount significant? >> And the third question gets at exactly what Johan was >> saying should be included in the patch description. >> >> We want to know not just the mechanics of the change, >> but at a higher level, what is its effect? > > The change may affect the time between loopback operations > and the reported performance. The code does not seem to > need an exact delay, so i think using fsleep() is reasonable. > However, testing is needed to confirm its actual effect. This is technically right, but you have already shown a little intuition about what the change does. And my point was that you should approach making changes to the code with this kind of analysis in mind. Simple fixups like this are great, but ideally they should produce *zero* change in behavior. In this particular case, there *is* a change, and you should make sure you understand it, and as Johan suggested, make a comment on it. > I do not have Greybus hardware to test the driver at runtime, > so my assessment is based on reviewing the code and fsleep() > implementation. > > If possible, could you please check the runtime behavior or > and let me know if you find any issues with this change? I am not set up to do any testing like this either. I don't think you strictly need to test this (other than doing compile testing and things like checkpatch). I'm just trying to suggest good practice for you to follow when proposing changes. -Alex> > Thanks, > Pavan > >> >> You don't need to provide a super high level of detail >> in this particular change, but you should demonstrate >> somehow that you've thought about these things. >> >> Please submit a new version of the patch and reword >> the description a bit to concisely capture why it >> makes sense to make the change, and why you believe >> that the change in behavior is likely harmless. >> >> Thanks. >> >> -Alex >> >>> --- >>> drivers/staging/greybus/loopback.c | 8 ++------ >>> 1 file changed, 2 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/staging/greybus/loopback.c b/drivers/staging/greybus/loopback.c >>> index efc69c10cffe..2fe845eaef29 100644 >>> --- a/drivers/staging/greybus/loopback.c >>> +++ b/drivers/staging/greybus/loopback.c >>> @@ -898,12 +898,8 @@ static int gb_loopback_fn(void *data) >>> gb->send_count++; >>> mutex_unlock(&gb->mutex); >>> - if (us_wait) { >>> - if (us_wait < 20000) >>> - usleep_range(us_wait, us_wait + 100); >>> - else >>> - msleep(us_wait / 1000); >>> - } >>> + if (us_wait) >>> + fsleep(us_wait); >>> } >>> gb_pm_runtime_put_autosuspend(bundle); >> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-10-22 19:29 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-10-22 11:02 [PATCH] staging: greybus: Use fsleep() for delay pavankumaryalagada 2026-10-22 11:28 ` Johan Hovold 2026-10-22 13:28 ` Alex Elder 2026-10-22 19:14 ` Yalagada Pavan Kumar 2026-10-22 19:29 ` Alex Elder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®