All of lore.kernel.org
 help / color / mirror / Atom feed
From: gerg <gerg@snapgear.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: linux-2.5.30uc0 MMU-less patches
Date: Sat, 03 Aug 2002 02:01:30 +1000	[thread overview]
Message-ID: <3D4AACDA.2010902@snapgear.com> (raw)
In-Reply-To: 3007.1028299196@redhat.com

Hi David,

David Woodhouse wrote:
> gerg@snapgear.com said:
> 
>> I have coded a generic MTD map driver to replace the old crufty
>>blkmem driver. The blkmem driver will be going away in future patches.

Did you have a look at uclinux.c, that is the one I was referring
to here?


> --- linux-2.5.30/drivers/mtd/maps/snapgear-uc.c	Thu Jan  1 10:00:00 1970
> +++ linux-2.5.30uc0/drivers/mtd/maps/snapgear-uc.c	Mon Jul 15 21:29:25 2002
> +#ifdef CONFIG_NFTL
> +#include <linux/mtd/nftl.h>
> +#endif
> 
> You shouldn't need that.

There is one board setup supported by this that uses DiskOnChip
(the CONFIG_SH_SECUREEDGE5410 define). But your probably right,
it wouldn't need nftl.h.


> +int flash_eraseconfig(void)
> +{
> 
> This will cause an oops if it gets woken by a signal -- you leave and the 
> the 'struct erase_info' on your stack frame, which you passed to the 
> asynchronous erase call, goes bye bye.

OK, I'll get that fixed.


> +		ROOT_DEV = MKDEV(NFTL_MAJOR, 1);
> 
> Oh, I see -- if we fail to find a file system we recognise on the NOR 
> flash, try booting from DiskOnChip. Does this really live here?

Well, it actually support for a completely different board - it
doesn't have NOR flash at all.

This code supports a wide variety of boards, with mixtures of
NOR flash and/or DiskOnChip.


> --- linux-2.5.30/drivers/mtd/mtdblock.c	Fri Aug  2 15:15:41 2002
> +++ linux-2.5.30uc0/drivers/mtd/mtdblock.c	Fri Aug  2 16:00:13 2002
> -		if (req->flags & REQ_CMD)
> +		if (! (req->flags & REQ_CMD))
> 
> Yes.
> 
> +#ifdef MAGIC_ROM_PTR
> +static int
> +mtdblock_romptr(kdev_t dev, struct vm_area_struct * vma)
> 
> No, although the fix I'm happy with is going to take a while to get 
> implemented so maybe in the short term. This is likely to get rejected on 
> other grounds anyway; perhaps separate it and don't submit it for inclusion 
> just now?

Sounds good to me. The most important is the uclinux.c support.
Since that means I can get rid of the blkmem driver all together
from the uClinux patches.

Thanks
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg@snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com


  reply	other threads:[~2002-08-02 15:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-02  6:34 [PATCH]: linux-2.5.30uc0 MMU-less patches Greg Ungerer
2002-08-02 12:16 ` Dave Jones
2002-08-02 15:29   ` gerg
2002-08-02 15:34     ` Dave Jones
2002-08-02 15:54       ` gerg
2002-08-02 16:01         ` Dave Jones
2002-08-02 14:39 ` David Woodhouse
2002-08-02 16:01   ` gerg [this message]
2002-08-05 10:02     ` David Woodhouse
2002-08-05 15:36       ` gerg

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=3D4AACDA.2010902@snapgear.com \
    --to=gerg@snapgear.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.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.