26b3d6f8ff (diff-61a0580c3eaa34a373cc7ee7ee46dd2a)
---
arm64: allwinner: a64: enable Bluetooth On Pinebook
Pinebook has an RTL8723CS WiFi + BT chip, BT is connected to UART1
and uses PL4 as BT reset, PL5 as device wake GPIO, PL6 as host wake GPIO
the I2C controlling signals are connected to R_I2C bus.
Enable it in the device tree.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
this enables:
[ 1.000019] com1 at simplebus1: ns16550a, working fifo
[ 1.000019] com1: interrupting on GIC irq 33
to attach. more work with firmware and btattach will be required,
for the BT to be actually functional.
like there are other leaks related to timeval in this file.
[ 133.414352] kleak: Possible leak in copyout: [len=16, leaked=4]
[ 133.414352] #0 0xffffffff80224d0a in kleak_note <netbsd>
[ 133.424360] #1 0xffffffff80224d8a in kleak_copyout <netbsd>
[ 133.434361] #2 0xffffffff80b5fd79 in sys___gettimeofday50 <netbsd>
[ 133.434361] #3 0xffffffff8025a89c in sy_call <netbsd>
[ 133.444351] #4 0xffffffff8025aace in sy_invoke <netbsd>
[ 133.454365] #5 0xffffffff8025ab54 in syscall <netbsd>
There's a lot of waits inside tools, but nothing that promises that we haven't
started doing the next subdir in the top level.
Shows up as warnings in the cleandir stage on releng builds:
cleandir ===> external/mit/xorg/server/drivers/xf86-video-suncg6
cleandir ===> lib/libpam/modules/pam_deny
sh: /home/builds/ab/HEAD-llvm/sparc64/201811091720Z-tools/bin/nbawk: not found
nbmake[9]: "../../Makefile.xf86-driver" line 23: warning: "/home/builds/ab/HEAD-llvm/sparc64/201811091720Z-tools/bin/nbawk '/^PACKAGE_VERSION=/ { match($1, "[0-9]+\\.[0-9]+\\.[0-9]+"); version = substr($1, RSTART, RLENGTH); } END { print version }' /home/source/ab/HEAD-llvm/xsrc/external/mit/xf86-video-ati/dist/configure" returned non-zero status
sh: /home/builds/ab/HEAD-llvm/sparc64/201811091720Z-tools/bin/nbawk: not found
similar to the rest of the file.
I'm wondering if I'm not fixing a huge bug here. The ECX8 value we were
using was wrong: ECX8 is bit 1, not bit 0. Bit 0 is ALTINST, an alternate
ISA, which is now known to be backdoored.
So it looks like we were explicitly enabling the backdoor.
Not tested, because I don't have a VIA cpu.
software to effortlessly create and manage virtual machines via NVMM.
It is mostly complete, only nvmm_assist_mem needs to be filled -- I have
a draft for that, but it needs some more care. This Mem Assist should
not be needed when emulating a system in x2apic mode, so theoretically
the current form of libnvmm is sufficient to emulate a whole class of
systems.
Generally speaking, there are so many modes in x86 that it is difficult
to handle each corner case without introducing a ton of checks that just
slow down the common-case execution. Currently we check a limited number
of things; we may add more checks in the future if they turn out to be
needed, but that's rather low priority.
Libnvmm is compiled and installed only on amd64. A man page (reviewed by
wiz@) is provided.
Throw away length 1 packets without a warning: we already throw away messages
with (len < sizeof(*msg)) a short while after, but print a warning.
Hardware is allowed to pad USB packets which % wMaxPacketSize length with
such packets for hardware implementation simplicity reasons.
This is described in
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/usb-short-packets
From Artturi Alm in tech-net, with amendment from pgoyette.
The command shows only 256 addresses at maximum even if a bridge caches more
addresses. It occurs because the kernel doesn't return an error if the command
passes a short buffer that can't store all cached addresses; the kernel fills
cached addresses as much as possible and returns it without telling that the
result is truncated.
Fix the issue by telling a required size of a buffer if a buffer passed from the
command is not enough, which lets the command retry with an enough buffer.
Reported by k-goda@IIJ
