public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Ian Campbell <icampbell@arcom.com>
To: Linux MTD Mailing List <linux-mtd@lists.infradead.org>
Subject: [PATCH] add_mtd_device_full
Date: 05 Feb 2003 11:42:31 +0000	[thread overview]
Message-ID: <1044445351.12802.1558.camel@LinuxDev> (raw)

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

Hello,

This patch adds a function add_mtd_device_full which works the same as
add_mtd_device except it allows you to request a particular minor number
for the new device.

I wanted this because on our boards we have Flash, SRAM and BIOS all
accessible via MTD, unfortunately the minor number of the SRAM and BIOS
devices can change depending on how many partitions exist in the main
Flash, and the BIOS minor number can additionally change depending on if
the board has SRAM fitted or not etc. I would much prefer to be able to
say that SRAM would always be mtd14 and BIOS would be mtd15.

It is also possible (and I have done this :-( ) that when booting from a
HDD or CDROM you modprobe the BIOS mapping module before the Flash
mapping module and happily overwrite the BIOS (on mtd0) thinking it is
the boot partition on the flash (which is normally mtd0).

What are the chances of this being rolled into the main MTD
distribution?

I've also attached mtd.ram.erase.patch which I sent ages ago which is
needed to mount JFFS2 on an SRAM (map_ram) device.

Ian.

-- 
Ian Campbell
Design Engineer

Arcom Control Systems Ltd,
Clifton Road,
Cambridge CB1 7EA
United Kingdom

Tel: +44 (0)1223 403465
E-Mail: icampbell@arcom.com
Web: http://www.arcom.com


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

[-- Attachment #2: mtd.ram.erase.patch --]
[-- Type: text/plain, Size: 354 bytes --]

? mtd.ram.erase.patch
? drivers/mtd/chips/.map_ram.c.swp
Index: drivers/mtd/chips/map_ram.c
=========================================?rom icampbell@arcom.com  Wed Feb  5 11:42:31 2003
From: icampbell@arcom.com (Ian Campbell)
Date: 05 Feb 2003 11:42:31 +0000
Subject: [PATCH] add_mtd_device_full
Message-ID: <1044445351.12802.1558.camel@LinuxDev>

[-- Attachment #3: Type: text/plain, Size: 1610 bytes --]

Hello,

This patch adds a function add_mtd_device_full which works the same as
add_mtd_device except it allows you to request a particular minor number
for the new device.

I wanted this because on our boards we have Flash, SRAM and BIOS all
accessible via MTD, unfortunately the minor number of the SRAM and BIOS
devices can change depending on how many partitions exist in the main
Flash, and the BIOS minor number can additionally change depending on if
the board has SRAM fitted or not etc. I would much prefer to be able to
say that SRAM would always be mtd14 and BIOS would be mtd15.

It is also possible (and I have done this :-( ) that when booting from a
HDD or CDROM you modprobe the BIOS mapping module before the Flash
mapping module and happily overwrite the BIOS (on mtd0) thinking it is
the boot partition on the flash (which is normally mtd0).

What are the chances of this being rolled into the main MTD
distribution?

I've also attached mtd.ram.erase.patch which I sent ages ago which is
needed to mount JFFS2 on an SRAM (map_ram) device.

Ian.

-- 
Ian Campbell
Design Engineer

Arcom Control Systems Ltd,
Clifton Road,
Cambridge CB1 7EA
United Kingdom

Tel: +44 (0)1223 403465
E-Mail: icampbell@arcom.com
Web: http://www.arcom.com


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

[-- Attachment #4: mtd.ram.erase.patch --]
[-- Type: text/plain, Size: 588 bytes --]

? mtd.ram.erase.patch
? drivers/mtd/chips/.map_ram.c.swp
Index: drivers/mtd/chips/map_ram.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/chips/map_ram.c,v
retrieving revision 1.14
diff -u -r1.14 map_ram.c
--- drivers/mtd/chips/map_ram.c	2 Oct 2001 15:05:12 -0000	1.14
+++ drivers/mtd/chips/map_ram.c	30 Oct 2002 12:20:06 -0000
@@ -107,6 +107,8 @@
 	for (i=0; i<instr->len; i++)
 		map->write8(map, 0xFF, instr->addr + i);
 
+	instr->state = MTD_ERASE_DONE;
+
 	if (instr->callback)
 		instr->callback(instr);
 

[-- Attachment #5: add_mtd_full.patch --]
[-- Type: text/plain, Size: 3348 bytes --]

Index: drivers//mtd/mtdcore.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/mtdcore.c,v
retrieving revision 1.34
diff -u -b -B -w -p -u -r1.34 mtdcore.c
--- drivers//mtd/mtdcore.c	24 Jan 2003 23:32:25 -0000	1.34
+++ drivers//mtd/mtdcore.c	5 Feb 2003 11:25:52 -0000
@@ -29,29 +29,37 @@ static struct mtd_info *mtd_table[MAX_MT
 static struct mtd_notifier *mtd_notifiers = NULL;
 
 /**
- *	add_mtd_device - register an MTD device
+ *	add_mtd_device_full - register an MTD device at a particular minor number
  *	@mtd: pointer to new MTD device info structure
+ *	@minor: requested minor number. -1 to for the first free.
  *
- *	Add a device to the list of MTD devices present in the system, and
- *	notify each currently active MTD 'user' of its arrival. Returns
- *	zero on success or 1 on failure, which currently will only happen
- *	if the number of present devices exceeds MAX_MTD_DEVICES (i.e. 16)
+ *	Add a device to the list of MTD devices present in the system,
+ *	and notifies each currently active MTD 'user' of its
+ *	arrival. Returns zero on success or 1 on failure, which
+ *	currently only occurs if the requested minor number has
+ *	already been allocated or if minor exceeds MAX_MTD_DEVICES
+ *	(i.e. 16)
  */
-
-int add_mtd_device(struct mtd_info *mtd)
+int add_mtd_device_full(struct mtd_info *mtd, int minor)
 {
-	int i;
+	struct mtd_notifier *not=mtd_notifiers;
 
 	down(&mtd_table_mutex);
 
-	for (i=0; i< MAX_MTD_DEVICES; i++)
-		if (!mtd_table[i])
-		{
-			struct mtd_notifier *not=mtd_notifiers;
+	if ( minor == -1 ) {
+		for (minor = 0; minor < MAX_MTD_DEVICES; minor++)
+			if (!mtd_table[minor])
+				break;
+	}
 
-			mtd_table[i] = mtd;
-			mtd->index = i;
-			DEBUG(0, "mtd: Giving out device %d to %s\n",i, mtd->name);
+	if ( minor >= MAX_MTD_DEVICES || minor < 0 || mtd_table[minor] ) {
+		up(&mtd_table_mutex);
+		return 1;
+	}
+
+	mtd_table[minor] = mtd;
+	mtd->index = minor;
+	DEBUG(0, "mtd: Giving out device %d to %s\n",minor, mtd->name);
 			while (not)
 			{
 				(*(not->add))(mtd);
@@ -62,8 +70,18 @@ int add_mtd_device(struct mtd_info *mtd)
 			return 0;
 		}
 	
-	up(&mtd_table_mutex);
-	return 1;
+/**
+ *	add_mtd_device - register an MTD device
+ *	@mtd: pointer to new MTD device info structure
+ *
+ *	Add a device to the list of MTD devices present in the system, and
+ *	notify each currently active MTD 'user' of its arrival. Returns
+ *	zero on success or 1 on failure, which currently will only happen
+ *	if the number of present devices exceeds MAX_MTD_DEVICES (i.e. 16)
+ */
+int add_mtd_device(struct mtd_info *mtd)
+{
+	return add_mtd_device(mtd, -1);
 }
 
 /**
Index: drivers//mtd/chips/map_ram.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/chips/map_ram.c,v
retrieving revision 1.14
diff -u -b -B -w -p -u -r1.14 map_ram.c
--- drivers//mtd/chips/map_ram.c	2 Oct 2001 15:05:12 -0000	1.14
+++ drivers//mtd/chips/map_ram.c	5 Feb 2003 11:25:52 -0000
@@ -107,6 +107,8 @@ static int mapram_erase (struct mtd_info
 	for (i=0; i<instr->len; i++)
 		map->write8(map, 0xFF, instr->addr + i);
 
+	instr->state = MTD_ERASE_DONE;
+
 	if (instr->callback)
 		instr->callback(instr);
 

                 reply	other threads:[~2003-02-05 11:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1044445351.12802.1558.camel@LinuxDev \
    --to=icampbell@arcom.com \
    --cc=linux-mtd@lists.infradead.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