linux-kernel - Re: [PATCH 1/3] x86: enable common clk on x86

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]

Message-ID: <20130116052054.GT13897@intel.com>
Date:	Wed, 16 Jan 2013 07:20:54 +0200
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Len Brown <lenb@...nel.org>,
	Mike Turquette <mturquette@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 1/3] x86: enable common clk on x86

On Wed, Jan 16, 2013 at 12:59:17AM +0100, Rafael J. Wysocki wrote:
> On Monday, January 14, 2013 04:46:26 PM Mika Westerberg wrote:
> > We are starting to see traditional SoC peripherals also in the x86 world,
> > things like UART, I2C and SPI controllers that might already have a working
> > device driver. These drivers typically take advantage of the Linux clk
> > framework to control and retrieve information about the peripheral clock.
> > 
> > There hasn't been a standard way on x86 to pass the clock rate from
> > whatever configuration system is used to the driver, but instead different
> > variations have emerged, like adding this information to the platform data.
> > 
> > In order to use the standard Linux way we enable the common clk subsystem
> > also on x86. This allows us to re-use the drivers with little or no
> > modification wrt. clock API usage.
> > 
> > This patch was originally proposed by Mark Brown.
> 
> Are there any side effects of selecting COMMON_CLK by an arch and if so then
> what are they?

Selecting COMMON_CLK also selects HAVE_CLK, so drivers that are dependent
on that option become available when you run make config.

It also makes clk_get() and friends to return errors if the clock is not
found (instead of returning NULL as in case with !HAVE_CLK). This means
that if there is a driver that counted on the stubbed out clocks on x86 it
will fail to get the clock after this patch. However, the patch that adds
the stub functions was merged only lately:

	commit 93abe8e4b13ae9a0428ce940a8a03ac72a7626f1
	Author: Viresh Kumar <viresh.kumar@...com>
	Date:   Mon Jul 30 14:39:27 2012 -0700

	    clk: add non CONFIG_HAVE_CLK routines
	    
	    Many drivers are shared between architectures that may or may not have
	    HAVE_CLK selected for them.  To remove compilation errors for them we
	    enclose clk_*() calls in these drivers within #ifdef CONFIG_HAVE_CLK,
	    #endif.
	    
	    This patch removes the need of these CONFIG_HAVE_CLK statements, by
	    introducing dummy routines when HAVE_CLK is not selected by platforms.
	    So, definition of these routines will always be available.  These calls
	    will return error for platforms that don't select HAVE_CLK.
--
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/