Thread (13 messages) flat view 13 messages, 5 authors, 2012-06-09

Re: [PATCH] netdev: mv643xx_eth: Prevent build on PPC32

From: Josh Boyer <hidden>
Date: 2012-06-08 01:04:51
Subsystem: common clk framework, the rest · Maintainers: Stephen Boyd, Brian Masney, Jerome Brunet, Linus Torvalds

On Fri, Jun 08, 2012 at 01:34:45AM +0100, Mark Brown wrote:
On Thu, Jun 07, 2012 at 07:55:51PM -0400, Josh Boyer wrote:
quoted
On Fri, Jun 08, 2012 at 12:51:15AM +0100, Mark Brown wrote:
quoted
quoted
This sort of issue is just the tip of the iceberg in terms of what it's
useful to do with the API.
quoted
Yes, sounds like it.  All I ask is that people test their patches along
the way so things don't get broken.  I mean, it's great we have an
iceberg but I don't want tons of drivers on other architectures running
into the thing and sinking because people aren't being careful.  Except
maybe the one already appropriately (nick)named.
It's really hard to blame the submitters here - this really isn't the
sort of API that you'd expect to only be available conditionally so this
isn't something that one would expect to have to worry about.  It's a
product of the age of the clock API and the glacial progress on the
generic clock API.
I'm not placing blame.  I'm declaring people should be cautious going
forward.  5 arches have the clock API.  21 don't.  Whatever reasons
there are for that, I don't care.  It should be a big warning sign.

It might even be beneficial to put some Kconfig dependencies on both
CONFIG_COMMON_CLK (which is somewhat misleadingly named) and
CONFIG_CLKDEV_LOOKUP so those are only selectable on those 5 arches.
Something like:
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 4864407..3f49c22 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -1,6 +1,7 @@
 
 config CLKDEV_LOOKUP
 	bool
+	depends on (ARM || SUPERH || MIPS || C6X || BLACKFIN)
 	select HAVE_CLK
 
 config HAVE_CLK_PREPARE
@@ -11,6 +12,7 @@ config HAVE_MACH_CLKDEV
 
 config COMMON_CLK
 	bool
+	depends on (ARM || SUPERH || MIPS || C6X || BLACKFIN)
 	select HAVE_CLK_PREPARE
 	select CLKDEV_LOOKUP
 	---help---
Regardless, hopefully things like this will get hit in linux-next in the
future.  I believe the only reason that it wasn't this time is that
none of the PPC defconfigs build in linux-next bother to build the
driver at all.

josh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help