Andy Green wrote: > For example mass GPIO resetting in > kernel idea is incompatible with this path.
The worst that can happen is that we unnecessarily reset a GPIO to its reset state. Any real changes this would cause to be made are divergences between boot loader and kernel. > (only: the other reset state for some regs is PMU standby which we > know we entered)... No rule without exception: if we do a reboot or a debug board reset, we don't enter PMU.Suspend. > Same for the odd wrong level GPIO, we have to workaround in bootloader. > ~ That doesn't undermine anything else. It's great if the boot loader fixes things. All I'm saying is that the kernel shouldn't count on it. The kernel is the last thing that runs, so it should be the one who determines the system state. Otherwise, you get the kind of obscure dependency about which this thread started. And this is already the second such critter we found in a week or so. - Werner
