Adjust based on review comments. Thanks a lot!

$ sysctl net.link.epair.ether_gen_addr=1
$ ifconfig epair8 create > /dev/null; ifconfig epair8a | grep ether; ifconfig epair8a destroy # (twice)
ether 58:9c:fc:10:2b:b4
ether 58:9c:fc:10:2b:b4

I almost think the kld_load lines (and the kldload now mentioned in some but not others) need to go from all of them and the manual procedure should be documented in one place elsewhere?
That would likely also give us a single version.
@ziaee any idea for a good man page to do so?

Something else funky is going on; please stop spending time on this until I can figure out I would say:
https://lists.freebsd.org/archives/freebsd-current/2025-June/007932.html

Fix Copyright.

Update the change to not break drm-kmod on all supported branches right away.

In D50995#1164147, @emaste wrote:

Why do we + 1? It came in 4cc8a9da491d1 but I believe is a bug.

Accepted assuming you'll fix the typo in the comment before commit.

The warnings are gone but does that also mean that if ATF doesn't support the bits any errata are not dealt with silently now?

Somehow I'd love to get this in so I can forget about this Issue. Anyone?

Note: this can go in w/o D50928 if deemed correct.

In D50923#1162429, @adrian wrote:

Heh we've both hit a couple of fun paths into this (see https://reviews.freebsd.org/D50794 as well)

In D44861#1161563, @rene wrote:

So for an AX201-based card (8087:0026) I currently get this:

rene@tuxedo:~/oss/freebsd/src/bluetooth $ sudo iwmbtfw -DI -d ugen1.4
main: opening dev 1.4
iwmbt_is_supported: found iwmbtfw compatible
iwmbt_get_version: Can't get version: : code=0, size=6
handle_8260: iwmbt_get_version() failed code -1
iwmbtfw: main: Firmware download failed!
rene@tuxedo:~/oss/freebsd/src/bluetooth $ sudo usbconfig -lv | grep AX
ugen1.4: bcdUSB=0x0201 bDeviceClass=0x00e0 bDeviceSubClass=0x0001 bDeviceProtocol=0x0001 idVendor=0x8087 idProduct=0x0026 bcdDevice=0x0002 iManufacturer=000000 iProduct=000000 iSerialNumber=000000 bNumConfigurations=0x0001 vendor='Intel Corp.' product='AX201 Bluetooth'

and from existing code:

	{ USB_VPI(USB_VENDOR_INTEL2, 0x0026, UBT_INTEL_DEVICE_8260) },

In D44861#1161446, @rene wrote:

The raw diff does not apply anymore on 15.0-CURRENT 45165aab2d229a1377fb2c054d5c7c338acc268a

In D50863#1161013, @dumbbell wrote:

In D50863#1161012, @bz wrote:

In D50863#1161009, @wulf wrote:

General convention in at least drm-kmod is to not redefine ACPICA objects if it is possible. Porting of this code is mostly just a changing of symbol case and adding/removing of underscores. drm-kmod does not even guards these changes with #ifdefs

I picked a random file ( in v6.6 drivers/gpu/drm/radeon/radeon_acpi.c ) and it seems everything there got CamelCased without any #ifdefs. It's just an unnecessary diff to vendor and maintenance.

No idea how much of this was done in drm-kmod but I am not going to rewrite case in entire files because of this. I had not compiled files or #ifdef'ed out the entire logic. Not gong to fly anymore. Remove the #ifdefs from drm-kmod and reduce the diff to upstream and make maintenance easier by having one place to edit and not 117. That's what LinuxKPI is for.

Yes, I need to spend some time to expand linuxkpi so that we can get rid of all these ifdefs in drm-kmod.

In D50863#1161009, @wulf wrote:

General convention in at least drm-kmod is to not redefine ACPICA objects if it is possible. Porting of this code is mostly just a changing of symbol case and adding/removing of underscores. drm-kmod does not even guards these changes with #ifdefs

You guys are better than mandoc -T lint :)

Add AUTHOR section as requested.
Repharase the sentend about WEP and explain why there is no support.

In D50791#1159833, @ziaee wrote:

Warner asked about reducing boilerplate in manuals. I wonder if we can put this in intro(4). I'm working on something and will tag you when I get closer.

adjust to say not possible to load from loader

In case https://reviews.freebsd.org/D50817 goes in we should actually change this to say "it is not possible to load the driver from .Xr loader 8 ." and be done with it.

In D42775#1159623, @lwhsu wrote:

releng : just be curious, is it ok to change the release related documents after the release is out of the door? (I guess so but want to confirm.)