Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966283AbcKLCTP (ORCPT ); Fri, 11 Nov 2016 21:19:15 -0500 Received: from mail-qk0-f195.google.com ([209.85.220.195]:35826 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936420AbcKLCTN (ORCPT ); Fri, 11 Nov 2016 21:19:13 -0500 MIME-Version: 1.0 Reply-To: cwchoi00@gmail.com In-Reply-To: References: <1477509425-16936-1-git-send-email-skannan@codeaurora.org> <5820CE7E.40802@codeaurora.org> <5821948B.2010907@samsung.com> <58223AF1.2030605@codeaurora.org> <58227CDB.6050907@samsung.com> <58228B9E.2090108@samsung.com> <58228C10.3070502@samsung.com> <58238840.90802@codeaurora.org> <5823BB01.3090502@samsung.com> <58265352.4030708@codeaurora.org> From: Chanwoo Choi Date: Sat, 12 Nov 2016 11:18:51 +0900 Message-ID: Subject: Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start To: Saravana Kannan Cc: Chanwoo Choi , "Rafael J. Wysocki" , MyungJoo Ham , Kyungmin Park , "linux-pm@vger.kernel.org" , linux-kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uAC2JJ9Q000904 Content-Length: 5898 Lines: 158 2016-11-12 11:17 GMT+09:00 Chanwoo Choi : > 2016-11-12 8:25 GMT+09:00 Saravana Kannan : >> On 11/09/2016 04:10 PM, Chanwoo Choi wrote: >>> >>> Hi, >>> >>> On 2016년 11월 10일 05:34, Saravana Kannan wrote: >>>> >>>> On 11/08/2016 06:38 PM, Chanwoo Choi wrote: >>>>> >>>>> On 2016년 11월 09일 11:36, Chanwoo Choi wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 2016년 11월 09일 10:33, Chanwoo Choi wrote: >>>>>>> >>>>>>> On 2016년 11월 09일 05:52, Saravana Kannan wrote: >>>>>>>> >>>>>>>> On 11/08/2016 01:02 AM, Chanwoo Choi wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 2016년 11월 08일 03:57, Saravana Kannan wrote: >>>>>>>>>> >>>>>>>>>> On 10/26/2016 05:06 PM, Chanwoo Choi wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 2016년 10월 27일 04:17, Saravana Kannan wrote: >>>>>>>>>>>> >>>>>>>>>>>> If the new governor fails to start, switch back to old governor >>>>>>>>>>>> so that the >>>>>>>>>>>> devfreq state is not left in some weird limbo. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Saravana Kannan >>>>>>>>>>>> --- >>>>>>>>>>>> * Fix NULL deref for real this time. >>>>>>>>>>>> * Addressed some style preferences. >>>>>>>>>>>> >>>>>>>>>>>> drivers/devfreq/devfreq.c | 13 +++++++++++-- >>>>>>>>>>>> 1 file changed, 11 insertions(+), 2 deletions(-) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/drivers/devfreq/devfreq.c >>>>>>>>>>>> b/drivers/devfreq/devfreq.c >>>>>>>>>>>> index bf3ea76..77c41a5 100644 >>>>>>>>>>>> --- a/drivers/devfreq/devfreq.c >>>>>>>>>>>> +++ b/drivers/devfreq/devfreq.c >>>>>>>>>>>> @@ -919,7 +919,7 @@ static ssize_t governor_store(struct device >>>>>>>>>>>> *dev, struct device_attribute *attr, >>>>>>>>>>>> struct devfreq *df = to_devfreq(dev); >>>>>>>>>>>> int ret; >>>>>>>>>>>> char str_governor[DEVFREQ_NAME_LEN + 1]; >>>>>>>>>>>> - struct devfreq_governor *governor; >>>>>>>>>>>> + const struct devfreq_governor *governor, *prev_governor; >>>>>>>>>>>> >>>>>>>>>>>> ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", >>>>>>>>>>>> str_governor); >>>>>>>>>>>> if (ret != 1) >>>>>>>>>>>> @@ -944,12 +944,21 @@ static ssize_t governor_store(struct device >>>>>>>>>>>> *dev, struct device_attribute *attr, >>>>>>>>>>>> goto out; >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> + prev_governor = df->governor; >>>>>>>>>>>> df->governor = governor; >>>>>>>>>>>> strncpy(df->governor_name, governor->name, >>>>>>>>>>>> DEVFREQ_NAME_LEN); >>>>>>>>>>>> ret = df->governor->event_handler(df, DEVFREQ_GOV_START, >>>>>>>>>>>> NULL); >>>>>>>>>>>> - if (ret) >>>>>>>>>>>> + if (ret) { >>>>>>>>>>>> dev_warn(dev, "%s: Governor %s not started(%d)\n", >>>>>>>>>>>> __func__, df->governor->name, ret); >>>>>>>>>>>> + if (prev_governor) { >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think that prev_governor is always set. You don't need to check >>>>>>>>>>> it. >>>>>>>>>>> Why do check it? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Not true. Even higher up in this function, we check if df->governor >>>>>>>>>> != NULL. Simple example would be that the default governor passed in while >>>>>>>>>> adding the device isn't compiled in. >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't understand. If device is not registered by >>>>>>>>> devfreq_add_device(), >>>>>>>>> you don't change the governor by using governor_store(). >>>>>>>>> >>>>>>>>> If you can change the governor through governor_store(), >>>>>>>>> it means that the devfreq instance was added without any problem. >>>>>>>>> The added devfreq instance must have the sepecific governor >>>>>>>>> on df->governor variable. >>>>>>>>> >>>>>>>>> So, I think that df->governor is always set and then prev_governor >>>>>>>>> is always set. >>>>>>>> >>>>>>>> >>>>>>>> Read the code more closely. add_device doesn't (and shouldn't) fail >>>>>>>> if the governor isn't present. After that, the governor could be changed >>>>>>>> from user space. >>>>>>> >>>>>>> >>>>>>> If governor is not present during devfreq_add_device(), >>>>>>> the devfreq instance is not able to register the devfreq framework. >>>>>>> So, the user never touch the sysfs[1] to change the governor >>>>>>> because the sysfs[1] is not created by devfreq framework. >>>>>>> [1] /sys/class/devfreq/[device name]/governor >>>>>>> >>>>>>> In summary, if governor is not present during devfreq_add_device(), >>>>>>> the devfreq framework doesn't create tye sysfs[1] for governor. >>>>>>> >>>>>>> The user-space never change the governor through sysfs[1] >>>>>>> because there is no any sysfs entry[1]. >>>>>> >>>>>> >>>>>> I checked the code of devfreq_add_device(). >>>>>> As you mentioned, if there is no governor, >>>>>> devfreq_add_device() don't pass wihtout calling the >>>>>> devfreq->governor->even_handler(). >>>>> >>>>> >>>>> Wrong expression / don't pass -> pass >>>>> >>>> >>>> I think it's correct as is. Just because the governor isn't there (or >>>> hasn't registered yet) doesn't mean the device add should fail. >>>> >>>> That aside, do you care to ack this patch for the way the code is >>>> currently? >>> >>> >>> Reviewed-by: Chanwoo Choi >> >> >> Thanks >> >>> After fixing the bug of devfreq_add_device(), >>> I'll remove the unneeded 'if statement' of prev_governor in >>> governor_store. >>> >> >> As mentioned earlier, I don't think it's a bug. It's fine as is. > > No. I think it is a bug. The goal of devfreq should handle the frequency/voltage > with governor. If governor is not necessary of the specific device, the device > driver don't need to use the devfreq. > > The default governor is always available and necessary of the device driver. The default governor have to be always available and necessary of the device driver. -- Best Regards, Chanwoo Choi