All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Javier Martinez Canillas <javier@dowhile0.org>,
	Doug Anderson <dianders@chromium.org>
Cc: "linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Stephan van Schaik <stephan@synkhronix.com>,
	Vincent Palatin <vpalatin@chromium.org>,
	Ben Dooks <ben-linux@fluff.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Russell King <linux@arm.linux.org.uk>,
	"moderated list:ARM/SAMSUNG ARM A..."
	<linux-arm-kernel@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND..." <devicetree@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Date: Tue, 29 Jul 2014 15:00:03 +0200	[thread overview]
Message-ID: <53D79AD3.8020700@suse.de> (raw)
In-Reply-To: <CABxcv=nDsKSdDtVZKpcTP+=3pbeTswJRCUvvXVx98p+1Zzz0Bg@mail.gmail.com>

Hi Javier and Doug,

Am 25.07.2014 19:02, schrieb Javier Martinez Canillas:
> On Fri, Jul 25, 2014 at 6:43 PM, Doug Anderson <dianders@chromium.org> wrote:
>> On Fri, Jul 25, 2014 at 9:35 AM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>>> Hello Andreas,
>>>
>>> On Fri, Jul 18, 2014 at 7:20 PM, Andreas Färber <afaerber@suse.de> wrote:
>>>>
>>>> +       memory {
>>>> +               reg = <0x40000000 0x80000000>;
>>>> +       };
>>>> +
>>>> +       chosen {
>>>> +       };
>>>> +
>>>
>>> Is there a reason for an empty chosen node? Same for the Spring DTS.
>>
>> I know that the bootloader (U-Boot) fills this in.  I'd have to double
>> check how the bootloader handles the node not being there to begin
>> with.
> 
> Yes, U-Boot fills this but if the node does not exist in the FDT, it
> creates one. Take a look at fdt_chosen() in common/fdt_support.c [0].
> 
> So I think it's better to just remove it since is empty.

Hm, in different context it was stated that device trees shouldn't rely
on bootloader behavior (for a /memory node on Zynq we ended up
specifying the size cell with the real value despite U-Boot overriding
it to a lesser value).

Can we instead settle on filling this node with defaults? :)
bootargs = "console=tty1"; would be my choice for Spring. Would that be
applicable for Snow as well?
Not sure how to specify that via linux,stdout-path property.

I believe this would be a follow-up patch either way.

Since there's at least two series out there trying to fiddle with
-cros-common.dtsi, including one that drops the slot sub-node of the MMC
and one that adds CPU power supply, it would be nice if we can get the
-cros-common parts sorted out and applied. Can you ack/review 1-2?
Should I squash them in a v3?

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

WARNING: multiple messages have this Message-ID (diff)
From: afaerber@suse.de (Andreas Färber)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Date: Tue, 29 Jul 2014 15:00:03 +0200	[thread overview]
Message-ID: <53D79AD3.8020700@suse.de> (raw)
In-Reply-To: <CABxcv=nDsKSdDtVZKpcTP+=3pbeTswJRCUvvXVx98p+1Zzz0Bg@mail.gmail.com>

Hi Javier and Doug,

Am 25.07.2014 19:02, schrieb Javier Martinez Canillas:
> On Fri, Jul 25, 2014 at 6:43 PM, Doug Anderson <dianders@chromium.org> wrote:
>> On Fri, Jul 25, 2014 at 9:35 AM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>>> Hello Andreas,
>>>
>>> On Fri, Jul 18, 2014 at 7:20 PM, Andreas F?rber <afaerber@suse.de> wrote:
>>>>
>>>> +       memory {
>>>> +               reg = <0x40000000 0x80000000>;
>>>> +       };
>>>> +
>>>> +       chosen {
>>>> +       };
>>>> +
>>>
>>> Is there a reason for an empty chosen node? Same for the Spring DTS.
>>
>> I know that the bootloader (U-Boot) fills this in.  I'd have to double
>> check how the bootloader handles the node not being there to begin
>> with.
> 
> Yes, U-Boot fills this but if the node does not exist in the FDT, it
> creates one. Take a look at fdt_chosen() in common/fdt_support.c [0].
> 
> So I think it's better to just remove it since is empty.

Hm, in different context it was stated that device trees shouldn't rely
on bootloader behavior (for a /memory node on Zynq we ended up
specifying the size cell with the real value despite U-Boot overriding
it to a lesser value).

