Add a work-in-progress version of ice(4), a driver for Intel E810 devices.
Ported from FreeBSD.

This driver does not pass packets yet, lots of code is still missing.
The driver will remain disabled

Add a work-in-progress version of ice(4), a driver for Intel E810 devices.
Ported from FreeBSD.

This driver does not pass packets yet, lots of code is still missing.
The driver will remain disabled in kernel configs until it is ready.

At this stage, code for device initialization should be fairly complete.
Some hardware features will require additional firmware packages to be
loaded. My plan is to get things working in the basic "safe mode" first,
which does not require external firmware.

I will continue working on this driver in-tree, with funding from genua.
Help is welcome.

ok dlg@

show more ...

Add ixv(4), a driver for virtual functions of Intel 82598EB, 82559,
and X540. The driver was originally written by Intel and released as
ixv driver version 1.5.32 and ported to OpenBSD by Yuichiro N

Add ixv(4), a driver for virtual functions of Intel 82598EB, 82559,
and X540. The driver was originally written by Intel and released as
ixv driver version 1.5.32 and ported to OpenBSD by Yuichiro NAITO,
naito.yuichiro at gmail.com. tested by henson at acm.org and many
others.

ok jmatthew

show more ...

Attach psp(4) version 1.

Some AMD CPUs come with an older platform security processor. It
is detectet by PCI Id and has different register offsets. Move the
dynamic register offsets into psp_softc

Attach psp(4) version 1.

Some AMD CPUs come with an older platform security processor. It
is detectet by PCI Id and has different register offsets. Move the
dynamic register offsets into psp_softc. The PCI attach code is
now in a separate psp_pci.c file and detects the version of the psp
along with the ccp. The attach code is more verbose to display
where problems might occur. Now the ccp_wait() has 2 seconds
timeout, both for polling and interrupt. Also prevent a useless
bus_space_read_4().

OK hshoexer@

show more ...

Introduce qwz(4), a work-in-progress port of the Linux ath12k driver.

This driver is not working yet, it's a copy of qwx(4) which bit-by-bit will be
adjusted to work on the newer generation of chips

Introduce qwz(4), a work-in-progress port of the Linux ath12k driver.

This driver is not working yet, it's a copy of qwx(4) which bit-by-bit will be
adjusted to work on the newer generation of chips. Even though this is only a
minor bump over the previous generation, the changes are large enough that
bringup, debugging and long-term maintenance would suffer trying to squash them
into a single driver. This can be reconsidered once we have reached a stable
state.

show more ...

Add PCI support for ufshci(4). Tested on the Microsoft Surface Go 4.

CAVEATS:
The ufshci(4) openings need to be limited to 1 currently, otherwise
file system corruptions have been identified using

Add PCI support for ufshci(4). Tested on the Microsoft Surface Go 4.

CAVEATS:
The ufshci(4) openings need to be limited to 1 currently, otherwise
file system corruptions have been identified using PCI. I hope this
can be fixed soon.

Help and ok jsg@, kettenis@

show more ...

Import mwx(4) a driver for Mediatek MT7921 and MT7922 802.11ax devices

This is work in progress. Scan works, RX of packets is more or less there
but TX does not work yet. The packets are passed to t

Import mwx(4) a driver for Mediatek MT7921 and MT7922 802.11ax devices

This is work in progress. Scan works, RX of packets is more or less there
but TX does not work yet. The packets are passed to the chip but get stuck
or ignored there. It is easy to hang the device or the system since device
reset is not quite right (like many other bits).

Also this is only for MT7921 right now since I have no access to a MT7922
device.

Lots of pushing from deraadt@ to commit this now.

show more ...

Introduce qwx(4), a work-in-progress port of the Linux ath11k driver.

This driver is not working yet. Scanning almost works but a lot more
work remains to be done. So far most of the porting work wa

Introduce qwx(4), a work-in-progress port of the Linux ath11k driver.

This driver is not working yet. Scanning almost works but a lot more
work remains to be done. So far most of the porting work was done by
myself, with some help from mpi, patrick, and kettenis.

Obviously this driver remains disabled for now. Enable relevant lines
in the kernel config if you want to help out with development.

At present firmware files must be obtained manually and placed
in the directory /etc/firmware/qwx/WCN6855/hw2.1/
This will be improved later.

Thanks to the OpenBSD Foundation for supporting this effort.

show more ...

Add initial support for Elkhart Lake ethernet to dwqe(4).

For now, only attach to PSE0/RGMII (device ID 0x4ba0) which is the
only device I have access to for testing.

There is a known problem where

Add initial support for Elkhart Lake ethernet to dwqe(4).

For now, only attach to PSE0/RGMII (device ID 0x4ba0) which is the
only device I have access to for testing.

There is a known problem where Tx throughput is lower than expected.
This is being looked into.

ok kettenis@

