linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chanwoo Choi <cw00.choi@samsung.com>
To: Saravana Kannan <skannan@codeaurora.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start
Date: Thu, 10 Nov 2016 09:10:41 +0900	[thread overview]
Message-ID: <5823BB01.3090502@samsung.com> (raw)
In-Reply-To: <58238840.90802@codeaurora.org>

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 <skannan@codeaurora.org>
>>>>>>>>> ---
>>>>>>>>> * 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 <cw00.choi@samsung.com>

After fixing the bug of devfreq_add_device(),
I'll remove the unneeded 'if statement' of prev_governor in governor_store. 

Best Regards,
Chanwoo Choi

  reply	other threads:[~2016-11-10  0:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20161026191715epcas1p311c2c626563a736e14c83fb0504c099e@epcas1p3.samsung.com>
2016-10-26 19:17 ` Saravana Kannan
2016-10-27  0:06   ` Chanwoo Choi
2016-11-07 18:57     ` Saravana Kannan
2016-11-08  9:02       ` Chanwoo Choi
2016-11-08 20:52         ` Saravana Kannan
2016-11-09  1:33           ` Chanwoo Choi
2016-11-09  2:36             ` Chanwoo Choi
2016-11-09  2:38               ` Chanwoo Choi
2016-11-09 20:34                 ` Saravana Kannan
2016-11-10  0:10                   ` Chanwoo Choi [this message]
2016-11-11 23:25                     ` Saravana Kannan
2016-11-12  2:17                       ` Chanwoo Choi
2016-11-12  2:18                         ` Chanwoo Choi
2018-12-07 20:29                     ` Saravana Kannan
2018-12-11  5:35                       ` Chanwoo Choi
     [not found]                       ` <CGME20161026191715epcas1p311c2c626563a736e14c83fb0504c099e@epcms1p3>
2018-12-11  7:18                         ` MyungJoo Ham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5823BB01.3090502@samsung.com \
    --to=cw00.choi@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=rjw@rjwysocki.net \
    --cc=skannan@codeaurora.org \
    --subject='Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).