@aokblast there is also PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297155 now referencing some of these problems.

I believe this is wrong. The 18V here is a card *feature* and the feature doesn't change with what the host supports.

FYI: I still need to run a universe but with some minor inconvenience and adjustment to the native USB headers
I seem to be able to confine the -fms-extensions (currently still, further restricted in the future) purely to the LinuxKPI USB drivers,
which I hope will make everyone happy without the need for further discussions.
I'll abandon this one.

I've just added another "first" use case (disable NOWITNESS), so it would be really nice to start getting this in.

I think the current version seems correct. Please go ahead, also take the PR, mark it for MFC15 at least (likely MFC14 as well) and close it once those are done. Please try to do the MFC15 timely. Thanks!

I believe this is a NOP but more correct.

In D59106#1355430, @vexeduxr wrote:

These two patches are precursors to adding support for the rtl8723bu. The main patch is mostly complete, but I'm still chipping away at cleaning it up. Adrian suggested we just get these out of the way now. The non cleaned up version can be found here: https://github.com/freebsd/freebsd-src/compare/main...VexedUXR:freebsd-src:rtwn

Both ifvlan.c and ifieee80211.c have a dedicated ioctl to call for this.
I think it might be time to make this something more generic in ifconfig then if we start growing a "parent interface: " printf line duplication.

Just leaving this here... I think we also need an uether.4 man page listing all the ue drivers and that the drivers can .Xr? @ziaee any opinion on that?

Just looking at the conversions this seems fine. Thank you for doing it! Is a huge help to cleanup the LinuxKPI bits.

Seems correct.

I'll accept this for the queue index problem; looking through the driver it feels like something else got convoluted but I could be wrong on that. @jsm and @adrian should probably cross-check that.

@emaste if I update the review for the missing call, do you think we could get this in for now? I can remove the comment as well if that's better. But I'd rather have this in and a bug fixed than drive it to perfection just yet (especially given the other open items in the stack).

In D58733#1349786, @markj wrote:

Oops, I forgot to submit, sorry.

I have no idea who's responsible for mthca(4). I have another change for that so any contacts would be good.

What's the KBI impact of this? Does it need a __FreeBSD_version bump then? Would it make sense to add it to the end?

In D58762#1348310, @emaste wrote:

I don't think we use large pages in linuxkpi. Therefore, this new function is curently a no-op.

Is there a way we can add either a compile-time error or KASSERT to ensure this remains the case?

No objections from me reading this. Wait what others are saying.

For what it's there it is fine.

I am splitting it up into fwget and the shell script so I can MFC fwget quickly more easily) and am committing this.
Sorry it fell through the cracks after your last update.

Unless there will be objections I'll put this in by Tuesday evening.

We have a bug report for this problem now (this review seems to solve it).
Here's the end of the thread on current: https://lists.freebsd.org/archives/freebsd-current/2026-July/010533.html

Update linux_free_pages() as suggested by @dumbbell.

In D58320#1341094, @dumbbell wrote:

I made an inline comment in linux_free_page(): there is a refcounting issue vs. the call to lkpi_page_unset_vm_page().

Beside this issue, I also made the following change to the i915 DRM driver which manipulates vm_page_t directly:

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2d94542f4d..58f64e9c0e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -171,14 +171,21 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
 		if (vm_object_set_memattr(vmobj, VM_MEMATTR_WRITE_COMBINING) != KERN_SUCCESS) {
 #if __FreeBSD_version >= 1500038
 			struct pctrie_iter pages;
-			vm_page_t page;
+			struct vm_page *m;
 
 			vm_page_iter_init(&pages, vmobj);
-			VM_RADIX_FORALL(page, &pages)
+			VM_RADIX_FORALL(m, &pages)
 #else
-			for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page))
+			for (vm_page_t m = vm_page_find_least(vmobj, 0); m != NULL; m = vm_page_next(m))
 #endif
-				pmap_page_set_memattr(page, VM_MEMATTR_WRITE_COMBINING);
+			{
+#ifdef PAGE_IS_LKPI_PAGE
+				struct page *page;
+				page = lkpi_vm_page_to_page(m);
+				lkpi_page_set_vm_page(page, m);
+#endif
+				pmap_page_set_memattr(m, VM_MEMATTR_WRITE_COMBINING);
+			}
 		}
 		VM_OBJECT_WUNLOCK(vmobj);
 	}

Do you think it's fine?

In D58320#1341094, @dumbbell wrote:

I made an inline comment in linux_free_page(): there is a refcounting issue vs. the call to lkpi_page_unset_vm_page().

Beside this issue, I also made the following change to the i915 DRM driver which manipulates vm_page_t directly:

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2d94542f4d..58f64e9c0e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -171,14 +171,21 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
 		if (vm_object_set_memattr(vmobj, VM_MEMATTR_WRITE_COMBINING) != KERN_SUCCESS) {
 #if __FreeBSD_version >= 1500038
 			struct pctrie_iter pages;
-			vm_page_t page;
+			struct vm_page *m;
 
 			vm_page_iter_init(&pages, vmobj);
-			VM_RADIX_FORALL(page, &pages)
+			VM_RADIX_FORALL(m, &pages)
 #else
-			for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page))
+			for (vm_page_t m = vm_page_find_least(vmobj, 0); m != NULL; m = vm_page_next(m))
 #endif
-				pmap_page_set_memattr(page, VM_MEMATTR_WRITE_COMBINING);
+			{
+#ifdef PAGE_IS_LKPI_PAGE
+				struct page *page;
+				page = lkpi_vm_page_to_page(m);
+				lkpi_page_set_vm_page(page, m);
+#endif
+				pmap_page_set_memattr(m, VM_MEMATTR_WRITE_COMBINING);
+			}
 		}
 		VM_OBJECT_WUNLOCK(vmobj);
 	}

Do you think it's fine?

In D55035#1341066, @aokblast wrote:

In D55035#1341051, @bz wrote:

Thanks for the comment; I have a way larger branch I think than what is in review. Do you want to have a look at the entire bits? I'd be thrilled if someone will review them :) and more than happy to extract the next days.

Do you mean https://reviews.freebsd.org/D54987? I was typing something while you leave your comment:)

In D58448#1341087, @ngie wrote:

In D58448#1340980, @bz wrote:

The module is not built at all so I wonder if you actually built it with mfsbsd.

I have other outstanding diffs on a branch which are required to get brcm to build/install: https://github.com/ngie-eign/freebsd-src/tree/brcm-polish . I'm trying to get a working driver on my mid-2010s MacBooks.

Thanks for the comment; I have a way larger branch I think than what is in review. Do you want to have a look at the entire bits? I'd be thrilled if someone will review them :) and more than happy to extract the next days.

The fact that there was a different behaviour with the extra bool means there was a reason for this.
We cannot unconditionally clear this and change behaviour as we still support Linux 6.1-lts drm-kmod and others.
This will need more careful investigation.

I would say "NO". The idea is to keep the #ifdef portion minimal as most of the differences will have to be upstreamed one day. Keeping the #ifdef away from the next statement makes merging easier.

The module is not built at all so I wonder if you actually built it with mfsbsd.