Switch from udelay() to fsleep() in drv260x_worker() as it runs in a
sleepable workqueue context where busy-waiting is unnecessary.

Assisted-by: LLM
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/input/misc/drv260x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 6c5c4c53753b..477ec84ea09b 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -222,7 +222,7 @@ static void drv260x_worker(struct work_struct *work)
 
 	gpiod_set_value(haptics->enable_gpio, 1);
 	/* Data sheet says to wait 250us before trying to communicate */
-	udelay(250);
+	fsleep(250);
 
 	error = regmap_write(haptics->regmap,
 			     DRV260X_MODE, DRV260X_RT_PLAYBACK);
-- 
2.55.0.897.gb25b4bd76c-goog


-- 
Dmitry

Hi Dmitry,

I tested this patch unchanged on a Lenovo Yoga Book YB1-X91L with
both onboard TI DRV2604 devices (ACPI DRV2604:00 and DRV2604:01).

The test kernel was built from commit
e5e85128bb7ce1bda7cfd7055be9821ac42b8108 and reported
7.2.0-yogabook-20260831-202310. The validation covered:

- 20 open/upload/close cycles on each device;
- strong and weak FF_RUMBLE effects on both devices;
- three s2idle suspend/resume cycles;
- repeated FF_RUMBLE playback on both devices after every resume.

All operations completed successfully, and the kernel log contained no
drv260x, I2C, regulator, or workqueue errors related to these devices.

Tested-by: Maurizio Casciano <mauriziocasciano7@gmail.com>

With Best Regards,
Maurizio Casciano