Patchwork [2/2] Remove now-defunct ts7250 nand driver

login
register
mail settings
Submitter hartleys
Date Jan. 5, 2010, 9:59 p.m.
Message ID <201001051459.58621.hartleys@visionengravers.com>
Download mbox | patch
Permalink /patch/42218/
State New
Headers show

Comments

hartleys - Jan. 5, 2010, 9:59 p.m.
The ts72xx platform has been updated to use the generic platform nand
driver (plat_nand.c).  This removes the now-defunct ts7250.c nand driver.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Matthieu Crapet <mcrapet@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jesse Off <joff@embeddedARM.com>

---
David Woodhouse - Jan. 6, 2010, 1:31 p.m.
On Tue, 2010-01-05 at 14:59 -0700, H Hartley Sweeten wrote:
> The ts72xx platform has been updated to use the generic platform nand
> driver (plat_nand.c).  This removes the now-defunct ts7250.c nand driver.
> 
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Matthieu Crapet <mcrapet@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Jesse Off <joff@embeddedARM.com>

	Applying: mtd: Remove now-defunct ts7250 nand driver
	error: patch failed: drivers/mtd/nand/ts7250.c:1
	error: drivers/mtd/nand/ts7250.c: patch does not apply
	Patch failed at 0001 mtd: Remove now-defunct ts7250 nand driver

It looks like your patch has legacy garbage in it:

> - *   Copyright (C) 2004 Marius Gr<F6>ger (mag@sysgo.de)

It fails to apply because the ö (correctly represented as 0xc3 0xb6) has
been converted into a single byte 0xf6 in some legacy character set.

When applying patches, git-am does look at the Content-Type: header and
convert legacy crap into UTF-8 for the changelog, but it leaves the
patch itself alone.

Care to join us in the 21st century?
hartleys - Jan. 6, 2010, 5:26 p.m.
On Wednesday, January 06, 2010 6:32 AM, David Woodhouse wrote:
> On Tue, 2010-01-05 at 14:59 -0700, H Hartley Sweeten wrote:

>> The ts72xx platform has been updated to use the generic platform nand

>> driver (plat_nand.c).  This removes the now-defunct ts7250.c nand driver.

>> 

>> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>

>> Cc: Matthieu Crapet <mcrapet@gmail.com>

>> Cc: David Woodhouse <dwmw2@infradead.org>

>> Cc: Jesse Off <joff@embeddedARM.com>

>

>	Applying: mtd: Remove now-defunct ts7250 nand driver

>	error: patch failed: drivers/mtd/nand/ts7250.c:1

>	error: drivers/mtd/nand/ts7250.c: patch does not apply

>	Patch failed at 0001 mtd: Remove now-defunct ts7250 nand driver

>

> It looks like your patch has legacy garbage in it:

>

>> - *   Copyright (C) 2004 Marius Gr<F6>ger (mag@sysgo.de)

>

> It fails to apply because the ö (correctly represented as 0xc3 0xb6) has

> been converted into a single byte 0xf6 in some legacy character set.

>

> When applying patches, git-am does look at the Content-Type: header and

> convert legacy crap into UTF-8 for the changelog, but it leaves the

> patch itself alone.

>

> Care to join us in the 21st century?


Hello David,

Ok, that's really strange.  I just looked at the email I sent and that line
is:

- *   Copyright (C) 2004 Marius Gröger (mag@sysgo.de)

The character must have been converted as the message left my outbox.

Hmmmm.. What should my default character set be?  It looks like my mailer is
setup to use these (in this order):

us-ascii
iso-8859-1
utf-8 (locale)
utf-8

Sorry for the trouble.

Regards,
Hartley
David Woodhouse - Jan. 6, 2010, 5:42 p.m.
On Wed, 2010-01-06 at 12:26 -0500, H Hartley Sweeten wrote:
> Ok, that's really strange.  I just looked at the email I sent and that line
> is:
> 
> - *   Copyright (C) 2004 Marius Gröger (mag@sysgo.de)

Your previous email was in iso8859-1, a legacy charset that really has
no business being used this century. You can see the charset in its
Content-Type: header:
	Content-type: text/plain; charset="iso-8859-1"

