OpenBSD cvs log

created 2020-07-28T21:32:56Z
begin 2020-05-31T00:00:00Z
end 2020-06-01T00:00:00Z
path src/sys
commits 12

date 2020-05-31T03:14:59Z
author dlg
files src/sys/net/pipex.c log diff annotate
message use ip{,6}_send instead of ip{,6}_output for l2tp and pptp.

pipex output is part of pppx and pppac if_start functions, so it
can't rely on or know if it already has NET_LOCK. this defers the
ip output stuff to where it can take the NET_LOCK reliably.

tested by Vitaliy Makkoveev, who also found that this was necessary
after ifq.c 1.38 and provided an excellent analysis of the problem.
ok mpi@

date 2020-05-31T04:58:38Z
author jsg
files src/sys/dev/pci/azalia.c log diff annotate
message match on pci id for azalia device with wrong subclass

The HP EliteBook 850 G6 has an Intel 300 Series HD Audio device with pci
subclass of MULTIMEDIA_AUDIO instead of the expected MULTIMEDIA_HDAUDIO.
Match on the pci id to handle this.

Reported and tested by Bruno Flueckiger.
ok kettenis@ deraadt@

date 2020-05-31T06:23:56Z
author dlg
files src/sys/arch/alpha/alpha/machdep.c log diff annotate
src/sys/arch/alpha/include/cpu.h log diff annotate
src/sys/arch/amd64/amd64/machdep.c log diff annotate
src/sys/arch/amd64/include/cpu.h log diff annotate
src/sys/dev/rnd.c log diff annotate
message introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.

rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it doesn't
use nanotime to get a monotonically increasing set or ordered and
accurate timestamps, it just wants something with bits that change.

there's been discussions for years about letting rnd use a clock
that's super fast to read, but not necessarily accurate, but it
wasn't until recently that i figured out it wasn't interested in
time at all, so things like keeping a fast clock coherent between
cpu cores or correct according to ntp is unecessary. this means we
can just let rnd read the cycle counters on cpus and things will
be fine. cpus with cycle counters that vary in their speed and
arent kept consistent between cores may even be desirable in this
context.

so this is the first step in converting rnd.c to reading cycle
counter. it copies the nanotime backend to each arch, and they can
replace it with something MD as a second step later on.

djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits.
thanks to visa for his eyes.
ok deraadt@ visa@
deraadt@ says he will help handle any MD fallout that occurs.

date 2020-05-31T06:23:57Z
author dlg
files src/sys/arch/arm/include/cpu.h log diff annotate
src/sys/arch/arm64/arm64/machdep.c log diff annotate
src/sys/arch/arm64/include/cpu.h log diff annotate
src/sys/arch/armv7/armv7/armv7_machdep.c log diff annotate
src/sys/arch/hppa/hppa/machdep.c log diff annotate
src/sys/arch/hppa/include/cpu.h log diff annotate
src/sys/arch/i386/i386/machdep.c log diff annotate
src/sys/arch/i386/include/cpu.h log diff annotate
src/sys/arch/landisk/landisk/machdep.c log diff annotate
src/sys/arch/loongson/loongson/machdep.c log diff annotate
src/sys/arch/luna88k/luna88k/machdep.c log diff annotate
src/sys/arch/m88k/include/cpu.h log diff annotate
src/sys/arch/macppc/macppc/machdep.c log diff annotate
message introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.

rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it doesn't
use nanotime to get a monotonically increasing set or ordered and
accurate timestamps, it just wants something with bits that change.

there's been discussions for years about letting rnd use a clock
that's super fast to read, but not necessarily accurate, but it
wasn't until recently that i figured out it wasn't interested in
time at all, so things like keeping a fast clock coherent between
cpu cores or correct according to ntp is unecessary. this means we
can just let rnd read the cycle counters on cpus and things will
be fine. cpus with cycle counters that vary in their speed and
arent kept consistent between cores may even be desirable in this
context.

so this is the first step in converting rnd.c to reading cycle
counter. it copies the nanotime backend to each arch, and they can
replace it with something MD as a second step later on.

djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits.
thanks to visa for his eyes.
ok deraadt@ visa@
deraadt@ says he will help handle any MD fallout that occurs.

date 2020-05-31T06:23:58Z
author dlg
files src/sys/arch/mips64/include/cpu.h log diff annotate
src/sys/arch/octeon/octeon/machdep.c log diff annotate
src/sys/arch/powerpc/include/cpu.h log diff annotate
src/sys/arch/powerpc64/include/cpu.h log diff annotate
src/sys/arch/powerpc64/powerpc64/machdep.c log diff annotate
src/sys/arch/sgi/sgi/machdep.c log diff annotate
src/sys/arch/sh/include/cpu.h log diff annotate
src/sys/arch/sparc64/include/cpu.h log diff annotate
src/sys/arch/sparc64/sparc64/machdep.c log diff annotate
message introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.

rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it doesn't
use nanotime to get a monotonically increasing set or ordered and
accurate timestamps, it just wants something with bits that change.

there's been discussions for years about letting rnd use a clock
that's super fast to read, but not necessarily accurate, but it
wasn't until recently that i figured out it wasn't interested in
time at all, so things like keeping a fast clock coherent between
cpu cores or correct according to ntp is unecessary. this means we
can just let rnd read the cycle counters on cpus and things will
be fine. cpus with cycle counters that vary in their speed and
arent kept consistent between cores may even be desirable in this
context.

so this is the first step in converting rnd.c to reading cycle
counter. it copies the nanotime backend to each arch, and they can
replace it with something MD as a second step later on.

djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits.
thanks to visa for his eyes.
ok deraadt@ visa@
deraadt@ says he will help handle any MD fallout that occurs.

date 2020-05-31T09:08:33Z
author stsp
files src/sys/net80211/ieee80211_node.c log diff annotate
message Remove a dead assignment to ni_rsn_state in ieee80211_node_leave_rsn().

Patch by Mikolaj Kucharski

date 2020-05-31T09:11:12Z
author stsp
files src/sys/net80211/ieee80211_node.h log diff annotate
src/sys/net80211/ieee80211_pae_input.c log diff annotate
src/sys/net80211/ieee80211_pae_output.c log diff annotate
message Typo in WPA supplicant state machine: RNSA_SUPP_PTKDONE -> RSNA_SUPP_PTKDONE

date 2020-05-31T11:47:09Z
author kettenis
files src/sys/dev/fdt/sdhc_fdt.c log diff annotate
message DDR mode seems to work fine on the Rockchip RK3399.

tested by benno@

date 2020-05-31T18:12:04Z
author jcs
files src/sys/dev/usb/usbdevs log diff annotate
message add two Surface Go Type Cover models

date 2020-05-31T18:12:28Z
author jcs
files src/sys/dev/usb/usbdevs.h log diff annotate
src/sys/dev/usb/usbdevs_data.h log diff annotate
message regen

date 2020-05-31T18:15:36Z
author jcs
files src/sys/arch/amd64/conf/GENERIC log diff annotate
message add umstc(4) for Microsoft Surface Type Cover keyboards

date 2020-05-31T18:15:37Z
author jcs
files src/sys/dev/hid/hid.h log diff annotate
src/sys/dev/usb/files.usb log diff annotate
src/sys/dev/usb/umstc.c log diff annotate
message add umstc(4) for Microsoft Surface Type Cover keyboards