From patchwork Thu Oct 19 17:05:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Lezcano X-Patchwork-Id: 10017849 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 21A91602C8 for ; Thu, 19 Oct 2017 17:10:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0CB3428D51 for ; Thu, 19 Oct 2017 17:10:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 01D7128DE1; Thu, 19 Oct 2017 17:10:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_SPAM autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0414B28D51 for ; Thu, 19 Oct 2017 17:10:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755120AbdJSRIv (ORCPT ); Thu, 19 Oct 2017 13:08:51 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:45280 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753422AbdJSRIt (ORCPT ); Thu, 19 Oct 2017 13:08:49 -0400 Received: by mail-wm0-f65.google.com with SMTP id q124so17347928wmb.0 for ; Thu, 19 Oct 2017 10:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=ml7oe/0YASyeXw6/R0x/YhaVd3BkPfM0Dt8qWCr5GTg=; b=MMD8Ts2m85jDApV5Au8lq3JOBzvpbORTmHIeayr7bbFnAdyiJYkU3tXkND+t56AAx7 eC5QzKoFxYe+0c3iKkT+oikjyaXJImowl1Az0tvc3SmJKNKKPjW9GaJyHgnaMZWLcJzO VWeMieJDjJboLleu/LgscXp+yhkkHfRwgmYAc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=ml7oe/0YASyeXw6/R0x/YhaVd3BkPfM0Dt8qWCr5GTg=; b=knIe4MeYc1UqrpA4+tPb3riUkSLHtObMMLKe4Sy6YgNGGNBrx7keLZL0cWwSfRCkxv GzNm/HeedrkLK6Nytc+eFCNu8n/j5uqXya4eVGWOG9MD2vRREwumO+DmNAjqUBXi8rIG rTRfipwoprH/haBRdJK93b4bgvoHlLZPbChuuuUDtZ8EXveUJ5zVLSLS990q4fgQllRP b8VsI6VB+81acIFYHsLy0mLHVr/eCOFGhDVH3RsJoBgiym5eprr2CV3fCjWjsX9z07oe Czyd407EWv2VaeagSS+oIY35iJ8NKeWnkOvO2pap76P26rNAo/vY41zP5Iba8gMwZsbF 0tCg== X-Gm-Message-State: AMCzsaXuXMCq/7CEtzHk4PWKb8Th1LmuJQgkh2MOPEjZb3Q7HRYE1R0g 9yb5hIKe4OEzTMNBc7zYlWSWnssD7Mc= X-Google-Smtp-Source: ABhQp+QmVpluCm0pph+AaO7Mh9cvtXr80LMv0XyAn7vfJZ2/BWmjha/PiJamcBdHGnqAdsHhVI5YQg== X-Received: by 10.28.45.9 with SMTP id t9mr2331808wmt.94.1508432927846; Thu, 19 Oct 2017 10:08:47 -0700 (PDT) Received: from localhost.localdomain ([2a01:e35:879a:6cd0:51c7:d9b7:e14b:6840]) by smtp.gmail.com with ESMTPSA id g16sm14277394wrd.72.2017.10.19.10.08.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Oct 2017 10:08:47 -0700 (PDT) From: Daniel Lezcano To: edubezval@gmail.com, rui.zhang@intel.com Cc: linux-pm@vger.kernel.org, leo.yan@linaro.org, linux-kernel@vger.kernel.org Subject: [PATCH 13/18] thermal/drivers/hisi: Remove mutex_lock in the code Date: Thu, 19 Oct 2017 19:05:55 +0200 Message-Id: <1508432760-17847-13-git-send-email-daniel.lezcano@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1508432760-17847-1-git-send-email-daniel.lezcano@linaro.org> References: <6ac48f08-7fe6-92e9-0801-6ed3bcd05ff1@linaro.org> <1508432760-17847-1-git-send-email-daniel.lezcano@linaro.org> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The mutex is used to protect against writes in the configuration register. That happens at probe time, with no possible race yet. Then when the module is unloaded and at suspend/resume. When the module is unloaded, it is an userspace operation, thus via a process. Suspending the system goes through the freezer to suspend all the tasks synchronously before continuing. So it is not possible to hit the suspend ops in this driver while we are unloading it. The resume is the same situation than the probe. In other words, even if there are several places where we write the configuration register, there is no situation where we can write it at the same time, so far as I can judge Signed-off-by: Daniel Lezcano Reviewed-by: Leo Yan Tested-by: Leo Yan --- drivers/thermal/hisi_thermal.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c index b77ca19..8d1a8be 100644 --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -53,7 +53,6 @@ struct hisi_thermal_sensor { }; struct hisi_thermal_data { - struct mutex thermal_lock; /* protects register data */ struct platform_device *pdev; struct clk *clk; struct hisi_thermal_sensor sensor; @@ -200,14 +199,10 @@ static inline void hisi_thermal_hdak_set(void __iomem *addr, int value) static void hisi_thermal_disable_sensor(struct hisi_thermal_data *data) { - mutex_lock(&data->thermal_lock); - /* disable sensor module */ hisi_thermal_enable(data->regs, 0); hisi_thermal_alarm_enable(data->regs, 0); hisi_thermal_reset_enable(data->regs, 0); - - mutex_unlock(&data->thermal_lock); } static int hisi_thermal_get_temp(void *__data, int *temp) @@ -344,7 +339,6 @@ static int hisi_thermal_probe(struct platform_device *pdev) if (!data) return -ENOMEM; - mutex_init(&data->thermal_lock); data->pdev = pdev; res = platform_get_resource(pdev, IORESOURCE_MEM, 0);