User Details
- User Since
- Aug 29 2014, 12:11 PM (505 w, 6 d)
Tue, May 7
Should be fine; otherwise we'll deal with it as needed; do we know what mii_mpd_rev 7 is/was?
Sat, May 4
Fri, May 3
I'll reply here rather than the email--one well two major concerns (and I didn't mean legal) with the "can of worms" are:
(1) You are adding VRRP version 3... someone will come next and ask "and what about VRRP version 2"?
(2) We are adding to but not fixing the problem of the conflicting version number; it's easy to say I can add v3 but ... see (1).
Thu, May 2
Is there any implementation for these new functions, i.e., something which updates the drivers or is this just dead wood swimming down the river?
Would be great if the commit message would mention IEEE80211_CRYPTO_MODULE() somehow so one can find this in the future more easily.
In theory I am fine with this once these modules actually exist. I would also fantastic if the annoying printf instead of loading them could be fixed. reverse order.
Most of the comments were marked "done" and changed some since the original comments but the "RSN AKM suite element" table still has a mix of #define suffixes and comments for the "256" cases? Is this on purpose for some reason beyond this file? At least the TDLS case I had originally asked for _256? I just wonder why not? Can you explain?
This still has changes not marked "done".
Is there a change in the stack which does change the drivers to use this?
You didn't answer my previous question?
Can you please update the commit message? Apart from that it seems fine-ish with what cc@ said.
Tue, Apr 30
fold the three $MKDIR into one as suggested by @jrm.
Sun, Apr 28
Rebuild all the wifi-firmware flavors from scripts, this time hopefully with lower case names.
Update one more time to (hopefully) have all ports/pkackage flavors in lower case.
Also the new files are all script generated.
The scripts will be pushed to github with the next update there before going into main.
Sat, Apr 27
Fri, Apr 26
Otherwise I am really happy to see the linuxkpi_*.c file in common/src given I keep meaning to say that we should rename them all away from linux_?
I can do the rename.
Thu, Apr 25
What is going to happen to sys/modules/linuxkpi_hdmi then? They both compile in linux_hdmi.c
Why not? Is that not just passing the result back to the caller at the end of the shell function?
Given I have to ask this, I am probably not the right one to review...
Ports change part I here: https://reviews.freebsd.org/D44945
- Fix the two QCA entries which depend on two packages
- Update the comments on Intel iwlwifi removing some initial logic in favor of a script (it is currently two but I'll try to clean it up and add it either to src or ports to generate both the fwget case pattern and the ports flavor->firmware files list generation)
Is is likely mis-sorted in the stack as this should go after D44922?
Are you going to change the few drivers which need change to get rid of the public exposure as well? Otherwise this is a dead code before added.
I haven't reviewed the actual function changes yet; just scrolled through
Update to fine(r) grained flavored packages.
Wed, Apr 24
Tue, Apr 23
Mon, Apr 22
@cc Adding LOCK asserts is a very good idea; not all the functions need them if I remember correctly. Should I really add it to this "fix" or should I do a separate full pass on the linux_80211_macops.c file?
Move the KASSERT/lsta assignment back to its original place;
I think the idea was to catch that state earlier on before more changes happen which could mask that situation but this change is really about the 2nd half so focus on that.
I wonder if that'll support a lot more than just AX210?
@emaste have you been running with this change the last months?
% grep -r THIS_MODULE sys/contrib/dev | wc -l
87
% grep -r THIS_MODULE sys/contrib/dev | grep -v '\.owner =' | wc -l
9
% grep -r THIS_MODULE sys/contrib/dev | grep -v '\.owner ='
sys/contrib/dev/acpica/changes.txt:any "_THIS_MODULE defined but not used" messages.
sys/contrib/dev/iwlwifi/iwl-drv.c: return request_firmware_nowait(THIS_MODULE, 1, drv->firmware_name,
sys/contrib/dev/iwlwifi/mvm/ops.c: module_put(THIS_MODULE);
sys/contrib/dev/iwlwifi/mvm/ops.c: if (!try_module_get(THIS_MODULE)) {
sys/contrib/dev/iwlwifi/mvm/ops.c: module_put(THIS_MODULE);
sys/contrib/dev/iwlwifi/pcie/trans.c: module_put(THIS_MODULE);
sys/contrib/dev/iwlwifi/pcie/trans.c: if (!try_module_get(THIS_MODULE)) {
sys/contrib/dev/iwlwifi/pcie/trans.c: module_put(THIS_MODULE);
sys/contrib/dev/rtw88/main.c: ret = request_firmware_nowait(THIS_MODULE, true, fw_name, rtwdev->dev,Fri, Apr 19
Thanks. If no one complains the next days I'll put this in.
Can we shorten hardware/software to hw/sw?
Nice tracking down.
Is there a PR for this somewhere we need to reference?
Wed, Apr 17
Mon, Apr 15
Any comments on this?
@emaste it seems most attributes in cdef.h have the __x__ instea dof just x. This seems to work with gcc as well for as much as I could test. It seems up-to gcc14-devel non of our gccs recognizes the counter_by in either spelling.
Sun, Apr 14
Does this give any information pciconf -l would not already give? I would rather we'd improve our tooling than use a sysctl for that? I'd almost want something like ifconfig -g bridge -l in devctl or somewhere appropriate?
@emaste is the logic correct now?