| Message ID | cover.1585905873.git.michal.simek@xilinx.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | serial: uartps: Revert dynamic port allocation | expand |
On Fri, Apr 03, 2020 at 11:24:29AM +0200, Michal Simek wrote: > Hi, > > there were several changes done in past in uartps drivers which have been > also done in uartlite driver. > Here is the thread about it > https://lore.kernel.org/linux-serial/20191203152738.GF10631@localhost/ > > This series reverts all patches which enabled dynamic port allocation and > returning driver to the previous state. There were added some features in > meantime which are not affected by this series. Should this go into 5.7-final as it's causing problems now, and backported as well? Or can it wait until 5.8-rc1? thanks, greg k-h
On 03. 04. 20 11:32, Greg KH wrote: > On Fri, Apr 03, 2020 at 11:24:29AM +0200, Michal Simek wrote: >> Hi, >> >> there were several changes done in past in uartps drivers which have been >> also done in uartlite driver. >> Here is the thread about it >> https://lore.kernel.org/linux-serial/20191203152738.GF10631@localhost/ >> >> This series reverts all patches which enabled dynamic port allocation and >> returning driver to the previous state. There were added some features in >> meantime which are not affected by this series. > > Should this go into 5.7-final as it's causing problems now, and > backported as well? Or can it wait until 5.8-rc1? These patches have been added to v4.20. It means all version from that are affected. The issue I am aware of is when you setup stdout-path = "serialX:115200n8" where X is not 0. But as was discussed the concept is based on Johan wrong that's why it can be consider as bug fix. Thanks, Michal
On Fri, Apr 03, 2020 at 11:37:46AM +0200, Michal Simek wrote: > On 03. 04. 20 11:32, Greg KH wrote: > > On Fri, Apr 03, 2020 at 11:24:29AM +0200, Michal Simek wrote: > >> Hi, > >> > >> there were several changes done in past in uartps drivers which have been > >> also done in uartlite driver. > >> Here is the thread about it > >> https://lore.kernel.org/linux-serial/20191203152738.GF10631@localhost/ > >> > >> This series reverts all patches which enabled dynamic port allocation and > >> returning driver to the previous state. There were added some features in > >> meantime which are not affected by this series. > > > > Should this go into 5.7-final as it's causing problems now, and > > backported as well? Or can it wait until 5.8-rc1? > > These patches have been added to v4.20. It means all version from that > are affected. > > The issue I am aware of is when you setup stdout-path = > "serialX:115200n8" where X is not 0. > > But as was discussed the concept is based on Johan wrong that's why it > can be consider as bug fix. Ok, I'll queue these up after 5.7-rc1 is out, for inclusion in 5.7-final, and cc: for stable, as I agree, they should all be reverted. Thanks for doing the work. greg k-h
On 03. 04. 20 11:44, Greg KH wrote: > On Fri, Apr 03, 2020 at 11:37:46AM +0200, Michal Simek wrote: >> On 03. 04. 20 11:32, Greg KH wrote: >>> On Fri, Apr 03, 2020 at 11:24:29AM +0200, Michal Simek wrote: >>>> Hi, >>>> >>>> there were several changes done in past in uartps drivers which have been >>>> also done in uartlite driver. >>>> Here is the thread about it >>>> https://lore.kernel.org/linux-serial/20191203152738.GF10631@localhost/ >>>> >>>> This series reverts all patches which enabled dynamic port allocation and >>>> returning driver to the previous state. There were added some features in >>>> meantime which are not affected by this series. >>> >>> Should this go into 5.7-final as it's causing problems now, and >>> backported as well? Or can it wait until 5.8-rc1? >> >> These patches have been added to v4.20. It means all version from that >> are affected. >> >> The issue I am aware of is when you setup stdout-path = >> "serialX:115200n8" where X is not 0. >> >> But as was discussed the concept is based on Johan wrong that's why it >> can be consider as bug fix. > > Ok, I'll queue these up after 5.7-rc1 is out, for inclusion in > 5.7-final, and cc: for stable, as I agree, they should all be reverted. > Thanks for doing the work. Thanks. I am definitely interested to hear more how this could be done differently because that hardcoded limits are painful. On FPGAs you can have a lot of uarts for whatever reason and users are using DT aliases to have consistent naming. Specifically on Xilinx devices we are using uartps which is ttyPS, uartlite which is ttyUL, ns16500 which is ttyS and also pl011 which is ttyAMA. Only ttyAMA or ttyPS on one chip are possible. And right now you can't have serial0 alias pointed ttyPS0 and another serial0 pointed to ttyUL0 or ttyS0. That's why others are shifted and we can reach that hardcoded NR_UART limit easily. And this was the reason why I have done these patches in past to remove any limit from these drivers and if user asks for serial100 alias you simply get ttyPS100 node. Johan mentioned any solution use in USB stack but I haven't really had a time to take a look at it how feasible it is to bring back to all drivers. Thanks, Michal
On 2020-04-03 11:51, Michal Simek wrote: > > Thanks. I am definitely interested to hear more how this could be done > differently because that hardcoded limits are painful. > On FPGAs you can have a lot of uarts for whatever reason and users are > using DT aliases to have consistent naming. > Specifically on Xilinx devices we are using uartps which is ttyPS, > uartlite which is ttyUL, ns16500 which is ttyS and also pl011 which is > ttyAMA. > Only ttyAMA or ttyPS on one chip are possible. > > And right now you can't have serial0 alias pointed ttyPS0 and another > serial0 pointed to ttyUL0 or ttyS0. That's why others are shifted and > we > can reach that hardcoded NR_UART limit easily. > And this was the reason why I have done these patches in past to remove > any limit from these drivers and if user asks for serial100 alias you > simply get ttyPS100 node. I would argue that the trouble originates from every uart driver using its own naming scheme and thereby creating separate namespaces. If all uarts would register as /dev/ttySnn then the serialN alias method would work. These non-overlapping namespaces is something the linux kernel driver community has allowed to happen. If the namespaces are not abandoned and disallowed, then the serialN alias method must no longer be used for any driver that does not create /dev/ttySnn devices. Every namespace will require its own alias base. Or forget about deriving the number from an alias and set the number in a property in the device tree node itself. The latter has my preference. Maarten
On 03. 04. 20 17:48, Maarten Brock wrote: > On 2020-04-03 11:51, Michal Simek wrote: >> >> Thanks. I am definitely interested to hear more how this could be done >> differently because that hardcoded limits are painful. >> On FPGAs you can have a lot of uarts for whatever reason and users are >> using DT aliases to have consistent naming. >> Specifically on Xilinx devices we are using uartps which is ttyPS, >> uartlite which is ttyUL, ns16500 which is ttyS and also pl011 which is >> ttyAMA. >> Only ttyAMA or ttyPS on one chip are possible. >> >> And right now you can't have serial0 alias pointed ttyPS0 and another >> serial0 pointed to ttyUL0 or ttyS0. That's why others are shifted and we >> can reach that hardcoded NR_UART limit easily. >> And this was the reason why I have done these patches in past to remove >> any limit from these drivers and if user asks for serial100 alias you >> simply get ttyPS100 node. > > I would argue that the trouble originates from every uart driver using > its own naming scheme and thereby creating separate namespaces. If all > uarts would register as /dev/ttySnn then the serialN alias method would > work. These non-overlapping namespaces is something the linux kernel > driver community has allowed to happen. > > If the namespaces are not abandoned and disallowed, then the serialN > alias method must no longer be used for any driver that does not create > /dev/ttySnn devices. Every namespace will require its own alias base. > Or forget about deriving the number from an alias and set the number in > a property in the device tree node itself. The latter has my preference. Uartlite and as I see ucc_uart are only two driver which are using port-number property for this purpose. And IIRC this property was the part of any spec long time ago. Thanks, Michal
Hi, there were several changes done in past in uartps drivers which have been also done in uartlite driver. Here is the thread about it https://lore.kernel.org/linux-serial/20191203152738.GF10631@localhost/ This series reverts all patches which enabled dynamic port allocation and returning driver to the previous state. There were added some features in meantime which are not affected by this series. Thanks, Michal Michal Simek (7): Revert "serial: uartps: Fix uartps_major handling" Revert "serial: uartps: Use the same dynamic major number for all ports" Revert "serial: uartps: Fix error path when alloc failed" Revert "serial: uartps: Do not allow use aliases >= MAX_UART_INSTANCES" Revert "serial: uartps: Change uart ID port allocation" Revert "serial: uartps: Move Port ID to device data structure" Revert "serial: uartps: Register own uart console and driver structures" drivers/tty/serial/xilinx_uartps.c | 211 +++++++---------------------- 1 file changed, 49 insertions(+), 162 deletions(-)