show more ...

add iosf(4), a driver for the Intel OnChip System Fabric

The OnChip System Fabric is mostly an implementation detail on a
bunch of Intel SoC platforms we usually don't care about, except
on some of

add iosf(4), a driver for the Intel OnChip System Fabric

The OnChip System Fabric is mostly an implementation detail on a
bunch of Intel SoC platforms we usually don't care about, except
on some of these machines there are devices shared between the
kernel and the platform that need to coordinate. The iosf(4) driver
allows the kernel to talk via a mailbox interface to take and
release a semaphore that the hardware also uses to lock around
accesses to some components.

There are two ways to talk to the mailbox interface, one via mmio
ops on an INT33BD acpi device. The other is via magic pci conf space
operations on the pci host device. This provides a generic iosf
driver with attachment glue for both acpi and pci so either can be
used. According to linux, the pci ops are a lot more reliable and
less buggy, so if both acpi and pci are available we will prefer
the pci ops after they attach.

I found this because I got a Dell Wyse 3040, which is a cherry
trail/braswell system that has an acpitz(4) which talks to a tipmic(4)
device attached to dwiic(4) on acpi. This box almost always locked
up by the time it got to showing the console login prompt, and it
turns out one of the reasons for this is because acpitz was touching
the tipmic device at the same time the powerunit on the platform
was also trying to use it. The tipmic device lists the iosf mailbox
as a dependency, and the dwiic controller has a _SEM property, both
of which indicate we should use an iosf device to coordinate iic
ops when talking to the tipmic.

This adds the code, but doesn't wire it into dwiic or the build yet.

help from patrick@ jsg@ kettenis@
ok kettenis@ patrick@

show more ...

ngbe(4), a driver for Wangxun WX1860 series Gigabit Ethernet devices.
Written based on the vendor driver for Linux.
Thanks to WangXun for relicensing their vendor driver to ISC.

Special thanks to mi

ngbe(4), a driver for Wangxun WX1860 series Gigabit Ethernet devices.
Written based on the vendor driver for Linux.
Thanks to WangXun for relicensing their vendor driver to ISC.

Special thanks to miod@ for reviewing and providing valuable input.

ok miod@

show more ...

If we've created multiple queues, set up an RSS key and indirection table
to distribute received packets across the queues.

ok dlg@

If enough MSI-X vectors are available, set up multiple tx and rx queues.
In multi-vector mode, the MSI-X vector number is the same as the irq number
on the nic, so use vector/irq 0 for link interrupt

If enough MSI-X vectors are available, set up multiple tx and rx queues.
In multi-vector mode, the MSI-X vector number is the same as the irq number
on the nic, so use vector/irq 0 for link interrupts, then assign one to
each pair of rx and tx queues. We don't configure RSS yet, so packets
will only be received on the first queue, but they can be transmitted on
any queue.

ok dlg@

show more ...

Add igc(4), a driver for the Intel 2.5Gb Ethernet controllers.

Ported by kevlo@
ok jmatthew@

Remove hifn(4), safe(4), and ubsec(4) crypto drivers. They require
the asynchronous crypto API which makes progress in MP difficult.
The hardware is rarely available. They support only obsolete cry

Remove hifn(4), safe(4), and ubsec(4) crypto drivers. They require
the asynchronous crypto API which makes progress in MP difficult.
The hardware is rarely available. They support only obsolete crypto
algorithms. Scheduling crypto tasks via PCI is probably slower
than the CPU, especailly as modern CPUs have their own accelerators.

show more ...

aq(4) driver for Aquantia 1/2.5/5/10Gb/s PCIe ethernet adapters

Adds support for Aquantia AQC1xx family of PCIe ethernet adapters. This
driver supports 1Gbps through 10Gbps modes of operation based

aq(4) driver for Aquantia 1/2.5/5/10Gb/s PCIe ethernet adapters

Adds support for Aquantia AQC1xx family of PCIe ethernet adapters. This
driver supports 1Gbps through 10Gbps modes of operation based on the
hardware and media/switch capabilities.

The initial code was ported from NetBSD, with jmatthew@ finishing up
the Tx/Rx ring support and interrupt handler routine.

The driver only supports devices using firmware V2.

This diff enables aq(4) on riscv64 and amd64, the only platforms where
I have tested the driver, but it likely works on other architectures
as well.

show more ...

If MSI-X vectors are available, create multiple tx/rx queues, configure
RSS, and use the RSS hash value as a flow ID for received packets.

ok dlg@

intrmap attribute missing from mcx; ok dlg

use the system stoeplitz key instead of a random one.

while here, stash the rss hash value from rx descriptors in the
mbuf as a flow id.

enable multiq support for ix.

this is an updated version of a diff from christiano haesbaert by way of
mpi@ to enable the use of multiple tx and rx rings with msi-x. now
that patrick@ got interrupts

