* [PATCH] allow use of mtd and jffs2 on uml [not found] <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com> @ 2007-10-24 1:17 ` Jason Lunz 2007-10-24 6:51 ` David Woodhouse 0 siblings, 1 reply; 63+ messages in thread From: Jason Lunz @ 2007-10-24 1:17 UTC (permalink / raw) To: atom ota; +Cc: linux-mtd, Jeff Dike, David Woodhouse, uml-user In gmane.linux.uml.user, you wrote: > I need to do some experiments with JFFS2 on a recent Linux kernel (2.6.22.6) > and was hoping to use UML, with block2mtd or nandsim as my MTD, but either > MTD configuration and consequently JFFS2 configuration isn't available in > "make ARCH=um menuconfig", or I just can't find it. > > I've searched Google and the list archive and it looks like JFFS2 worked > with UML in the past, but maybe something has changed. > > Is it possible to configure a UML kernel to support JFFS2? If so, how? The patch below makes it work. It's crude and I make no excuses for it, but it does let jffs2-on-block2mtd work on uml without problems. I think the addition of CONFIG_MTD_CHIPREG is an ugly hack in particular, and improperly done at that (it stays off for !UML, I think). But it should get you going. Maybe this could serve as a basis for something mergable. It applies to 2.6.23; with some wiggling it works on earlier versions too. Signed-off-by: Jason Lunz <lunz@falooley.org> --- arch/um/Kconfig | 4 +--- drivers/mtd/Kconfig | 12 +++++++----- drivers/mtd/chips/Kconfig | 11 ++++++++--- drivers/mtd/devices/Kconfig | 7 +++++++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate "Uncached system RAM" + depends on !UML help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate "Physical system RAM" + depends on !UML help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if !UML comment "Disk-On-Chip Device Drivers" +endif config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" + depends on !UML select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" + depends on !UML select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate "M-Systems Disk-On-Chip Millennium Plus" + depends on !UML select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -280,13 +279,16 @@ source "drivers/mtd/chips/Kconfig" -source "drivers/mtd/maps/Kconfig" +if !UML + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if !UML + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/ubi/Kconfig" Index: linux-2.6.23.1-uml/drivers/mtd/chips/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/chips/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/chips/Kconfig @@ -3,8 +3,13 @@ menu "RAM/ROM/Flash chip drivers" depends on MTD!=n +config MTD_CHIPREG + bool + depends on !UML + config MTD_CFI tristate "Detect flash chips by Common Flash Interface (CFI) probe" + depends on !UML select MTD_GEN_PROBE help The Common Flash Interface specification was developed by Intel, @@ -16,6 +21,7 @@ config MTD_JEDECPROBE tristate "Detect non-CFI AMD/JEDEC-compatible flash chips" + depends on !UML select MTD_GEN_PROBE help This option enables JEDEC-style probing of flash chips which are not @@ -178,7 +184,7 @@ config MTD_CFI_INTELEXT tristate "Support for Intel/Sharp flash chips" - depends on MTD_GEN_PROBE + depends on MTD_GEN_PROBE && !UML select MTD_CFI_UTIL help The Common Flash Interface defines a number of different command @@ -188,7 +194,7 @@ config MTD_CFI_AMDSTD tristate "Support for AMD/Fujitsu flash chips" - depends on MTD_GEN_PROBE + depends on MTD_GEN_PROBE && !UML select MTD_CFI_UTIL help The Common Flash Interface defines a number of different command @@ -198,7 +204,7 @@ config MTD_CFI_STAA tristate "Support for ST (Advanced Architecture) flash chips" - depends on MTD_GEN_PROBE + depends on MTD_GEN_PROBE && !UML select MTD_CFI_UTIL help The Common Flash Interface defines a number of different command @@ -210,18 +216,21 @@ config MTD_RAM tristate "Support for RAM chips in bus mapping" + depends on !UML help This option enables basic support for RAM chips accessed through a bus mapping driver. config MTD_ROM tristate "Support for ROM chips in bus mapping" + depends on !UML help This option enables basic support for ROM chips accessed through a bus mapping driver. config MTD_ABSENT tristate "Support for absent chips in bus mapping" + depends on !UML help This option enables support for a dummy probing driver used to allocated placeholder MTD devices on systems that have socketed Index: linux-2.6.23.1-uml/drivers/mtd/chips/Makefile =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/chips/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/chips/Makefile @@ -2,7 +2,7 @@ # linux/drivers/chips/Makefile # -obj-$(CONFIG_MTD) += chipreg.o +obj-$(CONFIG_MTD_CHIPREG) += chipreg.o obj-$(CONFIG_MTD_CFI) += cfi_probe.o obj-$(CONFIG_MTD_CFI_UTIL) += cfi_util.o obj-$(CONFIG_MTD_CFI_STAA) += cfi_cmdset_0020.o ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] allow use of mtd and jffs2 on uml 2007-10-24 1:17 ` [PATCH] allow use of mtd and jffs2 on uml Jason Lunz @ 2007-10-24 6:51 ` David Woodhouse 2007-10-24 15:54 ` Jason Lunz 2007-12-27 18:15 ` [uml-devel] " Jason Lunz 0 siblings, 2 replies; 63+ messages in thread From: David Woodhouse @ 2007-10-24 6:51 UTC (permalink / raw) To: Jason Lunz; +Cc: atom ota, Jeff Dike, linux-mtd, uml-user On Tue, 2007-10-23 at 18:17 -0700, Jason Lunz wrote: > > The patch below makes it work. It's crude and I make no excuses for > it, > but it does let jffs2-on-block2mtd work on uml without problems. > > I think the addition of CONFIG_MTD_CHIPREG is an ugly hack in > particular, and improperly done at that (it stays off for !UML, I > think). Why build anything in chips/ or maps/ ? We should make sure mtdram, nandsim and onenandsim are all buildable too. -- dwmw2 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] allow use of mtd and jffs2 on uml 2007-10-24 6:51 ` David Woodhouse @ 2007-10-24 15:54 ` Jason Lunz 2007-12-27 18:15 ` [uml-devel] " Jason Lunz 1 sibling, 0 replies; 63+ messages in thread From: Jason Lunz @ 2007-10-24 15:54 UTC (permalink / raw) To: David Woodhouse; +Cc: atom ota, Jeff Dike, linux-mtd, lkml, uml-user Push the "depends on HAS_IOMEM" in mtd down closer to the parts that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@falooley.org> --- On Wed, Oct 24, 2007 at 07:51:29AM +0100, David Woodhouse wrote: > Why build anything in chips/ or maps/ ? Did I mention it was crude? :) I followed your suggestion, and this version is much cleaner. > We should make sure mtdram, nandsim and onenandsim are all buildable > too. I wanted to keep this a pure kbuild change. Getting nand and onenand to build for uml would involve making them not use readb and friends, or getting uml to provide stub versions. arch/um/Kconfig | 4 +--- drivers/mtd/Kconfig | 12 +++++++----- drivers/mtd/chips/Kconfig | 11 ++++++++--- drivers/mtd/devices/Kconfig | 7 +++++++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" +endif config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate "M-Systems Disk-On-Chip Millennium Plus" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source "drivers/mtd/chips/Kconfig" -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/ubi/Kconfig" Index: linux-2.6.23.1-uml/drivers/mtd/Makefile =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] allow use of mtd and jffs2 on uml @ 2007-10-24 15:54 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2007-10-24 15:54 UTC (permalink / raw) To: David Woodhouse; +Cc: atom ota, Jeff Dike, uml-user, linux-mtd, lkml Push the "depends on HAS_IOMEM" in mtd down closer to the parts that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@falooley.org> --- On Wed, Oct 24, 2007 at 07:51:29AM +0100, David Woodhouse wrote: > Why build anything in chips/ or maps/ ? Did I mention it was crude? :) I followed your suggestion, and this version is much cleaner. > We should make sure mtdram, nandsim and onenandsim are all buildable > too. I wanted to keep this a pure kbuild change. Getting nand and onenand to build for uml would involve making them not use readb and friends, or getting uml to provide stub versions. arch/um/Kconfig | 4 +--- drivers/mtd/Kconfig | 12 +++++++----- drivers/mtd/chips/Kconfig | 11 ++++++++--- drivers/mtd/devices/Kconfig | 7 +++++++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" +endif config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate "M-Systems Disk-On-Chip Millennium Plus" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source "drivers/mtd/chips/Kconfig" -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/ubi/Kconfig" Index: linux-2.6.23.1-uml/drivers/mtd/Makefile =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] allow use of mtd and jffs2 on uml 2007-10-24 15:54 ` Jason Lunz @ 2007-10-24 16:24 ` atom ota -1 siblings, 0 replies; 63+ messages in thread From: atom ota @ 2007-10-24 16:24 UTC (permalink / raw) To: Jason Lunz; +Cc: linux-mtd, Jeff Dike, David Woodhouse, lkml, uml-user I'm not sure how to follow the "push ... down" instructions. I used your patch to build UML and jffs2 ran fine with block2mtd using a file attached to /dev/ubdb. Too bad about nandsim though. Tom On 10/24/07, Jason Lunz <lunz@falooley.org> wrote: > > Push the "depends on HAS_IOMEM" in mtd down closer to the parts that > actually need it. This allows enough of mtd to build to let jffs2 be > used on uml. > > Signed-off-by: Jason Lunz <lunz@falooley.org> > > --- > > On Wed, Oct 24, 2007 at 07:51:29AM +0100, David Woodhouse wrote: > > Why build anything in chips/ or maps/ ? > > Did I mention it was crude? :) I followed your suggestion, and this > version is much cleaner. > > > We should make sure mtdram, nandsim and onenandsim are all buildable > > too. > > I wanted to keep this a pure kbuild change. Getting nand and onenand to > build for uml would involve making them not use readb and friends, or > getting uml to provide stub versions. > > > arch/um/Kconfig | 4 +--- > drivers/mtd/Kconfig | 12 +++++++----- > drivers/mtd/chips/Kconfig | 11 ++++++++--- > drivers/mtd/devices/Kconfig | 7 +++++++ > 4 files changed, 23 insertions(+), 11 deletions(-) > > Index: linux-2.6.23.1-uml/arch/um/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/arch/um/Kconfig > +++ linux-2.6.23.1-uml/arch/um/Kconfig > @@ -326,9 +326,7 @@ > > source "drivers/md/Kconfig" > > -if BROKEN > - source "drivers/mtd/Kconfig" > -endif > +source "drivers/mtd/Kconfig" > > #This is just to shut up some Kconfig warnings, so no prompt. > config INPUT > Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > @@ -78,6 +78,7 @@ > > config MTD_SLRAM > tristate "Uncached system RAM" > + depends on HAS_IOMEM > help > If your CPU cannot cache all of the physical memory in your machine, > you can still use it for storage or swap by using this driver to > @@ -85,6 +86,7 @@ > > config MTD_PHRAM > tristate "Physical system RAM" > + depends on HAS_IOMEM > help > This is a re-implementation of the slram driver above. > > @@ -151,10 +153,13 @@ > Testing MTD users (eg JFFS2) on large media and media that might > be removed during a write (using the floppy drive). > > +if HAS_IOMEM > comment "Disk-On-Chip Device Drivers" > +endif > > config MTD_DOC2000 > tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -177,6 +182,7 @@ > > config MTD_DOC2001 > tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -198,6 +204,7 @@ > > config MTD_DOC2001PLUS > tristate "M-Systems Disk-On-Chip Millennium Plus" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig > @@ -2,7 +2,6 @@ > > menuconfig MTD > tristate "Memory Technology Device (MTD) support" > - depends on HAS_IOMEM > help > Memory Technology Devices are flash, RAM and similar chips, often > used for solid state file systems on embedded devices. This option > @@ -278,15 +277,18 @@ > This enables read only access to SmartMedia formatted NAND > flash. You can mount it with FAT file system. > > -source "drivers/mtd/chips/Kconfig" > > -source "drivers/mtd/maps/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/chips/Kconfig" > + source "drivers/mtd/maps/Kconfig" > +endif > > source "drivers/mtd/devices/Kconfig" > > -source "drivers/mtd/nand/Kconfig" > - > -source "drivers/mtd/onenand/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/nand/Kconfig" > + source "drivers/mtd/onenand/Kconfig" > +endif > > source "drivers/mtd/ubi/Kconfig" > > Index: linux-2.6.23.1-uml/drivers/mtd/Makefile > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile > +++ linux-2.6.23.1-uml/drivers/mtd/Makefile > @@ -26,6 +26,9 @@ > nftl-objs := nftlcore.o nftlmount.o > inftl-objs := inftlcore.o inftlmount.o > > -obj-y += chips/ maps/ devices/ nand/ onenand/ > +obj-y += devices/ > +ifdef CONFIG_HAS_IOMEM > +obj-y += chips/ maps/ nand/ onenand/ > +endif > > obj-$(CONFIG_MTD_UBI) += ubi/ > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] allow use of mtd and jffs2 on uml @ 2007-10-24 16:24 ` atom ota 0 siblings, 0 replies; 63+ messages in thread From: atom ota @ 2007-10-24 16:24 UTC (permalink / raw) To: Jason Lunz; +Cc: David Woodhouse, Jeff Dike, uml-user, linux-mtd, lkml I'm not sure how to follow the "push ... down" instructions. I used your patch to build UML and jffs2 ran fine with block2mtd using a file attached to /dev/ubdb. Too bad about nandsim though. Tom On 10/24/07, Jason Lunz <lunz@falooley.org> wrote: > > Push the "depends on HAS_IOMEM" in mtd down closer to the parts that > actually need it. This allows enough of mtd to build to let jffs2 be > used on uml. > > Signed-off-by: Jason Lunz <lunz@falooley.org> > > --- > > On Wed, Oct 24, 2007 at 07:51:29AM +0100, David Woodhouse wrote: > > Why build anything in chips/ or maps/ ? > > Did I mention it was crude? :) I followed your suggestion, and this > version is much cleaner. > > > We should make sure mtdram, nandsim and onenandsim are all buildable > > too. > > I wanted to keep this a pure kbuild change. Getting nand and onenand to > build for uml would involve making them not use readb and friends, or > getting uml to provide stub versions. > > > arch/um/Kconfig | 4 +--- > drivers/mtd/Kconfig | 12 +++++++----- > drivers/mtd/chips/Kconfig | 11 ++++++++--- > drivers/mtd/devices/Kconfig | 7 +++++++ > 4 files changed, 23 insertions(+), 11 deletions(-) > > Index: linux-2.6.23.1-uml/arch/um/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/arch/um/Kconfig > +++ linux-2.6.23.1-uml/arch/um/Kconfig > @@ -326,9 +326,7 @@ > > source "drivers/md/Kconfig" > > -if BROKEN > - source "drivers/mtd/Kconfig" > -endif > +source "drivers/mtd/Kconfig" > > #This is just to shut up some Kconfig warnings, so no prompt. > config INPUT > Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > @@ -78,6 +78,7 @@ > > config MTD_SLRAM > tristate "Uncached system RAM" > + depends on HAS_IOMEM > help > If your CPU cannot cache all of the physical memory in your machine, > you can still use it for storage or swap by using this driver to > @@ -85,6 +86,7 @@ > > config MTD_PHRAM > tristate "Physical system RAM" > + depends on HAS_IOMEM > help > This is a re-implementation of the slram driver above. > > @@ -151,10 +153,13 @@ > Testing MTD users (eg JFFS2) on large media and media that might > be removed during a write (using the floppy drive). > > +if HAS_IOMEM > comment "Disk-On-Chip Device Drivers" > +endif > > config MTD_DOC2000 > tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -177,6 +182,7 @@ > > config MTD_DOC2001 > tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -198,6 +204,7 @@ > > config MTD_DOC2001PLUS > tristate "M-Systems Disk-On-Chip Millennium Plus" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig > @@ -2,7 +2,6 @@ > > menuconfig MTD > tristate "Memory Technology Device (MTD) support" > - depends on HAS_IOMEM > help > Memory Technology Devices are flash, RAM and similar chips, often > used for solid state file systems on embedded devices. This option > @@ -278,15 +277,18 @@ > This enables read only access to SmartMedia formatted NAND > flash. You can mount it with FAT file system. > > -source "drivers/mtd/chips/Kconfig" > > -source "drivers/mtd/maps/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/chips/Kconfig" > + source "drivers/mtd/maps/Kconfig" > +endif > > source "drivers/mtd/devices/Kconfig" > > -source "drivers/mtd/nand/Kconfig" > - > -source "drivers/mtd/onenand/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/nand/Kconfig" > + source "drivers/mtd/onenand/Kconfig" > +endif > > source "drivers/mtd/ubi/Kconfig" > > Index: linux-2.6.23.1-uml/drivers/mtd/Makefile > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile > +++ linux-2.6.23.1-uml/drivers/mtd/Makefile > @@ -26,6 +26,9 @@ > nftl-objs := nftlcore.o nftlmount.o > inftl-objs := inftlcore.o inftlmount.o > > -obj-y += chips/ maps/ devices/ nand/ onenand/ > +obj-y += devices/ > +ifdef CONFIG_HAS_IOMEM > +obj-y += chips/ maps/ nand/ onenand/ > +endif > > obj-$(CONFIG_MTD_UBI) += ubi/ > ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH] allow use of mtd and jffs2 on uml 2007-10-24 6:51 ` David Woodhouse 2007-10-24 15:54 ` Jason Lunz @ 2007-12-27 18:15 ` Jason Lunz 1 sibling, 0 replies; 63+ messages in thread From: Jason Lunz @ 2007-12-27 18:15 UTC (permalink / raw) To: David Woodhouse Cc: atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@falooley.org> --- arch/um/Kconfig | 4 +--- drivers/mtd/Kconfig | 12 +++++++----- drivers/mtd/chips/Kconfig | 11 ++++++++--- drivers/mtd/devices/Kconfig | 7 +++++++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" +endif config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate "M-Systems Disk-On-Chip Millennium Plus" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source "drivers/mtd/chips/Kconfig" -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/ubi/Kconfig" Index: linux-2.6.23.1-uml/drivers/mtd/Makefile =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH] allow use of mtd and jffs2 on uml @ 2007-12-27 18:15 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2007-12-27 18:15 UTC (permalink / raw) To: David Woodhouse Cc: atom ota, Jeff Dike, user-mode-linux-devel, linux-mtd, lkml, Rob Landley Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@falooley.org> --- arch/um/Kconfig | 4 +--- drivers/mtd/Kconfig | 12 +++++++----- drivers/mtd/chips/Kconfig | 11 ++++++++--- drivers/mtd/devices/Kconfig | 7 +++++++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" +endif config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate "M-Systems Disk-On-Chip Millennium Plus" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source "drivers/mtd/chips/Kconfig" -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/ubi/Kconfig" Index: linux-2.6.23.1-uml/drivers/mtd/Makefile =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* [uml-devel] [PATCH] allow use of mtd and jffs2 on uml @ 2007-12-27 18:15 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2007-12-27 18:15 UTC (permalink / raw) To: David Woodhouse Cc: atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@falooley.org> --- arch/um/Kconfig | 4 +--- drivers/mtd/Kconfig | 12 +++++++----- drivers/mtd/chips/Kconfig | 11 ++++++++--- drivers/mtd/devices/Kconfig | 7 +++++++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" +endif config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate "M-Systems Disk-On-Chip Millennium Plus" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source "drivers/mtd/chips/Kconfig" -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/ubi/Kconfig" Index: linux-2.6.23.1-uml/drivers/mtd/Makefile =================================================================== --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] allow use of mtd and jffs2 on uml 2007-12-27 18:15 ` [uml-devel] " Jason Lunz (?) @ 2007-12-28 17:48 ` Sam Ravnborg -1 siblings, 0 replies; 63+ messages in thread From: Sam Ravnborg @ 2007-12-28 17:48 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Thu, Dec 27, 2007 at 01:15:25PM -0500, Jason Lunz wrote: > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > dependencies down closer to the parts of mtd that actually need it. This > allows enough of mtd to build to let jffs2 be used on uml. > > Signed-off-by: Jason Lunz <lunz@falooley.org> > > --- > > arch/um/Kconfig | 4 +--- > drivers/mtd/Kconfig | 12 +++++++----- > drivers/mtd/chips/Kconfig | 11 ++++++++--- > drivers/mtd/devices/Kconfig | 7 +++++++ > 4 files changed, 23 insertions(+), 11 deletions(-) > > Index: linux-2.6.23.1-uml/arch/um/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/arch/um/Kconfig > +++ linux-2.6.23.1-uml/arch/um/Kconfig > @@ -326,9 +326,7 @@ > > source "drivers/md/Kconfig" > > -if BROKEN > - source "drivers/mtd/Kconfig" > -endif > +source "drivers/mtd/Kconfig" > > #This is just to shut up some Kconfig warnings, so no prompt. > config INPUT > Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > @@ -78,6 +78,7 @@ > > config MTD_SLRAM > tristate "Uncached system RAM" > + depends on HAS_IOMEM > help > If your CPU cannot cache all of the physical memory in your machine, > you can still use it for storage or swap by using this driver to > @@ -85,6 +86,7 @@ > > config MTD_PHRAM > tristate "Physical system RAM" > + depends on HAS_IOMEM > help > This is a re-implementation of the slram driver above. > > @@ -151,10 +153,13 @@ > Testing MTD users (eg JFFS2) on large media and media that might > be removed during a write (using the floppy drive). > > +if HAS_IOMEM > comment "Disk-On-Chip Device Drivers" > +endif You can expand the if above to include the config symols.. > > config MTD_DOC2000 > tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -177,6 +182,7 @@ > > config MTD_DOC2001 > tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -198,6 +204,7 @@ > > config MTD_DOC2001PLUS > tristate "M-Systems Disk-On-Chip Millennium Plus" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- .. so if the endif was placed here you did not have to specify the "depends on". Assumng btw that no other symbols inbetween exists. > Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig > @@ -2,7 +2,6 @@ > > menuconfig MTD > tristate "Memory Technology Device (MTD) support" > - depends on HAS_IOMEM > help > Memory Technology Devices are flash, RAM and similar chips, often > used for solid state file systems on embedded devices. This option > @@ -278,15 +277,18 @@ > This enables read only access to SmartMedia formatted NAND > flash. You can mount it with FAT file system. > > -source "drivers/mtd/chips/Kconfig" > > -source "drivers/mtd/maps/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/chips/Kconfig" > + source "drivers/mtd/maps/Kconfig" > +endif This "if" should be pushed down in the kconfig file so it is obvoious we have this dependency. > > source "drivers/mtd/devices/Kconfig" > > -source "drivers/mtd/nand/Kconfig" > - > -source "drivers/mtd/onenand/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/nand/Kconfig" > + source "drivers/mtd/onenand/Kconfig" > +endif Same for this one - let it be explicit in the Kconfig file. > > source "drivers/mtd/ubi/Kconfig" > > Index: linux-2.6.23.1-uml/drivers/mtd/Makefile > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile > +++ linux-2.6.23.1-uml/drivers/mtd/Makefile > @@ -26,6 +26,9 @@ > nftl-objs := nftlcore.o nftlmount.o > inftl-objs := inftlcore.o inftlmount.o > > -obj-y += chips/ maps/ devices/ nand/ onenand/ > +obj-y += devices/ > +ifdef CONFIG_HAS_IOMEM > +obj-y += chips/ maps/ nand/ onenand/ > +endif The ifdef for CONFIG_HAS_IOMEM looks strange. Let kbuild visit the directories and then figure out nothing needs to be done. If you insist on the HAS_IOMEM dependency then use: obj-$(CONFIG_HAS_IOMEM) += chips/ maps/ nand/ o Sam ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] allow use of mtd and jffs2 on uml @ 2007-12-28 17:48 ` Sam Ravnborg 0 siblings, 0 replies; 63+ messages in thread From: Sam Ravnborg @ 2007-12-28 17:48 UTC (permalink / raw) To: Jason Lunz Cc: David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Thu, Dec 27, 2007 at 01:15:25PM -0500, Jason Lunz wrote: > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > dependencies down closer to the parts of mtd that actually need it. This > allows enough of mtd to build to let jffs2 be used on uml. > > Signed-off-by: Jason Lunz <lunz@falooley.org> > > --- > > arch/um/Kconfig | 4 +--- > drivers/mtd/Kconfig | 12 +++++++----- > drivers/mtd/chips/Kconfig | 11 ++++++++--- > drivers/mtd/devices/Kconfig | 7 +++++++ > 4 files changed, 23 insertions(+), 11 deletions(-) > > Index: linux-2.6.23.1-uml/arch/um/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/arch/um/Kconfig > +++ linux-2.6.23.1-uml/arch/um/Kconfig > @@ -326,9 +326,7 @@ > > source "drivers/md/Kconfig" > > -if BROKEN > - source "drivers/mtd/Kconfig" > -endif > +source "drivers/mtd/Kconfig" > > #This is just to shut up some Kconfig warnings, so no prompt. > config INPUT > Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > @@ -78,6 +78,7 @@ > > config MTD_SLRAM > tristate "Uncached system RAM" > + depends on HAS_IOMEM > help > If your CPU cannot cache all of the physical memory in your machine, > you can still use it for storage or swap by using this driver to > @@ -85,6 +86,7 @@ > > config MTD_PHRAM > tristate "Physical system RAM" > + depends on HAS_IOMEM > help > This is a re-implementation of the slram driver above. > > @@ -151,10 +153,13 @@ > Testing MTD users (eg JFFS2) on large media and media that might > be removed during a write (using the floppy drive). > > +if HAS_IOMEM > comment "Disk-On-Chip Device Drivers" > +endif You can expand the if above to include the config symols.. > > config MTD_DOC2000 > tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -177,6 +182,7 @@ > > config MTD_DOC2001 > tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -198,6 +204,7 @@ > > config MTD_DOC2001PLUS > tristate "M-Systems Disk-On-Chip Millennium Plus" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- .. so if the endif was placed here you did not have to specify the "depends on". Assumng btw that no other symbols inbetween exists. > Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig > @@ -2,7 +2,6 @@ > > menuconfig MTD > tristate "Memory Technology Device (MTD) support" > - depends on HAS_IOMEM > help > Memory Technology Devices are flash, RAM and similar chips, often > used for solid state file systems on embedded devices. This option > @@ -278,15 +277,18 @@ > This enables read only access to SmartMedia formatted NAND > flash. You can mount it with FAT file system. > > -source "drivers/mtd/chips/Kconfig" > > -source "drivers/mtd/maps/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/chips/Kconfig" > + source "drivers/mtd/maps/Kconfig" > +endif This "if" should be pushed down in the kconfig file so it is obvoious we have this dependency. > > source "drivers/mtd/devices/Kconfig" > > -source "drivers/mtd/nand/Kconfig" > - > -source "drivers/mtd/onenand/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/nand/Kconfig" > + source "drivers/mtd/onenand/Kconfig" > +endif Same for this one - let it be explicit in the Kconfig file. > > source "drivers/mtd/ubi/Kconfig" > > Index: linux-2.6.23.1-uml/drivers/mtd/Makefile > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile > +++ linux-2.6.23.1-uml/drivers/mtd/Makefile > @@ -26,6 +26,9 @@ > nftl-objs := nftlcore.o nftlmount.o > inftl-objs := inftlcore.o inftlmount.o > > -obj-y += chips/ maps/ devices/ nand/ onenand/ > +obj-y += devices/ > +ifdef CONFIG_HAS_IOMEM > +obj-y += chips/ maps/ nand/ onenand/ > +endif The ifdef for CONFIG_HAS_IOMEM looks strange. Let kbuild visit the directories and then figure out nothing needs to be done. If you insist on the HAS_IOMEM dependency then use: obj-$(CONFIG_HAS_IOMEM) += chips/ maps/ nand/ o Sam ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [uml-devel] [PATCH] allow use of mtd and jffs2 on uml @ 2007-12-28 17:48 ` Sam Ravnborg 0 siblings, 0 replies; 63+ messages in thread From: Sam Ravnborg @ 2007-12-28 17:48 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Thu, Dec 27, 2007 at 01:15:25PM -0500, Jason Lunz wrote: > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > dependencies down closer to the parts of mtd that actually need it. This > allows enough of mtd to build to let jffs2 be used on uml. > > Signed-off-by: Jason Lunz <lunz@falooley.org> > > --- > > arch/um/Kconfig | 4 +--- > drivers/mtd/Kconfig | 12 +++++++----- > drivers/mtd/chips/Kconfig | 11 ++++++++--- > drivers/mtd/devices/Kconfig | 7 +++++++ > 4 files changed, 23 insertions(+), 11 deletions(-) > > Index: linux-2.6.23.1-uml/arch/um/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/arch/um/Kconfig > +++ linux-2.6.23.1-uml/arch/um/Kconfig > @@ -326,9 +326,7 @@ > > source "drivers/md/Kconfig" > > -if BROKEN > - source "drivers/mtd/Kconfig" > -endif > +source "drivers/mtd/Kconfig" > > #This is just to shut up some Kconfig warnings, so no prompt. > config INPUT > Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig > @@ -78,6 +78,7 @@ > > config MTD_SLRAM > tristate "Uncached system RAM" > + depends on HAS_IOMEM > help > If your CPU cannot cache all of the physical memory in your machine, > you can still use it for storage or swap by using this driver to > @@ -85,6 +86,7 @@ > > config MTD_PHRAM > tristate "Physical system RAM" > + depends on HAS_IOMEM > help > This is a re-implementation of the slram driver above. > > @@ -151,10 +153,13 @@ > Testing MTD users (eg JFFS2) on large media and media that might > be removed during a write (using the floppy drive). > > +if HAS_IOMEM > comment "Disk-On-Chip Device Drivers" > +endif You can expand the if above to include the config symols.. > > config MTD_DOC2000 > tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -177,6 +182,7 @@ > > config MTD_DOC2001 > tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- > @@ -198,6 +204,7 @@ > > config MTD_DOC2001PLUS > tristate "M-Systems Disk-On-Chip Millennium Plus" > + depends on HAS_IOMEM > select MTD_DOCPROBE > select MTD_NAND_IDS > ---help--- .. so if the endif was placed here you did not have to specify the "depends on". Assumng btw that no other symbols inbetween exists. > Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig > +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig > @@ -2,7 +2,6 @@ > > menuconfig MTD > tristate "Memory Technology Device (MTD) support" > - depends on HAS_IOMEM > help > Memory Technology Devices are flash, RAM and similar chips, often > used for solid state file systems on embedded devices. This option > @@ -278,15 +277,18 @@ > This enables read only access to SmartMedia formatted NAND > flash. You can mount it with FAT file system. > > -source "drivers/mtd/chips/Kconfig" > > -source "drivers/mtd/maps/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/chips/Kconfig" > + source "drivers/mtd/maps/Kconfig" > +endif This "if" should be pushed down in the kconfig file so it is obvoious we have this dependency. > > source "drivers/mtd/devices/Kconfig" > > -source "drivers/mtd/nand/Kconfig" > - > -source "drivers/mtd/onenand/Kconfig" > +if HAS_IOMEM > + source "drivers/mtd/nand/Kconfig" > + source "drivers/mtd/onenand/Kconfig" > +endif Same for this one - let it be explicit in the Kconfig file. > > source "drivers/mtd/ubi/Kconfig" > > Index: linux-2.6.23.1-uml/drivers/mtd/Makefile > =================================================================== > --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile > +++ linux-2.6.23.1-uml/drivers/mtd/Makefile > @@ -26,6 +26,9 @@ > nftl-objs := nftlcore.o nftlmount.o > inftl-objs := inftlcore.o inftlmount.o > > -obj-y += chips/ maps/ devices/ nand/ onenand/ > +obj-y += devices/ > +ifdef CONFIG_HAS_IOMEM > +obj-y += chips/ maps/ nand/ onenand/ > +endif The ifdef for CONFIG_HAS_IOMEM looks strange. Let kbuild visit the directories and then figure out nothing needs to be done. If you insist on the HAS_IOMEM dependency then use: obj-$(CONFIG_HAS_IOMEM) += chips/ maps/ nand/ o Sam ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2007-12-28 17:48 ` [uml-devel] " Sam Ravnborg @ 2010-12-07 7:29 ` Jason Lunz -1 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-07 7:29 UTC (permalink / raw) To: Sam Ravnborg Cc: atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@acm.org> --- arch/um/Kconfig.rest | 4 +--- drivers/mtd/Kconfig | 1 - drivers/mtd/Makefile | 3 ++- drivers/mtd/chips/Kconfig | 4 ++++ drivers/mtd/devices/Kconfig | 8 ++++++++ drivers/mtd/maps/Kconfig | 4 ++++ drivers/mtd/mtdchar.c | 4 ++++ drivers/mtd/nand/Kconfig | 3 +++ drivers/mtd/onenand/Kconfig | 3 +++ include/linux/mtd/map.h | 2 ++ 10 files changed, 31 insertions(+), 5 deletions(-) diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest index 0ccad0f..e34f399 100644 --- a/arch/um/Kconfig.rest +++ b/arch/um/Kconfig.rest @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" source "drivers/leds/Kconfig" diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 1e2cbf5..a0e2a28 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,6 +1,5 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 760abc5..ffa2e15 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ +obj-y += maps/ devices/ nand/ onenand/ tests/ +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ obj-$(CONFIG_MTD_UBI) += ubi/ diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig index 35c6a23..27382c9 100644 --- a/drivers/mtd/chips/Kconfig +++ b/drivers/mtd/chips/Kconfig @@ -1,3 +1,5 @@ +if HAS_IOMEM + menu "RAM/ROM/Flash chip drivers" depends on MTD!=n @@ -240,3 +242,5 @@ config MTD_XIP then say N. endmenu + +endif # HAS_IOMEM diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig index 35081ce..8f6d85d 100644 --- a/drivers/mtd/devices/Kconfig +++ b/drivers/mtd/devices/Kconfig @@ -112,6 +112,8 @@ config MTD_SST25L Set up your spi devices with the right board-specific platform data, if you want to specify device partitioning. +if HAS_IOMEM + config MTD_SLRAM tristate "Uncached system RAM" help @@ -128,6 +130,8 @@ config MTD_PHRAM doesn't have access to, memory beyond the mem=xxx limit, nvram, memory on the video card, etc... +endif # HAS_IOMEM + config MTD_LART tristate "28F160xx flash driver for LART" depends on SA1100_LART @@ -187,6 +191,8 @@ config MTD_BLOCK2MTD Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM + comment "Disk-On-Chip Device Drivers" config MTD_DOC2000 @@ -249,6 +255,8 @@ config MTD_DOC2001PLUS under "NAND Flash Device Drivers" (currently that driver does not support all Millennium Plus devices). +endif # HAS_IOMEM + config MTD_DOCPROBE tristate select MTD_DOCECC diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index a0dd7bb..e793b29 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -1,3 +1,5 @@ +if HAS_IOMEM + menu "Mapping drivers for chip access" depends on MTD!=n @@ -553,3 +555,5 @@ config MTD_PISMO When built as a module, it will be called pismo.ko endmenu + +endif # HAS_IOMEM diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c index 4759d82..a434354 100644 --- a/drivers/mtd/mtdchar.c +++ b/drivers/mtd/mtdchar.c @@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file, /* * set up a mapping for shared memory segments */ +#ifdef CONFIG_HAS_IOMEM static int mtd_mmap(struct file *file, struct vm_area_struct *vma) { #ifdef CONFIG_MMU @@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma) return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS; #endif } +#endif static const struct file_operations mtd_fops = { .owner = THIS_MODULE, @@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = { #endif .open = mtd_open, .release = mtd_close, +#ifdef CONFIG_HAS_IOMEM .mmap = mtd_mmap, +#endif #ifndef CONFIG_MMU .get_unmapped_area = mtd_get_unmapped_area, #endif diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 8229802..8bdd465 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -10,6 +10,8 @@ config MTD_NAND_ECC_SMC The original Linux implementation had byte 0 and 1 swapped. +if HAS_IOMEM + menuconfig MTD_NAND tristate "NAND Device Support" depends on MTD @@ -533,3 +535,4 @@ config MTD_NAND_FSMC Flexible Static Memory Controller (FSMC) endif # MTD_NAND +endif # HAS_IOMEM diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig index 4dbd0f5..166aa18 100644 --- a/drivers/mtd/onenand/Kconfig +++ b/drivers/mtd/onenand/Kconfig @@ -1,3 +1,5 @@ +if HAS_IOMEM + menuconfig MTD_ONENAND tristate "OneNAND Device Support" depends on MTD @@ -75,3 +77,4 @@ config MTD_ONENAND_SIM OneNAND MTD layer. endif # MTD_ONENAND +endif # HAS_IOMEM diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h index a9e6ba4..c7233ba 100644 --- a/include/linux/mtd/map.h +++ b/include/linux/mtd/map.h @@ -388,6 +388,7 @@ static inline map_word map_word_ff(struct map_info *map) return r; } +#ifdef CONFIG_HAS_IOMEM static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) { map_word r; @@ -439,6 +440,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co { memcpy_toio(map->virt + to, from, len); } +#endif /* CONFIG_HAS_IOMEM */ #ifdef CONFIG_MTD_COMPLEX_MAPPINGS #define map_read(map, ofs) (map)->read(map, ofs) -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-07 7:29 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-07 7:29 UTC (permalink / raw) To: Sam Ravnborg Cc: David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@acm.org> --- arch/um/Kconfig.rest | 4 +--- drivers/mtd/Kconfig | 1 - drivers/mtd/Makefile | 3 ++- drivers/mtd/chips/Kconfig | 4 ++++ drivers/mtd/devices/Kconfig | 8 ++++++++ drivers/mtd/maps/Kconfig | 4 ++++ drivers/mtd/mtdchar.c | 4 ++++ drivers/mtd/nand/Kconfig | 3 +++ drivers/mtd/onenand/Kconfig | 3 +++ include/linux/mtd/map.h | 2 ++ 10 files changed, 31 insertions(+), 5 deletions(-) diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest index 0ccad0f..e34f399 100644 --- a/arch/um/Kconfig.rest +++ b/arch/um/Kconfig.rest @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" source "drivers/leds/Kconfig" diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 1e2cbf5..a0e2a28 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,6 +1,5 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 760abc5..ffa2e15 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ +obj-y += maps/ devices/ nand/ onenand/ tests/ +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ obj-$(CONFIG_MTD_UBI) += ubi/ diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig index 35c6a23..27382c9 100644 --- a/drivers/mtd/chips/Kconfig +++ b/drivers/mtd/chips/Kconfig @@ -1,3 +1,5 @@ +if HAS_IOMEM + menu "RAM/ROM/Flash chip drivers" depends on MTD!=n @@ -240,3 +242,5 @@ config MTD_XIP then say N. endmenu + +endif # HAS_IOMEM diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig index 35081ce..8f6d85d 100644 --- a/drivers/mtd/devices/Kconfig +++ b/drivers/mtd/devices/Kconfig @@ -112,6 +112,8 @@ config MTD_SST25L Set up your spi devices with the right board-specific platform data, if you want to specify device partitioning. +if HAS_IOMEM + config MTD_SLRAM tristate "Uncached system RAM" help @@ -128,6 +130,8 @@ config MTD_PHRAM doesn't have access to, memory beyond the mem=xxx limit, nvram, memory on the video card, etc... +endif # HAS_IOMEM + config MTD_LART tristate "28F160xx flash driver for LART" depends on SA1100_LART @@ -187,6 +191,8 @@ config MTD_BLOCK2MTD Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM + comment "Disk-On-Chip Device Drivers" config MTD_DOC2000 @@ -249,6 +255,8 @@ config MTD_DOC2001PLUS under "NAND Flash Device Drivers" (currently that driver does not support all Millennium Plus devices). +endif # HAS_IOMEM + config MTD_DOCPROBE tristate select MTD_DOCECC diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index a0dd7bb..e793b29 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -1,3 +1,5 @@ +if HAS_IOMEM + menu "Mapping drivers for chip access" depends on MTD!=n @@ -553,3 +555,5 @@ config MTD_PISMO When built as a module, it will be called pismo.ko endmenu + +endif # HAS_IOMEM diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c index 4759d82..a434354 100644 --- a/drivers/mtd/mtdchar.c +++ b/drivers/mtd/mtdchar.c @@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file, /* * set up a mapping for shared memory segments */ +#ifdef CONFIG_HAS_IOMEM static int mtd_mmap(struct file *file, struct vm_area_struct *vma) { #ifdef CONFIG_MMU @@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma) return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS; #endif } +#endif static const struct file_operations mtd_fops = { .owner = THIS_MODULE, @@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = { #endif .open = mtd_open, .release = mtd_close, +#ifdef CONFIG_HAS_IOMEM .mmap = mtd_mmap, +#endif #ifndef CONFIG_MMU .get_unmapped_area = mtd_get_unmapped_area, #endif diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 8229802..8bdd465 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -10,6 +10,8 @@ config MTD_NAND_ECC_SMC The original Linux implementation had byte 0 and 1 swapped. +if HAS_IOMEM + menuconfig MTD_NAND tristate "NAND Device Support" depends on MTD @@ -533,3 +535,4 @@ config MTD_NAND_FSMC Flexible Static Memory Controller (FSMC) endif # MTD_NAND +endif # HAS_IOMEM diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig index 4dbd0f5..166aa18 100644 --- a/drivers/mtd/onenand/Kconfig +++ b/drivers/mtd/onenand/Kconfig @@ -1,3 +1,5 @@ +if HAS_IOMEM + menuconfig MTD_ONENAND tristate "OneNAND Device Support" depends on MTD @@ -75,3 +77,4 @@ config MTD_ONENAND_SIM OneNAND MTD layer. endif # MTD_ONENAND +endif # HAS_IOMEM diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h index a9e6ba4..c7233ba 100644 --- a/include/linux/mtd/map.h +++ b/include/linux/mtd/map.h @@ -388,6 +388,7 @@ static inline map_word map_word_ff(struct map_info *map) return r; } +#ifdef CONFIG_HAS_IOMEM static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) { map_word r; @@ -439,6 +440,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co { memcpy_toio(map->virt + to, from, len); } +#endif /* CONFIG_HAS_IOMEM */ #ifdef CONFIG_MTD_COMPLEX_MAPPINGS #define map_read(map, ofs) (map)->read(map, ofs) -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-07 7:29 ` Jason Lunz (?) @ 2010-12-07 9:39 ` richard -rw- weinberger -1 siblings, 0 replies; 63+ messages in thread From: richard -rw- weinberger @ 2010-12-07 9:39 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz@acm.org> wrote: > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > dependencies down closer to the parts of mtd that actually need it. > This allows enough of mtd to build to let jffs2 be used on uml. > > Signed-off-by: Jason Lunz <lunz@acm.org> > --- > arch/um/Kconfig.rest | 4 +--- > drivers/mtd/Kconfig | 1 - > drivers/mtd/Makefile | 3 ++- > drivers/mtd/chips/Kconfig | 4 ++++ > drivers/mtd/devices/Kconfig | 8 ++++++++ > drivers/mtd/maps/Kconfig | 4 ++++ > drivers/mtd/mtdchar.c | 4 ++++ > drivers/mtd/nand/Kconfig | 3 +++ > drivers/mtd/onenand/Kconfig | 3 +++ > include/linux/mtd/map.h | 2 ++ > 10 files changed, 31 insertions(+), 5 deletions(-) > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest > index 0ccad0f..e34f399 100644 > --- a/arch/um/Kconfig.rest > +++ b/arch/um/Kconfig.rest > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" > > source "drivers/md/Kconfig" > > -if BROKEN > - source "drivers/mtd/Kconfig" > -endif > +source "drivers/mtd/Kconfig" drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2). Do you exactly know why it was marked and fixes this patch all issues? > source "drivers/leds/Kconfig" > > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > index 1e2cbf5..a0e2a28 100644 > --- a/drivers/mtd/Kconfig > +++ b/drivers/mtd/Kconfig > @@ -1,6 +1,5 @@ > menuconfig MTD > tristate "Memory Technology Device (MTD) support" > - depends on HAS_IOMEM > help > Memory Technology Devices are flash, RAM and similar chips, often > used for solid state file systems on embedded devices. This option > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > index 760abc5..ffa2e15 100644 > --- a/drivers/mtd/Makefile > +++ b/drivers/mtd/Makefile > @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o > nftl-objs := nftlcore.o nftlmount.o > inftl-objs := inftlcore.o inftlmount.o > > -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ > +obj-y += maps/ devices/ nand/ onenand/ tests/ > +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ > > obj-$(CONFIG_MTD_UBI) += ubi/ > diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig > index 35c6a23..27382c9 100644 > --- a/drivers/mtd/chips/Kconfig > +++ b/drivers/mtd/chips/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > menu "RAM/ROM/Flash chip drivers" > depends on MTD!=n > > @@ -240,3 +242,5 @@ config MTD_XIP > then say N. > > endmenu > + > +endif # HAS_IOMEM > diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig > index 35081ce..8f6d85d 100644 > --- a/drivers/mtd/devices/Kconfig > +++ b/drivers/mtd/devices/Kconfig > @@ -112,6 +112,8 @@ config MTD_SST25L > Set up your spi devices with the right board-specific platform data, > if you want to specify device partitioning. > > +if HAS_IOMEM > + > config MTD_SLRAM > tristate "Uncached system RAM" > help > @@ -128,6 +130,8 @@ config MTD_PHRAM > doesn't have access to, memory beyond the mem=xxx limit, nvram, > memory on the video card, etc... > > +endif # HAS_IOMEM > + > config MTD_LART > tristate "28F160xx flash driver for LART" > depends on SA1100_LART > @@ -187,6 +191,8 @@ config MTD_BLOCK2MTD > Testing MTD users (eg JFFS2) on large media and media that might > be removed during a write (using the floppy drive). > > +if HAS_IOMEM > + > comment "Disk-On-Chip Device Drivers" > > config MTD_DOC2000 > @@ -249,6 +255,8 @@ config MTD_DOC2001PLUS > under "NAND Flash Device Drivers" (currently that driver does not > support all Millennium Plus devices). > > +endif # HAS_IOMEM > + > config MTD_DOCPROBE > tristate > select MTD_DOCECC > diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig > index a0dd7bb..e793b29 100644 > --- a/drivers/mtd/maps/Kconfig > +++ b/drivers/mtd/maps/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > menu "Mapping drivers for chip access" > depends on MTD!=n > > @@ -553,3 +555,5 @@ config MTD_PISMO > When built as a module, it will be called pismo.ko > > endmenu > + > +endif # HAS_IOMEM > diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c > index 4759d82..a434354 100644 > --- a/drivers/mtd/mtdchar.c > +++ b/drivers/mtd/mtdchar.c > @@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file, > /* > * set up a mapping for shared memory segments > */ > +#ifdef CONFIG_HAS_IOMEM > static int mtd_mmap(struct file *file, struct vm_area_struct *vma) > { > #ifdef CONFIG_MMU > @@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma) > return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS; > #endif > } > +#endif > > static const struct file_operations mtd_fops = { > .owner = THIS_MODULE, > @@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = { > #endif > .open = mtd_open, > .release = mtd_close, > +#ifdef CONFIG_HAS_IOMEM > .mmap = mtd_mmap, > +#endif > #ifndef CONFIG_MMU > .get_unmapped_area = mtd_get_unmapped_area, > #endif > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 8229802..8bdd465 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -10,6 +10,8 @@ config MTD_NAND_ECC_SMC > The original Linux implementation had byte 0 and 1 swapped. > > > +if HAS_IOMEM > + > menuconfig MTD_NAND > tristate "NAND Device Support" > depends on MTD > @@ -533,3 +535,4 @@ config MTD_NAND_FSMC > Flexible Static Memory Controller (FSMC) > > endif # MTD_NAND > +endif # HAS_IOMEM > diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig > index 4dbd0f5..166aa18 100644 > --- a/drivers/mtd/onenand/Kconfig > +++ b/drivers/mtd/onenand/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > menuconfig MTD_ONENAND > tristate "OneNAND Device Support" > depends on MTD > @@ -75,3 +77,4 @@ config MTD_ONENAND_SIM > OneNAND MTD layer. > > endif # MTD_ONENAND > +endif # HAS_IOMEM > diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h > index a9e6ba4..c7233ba 100644 > --- a/include/linux/mtd/map.h > +++ b/include/linux/mtd/map.h > @@ -388,6 +388,7 @@ static inline map_word map_word_ff(struct map_info *map) > return r; > } > > +#ifdef CONFIG_HAS_IOMEM > static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) > { > map_word r; > @@ -439,6 +440,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co > { > memcpy_toio(map->virt + to, from, len); > } > +#endif /* CONFIG_HAS_IOMEM */ > > #ifdef CONFIG_MTD_COMPLEX_MAPPINGS > #define map_read(map, ofs) (map)->read(map, ofs) > -- > 1.7.2.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Thanks, //richard ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-07 9:39 ` richard -rw- weinberger 0 siblings, 0 replies; 63+ messages in thread From: richard -rw- weinberger @ 2010-12-07 9:39 UTC (permalink / raw) To: Jason Lunz Cc: Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz@acm.org> wrote: > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > dependencies down closer to the parts of mtd that actually need it. > This allows enough of mtd to build to let jffs2 be used on uml. > > Signed-off-by: Jason Lunz <lunz@acm.org> > --- > arch/um/Kconfig.rest | 4 +--- > drivers/mtd/Kconfig | 1 - > drivers/mtd/Makefile | 3 ++- > drivers/mtd/chips/Kconfig | 4 ++++ > drivers/mtd/devices/Kconfig | 8 ++++++++ > drivers/mtd/maps/Kconfig | 4 ++++ > drivers/mtd/mtdchar.c | 4 ++++ > drivers/mtd/nand/Kconfig | 3 +++ > drivers/mtd/onenand/Kconfig | 3 +++ > include/linux/mtd/map.h | 2 ++ > 10 files changed, 31 insertions(+), 5 deletions(-) > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest > index 0ccad0f..e34f399 100644 > --- a/arch/um/Kconfig.rest > +++ b/arch/um/Kconfig.rest > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" > > source "drivers/md/Kconfig" > > -if BROKEN > - source "drivers/mtd/Kconfig" > -endif > +source "drivers/mtd/Kconfig" drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2). Do you exactly know why it was marked and fixes this patch all issues? > source "drivers/leds/Kconfig" > > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > index 1e2cbf5..a0e2a28 100644 > --- a/drivers/mtd/Kconfig > +++ b/drivers/mtd/Kconfig > @@ -1,6 +1,5 @@ > menuconfig MTD > tristate "Memory Technology Device (MTD) support" > - depends on HAS_IOMEM > help > Memory Technology Devices are flash, RAM and similar chips, often > used for solid state file systems on embedded devices. This option > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > index 760abc5..ffa2e15 100644 > --- a/drivers/mtd/Makefile > +++ b/drivers/mtd/Makefile > @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o > nftl-objs := nftlcore.o nftlmount.o > inftl-objs := inftlcore.o inftlmount.o > > -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ > +obj-y += maps/ devices/ nand/ onenand/ tests/ > +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ > > obj-$(CONFIG_MTD_UBI) += ubi/ > diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig > index 35c6a23..27382c9 100644 > --- a/drivers/mtd/chips/Kconfig > +++ b/drivers/mtd/chips/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > menu "RAM/ROM/Flash chip drivers" > depends on MTD!=n > > @@ -240,3 +242,5 @@ config MTD_XIP > then say N. > > endmenu > + > +endif # HAS_IOMEM > diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig > index 35081ce..8f6d85d 100644 > --- a/drivers/mtd/devices/Kconfig > +++ b/drivers/mtd/devices/Kconfig > @@ -112,6 +112,8 @@ config MTD_SST25L > Set up your spi devices with the right board-specific platform data, > if you want to specify device partitioning. > > +if HAS_IOMEM > + > config MTD_SLRAM > tristate "Uncached system RAM" > help > @@ -128,6 +130,8 @@ config MTD_PHRAM > doesn't have access to, memory beyond the mem=xxx limit, nvram, > memory on the video card, etc... > > +endif # HAS_IOMEM > + > config MTD_LART > tristate "28F160xx flash driver for LART" > depends on SA1100_LART > @@ -187,6 +191,8 @@ config MTD_BLOCK2MTD > Testing MTD users (eg JFFS2) on large media and media that might > be removed during a write (using the floppy drive). > > +if HAS_IOMEM > + > comment "Disk-On-Chip Device Drivers" > > config MTD_DOC2000 > @@ -249,6 +255,8 @@ config MTD_DOC2001PLUS > under "NAND Flash Device Drivers" (currently that driver does not > support all Millennium Plus devices). > > +endif # HAS_IOMEM > + > config MTD_DOCPROBE > tristate > select MTD_DOCECC > diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig > index a0dd7bb..e793b29 100644 > --- a/drivers/mtd/maps/Kconfig > +++ b/drivers/mtd/maps/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > menu "Mapping drivers for chip access" > depends on MTD!=n > > @@ -553,3 +555,5 @@ config MTD_PISMO > When built as a module, it will be called pismo.ko > > endmenu > + > +endif # HAS_IOMEM > diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c > index 4759d82..a434354 100644 > --- a/drivers/mtd/mtdchar.c > +++ b/drivers/mtd/mtdchar.c > @@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file, > /* > * set up a mapping for shared memory segments > */ > +#ifdef CONFIG_HAS_IOMEM > static int mtd_mmap(struct file *file, struct vm_area_struct *vma) > { > #ifdef CONFIG_MMU > @@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma) > return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS; > #endif > } > +#endif > > static const struct file_operations mtd_fops = { > .owner = THIS_MODULE, > @@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = { > #endif > .open = mtd_open, > .release = mtd_close, > +#ifdef CONFIG_HAS_IOMEM > .mmap = mtd_mmap, > +#endif > #ifndef CONFIG_MMU > .get_unmapped_area = mtd_get_unmapped_area, > #endif > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 8229802..8bdd465 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -10,6 +10,8 @@ config MTD_NAND_ECC_SMC > The original Linux implementation had byte 0 and 1 swapped. > > > +if HAS_IOMEM > + > menuconfig MTD_NAND > tristate "NAND Device Support" > depends on MTD > @@ -533,3 +535,4 @@ config MTD_NAND_FSMC > Flexible Static Memory Controller (FSMC) > > endif # MTD_NAND > +endif # HAS_IOMEM > diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig > index 4dbd0f5..166aa18 100644 > --- a/drivers/mtd/onenand/Kconfig > +++ b/drivers/mtd/onenand/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > menuconfig MTD_ONENAND > tristate "OneNAND Device Support" > depends on MTD > @@ -75,3 +77,4 @@ config MTD_ONENAND_SIM > OneNAND MTD layer. > > endif # MTD_ONENAND > +endif # HAS_IOMEM > diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h > index a9e6ba4..c7233ba 100644 > --- a/include/linux/mtd/map.h > +++ b/include/linux/mtd/map.h > @@ -388,6 +388,7 @@ static inline map_word map_word_ff(struct map_info *map) > return r; > } > > +#ifdef CONFIG_HAS_IOMEM > static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) > { > map_word r; > @@ -439,6 +440,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co > { > memcpy_toio(map->virt + to, from, len); > } > +#endif /* CONFIG_HAS_IOMEM */ > > #ifdef CONFIG_MTD_COMPLEX_MAPPINGS > #define map_read(map, ofs) (map)->read(map, ofs) > -- > 1.7.2.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Thanks, //richard ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-07 9:39 ` richard -rw- weinberger 0 siblings, 0 replies; 63+ messages in thread From: richard -rw- weinberger @ 2010-12-07 9:39 UTC (permalink / raw) To: Jason Lunz Cc: Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz@acm.org> wrote: > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > dependencies down closer to the parts of mtd that actually need it. > This allows enough of mtd to build to let jffs2 be used on uml. > > Signed-off-by: Jason Lunz <lunz@acm.org> > --- > �arch/um/Kconfig.rest � � � �| � �4 +--- > �drivers/mtd/Kconfig � � � � | � �1 - > �drivers/mtd/Makefile � � � �| � �3 ++- > �drivers/mtd/chips/Kconfig � | � �4 ++++ > �drivers/mtd/devices/Kconfig | � �8 ++++++++ > �drivers/mtd/maps/Kconfig � �| � �4 ++++ > �drivers/mtd/mtdchar.c � � � | � �4 ++++ > �drivers/mtd/nand/Kconfig � �| � �3 +++ > �drivers/mtd/onenand/Kconfig | � �3 +++ > �include/linux/mtd/map.h � � | � �2 ++ > �10 files changed, 31 insertions(+), 5 deletions(-) > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest > index 0ccad0f..e34f399 100644 > --- a/arch/um/Kconfig.rest > +++ b/arch/um/Kconfig.rest > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" > > �source "drivers/md/Kconfig" > > -if BROKEN > - � � � source "drivers/mtd/Kconfig" > -endif > +source "drivers/mtd/Kconfig" drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2). Do you exactly know why it was marked and fixes this patch all issues? > �source "drivers/leds/Kconfig" > > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > index 1e2cbf5..a0e2a28 100644 > --- a/drivers/mtd/Kconfig > +++ b/drivers/mtd/Kconfig > @@ -1,6 +1,5 @@ > �menuconfig MTD > � � � �tristate "Memory Technology Device (MTD) support" > - � � � depends on HAS_IOMEM > � � � �help > � � � � �Memory Technology Devices are flash, RAM and similar chips, often > � � � � �used for solid state file systems on embedded devices. This option > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > index 760abc5..ffa2e15 100644 > --- a/drivers/mtd/Makefile > +++ b/drivers/mtd/Makefile > @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) � � � � � � � �+= mtdoops.o > �nftl-objs � � � � � � �:= nftlcore.o nftlmount.o > �inftl-objs � � � � � � := inftlcore.o inftlmount.o > > -obj-y � � � � �+= chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ > +obj-y � � � � � � � � �+= maps/ devices/ nand/ onenand/ tests/ > +obj-$(CONFIG_HAS_IOMEM) � � � �+= chips/ lpddr/ > > �obj-$(CONFIG_MTD_UBI) � � � � �+= ubi/ > diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig > index 35c6a23..27382c9 100644 > --- a/drivers/mtd/chips/Kconfig > +++ b/drivers/mtd/chips/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > �menu "RAM/ROM/Flash chip drivers" > � � � �depends on MTD!=n > > @@ -240,3 +242,5 @@ config MTD_XIP > � � � � �then say N. > > �endmenu > + > +endif # HAS_IOMEM > diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig > index 35081ce..8f6d85d 100644 > --- a/drivers/mtd/devices/Kconfig > +++ b/drivers/mtd/devices/Kconfig > @@ -112,6 +112,8 @@ config MTD_SST25L > � � � � �Set up your spi devices with the right board-specific platform data, > � � � � �if you want to specify device partitioning. > > +if HAS_IOMEM > + > �config MTD_SLRAM > � � � �tristate "Uncached system RAM" > � � � �help > @@ -128,6 +130,8 @@ config MTD_PHRAM > � � � � �doesn't have access to, memory beyond the mem=xxx limit, nvram, > � � � � �memory on the video card, etc... > > +endif # HAS_IOMEM > + > �config MTD_LART > � � � �tristate "28F160xx flash driver for LART" > � � � �depends on SA1100_LART > @@ -187,6 +191,8 @@ config MTD_BLOCK2MTD > � � � � �Testing MTD users (eg JFFS2) on large media and media that might > � � � � �be removed during a write (using the floppy drive). > > +if HAS_IOMEM > + > �comment "Disk-On-Chip Device Drivers" > > �config MTD_DOC2000 > @@ -249,6 +255,8 @@ config MTD_DOC2001PLUS > � � � � �under "NAND Flash Device Drivers" (currently that driver does not > � � � � �support all Millennium Plus devices). > > +endif # HAS_IOMEM > + > �config MTD_DOCPROBE > � � � �tristate > � � � �select MTD_DOCECC > diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig > index a0dd7bb..e793b29 100644 > --- a/drivers/mtd/maps/Kconfig > +++ b/drivers/mtd/maps/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > �menu "Mapping drivers for chip access" > � � � �depends on MTD!=n > > @@ -553,3 +555,5 @@ config MTD_PISMO > � � � � �When built as a module, it will be called pismo.ko > > �endmenu > + > +endif # HAS_IOMEM > diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c > index 4759d82..a434354 100644 > --- a/drivers/mtd/mtdchar.c > +++ b/drivers/mtd/mtdchar.c > @@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file, > �/* > �* set up a mapping for shared memory segments > �*/ > +#ifdef CONFIG_HAS_IOMEM > �static int mtd_mmap(struct file *file, struct vm_area_struct *vma) > �{ > �#ifdef CONFIG_MMU > @@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma) > � � � �return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS; > �#endif > �} > +#endif > > �static const struct file_operations mtd_fops = { > � � � �.owner � � � � �= THIS_MODULE, > @@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = { > �#endif > � � � �.open � � � � � = mtd_open, > � � � �.release � � � �= mtd_close, > +#ifdef CONFIG_HAS_IOMEM > � � � �.mmap � � � � � = mtd_mmap, > +#endif > �#ifndef CONFIG_MMU > � � � �.get_unmapped_area = mtd_get_unmapped_area, > �#endif > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 8229802..8bdd465 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -10,6 +10,8 @@ config MTD_NAND_ECC_SMC > � � � � �The original Linux implementation had byte 0 and 1 swapped. > > > +if HAS_IOMEM > + > �menuconfig MTD_NAND > � � � �tristate "NAND Device Support" > � � � �depends on MTD > @@ -533,3 +535,4 @@ config MTD_NAND_FSMC > � � � � �Flexible Static Memory Controller (FSMC) > > �endif # MTD_NAND > +endif # HAS_IOMEM > diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig > index 4dbd0f5..166aa18 100644 > --- a/drivers/mtd/onenand/Kconfig > +++ b/drivers/mtd/onenand/Kconfig > @@ -1,3 +1,5 @@ > +if HAS_IOMEM > + > �menuconfig MTD_ONENAND > � � � �tristate "OneNAND Device Support" > � � � �depends on MTD > @@ -75,3 +77,4 @@ config MTD_ONENAND_SIM > � � � � �OneNAND MTD layer. > > �endif # MTD_ONENAND > +endif # HAS_IOMEM > diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h > index a9e6ba4..c7233ba 100644 > --- a/include/linux/mtd/map.h > +++ b/include/linux/mtd/map.h > @@ -388,6 +388,7 @@ static inline map_word map_word_ff(struct map_info *map) > � � � �return r; > �} > > +#ifdef CONFIG_HAS_IOMEM > �static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) > �{ > � � � �map_word r; > @@ -439,6 +440,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co > �{ > � � � �memcpy_toio(map->virt + to, from, len); > �} > +#endif /* CONFIG_HAS_IOMEM */ > > �#ifdef CONFIG_MTD_COMPLEX_MAPPINGS > �#define map_read(map, ofs) (map)->read(map, ofs) > -- > 1.7.2.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at �http://vger.kernel.org/majordomo-info.html > Please read the FAQ at �http://www.tux.org/lkml/ > -- Thanks, //richard ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-07 9:39 ` richard -rw- weinberger (?) @ 2010-12-07 18:20 ` Jason Lunz -1 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-07 18:20 UTC (permalink / raw) To: richard -rw- weinberger Cc: atom ota, user-mode-linux-devel, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Tue, Dec 07, 2010 at 10:39:41AM +0100, richard -rw- weinberger wrote: > On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz@acm.org> wrote: > > > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > > dependencies down closer to the parts of mtd that actually need it. > > This allows enough of mtd to build to let jffs2 be used on uml. > > > > Signed-off-by: Jason Lunz <lunz@acm.org> > > --- > > arch/um/Kconfig.rest | 4 +--- > > drivers/mtd/Kconfig | 1 - > > drivers/mtd/Makefile | 3 ++- > > drivers/mtd/chips/Kconfig | 4 ++++ > > drivers/mtd/devices/Kconfig | 8 ++++++++ > > drivers/mtd/maps/Kconfig | 4 ++++ > > drivers/mtd/mtdchar.c | 4 ++++ > > drivers/mtd/nand/Kconfig | 3 +++ > > drivers/mtd/onenand/Kconfig | 3 +++ > > include/linux/mtd/map.h | 2 ++ > > 10 files changed, 31 insertions(+), 5 deletions(-) > > > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest > > index 0ccad0f..e34f399 100644 > > --- a/arch/um/Kconfig.rest > > +++ b/arch/um/Kconfig.rest > > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" > > > > source "drivers/md/Kconfig" > > > > -if BROKEN > > - source "drivers/mtd/Kconfig" > > -endif > > +source "drivers/mtd/Kconfig" > > drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2). > > Do you exactly know why it was marked and fixes this patch all issues? I don't know exactly why it was originally marked BROKEN. I imagine it was because most of the low-level mtd drivers need readb/writeb and friends, which don't exist on uml. But now that mtd has virtual ram- and blockdev-backed drivers, that's no longer sufficient reason to omit the whole subsystem. I can't claim that this fixes all possible issues of course, but I've privately been using this patch to run block2mtd under uml for years. My original motivation was to allow the use of jffs2 in a uml-based test environment and for that it's worked very well. Jason ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-07 18:20 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-07 18:20 UTC (permalink / raw) To: richard -rw- weinberger Cc: Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, Dec 07, 2010 at 10:39:41AM +0100, richard -rw- weinberger wrote: > On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz@acm.org> wrote: > > > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > > dependencies down closer to the parts of mtd that actually need it. > > This allows enough of mtd to build to let jffs2 be used on uml. > > > > Signed-off-by: Jason Lunz <lunz@acm.org> > > --- > > arch/um/Kconfig.rest | 4 +--- > > drivers/mtd/Kconfig | 1 - > > drivers/mtd/Makefile | 3 ++- > > drivers/mtd/chips/Kconfig | 4 ++++ > > drivers/mtd/devices/Kconfig | 8 ++++++++ > > drivers/mtd/maps/Kconfig | 4 ++++ > > drivers/mtd/mtdchar.c | 4 ++++ > > drivers/mtd/nand/Kconfig | 3 +++ > > drivers/mtd/onenand/Kconfig | 3 +++ > > include/linux/mtd/map.h | 2 ++ > > 10 files changed, 31 insertions(+), 5 deletions(-) > > > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest > > index 0ccad0f..e34f399 100644 > > --- a/arch/um/Kconfig.rest > > +++ b/arch/um/Kconfig.rest > > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" > > > > source "drivers/md/Kconfig" > > > > -if BROKEN > > - source "drivers/mtd/Kconfig" > > -endif > > +source "drivers/mtd/Kconfig" > > drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2). > > Do you exactly know why it was marked and fixes this patch all issues? I don't know exactly why it was originally marked BROKEN. I imagine it was because most of the low-level mtd drivers need readb/writeb and friends, which don't exist on uml. But now that mtd has virtual ram- and blockdev-backed drivers, that's no longer sufficient reason to omit the whole subsystem. I can't claim that this fixes all possible issues of course, but I've privately been using this patch to run block2mtd under uml for years. My original motivation was to allow the use of jffs2 in a uml-based test environment and for that it's worked very well. Jason ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-07 18:20 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-07 18:20 UTC (permalink / raw) To: richard -rw- weinberger Cc: Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, Dec 07, 2010 at 10:39:41AM +0100, richard -rw- weinberger wrote: > On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz@acm.org> wrote: > > > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > > dependencies down closer to the parts of mtd that actually need it. > > This allows enough of mtd to build to let jffs2 be used on uml. > > > > Signed-off-by: Jason Lunz <lunz@acm.org> > > --- > > �arch/um/Kconfig.rest � � � �| � �4 +--- > > �drivers/mtd/Kconfig � � � � | � �1 - > > �drivers/mtd/Makefile � � � �| � �3 ++- > > �drivers/mtd/chips/Kconfig � | � �4 ++++ > > �drivers/mtd/devices/Kconfig | � �8 ++++++++ > > �drivers/mtd/maps/Kconfig � �| � �4 ++++ > > �drivers/mtd/mtdchar.c � � � | � �4 ++++ > > �drivers/mtd/nand/Kconfig � �| � �3 +++ > > �drivers/mtd/onenand/Kconfig | � �3 +++ > > �include/linux/mtd/map.h � � | � �2 ++ > > �10 files changed, 31 insertions(+), 5 deletions(-) > > > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest > > index 0ccad0f..e34f399 100644 > > --- a/arch/um/Kconfig.rest > > +++ b/arch/um/Kconfig.rest > > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" > > > > �source "drivers/md/Kconfig" > > > > -if BROKEN > > - � � � source "drivers/mtd/Kconfig" > > -endif > > +source "drivers/mtd/Kconfig" > > drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2). > > Do you exactly know why it was marked and fixes this patch all issues? I don't know exactly why it was originally marked BROKEN. I imagine it was because most of the low-level mtd drivers need readb/writeb and friends, which don't exist on uml. But now that mtd has virtual ram- and blockdev-backed drivers, that's no longer sufficient reason to omit the whole subsystem. I can't claim that this fixes all possible issues of course, but I've privately been using this patch to run block2mtd under uml for years. My original motivation was to allow the use of jffs2 in a uml-based test environment and for that it's worked very well. Jason ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-07 18:20 ` Jason Lunz @ 2010-12-14 16:24 ` Artem Bityutskiy -1 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-14 16:24 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Tue, 2010-12-07 at 10:20 -0800, Jason Lunz wrote: > On Tue, Dec 07, 2010 at 10:39:41AM +0100, richard -rw- weinberger wrote: > > On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz@acm.org> wrote: > > > > > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > > > dependencies down closer to the parts of mtd that actually need it. > > > This allows enough of mtd to build to let jffs2 be used on uml. > > > > > > Signed-off-by: Jason Lunz <lunz@acm.org> > > > --- > > > arch/um/Kconfig.rest | 4 +--- > > > drivers/mtd/Kconfig | 1 - > > > drivers/mtd/Makefile | 3 ++- > > > drivers/mtd/chips/Kconfig | 4 ++++ > > > drivers/mtd/devices/Kconfig | 8 ++++++++ > > > drivers/mtd/maps/Kconfig | 4 ++++ > > > drivers/mtd/mtdchar.c | 4 ++++ > > > drivers/mtd/nand/Kconfig | 3 +++ > > > drivers/mtd/onenand/Kconfig | 3 +++ > > > include/linux/mtd/map.h | 2 ++ > > > 10 files changed, 31 insertions(+), 5 deletions(-) > > > > > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest > > > index 0ccad0f..e34f399 100644 > > > --- a/arch/um/Kconfig.rest > > > +++ b/arch/um/Kconfig.rest > > > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" > > > > > > source "drivers/md/Kconfig" > > > > > > -if BROKEN > > > - source "drivers/mtd/Kconfig" > > > -endif > > > +source "drivers/mtd/Kconfig" > > > > drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2). > > > > Do you exactly know why it was marked and fixes this patch all issues? > > I don't know exactly why it was originally marked BROKEN. I imagine it > was because most of the low-level mtd drivers need readb/writeb and > friends, which don't exist on uml. But now that mtd has virtual ram- and > blockdev-backed drivers, that's no longer sufficient reason to omit the > whole subsystem. > > I can't claim that this fixes all possible issues of course, but I've > privately been using this patch to run block2mtd under uml for years. My > original motivation was to allow the use of jffs2 in a uml-based test > environment and for that it's worked very well. But I think your solution is a bit dirty, because it adds a great deal of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. This is error-prone. Instead, you should solve this problem in UML code. I do not know how, but may be you can add readb/writeb there which actually do nothing or print a scary warning, or do BUG(), and let things which use them just fail run-time. Anyway, please, think about a solution which needs few changes in UML code instead of myriads of small little changes in many places. Thanks! -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-14 16:24 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-14 16:24 UTC (permalink / raw) To: Jason Lunz Cc: richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, 2010-12-07 at 10:20 -0800, Jason Lunz wrote: > On Tue, Dec 07, 2010 at 10:39:41AM +0100, richard -rw- weinberger wrote: > > On Tue, Dec 7, 2010 at 8:29 AM, Jason Lunz <lunz@acm.org> wrote: > > > > > > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > > > dependencies down closer to the parts of mtd that actually need it. > > > This allows enough of mtd to build to let jffs2 be used on uml. > > > > > > Signed-off-by: Jason Lunz <lunz@acm.org> > > > --- > > > arch/um/Kconfig.rest | 4 +--- > > > drivers/mtd/Kconfig | 1 - > > > drivers/mtd/Makefile | 3 ++- > > > drivers/mtd/chips/Kconfig | 4 ++++ > > > drivers/mtd/devices/Kconfig | 8 ++++++++ > > > drivers/mtd/maps/Kconfig | 4 ++++ > > > drivers/mtd/mtdchar.c | 4 ++++ > > > drivers/mtd/nand/Kconfig | 3 +++ > > > drivers/mtd/onenand/Kconfig | 3 +++ > > > include/linux/mtd/map.h | 2 ++ > > > 10 files changed, 31 insertions(+), 5 deletions(-) > > > > > > diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest > > > index 0ccad0f..e34f399 100644 > > > --- a/arch/um/Kconfig.rest > > > +++ b/arch/um/Kconfig.rest > > > @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" > > > > > > source "drivers/md/Kconfig" > > > > > > -if BROKEN > > > - source "drivers/mtd/Kconfig" > > > -endif > > > +source "drivers/mtd/Kconfig" > > > > drivers/mtd was already marked as broken when we moved over to git (2.6.12-rc2). > > > > Do you exactly know why it was marked and fixes this patch all issues? > > I don't know exactly why it was originally marked BROKEN. I imagine it > was because most of the low-level mtd drivers need readb/writeb and > friends, which don't exist on uml. But now that mtd has virtual ram- and > blockdev-backed drivers, that's no longer sufficient reason to omit the > whole subsystem. > > I can't claim that this fixes all possible issues of course, but I've > privately been using this patch to run block2mtd under uml for years. My > original motivation was to allow the use of jffs2 in a uml-based test > environment and for that it's worked very well. But I think your solution is a bit dirty, because it adds a great deal of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. This is error-prone. Instead, you should solve this problem in UML code. I do not know how, but may be you can add readb/writeb there which actually do nothing or print a scary warning, or do BUG(), and let things which use them just fail run-time. Anyway, please, think about a solution which needs few changes in UML code instead of myriads of small little changes in many places. Thanks! -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 16:24 ` Artem Bityutskiy @ 2010-12-14 19:51 ` Jason Lunz -1 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-14 19:51 UTC (permalink / raw) To: Artem Bityutskiy Cc: atom ota, user-mode-linux-devel, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote: > But I think your solution is a bit dirty, because it adds a great deal > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. > This is error-prone. The intent of that patch was to allow as much of the mtd subsystem to compile as possible. My thinking was to try and rectify the fact that uml has gone without mtd (and hence jffs2) support for years even though much of it works just fine. I think the entire subsystem being marked BROKEN in kconfig kept anyone from experimenting with it. The patch I sent was actually a reaction to feedback I got from Sam Ravnborg on my last attempt (um, three years ago :/ ) in which he suggested pushing down the ifdefs closer to their points of use. But I agree, the minimal version has a much smaller footprint. The version below still meets the goal of allowing jffs2-on-block2mtd usage under uml but is much smaller because only the mtd core is included. Compile-tested on i386, x86_64, um/i386, and um/x86_64. > Instead, you should solve this problem in UML code. I do not know how, > but may be you can add readb/writeb there which actually do nothing or > print a scary warning, or do BUG(), and let things which use them just > fail run-time. Something like this could work, but it would be error-prone for anyone else who attempts using iomem-requiring drivers on uml. Instead of getting obvious compile failures we'd have broken drivers that BUG() or emit scary warnings. That doesn't seem to me like an improvement. Jason -- Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@acm.org> --- arch/um/Kconfig.rest | 4 +--- drivers/mtd/Kconfig | 7 +++++-- drivers/mtd/Makefile | 3 ++- drivers/mtd/mtdchar.c | 4 ++++ include/linux/mtd/map.h | 18 +++++++++--------- 5 files changed, 21 insertions(+), 15 deletions(-) diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest index 0ccad0f..e34f399 100644 --- a/arch/um/Kconfig.rest +++ b/arch/um/Kconfig.rest @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" source "drivers/leds/Kconfig" diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 1e2cbf5..7537654 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,6 +1,5 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -307,7 +306,7 @@ config SSFDC config SM_FTL tristate "SmartMedia/xD new translation layer" - depends on EXPERIMENTAL && BLOCK + depends on EXPERIMENTAL && BLOCK && HAS_IOMEM select MTD_BLKDEVS select MTD_NAND_ECC help @@ -330,6 +329,8 @@ config MTD_OOPS To use, add console=ttyMTDx to the kernel command line, where x is the MTD device number to use. +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" source "drivers/mtd/maps/Kconfig" @@ -342,6 +343,8 @@ source "drivers/mtd/onenand/Kconfig" source "drivers/mtd/lpddr/Kconfig" +endif # HAS_IOMEM + source "drivers/mtd/ubi/Kconfig" endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 760abc5..74a03bd 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ +obj-y += tests/ +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ maps/ devices/ nand/ onenand/ obj-$(CONFIG_MTD_UBI) += ubi/ diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c index 4759d82..a434354 100644 --- a/drivers/mtd/mtdchar.c +++ b/drivers/mtd/mtdchar.c @@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file, /* * set up a mapping for shared memory segments */ +#ifdef CONFIG_HAS_IOMEM static int mtd_mmap(struct file *file, struct vm_area_struct *vma) { #ifdef CONFIG_MMU @@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma) return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS; #endif } +#endif static const struct file_operations mtd_fops = { .owner = THIS_MODULE, @@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = { #endif .open = mtd_open, .release = mtd_close, +#ifdef CONFIG_HAS_IOMEM .mmap = mtd_mmap, +#endif #ifndef CONFIG_MMU .get_unmapped_area = mtd_get_unmapped_area, #endif diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h index a9e6ba4..3d9f7e0 100644 --- a/include/linux/mtd/map.h +++ b/include/linux/mtd/map.h @@ -388,6 +388,15 @@ static inline map_word map_word_ff(struct map_info *map) return r; } +#ifdef CONFIG_MTD_COMPLEX_MAPPINGS +#define map_read(map, ofs) (map)->read(map, ofs) +#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) +#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) +#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) + +extern void simple_map_init(struct map_info *); +#define map_is_linear(map) (map->phys != NO_XIP) + static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) { map_word r; @@ -440,15 +449,6 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co memcpy_toio(map->virt + to, from, len); } -#ifdef CONFIG_MTD_COMPLEX_MAPPINGS -#define map_read(map, ofs) (map)->read(map, ofs) -#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) -#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) -#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) - -extern void simple_map_init(struct map_info *); -#define map_is_linear(map) (map->phys != NO_XIP) - #else #define map_read(map, ofs) inline_map_read(map, ofs) #define map_copy_from(map, to, from, len) inline_map_copy_from(map, to, from, len) -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-14 19:51 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-14 19:51 UTC (permalink / raw) To: Artem Bityutskiy Cc: richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote: > But I think your solution is a bit dirty, because it adds a great deal > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. > This is error-prone. The intent of that patch was to allow as much of the mtd subsystem to compile as possible. My thinking was to try and rectify the fact that uml has gone without mtd (and hence jffs2) support for years even though much of it works just fine. I think the entire subsystem being marked BROKEN in kconfig kept anyone from experimenting with it. The patch I sent was actually a reaction to feedback I got from Sam Ravnborg on my last attempt (um, three years ago :/ ) in which he suggested pushing down the ifdefs closer to their points of use. But I agree, the minimal version has a much smaller footprint. The version below still meets the goal of allowing jffs2-on-block2mtd usage under uml but is much smaller because only the mtd core is included. Compile-tested on i386, x86_64, um/i386, and um/x86_64. > Instead, you should solve this problem in UML code. I do not know how, > but may be you can add readb/writeb there which actually do nothing or > print a scary warning, or do BUG(), and let things which use them just > fail run-time. Something like this could work, but it would be error-prone for anyone else who attempts using iomem-requiring drivers on uml. Instead of getting obvious compile failures we'd have broken drivers that BUG() or emit scary warnings. That doesn't seem to me like an improvement. Jason -- Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@acm.org> --- arch/um/Kconfig.rest | 4 +--- drivers/mtd/Kconfig | 7 +++++-- drivers/mtd/Makefile | 3 ++- drivers/mtd/mtdchar.c | 4 ++++ include/linux/mtd/map.h | 18 +++++++++--------- 5 files changed, 21 insertions(+), 15 deletions(-) diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest index 0ccad0f..e34f399 100644 --- a/arch/um/Kconfig.rest +++ b/arch/um/Kconfig.rest @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" source "drivers/leds/Kconfig" diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 1e2cbf5..7537654 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,6 +1,5 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -307,7 +306,7 @@ config SSFDC config SM_FTL tristate "SmartMedia/xD new translation layer" - depends on EXPERIMENTAL && BLOCK + depends on EXPERIMENTAL && BLOCK && HAS_IOMEM select MTD_BLKDEVS select MTD_NAND_ECC help @@ -330,6 +329,8 @@ config MTD_OOPS To use, add console=ttyMTDx to the kernel command line, where x is the MTD device number to use. +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" source "drivers/mtd/maps/Kconfig" @@ -342,6 +343,8 @@ source "drivers/mtd/onenand/Kconfig" source "drivers/mtd/lpddr/Kconfig" +endif # HAS_IOMEM + source "drivers/mtd/ubi/Kconfig" endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 760abc5..74a03bd 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ +obj-y += tests/ +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ maps/ devices/ nand/ onenand/ obj-$(CONFIG_MTD_UBI) += ubi/ diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c index 4759d82..a434354 100644 --- a/drivers/mtd/mtdchar.c +++ b/drivers/mtd/mtdchar.c @@ -1075,6 +1075,7 @@ static unsigned long mtd_get_unmapped_area(struct file *file, /* * set up a mapping for shared memory segments */ +#ifdef CONFIG_HAS_IOMEM static int mtd_mmap(struct file *file, struct vm_area_struct *vma) { #ifdef CONFIG_MMU @@ -1113,6 +1114,7 @@ static int mtd_mmap(struct file *file, struct vm_area_struct *vma) return vma->vm_flags & VM_SHARED ? 0 : -ENOSYS; #endif } +#endif static const struct file_operations mtd_fops = { .owner = THIS_MODULE, @@ -1125,7 +1127,9 @@ static const struct file_operations mtd_fops = { #endif .open = mtd_open, .release = mtd_close, +#ifdef CONFIG_HAS_IOMEM .mmap = mtd_mmap, +#endif #ifndef CONFIG_MMU .get_unmapped_area = mtd_get_unmapped_area, #endif diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h index a9e6ba4..3d9f7e0 100644 --- a/include/linux/mtd/map.h +++ b/include/linux/mtd/map.h @@ -388,6 +388,15 @@ static inline map_word map_word_ff(struct map_info *map) return r; } +#ifdef CONFIG_MTD_COMPLEX_MAPPINGS +#define map_read(map, ofs) (map)->read(map, ofs) +#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) +#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) +#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) + +extern void simple_map_init(struct map_info *); +#define map_is_linear(map) (map->phys != NO_XIP) + static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) { map_word r; @@ -440,15 +449,6 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co memcpy_toio(map->virt + to, from, len); } -#ifdef CONFIG_MTD_COMPLEX_MAPPINGS -#define map_read(map, ofs) (map)->read(map, ofs) -#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) -#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) -#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) - -extern void simple_map_init(struct map_info *); -#define map_is_linear(map) (map->phys != NO_XIP) - #else #define map_read(map, ofs) inline_map_read(map, ofs) #define map_copy_from(map, to, from, len) inline_map_copy_from(map, to, from, len) -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 19:51 ` Jason Lunz @ 2010-12-14 20:01 ` Artem Bityutskiy -1 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-14 20:01 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote: > On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote: > > But I think your solution is a bit dirty, because it adds a great deal > > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. > > This is error-prone. > > The intent of that patch was to allow as much of the mtd subsystem to > compile as possible. My thinking was to try and rectify the fact that > uml has gone without mtd (and hence jffs2) support for years even though > much of it works just fine. I think the entire subsystem being marked > BROKEN in kconfig kept anyone from experimenting with it. > > The patch I sent was actually a reaction to feedback I got from Sam > Ravnborg on my last attempt (um, three years ago :/ ) in which he > suggested pushing down the ifdefs closer to their points of use. But I > agree, the minimal version has a much smaller footprint. > > The version below still meets the goal of allowing jffs2-on-block2mtd > usage under uml but is much smaller because only the mtd core is > included. Compile-tested on i386, x86_64, um/i386, and um/x86_64. > > > Instead, you should solve this problem in UML code. I do not know how, > > but may be you can add readb/writeb there which actually do nothing or > > print a scary warning, or do BUG(), and let things which use them just > > fail run-time. > > Something like this could work, but it would be error-prone for anyone > else who attempts using iomem-requiring drivers on uml. Instead of > getting obvious compile failures we'd have broken drivers that BUG() or > emit scary warnings. That doesn't seem to me like an improvement. This problem does not seem to be mtd-specific, right? So my point was that it would be nicer to come up with a general solution. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-14 20:01 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-14 20:01 UTC (permalink / raw) To: Jason Lunz Cc: richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote: > On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote: > > But I think your solution is a bit dirty, because it adds a great deal > > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. > > This is error-prone. > > The intent of that patch was to allow as much of the mtd subsystem to > compile as possible. My thinking was to try and rectify the fact that > uml has gone without mtd (and hence jffs2) support for years even though > much of it works just fine. I think the entire subsystem being marked > BROKEN in kconfig kept anyone from experimenting with it. > > The patch I sent was actually a reaction to feedback I got from Sam > Ravnborg on my last attempt (um, three years ago :/ ) in which he > suggested pushing down the ifdefs closer to their points of use. But I > agree, the minimal version has a much smaller footprint. > > The version below still meets the goal of allowing jffs2-on-block2mtd > usage under uml but is much smaller because only the mtd core is > included. Compile-tested on i386, x86_64, um/i386, and um/x86_64. > > > Instead, you should solve this problem in UML code. I do not know how, > > but may be you can add readb/writeb there which actually do nothing or > > print a scary warning, or do BUG(), and let things which use them just > > fail run-time. > > Something like this could work, but it would be error-prone for anyone > else who attempts using iomem-requiring drivers on uml. Instead of > getting obvious compile failures we'd have broken drivers that BUG() or > emit scary warnings. That doesn't seem to me like an improvement. This problem does not seem to be mtd-specific, right? So my point was that it would be nicer to come up with a general solution. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 20:01 ` Artem Bityutskiy @ 2010-12-14 21:12 ` Geert Uytterhoeven -1 siblings, 0 replies; 63+ messages in thread From: Geert Uytterhoeven @ 2010-12-14 21:12 UTC (permalink / raw) To: dedekind1 Cc: atom ota, user-mode-linux-devel, richard -rw- weinberger, David Woodhouse, Jeff Dike, Jason Lunz, lkml, linux-mtd, Rob Landley, Sam Ravnborg On Tue, Dec 14, 2010 at 21:01, Artem Bityutskiy <dedekind1@gmail.com> wrote: > On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote: >> On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote: >> > But I think your solution is a bit dirty, because it adds a great deal >> > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. >> > This is error-prone. >> >> The intent of that patch was to allow as much of the mtd subsystem to >> compile as possible. My thinking was to try and rectify the fact that >> uml has gone without mtd (and hence jffs2) support for years even though >> much of it works just fine. I think the entire subsystem being marked >> BROKEN in kconfig kept anyone from experimenting with it. >> >> The patch I sent was actually a reaction to feedback I got from Sam >> Ravnborg on my last attempt (um, three years ago :/ ) in which he >> suggested pushing down the ifdefs closer to their points of use. But I >> agree, the minimal version has a much smaller footprint. >> >> The version below still meets the goal of allowing jffs2-on-block2mtd >> usage under uml but is much smaller because only the mtd core is >> included. Compile-tested on i386, x86_64, um/i386, and um/x86_64. >> >> > Instead, you should solve this problem in UML code. I do not know how, >> > but may be you can add readb/writeb there which actually do nothing or >> > print a scary warning, or do BUG(), and let things which use them just >> > fail run-time. >> >> Something like this could work, but it would be error-prone for anyone >> else who attempts using iomem-requiring drivers on uml. Instead of >> getting obvious compile failures we'd have broken drivers that BUG() or >> emit scary warnings. That doesn't seem to me like an improvement. > > This problem does not seem to be mtd-specific, right? So my point was > that it would be nicer to come up with a general solution. The generic solution for stuff that needs I/O operations is to mark it "depends on HAS_IOMEM". I used a similar patch in the past, IIRC to try axfs on UML. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-14 21:12 ` Geert Uytterhoeven 0 siblings, 0 replies; 63+ messages in thread From: Geert Uytterhoeven @ 2010-12-14 21:12 UTC (permalink / raw) To: dedekind1 Cc: Jason Lunz, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, Dec 14, 2010 at 21:01, Artem Bityutskiy <dedekind1@gmail.com> wrote: > On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote: >> On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote: >> > But I think your solution is a bit dirty, because it adds a great deal >> > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. >> > This is error-prone. >> >> The intent of that patch was to allow as much of the mtd subsystem to >> compile as possible. My thinking was to try and rectify the fact that >> uml has gone without mtd (and hence jffs2) support for years even though >> much of it works just fine. I think the entire subsystem being marked >> BROKEN in kconfig kept anyone from experimenting with it. >> >> The patch I sent was actually a reaction to feedback I got from Sam >> Ravnborg on my last attempt (um, three years ago :/ ) in which he >> suggested pushing down the ifdefs closer to their points of use. But I >> agree, the minimal version has a much smaller footprint. >> >> The version below still meets the goal of allowing jffs2-on-block2mtd >> usage under uml but is much smaller because only the mtd core is >> included. Compile-tested on i386, x86_64, um/i386, and um/x86_64. >> >> > Instead, you should solve this problem in UML code. I do not know how, >> > but may be you can add readb/writeb there which actually do nothing or >> > print a scary warning, or do BUG(), and let things which use them just >> > fail run-time. >> >> Something like this could work, but it would be error-prone for anyone >> else who attempts using iomem-requiring drivers on uml. Instead of >> getting obvious compile failures we'd have broken drivers that BUG() or >> emit scary warnings. That doesn't seem to me like an improvement. > > This problem does not seem to be mtd-specific, right? So my point was > that it would be nicer to come up with a general solution. The generic solution for stuff that needs I/O operations is to mark it "depends on HAS_IOMEM". I used a similar patch in the past, IIRC to try axfs on UML. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 20:01 ` Artem Bityutskiy @ 2010-12-14 21:23 ` Jason Lunz -1 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-14 21:23 UTC (permalink / raw) To: Artem Bityutskiy Cc: atom ota, user-mode-linux-devel, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On one hand you've got uml, which simply doesn't have mmio. On the other there's mtd, which began as a method for accessing hardware devices that are often accessed using mmio. But then the mtd subsystem developed emulations of that hardware that are software based and thus don't require mmio. It's mainly these emulated backends I'm interested in exposing. Nothing is going to change so that it makes sense to have any real mmio-using hardware driver run on uml. The question you raise is, are there other classes of driver with a software-only subset that can be exposed on uml? And if so, would adding stub implementations of readb/writeb and friends actually be enough to make those work? I'm not aware of any, so at present I don't think the argument for implementing this in uml arch code is very strong. Or in other words, I don't think a "general solution" would be very general. Jason On Tue, Dec 14, 2010 at 10:01:33PM +0200, Artem Bityutskiy wrote: > This problem does not seem to be mtd-specific, right? So my point was > that it would be nicer to come up with a general solution. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-14 21:23 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-14 21:23 UTC (permalink / raw) To: Artem Bityutskiy Cc: richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On one hand you've got uml, which simply doesn't have mmio. On the other there's mtd, which began as a method for accessing hardware devices that are often accessed using mmio. But then the mtd subsystem developed emulations of that hardware that are software based and thus don't require mmio. It's mainly these emulated backends I'm interested in exposing. Nothing is going to change so that it makes sense to have any real mmio-using hardware driver run on uml. The question you raise is, are there other classes of driver with a software-only subset that can be exposed on uml? And if so, would adding stub implementations of readb/writeb and friends actually be enough to make those work? I'm not aware of any, so at present I don't think the argument for implementing this in uml arch code is very strong. Or in other words, I don't think a "general solution" would be very general. Jason On Tue, Dec 14, 2010 at 10:01:33PM +0200, Artem Bityutskiy wrote: > This problem does not seem to be mtd-specific, right? So my point was > that it would be nicer to come up with a general solution. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 21:23 ` Jason Lunz @ 2010-12-15 0:40 ` Rob Landley -1 siblings, 0 replies; 63+ messages in thread From: Rob Landley @ 2010-12-15 0:40 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, Artem Bityutskiy, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, David Woodhouse On Tuesday 14 December 2010 15:23:49 Jason Lunz wrote: > On one hand you've got uml, which simply doesn't have mmio. On the other > there's mtd, which began as a method for accessing hardware devices that > are often accessed using mmio. But then the mtd subsystem developed > emulations of that hardware that are software based and thus don't > require mmio. It's mainly these emulated backends I'm interested in > exposing. > > Nothing is going to change so that it makes sense to have any real > mmio-using hardware driver run on uml. The question you raise is, are > there other classes of driver with a software-only subset that can be > exposed on uml? And if so, would adding stub implementations of > readb/writeb and friends actually be enough to make those work? I'm not > aware of any, so at present I don't think the argument for implementing > this in uml arch code is very strong. Or in other words, I don't think a > "general solution" would be very general. For what it's worth, QEMU had replaced all my use cases for UML in the past few years. If I wanted to play with loopback mounting jffs2 I'd build a kernel to run under QEMU, and have that emulate the flash. Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-15 0:40 ` Rob Landley 0 siblings, 0 replies; 63+ messages in thread From: Rob Landley @ 2010-12-15 0:40 UTC (permalink / raw) To: Jason Lunz Cc: Artem Bityutskiy, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd On Tuesday 14 December 2010 15:23:49 Jason Lunz wrote: > On one hand you've got uml, which simply doesn't have mmio. On the other > there's mtd, which began as a method for accessing hardware devices that > are often accessed using mmio. But then the mtd subsystem developed > emulations of that hardware that are software based and thus don't > require mmio. It's mainly these emulated backends I'm interested in > exposing. > > Nothing is going to change so that it makes sense to have any real > mmio-using hardware driver run on uml. The question you raise is, are > there other classes of driver with a software-only subset that can be > exposed on uml? And if so, would adding stub implementations of > readb/writeb and friends actually be enough to make those work? I'm not > aware of any, so at present I don't think the argument for implementing > this in uml arch code is very strong. Or in other words, I don't think a > "general solution" would be very general. For what it's worth, QEMU had replaced all my use cases for UML in the past few years. If I wanted to play with loopback mounting jffs2 I'd build a kernel to run under QEMU, and have that emulate the flash. Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 20:01 ` Artem Bityutskiy @ 2010-12-15 0:49 ` Rob Landley -1 siblings, 0 replies; 63+ messages in thread From: Rob Landley @ 2010-12-15 0:49 UTC (permalink / raw) To: dedekind1 Cc: atom ota, user-mode-linux-devel, richard -rw- weinberger, David Woodhouse, Jeff Dike, Jason Lunz, lkml, linux-mtd, Sam Ravnborg On Tuesday 14 December 2010 14:01:33 Artem Bityutskiy wrote: > > > Instead, you should solve this problem in UML code. I do not know how, > > > but may be you can add readb/writeb there which actually do nothing or > > > print a scary warning, or do BUG(), and let things which use them just > > > fail run-time. > > > > Something like this could work, but it would be error-prone for anyone > > else who attempts using iomem-requiring drivers on uml. Instead of > > getting obvious compile failures we'd have broken drivers that BUG() or > > emit scary warnings. That doesn't seem to me like an improvement. > > This problem does not seem to be mtd-specific, right? So my point was > that it would be nicer to come up with a general solution. The problem is that jffs2 is a filesystem, and thus something people would really like to be able to loopback mount, but it's hardwired to assume it's only ever stored on a certain type of hardware, and thus requies incestuous knowledge of the erase granularity of the flash layer in order to function. It would be really nice to have either the loopback driver or jffs2 be able to fake the mtd thing with some kind of "granularity=262144" option to let it know "you're not on flash right now, but the flash you'll eventually be on is X". This might require padding the image at the beginning and being mounted with an offset if the filesystem doesn't start at the beginning of an erase block when copied to the final hardware, but losetup already supports offsets. What any of this has to do with UML is an open question. I don't want to require UML to loopback mount a jffs2 image, I want to be able to do it from my host. From my perspective, you're solving the wrong problem. Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-15 0:49 ` Rob Landley 0 siblings, 0 replies; 63+ messages in thread From: Rob Landley @ 2010-12-15 0:49 UTC (permalink / raw) To: dedekind1 Cc: Jason Lunz, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd On Tuesday 14 December 2010 14:01:33 Artem Bityutskiy wrote: > > > Instead, you should solve this problem in UML code. I do not know how, > > > but may be you can add readb/writeb there which actually do nothing or > > > print a scary warning, or do BUG(), and let things which use them just > > > fail run-time. > > > > Something like this could work, but it would be error-prone for anyone > > else who attempts using iomem-requiring drivers on uml. Instead of > > getting obvious compile failures we'd have broken drivers that BUG() or > > emit scary warnings. That doesn't seem to me like an improvement. > > This problem does not seem to be mtd-specific, right? So my point was > that it would be nicer to come up with a general solution. The problem is that jffs2 is a filesystem, and thus something people would really like to be able to loopback mount, but it's hardwired to assume it's only ever stored on a certain type of hardware, and thus requies incestuous knowledge of the erase granularity of the flash layer in order to function. It would be really nice to have either the loopback driver or jffs2 be able to fake the mtd thing with some kind of "granularity=262144" option to let it know "you're not on flash right now, but the flash you'll eventually be on is X". This might require padding the image at the beginning and being mounted with an offset if the filesystem doesn't start at the beginning of an erase block when copied to the final hardware, but losetup already supports offsets. What any of this has to do with UML is an open question. I don't want to require UML to loopback mount a jffs2 image, I want to be able to do it from my host. From my perspective, you're solving the wrong problem. Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-15 0:49 ` Rob Landley @ 2010-12-15 1:19 ` Jason Lunz -1 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-15 1:19 UTC (permalink / raw) To: Rob Landley Cc: atom ota, user-mode-linux-devel, dedekind1, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, David Woodhouse On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote: > The problem is that jffs2 is a filesystem, and thus something people would > really like to be able to loopback mount, but it's hardwired to assume it's > only ever stored on a certain type of hardware, and thus requies incestuous > knowledge of the erase granularity of the flash layer in order to function. I assume you can turn your jffs2 image file into a block dev using losetup, then turn the corresponding loop device into an mtd device using block2mtd, at which point you ought to be able to mount it with jffs2. I've never tried it. > What any of this has to do with UML is an open question. I don't want to > require UML to loopback mount a jffs2 image, I want to be able to do it from my > host. From my perspective, you're solving the wrong problem. There's more than just loopback-mounting jffs2 images. I use this to make entire uml+jffs2 virtual machines for testing purposes. Jason ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-15 1:19 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-15 1:19 UTC (permalink / raw) To: Rob Landley Cc: dedekind1, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote: > The problem is that jffs2 is a filesystem, and thus something people would > really like to be able to loopback mount, but it's hardwired to assume it's > only ever stored on a certain type of hardware, and thus requies incestuous > knowledge of the erase granularity of the flash layer in order to function. I assume you can turn your jffs2 image file into a block dev using losetup, then turn the corresponding loop device into an mtd device using block2mtd, at which point you ought to be able to mount it with jffs2. I've never tried it. > What any of this has to do with UML is an open question. I don't want to > require UML to loopback mount a jffs2 image, I want to be able to do it from my > host. From my perspective, you're solving the wrong problem. There's more than just loopback-mounting jffs2 images. I use this to make entire uml+jffs2 virtual machines for testing purposes. Jason ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-15 1:19 ` Jason Lunz @ 2010-12-15 6:31 ` Rob Landley -1 siblings, 0 replies; 63+ messages in thread From: Rob Landley @ 2010-12-15 6:31 UTC (permalink / raw) To: Jason Lunz, Denys Vlasenko Cc: atom ota, user-mode-linux-devel, dedekind1, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, David Woodhouse On Tuesday 14 December 2010 19:19:05 Jason Lunz wrote: > On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote: > > The problem is that jffs2 is a filesystem, and thus something people > > would really like to be able to loopback mount, but it's hardwired to > > assume it's only ever stored on a certain type of hardware, and thus > > requies incestuous knowledge of the erase granularity of the flash layer > > in order to function. > > I assume you can turn your jffs2 image file into a block dev using > losetup, then turn the corresponding loop device into an mtd device > using block2mtd, at which point you ought to be able to mount it with > jffs2. I've never tried it. That is awesome and I'm not finding any documentation on it... Ah: http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_MTD_device Wow that's awkward. Let's see, that says... mknod /tmp/mtdblock0 b 31 0 modprobe loop losetup /dev/loop0 rootfs.jffs2 modprobe mtdblock modprobe block2mtd # Note the ,128KiB is needed (on 2.6.26 at least) to set the # eraseblock size. echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd modprobe jffs2 mount -t jffs2 /tmp/mtdblock0 /media/jffs2 So the system isn't automatically loading mtdblock, udev isn't creating any /dev nodes for it even thought it is for loop, the associations are created by writing strings into a filesystem with a _notoriously_ unstable API (and it expects a three letter mixed case suffix to specify units), and despite "mtdblock0" I have no idea how that echo syntax would specify more than one association at a time. I'm trying to figure out whether creating a shell script for this or trying to modify the busybox mount command would be a better approach to beating some sort of usability out of doing this. Hmmm, mkfs.jffs2 is named as a mkfs but acts a a generator ala genext2fs. How about... mkdir empty mkfs.jffs2 -r empty -o rootfs.jffs2 -e 128 -l -n And it created an empty (zero byte) file. That's nice. If I touch a file in "empty" now 116 bytes. Adding -p makes it one erase block, but adding "-p 2048" doesn't specify a multiple of the erase block size, it instead rounded rounded it _down_ to that many bytes. But --pad=$((2048*1024*1024)) was apparently ignored...? How do I specify a _size_ for this thing so it has empty space I can write into after the fact? (The man page says pad with 0xFF. Am I going to have to do this by hand?) mkdir empty touch empty/hello mkfs.jffs2 -r empty -o temp.jffs2 -e 128 -l -n -p python -c "import sys; sys.stdout.write(131072*63*chr(0xff))" >> temp.jffs2 losetup /dev/loop0 temp.jffs2 echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd mount -t jffs2 mtdblock0 empty Yay! I have a filesystem! And df claims it's 8 megabytes. Woot. > > What any of this has to do with UML is an open question. I don't want to > > require UML to loopback mount a jffs2 image, I want to be able to do it > > from my host. From my perspective, you're solving the wrong problem. > > There's more than just loopback-mounting jffs2 images. I use this to > make entire uml+jffs2 virtual machines for testing purposes. As I said, I'm almost exclusively using qemu/kvm these days, but this is fun... > Jason Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-15 6:31 ` Rob Landley 0 siblings, 0 replies; 63+ messages in thread From: Rob Landley @ 2010-12-15 6:31 UTC (permalink / raw) To: Jason Lunz, Denys Vlasenko Cc: dedekind1, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd On Tuesday 14 December 2010 19:19:05 Jason Lunz wrote: > On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote: > > The problem is that jffs2 is a filesystem, and thus something people > > would really like to be able to loopback mount, but it's hardwired to > > assume it's only ever stored on a certain type of hardware, and thus > > requies incestuous knowledge of the erase granularity of the flash layer > > in order to function. > > I assume you can turn your jffs2 image file into a block dev using > losetup, then turn the corresponding loop device into an mtd device > using block2mtd, at which point you ought to be able to mount it with > jffs2. I've never tried it. That is awesome and I'm not finding any documentation on it... Ah: http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_MTD_device Wow that's awkward. Let's see, that says... mknod /tmp/mtdblock0 b 31 0 modprobe loop losetup /dev/loop0 rootfs.jffs2 modprobe mtdblock modprobe block2mtd # Note the ,128KiB is needed (on 2.6.26 at least) to set the # eraseblock size. echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd modprobe jffs2 mount -t jffs2 /tmp/mtdblock0 /media/jffs2 So the system isn't automatically loading mtdblock, udev isn't creating any /dev nodes for it even thought it is for loop, the associations are created by writing strings into a filesystem with a _notoriously_ unstable API (and it expects a three letter mixed case suffix to specify units), and despite "mtdblock0" I have no idea how that echo syntax would specify more than one association at a time. I'm trying to figure out whether creating a shell script for this or trying to modify the busybox mount command would be a better approach to beating some sort of usability out of doing this. Hmmm, mkfs.jffs2 is named as a mkfs but acts a a generator ala genext2fs. How about... mkdir empty mkfs.jffs2 -r empty -o rootfs.jffs2 -e 128 -l -n And it created an empty (zero byte) file. That's nice. If I touch a file in "empty" now 116 bytes. Adding -p makes it one erase block, but adding "-p 2048" doesn't specify a multiple of the erase block size, it instead rounded rounded it _down_ to that many bytes. But --pad=$((2048*1024*1024)) was apparently ignored...? How do I specify a _size_ for this thing so it has empty space I can write into after the fact? (The man page says pad with 0xFF. Am I going to have to do this by hand?) mkdir empty touch empty/hello mkfs.jffs2 -r empty -o temp.jffs2 -e 128 -l -n -p python -c "import sys; sys.stdout.write(131072*63*chr(0xff))" >> temp.jffs2 losetup /dev/loop0 temp.jffs2 echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd mount -t jffs2 mtdblock0 empty Yay! I have a filesystem! And df claims it's 8 megabytes. Woot. > > What any of this has to do with UML is an open question. I don't want to > > require UML to loopback mount a jffs2 image, I want to be able to do it > > from my host. From my perspective, you're solving the wrong problem. > > There's more than just loopback-mounting jffs2 images. I use this to > make entire uml+jffs2 virtual machines for testing purposes. As I said, I'm almost exclusively using qemu/kvm these days, but this is fun... > Jason Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-15 6:31 ` Rob Landley @ 2010-12-16 15:18 ` Artem Bityutskiy -1 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-16 15:18 UTC (permalink / raw) To: Rob Landley Cc: atom ota, user-mode-linux-devel, Denys Vlasenko, Sam Ravnborg, Jeff Dike, Jason Lunz, lkml, richard -rw- weinberger, linux-mtd, David Woodhouse On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote: > That is awesome and I'm not finding any documentation on it... Ah: > > http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_MTD_device > > Wow that's awkward. Let's see, that says... > > mknod /tmp/mtdblock0 b 31 0 > modprobe loop > losetup /dev/loop0 rootfs.jffs2 > modprobe mtdblock > modprobe block2mtd > # Note the ,128KiB is needed (on 2.6.26 at least) to set the > # eraseblock size. > echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd > modprobe jffs2 > mount -t jffs2 /tmp/mtdblock0 /media/jffs2 You should not need mtdblock in modern kernels, it is legacy. You should be abole to mount jffs2 on top of mtd0 with mount -t jffs2 mtd0 /media/jffs2 -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-16 15:18 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-16 15:18 UTC (permalink / raw) To: Rob Landley Cc: Jason Lunz, Denys Vlasenko, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote: > That is awesome and I'm not finding any documentation on it... Ah: > > http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_MTD_device > > Wow that's awkward. Let's see, that says... > > mknod /tmp/mtdblock0 b 31 0 > modprobe loop > losetup /dev/loop0 rootfs.jffs2 > modprobe mtdblock > modprobe block2mtd > # Note the ,128KiB is needed (on 2.6.26 at least) to set the > # eraseblock size. > echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd > modprobe jffs2 > mount -t jffs2 /tmp/mtdblock0 /media/jffs2 You should not need mtdblock in modern kernels, it is legacy. You should be abole to mount jffs2 on top of mtd0 with mount -t jffs2 mtd0 /media/jffs2 -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-16 15:18 ` Artem Bityutskiy @ 2010-12-18 4:08 ` Rob Landley -1 siblings, 0 replies; 63+ messages in thread From: Rob Landley @ 2010-12-18 4:08 UTC (permalink / raw) To: dedekind1 Cc: atom ota, user-mode-linux-devel, Denys Vlasenko, Sam Ravnborg, Jeff Dike, Jason Lunz, lkml, richard -rw- weinberger, linux-mtd, David Woodhouse On Thursday 16 December 2010 09:18:31 Artem Bityutskiy wrote: > On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote: > > That is awesome and I'm not finding any documentation on it... Ah: > > > > > > http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_ > >MTD_device > > > > Wow that's awkward. Let's see, that says... > > > > mknod /tmp/mtdblock0 b 31 0 > > modprobe loop > > losetup /dev/loop0 rootfs.jffs2 > > modprobe mtdblock > > modprobe block2mtd > > # Note the ,128KiB is needed (on 2.6.26 at least) to set the > > # eraseblock size. > > echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd > > modprobe jffs2 > > mount -t jffs2 /tmp/mtdblock0 /media/jffs2 > > You should not need mtdblock in modern kernels, it is legacy. You should > be abole to mount jffs2 on top of mtd0 with > > mount -t jffs2 mtd0 /media/jffs2 How does one associate the mtd0 with the loopback device? (I thought mtd0 was for actual flash memory.) Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-18 4:08 ` Rob Landley 0 siblings, 0 replies; 63+ messages in thread From: Rob Landley @ 2010-12-18 4:08 UTC (permalink / raw) To: dedekind1 Cc: Jason Lunz, Denys Vlasenko, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd On Thursday 16 December 2010 09:18:31 Artem Bityutskiy wrote: > On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote: > > That is awesome and I'm not finding any documentation on it... Ah: > > > > > > http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_ > >MTD_device > > > > Wow that's awkward. Let's see, that says... > > > > mknod /tmp/mtdblock0 b 31 0 > > modprobe loop > > losetup /dev/loop0 rootfs.jffs2 > > modprobe mtdblock > > modprobe block2mtd > > # Note the ,128KiB is needed (on 2.6.26 at least) to set the > > # eraseblock size. > > echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd > > modprobe jffs2 > > mount -t jffs2 /tmp/mtdblock0 /media/jffs2 > > You should not need mtdblock in modern kernels, it is legacy. You should > be abole to mount jffs2 on top of mtd0 with > > mount -t jffs2 mtd0 /media/jffs2 How does one associate the mtd0 with the loopback device? (I thought mtd0 was for actual flash memory.) Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-18 4:08 ` Rob Landley @ 2010-12-19 17:08 ` Artem Bityutskiy -1 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-19 17:08 UTC (permalink / raw) To: Rob Landley Cc: atom ota, user-mode-linux-devel, Denys Vlasenko, Sam Ravnborg, Jeff Dike, Jason Lunz, lkml, richard -rw- weinberger, linux-mtd, David Woodhouse On Fri, 2010-12-17 at 22:08 -0600, Rob Landley wrote: > On Thursday 16 December 2010 09:18:31 Artem Bityutskiy wrote: > > On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote: > > > That is awesome and I'm not finding any documentation on it... Ah: > > > > > > > > > http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_ > > >MTD_device > > > > > > Wow that's awkward. Let's see, that says... > > > > > > mknod /tmp/mtdblock0 b 31 0 > > > modprobe loop > > > losetup /dev/loop0 rootfs.jffs2 > > > modprobe mtdblock > > > modprobe block2mtd > > > # Note the ,128KiB is needed (on 2.6.26 at least) to set the > > > # eraseblock size. > > > echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd > > > modprobe jffs2 > > > mount -t jffs2 /tmp/mtdblock0 /media/jffs2 > > > > You should not need mtdblock in modern kernels, it is legacy. You should > > be abole to mount jffs2 on top of mtd0 with > > > > mount -t jffs2 mtd0 /media/jffs2 > > How does one associate the mtd0 with the loopback device? (I thought mtd0 was > for actual flash memory.) You do not need loopback devices, just flash your rootfs.jffs2 directly to /dev/mtd0, e.g., with nandwrite. You can emulate nand with nandsim. But your method should also work, I just wanted to point that JFFS2 does not depend on mtdblock in any way. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-19 17:08 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-19 17:08 UTC (permalink / raw) To: Rob Landley Cc: Jason Lunz, Denys Vlasenko, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd On Fri, 2010-12-17 at 22:08 -0600, Rob Landley wrote: > On Thursday 16 December 2010 09:18:31 Artem Bityutskiy wrote: > > On Wed, 2010-12-15 at 00:31 -0600, Rob Landley wrote: > > > That is awesome and I'm not finding any documentation on it... Ah: > > > > > > > > > http://wiki.maemo.org/Modifying_the_root_image#Block_device_emulating_an_ > > >MTD_device > > > > > > Wow that's awkward. Let's see, that says... > > > > > > mknod /tmp/mtdblock0 b 31 0 > > > modprobe loop > > > losetup /dev/loop0 rootfs.jffs2 > > > modprobe mtdblock > > > modprobe block2mtd > > > # Note the ,128KiB is needed (on 2.6.26 at least) to set the > > > # eraseblock size. > > > echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd > > > modprobe jffs2 > > > mount -t jffs2 /tmp/mtdblock0 /media/jffs2 > > > > You should not need mtdblock in modern kernels, it is legacy. You should > > be abole to mount jffs2 on top of mtd0 with > > > > mount -t jffs2 mtd0 /media/jffs2 > > How does one associate the mtd0 with the loopback device? (I thought mtd0 was > for actual flash memory.) You do not need loopback devices, just flash your rootfs.jffs2 directly to /dev/mtd0, e.g., with nandwrite. You can emulate nand with nandsim. But your method should also work, I just wanted to point that JFFS2 does not depend on mtdblock in any way. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-15 1:19 ` Jason Lunz @ 2010-12-15 8:18 ` Geert Uytterhoeven -1 siblings, 0 replies; 63+ messages in thread From: Geert Uytterhoeven @ 2010-12-15 8:18 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, dedekind1, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse [-- Attachment #1: Type: text/plain, Size: 1310 bytes --] On Wed, Dec 15, 2010 at 02:19, Jason Lunz <lunz@acm.org> wrote: > On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote: >> The problem is that jffs2 is a filesystem, and thus something people would >> really like to be able to loopback mount, but it's hardwired to assume it's >> only ever stored on a certain type of hardware, and thus requies incestuous >> knowledge of the erase granularity of the flash layer in order to function. > > I assume you can turn your jffs2 image file into a block dev using > losetup, then turn the corresponding loop device into an mtd device > using block2mtd, at which point you ought to be able to mount it with > jffs2. I've never tried it. And block2mtd is part of mtd, so you have to get mtd compiled first. BTW, the patch I used in the past was less intrusive than yours. I attached it, as I can't send it inline from here. Note that it was against 2.6.31-rc4. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds [-- Attachment #2: uml-mtd.diff --] [-- Type: text/x-patch, Size: 3089 bytes --] commit 57fce0f17f497583266a26328690f40f33af08c5 Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Date: Mon Dec 15 15:21:15 2008 +0100 UML: Enable MTD, by moving the dependency on HAS_IOMEM Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest index 0ccad0f..e34f399 100644 --- a/arch/um/Kconfig.rest +++ b/arch/um/Kconfig.rest @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" source "drivers/leds/Kconfig" diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index b8e35a0..052b00c 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,6 +1,5 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -315,15 +314,17 @@ config MTD_OOPS To use, add console=ttyMTDx to the kernel command line, where x is the MTD device number to use. -source "drivers/mtd/chips/Kconfig" - -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/lpddr/Kconfig" diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 82d1e4d..09fb548 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ +obj-y += devices/ tests/ +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ maps/ nand/ onenand/ obj-$(CONFIG_MTD_UBI) += ubi/ diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig index 325fab9..88937d6 100644 --- a/drivers/mtd/devices/Kconfig +++ b/drivers/mtd/devices/Kconfig @@ -106,6 +106,7 @@ config M25PXX_USE_FAST_READ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -113,6 +114,7 @@ config MTD_SLRAM config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -179,6 +181,7 @@ config MTD_BLOCK2MTD Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" config MTD_DOC2000 @@ -297,5 +300,6 @@ config MTD_DOCPROBE_55AA LinuxBIOS or if you need to recover a DiskOnChip Millennium on which you have managed to wipe the first block. +endif endmenu ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-15 8:18 ` Geert Uytterhoeven 0 siblings, 0 replies; 63+ messages in thread From: Geert Uytterhoeven @ 2010-12-15 8:18 UTC (permalink / raw) To: Jason Lunz Cc: Rob Landley, dedekind1, richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd [-- Attachment #1: Type: text/plain, Size: 1310 bytes --] On Wed, Dec 15, 2010 at 02:19, Jason Lunz <lunz@acm.org> wrote: > On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote: >> The problem is that jffs2 is a filesystem, and thus something people would >> really like to be able to loopback mount, but it's hardwired to assume it's >> only ever stored on a certain type of hardware, and thus requies incestuous >> knowledge of the erase granularity of the flash layer in order to function. > > I assume you can turn your jffs2 image file into a block dev using > losetup, then turn the corresponding loop device into an mtd device > using block2mtd, at which point you ought to be able to mount it with > jffs2. I've never tried it. And block2mtd is part of mtd, so you have to get mtd compiled first. BTW, the patch I used in the past was less intrusive than yours. I attached it, as I can't send it inline from here. Note that it was against 2.6.31-rc4. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds [-- Attachment #2: uml-mtd.diff --] [-- Type: text/x-patch, Size: 3089 bytes --] commit 57fce0f17f497583266a26328690f40f33af08c5 Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Date: Mon Dec 15 15:21:15 2008 +0100 UML: Enable MTD, by moving the dependency on HAS_IOMEM Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest index 0ccad0f..e34f399 100644 --- a/arch/um/Kconfig.rest +++ b/arch/um/Kconfig.rest @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" source "drivers/leds/Kconfig" diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index b8e35a0..052b00c 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,6 +1,5 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -315,15 +314,17 @@ config MTD_OOPS To use, add console=ttyMTDx to the kernel command line, where x is the MTD device number to use. -source "drivers/mtd/chips/Kconfig" - -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/lpddr/Kconfig" diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 82d1e4d..09fb548 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ +obj-y += devices/ tests/ +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ maps/ nand/ onenand/ obj-$(CONFIG_MTD_UBI) += ubi/ diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig index 325fab9..88937d6 100644 --- a/drivers/mtd/devices/Kconfig +++ b/drivers/mtd/devices/Kconfig @@ -106,6 +106,7 @@ config M25PXX_USE_FAST_READ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -113,6 +114,7 @@ config MTD_SLRAM config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -179,6 +181,7 @@ config MTD_BLOCK2MTD Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" config MTD_DOC2000 @@ -297,5 +300,6 @@ config MTD_DOCPROBE_55AA LinuxBIOS or if you need to recover a DiskOnChip Millennium on which you have managed to wipe the first block. +endif endmenu ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 19:51 ` Jason Lunz @ 2010-12-16 15:25 ` Artem Bityutskiy -1 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-16 15:25 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote: > On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote: > > But I think your solution is a bit dirty, because it adds a great deal > > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. > > This is error-prone. > > The intent of that patch was to allow as much of the mtd subsystem to > compile as possible. My thinking was to try and rectify the fact that > uml has gone without mtd (and hence jffs2) support for years even though > much of it works just fine. I think the entire subsystem being marked > BROKEN in kconfig kept anyone from experimenting with it. > > The patch I sent was actually a reaction to feedback I got from Sam > Ravnborg on my last attempt (um, three years ago :/ ) in which he > suggested pushing down the ifdefs closer to their points of use. But I > agree, the minimal version has a much smaller footprint. > > The version below still meets the goal of allowing jffs2-on-block2mtd > usage under uml but is much smaller because only the mtd core is > included. Compile-tested on i386, x86_64, um/i386, and um/x86_64. > > > Instead, you should solve this problem in UML code. I do not know how, > > but may be you can add readb/writeb there which actually do nothing or > > print a scary warning, or do BUG(), and let things which use them just > > fail run-time. > > Something like this could work, but it would be error-prone for anyone > else who attempts using iomem-requiring drivers on uml. Instead of > getting obvious compile failures we'd have broken drivers that BUG() or > emit scary warnings. That doesn't seem to me like an improvement. OK, pushed this patch to l2-mtd-2.6.git. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-16 15:25 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-16 15:25 UTC (permalink / raw) To: Jason Lunz Cc: richard -rw- weinberger, Sam Ravnborg, David Woodhouse, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote: > On Tue, Dec 14, 2010 at 06:24:38PM +0200, Artem Bityutskiy wrote: > > But I think your solution is a bit dirty, because it adds a great deal > > of little 'if HAS_IOMEM' and '#ifdef CONFIG_HAS_IOMEM' to many places. > > This is error-prone. > > The intent of that patch was to allow as much of the mtd subsystem to > compile as possible. My thinking was to try and rectify the fact that > uml has gone without mtd (and hence jffs2) support for years even though > much of it works just fine. I think the entire subsystem being marked > BROKEN in kconfig kept anyone from experimenting with it. > > The patch I sent was actually a reaction to feedback I got from Sam > Ravnborg on my last attempt (um, three years ago :/ ) in which he > suggested pushing down the ifdefs closer to their points of use. But I > agree, the minimal version has a much smaller footprint. > > The version below still meets the goal of allowing jffs2-on-block2mtd > usage under uml but is much smaller because only the mtd core is > included. Compile-tested on i386, x86_64, um/i386, and um/x86_64. > > > Instead, you should solve this problem in UML code. I do not know how, > > but may be you can add readb/writeb there which actually do nothing or > > print a scary warning, or do BUG(), and let things which use them just > > fail run-time. > > Something like this could work, but it would be error-prone for anyone > else who attempts using iomem-requiring drivers on uml. Instead of > getting obvious compile failures we'd have broken drivers that BUG() or > emit scary warnings. That doesn't seem to me like an improvement. OK, pushed this patch to l2-mtd-2.6.git. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 19:51 ` Jason Lunz @ 2010-12-16 22:01 ` Anatolij Gustschin -1 siblings, 0 replies; 63+ messages in thread From: Anatolij Gustschin @ 2010-12-16 22:01 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, Artem Bityutskiy, richard -rw- weinberger, David Woodhouse, Jeff Dike, lkml, linux-mtd, Rob Landley, Sam Ravnborg On Tue, 14 Dec 2010 11:51:24 -0800 Jason Lunz <lunz@acm.org> wrote: ... > diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h > index a9e6ba4..3d9f7e0 100644 > --- a/include/linux/mtd/map.h > +++ b/include/linux/mtd/map.h > @@ -388,6 +388,15 @@ static inline map_word map_word_ff(struct map_info *map) > return r; > } > > +#ifdef CONFIG_MTD_COMPLEX_MAPPINGS > +#define map_read(map, ofs) (map)->read(map, ofs) > +#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) > +#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) > +#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) > + > +extern void simple_map_init(struct map_info *); > +#define map_is_linear(map) (map->phys != NO_XIP) > + > static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) > { > map_word r; > @@ -440,15 +449,6 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co > memcpy_toio(map->virt + to, from, len); > } > > -#ifdef CONFIG_MTD_COMPLEX_MAPPINGS > -#define map_read(map, ofs) (map)->read(map, ofs) > -#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) > -#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) > -#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) > - > -extern void simple_map_init(struct map_info *); > -#define map_is_linear(map) (map->phys != NO_XIP) > - > #else > #define map_read(map, ofs) inline_map_read(map, ofs) > #define map_copy_from(map, to, from, len) inline_map_copy_from(map, to, from, len) This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not defined in the kernel configuration. Please fix! Thanks, Anatolij ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-16 22:01 ` Anatolij Gustschin 0 siblings, 0 replies; 63+ messages in thread From: Anatolij Gustschin @ 2010-12-16 22:01 UTC (permalink / raw) To: Jason Lunz Cc: Artem Bityutskiy, atom ota, user-mode-linux-devel, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Tue, 14 Dec 2010 11:51:24 -0800 Jason Lunz <lunz@acm.org> wrote: ... > diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h > index a9e6ba4..3d9f7e0 100644 > --- a/include/linux/mtd/map.h > +++ b/include/linux/mtd/map.h > @@ -388,6 +388,15 @@ static inline map_word map_word_ff(struct map_info *map) > return r; > } > > +#ifdef CONFIG_MTD_COMPLEX_MAPPINGS > +#define map_read(map, ofs) (map)->read(map, ofs) > +#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) > +#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) > +#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) > + > +extern void simple_map_init(struct map_info *); > +#define map_is_linear(map) (map->phys != NO_XIP) > + > static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) > { > map_word r; > @@ -440,15 +449,6 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co > memcpy_toio(map->virt + to, from, len); > } > > -#ifdef CONFIG_MTD_COMPLEX_MAPPINGS > -#define map_read(map, ofs) (map)->read(map, ofs) > -#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) > -#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) > -#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) > - > -extern void simple_map_init(struct map_info *); > -#define map_is_linear(map) (map->phys != NO_XIP) > - > #else > #define map_read(map, ofs) inline_map_read(map, ofs) > #define map_copy_from(map, to, from, len) inline_map_copy_from(map, to, from, len) This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not defined in the kernel configuration. Please fix! Thanks, Anatolij ^ permalink raw reply [flat|nested] 63+ messages in thread
* mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile 2010-12-16 22:01 ` Anatolij Gustschin (?) @ 2010-12-17 4:27 ` Jason Lunz 2010-12-19 16:47 ` Artem Bityutskiy -1 siblings, 1 reply; 63+ messages in thread From: Jason Lunz @ 2010-12-17 4:27 UTC (permalink / raw) To: Anatolij Gustschin Cc: Artem Bityutskiy, atom ota, user-mode-linux-devel, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Thu, Dec 16, 2010 at 11:01:10PM +0100, Anatolij Gustschin wrote: > This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not > defined in the kernel configuration. Please fix! Sorry, sloppy of me. This reverts all changes to mtd.h while keeping the ability to compile mtd on ARCH=um, with the exception mtdchar. Jason -- Revert hiding of inline_map_* functions in linux/mtd.h, and mark MTD_CHAR as incompatible with uml until a better solution can be found there. Signed-off-by: Jason Lunz <lunz@acm.org> --- drivers/mtd/Kconfig | 1 + include/linux/mtd/map.h | 18 +++++++++--------- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 7537654..51471a5 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -174,6 +174,7 @@ comment "User Modules And Translation Layers" config MTD_CHAR tristate "Direct char device access to MTD devices" + depends on HAS_IOMEM help This provides a character device for each MTD device present in the system, allowing the user to read and write directly to the diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h index 3d9f7e0..a9e6ba4 100644 --- a/include/linux/mtd/map.h +++ b/include/linux/mtd/map.h @@ -388,15 +388,6 @@ static inline map_word map_word_ff(struct map_info *map) return r; } -#ifdef CONFIG_MTD_COMPLEX_MAPPINGS -#define map_read(map, ofs) (map)->read(map, ofs) -#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) -#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) -#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) - -extern void simple_map_init(struct map_info *); -#define map_is_linear(map) (map->phys != NO_XIP) - static inline map_word inline_map_read(struct map_info *map, unsigned long ofs) { map_word r; @@ -449,6 +440,15 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co memcpy_toio(map->virt + to, from, len); } +#ifdef CONFIG_MTD_COMPLEX_MAPPINGS +#define map_read(map, ofs) (map)->read(map, ofs) +#define map_copy_from(map, to, from, len) (map)->copy_from(map, to, from, len) +#define map_write(map, datum, ofs) (map)->write(map, datum, ofs) +#define map_copy_to(map, to, from, len) (map)->copy_to(map, to, from, len) + +extern void simple_map_init(struct map_info *); +#define map_is_linear(map) (map->phys != NO_XIP) + #else #define map_read(map, ofs) inline_map_read(map, ofs) #define map_copy_from(map, to, from, len) inline_map_copy_from(map, to, from, len) -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile 2010-12-17 4:27 ` mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile Jason Lunz @ 2010-12-19 16:47 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-19 16:47 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, richard -rw- weinberger, David Woodhouse, Jeff Dike, lkml, linux-mtd, Rob Landley, Anatolij Gustschin, Sam Ravnborg On Thu, 2010-12-16 at 20:27 -0800, Jason Lunz wrote: > On Thu, Dec 16, 2010 at 11:01:10PM +0100, Anatolij Gustschin wrote: > > This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not > > defined in the kernel configuration. Please fix! > > Sorry, sloppy of me. This reverts all changes to mtd.h while keeping the > ability to compile mtd on ARCH=um, with the exception mtdchar. Merged with the previous patch, thanks. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile @ 2010-12-19 16:47 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-19 16:47 UTC (permalink / raw) To: Jason Lunz Cc: Anatolij Gustschin, atom ota, user-mode-linux-devel, richard -rw- weinberger, Sam Ravnborg, Jeff Dike, lkml, linux-mtd, Rob Landley, David Woodhouse On Thu, 2010-12-16 at 20:27 -0800, Jason Lunz wrote: > On Thu, Dec 16, 2010 at 11:01:10PM +0100, Anatolij Gustschin wrote: > > This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not > > defined in the kernel configuration. Please fix! > > Sorry, sloppy of me. This reverts all changes to mtd.h while keeping the > ability to compile mtd on ARCH=um, with the exception mtdchar. Merged with the previous patch, thanks. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile 2010-12-19 16:47 ` Artem Bityutskiy @ 2010-12-19 19:07 ` Jason Lunz -1 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-19 19:07 UTC (permalink / raw) To: Artem Bityutskiy; +Cc: Anatolij Gustschin, linux-mtd, lkml You should also drop the changes that 7bc3265a9e9a09d6a9a3cfaaf53ccf3af5271a93 made to drivers/mtd/mtdchar.c - there's no point changing that when mtdchar is disabled on ARCH=um. Jason On Sun, Dec 19, 2010 at 06:47:56PM +0200, Artem Bityutskiy wrote: > On Thu, 2010-12-16 at 20:27 -0800, Jason Lunz wrote: > > On Thu, Dec 16, 2010 at 11:01:10PM +0100, Anatolij Gustschin wrote: > > > This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not > > > defined in the kernel configuration. Please fix! > > > > Sorry, sloppy of me. This reverts all changes to mtd.h while keeping the > > ability to compile mtd on ARCH=um, with the exception mtdchar. > > Merged with the previous patch, thanks. > > -- > Best Regards, > Artem Bityutskiy (Битюцкий Артём) > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile @ 2010-12-19 19:07 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-19 19:07 UTC (permalink / raw) To: Artem Bityutskiy; +Cc: Anatolij Gustschin, lkml, linux-mtd You should also drop the changes that 7bc3265a9e9a09d6a9a3cfaaf53ccf3af5271a93 made to drivers/mtd/mtdchar.c - there's no point changing that when mtdchar is disabled on ARCH=um. Jason On Sun, Dec 19, 2010 at 06:47:56PM +0200, Artem Bityutskiy wrote: > On Thu, 2010-12-16 at 20:27 -0800, Jason Lunz wrote: > > On Thu, Dec 16, 2010 at 11:01:10PM +0100, Anatolij Gustschin wrote: > > > This change breaks compiling when CONFIG_MTD_COMPLEX_MAPPINGS is not > > > defined in the kernel configuration. Please fix! > > > > Sorry, sloppy of me. This reverts all changes to mtd.h while keeping the > > ability to compile mtd on ARCH=um, with the exception mtdchar. > > Merged with the previous patch, thanks. > > -- > Best Regards, > Artem Bityutskiy (Битюцкий Артём) > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile 2010-12-19 19:07 ` Jason Lunz @ 2010-12-20 11:23 ` Artem Bityutskiy -1 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-20 11:23 UTC (permalink / raw) To: Jason Lunz; +Cc: Anatolij Gustschin, linux-mtd, lkml On Sun, 2010-12-19 at 14:07 -0500, Jason Lunz wrote: > You should also drop the changes that > 7bc3265a9e9a09d6a9a3cfaaf53ccf3af5271a93 made to drivers/mtd/mtdchar.c - > there's no point changing that when mtdchar is disabled on ARCH=um. Ok, could you please re-sent the final patch with the commit message etc? -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile @ 2010-12-20 11:23 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-20 11:23 UTC (permalink / raw) To: Jason Lunz; +Cc: Anatolij Gustschin, lkml, linux-mtd On Sun, 2010-12-19 at 14:07 -0500, Jason Lunz wrote: > You should also drop the changes that > 7bc3265a9e9a09d6a9a3cfaaf53ccf3af5271a93 made to drivers/mtd/mtdchar.c - > there's no point changing that when mtdchar is disabled on ARCH=um. Ok, could you please re-sent the final patch with the commit message etc? -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-20 11:23 ` Artem Bityutskiy @ 2010-12-20 14:04 ` Jason Lunz -1 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-20 14:04 UTC (permalink / raw) To: Artem Bityutskiy; +Cc: Anatolij Gustschin, linux-mtd, lkml On Mon, Dec 20, 2010 at 01:23:36PM +0200, Artem Bityutskiy wrote: > Ok, could you please re-sent the final patch with the commit message > etc? Sure, here's everything as a single patch. ------------------------------------->8 Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@acm.org> --- arch/um/Kconfig.rest | 4 +--- drivers/mtd/Kconfig | 8 ++++++-- drivers/mtd/Makefile | 3 ++- 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest index 0ccad0f..e34f399 100644 --- a/arch/um/Kconfig.rest +++ b/arch/um/Kconfig.rest @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" source "drivers/leds/Kconfig" diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 7741470..603e447 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,6 +1,5 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -178,6 +177,7 @@ comment "User Modules And Translation Layers" config MTD_CHAR tristate "Direct char device access to MTD devices" + depends on HAS_IOMEM help This provides a character device for each MTD device present in the system, allowing the user to read and write directly to the @@ -310,7 +310,7 @@ config SSFDC config SM_FTL tristate "SmartMedia/xD new translation layer" - depends on EXPERIMENTAL && BLOCK + depends on EXPERIMENTAL && BLOCK && HAS_IOMEM select MTD_BLKDEVS select MTD_NAND_ECC help @@ -333,6 +333,8 @@ config MTD_OOPS To use, add console=ttyMTDx to the kernel command line, where x is the MTD device number to use. +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" source "drivers/mtd/maps/Kconfig" @@ -345,6 +347,8 @@ source "drivers/mtd/onenand/Kconfig" source "drivers/mtd/lpddr/Kconfig" +endif # HAS_IOMEM + source "drivers/mtd/ubi/Kconfig" endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index d4e7f25..c83eee4 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ +obj-y += tests/ +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ maps/ devices/ nand/ onenand/ obj-$(CONFIG_MTD_UBI) += ubi/ -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-20 14:04 ` Jason Lunz 0 siblings, 0 replies; 63+ messages in thread From: Jason Lunz @ 2010-12-20 14:04 UTC (permalink / raw) To: Artem Bityutskiy; +Cc: Anatolij Gustschin, lkml, linux-mtd On Mon, Dec 20, 2010 at 01:23:36PM +0200, Artem Bityutskiy wrote: > Ok, could you please re-sent the final patch with the commit message > etc? Sure, here's everything as a single patch. ------------------------------------->8 Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <lunz@acm.org> --- arch/um/Kconfig.rest | 4 +--- drivers/mtd/Kconfig | 8 ++++++-- drivers/mtd/Makefile | 3 ++- 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/um/Kconfig.rest b/arch/um/Kconfig.rest index 0ccad0f..e34f399 100644 --- a/arch/um/Kconfig.rest +++ b/arch/um/Kconfig.rest @@ -28,9 +28,7 @@ source "drivers/scsi/Kconfig" source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" source "drivers/leds/Kconfig" diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 7741470..603e447 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,6 +1,5 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -178,6 +177,7 @@ comment "User Modules And Translation Layers" config MTD_CHAR tristate "Direct char device access to MTD devices" + depends on HAS_IOMEM help This provides a character device for each MTD device present in the system, allowing the user to read and write directly to the @@ -310,7 +310,7 @@ config SSFDC config SM_FTL tristate "SmartMedia/xD new translation layer" - depends on EXPERIMENTAL && BLOCK + depends on EXPERIMENTAL && BLOCK && HAS_IOMEM select MTD_BLKDEVS select MTD_NAND_ECC help @@ -333,6 +333,8 @@ config MTD_OOPS To use, add console=ttyMTDx to the kernel command line, where x is the MTD device number to use. +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" source "drivers/mtd/maps/Kconfig" @@ -345,6 +347,8 @@ source "drivers/mtd/onenand/Kconfig" source "drivers/mtd/lpddr/Kconfig" +endif # HAS_IOMEM + source "drivers/mtd/ubi/Kconfig" endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index d4e7f25..c83eee4 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_MTD_OOPS) += mtdoops.o nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/ +obj-y += tests/ +obj-$(CONFIG_HAS_IOMEM) += chips/ lpddr/ maps/ devices/ nand/ onenand/ obj-$(CONFIG_MTD_UBI) += ubi/ -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-20 14:04 ` Jason Lunz @ 2010-12-22 14:40 ` Artem Bityutskiy -1 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-22 14:40 UTC (permalink / raw) To: Jason Lunz; +Cc: Anatolij Gustschin, linux-mtd, lkml On Mon, 2010-12-20 at 09:04 -0500, Jason Lunz wrote: > On Mon, Dec 20, 2010 at 01:23:36PM +0200, Artem Bityutskiy wrote: > > Ok, could you please re-sent the final patch with the commit message > > etc? > > Sure, here's everything as a single patch. > > ------------------------------------->8 > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > dependencies down closer to the parts of mtd that actually need it. > This allows enough of mtd to build to let jffs2 be used on uml. > > Signed-off-by: Jason Lunz <lunz@acm.org> OK, taken this one, thanks. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2010-12-22 14:40 ` Artem Bityutskiy 0 siblings, 0 replies; 63+ messages in thread From: Artem Bityutskiy @ 2010-12-22 14:40 UTC (permalink / raw) To: Jason Lunz; +Cc: Anatolij Gustschin, lkml, linux-mtd On Mon, 2010-12-20 at 09:04 -0500, Jason Lunz wrote: > On Mon, Dec 20, 2010 at 01:23:36PM +0200, Artem Bityutskiy wrote: > > Ok, could you please re-sent the final patch with the commit message > > etc? > > Sure, here's everything as a single patch. > > ------------------------------------->8 > Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM > dependencies down closer to the parts of mtd that actually need it. > This allows enough of mtd to build to let jffs2 be used on uml. > > Signed-off-by: Jason Lunz <lunz@acm.org> OK, taken this one, thanks. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um 2010-12-14 19:51 ` Jason Lunz @ 2011-01-06 15:45 ` David Woodhouse -1 siblings, 0 replies; 63+ messages in thread From: David Woodhouse @ 2011-01-06 15:45 UTC (permalink / raw) To: Jason Lunz Cc: atom ota, user-mode-linux-devel, Artem Bityutskiy, richard -rw- weinberger, Jeff Dike, lkml, linux-mtd, Rob Landley, Sam Ravnborg On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote: > > > Instead, you should solve this problem in UML code. I do not know how, > > but may be you can add readb/writeb there which actually do nothing or > > print a scary warning, or do BUG(), and let things which use them just > > fail run-time. > > Something like this could work, but it would be error-prone for anyone > else who attempts using iomem-requiring drivers on uml. Instead of > getting obvious compile failures we'd have broken drivers that BUG() or > emit scary warnings. That doesn't seem to me like an improvement. Drivers should *never* BUG() or crash, or busy-loop, on getting 0xFF when they read from hardware. That can happen anyway in some circumstances. Doesn't iSeries take this approach? I don't much like the patch that Artem took into his l2-mtd tree; it doesn't even let you build mtdchar, which really *ought* to be permitted. It also didn't allow the nandsim or mtdram devices, which are purely virtual. I think I'd prefer something similar to your original, Jason. I don't think the HAS_IOMEM dependencies have to be *so* complex to maintain. If anything we're just going to err on the side of inclusion and you'll occasionally have to send us patches to "hide" things from you again. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um @ 2011-01-06 15:45 ` David Woodhouse 0 siblings, 0 replies; 63+ messages in thread From: David Woodhouse @ 2011-01-06 15:45 UTC (permalink / raw) To: Jason Lunz Cc: Artem Bityutskiy, richard -rw- weinberger, Sam Ravnborg, atom ota, user-mode-linux-devel, Jeff Dike, lkml, linux-mtd, Rob Landley On Tue, 2010-12-14 at 11:51 -0800, Jason Lunz wrote: > > > Instead, you should solve this problem in UML code. I do not know how, > > but may be you can add readb/writeb there which actually do nothing or > > print a scary warning, or do BUG(), and let things which use them just > > fail run-time. > > Something like this could work, but it would be error-prone for anyone > else who attempts using iomem-requiring drivers on uml. Instead of > getting obvious compile failures we'd have broken drivers that BUG() or > emit scary warnings. That doesn't seem to me like an improvement. Drivers should *never* BUG() or crash, or busy-loop, on getting 0xFF when they read from hardware. That can happen anyway in some circumstances. Doesn't iSeries take this approach? I don't much like the patch that Artem took into his l2-mtd tree; it doesn't even let you build mtdchar, which really *ought* to be permitted. It also didn't allow the nandsim or mtdram devices, which are purely virtual. I think I'd prefer something similar to your original, Jason. I don't think the HAS_IOMEM dependencies have to be *so* complex to maintain. If anything we're just going to err on the side of inclusion and you'll occasionally have to send us patches to "hide" things from you again. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2011-01-06 15:45 UTC | newest]
Thread overview: 63+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <22c797d00709272118i33d32b9dy93d5f5ec8f8edd30@mail.gmail.com>
2007-10-24 1:17 ` [PATCH] allow use of mtd and jffs2 on uml Jason Lunz
2007-10-24 6:51 ` David Woodhouse
2007-10-24 15:54 ` Jason Lunz
2007-10-24 15:54 ` Jason Lunz
2007-10-24 16:24 ` atom ota
2007-10-24 16:24 ` atom ota
2007-12-27 18:15 ` Jason Lunz
2007-12-27 18:15 ` Jason Lunz
2007-12-27 18:15 ` [uml-devel] " Jason Lunz
2007-12-28 17:48 ` Sam Ravnborg
2007-12-28 17:48 ` Sam Ravnborg
2007-12-28 17:48 ` [uml-devel] " Sam Ravnborg
2010-12-07 7:29 ` [PATCH] mtd: allow mtd and jffs2 when ARCH=um Jason Lunz
2010-12-07 7:29 ` Jason Lunz
2010-12-07 9:39 ` richard -rw- weinberger
2010-12-07 9:39 ` richard -rw- weinberger
2010-12-07 9:39 ` richard -rw- weinberger
2010-12-07 18:20 ` Jason Lunz
2010-12-07 18:20 ` Jason Lunz
2010-12-07 18:20 ` Jason Lunz
2010-12-14 16:24 ` Artem Bityutskiy
2010-12-14 16:24 ` Artem Bityutskiy
2010-12-14 19:51 ` Jason Lunz
2010-12-14 19:51 ` Jason Lunz
2010-12-14 20:01 ` Artem Bityutskiy
2010-12-14 20:01 ` Artem Bityutskiy
2010-12-14 21:12 ` Geert Uytterhoeven
2010-12-14 21:12 ` Geert Uytterhoeven
2010-12-14 21:23 ` Jason Lunz
2010-12-14 21:23 ` Jason Lunz
2010-12-15 0:40 ` Rob Landley
2010-12-15 0:40 ` Rob Landley
2010-12-15 0:49 ` Rob Landley
2010-12-15 0:49 ` Rob Landley
2010-12-15 1:19 ` Jason Lunz
2010-12-15 1:19 ` Jason Lunz
2010-12-15 6:31 ` Rob Landley
2010-12-15 6:31 ` Rob Landley
2010-12-16 15:18 ` Artem Bityutskiy
2010-12-16 15:18 ` Artem Bityutskiy
2010-12-18 4:08 ` Rob Landley
2010-12-18 4:08 ` Rob Landley
2010-12-19 17:08 ` Artem Bityutskiy
2010-12-19 17:08 ` Artem Bityutskiy
2010-12-15 8:18 ` Geert Uytterhoeven
2010-12-15 8:18 ` Geert Uytterhoeven
2010-12-16 15:25 ` Artem Bityutskiy
2010-12-16 15:25 ` Artem Bityutskiy
2010-12-16 22:01 ` Anatolij Gustschin
2010-12-16 22:01 ` Anatolij Gustschin
2010-12-17 4:27 ` mtd: fix CONFIG_MTD_COMPLEX_MAPPINGS=n compile Jason Lunz
2010-12-19 16:47 ` Artem Bityutskiy
2010-12-19 16:47 ` Artem Bityutskiy
2010-12-19 19:07 ` Jason Lunz
2010-12-19 19:07 ` Jason Lunz
2010-12-20 11:23 ` Artem Bityutskiy
2010-12-20 11:23 ` Artem Bityutskiy
2010-12-20 14:04 ` [PATCH] mtd: allow mtd and jffs2 when ARCH=um Jason Lunz
2010-12-20 14:04 ` Jason Lunz
2010-12-22 14:40 ` Artem Bityutskiy
2010-12-22 14:40 ` Artem Bityutskiy
2011-01-06 15:45 ` David Woodhouse
2011-01-06 15:45 ` David Woodhouse
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.