Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[One Thousand Gnomes <gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>]

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