| Message ID | 20181212135313.30268-1-sibis@codeaurora.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | [v4] PM / devfreq: Restart previous governor if new governor fails to start | expand |
> From: Saravana Kannan <skannan@codeaurora.org> > > 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: Sibi Sankar <sibis@codeaurora.org> > Signed-off-by: Saravana Kannan <skannan@codeaurora.org> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Hello, In overall, the idea and the implementation looks good. However, I have a question: What if the following line fails? + df->governor->event_handler(df, DEVFREQ_GOV_START, + NULL); Don't we still need something to handle for such events? Cheers, MyungJoo
Hey MyungJoo, On 12/14/18 7:15 AM, MyungJoo Ham wrote: >> From: Saravana Kannan <skannan@codeaurora.org> >> >> 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: Sibi Sankar <sibis@codeaurora.org> >> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> > > Hello, > > In overall, the idea and the implementation looks good. > > However, I have a question: > > What if the following line fails? > > + df->governor->event_handler(df, DEVFREQ_GOV_START, > + NULL); > > Don't we still need something to handle for such events? The original discussion went as follows: governor_store is expected to be used only on cases where devfreq_add_device() succeeded i.e prev->governor is expected to be present and DEVFREQ_GOV_START is expected to succeed. Hence falling back to the previous governor seems like a sensible idea. This would also prevent DEVFREQ_GOV_STOP from being called on a governor were DEVFREQ_GOV_START had failed which is ideal. That being said DEVFREQ_GOV_START can still fail for the prev-governor due to some change in state of the system. Do you want to handle this case by clearing the state of governor rather than switching to previous governor? > > Cheers, > MyungJoo > >
Hey MyungJoo, Kyungmin Did you get a chance to think about how you want this fix implemented? On 2019-02-19 10:42, Sibi Sankar wrote: > Hey MyungJoo, > > On 12/14/18 7:15 AM, MyungJoo Ham wrote: >>> From: Saravana Kannan <skannan@codeaurora.org> >>> >>> 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: Sibi Sankar <sibis@codeaurora.org> >>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> >> >> Hello, >> >> In overall, the idea and the implementation looks good. >> >> However, I have a question: >> >> What if the following line fails? >> >> + df->governor->event_handler(df, DEVFREQ_GOV_START, >> + NULL); >> >> Don't we still need something to handle for such events? > > The original discussion went as follows: > governor_store is expected to be used only on cases > where devfreq_add_device() succeeded i.e prev->governor > is expected to be present and DEVFREQ_GOV_START is > expected to succeed. Hence falling back to the previous > governor seems like a sensible idea. > > This would also prevent DEVFREQ_GOV_STOP from being called > on a governor were DEVFREQ_GOV_START had failed which is > ideal. > > That being said DEVFREQ_GOV_START can still fail for the > prev-governor due to some change in state of the system. > Do you want to handle this case by clearing the state of > governor rather than switching to previous governor? > >> >> Cheers, >> MyungJoo >> >>
>Hey MyungJoo, Kyungmin >Did you get a chance to think about how you >want this fix implemented? > >On 2019-02-19 10:42, Sibi Sankar wrote: >> Hey MyungJoo, >> >> On 12/14/18 7:15 AM, MyungJoo Ham wrote: >>>> From: Saravana Kannan <skannan@codeaurora.org> >>>> >>>> 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: Sibi Sankar <sibis@codeaurora.org> >>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> >>> >>> Hello, >>> >>> In overall, the idea and the implementation looks good. >>> >>> However, I have a question: >>> >>> What if the following line fails? >>> >>> + df->governor->event_handler(df, DEVFREQ_GOV_START, >>> + NULL); >>> >>> Don't we still need something to handle for such events? >> >> The original discussion went as follows: >> governor_store is expected to be used only on cases >> where devfreq_add_device() succeeded i.e prev->governor >> is expected to be present and DEVFREQ_GOV_START is >> expected to succeed. Hence falling back to the previous >> governor seems like a sensible idea. >> >> This would also prevent DEVFREQ_GOV_STOP from being called >> on a governor were DEVFREQ_GOV_START had failed which is >> ideal. >> >> That being said DEVFREQ_GOV_START can still fail for the >> prev-governor due to some change in state of the system. >> Do you want to handle this case by clearing the state of >> governor rather than switching to previous governor? >> If moving back to previous governor fails after failing for "next" governor, we may assume it's fatal and stop the device; we can simply return errors. In such a case, df->governor may need to be NULL as well. Cheers, MyungJoo
On 2019-03-05 12:48, MyungJoo Ham wrote: >> Hey MyungJoo, Kyungmin >> Did you get a chance to think about how you >> want this fix implemented? >> >> On 2019-02-19 10:42, Sibi Sankar wrote: >>> Hey MyungJoo, >>> >>> On 12/14/18 7:15 AM, MyungJoo Ham wrote: >>>>> From: Saravana Kannan <skannan@codeaurora.org> >>>>> >>>>> 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: Sibi Sankar <sibis@codeaurora.org> >>>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >>>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> >>>> >>>> Hello, >>>> >>>> In overall, the idea and the implementation looks good. >>>> >>>> However, I have a question: >>>> >>>> What if the following line fails? >>>> >>>> + df->governor->event_handler(df, DEVFREQ_GOV_START, >>>> + NULL); >>>> >>>> Don't we still need something to handle for such events? >>> >>> The original discussion went as follows: >>> governor_store is expected to be used only on cases >>> where devfreq_add_device() succeeded i.e prev->governor >>> is expected to be present and DEVFREQ_GOV_START is >>> expected to succeed. Hence falling back to the previous >>> governor seems like a sensible idea. >>> >>> This would also prevent DEVFREQ_GOV_STOP from being called >>> on a governor were DEVFREQ_GOV_START had failed which is >>> ideal. >>> >>> That being said DEVFREQ_GOV_START can still fail for the >>> prev-governor due to some change in state of the system. >>> Do you want to handle this case by clearing the state of >>> governor rather than switching to previous governor? >>> > > If moving back to previous governor fails after > failing for "next" governor, we may assume it's fatal > and stop the device; we can simply return errors. > > In such a case, df->governor may need to be NULL as well. Thanks. Will make the necessary changes in the next re-spin. > > > Cheers, > MyungJoo
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 141413067b5c..ba2875a0b90e 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -1024,7 +1024,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) @@ -1053,12 +1053,19 @@ 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); + df->governor = prev_governor; + strncpy(df->governor_name, prev_governor->name, + DEVFREQ_NAME_LEN); + df->governor->event_handler(df, DEVFREQ_GOV_START, + NULL); + } out: mutex_unlock(&devfreq_list_lock);