In order to better integrate modern LinuxKPI USB this tries to reduce
a contention point of "LIST". Given there is no need to use a LIST here
change it to SLIST to avoid conflicts.
It is a workaround which does not solve the actual problem (overlapping
namespaces) but it helps us a lot for now.
Sponsored by: The FreeBSD Foundation
X-MFC? unclear
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D46534
Also correctly use tun.max_double_tap_distance for maximum distance
of fingers for vertical scrolling.
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
Reviewed by: imp, wulf
Pull Request: https://github.com/freebsd/freebsd-src/pull/1365
This patch allows scrolling with multiple fingers simultaneously, in
line with how wsp trackpads function on MacOS.
Two new tunables are added: hw.usb.wsp.max_finger_area and
hw.usb.wsp.max_double_tap_distance.
max_finger_area defines the maximum size which the driver registered an
object on trackpad as a finger.
Previously, this value was hardcoded as 1200, which was too low to
register thumb-clicks.
max_double_tap_distance defines the maximum distance between two
fingers which will register as a double-click.
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
Reviewed by: imp, wulf
Pull Request: https://github.com/freebsd/freebsd-src/pull/1365
This provides functionality for a click which is partially unreleased
and then allows the user to continue moving the mousepad as if were not
invoked as a full click
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
Reviewed by: imp, wulf
Pull Request: https://github.com/freebsd/freebsd-src/pull/1365
The RTW8821CU_CD entry in quirks has an invalid lo_rev/hi_rev match
entry. Use the different USB_QUIRK macro to match on all of these;
the value we currently see is 0x0200 on two different wifi sticks. [1]
Also add an entry for the DLINK DWA-181 rev A1, rtw88 USB.
Submitted by: phk
Tested by: phk
Fixes: b3b6a959c8 [1]
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46189
The way that net80211 and drivers are checking for the /type/ of key
is to check if it's in the vap WEP key array and if so, it's a group
key. If not, it's a unicast key.
That's not only kind of terrible, but it's also going to be
problematic with future 802.11 support (for multiple unicast keys
and IGTK keys for management frame protection.)
So as part of this, remove the places where this is done and
instead use a pair inline functions - ieee80211_is_key_global() and
ieee80211_is_key_unicast(). They currenly still use the same logic
but the drivers and net80211 stack isn't doing it itself.
There are still open questions about why keys are not being
correctly tagged as GROUP, GTK, PTK, etc. That will be investigated
and addressed in follow-up work as a pre-cursor to MFP, IGTK, etc.
as mentioned above.
Testing:
* iwn, rtwn - STA mode
Differential Revision: https://reviews.freebsd.org/D45516
- Group the request header and I/O buffer in one structure, rather than
assuming that both request structures have the same size.
- Pass a pointer to the whole structure to urndis_ctrl_query() and
urndis_ctrl_set() rather than just the header. Otherwise, on CHERI
platforms, these functions violate subobject bounds since they modify
the buffer following the header.
While here, there is no apparent reason for the request structure used
in urndis_attach() to be allocated statically. Change it so that it's
allocated on the stack.
No functional change intended.
Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D45866
Change 4787572d05 made if_alloc_domain() never fail, then also do the
wrappers if_alloc(), if_alloc_dev(), and if_gethandle().
No functional change intended.
Reviewed by: kp, imp, glebius, stevek
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45740
Almost all code related to the saf1761 driver was removed in commit
44796b7e82, except for two small bits related to saf1761otg support.
This patch completes the removal.
PR: 279302
Signed-off-by: Joshua Kinard <freebsd@kumba.dev>
Reviewed by: mhorne
MFC after: 3 days
Fixes: 44796b7e82 ("mips: remove saf1761")
Seperate usb quirks that target specific revisions from those that
dont. Alot of the quirks dont use lo_rev and hi_rev, so we can abstract
the 0x0000, 0xffff into a macro.
[[ This commit is a bit more churn than we like. I carefully reviewed
each one and they are all good. The end product is better -- imp ]]
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1153
In some cases, the USB_QUIRK_VP macro was being misused. Instead of
setting quirks to the intended value, the first two supplied quirks
would go into lo_rev and hi_rev. Replace it with USB_QUIRK_VO which only
takes the needed args. This also makes the Dummy products, which where
being used to correctly set vendor only quirks, not necessary.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1153
Microchip Technology acquired SMSC in 2012, and all current products
and datasheets refer to the devices supported by this driver as
Microchip parts. Mention SMSC in a parenthetical comment to explain
the driver's name.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45115
bcm2838_xhci(4) is a shim for the XHCI controller on the Raspberry Pi 4B
SoC. It loads the controller's firmware before passing control to the
normal xhci(4) driver.
When xhci(4) is built as a module (and not in the kernel), bcm2838_xhci
is not built at all and the RPi4's XHCI controller won't attach due to
missing firmware.
To fix this, build a new module, bcm2838_xhci.ko, which depends on
xhci.ko. For the dependency to work correctly, also modify xhci to
provide the 'xhci' module in addition to the 'xhci_pci' module it
already provided.
Since bcm2838_xhci is specific to a quirk of the RPi4 SoC, only build
the module for AArch64.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1142
Previosuly, USB_IFACE_DRIVER_ACTIVE would report that the driver is
active even after it detached. That's because a device(9) still
remains.
So, add device_is_alive(9) check for more accurate reporting.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43960
Since 5efea30f03 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c can trigger these for example.
Drivers for firmware based wireless cards have worked around some of
this (and other) problems in the past.
Add an array of tasks rather than a single one as we would simply
get npending > 1 and lose order with other tasks. Try to keep state
changes updated as queued in case we end up with more than one at a
time. While this is not ideal either (call it a hack) it will sort
the problem for now.
We will queue in ieee80211_new_state_locked() and do checks there
and dequeue in ieee80211_newstate_cb().
If we still overrun the (currently) 8 slots we will drop the state
change rather than overwrite the last one.
When dequeing we will update iv_nstate and keep it around for historic
reasons for the moment.
The longer term we should make the callers of
ieee80211_new_state[_locked]() actually use the returned errors
and act appropriately but that will touch a lot more places and
drivers (possibly incl. changed behaviour for ioctls).
rtwn(4) and rum(4) should probably be revisted and net80211 internals
removed (for rum(4) at least the current logic still seems prone to
races).
PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (in 2023)
MFC after: 3 days
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43389
device_set_usb_desc() first tries to fetch device information through
the iInterface descriptor, otherwise it falls back to usb_devinfo().
Since usb_devinfo() is both guaranteed to work, and is more verbose, get
rid of the initial iInterface attempt.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: imp, markj
Differential Revision: https://reviews.freebsd.org/D43383
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43196
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43195
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43194
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43192
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43191
dwc3 is big enough to have its own subdirectory.
While here only make it depend on kernel option dwc3 and rk_dwc3
without any SOC options.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43190
This is in preparation for annotating copyin() and related functions
with __result_use_check.
Reviewed by: wulf
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43103
Some Raspberry Pi pass smsc95xx.macaddr=XX:XX:XX:XX:XX:XX as bootargs.
Use this if no ethernet address is found in an EEPROM.
As last resort fall back to ether_gen_addr() instead of random MAC.
PR: 274092
Reported by: Patrick M. Hausen (via ML)
Reviewed by: imp, karels, zlei
Tested by: Patrick M. Hausen
Approved by: karels
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D42463
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
