@emaste had a comment for you here. Can you update?

Rebase and this time actually update the review.

Apply fixes as pointed out. Thanks a lot for the review!

I have https://reviews.freebsd.org/D58169 open in case you want to see a pr_debug() example file with a lot more stubbed only functions.

Modulo LINT and LKPI_PAGE changes for older branches: master, 6.12-lts, 6.6-lts and 6.1-lts seemed fine

The duplicate was suppoed to be a pm_runtime_resume(); re-add.

Remove duplicate pm_runtime_put().

In D47379#1333680, @jbo wrote:

I just came across this diff. Apparently no activity since November 2024 - is this still relevant?

I am currently trying to compile as many drm-kmod branches on main as I can to make sure this does not break any.

P2S: also pr_debug("TODO: %s\n", func); for all the empty functions?

Post-commit review: the upstream file is MIT. We may consider just pulling that in (in parts) and reflect that in the license?

https://reviews.freebsd.org/D58104 will do the general bits for us. For the others none of the HW I still have will see an update anymore; only powered off and gone.

Anyone? Otherwise I'll commit this the next days.

Anyone? Otherwise I'll commit this the next days.

Anyone? Otherwise I'll commit this the next days.

I'll be happy if this lands as I'll finally be able to ditch (updated versions) of https://reviews.freebsd.org/D23145 out of my tree. Thank you!

In D58020#1330655, @adrian wrote:

ugh ok why's do_ht being set when there's no htcap/htinfo fields.

OH, hilarious, it's because you have VHT parameters but not HT parameters? That's problematic. Would you mind doing an "ifconfig -v wlan0 list scan" to capture what's being seen in the scan, find the entry that has VHT parameters and not HT parameters, and including it in here?

Would you mind adding a note what this will be good for in the future to the proposed commit message?

In D57762#1327751, @nagymas_gmail.com wrote:

I personally I would go with the simpler solution calling IEEE80211_IS_CHAN_VHTxxx macros already combines mode and width.

static const char *
net80211_get_chanmode_descr(const struct ieee80211_channel *c)
{

...
<VHT*>

In D56026#1325514, @obiwac wrote:

But what triggers the actual RFKILL hardware level disconnect? The same button press?

Nothing at the moment. we need a generic rfkill interface on freebsd; see D55265 for a little discussion on this

And can software (e.g., a widget) undo this or does one have to press the button again?

That's I think the end goal. Pressing this button just reports this to the desktop environment or some other user program, and it is responsible for actually rfkill'ing or not.

Forgive my ignorance but what exactly is this doing from a high level perspective not from the functional change about simulating the key press.
If I had to try: it takes the key press from the function button and sends a simulated key press to evdev from whatever X thingy to consume?

I like it and I love your detailed explanation!

@jhb am I (at least logic wise) good; man page we can clarify; I would love to get this out of my tree :)

If we do it then let us do better than AI and also document 80P80.

Ah, thanks for the explanation; wasn't clear that the same upstream commit also removed the file.
I believe external drm-kmod starts with 4.16 (not that we still support it).

The actual change was in 6.17; comments etc got updated for 6.18.

Abandon in favour of D57730 which is the exact same functional change but with a different comment message and comments.

Anyone any suggestions/comments on where to place these bits?

Properly indent comment and put it under the first label.

Anyone on this one?