With clang 15, the following -Werror warning is produced:
sys/dev/usb/input/atp.c:2018:11: error: variable 'n_vertical_scrolls' set but not used [-Werror,-Wunused-but-set-variable]
u_int8_t n_vertical_scrolls = 0;
^
The 'n_vertical_scrolls' variable is no longer used after 197b9a2ef0,
so remove it.
MFC after: 3 days
(cherry picked from commit b621f3cf2d)
Split the current FDT-only implementation up into an FDT and an
ACPI part reusing and sharing as much code as possible (thanks mw!).
This makes the Synopsis XHCI root hubs attach correctly on SolidRun's
HoenyComb instead of just the generic XHCI root and this means we
are also doing proper chip setup and applying the quirk needed there [1].
There is one problem with ACPI attachment in that it uses the generic
XHCI PNP ID. So we need to do extra checks in order to not claim
all xhci, which means we check for a known quirk to be present
in acpi_probe. Long term this isn't scaling and this was discussed
in SolidRun's Discord Channel in 2021 with the intend that "jnettlet"
will take this to a steering committee. Since then ACPI has kind-of
become a technology non grata (due to not getting changes into Linux
timely) so it is unclear if this will ever happen. If there will be
further hardware with dwc3/ACPI we should go and make sure this problem
gets solved.
[1] 24698f90b7/Silicon/NXP/LX2160A/AcpiTables/Dsdt/Usb.asl
Reviewed by: manu, mw
Differential Revision: https://reviews.freebsd.org/D32256
(cherry picked from commit fbb5cb66f7)
Rather than hiding behind #if 0, hide the debugging behind DWC3_DEBUG
so it can be turned on with a single define. Require bootverbose
to print anything so we can still avoid spamming the console if DWC3_DEBUG
is on.
Harmonize the format string in snsp_dwc3_dump_regs() to always print the
full register and also print the XHCI quirks.
Call snsp_dwc3_dump_regs() twice, before and after generic XHCI attachment
and initialisation as this may have an effect on the confirgumation state.
Obtained from: an old debug patch
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D35700
(cherry picked from commit 11a7d5e5d9)
Rather than just printing the Global SNPS ID Register store it as well
so we can do a version check later.
In addition, for debugging purposes, read the Global Hardware Parameters
Registers and print them.
Based on the snpsid disable an XHCI feature using a quirk prepared
in 447c418da0.
Add the "snps,dis_u3_susphy_quirk" quirk and handle Suspend USB3.0 SS PHY
after power-on-reset/during core initialization (suggested to be cleared)
based on the DWC3_GHWPARAMS0 register.
Obtained from: an old debugging patch
Reviewed by: mw (earlier version), mmel
Differential Revision: https://reviews.freebsd.org/D35699
(cherry picked from commit 09cdf4878c)
(cherry picked from commit ec32fc2af5)
Enable dwc3's auto retry feature. For IN transfers with crc errors
or internal overruns this will make the host reply with a
non-terminating retry ACK. I believe the hope was to improve
reliability after seeing occasional hiccups.
Obtained from: an old debugging patch
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D35698
(cherry picked from commit cec0a5ec6b)
If snps,dis-del-phy-power-chg-quirk is set, the register bit should be
cleared not ored on (it's the "dis" version).
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D35697
(cherry picked from commit 0084212bfd)
Switch the driver to use device based functions which will work not
only with FDT but also ACPI.
While here make dr_mode a local variable as it is only used during
probe and not needed later in the softc.
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D33170
(cherry picked from commit b11f52f4db)
It seems we do not clear UPS_C_BH_PORT_RESET and UPS_C_PORT_RESET
conditions after warm or port reset. Add that code.
Obtained from: an old patch mainly debugging other problems
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D35483
(cherry picked from commit 8f892e9bee)
While XHCI is very generic some revisions of chipsets have problems.
On dwc3 <= 3.00a Port Disable does not seem to work so we need to not
enable it.
For that introduce quirks to xhci so that controllers can steer
certain features. I would hope that this is and remains the only one.
Obtained from: an old patch mainly debugging other problems
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D35482
(cherry picked from commit 447c418da0)
This avoids an issue where IN endpoint data received from the device right
before the file handle is closed, gets lost.
PR: 263995
Sponsored by: NVIDIA Networking
(cherry picked from commit b6f615255d)
Create a wrapper for newbus to take giant and for busses to take it too.
bus_topo_lock() should be called before interacting with newbus routines
and unlocked with bus_topo_unlock(). If you need the topology lock for
some reason, bus_topo_mtx() will provide that.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D31831
(cherry picked from commit c6df6f5322)
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33827
(cherry picked from commit fb6cebd8bd)
Because the maximum number of endpoint contexts is stored there.
Tested by: ehaupt@
PR: 262882
Approved by: re (gjb, early MFC)
Sponsored by: NVIDIA Networking
(cherry picked from commit 09dd1adfa4)
Only drop BULK and INTERRUPT endpoints, to reset the data toggle,
because for other endpoint types this is not critical.
While at it fix some whitespace.
Tested by: ehaupt@
PR: 262882
Approved by: re (gjb, early MFC)
Sponsored by: NVIDIA Networking
(cherry picked from commit e276d28150)
Use the drop and enable endpoint context commands to force a reset of
the data toggle for USB 2.0 and USB 3.0 after:
- clear endpoint halt command (when the driver wishes).
- set config command (when the kernel or user-space wants).
- set alternate setting command (only affected endpoints).
Some XHCI HW implementations may not allow the endpoint reset command when
the endpoint context is not in the halted state.
Reported by: Juniper and Gary Jennejohn
Sponsored by: NVIDIA Networking
(cherry picked from commit cda31e7349)
computing the same isochronous start frame number over and over again.
PR: 257082
Sponsored by: NVIDIA Networking
(cherry picked from commit 8fc2a3c417)
(cherry picked from commit f52783fcf5)
(cherry picked from commit cf48d1f771)
as given by the XHCI hardware parameters to avoid scheduling isochronous
transfers too early.
Sponsored by: NVIDIA Networking
(cherry picked from commit d038463bd2)
This should fix an issue where the "udev->re_enumerate_wait" field never gets
processed and reset. In this case usbconfig will wait forever and never return.
Sponsored by: NVIDIA Networking
(cherry picked from commit c7cd6f809d)
Currently there are five quirks the USB stack tries to automagically detect:
- UQ_MSC_NO_PREVENT_ALLOW
- UQ_MSC_NO_SYNC_CACHE
- UQ_MSC_NO_TEST_UNIT_READY
- UQ_MSC_NO_GETMAXLUN
- UQ_MSC_NO_START_STOP
If any of the quirks above are set, no further quirks will be probed.
If any of the USB mass storage tests fail, the USB device is
re-enumerated as a last resort to clear any error states from the
device. Then the USB stack will try to probe and attach the umass<N>
device passing the detected quirks.
While at it give more details in dmesg about what is going on.
Tested by: several
Submitted by: Idwer Vollering <vidwer_fbsdbugs@gmail.com>
Differential Revision: https://reviews.freebsd.org/D30919
Sponsored by: NVIDIA Networking
(cherry picked from commit 7520b88860)
The USB controller drivers assume they can cast a NULL pointer to a
struct and find the address of a member. KUBSan complains about this so
replace with the __offsetof and __containerof macros that use either a
builtin function where available, or the same NULL pointer on older
compilers without the builtin.
Reviewers: hselasky
Subscribers: imp
Reviewed by: hselasky
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33865
(cherry picked from commit a3cea15680)
If port resume fails, likely the USB device is detached. Ignore such errors,
because else the USB stack might try forever trying to resume the device,
before it will proceed detaching it.
Sponsored by: NVIDIA Networking
(cherry picked from commit a88e1a04df)
