DRV260x: Support ACPI-enumerated devices

DRV260x: Support ACPI-enumerated devices

[Yauhen Kharuzhy]

Lenovo Yoga Book YB1-X90 and YB1-X91 tablets use haptics controllers
DRV2604L. The X91 (Windows tablet) uses ACPI to define its configuration,
such as I2C address and GPIO connections. The X90 (Android tablet)
doesn't have it in the ACPI, but the device may be defined as an
i2c_board in the x86-android-tablets driver.

To support these variants, add an ACPI matching table and add additional
I2C IDs to the I2C matching table (the driver supports DRV2604(L),
DRV2605(L) devices).

Also, add verification of the device ID on start, implement a timeout
for waiting for effect playback, and fix the non-working suspend in case
the 'vbat' regulator doesn't exist in the system.

[PATCH 1/5] input: drv260x: Add I2C IDs for all device variants

[Yauhen Kharuzhy]

Add drv2604(L) and drv2605 to the list of supported I2C device IDs
for clarity.

Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
---
 drivers/input/misc/drv260x.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 96cd6a078c8a..18360bdfe877 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -598,6 +598,9 @@ static int drv260x_resume(struct device *dev)
 static DEFINE_SIMPLE_DEV_PM_OPS(drv260x_pm_ops, drv260x_suspend, drv260x_resume);
 
 static const struct i2c_device_id drv260x_id[] = {
+	{ "drv2604" },
+	{ "drv2604l" },
+	{ "drv2605" },
 	{ "drv2605l" },
 	{ }
 };
-- 
2.51.0

[PATCH 2/5] input: drv260x: Add support for ACPI-enumerated devices

[Yauhen Kharuzhy]

Add ACPI ids and GPIO lookup mapping for drv2604 haptics device.
Found in Lenovo Yoga Book YB1-X91L tablet.

Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
---
 drivers/input/misc/drv260x.c | 30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 18360bdfe877..f613c81fa2ba 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -15,6 +15,7 @@
 #include <linux/delay.h>
 #include <linux/gpio/consumer.h>
 #include <linux/regulator/consumer.h>
+#include <linux/acpi.h>
 
 #include <dt-bindings/input/ti-drv260x.h>
 
@@ -419,6 +420,12 @@ static const struct regmap_config drv260x_regmap_config = {
 	.cache_type = REGCACHE_NONE,
 };
 
+static const struct acpi_gpio_params enable_gpio = { 0, 0, false };
+static const struct acpi_gpio_mapping acpi_drv260x_default_gpios[] = {
+	{ "enable-gpio", &enable_gpio, 1 },
+	{ }
+};
+
 static int drv260x_probe(struct i2c_client *client)
 {
 	struct device *dev = &client->dev;
@@ -426,6 +433,14 @@ static int drv260x_probe(struct i2c_client *client)
 	u32 voltage;
 	int error;
 
+	if (has_acpi_companion(dev)) {
+		error = devm_acpi_dev_add_driver_gpios(dev, acpi_drv260x_default_gpios);
+		if (error) {
+			dev_err(dev, "can't add GPIO ACPI mapping\n");
+			return error;
+		}
+	}
+
 	haptics = devm_kzalloc(dev, sizeof(*haptics), GFP_KERNEL);
 	if (!haptics)
 		return -ENOMEM;
@@ -484,8 +499,10 @@ static int drv260x_probe(struct i2c_client *client)
 		return error;
 	}
 
-	haptics->enable_gpio = devm_gpiod_get_optional(dev, "enable",
-						       GPIOD_OUT_HIGH);
+	haptics->enable_gpio = devm_gpiod_get_optional(dev,
+			"enable", GPIOD_OUT_HIGH);
+
+	dev_dbg(dev, "Enable gpio = 0x%p\n", haptics->enable_gpio);
 	if (IS_ERR(haptics->enable_gpio))
 		return PTR_ERR(haptics->enable_gpio);
 
