@kbowling, @erj Could you please take a look? I'd like to commit this when we get a green light from validation team.

Thank you for your work on optimizing iflib!

Thank you! LGTM

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?