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

[H. Nikolaus Schaller]

Am 20.01.2016 um 18:46 schrieb One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>:

>> 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.

The assumption that there is  "the" user space of a given platform is wrong.

> 
>> 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.

Exactly. There are two reasons:
* we want to make sure that it works for any user space
* it should be done as early as possible

> 
>>>> 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.

Yes and no. The &uart { compatible = "something"; } already exists.

> 
>>>> 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

I wasn't aware that lots of uart's don't use it. At least one is using it. I would have
to check which percentage is using it and which isn't. Thanks for pointing this
out.

> it, so
> its not even uart generic.

Understood. I wasn't aware of that.

I just was under the false impression that this is the recommended common
and a well designed (object oriented) interface. struct uart_port
being the object and the uart_ops assigned to it, being the list of methods
that can be applied to an uart_port.

http://lxr.free-electrons.com/source/Documentation/serial/driver#L14
http://lxr.free-electrons.com/source/include/linux/serial_core.h#L45
http://lxr.free-electrons.com/source/include/linux/serial_core.h#L235

BR,
Nikolaus