Received: by 10.213.65.68 with SMTP id h4csp285503imn; Fri, 23 Mar 2018 04:45:03 -0700 (PDT) X-Google-Smtp-Source: AG47ELu5FVbvRB83MaOUlg6ZHRDlhQEwUkXJ0ltfnN1rkOLcMnNuJaF6noAglucMLITdjLA3cskA X-Received: by 10.98.61.206 with SMTP id x75mr18040204pfj.233.1521805503353; Fri, 23 Mar 2018 04:45:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521805503; cv=none; d=google.com; s=arc-20160816; b=N2g+Lja5mG2YOKfIHq9DC1karfTxwX9/PyDdlmbFcQyjAtwuHFwzIYbdKMCrCZJYMR RCZ+IBRZVuxCnDlQYnfUDdAZwt5Q84Iufsz+Gr6a95VOCTdSXi1bfajIdMlkXaTUtYg5 hiXuCThb1jsmgG7MVzcC6mFwJvNU3CQdlp1hkkDiIUpSN5mbiQqGfVgN00Tl/EcJu5iY CCE2HqPOsF1fVAdlvn1brBMbIq1dR5dkjb5tXlP6FFHx67Jp0GrT/t2qD8a9PcBtFyJO 5chkr0UALdH4rgtGND0zRTrkS78gp35Ik/Fc7kDeLYjnxHhrv1WHOFi2x8QTk2Vew70n 768w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=6tn+X9cL7mNi5D5h5h9abRScZt847x+l0gMbXrtU72c=; b=vOI4rCSNubOiq7kvK8uQTt+sjGIDHuLGoHw+PJS41RV/HZAqd1MGfkRIyJeERJ4TrU wwoeGG9ZjOksFri7grr67WOneLT7hwAmGHyQer3DhPhAf/XsBUQNpI7lgiMJPEUF736O o1ZV3NoMfK8ejtmjonAOJDBA60BpZQVbzG1nY6lTPD3n3gUIeeb9o7lbxH340SxQvOhc 8mYWMn4RdrFeBSACRMiJ02esMFwsCxZKH5pGM4FRyXjI70uIrPGPYvn2uOnxPZEyUjIQ LAerpSzZIC2orca2GldeH8KwnCH1VSxduissAwPvowl12ZcTAUbjO9AZPc2vBPpkpgs0 f0IA== 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 p20-v6si8177562plo.643.2018.03.23.04.44.48; Fri, 23 Mar 2018 04:45:03 -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 S1754479AbeCWKDb (ORCPT + 99 others); Fri, 23 Mar 2018 06:03:31 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:38798 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754463AbeCWKD2 (ORCPT ); Fri, 23 Mar 2018 06:03:28 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 399C9132F; Fri, 23 Mar 2018 10:03:27 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stephen Boyd , Shawn Guo , Dong Aisheng , Jerome Brunet , Marek Szyprowski , Heiko Stuebner , Michael Turquette Subject: [PATCH 4.14 73/77] clk: migrate the count of orphaned clocks at init Date: Fri, 23 Mar 2018 10:54:47 +0100 Message-Id: <20180323094147.176687755@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180323094142.260022880@linuxfoundation.org> References: <20180323094142.260022880@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jerome Brunet commit 99652a469df19086d594e8e89757d4081a812789 upstream. The orphan clocks reparents should migrate any existing count from the orphan clock to its new acestor clocks, otherwise we may have inconsistent counts in the tree and end-up with gated critical clocks Assuming we have two clocks, A and B. * Clock A has CLK_IS_CRITICAL flag set. * Clock B is an ancestor of A which can gate. Clock B gate is left enabled by the bootloader. Step 1: Clock A is registered. Since it is a critical clock, it is enabled. The clock being still an orphan, no parent are enabled. Step 2: Clock B is registered and reparented to clock A (potentially through several other clocks). We are now in situation where the enable count of clock A is 1 while the enable count of its ancestors is 0, which is not good. Step 3: in lateinit, clk_disable_unused() is called, the enable_count of clock B being 0, clock B is gated and and critical clock A actually gets disabled. This situation was found while adding fdiv_clk gates to the meson8b platform. These clocks parent clk81 critical clock, which is the mother of all peripheral clocks in this system. Because of the issue described here, the system is crashing when clk_disable_unused() is called. The situation is solved by reverting commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting during registration"). To avoid breaking again the situation described in this commit description, enabling critical clock should be done before walking the orphan list. This way, a parent critical clock may not be accidentally disabled due to the CLK_OPS_PARENT_ENABLE mechanism. Fixes: f8f8f1d04494 ("clk: Don't touch hardware when reparenting during registration") Cc: Stephen Boyd Cc: Shawn Guo Cc: Dong Aisheng Signed-off-by: Jerome Brunet Tested-by: Marek Szyprowski Tested-by: Heiko Stuebner Signed-off-by: Michael Turquette Signed-off-by: Greg Kroah-Hartman --- drivers/clk/clk.c | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-) --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2471,22 +2471,37 @@ static int __clk_core_init(struct clk_co core->rate = core->req_rate = rate; /* + * Enable CLK_IS_CRITICAL clocks so newly added critical clocks + * don't get accidentally disabled when walking the orphan tree and + * reparenting clocks + */ + if (core->flags & CLK_IS_CRITICAL) { + unsigned long flags; + + clk_core_prepare(core); + + flags = clk_enable_lock(); + clk_core_enable(core); + clk_enable_unlock(flags); + } + + /* * walk the list of orphan clocks and reparent any that newly finds a * parent. */ hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) { struct clk_core *parent = __clk_init_parent(orphan); - unsigned long flags; /* - * we could call __clk_set_parent, but that would result in a - * redundant call to the .set_rate op, if it exists + * We need to use __clk_set_parent_before() and _after() to + * to properly migrate any prepare/enable count of the orphan + * clock. This is important for CLK_IS_CRITICAL clocks, which + * are enabled during init but might not have a parent yet. */ if (parent) { /* update the clk tree topology */ - flags = clk_enable_lock(); - clk_reparent(orphan, parent); - clk_enable_unlock(flags); + __clk_set_parent_before(orphan, parent); + __clk_set_parent_after(orphan, parent, NULL); __clk_recalc_accuracies(orphan); __clk_recalc_rates(orphan, 0); } @@ -2503,16 +2518,6 @@ static int __clk_core_init(struct clk_co if (core->ops->init) core->ops->init(core->hw); - if (core->flags & CLK_IS_CRITICAL) { - unsigned long flags; - - clk_core_prepare(core); - - flags = clk_enable_lock(); - clk_core_enable(core); - clk_enable_unlock(flags); - } - kref_init(&core->ref); out: clk_prepare_unlock();