reasonx

@martinayotte Hello. Seems once you was dig into this problem too.

I have found, what is an old issue, first noted long ago in https://stackoverflow.com/questions/45813755/linux-8250-rs485-rts-troubleshooting The user has noted, what it possible misuse of TEMT\THRE IRQs. Looking at 6.12 kernel 8250 drivers, i have found it was changed in the part what was the topic in stackoverflow post. https://github.com/torvalds/linux/commit/b54f7a922d334014071ddaea313a045781024f4d I am novice linux user and have lack of understanding many things, including tty to phys architecture and it settings. Maybe im been able to try fix driver itself (have experience to write baremetal IRQ driver rs485 & uart drivers and modbus stack), but i have really big issues with linux modules building and etc. There are also another evidence about RTS\RS485 issues on 8250 in links below. And mention of some "RS485" state machine, "RS485 software emulation" what "may be buggy" in topic i cant find now.

Hello. Im trying to configurate and adapt OrangePI Zero 2W board to a custom extension board with multiple RS485 drivers. For now, im trying to configurate a single secondary UART (UART2) to initialize with muxed Rx\Tx pins and in RS485 (with software driven RTS pin). My current DT overlay is: And it is partially works. Works as UART. Able to send and receive data with muxed Rx\Tx. For RTS... its complicated. Seems RTS(PH4 GPIO) are initialized and acquired by UART2 software, and stay low during initial idling. After im trying to send any data (echo 123 >> /dev/ttyS2), RTS goes HIGH and stuck in this state before reboot. Im have tried to send big blob at 9600 and check the RTS with statserial. But as i see, RTS is 1 (active???) from inital to complete and after, and never changes.