Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3120341pxa; Sat, 8 Aug 2020 10:16:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNPqRyg9NfYwHoKB/nci5OyDUOGXEYkVZKRjM+wLDN3H72Tadi55jkkalyiE4HYQb4p50W X-Received: by 2002:a17:906:e2d6:: with SMTP id gr22mr14346223ejb.455.1596906999189; Sat, 08 Aug 2020 10:16:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596906999; cv=none; d=google.com; s=arc-20160816; b=oBDKFiNGjNR82n8znr7cjrmHQMyaAhQhlWHLj20uVcx++2MUux62MQ/6cfACTz71Fn f/aAP6Um9vxqY/JtYxmeo/y77+rC4QIlKVmA3F8j0MaRywIOO0WODPmswO5NzkIoMMA7 AVNNutVh0eCKHvMss8vN0Lvtb6x92J7H8b2GcxNSi+8EbH5JI/jSD4fl5Y5iSri3ohOo vn8HYRX1Csy7HgE0bBpUlG/ygIqCgtTrVuW615KajvefWiJIs0dLdZtVwA6e5kT3Qxr7 bEG91EJwaCxWFYY2+eJVcn8oB50jCK/iqvb/H7ul9tQGSfdKiHNq6l+IlpkDf2i0WbHA XG1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=10CvMVkFP5s0ogDLDyQLYDDtzvGA2GFASeeImWfNvUk=; b=0Qdq7T3RwresBLvbekJzZKUV/L064IMMupe3G1ULw8tEwjNGMD1lo1Z0FS5pOxPTTS HUzpb69ZI8F62CndpvVrSuWGsBH2nQhi8kRxoUYYiSyrGChgyAG2AtOf2xXOJ/E3fCW5 SrMqn47OHbVkhrRVXaZ+mhJCgq8VTiC51A5YKJCNGjmuZgcV8Z93ZFkZZsEBgWySvVwW 9nZRYD27RhpCvvpo6KXIs6qO3bmv2Uq4f92mf/MPoGRI1DusK7tyII/xeiwjgpeUccBJ jfYjJ/8omG3/rZEEZeUS5FlOMi9WfBtF3KFHpDYqWa9k93U0fM5dbCa+0Q/L8sWV1IY/ 000Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=V5zmyG2W; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x13si7590666edv.323.2020.08.08.10.16.14; Sat, 08 Aug 2020 10:16:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=V5zmyG2W; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726346AbgHHRNT (ORCPT + 99 others); Sat, 8 Aug 2020 13:13:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726242AbgHHRNT (ORCPT ); Sat, 8 Aug 2020 13:13:19 -0400 Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA417C061756; Sat, 8 Aug 2020 10:13:18 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id w12so4971921iom.4; Sat, 08 Aug 2020 10:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=10CvMVkFP5s0ogDLDyQLYDDtzvGA2GFASeeImWfNvUk=; b=V5zmyG2WJuuFRtXQWYNAehEPBSYzwi8qVw7YmJ9J92ZGxTUI3Tj3VA5ZAXaOo5E7dX jW1jq+SfY6CsA9PNjUeGHqd4HxfznppRMyHO1Ny4OvIpxpEfp7kg2chqEQR/fw2d/txO l+S+yq8d2X/KRIoBmR4WVsYIWi5Jg7OuIlpSXqu+FVDL2sHDoRL9yhZpLmaMc9PiyKOp ijCw2OapJAkYJut0Qf7mVS/5Ngs3I4a9M45wN1OvyUirQD1D8aYlYnFK8CEvIS0R34Br aCwcrLJdAvGPoRoHU778k01OI+CZg5kJbehPUkdprZUJ7OaLz6cw/VU1hOeMkjE9kuNv MorQ== 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:content-transfer-encoding; bh=10CvMVkFP5s0ogDLDyQLYDDtzvGA2GFASeeImWfNvUk=; b=WZQBwAGBTuyDJbfgfLvpx03D+uACpAzmZY/rIn6O4elef036wITx5cC9sCgoWuv/Bj KCgts0RgK3wh0D6l4jqaVWwiLYTZ2HFJ/2YMfsIps8IAPWbgoflctUjOZy2ej9oIBQrX bhtqsrIUFg09N+SLOySE5XoEttOtba0bUBoVBphjt6CQCpW6zTS2MvDb8rfGvAZL0IEk rfcn2Xo4yVoZwyQL31viMLz7o9x3wDq6+WTqymdGeN9EfwDvUnnpN1snSO95NbY+LLDg sHLjoB1IVygFCqRHaLdo1zoq9LNQnh/7MiB9F20+fwULXMBDgs0UjWmQIorf7WZoZPa4 XNKQ== X-Gm-Message-State: AOAM533+C7896IFeqb4vCUhNrpzYDKHYIz2tV2AmqW73fl8evOUt5D43 Ndf73PQDfMdXPBx+cOgT0ooFeSV66pT76dy+qU8= X-Received: by 2002:a6b:b888:: with SMTP id i130mr9996946iof.182.1596906797218; Sat, 08 Aug 2020 10:13:17 -0700 (PDT) MIME-Version: 1.0 References: <20200806160646.1997-1-s.nawrocki@samsung.com> In-Reply-To: From: Tomasz Figa Date: Sat, 8 Aug 2020 19:13:05 +0200 Message-ID: Subject: Re: [PATCH] clk: samsung: Prevent potential endless loop in the PLL set_rate ops To: Sylwester Nawrocki Cc: "open list:COMMON CLK FRAMEWORK" , Chanwoo Choi , Stephen Boyd , Mike Turquette , "moderated list:SAMSUNG SOC CLOCK DRIVERS" , linux-kernel , Bartlomiej Zolnierkiewicz , Marek Szyprowski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2020=E5=B9=B48=E6=9C=887=E6=97=A5(=E9=87=91) 19:06 Sylwester Nawrocki : > > Hi Tomasz, > > On 8/6/20 18:11, Tomasz Figa wrote: > >> --- a/drivers/clk/samsung/clk-pll.c > >> +++ b/drivers/clk/samsung/clk-pll.c > >> @@ -63,6 +63,27 @@ static long samsung_pll_round_rate(struct clk_hw *h= w, > >> return rate_table[i - 1].rate; > >> } > >> > >> +static int samsung_pll_lock_wait(struct samsung_clk_pll *pll, > >> + unsigned int reg_mask) > >> +{ > >> + ktime_t timeout; > >> + > >> + /* Wait until the PLL is in steady locked state */ > >> + timeout =3D ktime_add_ms(ktime_get(), PLL_TIMEOUT_MS); > >> + > >> + while (!(readl_relaxed(pll->con_reg) & reg_mask)) { > >> + if (ktime_after(ktime_get(), timeout)) { > >> + pr_err("%s: Could not lock PLL %s\n", > >> + __func__, clk_hw_get_name(&pll->hw)); > >> + return -EFAULT; > >> + } > >> + > >> + cpu_relax(); > >> + } > > > Thanks for the patch! Good to have this consolidated. How about going > > one step further and using the generic > > readl_relaxed_poll_timeout_atomic() helper? > > Might be a good suggestion, I was considering those helpers but ended > up not using them in the patch. The cpu_relax() call might also not be > really needed now, when there is the ktime code within the loop. > Having multiple occurrences of readl_relaxed_poll_timeout_atomic() could > increase the code size due to inlining. How about keeping the > samsung_pll_lock_wait() function and just changing its implementation? Sounds good to me, thanks! Best regards, Tomasz