Defining schemas for Device Tree

[swarren@wwwdotorg.org (Stephen Warren)]

On 07/30/2013 11:45 AM, jonsmirl at gmail.com wrote:
> On Tue, Jul 30, 2013 at 1:34 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:
>>> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>
>>>> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>>>>> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie@kernel.org> wrote:
>>>>>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>>>>>
>>>>>>> This...
>>>>>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>>>>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>>>>>
>>>>>>> Probably should be
>>>>>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>>>>>> dma-names = "tx", "rx";
>>>>>>
>>>>>> It should be - the latter is the generic DMA binding.  There's a lot of
>>>>>> bindings in the kernel that predate that but people are currently
>>>>>> working to transfer over, this is one of the examples of instability
>>>>>> that everyone is talking about.
>>>>>
>>>>> Is something similar to this possible in device tree syntax?
>>>>> dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>>>>
>>>> I /think/ you can physically write that in *.dts, or something very
>>>> similar; with the strings outside the <>:
>>>>
>>>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>>>>
>>>> However, there's been strong push-back (i.e. doing that has not been
>>>> allowed at all) on attempting to mix variable-length strings and
>>>> fixed-length/alignment integer cells in the same property. This is
>>>> primarily because you then can't ensure that the integer cell data is
>>>> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows
> 
> The PowerPC FDT doc says that strings are indirected into a string
> table. So they aren't variable length in the data structures.

Do you have a link to the document; I'm not sure which one you mean.

> I was wondering how dmas = "tx", "rx" was implemented. It is two
> pointers into the indirect block. So this should work, there is no
> variable length data to worry about in the structure.

If you look at of_property_read_string_index() in drivers/of/base.c,
you'll see that it expects the strings to just be packed together inline.

What you say may be correct for node and property names, just not
property values.