[Samsung Galaxy Nexus] rs20:
Let's get the qualification bit out of the way: I am pursuing a PhD in Electrical Engineering. While you're right that this problem has its roots in hardware, and one possible fix would be a change to RF shielding, I encourage you to explain why a fix in firmware is so terribly inferior.

First of all, the problem has been exhibited in the bootloader, so the patch cannot be applied in the kernel as you have suggested, since the kernel isn't even in play in bootloader mode. If you're claiming that the fix will *only* fix the bug within Android, and the bootloader will remain borked, that's a very bold and easily verifiable claim now that the fix has been released.

Secondly, claims abound that there's something wrong with a software fix, as if this sort of thing isn't common. As pointed out by Google engineer Dan Morrill (google 'Dan Morrill Nexus Volume), and, as I can confirm from my undergraduate degree, whenever you have a button, you need to debounce ( wikipedia 'debounce' ) the signal from the switch or else you will get spurious multiple presses whenever the button is pressed. So the idea of using logic circuitry/software to inhibit event generation soon after a button press is the absolutely dead-standard solution used by everyone, from hobbyists to global giants. Adapting that to testing if a button press is consistent and long, and not spurious noise is an absolutely trivial modification.

OK, so this means that the problem can probably be completely solved in software. That is, perfectly solved, you will never ever see a spurious button press due to radio interference. The only concern that remains is whether or not the CPU is 'overwhelmed with interrupts'; spending all of its time handling spurious interrupts only to find that the interrupts should be ignored to implement debouncing. Again, there is a far better solution: *disable* the volume button interrupt for a certain amount of time. That is, disable the volume button interrupt, and set a hardware timer going to fire x milliseconds later. When the hardware timer fires, re-enable the volume button interrupt, and see what's up. During the x ms, the processor is left in complete peace to do whatever processing is necessary.

When implemented on a slow (strictly compared to a Cortex A8) Atmel AVR microcontroller, this sort of strategy can transform a situation where the microcontroller is completely stalled, running at 100% CPU, just continually handling spurious button press interrupts, to < 1% CPU utilisation with no apparent overhead whatsoever.

Now, a hypothetical question: When *any* smartphone company, with the tight profit margins endemic to such a competitive marketplace, is presented with the option to a) implement proper RF shielding, which costs 2 cents per phone or b) do it in software for zero cents in such a way that it has an absolutely immeasurably negligble bearing on software performance or battery life, what would they choose? The only difference here is that Samsung made a bit of a mistake in not testing it in all markets, and are now putting out the software that they would have always put out if they were on a more relaxed timeline.

I cannot stress this enough: it is almost completely irrelevant how nasty the signal on the volume button line is, and how badly it makes the *current* software lag out. Software has control over the nature of the interrupts that it REQUESTS (the R in IRQ), so a complete, perfect fix for the lagging comes inherently with the fix of the spurious presses. And it's a fix shared not just by all smartphones in the market (admittedly, perhaps, only to implement debouncing), but just about any modern device that has a button on it.

Now I've already made my point at this stage, but I'm going to keep on going just to cover all the bases.

A smartphone is a bloody complicated thing; it's much closer to a PC than an Arduino board with an Atmel AVR on it. Imagine this problem happened on your PC: a 2G phone nearby caused your keyboard to type random characters. Everyone seems to be reacting under an apparent assumption here that this 'bandaid fix' is like a terrible hack in Windows that just uses some complicated heuristic to guess which key presses are fake and discard them. So what would you prefer? The keyboard is broken, so you would want to fix that instead, right? How would you do that? By updating the software on the keyboard. So why didn't Samsung do that... oh, wait. They probably did.

While the firmware inside a keyboard is probably not updateable over USB, there's in a micro hiding in there. Even in a tightly integrated device like a smartphone, the volume button probably isn't directly wired to a pin on the CPU. Just like the keyboard in a PC goes via the southbridge, then the northbridge, and then finally to the CPU. (Yes, I know the northbridge and southbridge have been merged in recent PCs, this is beside point.) Even though space is at a premium in a smartphone, I seriously doubt they would send each volume button and power button (and touch screen inputs) into their own pins on the smartphone CPU. It'll go into some other intermediary chip that handles all of the above, handles debouncing etc, and multiplexes all the data onto some kind of standard bus from the CPU that handles everything else like speakers, microphone, SD card, etc.

If this isn't the case, and the volume buttons are indeed directly wired to the CPU, i've already covered that case above. But otherwise, read on.

That random intermediary chip is probably vaguely related to a microcontroller itself, and guess what, that microcontroller runs software ('firmware'). Update that software, and the problem is completely and utterly fixed, at no cost to performance or anyone's pockets. An utterly perfect solution, that no-one has any valid reason to complain about.