linux-kernel - Re: [PATCH v3 2/5] serial: mvebu-uart: implement UART clock driver for configuring UART base clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210717180540.ersg5bslik6ivjie@pali>
Date:   Sat, 17 Jul 2021 20:05:40 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Vladimir Vid <vladimir.vid@...tura.hr>,
        Marek Behún <kabel@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-clk@...r.kernel.org, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 2/5] serial: mvebu-uart: implement UART clock driver
 for configuring UART base clock

On Saturday 17 July 2021 19:26:51 Andrew Lunn wrote:
> On Sat, Jul 17, 2021 at 02:38:26PM +0200, Pali Rohár wrote:
> > @@ -445,6 +472,7 @@ static void mvebu_uart_shutdown(struct uart_port *port)
> >  static int mvebu_uart_baud_rate_set(struct uart_port *port, unsigned int baud)
> >  {
> >  	unsigned int d_divisor, m_divisor;
> > +	unsigned long flags;
> >  	u32 brdv, osamp;
> >  
> >  	if (!port->uartclk)
> > @@ -463,10 +491,12 @@ static int mvebu_uart_baud_rate_set(struct uart_port *port, unsigned int baud)
> >  	m_divisor = OSAMP_DEFAULT_DIVISOR;
> >  	d_divisor = DIV_ROUND_CLOSEST(port->uartclk, baud * m_divisor);
> >  
> > +	spin_lock_irqsave(&mvebu_uart_lock, flags);
> 
> Hi Pali
> 
> You only need spin_lock_irqsave() if you plan on taking the spinlock
> in an interrupt handler. It seems unlikely the baud rate will be
> changed in interrupt context? Please check, and then swap to plain
> spin_lock().

Hello! Ok, I will check it.

> >  	brdv = readl(port->membase + UART_BRDV);
> >  	brdv &= ~BRDV_BAUD_MASK;
> >  	brdv |= d_divisor;
> >  	writel(brdv, port->membase + UART_BRDV);
> > +	spin_unlock_irqrestore(&mvebu_uart_lock, flags);
> >  
> >  	osamp = readl(port->membase + UART_OSAMP);
> >  	osamp &= ~OSAMP_DIVISORS_MASK;
> 
> > +	/* Recalculate UART1 divisor so UART1 baudrate does not change */
> > +	if (prev_clock_rate) {
> > +		divisor = DIV_U64_ROUND_CLOSEST((u64)(val & BRDV_BAUD_MASK) *
> > +						parent_clock_rate * prev_d1d2,
> > +						prev_clock_rate * d1 * d2);
> > +		if (divisor < 1)
> > +			divisor = 1;
> > +		else if (divisor > BRDV_BAUD_MAX)
> > +			divisor = BRDV_BAUD_MAX;
> > +		val = (val & ~BRDV_BAUD_MASK) | divisor;
> > +	}
> 
> I don't see any range checks in the patch which verifies the requested
> baud rate is actually possible. With code like this, it seems like the
> baud rate change will be successful, but the actual baud rate will not
> be what is requested.

This code is in function which changes parent UART clock from one used
by bootloader to clock which will be used by kernel UART driver.

Yes, it is possible if you configure something unusual in bootloader
that that this code breaks it. But I think there is not so much what we
can done here.

In other patches is updated function mvebu_uart_set_termios() which
verifies that you can set particular baudrate.

> > +	/* Recalculate UART2 divisor so UART2 baudrate does not change */
> > +	if (prev_clock_rate) {
> > +		val = readl(uart_clock_base->reg2);
> > +		divisor = DIV_U64_ROUND_CLOSEST((u64)(val & BRDV_BAUD_MASK) *
> > +						parent_clock_rate * prev_d1d2,
> > +						prev_clock_rate * d1 * d2);
> > +		if (divisor < 1)
> > +			divisor = 1;
> > +		else if (divisor > BRDV_BAUD_MAX)
> > +			divisor = BRDV_BAUD_MAX;
> > +		val = (val & ~BRDV_BAUD_MASK) | divisor;
> > +		writel(val, uart_clock_base->reg2);
> 
> Here it looks like UART1 could request a baud rate change, which ends
> up setting the clocks so that UART2 is out of range? Could the change
> for UART1 be successful, but you end up breaking UART2? I'm thinking
> when you are at opposite ends of the scale. UART2 is running at
> 110baud and UART1 at 230400baud.

This code is also in function which just do one time change of UART
parent clock. Once clk driver is probed this parent clock (and its d1
and d2 divisors) are not changed anymore. Parent clock and divisors are
chosen in way that kernel can always configure minimal baudrate 9600 on
both UARTs.

You are right that some combinations are not possible. But with these
patches it is fixed what is supported at clk driver probe time.

In v3 patch 5/5 is described how to calculate final baudrate from parent
clock and divisors d1, d2, d, m1, m2, m3, m4. Note that parent clock and
divisors d1 and d2 are shared for both UARTs. Other parameters (d, m1,
m2, m3, m4) can be set differently both UART1 and UART2. Changing shared
values is not possible during usage of UART.

If you have any idea how to improve current implementation, please let
me know.

Also note that all A3720 boards have disabled UART2 in DTS. And I'm not
sure if there is somebody who uses UART2 or who uses both UARTs.