Most synaptics touchpads return 0x47 in middle byte in responce to identify
command as stated in p.4.4 of "Synaptics PS/2 TouchPad Interfacing Guide".
But some devices e.g. found on HP EliteBook 9470m return 0x46 here.
Allow them to be identified as Synaptics as well as 0x47.
ExtendedQueries return incorrect data on such a touchpads so we ignore
their result and set conservative defaults.
PR: 222667
Reported by: Neel Chauhan <neel@neelc.org>
Tested by: Neel Chauhan <neel@neelc.org>
Approved by: gonzo
Modern touchpads do not issue interrupts on inactivity so "lost interrupt"
message became annoying spam nowadays. This change quiets the message
if debug.psm.loglevel=5 (or less) is set in /boot/loader.conf
Approved by: gonzo
ForcePads do not have any physical buttons, instead they detect click
based on finger pressure. Forcepads erroneously report button click
if there are 2 or more fingers on the touchpad breaking multifinger
gestures. To workaround this start reporting a click only after
4 consecutive single touch packets has been received. Skip these packets
in case more contacts appear.
PR: 223369
Reported by: Neel Chauhan <neel@neelc.org>
Tested by: Neel Chauhan <neel@neelc.org>
Reviewed by: gonzo
Approved by: gonzo
It is coded according to the Intel document 336996-001, reading of the
patches posted on lkml, and some additional consultations with Intel.
For existing processors, you need a microcode update which adds IBRS
CPU features, and to manually enable it by setting the tunable/sysctl
hw.ibrs_disable to 0. Current status can be checked in sysctl
hw.ibrs_active. The mitigation might be inactive if the CPU feature
is not patched in, or if CPU reports that IBRS use is not required, by
IA32_ARCH_CAP_IBRS_ALL bit.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D14029
The switch hardware requires this bit to be set in order to kick start the
actual ATU update. This was being masked on some chips by the learning
programming (what to do when a MAC address moves, hash table collision, etc)
which is currently inconsistent between chips.
Tested:
* AR9344 SoC (AR7240 style switch internal)
We may not have enough contiguous memory later, when NTB connection get
established. It is quite likely that NTB windows are symmetric and this
allocation remain, but even if not, we will just reallocate it later.
MFC after: 2 weeks
This used to work by accident with ld.bfd even though always_keepalive
was marked as static. LLD honors static more correctly, so export this
variable properly (including moving it into the tcp_* namespace).
Reviewed by: bz, emaste
MFC after: 2 weeks
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D14129
checks to recognize own network devices when using mlx5ib. This patch fixes
an issues where mlx5ib fails to recognize mceX network devices for use with
RoCE.
MFC after: 1 week
Sponsored by: Mellanox Technologies
host to reprobe the bus by switching the USB pull up resistors off and
back on. In other words - when FreeBSD is configured as a USB device,
changing the sysctl will be immediately noticed by the machine it's
connected to.
Reviewed by: hselasky@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
optimize away these loops. Change boolean to int to match what atomic
API supplies. Remove wmb() since the atomic_store_rel() on status.done
ensure the prior writes to status. It also fixes the fact that there
wasn't a rmb() before reading done. This should also be more efficient
since wmb() is fairly heavy weight.
Sponsored by: Netflix
Reviewed by: kib@, jim harris
Differential Revision: https://reviews.freebsd.org/D14053
I suppose it should make this code NUMA-aware with recent NUMA drop-in,
trying to allocate shared memory buffers from domain closer to NT-bridge.
MFC after: 2 weeks
Build with rtl8366rb has been broken due to incorrect retrieval of pointer
to device_t.
Reported by: lwhsu
Differential Revision: https://reviews.freebsd.org/D14044
This patch is cosmetic. It checks if allocation of ifnet structure failed.
It's better to have this check rather than assume positive scenario.
Submitted by: Dmitry Luhtionov <dmitryluhtionov@gmail.com>
Reported by: Dmitry Luhtionov <dmitryluhtionov@gmail.com>
Properly honor the lack of the CRD_F_IV_PRESENT flag in the GCM
software fallback case for encryption requests.
Submitted by: Harsh Jain @ Chelsio
Sponsored by: Chelsio Communications
In particular, this avoids edge cases where a generated IV might be
written into the output buffer even though the request is failed with
an error.
Sponsored by: Chelsio Communications
- Extend ccr_gcm_soft() to handle requests with a non-empty payload.
While here, switch to allocating the GMAC context instead of placing
it on the stack since it is over 1KB in size.
- Allow ccr_gcm() to return a special error value (EMSGSIZE) which
triggers a fallback to ccr_gcm_soft(). Move the existing empty
payload check into ccr_gcm() and change a few other cases
(e.g. large AAD) to fallback to software via EMSGSIZE as well.
- Add a new 'sw_fallback' stat to count the number of requests
processed via the software fallback.
Submitted by: Harsh Jain @ Chelsio (original version)
Sponsored by: Chelsio Communications
This works around an issue in the T6 that can result in DMA engine
stalls if an error occurs while processing a DSGL entry with a length
larger than 2KB.
Submitted by: Harsh Jain @ Chelsio
Sponsored by: Chelsio Communications
Most crypto requests will not trigger this condition, but a request
with a highly-fragmented data buffer (and a resulting "large" S/G
list) could trigger it.
Sponsored by: Chelsio Communications
The T6 can hang when processing certain AEAD requests if the request
sets a flag asking the crypto engine to discard the input IV and AAD
rather than copying them into the output buffer. The existing driver
always discards the IV and AAD as we do not need it. As a workaround,
allocate a single "dummy" buffer when the ccr driver attaches and
change all AEAD requests to write the IV and AAD to this scratch
buffer. The contents of the scratch buffer are never used (similar to
"bogus_page"), and it is ok for multiple in-flight requests to share
this dummy buffer.
Submitted by: Harsh Jain @ Chelsio (original version)
Sponsored by: Chelsio Communications
The T6 crypto engine's control messages only support a total AAD
length (including the prefixed IV) of 511 bytes. Reject requests with
large AAD rather than returning incorrect results.
Sponsored by: Chelsio Communications
Combined authentication-encryption and GCM requests already stored the
IV in the immediate explicitly. This extends this behavior to block
cipher requests to work around a firmware bug. While here, simplify
the AEAD and GCM handlers to not include always-true conditions.
Submitted by: Harsh Jain @ Chelsio
Sponsored by: Chelsio Communications
The driver now ensures only one thread at a time is running in the API
functions (clock_gettime() and clock_settime()) by specifically requesting
ownership of the i2c bus without using IIC_RECURSIVE, then it does all IO
using IIC_RECURSIVE so that each individual IO operation doesn't try to
re-acquire the bus.
The other IO done by the driver happens at attach or intr_config_hooks time,
when there can't be multiple threads running with the same device instance.
So, the IIC_RECURSIVE flag can be safely ORed into the wait flags for all IO
done by the driver, because it's all either done in a single-threaded
environment, or protected within a block bounded by explict
iicbus_acquire_bus() and iicbus_release_bus() calls.
The driver now ensures only one thread at a time is running in the API
functions (clock_gettime() and clock_settime()) by specifically requesting
ownership of the i2c bus without using IIC_RECURSIVE, then it does all IO
using IIC_RECURSIVE so that each individual IO operation doesn't try to
re-acquire the bus.
The other IO done by the driver happens at attach or intr_config_hooks time,
when there can't be multiple threads running with the same device instance.
So, the IIC_RECURSIVE flag can be safely ORed into the wait flags for all IO
done by the driver, because it's all either done in a single-threaded
environment, or protected within a block bounded by explict
iicbus_acquire_bus() and iicbus_release_bus() calls.
The recursive ownership support added in r321584 was unconditionally in
effect all the time -- whenever a given i2c slave device instance tried to
lock the i2c bus for exclusive use when it already owned the bus, the call
returned immediately without waiting. However, many i2c slave drivers use
bus ownership to enforce that only a single thread at a time can be using
the slave device. The recursive locking changes broke this use case.
Now there is a new flag, IIC_RECURSIVE, which can be mixed in with the
other flags passed to iicbus_acquire_bus() to allow drivers to indicate
when recursive locking is desired. Using the flag implies that the driver
is managing concurrent access to the device by different threads in some way.
This immediately fixes all existing i2c slave drivers except for the two
i2c RTC drivers which use the recursive locking feature; those will be
fixed in a followup commit.
In iflib, the device-specific init() function isn't supposed to edit
the struct ifnet driver flags. If it does, it'll cause an MPASS() assert
in iflib to fail.
PR: 225312
Reported by: bhughes@
These functions deal the same type of overflows we do with mallocarray(9).
Using our mallocarray will panic, which different from the previous
behavior (returning NULL), but neither behavior is more correct.
As a sidenote, drm_calloc_large() is not currently used at all.
Reviewed by: dumbbell
Differential Revision: https://reviews.freebsd.org/D13835
When allocating memory through malloc(9), we always expect the amount of
memory requested to be unsigned as a negative value would either stand for
an error or an overflow.
Unsign some values, found when considering the use of mallocarray(9), to
avoid unnecessary casting. Also consider that indexes should be of
at least the same size/type as the upper limit they pretend to index.
MFC after: 3 weeks
