public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox