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:

quoted

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.