Seems fine to me, but I am not an authority on the subject matter.

Please check the commit description before pushing.

Looks good, I am somewhat

Approved, please go ahead and commit this.

Oh spare me your wounded pride and perceived victimhood.

The subject of line-breaks is infinitely bikesheddable, so I will state my opinion here once more and then never again.

So, should it also be expanded/applied to the various hardware notes in this commit (not just the template)?

Overall it is a clear improvement.

In D50330#1148832, @bapt wrote:

origin is not a good way to reference a package, I know people are used to it, because at somepoint it was the only to get a unique name which reference a package, but it is not the case anymore, with flavors or even with subpackages.

Approved.

LGTM with one tweak.

Approved.

Approved.

Approved; with @imp and @tsoome's review I think you can proceed.

Thanks.

In D49687#1143288, @ziaee wrote:

Is that sufficient for me to merge this?

Thanks all for the input. Let us proceed here. Having spoken with the interested parties, I plan to handle the follow-up change describing the driver provenance.

Approved.

Add #ifdef FDT conditionals around mii_fdt.h inclusion and the call to mcommphy_yt8531_setup_delay().

@jsihv_gmx.com you might have seen, I merged this functionality but had to revert as it broke the build on amd64 (!FDT). Here is an updated version which addresses this.

Thanks, this is great.

Commit LGTM, if someone confirms the factual accuracy.

Approved.

Approved.

Okay, I looked through the code again in detail and things seem good to me.

In D49543#1129885, @cperciva wrote:

In D49543#1129854, @cperciva wrote:

The one user-visible difference is that if we avoid reusing freed IDs then we can quickly hit PCI_INVALID_IRQ and get a panic. If we reuse freed IDs then we only hit that panic when we leak an IRQ (which is a separate issue I'm talking to @jhb about).

If someone can figure out how to resolve the "returning PCI_INVALID_IRQ from intr_map_irq makes bad things happen" issue then I agree there will be no functional difference.

Never mind, once the bogus PCI IRQ allocation is gone (D49560) there's no panic because intr_map_irq isn't returning into the PCI code.

So no user-visible difference here.

Approved.

Indeed, I did not read it closely enough :)

Aside from the warning, this should be a no-op, as the only thing gated behind this knob on the kernel side is sys/modules/efirt, which still has an additional MACHINE_CPUARCH check around it.

IMO it is logically preferable to exhaust all unique/unused IDs before issuing one that was previously assigned, then freed. This is how the current code behaves.

FYI, it is difficult to review a change that reorders and rewords a list of entries, at the same time. In the future such a thing should be split.

In D49494#1128681, @ziaee wrote:

I verified that there are no other instances of git -C with git grep and tested the command. @mhorne should I merge this?

git -C /usr/src pull, as you say in the title.

Approved.

"show two examples in PORTS_MODULES so it's obvious that they're space separated", can you note something like this in the commit message?

LGTM, and Approved.

Approved.

In D49408#1126804, @ziaee wrote:

Thank you, I thought it does need it because I'm proposing changing the copyright header?

I ask once again to be mindful of your use of the commit trailers here... The commit does not require "approval" from @shurd, but as the author of the man page (its de-facto maintainer), his "Reviewed by" is meaningful.

Superseded by aaf0a7302d10.

Superseded by c0bed9bd0bda.

Superseded by c0bed9bd0bda.