linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
To: Lukas Wunner <lukas@wunner.de>
Cc: Daniel Winkler <danielwinkler@google.com>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	<linux-serial@vger.kernel.org>,
	<linux-mediatek@lists.infradead.org>,
	chromeos-bluetooth-upstreaming 
	<chromeos-bluetooth-upstreaming@chromium.org>,
	Aaron Sierra <asierra@xes-inc.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Revert "serial: 8250: Fix max baud limit in generic 8250 port"
Date: Wed, 1 Jul 2020 14:39:04 +0300	[thread overview]
Message-ID: <20200701113904.7zh534vmlvjvojia@mobilestation> (raw)
In-Reply-To: <20200701043001.73qhxyyjx6bayn2m@wunner.de>

Hello Lukas,

On Wed, Jul 01, 2020 at 06:30:01AM +0200, Lukas Wunner wrote:
> On Tue, Jun 30, 2020 at 04:42:11PM -0700, Daniel Winkler wrote:
> > This reverts commit 0eeaf62981ecc79e8395ca8caa1570eaf3a12257.
> 
> That is not an upstream commit.  You probably mean:
> 
>     commit 7b668c064ec33f3d687c3a413d05e355172e6c92
>     Author: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>     Date:   Thu May 7 02:31:32 2020 +0300
> 
>     serial: 8250: Fix max baud limit in generic 8250 port
> 
> And you didn't cc the commit author (hereby fixed).
> 
> Thanks,
> 
> Lukas

Thanks for Cc'ing me.

> 
> > 
> > The change regresses the QCA6174A-3 bluetooth chip, preventing
> > firmware from being properly loaded. We have verified that without
> > this patch, the chip works as intended.

That text doesn't say what is really wrong and why the firmware couldn't be loaded.
The original commit gets back the 8250 port baud rate limitation so if the baud
gets out of the range [uartclk / 16 / UART_DIV_MAX; (port->uartclk + tolerance) /
16], then it will be clamped to be within it. That range is what the standard
8250 port supports. Acceptance of out of that range values will cause a
problem further in calling serial8250_get_divisor() and uart_get_divisor()
methods (see the original patch log message) for standard 8250 ports. Any different
behavior must be taken into account by a custom set_termios() callbacks or at
least must be workarounded so the standard 8250 ports wouldn't be affected. So in
order to investigate the root cause of the problem it would be good to at least
know what your platform was and what UART port has been used in the attempt to
load the QCA6174A-3 chip firmware.

-Sergey

> > 
> > Signed-off-by: Daniel Winkler <danielwinkler@google.com>
> > ---
> > 
> >  drivers/tty/serial/8250/8250_port.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> > index 1632f7d25acca..e057c65ac1580 100644
> > --- a/drivers/tty/serial/8250/8250_port.c
> > +++ b/drivers/tty/serial/8250/8250_port.c
> > @@ -2618,8 +2618,6 @@ static unsigned int serial8250_get_baud_rate(struct uart_port *port,
> >  					     struct ktermios *termios,
> >  					     struct ktermios *old)
> >  {
> > -	unsigned int tolerance = port->uartclk / 100;
> > -
> >  	/*
> >  	 * Ask the core to calculate the divisor for us.
> >  	 * Allow 1% tolerance at the upper limit so uart clks marginally
> > @@ -2628,7 +2626,7 @@ static unsigned int serial8250_get_baud_rate(struct uart_port *port,
> >  	 */
> >  	return uart_get_baud_rate(port, termios, old,
> >  				  port->uartclk / 16 / UART_DIV_MAX,
> > -				  (port->uartclk + tolerance) / 16);
> > +				  port->uartclk);
> >  }
> >  
> >  void
> > -- 
> > 2.27.0.212.ge8ba1cc988-goog

  reply	other threads:[~2020-07-01 11:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 23:42 [PATCH] Revert "serial: 8250: Fix max baud limit in generic 8250 port" Daniel Winkler
2020-07-01  4:30 ` Lukas Wunner
2020-07-01 11:39   ` Serge Semin [this message]
2020-07-01 12:46     ` Alain Michaud
2020-07-01 13:26 ` Greg Kroah-Hartman
2020-07-01 18:26   ` Daniel Winkler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200701113904.7zh534vmlvjvojia@mobilestation \
    --to=sergey.semin@baikalelectronics.ru \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=asierra@xes-inc.com \
    --cc=chromeos-bluetooth-upstreaming@chromium.org \
    --cc=danielwinkler@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).