All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: David Howells <dhowells@redhat.com>
Cc: uClinux development list <uclinux-dev@uclinux.org>,
	akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org,
	mingo@elte.hu
Subject: Re: [uClinux-dev] [PATCH 1/14] FRV: Fujitsu FR-V CPU arch implementation
Date: Wed, 3 Nov 2004 20:32:08 +0000	[thread overview]
Message-ID: <20041103203208.GA23494@infradead.org> (raw)
In-Reply-To: <8632.1099511196@redhat.com>

[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.


  reply	other threads:[~2004-11-03 20:32 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040401020550.GG3150@beast>
     [not found] ` <76b4a884-2c3c-11d9-91a1-0002b3163499@redhat.com>
2004-11-01 19:30   ` [PATCH 4/14] FRV: Bitops fixes dhowells
2004-11-02  8:19     ` Andrew Morton
2004-11-01 19:30   ` [PATCH 3/14] FRV: Fujitsu FR-V arch documentation dhowells
2004-11-01 19:30   ` [PATCH 11/14] FRV: Add FDPIC ELF binary format driver dhowells
2004-11-02  8:18     ` Andrew Morton
2004-11-02 11:07     ` Andrew Morton
2004-11-02 16:47       ` David Howells
2004-11-02 17:23         ` Andi Kleen
2004-11-01 19:30   ` [PATCH 7/14] FRV: GDB stub dependent additional BUG()'s dhowells
2004-11-02  9:34     ` Christoph Hellwig
2004-11-02 16:09       ` David Howells
2004-11-03 10:39         ` Christoph Hellwig
2004-11-03 13:41           ` David Howells
2004-11-01 19:30   ` [PATCH 9/14] FRV: CONFIG_MMU fixes dhowells
2004-11-02  9:43     ` Christoph Hellwig
2004-11-03 15:06       ` David Howells
2004-11-03 15:13         ` Christoph Hellwig
2004-11-03 15:30           ` David Howells
2004-11-01 19:30   ` [PATCH 10/14] FRV: Make calibrate_delay() optional dhowells
2004-11-02  0:06     ` john stultz
2004-11-02 11:01       ` David Howells
2004-11-02  8:17     ` Andrew Morton
2004-11-02  9:36     ` Christoph Hellwig
2004-11-02 16:29       ` David Howells
2004-11-03 10:40         ` Christoph Hellwig
2004-11-01 19:30   ` [PATCH 6/14] FRV: IDE fixes dhowells
2004-11-01 22:53     ` Alan Cox
2004-11-02  0:13       ` Bartlomiej Zolnierkiewicz
2004-11-02 10:57         ` David Howells
2004-11-01 19:30   ` [PATCH 8/14] FRV: GP-REL data support dhowells
2004-11-02  8:18     ` Andrew Morton
2004-11-02  9:48     ` Christoph Hellwig
2004-11-02 16:34       ` David Howells
2004-11-03 10:42         ` Christoph Hellwig
2004-11-01 19:30   ` [PATCH 5/14] FRV: Fork fixes dhowells
2004-11-01 19:30   ` [PATCH 12/14] FRV: Generate more useful debug info dhowells
2004-11-02  0:29     ` Andrew Morton
2004-11-02 11:21       ` David Howells
2004-11-03  1:48         ` Linus Torvalds
2004-11-03  1:52           ` Linus Torvalds
2004-11-03 13:38             ` David Howells
2004-11-03 15:32               ` Linus Torvalds
2004-11-03 20:40             ` Florian Weimer
2004-11-03 20:42               ` Linus Torvalds
2004-11-12 14:57         ` Daniel Jacobowitz
2004-11-12 15:15           ` David Howells
2004-11-12 15:20             ` Daniel Jacobowitz
2004-11-01 19:30   ` [PATCH 13/14] FRV: Convert extern inline -> static inline dhowells
2004-11-01 19:30   ` [PATCH 14/14] FRV: Better mmap support in uClinux dhowells
2004-11-02  9:54     ` Christoph Hellwig
2004-11-02 16:43       ` David Howells
2004-11-03 10:45         ` Christoph Hellwig
2004-11-02  0:21   ` [PATCH 1/14] FRV: Fujitsu FR-V CPU arch implementation Andrew Morton
2004-11-04 11:54     ` David Howells
     [not found]   ` <200411011930.iA1JUKFH023161@warthog.cambridge.redhat.com>
2004-11-02 23:24     ` [uClinux-dev] [PATCH 2/14] FRV: Fujitsu FR-V arch include files Christoph Hellwig
2004-11-03 17:26       ` David Howells
2004-11-02 23:46   ` [uClinux-dev] [PATCH 1/14] FRV: Fujitsu FR-V CPU arch implementation Christoph Hellwig
2004-11-03 19:46     ` David Howells
2004-11-03 20:32       ` Christoph Hellwig [this message]
2004-11-08 14:34 ` [PATCH 1/20] FRV: Fujitsu FR-V CPU arch maintainer record dhowells
2004-11-08 14:34   ` [PATCH 2/20] FRV: Fujitsu FR-V arch documentation dhowells
2004-11-08 14:34   ` [PATCH 3/20] FRV: Fujitsu FR-V CPU arch implementation part 1 dhowells
2004-11-08 14:34   ` [PATCH 7/20] FRV: Fujitsu FR-V CPU arch implementation part 5 dhowells
2004-11-09 15:09     ` Geert Uytterhoeven
2004-11-08 14:34   ` [PATCH 4/20] FRV: Fujitsu FR-V CPU arch implementation part 2 dhowells
2004-11-08 14:34   ` [PATCH 6/20] FRV: Fujitsu FR-V CPU arch implementation part 4 dhowells
2004-11-08 14:34   ` [PATCH 5/20] FRV: Fujitsu FR-V CPU arch implementation part 3 dhowells
2004-11-08 14:34   ` [PATCH 9/20] FRV: Fujitsu FR-V CPU arch implementation part 7 dhowells
2004-11-08 14:34   ` [PATCH 11/20] FRV: Fujitsu FR-V CPU arch implementation part 9 dhowells
2004-11-08 14:34   ` [PATCH 10/20] FRV: Fujitsu FR-V CPU arch implementation part 8 dhowells
2004-11-08 14:34   ` [PATCH 8/20] FRV: Fujitsu FR-V CPU arch implementation part 6 dhowells
2004-11-08 14:34   ` [PATCH 16/20] FRV: Make calibrate_delay() optional dhowells
2004-11-08 14:34   ` [PATCH 15/20] FRV: Fujitsu FR-V arch include files dhowells
2004-11-08 14:34   ` [PATCH 14/20] " dhowells
2004-11-08 14:34   ` [PATCH 13/20] " dhowells
2004-11-08 14:34   ` [PATCH 18/20] FRV: procfs changes for nommu changes dhowells
2004-11-08 14:34   ` [PATCH 19/20] FRV: change setup_arg_pages() to take stack pointer dhowells
2004-11-08 14:34   ` [PATCH 20/20] FRV: Add FDPIC ELF binary format driver dhowells
2004-11-08 14:34   ` [PATCH 17/20] FRV: Better mmap support in uClinux dhowells
2004-11-09 12:57     ` Christoph Hellwig
2004-11-09 13:55       ` David Howells
2004-11-09 14:02         ` Christoph Hellwig
2004-11-19  5:29     ` Matt Mackall
2004-11-19 16:26       ` David Howells
2004-11-19 16:56         ` Matt Mackall
2004-11-19 17:06           ` David Howells
2004-11-19 17:42             ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041103203208.GA23494@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@osdl.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.org \
    --cc=uclinux-dev@uclinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.