Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp579781ima; Wed, 24 Oct 2018 06:09:30 -0700 (PDT) X-Google-Smtp-Source: AJdET5d2jJoKeYM/9MlPbxKJ1Psikf/fYlrwBLBlp3r0vE6UGhNECTMUIoZqhdgofpKYFysMuc5g X-Received: by 2002:a62:22c3:: with SMTP id p64-v6mr2336000pfj.9.1540386570089; Wed, 24 Oct 2018 06:09:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540386570; cv=none; d=google.com; s=arc-20160816; b=tnThtGP21RjzTmyH23HKwMpg4vnKFsIIqj4O4smo3pALb4poqcTyM+d1rBrGUcZbYh YHR/LDiXfavIt8fbOKrts55ukKgDvlkLJJvSGJU9FnkQi7lFqvlDGyCZ9xI7kkeDLR3N 06mAFhlj97o47brQ9Mdjntapq2QNooFXZKeNDL6DiW9lt0HyY+fNywRo7X2YgADIHJcn DkMNUQu3U0O6njGWFRsYt3B+dYJpVDe8vPhx7mHhB3IIf8NXl71hytZ/9K/TXkQw/7Yc tNEpQXov4altVX3/YIN1I/knw21BFlhW8Oo9Bmhv5lO9ezu6yisUNJgnSTaDH32mgQub iqVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature; bh=Ux2wTOcJdcAMlG0IVHnIbrQ10+25LJ1VZR/4E5o1AO0=; b=uYnhB0mVV1pyfzyCXvuh4yVtRZAnqbrZ6crYc/rWJ7DVrLeZs0UmrX83YUE+sJpOjU XuujVc9NwvDIZUQRkfGY7rro5VmW8mCPM6LLLkaKfXiptH0Rv6C9HBL2qpjx0OxBH4I1 Umpa7dukeFLRNV2fGe/CZwsPNVvuv8sOi1Zr++qxNuYoN2WO0C2AVIrjtU9GjdQUtJBg 7QAE0JEnBg3YpLjP6nH0Gm/Q8kOFev1c48hhw/xYb53L4avYZM0ZIYSobNjqclXRoB3e OLex9G6CxE0NzQVNhU28wHoTSrHxIpwGA2orJAsj3zuGIzMyUq+fptRODP4Fpxt7O9pd KMZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ugZxX7dH; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d18-v6si4922918plj.82.2018.10.24.06.08.58; Wed, 24 Oct 2018 06:09: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; dkim=pass header.i=@kernel.org header.s=default header.b=ugZxX7dH; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726809AbeJXVf6 (ORCPT + 99 others); Wed, 24 Oct 2018 17:35:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:34816 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726633AbeJXVf6 (ORCPT ); Wed, 24 Oct 2018 17:35:58 -0400 Received: from localhost (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 82B952064C; Wed, 24 Oct 2018 13:07:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1540386474; bh=Ux2wTOcJdcAMlG0IVHnIbrQ10+25LJ1VZR/4E5o1AO0=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=ugZxX7dHytw3MERDa4RID+JXo3sOTB07GouKDfSPG8oYu0Gei5+IsthMRu+ZQ6lke UOgC8I4OY/k6TZ0h+T2h4Xu66xSAWxSB5TLgmTfuZmZ4IMtWa2zlt9EPYxlVIkAv+6 EBNm+H9QoA9uPWykyETEUU7F9a/i9WRfElV4qg5w= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Derek Basehore , linux-kernel@vger.kernel.org From: Stephen Boyd In-Reply-To: <20181024013132.115907-2-dbasehore@chromium.org> Cc: linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-doc@vger.kernel.org, mturquette@baylibre.com, heiko@sntech.de, aisheng.dong@nxp.com, mchehab+samsung@kernel.org, corbet@lwn.net, Stephen Boyd , Jerome Brunet , Derek Basehore References: <20181024013132.115907-1-dbasehore@chromium.org> <20181024013132.115907-2-dbasehore@chromium.org> Message-ID: <154038647375.53599.631725372765617195@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: Re: [PATCH 1/6] clk: Remove recursion in clk_core_{prepare,enable}() Date: Wed, 24 Oct 2018 06:07:53 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Derek Basehore (2018-10-23 18:31:27) > From: Stephen Boyd > = > Enabling and preparing clocks can be written quite naturally with > recursion. We start at some point in the tree and recurse up the > tree to find the oldest parent clk that needs to be enabled or > prepared. Then we enable/prepare and return to the caller, going > back to the clk we started at and enabling/preparing along the > way. > = > The problem is recursion isn't great for kernel code where we > have a limited stack size. Furthermore, we may be calling this > code inside clk_set_rate() which also has recursion in it, so > we're really not looking good if we encounter a tall clk tree. > = > Let's create a stack instead by looping over the parent chain and > collecting clks of interest. Then the enable/prepare becomes as > simple as iterating over that list and calling enable. > = > Cc: Jerome Brunet > Signed-off-by: Stephen Boyd > Signed-off-by: Derek Basehore Did you change anything substantially? Or is it just a resend of my patch from a while ago? If you can add a link to the original and also describe what changed in a maintainer tag it would be much easier for me to compare.