ELECOM EDC-QUA3C is a USB3.1 Gen1 Type-A/C 2.5GBASE-T network adapter.
This also works as a cdce(4) device by:
usbconfig -d X.Y set_config 1
or
usbconfig -d X.Y set_config 2
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/1578
(cherry picked from commit dc273058cb0b6bef075e77272afc66f1a1fd3889)
The termios layer wants some level of guarantee that we've actually
submitted param changes to the hardware when our functions return, so we
need to do a little more waiting to avoid violating those guarantees.
This is especially important as some hardware has some minimum timing
specifications around this stuff, and without being less asynchronous
the software dealing with these devices can't reasonably operate the
hardware without more excessive delays than they should need.
More specifically, we make sure that:
- The command to start transfers is finished before we toggle DTR/RTS
- The status_change command finishes before we return, which may change
some fields in the softc that we need for a subsequent call into
usb_serial
- cfg_param finishes before we re-enable transfers, and we ensure that
RTS is appropriately toggled before we return to userland
This has been observed to fix some flakiness in connecting to some
ESP32 devices.
Tested by: kenrap from Libera
Reviewed by: imp, kib
(cherry picked from commit 36a80f4264350a2f4f0686eb91ae7f5943d40327)
ucom_queue_command will issue commands for open/close, then wait on them
to be finished. In the spirit of playing it safe, allow
ucom_queue_command's wait to be interrupted in case the usb process gets
jammed up waiting on the hardware -- we can at least recover the user
thread that initiated it, even if we can't recover the usb process.
Reviewed by: imp, kib
(cherry picked from commit 729eb176a465cedc55c5980f116d87be592421f1)
There's only one error that we can get back right now, but future
changes will add some more cases that we need to watch out for. Start
by returning errors and propagating them back.
Reviewed by: kib
(cherry picked from commit 51f3d0874f6216907c8971c4af9d6be6c93edf7b)
USB_GET_REPORT ioctl is documented to update ugd_actlen on return with
the number of bytes copied. It does not do this.
Reviewed by: wulf
PR: 282790
MFC after: 1 week
(cherry picked from commit 0b5d86b38ae9aec92ef96b9227a404a2df3c9234)
Key code swapping between [<>] and [^°] key is enabled for all Apple ISO
type keyboards. Before, swapping was enabled when the Eject key was
detected in HID usage. This did not correlate well with the swapped
keys presence.
usbdevs file is extended by several Apple keyboard models to support ISO
model identification.
Reviewed by: markj
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/1506
(cherry picked from commit 541e7a98b762916cd951a64dd7e77efd51dfa8dc)
By inspection, index increment was missing.
PR: 281843
Reported by: Matt Jacobson
Reviewed by: bz, markj
Fixes: e4611d2626 ("usb(4): Call optional endpoint_uninit() when changing configuration or alternate setting.")
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 114080d19973331426cd826f3a961c6ea9216a53)
That's a pretty old dock for Thinkpad X1 Carbon Gen4 and few others.
MFC after: 1 week
(cherry picked from commit a1bb5bdb0ab69bc3ce1f6051b6abc0cbaab83faa)
An interface's bpf could feasibly not exist, in which case
bpf_peers_present() would panic from a NULL pointer dereference. Solve
this by adding a new IfAPI that could deal with a NULL bpf, if such
could occur in the network stack.
Reviewed by: zlei
Sponsored by: Juniper Networks, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42082
(cherry picked from commit 8f31b879ecaf9e738dba631df4606742ee404e8e)
bpf: Prefer the boolean form when calling bpf_peers_present()
Reviewed by: markj, kp, #network
MFC with: 8f31b879ecaf
Differential Revision: https://reviews.freebsd.org/D45509
(cherry picked from commit 89204d9dcbe28558fae65936a0e93f44d926b88f)
- 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
(cherry picked from commit 5dc4682c32691b9d0a20abdc5479d6ce2b36915e)
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
(cherry picked from commit aa3860851b9f6a6002d135b1cac7736e0995eedc)
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")
(cherry picked from commit 80828c6fab0292b5c5a34a63558d837cb9308fbd)
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
(cherry picked from commit 7ef6ce51742d44a7375ccbaeda4cc64e034c4816)
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
(cherry picked from commit 8f374fa528d7643919bca1b4153dde03996305fe)
Since 5efea30f03 we can possibly lose a state transition which can
cause trouble further down the road.
The reproducer from 643d6dce6c1e 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).
Given this changes the internal structure of 'struct ieee80211vap',
which gets allocated by the drivers, and we do not have enough
spares, all wireless drivers need to be recompiled.
Given we are forced to do the update, we leave fields in the middle
of the struct and add more spares at the same time.
__FreeBSD_version gets updated to 1400509 to be able to detect
this change.
PR: 271979, 271988, 275255, 263613, 274003
Sponsored by: The FreeBSD Foundation (in 2023)
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43389
(cherry picked from commit 713db49d06deee90dd358b2e4b9ca05368a5eaf6)
(cherry picked from commit a890a3a5ddf33acb0a4000885945b89156799b07)
This is a popular USB WiFi chip.
Unfortunately, it's not supported by FreeBSD yet.
(cherry picked from commit 5b54b6ac8ca1bc0653a3b31e79c1bffd9b227c6e)
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
(cherry picked from commit 45cd29412eadbb0e8c40590a94b10663addac17a)
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
(cherry picked from commit b2caed2f8d699d6dc59ecf8810d945cdea148c44)
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.
(cherry picked from commit 3878bbf1bb9e68f8579b57cde7d4e5c77de93320)
if_smsc: fix build on armv6 & armv7
compile error was:
/usr/src/sys/dev/usb/net/if_smsc.c:1597:40: error: format specifies type 'unsigned long' but the argument has type 'ssize_t' (aka 'int') [-Werror,-Wformat]
"failed alloc for bootargs (%lu)", len);
~~~ ^~~
%zd
(cherry picked from commit 8a0ee306227a17a998bdc7af2275fd94b9164342)
PR: 274092
Reported by: Patrick M. Hausen (via ML)
Reviewed by: imp, karels, zlei
Tested by: Patrick M. Hausen
Approved by: karels
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D42463
Without these, the Norelsys NS1081 is completely defunct.
PR: 263868
Fixes: 7520b88860 ("usb(4): Automagically apply all quirks [...]")
(cherry picked from commit b332adfa96218148dfbb936a9c09d00484c868e3)
Without these, card hotplugging does not work on the GL3220.
PR: 263868
Fixes: 7520b88860 ("usb(4): Automagically apply all quirks [...]")
(cherry picked from commit 94efe9f91be7f3aa501983716db5a4378282a734)
The AX88179A has two firmware modes, one of which is backward
compatible with existing AX88178A/179 driver. The active firmware mode
can be controlled through a register.
Update axge(4) man page to mention 179A support and ensure that, when
bound to a AX88179A, the driver activates the compatible firmware mode.
Reviewed by: markj
Pull Request: https://github.com/freebsd/freebsd-src/pull/854
MFC after: 1 week
(cherry picked from commit 6962da914dd511349b219241e92b32329be76fc6)
ieee80211_node_incref() is the FreeBSD implementation of
ieee80211_ref_node(). Not being interested in the node returned
it was used as a shortcut in 3 drivers (ath, uath, wpi).
Replace the call with the public KPI of ieee80211_ref_node() and
ignore the result.
This leaves us with the single internal call going
ieee80211_ref_node() -> ieee80211_node_incref() and that should
help increasing portability but also limiting the places to trace
for node reference operations.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit f156cd892b55c04a39fa06d1899e6e316de77f03)
Newer versions of the AX88179 interweave dummies alongside valid
packet headers in bulk IN transfer data. This was probably done for
backward compatibility with existing drivers.
However current driver records these dummy headers as dropped frames,
leading to stats misreporting one Ierr per Ipkt.
This skips those dummy headers silently, thereby not generating Ierrs
for them.
Reviewed by: emaste
Pull Request: https://github.com/freebsd/freebsd-src/pull/842
(cherry picked from commit 70fbcd451b68b7f6038d8a602cd8d5e1bb890f1d)
Like other dwc3 controller, on Xilinx ZynqMP the base node is just here
to provide resets, the main dwc3 controller node is a child node.
Sponsored by: Beckhoff Automation GmbH & Co. KG
The XHCI controller on 64-bit SoCs need to use 64-bit DMA.
Add a quirk to tell the generic XHCI driver that 32-bit DMA needs
to be used, if there are any that may need to use 32-bit DMA only.
Reviewed by: andrew
Obtained from: Juniper Networks, Inc.
9600 was a standard baud rate decades ago, but 115200 is now more common
so choose defaults that are useful to the largest number of users.
Note that boot0sio does not support rates above 9600 so it remains
unchanged.
Reviewed by: bz, imp, manu
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36295
