Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp904416imm; Fri, 11 May 2018 08:07:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpLPzGEG4IFpgH2MZ0j7iSpEJZTSclREo4QS/5V2eKFEdYwM2JqvPZRC8FWEm3l9ZRXkYPC X-Received: by 2002:a63:618b:: with SMTP id v133-v6mr4627075pgb.285.1526051250599; Fri, 11 May 2018 08:07:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526051250; cv=none; d=google.com; s=arc-20160816; b=oIYED5U5Mcj0NsABqO2iRUv4e4FLgulYLJUbCKcMwYkCuFWSwQit9Wym6jYHc5P9pS IbjzsdXOTh5HmIp1xW7gQpl/iN3ORN3N8zNTxnV4QQMIN2sgT/+wi6CNaEgigEA6fXQ8 eiwINCgXXYLF6tP46bgwG2wE8pX8ZZYnbhTZ+wibDBbo6A3gaM3HL1ao5sItL9UqSYYX 7lJz2zfxxHB+frNn8bbHOyaNkRqCqHLlQ/sHBYB09rkhpnfoqDFRMWmkgKPkgcLf1RJH GxdSASKg0nq7sUghaWl7GFygYy3YYS5tFzd8bn5/Oz7PFwDbkTPqwoytGwXBXEuPxB/2 Pkmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=b6aYEYYyNQaeaX6H/inaPlNg88N+lgGknhcAJVHZRvs=; b=m0qtMOLBoZ+GOBak4aNVB5lecXDB9HizQT0Q5C/w6ofi2doZssebmULKtueE6BUnR8 ZdNusBBjOsSFIPW32mYaCYL074DYxLHP9igUTW3aH++y18TDfNdmZXMFbIIepouOVAXt FMUy6P+qDHMejRUIGat8OnnPWhpMwueksHLvWGbT+2K1O7hTmHixGnmN4PH7eMB0TKNI wB/Cz8JDZxD6JQYDSrArtzg/NbhQ78eyudb5D8LBl8Xafpervfq/OCMu4oNiHiah4OTq Fjr3F3ihKBlYLFjI1cLYCsQX9vroLFlxGQrZESC1pMmzKnGQx5n3Aqwdan1DNFeetk7O tvBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w5-v6si3445310plp.330.2018.05.11.08.07.16; Fri, 11 May 2018 08:07:30 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753542AbeEKPGm (ORCPT + 99 others); Fri, 11 May 2018 11:06:42 -0400 Received: from smtp01.smtpout.orange.fr ([80.12.242.123]:32349 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753519AbeEKPGk (ORCPT ); Fri, 11 May 2018 11:06:40 -0400 Received: from ubuntu-CJ.home ([86.244.116.1]) by mwinf5d36 with ME id l36B1x00C01t9Ri0336ec0; Fri, 11 May 2018 17:06:38 +0200 X-ME-Helo: ubuntu-CJ.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Fri, 11 May 2018 17:06:38 +0200 X-ME-IP: 86.244.116.1 From: Christophe JAILLET To: alan@linux.intel.com, sakari.ailus@linux.intel.com, mchehab@kernel.org, gregkh@linuxfoundation.org, andriy.shevchenko@linux.intel.com, chen.chenchacha@foxmail.com, keescook@chromium.org, arvind.yadav.cs@gmail.com Cc: linux-media@vger.kernel.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET Subject: [PATCH 3/3] media: staging: atomisp: Fix usage of 'media_entity_cleanup()' Date: Fri, 11 May 2018 17:06:18 +0200 Message-Id: <7c1d9505a90619764bc2f2a29fcfc9132a72e391.1526048313.git.christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.17.0 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org According to the doc, 'media_entity_cleanup()' must be called after unregistering the entity. All places I've check do it that way. So, move the call after 'v4l2_device_unregister_subdev()' as done elsewhere. Actually, this is not an issue, because 'media_entity_cleanup()' does nothing, but it is more future proof. Signed-off-by: Christophe JAILLET --- The change from '&flash->sd.entity' to '&sd->entity' in the last hunk is done because most of the drivers I've checked do it that way. Not sure if it is correct. It looks logical to me and it can be compiled. That's all I know. If this patch is reviewed and confirmed, I'll propose similar fixes for some other drivers. --- drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c index 1e5f516f6e50..b369b101abe7 100644 --- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c +++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c @@ -902,11 +902,12 @@ static int lm3554_probe(struct i2c_client *client) goto fail2; } return atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH); + fail2: - media_entity_cleanup(&flash->sd.entity); v4l2_ctrl_handler_free(&flash->ctrl_handler); fail1: v4l2_device_unregister_subdev(&flash->sd); + media_entity_cleanup(&flash->sd.entity); kfree(flash); return err; @@ -918,9 +919,9 @@ static int lm3554_remove(struct i2c_client *client) struct lm3554 *flash = to_lm3554(sd); int ret; - media_entity_cleanup(&flash->sd.entity); v4l2_ctrl_handler_free(&flash->ctrl_handler); v4l2_device_unregister_subdev(sd); + media_entity_cleanup(&sd->entity); atomisp_gmin_remove_subdev(sd); -- 2.17.0