Is there anything stopping from using our framework for building the binaries rather than using a vendor Makefile which works around it?

Sounds great, thanks for all the work you've put into this!

Thanks for looking into this!
I'm asking because I've seen countless of people reporting these controllers (especially on motherboards) as being notoriously unstable/flakey likely due to heat and the cause might not be obvious for the end user given that you normally have no issues at least in terms of heat with integrated NICs. I've also seen some reports on forums of the controller completely die as in drop off PCIe bus and never come back again but I'm not sure if that's only due to overheating. I agree that it probably should go into some kind of sensor/health framework in the end but it would be nice to some kind of warning for diagnostic purposes. While we can discuss thresholds later I'm not sure if I would consider it "safe" for it to go all up to 108C before shutting down/throttling, perhaps warn around 70C and kick in around 80C.

Given the rather hot nature of these chips perhaps add some kind of temperature warning or possibly drop link speed (if it helps reducing temperature) once it reaches a threshold rather than it completely wedges itself?

It should go in commit message rather than the port Makefile

Two issues with using Phab is that Porters Handbook's time outs don't apply to it and you don't necessarily even as a registered user receive emails. However, since there were a PR earlier (and emails have been sent) and upstream applied this PR just merge it as a build-fix.

distinfo updates are missing, LGTM

Nice, good catch! For easier tracking I'd suggest that we pull this from GitHub rather than adding it to the tree.