The ö was therefore encoded as a single byte 0xf6. When we save the mail
to disk and apply it as a patch, that 0xf6 doesn't actually match what's
in the file you were patching -- and thus the patch didn't apply.

> The character must have been converted as the message left my outbox.

Probably, yes.

> Hmmmm.. What should my default character set be?  It looks like my mailer is
> setup to use these (in this order):

Did you change anything already? Although your older mail was iso8859-1,
the mail to which I'm replying now is different. It's:
	Content-type: text/plain; charset="utf-8"

So this time the ö is encoded as two bytes (0xc3, 0xb6) and _does_ match
what's in the kernel source files. If you'd included the patch in _this_
mail, it would have applied.

> us-ascii
> iso-8859-1
> utf-8 (locale)
> utf-8

It's iso-8859-1 which is causing the problem. Because your mail only
used characters which can be represented in iso8859-1, it got converted
to that. Drop iso8859-1 and it should be fine. ASCII is fine because
it's a subset of UTF-8. Any ASCII text is also valid UTF-8.
Jamie Lokier - Jan. 6, 2010, 6:07 p.m.
David Woodhouse wrote:
> It looks like your patch has legacy garbage in it:
> 
> > - *   Copyright (C) 2004 Marius Gr<F6>ger (mag@sysgo.de)
> 
> It fails to apply because the ö (correctly represented as 0xc3 0xb6) has
> been converted into a single byte 0xf6 in some legacy character set.
>
> When applying patches, git-am does look at the Content-Type: header and
> convert legacy crap into UTF-8 for the changelog, but it leaves the
> patch itself alone.

That's unfortunate.  An option to git-am or it's subsidiary tools to
convert the patch as well as the commit would be useful.  After all it
_is_ made clear in the MIME header how it's formatted.

> Care to join us in the 21st century?

You mean send the mail in UTF-8 format when it only contains
characters in ISO-8859-1?  To make that the default behaviour of an
email sender would possibly violate RFC2045, which as far as I can
tell is still the prevailing standard, which is I guess why Mutt does
not do that in its default configuration, and recodes the text from
UTF-8 to 8859-1 when it can.  That's what 21st century tools do :-)

I guess it's time for a "send-hook" to use a different setting
specially for Linux mailing lists.

Do you instead mean send the patch in UTF-8 embedded in a mail encoded
as 8859-1?  That sounds quite difficult, if the patch is inline rather
than attached.

An option to git-am to DTRT sounds infinitely better to me.  Shame
it's not there; unfortunately it doesn't emit enough information to
make it easy with a wrapper script.

What settings do you use to get this right?

Thanks,
-- Jamie
David Woodhouse - Jan. 6, 2010, 6:36 p.m.
On Wed, 2010-01-06 at 18:07 +0000, Jamie Lokier wrote:
> David Woodhouse wrote:
> > It looks like your patch has legacy garbage in it:
> > 
> > > - *   Copyright (C) 2004 Marius Gr<F6>ger (mag@sysgo.de)
> > 
> > It fails to apply because the ö (correctly represented as 0xc3 0xb6) has
> > been converted into a single byte 0xf6 in some legacy character set.
> >
> > When applying patches, git-am does look at the Content-Type: header and
> > convert legacy crap into UTF-8 for the changelog, but it leaves the
> > patch itself alone.
> 
> That's unfortunate.  An option to git-am or it's subsidiary tools to
> convert the patch as well as the commit would be useful.  After all it
> _is_ made clear in the MIME header how it's formatted.

ISTR there was some resistance to that suggestion when git-am was first
fixed to handle the Content-Type of mails. The idea was that the patch
should be considered sacrosanct and shouldn't be mangled.

Personally, I suspect you're right, and it should be converted too.

But I still think it's useful to discourage people from sending patches
in EBCDIC and other legacy crap.

> > Care to join us in the 21st century?
> 
> You mean send the mail in UTF-8 format when it only contains
> characters in ISO-8859-1?  To make that the default behaviour of an
> email sender would possibly violate RFC2045, 

Um, why? Can you point at the particular section you think would be
violated?

