> The problem is that *I* have no control over user space. But I also don't want > to say to my users "that is not my problem - get it solved yourself". This does > not help them. Stuffing things into the kernel because the user space of a given platform can't get itself organised isn't helpful to the other billion plus Linux devices out there. > And, most device drivers are corner cases since they are special solutions > for singular platforms. Actually that is quite a small percentage - and the corner cases hide in drivers not in the core code, which is really important for maintainability. > >> I'm glad - because it raises some hard questions and while I don't agree > >> with some of your starting points (like needing to "open" a uart without > >> user space > > If have an idea how to turn off the device at boot time, before any user space > daemon is running, we can of course ignore that. Your early user space is responsible for it. If you can't accept that then I don't see any point continuing the conversation. > >> But see below as I think your mental model is perhaps wrong > >> and this is a point of confusion ? > > Maybe you do not accept that I want to keep as low level as reasonable (for me). It's always "for me". No the kernel project is not "for me" > >> Both of those techniques work in mainline without kernel changes (at > >> least on devices where the right gpio sysfs nodes exist > > they do not exist... For most they do because they are gpio lines so exportable to userspace. > >> This I think is actually the really hard and interesting part of the > >> problem. The "tell me about open and close" case is simple and can be > >> done via tty_port today with minimal extra hooks. There is a small > >> question about how you set those hooks from a DT binding > > tty has no binding. An UART hardware has. Another reason for me to > start with UARTs. Every uart is a tty_port, every non uart is a tty_port. There is no reason you can't bind to a non uart device. Your current patches create bindings for the uart layer. > >> For some hardware that is the only way I know to do this because the > >> power hungry uart receiver is physically powered down. I would have to > >> check but I *think* that is true even on a modern x86 PC that supports > >> wakeups via serial - although it may be well hidden in ACPI and firmware. > > Yes, agreed. But the gpio + interrupt solution was not mainlineable as well. That I am unsure about - at some point it is going to have to be sorted because it is increasingly common (if currently mostly invisible) > >> I'm not personally opoosed to the tty slave idea providing it ends up > >> attached to the tty_port not just uart. > > Well if you can tell us how to handle the data path I have no problems with it > to attach to the tty level. If your port is closed you have no data path. If you are using uart you have no data path because while your patch hooks a helper that some uarts use some of the time it's optional and a lot of uarts don't use it, so its not even uart generic. 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
