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