Attaching syscon_generic earlier than BUS_PASS_DEFAULT makes it more
difficult for specific syscon drivers to attach to the syscon node and to
get ordering right. Further discussion yielded the following set of
decisions:
- Move syscon_generic to BUS_PASS_DEFAULT
- If a platform needs a syscon with different attach order or probe
behavior, it should subclass syscon_generic and match on the SoC specific
compat string
- When we come across a need for a syscon that attaches earlier but only
specifies compatible = "syscon", we should create a syscon_exclusive driver
that provides generic access but probes earlier and only matches if "syscon"
is the only compatible. Such fdt nodes do exist in the wild right now, but
we don't really use them at the moment.
Additionally:
- Any syscon provider that has needs any more complex than a spinlock solely
for syscon access and a single memory resource should subclass syscon
directly rather than attempting to subclass syscon_generic or add complexity
to it. syscon_generic's attach/detach methods may be made public should the
need arise to subclass it with additional attach/detach behavior.
We introduce aw_syscon(4) that just subclasses syscon_generic but probes
earlier to meet our requirements for if_awg and implements #2 above for this
specific situation. It currently only matches a64/a83t/h3 since these are
the only platforms that really need it at the time being.
Discussed with: ian
Reviewed by: manu, andrew, bcr (manpages, content unchanged since review)
Differential Revision: https://reviews.freebsd.org/D13793
ian@ pointed out that BUS_PASS_DEFAULT + $anything is bogus, given that
BUS_PASS_DEFAULT is defined as __INT_MAX. Instead, we take a page out of
imx6_usbphy's book and use BUS_PASS_DEFAULT - 1000 to achieve the desired
effect of syscon_generic attaching before if_awg and other potential
consumers, but late enough that more specialized implementations should have
no problem attaching instead.
Reported by: ian
It still needs to be before if_awg at least in order to be available for
other operations, but it should not be attaching before interrupt
controllers at the very least.
This should make errors involving syscon register space colliding with other
devices a little more innocent, but these conflicts should really be tracked
down and resolved. One such conflict is with the Raspberry Pi 3 local
interrupt controller, noticed by tuexen@
Reported by: tuexen
This should help reduce confusion between syscon/syscons a little bit.
syscon is a resource generally modeled by FDT platforms, and not to be
confused with syscons.
