Remove now-defunct ts7250 nand driver

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.

---

index 3bd934e..61c0e13 100644
@@ -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

index 677cd53..48c727f 100644
@@ -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
 

index 1407bd1..fedf10d 100644
@@ -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

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:

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?

David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

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 at 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

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.

Probably, yes.

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.

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.

dwmw2

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.

---

Repost due to iso8859-1 UTF-8 issues.

index 3bd934e..61c0e13 100644
@@ -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

index 677cd53..48c727f 100644
@@ -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
?

index 1407bd1..fedf10d 100644
@@ -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

Hello David,

Do you know the status of these two patches in linux-next:

commit 7603757993e7ce3e63b2280ccf61d8058b7b2414

Author: H Hartley Sweeten <[email protected]>
Date:   Tue Jan 5 14:59:58 2010 -0700

mtd: Remove now-defunct ts7250 nand driver

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.

commit 030d2dd450a628b7a8e31e980af3d05854f68edb

Author: H Hartley Sweeten <[email protected]>
Date:   Tue Jan 5 14:59:56 2010 -0700

mtd: Update ep93xx/ts72xx to use generic platform nand driver

Update the ts72xx platform's nand driver support.

This changes the ts72xx platform from using a custom nand driver (ts7250.c) to the generic platform nand driver (plat_nand.c).

Tested on TS-7250 with 32MiB NAND.

I have some pending patches for arch/arm/mach-ep93xx/ts72xx.c that depend on these.

Thanks,
Hartley

I'm not David, but I think I know the answer. Last merge window was missed and the mtd tree was not merged, so the patches are waiting for the next merge window and will be merged.

[snip]

Just send your depending patches.

Best Regards,
Artem Bityutskiy (????? ????????)

Hello Artem,

Ah, thought that was the issue. It did appear that the mtd tree didn't get merged.

I'll hold until this gets merged (or dropped if that happens).

The patches are intended for the arm tree and I want to avoid any merge issues.

Thanks for the update,
Hartley

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.

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

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.

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

God no. Just send UTF-8.

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

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.

dwmw2

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

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.

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.

Section 4.1.2, Charset Parameter, final paragraph:

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:

            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

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?

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.

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?

dwmw2

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

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

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.

dwmw2

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

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.

dwmw2