Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3148655imm; Tue, 29 May 2018 01:47:54 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrx8n+Ol9EjzjK21ypFR13kavxx8ZzA27u4Eai5Qx0IUwSqQ+iLi7f84glcmMl9V35r8Re2 X-Received: by 2002:a65:5c09:: with SMTP id u9-v6mr13145579pgr.304.1527583674482; Tue, 29 May 2018 01:47:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527583674; cv=none; d=google.com; s=arc-20160816; b=ohFBcSpZbHhWaZiJaD4bBaBjAVp42w0DeUSBx6tyBwNWqIWphNriOM8DCgcGzcV39g x6gsTjjOEkW5fJH2jY4udFfarFY0cbJ1Yfmibgix2NWx+X9NPhnpyPtuiJIkmze69v19 UAhO6uG1hd16RIdCWgYG7vG2s7uxi2ww0gjB55w4LLKat9Ll9RyECiAlT2q+SmlyhwLF 0muO6IMdRhjuisSZSccSFDZkWR+sGl0r6RE/+E4B00teY625nmP6SSxjjPocUSG2JY+f mpJQS4vgXDvHlj//ZRq3abG4tsnBw5duptRzssWaQamFsQ3c5U4mc/mlukqaeS8MWYIc Jl/g== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=F3UZ2oezbOJPXS5zDHx1eLRm7yHqSEC2T2BDg9pnUsk=; b=XjPh6RrFNJtyFqAQm77BwRgFz/y4lPo7uruYtDATulGwDWuPZdWK36YZ70xTyiXkhf UWcYRLr4m36hCKa9WpElMoMDWQSNcix/ZTe3aqXMk0QahcnuAehG9r83UASyHjBTxEmj 3W0HJsqG/HpuGE/rvbxhanMrn/EWDkVJl5mQ6yLQNe47seepXAckVJFCDhKOctN7sDoQ SnxrdEnL9z2DWbXbXqC9t9wW6FHFuX6NdEOSwjLdAdCbk/IvibXE/FrICg8Z6taFqtZD Zw4gC+AFOGfZKARkcktcjCF7UJMUHJNHv9UU66Dyy2ty+5C9gSupgO5y9rnMfgtHhv34 ZRCA== ARC-Authentication-Results: i=1; mx.google.com; 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 p21-v6si9069567plq.94.2018.05.29.01.47.40; Tue, 29 May 2018 01:47:54 -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; 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 S1755395AbeE2Iqt convert rfc822-to-8bit (ORCPT + 99 others); Tue, 29 May 2018 04:46:49 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:46604 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751091AbeE2Iqp (ORCPT ); Tue, 29 May 2018 04:46:45 -0400 Received: from 79.184.254.169.ipv4.supernova.orange.pl (79.184.254.169) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id 0742ae9f6e63e4c8; Tue, 29 May 2018 10:46:43 +0200 From: "Rafael J. Wysocki" To: "Wangtao (Kevin, Kirin)" Cc: "Rafael J. Wysocki" , Viresh Kumar , Linux PM , Linux Kernel Mailing List , gengyanping@hisilicon.com, sunzhaosheng@hisilicon.com Subject: Re: [PATCH] cpufreq: reinitialize new policy min/max when writing scaling_(max|min)_freq Date: Tue, 29 May 2018 10:45:57 +0200 Message-ID: <3949526.VSbr9bPLlU@aspire.rjw.lan> In-Reply-To: <7700fad7-211d-d8b2-e4ee-975c1cf1f9dc@hisilicon.com> References: <1527144234-96396-1-git-send-email-kevin.wangtao@hisilicon.com> <7700fad7-211d-d8b2-e4ee-975c1cf1f9dc@hisilicon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT 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 On Friday, May 25, 2018 4:54:04 AM CEST Wangtao (Kevin, Kirin) wrote: > > 在 2018/5/24 15:45, Rafael J. Wysocki 写道: > > On Thu, May 24, 2018 at 8:43 AM, Kevin Wangtao > > wrote: > >> consider such situation, current user_policy.min is 1000000, > >> current user_policy.max is 1200000, in cpufreq_set_policy, > >> other driver may update policy.min to 1200000, policy.max to > >> 1300000. After that, If we input "echo 1300000 > scaling_min_freq", > >> then user_policy.min will be 1300000, and user_policy.max is > >> still 1200000, because the input value is checked with policy.max > >> not user_policy.max. if we get all related cpus offline and > >> online again, it will cause cpufreq_init_policy fail because > >> user_policy.min is higher than user_policy.max. > > > > How do you reproduce this, exactly? > > I write a driver register CPUFREQ_POLICY_NOTIFIER, and when event is CPUFREQ_ADJUST, > it will modify policy's min/max according to some conditions, I test it with writing > scaling_(max|min)_freq to traverse all frequencies repeatly, and also repeat hotplug > as background. You are expected to use cpufreq_update_policy() to update the limits in policy notifiers. Do you use it in your driver?