Import snapshot of Aquantia ACQ107 vendor driver

[emaste]

Summary

Obtained from https://github.com/Aquantia/aqtion-freebsd commit
c61d27b1d94af72c642deefa0595884481ea7377.

[emaste]

Cleanups and build infrastructure will follow; mainly wanted to pop this into review for a couple of points

• I didn't do this via a vendor branch. https://github.com/Aquantia/aqtion-freebsd looks like it is is abandoned and will not receive further updates. NetBSD and OpenBSD have derivatives of this driver with additional hardware support. Thus I think there is no value in bringing this into a vendor branch -- we'll have the initial import as a snapshot, but from there we will just iterate on it in the tree as our own code, including borrowed changes from NetBSD and/or OpenBSD.
• It has been restructured in NetBSD and OpenBSD, but I still think it makes sense to import this working driver as-is first rather than starting with a port of NetBSD's/OpenBSD's driver.
• I should probably strip out the non-src files (.cirrus.yml, .gitignore etc.) and just keep *.[ch]. The files have the license included so the standalone LICENSE is redundant.

[emaste]

Three patches obtained from net/aquantia-atlantic-kmod get the driver to build:

commit 74807fef8838c93f783d151f7200bfcc4e9e030a
Author:     Rozhuk Ivan <[e-mail]>
AuthorDate: Wed Oct 26 15:37:57 2022 +0300
Commit:     Ed Maste <[e-mail]>
CommitDate: Tue Nov 18 18:27:39 2025 -0500

    aq: Remove #include of user header <unistd.h>
    
    pause() has 2 different definition in unistd.h and sys/systm.h

commit 58ccb1795dc49f27c49441a83ea21e54328bf2f0
Author:     Olivier Cochard <[e-mail]>
AuthorDate: Wed Nov 12 22:17:03 2025 -0500
Commit:     Ed Maste <[e-mail]>
CommitDate: Tue Nov 18 18:27:39 2025 -0500

    aq: Port to IfAPI
    
    Direct access to struct ifnet members is not possible in FreeBSD 15;
    accessors must be used.  These exist in all supported FreeBSD versions,
    so we do not need to make this conditional.

commit 3103ddfd0293ea1f5d042c1de232c2f12d687b5b
Author:     John Baldwin <[e-mail]>
AuthorDate: Wed Nov 12 22:23:27 2025 -0500
Commit:     Ed Maste <[e-mail]>
CommitDate: Tue Nov 18 18:27:39 2025 -0500

    aq: Remove unused DRIVER_MODULE devclass

Then one bug fix:

commit 476cc6636437caaf2e6ff047292d8381afc1e555
Author:     Ed Maste <[e-mail]>
AuthorDate: Thu Nov 13 09:15:38 2025 -0500
Commit:     Ed Maste <[e-mail]>
CommitDate: Tue Nov 18 18:27:39 2025 -0500

    aq: Fix VLAN tag test
    
    Previously emitted a compiler warning "warning: bitwise comparison
    always evaluates to false."
    
    Looking at the OpenBSD driver (which is based on this code) it looks
    like the VLAN flag should be set if either of thsee bits is.  In the
    OpenBSD driver these are AQ_RXDESC_TYPE_VLAN and AQ_RXDESC_TYPE_VLAN2
    rather than a magic number 0x60.

[emaste]

PR238324

[adrian]

I think it's fine to land and clean up. It's a linux sourced driver with a HAL, debug and trace layer that we need to clean up and then they've written the iflib bits. So like, if it works for people, let's land it and clean it up in post.

sys/dev/aq/aq_hw.c

317

We can fix this in post - we have an ethernet random address generator now, we don't have to do this

sys/dev/aq/aq_main.c

370

heh we should fix this in post

380

we can delete this in post

451

ugh, we should also fix this in post to use a fixed RSS key so we don't have boot to boot variation

491

lol, we're going to have to implement suspend/resume at some point

782

we can fix this in post (unless someone plans on porting this to stable/13?)

[emaste]

sys/dev/aq/aq_hw.c

317

We have random_ether_addr in linuxkpi and a random fallback in ether_gen_addr_byname but I can't find a native kpi version of this full-random?

sys/dev/aq/aq_main.c

380

Yeah, we can remove all of the FreeBSD version #ifdefs. I wanted to start with an exact snapshot of the upstream repo just in case any future work is based on it.

451

Yeah -- I'll add a comment here to this effect after committing the initial snapshot

782

I expect to bring this back to stable/14 but won't bother with 13.

[michaelo]

Isn't it better not to have a driver at all rather than having one which is six years old, a preview and heck knows working at all reasonably?

[adrian]

In D53813#1229884, @michaelo wrote:

Isn't it better not to have a driver at all rather than having one which is six years old, a preview and heck knows working at all reasonably?

no?

We can always delete it and replace it with another if it doesn't pan out but people have the hardware now and we should have something.

[michaelo]

In D53813#1229885, @adrian wrote:

In D53813#1229884, @michaelo wrote:

Isn't it better not to have a driver at all rather than having one which is six years old, a preview and heck knows working at all reasonably?

no?

We can always delete it and replace it with another if it doesn't pan out but people have the hardware now and we should have something.

Delete even from minor to minor? I wonder how many people will start using it and notice that it works wonky...

[emaste]

Delete even from minor to minor?

Basic functionality works fine and we've got two years before stable/16 branches to find and fix issues.