On 19.12.2011 04:49, Shawn Guo wrote:
On Sun, Dec 18, 2011 at 06:34:14PM +0100, Dirk Behme wrote:
Factor out the uart save/restore functionality instead of
having the same code several times in the driver.
Signed-off-by: Dirk Behme<dirk.behme@xxxxxxxxx>
CC: Saleem Abdulrasool<compnerd@xxxxxxxxxxxx>
CC: Sascha Hauer<s.hauer@xxxxxxxxxxxxxx>
CC: Fabio Estevam<festevam@xxxxxxxxx>
CC: Uwe Kleine-König<u.kleine-koenig@xxxxxxxxxxxxxx>
CC: linux-serial@xxxxxxxxxxxxxxx
---
drivers/tty/serial/imx.c | 38 +++++++++++++++++++++++++++++++-------
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 163fc90..6a01c2a 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -260,6 +260,31 @@ static inline int is_imx21_uart(struct imx_port *sport)
}
/*
+ * Save and restore functions for UCR1, UCR2 and UCR3 registers
+ */
+static void imx_console_mode(struct uart_port *port,
Function name imx_console_mode seems not like a couple with
imx_console_restore. And I guess something like
imx_port_ucrs_save[restore] would be better?
+ unsigned int *ucr1,
+ unsigned int *ucr2,
+ unsigned int *ucr3)
Can we define something like 'struct imx_port_ucrs' to contains these?
Yes, we could have different function names above and use a struct.
I implemented what Sascha asked for in
http://www.spinics.net/lists/arm-kernel/msg144960.html
though:
-- Sascha wrote: --
I'm thinking about:
imx_console_mode(struct uart_port *port, u32 *ucr1, u32 *ucr2, u32 *ucr2);
imx_console_restore(struct uart_port *port, u32 ucr1, u32 ucr2, u32 ucr3);
-- Sascha end --
It seems Shawn proposes
imx_port_ucrs_save(struct uart_port *port, struct *imx_port_ucrs);
imx_port_ucrs_restore(struct uart_port *port, struct *imx_port_ucrs);
(?)
Sascha, Shawn: Could you agree on what we should use?
Once you agreed, I will send an update of both two patches.
Many thanks and best regards
Dirk
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
