Hi,
Am 26.03.2015 um 06:56 schrieb Pavel Machek <pa...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
