linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PING][PATCH v3 0/2] serial: 8250: Fixes for Oxford Semiconductor 950 UARTs
Date: Thu, 14 Apr 2022 14:47:17 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2204141421190.9383@angie.orcam.me.uk> (raw)
In-Reply-To: <CAHp75VdOf3+j8yQh=-f6iCN_gRhisgoQjov2kK1fhgv7xaBJRg@mail.gmail.com>

On Thu, 14 Apr 2022, Andy Shevchenko wrote:

> > >  Here's v3 of the outstanding fixes for Oxford Semiconductor 950 UARTs.
> > > As the change for the default FIFO rx trigger level has been already
> > > merged with commit d7aff291d069 ("serial: 8250: Define RX trigger levels
> > > for OxSemi 950 devices") only one patch of the original series remains.
> >
> >  Ping for:
> > <https://lore.kernel.org/lkml/alpine.DEB.2.21.2203310114210.44113@angie.orcam.me.uk/>
> 
> I still didn't get the answer why BOTHER can't be used instead of
> spreading the old hack.

 I just fail to see any sense in repeating myself over and over.

> You mentioned fractional baud rates and
> something else, and I asked why do you need them and from where you
> got the limitation of 16-bit values for dividers when using BOTHER.

 Sigh, I have documented it there with the original submission 10 months 
ago and then repeated with every reiteration:

>  Finally the 16-bit UART_DIV_MAX limitation of the baud rate requested
> with `serial8250_get_baud_rate' makes the standard rates of 200bps and
> lower inaccessible in the regular way with the baud base of 15625000.
> That could be avoided by tweaking our 8250 driver core appropriately, but
> I have figured out with modern serial port usage that would not be the
> best use of my time.  Someone who does have a real need to use an Oxford
> device at these low rates can step in and make the necessary chances.

 To put it shortly: the `spd_cust' feature is out there and it works, and 
contrary to what you assert requires no maintenance effort if you just 
leave it alone, while the alternative has various shortcomings that do 
require effort if they were to be addressed.  So please just get over it 
and let users choose what suits them best while letting developers focus 
on other stuff that keeps waiting.  If someone is happy with what BOTHER 
offers, then by no means I keep them from using it.

 I fail to understand really why a piece of code to correct and improve 
broken UART baud rate calculation has to be stuck in limbo for almost a 
year.  There is nothing wrong with this code and it has a proper change 
description and my observation has been that actually broken code often 
with half a sentence serving as justification gets accepted with no fuss 
all the time. :(

  Maciej

  reply	other threads:[~2022-04-14 15:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31  7:11 [RESEND][PATCH v3 0/2] serial: 8250: Fixes for Oxford Semiconductor 950 UARTs Maciej W. Rozycki
2022-03-31  7:11 ` [RESEND][PATCH v3 1/2] serial: 8250: Fold EndRun device support into OxSemi Tornado code Maciej W. Rozycki
2022-04-15  9:13   ` Greg Kroah-Hartman
2022-04-17 23:02     ` Maciej W. Rozycki
2022-04-20 14:48       ` Greg Kroah-Hartman
2022-04-21 21:38         ` Maciej W. Rozycki
2022-04-15  9:13   ` Greg Kroah-Hartman
2022-04-17 23:03     ` Maciej W. Rozycki
2022-03-31  7:11 ` [RESEND][PATCH v3 2/2] serial: 8250: Add proper clock handling for OxSemi PCIe devices Maciej W. Rozycki
2022-04-13 22:53 ` [PING][PATCH v3 0/2] serial: 8250: Fixes for Oxford Semiconductor 950 UARTs Maciej W. Rozycki
2022-04-14 12:45   ` Andy Shevchenko
2022-04-14 13:47     ` Maciej W. Rozycki [this message]
2022-04-14 13:55       ` Andy Shevchenko
  -- strict thread matches above, loose matches on Subject: below --
2022-02-12  8:41 [PATCH " Maciej W. Rozycki
2022-03-01 20:52 ` [PING][PATCH " Maciej W. Rozycki
2022-03-18 12:10   ` Greg Kroah-Hartman
2022-03-31  7:12     ` Maciej W. Rozycki

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=alpine.DEB.2.21.2204141421190.9383@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=andy.shevchenko@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    /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).