User Details
- User Since
- Nov 23 2015, 12:29 AM (441 w, 4 d)
Tue, May 7
update based on bz@ comments
Mon, May 6
rebase before scrutiny check
Thu, May 2
Individual accept.
Wed, May 1
Tue, Apr 30
Just some minor issues.
Mon, Apr 29
If you have a plan to figure out TEXT_SET(crypto##_set, name##_modevent) and TEXT_SET(ratectl##_set, alg##_modevent), I have no problem with this patch.
Cautious individual accept.
Fri, Apr 26
I don't get it why this change made a difference in your test. Is it because of the bug I pointed in TEXT_SET ?
LGTM
The rest looks good to me.
Wed, Apr 24
Also do you have any plan to update the man page regarding the new field ic_sw_cryptocaps besides ic_cryptocaps ?
Also please update the Summary section in this review, i.e. the mentioned new field ic_wpa_cryptocaps is actually the ic_sw_cryptocaps in the code change.
LGTM
I am intending to give approval, but I am afraid of missing the new response to my review comment for the code comment update. So let's be patient. :)
Tue, Apr 23
Wed, Apr 17
Mar 22 2024
During association with the AP, sw/hw keys (indexes) are set. And before tx, the hw key is selected by sw key's index returned from ieee80211_crypto_get_txkey(), same way as without LKPI_80211_HW_CRYPTO.
Mar 21 2024
Mar 15 2024
I am working the "multi-key" support these days on top of D43634(this patch) and D43648, but it turns out this patch is causing more trouble than it is trying to solve.
In fact, it caused this "Abort trap" from the console and then my VM is shutdown silently. The kernel is main with LKPI_80211_HW_CRYPTO on top of this patch.
Mar 14 2024
code update according to comments
Mar 7 2024
Mar 6 2024
I think LKPI_80211_LHW_LOCK_ASSERT can help remind us of such LKPI_80211_LHW_LOCK requirement for lkpi_80211_mo_* functions.
Mar 5 2024
Mar 4 2024
Mar 1 2024
The ktls draws my attention. Hope you add reviewers.
Feb 29 2024
Shall correct the typo first before committing.
Feb 26 2024
Please add PR: 277095 in the summary, as this patch also fixes that.
Feb 23 2024
Feb 22 2024
Good catch! Always keep an eye on the cubic_data->t_epoch refresh.
Feb 21 2024
Feb 20 2024
Initial test shows this error when I changed the channel number in AP. Looks like a reproduce of PR 277100 without LKPI_80211_HW_CRYPTO enabled, or a separate issue?
Feb 19 2024
Feb 16 2024
Feb 13 2024
Feb 12 2024
Feb 9 2024
Given D43389 is the FIRST of a series, is this the SECOND one or is there any dependence? Please help clarify.
Remove Copyright headnote and myself from if_iwn.c, as noted in review.
With D43770 in mind, I think we can go ahead and commit this change.
Feb 7 2024
add Copyright in if_iwn.c
Add missing update in if_iwn.c and keep IEEE80211_HTINFO_OPMODE_S from the kernel build lesson.
Feb 6 2024
I have created D43770 to clarify/illustrate my idea.
Feb 5 2024
Feb 2 2024
I meant this patch fixes the wrong/old values here, in the LinuxKPI. For example, IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED should have a value 3, not the old 0x02.
Feb 1 2024
Good catch!
Jan 31 2024
This patch also fixes the wrong/old values used in sys/compat/linuxkpi/common/include/linux/ieee80211.h. thanks
Jan 29 2024
I see two "MFC after" in the summary section, and the summary section seems to contain two parts that it looks you are going to split this patch into two when you MFC it. Am I understanding correctly? Are you going to manually MFC the two parts?
Jan 24 2024
Jan 23 2024
By the way, I forgot to ask, is it also helpful to add IEEE80211_LOCK_ASSERT in lkpi_iv_update_bss()?
Jan 22 2024
Jan 19 2024
Jan 17 2024
Jan 10 2024
I think this patch as a fix is targeting 271979#c28. If I am right, I will use the reproduce method to test this patch. thanks
Jan 8 2024
Good catch!
Jan 5 2024
Jan 3 2024
Jan 2 2024
Thanks for reminding me this so that I can make the right change of 93b7818226cf in MFC.
Dec 21 2023
Thanks for the reminder.
Dec 19 2023
Looks good to me now. Thanks for the update.
Dec 18 2023
This is committed in https://cgit.freebsd.org/src/commit/?id=93b7818226cf5270646725805b4a8c17a1ad3761