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

[Dr. H. Nikolaus Schaller]

Hi,

Am 26.03.2015 um 06:56 schrieb Pavel Machek <pavel@xxxxxx>:

> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/