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

Hi,

Am 26.03.2015 um 06:56 schrieb Pavel Machek [off-list ref]:

Hi!

quoted

quoted

quoted

quoted

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

quoted

quoted

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.

quoted

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