Before de8c0d15a64fa ("sound: Get rid of snd_clone and use
DEVFS_CDEVPRIV(9)"), sound(4) would create one device for each allocated
channel. The device names would be chosen from dsp_cdevs[], and created
with dsp_unit2name(). Additionally, dsp_cdevs[] was also used to match
these devices names, as well as OSSv4 aliases in dsp_clone().
Since sound(4) does not create separate devices for each channel
anymore, the meaning and use dsp_cdevs[] has changed. Part of it no
longer corresponds to devices at all, but instead is used to create
channel names, and another part is used to match only OSSv4 aliases in
dsp_clone().
To address this confusion, separate dsp_cdevs[] into a dsp_aliases[]
array, and move dsp_unit2name() to pcm/channel.c and rename it to
chn_mkname().
While here, get rid of the SND_DEV_DSPHW_* channel types, and simply use
the existing PCMDIR_* constants as the channel types. There is no need
to duplicate the same meaning twice.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47199
Needed by a follow-up patch, so that channels can be sorted properly.
This change does not affect the behavior of any subsystem.
While here, change to an enum.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47198
DSP_REGISTERED calls PCM_REGISTERED, and already contains all the checks
we are doing.
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47196
DSP_REGISTERED first checks if the softc is not null, through
PCM_REGISTERED, which in turn calls PCM_ALIVE, whereas PCM_DETACHING
accesses the softc flags directly.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D47195
The firmware may have unmasked pl011 interrupts. If we don't have a
device to handle one the kernel will print a spurious interrupt
warning. Rather than print the warning mask all interrupts until we
are ready to handle them.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D46863
This roughly corresponds to Linux 9d9e5347b035412daa844f884b94a05bac94f864
For FreeBSD this is currently not expected to cause any difference in
behavior because we do not have the MTP force smbus changes for modern
standby.
MFC after: 3 days
Sponsored by: BBOX.io
Under massive connection thrashing (web server restarting), we see
long periods where the web server blocks when enabling ktls offload
when NIC ktls offload is enabled.
It turns out the driver uses a single-threaded linux work queue to
serialize the commands that must be sent to the nic to allocate and
free tls resources. When freeing sessions, this work is handled
asynchronously. However, when allocating sessions, the work is handled
synchronously and the driver waits for the work to complete before
returning. When under massive connection thrashing, the work queue is
first filled by TLS sessions closing. Then when new sessions arrive,
the web server enables kTLS and blocks while the tens or hundreds of
thousands of sessions closes queued up are processed by the NIC.
Rather than using the work queue to open a TLS session on the NIC,
switch to doing the open directly. This allows use to cut in front of
all those sessions that are waiting to close, and minimize the amount
of time the web server blocks. The risk is that the NIC may be out of
resources because it has not processed all of those session frees. So
if we fail to open a session directly, we fall back to using the work
queue.
Differential Revision: https://reviews.freebsd.org/D47260
Sponsored by: Netflix
Reviewed by: kib
This fixes a clang 19 warning:
sys/dev/ath/ath_hal/ar9002/ar9285_btcoex.c:57:32: error: comparison of different enumeration types ('HAL_BOOL' and 'HAL_ANT_SETTING') [-Werror,-Wenum-compare]
57 | (AH5212(ah)->ah_diversity != HAL_ANT_VARIABLE)) {
| ~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~
The `ah_diversity` field of `struct ath_hal_5212` is of type `HAL_BOOL`,
not the enum type `HAL_ANT_SETTING`. In other code, `ah_diversity` is
set to `AH_TRUE` whenever the related field `ah_antControl` is set to
`HAL_ANT_VARIABLE`.
It is not entirely clear to me what the intended statement is here: the
test as it is written now compares the enum value 0 to `ah_diversity`,
so in effect it enables the following block whenever `ah_diversity` is
`AH_TRUE`. Write it like that, to avoid the compiler warning.
MFC after: 3 days
ACPI sleep states are only implemented on x86 systems, so having the
ACPI power button attempt to enter "S5" (or other state as configured
via the hw.acpi.power_button_state sysctl) is not useful.
On non-x86 systems, implement the power button with a call to
shutdown_nice(RB_POWEROFF)
to shut down the system.
Reviewed by: Andrew
Tested on: Graviton 2
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47094
Driver requests are done with stack allocated request. The request is
put on the tailq and then we msleep(9) until kernel process processes it.
If we timeout from this sleep, the kernel process may still read the
request from our stack, which may already be reused by some other code.
Make this sleep unbound and rely on the kernel process that does all its
I/O with timouts and will eventually wake us up.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D47179
Both conditions are the same, so the second one is unreachable.
PR: 229550
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: andreast, markj
Differential Revision: https://reviews.freebsd.org/D47167
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D47152
These malloc(9) calls are in contexts where sleeping is permitted.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, zlei, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46845
The current channel naming convention is:
pcmX:[virtual_]play|record:dspX.[v]p|rY
- pcmX and dspX share the same unit numbers
- "[v]p|r" gives us the same information as "[virtual_]play|record"
Remove the redundant information, so that the channel names become more
readable: dspX.[virtual_]play|record.Y
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46836
Currently we create and destroy channels with the following consistent
pattern:
- chn_init() -> pcm_chn_add()
- pcm_chn_remove() -> chn_kill()
Instead of calling two separate functions, merge pcm_chn_add() with
chn_init(), and pcm_chn_remove() with chn_kill().
Another benefit of this change is that we avoid the confusion caused by
having pcm_chn_add(), as well as pcm_addchan().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D46835
feeder_rate_min functions as the lower boundary.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46834
Instead of checking the value of "ret" multiple times, just set a goto
label and jump there immediately in case of an error.
While here, remove a redundant assignment to "d".
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46833
No longer used.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46522
If we do not enter dummy_chan_trigger() before detaching, we'll get a
use-after-free since the callout(9) callback might be called after
having been detached.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46715
feeder_register() is currently a SYSINIT in order to create the root
feeder, which happens only when feedercnt is 0. Separating the root
feeder registration makes the code more readable.
No functional change intended.
While here, fix some style errors.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, zlei, markj
Differential Revision: https://reviews.freebsd.org/D46821
There is no reason to initialize global variables in feeder_register(),
as these variables are unrelated to what the function does. Instead,
initialize them during sound(4) load.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D46749
Currently it is possible to assign a unit number that already exists.
Suppose the following channel list:
[vp2]
If we create 3 channels, we'll end up with the following list:
[vp0, vp1, vp2, vp2]
This happens because chn_init() does not check if the unit number we are
assigning already exists. While fixing this is trivial when the channel
list is sorted in ascending order, it is way more involved when sorted
in descending order. Even though sorting the list in descending order
would require deliberately modifying pcm_chn_add(), and is most likely
not going to happen, make the mechanism more robust by using a unr(9)
allocator for each channel type.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46680
Refactor CHN_INSERT_SORT() to also take into account the unit number of
each channel, while still prioritizing the type, to make the channel
list easier to work with.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46549
Simplify logic to execute the following algorithm:
1. Search for a free (i.e not busy) channel and return successfully.
2. If no channel was found, either return an ENOTSUP if no VCHAN can be
created (disabled or we reached the limit), or create one more VCHAN
and scan for it again.
3. If the second scan failed again, return EBUSY.
This patch also solves a bug where we'd end up in an infinite loop,
calling vchan_setnew() with the same `newcnt` value indefinitely, after
the following scenario:
1. Plug device.
2. Spawn X channels.
3. Kill all channels except _last_ opened.
4. Clean up all unused VCHANs.
5. Spawn X+1 channels.
6. Infinite loop in pcm_chnalloc().
I am not exactly sure which part of pcm_chnalloc() caused this bug, but
the patch fixes it at least...
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46548
The VCHAN count is checked in vchan_setnew(), and there is no reason to
cap the hardware channels in the first place.
This is part of a series of follow-up patches.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46521
This check is not really useful, and can in fact break things, if
sysctl_dev_pcm_vchans() calls vchan_setnew() with a value that will not
satisfy the KASSERT condition.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D46545
A hardware IPv6 server needs 2 consecutive stids (server tids) starting
from a 2-aligned stid whereas an IPv4 server needs only 1 stid without
any constraint. The allocator used to grab the first free stid(s) for
both but this can fragment the stid space leaving nothing suitable for
IPv6 even when lots of stids are available. Change the allocator to
prefer stids for IPv4 from the ones that cannot be used for IPv6.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D47042
Previously this just dereferenced NULL qp pointers and panicked.
Instead, use a shared lock on the connection lock to protect access to
the qp pointers and allocate a request. If the controller is not
associated, fail the request with ECONNABORTED.
Possibly this should be honoring kern.nvmf.fail_on_disconnection and
block waiting for a reconnect request while disconnected if that
tunable is false.
Reported by: Suhas Lokesha <suhas@chelsio.com>
Sponsored by: Chelsio Communications
The hash filter table order in the GMAC matches the order of the top
bit of the hashed destination address. See the description of
GMAC_MAC_Hash_table_Reg0 in RK3568 TRM part 2, section 20.4.2.
PR: 282074
Reviewed by: manu
MFC after: 7 days
Differential Revision: https://reviews.freebsd.org/D47115
Add a sysctl to artificially fail the reset to test the failure to reset
hardware code path. While there are many ways that reset can fail, this
provides an adequate way that similates enough of the failures well
enough to shake out this failure path.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28584
ifmedia_add() allocates an ifmedia_entry during ena_attach.
Current code doesn't release this memory during ena_detach()
This commit calls ifmedia_removeall() to properly free the
allocated memory during ena_detach().
Also, in case ena_attach fails, we need to detach ifmedia
which was allocated within ena_setup_ifnet().
This bug was first described in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278100
Reviewed by: zlei
Approved by: cperciva (mentor)
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
Large LLQ depth size is currently calculated by dividing the maximum
possible size of LLQ by 2.
In newer paltforms, starting from r8g the size of BAR2,
which contains LLQ, will be increased, and the maximum depth of
wide LLQ will be set according to a value set by the device, instead of
hardcoded division by 2.
The new value will be stored by the device in max_wide_llq_depth field
for drivers that expose ENA_ADMIN_LLQ_FEATURE_VERSION_1 or higher to
the device.
There is an assumption that max_llq_depth >= max_wide_llq_depth, since
they both use the same bar, and if it is possible to have a wide LLQ
of size max_wide_llq_depth, it is possible to have a normal LLQ of the
same size, since it will occupy half of the space.
Also moved the large LLQ case calculation of max_tx_queue_size
before its rounddown.
Approved by: cperciva (mentor)
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
