devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: device-tree <devicetree-discuss@lists.ozlabs.org>,
	robherring2@gmail.com, Grant Likely <grant.likely@secretlab.ca>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [RFC] ARM: OMAP: Remove nodes dynamically at runtime
Date: Thu, 5 Jul 2012 13:21:14 -0500	[thread overview]
Message-ID: <4FF5DB1A.5080106@ti.com> (raw)
In-Reply-To: <4FECF376.3010001@ti.com>

Hi Rob,

Thanks for the feedback. Some how our mail server appeared to filter out your
response!

> On 06/21/2012 06:50 PM, Jon Hunter wrote:
>> 
>> On 06/21/2012 02:15 PM, Jon Hunter wrote:
>>> Hi all,
>>>
>>> I am in the process of adding a device-tree binding for OMAP timers and
>>> I have encountered a scenario where ideally it would be useful to remove
>>> a device-tree node at runtime.
>>>
>>> The scenario is this ...
>>>
>>> 1. OMAP3 devices may or may not have security features enabled. Security
>>>    enabled devices are known as high-secure (HS) and devices without 
>>>    security are known as general purpose (GP).
>>> 2. For OMAP3 devices there are 12 general purpose timers available.
>>> 3. On secure devices the 12th timer is reserved for secure usage and so
>>>    cannot be used by the kernel, where as for a GP device it is available.
>>> 4. We can detect the OMAP device type, secure or GP, at runtime via an
>>>    on-chip register.
>>> 5. Today, when not using DT, we do not register the 12th timer as a linux
>>>    device if the device is secure.
>>>
>>> When migrating the timers to DT, I need a way to prevent this 12th timer
>>> from being registered as a device on a secure device. The options I have
>>> considered are ...
>>>
>>> a. Have separate a omap3.dtsi for GP and secure devices or place the
>>>    node for the 12th timer in a omap3-gp.dtsi that is only used for
>>>    boards with GP devices. The downside of this is that for boards
>>>    that can support GP and secure device (such as the omap3 SDP) we
>>>    require a separate dtb blob.
>
> That's certainly not ideal since you can distinguish which device you
> are on. Does omap have a custom register for this because determining
> secure vs. non-secure mode is a common problem without a standard way to
> determine it.

Yes, unfortunately the register I was referring to is a custom OMAP register. 

>>>
>>> b. Remove the timer node dynamically at runtime using the
>>>    of_node_detach() API. In this solution we define a "ti,timer-secure"
>>>    property that the 12th timer on omap3 devices would have and at
>>>    runtime if we are a secure omap3 device, we search the timer nodes
>>>    for any nodes with this property and remove them.
>>>
>>> Option B, seems to be the better option but requires me to enable 
>>> CONFIG_OF_DYNAMIC for all omap devices and I was not sure if there is any
>>> downside to doing so. Enabling this feature does not seem to add much code
>>> as far as I can tell, however, I  wanted to get some feedback before
>>> proposing this. Also if there are any other options I should consider then
>>> please let me know.
>>>
>
> I would wonder if of_node_get/put calls are all properly implemented.
> They don't really matter until OF_DYNAMIC is enabled, but it would
> affect all ARM DT platforms once we enable multi-platform support.
>
> Option C - have the bootloader set nodes status property to disabled.
> 
> Option D - same as C, but do it in the kernel with prom_add_property.

Option D, sounds good to me. I will look into this.

Thanks
Jon

  reply	other threads:[~2012-07-05 18:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-21 19:15 [RFC] ARM: OMAP: Remove nodes dynamically at runtime Jon Hunter
2012-06-21 23:50 ` Jon Hunter
2012-06-29  0:14   ` Jon Hunter
2012-07-05 18:21     ` Jon Hunter [this message]
     [not found]   ` <4FE3B328.8060805-l0cyMroinI0@public.gmane.org>
2012-07-02  3:49     ` 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=4FF5DB1A.5080106@ti.com \
    --to=jon-hunter@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-omap@vger.kernel.org \
    --cc=robherring2@gmail.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 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).