Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2988863imu; Sun, 9 Dec 2018 14:25:03 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vmv8Q77XJNYONgFJ4xQWm9u4aShEr8ynrHKuIjO9ZyVsB6QgInq5+081IbFFzYrGCYPy6h X-Received: by 2002:a62:3ac1:: with SMTP id v62mr9776337pfj.87.1544394302959; Sun, 09 Dec 2018 14:25:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544394302; cv=none; d=google.com; s=arc-20160816; b=Aci0l3+Kja20x0LSKfqGcuLhGHTmcLF7E2d7WiNfEcM4r+l8r7dfS4dEri8apHc6vw 6PUPeMdp1IQCyYw6ynKVQKuaG3piGbSdUGfsnvMmn9pkXhkZYVZs1OSGegAUkhwWyong tQyWKkaJWb8jrcTPNT0vJMik0xEZyLR96ygluUGxdyGK6nShROI1mzTranZqsS4RKUEe Y/Q9o7qUQWlDpGgpp/w6r+lBLVvXEr/9THuLTQXAyJCyTyuAZbJpi/MpQyuTi+WS9ljy wrJvW406lM37m8PM+wv1zHIAHIwfLo53J3xHzQeHu2srcKq/UZSjHDER2N4dQkGoZp77 bTKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=5rAgJTizfwju/m80DDqqoOboARiroH8Hzv7kv/n5dF4=; b=cMkIscGn4BJKA5prQLDQYkVEioiPQp45WCFE/rjqzlSa5Yev9JQxWH+A7q4UFTlS/M Z3I/YB5C+UzoH+xg+NYiCzETYckWn7O3/i8jfFb/RAyOPYmzFgsJMJ8AFAy11yumjTKd zO+M7uEJVXNUYhVthwqMLcYWMoyo1kovNZLAnBcxcQ6arfVwKyseDQxMi6Eiwnw6pmWu cJftDdaA31qPmXiAEXbhkN8GIEOJNAYKKek8fgn7vV8XDW+uRA3MlHdQVFkgBX0YR86R leYGGoC885ea0m3XrpXYrGAJycq3Mso0t+gtvB0h7mr58Er/6/8YK/RYE/YkWLK4MS97 3FSw== 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 h69si8074052pge.121.2018.12.09.14.24.47; Sun, 09 Dec 2018 14:25:02 -0800 (PST) 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 S1726496AbeLIVzT (ORCPT + 99 others); Sun, 9 Dec 2018 16:55:19 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34552 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726322AbeLIVzJ (ORCPT ); Sun, 9 Dec 2018 16:55:09 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW72Y-0002ik-RN; Sun, 09 Dec 2018 21:55:06 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72Y-0003D3-3y; Sun, 09 Dec 2018 21:55:06 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Mauro Carvalho Chehab" , "Sebastian Reichel" , "Javier Martinez Canillas" , "Sakari Ailus" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 012/328] media: omap3isp: zero-initialize the isp cam_xclk{a,b} initial data In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Javier Martinez Canillas commit 2ec7debd44b49927a6e2861521994cc075a389ed upstream. The struct clk_init_data init variable is declared in the isp_xclk_init() function so is an automatic variable allocated in the stack. But it's not explicitly zero-initialized, so some init fields are left uninitialized. This causes the data structure to have undefined values that may confuse the common clock framework when the clock is registered. For example, the uninitialized .flags field could have the CLK_IS_CRITICAL bit set, causing the framework to wrongly prepare the clk on registration. This leads to the isp_xclk_prepare() callback being called, which in turn calls to the omap3isp_get() function that increments the isp dev refcount. Since this omap3isp_get() call is unexpected, this leads to an unbalanced omap3isp_get() call that prevents the requested IRQ to be later enabled, due the refcount not being 0 when the correct omap3isp_get() call happens. Fixes: 9b28ee3c9122 ("[media] omap3isp: Use the common clock framework") Signed-off-by: Javier Martinez Canillas Reviewed-by: Sebastian Reichel Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- drivers/media/platform/omap3isp/isp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -282,7 +282,7 @@ static const char *isp_xclk_parent_name static int isp_xclk_init(struct isp_device *isp) { struct isp_platform_data *pdata = isp->pdata; - struct clk_init_data init; + struct clk_init_data init = { 0 }; unsigned int i; for (i = 0; i < ARRAY_SIZE(isp->xclks); ++i)