As discussed on current-users@, SANE uses ugen via libusb and not
uscanner, so users are not well served by having uscanner. Consensus
is that addressing how to adjust permissions for scanners should not
block restoring basic functionionality.
(Compile-tested only, but there are multiple reports of this being the
right approach.)
The mct on exynos uses an interrupt map so we add support now. Devices
represent their interrupts either through a combination of interrupt-parent
and interrupts properties, where the 'interrupts' property is an array of
one or more interrupt specifiers; or through a combination of an
interrupt-parent that points to an interrupt-map, where the interrupt-map
contains 2 or more entries consisting of an index, a pointer to an
interrupt-controller, and a specifier for that controller.
This code adds the ability to walk the interrupt-map and return a specifier.
Unfortunately, the addition requires changing the interface to the
interrupt-controllers' _establish and _intstr functions, so this check in
contains a rototill of the three existing fdt interrupt controllers to use
the new interface.
step N of N: get rid of baggage by removing whole files. What's left is in
approximately the same shape as when the FDT update started, that is mostly
broken. What's missing is most of the 76 devices recognized in the dtd. In
other words, This is barely the start of a port.
Next up, gpio then i2c, followed either by straightening out usb or getting
the sdhc driver to work -- both probably require getting the interrupt
combiner to work first. A large chunk of work is left to do on the clocks.
I barely got them attaching to fdt and didn't do anything to take advantage
of the information in the dtd.
None of the other existing drivers, such as they are, properly request gpios,
i2c or clocks, and, of course power domains are off the table.
There is a minimum conversion on the clock driver.
The USB driver needs reordering and is broken, but it was broken before.
Next up: tactical nuclear weapons
It is rather amazing that XU4 gets as far as it does, given how much of this
code simply doesn't work. Focusing now on getting everything converted to
FDT. Next up USB and clocks. After that nuke everything that's not needed
and start the port in earnest.
This is broken. exynos_gpio_bank_config and the call to it are wrong, and
the acquire function doesn't work.
But I'm in over my head and I need to discuss this:
There is a problem with the dtd: it doesn't have addresses for the individual
gpios. Do I add the addresses to it, or go back to the old version where I
have them hard coded in the driver.
There is a problem with creating the gpio device entries: I suspect I really
need to treat the pinctrl devices as busses and create the gpios as attached
to those busses, but I'm not familiar with how to do that in NetBSD. At the
minimum, a pointer to a similar situation would give me code to follow.
This is different than the usual bus attachment in that the gpios aren't
devices in the dtd (they don't have "compatible" properties) so they don't
get an attach routine called. An alternative to generating the bus
attachments might be to add "compatible" properties to the GPIO entries
in the dtd. so that they do get attached in the normal way.
If I'm going to modify the DTD, then it should be checked in, so a decision
on where to check them in would be nice, even if it does mean spreading them
all over because of license issues. (This DTD is GPL v2)
This is a mess and I don't understand why part of it works, but it passes
the basic test.
There has to be some better way to get the info that I'm grabbing from the
exynos_uarts[] array.
I'm not sure how to deal with VA != PA when the DTB contains physical rather
than virtual addresses. This is going to be an issue for all of the drivers.
This enables the use of FDT on the XU4 but doesn't add any drivers. However,
with this check in, XU4 becomes useless without a device tree blob from the
Linux tree, which isn't checked in anywhere.
This will work only if the patch to sysmon_wdog.c to convert it to
MODULE_CLASS_DRIVER is installed. Symptom of failure is a crash in
lockdebug because of an uninitialized mutex.
