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@xxxxxxxxx>
> > ---
> >  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