ifdi_power_prepare or whatever lands will also be used in a followup commit to disarm the ixgbe firmware recovery task when the device is suspended.

@ziaee yes this is overcome by b6cd053e6da9 no remaining changes are needed from this.

Add an attach-only refresh latch instead of overloading. Reset recovery still skips redundant PHY programming without republishing link. Reset preparation clears any obsolete attach refresh.

Some background on this change is perhaps worth sharing.. I was originally chasing the up/down/up dance on boot, seeing if I could improve boot speed by carefully driving initial ifnet status through a state machine. But the majority of the time is spent in PHY code so doing something careful in iflib only shaved off xx-xxx milliseconds. Therefore the initial investigation is more of a driver state machine problem, and ice(4) has a good example of doing link state well. This ends up closing a few gaps anyway so here is just the lifecycle relevant part, and it lends naturally to the PM state machine that is a child of this review.

@sumit.saxena_broadcom.com I'm going to help this along since it just needs some trivial changes to lang, I will retain you as the author

Committed as a550e8280b98

I think this is a strict accounting improvement. e1000 manufactures some descriptors in a couple situations to work around hw errata, although I'm not sure that direct RS wb would've faulted.

Switch back to removal. I don't think this is merely a WITNESS ordering issue now, 2f8f892ca344 may cause a timing sensitive deadlock with the existing registration lock and @netchild is hitting it.

In D59294#1360665, @glebius wrote:

Did the original version of this review removed use of IFNET_WLOCK completely? If I understand phabricator correct, that would be URL https://reviews.freebsd.org/D59294?id=185524 I also would prefer this.

@glebius this does not resolve the WITNESS panic between e0e12405285b6 and 2f8f892ca344

Limit this change to the fe00ca2f8871 regression

https://reviews.freebsd.org/D59294

@glebius I am stress testing a fix for the fail point registration, I will tag you when I post it.

Agreed, abandoning this approach

address feedback

address ice(4)

address feedback

iflib(4) change

In D59204#1359477, @netchild wrote:

My build is still running on the old hardware where I can test this.
Quick check, if I get it right:

• this solves the issue where demand is false on the next period.
• this does not solve an issue where ~1 packet per period is send while more than one is in the queue (no idea if this is behavior we can see in the real world): growth every period → demand true every period → armed reaches 4 → still resets.

This is unsafe as is, and needs a broader pass so you can close it.

Still relevant. No.

In D59239#1359142, @kevans wrote:

FWIW- I think the change is largely fine, but the main thought I had when looking at it initially is that it might be worth having its own RANDOM_PURE_TPM12 just in case one wanted to disable just entropy from older chips in their own generic images. We only have something like 4 bits left for new sources at the moment, though, so that kind of needs more deliberation. OTOH, Fortuna's design (as I understand it) means that it doesn't really matter if this single source is lower quality as long as it's not completely broken.

address license format and man page

Thanks for adding csprng. One thing that bears a bit of scrutiny here and the existing tpm20 collector is the registered quality level. https://trustedcomputinggroup.org/resource/sha-1-uses-in-tpm-v1-2/ claims the SHA-1 mixing function does not materially degrade the output and I can link some papers that claim they tend to outperform PRNGs. In a tpm20, you generally have a high(er) quality random source and mixing function, but it could also be a vTPM proxying CPU rdrand or the like.

Apply uio finding from @kevans to tpm20

It's a good catch, The TPM wait paths can return errnos, which the write converts into a succcessful short write once uio_resid has chaged. I restored the original residual when a post-copy TPM op fails, and preserve the short count only after sc_end() succeeds.

Add locality acquire assertion. Release side would be trickier since it is used in abort and cleanup.

OpenBSD carries the same BIT change.

I reworked the implementation around this feedback but I'm not sure it can be done in pcib (please let me know if you see otherwise).

address feedback

Some followups: Add NOTES entry on commit. Later consider MODULE_PNP_INFO. LGTM.

I plan to commit this, D58777, D58778 if no more followups are received in the next 48 hours.

In D59141#1356940, @imp wrote:

Would you rather we commit our changes first and you rebase on top of them, or vice versa since they are complimentary.

In D59141#1356926, @imp wrote:

Here's the work we've done internally that's somewhat similar.

https://github.com/bsdimp/freebsd/tree/tpm-measured-boot

This is deliberately limited to the measurement plumbing. Policy decisions are exciting. For instance, this could be used to drive a full TCB with veriexec(9), sealing keys like GELI or ZFS to boot state, remote attestation, signed containers, a Chain of Trust to externally controlled bhyve VMs, etc but that will come with a lot more weight. When I did this in industry at a financial custodian, we had extremely stringent controls centered around immutable build and release pipelines as otherwise this can become a big pain when you do something trivial like change a loader setting or upgrade etc. So that is left for later experimentation, and decisions for what make sense to ship as an open source general purpose OS.

address feedback

@ziaee the igbv(4) linkage and the new SR-IOV section in head we talked about on IRC is an attempt, feel free to massage it as you see fit

Accessor split out to 3481a9cdc4dc

In D58370#1354832, @christos wrote:

Doesn't snd_hdsp(4) need the same?

Thank you for doing this. I want to eventually add some 1588 stuff to some drivers so this will be a prerequisite. Consider documenting in iflibtxtx(9).

This is substantively fine, I would fix up these 6 new suggestions and then see if @adrian has any desire for the naming.