From: robh@kernel.org (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm, nvram_file_name dt property
Date: Sun, 17 Jul 2016 16:45:02 -0500 [thread overview]
Message-ID: <20160717214502.GA11498@rob-hp-laptop> (raw)
In-Reply-To: <3996482.D5xdKXDiGl@wuerfel>
On Thu, Jul 07, 2016 at 10:46:28AM +0200, Arnd Bergmann wrote:
> On Wednesday, July 6, 2016 9:19:41 PM CEST Arend Van Spriel wrote:
> > On 6-7-2016 15:42, Arnd Bergmann wrote:
> > > On Wednesday, July 6, 2016 10:08:55 AM CEST Arend Van Spriel wrote:
> > >> On Tue, Jul 5, 2016 at 3:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > All existing uses of the model property in arch/arm/boot/dts and most of
> > > the ones in arch/powerpc/boot/dts are against the intended usage in
> > > one way or another, but adding different kind of incorrect usage won't
> > > improve that.
> > >
> > > The only way I can see the model property being used correctly would
> > > be to have it match the first entry in the compatible property, but
> > > that is completely redundant, so we tend to omit it, except for the
> > > root node in which it is required. For the root node however, the
> > > historic practice that has crept in on ARM is to put something completely
> > > different in there, which is a human-readable description of the
> > > machine rather than something we can use as a unique indentifier.
> > >
> > > I'd just consider the "model" property burned, and not use it for anything
> > > that doesn't already use it, just like we handle "device_type": a few
> > > things require it, nothing else should use it.
> >
> > If that is the agreed approach in devicetree arena I am fine with it. I
> > have been unaware of this and just looked at the suggestion from Jonas
> > seeing a solution to the problem at hand.
>
> I don't think it has been discussed or decided before as the question
> has not come up, so for now this is my personal view. Maybe one of
> the devicetree maintainers can comment on this.
Back from vacation and getting caught up.
I agree with Arnd here. In my view model is the OEM branding on the
device, compatible is the h/w. If you have different firmware related
files, that goes beyond OEM branding.
Rob
next prev parent reply other threads:[~2016-07-17 21:45 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-29 14:04 [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property Hans de Goede
2016-06-29 14:04 ` [PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name Hans de Goede
2016-06-29 17:01 ` [PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm, nvram_file_name Kalle Valo
2016-06-29 18:01 ` [linux-sunxi] Re: [PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name Hans de Goede
2016-06-29 14:04 ` [PATCH 3/4] ARM: dts: sun7i-a20-wits-pro-a20-dkt: Set brcm, nvram_file_name Hans de Goede
2016-06-29 14:04 ` [PATCH 4/4] ARM: dts: sun5i-a10s-auxtek-t004: " Hans de Goede
2016-06-29 14:42 ` [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property Jonas Gorski
2016-06-29 15:16 ` Hans de Goede
2016-06-29 17:00 ` Kalle Valo
2016-06-29 18:01 ` [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm, nvram_file_name " Hans de Goede
2016-06-29 18:51 ` Arend Van Spriel
2016-06-29 18:57 ` Arend Van Spriel
2016-06-30 8:50 ` Kalle Valo
2016-06-29 19:33 ` Arnd Bergmann
2016-06-29 19:54 ` [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name " Priit Laes
2016-06-29 20:07 ` [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm, nvram_file_name " Arnd Bergmann
2016-06-30 9:02 ` Kalle Valo
2016-06-30 9:50 ` Hans de Goede
2016-06-30 9:58 ` Kalle Valo
2016-06-30 10:04 ` Hans de Goede
2016-06-30 10:18 ` Jonas Gorski
2016-06-30 10:25 ` Hans de Goede
2016-06-30 11:31 ` Arnd Bergmann
2016-06-30 19:23 ` Arend Van Spriel
2016-07-01 8:51 ` Arnd Bergmann
2016-07-01 8:58 ` Jonas Gorski
2016-07-02 6:59 ` Kalle Valo
2016-07-02 18:20 ` Arend Van Spriel
2016-07-02 21:30 ` Arnd Bergmann
2016-07-04 8:41 ` Arend Van Spriel
2016-07-04 8:55 ` Arnd Bergmann
2016-07-04 9:08 ` Arend Van Spriel
2016-07-04 14:54 ` Arnd Bergmann
2016-07-04 18:36 ` Arend van Spriel
2016-07-05 13:43 ` Arnd Bergmann
2016-07-06 8:08 ` Arend Van Spriel
2016-07-06 13:42 ` Arnd Bergmann
2016-07-06 19:19 ` Arend Van Spriel
2016-07-07 8:46 ` Arnd Bergmann
2016-07-07 9:16 ` Arend Van Spriel
2016-07-07 9:24 ` Arnd Bergmann
2016-07-17 21:45 ` Rob Herring [this message]
2016-07-18 7:51 ` Arend Van Spriel
2016-06-30 8:46 ` Kalle Valo
2016-06-30 9:49 ` Hans de Goede
2016-06-30 9:53 ` Hans de Goede
2016-07-01 2:08 ` [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name " Rob Herring
2016-07-01 8:17 ` Arend Van Spriel
2016-07-01 9:20 ` Arnd Bergmann
2016-07-04 16:12 ` Rob Herring
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=20160717214502.GA11498@rob-hp-laptop \
--to=robh@kernel.org \
--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