[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 5/8] x86/HPET: drop "long timeout" handling from reprogram_hpet_evt_channel()
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 22 Jan 2026 10:03:05 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6jnphzctb+7lIRKrxEX309Ls5U7f/H6HAe4WlzmKt08=; b=VK1NnD1203vaU6DBb8Vy+m7fcLmPnplnjnJwTwIF9t1uSxIcw4oQrV5q2EDEGR1IRWK+gWat1zbBS3KEYLO3mUV5GX6mltx9dkntFzxJGWRuHIy+l0u2C/bpUnSerf1nNOxtQAE4SUBKs9KIB/o9Y3aPcZ3/gRYZ+g+1rbZH9jOwf+Of25shm7mTxdfyEt8NVGZ8C4Kdxux1Y/CjEzJO9jQbKAxEv/GcV9/8Hj1GkFJZXwKLX2uvkIFdIhZ/qZ7AbKMFQ8cxJ898NuRfkSIFUyhQ2gkO+bIpY7HdGYVFZmHl4qUkATpiHm2ukPmYtalVHiTIeqlNmCVlYgpzW6ye6Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xAM9SgQdpMJNGsi/A7/z9J6J0jblqrhlGBkVCgg75Wzk68ejr73WJgcofdEmsBfij7K54/CouYLRSWmuVXeECrrjYIji3GvqoFG8dTbLFUAep2YTFYW9GAOyuC3IUEHPT2qYugSB72aHGQoIPAawqKDeOyArtQAozWunJbL/DgGabdPuNWenTleHUimfLJHeoHuCF8Un41GvomaKgvTJlG5yAQYpwHncgM9AKefm3sphMYHwUj0y/O5qgd2+FgMlYErDWwC0r4lc+k4zL1Vk4lR9l+CZoXaALrgtOl/S+MOlGCreuEw6jCjydKLU9cOkN+HlAgk2r4c6HMOTnvX3/w==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Delivery-date: Thu, 22 Jan 2026 09:03:18 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, Nov 17, 2025 at 03:39:03PM +0100, Jan Beulich wrote:
> Neither caller passes STIME_MAX, so (bogusly) handling the case isn't
> necessary.
>
> "Bogusly" because with 32-bit counters, writing 0 means on average half
> the wrapping period until an interrupt would be raised, while of course
> in extreme cases an interrupt would be raised almost right away.
>
> Amends: aa42fc0e9cd9 ("cpuidle: remove hpet access in hpet_broadcast_exit")
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> v3: Drop the code instead of adjusting it.
>
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -162,13 +162,6 @@ static int reprogram_hpet_evt_channel(
>
> ch->next_event = expire;
>
> - if ( expire == STIME_MAX )
> - {
> - /* We assume it will take a long time for the timer to wrap. */
> - hpet_write32(0, HPET_Tn_CMP(ch->idx));
> - return 0;
> - }
I wouldn't mind if you replaced this with an ASSERT(expire != STIME_MAX);
Thanks, Roger.
|
