Fix reviewers list.

Fix assertion condition. It should be the expected state, not the opposite.

Wake-on-Lan configuration is not available for VFs.

In D52782#1206718, @erj wrote:

Can you tell us what the hardware enhancements are? 👀

This file might be a collateral damage of splitting PF and VF drivers on Linux. We should have all definitions from this file in other places, but let me double check if there are no differences.

In my testing it also looks good, both on PF and VF.

@jmg thank you for the patch! I started working on that issue, but a family emergency put me AFK for almost 2 weeks. To avoid further delay I think we should proceed with your version. It looks good to me, but let me run some basic tests on Monday. I'll approve this review as soon as I'm done.

Thanks again!

Fixing Eric's comment about codename seemed as a trivial change so I tried to do it without engaging Yogesh and updating the review. I'm sorry, it looks like it was a poor idea. Commit wasn't automatically detected by Phabricator and this review is still open. Is there anything else I should do except for adding the commit with 'Edit Related Objects', and promising to not try to cut the corners in the future?

@erj @kbowling - We've got a green light from our validation team. Could you please take a look at latest updates?

Abandoning this revision as related Github PR was merged by @imp

• ice(4): Fix setting VF MAC address

@jhb Is there anything else you'd like me to change in this patch?

Remove also 2-part ID for 0x12D3 devices.

I would assume if you hold the fw semaphore you'd have exclusive access to the adapter..

@adrian Would you mind posting device id and hw->phy.type from the system you're using for testing?

In D50128#1147046, @kbowling wrote:

I would be somewhat curious why we need to serialize like this. Note that nothing else prodding the swfw in ixgbe is explicitly locked or asserted.

In D50067#1149007, @erj wrote:

In the description:

Support exclusively for x64 operating systems; no 32-bit OS support

Doesn't the in-kernel ixgbe driver still build for i386? Does this just mean no "official" support when it's running on non amd64 kernels?

Add missing newline

@erj, @kbowling: We're still awaiting for feedback from validation team, but would you mind taking a look?

@erj, @kbowling Could you please take a look?

In D50243#1145941, @kbowling wrote:

It has the approver-this is a bit of a race condition as you need me or erj or both to approve so you will always need to update it right before push.

In D50243#1145872, @kbowling wrote:

It will be helpful, especially early on, to add a fully formatted commit message to the review description so we can have a look and make sure you have the git config right.

In D50127#1144438, @erj wrote:

I'm going to assume there are some hidden #ifdefs that are getting stripped out that require the write() function to be more complex for some reason. @krzysztof.galazka_intel.com ?

Implement feedback from jhb.

Update with recent changes from Github PR: https://github.com/freebsd/freebsd-src/pull/1573

Looks good to me. Unfortunately I don't have any EM HW to test it.

LGTM

The one thing I think drivers would like to do is allocate additional MSI-X IRQs on the fly

Ah, that makes sense. Thanks a lot for clarification!

In D48812#1114102, @jhb wrote:

I'm worried that this might have other side effects for things like EA caps. However, I think it's also true that caching the MSI counts is probably wrong in general. It's not just VFs, in theory writing to some other register in a PF can change the value of the MSI control registers and we should just always read them.

In D48812#1113788, @jhb wrote:

I believe pci_msix_count() is returning a cached value from when the VF was first created in pci_read_cap() called from pci_fill_devinfo() called from pci_add_iov_child() called from PCI_CREATE_IOV_CHILD. If the MSI-X count is then adjusted by the driver in the PCI_IOV_ADD_VF callback, the cached value will be wrong.

I'm not sure why pci_msix_count returns incorrect number. pciconf output looks fine: