linux-kernel - Re: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common

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:	Fri, 21 Sep 2012 19:50:54 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Matt Porter <mporter@...com>
Cc:	"Hebbar, Gururaja" <gururaja.hebbar@...com>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Chris Ball <cjb@...top.org>,
	"Cousson, Benoit" <b-cousson@...com>,
	Arnd Bergmann <arnd@...db.de>,
	Linux Documentation List <linux-doc@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linux MMC List <linux-mmc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Vinod Koul <vinod.koul@...el.com>,
	Rob Landley <rob@...dley.net>, Dan Williams <djbw@...com>,
	Linux SPI Devel List 
	<spi-devel-general@...ts.sourceforge.net>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to
	arm/common

On Fri, Sep 21, 2012 at 02:34:46PM -0400, Matt Porter wrote:
> On Fri, Sep 21, 2012 at 10:42:05AM +0100, Russell King wrote:
> > Here's the pertinant question: "is it platform data?"  Looking at the
> > file, it appears to be internal data structures and register definitions
> > for the driver itself.  Therefore, it isn't platform data, and it
> > shouldn't be living separately from the driver.
> > 
> > If the driver itself only makes use of the data structures, the data
> > structures should be defined either within the driver, or a header file
> > co-located next to the driver itself.  The same goes for register
> > definitions too.
> > 
> > The only structure that I can find which isn't internal to the driver
> > is struct edma_soc_info, struct edma_rsv_info, and the enum dma_event_q.
> > Those can go to include/linux/platform_data, but the rest should not.
> 
> Ok, but is it ok to keep the actual private EDMA API portion in
> arch/arm/include/asm/mach/? It's not a problem to move the internal
> portions to a local include and that pdata to the appropriate place.

Move the platform data parts to include/linux/platform_data.
Move the driver specific parts to be either in the .c file for the
driver, or in a .h file _along_ _side_ the .c file.

Private data for drivers should be kept as close to the driver as
possible, whether that be in the same .c file as the driver itself,
or a header co-located with the .c file.
--
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/