aboutsummaryrefslogtreecommitdiff
path: root/sys/dev
Commit message (Collapse)AuthorAgeFilesLines
...
* ufshci: Add a check for WLUN during driver initializationJaeyoon Choi2025-12-015-8/+150
| | | | | | | | | This patch checks whether wlun is registered as a periph device. It also implements a function to issue an SSU. Reviewed by: imp (mentor) Sponsored by: Samsung Electronics Differential Revision: https://reviews.freebsd.org/D53923
* cam/scsi: Add power condition support to START STOP UNITJaeyoon Choi2025-12-012-0/+2
| | | | | | | | | This patch adds a power_condition parameter to the scsi_start_stop() function and sets the power condition via SSU. Reviewed by: imp (mentor) Sponsored by: Samsung Electronic Differential Revision: https://reviews.freebsd.org/D53922
* ufshci: Enable WLUN scanJaeyoon Choi2025-12-014-2/+17
| | | | | | | | QEMU ufs device does not implement WLUN, so QUIRK is added. Reviewed by: imp (mentor) Sponsored by: Samsung Electronics Differential Revision: https://reviews.freebsd.org/D53921
* ufshci: add helper to convert SCSI LUN to UPIU LUN formatsJaeyoon Choi2025-12-012-1/+26
| | | | | | Reviewed by: imp (mentor) Sponsored by: Samsung Electronics Differential Revision: https://reviews.freebsd.org/D53919
* aq(4): Fix VLAN tag testEd Maste2025-11-301-1/+1
| | | | | | | | | | | | | Previously emitted a compiler warning "warning: bitwise comparison always evaluates to false." Looking at the OpenBSD driver (which is based on this code) it looks like the VLAN flag should be set if either of these bits is. In the OpenBSD driver these are AQ_RXDESC_TYPE_VLAN and AQ_RXDESC_TYPE_VLAN2 rather than a magic number 0x60. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53836
* aq(4): Remove unimplemented functionsEd Maste2025-11-301-4/+0
| | | | | | | aq_if_priv_ioctl and aq_if_debug have prototypes but are not yet implemented. Just remove the commented-out DEVMETHODs and the unused prototypes, to clear a build-time warning; the DEVMETHODs and prototypes can be readded if / when they are implemented.
* aq(4): Remove unused DRIVER_MODULE devclassJohn Baldwin2025-11-301-0/+4
|
* aq(4): Port to IfAPIOlivier Cochard2025-11-303-16/+16
| | | | | | Direct access to struct ifnet members is not possible in FreeBSD 15; accessors must be used. These exist in all supported FreeBSD versions, so we do not need to make this conditional.
* aq(4): Remove #include of user header <unistd.h>Rozhuk Ivan2025-11-301-1/+0
| | | | pause() has 2 different definition in unistd.h and sys/systm.h
* sys: Import snapshot of Aquantia ACQ107 vendor driverEd Maste2025-11-3018-0/+12109
| | | | | | | | | | | | | | | | | | | | Obtained from https://github.com/Aquantia/aqtion-freebsd commit c61d27b1d94af72c642deefa0595884481ea7377. This is not using a vendor branch. The formerly-upstream repo is abandoned and I do not believe it will receive updates. This initial import serves as a snapshot of the vendor code, but from here we will iterate on it in the tree as our own code. Bug fixes, code cleanup, and build infrastructure will follow. NetBSD and OpenBSD have derivatives of this driver (with additional hardware support). We can look to changes in those drivers, and the Linux driver, to add support here. Reviewed by: adrian Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53813
* acpi: Fix typos in sysctl descriptionsAymeric Wibo2025-11-281-2/+2
| | | | | | Reviewed by: thj, emaste Approved by: thj Sponsored by: The FreeBSD Foundation
* acpi: Fix setting sleep state sysctls to NONEAymeric Wibo2025-11-281-15/+24
| | | | | | | | | | | | | | This restores the functionality as it was pre-97d152698f48. A stopgap was committed by glebius@ in 34dfccc64f47 ("acpi: in acpi_stype_sysctl() use same logic as in acpi_sleep_state_sysctl()"). PR: 290651 Reviewed by: thj, emaste Approved by: thj Fixes: 97d152698f48 ("acpi: Use sleep types defined in sys/power.h") Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53909
* sound: Retire snd_mixer->busyChristos Margiolis2025-11-283-35/+1
| | | | | | | | | | | | | | | | | Does not really serve any real purpose. It gets set on mixer_open() and unset on mixer_close(), so it essentially tells us whether the mixer is open or not. mixer_close() uses it to return EBADF in case the mixer is not busied, as in, the mixer has not been open()'d yet. This is redundant. The other place where this is used is to decide whether to serve an ioctl issued by userland, in which case it won't if, again, the mixer has not been busied (i.e., opened). Again, seems redundant. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53859
* sys: RealTek -> Realtekykla2025-11-2712-64/+64
| | | | | | | | | | | Realtek changed how it styled its name 25 or so years ago, but the old style persisted in many places. These products use the new styling in their datasheets. Signed-off-by: ykla yklaxds@gmail.com Sponsored by: Chinese FreeBSD Community Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1901
* vt: Allow VT_SETMODE with frsig=0Ed Maste2025-11-271-3/+3
| | | | | | | | | | | | | Linux does not check that any of the signals in vt_mode VT_SETMODE ioctl (relsig, acqsig, frsig) are valid, but FreeBSD required that all three are valid. frsig is unusued in both Linux and FreeBSD, and software typically leaves it unset. To improve portability, allow frsig to be set to zero. PR: 289812 Reported by: Dušan Gvozdenović Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D52835
* xae(4), axidma(4): rewrite DMA operation.Ruslan Bukin2025-11-265-895/+745
| | | | | | | | | | | | Due to performance constraints on a synthesized CHERI RISC-V core, remove usage of xdma(4) scatter-gather framework. Instead, provide a minimalistic interface between two drivers. This increases performance ~4-5 times. Tested using scp(1) and nc(1) on Codasip Prime. Sponsored by: CHERI Research Centre Differential Revision: https://reviews.freebsd.org/D53932
* nvme: Use 'unsigned int' in preference to bare unsignedWarner Losh2025-11-261-1/+1
| | | | | | | It's our preferred style. No functional change. Noticed by: avg Sponsored by: Netflix
* cxgbe(4): Enable IFCAP_NV and implement SIOCGIFCAPNV/SIOCSIFCAPNVNavdeep Parhar2025-11-251-3/+18
| | | | | MFC after: 1 week Sponsored by: Chelsio Communications
* nvme: Minor style(9) fixesWarner Losh2025-11-251-7/+4
| | | | | | | | <sys/systm.h> needs to be first after <sys/param.h>. And we don't need both sys/param.h and sys/types.h. Fixes: 032fbda024d78 Sponsored by: Netflix
* em(4): fix capability bounds needed to access checksum context.Ruslan Bukin2025-11-251-1/+1
| | | | | | | | | | | | | | | Ensure the offp capability bounds cover entire struct with checksum fields. This is needed for CHERI systems to avoid bounds violation trap, as otherwise offp allowed to dereference 4 bytes of csum_flags field only so bzero failed. Tested on ARM Morello. Reviewed by: kbowling Discussed with: jrtc27 Sponsored by: CHERI Research Centre Differential Revision: https://reviews.freebsd.org/D53903
* nvme(4): Increase HMB alignment.Ruslan Bukin2025-11-251-1/+1
| | | | | | | | | | | | | The NVME controller in Crucial P310 disk does not accept 16-byte aligned host memory buffer on Codasip Prime platform, but works fine on PAGE_SIZE aligned memory. Instead of adding a quirk, just increase alignment for everyone. Reviewed by: jhb Discussed with: imp Sponsored by: CHERI Research Centre Differential Revision: https://reviews.freebsd.org/D53296
* cxgbe(4): Fix compile warning for !RSS kernelsNavdeep Parhar2025-11-241-4/+2
| | | | | | | | | | .../sys/dev/cxgbe/t4_main.c:7197:1: warning: unused function 'hashen_to_hashconfig' [-Wunused-function] 7197 | hashen_to_hashconfig(int hashen) | ^~~~~~~~~~~~~~~~~~~~ 1 warning generated. Reported by: bz Fixes: d381a6b4a552 cxgbe: use newly exposed RSS hash key API rather than ad-hoc hashing
* irdma(4): fix potential memory leak on qhash cqp operationBartosz Sobczak2025-11-244-63/+114
| | | | | | | | | | | | | | | | It was found that in some circumstances when launching non-waiting create qhash cqp operation the refcount on the cqp_request may be not properly decremented leading to a memory leak. Signed-off-by: Bartosz Sobczak <bartosz.sobczak@intel.com> Reviewed by: anzhu_netapp.com Tested by: mateusz.moga_intel.com Approved by: kbowling (mentor) MFC after: 1 week Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D53732
* cxgbe: Fix the RSS buildMark Johnston2025-11-241-1/+1
| | | | | | | When "options RSS" is configured, opt_rss.h defines the "RSS" token. PR: 291068 Fixes: 17b4a0acfaf5 ("cxgbe(4): T7 related updates to shared code")
* nvme: Fix some commentsWarner Losh2025-11-241-3/+2
| | | | | | Tweak a couple of comments and fix a spelling error. Sponsored by: Netflix
* mlx5: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-243-35/+1
| | | | | | Differential Revision: https://reviews.freebsd.org/D53091 Reviewed by: kib Sponsored by: Netflix
* sound: Fix revents in midi_poll()Nicolas Provost2025-11-241-11/+9
| | | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: christos Pull Request: https://github.com/freebsd/freebsd-src/pull/1887
* Revert "sound: Merge chn_intr() with chn_intr_locked()"Christos Margiolis2025-11-232-2/+19
| | | | | | | | | It turns out that snd_uaudio(4) uses sound(4)'s channel lock for its USB transfer callbacks. I will try to address this at some point, because this is layering violation, but for now we need to revert the commit, as it causes a lock recursion panic with USB audio devices. This reverts commit e254ef87a30bfcaabc6e4d8e0ecf05f6949a4f06.
* igc: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-222-8/+1
| | | | | | Differential Revision: https://reviews.freebsd.org/D53103 Reviewed by: markj Sponsored by: Netflix
* sfxge: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-222-16/+0
| | | | | | Differential Revision: https://reviews.freebsd.org/D53102 Reviewed by: arybchik, zlei Sponsored by: Netflix
* lio: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-224-15/+4
| | | | | | Differential Revision: https://reviews.freebsd.org/D53101 Reviewed by: zlei Sponsored by: Netflix
* ena: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-223-8/+0
| | | | | Differential Revision: https://reviews.freebsd.org/D53100 Reviewed by: akiyano_amazon.com
* hn: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-221-17/+0
| | | | | Differential Revision: https://reviews.freebsd.org/D53099 Sponsored by: Netflix
* vmxnet3: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-221-21/+8
| | | | | | Differential Revision: https://reviews.freebsd.org/D53098 Reviewed by: tuexen Sponsored by: Netflix
* e1000: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-224-10/+0
| | | | | | Differential Revision: https://reviews.freebsd.org/D53097 Reviewed by: kbowling Sponsored by: Netflix
* ice: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-221-24/+4
| | | | | Differential Revision: https://reviews.freebsd.org/D53096 Sponsored by: Netflix
* iavf: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-222-12/+0
| | | | | Differential Revision: https://reviews.freebsd.org/D53095 Sponsored by: Netflix
* ixl: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-222-15/+2
| | | | | Differential Revision: https://reviews.freebsd.org/D53094 Sponsored by: Netflix
* ixgbe: Use newly exposed RSS hash API rather than ad-hoc hashingAndrew Gallatin2025-11-221-17/+3
| | | | | | Differential Revision: https://reviews.freebsd.org/D53093 Reviewed by: kbowling Sponsored by: Netflix
* cxgbe: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-221-13/+2
| | | | | | Differential Revision: https://reviews.freebsd.org/D53092 Reviewed by: np (outside of differential) Sponsored by: Netflix
* sound: Retire snd_mtx* wrappersChristos Margiolis2025-11-2134-556/+512
| | | | | | | | | | | | Do not create mutexes with snd_mtxcreate(). It doesn't provide any value, plus it first allocates the mutex with malloc(9). Allocate mutexes in the stack and use mtx_* functions directly instead of the snd_mtx* wrappers. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D53855
* sound: Merge chn_intr() with chn_intr_locked()Christos Margiolis2025-11-212-19/+2
| | | | | | | | | | | | There is no scenario where chn_intr() is called with the channel lock already held. No functional change intended. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: kib, markj Differential Revision: https://reviews.freebsd.org/D53854
* sound: Merge PCM_ALIVE() with PCM_REGISTERED()Christos Margiolis2025-11-212-3/+3
| | | | | | | | | PCM_ALIVE() is used only in pcm_unregister(), but it does not hurt to use PCM_REGISTERED(), which uses PCM_ALIVE() internally. In fact, it's more robust this way. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Clean up midi/ includesChristos Margiolis2025-11-212-23/+11
| | | | | | Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D53841
* sound: Simplify logic in dsp_io_ops()Christos Margiolis2025-11-211-22/+10
| | | | | | | | | | | | | | | | | | | | | | Use CHN_LOCK()/CHN_UNLOCK() directly, instead of dsp_lock_chans()/dsp_unlock_chans(). These functions are useful when we want to potentially lock both channels. Here we know which channel we are locking, so we can just lock it directly. This way we get rid of the prio variable as well. Related to runpid again, there is no reason to assign it when CHN_F_RUNNING is not set. channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc(). Get rid of runpid. I do not see how we can end up with channel->pid (td->td_proc->p_pid) not matching buf->uio_td->td_proc->p_pid. Also improve errno values. Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53736
* iwx: tag RX frames as A_MPDU RX; tag A-MSDU frames appropriatelyAdrian Chadd2025-11-211-30/+32
| | | | | | | | | | | | | | | | | | | | | | | * tag packets for 11n/11ac associated nodes with A_MPDU so they get passed into the reordering logic * tag A-MSDU frames with AMSDU and AMSDU_MORE so they don't get dropped due to duplicate sequence numbers. Note: I haven't yet elicited A-MSDU in A-MPDU to fully test this, but I do see the net80211 reordering logic kick in (which you can see via wlanstats -i wlan0 -o ampdu 1). I've checked with Johannes Berg at Intel (who maintains the linux iwlwifi stuff); he replied saying none of the firmware versions are doing AMPDU reorder offloading. Differential Revision: https://reviews.freebsd.org/D53781 Locally tested: * AX210, STA mode, > 200mbit bidirectional traffic testing on 5GHz VHT/40.
* e1000: Don't enable ASPM L1 without L0sKevin Bowling2025-11-211-1/+2
| | | | | | | | | | | Reporter noted packet loss with 82583. NVM is down level. The errata docs mention disabling this, which should be the firmware default, so I am not sure why we were enabling this bit. Linux and OpenBSD have the same issue, while NetBSD got it right. Reported by: Codin <codin@nagi.ftp.sh> Tested by: Codin <codin@nagi.ftp.sh> MFC after: 2 weeks
* e1000: Bump 82574/82583 PBA to 32KKevin Bowling2025-11-211-1/+5
| | | | | | | | | | | | | | | | | The reporter contacted me with packet loss and throughput fluctuations on a low power machine (Intel J1900) that got worse with the recent AIM algorithm in FreeBSD 14.2+. 32K RX PBA matches Linux default. Add a conditional path since we don't otherwise do a fixup for jumbo frames to retain space for two frames in Tx. With this change and an additional errata change, the throughput meets line rate for the reporter. Reported by: Codin <codin@nagi.ftp.sh> Tested by: Codin <codin@nagi.ftp.sh> MFC after: 2 weeks
* sound: Remove vchan_passthrough() and hw.snd.passthrough_verboseChristos Margiolis2025-11-202-23/+0
| | | | | | | Unused and confusing. Sponsored by: The FreeBSD Foundation MFC after: 1 week
* sound: Fix KASSERT panics in chn_read() and chn_write()Christos Margiolis2025-11-201-48/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | INVARIANTS kernels may trigger a KASSERT panic from sndbuf_acquire(), when fuzzing write(2) using stress2, because of a race in chn_write(). In the case of chn_write(), what sndbuf_acquire() does is extend the ready-to-read area of the buffer by a specified amount of bytes. The KASSERT in question makes sure the number of bytes we want to extend the ready area by, is less than or equal to the number of free bytes in the buffer. This makes sense, because we cannot extend the ready area to something larger than what is available (i.e., free) in the first place. What chn_write() currently does for every write is; calculate the appropriate write size, let's say X, unlock the channel, uiomove() X bytes to the channel's buffer, lock the channel, and call sndbuf_acquire() to extend the ready area by X bytes. The problem with this approach, however, is the following. Suppose an empty channel buffer with a length of 1024 bytes, and 2 threads, (A) and (B), where (B) is a higher-priority one. Suppose thread (A) wants to write 1024 bytes. It unlocks the channel and uiomove()s 1024 bytes to the channel buffer. At the same time, thread (B) picks up the lock, and because it is higher priority, it keeps dominating the lock for a few iterations. By the time thread (A) picks up the lock again, it tries to call sndbuf_acquire() with a size of 1024 bytes, which was calculated before it performed the uiomove(). In this case, there is a very high chance that the buffer will not be empty, that is, have a free area of 1024 bytes, as was the case when thread (A) started executing, and so the KASSERT will trigger a panic because the condition (bytes <= free) is not met. Another scenario that can trigger a panic is the following: suppose a buffer with a size of 4 bytes, and two threads: (A) and (B). In the first iteration, thread (A) wants to write 2 bytes, while the buffer is empty, BUT the pointer (sndbuf_getfreeptr()) is at the end (i.e., buf[3]). In the first iteration of the loop, because of the way we calculate t, we'll end up writing only 1 byte, so after sz -= t, sz will be 1, and so we'll need one more iteration in the inner loop, to write the remaining 1 byte. Now we're at the end of the first loop, thread (A) unlocks the channel, it has written 1 byte, it needs to write 1 more, and the buffer is left with 3 empty slots. Now thread (B) picks up the lock, and it wants to write 3 (or more) bytes. Eventually it writes the 3 bytes, and it leaves the buffer with 0 free slots. By the time thread (A) picks up the lock again, and continues with the second iteration of the inner loop, it will try to write the last byte, but sndbuf_acquire() will panic because there is no free space anymore. To fix this, get rid of the inner loop and calculate the write size on each iteration. Also, call sndbuf_acquire() before unlocking the channel. In the scenarios explained above, we'll end up entering the chn_sleep() case. Modify it as well, so that we do not kill the channel if we need to sleep more. Do the same for chn_read() to avoid possible similar panics from sndbuf_dispose(). Reported by: pho Tested by: christos, pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: pho, kib Differential Revision: https://reviews.freebsd.org/D53666
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-14 22:31:30 +0000