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: > > > > > On Tue, Mar 22, 2022 at 04:29:08PM +0200, Andy Shevchenko wrote: > > > > > > On Mon, Mar 21, 2022 at 11:07 PM Pali Rohár <pali@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > Support for UPF_SPD_* flags is currently broken in more drivers for two > > > > > > > reasons. First one is that uart_update_timeout() function does not > > > > > > > > > > > > the uart_update_timeout() > > > > > > > > > > > > > calculate timeout for UPF_SPD_CUST flag correctly. Second reason is that > > > > > > > userspace termios structre is modified by most drivers after each > > > > > > > > > > > > structure > > > > > > > > > > > > ... > > > > > > > > > > > > > (error handling was ommited for simplification) > > > > > > > > > > > > omitted > > > > > > > > > > > > > After calling set_active_spd_cust_baud() function SPD custom divisor > > > > > > > should be active and therefore is_spd_cust_active() should return true. > > > > > > > > > > > > > > But it is not active (cfgetospeed does not return B38400) and this patch > > > > > > > series should fix it. I have tested it with 8250 driver. > > > > > > > > > > > > drivers > > > > > > > > > > > > > Originally Johan Hovold reported that there may be issue with these > > > > > > > ASYNC_SPD_FLAGS in email: > > > > > > > https://lore.kernel.org/linux-serial/20211007133146.28949-1-johan@xxxxxxxxxx/ > > > > > > > > > > > > > > > > > > > > > Johan, Greg, could you please test these patches if there is not any > > > > > > > regression? > > > > > > > > > > > > I'm wondering why we are still supporting this ugly hack? > > > > > > Doesn't BOTHER work for you? > > > > > > > > > > Yes, I too do not want to add more support for these old flags. If they > > > > > have not been working, let's not add support for them as obviously no > > > > > one is using them. Let's try to remove them if at all possible. > > > > > > > > Well, it works partially. For more drivers SET method is working, but > > > > GET method returns incorrect value. If your userspace application is > > > > written in a way that does not retrieve from kernel current settings > > > > then it has big probability that application works. > > > > > > I do not understand, sorry, what do you mean by this? > > > > I mean that SET methods are working, GET methods not. In this case SET > > done via ioctl(TIOCSSERIAL) and GET via ioctl(TIOCGSERIAL). > > > > > And as you are responding to a months-old thread, I am totally lost, and > > > don't even know what the patch here was... > > > > > > > So, do you really want to remove support for these old flags completely? > > > > That would of course break above applications. > > > > > > 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. > > 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. > > greg k-h 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.
