ctl: Use CAM_PRIORITY_NORMAL for queued CCBs
Previously this was using CAM_PRIORITY_NONE which tripped over the
assertion added in b4b166b8c46b8.
PR: 293076
Reported by: Ken J. Thomson <thomsonk at yandex.com>
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D56995
ctld: Only check physical port linking in a single configuration context
Commit 969876fcee57 moved struct pport from being per-configuration to
being a "global" object shared across multiple configurations. As a
result, the check for duplicate ports actually spanned across
configurations, such that reloading a configuration would now think
that existing physical ports were already linked.
The linking field in pport added in the C++-ification (commit
6acc7afa34aa) faithfully replicated this bug (albeit simpler as I had
noticed that the TAILQ links weren't used after the earlier commit).
To restore the desired behavior, remove the linking field from struct
pport entirely and use a local unordered_map in conf::add_pports which
tracks if a given pport is claimed by more than one target.
PR: 293076
Reported by: Ken J. Thomson <thomsonk at yandex.com>
Fixes: 969876fcee57 ("ctld: parse config file independently of getting kernel info")
[2 lines not shown]
ctld: Refactor ioctl port handling
- Normalize ioctl port names when the port name is first added to
the configuration. This can catch potential duplicate port names
sooner and helps with other parts of this change.
- When recognizing existing ioctl ports, always expand the name to
include the physical and virtual port numbers. This permits binding
ioctl/0/0 or ioctl/1/0 to a target, for example.
- When adding physical ports to a target, first check for an existing
kernel port to reuse. This handles both ioctl and non-ioctl ports
and removes the need for the conf::add_port method for ioctl ports
to check in kports.
- If an existing kport isn't found when adding physical ports, check
to see if the port name is an ioctl port. If so, call conf::add_port
to add an ioctl port. This add_port method overload is now simpler
as it always creates a new port.
[9 lines not shown]
rk_gpio: implement PIC masking methods and mask unhandled IRQs
The Rockchip GPIO controller implements PIC operations for the INTRNG
framework but is missing four masking methods that INTRNG calls during
the filter/ithread handoff: pic_disable_intr, pic_enable_intr,
pic_pre_ithread, pic_post_ithread.
Without them, level-sensitive interrupt sources connected to a
Rockchip GPIO pin re-fire continuously while their ithread runs. On
a RockPro64 with a FUSB302B Type-C controller (i2c) attached to
gpio1 INT_N, the system enters a ~210 kHz interrupt storm the moment
the fusb302 driver attaches and INT_N goes low.
Two complementary changes:
1. Add the four pic_disable_intr/pic_enable_intr/pic_pre_ithread/
pic_post_ithread method bodies. Each toggles the pin's
RK_GPIO_INTMASK bit so the source is masked during the in-flight
ithread window and unmasked on return, honouring the generic
[17 lines not shown]
bcm2835_sdhci: Clean up DMA resources on attach failure
bcm_sdhci_attach() allocates a DMA channel with bcm_dma_allocate()
before creating the bus_dma tag and map. If a later initialization
step fails, the common error path releases the interrupt and memory
resources, but leaves the DMA channel allocated.
Call bcm_dma_free() for cleanup, as it already performs the required
internal checks and can therefore be invoked directly.
Signed-off-by: Haoxiang Li <lihaoxiang at isrc.iscas.ac.cn>
Reviewed by: mhorne
MFC after: 3 days
Pull Request: https://github.com/freebsd/freebsd-src/pull/2241
cap_mkdb: Fix memory leak
This is not a big deal since it only iterates once before exiting, but
that's no reason to set a bad example.
PR: 195128
MFC after: 1 week
Reviewed by: ngie
Differential Revision: https://reviews.freebsd.org/D57251
limits: Improve consistency
Historical precedent seems pretty consistent: size limits have singular
names, number limits have plural names. RLIMIT_VMM broke this, and I
made matters worse by referring to this limit as “vmms” in limits(1).
Consistently use “vms” everywhere user-visible, while leaving the
question of whether or not to rename RLIMIT_VMM itself for another day.
Fixes: 1092ec8b3375 ("kern: Introduce RLIMIT_VMM")
Fixes: 53af2026f213 ("limits: Unbreak after RLIMIT_VMM addition")
Reviewed by: bnovkov
Differential Revision: https://reviews.freebsd.org/D57265
sound: Retire snd_mixer->enuminfo
Instead of caching this when mix_setrecdevs() is called (which many
drivers never call), calculate it when we need it. After all, it is
quite rare that this structure is used by applications.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Retire MIXER_SIZE and use correct size in DEFINE_CLASS
I am not sure why this hack was needed, but the size should be
sizeof(struct snd_mixer). Unfortunately, we have to expose snd_mixer,
but it should be better than relying on a hack.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Remove all remaining uses of mixer_get_lock()
These functions are called from sound(4) through MIXER_SET() in
mixer_set(), but nothing mixer-related is used or needs to be locked in
these cases.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
snd_uaudio: Stop using mixer_get_lock()
There is no reason to lock snd_mixer->lock here, since the only thing we
are doing with snd_mixer is to call mix_getdevinfo() and mix_get_dev(),
which are one-line getters, which are needed to eventually call
uaudio_get_child_index_by_dev().
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
snd_uaudio: Do not use snd_mixer->lock as mixer_lock
In similar fashion to c234740c9d34 ("snd_uaudio: Do not use
pcm_channel->lock to protect uaudio_chan"), stop this layering
violation, and introduce a snd_uaudio(4)-internal mixer_lock.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Retire mixer_ioctl_channel()
This function never succeeds when it is not called from the same process
that has opened the file descriptor (e.g., mixer(8)). The reason is that
the CHN_FOREACH() loop tries to match the pid of each channel with the
pid of the process performing the ioctl, which will not be the same,
unless it's the same process that both opened the channel and performed
the ioctl.
In the case that the same process opens the channels and performs the
ioctl, however, we still do not need to worry, because mixer_ioctl_cmd()
essentially does the same thing anyway. Additionally, this scenario
should be quite rare, given that most applications do not open both
/dev/dsp* and /dev/mixer*, and in fact, it is actively encouraged by the
official OSSv4 specification not to do that.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Retire M_MIXER
Even though harmless, it is not really useful, as there is essentially
only one allocation with M_MIXER.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
sound: Retire hint.pcm.%d.eq_preamp
It wasn't documented in the first place, but it is easier to just use
the sysctl.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
sound: Remove dead EQ FEEDEQ_DISABLE code
If EQ is disabled, we never reach those code paths in the first place.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
sound: Retire FEEDEQ_DISABLE
We can do this more efficiently by just using the SD_F_EQ* flags. In
fact, the dev.pcm.%d.eq handler will (un)set SD_F_EQ_ENABLED and this is
what we actually test with when choosing to creating the EQ feeder or
not, so setting the state to FEEDEQ_DISABLE does not really an effect in
the first place.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
sound: Expose EQ by default
The dev.pcm.%d.eq* sysctls and mixer "bass" and "treble" controls are
exposed only if hint.pcm.%d.eq is set. However, there is no good reason
why we shouldn't at least expose the controls, and let the user
enable/disable/bypass equalization through the sysctl.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
sound: Retire EQ states
The SD_F_EQ_ENABLED does the same thing, and is actually what we test
against in order to create the EQ feeder.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
sound: Retire FEEDEQ_BYPASS
In effect, this is the same as the disable state. There is a comment
that says the bypass state skips EQ altogether, which is what the
disable should be. The disable state according to the comment disables
EQ but keeps the EQ preamp (dev.pcm.%d.eq_preamp), however after testing
it seems that the preamp does not really take effect, because with EQ
disabled, feeder_eq is non existent, so we never execute any EQ code in
the first place.
Make things simpler and clearer and have 2 states; enable and disable,
and do what they should do intuitively.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
