> 3. mechanism to open/close the UART by the peer driver (for power management of the > UART), even if it there is a user-space tty client for the same UART which might or might > not be open at any time. Manage that in an optimal way. Power management doesn't have to go via the uart layer. You can even manage it via the existing sysfs power interfaces (and some Android devices do in fact do exactly that either by controlling the uart pm or using a gpio line). Not pretty either but means people are only peeing in their own backyard. What goes into the kernel costs *everyone*, what goes in device user space costs only the perpetrator. It would help to rewind and understand what your needs are not what your implementation as it stands is. Why can't you just use hciattach like everyone else ? Improving the PM logic by refining the existing hci ldisc to be power smart so everyone benefits from any improvement might be a useful other discussion. The 8686 is already working in serial mode with no kernel hackery on other boards. > For the GPS chip I am only interested in mctrl and if characters are received. But > I still want them to arrive at user space through a standard tty interface. So a solution > that does not interwork and cooperate with the tty layer is not a useable solution for > my requirements. Why does it matter how they arrive so long as your user space can interpret it correctly. Or is your user space some proprietary blob you can't change ? Them arriving by a tty interface is fine - no issue with that providing it doesn't need to mess up core code. > The reason appears to sit here: > > http://lxr.free-electrons.com/source/drivers/tty/serial/serial_core.c#L2725 > > This means that as soon as some UART is successfully probed, a new tty > interface is created for it. So we simply have to optionally disable it. This is > described by requirement 6. You can just report EBUSY in your open method. You don't need to touch the serial core layer. It's quite sufficient to do if (busy) return -EBUSY; at the top of your uart open method. > UART drivers we have and work with any of them. This is why I think > serial-core and struct uart_port is the right level. Even if it looks like a hack. Your "looks like" instinct is IMHO bang on - looks like a hack, is a hack. It's also unnecessary as you can hide it in your open method if you must do that. > So please wait until I have updated the patch set of our proposal. Then you > can see that we do not directly touch the tty layer. The uart layer is part of the tty layer. It's just a glue library to make writing some tty drivers a bit easier. It's tied deeply to the tty_port implementation. One day it might even cease to exist replaced by more generic tty_port helpers. The tty layer is also an *abstract* concept. There is no real world tie between physical collections of shift registers that dribble bits to one another and tty devices in the kernel. You only need a tty driver for certain types of user interaction. 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
