sysutils/cfengine328: Add new port
Add the latest cfengine to the ports collection.
Update the sysutils/cfengine metaport to point to the new port. It
becomes default.
sysutils/cfengine-masterfiles328: Add new port
Add the latest cfengine to the ports collection.
Update the sysutils/cfengine-masterfiles metaport to point to the new
port. It becomes default.
pkg: Add -j and -r options
This allows pkg(7) to be used to bootstrap a jail or chroot, and to
recognize the -j and -r options and pass them through to pkg(8) if
already bootstrapped.
Note that this does not address the issue of repository keys. If using
a signed package repository, you will still need to copy /usr/share/keys
into the target environment before or after bootstrapping, or pkg will
be unable to verify package signatures.
MFC after: 1 week
Reviewed by: imp, bapt
Differential Revision: https://reviews.freebsd.org/D58165
mt76: further adjust debugfs compile time options
The debugfs options between the various modules (core and chipsets)
are not 100% de-coupled. This means we may run into unresolveable
symbols at load time of the modules if we enable certain options
generally or for core but not for the chipset.
For now: always build the core module with debugfs support.
Migrate the CONFIG_MAC80211_DEBUGFS flag into the Makefile of each
chipset so we can individually turn it on.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: lkpi_80211_txq_tx_one() only pass sta if added to drv
If we are doing a direct (*tx) downcall, only pass sta as meta data
if it was added to the driver (via the state machine). This prevents
us passing a sta not known to the driver leading to possible follow-up
complications/errors. This will usually happen if (a) we are doing
software scanning, or (b) if net80211 decides to change the ni from
under us and sends a packet with the new ni.
Adjust a debug statement before to also have the added_to_drv field
in it to ease debugging.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: fix lkpi_pci_get_device() reference counting on device
In case we are passed an "odev" (a device to start the search from),
that device would have an extra reference. The best way to illustrate
this is to look at for_each_pci_dev(), which will return one device
after the other. Upon first return we return a pdev with a reference.
That pdev is then passed in as odev on the next call. If we do not
clear the reference it will be leaked.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Fixes: 910cf345d0ee9 ("LinuxKPI: pci: implement ...")
Reviewed by: dumbbell, emaste
Differential Revision: https://reviews.freebsd.org/D57428
LinuxKPI: pci detach: implement a proper detach (release) path
There are two paths in the LinuxKPI PCI code to instantiate a "pdev"
(LinuxKPI pci_dev). One is using the FreeBSD bus framework and the
pdev will be the softc.
This commit starts cleaning up the detach path for just that case
to the best possible.
So far we did a lot of the work in linux_pci_detach_device(), which is
the internal handler of the detach function and little in the
(*release) callback (devres cleanup only).
The problem with that is, that we tear down resources which later in the
devres cleanup are needed. With them not being there anymore we panic, e.g.,
in lkpi_dma_unmap < lkpi_dmam_free_coherent < lkpi_devres_release_free_list.
The solution is to migrate most of the cleanup work into the (*release)
callback, which will automatically be called when the device (kobj) reference
drops to zero. The only work which should be done immediately is to let the
dirver do its cleanup; this has to happen before we try to teardown the
resources, but also we do want this to happen when detach is called
[23 lines not shown]
LinuxKPI: add system_percpu_wq
In Linux v6.17 system_wq was replaced (renamed to) system_percpu_wq,
with the old name still present.
We just alias system_percpu_wq to linux_system_short_wq like we do
for system_wq to keep both around for the forseeable future.
Note: the original system_wq was a per-cpu queue upstream as well
based on my understanding but we never implemented it as such.
That means we are still lacking a per-cpu implementation for
system_percpu_wq but at least we do not change the status-quo
of the LinuxKPI implementation with this.
Note2: we should add a check somewhere for LINUXKPI_VESION >=
61700 to print a warning if anyone still uses the system_wq
to detect any possible sami-native or out-of-tree drivers
relying on this and not properly updating.
[4 lines not shown]
