linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: afaerber@suse.de (Andreas Färber)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: tegra: add Acer Chromebook 13 device tree
Date: Mon, 18 Aug 2014 19:03:04 +0200	[thread overview]
Message-ID: <53F231C8.5050309@suse.de> (raw)
In-Reply-To: <53F2255E.7090208@wwwdotorg.org>

Am 18.08.2014 18:10, schrieb Stephen Warren:
> On 08/16/2014 09:20 AM, Andreas F?rber wrote:
>> Am 13.08.2014 21:14, schrieb Dylan Reid:
>>> +    pinmux: pinmux at 0,70000868 {
>>> +        pinctrl-names = "default";
>>> +        pinctrl-0 = <&pinmux_default>;
>>> +
>>> +        pinmux_default: common {
>>> +            dap_mclk1_pw4 {
>>
>> Any need to have the nodes this way? Shouldn't this rather be
>> dap-mclk1-pw4 as node name by conventions, with a dap_mclk1_pw4 label
>> for referencing if needed? Same below, obviously.
> 
> Underscores are consistent with at least all the other Tegra DTs, so I
> think this is best as is.
> 
>>> +    pwm: pwm at 0,7000a000 {
>>
>> Add the label to the .dtsi where the node is first declared? Then you
>> can override it the safer &pwm { ... }; way. Same for all other nodes
>> being extended/overridden here - that's what your colleagues requested
>> for Spring. It'll help with the 80 char limit further below by reducing
>> indentation.
> 
> We certainly do have the pwm label in *.dtsi for other SoCs, so we
> should probably move the label there.
> 
> Using the &pwm {} syntax would be inconsistent with all the other Tegra
> DTs, and isn't really any safer; the HW isn't going to change, so once
> this is written, it should continue to "just work".

For exactly those consistency reasons I was asked to refactor the whole
set of exynos5250-*.dts files despite having no relation to them -
turning my 1 .dts patch into a large series that still isn't applied...

It's funny and disappointing that every Linux maintainer seems to have
their own conventions, and not even the Google Chrome people can agree
on a common style or live up to what they ask of others.

As for &pwm {}, I understood it's "safer" in that mismatches in the node
name will lead to compilation errors rather than silent runtime misbehavior.

Regards,
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-08-18 17:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13 19:14 [PATCH v2] ARM: tegra: add Acer Chromebook 13 device tree Dylan Reid
2014-08-16 15:20 ` Andreas Färber
2014-08-18 16:10   ` Stephen Warren
2014-08-18 17:03     ` Andreas Färber [this message]
2014-08-18 23:24     ` Andrew Bresticker
2014-08-18 23:43       ` Stephen Warren
2014-08-19  0:11         ` Andrew Bresticker
2014-08-19 21:47           ` Stephen Warren
2014-08-20  5:36             ` Thierry Reding
2014-08-20 13:37             ` Olof Johansson
2014-08-20 15:25               ` Thierry Reding
2014-08-20 17:25                 ` Andrew Bresticker
2014-08-20 13:29         ` Olof Johansson
2014-08-20 14:32           ` Thierry Reding
2014-08-20 15:40             ` Olof Johansson
2014-08-21  7:19               ` Thierry Reding
2014-08-18 23:05 ` Andrew Bresticker
2014-09-04 19:40 ` Stephen Warren
2014-09-04 20:33   ` Dylan Reid
2014-09-04 21:04     ` Stephen Warren
2014-09-04 21:08       ` Dylan Reid

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=53F231C8.5050309@suse.de \
    --to=afaerber@suse.de \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).