From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DB9FC3A59F for ; Mon, 26 Aug 2019 21:24:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 422802186A for ; Mon, 26 Aug 2019 21:24:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566854661; bh=7ag3qSHELurKC8BHo1sm6KhvINW0pll6GeIjp2vLyF8=; h=In-Reply-To:References:Cc:Subject:To:From:Date:List-ID:From; b=Arpffehx9BvWi2mcgXMJcKSEmHwBm269RW8OTZUJ+3Nh3XnJ9QuOGP0CIDoFoJTve XKMqzeHVU5ppjFaeRzQNdvDUK6fiIcfPJiooozJd0izcjKFO0TL+0aYGy2HPACE8bW 2ZxOIEoihoPMTjxM5HSpLaFAzwEW6BFOsa39Xeh0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728078AbfHZVYR (ORCPT ); Mon, 26 Aug 2019 17:24:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:38046 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727646AbfHZVYR (ORCPT ); Mon, 26 Aug 2019 17:24:17 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ABD3521848; Mon, 26 Aug 2019 21:24:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566854655; bh=7ag3qSHELurKC8BHo1sm6KhvINW0pll6GeIjp2vLyF8=; h=In-Reply-To:References:Cc:Subject:To:From:Date:From; b=eYE0M8qOOOKuinBRZV4EgaFRj0w68M6WpbjBgPhh2I4Dj6cqAkYvxTYesFItIt73p eFqm+xf56HrKDtXkOFwniWgS/5uQ5r8NAwW+hQiUri9BzfdlCA2yXRhpC6iAFJ4Xz8 YW1RQqhbw/mf4nLMfQvEQGSAS30mg5hBldKNrAh8= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190821181009.00D6322D6D@mail.kernel.org> References: <20190723051446.20013-1-bjorn.andersson@linaro.org> <20190729224652.17291206E0@mail.kernel.org> <20190821181009.00D6322D6D@mail.kernel.org> Cc: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Rob Clark , Sean Paul Subject: Re: [RFC] clk: Remove cached cores in parent map during unregister To: Bjorn Andersson , Michael Turquette , Sai Prakash Ranjan From: Stephen Boyd User-Agent: alot/0.8.1 Date: Mon, 26 Aug 2019 14:24:14 -0700 Message-Id: <20190826212415.ABD3521848@mail.kernel.org> Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Quoting Stephen Boyd (2019-08-21 11:10:08) > Quoting Stephen Boyd (2019-07-29 15:46:51) > > Quoting Bjorn Andersson (2019-07-22 22:14:46) > > > As clocks are registered their parents are resolved and the parent_map > > > is updated to cache the clk_core objects of each existing parent. > > > But in the event of a clock being unregistered this cache will carry > > > dangling pointers if not invalidated, so do this for all children of = the > > > clock being unregistered. > > >=20 > > > Signed-off-by: Bjorn Andersson > > > --- > > >=20 > > > This resolves the issue seen where the DSI PLL (and it's provided clo= cks) is > > > being registered and unregistered multiple times due to probe deferra= l. > > >=20 > > > Marking it RFC because I don't fully understand the life of the clock= yet. > >=20 > > The concept sounds sane but the implementation is going to be not much > > fun. The problem is that a clk can be in many different parent caches, > > even ones for clks that aren't currently parented to it. We would need > > to walk the entire tree(s) and find anywhere that we've cached the > > clk_core pointer and invalidate it. Maybe we can speed that up a little > > bit by keeping a reference to the entry of each parent cache that is for > > the parent we're removing, essentially holding an inverse cache, but I'm > > not sure it will provide any benefit besides wasting space for this one > > operation that we shouldn't be doing very often if at all. > >=20 > > It certainly sounds easier to iterate through the whole tree and just > > invalidate entries in all the caches under the prepare lock. We can > > optimize it later. >=20 > Here's an attempt at the simple approach. There's another problem where > the cached 'hw' member of the parent data is held around when we don't > know when the caller has destroyed it. Not much else we can do for that > though. >=20 > ---8<--- > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > index c0990703ce54..f42a803fb11a 100644 > --- a/drivers/clk/clk.c > +++ b/drivers/clk/clk.c > @@ -3737,6 +3737,37 @@ static const struct clk_ops clk_nodrv_ops =3D { > .set_parent =3D clk_nodrv_set_parent, > }; > =20 > +static void clk_core_evict_parent_cache_subtree(struct clk_core *root, > + struct clk_core *target) > +{ > + int i; > + struct clk_core *child; > + > + if (!root) > + return; I don't think we need this part. Child is always a valid pointer.