Messages in this thread | | | Date | Fri, 19 May 2006 12:03:03 +0200 | From | Jörn Engel <> | Subject | Re: [PATCH] Add Amstrad Delta NAND support. |
| |
On Fri, 19 May 2006 10:01:42 +0100, Jonathan McDowell wrote: > On Thu, May 18, 2006 at 06:57:28PM +0200, Jörn Engel wrote: > > On Thu, 18 May 2006 17:09:41 +0100, Jonathan McDowell wrote: > > > + omap_writew(0, (OMAP_MPUIO_BASE + OMAP_MPUIO_IO_CNTL)); > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Could that be done in a macro? > > Is there any benefit to doing so?
Not a big one. A common pattern is to have some defines like
#define FOO_BASE 0x12340000 #define FOO_THIS (FOO_BASE + 0) #define FOO_THAT (FOO_BASE + 4) etc.
Your code looks similar to this pattern, so I asked. If it doesn't make sense, fair.
> > > + udelay(0.04); > > > > Floating point in the kernel? > > Not quite. udelay is a macro on ARM so this ends up as an integer before > it ever hits a function call.
Hmm. It does what you say. Whether this is robust and will continue to do so... I'm not sure.
> In an ideal world I'd use "ndelay(40);" > but that would result in a delay of over 1µs as ARM doesn't have ndelay > defined so we hit the generic fallback.
Can you either introduce a proper ndelay or get rmk to officially bless your use of (constant, I know) floats in the kernel source? A proper ndelay would obviously be preferred.
> > > + ams_delta_mtd = kmalloc (sizeof(struct mtd_info) + > > ^ > > > + sizeof (struct nand_chip), GFP_KERNEL); > > > > Remove space > > > > And please create a structure containing both struct mtd_info and > > struct nand_chip. Then use sizeof(that structure)... > > This format is used throughout the drivers/mtd/nand/ directory. I'd > suggest it'd be more appropriate to have a separate patch that did this > for all of them if it's desired, rather than having each driver do its > own thing. > > Agreed on all the spacing comments you raised; hangovers from toto.c > that I used as a base.
We have suboptimal code in the kernel, true. I still prefer new code to have slightly higher standards, so the overall quality improves slowly. Therefore, pointing to the other ugly duckling is not an excuse for being mud-covered. ;)
But you are right. The other ducklings could use a bath as well.
Jörn
-- There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |