The USB bus performs additional teardown steps in between detaching
child devices and deleting child devices.
Reported by: phk, thj
Tested by: phk
Fixes: e9d3857040 ("Use bus_detach_children instead of bus_generic_detach")
A REQUEST SENSE CDB was just copied into the cmd buffer, so testing for
INQUIRY will always fail. Remove the dead code.
This code was added, apparently by mistake in 2003. 8541fbec79
merged changes from NetBSD's umass_scsipi.c 1.8 to address some BBB
bulk-in clear problems. NetBSD had fixed a problem in the
FORCE_SHORT_INQUIRY quirk code they had ported from FreeBSD that FreeBSD
also needed. That merge also included the dead code, which was not in
NetBSD.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D49311
Currently dev.pcm.X.mode is calculated only once in pcm_sysinit(), which
is called by pcm_register() during attach, but this can result in
inconsistencies.
For some context, what pcm_mode_init() does is, it checks if "playcount"
is positive, in which case we assume the device supports playback. The
same is done for "reccount" for recording, and if "mixer_dev" is not
NULL, we know the device has a mixer.
The "playcount" and "reccount" variables correspond to the number of
_primary_ playback/recording channels, so we can assume that the primary
channels have been created before reaching pcm_mode_init(). However, for
the mixer that's not always the case. If the mixer is created _after_
pcm_register(), as is the case for snd_dummy(4) for example,
pcm_mode_init() will see that "mixer_dev" is NULL, and report that the
device does not have a mixer, whereas in reality we just created it
afterwards.
While this could be fixed by simply creating the mixers always before
pcm_register(), it is better to be robust and calculate the mode
dynamically.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49024
This flag is redundant and essentially a no-op, as it is set when the
device supports at least playback or recording, which is almost always
the case. But even if the device is mixer-only (i.e., 0 channels), there
is no reason to keep this flag; it is only used to bail out of the vchan
sysctl handlers, but we already bail out anyway if we try to use the
sysctl in a vchan direction that is not supported.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49021
Not used outside of pcm/dsp.c.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: imp, markj
Differential Revision: https://reviews.freebsd.org/D49217
- Get rid of macro magic.
- Make feed_mixer_info handling similar to most feeders.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48394
It does what feed_matrix_apply() already does, so it is redundant.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48036
Turn the FEEDMATRIX_DECLARE macro into a single inline function
(feed_matrix_apply()). There is no reason to have this as a macro, it
only complicated the code. An advantage of this patch is that, because
we no longer call the functions created by the macro through function
pointers (apply field of feed_matrix_info), we can call
feed_matrix_apply() directly in feed_matrix_feed().
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48035
Turn the FEEDEQ_DECLARE macro into a single inline function
(feed_eq_biquad()). There is no reason to have this as a macro, and it
only complicates the code. An advantage of this patch is that, because
we no longer call the functions created by the macro through function
pointers (biquad_op), we can call feed_eq_biquad() directly in
feed_eq_feed().
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48032
This makes some subsequent feeder refactors easier to implement.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48421
Merge the PCM_READ|WRITE_* macros defined in pcm/pcm.h, as well as the
intpcm_read|write_* macros defined in pcm/feeder_format.c, into six
inline functions: pcm_sample_read|write[_norm|calc](). The absence of
macro magic makes the code significantly easier to read, use and modify.
Since these functions take the input/output format as a parameter, get
rid of the read() and write() function pointers defined in struct
feed_format_info, as well as the feeder_format_read|write_op()
functions, and use the new read/write functions directly.
Sponsored by: The FreeBSD Fondation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D47932
The lock is already not held while deleting child devices, and the
bus_topo_lock is already held when child devices are created.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49272
Drop SDHCI_LOCK and instead acquire bus_topo_lock when adding and
removing new-bus devices.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49271
Some drivers held regular mutexes across some new-bus calls; instead
depend on bus_topo_lock to protect the relevant softc members. This
also fixes the bus_topo_lock to be explicit in these drivers rather
than relying on the implicit Giant from taskqueue_swi_giant. It
avoids calling sleepable routines like device_probe_and_attach from an
swi context.
Differential Revision: https://reviews.freebsd.org/D49270
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
