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: <20111026073348.GB2915@opensource.wolfsonmicro.com>
Date:	Wed, 26 Oct 2011 09:33:50 +0200
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Mike Frysinger <vapier@...too.org>
Cc:	Russell King <linux@....linux.org.uk>,
	Haavard Skinnemoen <hskinnemoen@...il.com>,
	Hans-Christian Egtvedt <egtvedt@...fundet.no>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Guan Xuetao <gxt@...c.pku.edu.cn>,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	uclinux-dist-devel@...ckfin.uclinux.org,
	linux-m68k@...ts.linux-m68k.org, linux-mips@...ux-mips.org,
	linux-sh@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH] gpiolib/arches: Centralise bolierplate asm/gpio.h

On Tue, Oct 25, 2011 at 07:44:14PM -0400, Mike Frysinger wrote:

> i don't think this is generally how asm-generic is handled.  instead, how about:
>  - move the duplicate code to asm-generic/gpio.h
>  - have the arches which merely need asm-generic/gpio.h add "generic-y
> += gpio.h" to their include/asm/Kbuild
>  - for arches which need to override these common funcs in some way,
> add #ifdef protection to the asm-generic/gpio.h

> and it seems like with slightly more work, this path allow you to
> merge most of arch/sh/include/asm/gpio.h.  and it has the advantage of
> not needing new Kconfig symbols.

That's really not how gpiolib is currently handled, unfortunately -
trying to transition over to that model in one patch would be way too
much.  

The goal here from that point of view is to make transitioning to
something more sensible easier by getting rid of the boilerplate code,
it makes doing the more invasive changes like you're suggesting much
easier as we're only dealing with the architectures that are actually
doing something.  It also means that we're able to immediately work on
turning on gpiolib on random architectures which is a definite win.
--
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