diff options
author | Wolfram Sang <w.sang@pengutronix.de> | 2011-04-29 15:06:41 +0200 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2011-05-02 19:08:55 +0100 |
commit | 7635965891761a732a610aa7ad9371de742ef52b (patch) | |
tree | e3d10a04ef7f43de126d0d0626b99cd204b7ae71 /.mailmap | |
parent | cde7c41feaa06cb6bfc748b2fc3c7d809091c2b0 (diff) | |
download | lwn-7635965891761a732a610aa7ad9371de742ef52b.tar.gz lwn-7635965891761a732a610aa7ad9371de742ef52b.zip |
ARM: mach-stmp37xx: remove mach
This mach has not seen any updates since the initial inclusion besides
generic cleanup. Furthermore:
- It has a lot of reinvented interfaces, leaking all sorts of
mach-related includes into the drivers. One example is the dmaengine
which does not use the linux dmaengine-API but some privately exported
symbols. So, drivers cannot be reused. mach-mxs is very similar and
does it better.
- It can be doubted that this worked at all. Check the DMA routines in
stmp37xx.c for copy/paste bugs. A lot of APBX-related stuff is
actually writing into registers for APBH.
- There is only one board defined (which I couldn't find any trace of
despite being a development board). In this board, only two devices
have resources, the debug uart and the application uart. Neither of
those have the needed custom drivers merged (and never will). debug
uart is amba-pl011 which has an in-kernel driver without the
mach-specific-stuff. appuart has a driver which was introduced for
mach-mxs, and this one is reusable for a properly done mach.
So, this single board registers only unsupported devices and the
generic code looks suspicious and has poor design. Delete this
stuff. If there is interest, it is wiser to restart using
mach-mxs.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions