Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 13 Nov 2019 00:23:15 -0800
From:   Dmitry Torokhov <dmitry.torokhov@gmail.com>
To:     Chuhong Yuan <hslester96@gmail.com>
Cc:     linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: synaptics-rmi4 - add missed operations in remove
Message-ID: <20191113082315.GP13374@dtor-ws>
References: <20191113063656.8713-1-hslester96@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191113063656.8713-1-hslester96@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Nov 13, 2019 at 02:36:56PM +0800, Chuhong Yuan wrote:
> The driver forgets to deal with work and workqueue in remove like what
> is done when probe fails.
> Add the missed operations to fix it.

Is it really possible for the work to still be pending when fully
registered device is properly unregistered? I thought we'd wait for
successful data acquisition in rmi_f54_buffer_queue() before unregister
can complete.

> 
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
>  drivers/input/rmi4/rmi_f54.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index 710b02595486..2c0cde5c775c 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -730,6 +730,9 @@ static void rmi_f54_remove(struct rmi_function *fn)
>  
>  	video_unregister_device(&f54->vdev);
>  	v4l2_device_unregister(&f54->v4l2);
> +	cancel_delayed_work_sync(&f54->work);
> +	flush_workqueue(f54->workqueue);
> +	destroy_workqueue(f54->workqueue);
>  }
>  
>  struct rmi_function_handler rmi_f54_handler = {
> -- 
> 2.23.0
> 

Thanks.

-- 
Dmitry