I wouldn't say that was a bug. That was by design of Dmitry, which
I'm far from happy with. If an output is being used to drive a
reset line, you always want to actively drive it to the inactive
Compilation errors are only going to get worse as ARM continues to
diversify. We're entirely reliant on sfr's linux-next project to
find build errors prior to merging, and it is unfortunate that this
time around, sfr was on vacation on the run up to the merge window.
Hence, there was very little build coverage of the changes that
went in during this last merge window. I spent most of the merge
window fixing up all the shitty patches that people had submitted up
until that point that either broke compilation or had runtime
If 2.6.27 doesn't boot even with the reset fixes applied, there's a hell
of a lot of changes that could be the culpret (and I don't remember much
that happened before this last merge window.) The only thing I can
suggest is to bisect with the reset fixes on top.
This is precisely where we're let down by not having a Zaurus maintainer
who knows the Zaurus issues inside out, and regularly puts effort into
building and testing kernels for these platforms. That's a hint for
anyone who's reading this.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
