Hi,
On Wed, Dec 29, 2010 at 10:35:31AM +0000, Liam Girdwood wrote:
Even though the driver will never work with those other archs, compile
testing with several of them isn't bad at all.
This seems unnecessary since this driver is for the OMAP platform only
and also means maintainers will have to waste time fixing any build
issues for this driver on irrelevant architectures. The costs here
outweigh any benefits....
If that's the case, what's the use for linux-next, then ? Drivers should
be arch independent as much as possible, no ? Isn't that why we don't
want drivers using branches to things such as machine_is_omap4_panda()
or similar ?
But the whole audio part on OMAP is still in a bad shape anyway, e.g.
mcbsp exports omap-only functions for drivers to use, so this will only
be yet another driver to the pile :-p
It also seems inconsistent with the other OMAP system headers in
plat-omap too.
Other than a few drivers which still need converting (and are on their
way) I can only see really arch-specific bits and pieces under plat/.
Not sure what's your point here.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
