Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-12-27 05:11:48 +00:00
Code Issues Packages Projects Releases Wiki Activity
002f6aab43
linux/drivers/mtd/maps/physmap.c

326 lines
7.8 KiB
C
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
/*
* Normal mappings of chips in physical memory
*
* Copyright (C) 2003 MontaVista Software Inc.
* Author: Jun Sun, jsun@mvista.com or jsun@junsun.net
*
* 031022 - [jsun] add run-time configure and partition setup
*/
#include <linux/module.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/slab.h>
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
#include <linux/device.h>
#include <linux/platform_device.h>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#include <linux/mtd/mtd.h>
#include <linux/mtd/map.h>
#include <linux/mtd/partitions.h>
[MTD] Make functions static, include header files with prototypes This patch contains the following possible cleanups: - every file should #include the headers containing the prototypes for it's global functions - make needlessly global functions static Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-29 14:49:38 +00:00
#include <linux/mtd/physmap.h>
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
#include <linux/mtd/concat.h>
[MTD] physmap: fix memory leak on physmap_flash_remove by using devres physmap_flash_remove releases only last memory region. This causes memory leak if multiple resources were provided. This patch fixes this leakage by using devm_ functions. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-11-26 10:26:29 +00:00
#include <linux/io.h>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
#define MAX_RESOURCES 4
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
struct physmap_flash_info {
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
struct mtd_info *mtd[MAX_RESOURCES];
struct mtd_info *cmtd;
struct map_info map[MAX_RESOURCES];
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
#ifdef CONFIG_MTD_PARTITIONS
int nr_parts;
struct mtd_partition *parts;
#endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
};
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
static int physmap_flash_remove(struct platform_device *dev)
{
struct physmap_flash_info *info;
struct physmap_flash_data *physmap_data;
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
int i;
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
info = platform_get_drvdata(dev);
if (info == NULL)
return 0;
platform_set_drvdata(dev, NULL);
physmap_data = dev->dev.platform_data;
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
#ifdef CONFIG_MTD_CONCAT
if (info->cmtd != info->mtd[0]) {
del_mtd_device(info->cmtd);
mtd_concat_destroy(info->cmtd);
}
#endif
for (i = 0; i < MAX_RESOURCES; i++) {
if (info->mtd[i] != NULL) {
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#ifdef CONFIG_MTD_PARTITIONS
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
if (info->nr_parts) {
del_mtd_partitions(info->mtd[i]);
kfree(info->parts);
} else if (physmap_data->nr_parts) {
del_mtd_partitions(info->mtd[i]);
} else {
del_mtd_device(info->mtd[i]);
}
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
#else
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
del_mtd_device(info->mtd[i]);
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
#endif
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
map_destroy(info->mtd[i]);
}
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
}
return 0;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };
#ifdef CONFIG_MTD_PARTITIONS
static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
#endif
static int physmap_flash_probe(struct platform_device *dev)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
struct physmap_flash_data *physmap_data;
struct physmap_flash_info *info;
const char **probe_type;
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
int err = 0;
int i;
int devices_found = 0;
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
physmap_data = dev->dev.platform_data;
if (physmap_data == NULL)
return -ENODEV;
[MTD] physmap: fix memory leak on physmap_flash_remove by using devres physmap_flash_remove releases only last memory region. This causes memory leak if multiple resources were provided. This patch fixes this leakage by using devm_ functions. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-11-26 10:26:29 +00:00
info = devm_kzalloc(&dev->dev, sizeof(struct physmap_flash_info),
GFP_KERNEL);
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
if (info == NULL) {
err = -ENOMEM;
goto err_out;
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
platform_set_drvdata(dev, info);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
for (i = 0; i < dev->num_resources; i++) {
printk(KERN_NOTICE "physmap platform flash device: %.8llx at %.8llx\n",
(unsigned long long)(dev->resource[i].end - dev->resource[i].start + 1),
(unsigned long long)dev->resource[i].start);
[MTD] physmap: fix memory leak on physmap_flash_remove by using devres physmap_flash_remove releases only last memory region. This causes memory leak if multiple resources were provided. This patch fixes this leakage by using devm_ functions. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-11-26 10:26:29 +00:00
if (!devm_request_mem_region(&dev->dev,
dev->resource[i].start,
dev->resource[i].end - dev->resource[i].start + 1,
dev->dev.bus_id)) {
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
dev_err(&dev->dev, "Could not reserve memory region\n");
err = -ENOMEM;
goto err_out;
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
info->map[i].name = dev->dev.bus_id;
info->map[i].phys = dev->resource[i].start;
info->map[i].size = dev->resource[i].end - dev->resource[i].start + 1;
info->map[i].bankwidth = physmap_data->width;
info->map[i].set_vpp = physmap_data->set_vpp;
[MTD] physmap: fix memory leak on physmap_flash_remove by using devres physmap_flash_remove releases only last memory region. This causes memory leak if multiple resources were provided. This patch fixes this leakage by using devm_ functions. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-11-26 10:26:29 +00:00
info->map[i].virt = devm_ioremap(&dev->dev, info->map[i].phys,
info->map[i].size);
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
if (info->map[i].virt == NULL) {
dev_err(&dev->dev, "Failed to ioremap flash region\n");
err = EIO;
goto err_out;
}
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
simple_map_init(&info->map[i]);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
probe_type = rom_probe_types;
for (; info->mtd[i] == NULL && *probe_type != NULL; probe_type++)
info->mtd[i] = do_map_probe(*probe_type, &info->map[i]);
if (info->mtd[i] == NULL) {
dev_err(&dev->dev, "map_probe failed\n");
err = -ENXIO;
goto err_out;
} else {
devices_found++;
}
info->mtd[i]->owner = THIS_MODULE;
}
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
if (devices_found == 1) {
info->cmtd = info->mtd[0];
} else if (devices_found > 1) {
/*
* We detected multiple devices. Concatenate them together.
*/
#ifdef CONFIG_MTD_CONCAT
info->cmtd = mtd_concat_create(info->mtd, devices_found, dev->dev.bus_id);
if (info->cmtd == NULL)
err = -ENXIO;
#else
printk(KERN_ERR "physmap-flash: multiple devices "
"found but MTD concat support disabled.\n");
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
err = -ENXIO;
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
#endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
if (err)
goto err_out;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#ifdef CONFIG_MTD_PARTITIONS
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
err = parse_mtd_partitions(info->cmtd, part_probe_types, &info->parts, 0);
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
if (err > 0) {
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
add_mtd_partitions(info->cmtd, info->parts, err);
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
return 0;
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
if (physmap_data->nr_parts) {
printk(KERN_NOTICE "Using physmap partition information\n");
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
add_mtd_partitions(info->cmtd, physmap_data->parts,
physmap_data->nr_parts);
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
return 0;
}
#endif
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
add_mtd_device(info->cmtd);
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
return 0;
err_out:
physmap_flash_remove(dev);
return err;
}
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 21:16:48 +00:00
#ifdef CONFIG_PM
static int physmap_flash_suspend(struct platform_device *dev, pm_message_t state)
{
struct physmap_flash_info *info = platform_get_drvdata(dev);
int ret = 0;
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
int i;
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 21:16:48 +00:00
mtd: maps/physmap: fix oops in suspend/resume/shutdown ops # reboot ... [ 42.351266] Flash device refused suspend due to active operation (state 0) [ 42.358195] Unable to handle kernel NULL pointer dereference at virtual address 00000078 [ 42.360060] pgd = c7d9c000 [ 42.362769] [00000078] *pgd=a7d8d031, *pte=00000000, *ppte=00000000 [ 42.372902] Internal error: Oops: 17 [#1] [ 42.376911] Modules linked in: [ 42.379980] CPU: 0 Not tainted (2.6.25-rc2-10642-ge8f2594-dirty #73) [ 42.380000] PC is at physmap_flash_shutdown+0x28/0x54 ... [ 42.380000] Backtrace: [ 42.380000] [<c0130c1c>] (physmap_flash_shutdown+0x0/0x54) from [<c01207c0>] (platform_drv_shutdown+0x20/0x24) [ 42.380000] r5:28121969 r4:c0229e08 [ 42.380000] [<c01207a0>] (platform_drv_shutdown+0x0/0x24) from [<c011cd40>] (device_shutdown+0x60/0x88) [ 42.380000] [<c011cce0>] (device_shutdown+0x0/0x88) from [<c003e8a4>] (kernel_restart_prepare+0x2c/0x3c) [ 42.380000] r4:00000000 [ 42.380000] [<c003e878>] (kernel_restart_prepare+0x0/0x3c) from [<c003ea00>] (kernel_restart+0x14/0x48) [ 42.380000] [<c003e9ec>] (kernel_restart+0x0/0x48) from [<c003fdc0>] (sys_reboot+0xe8/0x1f8) [ 42.380000] r4:01234567 [ 42.380000] [<c003fcd8>] (sys_reboot+0x0/0x1f8) from [<c001aa00>] (ret_fast_syscall+0x0/0x2c) [ 42.380000] r7:00000058 r6:00000004 r5:00000001 r4:00000000 [ 42.380000] Code: 0a000009 e7953004 e1a00003 e1a0e00f (e593f078) [ 42.650051] ---[ end trace 6d6c26a0fc3141de ]--- Segmentation fault INIT: no more processes left in this runlevel While looping for mtd[i]s, we should stop at the mtd[i] == NULL. This patch also removes unnecessary "if (info)" checks: suspend/resume/shutdown ops are executed only if probe() is succeeded, so info is guaranteed to be !NULL. Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Cc: David Brownell <david-b@pacbell.net> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-28 21:16:09 +00:00
for (i = 0; i < MAX_RESOURCES && info->mtd[i]; i++)
[MTD] physmap: resume already suspended chips on failure to suspend A nice side effect of this patch is that the return value of physmap_flash_suspend in the error path is the value of the first failing suspend callback and not the bitwise OR of all of them. Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-07-22 07:39:01 +00:00
if (info->mtd[i]->suspend) {
ret = info->mtd[i]->suspend(info->mtd[i]);
if (ret)
goto fail;
}
return 0;
fail:
for (--i; i >= 0; --i)
if (info->mtd[i]->suspend) {
BUG_ON(!info->mtd[i]->resume);
info->mtd[i]->resume(info->mtd[i]);
}
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 21:16:48 +00:00
return ret;
}
static int physmap_flash_resume(struct platform_device *dev)
{
struct physmap_flash_info *info = platform_get_drvdata(dev);
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
int i;
mtd: maps/physmap: fix oops in suspend/resume/shutdown ops # reboot ... [ 42.351266] Flash device refused suspend due to active operation (state 0) [ 42.358195] Unable to handle kernel NULL pointer dereference at virtual address 00000078 [ 42.360060] pgd = c7d9c000 [ 42.362769] [00000078] *pgd=a7d8d031, *pte=00000000, *ppte=00000000 [ 42.372902] Internal error: Oops: 17 [#1] [ 42.376911] Modules linked in: [ 42.379980] CPU: 0 Not tainted (2.6.25-rc2-10642-ge8f2594-dirty #73) [ 42.380000] PC is at physmap_flash_shutdown+0x28/0x54 ... [ 42.380000] Backtrace: [ 42.380000] [<c0130c1c>] (physmap_flash_shutdown+0x0/0x54) from [<c01207c0>] (platform_drv_shutdown+0x20/0x24) [ 42.380000] r5:28121969 r4:c0229e08 [ 42.380000] [<c01207a0>] (platform_drv_shutdown+0x0/0x24) from [<c011cd40>] (device_shutdown+0x60/0x88) [ 42.380000] [<c011cce0>] (device_shutdown+0x0/0x88) from [<c003e8a4>] (kernel_restart_prepare+0x2c/0x3c) [ 42.380000] r4:00000000 [ 42.380000] [<c003e878>] (kernel_restart_prepare+0x0/0x3c) from [<c003ea00>] (kernel_restart+0x14/0x48) [ 42.380000] [<c003e9ec>] (kernel_restart+0x0/0x48) from [<c003fdc0>] (sys_reboot+0xe8/0x1f8) [ 42.380000] r4:01234567 [ 42.380000] [<c003fcd8>] (sys_reboot+0x0/0x1f8) from [<c001aa00>] (ret_fast_syscall+0x0/0x2c) [ 42.380000] r7:00000058 r6:00000004 r5:00000001 r4:00000000 [ 42.380000] Code: 0a000009 e7953004 e1a00003 e1a0e00f (e593f078) [ 42.650051] ---[ end trace 6d6c26a0fc3141de ]--- Segmentation fault INIT: no more processes left in this runlevel While looping for mtd[i]s, we should stop at the mtd[i] == NULL. This patch also removes unnecessary "if (info)" checks: suspend/resume/shutdown ops are executed only if probe() is succeeded, so info is guaranteed to be !NULL. Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Cc: David Brownell <david-b@pacbell.net> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-28 21:16:09 +00:00
for (i = 0; i < MAX_RESOURCES && info->mtd[i]; i++)
[MTD] physmap: Fix suspend/resume/shutdown bugs. Don't call suspend/resume functions if they have not been defined. Signed-off-by: Robert Jarzmik <rjarzmik@free.fr> Acked-By: Jörn Engel <joern@logfs.org> Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-07-22 07:39:00 +00:00
if (info->mtd[i]->resume)
info->mtd[i]->resume(info->mtd[i]);
mtd: maps/physmap: fix oops in suspend/resume/shutdown ops # reboot ... [ 42.351266] Flash device refused suspend due to active operation (state 0) [ 42.358195] Unable to handle kernel NULL pointer dereference at virtual address 00000078 [ 42.360060] pgd = c7d9c000 [ 42.362769] [00000078] *pgd=a7d8d031, *pte=00000000, *ppte=00000000 [ 42.372902] Internal error: Oops: 17 [#1] [ 42.376911] Modules linked in: [ 42.379980] CPU: 0 Not tainted (2.6.25-rc2-10642-ge8f2594-dirty #73) [ 42.380000] PC is at physmap_flash_shutdown+0x28/0x54 ... [ 42.380000] Backtrace: [ 42.380000] [<c0130c1c>] (physmap_flash_shutdown+0x0/0x54) from [<c01207c0>] (platform_drv_shutdown+0x20/0x24) [ 42.380000] r5:28121969 r4:c0229e08 [ 42.380000] [<c01207a0>] (platform_drv_shutdown+0x0/0x24) from [<c011cd40>] (device_shutdown+0x60/0x88) [ 42.380000] [<c011cce0>] (device_shutdown+0x0/0x88) from [<c003e8a4>] (kernel_restart_prepare+0x2c/0x3c) [ 42.380000] r4:00000000 [ 42.380000] [<c003e878>] (kernel_restart_prepare+0x0/0x3c) from [<c003ea00>] (kernel_restart+0x14/0x48) [ 42.380000] [<c003e9ec>] (kernel_restart+0x0/0x48) from [<c003fdc0>] (sys_reboot+0xe8/0x1f8) [ 42.380000] r4:01234567 [ 42.380000] [<c003fcd8>] (sys_reboot+0x0/0x1f8) from [<c001aa00>] (ret_fast_syscall+0x0/0x2c) [ 42.380000] r7:00000058 r6:00000004 r5:00000001 r4:00000000 [ 42.380000] Code: 0a000009 e7953004 e1a00003 e1a0e00f (e593f078) [ 42.650051] ---[ end trace 6d6c26a0fc3141de ]--- Segmentation fault INIT: no more processes left in this runlevel While looping for mtd[i]s, we should stop at the mtd[i] == NULL. This patch also removes unnecessary "if (info)" checks: suspend/resume/shutdown ops are executed only if probe() is succeeded, so info is guaranteed to be !NULL. Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Cc: David Brownell <david-b@pacbell.net> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-28 21:16:09 +00:00
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 21:16:48 +00:00
return 0;
}
static void physmap_flash_shutdown(struct platform_device *dev)
{
struct physmap_flash_info *info = platform_get_drvdata(dev);
[MTD] physmap.c: Add support for multiple resources This patch extends the physmap mapping driver to support multiple resources for non-identical NOR chips that will be concatenated together when selected. This is needed for example for Intel 48F4400 512MBit chips, since they consist of 2 single different NOR chips with different geometries. The first (lower) one has botton boot sectors and the 2nd (upper) has top boot sectors. This currently isn't handled correctly by calling the physmap driver once with only one resource covering both chips in one memory region. The same geometrie is used for both chips. With this patch the following resource structure can be used to describe the 48F4400 chip correctly: static struct resource board_nor_resource[] = { [0] = { .start = 0xf8000000, .end = 0xfbffffff, .flags = IORESOURCE_MEM, }, [1] = { .start = 0xfc000000, .end = 0xffffffff, .flags = IORESOURCE_MEM, } }; Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-01 14:26:54 +00:00
int i;
mtd: maps/physmap: fix oops in suspend/resume/shutdown ops # reboot ... [ 42.351266] Flash device refused suspend due to active operation (state 0) [ 42.358195] Unable to handle kernel NULL pointer dereference at virtual address 00000078 [ 42.360060] pgd = c7d9c000 [ 42.362769] [00000078] *pgd=a7d8d031, *pte=00000000, *ppte=00000000 [ 42.372902] Internal error: Oops: 17 [#1] [ 42.376911] Modules linked in: [ 42.379980] CPU: 0 Not tainted (2.6.25-rc2-10642-ge8f2594-dirty #73) [ 42.380000] PC is at physmap_flash_shutdown+0x28/0x54 ... [ 42.380000] Backtrace: [ 42.380000] [<c0130c1c>] (physmap_flash_shutdown+0x0/0x54) from [<c01207c0>] (platform_drv_shutdown+0x20/0x24) [ 42.380000] r5:28121969 r4:c0229e08 [ 42.380000] [<c01207a0>] (platform_drv_shutdown+0x0/0x24) from [<c011cd40>] (device_shutdown+0x60/0x88) [ 42.380000] [<c011cce0>] (device_shutdown+0x0/0x88) from [<c003e8a4>] (kernel_restart_prepare+0x2c/0x3c) [ 42.380000] r4:00000000 [ 42.380000] [<c003e878>] (kernel_restart_prepare+0x0/0x3c) from [<c003ea00>] (kernel_restart+0x14/0x48) [ 42.380000] [<c003e9ec>] (kernel_restart+0x0/0x48) from [<c003fdc0>] (sys_reboot+0xe8/0x1f8) [ 42.380000] r4:01234567 [ 42.380000] [<c003fcd8>] (sys_reboot+0x0/0x1f8) from [<c001aa00>] (ret_fast_syscall+0x0/0x2c) [ 42.380000] r7:00000058 r6:00000004 r5:00000001 r4:00000000 [ 42.380000] Code: 0a000009 e7953004 e1a00003 e1a0e00f (e593f078) [ 42.650051] ---[ end trace 6d6c26a0fc3141de ]--- Segmentation fault INIT: no more processes left in this runlevel While looping for mtd[i]s, we should stop at the mtd[i] == NULL. This patch also removes unnecessary "if (info)" checks: suspend/resume/shutdown ops are executed only if probe() is succeeded, so info is guaranteed to be !NULL. Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Cc: David Brownell <david-b@pacbell.net> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-28 21:16:09 +00:00
for (i = 0; i < MAX_RESOURCES && info->mtd[i]; i++)
[MTD] physmap: Fix suspend/resume/shutdown bugs. Don't call suspend/resume functions if they have not been defined. Signed-off-by: Robert Jarzmik <rjarzmik@free.fr> Acked-By: Jörn Engel <joern@logfs.org> Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-07-22 07:39:00 +00:00
if (info->mtd[i]->suspend && info->mtd[i]->resume)
if (info->mtd[i]->suspend(info->mtd[i]) == 0)
info->mtd[i]->resume(info->mtd[i]);
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 21:16:48 +00:00
}
[MTD] Fix maps/physmap.c compilation with CONFIG_PM Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-02-03 20:56:03 +00:00
#else
#define physmap_flash_suspend NULL
#define physmap_flash_resume NULL
#define physmap_flash_shutdown NULL
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 21:16:48 +00:00
#endif
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
static struct platform_driver physmap_flash_driver = {
.probe = physmap_flash_probe,
.remove = physmap_flash_remove,
[MTD] physmap: add power management support Implement PM handling for physmap. Idea from Steven Scholz, patch by David Anders. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-09-21 21:16:48 +00:00
.suspend = physmap_flash_suspend,
.resume = physmap_flash_resume,
.shutdown = physmap_flash_shutdown,
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
.driver = {
.name = "physmap-flash",
[MTD] [MAPS] fix platform driver hotplug/coldplug Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform modalias is prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable MTD mapping platform drivers, to re-enable auto loading. NOTE oddness with physmap ... it's a legacy driver in some configs, which means it can't always support hotplugging. (Not that most of these mapping drivers would often be used as modules...) [dbrownell@users.sourceforge.net: bugfix, more drivers, registration fixes] Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-04-18 20:44:26 +00:00
.owner = THIS_MODULE,
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
},
};
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] physmap: make physmap compat explicit The current method for always showing physmap compat address, size, and width is a bit confusing. If length is set to 0, then the address and width are still shown but silently unused. The physmap code itself already has logic which sets compat based on length, so just pull that out and into the Kconfig to make everything clear. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <Bryan.Wu@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-01 22:23:40 +00:00
#ifdef CONFIG_MTD_PHYSMAP_COMPAT
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
static struct physmap_flash_data physmap_flash_data = {
.width = CONFIG_MTD_PHYSMAP_BANKWIDTH,
};
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
static struct resource physmap_flash_resource = {
.start = CONFIG_MTD_PHYSMAP_START,
[MTD] Fix off-by-one error in physmap.c This patch fixes a simple off-by-one error in the mtd physmap driver. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-06-27 13:38:15 +00:00
.end = CONFIG_MTD_PHYSMAP_START + CONFIG_MTD_PHYSMAP_LEN - 1,
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
.flags = IORESOURCE_MEM,
};
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
static struct platform_device physmap_flash = {
.name = "physmap-flash",
.id = 0,
.dev = {
.platform_data = &physmap_flash_data,
},
.num_resources = 1,
.resource = &physmap_flash_resource,
};
void physmap_configure(unsigned long addr, unsigned long size,
int bankwidth, void (*set_vpp)(struct map_info *, int))
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
{
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
physmap_flash_resource.start = addr;
physmap_flash_resource.end = addr + size - 1;
physmap_flash_data.width = bankwidth;
physmap_flash_data.set_vpp = set_vpp;
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#ifdef CONFIG_MTD_PARTITIONS
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
void physmap_set_partitions(struct mtd_partition *parts, int num_parts)
{
physmap_flash_data.nr_parts = num_parts;
physmap_flash_data.parts = parts;
}
#endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#endif
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
static int __init physmap_init(void)
{
int err;
err = platform_driver_register(&physmap_flash_driver);
[MTD] physmap: make physmap compat explicit The current method for always showing physmap compat address, size, and width is a bit confusing. If length is set to 0, then the address and width are still shown but silently unused. The physmap code itself already has logic which sets compat based on length, so just pull that out and into the Kconfig to make everything clear. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <Bryan.Wu@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-01 22:23:40 +00:00
#ifdef CONFIG_MTD_PHYSMAP_COMPAT
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
if (err == 0)
platform_device_register(&physmap_flash);
#endif
return err;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
}
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
static void __exit physmap_exit(void)
{
[MTD] physmap: make physmap compat explicit The current method for always showing physmap compat address, size, and width is a bit confusing. If length is set to 0, then the address and width are still shown but silently unused. The physmap code itself already has logic which sets compat based on length, so just pull that out and into the Kconfig to make everything clear. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <Bryan.Wu@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-01 22:23:40 +00:00
#ifdef CONFIG_MTD_PHYSMAP_COMPAT
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
platform_device_unregister(&physmap_flash);
#endif
platform_driver_unregister(&physmap_flash_driver);
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[MTD] Convert physmap to platform driver After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-07 16:16:36 +00:00
module_init(physmap_init);
module_exit(physmap_exit);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
MODULE_LICENSE("GPL");
MODULE_AUTHOR("David Woodhouse <dwmw2@infradead.org>");
MODULE_DESCRIPTION("Generic configurable MTD map driver");
[MTD] [MAPS] fix platform driver hotplug/coldplug Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform modalias is prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable MTD mapping platform drivers, to re-enable auto loading. NOTE oddness with physmap ... it's a legacy driver in some configs, which means it can't always support hotplugging. (Not that most of these mapping drivers would often be used as modules...) [dbrownell@users.sourceforge.net: bugfix, more drivers, registration fixes] Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-04-18 20:44:26 +00:00
/* legacy platform drivers can't hotplug or coldplg */
[MTD] physmap: make physmap compat explicit The current method for always showing physmap compat address, size, and width is a bit confusing. If length is set to 0, then the address and width are still shown but silently unused. The physmap code itself already has logic which sets compat based on length, so just pull that out and into the Kconfig to make everything clear. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Bryan Wu <Bryan.Wu@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-12-01 22:23:40 +00:00
#ifndef CONFIG_MTD_PHYSMAP_COMPAT
[MTD] [MAPS] fix platform driver hotplug/coldplug Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform modalias is prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable MTD mapping platform drivers, to re-enable auto loading. NOTE oddness with physmap ... it's a legacy driver in some configs, which means it can't always support hotplugging. (Not that most of these mapping drivers would often be used as modules...) [dbrownell@users.sourceforge.net: bugfix, more drivers, registration fixes] Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-04-18 20:44:26 +00:00
/* work with hotplug and coldplug */
MODULE_ALIAS("platform:physmap-flash");
#endif
Reference in New Issue Copy Permalink