serial: 8250_dw: Fix breakage when HAVE_CLK=n
Commit 6a171b29 ("serial: 8250_dw: Allow hardware flow control to be used") recently broke the 8250_dw driver on platforms which don't select HAVE_CLK, as dw8250_set_termios() gets confused by the behaviour of the fallback HAVE_CLK=n clock API in linux/clk.h which pretends everything is fine but returns (valid) NULL clocks and 0 HZ clock rates. That 0 rate is written into the uartclk resulting in a crash at boot, e.g. on Cavium Octeon III based UTM-8 we get something like this: 1180000000800.serial: ttyS0 at MMIO 0x1180000000800 (irq = 41, base_baud = 25000000) is a OCTEON ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1 at drivers/tty/serial/serial_core.c:441 uart_get_baud_rate+0xfc/0x1f0 ... Call Trace: ... [<ffffffff8149c2e4>] uart_get_baud_rate+0xfc/0x1f0 [<ffffffff814a5098>] serial8250_do_set_termios+0xb0/0x440 [<ffffffff8149c710>] uart_set_options+0xe8/0x190 [<ffffffff814a6cdc>] serial8250_console_setup+0x84/0x158 [<ffffffff814a11ec>] univ8250_console_setup+0x54/0x70 [<ffffffff811901a0>] register_console+0x1c8/0x418 [<ffffffff8149f004>] uart_add_one_port+0x434/0x4b0 [<ffffffff814a1af8>] serial8250_register_8250_port+0x2d8/0x440 [<ffffffff814aa620>] dw8250_probe+0x388/0x5e8 ... The clock API is defined such that NULL is a valid clock handle so it wouldn't be right to check explicitly for NULL. Instead treat a clk_round_rate() return value of 0 as an error which prevents uartclk being overwritten. Fixes: 6a171b29 ("serial: 8250_dw: Allow hardware flow control to be used") Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: David Daney <david.daney@cavium.com> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-serial@vger.kernel.org Cc: linux-clk@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: bcm-kernel-feedback-list@broadcom.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Jason Uy <jason.uy@broadcom.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Showing
Please register or sign in to comment