Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3758577pxk; Tue, 22 Sep 2020 01:33:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwRp06oobYH+l8G+WrQ3nnQZ71Rx7E8g5ytIEVSSP9z6VqSxS4uVsD26p8uuysDtOFQ4Li X-Received: by 2002:aa7:d648:: with SMTP id v8mr2822158edr.159.1600763587636; Tue, 22 Sep 2020 01:33:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600763587; cv=none; d=google.com; s=arc-20160816; b=dlUnwLzzlf8lq4wlaIkCZnIJgXf7MQTiFPLL7H0DdEvOC672AQvf0slmh6kpNSEhr1 JIbuN3GKunLdF4ajbMUgUMW/Nyv61m1YOrPZMFZvedsPdQP8M83m7vGNPhK386+9hKsH wsRYu3213lGTJhBeiOtBsWm7iv3KXqoaffrIgSJo6aeXZOB9p8Ob1X08EI8/NcYC08Y0 mc6r1amkTxGDU2Tu3E1fuAf1Dp5Ryo37L+ERa07Q3SEpYPyvJDRFyp0ZNkm95ymmfdqJ BCy2XVq8UdoVeK1eJpNPSShUtbRUQ5dCNvySC9ScEztP3x+yBUfUL22Pu23Fl3UfMD5x U9cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from:ironport-sdr; bh=KDNGKJlKSYb43Dh4GB7t5+38R49ZWQcg50HonWdsdZ4=; b=bVtP3XZl1HXE0eQGmvA/xblcmNgQsFz3ROo4My/Yr8nDQekBhSZJhsmwg0q4FnCk6i dwS0dWq4NHie/kD2EOXUMTkr+KWWKu7UU7r8pfyqVf9kPCRF46GpRNPtbKSVHtFrWcPw pvVhw/6yF3FTaoUY/QyM0cMFY633CcpAvunzqpJTsm3kvd8UisJ/x2IhYV9eDUXZTPr7 2nbCDNdg6PiY+jTQwgIP4VtMl0G/Kf619yRnKwsKfB/298xI0xpWCHWUmkbJAJ6dZV3k ch0DICSWOoO+TxVFt7wcEC+2fDhenmRkgP75Gkr06oLuIb08NTyryRxAO4UsNZ5p6etP ENXw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u20si9577131edi.129.2020.09.22.01.32.44; Tue, 22 Sep 2020 01:33:07 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729704AbgIVHNN (ORCPT + 99 others); Tue, 22 Sep 2020 03:13:13 -0400 Received: from labrats.qualcomm.com ([199.106.110.90]:9654 "EHLO labrats.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728526AbgIVHNN (ORCPT ); Tue, 22 Sep 2020 03:13:13 -0400 IronPort-SDR: e7YpYL10wF24JN8gGfcVAhUbG85jKVpKaDX25U3G+TtfcH+0agOiqCM1tlBnKKscgFdsFUueFj FfykhwMzS1WXRbUaQ/IpQhySUMYX7yw4d0DYh3ztmebWHCUctl/p/m2cjElqemzh5AFN5pjjBu lVqgVDvqaDsdoYqumvrJOENQM+Zxe2J9IQGgGyV/hl3k4kXt5JeqD52PzS14prcvXR0+Ml2Ibo xmlXtiqdpCmqu/LHTOaZO/rv/YPTvMWfYn+5lkidd05zU7iWPjvc+FouVdA+6K4yNbHZq956fp +Vs= X-IronPort-AV: E=Sophos;i="5.77,289,1596524400"; d="scan'208";a="47332985" Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by labrats.qualcomm.com with ESMTP; 22 Sep 2020 00:09:12 -0700 Received: from wsp769891wss.qualcomm.com (HELO stor-presley.qualcomm.com) ([192.168.140.85]) by ironmsg05-sd.qualcomm.com with ESMTP; 22 Sep 2020 00:09:10 -0700 Received: by stor-presley.qualcomm.com (Postfix, from userid 359480) id C9F3B21653; Tue, 22 Sep 2020 00:09:09 -0700 (PDT) From: Can Guo To: asutoshd@codeaurora.org, nguyenb@codeaurora.org, hongwus@codeaurora.org, rnayak@codeaurora.org, linux-scsi@vger.kernel.org, kernel-team@android.com, saravanak@google.com, salyzyn@google.com, cang@codeaurora.org Cc: Alim Akhtar , Avri Altman , "James E.J. Bottomley" , "Martin K. Petersen" , Stanley Chu , Bean Huo , Bart Van Assche , linux-kernel@vger.kernel.org (open list) Subject: [PATCH] scsi: ufs: Make sure clk scaling happens only when hba is runtime ACTIVE Date: Tue, 22 Sep 2020 00:09:04 -0700 Message-Id: <1600758548-28576-1-git-send-email-cang@codeaurora.org> X-Mailer: git-send-email 2.7.4 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If someone plays with the UFS clk scaling devfreq governor through sysfs, ufshcd_devfreq_scale may be called even when hba is not runtime ACTIVE, which can lead to unexpected error. We cannot just protect it by calling pm_runtime_get_sync, because that may cause racing problem since hba runtime suspend ops needs to suspend clk scaling. In order to fix it, call pm_runtime_get_noresume and check hba's runtime status, then only proceed if hba is runtime ACTIVE, otherwise just bail. governor_store devfreq_performance_handler update_devfreq devfreq_set_target ufshcd_devfreq_target ufshcd_devfreq_scale Signed-off-by: Can Guo diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index e4cb994..847f355 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -1294,8 +1294,15 @@ static int ufshcd_devfreq_target(struct device *dev, } spin_unlock_irqrestore(hba->host->host_lock, irq_flags); + pm_runtime_get_noresume(hba->dev); + if (!pm_runtime_active(hba->dev)) { + pm_runtime_put_noidle(hba->dev); + ret = -EAGAIN; + goto out; + } start = ktime_get(); ret = ufshcd_devfreq_scale(hba, scale_up); + pm_runtime_put(hba->dev); trace_ufshcd_profile_clk_scaling(dev_name(hba->dev), (scale_up ? "up" : "down"), -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.