[U-Boot] [PATCH v3 14/16] tegra: dts: Add serial port details

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/04/2014 02:14 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 4 August 2014 11:47, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>
>> On 08/04/2014 04:43 AM, Simon Glass wrote:
>>>
>>> On 1 August 2014 15:50, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>
>> ...
>>
>>>> DT schemas/bindings MUST be identical between U-Boot, Linux, FreeBSD,
>>>> Barebox, ... (all of which use DT). As such, all the DT bindings MUST be
>>>> discussed on the devicetree mailing list.
>>>>
>>>> Since you're the author of the patch, it's your responsibility to have that
>>>> discussion.
>>>
>>>
>>> Are you referring to the linux,stdout-path discussion, or something
>>> more DT-generic?I suppose we could have a 'u-boot,console' for our
>>> part. But in any case you are talking about code and a convention that
>>> is already in mainline U-Boot.
>>
>>
>> I'm saying that any and all additions or changes to DT schemas/bindings must be discussed on the devicetree mailing list, not made/reviewed in isolation on only the U-Boot mailing list.
>>
>>
>>> While I accept that we might change to
>>>
>>> something DT-generic if Linux points the way to something better, I
>>> don't want to stop using it just because Linux hasn't decided yet. The
>>> early console stuff and early debug UART stuff in Linux is not yet a
>>> shining example of perfection.
>>
>>
>> I strongly believe that if U-Boot continues to use DT, the current DT usage in U-Boot needs to be actively moved in line with the bindings that the Linux kernel, Barebox, FreeBSD, ... use. I'd prefer this to happen even before U-Boot starts making additional use of DT, so the conversion doesn't get forgotten. However, I suppose it's a bit draconian to prevent further usage until the existing usage is cleaned up, except where new usage introduces additional dependencies on any current usage that's inconsistent with the standard bindings.
>>
>>
>>> That said, it's a good time to adopt 'u-boot,console' if that's what we need?
>>
>>
>> It's certainly a good time to start that discussion on the devicetree mailing list, and get such a new property reviewed/ack'd there.
>
> [side note: You will be aware that I have expended considerable effort
> getting agreement on bindings. I used to copy all DT patches to that
> mailing list, but I can't recall getting a reply that often. Also note
> that U-Boot's use of DT pre-dated the kernel with many subsystems
> (e.g. the request to retrofit clock bindings after the code was
> already written). Yes, DT bindings should be common across all
> platforms, but where subsystems don't exist in U-Boot I feel the
> approach of 'do nothing until someone writes a new subsystem' might
> just be a recipe for inaction/no progress. Better to iterate towards
> perfection than never move]

Do nothing isn't the right approach.

Invent something else without co-ordinating it isn't the right approach.

Proposing the DT bindings for that subsystem (even if the kernel doesn't 
implement code that handles the binding yet) and getting that merged 
into the DT binding documentation repository (which just happens to be 
part of the Linux kernel tree right now) is the only approach that makes 
sense.

> So to be clear, with the clock-frequency property moved back to being
> hard-coded in the CONFIG, your remaining objection is that the console
> alias, which is already used in U-Boot, should be agreed with the
> devicetree mailing list? Is that right?

IIRC, yes.