Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2189380pxb; Mon, 18 Jan 2021 10:30:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJwMoaBr4DsghX5tXY/SbzIIdF4tbvh5f1rwYYOLR4lMWMVNb1xERKhpEvcGjwYGGozO5QmU X-Received: by 2002:a17:907:94c8:: with SMTP id dn8mr661803ejc.512.1610994642804; Mon, 18 Jan 2021 10:30:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610994642; cv=none; d=google.com; s=arc-20160816; b=H+Cc9OWX07jLePEODIrW/CSmwIAo4NCFM2ju17ULyy1A+f728fkixqnaYVaEeXb6q4 ba4nMukeJlT7ChsVE+64WiU9WT7mzADbPRUaqwYoMqOdJhOFg70BEwZJLx9Lm36ffbNo EGj2tr/yvnzzycNh/YfxwvkdvY4ro1gtf8sCdJmvENVH1AzPpx1xuErLtrh6Qy5E9glT OPzS/hqN3uoZE2tb9Be78mzahrKJJZwXfeHIOL7yz2kAkI7pEc1z1yi9zwCCq22+eCIt n+C4GSrxcxfj/jljmt3SlPSPG85fEFi4bQByvh8ufADcJSUPE+RVR/qtGCIwPRdG9pLt kB5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=HbfwnMzVo9lboeP6/vCY6odbhTWYoclZOwUX8rhueKo=; b=mPhW/ufmpS4R4c4lvCrLW6I/X91Pg0Ggq/+zt8rziWqbrBGGblQ/oeyHnIEivePR3q kqX8zUGbU6Vi7HdCVM/XQgHgn63PCG0Vg1tCpQLY3MQazUotUVrD4BTzN3S0tovkhELH DJ1QE+tjALJ+OqWLrO8mLnFlCMEwL2VPAbgc5IWiiQyCEvazq68AiMdxxt+SENhPkBBV WXwtN83zL2nOoLah6bUbAwvSQBO6VAXC8Iw2hoChFgIq3j55A3ULrL/heM8U5RnEmb5G IhoyFgQJhwGRDdJfBO+XEx7z5g1vJb40+8LKtW1XDwYqfu8T6xfu1+pmsANl9Je8pP0X xceQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id be27si2583188edb.66.2021.01.18.10.30.18; Mon, 18 Jan 2021 10:30:42 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407490AbhARS2C (ORCPT + 99 others); Mon, 18 Jan 2021 13:28:02 -0500 Received: from foss.arm.com ([217.140.110.172]:41794 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407598AbhARS1A (ORCPT ); Mon, 18 Jan 2021 13:27:00 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7BE6831B; Mon, 18 Jan 2021 10:26:14 -0800 (PST) Received: from [10.57.2.166] (unknown [10.57.2.166]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 18E183F719; Mon, 18 Jan 2021 10:26:12 -0800 (PST) Subject: Re: [PATCH] PM / devfreq: Add sysfs attributes to simple_ondemand governor To: Greg KH Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, cw00.choi@samsung.com, myungjoo.ham@samsung.com, kyungmin.park@samsung.com References: <20210115170530.22603-1-lukasz.luba@arm.com> <43729797-2d3c-be12-ce72-bfe5bca54fa0@arm.com> From: Lukasz Luba Message-ID: <76f88a00-31ce-db9b-350a-bca6644dbfc9@arm.com> Date: Mon, 18 Jan 2021 18:26:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/18/21 6:14 PM, Greg KH wrote: > On Mon, Jan 18, 2021 at 05:56:06PM +0000, Lukasz Luba wrote: >> >> >> On 1/18/21 5:17 PM, Greg KH wrote: >>> On Fri, Jan 15, 2021 at 05:05:30PM +0000, Lukasz Luba wrote: >>>> The simple_ondemand devfreq governor is used by quite a few devices, like >>>> GPUs, DSPs, memory controllers, etc. It implements algorithm which tries >>>> to predict the device frequency based on past statistics. There are two >>>> tunables for the algorithm: 'upthreshold' and 'downdifferential'. These >>>> tunables change the behavior of the decision, e.g. how fast to increase >>>> the frequency or how rapidly limit the frequency. These values might be >>>> different based on the application which is currently running, e.g. >>>> different behavior is needed for a game than for web browsing or clean >>>> desktop. The patch exports these two tunables so they can be adjusted >>>> based on current need. There is also a check with the allowed ranges >>>> to make sure the values are correct and safe. >>>> >>>> Signed-off-by: Lukasz Luba >>>> --- >>>> drivers/devfreq/governor_simpleondemand.c | 135 ++++++++++++++++++++++ >>>> 1 file changed, 135 insertions(+) >>>> >>>> diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c >>>> index d57b82a2b570..4b3c182e0a49 100644 >>>> --- a/drivers/devfreq/governor_simpleondemand.c >>>> +++ b/drivers/devfreq/governor_simpleondemand.c >>>> @@ -15,6 +15,7 @@ >>>> /* Default constants for DevFreq-Simple-Ondemand (DFSO) */ >>>> #define DFSO_UPTHRESHOLD (90) >>>> #define DFSO_DOWNDIFFERENCTIAL (5) >>>> +#define DFSO_MAX_VALUE (100) >>>> static int devfreq_simple_ondemand_func(struct devfreq *df, >>>> unsigned long *freq) >>>> { >>>> @@ -84,15 +85,149 @@ static int devfreq_simple_ondemand_func(struct devfreq *df, >>>> return 0; >>>> } >>>> +static ssize_t upthreshold_show(struct device *dev, >>>> + struct device_attribute *attr, char *buf) >>>> +{ >>>> + struct devfreq_simple_ondemand_data *data; >>>> + struct devfreq *df = to_devfreq(dev); >>>> + >>>> + if (!df->data) >>>> + return -EINVAL; >>>> + >>>> + data = df->data; >>>> + >>>> + return sprintf(buf, "%d\n", data->upthreshold); >>> >>> sysfs_emit()? >>> >>> Also, you forgot the Documentation/ABI/ updates for new sysfs files :( >> >> True, I will remember next time. >> >>> >>> >>>> +} >>>> + >>>> +static ssize_t upthreshold_store(struct device *dev, >>>> + struct device_attribute *attr, >>>> + const char *buf, size_t count) >>>> +{ >>>> + struct devfreq_simple_ondemand_data *data; >>>> + struct devfreq *df = to_devfreq(dev); >>>> + unsigned int value; >>>> + int ret; >>>> + >>>> + if (!df->data) >>>> + return -EINVAL; >>>> + >>>> + data = df->data; >>>> + >>>> + ret = kstrtouint(buf, 10, &value); >>>> + if (ret < 0) >>>> + return -EINVAL; >>>> + >>>> + mutex_lock(&df->lock); >>>> + >>>> + if (value > DFSO_MAX_VALUE || value <= data->downdifferential) { >>>> + mutex_unlock(&df->lock); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + data->upthreshold = value; >>>> + mutex_unlock(&df->lock); >>>> + >>>> + return count; >>>> +} >>>> +static DEVICE_ATTR_RW(upthreshold); >>>> + >>>> +static ssize_t downdifferential_show(struct device *dev, >>>> + struct device_attribute *attr, char *buf) >>>> +{ >>>> + struct devfreq_simple_ondemand_data *data; >>>> + struct devfreq *df = to_devfreq(dev); >>>> + >>>> + if (!df->data) >>>> + return -EINVAL; >>>> + >>>> + data = df->data; >>>> + >>>> + return sprintf(buf, "%d\n", data->downdifferential); >>>> +} >>>> + >>>> +static ssize_t downdifferential_store(struct device *dev, >>>> + struct device_attribute *attr, >>>> + const char *buf, size_t count) >>>> +{ >>>> + struct devfreq_simple_ondemand_data *data; >>>> + struct devfreq *df = to_devfreq(dev); >>>> + unsigned int value; >>>> + int ret; >>>> + >>>> + if (!df->data) >>>> + return -EINVAL; >>>> + >>>> + data = df->data; >>>> + >>>> + ret = kstrtouint(buf, 10, &value); >>>> + if (ret < 0) >>>> + return -EINVAL; >>>> + >>>> + mutex_lock(&df->lock); >>>> + >>>> + if (value > DFSO_MAX_VALUE || value >= data->upthreshold) { >>>> + mutex_unlock(&df->lock); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + data->downdifferential = value; >>>> + mutex_unlock(&df->lock); >>>> + >>>> + return count; >>>> +} >>>> +static DEVICE_ATTR_RW(downdifferential); >>>> + >>>> +static void devfreq_simple_ondemand_sysfs_setup(struct devfreq *df) >>>> +{ >>>> + struct devfreq_simple_ondemand_data *data; >>>> + int ret; >>>> + >>>> + if (!df->data) { >>>> + /* The memory will be freed automatically */ >>>> + df->data = devm_kzalloc(&df->dev, >>>> + sizeof(struct devfreq_simple_ondemand_data), >>>> + GFP_KERNEL); >>>> + if (!df->data) { >>>> + dev_warn(&df->dev, "Unable to allocate memory"); >>>> + return; >>>> + } >>>> + } >>>> + >>>> + data = df->data; >>>> + >>>> + /* After new allocation setup default values, since they are used */ >>>> + if (!data->upthreshold) >>>> + data->upthreshold = DFSO_UPTHRESHOLD; >>>> + >>>> + if (!data->downdifferential) >>>> + data->downdifferential = DFSO_DOWNDIFFERENCTIAL; >>>> + >>>> + ret = sysfs_create_file(&df->dev.kobj, &dev_attr_upthreshold.attr); >>>> + if (ret < 0) >>>> + dev_warn(&df->dev, "Unable to create 'upthreshold' attr\n"); >>>> + >>>> + ret = sysfs_create_file(&df->dev.kobj, &dev_attr_downdifferential.attr); >>>> + if (ret < 0) >>>> + dev_warn(&df->dev, "Unable to create 'downdifferential' attr\n"); >>> >>> You just raced with userspace and lost :( >>> >>> Please use the default sysfs groups so that it all works properly. >>> >>> Huge hint, when calling sysfs_* from a driver, that usually means you >>> are doing something wrong. >> >> I should have used kobject_init_and_add() and the default devfreq >> sysfs group as a parent. > > No, never use "raw" kobjects in the sys/devices/ tree, that is a sure > way to ensure that userspace will never be notified or see your > attributes. Interesting, I've seen it in the schedutil governor, but might in a different context. Regards, Lukasz