On 27 June 2018 at 06:58, Bernhard Voelker <mail@xxxxxxxxxxxxxxxxxxx> wrote:
> On 06/26/2018 11:13 PM, Sami Kerola wrote:
>> @@ -255,16 +249,7 @@ static int synchronize_to_clock_tick_rtc(const struct hwclock_control *ctl)
>> } else {
>> int rc; /* Return code from ioctl */
>> /* Turn on update interrupts (one per second) */
>> -#if defined(__alpha__) || defined(__sparc__)
>> - /*
>> - * Not all alpha kernels reject RTC_UIE_ON, but probably
>> - * they should.
>> - */
>> - rc = -1;
>> - errno = EINVAL;
>> -#else
>> rc = ioctl(rtc_fd, RTC_UIE_ON, 0);
>> -#endif
>
> Are you sure you want to change the code path for SPARC?
Hi Berny,
After reading linux kernel code, and trying to find references where sparc
condition might be originating I could not find good reason why sparc should
hard code RTC_UIE_ON not to be supported. There is message from 2005 about
chrony having issue with sparc RTC_UIE_ON, but later in that thread Dave
Miller tells there is no problem with rtc and sparc. I am fairly confident
ioctl(rtc_fd, RTC_UIE_ON, 0) will either do the right thing or return -1.
Reference: https://lists.debian.org/debian-sparc/2005/04/msg00115.html
--
Sami Kerola
http://www.iki.fi/kerolasa/
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
