Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

Dr. H. Nikolaus Schaller
2015-03-26T06:44:25Z

Hi,

Am 26.03.2015 um 06:56 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
>
>>>>> Main reason is, that I would need to go
>>>>> through the UART to “communicate" with the w2sg0004.
>>>>
>>>> You can always "communicate” through the UART. Even without DT. As long as
>>>> the connected chip is powered up by any means (could be some fixed-regulator
>>>> or hard wired).
>>>
>>> But you don't know "how" to communicate through the uart.
>>
>> Maybe we are talking using different assumptions. As long as you have a user space
>> gpsd daemon that talks to the gps chip the kernel simply has to transparently (except
>> line disciplines) pass the data to the uart.
>
> Forget userspace, some other operating system (or future linux) may
> want to put gps handling into the kernel. (To hide differences between
> different GPSes).
>
>>> Because we want the phone to boot knowing "I have a bluetooth" or "I
>>> have a GPS", as it would if it was connected using USB, and not having
>>> user figure out what commands he needs to do to enable reasonable
>>> hardware support (and getting it wrong, because you need to specify
>>> _many_ critical parameters to hciattach).
>>
>> Yes, this is indeed something I also would like to see for the GTA04 (and other)
>> devices.
>>
>> So the reason is that some kernel driver wants to use the tty/uart to communicate
>> directly with the chip. This is very similar to a gpio that some driver wants to use.
>>
>> Thus please consider the
>>
>> / {
>> bt {
>> compatible = "vendor,product“;
>> uart = <&uart1>;
>> enable = <&gpio17 34 0>;
>> };
>> };
>
> Would work, too, but I and everyone knows that subnode is better,
> easier solution.

“Everyone” could be wrong and ignorant.

And I thought we are not looking for the easiest solution but the right one.
Especially if we define something that is for other operating systems as well.

About easier: the one given above allows to modify the driver to present e.g. an iio
interface to user space (and no /dev/tty) *without changing the DT*. Because the
driver code decides which interface it presents. And not where it is a subnode in DT.

This is the level of abstraction DT nodes should have.

It may be that you did not read my previous argumentation completely.

In short, please see:

http://www.devicetree.org/Device_Tree_Usage#Devices

And check of there is anything that mandates useage of a subnode in this case.
I simply don’t find it.

Rather, although it is also not explicitly excluded, I read hints that it should *not* be
done the subnode way.

The reason is that it appears to me that the DT hierarchy is intended to describe
how kernel drivers can *address* different components. Nothing less and nothing more.

Especially there is no hint that layering in DT has anything to do with data flow
hierarchies or a “primary” interface as Sebastian calls it.

>
>> approach.
>>
>> And if you want to hide uart1 from the user-space, that should be a property
>> of the uart1 node (whereever it is defined).
>
> Sorry? That would be one heck of layering violation.

Which layering?

I think you still mix the software/kernel driver/data flow layers with DT layers.

DT can and must be independent on that.

BR,
Nikolaus