The sample rate selection of snd_uaudio(4) at runtime was implicitly
relying on a specific order in the device config list. In case a default
was set through the hw.usb.uaudio.default_rate sysctl tunable, commit
42fdcd9fd917 removed a duplicate sample rate entry from that list, which
inadvertently broke sample rate selection at runtime. Implement sample
rate selection in a way that works for any order in the device config
list.
Reported by: Lexi Winter <lexi@le-fay.org>
MFC after: 1 week
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D44051
(cherry picked from commit a9341f0f0ae01b4d249dbf3bacfa420152c46aef)
Fixing the error messages when detaching the mana gdma devices
showed in dmesg: "Device leaked memory resources".
Reported by: NetApp
MFC after: 3 days
Sponsored by: Microsoft
(cherry picked from commit 47e99e5bc5bcfa621fe6a3e62386f227c47e8cff)
snd_uaudio(4) selects the first maching rate/channel/bit/format/buffer
configuration for use during attach, even though it will print the rest
of the supported configurations detected. To make this clear, mark the
selected playback and recording configurations with a "selected" string.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D43766
(cherry picked from commit f60e99f45e8197de2bc0970c7dd7f87148fdaf30)
Let the USB audio descriptor iteration detect configurations with more
channels and larger sample size, even when the following global sysctl
tunables are set to a lower value:
hw.usb.uaudio.default_channels hw.usb.uaudio.default_bits
This improves utility and is closer to the meaning of default.
Also, do not create duplicate sample rate entries.
MFC after: 2 weeks
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D43679
(cherry picked from commit 42fdcd9fd917764d84edcc43e252a90cade78f80)
Adapt the length of the driver side audio buffer to the USB transfer
interval, which is adjustable through the buffer_ms tunable. This
eliminates unnecessary latency in USB audio playback.
To reduce power consumption caused by frequent CPU wakeups, increase the
default buffer_ms value to 4ms. In combination with adaptive buffer
length, this still results in less roundtrip latency compared to the
previous 2ms default.
Extend the buffer_ms value range to 1ms for low latency applications.
MFC after: 2 weeks
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D41942
(cherry picked from commit b2e97edffdab6ad1e9103a6bbe90300d78a961ed)
The goal of reserving firmware-assigned resources is to ensure that
"wildcard" resource allocation requests will not claim an address
range that is actually in use even if no attached driver is actively
using that range. However, the current approach can break in some
cases.
In particular, ACPI can enumerate devices behind PCI bridges that
don't show up in a normal PCI scan, but those device_t objects can end
up as direct children of acpi0. Reserving resources for those devices
directly from acpi0 ends up conflicting with later attempts to reserve
the PCI bridge windows.
As a workaround, defer reserving unclaimed resources until after the
initial probe and attach scan. Eventually this pass of reserving
unclaimed resources can be moved earlier, but it requires changes to
other drivers in the tree to permit enumerating devices and reserving
firmware-assigned resources in a depth-first traversal before
attaching devices whose drivers request wildcard allocations.
PR: 272507
Reported by: Justin Tocci <justin@tocci.org>
Reported by: john@feith.com, many others
Tested by: Oleg Sidorkin <osidorkin@gmail.com>, dch
(cherry picked from commit f2fcb68074a51a8b399dc80d4c03fbe98a0ab92c)
While we only support 4-byte registers in the uart code the physical
access may be to an 8-byte register. Support this as an option on
non-i386. On i386 we lack the needed 8-byte bus_space functions.
ACPI has an option for 8-byte register io width, and FDT can be given
any size. Support these sizes, even if we don't expect to see hardware
with an 8-byte io width.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43374
(cherry picked from commit a9fc9d6d15f006feb6d7ddb036e020d5f9d19fce)
Tell bus_dma(9) which NUMA domain the PCI driver is closest to so it
can allocate memory from there when possible.
Reviewed by: markj, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D42186
(cherry picked from commit 7098f3c7569c21ecdfc990772e96a416f1a94eee)
Some platforms require an adjustment of the ethernet hearders. Rather
than make this be on __NO_STRICT_ALIGNMENT being defined, define
VTNET_ETHER_ALIGN to be either 0 or ETHER_ALIGN (aka 2). Add a test to
the if statements to only do them when != 0. This eliminates the #ifdef
sprinkled in the code, still communicates the intent and gives the same
compiled results.
Sponsored by: Netflix
Reviewed by: bz, bryanv
Differential Revision: https://reviews.freebsd.org/D43654
(cherry picked from commit 0ea4b4084845bfeedc8c692e4d34252023b78cb3)
While we account for the padding in the length of the mbuf we use, we do
not account for it when we 'guess' the size of the mbuf to allocate
based in the MTU of the device. This leads to a situation where we might
fail if the mtu is close to a bucket size (say 2018) such that the added
padding would push us over the edge for a full-sized packet. mtu of 2018
is super rare (2016 and 2020 would both work), but fix it none-the-less.
It's a shame we can't just set VTNET_RX_HEADER_PAD to 2 in this case. The 4
seems hard-coded somewhere I've not found documented (I think it's in the
protocol given the comments about VIRTIO_F_ANY_LAYOUT).
Sponsored by: Netflix
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D43656
(cherry picked from commit d9e0e42627613b56abf0f8fa1ad601e5690d775c)
If the header that we add to the packet's size is 0 % 4 and we're
strictly aligning, then we need to adjust where we store the header so
the packet that follows will have it's struct ip header properly
aligned. We do this on allocation (and when we check the length of the
mbufs in the lro_nomrg case). We can't just adjust the clustersz in the
softc, because it's also used to allocate the mbufs and it needs to be
the proper size for that. Since we otherwise use the size of the mbuf
(or sometimes the smaller size of the received packet) to compute how
much we can buffer, this ensures no overflows. The 2 byte adjustment
also does not affect how many packets we can receive in the lro_nomrg
case.
PR: 271288
Sponsored by: Netflix
Reviewed by: bryanv
Differential Revision: https://reviews.freebsd.org/D43224
(cherry picked from commit 3be59adbb5a2ae7600d46432d3bc82286e507e95)
Since 5efea30f03 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e can trigger these for example.
Drivers for firmware based wireless cards have worked around some of
this (and other) problems in the past.
Add an array of tasks rather than a single one as we would simply
get npending > 1 and lose order with other tasks. Try to keep state
changes updated as queued in case we end up with more than one at a
time. While this is not ideal either (call it a hack) it will sort
the problem for now.
We will queue in ieee80211_new_state_locked() and do checks there
and dequeue in ieee80211_newstate_cb().
If we still overrun the (currently) 8 slots we will drop the state
change rather than overwrite the last one.
When dequeing we will update iv_nstate and keep it around for historic
reasons for the moment.
The longer term we should make the callers of
ieee80211_new_state[_locked]() actually use the returned errors
and act appropriately but that will touch a lot more places and
drivers (possibly incl. changed behaviour for ioctls).
rtwn(4) and rum(4) should probably be revisted and net80211 internals
removed (for rum(4) at least the current logic still seems prone to
races).
Given this changes the internal structure of 'struct ieee80211vap',
which gets allocated by the drivers, and we do not have enough
spares, all wireless drivers need to be recompiled.
Given we are forced to do the update, we leave fields in the middle
of the struct and add more spares at the same time.
__FreeBSD_version gets updated to 1400509 to be able to detect
this change.
PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (in 2023)
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43389
(cherry picked from commit 713db49d06deee90dd358b2e4b9ca05368a5eaf6)
(cherry picked from commit a890a3a5ddf33acb0a4000885945b89156799b07)
Unlike bwi(4), bwn(4) does not rely on ic_headroom (despite having it
set) but splits the bwn_txhdr (first) segment into its own transaction.
Remove ic_headroom to avoid net80211 troubles with not enough space in
the mbuf around ieee80211_mbuf_adjust().
PR: 275616
(cherry picked from commit 59dba901f227420647e4856f03cb782a3375c220)
This reverts commit 6c3e93cb5a for
sys/dev/ath/if_ath.c only.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 82506f26c03aa312b91e01a797f31e061749a76d)
This reverts commit b65f813c1a.
As a side effect this also seems to fix wtap which seems to have
lost the epoch over the input path in between.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 1c6dd33d26eb02c6145383a49150965eeca61120)
sys/rman.h defines `resource` structure which conflicts with the Linux
structure of the same name. To fix that remove reference to sys/rman.h
from linux/pci.h and move resource management code to linux_pci.c.
Update consumers which were depending on linux/pci.h pollution.
No functional changes intended.
Sponsored by: Serenity Cyber Security, LLC
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42792
(cherry picked from commit 96ab16ebab6319dce9b3041961b0ab6e20a4fecc)
[Why]
For instance, it gives a chance to the new backend to refresh the
screen. This is needed by the vt_drmfb backend and `drm_fb_helper`.
This change was lost when I posted changes to reviews.freebsd.org and it
broken the amdgpu driver... Thanks to manu@ for reporting the problem
and wulf@ to find out the missing change!
Tested by: manu
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42834
(cherry picked from commit 40c20fc29cad4d38d9a565e9c7ba78612097308e)
[Why]
This ensures that vtterm_cnungrab() is the mirror of vtterm_cngrab().
And the latter always call vt_window_switch() and thus the backend's
vd_postswitch().
This makes sure that whatever the backend did during vtterm_cngrab(), it
can undo it during vtterm_cnungrab().
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42752
(cherry picked from commit f18b3ce0b7be0b24a743ec59077ca8e7929a353c)
[Why]
We want the same behavior at the backend level, regardless if we need to
switch the current window or not.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42751
(cherry picked from commit 16b13bd3fd63be56653296ba54956f5526918445)
[Why]
In the DRM drivers and the integration with vt(4), we need to execute
DRM code outside of the vtbuf_lock. The reason is that this DRM code
acquires locks which can't be acquired when vtbuf_lock, an MTX_SPIN
mutex, is already held.
[How]
A vt(4) backend can now set the `vd_bitblt_after_vtbuf_unlock` flag to
true if it wants to be called outside of vt_buf_lock.
In this case, vt(4) uses an internal version of bitblt_text that uses
the `vd_drawn` arrays, plus a new `vd_pos_to_flush` array, to track
characters to draw/refresh. This internal version then uses the
backend's bitblt_bmp callback to draw the characters after vt_buf has
been unlocked.
Drawing borders and CPU logos is also deferred after the vt_buf lock is
released for the same reason.
We introduce another lock (a default mutex), only used when the
`vd_bitblt_after_vtbuf_unlock` flag is set, to replace part the role of
the vt_buf lock and manage concurrent calls to vt_flush().
The `SC_NO_CONSDRAWN` define is dropped because we now always need the
`vd_drawn` arrays.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42057
(cherry picked from commit 162a2b858854656ddd6b75d290be8a640ba8f324)
[Why]
The same protection was added to vt_flush() in the previous commit. We
want the same one in vt_window_switch(): if e.g. the DRM driver panics
while handling a call to vt_window_switch(), we don't want to
recursively call vt_window_switch() again and trigger another panic.
Reviewed by: imp, manu
Approved by: imp, manu
Differential Revision: https://reviews.freebsd.org/D42750
(cherry picked from commit 24d6f256f825e5d7f8ca6b5d16499f13614f9cdd)
[Why]
If there is a problem with DRM drivers or in their integration with
vt(4) and displaying something on the console triggers a panic, there is
a high chance that displaying that panic will trigger another one,
recursively.
[How]
If vt_flush() is called and it detects is is called resursively from
another panic, it return immediately, doing nothing, to avoid the risk
of triggering another panic.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D42056
(cherry picked from commit 049e3fba04e82f840cc43080edade0ed415fee72)
For example, shutdown_panic wants to produce some output and maybe take
some input before a system is actually reset.
The change should only make difference for the case of system reset
(reboot), poweroff and halt should not be affected.
The change makes difference only if hw.acpi.handle_reboot is set. It
used to default to zero until r213755 / ac731af567.
Also, run shutdown_halt even later, after acpi_shutdown_final. The
reason for that is that poweroff is requested by RB_POWEROFF | RB_HALT
combination of flags. In my opinion, that command is a bit bipolar, but
since we've been doing that forever, then so be it. Because of that
flag combination, the order of shutdown_final handlers that check for
either flag does matter.
Some additional complexity comes from platform-specific shutdown_final
handlers that aim to handle multiple reboot options at once. E.g.,
acpi_shutdown_final handles both poweroff and reboot / reset. As
explained in 9cdf326b4f, such a handler must run after shutdown_panic to
give it a chance. But as the change revealed, the handler must also run
before shutdown_halt, so that the system can actually power off before
entering the halt limbo.
Previously, shutdown_panic and shutdown_halt had the same priority which
appears to be incompatible with handlers that can do both poweroff and
reset.
The above also applies to power cycle handlers.
(cherry picked from commit 9cdf326b4faef97f0d3314b5dd693308ac494d48)
(cherry picked from commit e4ab361e53945a6c3e9d68c5e5ffc11de40a35f2)
The rest of the sound system supports 7+1 maximum and is not aware of 8+0.
I believe that these messages are caused by 8+0:
kernel: feeder_init(0xfffff801f935d680) on feeder_matrix returned 22
kernel: pcm0: feeder_build_matrix(): can't add feeder_matrix
(cherry picked from commit c053a56c0f5df6db5223316831142e1d8afff64f)
First of all and unlike I2C, it's not the master that dictates how many
bytes to read in block read operation. It's the device that informs the
master how many bytes it's sending back.
Thus, for ichsmb_bread() the count parameter is purely an output
parameter. The code has been changed to reflect that.
The sanity checking of the response length is now done once it (the
first byte of the response) is received.
While here, handling of ICH_HST_STA_FAILED status bit has been added.
Plus some code style improvements and some new code comments in the
vicinity of the changed code.
(cherry picked from commit cbf7c81b608bb9311e50df9481447dc843083a0e)
That is, wd_shutdown_countdown value is ignored when halting.
A halted system should remain halted for as long as needed until
a power cycle, so the watchdog should not reset the system.
(cherry picked from commit 8fdb26160160c4507eb2f644a982a3e05984cdf6)
The function had a signature of watchdog_fn while in fact it is used as
shutdown_fn.
(cherry picked from commit 90dc7889825d13290955d0eb7e1fb4388c0a0135)
Power off or reset may be activated either by low or high signal or by an
edge. So, try everything.
Also, the driver now supports DTS properties for timings.
Finally, the driver does not change the pin configuration during attach.
It is assumed that the pin is already in a state that does not trigger
the power event (otherwise we wouldn't be running).
(cherry picked from commit 320e4beb97618c6964380bfa404a3e96c5de7663)
This is a popular USB WiFi chip.
Unfortunately, it's not supported by FreeBSD yet.
(cherry picked from commit 5b54b6ac8ca1bc0653a3b31e79c1bffd9b227c6e)
Fall-through to non-FDT probe code if no matching device node is found.
While here, fix indentation of the switch statement.
Also, make the device description for the hints-based attachment the
same as for FDT attachment.
Fixes: 2486b446db ds1307: add support for the EPSON RX-8035SA I2C RTC
(cherry picked from commit 34694f3da7f9537c34b1878206c65a8cda16c6c0)
On several systems we've noticed that when NTB link goes down, the
Physical Layer User Test Pattern registers we use as additional
scratchpad registers (that is explicitly allowed by the chip specs)
become read-only for about 100us. I see no explanation for this in
the chip specs, neither why it was not seen before, may be a race.
Since we do need these registers, workaround it by repeating writes
until we succeed or 1ms timeout expire.
MFC after: 1 week
(cherry picked from commit 3883c6fbf232452098ba6ea802ef1426d83d2d68)
