devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
To: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>,
	santosh shilimkar
	<santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Santosh Shilimkar
	<ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags
Date: Thu, 24 Sep 2015 09:20:50 -0500	[thread overview]
Message-ID: <560406C2.6090200@ti.com> (raw)
In-Reply-To: <56040323.1080409-l0cyMroinI0@public.gmane.org>

On 09/24/2015 09:05 AM, Murali Karicheri wrote:
> On 09/23/2015 02:19 PM, santosh shilimkar wrote:
>> Nishant,
>>
>> On 9/22/2015 9:08 AM, Nishanth Menon wrote:
>>> Keystone2 devices are used on more platforms than just Texas
>>> Instruments reference evaluation platforms called EVMs. Providing a
>>> generic compatible "ti,keystone" is not sufficient to differentiate
>>> various SoC definitions possible on various platforms. So, provide
>>> compatible matches for each SoC family by itself.
>>>
>>> This allows SoC specific logic to be run time handled based on
>>> of_machine_is_compatible("ti,k2hk") or as needed for the dependent
>>> processor instead of needing to use board dependent compatibles that
>>> are needed now.
>>>
>>> Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
>>> ---
>> You need to expand that 'not sufficient' for me. Unless there is
>> genuine case to support this, I would want to avoid this churn.
>>
> 
> I agree. If there are run time check required in code to treat the 
> variants of Keystone SoC differently, then this change is needed. At 
> this time, SoC DTS captures these differences. IMHO, If a future 
> Keystone SoC support required SoC specific compatibility string to 
> customize SoC specific initialization code, then it can be introduced at 
> that time. I am not sure why this is introduced with out an example usage.

a) See
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/usage-model.txt#n116
-> all we have today is board, soc generic family. The generic
compatible flag of ti,keystone to mark that this is a keystone2 device
does not identify that what kind of soc it is. which is what this
series introduces.

b) there is no realistic way for user space applications such as a
test framework or other SoC based applications in a generic distro to
detect the right SoC this platform is running on - imagine writing SoC
specific code that depends on board compatible flags - there is never
an end to that story as the number of boards expand.

c) Ideally we will try never to introduce code that will have to
depend on SoC compatible flag based match in kernel - but that is not
a reason not to follow guidelines provided by devicetree documentation
to provide SoC specific compatible flags.

-- 
Regards,
Nishanth Menon
--
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:[~2015-09-24 14:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 16:08 [PATCH 0/3] ARM: dts/keystone: Introduce SoC specific compatible matches Nishanth Menon
2015-09-22 16:08 ` [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags Nishanth Menon
2015-09-23 18:05   ` Murali Karicheri
     [not found]     ` <5602E9F3.7020102-l0cyMroinI0@public.gmane.org>
2015-09-23 19:15       ` Nishanth Menon
     [not found]   ` <1442938118-4718-2-git-send-email-nm-l0cyMroinI0@public.gmane.org>
2015-09-23 18:19     ` santosh shilimkar
2015-09-24 14:05       ` Murali Karicheri
     [not found]         ` <56040323.1080409-l0cyMroinI0@public.gmane.org>
2015-09-24 14:20           ` Nishanth Menon [this message]
2015-09-24 15:54             ` Murali Karicheri
     [not found]               ` <56041CA4.40208-l0cyMroinI0@public.gmane.org>
2015-09-25 14:50                 ` Nishanth Menon
2015-09-25 15:18                   ` santosh shilimkar
2015-09-25 16:01                     ` Nishanth Menon
     [not found]                       ` <56056FD9.5060000-l0cyMroinI0@public.gmane.org>
2015-09-25 16:15                         ` santosh shilimkar
     [not found]                           ` <56057319.9080104-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2015-09-25 17:38                             ` Nishanth Menon
2015-10-02 16:09                               ` santosh shilimkar
2015-10-03 23:44                                 ` Nishanth Menon
     [not found]                                   ` <5610685A.3070501-l0cyMroinI0@public.gmane.org>
2015-10-04  0:16                                     ` santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA
2015-09-30 14:31                         ` Murali Karicheri
2015-09-22 16:08 ` [PATCH 2/3] ARM: keystone: Update compatible to have SoC specific matches Nishanth Menon
2015-09-22 16:08 ` [PATCH 3/3] ARM: dts: keystone: Update SoC specific compatible flags Nishanth Menon
     [not found] ` <1442938118-4718-1-git-send-email-nm-l0cyMroinI0@public.gmane.org>
2015-10-03 23:38   ` [PATCH V2 0/3] ARM: dts/keystone: Introduce SoC specific compatible matches Nishanth Menon
2015-10-03 23:38     ` [PATCH V2 2/3] ARM: keystone: Update compatible to have SoC specific matches Nishanth Menon
     [not found]     ` <1443915530-15035-1-git-send-email-nm-l0cyMroinI0@public.gmane.org>
2015-10-03 23:38       ` [PATCH V2 1/3] Documentation: dt: keystone: provide SoC specific compatible flags Nishanth Menon
2015-10-03 23:38       ` [PATCH V2 3/3] ARM: dts: keystone: Update " Nishanth Menon
2015-10-04  0:13       ` [PATCH V2 0/3] ARM: dts/keystone: Introduce SoC specific compatible matches santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA

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=560406C2.6090200@ti.com \
    --to=nm-l0cymroini0@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=m-karicheri2-l0cyMroinI0@public.gmane.org \
    --cc=santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=ssantosh-DgEjT+Ai2ygdnm+yROfE0A@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).