Here's the output I got from the first pcib above ice4/ice5 in devinfo:

I like the changes for the Intel ethernet drivers. I've always been uncomfortable with how we were required to manually iterate through the list in the driver using the LIST_FOREACH macros; like you say in your description, if the data structure changes, then it causes a lot of driver thrash.

In D21944#479344, @jhb wrote:

How did this work? Meaning how did you allocate bus numbers? Did the parent PCI-PCI bridge have enough bus numbers in range already? For this to work properly you'd need to ensure that the parent PCI-PCI bridge at the other end of the link has the requested bus numbers mapped into its range of valid bus numbers.

@krzysztof.galazka_intel.com did this get tested yet?

In D21712#474097, @gallatin wrote:

Would it make sense then to assert that the link is down?

Relevant bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

Bugzilla link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

Is there a reason that we wouldn't do this for all of our drivers, instead of hardcoding the BAR index?

In D21005#455734, @jacob.e.keller_intel.com wrote:

This is built on top of https://reviews.freebsd.org/D21004
It could probably be backported, but isn't as necessary as the previous patch which is why I kept them separate.

Wrap line to keep it under 80 cols

This was committed to stable/11 in rS349163 and releng/11.3 in rS349181.

This is fine -- this was a result of our code stripping process, I think.

Attempt to fix paths for stable/11.

• Replace a space after #define with tab

• ifconfig: Add option to report VF status info
• ixl: Add a license to ifvfstatus.c
• ixl: Updates to if_ixl.c
• Add spare data fields to struct ifvfstatus