omap: mailbox: bunch of cleanups
Get series with b4
b4 am [email protected]Versions newest first
- v3 Latest2 of 14 patches 0 repliesNew
2 of 14 patches are in this archive. The cover letter announces 14.
Patches in v3 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 14/14 | omap: mailbox: reorganize headers | +0 | 1 reply | |
| 14/14 | omap: mailbox: reorganize headers | +0 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v3 yet.
Cover letter [PATCH v3 00/14] omap: mailbox: bunch of cleanups
Hi,
Quoted 6 lines · ext Russell King - ARM Linux
I think folk need to read this:
http://lkml.org/lkml/2010/6/2/472and consider what it means for the future, and what can be done to reduce the amount of "churn".
I believe Linus is considering more the amount of files not the amount of patches. Personally, I consider trivial cleanup patches the best way to start off with a new code (not saying that Felipe C. is new to mbox driver) and those patches are as needed as a brand new feature.
One thing to decrease the amount of lines of code in arch/arm is to move the drivers to they're proper locations on the tree. Only on omap we have 6 platform_drivers that could (should) be moved to proper locations after a 'trivial cleanups'.
gpio.c mcbsp.c timer drivers (for clocksource) etc, which alone would mean a decrease of 6237 lines out of arch/arm/*omap* only. And I'm not even counting the drivers which aren't platform_drivers.
The thing is that ARM is really different than x86 and there's no standardization among different SoCs, so other than moving drivers out of arch/arm, there isn't much we can do. Or do you have any ideas ?
Signature · 3 lines
balbi DefectiveByDesign.org