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/
>
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox