linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Johan Hovold" <johan@kernel.org>,
	"Marek Behún" <kabel@kernel.org>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] serial: Fix support for UPF_SPD_* flags
Date: Fri, 8 Jul 2022 17:54:13 +0200	[thread overview]
Message-ID: <20220708155413.rlc3iyf72tdwthfa@pali> (raw)
In-Reply-To: <CAHp75Vci1zeDV1axd_v_PLLPGfF5AzAzmmcegjD1djqnR6XUcA@mail.gmail.com>

On Friday 08 July 2022 17:42:03 Andy Shevchenko wrote:
> On Fri, Jul 8, 2022 at 4:20 PM Pali Rohár <pali@kernel.org> wrote:
> > On Friday 08 July 2022 15:51:01 Greg Kroah-Hartman wrote:
> > > On Fri, Jul 08, 2022 at 03:26:21PM +0200, Pali Rohár wrote:
> > > > On Friday 08 July 2022 15:07:43 Greg Kroah-Hartman wrote:
> > > > > On Thu, Jul 07, 2022 at 10:48:40AM +0200, Pali Rohár wrote:
> > > > > > On Friday 22 April 2022 16:28:06 Greg Kroah-Hartman wrote:
> 
> ...
> 
> > > > > I'm not saying remove them, I'm saying let us not add any more
> > > > > dependancies on them in order to keep new applications from ever wanting
> > > > > to use them.
> > > >
> > > > Last time you wrote to remove them. Now saying not to remove them. So I
> > > > do not understand you now.
> 
> There was a _new_ addition of the ugly SPD_CUST, that's what I believe
> Greg opposes to. And I support that.

Which addition? I do not understand you. There was not any new driver
with introduction of SPD support.

> > > I'm sorry, I am totally lost.
> >
> > So look what you have wrote? Who is lost here is me.
> >
> > > How about starting over and resubmitting
> > > the changes you want and we can go from there.
> >
> > What to resubmit? I do not understand you. In case you lost emails or
> > accidentally removed them, you can look at them in archive, not? I hope
> > that you do not want me to copy+paste all existing patches with all your
> > quotes on them which you wrote into new emails.
> 
> That change that adds the new user of SPD_CUST?

What you are talking about? Which user?

> In any case the best summary about BOTHER I ever read is this [1] (and
> an initial steps in picocom [2]).

Is not that example in manpage enough?

> And I believe that instead of
> SPD_CUST we should get rid (or at least minimize) the problems with
> BOTHER in user space.

I looked into archives and seems that glibc people are not interested in
this area. And I'm not going to spend time on another project which seems
to be useless.

> [1]: https://github.com/npat-efault/picocom/blob/master/termios2.txt
> [2]: https://github.com/jmesmon/picocom/issues/2
> 
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko

  reply	other threads:[~2022-07-08 15:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21 16:30 [PATCH 0/3] serial: Fix support for UPF_SPD_* flags Pali Rohár
2022-03-21 16:30 ` [PATCH 1/3] serial: core: Document why UPF_SPD_CUST is not handled in uart_get_baud_rate() Pali Rohár
2022-03-21 16:30 ` [PATCH 2/3] serial: core: Fix function uart_update_timeout() to handle UPF_SPD_CUST flag Pali Rohár
2022-03-21 16:30 ` [PATCH 3/3] serial: Fix support for UPF_SPD_* flags in serial drivers Pali Rohár
2022-03-22 14:29 ` [PATCH 0/3] serial: Fix support for UPF_SPD_* flags Andy Shevchenko
2022-03-22 18:53   ` Pali Rohár
2022-04-22 14:28   ` Greg Kroah-Hartman
2022-07-07  8:48     ` Pali Rohár
2022-07-08 13:07       ` Greg Kroah-Hartman
2022-07-08 13:26         ` Pali Rohár
2022-07-08 13:51           ` Greg Kroah-Hartman
2022-07-08 14:20             ` Pali Rohár
2022-07-08 15:42               ` Andy Shevchenko
2022-07-08 15:54                 ` Pali Rohár [this message]
2022-07-08 16:09                   ` Andy Shevchenko
2022-07-08 16:25                     ` Pali Rohár
2022-07-08 17:41                       ` Andy Shevchenko

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=20220708155413.rlc3iyf72tdwthfa@pali \
    --to=pali@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=johan@kernel.org \
    --cc=kabel@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).