| Message ID | 20220321163055.4058-1-pali@kernel.org |
|---|---|
| Headers | show |
| Series | serial: Fix support for UPF_SPD_* flags | expand |
On Mon, Mar 21, 2022 at 11:07 PM Pali Rohár <pali@kernel.org> 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@kernel.org/ > > > 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? I would rather expect to have this removed completely.
On Tuesday 22 March 2022 16:29:08 Andy Shevchenko wrote: > On Mon, Mar 21, 2022 at 11:07 PM Pali Rohár <pali@kernel.org> 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@kernel.org/ > > > > > > 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? Johan pointed in above mentioned patch that it would break ASYNC_SPD_FLAGS. So I have looked at how are ASYNC_SPD_FLAGS implemented to ensure that they would work correctly... > I would rather expect to have this removed completely. Well, if somebody is going to remove it, I have no objections. But I understood that ASYNC_SPD_FLAGS should be still supported...
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@kernel.org> 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@kernel.org/ > > > > > > > > > > > > > > > > > > > > > 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.
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. > > 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? In any case the best summary about BOTHER I ever read is this [1] (and an initial steps in picocom [2]). And I believe that instead of SPD_CUST we should get rid (or at least minimize) the problems with BOTHER in user space. [1]: https://github.com/npat-efault/picocom/blob/master/termios2.txt [2]: https://github.com/jmesmon/picocom/issues/2
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
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. > > > > 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
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
On Fri, Jul 8, 2022 at 6:25 PM Pali Rohár <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á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"... 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 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)." 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 me. 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 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. 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.hack.
Support for UPF_SPD_* flags is currently broken in more drivers for two reasons. First one is that uart_update_timeout() function does not calculate timeout for UPF_SPD_CUST flag correctly. Second reason is that userspace termios structre is modified by most drivers after each TIOCSSERIAL or TCSETS call to discard activation of UPF_SPD_* flags. Reproducer for these issues: #include <termios.h> #include <sys/ioctl.h> #include <asm/ioctls.h> #include <linux/serial.h> static unsigned cdiv(unsigned a, unsigned b) { if (!b) return b; return (a + (b/2)) / b; } void set_active_spd_cust_baud(int fd, unsigned baudrate) { struct serial_struct serial; struct termios termios; tcgetattr(fd, &termios); ioctl(fd, TIOCGSERIAL, &serial); serial.flags &= ~ASYNC_SPD_MASK; serial.flags |= ASYNC_SPD_CUST; serial.custom_divisor = cdiv(serial.baud_base, baudrate); ioctl(fd, TIOCSSERIAL, &serial); cfsetspeed(&termios, B38400); tcsetattr(fd, TCSANOW, &termios); } int is_spd_cust_active(int fd) { struct serial_struct serial; struct termios termios; tcgetattr(fd, &termios); ioctl(fd, TIOCGSERIAL, &serial); return (serial.flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST && cfgetospeed(&termios) == B38400; } (error handling was ommited for simplification) 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. 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@kernel.org/ Johan, Greg, could you please test these patches if there is not any regression? Pali Rohár (3): serial: core: Document why UPF_SPD_CUST is not handled in uart_get_baud_rate() serial: core: Fix function uart_update_timeout() to handle UPF_SPD_CUST flag serial: Fix support for UPF_SPD_* flags in serial drivers drivers/tty/serial/21285.c | 2 +- drivers/tty/serial/8250/8250_mtk.c | 2 +- drivers/tty/serial/8250/8250_omap.c | 2 +- drivers/tty/serial/8250/8250_port.c | 2 +- drivers/tty/serial/altera_uart.c | 2 +- drivers/tty/serial/ar933x_uart.c | 2 +- drivers/tty/serial/arc_uart.c | 2 +- drivers/tty/serial/dz.c | 2 +- drivers/tty/serial/imx.c | 3 +- drivers/tty/serial/lantiq.c | 2 +- drivers/tty/serial/lpc32xx_hs.c | 2 +- drivers/tty/serial/men_z135_uart.c | 2 +- drivers/tty/serial/mps2-uart.c | 2 +- drivers/tty/serial/msm_serial.c | 2 +- drivers/tty/serial/mvebu-uart.c | 2 +- drivers/tty/serial/owl-uart.c | 2 +- drivers/tty/serial/pch_uart.c | 2 +- drivers/tty/serial/pic32_uart.c | 2 +- drivers/tty/serial/rda-uart.c | 2 +- drivers/tty/serial/rp2.c | 2 +- drivers/tty/serial/sccnxp.c | 2 +- drivers/tty/serial/serial-tegra.c | 2 +- drivers/tty/serial/serial_core.c | 76 ++++++++++++++++++++++++++++- drivers/tty/serial/sprd_serial.c | 2 +- drivers/tty/serial/timbuart.c | 2 +- drivers/tty/serial/vt8500_serial.c | 2 +- drivers/tty/serial/xilinx_uartps.c | 2 +- include/linux/serial_core.h | 2 + 28 files changed, 103 insertions(+), 28 deletions(-)