- Implement bus_map/unmap_resource pulling bits from the previous
ofw_pcib_activate/deactivate_resource. One difference here is that
the bus_unmap_resource implementation uses bus_space_unmap instead
of pmap_unmapdev as a complement to the existing use of bus_space_map.
- Use bus_generic_rman_* in various routines for memory and I/O port
resources.
- Use pci_domain_* for PCI_RES_BUS in
ofw_pcib_activate/deactivate_resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43441
bpfattach() is called in wg_clone_create(), but the bpfdetach() is
missing from wg_close_destroy(). Add the missing bpfdetach() to avoid
leaking both the associated bpf bits as well as the ifnet that bpf will
hold a reference to.
PR: 276526
MFC after: 3 days
Commit 6b6914c1e2 introduced a printf-like version of
device_set_desc(), so use it to simplify device description setting in
the audio stack.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D43467
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.