> Do you instead mean send the patch in UTF-8 embedded in a mail encoded
> as 8859-1?  That sounds quite difficult, if the patch is inline rather
> than attached.

God no. Just send UTF-8.

Would you advise that I send a mail as EBCDIC if it can fit into that?

> What settings do you use to get this right?

We've learned the hard way that marking text with encodings is
complicated and error-prone. The only viable option is to eliminate that
need as much as possible.

The rule is simplesimple -- just use UTF-8 everywhere, for everything.

Then the only time you have to deal with the issue of encodings is when
you're taking legacy crap in from people who don't follow that rule.
Nicolas Pitre - Jan. 6, 2010, 6:55 p.m.
On Wed, 6 Jan 2010, Jamie Lokier wrote:

> I guess it's time for a "send-hook" to use a different setting
> specially for Linux mailing lists.
> 
> Do you instead mean send the patch in UTF-8 embedded in a mail encoded
> as 8859-1?  That sounds quite difficult, if the patch is inline rather
> than attached.
> 
> An option to git-am to DTRT sounds infinitely better to me.  Shame
> it's not there; unfortunately it doesn't emit enough information to
> make it easy with a wrapper script.

I think your idea of enhancing git-am is really a good one, and I 
certainly encourage you to submit a patch to git.  The utility actually 
doing the work is git-mailinfo corresponding to builtin-mailinfo.c in 
the Git source tree.


Nicolas
Nicolas Pitre - Jan. 6, 2010, 7:01 p.m.
On Wed, 6 Jan 2010, David Woodhouse wrote:

> On Wed, 2010-01-06 at 18:07 +0000, Jamie Lokier wrote:
> > That's unfortunate.  An option to git-am or it's subsidiary tools to
> > convert the patch as well as the commit would be useful.  After all it
> > _is_ made clear in the MIME header how it's formatted.
> 
> ISTR there was some resistance to that suggestion when git-am was first
> fixed to handle the Content-Type of mails. The idea was that the patch
> should be considered sacrosanct and shouldn't be mangled.

Well, initially git-am was "fixed" by providing an option to allow 
normalization to UTF-8 of patch metadata.  Nowadays this option is the 
default.  So at least providing an option to convert the patch content 
as well might be perfectly sane.


Nicolas
Jamie Lokier - Jan. 6, 2010, 11:05 p.m.
Nicolas Pitre wrote:
> On Wed, 6 Jan 2010, Jamie Lokier wrote:
> 
> > I guess it's time for a "send-hook" to use a different setting
> > specially for Linux mailing lists.
> > 
> > Do you instead mean send the patch in UTF-8 embedded in a mail encoded
> > as 8859-1?  That sounds quite difficult, if the patch is inline rather
> > than attached.
> > 
> > An option to git-am to DTRT sounds infinitely better to me.  Shame
> > it's not there; unfortunately it doesn't emit enough information to
> > make it easy with a wrapper script.
> 
> I think your idea of enhancing git-am is really a good one, and I 
> certainly encourage you to submit a patch to git.  The utility actually 
> doing the work is git-mailinfo corresponding to builtin-mailinfo.c in 
> the Git source tree.

As I don't work with Git source and don't have enough time, I won't be
doing this, but I'd be delighted if someone else took the idea to the
Git people.  This thread could be used to explain why :-)

-- Jamie
David Woodhouse - Jan. 6, 2010, 11:08 p.m.
On Wed, 2010-01-06 at 23:05 +0000, Jamie Lokier wrote:
> As I don't work with Git source and don't have enough time, I won't be
> doing this, but I'd be delighted if someone else took the idea to the
> Git people.  This thread could be used to explain why :-) 

I won't be bothering -- I'm quite happy just telling people not to send
me legacy crap. There really is no justification for it, these days.
Jamie Lokier - Jan. 6, 2010, 11:21 p.m.
David Woodhouse wrote:
> > That's unfortunate.  An option to git-am or it's subsidiary tools to
> > convert the patch as well as the commit would be useful.  After all it
> > _is_ made clear in the MIME header how it's formatted.
> 
> ISTR there was some resistance to that suggestion when git-am was first
> fixed to handle the Content-Type of mails. The idea was that the patch
> should be considered sacrosanct and shouldn't be mangled.

