lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 22 Nov 2013 09:58:01 -0600
From:	Rob Herring <robherring2@...il.com>
To:	Joel Fernandes <joelf@...com>
Cc:	linux-omap <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	jgchunter@...il.com, rnayak@...com, Felipe Balbi <balbi@...com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	benoit.cousson@...aro.org
Subject: Re: [PATCH 5/8] ARM: OMAP2+: timer: Introduce OF-friendly
 clocksource/clockevent system timers

On Thu, Nov 21, 2013 at 7:56 PM, Joel Fernandes <joelf@...com> wrote:
> This work is a migration effort of OMAP system timers to the
> clocksource/clockevent framework. Consider this as a first-pass in this effort.
> There are few cleanups that need to be done first. The HWMOD code is
> intertwined with the timer code. HWMOD code cleanups in the future will
> hopefully make most of this code go away, so till then we separate out the
> power/clocks portion of the code from the actual timer bits.  This will
> facilitate near-future work of adapting the system timer as a clocksource.
>
> New functions for OF-only boot are introduced, and we can soon delete the old
> versions once we migrate all platforms. Currently only AM335x is migrated and
> testedA new omap_generic_timer_init function is introduced for DT platforms.
> Code required earlier for non-DT platforms such as setup of timer IDs and timer
> parent clock is not required.  parent clocks are automatically setup by the mux
> clock driver through DT so they no longer need to be hardcoded.
>
> The init code will try to pick the best timer for clocksource and clockevent
> however bindings are added to force a particular timer as clocksource or
> clockevent through DT.
>
> Signed-off-by: Joel Fernandes <joelf@...com>
> ---
>  .../devicetree/bindings/arm/omap/timer.txt         |  12 ++
>  arch/arm/mach-omap2/common.h                       |   1 +
>  arch/arm/mach-omap2/timer.c                        | 235 +++++++++++++++++++++
>  3 files changed, 248 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
> index d02e27c..6cf7a75 100644
> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -32,6 +32,18 @@ Optional properties:
>  - ti,timer-secure:     Indicates the timer is reserved on a secure OMAP device
>                         and therefore cannot be used by the kernel.
>
> +- ti,timer-clockevent,
> +  ti,timer-clocksource These properties force the system timer code to choose
> +                       the particular timer as a clockevent or clocksource.
> +                       If these properties are not specified, the timer code
> +                       picks up a "ti,timer-alwon" as the clocksource and a
> +                       timer containing one of the following properties as
> +                       the clockevent in the following order:
> +                               ti,timer-alwon
> +                               ti,timer-dsp
> +                               ti,timer-pwm
> +                               ti,timer-secure

These properties were added specifically for the reason of avoiding
linux specific properties like these. When is this not sufficient?

And I agree with the comment to use OF_CLKSRC.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