Can we instead settle on filling this node with defaults? :)
bootargs = "console=tty1"; would be my choice for Spring. Would that be
applicable for Snow as well?
Not sure how to specify that via linux,stdout-path property.

I believe this would be a follow-up patch either way.

Since there's at least two series out there trying to fiddle with
-cros-common.dtsi, including one that drops the slot sub-node of the MMC
and one that adds CPU power supply, it would be nice if we can get the
-cros-common parts sorted out and applied. Can you ack/review 1-2?
Should I squash them in a v3?

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

  reply	other threads:[~2014-07-29 13:00 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18 17:20 [PATCH v2 0/4] ARM: dts: exynos: Prepare Spring Andreas Färber
2014-07-18 17:20 ` [PATCH v2 1/4] ARM: dts: exynos5250: max77686 is Snow only Andreas Färber
2014-07-18 17:20   ` Andreas Färber
2014-07-18 17:20   ` Andreas Färber
2014-07-25  5:28   ` Kukjin Kim
2014-07-25  5:28     ` Kukjin Kim
2014-07-25 15:08     ` Doug Anderson
2014-07-25 15:08       ` Doug Anderson
2014-07-25 15:13       ` Doug Anderson
2014-07-25 15:13         ` Doug Anderson
2014-07-25 15:30         ` Andreas Färber
2014-07-25 15:30           ` Andreas Färber
2014-07-25 15:30           ` Andreas Färber
2014-07-25 16:02           ` Doug Anderson
2014-07-25 16:02             ` Doug Anderson
2014-07-29 16:15   ` Doug Anderson
2014-07-29 16:15     ` Doug Anderson
2014-07-18 17:20 ` [PATCH v2 2/4] ARM: dts: exynos5250: cypress,cyapa trackpad " Andreas Färber
2014-07-18 17:20   ` Andreas Färber
2014-07-18 17:20   ` [PATCH v2 2/4] ARM: dts: exynos5250: cypress, cyapa " Andreas Färber
2014-07-29 16:16   ` [PATCH v2 2/4] ARM: dts: exynos5250: cypress,cyapa " Doug Anderson
2014-07-29 16:16     ` Doug Anderson
2014-07-29 23:06     ` Kukjin Kim
2014-07-29 23:06       ` Kukjin Kim
2014-07-30  0:21       ` Andreas Färber
2014-07-30  0:21         ` Andreas Färber
2014-07-18 17:20 ` [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow Andreas Färber
2014-07-18 17:20   ` Andreas Färber
2014-07-18 17:20   ` Andreas Färber
2014-07-25 16:02   ` Doug Anderson
2014-07-25 16:02     ` Doug Anderson
2014-07-29 12:45     ` Andreas Färber
2014-07-29 12:45       ` Andreas Färber
2014-07-29 15:11       ` Doug Anderson
2014-07-29 15:11         ` Doug Anderson
2014-07-25 16:35   ` Javier Martinez Canillas
2014-07-25 16:35     ` Javier Martinez Canillas
2014-07-25 16:43     ` Doug Anderson
2014-07-25 16:43       ` Doug Anderson
2014-07-25 17:02       ` Javier Martinez Canillas
2014-07-25 17:02         ` Javier Martinez Canillas
2014-07-29 13:00         ` Andreas Färber [this message]
2014-07-29 13:00           ` Andreas Färber
2014-07-29 14:39           ` Javier Martinez Canillas
2014-07-29 14:39             ` Javier Martinez Canillas
2014-07-29 15:27           ` Doug Anderson
2014-07-29 15:27             ` Doug Anderson
2014-07-18 17:20 ` [PATCH v2 4/4] ARM: dts: exynos5250: Add Spring device tree Andreas Färber
2014-07-18 17:20   ` Andreas Färber
2014-07-18 17:20   ` Andreas Färber
2014-07-25 16:02   ` Doug Anderson
2014-07-25 16:02     ` Doug Anderson
     [not found]     ` <CAD=FV=Xu9b6433pV=bqi3jZZR03G6nyi2iNgbSXwAcRY4Y=4yA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-30 13:06       ` Andreas Färber
2014-07-30 13:06         ` Andreas Färber
2014-07-30 13:06         ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D79AD3.8020700@suse.de \
    --to=afaerber@suse.de \
    --cc=ben-linux@fluff.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=javier@dowhile0.org \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=stephan@synkhronix.com \
    --cc=vpalatin@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.