no longer mark MTD_OBSOLETE_CHIPS as BROKEN and remove broken MTD_OBSOLETE_CHIPS drivers
PATCH 1/1 no longer mark MTD_OBSOLETE_CHIPS as BROKEN and remove broken MTD_OBSOLETE_CHIPS drivers
MTD_OBSOLETE_CHIPS shouldn't be marked as BROKEN.
This patch brings the MTD_SHARP driver back into life and removes the non-compiling MTD_AMDSTD and MTD_JEDEC with everything depending on them.
---
This patch was already sent on:
- 6 Jan 2006
- 13 Dec 2005
Due to it's size, the patch is attached gzip'ed.
arch/cris/arch-v10/drivers/Kconfig | 1 arch/cris/arch-v10/drivers/axisflashmap.c | 3 arch/cris/arch-v32/drivers/Kconfig | 1 arch/cris/arch-v32/drivers/axisflashmap.c | 3 drivers/mtd/chips/Kconfig | 22 drivers/mtd/chips/Makefile | 2 drivers/mtd/chips/amd_flash.c | 1403 ---------------------- drivers/mtd/chips/jedec.c | 935 -------------- drivers/mtd/maps/Kconfig | 18 drivers/mtd/maps/Makefile | 2 drivers/mtd/maps/octagon-5066.c | 248 --- drivers/mtd/maps/vmax301.c | 198 --- include/linux/mtd/jedec.h | 66 - 13 files changed, 1 insertion(+), 2901 deletions(-)
Quoted 3 lines · Adrian Bunk
This patch brings the
MTD_SHARPdriver back into life and removes the non-compilingMTD_AMDSTDandMTD_JEDECwith everything depending on them.
Please provide further background on your reasoning. I'll enumerate my questions to make it easy for you to answer each one fully.
1. Precisely when were these chip drivers marked obsolete?
2. What was the reason for marking them obsolete?
3. What are the factors which led you to conclude that _now_ is the time to actually remove them?
4. What are the factors which led you to _remove_ the map drivers which currently use the obsolete chip drivers, rather than taking the obvious alternative solution for those map drivers?
Signature · 1 line
dwmw2
Quoted 9 lines · David Woodhouse
Quoted 3 lines · Adrian Bunk
This patch brings the
MTD_SHARPdriver back into life and removes the non-compilingMTD_AMDSTDandMTD_JEDECwith everything depending on them.Please provide further background on your reasoning. I'll enumerate my questions to make it easy for you to answer each one fully.
1. Precisely when were these chip drivers marked obsolete?
Since kernel 2.4.11-pre4, released Thu, 4 Oct 2001 20:47:23 -0700.
Quoted 1 line
2. What was the reason for marking them obsolete?
The changelog says:
- David Woodhouse: large MTD and JFFS[2] update
Quoted 2 lines
3. What are the factors which led you to conclude that _now_ is the time to actually remove them?
http://lkml.org/lkml/2005/12/12/43
Quoted 3 lines
4. What are the factors which led you to _remove_ the map drivers which currently use the obsolete chip drivers, rather than taking the obvious alternative solution for those map drivers?
It seems that for one and a half years noone considered it a problem that they were no longer available...
Quoted 1 line
dwmw2
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 3 lines · Adrian Bunk
Quoted 1 line
1. Precisely when were these chip drivers marked obsolete?
Since kernel 2.4.11-pre4, released Thu, 4 Oct 2001 20:47:23 -0700.
Good. That's when they were first marked 'theoretically obsolete', at least. Now, when did they _actually_ become obsolete, and why?
Quoted 4 lines
Quoted 1 line
2. What was the reason for marking them obsolete?
The changelog says:
- David Woodhouse: large MTD and JFFS[2] update
I didn't ask who; I knew that. I asked you _why_. Admittedly, I happen to know that too - but I want to know if _you_ know it.
Since you've taken it upon yourself to decide the timescale of the removal, surely it's reasonable to expect that you do actually know what you're removing and why it's obsolescent?
Quoted 4 lines
Quoted 2 lines
3. What are the factors which led you to conclude that _now_ is the time to actually remove them?
That's also an insufficient answer. Why now? What are the factors you weighed up in favour of removal, and against it? I assume you gave it some serious consideration?
Quoted 6 lines
Quoted 3 lines
4. What are the factors which led you to _remove_ the map drivers which currently use the obsolete chip drivers, rather than taking the obvious alternative solution for those map drivers?
It seems that for one and a half years noone considered it a problem that they were no longer available...
Even if the chip drivers in question really been unavailable for that period of time, rather than merely hidden behind an extra config option -- people with embedded systems are often slow to update. That isn't really sufficient reason for removing those map drivers rather than taking the obvious alternative solution. You do know enough about the code you're changing to know what that alternative solution is, right?
Signature · 1 line
dwmw2
Quoted 6 lines · David Woodhouse
Quoted 5 lines
Quoted 2 lines
2. What was the reason for marking them obsolete?
The changelog says:
- David Woodhouse: large MTD and JFFS[2] update
Quoted 7 lines
I didn't ask who; I knew that. I asked you _why_. Admittedly, I happen to know that too - but I want to know if _you_ know it.
Since you've taken it upon yourself to decide the timescale of the removal, surely it's reasonable to expect that you do actually know what you're removing and why it's obsolescent?
Hey, Adrian isn't an MTD developer - give him a break.
What he's doing here is to poke other maintainers into getting the tree cleaned up. It's a useful thing to do.
If you, an MTD maintainer, can tell him what we _should_ be doing, I'm sure Adrian would help.
Quoted 1 line · Andrew Morton
Hey, Adrian isn't an MTD developer
Indeed he is not. And while his minor nitpicks can sometimes be worth the effort, it's less useful for him to start making value judgements about removing drivers which have _theoretically_ been replaced by new code, but which are actually still being used in some cases.
Quoted 2 lines
What he's doing here is to poke other maintainers into getting the tree cleaned up. It's a useful thing to do.
I know what needs doing to clean the tree up -- and removing the older chip drivers is very far from the top of my todo list. If you really want to accelerate their demise, add a #warning and a printk saying "You should no longer be using this driver -- try using jedec_probe or cfi_probe instead and contact the linux-mtd list if that fails".
Quoted 2 lines
If you, an MTD maintainer, can tell him what we _should_ be doing, I'm sure Adrian would help.
That would be much appreciated -- and _useful_. We need to add sysfs support to MTD devices, we need to revamp the way that the chip probe code hands off to the back-end chip drivers, and in doing so get rid of the use of inter_module_crap(), and we need to audit the module refcounting while we're at it.
I'm hoping I'll get a week or two some time soon to sit down and actually concentrate on that, because it's not something I can really pick at piecemeal and it wants proper testing. But if Adrian wants to have a go, that would be wonderful.
But picking away at what looks like low-hanging fruit without a real understanding of what's going on doesn't really help much.
Signature · 1 line
dwmw2
Quoted 7 lines · David Woodhouse
Quoted 1 line · Andrew Morton
Hey, Adrian isn't an MTD developer
Indeed he is not. And while his minor nitpicks can sometimes be worth the effort, it's less useful for him to start making value judgements about removing drivers which have _theoretically_ been replaced by new code, but which are actually still being used in some cases.
I interpreted your "or just removed" in [1] as your approval for a patch to remove the non-compiling drivers.
I'm not a native English speaker, and therefore I might have misunderstood your email.
What I want for 2.6.16 is to remove the wrong dependency of MTD_SHARP on BROKEN and the non-compiling drivers either still hidden under BROKEN or removed.
If there is any way I can submit a patch achieving this that would be acceptable for you simply tell how exactly you want this patch.
Quoted 9 lines
Quoted 2 lines
What he's doing here is to poke other maintainers into getting the tree cleaned up. It's a useful thing to do.
I know what needs doing to clean the tree up -- and removing the older chip drivers is very far from the top of my todo list. If you really want to accelerate their demise, add a #warning and a printk saying "You should no longer be using this driver -- try using
jedec_probeorcfi_probeinstead and contact the linux-mtd list if that fails".
...
We are talking about drivers marked as BROKEN for one and a half years that do no longer compile.
Quoted 1 line
dwmw2
cu
Adrian
[1] http://lkml.org/lkml/2005/12/12/43
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 6 lines · Adrian Bunk
What I want for 2.6.16 is to remove the wrong dependency of
MTD_SHARPon BROKEN and the non-compiling drivers either still hidden under BROKEN or removed.If there is any way I can submit a patch achieving this that would be acceptable for you simply tell how exactly you want this patch.
Remove the incorrect BROKEN dependency from MTD_OBSOLETE_CHIPS.
If you then want to add it again to any chip driver which really doesn't compile, feel free. But leave the map drivers alone. Those can be switched to use different chip back-ends.
Signature · 1 line
dwmw2
PATCH 1/1 no longer mark MTD_OBSOLETE_CHIPS as BROKEN
Quoted 5 lines · David Woodhouse
Quoted 4 lines · Adrian Bunk
What I want for 2.6.16 is to remove the wrong dependency of
MTD_SHARPon BROKEN and the non-compiling drivers either still hidden under BROKEN or removed.
Quoted 8 lines
Quoted 2 lines
If there is any way I can submit a patch achieving this that would be acceptable for you simply tell how exactly you want this patch.
Remove the incorrect BROKEN dependency from
MTD_OBSOLETE_CHIPS.If you then want to add it again to any chip driver which really doesn't compile, feel free. But leave the map drivers alone. Those can be switched to use different chip back-ends.
Patch below.
Quoted 1 line
dwmw2
cu
Adrian
<-- snip -->
This patch removes the wrong dependency of MTD_OBSOLETE_CHIPS on BROKEN and marks the non-compiling MTD_AMDSTD and MTD_JEDEC drivers as BROKEN.
---
drivers/mtd/chips/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mtd/chips/Kconfig renamed from drivers/mtd/chips/Kconfig.old +3 -3
@@ -260,7 +260,7 @@ with this driver will return -ENODEV upon access. config MTD_OBSOLETE_CHIPS - depends on MTD && BROKEN + depends on MTD bool "Older (theoretically obsoleted now) drivers for non-CFI chips" help This option does not enable any code directly, but will allow you to
@@ -273,7 +273,7 @@ config MTD_AMDSTD tristate "AMD compatible flash chip support (non-CFI)" - depends on MTD && MTD_OBSOLETE_CHIPS + depends on MTD && MTD_OBSOLETE_CHIPS && BROKEN help This option enables support for flash chips using AMD-compatible commands, including some which are not CFI-compatible and hence
@@ -291,7 +291,7 @@ config MTD_JEDEC tristate "JEDEC device support" - depends on MTD && MTD_OBSOLETE_CHIPS + depends on MTD && MTD_OBSOLETE_CHIPS && BROKEN help Enable older older JEDEC flash interface devices for self programming flash. It is commonly used in older AMD chips. It is
Re: [2.6 patch] no longer mark MTD_OBSOLETE_CHIPS as BROKEN
Quoted 2 lines · Adrian Bunk
This patch removes the wrong dependency of
MTD_OBSOLETE_CHIPSon BROKEN and marks the non-compilingMTD_AMDSTDandMTD_JEDECdrivers as BROKEN.
Looks better; thanks.
Quoted 1 line
Signed-off-by Adrian Bunk <[email protected]>
Signature · 1 line
dwmw2