We shouldn't force USB2 only based on if we have an external PHY.
The internal PHY register tell us what link speed we can acheive
and we need to force USB2 only if it cannot do USB3.
This is only available after revision 0x290A of the dwc3 IP.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37394
Fixed: 1331c0f44b ("Add support for RockChip RK356X to DWC3 driver.")
Sponsored by: Beckhoff Automation GmbH & Co. KG
We need to enable some quirks based on the version so read it.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37393
Sponsored by: Beckhoff Automation GmbH & Co. KG
Usually dwc3 needs a glue node that contain the SoC specific clocks/resets.
For some reason the RK3328 DTS doesn't have this glue node and the clocks
are specified in the dwc3 node directly.
The bindings says that it is allowed but doesn't specified some strict names
for them.
Add a specific case for RK3328 based on the compatible string.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37392
Sponsored by: Beckhoff Automation GmbH & Co. KG
The SAN interceptors simply take a bus_space_tag_t, so we're
dropping qualifiers here. const semantics with a ptr typedef mean we'd
have to drop or change the bus_space_tag_t abstraction used in the SAN
sanitizers in order to make a compatible change there, which likely
isn't worth it.
Reviewed by: andrew, markj
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D36764
For RK356x platform, we can set bit 26 of DWC3_GUCTL1 register
for usb 2.0 device.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D36211
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
MFC after: 10 days
Differential Revision: https://reviews.freebsd.org/D32256
During the review of 09cdf4878c we
switched from cached registers to reading them as needed.
One read of the two reads was moved after the softreset got triggered
and as a result returned 0 rather than the proper register value.
Moving the read before the softreset gets initiated seems to make
things work again and xhci.c no longer complains about
"Controller does not support 4K page size.".
MFC after: 10 days
X-MFC with: 09cdf4878c
Pointy hat to: bz
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
MFC after: 2 weeks
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D35700
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.
MFC after: 2 weeks
Obtained from: an old debugging patch
Reviewed by: mw (earlier version), mmel
Differential Revision: https://reviews.freebsd.org/D35699
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
MFC after: 2 weeks
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D35698
If snps,dis-del-phy-power-chg-quirk is set, the register bit should be
cleared not ored on (it's the "dis" version).
MFC after: 2 weeks
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D35697
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.
MFC after: 2 weeks
Reviewed by: mw
Differential Revision: https://reviews.freebsd.org/D33170
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
MFC after: 2 weeks
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D35482
Only drop BULK and INTERRUPT endpoints, to reset the data toggle,
because for other endpoint types this is not critical.
Tested by: ehaupt@
PR: 262882
MFC after: 3 hours
Sponsored by: NVIDIA Networking
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
MFC after: 1 week
Sponsored by: NVIDIA Networking
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
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
The saf1761 OTG support was only for mips targets (BERI?). Retire it.
Sponsored by: Netflix
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D33706
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
Add support for the "snps,dis_rxdet_inp3_quirk" quirk needed
at least on SolidRun's HoneyComb.
Reviewed by: manu, mw
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32921
Currently, to support 64-byte contexts, xhci_ctx_[gs]et_le(32|64) take a
pointer to the field within a 32-byte context and, if 64-byte contexts
are in use, compute where the 64-byte context field is and use that
instead by deriving a pointer from the 32-byte field pointer. This is
done by exploiting a combination of 64-byte contexts being the same
layout as their 32-byte counterparts, just with 32 bytes of padding at
the end, and that all individual contexts are either in a device
context or an input context which itself is page-aligned. By masking out
the low 4 bits (which is the offset of the field within the 32-byte
contxt) of the offset within the page, the offset of the invididual
context within the containing device/input context can be determined,
which is itself 32 times the number of preceding contexts. Thus, adding
this value to the pointer again gets 64 times the number of preceding
contexts plus the field offset, which gives the offset of the 64-byte
context plus the field offset, which is the address of the field in the
64-byte context.
However, this involves a fair amount of lying to the compiler when
constructing these intermediate pointers, and is rather difficult to
reason about. In particular, this is problematic for CHERI, where we
compile the kernel with subobject bounds enabled; that is, unless
annotated to opt out (e.g. for C struct inheritance reasons where you
need to be able to downcast, or containerof idioms), a pointer to a
member of a struct is a capability whose bounds only cover that field,
and any attempt to dereference outside those bounds will fault,
protecting against intra-object buffer overflows. Thus the pointer given
to xhci_ctx_[gs]et_le(32|64) is a capability whose bounds only cover the
field in the 32-byte context, and computing the pointer to the 64-byte
context field takes the address out of bounds, resulting in a fault when
later dereferenced.
This can be cleaned up by using a different abstraction. Instead of
doing the 32-byte to 64-byte conversion on access to the field, we can
do the conversion when getting a pointer to the context itself, and
define proper 64-byte versions of contexts in order to let the compiler
do all the necessary arithmetic rather than do it manually ourselves.
This provides a cleaner implementation, works for CHERI and may even be
slightly more performant as it avoids the need to mess with masking
pointers (which cannot in the general case be optimised by compilers to
be reused across accesses to different fields within the same context,
since it does not know that the contexts are over-aligned compared with
the C ABI requirements).
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D32554
Change the probe return value from BUS_PROBE_DEFAULT to BUS_PROBE_GENERIC
given this is the "generic" attach method. This allows individual
drivers using XHCI generic but needing their own intialisation to
gain priority for attaching over the generic implementation.
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D32257
