All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Frank Rowand <frowand.list@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/2] of: base: add support to get machine model name
Date: Fri, 9 Dec 2016 10:03:03 -0600	[thread overview]
Message-ID: <CAL_JsqKioaP6JvihmJ3HK6cEfCgFRrtYr+EbJ2KvptxcrWCLnA@mail.gmail.com> (raw)
In-Reply-To: <195d492b-c674-e096-4f84-d37ca5448db2@arm.com>

On Wed, Nov 23, 2016 at 4:25 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 22/11/16 21:35, Rob Herring wrote:
>>
>> On Tue, Nov 22, 2016 at 12:44 PM, Frank Rowand <frowand.list@gmail.com>
>> wrote:
>
>
> [...]
>
>>>
>>> This patch adds a function that leads to conflating the "model" property
>>> and the "compatible" property. This leads to opaque, confusing and
>>> unclear
>>> code where ever it is used.   I think it is not good for the device tree
>>> framework to contribute to writing unclear code.
>>>
>>> Further, only two of the proposed users of this new function appear to
>>> be proper usage.  I do not think that the small amount of reduced lines
>>> of code is a good trade off for the reduced code clarity and for the
>>> potential for future mis-use of this function.
>>>
>>> Can I convince you to revert this patch?
>>
>>
>> Yes, I will revert.

I looked at this again and the users. They are all informational, so
I'm not worried if a compatible string could be returned with this
change. The function returns the best name for the machine and having
consistency is a good thing.

I was considering not reverting (as I'd not yet gotten around to it),
but I'm still going to revert for the naming.

>>
>>> If not, will you accept a patch to change the function name to more
>>> clearly indicate what it does?  (One possible name would be
>>> of_model_or_1st_compatible().)
>>
>>
>> I took it as there's already the FDT equivalent function.
>
>
> Yes it was mainly for non of_flat_* replacement for
> of_flat_dt_get_machine_name

I would suggest just of_get_machine_name().

You might also add a fallback to return "unknown", and drop some of
the custom strings. I don't think anyone should care about the actual
string. However, it's an error to have a DT with no model or top level
compatible, so maybe a WARN.

Rob

  reply	other threads:[~2016-12-09 16:03 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17 15:32 [PATCH 1/2] of: base: add support to get machine model name Sudeep Holla
2016-11-17 15:32 ` Sudeep Holla
2016-11-17 15:32 ` [PATCH 2/2] of: base: replace all duplicate code with of_machine_get_model_name Sudeep Holla
2016-11-17 21:00 ` [PATCH 1/2] of: base: add support to get machine model name Frank Rowand
2016-11-17 21:00   ` Frank Rowand
2016-11-17 22:12   ` Frank Rowand
2016-11-17 22:12     ` Frank Rowand
2016-11-18 10:41   ` Sudeep Holla
2016-11-18 10:41     ` Sudeep Holla
2016-11-18 20:22     ` Frank Rowand
2016-11-18 20:22       ` Frank Rowand
2016-11-21 16:05       ` Frank Rowand
2016-11-21 16:05         ` Frank Rowand
2016-11-21 16:23         ` Sudeep Holla
2016-11-21 16:23           ` Sudeep Holla
2016-11-21 19:24           ` Frank Rowand
2016-11-21 19:24             ` Frank Rowand
2016-11-21 20:49             ` Frank Rowand
2016-11-21 20:49               ` Frank Rowand
2016-11-21 16:20       ` Sudeep Holla
2016-11-21 20:21         ` Frank Rowand
2016-11-21 20:21           ` Frank Rowand
2016-11-18 14:46 ` Rob Herring
2016-11-18 20:00   ` Frank Rowand
2016-11-18 20:00     ` Frank Rowand
2016-11-22 18:44     ` Frank Rowand
2016-11-22 18:44       ` Frank Rowand
2016-11-22 21:35       ` Rob Herring
2016-11-23 10:25         ` Sudeep Holla
2016-12-09 16:03           ` Rob Herring [this message]
2016-12-09 23:54             ` Frank Rowand
2016-12-09 23:54               ` Frank Rowand
2016-12-12 15:17               ` Rob Herring
2016-12-12 15:17                 ` Rob Herring
2016-11-23 10:23       ` Sudeep Holla

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=CAL_JsqKioaP6JvihmJ3HK6cEfCgFRrtYr+EbJ2KvptxcrWCLnA@mail.gmail.com \
    --to=robh@kernel.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    /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.