- User Since
- Jun 3 2014, 3:27 PM (351 w, 4 d)
Jan 27 2021
Jan 26 2021
Jan 21 2021
Jan 16 2021
Dec 27 2020
Dec 26 2020
Dec 25 2020
Dec 13 2020
Jan 24 2020
Dec 28 2019
Dec 27 2019
Nov 30 2019
looks good to me
Nov 21 2019
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.
Oct 30 2019
Oct 24 2019
Oct 20 2019
Oct 7 2019
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.
Aug 28 2019
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);
bge_netdump_init(if_t ifp, int *nrxr, int *ncl, int *clsize)
Jun 26 2019
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.
Jun 24 2019
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.
Jun 16 2019
Jun 15 2019
Jun 7 2019
Thanks, looks good to me now
May 22 2019
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