Re: [PATCH v2 for-4.21 1/9] x86/HPET: disable unused channels

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.10.2025 13:18, Jan Beulich wrote:
> @@ -526,6 +524,8 @@ static void hpet_detach_channel(unsigned
>          spin_unlock_irq(&ch->lock);
>      else if ( (next = cpumask_first(ch->cpumask)) >= nr_cpu_ids )
>      {
> +        hpet_disable_channel(ch);
> +        ch->next_event = STIME_MAX;
>          ch->cpu = -1;
>          clear_bit(HPET_EVT_USED_BIT, &ch->flags);
>          spin_unlock_irq(&ch->lock);

Now that I have everything else working, I thought I'd look into where the
excess IRQs come from on Intel hardware. Since my earlier experiment with
making conditional the write in hpet_enable_channel() / hpet_msi_unmask()
had failed, I was misguided into assuming some more complex logic in their
HPETs. It now appears to be as simple as I initially suspected: It's 0 -> 1
transitions of the ENABLE bit which cause immediate IRQs. And the reason
why the removal of the mask/unmask pairs in patch 2 weren't (sufficiently)
helpful is above: We better wouldn't disable the channels, to avoid said
(mis-)feature. Instead I'm now intending to merely write a long timeout
value here, along the lines of what I did in this version (code there fully
dropped in v3 though) in patch 8.

Jan