| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
We don't build the smccc code on arm so don't call into it there.
|
|
|
|
|
|
|
|
|
| |
To allow device drivers to call into SMCCC we need to initialise it
earlier. As it depends on PSCI, and that is detected via ACPI or FDT
move the call to smccc_init to the PSCI driver.
Add a function for drivers to read the smccc version, or 0 if smccc
is not present.
|
|
|
|
|
|
|
|
| |
- s/confguration/configuration/
- s/nornal/normal/
Obtained from: NetBSD
MFC after: 5 days
|
|
|
|
|
|
|
|
|
| |
`SZ_2K` and `SZ_1G` were defined in irdma. They are removed from this
driver.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D38150
|
|
|
|
|
|
|
|
|
| |
This is useful to the DRM drivers to let them know if a device is
effectively used by the console.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D38089
|
|
|
|
|
|
| |
Reviewed by: erj
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37845
|
|
|
|
|
| |
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37815
|
|
|
|
|
|
| |
Reviewed by: kd
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37813
|
|
|
|
|
|
| |
Reviewed by: erj
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37858
|
|
|
|
|
|
| |
Reviewed by: erj
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37857
|
|
|
|
|
|
| |
Reviewed by: mw
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37825
|
|
|
|
|
|
| |
Reviewed By: bryanv
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37799
|
|
|
|
|
|
| |
Reviewed by: melifaro
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Overview:
Intel(R) QuickAssist Technology (Intel(R) QAT) provides hardware
acceleration for offloading security, authentication and compression
services from the CPU, thus significantly increasing the performance and
efficiency of standard platform solutions.
This commit introduces:
- Intel® 4xxx Series platform support.
- QuickAssist kernel API implementation update for Generation 4 device.
Enabled services: symmetric cryptography and data compression.
- Increased default number of crypto instances in static configuration
for performance purposes.
OCF backend changes:
- changed GCM/CCM MAC validation policy to generate MAC by HW
and validate by SW due to the QAT HW limitations.
Patch co-authored by: Krzysztof Zdziarski <krzysztofx.zdziarski@intel.com>
Patch co-authored by: Michal Jaraczewski <michalx.jaraczewski@intel.com>
Patch co-authored by: Michal Gulbicki <michalx.gulbicki@intel.com>
Patch co-authored by: Julian Grajkowski <julianx.grajkowski@intel.com>
Patch co-authored by: Piotr Kasierski <piotrx.kasierski@intel.com>
Patch co-authored by: Adam Czupryna <adamx.czupryna@intel.com>
Patch co-authored by: Konrad Zelazny <konradx.zelazny@intel.com>
Patch co-authored by: Katarzyna Rucinska <katarzynax.kargol@intel.com>
Patch co-authored by: Lukasz Kolodzinski <lukaszx.kolodzinski@intel.com>
Patch co-authored by: Zbigniew Jedlinski <zbigniewx.jedlinski@intel.com>
Sponsored by: Intel Corporation
Reviewed by: markj, jhb
Differential Revision: https://reviews.freebsd.org/D36254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now we have little visibility into packet drops within netmap.
Start trying to make packet loss issues more visible by counting queue
drops in the transmit path, and in the input path for interfaces running
in emulated mode, where we place received packets in a bounded software
queue that is processed by rxsync.
Reviewed by: vmaffione
MFC after: 1 week
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38064
|
|
|
|
|
|
|
|
|
| |
Reviewed by: vmaffione
MFC after: 1 week
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38063
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check is ok by default, since the default value of
netmap_generic_ringsize is 1024. But we should check against the
configured "ring" size.
Reviewed by: vmaffione
MFC after: 1 week
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per the removed comments these fields should be loaded only once, since
they can in principle be modified concurrently, though this would be a
violation of the userspace contract with netmap.
No functional change intended.
Reviewed by: vmaffione
MFC after: 1 week
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38061
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code paths while dumping do not got through busdma. As such,
safeguard against calling bus_dmamap_sync() with a NULL map. The x86
implementation tolerates this but others do not, resulting in a
NULL dereference panic when dumping to a vtblk device on arm64, riscv,
etc.
Fixes: 782105f7c898 ("vtblk: Use busdma")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37990
|
|
|
|
|
|
|
|
|
|
| |
Add in the zones for my MacbookAir6,2, a 2013 Macbook Air.
Tested - said Macbook Air 2013. Thermal Zones and keyboard backlight
control works fine.
Differential Revision: https://reviews.freebsd.org/D38073
Approved by: jrtc27
|
|
|
|
|
|
|
|
| |
instead of checking _X 2 times.
Reviewed by: wulf
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D38135
|
|
|
|
|
|
| |
Noted by: jkim
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
We need to repeat the operation if the vnode was relocked.
Reported and reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38114
|
|
|
|
|
|
| |
- s/delimeter/delimiter/
MFC after: 7 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CDC_CM descriptor points to the wrong interface for serial port use.
Ignore it to use the CDC_UNION descriptor.
usbconfig dump (spec at: https://usb.org/sites/default/files/CDC1.2_WMC1.1_012011.zip):
ugen0.2: <Baltech AG Smartcard Reader> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (300mA)
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0000 <Probed by interface class>
bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0040
idVendor = 0x13ad
idProduct = 0xf019
bcdDevice = 0x0100
iManufacturer = 0x0001 <Baltech AG>
iProduct = 0x0002 <Smartcard Reader>
iSerialNumber = 0x0003 <45031910>
bNumConfigurations = 0x0001
Configuration index 0
bLength = 0x0009
bDescriptorType = 0x0002
wTotalLength = 0x0064
bNumInterfaces = 0x0003
bConfigurationValue = 0x0001
iConfiguration = 0x0000 <no string>
bmAttributes = 0x0080
bMaxPower = 0x0096
Interface 0
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x0000
bAlternateSetting = 0x0000
bNumEndpoints = 0x0001
bInterfaceClass = 0x0003 <HID device>
bInterfaceSubClass = 0x0000
bInterfaceProtocol = 0x0000
iInterface = 0x0000 <no string>
Additional Descriptor
bLength = 0x09
bDescriptorType = 0x21
bDescriptorSubType = 0x11
RAW dump:
0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0xd0,
0x08 | 0x00
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0081 <IN>
bmAttributes = 0x0003 <INTERRUPT>
wMaxPacketSize = 0x0040
bInterval = 0x0001
bRefresh = 0x0000
bSynchAddress = 0x0000
Additional Descriptor
bLength = 0x08
bDescriptorType = 0x0b
bDescriptorSubType = 0x01
RAW dump:
0x00 | 0x08, 0x0b, 0x01, 0x02, 0x02, 0x02, 0x00, 0x00
Interface 1
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x0001
bAlternateSetting = 0x0000
bNumEndpoints = 0x0001
bInterfaceClass = 0x0002 <Communication device>
bInterfaceSubClass = 0x0002
bInterfaceProtocol = 0x0000
iInterface = 0x0000 <no string>
Additional Descriptor
bLength = 0x05
bDescriptorType = 0x24
bDescriptorSubType = 0x00
RAW dump:
0x00 | 0x05, 0x24, 0x00, 0x10, 0x01
Additional Descriptor
bLength = 0x04
bDescriptorType = 0x24
bDescriptorSubType = 0x02
RAW dump:
0x00 | 0x04, 0x24, 0x02, 0x00
Additional Descriptor
bLength = 0x05
bDescriptorType = 0x24
bDescriptorSubType = 0x06
RAW dump:
0x00 | 0x05, 0x24, 0x06, 0x01, 0x02
Additional Descriptor
bLength = 0x05
bDescriptorType = 0x24
bDescriptorSubType = 0x01
RAW dump:
0x00 | 0x05, 0x24, 0x01, 0x00, 0x01
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0085 <IN>
bmAttributes = 0x0003 <INTERRUPT>
wMaxPacketSize = 0x0008
bInterval = 0x0010
bRefresh = 0x0000
bSynchAddress = 0x0000
Interface 2
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x0002
bAlternateSetting = 0x0000
bNumEndpoints = 0x0002
bInterfaceClass = 0x000a <CDC-data>
bInterfaceSubClass = 0x0000
bInterfaceProtocol = 0x0000
iInterface = 0x0000 <no string>
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0086 <IN>
bmAttributes = 0x0002 <BULK>
wMaxPacketSize = 0x0040
bInterval = 0x0000
bRefresh = 0x0000
bSynchAddress = 0x0000
Endpoint 1
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0006 <OUT>
bmAttributes = 0x0002 <BULK>
wMaxPacketSize = 0x0040
bInterval = 0x0000
bRefresh = 0x0000
bSynchAddress = 0x0000
Reviewed by: manu
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37942
|
|
|
|
|
|
|
|
|
|
|
| |
Some devices have CDC_CM descriptors that would point us to
the wrong interfaces. Add a quirk to ignore those (prefering the
CDC_UNION descriptor effectively)
Reviewed by: manu
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37942
|
|
|
|
|
|
|
|
|
|
| |
Add ACPI_RESOURCE_TYPE_FIXED_MEMORY32 to the PCI ECAM driver. This is
used on the Microsoft Dev Kit 2023 and reportedly the Lenovo x13s.
Reviewed by: Robert Clausecker <fuz@fuz.su> (Earlier version)
Tested by: Robert Clausecker <fuz@fuz.su> (Earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D38031
|
|
|
|
|
| |
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
|
|
|
| |
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
|
|
|
| |
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
|
|
|
| |
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D37837
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Fixes:
* Remove timer service re-arm on ena_restore_device failure.
* Re-Enable per-packet missing tx completion print
Minor Changes:
* Switch driver owners from Semihalf to Amazon in man file.
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case the reset sequence fails (ena_destroy_device() followed by
ena_restore_device() calls) during ena_restore_device(), the driver
resources are being freed. After the clean-up, the timer service is
re-armed in order to try and re-initialize the driver state.
But, such an attempt would fail given that the resources are freed.
Moreover, this would actually cause either the system to fail or a
panic.
When the driver fails in ena_restore_device() procedure, the only
recovery is either unloading and loading the driver or instance
reboot.
This change removes the timer service re-arm in case of failure
in ena_restore_device().
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
Fixes: 78554d0c707c ("ena: start timer service on attach")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit [1] first added the ena_tx_buffer.print_once member,
so that a message about a missing tx completion is printed only
once per packet (and not every second when the watchdog runs).
In this commit print_once is initialized to true, and is set back
to false after detecting a missing tx completion and printing
a warning about it to dmesg.
Commit [2] incorrectly reverses the values assigned to print_once.
The variable is initialized to be true but is checked to be false
when a missing tx completion is detected. This is never true, and
therefore the warning print for each missing tx completion is never
printed since this commit.
Commit [3] added time passed since last TX cleanup to the missing
tx completions per-packet print. However, due to the issue in commit
[2], this time is never printed.
This commit reverses back the values assigned to ena_tx_buffer.print_once
erroneously by commit [2], bringing back to life the missing tx
completion per-packet print.
Also add a space after "." in the missing tx completion print.
[1] - 9b8d05b8ac78 ("Add support for Amazon Elastic Network Adapter (ENA) NIC")
[2] - 74dba3ad7851 ("Split function checking for missing TX completion in ENA driver")
[3] - d8aba82b5ca7 ("ena: Store ticks of last Tx cleanup")
Fixes: 74dba3ad7851 ("Split function checking for missing TX completion in ENA driver")
Fixes: d8aba82b5ca7 ("ena: Store ticks of last Tx cleanup")
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To attach to the hypervisor, kvmclock needs to write a per-CPU MSR.
When EARLY_AP_STARTUP is not defined, device attach happens too early:
APs are not yet spun up, so smp_rendezvous only runs the callback on the
local CPU. As a result, the timecounter only gets initialized on the
BSP, and then timekeeping is broken on SMP systems.
Implement handling for !EARLY_AP_STARTUP kernels: keep track of the CPU
on which device attach ran, and then use a SI_SUB_SMP SYSINIT to
register the rest of the CPUs with the hypervisor.
Reported by: Shrikanth R Kamath <kshrikanth@juniper.net>
Reviewed by: kib, jhb (earlier versions)
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D37705
|
|
|
|
|
|
|
|
| |
Reviewed by: zlei
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D37436
|
|
|
|
|
|
|
| |
endpoint.
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
|
|
|
|
|
| |
alternate setting.
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
|
|
|
|
| |
- s/desciptor/descriptor/
MFC after: 3 days
|
|
|
|
|
|
| |
- s/Reqests/Requests/
MFC after: 3 days
|
|
|
|
|
|
| |
- s/reuqest/request/
MFC after: 3 days
|
|
|
|
|
|
| |
- s/reqest/requests/
MFC after: 3 days
|
|
|
|
|
|
| |
- s/reqests/requests/
MFC after: 3 days
|
|
|
|
|
|
| |
- s/reqest/request/
MFC after: 3 days
|
|
|
|
|
|
| |
- s/reqests/requests/
MFC after: 3 days
|
|
|
|
|
|
|
| |
- s/reuqest/request/
- s/requst/request/
MFC after: 3 days
|
|
|
|
|
|
| |
- s/requsted/requested/
MFC after: 5 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Virtio operates with physical addresses, while busdma is designed to
map these to produce bus addresses. On most supported platforms,
these two are interchangeable; on powerpc platforms, they are not.
When on powerpc, set an IOMMU of NULL, which causes the powerpc busdma
code to bypass the iommu mapping; this leaves us with the physical
buffer addresses which the virtio host expects to see.
Tested by: alfredo
Fixes: 782105f7c898 ("vtblk: Use busdma")
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D37891
|
|
|
|
|
|
| |
MFC after: 2 weeks
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D37740
|
|
|
|
|
| |
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D37945
|