| Age | Commit message (Collapse) | Author |
|---|
|
|
|
introduced in 1.7 and preventing `o' and `p' keys from working as
intended. Reported by Anders Gustafsson.
From miod@
|
|
report id to signal that multiple ones should be claimed by the match
routines does not work. All valid report ids 1-255 cannot of course be
used and 0 which is reserved by the USB HID specification is internally
used to represents devices lacking an explicit report id.
Therefore, use presence of the claimed array to signal that multiple
report ids can be claimed.
Tested by gnezdo@
|
|
report ids conflict, extract the claim multiple report ids conditional
in order to minimize the required upcoming changes to resolve the
conflict.
Tested by gnezdo@
|
|
Tested:
4965: jsg
5300: stsp, Jan Stary
6030: Fred Crowsons
6200: stsp
6205: stsp, Josh Grosse
6300: okan, afresh1
|
|
No functional change, as this data is not being used anywhere yet.
|
|
Our driver was using the wrong data structure for RXON_ASSOC commands on
4965 devices. This resulted in fatal firmware errors during association.
Problem found and fix tested on 4965 by jsg@.
Patch also tested on 6200 by me.
|
|
UHIDEV_CLAIM_MULTIPLE_REPORTID conflict.
Breaks fido(4) as reported by gnezdo@
|
|
time without using sentinel that cannot be represented using a single
byte. Instead, use 0 as this report ID is reserved according to the USB
HID specification. Fixes attachment of some upd devices which exposes up
to 256 report IDs.
Thanks to Damien Couderc <openbsd at petrocore dot eu> for reporting and
testing.
|
|
This driver handles events triggered by GPIO keys such as lid status and
power button.
OK kettenis
|
|
|
|
ok jmatthew@
|
|
the reportid locator. The same locator was removed in 2004 making the routine
redundant.
ok gnezdo@ mpi@
|
|
Thanks to Damien Couderc <openbsd at petrocore dot eu> for testing and ok
gnezdo@
|
|
The "label" property is obsolete and "function" should be used,
but devices like the Raspberry Pi 4b still use it.
Detect LEDs on such machines:
-gpioleds0 at mainbus0: no LEDs
+gpioleds0 at mainbus0: "led0", "led1"
OK patrick
|
|
OK patrick
|
|
Fixes panic seen on the Pinebook Pro.
|
|
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@
|
|
we can access through the phy-handle. If there's no reference, keep doing
what we have been doing so far.
ok kettenis@
|
|
|
|
name "phys". To handle those, make sure that we look it up and in case it's
not there fall back to "fsl,usbphy".
ok kettenis@
|
|
Laurence Tratt reported firefox would hard lock a machine
with polaris12 with the ttm change from linux 5.10.77.
robert@ also hit the same problem.
|
|
From Thelford Williams
eb3b6805e3e9d98b2507201fd061a231988ce623 in linux 5.10.y/5.10.77
5afa7898ab7a0ec9c28556a91df714bf3c2f725e in mainline linux
|
|
From Christian Koenig
c21b4002214c1c7e7b627b9b53375612f7aab6db in linux 5.10.y/5.10.77
0db55f9a1bafbe3dac750ea669de9134922389b5 in mainline linux
|
|
Pointed out by Brad, thanks!
OK kettenis@, deraadt@
|
|
ok jsg@
|
|
i wanted to talk modbus to a thing using a uchcom rs485 adapter,
but i needed even parity enabled to do that which the code didnt
support. this pulls in the necessary changes from netbsd uchcom.c
r1.26. it does not pull in the reset changes in 1.26 because netbsd
r1.28 reverts the reset code back to what we have now.
existing functionality tested by felix kronlage-dammers
ok patrick@
|
|
|
|
OK deraadt@
|
|
installation happening w/o a node, and don't attempt to set WEP keys that don't
exist.
Should fix the '(null node)' panics reported by James Hastings.
ok stsp@
|
|
|
|
as we currently configure neither in the transmit code path.
Found by sf@
|
|
|
|
member to allow us to specify a delay between assert the CS# signal and
starting the clock. And the transfer function gains a flags argument,
which can be used to specify a new SPI_KEEP_CS flag to keep CS# asserted
after the transfer. This allows us to do another transfer immediately
afterwards without de-asserting CS# which is necessary for sending
commands to the upcoming Apple M1 keyboard/touchpad driver.
ok patrick@
|
|
that the RDT is written, and that it is written not too early. Doing it
before writing IGC_RXDCTL definitely doesn't work.
The tail pointer needs to be set to the next empty slot, so it has to be
"last desc filled + 1".
Make sure sure that the rss mapping does not happen in the middle of the
RX checksum block, and that it happens only if nqueues > 1. Also disable
storing bad packets.
With this, igc(4) receives packets just fine.
ok kevlo@
|
|
Ported by kevlo@
ok jmatthew@
|
|
|
|
|
|
|
|
|
|
|
|
Problem found and fix tested by krw@.
ok krw@
|
|
power connected (default is yes when no driver differentiates) then default
to 100% performance. On battery, use the existing auto algorithm (which is
admittedly somewhat unrefined).
This change overrides the system/BIOS speed and puts OpenBSD in control.
As this happens very early during boot, besides speedups in all usage usage
patterns, some surprises: unhibernate and sysupgrade times are cut in half.
note: on a few architectures, the setperf fn pointer is changed late, and
thus the auto algorithm stops timeing out. kettenis and i will look for
a solution.
in snaps for more than a week.
ok kettenis
|
|
|
|
During detach, we can't rely on softintrs to signal processes blocked
in read, write or poll, so we need to explicitely call wakeup
functions in the detach method, as other drivers do.
|
|
selwakeup() needs to be protected by KERNEL_LOCK, but we're not
allowed to grab KERNEL_LOCK on interrupt context because midi runs at
IPL_AUDIO with the audio_lock held. Furthermore, doing so is a locking
order bug: syscall code-path grabs KERNEL_LOCK first while interrupt
code-path does the opposite when calling selwakeup().
ok visa
|
|
ok sthen, anton
|
|
|
|
|
|
|
