Adjusted the devel/safe-iop and devel/uthash one-offs regarding BSD1CLAUSE.

In D23315#511436, @kbowling wrote:

I don't think any of the past corporate sponsors of this work are stepping up so the community is going to have to here. @marius you have the most recent experience looking deeply at the e1000 code, can you share an opinion on the issue and proposal?

looks good to me

I'm inclined to say that this change is okay, I'm having problems to understand its motivation, though. First off, bcm_sdhci_intr() already wraps around sdhci_generic_intr() so I don't see why sdhci_bcm(4) shouldn't actually be able to nab SDHCI interrupts before sdhci(4) does. Granted, there's the case of sdhci(4) calling sdhci_generic_intr() directly when dumping. However, when dumping in case of a panic, the scheduler is stopped so the interrupt thread for bcm_sdhci_dma_intr() shouldn't get to run either. Thus, it's not obvious to me how panic dumping currently can work at all in the first place if sdhci_bcm(4) uses DMA for these requests.
Second, "platform-driven transfer [...] keeping the bits enabled in SDHCI_INT_ENABLE for internal handling" sounds like using SDHCI_INT_ENABLE as a mere scratchpad register in the platform-specific code. If that's what you mean, it generally would be better implemented using e. g. a variable or a member in the front-end-specific softc.

I think this patch isn't entirely correct and complete; em_msix_link() should set EM_MSIX_LINK only for 82574 and em_if_update_admin_status() should only re-arm LSC interrupts if the driver takes advantage of autoclearing and, thus, uses MSI-X for such a device.
I've created D21924 with my version of the fix, which takes the above into account.

Looks good to me

I generally agree with the style(9) argument, however, if_t explicitly was introduced in r266974 as part of the - back then - new API:
"This commit introduces the 'if_t' type to replace 'struct ifnet *'as the type of a network interface."
So I'd say that new code no longer should use struct ifnet * (netdump(4) was added in r333283, so should have used if_t, too).

Could you please consistently use if_t instead of struct ifnet * in debugnet(4) components and its support code in e. g. drivers?
IIRC, there's already quite some mixing and matching in that regard in netdump(4) counterparts, for example:
typedef void netdump_init_t(struct ifnet *, int *nrxr, int *ncl, int *clsize);
but:
bge_netdump_init(if_t ifp, int *nrxr, int *ncl, int *clsize)

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.