Looks like they forgot mailers work with text, not preservation of
octets, and mailers mangle the octets in standardised ways, so a bit
of unmangling is needed on occasions.

> Personally, I suspect you're right, and it should be converted too.

It would need to optional for git users whose source code isn't UTF-8 -
possibly converting the other way for them.  But yeah I think it'd make
sense to be on by default.

> > > Care to join us in the 21st century?
> > 
> > You mean send the mail in UTF-8 format when it only contains
> > characters in ISO-8859-1?  To make that the default behaviour of an
> > email sender would possibly violate RFC2045, 
> 
> Um, why? Can you point at the particular section you think would be
> violated?

Section 4.1.2, Charset Parameter, final paragraph:

>>   In general, composition software should always use the "lowest common
>>   denominator" character set possible.  For example, if a body contains
>>   only US-ASCII characters, it SHOULD be marked as being in the US-
>>   ASCII character set, not ISO-8859-1, which, like all the ISO-8859
>>   family of character sets, is a superset of US-ASCII.  More generally,
>>   if a widely-used character set is a subset of another character set,
>>   and a body contains only characters in the widely-used subset, it
>>   should be labelled as being in that subset.  This will increase the
>>   chances that the recipient will be able to view the resulting entity
>>   correctly.

It's a SHOULD, but it's still a good idea.  ISO-8859-1 is still very
widely-used for email.

Also in that section:

>>    (1)   US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
>>
>>    (2)   ISO-8859-X -- where "X" is to be replaced, as
>>          necessary, for the parts of ISO-8859 [ISO-8859].  Note
>>          that the ISO 646 character sets have deliberately been
>>          omitted in favor of their 8859 replacements, which are
>>          the designated character sets for Internet mail.  As of
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>          the publication of this document, the legitimate values
>>          for "X" are the digits 1 through 10.

> Would you advise that I send a mail as EBCDIC if it can fit into that?

Obviously not - RFC2045 does not recommend that, so mailers don't do it
in their default configurations.  But they do recode text into the
lowest common charset that can represent the text.  In practice that
means no effect on ASCII, but does affect some non-ASCII characters.

Mutt out of the box tries us-ascii / iso-8859-1 / utf-8, in that order,
to maximise the chance of recipients being able to read the mail.  Even
on a fully 21st-century-ised Linux with UTF-8 terminals etc. :-) I don't
know what other mailers do, sorry, but I'd expect them to do the same.

-- Jamie
Jamie Lokier - Jan. 6, 2010, 11:27 p.m.
David Woodhouse wrote:
> On Wed, 2010-01-06 at 23:05 +0000, Jamie Lokier wrote:
> > As I don't work with Git source and don't have enough time, I won't be
> > doing this, but I'd be delighted if someone else took the idea to the
> > Git people.  This thread could be used to explain why :-) 
> 
> I won't be bothering -- I'm quite happy just telling people not to send
> me legacy crap. There really is no justification for it, these days.

I suggest mutt users put this in .muttrc to work around git's inconsistency:

   set send_charset="us-ascii:utf-8"

If that's not acceptable, one could always add a hook to grep for a
patch when sending to decide what to do :-)

-- Jamie
David Woodhouse - Jan. 6, 2010, 11:43 p.m.
On Wed, 2010-01-06 at 23:21 +0000, Jamie Lokier wrote:
> > Personally, I suspect you're right, and it should be converted too.
> 
> It would need to optional for git users whose source code isn't UTF-8 -
> possibly converting the other way for them.  But yeah I think it'd make
> sense to be on by default.

It's silly to talk of 'converting the other way'. The tool converts from
the charset of the email, to the charset that the git repository is
configured for (which is UTF-8 by default and in all sane cases).

Why would you want to convert the other way?

It is currently optional, but I suspect that's the wrong approach. The
only reason you'd ever want that is if the mail it's interpreting is
mislabelled -- and in that case surely the best workaround is an option
which lets you override the Content-Type: header, not just disable the
charset conversion altogether. Obviously if you override the input
charset to be equal to your repository configuration, that means that no
conversion is done. But that's just a fairly unimportant special case of
the override, surely?

