[U-Boot] [PATCH] tegra: trimslice: fix a couple typos

[Igor Grinberg]

On 06/01/12 18:45, Marek Vasut wrote:
> Dear Stephen Warren,
> 
>> On 06/01/2012 12:38 AM, Igor Grinberg wrote:
>>> On 05/31/12 19:50, Stephen Warren wrote:
>>>> On 05/31/2012 04:13 AM, Marek Vasut wrote:
>>>>> Dear Igor Grinberg,
>>>>>
>>>>>> On 05/30/12 19:45, Stephen Warren wrote:
>>>>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>>>>
>>>>>>> Fix the .dts file USB unit addresses not to duplicate each-other.
>>>>>>>
>>>>>>> Fix the board name string to indicate the vendor is Compulab not
>>>>>>> NVIDIA.
>>>>>>>
>>>>>>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>>>>>>
>>>>>> Acked-by: Igor Grinberg <grinberg at compulab.co.il>
>>>>>
>>>>> Do we have one copy of the dts files here and one in Linux kernel tree?
>>>>> Are they the same?
>>>>
>>>> Both U-Boot and the kernel have their own copies of the .dts files.
>>>>
>>>> In general, the U-Boot copy would be identical to what's in the kernel,
>>>> or a pure subset since mostly the kernel's driver support is more
>>>> advanced, so we've added more nodes to the DT.
>>>>
>>>> That said, there are unfortunately some bizarre quirks in the way the
>>>> U-Boot parses the device tree, such as requiring the /aliases node in
>>>> order to enumerate at least some devices, the use of the Tegra clock
>>>> binding that hasn't been incorporated into the kernel yet and is used
>>>> for both clock and module reset functionality even though it's really
>>>> only intended for clock functionality, and various other small
>>>> properties that are U-Boot specific (although I forget if we managed to
>>>> eliminate these all or not). These all end up causing differences
>>>> between the two device tree files:-(
>>>
>>> Thanks for the information.
>>>
>>> I don't see any problem with having differences between the .dts files
>>
>>> in kernel and U-Boot, because the way I see it:
>> The issue isn't so much the duplicate files, but differing content.
>>
>> The whole point about DT is that it's a pure representation of the
>> hardware; there should be no software-dependent design or data in it.

Right, what I was saying is not that the design or the bindings can differ, but
that the DT blob can be adjusted with data in run time to better represent the
"run time detected" hardware (e.g. extension boards and devices on them,
revisions, serial number, etc.)

>> Put another way, both U-Boot and the Linux kernel (and indeed anything
>> else) should expect the DT to be written according to the same
>> "bindings" design. This doesn't preclude the U-Boot DT file being a
>> strict subset of the kernel file it it needs less information, but what
>> is in both should match.

That is understood completely and of course agreed!


-- 
Regards,
Igor.