| Message ID | 20101214195124.GA6010@falooley.org |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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.
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
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
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
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
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
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.
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
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
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.
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.
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 (Битюцкий Артём) > >
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?
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.
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)