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:

quoted

On 06/21/2012 02:15 PM, Jon Hunter wrote:

quoted

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. 

quoted

quoted

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