devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/2] of: base: add support to get machine model name
Date: Fri, 18 Nov 2016 12:22:42 -0800	[thread overview]
Message-ID: <582F6312.5040009@gmail.com> (raw)
In-Reply-To: <075d4718-8cd2-e390-b755-bc24e7497eae-5wv7dgnIgG8@public.gmane.org>

On 11/18/16 02:41, Sudeep Holla wrote:
> 
> 
> On 17/11/16 21:00, Frank Rowand wrote:
>> On 11/17/16 07:32, Sudeep Holla wrote:
>>> Currently platforms/drivers needing to get the machine model name are
>>> replicating the same snippet of code. In some case, the OF reference
>>> counting is either missing or incorrect.
>>>
>>> This patch adds support to read the machine model name either using
>>> the "model" or the "compatible" property in the device tree root node
>>> to the core OF/DT code.
>>>
>>> This can be used to remove all the duplicate code snippets doing exactly
>>> same thing later.
>>
>> I find five instances of reading only property "model":
>>
>>   arch/arm/mach-imx/cpu.c
>>   arch/arm/mach-mxs/mach-mxs.c
>>   arch/c6x/kernel/setup.c
>>   arch/mips/cavium-octeon/setup.c
>>   arch/sh/boards/of-generic.c
>>
> 
> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
> that this will be used for.

I have not seen 2/2.  I do not see it on the devicetree list or on lkml.

I did see a list of drivers in the RFC patch that you sent several hours
before this patch.

In that patch you replaced reading the model name from the _flat_ device
tree with the new function in at least one location.  That is not
correct.


> 
>> I find one instance of reading property "model", then if
>> that does not exist, property "compatible":
>>
>>   arch/mips/generic/proc.c
>>
> 
> Correct as you can check in patch 2/2
> 
>> The proposed patch matches the code used in one place, and thus
>> current usage does not match the patch description.
>>
> 
> Yes, but does it matter ? compatibles are somewhat informative about the
> model IMO.

Yes it does matter.  That is just sloppy and makes devicetree yet harder
to understand.  It hurts clarity.  The new function name says get "model",
not get "model" or "first element of the compatible list".

And using the _first_ element only of the compatible list to determine
model is not a good paradigm.  It is yet another hidden, special case,
undocumented trap to lure in the unwary.

It is extremely unlikely that the change actually changes behavior for an
existing device tree because there is probably no dts that does not
contain the model property but does contain the proper magic value in
the compatible property.  But did you actually check for that?

> 
>> Is my search bad?  Are you planning to add additional instances
>> of reading "model" then "compatible"?
>>
> 
> No, just replacing the existing ones as in patch 2/2
> 

You also ignored Arnd's comment in reply to your RFC patch.

-Frank

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2016-11-18 20:22 UTC|newest]

Thread overview: 21+ 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 ` [PATCH 2/2] of: base: replace all duplicate code with of_machine_get_model_name Sudeep Holla
     [not found] ` <1479396775-32033-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
2016-11-17 21:00   ` [PATCH 1/2] of: base: add support to get machine model name Frank Rowand
     [not found]     ` <582E1A59.7040502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-17 22:12       ` Frank Rowand
2016-11-18 10:41       ` Sudeep Holla
     [not found]         ` <075d4718-8cd2-e390-b755-bc24e7497eae-5wv7dgnIgG8@public.gmane.org>
2016-11-18 20:22           ` Frank Rowand [this message]
     [not found]             ` <582F6312.5040009-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-21 16:05               ` Frank Rowand
     [not found]                 ` <58331B5D.8060907-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-21 16:23                   ` Sudeep Holla
     [not found]                     ` <55e27115-421e-b67b-eb7a-9b1c3d662711-5wv7dgnIgG8@public.gmane.org>
2016-11-21 19:24                       ` Frank Rowand
     [not found]                         ` <58334A06.103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-21 20:49                           ` Frank Rowand
2016-11-21 16:20             ` Sudeep Holla
     [not found]               ` <0f150e21-ba46-d4f2-98e8-a226eb82ca3e-5wv7dgnIgG8@public.gmane.org>
2016-11-21 20:21                 ` Frank Rowand
2016-11-18 14:46 ` Rob Herring
2016-11-18 20:00   ` Frank Rowand
     [not found]     ` <582F5DC0.4080804-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
     [not found]               ` <CAL_JsqKioaP6JvihmJ3HK6cEfCgFRrtYr+EbJ2KvptxcrWCLnA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-12-09 23:54                 ` Frank Rowand
     [not found]                   ` <584B442D.4020104-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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=582F6312.5040009@gmail.com \
    --to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=sudeep.holla-5wv7dgnIgG8@public.gmane.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).