These functions may map more memory for DMA than is actually used, since
the allocator operates on multiples of a 4KB page size. Thus,
bus_dmamap_sync() can trigger KMSAN reports when the unused portion of
a page is not zero-ed.
Reported by: KMSAN
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D43133
These members are protected by the identity lock, so rlock it in
noise_remote_alloc() and then assert that we have it held to some extent
in noise_precompute_ss().
PR: 276392
In practice this is harmless; only keepalive packets may realistically have
p_mtu == 0, and they'll also have no payload so the math works out the same
either way. Still, let's prefer technical accuracy and calculate the amount
of padding needed rather than the padded length...
PR: 276363
For an unknown TX CQE error type (probably from a newer hardware),
still free the mbuf, update the queue tail, etc., otherwise the
accounting will be wrong.
Also, TX errors can be triggered by injecting corrupted packets, so
replace the mana_err to mana_dbg logging.
Reported by: NetApp
MFC after: 1 week
Sponsored by: Microsoft
Audio devices with more than 8 channels need bitperfect mode to operate,
the vchan processing chain is limited to 8 channels. For these devices,
let applications properly select a certain number of channels supported
by the driver, instead of mapping the request to a vchan format.
Reviewed by: emaste
Pull Request: https://github.com/freebsd/freebsd-src/pull/914
Disassemble a one-for-all soshutdown() into protocol specific methods.
This creates a small amount of copy & paste, but makes code a lot more
self documented, as protocol specific method would execute only the code
that is relevant to that protocol and nothing else. This also fixes a
couple recent regressions and reduces risk of future regressions. The
extended KPI for the new pr_shutdown removes need for the extra pr_flush
which was added for the sake of SCTP which could not perform its shutdown
properly with the old one. Particularly for SCTP this change streamlines
a lot of code.
Some notes on why certain parts of code were copied or were not to certain
protocols:
* The (SS_ISCONNECTED | SS_ISCONNECTING | SS_ISDISCONNECTING) check is
needed only for those protocols that may be connected or disconnected.
* The above reduces into only SS_ISCONNECTED for those protocols that
always connect instantly.
* The ENOTCONN and continue processing hack is left only for datagram
protocols.
* The SOLISTENING(so) block is copied to those protocols that listen(2).
* sorflush() on SHUT_RD is copied almost to every protocol, but that
will be refactored later.
* wakeup(&so->so_timeo) is copied to protocols that can make a non-instant
connect(2), can SO_LINGER or can accept(2).
There are three protocols (netgraph(4), Bluetooth, SDP) that did not have
pr_shutdown, but old soshutdown() would still perform sorflush() on
SHUT_RD for them and also wakeup(9). Those protocols partially supported
shutdown(2) returning EOPNOTSUP for SHUT_WR/SHUT_RDWR, now they fully lost
shutdown(2) support. I'm pretty sure netgraph(4) and Bluetooth are okay
about that and SDP is almost abandoned anyway.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D43413
device_set_usb_desc() first tries to fetch device information through
the iInterface descriptor, otherwise it falls back to usb_devinfo().
Since usb_devinfo() is both guaranteed to work, and is more verbose, get
rid of the initial iInterface attempt.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: imp, markj
Differential Revision: https://reviews.freebsd.org/D43383
Although the module is compiled "snd_uaudio.ko", follow the rest of the
sound modules' naming convention in the declaration as well.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D43396
PCM_KLDSTRING() prints the kernel module associated with a given audio
device only when that module is not compiled in. Get rid of
PCM_KLDSTRING() altogether and print the driver name (even for modules
that are compiled in) instead, as it implies the module as well.
While here, convert all status strings to the following dmesg-like
format:
[<port|mem> <irq>] on <driver>
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: markj, imp
Differential Revision: https://reviews.freebsd.org/D43349
Unlike the other sound drivers, snd_uaudio(4) doesn't provide
information about the device's description and the driver it's attached
to. A side-effect of this is that applications such as mixer(8), that
fetch these strings through the OSS API's SNDCTL_CARDINFO ioctl will
show a USB audio device as:
pcm0:mixer: <USB Audio> at ? kld snd_uaudio
This patch replaces the generic "USB Audio" description with the
device's actual manufacturer and product strings, and the "at ?" string
with the driver it's attached to:
pcm0:mixer: <Focusrite Scarlett Solo USB> at uaudio0 kld snd_uaudio
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D43347
ADAT connections transport 8, 4 or 2 audio channels depending on the
sample rate. Instead of splitting each physical ADAT port into 4
(potentially unmapped) stereo pcm devices, create just one pcm
device of variable channel width for every ADAT port.
Depending on the sample rate and channel width selected, the pcm
channels may be only partially mapped to ADAT channels and vice versa.
Added flexibility of the new channel mapping is also prerequisite to
introduce more pcm device layouts in follow-up commits.
Reviewed by: br
Differential Revision: https://reviews.freebsd.org/D43393
When mouse reporting feature is turned on (control sequence ^[[?1000h),
syscons sends valid mouse coordinates only for ttyv0. Applications
running on other ttys always (erroneously) get mouse coordinates from
the first tty, not from tty they actually run.
Steps to reproduce:
1. On ttyv0, run any application that uses mouse reporting feature. Make
some clicks. The feature works properly.
2. Switch to another ttyv, run the application. The application receives
mouse click events, but mouse position reported by syscons to the
application does not match with the actual mouse position on the screen.
Expected result:
Reported mouse position should match with visible mouse position.
PR: 193339
Reviewed by: imp
In 9750d9e5, I brought the equivalent of the TS_BUSY flag back in a
mostly hardware-agnostic way in order to fix tty_drain() and, thus,
TIOCDRAIN for UARTs with TX FIFOs. This proved to be sufficient for
fixing the regression reported. So in light of the release cycle of
FreeBSD 10.3, I decided that this change was be good enough for the
time being and opted to go with the smallest possible yet generic
(for all UARTs driven by uart(4)) solution addressing the problem at
hand.
However, at least for the NS8250-class the above isn't a complete
fix as these UARTs only trigger an interrupt when the TX FIFO became
empty. At this point, there still can be an outstanding character
left in the transmit shift register as indicated via the LSR. Thus,
this change adds the 3rd (besides the tty(4) and generic uart(4) bits)
part I had in my tree ever since, adding a uart_txbusy method to be
queried in addition for tsw_busy and hooking it up as appropriate
for the NS8250-class.
As it turns out, the exact equivalent of this 3rd part later on was
implemented for uftdi(4) in 9ad221a5.
While at it, explain the rational behind the deliberately missing
locking in uart_tty_busy() (also applying to the generic sc_txbusy
testing already present).
When compiling with gcc, a function annotated with __result_use_check
cannot have its return value ignored with a void cast. So, try to
handle it.
MFC after: 1 week
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43196
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43195
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43194
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: dab, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43193
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43192
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43191
dwc3 is big enough to have its own subdirectory.
While here only make it depend on kernel option dwc3 and rk_dwc3
without any SOC options.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43190
No need to keep it under sys/arm64/rockchip/clk
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43189
No need to keep it under sys/arm/allwinner/clkng
It's easier to find which controller we support by looking under one directory.
It will also be shared with Allwinner RiscV SoC.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43188
No need to keep it under sys/arm/allwinner
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43187
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43186
No need to keep it under sys/arm/allwinner
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43185
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
Sponsored by: Beckhoff Automation GmbH & Co. KG
No need to keep it under sys/arm64/rockchip
It's easier to find which controller we support by looking under one directory.
While here remove the condition on SOC option, device rk_i2c is enough as all
Rockchip SoC that we support have this controller.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43184
The global hw.igb.rx_process_limit knob never was adhered to by the
in-tree version of this driver but similar functionality is available
via the device-specific dev.igb.N.iflib.rx_budget.
While at it, remove the - besides initialization of tx_process_limit -
unused {r,t}x_process_limit members.
The global hw.em.rx_process_limit knob has been replaced by the device-
specific dev.IF.N.iflib.rx_budget along with the conversion to iflib(4).
While at it, remove the - besides initialization of tx_process_limit -
unused {r,t}x_process_limit members.
Work around vendors who use the same address for multiple
ReadAckRegisters in their ACPI HEST table. This
allows apei to attach cleanly on Ampere Altra servers.
Note the issue is not specific to Ampere, I've run into
it with at least one other vendor (whose server is not
yet released).
Sponsored by: Netflix
Reviewed by: jhb
In particular, don't reserve resources added by drivers via other
means (e.g. acpi_bus_alloc_gas which calls bus_alloc_resource
right after adding the resource).
The intention of reserved resources is to ensure that a resource range
that a bus driver knows is assigned to a device is reserved by the
system even if no driver is attached to the device. This prevents
other "wildcard" resource requests from conflicting with these
resources. For ACPI, the only resources the bus driver knows about
for unattached devices are the resources returned from _CRS. All of
these resources are already reserved now via acpi_reserve_resources
called from acpi_probe_children.
As such, remove the logic from acpi_set_resource to try to reserve
resources when they are set. This permits RF_SHAREABLE to work with
acpi_bus_alloc_gas without requiring hacks like the current one for
CPU device resources in acpi_set_resource.
Reported by: gallatin (RF_SHAREABLE not working)
Diagnosed by: jrtc27
Version : 1.27.5.0
Date : 10/10/2023
=====================
Fixes
-----
BASE:
- Fixed handling the Remote Fault with AN, causing the link failure.
=====================
Obtained from: Chelsio Communications
MFC after: 2 weeks
Sponsored by: Chelsio Communications
This is in preparation for annotating copyin() and related functions
with __result_use_check.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D43178
a designated master clock to stay in sync. Add a sysctl setting
to control the preferred clock source for each HDSPe sound card.
Complement this by sysctl values to list available clock sources,
show the currently effective clock source and display the sync
status of all connections. Clock sources are named according to
RME user manuals.
Submitted by: Florian Walpen <dev@submerge.ch>
Differential Revision: https://reviews.freebsd.org/D43252
Replace the DOOMED flag with a transient DETACHING flag that is cleared
when VI is detached. This fixes VI reattach when only the VI and not
the parent nexus is detached. The old flag was never cleared and
prevented subsequent synch op's related to the VI.
PR: 275260
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43287
Sponsored by: Chelsio Communications
This avoids a mutex reinitialization when the VI is detached and
reattached.
Fixes: 516fe911a6 cxgbe(4): Always use the per-VI callout to read interface stats.
MFC after: 1 week
Sponsored by: Chelsio Communications
Correctly identify the active firmware in flash on adapters with
primary and secondary firmware region in flash.
Correctly identify the active NVRAM on adapters with primary
and secondary NVRAM region in flash.
Loading ispfw(4) moved from isp_pci_attach() to isp_reset().
Drop the reference to ispfw(4) after using it so one can kldunload(8) it.
New isp_load_ram() function to load either ispfw(4) or flash firmware
into RISC's RAM.
New functions to read data from flash. The old ones will be removed later.
A bunch of new helper functions to identify and validate active flash
regions for firmware, auxiliary and NVRAM.
Overhaul ISP_FW_* macros and make use of it when comparing firmware
versions. We can handle firmware versions up to 255.255.255.
Firmware load priority slightly changed:
For 27xx and newer adapters:
- load ispfw(4) firmware
- request (active) flash firmware information
- compare version numbers of ispfw(4) and flash firmware
- load firmware with highest version into RISC's RAM
- if loading ispfw(4) is disabled or failed - load firmware from flash
- if everything else fails use MBOX_LOAD_FLASH_FIRMWARE as fallback
For 26xx and older adapters nothing changed:
- load ispfw(4) firmware and load it into RISC's RAM
- if loading ispfw(4) is disabled or failed use MBOX_EXEC_FIRMWARE
- for 26xx a preceding MBOX_LOAD_FLASH_FIRMWARE is used
New read only sysctl(8)'s:
dev.isp.N.fw_version_run: the firmware version actually running
dev.isp.N.fw_version_ispfw: the firmware version provided by ispfw(4)
dev.isp.N.fw_version_flash: the (active) firmware version in flash
While here:
- firmware attribute handling/parsing reworked
+ renamed defines from ISP2400_FW_ATTR_* to ISP_FW_ATTR_*
+ changed values to match new handling/parsing
+ added some more attributes
- enable FLT support on 26xx based adapters
- log level adjustments
- new function return status codes (some for now, some for later use)
- some minor style changes
Tested and approved to work on real hardware with:
- Qlogic ISP 2532 (QLogic QLE2560 8Gb FC Adapter)
- Qlogic ISP 2031 (QLogic QLE2662 16Gbit 2Port FC Adapter)
- Qlogic ISP 2722 (QLogic QLE2690 16Gb FC Adapter)
- Qlogic ISP 2812 (QLogic QLE2772 32Gbit 2Port FC Adapter)
PR: 273263
Reviewed by: mav
Pull Request: https://github.com/freebsd/freebsd-src/pull/877
MFC after: 1 month
Sponsored by: Technical University of Munich
Update 25xx firmware: version 8.8.207
Add 26xx firmware: version 8.8.231
Add 27xx firmware: version 9.12.0
Add 28xx firmware: version 9.12.1
Remove BUGS section from manpage as we now have firmware for
all supported controllers.
PR: 273263
MFC after: 1 month
Pull Request: https://github.com/freebsd/freebsd-src/pull/877
Sponsored by: Technical University of Munich
