Re: [PATCH] rtc-dev: stop periodic interrupts on device release

From: Mike Frysinger
Date: Sat Jul 26 2008 - 23:04:16 EST


On Sat, Jul 26, 2008 at 4:50 PM, David Brownell wrote:
> On Saturday 26 July 2008, Tomas Janousek wrote:
>> 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().

the rtc-bfin.c patches are in some queue somewhere to fix this ;)

> - 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.

rtc-bfin.c turns off all irqs and frees it in the release() function
(since the irq is requested in the open() function). i guess that
isnt supposed to happen huh.

> 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.

specific drivers shouldnt worry about this then right ? handle it in rtc-dev ?
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/