Some ACPI wmi query is implemented by named object, not method,
ACPICA complains when non-method object is evaluated with one or more arguments.
Especially, almost all binary MOF object obtaining method is the case.
This commit will fix it.
PR: 284912
Reported by: Alexander Ziaee
Differential Revision: https://reviews.freebsd.org/D49129
Previously, a two-finger horizontal scroll would result in a forwards/backwards
keyboard event being performed. This patch changes that functionality to be
specified via two new sysctls: horizontal_swipe_finger_count and
scroll_finger_count. The former specifies how many fingers are used to perform
the aforementioned forwards/backwards keyboard event, while the latter specifies
how many fingers are used to perform horizontal scrolling. 0 disables each of
them.
The threshold for scrolling has been coupled into a single tunable:
scr_threshold. This tunable is used for both scrolling and the horizontal swipe.
t_factor and t_invert tunables have been created in the same manner as their
z-axis counterparts.
Horizontal scrolling is disabled by default, as it requires the sysctl
hw.usb.wsp.t_factor to 3 (wsp mode). Horizontal swiping is enabled by default
with a three-finger tap.
Also rewrite much of, and improve, documentation.
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
Neither the ums(4) nor psm(4) reporting can be used by the wsp(4)
driver, as they rely on static-length movements, while wsp(4) may need
to scroll in large amounts per evdev event push.
This style uses a false button-5 press as an indicator that the z-axis
movement is a horizontal scroll, otherwise a vertical scroll.
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
The hw.usb.wsp.max_scroll_finger_distance sysctl may be used to specify
the maximum distance between two fingers which are registered as a z-axis
(vertical scroll with mousepad) movement.
Previously, this was shared with the tunable
hw.usb.wsp.max_double_tap_distance which is used to specify the maximum
distance between two fingers which register as a right-click.
This patch also cleans up and add new information to the manpage for
wsp(4).
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
The previous value caused nearly every horizontal movement to be
classed as a left/right-keyboard button-click.
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
Using printf() with '%s' can lead to arbitrary long printing (although,
usually, a NUL byte should appear quite quickly) and trying to print
unprintable characters.
Instead, print in hexadecimal the exact bytes that are compared to the
expected signature.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Only allow the length tolerance (0x1e instead of 0x1f) for a 32-bit
entry point, as there was no 64-bit entry point in the erroneous SMBIOS
v2.1 standard and assigning the length with 0x1f does not make sense in
this case.
While here, fix accessing the major/minor versions via 'eps' even in the
64-bit entry point case (not causing any practical problem thus far as
the entry point length is greater than any SMBIOS revisions in
existence, so the comparison guarding the fixup would not pass).
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
While here, de-indent most of the code by simply bailing out if 'addr'
is still 0 after the various detection methods have been tried.
Reviewed by: emaste, imp
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49180
Additionally, on verbose boot, print the entry point revision as
a diagnostic/debugging help.
PR: 284460
Reviewed by: markj, imp (both older version)
MFC after: 2 weeks
Event: February src bug-busting session
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49179
When booted from BIOS (i.e., not EFI), also search for a 64-bit version
of the SMBIOS Entry Point.
This allows us to detect and report the proper SMBIOS version with
BIOSes that only provide the v3 table, as happens on Hetzner virtual
machines.
For machines that provide both, leverage the v3 table in priority
consistently with the EFI case.
PR: 284460
Reviewed by: markj, imp (both older version)
MFC after: 2 weeks
Relnotes: yes
Event: February src bug-busting session
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49179
This method is often used to process GPIO "Power on" button press on
modern x86 laptops with S0ix sleep mode.
Tested with patch from https://reviews.freebsd.org/D26407
Sponsored by: Future Crew LLC
MFC after: 2 month
before starting of children initialization to ensure that parent device
is fully functional.
Sponsored by: Future Crew LLC
MFC after: 2 month
Differential Revision: https://reviews.freebsd.org/D48958
For some devices e.g. ITE5570 it is not enough to read HID-over-I2C
input length header of RESET command response to acknowledge interrupt.
Do a full-size read to avoid interrupt storm.
Sponsored by: Future Crew LLC
MFC after: 2 month
Differential Revision: https://reviews.freebsd.org/D48957
This replaces 50 ms busy loop with mtx_sleep for the same duration thus
saving CPU time when iichid is driven with interrupts.
Sponsored by: Future Crew, LLC
MFC after: 2 month
Differential Revision: https://reviews.freebsd.org/D48956
In order to signal to Graviton [123] systems that a device is ready
to be "ejected" (after a detach request is made via the EC2 API) we
need to set PCIM_PSTAT_PME to 1 and PCIM_PSTAT_PMEENABLE to 0. We are
not aware of any rationale for this requirement beyond "another OS
kernel happens to do this", i.e. this is effectively bug-for-bug
compatibility.
Arguably this should be done by the ACPI _EJ0 method on these systems,
but it is not.
Create a new ACPI_Q_CLEAR_PME_ON_DETACH quirk and set it in EC2 AMIs,
and add the PCI register write to acpi_pci_device_notify_handler when
that quirk is set.
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D49146
These includes were for __FBSD_RCSID() macro. They weren't formatted
like the rest of the tree so weren't trimmed automatically when that
script was run. Trim them now.
MFC After: 1 week
Sponsored by: Netflix
IPv4 packets can be routed via an IPv6 nexthop, so the handling of the
parsed address family is more strict than it needs to be. If we have a
valid header that matches a known peer, then we have no reason to
decline the packet.
Convert it to an assertion that it matches the destination as viewed by
the stack below it, instead. `dst` may be the gateway instead of the
destination in the case of a nexthop, so the `af` assignment must be
switched to use the destination in all cases.
Add a test case that approximates a setup like in the PR and
demonstrates the issue.
PR: 284857
Reviewed by: markj (earlier version), zlei
Differential Revision: https://reviews.freebsd.org/D49172
Use the correct device pointer to obtain the domain set for memory
allocation. Previously, the functions were incorrectly using the arg
parameter directly instead of accessing mlx5_core_dev.
Signed-off-by: Slava Shwartsman <slavash@nvidia.com>
Sponsored by: NVidia networking
MFC after: 1 week
For safety I was trying to clear out the descriptor but the full descriptor
was not allocated. Remove any code trying to do that so the same mistake
won't be made. This was found when looking to MFC the prior change
and having the loader, load the module.
Remove cq->ntxqsets since the completion queue is part of the RX and TX sets
Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.
Enable the vt_efifb driver. A small tweak is required to work around the
lack of VM_MEMATTR_WRITE_COMBINING on this platform; we use
VM_MEMATTR_UNCACHEABLE instead.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48884
ieee80211_node_set_txrate_ht_mcsrate() takes an MCS rate from 0..76,
the high bit (IEEE80211_RATE_MCS) must not be set.
This is definitely my fault - I likely didn't get to testing this
diff when I changed it from ieee80211_node_set_txrate_dot11rate()
just before landing.
Differential Revision: https://reviews.freebsd.org/D49197
Reviewed by: bz
Summary:
The device IDs for these were in the driver's list of PCI ids to attach
to, but igc_set_mac_type() had never been setup to set the correct mac
type for these devices. Fix this by adding these IDs to the switch block
in order for them to be recognized by the driver instead of returning an
error.
This fixes the igc(4) attach for the I226-K LOM on the ASRock Z790
PG-ITX/TB4 motherboard, allowing it to be recognized and used.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: kbowling@
MFC after: 3 days
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D49147
Set the default refill threshod to be one quarter of the rx queue
length. User can change this value with hw.mana.rx_refill_thresh
in loader.conf. It improves the rx completion handling by saving
10% to 15% of overall time with this change.
Tested by: whu
MFC after: 2 weeks
Sponsored by: Microsoft
Migrate the transmit path to use ieee80211_node_get_txrate(), and handle
VHT rates.
Nothing is currently setting VHT rates, but the driver should now
be ready.
Differential Revision: https://reviews.freebsd.org/D48606
Reviewed by: bz
There are only a few places where the returned rix is used:
* linuxkpi - logging
* bwi/bwn - used for finding a fallback rate to choose, which
honestly should be returned by the ratectl API
* iwm - building the rateset to program into firmware
Everyone else uses the dot11rate value in ni->ni_txnode.
This is a precursor for VHT and later rate support; where currently
there aren't rate tables in ieee80211_phy.c for VHT and later
rates.
Although it's likely doable to add tables for VHT, 11ax and MU-OFDMA
(HE) rates are sufficiently larger/different to just not fit in the
current scheme without more refactoring.
Differential Revision: https://reviews.freebsd.org/D48603
Reviewed by: bz, thj
This just mechanically converts things.
* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
doesn't report it up.
Differential Revision: https://reviews.freebsd.org/D48602
Reviewed by: bz, thj
Add a new hw_all_ok() routine and use it to avoid hardware access in the
public control interfaces (ifnet ioctls, ifmedia calls, etc.). Continue
to use hw_off_limits() in the private ioctls/sysctls and other debug
code. Retire adapter_stopped() as it's of no use by itself.
This fixes problems where ifnet slow-path operations would enter a
synch_op just before set_adapter_hwstatus(false) and touch the hardware
when it's not safe to do so.
MFC after: 1 week
Sponsored by: Chelsio Communications
Amazon EC2 m7i cloud instances use PCI hotplug rather than ACPI
hotplug. The card is removed and detach is called to remove the drive
from the system. The hardware is no longer present at this point, but
the bridge doesn't translate the now-missing hardware reads to all ff's
leading us to conclude the hardware is there and we need to do a proper
shutdown of it. Fix this oversight by asking the bridge if the device is
still present as well. We need both tests since some systems one cane
remove the card w/o a hotplug event and we want to fail-safe in those
cases.
Convert gone to a bool while I'm here and update a comment about
shutting down the controller and why that's important.
Tested by: cperciva
Sponsored by: Netflix
The comment and rationale behind choosing CHN_INSERT_SORT_DESCEND()
instead of CHN_INSERT_SORT_ASCEND() are no longer relevant as of FILLME
("sound: Allocate vchans on-demand").
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48962
The mechanism of acquiring SD_F_BUSY in pcm_init() and releasing it in
pcm_register() is a leftover from the previous device creation scheme,
where pcm_init() (previously pcm_register()) would create the sysctl
nodes, as well as the device node. In this scenario, acquiring SD_F_BUSY
was necessary, in order to avoid races in case the device was accessed
before it was ready for use. Commit 66f3eb14e9 ("sound: Move sysctl
and /dev/dspX creation to pcm_setstatus()") fixed this issue, so we can
simplify things now. Only acquire SD_F_BUSY in pcm_addchan(), because
chn_init() expects to be called with SD_F_BUSY acquired.
While here, move the sndstat_register() call further down to be more
robust.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D48482
This gives us a slight performance boost since we do not have to go
through chn_setparam() and the driver functions.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D48012
It's a no-op. There is no lock associated with the buffer.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D48008
vchan_getparentchannel() is used by various vchan sysctl functions to
fetch the first primary channel. However, this assumes that all devices
have only one primary channel per direction. If a device does not meet
this assumption, then the sysctl functions will be applying the
configurations on the first primary channel only.
Since we now have the "primary" channel sublist, we can retire
vchan_getparentchannel() and iterate through the "primary" list in each
sysctl function and apply the settings to all primary channels.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48336
