When spitting an RSM containing the SYN and data, honor the
sequence number used by the SYN flag when computing the offset
in the socket buffer.
PR: 297006
Reviewed by: rrs, Peter Lei
MFC after: 3 days
MFC to: stable/15
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D61149
Where the kern_ interfaces map trivially to the syscall interface, follow
the syscall name even if awkward (e.g., sys___mac* -> kern___mac*).
Otherwise use shorter names.
Effort: CHERI upstreaming
Sponsored by: DARPA, AFRL
Pull Request: https://github.com/freebsd/freebsd-src/pull/2284
The Enhanced SuperSpeed meaning of the slot context parent hub slot ID
and port number fields was introduced in xHCI 1.2. Controllers built to
an earlier revision define them only for a Low- or Full-speed device
behind a High-speed hub.
A SuperSpeed device behind a USB 3.2 hub on an Intel Alpine Ridge
controller, an xHCI 1.1 part, stops responding to Address Device and
loops in uhub_reattach_port until the port is disabled.
Fixes: 20b1998254 ("usb: support SSP and SSPx2 xHCI")
Reviewed by: aokblast, ngie, adrian
Differential Revision: https://reviews.freebsd.org/D61278
Nothing tells the SMC that a power off or restart was user requested, so
the T2 keeps rebooting the machine thinking the system is wedged.
Approved-by: ngie (co-mentor)
Reviewed by: ngie, adrian
Differential Revision: https://reviews.freebsd.org/D61260
All currently supported powerpc CPUs handle single-copy atomicity for
any size up to the native word size, so load and store operations are
guaranteed for sub-word size that are naturally aligned.
If a lookup fails for a R_PPC_JMP_SLOT (PLT relocation) ignoring errors
results in an address of 0 gets written into the jump slot, leading to a
NULL pointer jump when attempting to call the function it points to.
Fix this with proper error checking so that a module will fail to load
instead of crashing later on.
Add NVMe CCB (union ccb / struct ccb_nvmeio) building functions for
the four NVMe reservation opcodes, Format NVM, and Get Features /
Set Features. These use the nvme_command building blocks added to
sys/dev/nvme/nvme.h, and are used by the new camcontrol(8) nvres,
nvformat and nvfeature subcommands that will be added separately.
sys/cam/nvme/nvme_all.c:
Add NVMe CCB building functions for the four NVMe reservation
opcodes: nvme_resv_report(), nvme_resv_register(),
nvme_resv_acquire() and nvme_resv_release(). Data direction
is set internally (CAM_DIR_IN or CAM_DIR_OUT as appropriate),
so no flags parameter is needed.
Add a new nvme_format() CCB building function.
Add nvme_get_feature() and nvme_set_feature() CCB building
functions, along with nvme_get_feature_hostid() and
nvme_set_feature_hostid() convenience wrappers for the hostid
feature. nvme_set_feature_hostid() takes an sv argument so
the caller can request that the hostid persist across reset.
sys/cam/nvme/nvme_all.h:
Add prototypes for the above. Wrap the declarations in
__BEGIN_DECLS / __END_DECLS so C++ compilers don't mangle the
names of the C symbols.
Co-authored-by: Reid Linnemann <[email protected]>
Co-authored-by: Dave Baukus <[email protected]>
Co-authored-by: Claude Fable 5 <[email protected]>
Reviewed by: imp
MFC after: 1 week
Sponsored by: Spectra Logic
Differential Revision: https://reviews.freebsd.org/D59532
Add command (struct nvme_command) building functions for the four
NVMe reservation opcodes (Report, Register, Acquire and Release),
Format NVM, and Get Features / Set Features, along with the
enumerations and data structures that go with them. These are
shared between the kernel and userland, and are the underpinnings
for new camcontrol(8) subcommands (nvres, nvformat, nvfeature) that
will be added separately.
The reservation type names are intentionally similar to the SCSI
names for the same reservation types.
sys/dev/nvme/nvme.h:
Add NVMe command building functions for the four NVMe
reservation opcodes: nvme_ns_resv_report_cmd(),
nvme_ns_resv_register_cmd(), nvme_ns_resv_acquire_cmd() and
nvme_ns_resv_release_cmd().
Add enumerated types for the various NVMe reservation
subcommand actions (acquire, register, release), reservation
types, and Change Persist Through Power Loss State values.
Add struct nvme_resv_acq_data and struct nvme_resv_reg_data,
the data payloads for reservation Acquire and Register.
Add a new NVMe Format NVM command building function,
nvme_admin_format_cmd(), and an enumeration for the Secure
Erase Setting parameter for format.
Add nvme_admin_get_feature_cmd() and
nvme_admin_set_feature_cmd() functions to fill a struct
nvme_command for Get Features / Set Features.
Add macros for bitfields in the ctratt and mic dwords of the
NVMe Identify Controller data structure.
Add a prototype for nvme_hostid_sbuf().
Stop byte swapping the hostid fields in
nvme_resv_status_swapbytes() and
nvme_resv_status_ext_swapbytes(), and document the fields as
little endian. The hostid is an opaque 8 or 16 byte value;
keep it in the byte order the device returns it in instead of
interpreting it at this level.
Widen the nvme_ctrlr_cmd_get_feature() and
nvme_ctrlr_cmd_set_feature() prototypes as described below.
While here, fix the entry count clamp in the reservation status
swapbytes functions to use sizeof(*s) rather than sizeof(s); using
the pointer size made the clamp one entry too permissive.
sys/dev/nvme/nvme_util.c:
Add nvme_hostid_sbuf(), which formats an 8 or 16 byte hostid
(from the Get Features hostid feature, in the little-endian
byte order the device returns it in) into an sbuf as an
integer value in base 16, most significant byte first.
sbin/nvmecontrol/resv.c:
Decode the now little-endian hostid fields explicitly when
printing, and zero pad the printed 64-bit values. Previously
the extended hostid printed in a different byte order on big
and little endian machines, and without zero padding between
the two halves.
sys/dev/nvme/nvme_ctrlr_cmd.c:
Refactor nvme_ctrlr_cmd_get_feature() and
nvme_ctrlr_cmd_set_feature() to use the new command building
functions from nvme.h and accept a namespace ID parameter.
Refactor nvme_ctrlr_cmd_set_feature() to also accept the sv
(save) parameter to persist a feature value across reset.
sys/dev/nvme/nvme_ctrlr.c:
Update the temperature threshold, autonomous power state
transition and host memory buffer callers for the new
nvme_ctrlr_cmd_get_feature() and nvme_ctrlr_cmd_set_feature()
arguments.
Co-authored-by: Reid Linnemann <[email protected]>
Co-authored-by: Dave Baukus <[email protected]>
Co-authored-by: Claude Fable 5 <[email protected]>
Reviewed by: imp
MFC after: 1 week
Sponsored by: Spectra Logic
Differential Revision: https://reviews.freebsd.org/D59531
Support per-session configurable ping (SCSI NOP) and login timeouts
similar to what is supported in the Linux iSCSI initiator configuration file.
Reduce iscsi timer granularity to 0.1 sec.
For backwards compatibility, when all timers are selected on integer numbers,
all status messages are unchanged. If the higher granularity is used, the
log messages include sub-second granularity.
The sysctl(3) interface has changed from pure int to string, in order to
support fractional seconds in a human-readable, dotted notation.
Reviewed By: #netapp, #manpages, jhb, pauamma_chezdork.com, siderop1_netapp.com
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D32540
iWARP handling code deals with TCP header processing outside of the normal TCP stack.
Add validation checks to verify the internal integrity of the TCP headers.
Reviewed By: tuexen, O11 Intel Networking group, #transport, bartosz.sobczak_intel.com
Sponsored by: NetApp, Inc.
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58323
vmm does not handle CPUID leaf 0x80000022, so a FreeBSD guest on a
Family 19h or later host panics on "kldload hwpmc", which trusts the
PerfMonV2 bit and writes AMD_PMC_GLOBAL_CTL.
Tested by: Osvaldo Janeri Filho <[email protected]>
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: markj, kib
Differential Revision: https://reviews.freebsd.org/D61141
The v2 path writes AMD_PMC_GLOBAL_CTL whenever the PerfMonV2 CPUID bit
is set. bhyve passes that bit through from the host but does not emulate
the register, so loading hwpmc in a guest on a Family 19h or later host
panics the kernel.
amd_v2_hwcheck_cpu() already probes EVSEL MSRs, so probe GLOBAL_CTL
there too, in order to reject the v2 path and fall back to the generic
CPU class.
Fixes: 9d30640105 ("hwpmc_amd: add PerfMonV2 global-control path")
Tested by: Osvaldo Janeri Filho <[email protected]>
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: mhorne, [email protected]
Differential Revision: https://reviews.freebsd.org/D61133
The acpi IORT code incorrectly uses a u_int as the MSI xref type, while
INTRNG expects an intptr_t. Switch to using intptr_t to help document
this value is the xref for the MSI controller.
Reviewed by: dsl
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D60653
FEAT_TTL adds a Translation Table Level field for TLB maintenance intructions,
to indicate the level holding the leaf address for the address being
invalidated. This can reduce the cost of TLB invalidation.
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D60090
If copyout of the newly allocated PMC ID fails, the caller cannot use or
release the PMC. Release it in the kernel.
Reviewed by: mhorne
MFC after: 3 days
Sponsored by: Advanced Micro Devices, Inc.
Differential Revision: https://reviews.freebsd.org/D60562
A cpuctl(4) write that stops or reprograms IBS can clear the valid bit
of a sample whose NMI is already raised. hwpmc then declines the NMI,
no other handler claims it, and with the default machdep.panic_on_nmi
the system panics.
Have nmi_handle_intr() claim, after all handlers declined it, one NMI
per cpuctl write to an IBS control MSR. Claiming last, rather than
from a cpuctl NMI handler, cannot take an NMI away from hwpmc.
cpuctl.ko now needs the new kernel symbols; an MFC has to update both.
Reproduced on an EPYC 9654 by toggling IBS op through /dev/cpuctlN:
about one unclaimed NMI per 2000 toggles.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: AMD
Signed-off-by: Osvaldo Janeri Filho <[email protected]>
Differential Revision: https://reviews.freebsd.org/D60765
The setting is only read on exec(2), so it can be safely modified.
This is useful to adapt the system to newly discovered buggy programs
without reboot.
Note that that running processes keep their mode until they exec again.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
The quirk's 8KB transfer clamp exposed raw character-device I/O to
the oversized-mapping stall fixed earlier, and its single tracker
turned a stranded request into a complete I/O stall. Without it an
S3X controller runs 128 trackers at its MDTS-derived transfer size
with no retries, failures, or timeouts, at about seven times the
serialized throughput.
Reviewed by: imp, adrian, ngie
Approved by: ngie (co-mentor)
Differential Revision: https://reviews.freebsd.org/D59156
The controller's Recommended Arbitration Burst was ignored; the
specification advises matching the Arbitration feature's burst to it
even under plain round robin. Some controllers report unusable
values: programming the Apple S3X with its reported RAB wedged
sustained I/O, so quirked controllers keep their default
configuration. The hw.nvme.arb_burst tunable overrides the
recommendation.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D59155
devctl_notify() can be called with a mutex held. If the event system is
not listed in devctl_systems[], sysevent_get_group() calls
sysevent_new_group(), which calls strdup() with M_WAITOK, and we may end
up sleeping while holding a non-sleepable mutex.
Add the missing systems.
While here, remove the nonexistent KERNEL system.
PR: 299272
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D61161
The xdrmbuf_getlong() function failed to check for the return
value from xdrmbuf_getbytes(). This could have resulted in
a failure during NFS RPC message processing.
Reviewed by: rmacklem
MFC after: 2 weeks
Sponsored by: VersatusHPC
According to the virtio spec:
> The driver MUST NOT send any buffer available notifications to the
> device before setting DRIVER_OK.
DRIVER_OK isn't set until after attach completes, so defer the first
enqueue. We haven't found any problems as a result of this to the best
of my knowledge: q35 and other devices that we *have* been used with
will apparently check when we go DRIVER_OK.
Tested with q35 virtio-random, which still works.
Reported by: llm-postcr
Reviewed by: kfv, markj
Fixes: f1c5a2e3a6 ("virtio_random: Pipeline fetching the data")
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D61228
When returning NFSERR_BADSEQID, the server should not have incremented
the sequence ID, yet the call to nfsrv_checkseqid() a few lines above
does precisely that. Instead, check for a legitimate retransmission
of the original successful request, and reject otherwise, before the
ticket is used and sequence ID incremented.
MFC after: 1 week
Fixes: ff45b9fc1a ("Bjorn reported a problem...")
Sponsored by: Klara, Inc.
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D61156
transmit only requested GO_IDLE and the locality release, so a back-to-back
command could see stale state and fail with EIO.
A post-send idle timeout no longer discards a completed response.
Reviewed by: kbowling
Approved by: kbowling
Differential Revision: https://ron-dev.freebsd.org/FreeBSD/src/pulls/93
e6000sw_write_xmdio() loaded the Clause 45 register address into the
SMI PHY data register a second time, where the value to write belongs,
so every Clause 45 write stored the register address.
Its only caller, e6000sw_serdes_power(), runs at attach for ports 9 and
10 of the 88E6190 and 88E6190X to power one SERDES interface up and the
other down. It wrote 0x2000 to the SGMII control register and 0x1000
to the 10GBASE-R PCS control register instead, so neither interface was
powered down and the rest of each register was overwritten.
Fixes: 9aba06377d ("Add support for the Marvell 88E6190 11 ports switch.")
Sponsored by: Rubicon Communications, LLC ("Netgate")
The need for a separate map for TSO and non-TSO seems to have arisen from
a misunderstanding about the DMA requirements for Intel drivers like
ice/ixl/iavf. Specifically, this Intel hardware has a quirk where no
more than N (=8) segs can be DMA'ed per packet on the wire. This limit
was enforced using a DMA map with a low segment limit for non-TSO and a
driver specific check for TSO. This led to a *lot* of complexity in
iflib (~80 extra lines of code that this change removes) when the
limit can simply be enforced via the existing EFBIG mechanisms.
This change adds a new flag, IFLIB_SPARSE_TX, that drivers for hardware
with this quirk must set. When set, it causes non-TSO sends that
exceed isc_tx_nsegment to be treated as if bus_dmamap_load_mbuf_sg()
had returned EFBIG.
Due to the API/KABI change, I've bumped the FreeBSD version as well.
Note kgalazka suggested the flag, rather than a more awkward
mechanism that I had in my initial patch.
Reviewed by: kbowling
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D60175
The mmc(4) stack waits after powering up a card: mmc_power_up() waits 1 ms
after the supplies are on and 2 ms after the clock is running, before the
first command is sent. The MMCCAM probe had no such wait: it went from the
power_up request to the power_on request to CMD0 without any delay.
Some devices do not answer the first commands if they are sent too early and
then never enumerate, with no error. On a RockPro64 the Broadcom SDIO Wi-Fi
(BCM4359) was not detected on any of 8 boots without a delay. It was
detected on 8 out of 8 with the same waits as mmc_power_up() added to the
probe.
Add the same two waits, once the power_up request and once the power_on
request are done. This replaces the delay that was in mmc_fdt_set_power(),
which was a fixed 10 ms for FDT hosts only; the waits of the legacy stack are
enough and apply to every MMCCAM host.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61077
set_power() enabled the ext_clock on power-on and called clk_stop() on
power-off. This was wrong in three ways:
- clk_stop() is not the counterpart of clk_enable() (it KASSERTs
enable_cnt == 0), so it panics once the clock has been enabled.
- set_power() is driven by the MMC power_mode IOS and is called
repeatedly for the same state during probing and tuning, so the
enable/disable refcount over- or underflows and panics.
- The ext_clock may be a shared PMIC output (e.g. rk808-clkout2 on the
RockPro64, also feeding the companion Bluetooth controller), so gating
it here disturbs the other consumers.
The external clock is a free-running low-power oscillator the device
needs for its whole lifetime, so enable it once at attach and leave it
running. Only act on real power-mode transitions in set_power() and
limit it to driving the reset line, which is what actually sequences the
device.
Tested on a RockPro64 (Broadcom BCM4359 SDIO Wi-Fi): the SDIO function
now enumerates and the module is reachable from userspace.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61023
cam_periph_mapmem() and cam_periph_unmapmem() map the user-provided
struct mmc_data for XPT_MMC_IO CCBs, but use sizeof(struct mmc_data *)
instead of sizeof(struct mmc_data) as the length. Only the pages
covering a pointer are mapped, so accessing a field past the first
pointer-sized region (for instance cmd->data->flags) faults if the
structure happens to straddle a page boundary and the following page is
not mapped.
The failure is intermittent because it depends on where the caller places
the struct mmc_data. Issuing a CMD53 CCB through pass(4) to an MMCCAM
SDIO card whose struct mmc_data lands at the end of a page panics with
"data abort in critical section or under mutex" in the host driver.
Map the whole structure in both the map and unmap paths.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61022
XPT_MMC_IO maps two nested buffers: cmd.data, then cmd.data->data whose
address is derived from cmd.data. cam_periph_unmapmem() restored them in
forward order, so it put cmd.data back to its userspace value and then
dereferenced that pointer to reach cmd.data->data from kernel context,
panicking in vm_fault_lookup().
Unmap in reverse order, mirroring how the mappings were created. This is
a no-op for single-buffer func_codes and for the other two-buffer cases
(XPT_DEV_MATCH, XPT_SMP_IO), whose buffers are independent.
The bug is only reachable via the pass(4) userspace path, which maps and
unmaps CCB buffers; in-kernel MMCCAM consumers never call
cam_periph_{map,unmap}mem(). Triggered by a userspace SDIO CMD53
transfer from sdiotool(8) through pass(4).
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61021
Only XPT_MMC_SET_TRAN_SETTINGS was handed to the slot taskqueue.
XPT_SET_TRAN_SETTINGS, which mmc_xpt.c issues too, still called
sdhci_cam_settran_settings() directly from the CAM done thread with the
CAM device lock held. Changing the bus clock can sleep (clk_set_freq()
takes the clock topology sx lock), which panics with "sleeping thread
holds CAM device lock".
Handle both opcodes the same way and complete the request from the
taskqueue.
Differential Revision: https://reviews.freebsd.org/D61013
sdhci_set_clock() compared the requested clock with slot->clock, which holds
the rate that the host driver actually applied. Some drivers do not apply
the requested rate: the RK3568 one maps the 400kHz identification frequency
to 375kHz. The two values then never match and every update_ios call goes
through SDHCI_SET_CLOCK() again, even when the clock did not change.
That ends in clk_set_freq(), which takes a sleepable lock, from the done
context of the mmc probe with the CAM locks held. With another thread
holding the clock topology lock this panics with "sleeping thread holds CAM
device lock".
Remember the last requested clock in a new field and compare against it.
Clear it wherever slot->clock is cleared so that a reset still forces an
update.
Tested on a Quartz64 Model A with an NVMe drive on the PCIe slot, where the
panic was seen: 5 cold boots out of 5 attached everything.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D61012
The divider of the controller is not functional on Rockchip, the card clock
is the rate of the core clock. Request the core clock rounded down so that
the closest available rate is selected and report a failure, which was
ignored before. The eMMC was identified at the wrong clock and was never
detected.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60893
The eMMC core clock is a mux without a divider, whose parents provide the
375kHz clock for card identification and the 24MHz to 200MHz clocks for the
other modes. Use RK_CLK_MUX_ROUND_PARENT so that the host driver can change
the card clock, which could not be done before.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60892
The sdmmc clocks are muxes without a divider, whose parents provide the
750kHz clock for card identification and the 50MHz and 100MHz clocks for
the bus. Use RK_CLK_MUX_ROUND_PARENT so that the host driver can change the
card clock, which used to fail with EBUSY and left the SD cards at half
speed.
Differential Revision: https://reviews.freebsd.org/D60891
Add RK_CLK_MUX_ROUND_PARENT for muxes whose parents are fixed rate clocks
that can be shared with other consumers. When a rate is requested, pick
the parent with the rate that best fits the rounding flags and never change
the rate of a parent. Without it the request is passed up to the shared
parents, which refuse to change.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60890
Pin the xin clock to 200MHz, use the generic UHS timing and tuning
methods, parse the eMMC properties and the vqmmc supply from the device
tree, and set the I/O voltage through the regulator framework instead of
the S18 bit. Limit the RockPro64 to 100MHz.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60889
Add the tuning procedure (CMD21 with the standard JEDEC tuning block
patterns), the 1.2V/1.8V/3.3V signaling voltage switch using voltage
bands, a watchdog for stuck requests, controller recovery and DMA fixes
needed to run HS200 reliably.
For the Rockchip glue, implement the tuning hook by sweeping the sample
clock phase over 360 degrees, picking the middle of the widest good window
and restoring the previous phase on failure. The drive phase is set to
180 degrees.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D60888
Describe the SDMMC, SDIO, EMMC and their sample/drive phase clocks so that
host drivers can tune them.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D60887
Allow HS200 tuning only above 100MHz timings, let the host driver keep a
fixed maximum clock, and stop clearing max_clk in the generic FDT attach so
that a controller driver can set it before attach.
Differential Revision: https://reviews.freebsd.org/D60885
Switch eMMC cards to HS200 when both the card and the host support it,
falling back to high speed on failure. Bus settings changes now wait for
the SIM to complete, which runs from its own taskqueue. Also fix a race
where a new request could be lost when the SIM task cleared the current
request after completing it, and fail bios queued for a partition whose
switch failed.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D60884
The PerfMonV2 start and stop methods set the core enable bit on UMC
counters too, so UMC events never count. Use the UMC enable bit, as
the legacy methods do.
Reviewed by: mhorne, Ali Mashtizadeh <[email protected]>
Fixes: 9d30640105 ("hwpmc_amd: add PerfMonV2 global-control path")
Sponsored by: AMD
Signed-off-by: Osvaldo Janeri Filho <[email protected]>
Differential Revision: https://reviews.freebsd.org/D60770
An Intel display-audio codec was observed to remain in D3 after monitor
sleep on DragonFly BSD. Starting a new stream then produced no sound,
and waking the codec alone left the output pin amplifier muted and other
function configuration unrestored.
Read the audio function power state at stream start. If its requested or
actual state is not D0, use the existing power-up routine before
configuring and starting the stream, then restore the function to a
known state:
Restore selectors, pins, EAPD, GPIO/GPO and direct codec patches, then
replay the cached gain and mute values once the pins are configured.
Split widget configuration out of hdaa_audio_commit() into
hdaa_audio_widget_commit() so the wake path can reuse it without
reinitializing the cached amplifier values. Preserve the existing
volume, mute and forced-mute values.
Re-enable unsolicited responses, refresh ELD, and run jack presence
handling for playback pins. Skip the full presence handler for recording
pins only: its recording path can drop the driver lock to update the
recording source, which is not safe while starting a stream with the
channel lock held. The playback path does not drop the driver lock, so
it is safe to run here, and it is what matters for display audio, whose
pins belong to playback associations.
GET_POWER_STATE reports the actual state in ACT (bits 7:4) and the
requested state in SET (bits 3:0). They can differ during a transition.
Checking both avoids skipping the D0 request when the function is still
actually in D0 but has been requested to power down, or when D0 has been
requested but the actual state has not reached D0 yet. The observed
post-sleep response on DragonFly was 0x233, with both fields reporting
D3.
Despite their names, HDAA_AMP_MUTE_DEFAULT (0xffffffff) and
HDAA_AMP_VOL_DEFAULT (-1) are sentinels meaning "keep the cached
setting" in hdaa_audio_ctl_amp_set(). Passing them leaves ctl->muted,
ctl->left and ctl->right unchanged, then writes the cached values to the
hardware while respecting ctl->forcemute. It does not select factory
defaults or unconditionally unmute the output.
Preserve the existing behavior when the power-state query returns
HDA_INVALID or both fields already report D0, and leave the D0 fast path
and invalid power-state query handling unchanged.
The observed wake-only silence and amplifier recovery were seen on
DragonFly BSD. This FreeBSD adaptation has not been validated on FreeBSD
hardware.
PR: 299139
MFC after: 2 weeks
Reviewed by: christos
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2464
Removed ABS_SET, BSS_SET, and SET_ENTRY. They were initially
introduced in v1.1 to be used with a.out file. After the migration
to ELFs they are equivalent to TEXT_SET and DATA_SET.
Furthermore, these macros are never used in the src tree.
Event: Oslo Hackathon 2026
Reviewed by: des, jhb
Differential Revision: https://reviews.freebsd.org/D61035
Michael Tuexen