Looks good to me now, thanks.
For committing, please extend the commit message to additionally state
that the iflib(4) interrupt allocation needs re-doing not only to also support
single-message MSI-X and MSI-X-only devices, but for none-PCI devices
and multiple interrupt vectors that are not MSI-X as well, though.

Apart from the style problem, this change looks good to me.
Have you looked at how hard it would be to actually support configurations
with just 1 MSI-X, though? I think to remember the assumption that a single
interrupt means what iflib(4) calls "legacy", i. e. INTx or MSI, in 1 or 2 places
and generally iflib(4) would need to be made less smart and not so aggressive
in setting up interrupts, but nothing which seemed that much work.

Thanks, looks good to me now

Looks good to me; still needs re@ approval via the usual change request procedure for committing to stable/11 during the freeze, though.

Looks good to me

Looks good to me now, thanks!

Looks good to me now, thanks!

Looks good to me

Yes, the case of the driver providing isc_n{r,t}xd_min which aren't a power of 2 must be handled as well for iflib(4) to actually do the right thing. This is getting kind of ridiculous, though, as rounding up isc_n{r,t}xd_min to a power of 2 in turn may exceed sc_n{r,t}xd_max and so far nothing guarantees that sc_n{r,t}xd_max is a power 2 either, same for sc_n{r,t}xd_default. As much as I understand the desire for iflib(4) to figure out applicable values within the ranges supplied by the driver with the driver just taking actual hardware limitations and not iflib(4) constraints into account, IMO such magic would just be too complex without much real gain beyond some convenience for driver developers. Moreover, these ring size constraints aren't the only restriction imposed by iflib(4) onto the driver/hardware. For example, given that iflib(4) only offers a shared DMA alignment constraint (isc_q_align) for both RX and TX descriptors, ixl(4) nowadays specifies a 4096-byte alignment for both while according to the pre-iflib(4) counterpart, that alignment is only required for the RX descriptors with 128 bytes being sufficient for the TX ones. By contrast, something that iflib(4) really should deal gracefully with rather than iflib_device_register() just failing is a user supplying non-power-of-2 ring sizes via the override_n{r,t}xds SYSCTLs.
Thus, what I'd suggest instead is to simply assert in _iflib_assert() via MPASS() that all isc_n{r,t}xd_{default,max,min} are a power of 2. Actually, it's not that uncommon for Ethernet MACs to also only support ring sizes which are a power of 2 (at least Apple GMAC, National Semiconductor Saturn, Sun CAS, ERI and GEM come to my mind), probably for the same optimization reasons iflib(4) only supports power-of-2-sizes, too. If a particular MAC happens to really support some more odd-ish ring sizes, just take note of that fact with a comment in the driver. However, code should be added to iflib_reset_qvalues() which resets isc_n{r,t}xd to isc_n{r,t}xd_default in case the user-supplied values aren't a power of 2.

Looks good to me now

Looks good to me, it would be great if you could expand "Resp" to "Response" and use "result" instead of "err" for consistency while at it, though.

Returning FILTER_SCHEDULE_THREAD from iflib_fast_intr_{ctx,rxtx}()
is still wrong as iflib_irq_alloc_generic() doesn't register a handler that could
be scheduled.

I second Andrew; using FILTER_STRAY in case of !iflib_started is a good move,
but returning FILTER_SCHEDULE_THREAD from the filter registered via
bus_setup_intr(9) is wrong at least when done unconditionally. The latter
signals intr_event_handle() to schedule an ithread for running the handler
registered via bus_setup_intr(9), but currently neither iflib(4) nor its
consumers appear to actually register a handler. The better change in that
regard probably is to remove support for handlers from _iflib_irq_alloc() and
iflib_irq_alloc() as the approach taken by iflib(4) apparently is to schedule a
gtask by itself (rather than letting intr_event_handle() schedule an ithread) if
there's no ifi filter or the ifi filter doesn't fully handle a particular interrupt,
i. e. the ifi filter returns the somewhat abused FILTER_SCHEDULE_THREAD.
Maybe iflib_irq_alloc() should be even removed completely as its currently
unused and if a driver wants to do something fancy with an interrupt outside
of the design of iflib(4), that driver is better off setting up that interrupt entirely
by itself.

Bring back additional function descriptions lost, adjust some others and INIT_DEBUGOUT() invocations to match reality after the iflib(4) conversion.

Improved em_if_timer() and em_if_watchdog_reset() descriptions, brought back the right one for lem_smartspeed() from prior to the iflib(4) conversion.

Fixed a typo (RX vs. TX) in one of the messages altered by the previous patch

Well, as-is iflib(4) in fact is PCI-specific.

Well, I would just have went with "PCI" but if you prefer to state all variants :)

sys/dev/ixgbe/if_ixv.c appears to be missing a "MODULE_DEPEND(ixv, iflib, 1, 1, 1);" but while you are at it, you could remove its netmap dependency (now already provided by iflib.c) instead

Yes, as the manpage for the bus_release_resource(9) family of functions says: "The bus methods are free to change the RIDs that they are given as a parameter. You must not depend on the value you gave it earlier." On way do deal with that is to cache the returned RID in e. g. the softc. As is, em(4) does that for adapter->ioport via adapter->io_rid, but not for the adapter->flash and adapter->memory resources. The summary doesn't state this correctly, sorry, I'll address that when committing.