Re: [uClinux-dev] [PATCH 1/14] FRV: Fujitsu FR-V CPU arch implementation

[Christoph Hellwig]

[any reason you drop me from the cc list?]

> > Please use the generic kernel/irq/* code.
> 
> That code is not sufficient.

Why?  And what makes it impossible to extend the code to handle your
hardware. 

> > I can't see this beeing called from generic code ever, why do you
> > implement it?
> 
> It's a placeholder for something I'd like to implement for the FR451 CPU which
> has a decrementer counter. It is actually called from entry.S.

So add it when you implement that code.

> > > +void *dma_alloc_coherent(struct device *hwdev, size_t size, dma_addr_t *dma_handle, int flag)
> 
> > the last argument is the gfp mask.
> 
> It's called "flag" in include/asm-i386/dma-mapping.h. And shouldn't it be an
> "unsigned long" if it's GFP flags?

If you look at the callers it's use as gfp mask.  Feel free to send patches
to change the types to what you think makes sense.

> > does GFP_DMA really hae the same meaning as on i386 here?
> 
> I'm not sure whether it should put all of its memory in the DMA region, or
> none of it. There's no documentation on this.

There's no rules on how to do it anyway.  But it looks like you don't
have any arbitrary dma limits, so conditionally setting doesn't make
much sense.

> > Don't mess with per-arch fields in common procfs files.
> 
> Should I then add an arch-specific file to "/proc/<pid>/"?

That's not that bad at least.  But you'd need to convience us why
your port is the first that absolutely needs something like that.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/