| Message ID | 338b16e4c882634e30e4f4c011a9e9c52d134cbc.1486611268.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | PM / Domains: Implement domain performance states | expand |
On Thu 2017-02-09 09:11:47, Viresh Kumar wrote: > The switch block handles all the QOS request types present today, but > starts giving compilation warnings as soon as a new type is added and > not handled in this. > > To prevent against that, add the default case as well and do a WARN from > it. I'd say compilation-time warning is better than hmm.... stacktrace and memory leak at runtime? > --- a/drivers/base/power/qos.c > +++ b/drivers/base/power/qos.c > @@ -621,6 +621,9 @@ static void __dev_pm_qos_drop_user_request(struct device *dev, > req = dev->power.qos->flags_req; > dev->power.qos->flags_req = NULL; > break; > + default: > + WARN_ON(1); > + return; > } > __dev_pm_qos_remove_request(req); > kfree(req); -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 09-02-17, 15:24, Pavel Machek wrote: > On Thu 2017-02-09 09:11:47, Viresh Kumar wrote: > > The switch block handles all the QOS request types present today, but > > starts giving compilation warnings as soon as a new type is added and > > not handled in this. > > > > To prevent against that, add the default case as well and do a WARN from > > it. > > I'd say compilation-time warning is better than hmm.... stacktrace and memory leak > at runtime? Of course we aren't going to allow a compilation warning for each and every platform that compiles this file. How do you wish to fix the issue then ? -- viresh
On Fri 2017-02-10 11:30:30, Viresh Kumar wrote: > On 09-02-17, 15:24, Pavel Machek wrote: > > On Thu 2017-02-09 09:11:47, Viresh Kumar wrote: > > > The switch block handles all the QOS request types present today, but > > > starts giving compilation warnings as soon as a new type is added and > > > not handled in this. > > > > > > To prevent against that, add the default case as well and do a WARN from > > > it. > > > > I'd say compilation-time warning is better than hmm.... stacktrace and memory leak > > at runtime? > > Of course we aren't going to allow a compilation warning for each and every > platform that compiles this file. How do you wish to fix the issue then ? What is tue issue? As soon as new QoS request type is added, this switch can be fixed. There is no issue now, and there should be no issue in future. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c index 58fcc758334e..01f615b18055 100644 --- a/drivers/base/power/qos.c +++ b/drivers/base/power/qos.c @@ -621,6 +621,9 @@ static void __dev_pm_qos_drop_user_request(struct device *dev, req = dev->power.qos->flags_req; dev->power.qos->flags_req = NULL; break; + default: + WARN_ON(1); + return; } __dev_pm_qos_remove_request(req); kfree(req);
The switch block handles all the QOS request types present today, but starts giving compilation warnings as soon as a new type is added and not handled in this. To prevent against that, add the default case as well and do a WARN from it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- drivers/base/power/qos.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.7.1.410.g6faf27b