There was a race condition where during cleanup/release operation
on-going streaming would cause a kernel panic because the hardware
module was disabled prematurely with IRQ still pending.
Fixes: 417d2e507ed [media] media: platform: add VPFE capture driver support for
AM437X
Cc: <sta...@vger.kernel.org> # v4.0+
Signed-off-by: Benoit Parrot <bpar...@ti.com>
---
Changes from v1:
- Added stable reference
drivers/media/platform/am437x/am437x-vpfe.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
b/drivers/media/platform/am437x/am437x-vpfe.c
index a30cc2f..eb25c43 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -1185,14 +1185,21 @@ static int vpfe_initialize_device(struct vpfe_device
*vpfe)
static int vpfe_release(struct file *file)
{
struct vpfe_device *vpfe = video_drvdata(file);
+ bool fh_singular = v4l2_fh_is_singular_file(file);
int ret;
mutex_lock(&vpfe->lock);
- if (v4l2_fh_is_singular_file(file))
- vpfe_ccdc_close(&vpfe->ccdc, vpfe->pdev);
+ /* the release helper will cleanup any on-going streaming */
ret = _vb2_fop_release(file, NULL);
+ /*
+ * If this was the last open file.
+ * Then de-initialize hw module.
+ */
+ if (fh_singular)
+ vpfe_ccdc_close(&vpfe->ccdc, vpfe->pdev);
+
mutex_unlock(&vpfe->lock);
return ret;
--
1.8.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
