| Message ID | 201001051459.58621.hartleys@visionengravers.com |
|---|---|
| State | Accepted |
| Commit | 7603757993e7ce3e63b2280ccf61d8058b7b2414 |
| Headers | show |
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?
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
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.
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
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.
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
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
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
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.
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
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
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?
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.
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");
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> ---