list of future callbacks. We've already processed the list (and removed
all the entries), and there's nothing in the future that will process
the list again.
This avoids the possibility of leaving an entry in the list that points
to an unloaded module's former address space.
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)
By default, RPI firmware sets the max CPU frequency to 600MHz. This can be
overridden by setting arm_freq in config.txt, but the default freq at boot
is still 600MHz.
Add logic to rc.local to compare the current vs. max CPU frequency; if they
differ, set the target frequency to the maximum.
XXX: also there should be real bounds-check logic in here.
XXX: if the on-disk data structure contains rubbish this code will
XXX: leak or trample arbitrary kernel memory.
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.
