linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 07/16] PM / devfreq: tegra: Properly disable interrupts
Date: Tue, 4 Jun 2019 16:06:33 +0200	[thread overview]
Message-ID: <20190604140633.GA397@ulmo> (raw)
In-Reply-To: <c2f2a8c8-1f30-34aa-9b95-a7a44e0ec96f@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5405 bytes --]

On Tue, Jun 04, 2019 at 04:40:18PM +0300, Dmitry Osipenko wrote:
> 04.06.2019 14:07, Thierry Reding пишет:
> > On Thu, May 02, 2019 at 02:38:06AM +0300, Dmitry Osipenko wrote:
> >> There is no guarantee that interrupt handling isn't running in parallel
> >> with tegra_actmon_disable_interrupts(), hence it is necessary to protect
> >> DEV_CTRL register accesses and clear IRQ status with ACTMON's IRQ being
> >> disabled in the Interrupt Controller in order to ensure that device
> >> interrupt is indeed being disabled.
> >>
> >> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> >> ---
> >>  drivers/devfreq/tegra-devfreq.c | 21 +++++++++++++++------
> >>  1 file changed, 15 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> >> index b65313fe3c2e..ce1eb97a2090 100644
> >> --- a/drivers/devfreq/tegra-devfreq.c
> >> +++ b/drivers/devfreq/tegra-devfreq.c
> >> @@ -171,6 +171,8 @@ struct tegra_devfreq {
> >>  	struct notifier_block	rate_change_nb;
> >>  
> >>  	struct tegra_devfreq_device devices[ARRAY_SIZE(actmon_device_configs)];
> >> +
> >> +	int irq;
> > 
> > Interrupts are typically unsigned int.
> > 
> >>  };
> >>  
> >>  struct tegra_actmon_emc_ratio {
> >> @@ -417,6 +419,8 @@ static void tegra_actmon_disable_interrupts(struct tegra_devfreq *tegra)
> >>  	u32 val;
> >>  	unsigned int i;
> >>  
> >> +	disable_irq(tegra->irq);
> >> +
> >>  	for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
> >>  		dev = &tegra->devices[i];
> >>  
> >> @@ -427,9 +431,14 @@ static void tegra_actmon_disable_interrupts(struct tegra_devfreq *tegra)
> >>  		val &= ~ACTMON_DEV_CTRL_CONSECUTIVE_ABOVE_WMARK_EN;
> >>  
> >>  		device_writel(dev, val, ACTMON_DEV_CTRL);
> >> +
> >> +		device_writel(dev, ACTMON_INTR_STATUS_CLEAR,
> >> +			      ACTMON_DEV_INTR_STATUS);
> >>  	}
> >>  
> >>  	actmon_write_barrier(tegra);
> >> +
> >> +	enable_irq(tegra->irq);
> > 
> > Why do we enable interrupts after this? Is there any use in having the
> > top-level interrupt enabled if nothing's going to generate an interrupt
> > anyway?
> 
> There is no real point in having the interrupt enabled other than to
> keep the enable count balanced.
> 
> IIUC, we will need to disable IRQ at the driver's probe time (after
> requesting the IRQ) if we want to avoid that (not really necessary)
> balancing. This is probably something that could be improved in a
> follow-up patches, if desired.
> 
> >>  }
> >>  
> >>  static void tegra_actmon_configure_device(struct tegra_devfreq *tegra,
> >> @@ -604,7 +613,6 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
> >>  	struct resource *res;
> >>  	unsigned int i;
> >>  	unsigned long rate;
> >> -	int irq;
> >>  	int err;
> >>  
> >>  	tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
> >> @@ -673,15 +681,16 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
> >>  		dev_pm_opp_add(&pdev->dev, rate, 0);
> >>  	}
> >>  
> >> -	irq = platform_get_irq(pdev, 0);
> >> -	if (irq < 0) {
> >> -		dev_err(&pdev->dev, "Failed to get IRQ: %d\n", irq);
> >> -		return irq;
> >> +	tegra->irq = platform_get_irq(pdev, 0);
> >> +	if (tegra->irq < 0) {
> >> +		err = tegra->irq;
> >> +		dev_err(&pdev->dev, "Failed to get IRQ: %d\n", err);
> >> +		return err;
> >>  	}
> > 
> > This is very oddly written. tegra->irq should really be an unsigned int
> > since that's the standard type for interrupt numbers. But since you need
> > to be able to detect errors from platform_get_irq() it now becomes
> > natural to write this as:
> > 
> > 	err = platform_get_irq(pdev, 0);
> > 	if (err < 0) {
> > 		dev_err(...);
> > 		return err;
> > 	}
> > 
> > 	tegra->irq = err;
> > 
> > Two birds with one stone. I suppose this could be done in a follow-up
> > patch since it isn't practically wrong in your version, so either way:
> > 
> > Acked-by: Thierry Reding <treding@nvidia.com>
> > 
> 
> Thank you for the ACK! Although, I disagree with yours suggestion, to me
> that makes code a bit less straightforward and it's not really
> worthwhile to bloat the code just because technically IRQ's are unsigned
> numbers (we don't care about that). It also makes me a bit uncomfortable
> to see "err" assigned to a variable, I don't think it's a good practice.

Actually you should care that IRQs are unsigned. Implicit casting from
a potentially negative value can hide bugs. That is, once you've passed
that negative value into the IRQ API you loose the context that it could
be an error code. Hence I think it makes sense to always store values in
the native type, and only store them if they are actually valid.

In the above you have an error value in tegra->irq. In this particular
case it's pretty harmless because you don't do anything with it, but if
the circumstances were slightly different that could lead to problems
down the road.

On the other hand what I was proposing makes it pretty clear from the
context that err contains a valid interrupt number when it is assigned
to tegra->irq. There's plenty of similar constructs in the kernel if you
want to grep for it.

Also, it's not bloating the code at all. It's the exact same number of
lines of code as your variant.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-06-04 14:06 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190501234148epcas5p1cc9a8dafa9ee6d8d046d1292b8270727@epcas5p1.samsung.com>
2019-05-01 23:37 ` [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support Dmitry Osipenko
2019-05-01 23:37   ` Dmitry Osipenko
2019-05-01 23:38   ` [PATCH v4 01/16] PM / devfreq: tegra: Fix kHz to Hz conversion Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 10:54     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 02/16] PM / devfreq: tegra: Replace readl-writel with relaxed versions Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 10:55     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 03/16] PM / devfreq: tegra: Replace write memory barrier with the read barrier Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 10:56     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 04/16] PM / devfreq: tegra: Don't ignore clk errors Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 10:57     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 05/16] PM / devfreq: tegra: Don't set EMC clock rate to maximum on probe Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:00     ` Thierry Reding
2019-06-04 13:05       ` Dmitry Osipenko
2019-05-01 23:38   ` [PATCH v4 06/16] PM / devfreq: tegra: Drop primary interrupt handler Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:02     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 07/16] PM / devfreq: tegra: Properly disable interrupts Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:07     ` Thierry Reding
2019-06-04 13:40       ` Dmitry Osipenko
2019-06-04 14:06         ` Thierry Reding [this message]
2019-06-04 14:59           ` Dmitry Osipenko
2019-06-04 22:55         ` Dmitry Osipenko
2019-06-07 16:58           ` Dmitry Osipenko
2019-05-01 23:38   ` [PATCH v4 08/16] PM / devfreq: tegra: Clean up driver's probe / remove Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:09     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 09/16] PM / devfreq: tegra: Avoid inconsistency of current frequency value Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:14     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 10/16] PM / devfreq: tegra: Mark ACTMON's governor as immutable Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:15     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 11/16] PM / devfreq: tegra: Move governor registration to driver's probe Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:15     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 12/16] PM / devfreq: tegra: Reconfigure hardware on governor's restart Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:17     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 13/16] PM / devfreq: tegra: Support Tegra30 Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:18     ` Thierry Reding
2019-05-01 23:38   ` [PATCH v4 14/16] PM / devfreq: tegra: Enable COMPILE_TEST for the driver Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:20     ` Thierry Reding
2019-06-04 13:53       ` Dmitry Osipenko
2019-06-04 14:10         ` Thierry Reding
2019-06-04 14:18           ` Thierry Reding
2019-06-04 14:41             ` Dmitry Osipenko
2019-06-04 14:50               ` Thierry Reding
2019-06-04 15:15                 ` Dmitry Osipenko
2019-05-01 23:38   ` [PATCH v4 15/16] PM / devfreq: tegra: Rename tegra-devfreq.c to tegra30-devfreq.c Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:23     ` Thierry Reding
2019-06-04 14:35       ` Dmitry Osipenko
2019-05-01 23:38   ` [PATCH v4 16/16] PM / devfreq: Introduce driver for NVIDIA Tegra20 Dmitry Osipenko
2019-05-01 23:38     ` Dmitry Osipenko
2019-06-04 11:25     ` Thierry Reding
2019-06-04 13:57       ` Dmitry Osipenko
2019-05-03  0:31   ` [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support Chanwoo Choi
2019-05-03  0:31     ` Chanwoo Choi
2019-05-03  0:52     ` Dmitry Osipenko
2019-05-03  0:52       ` Dmitry Osipenko
2019-06-03 16:52       ` Dmitry Osipenko
2019-06-04  0:49         ` Chanwoo Choi
2019-06-04 23:09           ` Dmitry Osipenko
2019-06-23 17:17             ` Dmitry Osipenko
2019-06-23 23:50               ` Chanwoo Choi
2019-06-24  0:35                 ` Dmitry Osipenko

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=20190604140633.GA397@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=cw00.choi@samsung.com \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=tomeu.vizoso@collabora.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).