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;
MIME-Version: 1.0
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>
 <20220708162532.jefbmpokampkuahv@pali>
In-Reply-To: <20220708162532.jefbmpokampkuahv@pali>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Fri, 8 Jul 2022 19:41:37 +0200
Message-ID: <CAHp75VfD24SxejjQ6hq85BTaHpOGPj3-diEqxu5BGnABm0Yz1w@mail.gmail.com>
Subject: Re: [PATCH 0/3] serial: Fix support for UPF_SPD_* flags
To:     =?UTF-8?Q?Pali_Roh=C3=A1r?= <pali@kernel.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        Johan Hovold <johan@kernel.org>,
        =?UTF-8?B?TWFyZWsgQmVow7pu?= <kabel@kernel.org>,
        "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Jul 8, 2022 at 6:25 PM Pali Roh=C3=A1r <pali@kernel.org> wrote:
>
> On Friday 08 July 2022 18:09:07 Andy Shevchenko wrote:
> > On Fri, Jul 8, 2022 at 5:54 PM Pali Roh=C3=A1r <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=C3=A1r <pali@kernel.org> wr=
ote:
> > > > > On Friday 08 July 2022 15:51:01 Greg Kroah-Hartman wrote:
> > > > > > On Fri, Jul 08, 2022 at 03:26:21PM +0200, Pali Roh=C3=A1r 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=C3=A1r w=
rote:
> > > > > > > > > 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 m=
ore
> > > > > > > > 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 beli=
eve
> > > > 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"...

Ask someone who makes a decision. I wrote just my p.o.v. on the
"problem". I think there is no problem with SPD_CUST, it should be
oblivionized.

> > > > > > 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 email=
s 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 a=
ll 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)."

I do not know the "manpages git" URL. Neither its hosting. kernel.org?
And then? It took time for you to just write something instead of helping m=
e.
Whatever. I found the commits.

> 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 s=
eems
> > > 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.

Then help make it happen?

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

I'm puzzled who asked you about SPD_CUST implementation... It.is.an.ugly.ha=
ck.

--=20
With Best Regards,
Andy Shevchenko