All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	linux-alpha@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	linux-serial@vger.kernel.org, linux-rtc@vger.kernel.org
Subject: Re: [PATCH 2/2 v4] alpha: add a delay before serial port read
Date: Thu, 7 May 2020 10:52:01 +0200	[thread overview]
Message-ID: <20200507085201.GA1097552@kroah.com> (raw)
In-Reply-To: <alpine.LRH.2.02.2005070407010.5006@file01.intranet.prod.int.rdu2.redhat.com>

On Thu, May 07, 2020 at 04:18:49AM -0400, Mikulas Patocka wrote:
> 
> 
> On Wed, 6 May 2020, Greg Kroah-Hartman wrote:
> 
> > On Wed, May 06, 2020 at 01:04:38PM -0400, Mikulas Patocka wrote:
> > > 
> > > I've created this patch that adds a global macro/variable 
> > > serial_port_needs_delay. I've also deleted UPQ_DELAY_BEFORE_READ and test 
> > > serial_port_needs_delay directly in io_serial_in, so that the compiler 
> > > will optimize it out on non-alpha architectures.
> > 
> > That's not good, what about systems with hundreds of serial ports?
> 
> I doubt that someone will conect hundreds of serial ports to such an old 
> alpha machine :)



> 
> > > > But, there is no other way to detect this based on hardware
> > > > signatures/types instead?  That is usually the best way to do it, right?
> > > 
> > > It's hard to detect Alpha without using '#ifdef CONFIG_ALPHA' :) The ISA 
> > > serial port hardware is simple, so I think that you can't distinguish it 
> > > just based on its behavior.
> > 
> > The ISA serial port hardware does not have a unique vendor/product id
> > somewhere?  Some other sort of definition that we can use to determine
> > exactly what type of system we are running on?
> 
> AFAIK it doesn't. You can only distinguish 8250, 16550 and 16550A - but 
> not the vendor.
> 
> > > Index: linux-stable/drivers/tty/serial/8250/8250_port.c
> > > ===================================================================
> > > --- linux-stable.orig/drivers/tty/serial/8250/8250_port.c	2020-05-06 18:54:24.000000000 +0200
> > > +++ linux-stable/drivers/tty/serial/8250/8250_port.c	2020-05-06 18:54:24.000000000 +0200
> > > @@ -30,6 +30,7 @@
> > >  #include <linux/uaccess.h>
> > >  #include <linux/pm_runtime.h>
> > >  #include <linux/ktime.h>
> > > +#include <linux/pci.h>
> > >  
> > >  #include <asm/io.h>
> > >  #include <asm/irq.h>
> > > @@ -442,6 +443,9 @@ static unsigned int mem32be_serial_in(st
> > >  
> > >  static unsigned int io_serial_in(struct uart_port *p, int offset)
> > >  {
> > > +	if (serial_port_needs_delay)
> > > +		ndelay(300);
> > 
> > Again, this should be a per-port thing, not all ports in the system are
> > this broken, right?
> > 
> > thanks,
> > 
> > greg k-h
> 
> Here is the patch that uses per-port flag UPQ_DELAY_BEFORE_READ. The flag 
> is activated if we have the specific PCI-ISA bridge and if the serial port 
> is an ISA port.


Better, care to submit this in a format that it can be applied in?

thanks,

greg k-h

  reply	other threads:[~2020-05-07  8:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 11:23 [PATCH 2/2] alpha: add a delay before serial port read Mikulas Patocka
2020-05-06 11:47 ` Greg Kroah-Hartman
2020-05-06 15:29   ` [PATCH 2/2 v2] " Mikulas Patocka
2020-05-06 15:49     ` Greg Kroah-Hartman
2020-05-06 15:57       ` Mikulas Patocka
2020-05-06 16:08         ` Greg Kroah-Hartman
2020-05-06 17:04           ` [PATCH 2/2 v3] " Mikulas Patocka
2020-05-06 17:45             ` Greg Kroah-Hartman
2020-05-07  8:18               ` [PATCH 2/2 v4] " Mikulas Patocka
2020-05-07  8:52                 ` Greg Kroah-Hartman [this message]
2020-05-07 10:53                   ` Mikulas Patocka
2020-05-07 11:10                     ` Greg Kroah-Hartman
2020-05-07 12:53                       ` Mikulas Patocka
2020-05-07 12:57                       ` [PATCH 2/2 v5] " Mikulas Patocka
2020-05-07 13:58                         ` Greg Kroah-Hartman
2020-05-07 14:03                           ` Mikulas Patocka
2020-05-10  0:13                 ` [PATCH 2/2 v4] " Maciej W. Rozycki
2020-05-23 10:37                   ` Mikulas Patocka

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=20200507085201.GA1097552@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mattst88@gmail.com \
    --cc=mpatocka@redhat.com \
    --cc=rth@twiddle.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.