[PATCH] serial: 8250_early: Setup divider when uartclk is passed

[PATCH] serial: 8250_early: Setup divider when uartclk is passed

[Michal Simek]

device->baud is always non zero value because it is checked already in
early_serial8250_setup() before init_port is called.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 drivers/tty/serial/8250/8250_early.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_early.c b/drivers/tty/serial/8250/8250_early.c
index ae6a256524d8..5cd8c36c8fcc 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -122,7 +122,7 @@ static void __init init_port(struct earlycon_device *device)
 	serial8250_early_out(port, UART_FCR, 0);	/* no fifo */
 	serial8250_early_out(port, UART_MCR, 0x3);	/* DTR + RTS */
 
-	if (port->uartclk && device->baud) {
+	if (port->uartclk) {
 		divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
 		c = serial8250_early_in(port, UART_LCR);
 		serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
-- 
2.17.0

Re: [PATCH] serial: 8250_early: Setup divider when uartclk is passed

[Matt Redfearn]

Hi Michal

On 23/04/18 10:18, Michal Simek wrote:
> device->baud is always non zero value because it is checked already in
> early_serial8250_setup() before init_port is called.

True, currently init_port is only called from the one location and so 
the test is a little redundant, though I don't see the harm in testing 
both inputs to the divisor calculation immediately before use such that 
any future call path avoids setting a bad divisor.

> 
> Fixes: 0ff3ab701963 ("serial: 8250_early: Only set divisor if valid clk & baud")
> Cc: stable <stable@vger.kernel.org>

Even if the test is dropped going forward, I wouldn't consider it's 
presence a "bug" such that a fix needs to be backported.

Thanks,
Matt

> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> 
>   drivers/tty/serial/8250/8250_early.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_early.c b/drivers/tty/serial/8250/8250_early.c
> index ae6a256524d8..5cd8c36c8fcc 100644
> --- a/drivers/tty/serial/8250/8250_early.c
> +++ b/drivers/tty/serial/8250/8250_early.c
> @@ -122,7 +122,7 @@ static void __init init_port(struct earlycon_device *device)
>   	serial8250_early_out(port, UART_FCR, 0);	/* no fifo */
>   	serial8250_early_out(port, UART_MCR, 0x3);	/* DTR + RTS */
>   
> -	if (port->uartclk && device->baud) {
> +	if (port->uartclk) {
>   		divisor = DIV_ROUND_CLOSEST(port->uartclk, 16 * device->baud);
>   		c = serial8250_early_in(port, UART_LCR);
>   		serial8250_early_out(port, UART_LCR, c | UART_LCR_DLAB);
> 

Re: [PATCH] serial: 8250_early: Setup divider when uartclk is passed

[Michal Simek]

Hi Matt,

On 23.4.2018 15:21, Matt Redfearn wrote:
> Hi Michal
> 
> On 23/04/18 10:18, Michal Simek wrote:
>> device->baud is always non zero value because it is checked already in
>> early_serial8250_setup() before init_port is called.
> 
> True, currently init_port is only called from the one location and so
> the test is a little redundant, though I don't see the harm in testing
> both inputs to the divisor calculation immediately before use such that
> any future call path avoids setting a bad divisor.

I will let others to decide.

> 
>>
>> Fixes: 0ff3ab701963 ("serial: 8250_early: Only set divisor if valid
>> clk & baud")
>> Cc: stable <stable@vger.kernel.org>
> 
> Even if the test is dropped going forward, I wouldn't consider it's
> presence a "bug" such that a fix needs to be backported.

Not a problem with not adding this to stable.

Thanks,
Michal

Re: [PATCH] serial: 8250_early: Setup divider when uartclk is passed

[Greg Kroah-Hartman]

On Mon, Apr 23, 2018 at 11:18:11AM +0200, Michal Simek wrote:
> device->baud is always non zero value because it is checked already in
> early_serial8250_setup() before init_port is called.
> 
> Fixes: 0ff3ab701963 ("serial: 8250_early: Only set divisor if valid clk & baud")
> Cc: stable <stable@vger.kernel.org>

This isn't "fixing" anything, as the logic is identical before, or
after, this patch is committed.  So I'll apply this, but will drop these
two tags.

thanks,

greg k-h