Fix a copy-and-paste error in acpi_pcib_request_feature where the
child device was passed into acpi_pcib_osc rather than the pcib
device.
Reviewed by: garga, jhb
Fixes: ba1904937d9a ("acpica: Extract _OSC parsing to a common file")
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48285
(cherry picked from commit b714eacb790551f35de03831b88ad7b7e1502102)
bcd2bin() must not be called with a value greater or equal to
LIBKERN_LEN_BCD2BIN.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 516e24e57987d184cce70e7f31443653aa1a5e63)
Using printf() with '%s' can lead to arbitrary long printing (although,
usually, a NUL byte should appear quite quickly) and trying to print
unprintable characters.
Instead, print in hexadecimal the exact bytes that are compared to the
expected signature.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit bb04712e37723d112b2fad28af4b035ef35a25be)
This helps figuring out quickly why no SMBIOS device appears in this case.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit fdf08ac1e9f9baac4fcf4af8f3bf7a34d3ea0009)
Only allow the length tolerance (0x1e instead of 0x1f) for a 32-bit
entry point, as there was no 64-bit entry point in the erroneous SMBIOS
v2.1 standard and assigning the length with 0x1f does not make sense in
this case.
While here, fix accessing the major/minor versions via 'eps' even in the
64-bit entry point case (not causing any practical problem thus far as
the entry point length is greater than any SMBIOS revisions in
existence, so the comparison guarding the fixup would not pass).
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit f6cbd6b6d2ccd672e4807128ce0d07db333d4335)
Consistently with what the probe and attach methods are doing.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 3907feff7ab732b918ba3f5993e7a6718fffea14)
While here, de-indent most of the code by simply bailing out if 'addr'
is still 0 after the various detection methods have been tried.
Reviewed by: emaste, imp
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49180
(cherry picked from commit 67d510f0c07afd89e51e337e5abec47f4483ecd9)
Additionally, on verbose boot, print the entry point revision as
a diagnostic/debugging help.
PR: 284460
Reviewed by: markj, imp (both older version)
MFC after: 2 weeks
Event: February src bug-busting session
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49179
(cherry picked from commit e421a6615dc257b71ac5255336dddf5c99cd12aa)
When booted from BIOS (i.e., not EFI), also search for a 64-bit version
of the SMBIOS Entry Point.
This allows us to detect and report the proper SMBIOS version with
BIOSes that only provide the v3 table, as happens on Hetzner virtual
machines.
For machines that provide both, leverage the v3 table in priority
consistently with the EFI case.
PR: 284460
Reviewed by: markj, imp (both older version)
MFC after: 2 weeks
Relnotes: yes
Event: February src bug-busting session
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49179
(cherry picked from commit bc7f6508363c5cf4544044e00bbaf71de8f0168d)
Get smbios working on arm64 where it seems to be
exclusively smbios version 3.x
The "interesting" thing here is that the smbios table seems to be
RAM in the EFI runtime services table. This makes it owned by "ram0",
and not io memory. That prevents bus_alloc_resource() from being able
to claim it, since ram0 already owns it. According to jhb, this is
how things are supposed to work. Eg, bus_alloc_resource() is meant
to be used with IO memory, not physical memory. Following his
suggestion, I converted the driver to simply use pmap_mapbios().
This is a prerequisite for getting IPMI to attach via the SSIF
attachment on arm64 servers, where all IPMI that I've seen
uses SSIF.
Note that this change is based on initial work by Allan Jude in
https://reviews.freebsd.org/D28739.
Reviewed by: imp
Sponsored by: Netflix, Ampere Computing LLC (D28739)
Differential Revision: https://reviews.freebsd.org/D42592
(cherry picked from commit ba0e4d7971e05ee64281a4fc49a2fb408c8ad816)
This call was meant to be the default case in the first place, but
somehow missed this.
Reported by: glebius
Fixes: 4021fa32d92d ("sound: Simplify pcm/feeder_mixer.c")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
(cherry picked from commit b6420b5ea5bcdeb859a2b3357e5dbaafe7aaff88)
Lock around uses of devclass_*() and replace leftover
CTLFLAG_NEEDGIANTs with CTLFLAG_MPSAFE.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D46700
(cherry picked from commit 35400672df83e337f8792df1972a15003b603930)
Reduce ifdefs, and add aliases for the unsigned formats.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48009
(cherry picked from commit a4aff024fd53a38ba08bbf5309589e1865ffe024)
Even though the OSS manual [1] advises against using AFMT_FLOAT, there
are applications that expect the sound driver to support it, and might
not work properly without it.
This patch adds AFMT_F32_LE|BE (as well as AFMT_FLOAT for OSS
compatibility) in sys/soundcard.h and implements AFMT_F32_LE|BE <->
AFMT_S32_LE|BE conversion functions. As a result, applications can
write/read floats to/from sound(4), but internally, because sound(4)
works with integers, we convert floating point samples to integer ones,
before doing any processing.
The reason for encoding/decoding IEEE754s manually, instead of using
fpu_kern(9), is that fpu_kern(9) is not supported by all architectures,
and also introduces significant overhead.
The IEEE754 encoding/decoding implementation has been written by Ariff
Abdullah [2].
[1] http://manuals.opensound.com/developer/AFMT_FLOAT.html
[2] https://people.freebsd.org/~ariff/utils/ieee754.c
PR: 157050, 184380, 264973, 280612, 281390
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47638
(cherry picked from commit e1bbaa71d62c8681a576f9f5bedf475c7541bd35)
Make vchanrate and vchanformat reflect the primary channel's software
buffer's rate and format respectively. Fix previous inconsistencies.
Get rid of the initializations in vchan_create() and move them to
chn_init().
Without the feeder_rate_round check in sysctl_dev_pcm_vchanrate(), we
can set the software rate to anything between feeder_rate_min and
feeder_rate_max. If we keep the check, however, the rate is limited to
whatever the driver's min/max is, which can be a problem if, for
example, the driver supports only a single rate, in which case we won't
be able to set anything other than the driver rate.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48961
(cherry picked from commit e372211be5c56e218e974a4478be9aa80bfca064)
Check if CTS bit is set in the mailbox message before waiting for ACK.
Otherwise ACK will never be received causing the function to timeout. Add
a note for ixgbe_write_mbx that it should be called while holding a lock.
Fixes: 6d243d2 ("net/ixgbe/base: introduce new mailbox API")
Cc: stable@dpdk.org
Signed-off-by: Norbert Ciosek <norbertx.ciosek@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Obtained from: DPDK (1f119e4)
(cherry picked from commit 1580f8d9c1740e0c54554e6c185573d34f2dcf76)
Summary:
The device IDs for these were in the driver's list of PCI ids to attach
to, but igc_set_mac_type() had never been setup to set the correct mac
type for these devices. Fix this by adding these IDs to the switch block
in order for them to be recognized by the driver instead of returning an
error.
This fixes the igc(4) attach for the I226-K LOM on the ASRock Z790
PG-ITX/TB4 motherboard, allowing it to be recognized and used.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: kbowling@
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D49147
(cherry picked from commit 7ee310c80ea7b336972f53cc48b8c3d03029941e)
In order to signal to Graviton [123] systems that a device is ready
to be "ejected" (after a detach request is made via the EC2 API) we
need to set PCIM_PSTAT_PME to 1 and PCIM_PSTAT_PMEENABLE to 0. We are
not aware of any rationale for this requirement beyond "another OS
kernel happens to do this", i.e. this is effectively bug-for-bug
compatibility.
Arguably this should be done by the ACPI _EJ0 method on these systems,
but it is not.
Create a new ACPI_Q_CLEAR_PME_ON_DETACH quirk and set it in EC2 AMIs,
and add the PCI register write to acpi_pci_device_notify_handler when
that quirk is set.
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D49146
(cherry picked from commit d70bac252d30adec4feba0c866dabe2c16a756d9)
We claim to support Active State Power Management, but don't appear to
do anything different in the kernel when it's enabled other than tell
the firmware we do.
This breaks VMware Fusion on Apple Silicon when it's enabled as it
expects the kernel to enable the ports. As it is reported to be needed
on some x86 servers keep it enabled there, but disable on non-x86
architectures.
Reported by: kp, tuexen
Reviewed by: tuexen, mav, imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48303
(cherry picked from commit 143dff0f9ce9a6f03ae5701368c7144b30e2dc39)
In the ACPI attachment add support for the pcib_request_feature method.
This uses the common _OSC handling.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48048
(cherry picked from commit 1f5c50a8617355758510675cb9412f56fed12efc)
In the ACPI attachment support the ACPI_IVAR_HANDLE ivar. While here
use the common ivar function to support the common ivars.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48047
(cherry picked from commit deb36d0c65436d16b04f99cc2a27bd0f3980a6f0)
Allow this to be called from attachments to allow more ivars to be
implemented.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48046
(cherry picked from commit 7cafe75c8c52deffcb3e64200eb4187a52cf202d)
In pci_host_generic.c use a switch statement rather than a series
of if statements.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48045
(cherry picked from commit fafb43abd0dcaf2d36ec7344f46e7e19c42be888)
This will be used by pci_host_generic_acpi.c so needs to be in a
common location.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48044
(cherry picked from commit ba1904937d9ae0539e39001467a1519b17177118)
unless the dev.acpi_ibm.0.handlerevents sysctl is set to process
them internally. The default for the latter is to ignore them,
so passing to evdev(4) is enabled by default.
Reviewed by: wulf, imp
Tested on: Lenovo Thinpad X11 Carbon 7Th Gen
Differential Revision: https://reviews.freebsd.org/D48174
(cherry picked from commit c21f5751ef0932796676e55953461e0679020e28)
Amazon EC2 m7i cloud instances use PCI hotplug rather than ACPI
hotplug. The card is removed and detach is called to remove the drive
from the system. The hardware is no longer present at this point, but
the bridge doesn't translate the now-missing hardware reads to all ff's
leading us to conclude the hardware is there and we need to do a proper
shutdown of it. Fix this oversight by asking the bridge if the device is
still present as well. We need both tests since some systems one cane
remove the card w/o a hotplug event and we want to fail-safe in those
cases.
Convert gone to a bool while I'm here and update a comment about
shutting down the controller and why that's important.
Tested by: cperciva
Sponsored by: Netflix
(cherry picked from commit dc95228d98474aba940e3885164912b419c5579d)
10ms seems to be too strict for some configurations, so increase to
20ms.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1327
(cherry picked from commit e152944f1a16a4ff33b4e20b813ce4a54b884b90)
Only set the GETMAXLUN quirk when it causes an error, but don't set it
when it returns 0. Since we reset the device when we set any quirk, only
set this quirk when it generates an error so umass will avoid it. When
the command works, there's no reason for umass to avoid it at all.
MFC After: 1 week
Sponsored by: Netflix
(cherry picked from commit b0375f78e32acd7947d28126a5e165f8139a5a23)
