Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp21879imm; Tue, 17 Jul 2018 13:09:27 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfetsZnBe+FIvhRUk2y/XH4fp1h5IughrEbpEU57FOnzLOcCBm9Eu20fcYhPxKUvN6WgqeV X-Received: by 2002:a63:f953:: with SMTP id q19-v6mr2870171pgk.292.1531858167181; Tue, 17 Jul 2018 13:09:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531858167; cv=none; d=google.com; s=arc-20160816; b=M9rSg3Q9KNhwPY75uxo2jTAfmPwbA82kAH3fJoaxRwGFj057D4JjMfix2XctU5/RMM zzBmpjPtlmmpLeKxNfsc6Y6zOQOiMD2eDCSiYs6FaKMspI6vCf3B0VC3Ttu+MZDcgs5u mPCNW52ybMPCFVpr65rpf3AnkoZXv/7aRBvV5eDNOu6qPayrYvgeaqhu2c6cG9oARd0d VjhXYUAN3NxzoSG+m8WR/ck9IS0HSIpewz901vQT0eTo26747G8ng6BEyWBHqYGs3jEb Ju1BPcsq73A486s/COocTUi22CHolKObj0I4I8r2iVeUwWwAYPzunWol768shEC+U3sf aGSg== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=sF5AlaQP39FqOPzedF3gA0UAv8cCONHNYLOBoqDZm/k=; b=B5/jGAMcGxvWtNKmOiENS/FIejlBEII+T2+07RDav6sEDQzcxW7EW20/r+icLwPKvD UiOShMdVkqVqOS8R1nzzOLsdU8LWHRoqB7id9SOYQ6nN/1IwzxxcktvjV8t+V/jLnysV 1y4856C4kGF4NnUK+fLOSaVP/ctJRaAZieOy/HS3FP2A8tvK4Id1QJkwAdbB4QkUb3Sm BRhmmY2fuhwchc4K1RgT3cPzUC++w8Uf0nMn8jRsO4rWi3v8ANucM2yIqKe5FAHM3AEn qe9GXEthh2mOfZiXjZtkchnFxWlofrAB1eHZLXpRhPOvZDZ4mKe1v38YUx8UIr3DqNgS u6ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=avISY3Kd; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 196-v6si1591964pgg.588.2018.07.17.13.09.12; Tue, 17 Jul 2018 13:09:27 -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=@gmail.com header.s=20161025 header.b=avISY3Kd; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730718AbeGQUmw (ORCPT + 99 others); Tue, 17 Jul 2018 16:42:52 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:41682 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730040AbeGQUmw (ORCPT ); Tue, 17 Jul 2018 16:42:52 -0400 Received: by mail-oi0-f67.google.com with SMTP id k12-v6so4413116oiw.8; Tue, 17 Jul 2018 13:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sF5AlaQP39FqOPzedF3gA0UAv8cCONHNYLOBoqDZm/k=; b=avISY3Kd1GSHWsSir1HMr6HTodWZgXzVvsHKf7TGf+ZfEc6/R3MYDVUUDS6Brsttkc oKzcOcU6eZp7WvCFXpNBCpYlXLDTgWNfMKcDB+QYS/vVd+/3g9CYpmcQ3mcrvfmAUtqO UvYtfIhFLg9w2XTDGDU+HImIlh3hdm9vCcn6V03vj2biAAbXHES/Eb0x5bnK/dFTIrHz j01QR1gpFdkR0grWpVN7phD9CKw57gr2GxyKRsfbPy0YOnO4Eiu7gjGCQhF18K6qvH6v c65xIFQsz73iEib39zOGOM6uQu20DZ7/U1Yrw/e0gQuUfC9lfu431uE7mJFfZyJKC/su g+Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sF5AlaQP39FqOPzedF3gA0UAv8cCONHNYLOBoqDZm/k=; b=No0QZIvcpAiZ9/DKGDQaB+s0PZUqr3h3Tr7C5sMVImHSIrPBGs8nzYDybOZo0UimvV fvAo7vILB4pvC8TWtNm8YVf9ssS3fME/sS5veTZIvFOLEr73JkDXUxSM1ALVE9Hvyyh8 6qUjM7nTc/VSlfzgRzyVlMam+XUjWmtqrjYyxJSznXxSP+lEBJLmDmq1ypd60eR/4NeP 1Cq5QA/ZKtkxLT/JPWqATq+DXXB6+9//qhLUL5BytClDWuM/rWf0fWyN7Upl2JuhO6W6 YSzEIBtwhcWOzeoPXDp1ONV8bYVSATKvVWrXtUqDhWWZLPeH32B85XjbHbbEq4B4oNgj tOXA== X-Gm-Message-State: AOUpUlFqodx0qC55uvZu7d83BKJrpu5OCYDukRPBkEGKkSZr7Y+laAiY TMGzA5ly5+wMPLVdS65gMSMxyFZpHv6KKMoXBzM= X-Received: by 2002:aca:56d1:: with SMTP id k200-v6mr2974796oib.319.1531858118040; Tue, 17 Jul 2018 13:08:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:5b33:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 13:08:17 -0700 (PDT) In-Reply-To: References: <1531822342-4293-1-git-send-email-linux.amoon@gmail.com> <1531822342-4293-2-git-send-email-linux.amoon@gmail.com> From: Anand Moon Date: Wed, 18 Jul 2018 01:38:17 +0530 Message-ID: Subject: Re: [PATCH 2/5] thermal: exynos: cleanup of clk err check for exynos_tmu_work To: Krzysztof Kozlowski Cc: Bartlomiej Zolnierkiewicz , Zhang Rui , Eduardo Valentin , Kukjin Kim , Rob Herring , Mark Rutland , Linux PM list , "linux-samsung-soc@vger.kernel.org" , linux-arm-kernel , Linux Kernel , devicetree 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 Hi Krzysztof, On 17 July 2018 at 17:54, Krzysztof Kozlowski wrote: > On 17 July 2018 at 12:12, Anand Moon wrote: >> cleanup err check in exynos_tmu_work as clk internal >> framework will perform if clk is enable/disable >> so drop the double check of IS_ERR and other such references. > > I do not understand the statement. Clock framework will perform if clk > is enable/disable? How clock can be "enable" or "disable"? You mean > gate clock? you mean clock pointer is an ERR pointer? > if (!IS_ERR(data->clk_sec)) check if the pointer is valid or not this check is again performed in clk_enable. >> CC: Bartlomiej Zolnierkiewicz >> Signed-off-by: Anand Moon >> --- >> drivers/thermal/samsung/exynos_tmu.c | 19 ++++++------------- >> 1 file changed, 6 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c >> index 0164c9e..2dbde97 100644 >> --- a/drivers/thermal/samsung/exynos_tmu.c >> +++ b/drivers/thermal/samsung/exynos_tmu.c >> @@ -300,8 +300,7 @@ static int exynos_tmu_initialize(struct platform_device *pdev) >> >> mutex_lock(&data->lock); >> clk_enable(data->clk); >> - if (!IS_ERR(data->clk_sec)) >> - clk_enable(data->clk_sec); >> + clk_enable(data->clk_sec); >> >> status = readb(data->base + EXYNOS_TMU_REG_STATUS); >> if (!status) { >> @@ -334,8 +333,7 @@ static int exynos_tmu_initialize(struct platform_device *pdev) >> err: >> clk_disable(data->clk); >> mutex_unlock(&data->lock); >> - if (!IS_ERR(data->clk_sec)) >> - clk_disable(data->clk_sec); >> + clk_disable(data->clk_sec); >> out: >> return ret; >> } >> @@ -789,19 +787,16 @@ static void exynos_tmu_work(struct work_struct *work) >> struct exynos_tmu_data *data = container_of(work, >> struct exynos_tmu_data, irq_work); >> >> - if (!IS_ERR(data->clk_sec)) >> - clk_enable(data->clk_sec); >> - if (!IS_ERR(data->clk_sec)) >> - clk_disable(data->clk_sec); >> - >> thermal_zone_device_update(data->tzd, THERMAL_EVENT_UNSPECIFIED); >> >> mutex_lock(&data->lock); >> clk_enable(data->clk); >> + clk_enable(data->clk_sec); > > You are changing here the logic completely. Before the "enable" was > followed immediately by "disable". Now you are moving disable > somewhere else... All this looks suspicious... I chose to move enable/disable of clk_sec this under the mutex lock for safe which dose the same sequence with different order. Second approach: We should get rid of clk_enable/disable in exynos_tmu_work as this looks unnecessary for toggle clk's on every update. Best Regards -Anand