[PATCH V4] mtd: Add DiskOnChip G3 support

[Artem Bityutskiy]

Could you please re-base your driver on top of my l2 tree and fix
warnings 0 I get the following:

  CC [M]  drivers/mtd/devices/docg3.o
drivers/mtd/devices/docg3.c: In function ‘doc_read’:
drivers/mtd/devices/docg3.c:556:2: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 5 has type ‘size_t’ [-Wformat]
drivers/mtd/devices/docg3.c: In function ‘doc_read_oob’:
drivers/mtd/devices/docg3.c:652:2: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘size_t’ [-Wformat]
drivers/mtd/devices/docg3.c:657:7: error: ‘MTD_OOB_PLACE’ undeclared (first use in this function)
drivers/mtd/devices/docg3.c:657:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/mtd/devices/docg3.c: In function ‘flashcontrol_open’:
drivers/mtd/devices/docg3.c:793:1: warning: passing argument 2 of ‘single_open’ from incompatible pointer type [enabled by default]
include/linux/seq_file.h:120:5: note: expected ‘int (*)(struct seq_file *, void *)’ but argument is of type ‘ssize_t (*)(struct seq_file *, void *)’
drivers/mtd/devices/docg3.c: In function ‘asic_mode_open’:
drivers/mtd/devices/docg3.c:827:1: warning: passing argument 2 of ‘single_open’ from incompatible pointer type [enabled by default]
include/linux/seq_file.h:120:5: note: expected ‘int (*)(struct seq_file *, void *)’ but argument is of type ‘ssize_t (*)(struct seq_file *, void *)’
drivers/mtd/devices/docg3.c: In function ‘device_id_open’:
drivers/mtd/devices/docg3.c:838:1: warning: passing argument 2 of ‘single_open’ from incompatible pointer type [enabled by default]
include/linux/seq_file.h:120:5: note: expected ‘int (*)(struct seq_file *, void *)’ but argument is of type ‘ssize_t (*)(struct seq_file *, void *)’
drivers/mtd/devices/docg3.c: In function ‘protection_open’:
drivers/mtd/devices/docg3.c:892:1: warning: passing argument 2 of ‘single_open’ from incompatible pointer type [enabled by default]
include/linux/seq_file.h:120:5: note: expected ‘int (*)(struct seq_file *, void *)’ but argument is of type ‘ssize_t (*)(struct seq_file *, void *)’
drivers/mtd/devices/docg3.c: In function ‘docg3_probe’:
drivers/mtd/devices/docg3.c:1015:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ [-Wformat]
drivers/mtd/devices/docg3.c:1021:3: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘resource_size_t’ [-Wformat]
drivers/mtd/devices/docg3.c:1039:3: error: implicit declaration of function ‘parse_mtd_partitions’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

BTW, the next step I'd do is to try to compile it with sparse, so you
could test this driver with sparse: Documentation/sparse.txt

Thanks!

On Wed, 2011-09-21 at 21:27 +0200, Robert Jarzmik wrote:
> +#define doc_readb(reg)	\
> +	__raw_readb(docg3->base + (reg));
> +#define doc_writeb(value, reg)						\
> +do {									\
> +	doc_vdbg("Write %02x to register %04x\n", (value), (reg));	\
> +	__raw_writeb((value), docg3->base + (reg));			\
> +} while (0)
> +#define doc_readw(reg)	\
> +	__raw_readw(docg3->base + (reg));
> +#define doc_writew(value, reg)						\
> +do {									\
> +	doc_vdbg("Write %04x to register %04x\n", (value), (reg));	\
> +	__raw_writew((value), docg3->base + (reg));			\
> +} while (0)
> +
> +#define doc_flashCommand(cmd)						\
> +do {									\
> +	doc_dbg("doc_flashCommand:  %02x " #cmd "\n", DoC_Cmd_##cmd);	\
> +	doc_writeb(DoC_Cmd_##cmd, DoC_FlashCommand);			\
> +} while (0)
> +
> +#define doc_flashSequence(seq)						\
> +do {									\
> +	doc_dbg("doc_flashSequence: %02x " #seq "\n", DoC_Seq_##seq);	\
> +	doc_writeb(DoC_Seq_##seq, DoC_FlashSequence);			\
> +} while (0)
> +
> +#define doc_flashAddress(addr)						\
> +do {									\
> +	doc_dbg("doc_flashAddress:  %02x\n", (addr));			\
> +	doc_writeb((addr), DoC_FlashAddress);				\
> +} while (0)

Could you please turn these macros into 'static inline' function - this
is one of the modern patterns of kernel programming - we try to use
functions for better type checking.

-- 
Best Regards,
Artem Bityutskiy