Stop trying to manually calculate RID, which cannot be done correctly
by PCI_DEVFN(). Use PCI_GET_RID() method instead.
Do not use pci_find_dbsf() to go from the linux pci_dev to freebsd
device_t. First, device is readily available as dev.bsddev. Second,
using pci_find_dbsf() fails for ARI-enabled functions with large
function numbers, because PCI_SLOT()/PCI_FUNC() are for non-ARI.
Reviewed by: bz, hselasky, manu
Tested by: manu (drm)
Sponsored by: Mellanox Technologies/NVidia Networking
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27960
Everything required for remote kernel debugging over a serial
connection. For FDT-based systems, a debug port can be specified by
setting hw.fdt.dbgport to the desired device tree node in loader.conf.
For example, hw.fdt.dbgport="uart1", or
hw.fdt.dbgport="serial@ff1a0000".
Looks good: emaste
Tested by: rwatson
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27727
The program counter field in the PCB is written in exactly one place,
makectx(), upon entry to the debugger. For threads other than curthread,
its value will be empty, or bogus. Rather than writing to this field in
more places, it can be removed in favor of using the value in the link
register.
To make this clearer, pcb->pcb_x[30] is renamed to pcb->pcb_lr, similar
to what already exists in struct trapframe. Also, prefer lr to x30 in
assembly, as it better conveys intention.
This improves PC_REGS() for kdb_thread != curthread. It is required for
a functional gdb(4) stub, fixing the output of `info threads`, in
particular.
The space occupied by pcb_pc is retained, for compatibility with kgdb.
Reviewed by: markj, jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27720
This effectively undoes the changes made in r321571. While useful, it is
inconsistent with how other architectures pass trapframes to kdb. This
change is also required to get a working gdb(4) stub on arm64, as
otherwise the backtrace will begin too early.
As of 088a7eef95, this information can still be obtained via
"show registers/u".
Reviewed by: jhb (slightly earlier version)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Pull Request: https://reviews.freebsd.org/D27719
The debugger is always entered after some kind of kernel trap, often a
breakpoint in kdb_enter(). This means that the most recent trapframe
will include kernel state at the time of the trap, when often it is
desirable to the developer to view the contents of the previous
trapframe. This trapframe often corresponds to the entry from userspace.
The ddb(4) man page claims the ability to display user register state
via the 'u' modifier to `show registers`, but this appears untrue. It is
not obvious from a quick search of the history when this feature was
added, or when it was removed. (Re)implement this feature in
db_show_regs, noting that it is not necessarily populated with userspace
state.
Reviewed by: jhb (earlier version), markj, bcr (manpages)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27705
Ext_pg mbufs allow carrying multiple pages per mbuf. This
reduces mbuf linked list traversals, especially in socket
buffers, thereby reducing cache misses and CPU use for
applications using sendfile. Note that ext_pages use
unmapped pages, eliminating KVA mapping costs on 32-bit
platforms.
Ext_pg mbufs are also required for ktls (KERN_TLS), and having
them disabled by default is a stumbling block for those
wishing to enable ktls.
Reviewed-by: jhb, glebius
Sponsored by: Netfix
The device mapping table contains sc->max_devices entries, so only
indices in [0, sc->max_devices) are valid.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27964
Previously we copied in the request into a stack-allocated structure
that could be smaller than the request size. Furthermore, we checked
the request size only after doing the copyin.
Fix this by allocating a buffer to hold the request, then copying the
buffer's contents into a command descriptor. This is a bit heavy-handed
but I expect the overhead will not be noticeable. The approach of
coping the header in first is susceptible to TOCTOU problems.
Reviewed by: imp
Reported by: maxpl0it@protonmail.com
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27963
safexcel_ring_intr() could fail to observed that sc_blocked is set after
completing all outstanding ops for a ring, in which case blocked ops
would be deferred forever.
Request structures are managed by individual rings, so move the
"blocked" flag into the per-ring state block and use the ring lock to
synchronize with safexcel_process(). Remove sc_mtx since it is now
unused.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
mtx_init() does not make a copy of the name so the buffer must be valid
for the lifetime of the driver instance. Store each ring's lock's name
in the ring structure.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
The new UAR API already offsets the UAR map pointer the mlx5en(4) is using.
While at it remove some no longer needed variables for keeping track
of the current BF offset.
This fixes a regression issue after the new UAR allocation APIs
were introduced.
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
Add decoding of the Device Self-test log page and the ability to start
or abort a test.
Reviewed by: imp, mav
Tested by: Muhammad Ahmad <muhammad.ahmad@seagate.com>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D27517
This ioctl would instantly induce a panic, likely since near inception, up
until 0861c7d3e0. Lack of previous interest in fixing it combined with
the problematic interface (exports a pointer, really a physical address)
brings us to the natural conclusion: remove it until a useful consumer
forward.
If it eventually gets resurrected, the interface should definitely not
return in this exact form and likely needs to be reimagined.
The associated KPI, efi_get_table, is left intact for the time being.
Reviewed by: imp, jrtc27
Also discussed with: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D28030
Virtual PMCs could be running on multiple CPUs so this needs to be
a per-CPU value.
Submitted by: rwatson (earlier version)
Reviewed by: gnn
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D27973
When testing hwpmc on arm64 we found the counter could overflow while
reading the event count. Handle this case in the armv7 code by also
checking if the overflow bit is set and incrementing the overflow
cound as needed.
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D27969
This change include several changes as listed below all related to UAR.
UAR is a special PCI memory area where the so-called doorbell register and
blue flame register live. Blue flame is a feature for sending small packets
more efficiently via a PCI memory page, instead of using PCI DMA.
- All structures and functions named xxx_uuars were renamed into xxx_bfreg.
- Remove partially implemented Blueflame support from mlx5en(4) and mlx5ib.
- Implement blue flame register allocator.
- Use blue flame register allocator in mlx5ib.
- A common UAR page is now allocated by the core to support doorbell register
writes for all of mlx5en and mlx5ib, instead of allocating one UAR per
sendqueue.
- Add support for DEVX query UAR.
- Add support for 4K UAR for libmlx5.
Linux commits:
7c043e908a74ae0a935037cdd984d0cb89b2b970
2f5ff26478adaff5ed9b7ad4079d6a710b5f27e7
0b80c14f009758cefeed0edff4f9141957964211
30aa60b3bd12bd79b5324b7b595bd3446ab24b52
5fe9dec0d045437e48f112b8fa705197bd7bc3c0
0118717583cda6f4f36092853ad0345e8150b286
a6d51b68611e98f05042ada662aed5dbe3279c1e
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
- call pci_iov_detach() on detaching from PCI device to take care of hang
on destroying VFs after PF is down.
- disable eswitch SRIOV support right after pci_iov_detach(),
else the eswitch cleanup sometimes occur while the SRIOV flow table
is still present.
Submitted by: kib@
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
O_RESOLVE_BENEATH recently took value 0x00800000, but I failed to spot
that while rebasing. Let's use 0x01000000 for the new O_DSYNC flag.
Reported by: kevans
Remove wi(4). pccard is going away, and wi only supports PC Card
devices, though it has a minor amount of glue to also support
PCI cards. However, removing the one without removing the other
is hard, so the whole driver is being removed.
Relnotes: Yes
pccard is being removed, so remove bt3c driver since it only has PC
Card attachment. Also remove bt3cfw(8) since it's the firmware for this
driver.
Relnotes: Yes
PC Card support is being removed, so remove its attachment here. ndis
is slated to be removed entirely for 13, but that's not been done yet.
Relnotes: Yes
The originally chosen numbers interfere with downstream projects'
syscalls. Move them to the end of the syscall table instead.
Reported by: jrtc27
Reviewed by: brooks
MFC-With: 022ca2fc7f
Differential Revision: 022ca2fc7f
aio_fsync(O_DSYNC, ...) is the asynchronous version of fdatasync(2).
Reviewed by: kib, asomers, jhb
Differential Review: https://reviews.freebsd.org/D25071
Respect the new IO_DATASYNC flag when performing synchronous writes.
Compared to O_SYNC, O_DSYNC lets us skip updating the inode in some
cases, matching the behaviour of fdatasync(2).
Reviewed by: kib
Differential Review: https://reviews.freebsd.org/D25160
POSIX O_DSYNC means that writes include an implicit fdatasync(2), just
as O_SYNC implies fsync(2).
VOP_WRITE() functions that understand the new IO_DATASYNC flag can act
accordingly, but we'll still pass down IO_SYNC so that file systems that
don't understand it will continue to provide the stronger O_SYNC
behaviour.
Flag also applies to fcntl(2).
Reviewed by: kib, delphij
Differential Revision: https://reviews.freebsd.org/D25090
This change includes:
hpen - Generic / MS Windows compatible HID pen tablet driver.
hgame - Generic game controller and joystick driver.
xb360gp - Xbox360-compatible game controller driver.
Submitted by: Greg V <greg_unrelenting.technology>
Reviewed by: hselasky (as part of D27993)
hidmap is a kernel module that maps HID input usages to evdev events.
Following dependent drivers is included in the commit:
hms - HID mouse driver.
hcons - Consumer page AKA Multimedia keys driver.
hsctrl - System Controls page (Power/Sleep keys) driver.
ps4dshock - Sony DualShock 4 gamepad driver.
Reviewed by: hselasky
Differential revision: https://reviews.freebsd.org/D27993
which installs /dev/uhid# alias to hidraw character device for
compatibility with some existing uhid(4) users like Firefox.
As side effect it renames traditional uhid(4) driver to hidraw
to make possible using of common unit number allocator.
Requested by: Greg V <greg_unrelenting.technology>
Reviewed by: hselasky (as part of D27992)
This driver provides raw access to HID devices through uhid(4)-compatible
interface and is based on pre-8.x uhid(4) code. Unlike uhid(4) it does
not take devices in to monopoly ownership and allows parallel access
from other drivers.
hidraw supports Linux's hidraw-compatible interface as well.
Reviewed by: hselasky
Differential revision: https://reviews.freebsd.org/D27992
This allows to mark HID-device interrupt handlers as MP-SAFE.
Atomics-based lockless key event queue with swi_giant taskqueue is used
to pass key-press events into Giant-protected system console.
Reviewed by: hselasky (as part of D27991)
This change implements hid_if.m methods for HID-over-USB protocol [1].
Also, this change adds USBHID_ENABLED kernel option which changes
device_probe() priority and adds/removes PnP records to prefer usbhid
over ums, ukbd, wmt and other USB HID device drivers and vice-versa.
The module is based on uhid(4) driver. It is disabled by default for
now due to conflicts with existing USB HID drivers.
[1] https://www.usb.org/sites/default/files/hid1_11.pdf
Reviewed by: hselasky
Differential revision: https://reviews.freebsd.org/D27893
hidquirk(4) is derived from usb_quirk(4) and inherits all its HID-related
functionality. It does not support ioctl(2) interface yet.
Reviewed by: hselasky
Differential revision: https://reviews.freebsd.org/D27890
This driver provides support for multiple HID driver attachments
to single HID transport backend. This ability existed in Net/OpenBSD
(uhidev and ihidev drivers) but has never been ported to FreeBSD.
Unlike Net/OpenBSD we do not use report number alone to distinct report
source but we follow MS way and use a top level collection (TLC) usage
index that report belongs to as a location key.
The driver performs child device autodiscovery based on HID report
descriptor data, proxying of HID requests from child devices to parent
transport backends and broadcasting of interrupts in backward direction.
Differential revision: https://reviews.freebsd.org/D27888
Create an abstract HID interface that provides hardware independent
access to HID capabilities and functions through the device tree.
hid_if.m resembles existing USBHID KPI and consist of next methods:
HID method USBHID variant
-----------------------------------------------------------------------
hid_intr_setup usbd_transfer_setup (INTERRUPT IN xfer)
hid_intr_unsetup usbd_transfer_unsetup (INTERRUPT IN xfer)
hid_intr_start usbd_transfer_start (INTERRUPT IN xfer)
hid_intr_stop usbd_transfer_drain (INTERRUPT IN xfer)
hid_intr_poll usbd_transfer_poll (INTERRUPT IN xfer)
hid_get_rdesc usbd_req_get_report_descriptor
hid_read No direct analog. Not intended for common use.
hid_write uhid(4) write()
hid_get_report usbd_req_get_report
hid_set_report usbd_req_set_report
hid_set_idle usbd_req_set_idle
hid_set_protocol usbd_req_set_protocol
This change is part of D27888
Also hide shim code added in a previous commit under COMPAT_USBHID12.
Note: it is enough to add -DCOMPAT_USBHID12 to CFLAGS to compile old
code with new HID subsystem, but it is not enough to link it at runtime.
HID dependency has to be added explicitly with MODULE_DEPEND macro.
Reviewed by: manu, hselasky (as part of D27887)
This does an import of quirk stubs, debugging macros from USB code and
numerous usage constants used by dependent drivers.
Besides, this change renames some functions to get a better matching
with userland library and NetBSD/OpenBSD HID code. Namely:
- Old hid_report_size() renamed to hid_report_size_max()
- New hid_report_size() calculates size of given report rather than
maximum size of all reports.
- hid_get_data_unsigned() renamed to hid_get_udata()
- hid_put_data_unsigned() renamed to hid_put_udata()
Compat shim functions are provided in usbhid.h to make possible compile
of legacy code unmodified after this change.
Reviewed by: manu, hselasky
Differential revision: https://reviews.freebsd.org/D27887
It will be used by the upcoming HID-over-i2C implementation. Should be
no-op, except hid.ko module dependency is to be added to affected drivers.
Reviewed by: hselasky, manu
Differential revision: https://reviews.freebsd.org/D27867
It is possible that the client list lock is taken by other process for too
long due to e.g. IO timeouts. Allow user to terminate open() in this case.
Reviewed by: markj (as part of D27865)
At the beginning of evdev there was a LOR between hardware driver's and
evdev client list locks as they were taken in different order at
driver's interrupt and evdev open()/close() handlers.
The LOR was fixed with introduction of evdev_register_mtx() function
which allowed to use a hardware driver's lock as evdev client list lock.
While this works good with PS/2 and USB, this does not work with I2C.
Unlike PS/2 and USB, I2C open()/close() handlers do unbound sleeps
while waiting for I2C bus to release and while performing IO.
This change uses epoch(9) for traversing evdev client list in interrupt
handler to avoid the LOR thus making possible to convert evdev client
list lock to sleepable sx.
While here add brief locking protocol description.
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D27865
hid_locate() currently ignores all HID items which tagged as constant,
i.e. bit 0 of main item data is set to 1. See p.6.2.2.4 of
hid1_11.pdf [1]. Such an items are unconditionally treated as
byte-alignment padding. While that may be right decision for input and
output reports that is wrong for features reports. Feature reports can
contain constant capabilities e.g. 'Contact Count Maximum'.
See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232040
Remove check for constant from hid_locate() to make possible parsing of
such a reports.
[1] https://www.usb.org/sites/default/files/documents/hid1_11.pdf
Reviewed by: hselasky
Obtained from: sysutils/iichid
Differential Revision: https://reviews.freebsd.org/D27747
This was overlooked in the pfi_kkif/pfi_kif splitup and as a result
userspace could no longer tell which interfaces had the skip flag
applied.
MFC after: 2 weeks
Doing a 'dd' over iscsi will reliably cause stalls. Tx
cleaning _should_ reliably happen as data is sent.
However, currently if the transmit queue fills it will
wait until the iflib timer (hz/2) runs.
This change causes the the tx taskq thread to be run
if there are completed descriptors.
While here:
- make timer interrupt delay a sysctl
- simplify txd_db_check handling
- comment on INTR types
Background on the change:
Initially doorbell updates were minimized by only writing to the register
on every fourth packet. If txq_drain would return without writing to the
doorbell it scheduled a callout on the next tick to do the doorbell write
to ensure that the write otherwise happened "soon". At that time a sysctl
was added for users to avoid the potential added latency by simply writing
to the doorbell register on every packet. This worked perfectly well for
e1000 and ixgbe ... and appeared to work well on ixl. However, as it
turned out there was a race to this approach that would lockup the ixl MAC.
It was possible for a lower producer index to be written after a higher one.
On e1000 and ixgbe this was harmless - on ixl it was fatal. My initial
response was to add a lock around doorbell writes - fixing the problem but
adding an unacceptable amount of lock contention.
The next iteration was to use transmit interrupts to drive delayed doorbell
writes. If there were no packets in the queue all doorbell writes would be
immediate as the queue started to fill up we could delay doorbell writes
further and further. At the start of drain if we've cleaned any packets we
know we've moved the state machine along and we write the doorbell (an
obvious missing optimization was to skip that doorbell write if db_pending
is zero). This change required that tx interrupts be scheduled periodically
as opposed to just when the hardware txq was full. However, that just leads
to our next problem.
Initially dedicated msix vectors were used for both tx and rx. However, it
was often possible to use up all available vectors before we set up all the
queues we wanted. By having rx and tx share a vector for a given queue we
could halve the number of vectors used by a given configuration. The problem
here is that with this change only e1000 passed the necessary value to have
the fast interrupt drive tx when appropriate.
Reported by: mav@
Tested by: mav@
Reviewed by: gallatin@
MFC after: 1 month
Sponsored by: iXsystems
Differential Revision: https://reviews.freebsd.org/D27683
vn_rdwr() must lock the entire file range for IO_APPEND
just like vn_io_fault() does for O_APPEND.
Reviewed by: kib, imp, mckusick
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28008
Only ACPI attachment is supported for now, some others depend on the
presence of smbios(4) support, which we lack on arm64.
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D28009
A straightforward(ish) port from aesni(4). This implementation does not
perform loop unrolling on the input blocks, so this is left as a future
performance improvement.
Submitted by: Greg V <greg AT unrelenting.technology>
Looks good: jhb, jmg
Tested by: mhorne
Differential Revision: https://reviews.freebsd.org/D21017
In the conversion into a tunable, we converted the
size of the s/g list used by the driver to be based
off of a hardcoded size of 128k rather than maxphys,
this caused performance problems for us. Revert this
to use the maxphys tunable.
Note that this constant is used to size dynamically allocated
things, and not static data structs, so this is safe.
Reviewed By: imp, kib, mav
Tested By:i dhw
Differential Revision: https://reviews.freebsd.org/D28023
Sponsored by: Netflix
No functional change - only moved lines, changed whitespace, and
updated comments.
Reviewed by: allanjude
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D28001
Code changes in this commit were obtained from straight from OpenBSD's
uplcom.c with almost no modification, the list of chip names and USB
IDs was obtained from Linux.
Differential Revision: https://reviews.freebsd.org/D27952
Submitted by: tomli_tomli.me (Yifeng Li)
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
This makes the minimum amount of changes to allow inclusion of dtrace.h
without all the solaris compatibility headers. Installing dtrace.h allows
compiling consumers of libdtrace (e.g. https://github.com/tmetsch/python-dtrace)
without requiring a copy of the source tree.
For python-dtrace I worked around this in 58019c9a12
but being able to build the library without installed sources would be
extremely useful.
Reviewed By: gnn
Differential Revision: https://reviews.freebsd.org/D27884
There is no reason this driver can't return default probe value.
Submitted by: Artur Rojek <ar@semihalf.com>
Reviewed by: emaste, mmel
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential Revision: https://reviews.freebsd.org/D26869
Replace various hw reg bit set/clear helpers with a universal
`qoriq_gpio_set` function.
Submitted by: Artur Rojek <ar@semihalf.com>
Reviewed by: mmel
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential Revision: https://reviews.freebsd.org/D26868
Make the code more conformant to style(9) and improve the general
readability.
This patch does not alter the driver logic.
Submitted by: Artur Rojek <ar@semihalf.com>
Reviewed by: mmel
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential Revision: https://reviews.freebsd.org/D26867
