Some iichid(4) child devices, currently hkbd(4) only, opens parent
device in their attach handlers. That breaks internal iichid(4) state
leading to rejecting any incoming data on software and hardware levels.
Fix it with adding of extra state check in iichid(4) attach handler.
Reported by: many
Submitted by: trasz (initial version)
PR: 280290
MFC after: 3 days
(cherry picked from commit 018cb11cb7)
Similar to how the network stack needs to use mb_unmapped_to_ext() to
convert mbufs before passing them to an unsupported driver, if_bridge
needs to avoid passing M_EXTPG mbufs to interfaces that don't support
them. Thus, clear IFCAP_MEXTPG on the bridge if any member interfaces
don't handle unmapped mbufs.
PR: 278245
Reviewed by: jhb, gallatin
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47294
(cherry picked from commit 2bbfbf80d3)
to accomodate lack of ilog2() on stable/14. Done as separate commit to
ease future cherry-picks.
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
Identify interfaces consistenly by the pair of the ifn pointer
and the index.
This avoids a use after free when the ifn and or index was reused.
Reported by: bz, pho, and others
(cherry picked from commit 523913c943)
The way a sound driver currently registers to sound(4) is using the
following sequence of function calls:
1. pcm_register() to initialize snddev_info.
2. pcm_addchan() calls to create the device's primary channels.
3. pcm_setstatus() to do the final setup.
While using 3 different functions in a specific order might not be very
elegant, this pattern cannot be easily avoided. However, pcm_register()
and pcm_setstatus() are especially confusing, since one would
intuitively expect:
1. pcm_register() to actually do the registration, as opposed to a basic
initialization.
2. pcm_setstatus() to, as the name suggests, set some kind of status, as
opposed to finalizing the registration.
This patch renames pcm_register() to pcm_init(), and pcm_setstatus() to
pcm_register(). Drivers are modified accordingly.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47325
(cherry picked from commit 516a9c0212)
These flags are properly set in pcm_setstatus(), once the primary
channels have been created. The existing comment already states that
this is wrong.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47324
(cherry picked from commit 3a7d40c692)
The d->status string is populated in pcm_setstatus() anyway, so call
sndstat_register() after we populate it, and are closer to finalizing
the device creation.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47323
(cherry picked from commit 181a31d834)
Create the sysctl and /dev/dsp* nodes in pcm_setstatus(), which is
responsible for finalizing the device initialization, instead of doing
this in the middle of the initialization.
For the sysctl creation specifically, move them into pcm_sysinit(),
since this is where we create the rest of the sysctl nodes anyway.
A side effect of this change is, that we avoid the possibility of racing
in between pcm_register() and pcm_setstatus() by accessing /dev/dspX or
the sysctls within that window.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47322
(cherry picked from commit 66f3eb14e9)
pcm_veto_load is used to prevent pcm_register() from running if the root
feeder has not been registered yet. However, feeder_register_root() is a
SYSINIT.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D47280
(cherry picked from commit 98cd27c8e1)
xdr_void() should have type xdrproc_t, make it so.
PR: 280514
Reviewed by: brooks, dim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47340
(cherry picked from commit a5d1cf5e36)
Absent a linker.hints, if a module dependency exists on disk, the loader
will automatically load it. That is, if something depends on module
foo, and foo.ko exists, we'll load foo.ko even though the linker hints
file is missing. It's a bit of a hack but it's handy.
This breaks with geom_flashmap though, since it's geom_flashmap.ko on
disk but the module is called g_flashmap. However, pretty much every
other GEOM module is given a "geom_" prefix, so for consistency's sake
alone, it seems nice to rename the module.
PR: 274388
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47311
(cherry picked from commit 2352336ad9)
We were previously unconditionally adding PROT_WRITE to the maxprot of
private mapping (because a private mapping can be written even if the
fd is read-only), but this might violate the user's PROT_MAX request.
While here, rename cap_maxprot to max_maxprot. This is the intersection
of the maximum protections imposed by capsicum rights on the fd (not
really relevant for private mappings) and the user-required maximum
protections (which were not being obeyed). In particular, cap_maxprot
is a misnomer after the introduction of PROT_MAX.
Add some regression test cases. mmap__maxprot_shm fails without this
patch.
Note: Capsicum's CAP_MMAP_W is a bit ambiguous. Should it be required
in order to create writeable private mappings? Currently it is, even
though such mappings don't permit writes to the object referenced by the
fd.
Reported by: brooks
Reviewed by: brooks
MFC after: 1 month
Fixes: c7841c6b8e ("Relax restrictions on private mappings of POSIX shm objects.")
Differential Revision: https://reviews.freebsd.org/D46741
(cherry picked from commit 33c2c58f0a)
The KDMKTONE ioctl, introduced in commit 916347f77e, is used to beep
the PC speaker. For historical reasons the frequency is specified as an
8254 PIT divisor for a 1.19MHz clock. Linux provides this same ioctl.
Add a comment to vtterm_beep to avoid someone wanting to "fix" this in
the future.
Also add an XXX comment that the period unit is supposed to be "timer
ticks." Note that nothing in the base system uses this ioctl.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47395
(cherry picked from commit adba3c7420)
386BSD provided a MD function sysbeep. This took two arguments (pitch
and period). Pitch was jammed into the PIT's divisor directly (which
means the argument was expected to sound a tone at '1193182 / pitch'
Hz). FreeBSD inherited this interface.
In commit e465985885 (svn 177642, Mar 26 2008), phk changed this
function to take a tone to sound in hz. He converted all in-tree
instances of 1193182 / hz to just hz (and kept the few misguided folks
that passed hz directly unchanged -- this was part of what motivated the
change). He converted the places where we pre-computed the 8254 divisor
from being pitch to 1193182 / pitch (since that converts the divisor to
the frequency and the interfaces that were exposed to userland exposed
it in these units in places, continuing the tradition inherited from SCO
System V/386 Unix in spots).
In 2009, Ed Shouten was contracted by the FreeBSD Foundation to write /
finish newcons. This work was done in perforce and was imported into
subversion in user/ed/newcons in revision 199072
(https://svnweb.freebsd.org/base?view=revision&revision=199072) which
was later imported into FreeBSD by ray@ (Aleksandr Rybalko).
From that earliest import into svn import to this date, we ring the bell
with:
sysbeep(1193182 / VT_BELLPITCH, VT_BELLDURATION);
where VT_BELLPITCH was defined to be 800. This results in a bell
frequency of 1491Hz, more or less today. This is similar to the
frequency that syscons and pcvt used (1493Hz and 1500Hz respectively).
This in turn was inherited from 386BSD, it seems, which used the hard
coded value 0x31b which is 795 -> 1500Hz.
This '800' was intended to be the bell tone (eg 800Hz) and this
interface was one that wasn't converted. The most common terminal prior
to the rise of PCs was the VT100, which had an approximately 800Hz
bell. Ed Shouten has confirmed that the original intent was 800Hz and
changing this was overlooked after the change to -current was made.
This restors that original intent and makes the bell less obnoxious in
the process.
Reviewed by: des, adrian
Differential Revision: https://reviews.freebsd.org/D32594
Sponsored by: Netflix
(cherry picked from commit ba48d52ca6)
This change was accidentally reverted in 80f21bb039.
(cherry picked from commit 2416be588e)
Changes to acpi_gpiobus.c handle discovering and parsing the _AEI
objects and storing necessary data in device ivars. A new gpioaei.c
file implements the device, which simply requests an interrupt when
the pin is triggered and invokes the appropriate _Exx or _Lxx ACPI
method.
This makes the GPIO "power button" work on arm64 Graviton systems,
allowing EC2 "Stop"/"Reboot" instance calls to be handled cleanly.
(Prior to this change, those requests would time out after 4 minutes
and the instance would be forcibly killed.)
Reviwed by: imp, andrew, Ahmad Khalifa
MFC after: 3 days
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47253
Co-authored-by: Andrew Turner <andrew@FreeBSD.org>
(cherry picked from commit 9709bda03c)
[MFC note: This is not a direct cherry-pick due to API changes in HEAD
which are not present in stable/14.]
We need to call into INTRNG to activate all interrupts on platforms that
use it. Currently, interrupts are only activated in the nexus drivers for
INTRNG platforms, but this does not handle other bus devices such as
gpiobus that manage their own IRQ space.
Reported by: cperciva
Reviewed by: cperciva, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47282
(cherry picked from commit c85855a72d)
GPIO interrupts work just fine and will be used shortly. We still
do not support GPIO_INTR_SHAREABLE however, so leave that within
the NOT_YET scope.
Reviwed by: andrew
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47251
(cherry picked from commit 2d4219919a)
This allows acpi_gpiobus to override the method and fall back to the
generic gpiobus_read_ivar function if needed.
Reviewed by: andrew
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47250
(cherry picked from commit bc0d10d01c)
AWS Graviton [1234] systems have a bug in their ACPI where they mark
the PL061's GPIO pins as needing to be configured in PullUp mode (in
fact the PL061 has no pullup/pulldown resistors); this flag needs to
be removed in order for _AEI objects to be handled on these systems.
Reviewed by: Ali Saidi
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47239
(cherry picked from commit 2f3f867ac6)
This is the GPIO_INTR_EDGE_* flags, just as a convenience to let code
test flags for interrupt edginess.
Sponsored by: Amazon
(cherry picked from commit f6197f2bc0)
ACPI sleep states are only implemented on x86 systems, so having the
ACPI power button attempt to enter "S5" (or other state as configured
via the hw.acpi.power_button_state sysctl) is not useful.
On non-x86 systems, implement the power button with a call to
shutdown_nice(RB_POWEROFF)
to shut down the system.
Reviewed by: Andrew
Tested on: Graviton 2
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D47094
(cherry picked from commit f41ef9d80b)
Right now flags is set to 0 before this "=" -> "|=" change, but it will
matter when the NOT_YET section above becomes effective.
MFC after: 2 weeks
Sponsored by: Amazon
(cherry picked from commit c808132731)
This currently only implements the address space handler and attempts to
configure pins with flags obtained from ACPI.
Reviewed by: wulf
MFC after: 1 month
Pull Request: https://github.com/freebsd/freebsd-src/pull/1359
(cherry picked from commit 92adaa5862)
As explained in PR 277038, iflib calls IFDI_DETACH() and then
IFDI_QUEUES_FREE(). With igc, the latter writes to a register after it
has been unmapped.
igc_if_detach() already calls igc_release_hw_control(), and looking at
callers of igc_if_queues_free(), that appears to be sufficient. So,
just remove the igc_release_hw_control() call.
PR: 277038
Reported by: Mike Belanger <mibelanger@qnx.com>
Reviewed by: kbowling
Tested by: kbowling
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47293
(cherry picked from commit 35d05a14ed)
This allows iavf to load on E830 devices since those devices place their MSI-X
BAR at a different location than in previous 800 series products.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D46952
(cherry picked from commit e53a21abdf)
ifmedia_add() allocates an ifmedia_entry during ena_attach.
Current code doesn't release this memory during ena_detach()
This commit calls ifmedia_removeall() to properly free the
allocated memory during ena_detach().
Also, in case ena_attach fails, we need to detach ifmedia
which was allocated within ena_setup_ifnet().
This bug was first described in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278100
Reviewed by: zlei
Approved by: cperciva (mentor)
Sponsored by: Amazon, Inc.
(cherry picked from commit 449496eb28)
Large LLQ depth size is currently calculated by dividing the maximum
possible size of LLQ by 2.
In newer paltforms, starting from r8g the size of BAR2,
which contains LLQ, will be increased, and the maximum depth of
wide LLQ will be set according to a value set by the device, instead of
hardcoded division by 2.
The new value will be stored by the device in max_wide_llq_depth field
for drivers that expose ENA_ADMIN_LLQ_FEATURE_VERSION_1 or higher to
the device.
There is an assumption that max_llq_depth >= max_wide_llq_depth, since
they both use the same bar, and if it is possible to have a wide LLQ
of size max_wide_llq_depth, it is possible to have a normal LLQ of the
same size, since it will occupy half of the space.
Also moved the large LLQ case calculation of max_tx_queue_size
before its rounddown.
Approved by: cperciva (mentor)
Sponsored by: Amazon, Inc.
(cherry picked from commit d0419551d9)
This commit adds support for receiving LLQ entry size recommendation
from the device. The driver will use the recommended entry size, unless
the user specifically chooses to use regular or large LLQ entry.
Also added enum ena_llq_header_size_policy_t and llq_plociy field in
order to support the new feature.
Approved by: cperciva (mentor)
Sponsored by: Amazon, Inc.
(cherry picked from commit b1c38df05d)
