linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <Pawel.Moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
Date: Thu, 12 Feb 2015 10:52:15 +0000	[thread overview]
Message-ID: <20150212105215.GA1522@leverpostej> (raw)
In-Reply-To: <20150211182945.5004586a@bbrezillon>

[...]

> > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> > index d9b05b5..2b8ff50 100644
> > --- a/include/linux/interrupt.h
> > +++ b/include/linux/interrupt.h
> > @@ -57,6 +57,9 @@
> >   * IRQF_NO_THREAD - Interrupt cannot be threaded
> >   * IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device
> >   *                resume time.
> > + * IRQF_SHARED_TIMER_OK - Interrupt is safe to be shared with a timer. The
> > + *                        handler may be called spuriously during suspend
> > + *                        without issue.
> >   */
> >  #define IRQF_DISABLED		0x00000020
> >  #define IRQF_SHARED		0x00000080
> > @@ -70,8 +73,10 @@
> >  #define IRQF_FORCE_RESUME	0x00008000
> >  #define IRQF_NO_THREAD		0x00010000
> >  #define IRQF_EARLY_RESUME	0x00020000
> > +#define __IRQF_TIMER_SIBLING_OK	0x00040000
> >  
> >  #define IRQF_TIMER		(__IRQF_TIMER | IRQF_NO_SUSPEND | IRQF_NO_THREAD)
> > +#define IRQF_SHARED_TIMER_OK	(IRQF_SHARED | __IRQF_TIMER_SIBLING_OK)
> >  
> >  /*
> >   * These values can be returned by request_any_context_irq() and
> > diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
> > index 3ca5325..e4ec91a 100644
> > --- a/kernel/irq/pm.c
> > +++ b/kernel/irq/pm.c
> > @@ -28,6 +28,47 @@ bool irq_pm_check_wakeup(struct irq_desc *desc)
> >  }
> >  
> >  /*
> > + * Check whether an interrupt is safe to occur during suspend.
> > + *
> > + * Physical IRQ lines may be shared between devices which may be expected to
> > + * raise interrupts during suspend (e.g. timers) and those which may not (e.g.
> > + * anything we cut the power to). Not all handlers will be safe to call during
> > + * suspend, so we need to scream if there's the possibility an unsafe handler
> > + * will be called.
> > + *
> > + * A small number of handlers are safe to be shared with timer interrupts, and
> > + * we don't want to warn erroneously for these. Such handlers will not poke
> > + * hardware that's not powered or call into kernel infrastructure not available
> > + * during suspend. These are marked with __IRQF_TIMER_SIBLING_OK.
> > + */
> > +bool irq_safe_during_suspend(struct irq_desc * desc, struct irqaction *action)
> > +{
> > +	const unsigned int safe_flags =
> > +		__IRQF_TIMER_SIBLING_OK | IRQF_NO_SUSPEND;
> > +
> > +	/*
> > +	 * If no-one wants to be called during suspend, or if everyone does,
> > +	 * then there's no potential conflict.
> > +	 */
> > +	if (!desc->no_suspend_depth)
> > +		return true;
> > +	if (desc->no_suspend_depth == desc->nr_actions)
> > +		return true;
> > +
> > +	/*
> > +	 * If any action hasn't asked to be called during suspend or is not
> > +	 * happy to be called during suspend, we have a potential problem.
> > +	 */
> > +	if (!(action->flags & safe_flags))
> > +		return false;
> 	else if (!(action->flags & IRQF_NO_SUSPEND) ||
> 		 desc->no_suspend_depth > 1)
> 		return true;
> 
> Am I missing something or is the following loop only required if
> we're adding an action with the IRQF_NO_SUSPEND flag set for the
> first time ?

With the check above we could return true incorrectly after the first
time we return true. Consider adding the following in order to an empty
desc:

	flags = IRQF_SHARED		// safe, returns true
	flags = IRQF_NO_SUSPEND		// unsafe, returns false
	flags = IRQF_NO_SUSPEND		// unsafe, but returns true

Currently it shouldn't matter as the only caller is a WARN_ON_ONCE(),
but it seems unfortunate to allow this.

We'd also run the loop until we had at least two IRQF_NO_SUSPEND
irqactions:

	flags = IRQF_SHARED_TIMER_OK	// early return
	flags = IRQF_NO_SUSPEND		// run loop
	flags = IRQF_SHARED_TIMER_OK	// run loop
	flags = IRQF_SHARED_TIMER_OK	// run loop
	flags = IRQF_SHARED_TIMER_OK	// run loop
	flags = IRQF_NO_SUSPEND		// don't run loop.
	flags = IRQF_SHARED_TIMER_OK	// don't run loop

I assume that we only have one IRQF_NO_SUSPEND action sharing the line
anyway in your case?

Given that we'll only bother to run the test if there's a mismatch
between desc->no_suspend_depth and desc->nr_actions, I don't think we
win much. These cases should be rare in practice, the tests only
performed when we request the irq, and there shouldn't be that many
actions to loop over.

Thanks,
Mark.

> 
> > +	for (action = desc->action; action; action = action->next)
> > +		if (!(action->flags & safe_flags))
> > +			return false;
> > +
> > +	return true;
> > +}
> > +
> > +/*
> >   * Called from __setup_irq() with desc->lock held after @action has
> >   * been installed in the action chain.
> >   */
> > @@ -44,8 +85,7 @@ void irq_pm_install_action(struct irq_desc *desc, struct irqaction *action)
> >  	if (action->flags & IRQF_NO_SUSPEND)
> >  		desc->no_suspend_depth++;
> >  
> > -	WARN_ON_ONCE(desc->no_suspend_depth &&
> > -		     desc->no_suspend_depth != desc->nr_actions);
> > +	WARN_ON_ONCE(!irq_safe_during_suspend(desc, action));
> >  }
> >  
> >  /*
> 
> 
> 
> -- 
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> 

  reply	other threads:[~2015-02-12 10:52 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29 10:33 [PATCH v4 0/5] ARM: at91: fix irq_pm_install_action WARNING Boris Brezillon
2015-01-29 10:33 ` [PATCH v4 1/5] genirq: Authorize chained handlers to remain disabled when initialized Boris Brezillon
2015-01-29 10:33 ` [PATCH v4 2/5] irqchip: add virtual demultiplexer implementation Boris Brezillon
2015-02-10 15:00   ` Peter Zijlstra
2015-02-10 15:20     ` Boris Brezillon
2015-02-10 15:43     ` [PATCH] genirq: fix virtual irq demuxer related comments Boris Brezillon
2015-02-10 16:14       ` Peter Zijlstra
2015-02-20 16:12         ` Mark Rutland
2015-02-20 16:17           ` Peter Zijlstra
2015-02-10 15:48   ` [PATCH v4 2/5] irqchip: add virtual demultiplexer implementation Mark Rutland
2015-01-29 10:33 ` [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip Boris Brezillon
2015-02-10 15:36   ` Mark Rutland
2015-02-10 15:52     ` Boris Brezillon
2015-02-10 16:06       ` Boris Brezillon
2015-02-10 16:16       ` Mark Rutland
2015-02-10 16:20         ` Boris Brezillon
2015-02-10 20:48       ` Mark Rutland
2015-02-11  8:53         ` Boris Brezillon
2015-02-11 11:11           ` Mark Rutland
2015-02-11 12:24             ` Boris Brezillon
2015-02-11 12:36               ` Mark Rutland
2015-02-11 13:38                 ` Alexandre Belloni
2015-02-11 13:48                   ` Mark Rutland
2015-02-11 14:55               ` Rafael J. Wysocki
2015-02-11 14:43                 ` Mark Rutland
2015-02-11 15:17                   ` Rafael J. Wysocki
2015-02-11 15:03                     ` Boris Brezillon
2015-02-11 15:39                       ` Rafael J. Wysocki
2015-02-11 15:23                         ` Mark Rutland
2015-02-11 15:12                     ` Mark Rutland
2015-02-11 15:51                       ` Rafael J. Wysocki
2015-02-11 15:57                         ` Mark Rutland
2015-02-11 16:15                           ` Boris Brezillon
2015-02-11 16:32                             ` Mark Rutland
2015-02-11 16:38                               ` Boris Brezillon
2015-02-11 17:17                                 ` Mark Rutland
2015-02-20 14:22                                 ` Mark Rutland
2015-02-20 14:53                                   ` Boris Brezillon
2015-02-20 15:16                                     ` Mark Rutland
2015-02-23 17:00                                       ` Boris Brezillon
2015-02-23 18:14                                         ` Mark Rutland
2015-02-23 20:16                                           ` Boris Brezillon
2015-02-11 16:42                             ` Rafael J. Wysocki
2015-02-11 16:28                               ` Boris Brezillon
2015-02-11 17:13                               ` Mark Rutland
2015-02-11 17:29                                 ` Boris Brezillon
2015-02-12 10:52                                   ` Mark Rutland [this message]
2015-02-12 11:09                                     ` Boris Brezillon
2015-02-12 11:23                                       ` Mark Rutland
2015-02-16  9:49                                 ` Peter Zijlstra
2015-02-16  9:28                         ` Peter Zijlstra
2015-02-16 12:23                           ` Mark Rutland
2015-02-19  1:16                             ` Rafael J. Wysocki
2015-02-19 11:23                               ` Mark Rutland
2015-02-19 22:35                                 ` Rafael J. Wysocki
2015-02-20 10:31                                   ` Mark Rutland
2015-02-24  1:02                                     ` Rafael J. Wysocki
2015-02-24  8:42                                       ` Boris Brezillon
2015-02-11 14:45                 ` Boris Brezillon
2015-02-11 14:39             ` Rafael J. Wysocki
2015-02-11  9:11         ` Peter Zijlstra
2015-02-11 11:15           ` Mark Rutland
2015-02-11 14:31             ` Rafael J. Wysocki
2015-02-11 14:14               ` Mark Rutland
2015-02-11 15:07                 ` Rafael J. Wysocki
2015-02-11 15:03                   ` Mark Rutland
2015-02-11 14:34         ` Rafael J. Wysocki
2015-01-29 10:33 ` [PATCH v4 4/5] ARM: at91/dt: select VIRT_IRQ_DEMUX for all at91 SoCs Boris Brezillon
2015-01-29 10:33 ` [PATCH v4 5/5] ARM: at91/dt: define a virtual irq demultiplexer chip connected on irq1 Boris Brezillon
2015-02-09 15:47 ` [PATCH v4 0/5] ARM: at91: fix irq_pm_install_action WARNING Boris Brezillon

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=20150212105215.GA1522@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=Pawel.Moll@arm.com \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@atmel.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    /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).