Message-ID: <cccbd4cf-f302-b64d-bf32-abdefbc7c6d0@o2.pl>
Date:   Fri, 7 Jan 2022 14:14:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.1
Subject: Re: [PATCH v5 0/9] rtc-cmos,rtc-mc146818-lib: fixes
Content-Language: en-GB
To:     Alexandre Belloni <alexandre.belloni@bootlin.com>
References: <20220107124934.159878-1-mat.jonczyk@o2.pl>
 <Ydg6EnPdWjB3Vznc@piout.net>
From:   =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= <mat.jonczyk@o2.pl>
Cc:     linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
        Alessandro Zummo <a.zummo@towertech.it>
In-Reply-To: <Ydg6EnPdWjB3Vznc@piout.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

W dniu 07.01.2022 o 14:03, Alexandre Belloni pisze:
> Hi,
>
> On 07/01/2022 13:49:25+0100, Mateusz Jończyk wrote:
[snip]
>> v5: Increase maximum accepted duration of the UIP high pulse from 10 to 20ms,
>>     in case there are some very slow chips out there.
>>
>>     Note: this may cause problems with hpet_rtc_interrupt() if the CMOS
>>     RTC stops working while the system is running and RTC update
>>     interrupt / RTC alarm interrupt is enabled (which should be rare).
>>     In this case, hpet_rtc_interrupt() is executed 64 times per second
>>     and takes up to 20ms to complete - which may constantly occupy
>>     one CPU. I am not sure if this is likely enough to implement
>>     special handling of this case in hpet_rtc_interrupt().
>>
> Because v4 has been applied, 

Nice, thank you! I didn't know about this.

> you'd have to send a series against rtc-next.

OK

Greetings,

Mateusz