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

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:	Thu, 7 Jun 2012 21:04:03 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Ben Hutchings <ben@...adent.org.uk>,
	Lennert Buytenhek <buytenh@...tstofly.org>,
	Andrew Lunn <andrew@...n.ch>, Olof Johansson <olof@...om.net>,
	netdev@...r.kernel.org
Subject: Re: [PATCH] netdev: mv643xx_eth: Prevent build on PPC32

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:
> > On Fri, Jun 08, 2012 at 12:51:15AM +0100, Mark Brown wrote:
> 
> > > This sort of issue is just the tip of the iceberg in terms of what it's
> > > useful to do with the API.
> 
> > 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html