that should be = M_SIZE();

As a matter of fact that line looks like a NOP actually.

There's a whole lot I don't understand with the driver in the following:
(1) why are we moving by ETHER_HDR_LEN rather than by ETHER_ALIGN if it's all just fixing the uint32_t alignment enforced by the HW to then get the equivalent of m_adj(m, ETHER_ALIGN) after receiving the data?
(2) Why in the old world there was a check for MHLEN on first if w/o making sure there's no external storage, despite we know we have a cluster from m_getcl?
(3) it only uses l2hlen later but the comment says moving ethernet + IP header.
(4) no one ever initialises l2hlen in this driver, so it's 0, right? Which is probably good as otherwise the first else if() condition would be bogus.
(5) that effectively makes parts of the else if condition now a bit redundant as we already have a cluster from m_getcl() and thus we are really only asking if (ETHER_HDR_LEN /* or ETHER_ALIGN */ <= MHLEN)) so we can move the ethernet header to the internal storage of the new pkthdr mbuf with proper alignment (or not as we don't care in that case as the L3 header would be moved to properly align, but isn't either leaving the L3 probably at a %2 and not a %4 offset?)

I am just confused here.

I wonder if that wants to be m_new->m_len aka. M_SIZE(n_new)?

The other cases of MCLBYTES and JUMBO sizes are blah to fix w/o restructuring the driver or having at least accessor functions/macros hiding the actual values so the magic could be changed under the hood in the future. I guess in a future iteration.

I keep wondering why we can't first calculate the "len" and then ask for the mbuf size we need? Probably not part of this change.

I keep wondering why we can't just ask for the appropriate size depending on "length"? Probably not part of this change.

This line should also move up before the m_adj call; otherwise lens are not initialised and m_adj probably does funky things.

That's an independent fix and should probably go in it's own commit afterwards.

Lines 3721 and following; there are more MCLBYTES that could be changed based on adapter->fmp or mp.
Line 3853 has another one (in addition to more c&p stupidity discussed similar to emac it seems)

The +2 should probably all be ETHER_ALIGN; untreated to this change ;-)

Why not at least check m->m_len first to see what size you want?
Probably exposes another constant again:( But common theme it seems.

Line 2928 is another MLEN that wants changing.
Line 1951 looks spookily like it could be M_SIZE() as well instead of MCLBYTES but it is weird.

I gave up on the logic, but the changes seem fine. I wonder if this driver wants to be de-orbited ;-)

Line 1199 looks like it can be M_SIZE() as well

That one can be changed as well, I'd say.

Line 2744 is like 2660 and should get the same treatment.

This is another M_SIZE(m0) given the follow-up usage, right?

In theory that could be changed to M_SIZE as well.

You touched the driver, you own it :-p /SCNR :D

I keep wondering about this one. That's a lookahead :-(
That code should be slightly rewritten I guess.

Unrelated, but do I have to understand this one?

This line should go before m_adj()

This line should move before m_adj()

There's plenty of MCLBYTES some of which look remotely resolvable but maybe in a next pass.

Looks like a missed one.