EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33834
(cherry picked from commit 85b3794cee)
The only valid condition for if_awg and aw_syscon is syscon.
EXT_RESOURCES is enabled in GENERIC since 12-CURRENT.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33833
(cherry picked from commit ee2e56c6d7)
For backward compatibility, the memory size will be interpreted in MB if
it's smaller than1 MB and has no suffix. Nowadays, the -m switch accepts
more than just MB. Respect it in the usage message.
Differential Revision: https://reviews.freebsd.org/D34506
Reviewed by: grehan
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 month
(cherry picked from commit afd4f7fa25)
Some PCI devices especially GPUs require a ROM to work properly.
The ROM is executed by boot firmware to initialize the device.
To add a ROM to a device use the new ROM option for passthru device
(e.g. -s passthru,0/2/0,rom=<path>/<to>/<rom>).
It's necessary that the ROM is executed by the boot firmware.
It won't be executed by any OS.
Additionally, the boot firmware should be configured to execute the
ROM file.
For that reason, it's only possible to use a ROM when using
OVMF with enabled bus enumeration.
Differential Revision: https://reviews.freebsd.org/D33129
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 month
(cherry picked from commit e47fe3183e)
Export functions for reading and writing the pci config space from passthru
device to be used by other devices.
This is required for lpc devices to set their vendor/device ids to their
physical values.
Otherwise, GPU passthrough for integrated Intel GPUs won't work properly.
Differential Revision: https://reviews.freebsd.org/D33769
Reviewed by: markj
Sponsored by: Beckhoff Automation GmbH & Co. KG
MFC after: 1 month
(cherry picked from commit 563fd2240e)
Previously we invoked the sysctl with a NULL buffer to query the size,
allocated a buffer, then invoked it again to fetch the data.
As we only handle the case where the sysctl provides data of the
expected size we can just allocate a correctly-sized buffer to begin
with.
Reported by: Thomas Hurst via Twitter
Reviewed by: kevans
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35140
(cherry picked from commit 904c148f1c)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
For RISC-V it was always enabled.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33835
(cherry picked from commit 02398e581d)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33832
(cherry picked from commit 4bcdfeb06f)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33831
(cherry picked from commit 90a5fc326e)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33830
(cherry picked from commit 774a4b6a51)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
Reviewed by: kevans
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33829
(cherry picked from commit 14444bf7c8)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33828
(cherry picked from commit 5c00765bf2)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33827
(cherry picked from commit fb6cebd8bd)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33826
(cherry picked from commit 4f64df4e32)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33825
(cherry picked from commit d46fd9e855)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33824
(cherry picked from commit a813b0965d)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33823
(cherry picked from commit 36498b1408)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33822
(cherry picked from commit b4cc0f7d28)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33821
(cherry picked from commit 78f8b4aafa)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33820
(cherry picked from commit a5339ba3ff)
Write to the PWREN register should be done in update_ios based
on the power_mode value in the ios struct.
Also none of the manual (RockChip and Altera) and Linux talks about
the needed for an inverted PWREN value so just remove this.
This fixes eMMC (and possibly SD) when u-boot didn't setup the controller.
Reported by: avg
Tested-on: Rock64, RockPro64
(cherry picked from commit af32e2cc32)
When using SDIO the block size if per function and most of the time
not equal to MMC_SECTOR_SIZE, fix sdio on dwmmc by setting the correct
block size in the mmc registers.
MFC after: 1 month
Sponsored by: Diablotin Systems
(cherry picked from commit 990a1dbf6f)
When we try to load these tables via acpidump(8) we need them to be in
the DMAP for /dev/mem to access. Add the EFI ACPI reclaim memory type
to the list of memory we map into DMAP but not used by the kernel as
this is the recommended place to put these.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 5b651b501a)
New sysctl allows to mark transmitted PPPoE LCP Control
ethernet frames with needed 3-bit Priority Code Point (PCP) value.
Confirming driver like if_vlan(4) uses the value to fill
IEEE 802.1p class of service field.
This is similar to Cisco IOS "control-packets vlan cos priority"
command.
It helps to avoid premature disconnection of user sessions
due to control frame drops (LCP Echo etc.)
if network infrastructure has a botteleck at a switch
or the xdsl DSLAM.
See also:
https://sourceforge.net/p/mpd/discussion/44692/thread/c7abe70e3a/
Tested by: Klaus Fokuhl at SourceForge
(cherry picked from commit 2e547442ab)
(cherry picked from commit 28903f396a)
Robert Morris reported that, for the case of SecinfoNoname
with the Parent option, providing a non-directory could
cause a crash.
This patch adds a sanity check for v_type == VDIR for
this case, to avoid the crash.
PR: 260300
(cherry picked from commit 47d75c29f5)
Extend the size of the local rx_buffer_size variable to account for
larger buffer sizes possible on 82580, i350 chips.
From i350 datasheet, 6.2.10 Initialization Control 4 (LAN Base Address
+ Offset 0x13):
When 4 ports are enabled maximum buffer size is 36 KB. When 2 ports are
enabled maximum buffer size is 72 KB. When only a single port is
enabled maximum buffer size is 144 KB.
and 8.3:
The overall available internal buffer size in the I350 for all ports is
144 KB for receive buffers and 80 KB for transmit Buffers. Disabled
ports memory can be shared between active ports and sharing can be
asymmetric. The default buffer size for each port is loaded from the
EEPROM on initialization.
From the reporter:
But for I350 when only 2 ports are used PBA size can be set as 72KB
(see datasheet RXPbsize or e1000_rxpbs_adjust_82580 function in
e1000_82575.c). In this case calculating the rx_buffer_size overflows
as 0x0048 << 10 = 73728 or 0x12000 pushed into u16. It is then set as
0x2000 or 8192.
PR: 263896
Reported by: hannula@gmail.com
Tested by: hannula@gmail.com
Approved by: markj
Differential Revision: https://reviews.freebsd.org/D35167
(cherry picked from commit 6987c47569)
something similar a while back, and there are devices in the wild
that otherwise won't attach. This patch is temporary until the
PHY code is further cleared up.
Obtained from: grehan
(cherry picked from commit 6f3c0d2764)
If 'options RSS' is set we bind the epair tasks to different CPUs. We
must take care to not keep the current thread bound to the last CPU when
we return to userspace.
MFC after: 1 week
Sponsored by: Orange Business Services
(cherry picked from commit cbbce42345)
This removes a guard condition that prevents KTLS being enabled for
receiving in TLS 1.3. Use the correct sequence number and BIO for
receive vs transmit offload.
Approved by: jkim
Obtained from: OpenSSL commit 7c78932b9a4330fb7c8db72b3fb37cbff1401f8b
MFC after: 1 week
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D34976
(cherry picked from commit 913616b885)
- Don't unpad records, check the outer record type, or extract the
inner record type from TLS 1.3 records handled by the kernel. KTLS
performs all of these steps and returns the inner record type in the
TLS header.
- When checking the length of a received TLS 1.3 record don't allow
for the extra byte for the nested record type when KTLS is used.
- Pass a pointer to the record type in the TLS header to the
SSL3_RT_INNER_CONTENT_TYPE message callback. For KTLS, the old
pointer pointed to the last byte of payload rather than the record
type. For the non-KTLS case, the TLS header has been updated with
the inner type before this callback is invoked.
Approved by: jkim
Obtained from: OpenSSL commit a5fb9605329fb939abb536c1604d44a511741624
MFC after: 1 week
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D34975
(cherry picked from commit c0f977bfb6)
When KTLS receive is enabled, pending data may still be present due to
read ahead. This data must still be processed the same as records
received without KTLS. To ease readability (especially in
consideration of additional checks which will be added for TLS 1.3),
add a helper variable 'using_ktls' that is true when the KTLS receive
path is being used to receive a record.
Approved by: jkim
Obtained from: OpenSSL commit 031132c297e54cbc20404a0bf8de6ed863196399
MFC after: 1 week
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D34974
(cherry picked from commit 4f1f9c5502)
KTLS implementations currently assume that the start of the in-kernel
socket buffer is aligned with the start of a TLS record for the
receive side. The socket option to enable KTLS specifies the TLS
sequence number of this initial record.
When read ahead is enabled, data can be pending in the SSL read buffer
after negotiating session keys. This pending data must be examined to
ensurs that the kernel's socket buffer does not contain a partial TLS
record as well as to determine the correct sequence number of the
first TLS record to be processed by the kernel.
In preparation for enabling receive kernel offload for TLS 1.3, move
the existing logic to handle read ahead from t1_enc.c into ktls.c and
invoke it from ktls_configure_crypto().
Approved by: jkim
Obtained from: OpenSSL commit 85773128d0e80cd8dcc772a6931d385b8cf4acd1
MFC after: 1 week
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D34973
(cherry picked from commit 019cff03b3)
In some corner cases the check for packets
which exceed the allowed record length was missing
when KTLS is initially enabled, when some
unprocessed packets are still pending.
Approved by: jkim
Obtained from: OpenSSL commit 8fff986d52606e1a33f9404504535e2e2aee3e8b
MFC after: 1 week
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D34972
(cherry picked from commit f6e5fcdc84)
Rather than using taskqueue_swi_giant which holds Giant for all
deferred destroy_dev calls, create a separate queue for destroyed
devices with D_NEEDGIANT set in the corresponding cdevsw. The task
for this queue holds Giant whild destroying deferred devices while the
task for the default queue does not hold Giant.
In addition, switch to taskqueue_thread for destroy_dev_sched.
Deferred destroy_dev requests don't need to run at an SWI priority.
Reviewed by: imp, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D34915
(cherry picked from commit d139909d6e)
This variable was flagged as a set but unused warning as its value was
read from a register and then modified to set a bit
(TI_MBOX_SYSCONFIG_SOFTRST). After the variable is modified, the code
then loops waiting for the SOFTRST bit to go clear in the
TI_MBOX_SYSCONFIG register. Presumably merely reading from the
register does not request a reset as other places in the driver read
this register, so most likely the updated value of sysconfig setting
the reset bit is supposed to be written to the register to request a
reset before the polling loop that waits for the reset to finish.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D34856
(cherry picked from commit ecbe50447d)
The probe routine was setting a value in the softc, but since the
probe routine was not returning zero, this value was lost since the
softc was reallocated (and re-zeroed) when the device was attached.
This is similar in nature to the fixes from
965205eb66.
To fix, move the code to set the 'shasta' flag to the start of attach
along with related code to set an IRQ resource on some non-shasta
devices. The IRQ resource still "worked" being in the probe routine
as the IRQ resource persisted after probe returned, but it is cleaner
to go ahead and move it to attach after setting the 'shasta' flag.
I have no way to test this, but noticed this while reading the code.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D34888
(cherry picked from commit d5472cd4b3)