enable multiq support for ix.

this is an updated version of a diff from christiano haesbaert by way of
mpi@ to enable the use of multiple tx and rx rings with msi-x. now
that patrick@ got interrupts on multiple cpus working on arm64, i
can commit this.

the main changes are to use an intrmap pointer as the flag for
whether msix has been enabled or not, and to use the intrmap to
establish vectors on multiple cpus.

tested by hrvoje popovski

show more ...

Set up a second level flow table for RSS and switch the root flow table
entries to forwarding packets to it. The RSS flow table contains flow
table entries that match specific types of traffic and s

Set up a second level flow table for RSS and switch the root flow table
entries to forwarding packets to it. The RSS flow table contains flow
table entries that match specific types of traffic and send them to TIRs
set up to hash on the appropriate fields, then deliver packets through an
RQT to all our rx queues. We still only have one queue, but now all we
need to do is plug in an intrmap to add more.

ok dlg@

show more ...

add rss/toeplitz support for 710 chips.

this basically distributes incoming packets over the rx rings, where
without this they would all land on ring 0.

note that the 722 stuff is stubbed out at th

add rss/toeplitz support for 710 chips.

this basically distributes incoming packets over the rx rings, where
without this they would all land on ring 0.

note that the 722 stuff is stubbed out at the moment. i don't have
an x722 to test with, so it's hard to get motivated to write the
code for it.

this is based on stuff supplied by christiano haesbaert.

show more ...

use intrmap to set up multiple queues across multiple cpus.

ixl(4) is only enabled on amd64 and sparc64, and both of them now
support pci_intr_establish_cpu(), so it is safe to apply this.

a few th

use intrmap to set up multiple queues across multiple cpus.

ixl(4) is only enabled on amd64 and sparc64, and both of them now
support pci_intr_establish_cpu(), so it is safe to apply this.

a few things to note:

- the chip only supports a power of 2 number of queues, (ie, 1, 2,
4, 8, etc), so this also tests the INTRMAP_POWEROF2 flag to
intrmap_create. i tested this on a box with 6 cpus and it did the
right thing.
- the chip can support a lot of vectors, but we're limiting it to
8 for now.
- rss with toeplitz is not implemented yet, so all rxed packets end
up on the 0th queue for now.

jmatthew@ had done most of the work already, and christiano haesbaert
provided some hints to motivate me to work on this bit of it.

tested by jmatthew@ on sparc64
ok jmatthew@

show more ...

enable multiple queues (and interrupts on multiple cpus) on vmx(4).

im doing this with vmx(4) because it only exists on two archs (well,
one and a half archs really) so any impact is localised. most

enable multiple queues (and interrupts on multiple cpus) on vmx(4).

im doing this with vmx(4) because it only exists on two archs (well,
one and a half archs really) so any impact is localised. most other
drivers i'm working on are enabled on 3 or 4 archs, and we're still
working on the interrupt code on those archs.

in the meantime vmx(4) can be used as a reference driver on how to
implement multiq. it shows the use of rss, toeplitz, intrmap, and
interrupts on multiple cpus. it's also a relatively simple device,
which makes it easier to understand the above features.

note that vmx(4) seems to advertise 25 msi-x vectors. it appears
that the intention is that 16 of these vectors are supposed to be
used for rx, 8 for tx, and 1 for events (eg, link up and down).
we're keeping things simple for now and using a maximum of 8 vectors
for both tx and rx, and one for events.

this is mostly based on work that jmatthew@ did, but it's simplified
now cos intrmap makes things easier.

show more ...

configure toeplitz using the kernel stoeplitz key if needed.

"if needed" basically means if more than 1 queue is set up, then
set up rss.

again, i think jmatthew@ wrote most of this, but im sniping

configure toeplitz using the kernel stoeplitz key if needed.

"if needed" basically means if more than 1 queue is set up, then
set up rss.

again, i think jmatthew@ wrote most of this, but im sniping it cos
of the stoeplitz integration.

show more ...

Add a PCI attachment driver for com(4). Intel has been removing legacy
I/O-Ports on recent machines. Instead the UARTs are memory mapped PCI-
devices, as part of a so-called Low Power Subsystem (LP

Add a PCI attachment driver for com(4). Intel has been removing legacy
I/O-Ports on recent machines. Instead the UARTs are memory mapped PCI-
devices, as part of a so-called Low Power Subsystem (LPSS).

Such an LPSS is also used for I2C and SPI, though they use different PCI
device ids. Each LPSS contains the actual device, and some registers to
control clocks, resets, etc. These private registers need to be saved
and restored upon suspend/resume. Also we should read the current clock
settings to calculate the frequency supplied to the device.

The UART controller itself is based on Synopsys DesignWare IP, like
we're used to from various ARM-based machines

ok kettenis@

show more ...