@@ -606,6 +623,14 @@ static const struct i2c_device_id drv260x_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, drv260x_id);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id drv260x_acpi_match[] = {
+	{ "DRV2604", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(acpi, drv260x_acpi_match);
+#endif
+
 static const struct of_device_id drv260x_of_match[] = {
 	{ .compatible = "ti,drv2604", },
 	{ .compatible = "ti,drv2604l", },
@@ -621,6 +646,7 @@ static struct i2c_driver drv260x_driver = {
 		.name	= "drv260x-haptics",
 		.of_match_table = drv260x_of_match,
 		.pm	= pm_sleep_ptr(&drv260x_pm_ops),
+		.acpi_match_table = ACPI_PTR(drv260x_acpi_match),
 	},
 	.id_table = drv260x_id,
 };
-- 
2.51.0

Re: [PATCH 2/5] input: drv260x: Add support for ACPI-enumerated devices

[Dmitry Torokhov]

Hi Yauhen,

On Thu, Feb 12, 2026 at 01:46:52AM +0200, Yauhen Kharuzhy wrote:
> Add ACPI ids and GPIO lookup mapping for drv2604 haptics device.
> Found in Lenovo Yoga Book YB1-X91L tablet.
> 
> Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> ---
>  drivers/input/misc/drv260x.c | 30 ++++++++++++++++++++++++++++--
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
> index 18360bdfe877..f613c81fa2ba 100644
> --- a/drivers/input/misc/drv260x.c
> +++ b/drivers/input/misc/drv260x.c
> @@ -15,6 +15,7 @@
>  #include <linux/delay.h>
>  #include <linux/gpio/consumer.h>
>  #include <linux/regulator/consumer.h>
> +#include <linux/acpi.h>

Sort alphabetically please.

>  
>  #include <dt-bindings/input/ti-drv260x.h>
>  
> @@ -419,6 +420,12 @@ static const struct regmap_config drv260x_regmap_config = {
>  	.cache_type = REGCACHE_NONE,
>  };
>  
> +static const struct acpi_gpio_params enable_gpio = { 0, 0, false };
> +static const struct acpi_gpio_mapping acpi_drv260x_default_gpios[] = {
> +	{ "enable-gpio", &enable_gpio, 1 },
> +	{ }
> +};

I'd rather move this ACPI/device-specifin handling into drivers/platform/x86/x86-android-tablets/lenovo.c

> +
>  static int drv260x_probe(struct i2c_client *client)
>  {
>  	struct device *dev = &client->dev;
> @@ -426,6 +433,14 @@ static int drv260x_probe(struct i2c_client *client)
>  	u32 voltage;
>  	int error;
>  
> +	if (has_acpi_companion(dev)) {
> +		error = devm_acpi_dev_add_driver_gpios(dev, acpi_drv260x_default_gpios);
> +		if (error) {
> +			dev_err(dev, "can't add GPIO ACPI mapping\n");
> +			return error;
> +		}
> +	}
> +
>  	haptics = devm_kzalloc(dev, sizeof(*haptics), GFP_KERNEL);
>  	if (!haptics)
>  		return -ENOMEM;
> @@ -484,8 +499,10 @@ static int drv260x_probe(struct i2c_client *client)
>  		return error;
>  	}
>  
> -	haptics->enable_gpio = devm_gpiod_get_optional(dev, "enable",
> -						       GPIOD_OUT_HIGH);
> +	haptics->enable_gpio = devm_gpiod_get_optional(dev,
> +			"enable", GPIOD_OUT_HIGH);

Why this change?

> +
> +	dev_dbg(dev, "Enable gpio = 0x%p\n", haptics->enable_gpio);

?

>  	if (IS_ERR(haptics->enable_gpio))
>  		return PTR_ERR(haptics->enable_gpio);
>  
> @@ -606,6 +623,14 @@ static const struct i2c_device_id drv260x_id[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, drv260x_id);
>  
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id drv260x_acpi_match[] = {
> +	{ "DRV2604", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(acpi, drv260x_acpi_match);
> +#endif
> +
>  static const struct of_device_id drv260x_of_match[] = {
>  	{ .compatible = "ti,drv2604", },
>  	{ .compatible = "ti,drv2604l", },
> @@ -621,6 +646,7 @@ static struct i2c_driver drv260x_driver = {
>  		.name	= "drv260x-haptics",
>  		.of_match_table = drv260x_of_match,
>  		.pm	= pm_sleep_ptr(&drv260x_pm_ops),
> +		.acpi_match_table = ACPI_PTR(drv260x_acpi_match),
>  	},
>  	.id_table = drv260x_id,
>  };

Thanks.

-- 
Dmitry

Re: [PATCH 2/5] input: drv260x: Add support for ACPI-enumerated devices

[Yauhen Kharuzhy]

On Thu, Feb 12, 2026 at 09:26:24AM -0800, Dmitry Torokhov wrote:
> Hi Yauhen,
> 
> On Thu, Feb 12, 2026 at 01:46:52AM +0200, Yauhen Kharuzhy wrote:
> > Add ACPI ids and GPIO lookup mapping for drv2604 haptics device.
> > Found in Lenovo Yoga Book YB1-X91L tablet.
> > 
> > Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> > ---
> >  drivers/input/misc/drv260x.c | 30 ++++++++++++++++++++++++++++--
> >  1 file changed, 28 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
> > index 18360bdfe877..f613c81fa2ba 100644
> > --- a/drivers/input/misc/drv260x.c
> > +++ b/drivers/input/misc/drv260x.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/delay.h>
> >  #include <linux/gpio/consumer.h>
> >  #include <linux/regulator/consumer.h>
> > +#include <linux/acpi.h>
> 
> Sort alphabetically please.

Sure.

> 
> >  
> >  #include <dt-bindings/input/ti-drv260x.h>
> >  
> > @@ -419,6 +420,12 @@ static const struct regmap_config drv260x_regmap_config = {
> >  	.cache_type = REGCACHE_NONE,
> >  };
> >  
> > +static const struct acpi_gpio_params enable_gpio = { 0, 0, false };
> > +static const struct acpi_gpio_mapping acpi_drv260x_default_gpios[] = {
> > +	{ "enable-gpio", &enable_gpio, 1 },
> > +	{ }
> > +};
> 
> I'd rather move this ACPI/device-specifin handling into drivers/platform/x86/x86-android-tablets/lenovo.c

I am not sure if this is device-specific, but since there are no other
devices with a DRV260x ACPI entry, I may agree. Will move it.

> 
> > +
> >  static int drv260x_probe(struct i2c_client *client)
> >  {
> >  	struct device *dev = &client->dev;
> > @@ -426,6 +433,14 @@ static int drv260x_probe(struct i2c_client *client)
> >  	u32 voltage;
> >  	int error;
> >  
> > +	if (has_acpi_companion(dev)) {
> > +		error = devm_acpi_dev_add_driver_gpios(dev, acpi_drv260x_default_gpios);
> > +		if (error) {
> > +			dev_err(dev, "can't add GPIO ACPI mapping\n");
> > +			return error;
> > +		}
> > +	}
> > +
> >  	haptics = devm_kzalloc(dev, sizeof(*haptics), GFP_KERNEL);
> >  	if (!haptics)
> >  		return -ENOMEM;
> > @@ -484,8 +499,10 @@ static int drv260x_probe(struct i2c_client *client)
> >  		return error;
> >  	}
> >  
> > -	haptics->enable_gpio = devm_gpiod_get_optional(dev, "enable",
> > -						       GPIOD_OUT_HIGH);
> > +	haptics->enable_gpio = devm_gpiod_get_optional(dev,
> > +			"enable", GPIOD_OUT_HIGH);
> 
> Why this change?

A good question. Looks like artifact from previous development
iterations, will remove it.

> 
> > +
> > +	dev_dbg(dev, "Enable gpio = 0x%p\n", haptics->enable_gpio);
> 
> ?

Hmm, looks like a forgotten debug stuff, removing it.


-- 
Yauhen Kharuzhy

[PATCH 3/5] input: drv260x: Check the device ID at initialization

[Yauhen Kharuzhy]

To ensure that the device is accessible on the I2C bus, read the status
register and check the Device ID field in drv260x_init().

Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
---
 drivers/input/misc/drv260x.c | 44 ++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index f613c81fa2ba..f08a3d6c3ed8 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -56,6 +56,13 @@
 #define DRV260X_LRA_RES_PERIOD	0x22
 #define DRV260X_MAX_REG			0x23
 
+#define DRV260X_STATUS_ID_MASK		0xe0
+#define DRV260X_STATUS_ID_SHIFT		5
+#define DRV260X_ID_DRV2605		3
+#define DRV260X_ID_DRV2604		4
+#define DRV260X_ID_DRV2604L		6
+#define DRV260X_ID_DRV2605L		7
+
 #define DRV260X_GO_BIT				0x01
 
 /* Library Selection */
@@ -305,10 +312,47 @@ static const struct reg_sequence drv260x_erm_cal_regs[] = {
 	{ DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
 };
 
+struct drv260x_id_map {
+	u8 id;
+	char *name;
+};
+
+static const struct drv260x_id_map drv_260x_devids[] = {
+	{ DRV260X_ID_DRV2605, "DRV2605"},
+	{ DRV260X_ID_DRV2604, "DRV2604"},
+	{ DRV260X_ID_DRV2604L, "DRV2604L"},
+	{ DRV260X_ID_DRV2605L, "DRV2605L"},
+};
+
+static char *drv260x_get_model(u8 id)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(drv_260x_devids); i++)
+		if (id == drv_260x_devids[i].id)
+			return drv_260x_devids[i].name;
+
+	return NULL;
+}
+
 static int drv260x_init(struct drv260x_data *haptics)
 {
 	int error;
 	unsigned int cal_buf;
+	u8 id;
+
+	error = regmap_read(haptics->regmap, DRV260X_STATUS, &cal_buf);
+	if (error) {
+		dev_err(&haptics->client->dev,
+				"Failed to read DRV260X_status register: %d\n",
+				error);
+		return error;
+	}
+
+	id = (cal_buf & DRV260X_STATUS_ID_MASK) >> DRV260X_STATUS_ID_SHIFT;
+
+	dev_info(&haptics->client->dev, "ID: %u (%s)\n", id,
+		 drv260x_get_model(id));
 
 	error = regmap_write(haptics->regmap,
 			     DRV260X_RATED_VOLT, haptics->rated_voltage);
-- 
2.51.0

Re: [PATCH 3/5] input: drv260x: Check the device ID at initialization

[Dmitry Torokhov]

On Thu, Feb 12, 2026 at 01:46:53AM +0200, Yauhen Kharuzhy wrote:
> To ensure that the device is accessible on the I2C bus, read the status
> register and check the Device ID field in drv260x_init().
> 
> Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> ---
>  drivers/input/misc/drv260x.c | 44 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
> index f613c81fa2ba..f08a3d6c3ed8 100644
> --- a/drivers/input/misc/drv260x.c
> +++ b/drivers/input/misc/drv260x.c
> @@ -56,6 +56,13 @@
>  #define DRV260X_LRA_RES_PERIOD	0x22
>  #define DRV260X_MAX_REG			0x23
>  
> +#define DRV260X_STATUS_ID_MASK		0xe0
> +#define DRV260X_STATUS_ID_SHIFT		5
> +#define DRV260X_ID_DRV2605		3
> +#define DRV260X_ID_DRV2604		4
> +#define DRV260X_ID_DRV2604L		6
> +#define DRV260X_ID_DRV2605L		7
> +
>  #define DRV260X_GO_BIT				0x01
>  
>  /* Library Selection */
> @@ -305,10 +312,47 @@ static const struct reg_sequence drv260x_erm_cal_regs[] = {
>  	{ DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
>  };
>  
> +struct drv260x_id_map {
> +	u8 id;
> +	char *name;
> +};
> +
> +static const struct drv260x_id_map drv_260x_devids[] = {
> +	{ DRV260X_ID_DRV2605, "DRV2605"},
> +	{ DRV260X_ID_DRV2604, "DRV2604"},
> +	{ DRV260X_ID_DRV2604L, "DRV2604L"},
> +	{ DRV260X_ID_DRV2605L, "DRV2605L"},
> +};
> +
> +static char *drv260x_get_model(u8 id)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(drv_260x_devids); i++)
> +		if (id == drv_260x_devids[i].id)
> +			return drv_260x_devids[i].name;
> +
> +	return NULL;
> +}
> +
>  static int drv260x_init(struct drv260x_data *haptics)
>  {
>  	int error;
>  	unsigned int cal_buf;
> +	u8 id;
> +
> +	error = regmap_read(haptics->regmap, DRV260X_STATUS, &cal_buf);
> +	if (error) {
> +		dev_err(&haptics->client->dev,
> +				"Failed to read DRV260X_status register: %d\n",
> +				error);
> +		return error;
> +	}
> +
> +	id = (cal_buf & DRV260X_STATUS_ID_MASK) >> DRV260X_STATUS_ID_SHIFT;
> +
> +	dev_info(&haptics->client->dev, "ID: %u (%s)\n", id,
> +		 drv260x_get_model(id));
>  
>  	error = regmap_write(haptics->regmap,
>  			     DRV260X_RATED_VOLT, haptics->rated_voltage);

If the device is not available this regmap_write() will fail so I am not
sure why we need all this new code.

Thanks.

-- 
Dmitry

Re: [PATCH 3/5] input: drv260x: Check the device ID at initialization

[Yauhen Kharuzhy]

On Thu, Feb 12, 2026 at 09:28:51AM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 12, 2026 at 01:46:53AM +0200, Yauhen Kharuzhy wrote:
> > To ensure that the device is accessible on the I2C bus, read the status
> > register and check the Device ID field in drv260x_init().
> > 
> > Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> > ---
> >  drivers/input/misc/drv260x.c | 44 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 44 insertions(+)
> > 
> > diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
> > index f613c81fa2ba..f08a3d6c3ed8 100644
> > --- a/drivers/input/misc/drv260x.c
> > +++ b/drivers/input/misc/drv260x.c
> > @@ -56,6 +56,13 @@
> >  #define DRV260X_LRA_RES_PERIOD	0x22
> >  #define DRV260X_MAX_REG			0x23
> >  
> > +#define DRV260X_STATUS_ID_MASK		0xe0
> > +#define DRV260X_STATUS_ID_SHIFT		5
> > +#define DRV260X_ID_DRV2605		3
> > +#define DRV260X_ID_DRV2604		4
> > +#define DRV260X_ID_DRV2604L		6
> > +#define DRV260X_ID_DRV2605L		7
> > +
> >  #define DRV260X_GO_BIT				0x01
> >  
> >  /* Library Selection */
> > @@ -305,10 +312,47 @@ static const struct reg_sequence drv260x_erm_cal_regs[] = {
> >  	{ DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
> >  };
> >  
> > +struct drv260x_id_map {
> > +	u8 id;
> > +	char *name;
> > +};
> > +
> > +static const struct drv260x_id_map drv_260x_devids[] = {
> > +	{ DRV260X_ID_DRV2605, "DRV2605"},
> > +	{ DRV260X_ID_DRV2604, "DRV2604"},
> > +	{ DRV260X_ID_DRV2604L, "DRV2604L"},
> > +	{ DRV260X_ID_DRV2605L, "DRV2605L"},
> > +};
> > +
> > +static char *drv260x_get_model(u8 id)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(drv_260x_devids); i++)
> > +		if (id == drv_260x_devids[i].id)
> > +			return drv_260x_devids[i].name;
> > +
> > +	return NULL;
> > +}
> > +
> >  static int drv260x_init(struct drv260x_data *haptics)
> >  {
> >  	int error;
> >  	unsigned int cal_buf;
> > +	u8 id;
> > +
> > +	error = regmap_read(haptics->regmap, DRV260X_STATUS, &cal_buf);
> > +	if (error) {
> > +		dev_err(&haptics->client->dev,
> > +				"Failed to read DRV260X_status register: %d\n",
> > +				error);
> > +		return error;
> > +	}
> > +
> > +	id = (cal_buf & DRV260X_STATUS_ID_MASK) >> DRV260X_STATUS_ID_SHIFT;
> > +
> > +	dev_info(&haptics->client->dev, "ID: %u (%s)\n", id,
> > +		 drv260x_get_model(id));
> >  
> >  	error = regmap_write(haptics->regmap,
> >  			     DRV260X_RATED_VOLT, haptics->rated_voltage);
> 
> If the device is not available this regmap_write() will fail so I am not
> sure why we need all this new code.

Mostly for informational purposes about the detected model. Maybe you are
right, and this is unnecessary.

> 
> Thanks.
> 
> -- 
> Dmitry

-- 
Yauhen Kharuzhy

[PATCH 4/5] input: drv260x: Stop waiting for GO bit clearing after timeout

[Yauhen Kharuzhy]

If something goes wrong during effect playing or calibration, the GO bit
may not be cleared after some time, and the driver will get stuck.
To prevent this, add a timeout to the waiting loop.

Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
---
 drivers/input/misc/drv260x.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index f08a3d6c3ed8..f7bfac6d3973 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -173,6 +173,12 @@
 #define DRV260X_AUTOCAL_TIME_500MS		(2 << 4)
 #define DRV260X_AUTOCAL_TIME_1000MS		(3 << 4)
 
+/*
+ * Timeout for waiting for the GO status bit, in seconds. Should be reasonably
+ * large to allow long-duration effects and a calibration cycle
+ */
+#define DRV260X_GO_TIMEOUT_S 5
+
 /**
  * struct drv260x_data -
  * @input_dev: Pointer to the input device
@@ -339,6 +345,7 @@ static int drv260x_init(struct drv260x_data *haptics)
 {
 	int error;
 	unsigned int cal_buf;
+	unsigned long timeout;
 	u8 id;
 
 	error = regmap_read(haptics->regmap, DRV260X_STATUS, &cal_buf);
@@ -442,6 +449,7 @@ static int drv260x_init(struct drv260x_data *haptics)
 		return error;
 	}
 
+	timeout = jiffies + DRV260X_GO_TIMEOUT_S * HZ;
 	do {
 		usleep_range(15000, 15500);
 		error = regmap_read(haptics->regmap, DRV260X_GO, &cal_buf);
@@ -451,6 +459,10 @@ static int drv260x_init(struct drv260x_data *haptics)
 				error);
 			return error;
 		}
+		if (jiffies - timeout <= 0) {
+			dev_err(&haptics->client->dev, "GO timeout\n");
+			break;
+		}
 	} while (cal_buf == DRV260X_GO_BIT);
 
 	return 0;
-- 
2.51.0

Re: [PATCH 4/5] input: drv260x: Stop waiting for GO bit clearing after timeout

[Dmitry Torokhov]

On Thu, Feb 12, 2026 at 01:46:54AM +0200, Yauhen Kharuzhy wrote:
> If something goes wrong during effect playing or calibration, the GO bit
> may not be cleared after some time, and the driver will get stuck.
> To prevent this, add a timeout to the waiting loop.
> 
> Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> ---
>  drivers/input/misc/drv260x.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
> index f08a3d6c3ed8..f7bfac6d3973 100644
> --- a/drivers/input/misc/drv260x.c
> +++ b/drivers/input/misc/drv260x.c
> @@ -173,6 +173,12 @@
>  #define DRV260X_AUTOCAL_TIME_500MS		(2 << 4)
>  #define DRV260X_AUTOCAL_TIME_1000MS		(3 << 4)
>  
> +/*
> + * Timeout for waiting for the GO status bit, in seconds. Should be reasonably
> + * large to allow long-duration effects and a calibration cycle
> + */
> +#define DRV260X_GO_TIMEOUT_S 5
> +
>  /**
>   * struct drv260x_data -
>   * @input_dev: Pointer to the input device
> @@ -339,6 +345,7 @@ static int drv260x_init(struct drv260x_data *haptics)
>  {
>  	int error;
>  	unsigned int cal_buf;
> +	unsigned long timeout;
>  	u8 id;
>  
>  	error = regmap_read(haptics->regmap, DRV260X_STATUS, &cal_buf);
> @@ -442,6 +449,7 @@ static int drv260x_init(struct drv260x_data *haptics)
>  		return error;
>  	}
>  
> +	timeout = jiffies + DRV260X_GO_TIMEOUT_S * HZ;
>  	do {
>  		usleep_range(15000, 15500);
>  		error = regmap_read(haptics->regmap, DRV260X_GO, &cal_buf);
> @@ -451,6 +459,10 @@ static int drv260x_init(struct drv260x_data *haptics)
>  				error);
>  			return error;
>  		}
> +		if (jiffies - timeout <= 0) {

time_after()

> +			dev_err(&haptics->client->dev, "GO timeout\n");

This should be a warning, not error, since we are continuing.

But actually, shouldn't we signal an error? This is probe path and if
the controller does not ever signal readiness I do not think we should
pretend that it will work.

> +			break;
> +		}
>  	} while (cal_buf == DRV260X_GO_BIT);

Thanks.

-- 
Dmitry

Re: [PATCH 4/5] input: drv260x: Stop waiting for GO bit clearing after timeout

[Yauhen Kharuzhy]

On Thu, Feb 12, 2026 at 09:34:51AM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 12, 2026 at 01:46:54AM +0200, Yauhen Kharuzhy wrote:
> > If something goes wrong during effect playing or calibration, the GO bit
> > may not be cleared after some time, and the driver will get stuck.
> > To prevent this, add a timeout to the waiting loop.
> > 
> > Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
> > ---
> >  drivers/input/misc/drv260x.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
> > index f08a3d6c3ed8..f7bfac6d3973 100644
> > --- a/drivers/input/misc/drv260x.c
> > +++ b/drivers/input/misc/drv260x.c
> > @@ -173,6 +173,12 @@
> >  #define DRV260X_AUTOCAL_TIME_500MS		(2 << 4)
> >  #define DRV260X_AUTOCAL_TIME_1000MS		(3 << 4)
> >  
> > +/*
> > + * Timeout for waiting for the GO status bit, in seconds. Should be reasonably
> > + * large to allow long-duration effects and a calibration cycle
> > + */
> > +#define DRV260X_GO_TIMEOUT_S 5
> > +
> >  /**
> >   * struct drv260x_data -
> >   * @input_dev: Pointer to the input device
> > @@ -339,6 +345,7 @@ static int drv260x_init(struct drv260x_data *haptics)
> >  {
> >  	int error;
> >  	unsigned int cal_buf;
> > +	unsigned long timeout;
> >  	u8 id;
> >  
> >  	error = regmap_read(haptics->regmap, DRV260X_STATUS, &cal_buf);
> > @@ -442,6 +449,7 @@ static int drv260x_init(struct drv260x_data *haptics)
> >  		return error;
> >  	}
> >  
> > +	timeout = jiffies + DRV260X_GO_TIMEOUT_S * HZ;
> >  	do {
> >  		usleep_range(15000, 15500);
> >  		error = regmap_read(haptics->regmap, DRV260X_GO, &cal_buf);
> > @@ -451,6 +459,10 @@ static int drv260x_init(struct drv260x_data *haptics)
> >  				error);
> >  			return error;
> >  		}
> > +		if (jiffies - timeout <= 0) {
> 
> time_after()
> 
> > +			dev_err(&haptics->client->dev, "GO timeout\n");
> 
> This should be a warning, not error, since we are continuing.
> 
> But actually, shouldn't we signal an error? This is probe path and if
> the controller does not ever signal readiness I do not think we should
> pretend that it will work.

Sounds reasonable. I got such a hang when selecting invalid mode/library
properties, and yes, it doesn't look like we can expect correct
functioning afterward. Will change to error.

> 
> > +			break;
> > +		}
> >  	} while (cal_buf == DRV260X_GO_BIT);
> 
> Thanks.
> 
> -- 
> Dmitry

-- 
Yauhen Kharuzhy

[PATCH 5/5] input: drv260x: Don't try to disable dummy regulator

[Yauhen Kharuzhy]

Don't use a dummy regulator for 'vbat' because it cannot be disabled
during suspending.

Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
---
 drivers/input/misc/drv260x.c | 44 +++++++++++++++++++++++-------------
 1 file changed, 28 insertions(+), 16 deletions(-)

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index f7bfac6d3973..e82ede54c6f6 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -548,11 +548,17 @@ static int drv260x_probe(struct i2c_client *client)
 	haptics->overdrive_voltage = error ? DRV260X_DEF_OD_CLAMP_VOLT :
 					     drv260x_calculate_voltage(voltage);
 
-	haptics->regulator = devm_regulator_get(dev, "vbat");
+	haptics->regulator = devm_regulator_get_optional(dev, "vbat");
 	if (IS_ERR(haptics->regulator)) {
-		error = PTR_ERR(haptics->regulator);
-		dev_err(dev, "unable to get regulator, error: %d\n", error);
-		return error;
+		if (PTR_ERR(haptics->regulator) == -ENODEV) {
+			haptics->regulator = NULL;
+			dev_dbg(dev, "No vbat regulator found\n");
+		} else {
+			error = PTR_ERR(haptics->regulator);
+			dev_err(dev, "unable to get regulator, error: %d\n",
+				error);
+			return error;
+		}
 	}
 
 	haptics->enable_gpio = devm_gpiod_get_optional(dev,
@@ -626,13 +632,15 @@ static int drv260x_suspend(struct device *dev)
 
 		gpiod_set_value(haptics->enable_gpio, 0);
 
-		error = regulator_disable(haptics->regulator);
-		if (error) {
-			dev_err(dev, "Failed to disable regulator\n");
-			regmap_update_bits(haptics->regmap,
-					   DRV260X_MODE,
-					   DRV260X_STANDBY_MASK, 0);
-			return error;
+		if (haptics->regulator) {
+			error = regulator_disable(haptics->regulator);
+			if (error) {
+				dev_err(dev, "Failed to disable regulator\n");
+				regmap_update_bits(haptics->regmap,
+						   DRV260X_MODE,
+						   DRV260X_STANDBY_MASK, 0);
+				return error;
+			}
 		}
 	}
 
@@ -647,10 +655,12 @@ static int drv260x_resume(struct device *dev)
 	guard(mutex)(&haptics->input_dev->mutex);
 
 	if (input_device_enabled(haptics->input_dev)) {
-		error = regulator_enable(haptics->regulator);
-		if (error) {
-			dev_err(dev, "Failed to enable regulator\n");
-			return error;
+		if (haptics->regulator) {
+			error = regulator_enable(haptics->regulator);
+			if (error) {
+				dev_err(dev, "Failed to enable regulator\n");
+				return error;
+			}
 		}
 
 		error = regmap_update_bits(haptics->regmap,
@@ -658,7 +668,9 @@ static int drv260x_resume(struct device *dev)
 					   DRV260X_STANDBY_MASK, 0);
 		if (error) {
 			dev_err(dev, "Failed to unset standby mode\n");
-			regulator_disable(haptics->regulator);
+			if (haptics->regulator)
+				regulator_disable(haptics->regulator);
+
 			return error;
 		}
 
-- 
2.51.0

Re: [PATCH 5/5] input: drv260x: Don't try to disable dummy regulator

[Dmitry Torokhov]

On Thu, Feb 12, 2026 at 01:46:55AM +0200, Yauhen Kharuzhy wrote:
> Don't use a dummy regulator for 'vbat' because it cannot be disabled
> during suspending.

Why? Dummy regulator is supposed to be a placeholder that allows all the
regular operations (enable/disable/etc) without having actually supply
attached. Optional regulators are supposed to only be users when there
are parts of a chip that are powered separately and may be not in use in
a given design.

This change is counter to the regulator framework.

Thanks.

-- 
Dmitry

Re: [PATCH 5/5] input: drv260x: Don't try to disable dummy regulator

[Yauhen Kharuzhy]

On Thu, Feb 12, 2026 at 09:41:04AM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 12, 2026 at 01:46:55AM +0200, Yauhen Kharuzhy wrote:
> > Don't use a dummy regulator for 'vbat' because it cannot be disabled
> > during suspending.
> 
> Why? Dummy regulator is supposed to be a placeholder that allows all the
> regular operations (enable/disable/etc) without having actually supply
> attached. Optional regulators are supposed to only be users when there
> are parts of a chip that are powered separately and may be not in use in
> a given design.

Hmm, I definitely had an issue with this. Will re-check.

Thanks for the review.

> 
> This change is counter to the regulator framework.
> 
> Thanks.
> 
> -- 
> Dmitry

-- 
Yauhen Kharuzhy