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.

quoted

quoted

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.

quoted

quoted

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"

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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)
 

quoted

quoted

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html