@manu if you are (still) happy with the updated versions, the ports/packages are coming as well (see D44945).
I think we are getting more "stable" now in between supported versions and "noise".
Also while this adds forward matching at least for Intel (the firmware flavor for sc does not exist as the firmware is not public yet), shipping it like this means that after a release we can add the firmware package and the driver and fwget will already support it.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Fri, May 17
Thu, May 16
Re-genertae them based on updated scripts.
Update firmware to 20240513 (I have locally updated the commit message).
Also sort out some iwlwifi bits (we try to find the best supported
firmware version if the latest does not exist; may not have made a difference
to the lastet review version?)
Wed, May 15
In D45205#1031216, @manu wrote:The main reason for this change is that now struct mtx and spinlock_t are 100% interchangeable in code which is a first step to share structures between linuxkpi driver and native ones.
Funny enough we have no way to destroy this; thankfully witness doesn't track it...
Tue, May 14
Duplicate the implmentation and add a comment for kvmalloc/kvfree in slab.h
In D45181#1030842, @emaste wrote:Do we have our approach documented somewhere? This looks acceptable given that we already #define kvfree(arg) kfree(arg) but it would be good to have that mentioned somewhere.
Mon, May 13
Apart from the () I am fine. if @jhb doesn't commit it I can.
I'll add the back reference to the PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247545
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
In D44774#1027883, @kp wrote:In D44774#1027778, @bz wrote: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"?Right now the answer is "We don't have v2, and we have no plans to support v2 either.".
If someone does ever want to add VRRPv2 support they get to deal with the fallout. I'm not inclined to copy/paste chunks of code on the off chance that maybe it'll be slightly helpful in the future.
We're not making choices that'll make that impossible to do in the future.(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).
As in carpv3? That seems entirely unlikely to ever happen, given that carp's entire reason for existing is now moot.
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)
In D44918#1024641, @manu wrote:Looks better now, thanks a lot.
In D44918#1024544, @imp wrote:I don't suppose that yhese could be generated automatically? It's a huge table to maintain by hand...
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
In D44918#1024287, @manu wrote:wifi-firmware-iwlwifi-kmod doesn't seems to exists ?
Tue, Apr 23
In D44906#1023889, @markj wrote:In D44906#1023888, @bz wrote:In D44906#1023886, @emaste wrote:Should we change the in-kernel default as well? It will normally be overridden by the rc.conf setting so it doesn't have a practical impact but probably good for consistency.
Would NFS Root be affected by that? Hmm it's a tunable so less of a problem in case people do have trouble.
This is a server setting, so I wouldn't expect so.
In D44906#1023886, @emaste wrote:Should we change the in-kernel default as well? It will normally be overridden by the rc.conf setting so it doesn't have a practical impact but probably good for consistency.
Mon, Apr 22
In D44906#1023836, @rmacklem wrote:lgtm. I cannot recall if there is any man page change
needed for this?
@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.
In D43967#1023740, @emaste wrote:@bz I put this in my wipbsd tree on Feb 18, and I have been switching between that tree and main since then. I haven't observed any issue attributable to this change. I still do see one Invalid TXQ sometime in early boot.
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,
Apr 19 2024
In D44827#1023208, @adrian wrote:eg ath(4) would do something like:
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?