Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1577288 > unrolled thread

[PATCH V2 1/6] PM / QOS: Add default case to the switch

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH V2 1/6] PM / QOS: Add default case to the switch Viresh Kumar <viresh.kumar@linaro.org> - 2017-02-09 04:50 +0100
    Re: [PATCH V2 1/6] PM / QOS: Add default case to the switch Pavel Machek <pavel@ucw.cz> - 2017-02-09 15:30 +0100
      Re: [PATCH V2 1/6] PM / QOS: Add default case to the switch Viresh Kumar <viresh.kumar@linaro.org> - 2017-02-10 07:10 +0100
        Re: [PATCH V2 1/6] PM / QOS: Add default case to the switch Pavel Machek <pavel@ucw.cz> - 2017-02-10 13:30 +0100
          Re: [PATCH V2 1/6] PM / QOS: Add default case to the switch Viresh Kumar <viresh.kumar@linaro.org> - 2017-02-13 04:20 +0100
        Re: [PATCH V2 1/6] PM / QOS: Add default case to the switch Pavel Machek <pavel@ucw.cz> - 2017-02-10 22:30 +0100

#1577288 — [PATCH V2 1/6] PM / QOS: Add default case to the switch

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(+)

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);
-- 
2.7.1.410.g6faf27b

[toc] | [next] | [standalone]

#1577642

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

[toc] | [prev] | [next] | [standalone]

#1578189

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

[toc] | [prev] | [next] | [standalone]

#1578425

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1579369

On 10-02-17, 13:15, Pavel Machek wrote:
> 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.

Sure. Will do it in V3.

-- 
viresh

[toc] | [prev] | [next] | [standalone]

#1578811

[Multipart message — attachments visible in raw view] — view raw

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 ?

Surely compilation warnings are better than getting bug reports from
users?

Of course, it is better to fix the switch when adding new QoS type...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web