[RFC] Make physmap into a platform device driver...

[Deepak Saxena <dsaxena@plexity.net>]

I'm working on a system where I want to use the physmap driver
but the size or buswidth of the flash device might change depending
on the specific board layout. I want to be able to build a single kernel
that boots on all boards using this NPU (IXP2350) and with the hardcoded
approach to buswidth and such, it makes it rather impossible. On ARM
platforms, we've been using the following data structure to pass
board-specific flash information to the SOC-specific drivers and I 
am wondering if it makes sense to move it out of ARM into the generic
MTD layer and have the physmap driver use it. The physmap driver
could register itself as a platform driver for "phys-mtd" devices
and boards would just fill in platform_device structure with the
appropriate resource window and the needed fields below as the
platform_data. We may want to trim down the structure to remove 
ARM-specific fields and let ARM have it's own structure that contains
the generic structure as a member. Thoughts?

~Deepak

/*
 * map_name:	the map probe function name
 * name:	flash device name (eg, as used with mtdparts=)
 * width:	width of mapped device
 * init:	method called at driver/device initialisation
 * exit:	method called at driver/device removal
 * set_vpp:	method called to enable or disable VPP
 * mmcontrol:	method called to enable or disable Sync. Burst Read in OneNAND
 * parts:	optional array of mtd_partitions for static partitioning
 * nr_parts:	number of mtd_partitions for static partitoning
 */
struct flash_platform_data {
	const char	*map_name;
	const char	*name;
	unsigned int	width;
	int		(*init)(void);
	void		(*exit)(void);
	void		(*set_vpp)(int on);
	void		(*mmcontrol)(struct mtd_info *mtd, int sync_read);
	struct mtd_partition *parts;
	unsigned int	nr_parts;
};


-- 
Deepak Saxena - dsaxena@plexity.net - http://www.plexity.net

A starving child in Africa or you in front of your TV?
Where's the real tragedy?