Age | Commit message (Collapse) | Author |
|
unused but intended to be used to correlate audio and wskbd devices.
ok ratchov@
|
|
|
|
new hardware support includes
Intel
ehl/Elkhart Lake (embedded)
jsl/Jasper Lake (atom)
rkl/Rocket Lake (desktop)
AMD
van gogh APU (gfx1033)
yellow carp / rembrandt APU (gfx1035?)
Ryzen 6000 APU
navy flounder / navi 22 (gfx1031)
RX 6700, RX 6700 XT, RX 6700M, RX 6800M, RX 6850M XT
dimgrey cavefish / navi 23 (gfx1032)
Pro W6600, Pro W6600M, RX 6600, RX 6600 XT, RX 6600M,
RX 6600S, RX 6650M, RX 6650M XT, RX 6700S, RX 6800S
beige goby / navi 24 (gfx1034)
RX 6500 XT, RX 6400, RX 6500M, RX 6300M
Thanks to the OpenBSD Foundation for sponsoring this work
niklas@ for helping with ttm and amdgpu and patrick@ for adapting
rockchip drm.
|
|
To fix Allwinner H6's UART problem, need to add dw-apb-uart special code.
ok kettenis@
|
|
feedback and ok tb@ jmc@ ok ratchov@
|
|
|
|
everyone else seems to use ETHERTYPE_EAPOL, and as a bonus it also
appears to be more correct.
ok deraadt@ stsp@
|
|
|
|
ok visa@
|
|
don't give any traffic to whoever registered it afterwards
ok claudio@ stsp@
|
|
firmare names on Apple M1 Pro/Max and Apple T2 Macs.
|
|
divisible by 1400, the last chunk isn't marked with an end flag.
ok tobhe@
|
|
will take care of releasing them, as otherwise initialization would
fail some of the time. That chip also contains 3 of these, so make
sure we reset all of them. Necessary on Apple M1 Pro/Max.
|
|
|
|
|
|
a few more chips.
|
|
reliability when bwfm is used as an access point.
ok patrick@
|
|
and close flowrings using bwfm_do_async().
Reported by and ok kettenis@
|
|
Ported from run(4) with legacy chipsets removed.
Not yet enabled in the build.
ok stsp@ jmatthew@
|
|
feedback and ok millert@
|
|
Interrupt sharing did not work correctly when two dwiic(4) devices
share an interrupt line. We ended up with an interrupt storm.
One of the two interrupt handlers would see interrupt status bits set
to zero but claim the interrupt regardless. The second handler would
never get to run, and the interrupt condition on the second device was
not cleared as a result. Fix this by returning zero from dwiic_intr()
if the device's interrupt status bits read back as zero.
The storm occurred as soon as X11 was started. xenodm(1) never managed to
display its login prompt. Observed on the Thinkpad Helix2 which had been
unable to start X since dwiic(4) started to attach on this machine in 2018.
(I already saw the problem back then but never dug into it, and temporarily
lost access to helix2 hardware for a long time.)
With help from jcs@ who provided debugging hints already back in 2018.
ok kettenis@
|
|
data. Also add the MAC address to the nvram data when there is a
"local-mac-address" property in the device tree. This makes bwfm(4) work
with the firmware/nvram/clm_blob files provided with MacOS on the Apple
M1 Macs.
ok patrick@
|
|
For the moment we use either the 40MHz rate set or the 20 MHz one,
depending on whether our peer supports 40MHz channels.
If this turns out to be suboptimal we could probe the 40MHz and 20MHz
rate sets separately to detect which one works better.
The same applies to use of the short guard interval (SGI), which is
either always on or off at the moment. Again, probing for this could
be added later if needed.
|
|
that are marked "ok". Linux has some workarounds for this and checks whether
the status word has error bits set in it regardless of the bit that marks
the frame as "ok". Adapt this workaround to our driver and drop the frame
after setting input errors. This doesn't filter out all corrupted frames,
but it does keep things down to a level where it doesn't fill up the node
cache anymore when athn(4) is used in hostap mode.
Seen with:
athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: intx
athn0: AR9280 rev 2 (2T2R), ROM rev 16, address xx:xx:xx:xx:xx:xx
ok stsp@
|
|
ok patrick@
|
|
serial drivers.
ok patrick@
|
|
device into D3 and do a hot-resume if possible. Otherwise we need to clean
up the resources to allow complete HW re-initialization to take place.
|
|
|
|
ok patrick@
|
|
at the very least it stops the compiler omgoptimising away important
code.
tested by and ok deraadt@ jmatthew@
|
|
ok mpi@
|
|
make NVMe on the Apple M1 stable. Hopefully we can figure out the real
issue in the future.
ok jmatthew@
|
|
make NVMe on the Apple M1 stable. Hopefully we can figure out the real
issue in the future.
ok jmatthew@
|
|
the connection because an AP is gone away, this makes sure we don't
end up picking a now non-existant AP over and over.
Another problem this works around is that when trying to re-join that
AP, the attempt to connect would not yield any event message from the
firmware, and then we would get stuck. Since we now definitely choose
a different AP, this issue does not show up.
ok stsp@
|
|
React to deauth/disassoc and link state events if we're
already past the SCAN stage.
ok stsp@
|
|
SSIDs are binary data, not NUL-terminated strings.
ok patrick@
|
|
directly after having successfully associated. In that case we should
ignore the message, because otherwise we re-scan, re-associate and then
get stuck in a loop. Ignoring the unsolicited assoc status even leads
to a successful connection.
Found by and ok gerhard@
|
|
It looks like twe was refactored in 2011 and one error check was missed.
While the device may no longer be widely used, this helps reduce the
coverity alert count.
CID 1453371
ok krw@
|
|
the limit after every character, and wait for the FIFO to empty before
sending out more bytes. With this I can now use ipmitool(1) to change
IPMI passwords on the Ampere eMAG.
ok kettenis@
|
|
a botched merge meant i was posting the previously used slot to the
chip to process before posting the current slot.
ok deraadt@
|
|
hardware support changes include
inteldrm: better support for tiger lake
amdgpu: support for navi12, navi21 "sienna_cichlid", arcturus
amdgpu: support for cezanne "green sardine" ryzen 5000 apu
Thanks to the OpenBSD Foundation for sponsoring this work,
patrick@ for helping adapt rockchip drm, kettenis@ and mpi@
for uvm discussions and various testers.
|
|
This fixes an issue introduced with our workaround for bogus michael
mic failures seen when hardware receives control frames. We do need
to ignore the michael mic failure in this case but we should not call
ieee80211_find_rxnode() on such frames unconditionally. Do this only
if the transmitter's address has already been cached.
When ieee80211_find_rxnode() is called with an unknown source MAC address
it will create a new entry in the node cache. Frames flagged as incorrectly
received by hardware should not be passed to ieee80211_find_rxnode() without
further verification to avoid creating bogus cache entries based on corrupt
frame headers.
Prompted by an issue seen by kettenis@ on arm64 where the node cache
contains bogus entries. This change doesn't fix the issue but it is
a step in the right direction regardless since it fixes one possible
cause for the issue.
ok kettenis@
tested by myself and Mikolaj Kucharski
|
|
brackets to manage operator precedence. Otherwise we'd attempt to sync
more than needed, which doesn't cause issues, but it's still wrong.
ok dlg@ jmatthew@
|
|
hopefully big endian still works.
|
|
"makes sense" jmatthew@
|
|
OK jsg@ deraadt@
|
|
This makes the NVMe storage on the Apple M1 machines actually work!
ok patrick@, dlg@
|
|
|
|
this paves the way for supporting the apple nvme storage controllers.
hopefully most of the remaining work on that is in the bus glue for
those controllers and this code won't need more tweaks.
hibernate still works, but it's relying on luck at the moment.
hibernate on arm64 and the apple controllers in particular will
almost certainly require more work here.
ok jmatthew@
|
|
the Apple NVME Storage (ans) controller is almost but not quite a
vanilla nvme controller. one difference is that it doesnt attach
to a pci bus, so it will need custom bus glue to attach on those
machines. the other differences are around command submission.
vanilla nvme command submission is done via rings where the host
fills in one or more entries on the ring and then posts where the
ring is up to in a doorbell. ans nvme command submission is done
via an array of command slots where the host picks a slot and then
posts every slot number it fills in to a doorbell instead. this is
kind of clever because once a command slot is allocated, you don't
need any coordination between multiple cpus using that array of
slots to fill in and post the entry they were allocated. on the
other hand, it's different, so the code needs to be specialised.
ans also seems to have some weird iommu thing that needs to be
maintained as commands are posted and completed.
the nvme_ops struct will allow vanilla and ans controllers to provide
their own backens for these different semantics.
ok jmatthew@
|