Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp1033051ima; Wed, 24 Oct 2018 13:11:16 -0700 (PDT) X-Google-Smtp-Source: AJdET5c75rFf7figBbzrDtAQ02//TvxNlUpLANJZDgNkWwhhWxzZIj1aJ5M4uNRYveNfAfaPhIaF X-Received: by 2002:a62:564e:: with SMTP id k75-v6mr4001571pfb.33.1540411876549; Wed, 24 Oct 2018 13:11:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540411876; cv=none; d=google.com; s=arc-20160816; b=Ca+JU23jRqIM0Nme20ucv1kUDdN4AfsqfQ4NIBUCWpt6O9VoZcEWYm6LWIfwbRG3ku MJGk68n7GJ43NdPvRwvrefZ56hcIUDJ5Y+1GGR184riIAasUJcIcCWxA3INS+n9yP+Wr MkFP3Tfj2se8Yf6nUm4gy7b+gUh2sOUyXrr9ArVOs+zoUqHx0m3LydLRI31XwaXtMJtQ bNBi6zBx9CYLc0oCKGZTQzkqIwSYJApW53VznpNE9Mxo8sE5z40ntsjQhMyvejwvhKXO lD7K2KfQztv40sOgp/LRaHHpNx3rnO64oCRJqjbScBJn4i5shYwXQThzmDVxIHre6G6s 9f/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=myUIaGAQ4FX09BC3WcQ/tTbGenycR0huzAA5WP9HNOM=; b=V65NqH1wksgi5khxJjDS6rfH+zajRepnllsbLOSDzcMZqx/gF41Es8CVEifWW/jifn is6L0d48QDqy5k1WnE5DxIsb7G7Xu8lTlgTbMWoz26x+9maHXtf2CddEO/qp4fdGSfpJ 1lKuAfwulnYB2x7ZLHTpLo184Fl9vWx5q0Cd0sMC8+tRKUyuVO9JxPVlOo84Pgq+DbEt s1avLaep2v6gVFSIGwiSQsmOcFVXrrKdyrm23vArhFp8bEodGmDetLSXUB1U+NNz39OG u9zOyxJeLUQkk/YzyMflOoUBsO+xD8C0VzxHpSDgseSJ3377gKK6YUkyxaGNHxCEPbeM UkTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="BCa/w9Kq"; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w11-v6si5375004pgs.377.2018.10.24.13.11.00; Wed, 24 Oct 2018 13:11:16 -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=@chromium.org header.s=google header.b="BCa/w9Kq"; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726398AbeJYEir (ORCPT + 99 others); Thu, 25 Oct 2018 00:38:47 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:46185 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725829AbeJYEir (ORCPT ); Thu, 25 Oct 2018 00:38:47 -0400 Received: by mail-io1-f66.google.com with SMTP id y22-v6so3950749ioj.13 for ; Wed, 24 Oct 2018 13:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=myUIaGAQ4FX09BC3WcQ/tTbGenycR0huzAA5WP9HNOM=; b=BCa/w9Kqa9uMTeQwC1JOhravLnMIgNNPp8L1DXtvsKbPyw8Gzfh5L3JzRb+eI4HCAg HjS2dou6uBQ189nOnHvQGwo/ZRm2eUgRRFAqtPONkVsGYF0c9W+6HAQTFcmIajf/HEmq JuM4St/WzCKJ5lA+rwMCD0bGoQcuNoUNDnhw8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=myUIaGAQ4FX09BC3WcQ/tTbGenycR0huzAA5WP9HNOM=; b=rmbPy2H08Nwmmt8TBP3FaMwgByEDQOfT1N6o8ZtyTM3V4FEAuYAAtGc8+U7l98zYTz xgtx3zs9AwsobIkotCzRwW+Hdu/u94iHUS3uwwkchWTgENLbi/5Ws21VESyNzRIDRhx/ mVgHZkURtfzwsGRTb71IBIiQ7iMQlnkMhqGAQSEBZM/xsiEjt6a2u+UA0H3E3ihoAtG/ TMbAuey5akvrDrKDEB6IARRs8qvwRpk07hK6Igavt+WP8GMf11v9J+cXXTZDzGpkBuMc qCkbijMz9r009MdkWmveuFLMEEzDiRkTPmArhw/OvfTCk5WQ8IhA4FJU4zNdhiEdSMK5 WYFQ== X-Gm-Message-State: AGRZ1gLeT3T8znIueiHydVX8I4PZZJIbcCKBuZuxhB+QJ9nnHRiGBsdO 3Iygd7lgVkKaJKVX41CnJpJWmdlxWBvSKllVrDucjYnkf6Gx7Q== X-Received: by 2002:a6b:ac45:: with SMTP id v66-v6mr16627405ioe.66.1540411758345; Wed, 24 Oct 2018 13:09:18 -0700 (PDT) MIME-Version: 1.0 References: <20181024013132.115907-1-dbasehore@chromium.org> <20181024013132.115907-2-dbasehore@chromium.org> <154038647375.53599.631725372765617195@swboyd.mtv.corp.google.com> In-Reply-To: <154038647375.53599.631725372765617195@swboyd.mtv.corp.google.com> From: "dbasehore ." Date: Wed, 24 Oct 2018 13:09:07 -0700 Message-ID: Subject: Re: [PATCH 1/6] clk: Remove recursion in clk_core_{prepare,enable}() To: sboyd@kernel.org Cc: linux-kernel , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-doc@vger.kernel.org, Michael Turquette , =?UTF-8?Q?Heiko_St=C3=BCbner?= , aisheng.dong@nxp.com, mchehab+samsung@kernel.org, corbet@lwn.net, Stephen Boyd , jbrunet@baylibre.com 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 On Wed, Oct 24, 2018 at 6:07 AM Stephen Boyd wrote: > > 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. > It should just be your patch with the compilation warning fixed. This is picked up from https://lore.kernel.org/patchwork/patch/814369/