On Sun, 8 Jun 2014, Russell King - ARM Linux wrote: > On Sat, Jun 07, 2014 at 04:53:34PM -0700, Olof Johansson wrote: > > You do realize that you have absolutely zero leverage over us on this, > > right? Our product is already shipped with kernel code that fixes > > this. > > That is never a justification for forcing /any/ code into the kernel. > > We've been here before with the iPAQs, where there were all sorts of > horrid hacks that were in the code for that device, and we said no to > it, and we kept it out of the mainline kernel, and stopped those hacks > polluting elsewhere (because people got to know on the whole that if > they used those hacks, it would bar them from mainline participation.) That's different. The iPaq had very little in terms of firmware, and the one it had was field upgradable with almost no risk to brick it (unless you wanted to hack the firmware code but that's another story). The reason iPaq had never been well supported in mainline can be attributed to laziness for not wanting to make the code into a shape acceptable for mainline inclusion. But nothing fundamentally prevented that from happening if someone had wanted to do it. Here we're talking about firmware-induced hacks for which, had there been no firmware, the kernel would be in full position to fix properly because that would have been a kernel bug after all. Hence my crusade against this "you should abstract things in firmware" mantra. Especially for mobile devices. But, because firmware already exists out there and it is between prohibitive and impossible to fix, we have no choice but to compensate in the kernel some times. In this very case my approach is to render the firmware irrelevant globally rather than trying to work around it for one particular device. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |