Messages in this thread | | | Subject | Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices. | From | "Dr. H. Nikolaus Schaller" <> | Date | Thu, 26 Mar 2015 07:44:13 +0100 |
| |
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
| |