Reflect @markj's comment

@andy_omniosce.org Hi. I am wondering whether you are preparing to upstream your 1.0 implementation? If this happens after few years. I think I might want to merge my implementation first. Thanks!

In D60959#1397868, @kib wrote:

Why did you left trywrlock() out of this change? POSIX allows both wrlock() and trywrlock() to return EDEADLK, and our man page notes the error for both functions. So if making one return the error, I do not see why not making another to behave identically.

Update

In D60832#1397713, @aokblast wrote:

In D60832#1397587, @markj wrote:

In D60832#1397040, @kib wrote:

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

I still do not understand why should it not. Using kinfo would make the test more precise IMO, But I do not intend to block this change.

I also do not really understand. It seems fine to use kinfo. See tests/sys/kern/procdesc.c:wait_for_naptime() for an example. It is just an alternative method to avoid polling while you are waiting for thr_fun() to wake up.

Wouldn't wait_for_naptime still poll on something?

In D60959#1397868, @kib wrote:

Why did you left trywrlock() out of this change? POSIX allows both wrlock() and trywrlock() to return EDEADLK, and our man page notes the error for both functions. So if making one return the error, I do not see why not making another to behave identically.

In D60832#1397587, @markj wrote:

In D60832#1397040, @kib wrote:

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

I still do not understand why should it not. Using kinfo would make the test more precise IMO, But I do not intend to block this change.

I also do not really understand. It seems fine to use kinfo. See tests/sys/kern/procdesc.c:wait_for_naptime() for an example. It is just an alternative method to avoid polling while you are waiting for thr_fun() to wake up.

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

LG for me

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

In D60711#1392531, @kib wrote:

In fact, if the loop exited due to TID_TERMINATED, then ret does not matter.

In D60717#1393031, @kib wrote:

The change now takes the thread list write lock unconditionally. Before the change, it only happen if the thread is not referenced. Did you checked that this is innocent?

Reflect @kib's comment

LGTM!

Add wulf as a reviewer and I will start to review this on this weekend.

I would say that epp is not a thing that should be control by powerd. I have some discussion with @olce previously.

I tink we still need to check this flag in usb_handle_remote_wakeup like (is_on && bsd_remote)

In D59190#1386946, @kilikmatej_protonmail.com wrote:

Hello,
I backported this commit (102adf88e6e8) to FreeBSD 15.1-RELEASE and it works: the render node (226:128, renderD128) is now visible in linsysfs and Linux Mesa uses the GPU under the Linuxulator.
Details in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278363

Would it be possible to MFC this to stable/15? Thank you!

Minor fixes

LGTM!

Reflect kib@'s comment

LGTM to me. But I think we need feedback from doc group

In D57381#1374059, @markj wrote:

@zishun.yi.dev_gmail.com @aokblast hi, I wonder if anything is blocking landing that LLVM PR upstream? That's the only thing preventing us from committing KASAN support for riscv.

Reflect comment from brooks@

In D57194#1363739, @bz wrote:

In D57194#1311278, @aokblast wrote:

In D57194#1311193, @bz wrote:

Fantasic! You are solving one of my local TODOs :)

Can you make all these USB changes belonging together a stack in Phabricator?
It's a bit hard to grasp which all are there or belong together.
I'd be happy to at least scroll through them even if I cannot review them all in detail most likely.

% git show 9dbb804f59533d7d539200367394e4013714b02c
commit 9dbb804f59533d7d539200367394e4013714b02c
Author:     Bjoern A. Zeeb <bz@FreeBSD.org>
AuthorDate: Mon Feb 9 01:11:41 2026 +0000
Commit:     Bjoern A. Zeeb <bz@FreeBSD.org>
CommitDate: Sun May 24 15:53:58 2026 +0000

    TODO usb: add USB_SPEED_SUPER_PLUS to enum usb_dev_speed
    
    While nothing in our native USB stack uses the USB 3.1 "SUPERSPEED+"
    setting yet, a LinuxKPI based wireless driver does check for it.
    
    TODO: The arrays in usbd_get_std_packet_size() likely need to be updated.
    
    Sponsored by:   The FreeBSD Foundation
    MFC after:      3 days

diff --git sys/dev/usb/usb.h sys/dev/usb/usb.h
index 3e972f876c6a..f07eb9adfe40 100644
--- sys/dev/usb/usb.h
+++ sys/dev/usb/usb.h
@@ -755,8 +755,9 @@ enum usb_dev_speed {
        USB_SPEED_FULL,
        USB_SPEED_HIGH,
        USB_SPEED_SUPER,
+       USB_SPEED_SUPER_PLUS,
 };
-#define        USB_SPEED_MAX   (USB_SPEED_SUPER+1)
+#define        USB_SPEED_MAX   (USB_SPEED_SUPER_PLUS+1)
 
 /*
  * The "USB_REV" macros defines all the supported USB revisions.

Hi bz@, Thanks for your reply. I might not know what is the correct way to do so. But I think in the stack tab, all of my patches can be seen in here.

I do not see any changes to usb_transfer.c in the stack.
That likely means usbd_get_std_packet_size() array accesses may get out of bounds accesses?
If I am right, this should be addressed somewhere before this or other bits go in.

Expose pcidev/drm

LG for implementation part.

In D59186#1357916, @kevans wrote:

CC releng because this should go into 14.5, IMO, which might mean an expedited MFC. I think this is reasonably safe.