linux-kernel - Re: RTC regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4F59003F.4050709@nod.at>
Date:	Thu, 08 Mar 2012 19:53:51 +0100
From:	Richard Weinberger <richard@....at>
To:	John Stultz <john.stultz@...aro.org>
CC:	Thomas Gleixner <tglx@...utronix.de>, a.zummo@...ertech.it,
	rtc-linux@...glegroups.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: RTC regression

On 07.03.2012 00:36, John Stultz wrote:
> On Wed, 2012-02-29 at 22:41 +0100, Richard Weinberger wrote:
>> Hi!
>>
>> hwclock calls the RTC_UIE_ON ioctl to wait for a timer tick.
>> If RTC_UIE_ON was successful it opens /dev/rtcX and waits up to 5 seconds using select()
>> for a tick.
>> Some RTC drivers have no support for RTC_UIE_ON and ioctl just returns -EINVAL.
>> Drivers indicated this by setting rtc_class_ops->update_irq_enable to NULL.
>> In this case hwclock waits in a busy loop for the next timer tick.
>>
>> These two commits changed this behavior:
>> 6610e08 (RTC: Rework RTC code to use timerqueue for events)
>> 51ba60c (RTC: Cleanup rtc_class_ops->update_irq_enable())
>>
>> rtc_class_ops->update_irq_enable was removed and rtc_update_irq_enable()
>> is now using rtc_class_ops->set_alarm instead of rtc_class_ops->update_irq_enable.
>>
>> Some RTC devices (like mpc515x) don't support intervals smaller than one
>> minute.
>> rtc-mpc5121.c deals with this by rounding up to one minute.
>> But now after commit 6610e08 RTC_UIE_ON will no longer return -EINVAL and
>> the next tick comes somewhen within the next 60 seconds, because the driver rounded up...
>> hwclock's select() is not happy about this and timeouts in most cases.
>
> Thanks for diagnosing and pointing out this issue! I hadn't been aware
> of such hardware.
>
> Would something like the following be a better generic interface?
> Basically allow the RTC drivers to flag that UIE is unsupported (much as
> setting the update_irq_enable to null did prior).
>
> Let me know if this works for you, and I'll look to see what other
> drivers might be affected here.
>
> thanks
> -john
>
> Add generic infrastructure to handle rtc devices that don't support UIE
> mode.
>
> Signed-off-by: John Stultz<john.stultz@...aro.org>

Tested-by: Richard Weinberger <richard@....at>

> diff --git a/drivers/rtc/rtc-mpc5121.c b/drivers/rtc/rtc-mpc5121.c
> index 9d3cacc..be6d4f4 100644
> --- a/drivers/rtc/rtc-mpc5121.c
> +++ b/drivers/rtc/rtc-mpc5121.c
> @@ -360,6 +360,8 @@ static int __devinit mpc5121_rtc_probe(struct platform_device *op)
>   						&mpc5200_rtc_ops, THIS_MODULE);
>   	}
>
> +	rtc->rtc.uie_unsupported = 1;
> +

Please replace this line by:
rtc->rtc->uie_unsupported = 1;

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/