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
next prev parent 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