[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75Vf=JGbmydAaeA=81YDViVtj7cG91Sr4teJ8mhFNH8AhAw@mail.gmail.com>
Date: Fri, 8 Jul 2022 18:09:07 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Pali Rohár <pali@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
Johan Hovold <johan@...nel.org>,
Marek Behún <kabel@...nel.org>,
"open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] serial: Fix support for UPF_SPD_* flags
On Fri, Jul 8, 2022 at 5:54 PM Pali Rohár <pali@...nel.org> wrote:
> On Friday 08 July 2022 17:42:03 Andy Shevchenko wrote:
> > On Fri, Jul 8, 2022 at 4:20 PM Pali Rohár <pali@...nel.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.
You stated that SPD_CUST is broken in some drivers, so you are trying
to fix a broken ugly hack. Why? Instead of making it rot and be
removed eventually, you pump life into frankenstein.
> > > > 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?
This I missed, I was thinking that you are talking about a new user,
now I read briefly and it seems that it's about an existing user.
Anyway, that change I suppose.
> > 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?
Dunno.
Can you point it out to me? I can't find it quickly.
> > 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.
So why should the kernel suffer if it already provides something good
for the user and user space ignores that?
> > [1]: https://github.com/npat-efault/picocom/blob/master/termios2.txt
> > [2]: https://github.com/jmesmon/picocom/issues/2
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists