Age | Commit message (Collapse) | Author |
|
Some controllers generate 128 bit WWIDs for RAID volumes but only has a
64-bit field to report it to the host, so it only puts the
vendor-specified part here (last half of ID string printed when sd*
attaches matches sl->port_wwn in reverse).
As such IDs are not IEEE NAA compliant, OpenBoot PROM -at least on SPARC-
sets the highest nibble to three by convention to mark such volumes as
RAID volumes so that the OS (Solaris) may identify it as such.
This is the last missing piece to make booting off hardware RAID on sparc64
just work; autoconf(9) is now able to match the port WWN against the
bootpath to eventually identify the volume as the root device.
Feedback jmatthew deraadt
OK jmatthew
|
|
|
|
|
|
|
|
ok jsg@
|
|
|
|
From Allen Pais
55248674330101fb3ccf7cec8b729e8e067e5f71 in linux 4.19.y/4.19.92
81de29d842ccb776c0f77aa3e2b11b07fff0c0e2 in mainline linux
|
|
From Colin Ian King
6032df37982ab948e6d2a41744deabef9181bec9 in linux 4.19.y/4.19.92
17cf678a33c6196a3df4531fe5aec91384c9eeb5 in mainline linux
|
|
From Sam Bobroff
9234c9254e22da026e351cd4b7028e216abbeef0 in linux 4.19.y/4.19.92
3d0e3ce52ce3eb4b9de3caf9c38dbb5a4d3e13c3 in mainline linux
|
|
From Pan Bian
2c528fa3c40d16c61da38a9f4fa7a0ce71df4db3 in linux 4.19.y/4.19.92
946ab8db6953535a3a88c957db8328beacdfed9d in mainline linux
|
|
From Hawking Zhang
7b3fe663da71273710fc8f7fa0c71515e96c6786 in linux 4.19.y/4.19.92
58f46d4b65021083ef4b4d49c6e2c58e5783f626 in mainline linux
|
|
From David Galiffi
59fc1675b5731b6cb57ad668ab2022add0433d5d in linux 4.19.y/4.19.92
dd998291dbe92106d8c4a7581c409b356928d711 in mainline linux
|
|
From Rodrigo Siqueira
5d60d398148d00a6fc8f0e1844055be3441e1d01 in linux 4.19.y/4.19.92
aed6105b28b10613f16c0bfe97525fe5a23338df in mainline linux
|
|
From Christian Koenig
16bb81d541f31b163563fea951ccb30b0def0c0a in linux 4.19.y/4.19.92
6817bf283b2b851095825ec7f0e9f10398e09125 in mainline linux
|
|
From Sean Paul
f015785ae7fbf7a817b74b4001f92ca3070aa718 in linux 4.19.y/4.19.92
268de6530aa18fe5773062367fd119f0045f6e88 in mainline linux
|
|
ok mpi@ bluhm@
|
|
make the structs const so that the data are put in .rodata.
OK mpi@, deraadt@, anton@, bluhm@
|
|
ok kn@
|
|
don't depend on indirect inclusion from acpidev.h
|
|
|
|
|
|
file or not
found by olivier@burelli.fr
|
|
ok mpi@
|
|
ok jsg@
|
|
On sparc64, booting root devices off hardware RAID volumes requires the port
WWN to be set for autoconf(9) to match the disk against the bootpath and
therefore identify it as root device.
Pointed out by kettenis
Input and OK jmatthew
|
|
tested by and ok kn@
|
|
OK jan@
|
|
|
|
Those can be found in SPARC T4 machines, mine has the F80 800G model.
Since other devices with different flash configurations use the same
vendor/product ID, use the LSI chip name as product name as pointed out
by jmatthew, thanks.
OK jmatthew deraadt
|
|
ok kettenis@
|
|
ok kettenis@
|
|
|
|
drops graphics buffers that are cached and not in active use.
Help from beck@ for pointing out how to hook this up to our pagedaemon.
ok jsg@
|
|
AMD SoCs/chipsets.
From James Hastings
|
|
These are straightforward except for the tsleep(9) conversion. ratchov@
had a bit to say about that code:
https://marc.info/?l=openbsd-tech&m=157665936017373&w=2
> The problem is that close(2) may reset the transmitter before the few
> bytes of its internal buffer is sent on the wire; there's no "wait for
> completion" feature in such simple hardware, so we just wait few
> milliseconds.
>
> The transmitter buffer size is around 16 bytes, the byte rate is 3125
> bytes/second. So if we wait at least 16B / 3125B/s = 5.12ms, we're
> safe. Waiting 10ms-20ms is enough and is unnoticeable.
Hence, in this diff we wait a flat 20ms in that situation.
ok ratchov@
|
|
From Alex Deucher
33c1d3bc1d5e1062844a31acc85eb50f9447f006 in linux 4.19.y/4.19.91
008037d4d972c9c47b273e40e52ae34f9d9e33e7 in mainline linux
|
|
ok claudio@
|
|
than writing a hard-coded bit pattern to this register.
Matches what Intel's Linux driver does, so it should be the right thing to do.
Tested on 8265 by Tracey Emery and myself.
|
|
Matches what iwm(4) has been doing for a long time to ensure that
a good initial Tx rate will be chosen.
Tested by Tracey Emery on AR9281.
|
|
|
|
Some drivers have returned ENXIO (6) if the device is not available
which incorrectly translates into POLLPRI|POLLOUT (2|4) in userland.
Change it to POLLERR for now, but it might as well be POLLHUP.
OK mpi@
|
|
There is an existing allocsize variable tracking size of allocations,
turns out we can pass it to free in the error path.
OK florian@, mpi@
|
|
ok deraadt@, dlg@
|
|
against codes in the known-codes table, like Linux does it.
Mark the known-codes table static so it won't ever collide with
symbols declared elsewhere in the kernel.
Also add some more cause codes found in iwlwifi. I still keep hitting
firmware SYSASSERT codes that aren't declared in this table, though :(
These changes only affect IWM_DEBUG builds.
|
|
Firmware-based Tx retries were disabled when it was found that MiRA
makes better choices while probing with a constant Tx retry rate.
Before that change, high Tx rates looked better than they actually
were. The change resulted in less retries and thus higher throughput
because a lower, but actually working, initial Tx rate eventually
became the preferred choice.
However, disallowing retries at lower rates also resulted in increased
amounts of observable packet loss, especially while the connection to
the AP was still fresh and bad Tx rates had not been discovered yet.
To get the best of both worlds, use a constant Tx rate for retries while
MiRA is probing and otherwise allow firmware fallback to lower rates.
tested by Tracey Emery, pamela, jasper, and myself, on 7265/8265/9260
|
|
in inteldrm(4).
ok guenther@
|
|
|
|
ok ratchov@
|
|
While FIDO/U2F keys were already supported by the generic uhid(4)
driver, this driver adds the first step to tighten the security of
FIDO/U2F access. Specifically, users don't need read/write access to
all USB/HID devices anymore and the driver also improves integration
with pledge(2) and unveil(2): It is pledge-friendly because it doesn't
require any ioctls to discover the device and unveil-friendly because
it uses a single /dev/fido/* directory for its device nodes.
It also allows to support FIDO/U2F in firefox without further
weakening the "sandbox" of the browser. Firefox does not have a
proper privsep design and many operations, such as U2F access, are
handled directly by the main process. This means that the browser's
"fat" main process needs direct read/write access to all USB HID
devices, at least on other operating systems. With fido(4) we can
support security keys in Firefox under OpenBSD without such a
compromise.
With this change, libfido2 stops using the ioctl to query the device
vendor/product and just assumes "OpenBSD" "fido(4)" instead. The
ioctl is still supported but there was no benefit in obtaining the
vendor product or name; it also allows to use libfido2 under pledge.
With feedback from deraadt@ and many others
OK kettenis@ djm@ and jmc@ for the manpage bits
|
|
Some numbers may be wrong but it a start and further fixes can
happen in tree. Especially the LPDDRx case is untested.
OK deraadt@
|