> When translating the system requirements you have provided and mixing > with mine, I think we need: > > 1. mechanism to receive characters sent by the peer MCU Low level driver queue of some kind > 2. mechanism to send characters to the peer (or a block for firmware download) Ditto (maybe even netlink) > 3. mechanism to open/close the UART (even if there is no user space/tty client) So don't use the tty layer in the first place > 4. mechanism to set the struct termios of the UART (baud rate etc.) Can be done without the tty layer. > 5. mechanism to be notified that user space has opened/closed the tty port or changes mctrl > 6. mechanism to prevent the tty layer to present a /dev/tty* to user space at all This sounds the wrong way up entirely. Instead of trying to make the tty layer do weird stuff, make the driver present a tty that is only the things that it wants to be exposed as a tty if any. If there are none then don't use the tty layer at all. We have lots of interfaces to random MCUs. Many of them talk "serial" protocols, almost none of them pretend to be the tty layer. Alan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