> Section 4.1.2, Charset Parameter, final paragraph:
> 
> >>   In general, composition software should always use the "lowest common
> >>   denominator" character set possible.  For example, if a body contains
> >>   only US-ASCII characters, it SHOULD be marked as being in the US-
> >>   ASCII character set, not ISO-8859-1, which, like all the ISO-8859
> >>   family of character sets, is a superset of US-ASCII.  More generally,
> >>   if a widely-used character set is a subset of another character set,
> >>   and a body contains only characters in the widely-used subset, it
> >>   should be labelled as being in that subset.  This will increase the
> >>   chances that the recipient will be able to view the resulting entity
> >>   correctly.
> 
> It's a SHOULD, but it's still a good idea.  ISO-8859-1 is still very
> widely-used for email.

That might have made sense 13 years ago, but today I would suggest that
we ought to be applying a general principle that UTF-8 SHOULD be used
everywhere.

By doing so, we mostly sidestep the need for the whole charset labelling
and conversion clusterfuck that nobody ever quite managed to get right
anyway. If everything on the system is UTF-8, all the time, then it
doesn't _matter_ that nobody ever really managed to get labelling to
work.

>From RFC2119:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

I understand the full implications of not using legacy character sets,
and have carefully weighed them before choosing to send UTF-8.

What's the down-side? That some Luddite out there might have a system
which _still_ can't render UTF-8 email in 2010, so they're only seeing
the 99.999% of the email which is readable as ASCII?
David Woodhouse - Jan. 6, 2010, 11:50 p.m.
On Wed, 2010-01-06 at 23:27 +0000, Jamie Lokier wrote:
> I suggest mutt users put this in .muttrc to work around git's
> inconsistency:
> 
>    set send_charset="us-ascii:utf-8"

I would also suggest that mutt users do that. And if it isn't the
default on the distribution you're using, then file a bug.

Patch

diff --git a/arch/arm/mach-ep93xx/include/mach/ts72xx.h b/arch/arm/mach-ep93xx/include/mach/ts72xx.h
index 3bd934e..61c0e13 100644
--- a/arch/arm/mach-ep93xx/include/mach/ts72xx.h
+++ b/arch/arm/mach-ep93xx/include/mach/ts72xx.h
@@ -9,9 +9,6 @@ 
  * febff000	22000000	4K	model number register
  * febfe000	22400000	4K	options register
  * febfd000	22800000	4K	options register #2
- * febfc000	[67]0000000	4K	NAND data register
- * febfb000	[67]0400000	4K	NAND control register
- * febfa000	[67]0800000	4K	NAND busy register
  * febf9000	10800000	4K	TS-5620 RTC index register
  * febf8000	11700000	4K	TS-5620 RTC data register
  */
@@ -41,22 +38,6 @@ 
 #define TS72XX_OPTIONS2_TS9420_BOOT	0x02
 
 
-#define TS72XX_NAND1_DATA_PHYS_BASE	0x60000000
-#define TS72XX_NAND2_DATA_PHYS_BASE	0x70000000
-#define TS72XX_NAND_DATA_VIRT_BASE	0xfebfc000
-#define TS72XX_NAND_DATA_SIZE		0x00001000
-
-#define TS72XX_NAND1_CONTROL_PHYS_BASE	0x60400000
-#define TS72XX_NAND2_CONTROL_PHYS_BASE	0x70400000
-#define TS72XX_NAND_CONTROL_VIRT_BASE	0xfebfb000
-#define TS72XX_NAND_CONTROL_SIZE	0x00001000
-
-#define TS72XX_NAND1_BUSY_PHYS_BASE	0x60800000
-#define TS72XX_NAND2_BUSY_PHYS_BASE	0x70800000
-#define TS72XX_NAND_BUSY_VIRT_BASE	0xfebfa000
-#define TS72XX_NAND_BUSY_SIZE		0x00001000
-
-
 #define TS72XX_RTC_INDEX_VIRT_BASE	0xfebf9000
 #define TS72XX_RTC_INDEX_PHYS_BASE	0x10800000
 #define TS72XX_RTC_INDEX_SIZE		0x00001000
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 677cd53..48c727f 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -95,12 +95,6 @@  config MTD_NAND_OMAP_PREFETCH_DMA
 	 or in DMA interrupt mode.
 	 Say y for DMA mode or MPU mode will be used
 
