bthidd: Remove unused macros from hid.c.
ASIZE() was never used, and min() stopped being used in r207812.
Differential Revision: https://reviews.freebsd.org/D2230
Reviewed by: emax
Approved by: emax
bthidd: Consider usage ranges when dealing with array inputs.
So far, we were always using HID_USAGE() to determine the Usage ID of a
certain HID report input item. This does not work as intended if a field
is an array and the allowed usages are specified with a usage range, as
HID_USAGE() will return 0. We need to use the field value as an index in
the usage range list in this case instead.
This makes the volume keys in a Microsoft Bluetooth Mobile Keyboard
5000 be properly recognized. The relevant part of the HID report looks
like this:
0xA1, 0x01, // Collection (Application)
0x85, 0x07, // Report ID (7)
0x05, 0x0C, // Usage Page (Consumer)
0x19, 0x00, // Usage Minimum (Unassigned)
0x2A, 0xFF, 0x03, // Usage Maximum (0x03FF)
0x95, 0x01, // Report Count (1)
0x75, 0x10, // Report Size (16)
0x15, 0x00, // Logical Minimum (0)
0x27, 0xFF, 0x03, 0x00, 0x00, // Logical Maximum (1023)
0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred
// State,No Null Position)
When a key such as "volume down" is pressed, the following data is
transferred through Interrupt In:
0x07 0xEA 0x00
Differential Revision: https://reviews.freebsd.org/D2229
Adjust to handle either a 32-bit or 64-bit lun_id_t in printf.
MFC r266615:
Increase taskqueue thread priority from idle to PRIBIO.
MFC r279253:
- Copyright to Avago
- SSU changes
- SATA ID timeout handling (PR 191348)
- reset handling changes
- Bump version to 20.00.00.00-fbsd
MFC r279695:
Change that should have been done with r279253
Revert the IPI startup sequence to match what is described in the
Intel Multiprocessor Specification v1.4. The Intel SDM claims that
278325:
Revert the IPI startup sequence to match what is described in the
Intel Multiprocessor Specification v1.4. The Intel SDM claims that
the INIT IPIs here are invalid, but other systems follow the MP
spec instead.
While here, fix the IPI wait routine to accept a timeout in microseconds
instead of a raw spin count, and don't spin forever during AP startup.
Instead, panic if a STARTUP IPI is not delivered after 20 us.
280866:
Wait 100 microseconds for a local APIC to dispatch each startup-related IPI
rather than 20. The MP 1.4 specification states in Appendix B.2:
"A period of 20 microseconds should be sufficient for IPI dispatch to
complete under normal operating conditions".
(Note that this appears to be separate from the 10 millisecond (INIT) and
200 microsecond (STARTUP) waits after the IPIs are dispatched.) The
Intel SDM is silent on this issue as far as I can tell.
At least some hardware requires 60 microseconds as noted in the PR, so
bump this to 100 to be on the safe side.
PR: 196542, 197756
Explain that vm_page_array is mapped to describe the memory, not the
memory itself. Provide the formula to calculate the number of
required page tables. Correct the size of the struct vm_page for
non-PAE case.
Expand the bitcount*() API and use it to implement CPU_COUNT for cpusets.
278474:
Use __builtin_popcnt() to implement a BIT_COUNT() operation for bitsets and
use this to implement CPU_COUNT() to count the number of CPUs in a cpuset.
278476:
Use __builtin_popcountl() instead of __builtin_popcount().
280279:
Expand the bitcount* API to support 64-bit integers, plain ints and longs
and create a "hidden" API that can be used in other system headers without
adding namespace pollution.
- If the POPCNT instruction is enabled at compile time, use
__builtin_popcount*() to implement __bitcount*(), otherwise fall back
to software implementations.
- Use the existing bitcount16() and bitcount32() from <sys/systm.h> to
implement the non-POPCNT __bitcount16() and __bitcount32() in
<sys/types.h>.
- For the non-POPCNT __bitcount64(), use a similar SWAR method on 64-bit
systems. For 32-bit systems, use two __bitcount32() operations on the
two halves.
- Use __bitcount32() to provide a __bitcount() that operates on plain ints.
- Use either __bitcount32() or __bitcount64() to provide a
__bitcountl() that operates on longs.
- Add public bitcount*() wrappers for __bitcount*() for use in the kernel
in <sys/libkern.h>.
- Use __bitcountl() instead of __builtin_popcountl() in BIT_COUNT().
Assorted updates to md5.1
Note that the -c argument's parameter is compared against the digest of
the file, not the file. [1]
Update the "current time" parentheticals for notes about reversing
and colliding the hash functions. [1]
Some general mdoc updates.
PR: docs/188043 [1]
Submitted by: Jamie Landeg-Jones [1]
Periodically wake up threads waiting for vmem(9) resources, so they could
ask for resource reclamation again.
This is kind of dirty hack, but as last resort this is better then stuck
indefinitely because of KVA fragmentation, waiting until some random event
free something sufficient. OpenSolaris also has this hack in its vmem(9).
Fix a possible infinite loop in ctf_discard().
MFC r279864:
Use CTF_TYPE_TO_INDEX when comparing type indices to the dynamic type
threshold.
MFC r279869:
If the destination container contains only a forward declaration for the
input type in ctf_add_type(), search its dynamic type list before adding
a new type.
Bug fixes and feature adds
- Remove extranious echo that breaks puppet
- Handle restarts of multiple pflog devices correctly
- Add the ability to perform actions on specific pflog devices.
Typo Fix.
PR: 199150
r245508 modified the NFS client's Setattr RPC to
use VA_UTIMES_NULL to indicate whether it should
set the time to the current tod on the server.
This had the side effect of making the NFS client
use the client's timestamp for exclusive create,
starting with FreeBSD9.2.
Unfortunately a bug in some Solaris NFS servers
causes these servers to return NFS_OK to the
Setattr RPC done during exclusive create, but not
actually set the file's mode, leaving the file's
mode == 0.
This patch restores the NFS client's behaviour to
use the server's tod for the exclusive open's
Setattr RPC, to avoid the Solaris server bug and
to restore the pre-FreeBSD9.2 NFS behaviour.
Add OBJCOPY to the list of external tools
MFC r272815 (by bapt):
Fix typo
This should fix the build troubles some people have been seeing after
the MFC of r280980 (in r281289). Sorry for the breakage.
When CPU is not busy, those queues are typically empty. When CPU is busy,
then one more extra sorting is the last thing it needs. If specific device
(HDD) really needs sorting, then it will be done later by CAM.
This supposed to fix livelock reported for mirror of two SSDs, when UFS
fires zillion of BIO_DELETE requests, that totally blocks I/O subsystem by
pointless sorting of requests and responses under single mutex lock.
Simplify string mangling in ifmaybeload().
- Use strlcpy() instead of strcpy().
- Use strlcat() instead of a strlcpy() with a magic number subtracted
from the length.
- Replace strncmp(..., strlen(foo) + 1) with strcmp(...).
Enable bzipfs support in the EFI loader.
- Add bzipfs to the list of supported filesystems in the EFI loader.
- Increase the heap size allocated for the EFI loader from 2MB to 3MB.
The System V ABI for amd64 allows functions to use space in a 128 byte
redzone below the stack pointer for scratch space and requires
interrupt and signal frames to avoid overwriting it. However, EFI uses
the Windows ABI which does not support this. As a result, interrupt
handlers in EFI push their interrupt frames directly on top of the
stack pointer. If the compiler used the red zone in a function in the
EFI loader, then a device interrupt that occurred while that function
was running could trash its local variables. In practice this happens
fairly reliable when using gzipfs as an interrupt during decompression
can trash the local variables in the inflate_table() function
resulting in corrupted output or hangs.
Fix this by disabling the redzone for amd64 EFI binaries. This
requires building not only the loader but any libraries used by the
loader without redzone support.
Thanks to Jilles for pointing me at the redzone once I found the stack
corruption.
Allow the EFI loader to work with large kernels and/or modules
(for example, a large mfsroot). Note that for EFI the kernel and
modules (as well as other metadata files such as splash screens or
memory disk images) are loaded into a statically-sized staging area.
When the EFI loader exits it copies this staging area down to the
location the kernel expects to run at.
- Add bounds checking to the copy routines to fail attempts to access
memory outside of the staging area. Previously loading a combined
kernel + modules larger than the staging size (32MB) would overflow
the staging area trashing whatever memory was afterwards. Under
Intel's OVMF firmware for qemu this resulted in fatal faults in the
firmware itself. Now the attempt will fail with ENOMEM.
- Allow the staging area size to be configured at compile time via
an EFI_STAGING_SIZE variable in src.conf or on the command line.
It accepts the size of the staging area in MB. The default size
remains 32MB.
Swap device is still reported as enabled, and system still may crash later
if some swapped-out kernel pages were lost with the device, but at least
GEOM and CAM can now release the lost disk, allowing it to be reconnected.
