Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1928780imm; Thu, 24 May 2018 03:05:38 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoYYFo63ZzejuHxe2/lqdu/Gm7Tzmma734fRNTOIhsWH0g/thrwVogr83eWb1jQzuVsfVLN X-Received: by 2002:a63:7145:: with SMTP id b5-v6mr5339820pgn.45.1527156338136; Thu, 24 May 2018 03:05:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527156338; cv=none; d=google.com; s=arc-20160816; b=io0lvSLtvdsDBXZvPB7QsFVamryCJv2qP6vKV1s0RijP8lxU7NuOCnF7ncoiY6og/5 9PySeOw8QeWqRjI27GZxb1+Pi17cjYfgdwDhRoHaUDhfyTrhk+Xe9sYdW2qyL5HvOej6 arRU3GKfxSPRn73DIZcvXYfcwwdvb6ouRKXKrOXfgbSD8PzmjIbBOgH7Oy/If8HcDL8w IRaiNf+DJ9pjrT5ohxcpWtnsyjcK4x8NrN7tuVwgsIobf3dMzdpXbyL20xvjM9WeROK/ +f2rf5ruD673K8a6EqZmQR+2dMkCQryIMub2dYiDnGshFETthPB1SHhUrb1UqEmXDZnG 2/fQ== 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:dkim-signature :arc-authentication-results; bh=SJFg4MwbYn8C6f+WBwM3X4vJZEJznh9zBVPNtZrfVtg=; b=KrXeWb+57tjhMiykotn5dPj+lAPZWV/kheOV6bgkDrmMrbqNg9yloB9Xsc+boijWzx Uw0sJ1TkVMxU6PCa/P7CnGbdoR5O//VVO23eI2ZVMTuabsB9gA8kJSGMDb48mI18N20Z ZfI91JGPeaQtOVKnUwT551gjETU/KfJzlMKcVFFipNqrpTVw12gDvA+/JyM4e1K3eh0h mvNizzEGGws2Sg9W5h9ir9TG/talp/GbroPJadQsgO03tdHaqBAMeMgmylmBNxcH0vkq wLyqxmea5I1vJFfiLjQBjsEDaLMsKrE+sfYK0DEc3R928XYxhkD9bBihiionu0KizhHx PoRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=GQX7A8Wg; 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 s5-v6si16468925pgo.12.2018.05.24.03.05.21; Thu, 24 May 2018 03:05:38 -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=GQX7A8Wg; 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 S1031425AbeEXKE1 (ORCPT + 99 others); Thu, 24 May 2018 06:04:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:53760 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031035AbeEXKEW (ORCPT ); Thu, 24 May 2018 06:04:22 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (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 98DDE20897; Thu, 24 May 2018 10:04:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527156261; bh=e3YLHszbBx1/9vQnZTGRtulimR/K4btiLSE1OKPcYmo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GQX7A8WgmSwKXkxQMP2x/Ekp/xDax6gJcToSJZC9GXDzG/3zi58X+L7gOufp7guP+ TdZxoQeReLxzHs7St6LzYI9XAE8DJSHlazck1yiKdQqzzMpThBLZYJ2o14OwUFjjUD 7XrC1l07MqgpqOCKvE71GAxcmyLF09IUA//iPbcE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Shawn Lin , Jerome Brunet , Stephen Boyd , Sasha Levin Subject: [PATCH 4.16 122/161] clk: Dont show the incorrect clock phase Date: Thu, 24 May 2018 11:39:07 +0200 Message-Id: <20180524093032.901943225@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180524093018.331893860@linuxfoundation.org> References: <20180524093018.331893860@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.16-stable review patch. If anyone has any objections, please let me know. ------------------ From: Shawn Lin [ Upstream commit 1f9c63e8de3d7b377c9d74e4a17524cfb60e6384 ] It's found that the clock phase output from clk_summary is wrong compared to the actual phase reading from the register. cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample sdio_sample 0 1 0 50000000 0 -22 It exposes an issue that clk core, clk_core_get_phase, always returns the cached core->phase which should be either updated by calling clk_set_phase or directly from the first place the clk was registered. When registering the clk, the core->phase geting from ->get_phase() may return negative value indicating error. This is quite common since the clk's phase may be highly related to its parent chain, but it was temporarily orphan when registered, since its parent chains hadn't be ready at that time, so the clk drivers decide to return error in this case. However, if no clk_set_phase is called or maybe the ->set_phase() isn't even implemented, the core->phase would never be updated. This is wrong, and we should try to update it when all its parent chains are settled down, like the way of updating clock rate for that. But it's not deserved to complicate the code now and just update it anyway when calling clk_core_get_phase, which would be much simple and enough. Signed-off-by: Shawn Lin Acked-by: Jerome Brunet Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/clk/clk.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2375,6 +2375,9 @@ static int clk_core_get_phase(struct clk int ret; clk_prepare_lock(); + /* Always try to update cached phase if possible */ + if (core->ops->get_phase) + core->phase = core->ops->get_phase(core->hw); ret = core->phase; clk_prepare_unlock();