On Mon, 29 Apr 2013, Linus Torvalds wrote: > The "explanations" for why it should be in drivers/ is this mindless drivel: > > On Tue, Feb 22 2011, Daniel Walker wrote: > > On Tue, 2011-02-22 at 12:47 -0800, Dima Zavin wrote: > > > >> What is the problem leaving it under arch/arm/mach-msm? > > > > Because it's a driver. > > Seriously. That's the *ONLY* explanation given.
This certainly sucks as an answer. > WTF? That's a singularly *bad* reason for moving things to "drivers". Agreed. > And I'm calling the ARM people out on this idiocy. Arnd and Nico - > stop encouraging this kind of crap. Move things to drivers only once > there is actual reason for it. If it's some proprierary single-SoC > thing, it can damn well stay away from other people. And it definitely > shouldn't mess up autocomplete in some core location. All I wish to add to what Arnd already stated is this: We ought to gather drivers together according to their _purpose_. Especially if they provide some generic functionality via a common API to be used by the rest of the kernel. In some cases that API just begs to be created and commonalities factored out from individual drivers, which also warrants a move to drivers/. Of course the cpufreq drivers, or even the cpuidle drivers, are awfully platform specific, or even proprietary single-SoC in many cases. But the interface they register into and the services they provide are common, and it is far easier for someone maintaining the cpuidle infrastructure to improve the interface and avoid conflicts by having all the related drivers at the same place. . It even helps next driver author look for better examples than only the last SoC they worked with. However this is a design goal, not a hard rule. If a piece of code has no interface commonality with anything else then it is indeed not worth the hassle. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
