All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Tomas Janousek <tomi@nomi.cz>
Cc: linux-kernel@vger.kernel.org,
	Alessandro Zummo <alessandro.zummo@towertech.it>
Subject: Re: [PATCH] rtc-dev: stop periodic interrupts on device release
Date: Sat, 26 Jul 2008 13:50:55 -0700	[thread overview]
Message-ID: <200807261350.55524.david-b@pacbell.net> (raw)
In-Reply-To: <20080726154617.GA5613@notes.lisk.in>

On Saturday 26 July 2008, Tomas Janousek wrote:
> Solves http://bugzilla.kernel.org/show_bug.cgi?id=11127
> 
> The old rtc.c driver did it, some drivers (like rtc-sh) do it in their release
> function too, but rtc-cmos does not -- because it provides the irq_set_state
> op -- so the rtc framework itself should care about it. This patch makes it do
> so.

I'd say it differently:  hardly any RTC drivers do this correctly.

Maybe only rtc-sh, which tracks whether user or kernel code turned
on the periodic IRQ.

 
> I am aware that some drivers, like rtc-sh, handle userspace PIE sets in their
> ioctl op, exporting the irq_set_state op at the same time. The logic in
> rtc_irq_set_state should make sure it doesn't matter and the driver should not
> need to care stopping periodic interrupts in its release routine any more.
> I did not look at other drivers though.

A quick grep shows that out of 42 (wow!) current RTC drivers:

 - rtc-{bfin,sa1100,sh,test} support ioctl(PIE_ON/PIE_OFF), at least
   before some recent patches fixing that glitch (not in my tree) by
   switching to irq_set_state().

 - rtc-{cmos,s3c,sh,vr41xx} support the more correct irq_set_state()
   requests, which are available for in-kernel use not just through
   ioctl(PIE_ON/PIE_OFF) calls to /dev files.

 - Of those:  rtc-{bfin,s3c,sa1100,sh,vr41xx} all have release()
   methods ... though it looks to me like most of those wrongly
   disable *all* IRQs, even ones in use by something other than
   the /dev client closing that FD.

That suggests there's quite a mess yet to be fixed.  This patch
will ensure that periodic IRQs get properly shut off by close()
or exit() of a task that started them.  Those release() methods
shouldn't then be second-guessing things.

And then there are the other two types of IRQ.  Update IRQs can
only be enabled through ioctl(UIE_ON), so they're fair game to
turn off when closing /dev files.  Alarms seem to be a special
case -- best not touched when closing files.


> Signed-off-by: Tomas Janousek <tomi@nomi.cz>
> Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
> Cc: David Brownell <david-b@pacbell.net>

Acked-by: David Brownell <dbrownell@users.sourceforge.net>

... who likes it when bugfixes just take one line of code,
even if they consume many pages of discussion.  ;)


> ---
>  drivers/rtc/rtc-dev.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-dev.c b/drivers/rtc/rtc-dev.c
> index 90dfa0d..6fafa62 100644
> --- a/drivers/rtc/rtc-dev.c
> +++ b/drivers/rtc/rtc-dev.c
> @@ -408,6 +408,8 @@ static int rtc_dev_release(struct inode *inode, struct file *file)
>  #ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL
>  	clear_uie(rtc);
>  #endif

Hmm, I'd think that something like an rtc_dev_ioctl(PIE_OFF) would be
preferable here ... so that it's not just UIE_EMUL logic which turns
off the one-per-second update IRQs.

In fact, with a change like that I suspect the release() issues could
best be dealt with by just removing that method and its implementations...


> +	rtc_irq_set_state(rtc, NULL, 0);
> +
>  	if (rtc->ops->release)
>  		rtc->ops->release(rtc->dev.parent);
>  
> -- 
> 1.5.6
> 
> 
> -- 
> Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
> 



  parent reply	other threads:[~2008-07-26 20:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-26 15:46 [PATCH] rtc-dev: stop periodic interrupts on device release Tomas Janousek
2008-07-26 17:55 ` Alessandro Zummo
2008-07-26 18:06   ` Tomáš Janoušek
2008-07-26 18:13     ` Alessandro Zummo
2008-07-26 19:58       ` David Brownell
2008-07-26 20:50 ` David Brownell [this message]
2008-07-27  3:03   ` Mike Frysinger
2008-07-27  5:03     ` David Brownell
2008-07-28 20:41   ` Tomáš Janoušek
2008-07-28 20:47     ` Alessandro Zummo
2008-07-28 22:05     ` David Brownell
2008-07-28 23:36       ` Tomáš Janoušek
2008-07-29 20:08         ` David Brownell

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=200807261350.55524.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=alessandro.zummo@towertech.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tomi@nomi.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.