| Age | Commit message (Collapse) | Author |
|---|
|
new hardware support includes
AMD
Raphael, Ryzen 7000 desktop, gfx1036/GC 10.3.6
Mendocino, Ryzen & Athlon 7020 Series mobile APU, gfx1037/GC 10.3.7
Navi 31, gfx1100 dGPU, GC 11.0.0, Radeon RX 7900 XT/XTX
gfx1101 dGPU
gfx1102 dGPU
gfx1103 APU
Thanks to the OpenBSD Foundation for sponsoring this work.
|
|
from iwm(4), which also looks at the TX_MGMT_ONLY flag. We don't expect
that flag to be ever set for bwfm(4), but it shouldn't hurt and it keeps
things consistent across drivers.
This fixes issues with suspend/resume (including firmware crashes seen on
the M2 Macbook Air).
ok patrick@, stsp@
|
|
New warning -Warray-parameter is a bit overzealous.
ok millert@ tb@
|
|
ok jmatthew@
|
|
|
|
Make drivers which do *not* adverise AUDIO_PROP_FULLDPLEX return ENXIO
in their open() if full-duplex mode was requested.
This way, sys/dev/audio.c:audio_open() will fail immediately rather than
later through the to-be-removed get_props() check.
These are all drivers which simply don't support full-duplex mode.
In device-tree based drivers like simpleaudio(4)/rkiis(4) and newer Apple
ones like aplaudio(4)/aplmca(4), this adds a new open() stub to the
low-level drivers which merely does the duplex check.
My Pinebook Pro keeps playing audio and recording silence with this diff
just like before (rkiis(4) is currently play-only):
simpleaudio0 at mainbus0
simpleaudio1 at mainbus0
audio0 at simpleaudio1
$ aucat -i song69.wav -o rec.wav
OK ratchov miod
|
|
The property bits of audio(9) are obsolete and ought to be removed
completely.
sys/dev/audio.c:audio_open() currently uses get_props() to bail out if
read *and* write was requested on a non-duplex driver.
Drivers that currently support playing but not recording need adjustment
before the API can be cleaned up.
Drivers that advertise themselves as full duplex, i.e. those that always
return AUDIO_PROP_FULLDUPLEX unconditionally in their get_props() currently
always succeed this check.
As this is the only property, losen audio_open()'s DIAGNOSTIC check and only
do the duplex check if the driver provides get_props().
This allows for simple removal of get_props() from full-duplex drivers
without adding any other code or without changing functionality.
This includes all audio drivers under sys/dev/pci/ (maestro(4) being the
only unfinished exception here).
Other drivers as well as the API change can then follow in smaller diffs.
This builds on amd64, arm64, i386, macppc and sparc64.
amd64 with azalia(4) still plays, records as well as plays and records
at the same time on my X230 as tested with
$ aucat -i play.wav [-o rec.wav]
alpha and hppa tests by miod
OK ratchov miod
|
|
ah{c,d}_find_pci_device() already return their members as const.
OK krw
|
|
1st edition of Kernighan and Ritchie's The C Programming Language, to
that of the parameter-type-list form described in the ANSI X3.159-1989
standard.
In ISO/IEC 9899:2023 drafts, there is only one form of function definition.
"N2432 Remove support for function definitions with identifier lists".
ok kettenis@
|
|
to assign a quality to RTC implementation and pick the "best" RTC if a
system has multiple RTCs (or multiple interfaces to an RTC). This allows
us to prefer a battery-backed I2C RTC over an RTC that is part of the SoC
which is only running of the SoC is powered. It also allows us to
work around issues with firmware RTC interfaces that may lie to us or
even crash the system.
This change makes sure the todr_quality member of the struct is always
initialized. In most cases the quality will be set to zero; further
adjustments of the quality for specific subsystems/architectures will follow.
ok cheloha@, patrick@
|
|
In case firmware initially comes up in FAULT state, reset the device and
give it one more chance to attach successfully. The Linux megaraid_sas
driver applies the same workaround in this case. There seems to be a bug
in some firmware versions which can trigger this behaviour; see mainline
Linux commit 6431f5d7c6025f8b007af06ea090de308f7e6881
Problem observed by me with mfii(4) attached via KVM PCI-passthrough:
mfii0 at pci0 dev 2 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05: msi
mfii0: firmware fault
With this workaround in place, attachment succeeds and the device works:
mfii0 at pci0 dev 2 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05: msi
mfii0: firmware fault; attempting full device reset, this can take some time
mfii0: "RAID Ctrl SAS 6G 1GB (D3116C)", firmware 23.29.0-0019, 1024MB cache
Tested for regressions on bare metal by Hrvoje with two different adapters:
mfii0 at pci1 dev 0 function 0 "Symbios Logic MegaRAID SAS3508" rev 0x01: msi
mfii0: "PERC H740P Mini ", firmware 51.16.0-4076, 8192MB cache
mfii0 at pci4 dev 0 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05: msi
mfii0: "ServeRAID M5110", firmware 23.34.0-0023, 512MB cache
ok jmatthew@
|
|
ok jcs@
|
|
c99 6.11.5:
"The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature."
ok miod@ tb@
|
|
- enable Tx/Rx aggregations of individual 802.11 frames on the USB bus
- in urtwn_fw_loadpage(), the maximum block size is 254 bytes rather than
196 bytes
- clear the interrupt status register
- no need to disable BAR for USB devices and set NAV limit
ok stsp@, jmatthew@
|
|
ok miod@
|
|
ok stsp@, jmatthew@
|
|
|
|
ok stsp@, jmatthew@, kevlo@
|
|
|
|
This happens on the new 14" and 16" Macbook Pro where we deliberately use
a framebuffer that skips the first few lines to avoid "the notch".
The offset of the first pixel is added to struct wsdisplay_fbinfo. The
stride is added as well, mirroring the value returned by the
WSDISPLAYIO_LINEBYTES ioctl, such that we can retire that one in the
future. A compat ioctl is implemented to help the transition. The compat
code will be removed after OpenBSD 7.3 has been released.
ok miod@
|
|
not return any pointers without lock anymore.
OK mvs@ mbuhl@
|
|
to make make media structures MP safe.
OK mvs@
|
|
|
|
Also remove unneeded includes of <sys/poll.h> and <sys/select.h>.
Some addenda from jsg@.
OK miod@ mpi@
|
|
The net80211 stack detach routine can trigger more tasks to be scheduled,
e.g. to delete WPA keys. So let's not free the driver's taskq before
net80211 has been detached.
fixed with and ok by mpi@
Crash reported by mlarkin@ who yanked the USB cable to test our fix.
|
|
ok miod@
|
|
pluart_param().
|
|
|
|
It's most likely that users have the wrong baud rate in /etc/ttys as
this was corrected in revision 1.11 of sys/dev/ic/pluart.c. Make sure to
change the console baud rate from 38400 to 115200 in /etc/ttys before
upgrading.
ok visa@
|
|
ok jsg@
|
|
setup
OK dlg@
|
|
but instead defaults to 38400. This in turn causes the same baudrate to
end up in /etc/ttys during installation. Note that this is not a problem
as of now since pluart does not support changing the baudrate just yet.
Instead, honor and propagate the baudrate given to pluartcnattach()
while attaching the hardware console.
ok visa@
|
|
tx interrupts.
Special treatment of Server Base System Architecture (SBSA) generic UART
devices is required as presence of the interrupt trigger level register
is not guaranteed. Therefore treat such devices of having a 1-byte FIFO.
ok visa@
|
|
unbreaks the build on bigendian archs.
found by deraadt@
|
|
some of them are 16 bit, so check frequently.
now i can see what packets my apu1 is dropping in hardware.
ok claudio@
|
|
ending up in an odd state during netboot in which u-boot (in my case)
hands of the device in a somewhat initialized state.
ok kettenis@
|
|
GENET_DMA_DEFAULT_QUEUE.
ok kettenis@
|
|
Sven Wolf noticed that scans on ral(4) are buggy ever since I added a new
field to this struct. Turns out a lot of drivers were initializing fields
one-by-one, leaving any newly added fields uninitialized by default.
Affected drivers may report wrong channel numbers for received beacons.
The net80211 stack will discard such beacons, assuming they were received
on the wrong channel due to signal leakage. Scanning is broken as result.
ok miod@
|
|
ok krw@
|
|
ok miod@
|
|
ok miod@
|
|
ok mpi@ ratchov@ "More const is good" deraadt@
|
|
the channel on which a frame was received.
ieee80211_inputm() was expecting that ic->ic_bss->ni_chan would correspond
to the channel which is currently being scanned. This dates back to older
devices which are manually tuned to the next channel by the driver during
SCAN->SCAN state transitions.
However, this approach is very awkward for drivers which scan across a
whole range of channels in firmware. Such drivers had an ugly workaround
in place which tweaked ni_chan for each received frame.
Introduce a channel number field in the Rx info struct which drivers
can use to indicate the channel on which a frame was received.
If this field is set, net80211 will use it instead of using the current
channel of ic_bss. Use this new mechanism in all affected drivers.
Tested by jmc@, sthen@, and myself on iwm(4) and iwx(4).
Changes to iwn(4) and bwfm(4) are the same mechanical changes to get rid
of the ni_chan tweak, and are therefore expected to work.
ok sthen@ dlg@
|
|
The "driver rate" bit which tells firmware to use the driver-provided
Tx rate is in a different spot of Tx descriptor double word 3.
Fix the corresponding macro definition.
The device was sending all frames at CCK1 because of this bug, regardless
of the Tx rate the driver had chosen.
tcpbench before:
Conn: 1 Mbps: 0.808 Peak Mbps: 1.108 Avg Mbps: 0.808
tcpbench with fix:
Conn: 1 Mbps: 21.078 Peak Mbps: 21.078 Avg Mbps: 21.078
ok jmatthew@
|
|
|
|
the revision and ranges from 16 to 32 bytes.
Special treatment of Server Base System Architecture (SBSA) generic UART
devices is required as presence of the interrupt trigger level register
is not guaranteed. Therefore treat such devices of having a 1-byte FIFO.
With help from kettenis@ and ok visa@
|
|
lm700x: az, rt
tc921x: sfr
pt2254a: sfr, sf2r
|
|
used by wdsc on sgi (removed in 2021)
ok krw@
|
|
ok deraadt@
|
|
command, which is indicated by the "scan_ver" firmware variable.
ok patrick@
|
