Looks good and works good in my test.
Thank you!

The superio.c change looks mostly good, but I think that you can use ite_devices for your chip as well.
Most likely it does have the watchdog component.
Also, you were correct about the comment and assert on the possible vendor IDs. Those were not updated when fintek support was added.

LGTM. Thank you very much!

Probe the boot device first to give it preferrential treatment.
In my tests this does not make a difference as the BIOS puts the boot disk
as the first disk anyway, but other implementations may have their quirks.

I realized, after feedback from testers, that I changed only the way in which loader would pick a boot pool.
But loader usually does not do that, it just uses a pool that is passed to it by an earlier stage (typically [gpt]zfsboot).
It turned out that zfsboot did not consult zfs_pools at all and used its own mechanism to select a boot pool.
That mechanism made use of bootinfo.bi_bios_dev and zfs_probe_dev.
I changed zfsboot to use the same boot poo selection mechanism that I had in mind for loader.

(gpt)zfsboot used its own mechanism to pick up the boot pool, so it was not
affected by the earlier changes.
The boot pool was the first pool discovered while probing the boot disk.
Pools discovered via other disks were noted, but ignored.
Now (gpt)zfsboot has been changed to use spa_first_bootable().

@tsoome , could you please clarify the nature of our objection to this change?

One final super-small nit: I am not sure what style(9) says about it, but my personal preference is that if one block of an if-else chain needs curly braces then all blocks in the chain should have them.
To my eye, that looks prettier.
But feel free to ignore this if it looks uglier or just the same to you.

I think that this is a very good change. Some minor code style / improvement suggestions from me.
Thank you.

@imp , I am not sure if we are disagreeing about anything.
I just explained why the current code the way it is (for shared interrupts).
And stated that the non-shared interrupts case is different.

In D34117#771775, @imp wrote:

But it does not make sense for exclusive interrupts: how the hardware can generate an interrupt if it's not sufficiently resumed yet?

You assume a binary condition in the resume function. Maybe the hardware needs interrupts to properly resume the device after restoring a few registers?

In D34117#771597, @markj wrote:

So this fails for at least nvme: pci_resume_child() un-suspends interrupts after resuming devices, but nvme_pci_resume() depends on having working admin interrupts, in nvme_ctrlr_identify(). It's not obvious to me exactly why we need to resume the driver before enabling interrupts. Reording fixes the problem on my laptop at least.

In D34117#771584, @markj wrote:

I still tend to think it's better to avoid the unlocked intsts read in hdac_intr_handler().

Yes, rid 0 is for legacy PCI interrupts and rids >= 1 are for MSI / MSI-X.
So, indeed, a proper barrier would require iterating over all active interrupt resources.

@markj , hmm, maybe 82a5a2752724 should be extended to non-shared interrupts to prevent races between an interrupt handler and a suspend method?

I am a bit torn on this.
On the one hand, I like the simplicity that comes from returning errno codes to userland.
On the other hand, recently I had to write a program that had to use "low level" ioctl-s like I2CSTART and I needed to be able to distinguish IIC_ENOACK from other bus conditions.
In any case, the current state of matters where a return value can be either an errno code or an IIC code is clearly a mess.

In D33980#768547, @kib wrote:

Did you consider putting sched_pin() at the caller' side, same as on amd64?
I do not insist, just curios: IMO i386 on 12 ought to get as little efforts as possible.

address comments from mav

@manu , not sure if this is the approach that you had in mind.
But I think it's better to discuss based on some concrete code rather than abstractly.
Thank you.

Ping.