Age | Commit message (Collapse) | Author |
|
and will not do so during resume.
Tested by kevlo@ on iwx(4) and by myself on iwm(4).
|
|
|
|
use uvm_obj_init() to initialize the pager ops and initial reference count.
This will help future uvm unlocking diffs.
ok mpi@, jsg@
|
|
tracing syscalls
and adjust btrace(8) accordingly.
extracted from a larger diff by Tom Rollet.
ok mpi@
|
|
|
|
with a fix from + ok kevlo@
|
|
family (discrete) not integrated.
ok stsp@
|
|
Adds support for Aquantia AQC1xx family of PCIe ethernet adapters. This
driver supports 1Gbps through 10Gbps modes of operation based on the
hardware and media/switch capabilities.
The initial code was ported from NetBSD, with jmatthew@ finishing up
the Tx/Rx ring support and interrupt handler routine.
The driver only supports devices using firmware V2.
This diff enables aq(4) on riscv64 and amd64, the only platforms where
I have tested the driver, but it likely works on other architectures
as well.
|
|
ok patrick@
|
|
more common volume increment/decrement usages in which each volume
change direction is represented using a distinct usage. The volume usage
instead uses bits of the interrupt buffer to represent the wanted
volume. The same bits should be within the bounds given by the logical
min/max associated with the HID item. However, the volume is not
interpreted as an absolute value but rather just looking at the sign bit
in order to determine the volume change direction.
I couldn't find any documentation of this usage and the implementation is
therefore solely based on analysing actual data from Richard Toohey's
<richardjtoohey at gmail dot com> Dell keyboard.
|
|
in more than one context.
|
|
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.
|
|
|
|
from Brad originally
|
|
|
|
not considered initialized anymore.
|
|
a suspend/resume cycle, the values are set to a sane default.
|
|
by a suspend/resume cycle, the pointers are set to a sane default.
|
|
we're still using the i8254 for that. On Hyper-V Gen 2 VMs there is no
i8254 we can trust, so we need some kind of fallback, especially if there
is no TSC either.
Discussed with the hackroom
ok kettenis@
|
|
Found by mpi@ and gnezdo@
ok gnezdo@
|
|
ok patrick@
|
|
tested by and ok jmatthew@
|
|
location as the product of the corresponding Report Count and Report
Size can be greater than one.
Fixes Richard Toohey's <richardjtoohey at gmail dot com> Dell keyboard.
|
|
only happen if ucc_hid_parse() has a bug, better play it safe.
|
|
at the very least it stops the compiler omgoptimising away important
code.
tested by and ok deraadt@ jmatthew@
|
|
compare the data structures with the Linux code which unfortunately is
the only documentation we have for the pin numbers used by ACPI.
While there make the data structures const.
ok jcs@
|
|
ok mpi@
|
|
This might help with troubleshooting "iwx0: acquiring device failed"
errors.
OK stsp@
|
|
wskbd in order to make them visible in X11. Matches what ukbd(4) already
does.
|
|
|
|
usage greater than zero. Usage zero is defined as unassigned by the
specification and cannot be mapped to anything sensible.
Prevents ucc from attaching to bunch of odd report IDs from a Lenovo
ThinkPad USB-C Dock which only exposes the unassigned usage. This is
not a problem in practice but I think we're better attaching them as
uhid devices instead as ucc cannot provide any functionality.
Thanks to Mario Peter <mp at mpeter dot de> for reporting and testing.
|
|
causing ucc to only being able to attach to the last report ID. This in
turn is caused by hid_is_collection() only being able to observe an end
of collection item with the last report ID for the same collection.
Instead, change the matching of ucc to only consider report IDs with at
least one corresponding Consumer Control usage.
Fixes gnezdo@'s Google Pixel earbuds.
|
|
Feature) from the corresponding descriptor report for a given report ID.
The ordering of the items is identical in both the descriptor and
interrupt report. As the interrupt report can cover more than Consumer
Control related key presses, ucc must be more careful while examining
the interrupt report in order to not confuse other items as key presses.
While parsing the descriptor report, take note of the bits that
represents Consumer Control key presses and use it to slice the
interrupt report.
Thanks to florian@ gnezdo@ and Alessandro De Laurenzis <just22 at
atlantide dot mooo dot com> for testing.
|
|
specification ucc might as well enumerate all of them. Finding an
appropriate scan code recognized by X11 for each usage is more tricky.
I've added a few more but the majority are still unmapped. Linux has
defined a couple of more usages covered by the evdev[1] key codes but
those symbols are not picked up in an vanilla X11 configuration on
OpenBSD, according to setxkbmap(1).
This should at least lower the barrier for adding scan codes for wanted
keys.
Note that the strings are discarded unless UCC_DEBUG is enabled.
Thanks to gnezdo@ for testing.
[1] xenocara/dist/xkeyboard-config/keycodes/evdev
|
|
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@
|
|
doesn't deal with non-GTT mappings. What the Linux code does here isn't
possible on OpenBSD and probably unecessary.
Seems to fix a crash reported by sthen@
ok jsg@
|
|
From Qingqing Zhuo
2e6cc93e1b8cf3ec2966961c1e98722ee7281023 in linux 5.10.y/5.10.61
c4152b297d56d3696ad0a9003169bc5b98ad7b72 in mainline linux
|
|
From Bing Guo
dcc8c5fb8d8595f5061c7b000ca1d16449a5e865 in linux 5.10.y/5.10.61
06050a0f01dbac2ca33145ef19a72041206ea983 in mainline linux
|
|
From Yifan Zhang
7525f2e4de0069983497a9d3eab1ca9813ae1b4b in linux 5.10.y/5.10.61
1c0539a6fc8a4a4b77278e35d763073890de96b9 in mainline linux
|
|
already account for the two-byte length and one-byte report id,
rather than adding them ourself and requesting wMaxInputLength + 3.
Fixes dwiic timeouts requesting data from at least one touchpad.
Tested by various
|
|
|
|
|
|
to get ownership.
See Linux commit 501fd9895c1d7d8161ed56698ae2fccb10ef14f5
ok stsp@
|
|
ucc_keysym. No functional change.
|
|
this flag will cause wskbd to discard the given keymap layout and
instead favor the layout of the associated wsmux. This is not a problem
while attaching ucc(4) during boot as the wsmux uses the default layout
at this point. However, if the layout is changed using /etc/kbdtype from
rc(8) during boot, attaching ucc(4) at this point would cause
wskbd_attach() to get stuck in an infinite loop:
wskbdX: cannot load keymap, falling back to default
... which in turn is caused by ucc(4) only providing a us layout and
using anything else in /etc/kbdtype would not work.
I missed this as I don't use /etc/kbdtype but cwen@ and Mazzurco
Riccardo <mazzurco dot riccardo at protonmail dot com> reported the same
problem.
|
|
Fixes cwen@'s Creative BT-W3 audio device.
|
|
discard it but instead just inspect the first bytes that can make up a
usage. This is a work around as the correct solution is to only inspect
a limited number of bits as given by the report count and size
associated with the Consumer usage page.
Final piece to get florian@'s Microsoft Sculpt keyboard working.
|
|
associated min/max boundaries. Assuming that every usage array starts
with the Control usage is incorrect.
Fixes claudio@'s GMMK keyboard and partial fix for florian@'s Microsoft
Sculpt keyboard.
|