-config MTD_NAND_TS7250
-	tristate "NAND Flash device on TS-7250 board"
-	depends on MACH_TS72XX
-	help
-	  Support for NAND flash on Technologic Systems TS-7250 platform.
-
 config MTD_NAND_IDS
 	tristate
 
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1407bd1..fedf10d 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -19,7 +19,6 @@  obj-$(CONFIG_MTD_NAND_DISKONCHIP)	+= diskonchip.o
 obj-$(CONFIG_MTD_NAND_H1900)		+= h1910.o
 obj-$(CONFIG_MTD_NAND_RTC_FROM4)	+= rtc_from4.o
 obj-$(CONFIG_MTD_NAND_SHARPSL)		+= sharpsl.o
-obj-$(CONFIG_MTD_NAND_TS7250)		+= ts7250.o
 obj-$(CONFIG_MTD_NAND_NANDSIM)		+= nandsim.o
 obj-$(CONFIG_MTD_NAND_CS553X)		+= cs553x_nand.o
 obj-$(CONFIG_MTD_NAND_NDFC)		+= ndfc.o
diff --git a/drivers/mtd/nand/ts7250.c b/drivers/mtd/nand/ts7250.c
deleted file mode 100644
index 0f5562a..0000000
--- a/drivers/mtd/nand/ts7250.c
+++ /dev/null
@@ -1,207 +0,0 @@ 
-/*
- * drivers/mtd/nand/ts7250.c
- *
- * Copyright (C) 2004 Technologic Systems (support@embeddedARM.com)
- *
- * Derived from drivers/mtd/nand/edb7312.c
- *   Copyright (C) 2004 Marius Gröger (mag@sysgo.de)
- *
- * Derived from drivers/mtd/nand/autcpu12.c
- *   Copyright (c) 2001 Thomas Gleixner (gleixner@autronix.de)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * Overview:
- *   This is a device driver for the NAND flash device found on the
- *   TS-7250 board which utilizes a Samsung 32 Mbyte part.
- */
-
-#include <linux/slab.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/nand.h>
-#include <linux/mtd/partitions.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <mach/ts72xx.h>
-
-#include <asm/sizes.h>
-#include <asm/mach-types.h>
-
-/*
- * MTD structure for TS7250 board
- */
-static struct mtd_info *ts7250_mtd = NULL;
-
-#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probes[] = { "cmdlinepart", NULL };
-
-#define NUM_PARTITIONS 3
-
-/*
- * Define static partitions for flash device
- */
-static struct mtd_partition partition_info32[] = {
-	{
-		.name		= "TS-BOOTROM",
-		.offset		= 0x00000000,
-		.size		= 0x00004000,
-	}, {
-		.name		= "Linux",
-		.offset		= 0x00004000,
-		.size		= 0x01d00000,
-	}, {
-		.name		= "RedBoot",
-		.offset		= 0x01d04000,
-		.size		= 0x002fc000,
-	},
-};
-
-/*
- * Define static partitions for flash device
- */
-static struct mtd_partition partition_info128[] = {
-	{
-		.name		= "TS-BOOTROM",
-		.offset		= 0x00000000,
-		.size		= 0x00004000,
-	}, {
-		.name		= "Linux",
-		.offset		= 0x00004000,
-		.size		= 0x07d00000,
-	}, {
-		.name		= "RedBoot",
-		.offset		= 0x07d04000,
-		.size		= 0x002fc000,
-	},
-};
-#endif
-
-
-/*
- *	hardware specific access to control-lines
- *
- *	ctrl:
- *	NAND_NCE: bit 0 -> bit 2
- *	NAND_CLE: bit 1 -> bit 1
- *	NAND_ALE: bit 2 -> bit 0
- */
-static void ts7250_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
-{
-	struct nand_chip *chip = mtd->priv;
-
-	if (ctrl & NAND_CTRL_CHANGE) {
-		unsigned long addr = TS72XX_NAND_CONTROL_VIRT_BASE;
-		unsigned char bits;
-
-		bits = (ctrl & NAND_NCE) << 2;
-		bits |= ctrl & NAND_CLE;
-		bits |= (ctrl & NAND_ALE) >> 2;
-
-		__raw_writeb((__raw_readb(addr) & ~0x7) | bits, addr);
-	}
-
-	if (cmd != NAND_CMD_NONE)
-		writeb(cmd, chip->IO_ADDR_W);
-}
-
-/*
- *	read device ready pin
- */
-static int ts7250_device_ready(struct mtd_info *mtd)
-{
-	return __raw_readb(TS72XX_NAND_BUSY_VIRT_BASE) & 0x20;
-}
-
-/*
- * Main initialization routine
- */
-static int __init ts7250_init(void)
-{
-	struct nand_chip *this;
-	const char *part_type = 0;
-	int mtd_parts_nb = 0;
-	struct mtd_partition *mtd_parts = 0;
-
-	if (!machine_is_ts72xx() || board_is_ts7200())
-		return -ENXIO;
-
-	/* Allocate memory for MTD device structure and private data */
-	ts7250_mtd = kmalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), GFP_KERNEL);
-	if (!ts7250_mtd) {
-		printk("Unable to allocate TS7250 NAND MTD device structure.\n");
-		return -ENOMEM;
-	}
-
-	/* Get pointer to private data */
-	this = (struct nand_chip *)(&ts7250_mtd[1]);
-
-	/* Initialize structures */
-	memset(ts7250_mtd, 0, sizeof(struct mtd_info));
-	memset(this, 0, sizeof(struct nand_chip));
-
-	/* Link the private data with the MTD structure */
-	ts7250_mtd->priv = this;
-	ts7250_mtd->owner = THIS_MODULE;
-
-	/* insert callbacks */
-	this->IO_ADDR_R = (void *)TS72XX_NAND_DATA_VIRT_BASE;
-	this->IO_ADDR_W = (void *)TS72XX_NAND_DATA_VIRT_BASE;
-	this->cmd_ctrl = ts7250_hwcontrol;
-	this->dev_ready = ts7250_device_ready;
-	this->chip_delay = 15;
-	this->ecc.mode = NAND_ECC_SOFT;
-
-	printk("Searching for NAND flash...\n");
-	/* Scan to find existence of the device */
-	if (nand_scan(ts7250_mtd, 1)) {
-		kfree(ts7250_mtd);
-		return -ENXIO;
-	}
-#ifdef CONFIG_MTD_PARTITIONS
-	ts7250_mtd->name = "ts7250-nand";
-	mtd_parts_nb = parse_mtd_partitions(ts7250_mtd, part_probes, &mtd_parts, 0);
-	if (mtd_parts_nb > 0)
-		part_type = "command line";
-	else
-		mtd_parts_nb = 0;
-#endif
-	if (mtd_parts_nb == 0) {
-		mtd_parts = partition_info32;
-		if (ts7250_mtd->size >= (128 * 0x100000))
-			mtd_parts = partition_info128;
-		mtd_parts_nb = NUM_PARTITIONS;
-		part_type = "static";
-	}
-
-	/* Register the partitions */
-	printk(KERN_NOTICE "Using %s partition definition\n", part_type);
-	add_mtd_partitions(ts7250_mtd, mtd_parts, mtd_parts_nb);
-
-	/* Return happy */
-	return 0;
-}
-
-module_init(ts7250_init);
-
-/*
- * Clean up routine
- */
-static void __exit ts7250_cleanup(void)
-{
-	/* Unregister the device */
-	del_mtd_device(ts7250_mtd);
-
-	/* Free the MTD device structure */
-	kfree(ts7250_mtd);
-}
-
-module_exit(ts7250_cleanup);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Jesse Off <joff@embeddedARM.com>");
-MODULE_DESCRIPTION("MTD map driver for Technologic Systems TS-7250 board");