Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 8 Jul 2022 18:25:32 +0200
From:   Pali =?utf-8?B?Um9ow6Fy?= <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 =?utf-8?B?QmVow7pu?= <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
Message-ID: <20220708162532.jefbmpokampkuahv@pali>
References: <CAHp75VddDG-ZJpbAb5ZhKaMpP0L+CMEx2pcYy3FOMiaxNydCWA@mail.gmail.com>
 <YmK7drS0XgnTQcaf@kroah.com>
 <20220707084840.jvsstvyx2ul5ltb6@pali>
 <YsgsH94PV/wAX0Vu@kroah.com>
 <20220708132621.4v2es73h52aq3izn@pali>
 <Ysg2RW0B/cLL3k+k@kroah.com>
 <20220708142001.7fciqnfckznlvsa4@pali>
 <CAHp75Vci1zeDV1axd_v_PLLPGfF5AzAzmmcegjD1djqnR6XUcA@mail.gmail.com>
 <20220708155413.rlc3iyf72tdwthfa@pali>
 <CAHp75Vf=JGbmydAaeA=81YDViVtj7cG91Sr4teJ8mhFNH8AhAw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHp75Vf=JGbmydAaeA=81YDViVtj7cG91Sr4teJ8mhFNH8AhAw@mail.gmail.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

On Friday 08 July 2022 18:09:07 Andy Shevchenko wrote:
> On Fri, Jul 8, 2022 at 5:54 PM Pali Rohár <pali@kernel.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@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.
> 
> 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.

Firstly I got rejection of my other patches because they does not handle
SDP_CUST correctly. So I decided to look at those issues and fix it via
helper function which can be easily reused in all drivers. So helper
function wrap all "ugly" hacks. Then I got reaction that SDP should be
removed. Then I got another reaction that that "I'm not saying to remove
them" and another another reaction why to be removed eventually.

So how should I interpret this? I'm feeling that you are just trying to
annoy people with this "do this", "do opposite", "do again it", "do
again opposite"...

> > > > > 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.

Argh... Have you read emails to which you wrote reply? So copy+paste
relevant part from my previous email just for you:

 "New version of tcsetattr and ioctl_tty manpages would have documented
  how to use BOTHER (it is currently in the manpages git)."

Plus in past I also pointed to the extended version of that example from
manpage which is currently in my repo on github:
https://github.com/pali/linux-baudrate.git

> > > 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?

Because it is unusable? API which standard linux userspace applications
cannot use is useless. And for application develop it does not matter if
issue is in kernel part of API or userspace part of API. At the end
would be use used.

With whole this discussion I have feeling that there correct way is just
to use SDP flags in userspace as there is no interest in fixing BOTHER's
c_ospeed and c_ispeed in kernel drivers and it was rejected just because
of not handling SDP flags correctly.

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