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
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
