linux_old1/drivers/mtd/mtdpart.c

787 lines
21 KiB
C
Raw Normal View History

/*
* Simple MTD partitioning layer
*
* Copyright © 2000 Nicolas Pitre <nico@fluxnic.net>
* Copyright © 2002 Thomas Gleixner <gleixner@linutronix.de>
* Copyright © 2000-2010 David Woodhouse <dwmw2@infradead.org>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
#include <linux/module.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/list.h>
#include <linux/kmod.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/err.h>
#include "mtdcore.h"
/* Our partition linked list */
static LIST_HEAD(mtd_partitions);
static DEFINE_MUTEX(mtd_partitions_mutex);
/* Our partition node structure */
struct mtd_part {
struct mtd_info mtd;
struct mtd_info *master;
uint64_t offset;
struct list_head list;
};
/*
* Given a pointer to the MTD object in the mtd_part structure, we can retrieve
* the pointer to that structure with this macro.
*/
#define PART(x) ((struct mtd_part *)(x))
/*
* MTD methods which simply translate the effective address and pass through
* to the _real_ device.
*/
static int part_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
struct mtd_part *part = PART(mtd);
struct mtd_ecc_stats stats;
int res;
stats = part->master->ecc_stats;
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
res = part->master->_read(part->master, from + part->offset, len,
retlen, buf);
if (unlikely(mtd_is_eccerr(res)))
mtd->ecc_stats.failed +=
part->master->ecc_stats.failed - stats.failed;
else
mtd->ecc_stats.corrected +=
part->master->ecc_stats.corrected - stats.corrected;
return res;
}
static int part_point(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, void **virt, resource_size_t *phys)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_point(part->master, from + part->offset, len,
retlen, virt, phys);
}
static int part_unpoint(struct mtd_info *mtd, loff_t from, size_t len)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_unpoint(part->master, from + part->offset, len);
}
static unsigned long part_get_unmapped_area(struct mtd_info *mtd,
unsigned long len,
unsigned long offset,
unsigned long flags)
{
struct mtd_part *part = PART(mtd);
offset += part->offset;
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_get_unmapped_area(part->master, len, offset,
flags);
}
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 09:26:58 +08:00
static int part_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
{
struct mtd_part *part = PART(mtd);
int res;
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 09:26:58 +08:00
if (from >= mtd->size)
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 09:26:58 +08:00
return -EINVAL;
if (ops->datbuf && from + ops->len > mtd->size)
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 09:26:58 +08:00
return -EINVAL;
/*
* If OOB is also requested, make sure that we do not read past the end
* of this partition.
*/
if (ops->oobbuf) {
size_t len, pages;
if (ops->mode == MTD_OPS_AUTO_OOB)
len = mtd->oobavail;
else
len = mtd->oobsize;
pages = mtd_div_by_ws(mtd->size, mtd);
pages -= mtd_div_by_ws(from, mtd);
if (ops->ooboffs + ops->ooblen > pages * len)
return -EINVAL;
}
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
res = part->master->_read_oob(part->master, from + part->offset, ops);
if (unlikely(res)) {
if (mtd_is_bitflip(res))
mtd->ecc_stats.corrected++;
if (mtd_is_eccerr(res))
mtd->ecc_stats.failed++;
}
return res;
}
static int part_read_user_prot_reg(struct mtd_info *mtd, loff_t from,
size_t len, size_t *retlen, u_char *buf)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_read_user_prot_reg(part->master, from, len,
retlen, buf);
}
static int part_get_user_prot_info(struct mtd_info *mtd, size_t len,
size_t *retlen, struct otp_info *buf)
{
struct mtd_part *part = PART(mtd);
return part->master->_get_user_prot_info(part->master, len, retlen,
buf);
}
static int part_read_fact_prot_reg(struct mtd_info *mtd, loff_t from,
size_t len, size_t *retlen, u_char *buf)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_read_fact_prot_reg(part->master, from, len,
retlen, buf);
}
static int part_get_fact_prot_info(struct mtd_info *mtd, size_t len,
size_t *retlen, struct otp_info *buf)
{
struct mtd_part *part = PART(mtd);
return part->master->_get_fact_prot_info(part->master, len, retlen,
buf);
}
static int part_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const u_char *buf)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_write(part->master, to + part->offset, len,
retlen, buf);
}
static int part_panic_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const u_char *buf)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_panic_write(part->master, to + part->offset, len,
retlen, buf);
}
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 09:26:58 +08:00
static int part_write_oob(struct mtd_info *mtd, loff_t to,
struct mtd_oob_ops *ops)
{
struct mtd_part *part = PART(mtd);
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 09:26:58 +08:00
if (to >= mtd->size)
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 09:26:58 +08:00
return -EINVAL;
if (ops->datbuf && to + ops->len > mtd->size)
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 09:26:58 +08:00
return -EINVAL;
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_write_oob(part->master, to + part->offset, ops);
}
static int part_write_user_prot_reg(struct mtd_info *mtd, loff_t from,
size_t len, size_t *retlen, u_char *buf)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_write_user_prot_reg(part->master, from, len,
retlen, buf);
}
static int part_lock_user_prot_reg(struct mtd_info *mtd, loff_t from,
size_t len)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_lock_user_prot_reg(part->master, from, len);
}
static int part_writev(struct mtd_info *mtd, const struct kvec *vecs,
unsigned long count, loff_t to, size_t *retlen)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_writev(part->master, vecs, count,
to + part->offset, retlen);
}
static int part_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct mtd_part *part = PART(mtd);
int ret;
instr->addr += part->offset;
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
ret = part->master->_erase(part->master, instr);
if (ret) {
if (instr->fail_addr != MTD_FAIL_ADDR_UNKNOWN)
instr->fail_addr -= part->offset;
instr->addr -= part->offset;
}
return ret;
}
void mtd_erase_callback(struct erase_info *instr)
{
if (instr->mtd->_erase == part_erase) {
struct mtd_part *part = PART(instr->mtd);
if (instr->fail_addr != MTD_FAIL_ADDR_UNKNOWN)
instr->fail_addr -= part->offset;
instr->addr -= part->offset;
}
if (instr->callback)
instr->callback(instr);
}
EXPORT_SYMBOL_GPL(mtd_erase_callback);
static int part_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_lock(part->master, ofs + part->offset, len);
}
static int part_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_unlock(part->master, ofs + part->offset, len);
}
static int part_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_is_locked(part->master, ofs + part->offset, len);
}
static void part_sync(struct mtd_info *mtd)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
part->master->_sync(part->master);
}
static int part_suspend(struct mtd_info *mtd)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_suspend(part->master);
}
static void part_resume(struct mtd_info *mtd)
{
struct mtd_part *part = PART(mtd);
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
part->master->_resume(part->master);
}
static int part_block_isreserved(struct mtd_info *mtd, loff_t ofs)
{
struct mtd_part *part = PART(mtd);
ofs += part->offset;
return part->master->_block_isreserved(part->master, ofs);
}
static int part_block_isbad(struct mtd_info *mtd, loff_t ofs)
{
struct mtd_part *part = PART(mtd);
ofs += part->offset;
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
return part->master->_block_isbad(part->master, ofs);
}
static int part_block_markbad(struct mtd_info *mtd, loff_t ofs)
{
struct mtd_part *part = PART(mtd);
int res;
ofs += part->offset;
mtd: fix partition wrapper functions This patch reverts a change that may have been mistakenly included with the set of patches that introduced the new mtd api entry functions. Or perhaps I am mistaken :) The problem is in the partition wrapper functions, where the calls to the driver methods were replaced with calls to the new mtd api functions. This causes the api function to be called a second time, further down the call stack. This is not only unnecessary and redundant - because the sanity checking code and (more restrictive) bounds checks for the partition were done in the first call - but is potentially problematic and confusing. For example, the call stack for a call to mtd_read() on a partitioned device currently looks like this: mtd_read() gets struct mtd_info for the partition | +-> part_read() via the pointer assigned when the partition was created | +->mtd_read() this time gets struct mtd_info for the master | +->xyz_driver_read() via the pointer asigned by the driver It seems that this can cause a variety of problems. For example, if you want to add code to the api function that tests a value in mtd_info that is relevant only to the partition. Or (in my case) you want the driver to return a value that may be different from that returned by the mtd api function. This patch eliminates the second call to the mtd api function. It was tested on the docg4 nand driver with a subset of the api functions, but I inspected the rest and don't see any problems. Signed-off-by: Mike Dunn <mikedunn@newsguy.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2012-03-04 05:13:06 +08:00
res = part->master->_block_markbad(part->master, ofs);
if (!res)
mtd->ecc_stats.badblocks++;
return res;
}
static inline void free_partition(struct mtd_part *p)
{
kfree(p->mtd.name);
kfree(p);
}
/*
* This function unregisters and destroy all slave MTD objects which are
* attached to the given master MTD object.
*/
int del_mtd_partitions(struct mtd_info *master)
{
struct mtd_part *slave, *next;
int ret, err = 0;
mutex_lock(&mtd_partitions_mutex);
list_for_each_entry_safe(slave, next, &mtd_partitions, list)
if (slave->master == master) {
ret = del_mtd_device(&slave->mtd);
if (ret < 0) {
err = ret;
continue;
}
list_del(&slave->list);
free_partition(slave);
}
mutex_unlock(&mtd_partitions_mutex);
return err;
}
static struct mtd_part *allocate_partition(struct mtd_info *master,
const struct mtd_partition *part, int partno,
uint64_t cur_offset)
{
struct mtd_part *slave;
char *name;
/* allocate the partition structure */
slave = kzalloc(sizeof(*slave), GFP_KERNEL);
name = kstrdup(part->name, GFP_KERNEL);
if (!name || !slave) {
printk(KERN_ERR"memory allocation error while creating partitions for \"%s\"\n",
master->name);
kfree(name);
kfree(slave);
return ERR_PTR(-ENOMEM);
}
/* set up the MTD object for this partition */
slave->mtd.type = master->type;
slave->mtd.flags = master->flags & ~part->mask_flags;
slave->mtd.size = part->size;
slave->mtd.writesize = master->writesize;
slave->mtd.writebufsize = master->writebufsize;
slave->mtd.oobsize = master->oobsize;
slave->mtd.oobavail = master->oobavail;
slave->mtd.subpage_sft = master->subpage_sft;
slave->mtd.name = name;
slave->mtd.owner = master->owner;
slave->mtd.backing_dev_info = master->backing_dev_info;
/* NOTE: we don't arrange MTDs as a tree; it'd be error-prone
* to have the same data be in two different partitions.
*/
slave->mtd.dev.parent = master->dev.parent;
slave->mtd._read = part_read;
slave->mtd._write = part_write;
if (master->_panic_write)
slave->mtd._panic_write = part_panic_write;
if (master->_point && master->_unpoint) {
slave->mtd._point = part_point;
slave->mtd._unpoint = part_unpoint;
}
if (master->_get_unmapped_area)
slave->mtd._get_unmapped_area = part_get_unmapped_area;
if (master->_read_oob)
slave->mtd._read_oob = part_read_oob;
if (master->_write_oob)
slave->mtd._write_oob = part_write_oob;
if (master->_read_user_prot_reg)
slave->mtd._read_user_prot_reg = part_read_user_prot_reg;
if (master->_read_fact_prot_reg)
slave->mtd._read_fact_prot_reg = part_read_fact_prot_reg;
if (master->_write_user_prot_reg)
slave->mtd._write_user_prot_reg = part_write_user_prot_reg;
if (master->_lock_user_prot_reg)
slave->mtd._lock_user_prot_reg = part_lock_user_prot_reg;
if (master->_get_user_prot_info)
slave->mtd._get_user_prot_info = part_get_user_prot_info;
if (master->_get_fact_prot_info)
slave->mtd._get_fact_prot_info = part_get_fact_prot_info;
if (master->_sync)
slave->mtd._sync = part_sync;
if (!partno && !master->dev.class && master->_suspend &&
master->_resume) {
slave->mtd._suspend = part_suspend;
slave->mtd._resume = part_resume;
}
if (master->_writev)
slave->mtd._writev = part_writev;
if (master->_lock)
slave->mtd._lock = part_lock;
if (master->_unlock)
slave->mtd._unlock = part_unlock;
if (master->_is_locked)
slave->mtd._is_locked = part_is_locked;
if (master->_block_isreserved)
slave->mtd._block_isreserved = part_block_isreserved;
if (master->_block_isbad)
slave->mtd._block_isbad = part_block_isbad;
if (master->_block_markbad)
slave->mtd._block_markbad = part_block_markbad;
slave->mtd._erase = part_erase;
slave->master = master;
slave->offset = part->offset;
if (slave->offset == MTDPART_OFS_APPEND)
slave->offset = cur_offset;
if (slave->offset == MTDPART_OFS_NXTBLK) {
slave->offset = cur_offset;
if (mtd_mod_by_eb(cur_offset, master) != 0) {
/* Round up to next erasesize */
slave->offset = (mtd_div_by_eb(cur_offset, master) + 1) * master->erasesize;
printk(KERN_NOTICE "Moving partition %d: "
"0x%012llx -> 0x%012llx\n", partno,
(unsigned long long)cur_offset, (unsigned long long)slave->offset);
}
}
if (slave->offset == MTDPART_OFS_RETAIN) {
slave->offset = cur_offset;
if (master->size - slave->offset >= slave->mtd.size) {
slave->mtd.size = master->size - slave->offset
- slave->mtd.size;
} else {
printk(KERN_ERR "mtd partition \"%s\" doesn't have enough space: %#llx < %#llx, disabled\n",
part->name, master->size - slave->offset,
slave->mtd.size);
/* register to preserve ordering */
goto out_register;
}
}
if (slave->mtd.size == MTDPART_SIZ_FULL)
slave->mtd.size = master->size - slave->offset;
printk(KERN_NOTICE "0x%012llx-0x%012llx : \"%s\"\n", (unsigned long long)slave->offset,
(unsigned long long)(slave->offset + slave->mtd.size), slave->mtd.name);
/* let's do some sanity checks */
if (slave->offset >= master->size) {
/* let's register it anyway to preserve ordering */
slave->offset = 0;
slave->mtd.size = 0;
printk(KERN_ERR"mtd: partition \"%s\" is out of reach -- disabled\n",
part->name);
goto out_register;
}
if (slave->offset + slave->mtd.size > master->size) {
slave->mtd.size = master->size - slave->offset;
printk(KERN_WARNING"mtd: partition \"%s\" extends beyond the end of device \"%s\" -- size truncated to %#llx\n",
part->name, master->name, (unsigned long long)slave->mtd.size);
}
if (master->numeraseregions > 1) {
/* Deal with variable erase size stuff */
int i, max = master->numeraseregions;
u64 end = slave->offset + slave->mtd.size;
struct mtd_erase_region_info *regions = master->eraseregions;
/* Find the first erase regions which is part of this
* partition. */
for (i = 0; i < max && regions[i].offset <= slave->offset; i++)
;
/* The loop searched for the region _behind_ the first one */
if (i > 0)
i--;
/* Pick biggest erasesize */
for (; i < max && regions[i].offset < end; i++) {
if (slave->mtd.erasesize < regions[i].erasesize) {
slave->mtd.erasesize = regions[i].erasesize;
}
}
BUG_ON(slave->mtd.erasesize == 0);
} else {
/* Single erase size */
slave->mtd.erasesize = master->erasesize;
}
if ((slave->mtd.flags & MTD_WRITEABLE) &&
mtd_mod_by_eb(slave->offset, &slave->mtd)) {
/* Doesn't start on a boundary of major erase size */
/* FIXME: Let it be writable if it is on a boundary of
* _minor_ erase size though */
slave->mtd.flags &= ~MTD_WRITEABLE;
printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an erase block boundary -- force read-only\n",
part->name);
}
if ((slave->mtd.flags & MTD_WRITEABLE) &&
mtd_mod_by_eb(slave->mtd.size, &slave->mtd)) {
slave->mtd.flags &= ~MTD_WRITEABLE;
printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an erase block -- force read-only\n",
part->name);
}
slave->mtd.ecclayout = master->ecclayout;
slave->mtd.ecc_step_size = master->ecc_step_size;
slave->mtd.ecc_strength = master->ecc_strength;
slave->mtd.bitflip_threshold = master->bitflip_threshold;
if (master->_block_isbad) {
uint64_t offs = 0;
while (offs < slave->mtd.size) {
if (mtd_block_isreserved(master, offs + slave->offset))
slave->mtd.ecc_stats.bbtblocks++;
else if (mtd_block_isbad(master, offs + slave->offset))
slave->mtd.ecc_stats.badblocks++;
offs += slave->mtd.erasesize;
}
}
out_register:
return slave;
}
int mtd_add_partition(struct mtd_info *master, const char *name,
long long offset, long long length)
{
struct mtd_partition part;
struct mtd_part *p, *new;
uint64_t start, end;
int ret = 0;
/* the direct offset is expected */
if (offset == MTDPART_OFS_APPEND ||
offset == MTDPART_OFS_NXTBLK)
return -EINVAL;
if (length == MTDPART_SIZ_FULL)
length = master->size - offset;
if (length <= 0)
return -EINVAL;
part.name = name;
part.size = length;
part.offset = offset;
part.mask_flags = 0;
part.ecclayout = NULL;
new = allocate_partition(master, &part, -1, offset);
if (IS_ERR(new))
return PTR_ERR(new);
start = offset;
end = offset + length;
mutex_lock(&mtd_partitions_mutex);
list_for_each_entry(p, &mtd_partitions, list)
if (p->master == master) {
if ((start >= p->offset) &&
(start < (p->offset + p->mtd.size)))
goto err_inv;
if ((end >= p->offset) &&
(end < (p->offset + p->mtd.size)))
goto err_inv;
}
list_add(&new->list, &mtd_partitions);
mutex_unlock(&mtd_partitions_mutex);
add_mtd_device(&new->mtd);
return ret;
err_inv:
mutex_unlock(&mtd_partitions_mutex);
free_partition(new);
return -EINVAL;
}
EXPORT_SYMBOL_GPL(mtd_add_partition);
int mtd_del_partition(struct mtd_info *master, int partno)
{
struct mtd_part *slave, *next;
int ret = -EINVAL;
mutex_lock(&mtd_partitions_mutex);
list_for_each_entry_safe(slave, next, &mtd_partitions, list)
if ((slave->master == master) &&
(slave->mtd.index == partno)) {
ret = del_mtd_device(&slave->mtd);
if (ret < 0)
break;
list_del(&slave->list);
free_partition(slave);
break;
}
mutex_unlock(&mtd_partitions_mutex);
return ret;
}
EXPORT_SYMBOL_GPL(mtd_del_partition);
/*
* This function, given a master MTD object and a partition table, creates
* and registers slave MTD objects which are bound to the master according to
* the partition definitions.
*
* We don't register the master, or expect the caller to have done so,
* for reasons of data integrity.
*/
int add_mtd_partitions(struct mtd_info *master,
const struct mtd_partition *parts,
int nbparts)
{
struct mtd_part *slave;
uint64_t cur_offset = 0;
int i;
printk(KERN_NOTICE "Creating %d MTD partitions on \"%s\":\n", nbparts, master->name);
for (i = 0; i < nbparts; i++) {
slave = allocate_partition(master, parts + i, i, cur_offset);
if (IS_ERR(slave))
return PTR_ERR(slave);
mutex_lock(&mtd_partitions_mutex);
list_add(&slave->list, &mtd_partitions);
mutex_unlock(&mtd_partitions_mutex);
add_mtd_device(&slave->mtd);
cur_offset = slave->offset + slave->mtd.size;
}
return 0;
}
static DEFINE_SPINLOCK(part_parser_lock);
static LIST_HEAD(part_parsers);
static struct mtd_part_parser *get_partition_parser(const char *name)
{
struct mtd_part_parser *p, *ret = NULL;
spin_lock(&part_parser_lock);
list_for_each_entry(p, &part_parsers, list)
if (!strcmp(p->name, name) && try_module_get(p->owner)) {
ret = p;
break;
}
spin_unlock(&part_parser_lock);
return ret;
}
#define put_partition_parser(p) do { module_put((p)->owner); } while (0)
void register_mtd_parser(struct mtd_part_parser *p)
{
spin_lock(&part_parser_lock);
list_add(&p->list, &part_parsers);
spin_unlock(&part_parser_lock);
}
EXPORT_SYMBOL_GPL(register_mtd_parser);
void deregister_mtd_parser(struct mtd_part_parser *p)
{
spin_lock(&part_parser_lock);
list_del(&p->list);
spin_unlock(&part_parser_lock);
}
EXPORT_SYMBOL_GPL(deregister_mtd_parser);
/*
* Do not forget to update 'parse_mtd_partitions()' kerneldoc comment if you
* are changing this array!
*/
static const char * const default_mtd_part_types[] = {
"cmdlinepart",
"ofpart",
NULL
};
/**
* parse_mtd_partitions - parse MTD partitions
* @master: the master partition (describes whole MTD device)
* @types: names of partition parsers to try or %NULL
* @pparts: array of partitions found is returned here
* @data: MTD partition parser-specific data
*
* This function tries to find partition on MTD device @master. It uses MTD
* partition parsers, specified in @types. However, if @types is %NULL, then
* the default list of parsers is used. The default list contains only the
* "cmdlinepart" and "ofpart" parsers ATM.
* Note: If there are more then one parser in @types, the kernel only takes the
* partitions parsed out by the first parser.
*
* This function may return:
* o a negative error code in case of failure
* o zero if no partitions were found
* o a positive number of found partitions, in which case on exit @pparts will
* point to an array containing this number of &struct mtd_info objects.
*/
int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
struct mtd_partition **pparts,
struct mtd_part_parser_data *data)
{
struct mtd_part_parser *parser;
int ret = 0;
if (!types)
types = default_mtd_part_types;
for ( ; ret <= 0 && *types; types++) {
parser = get_partition_parser(*types);
if (!parser && !request_module("%s", *types))
parser = get_partition_parser(*types);
if (!parser)
continue;
ret = (*parser->parse_fn)(master, pparts, data);
put_partition_parser(parser);
if (ret > 0) {
printk(KERN_NOTICE "%d %s partitions found on MTD device %s\n",
ret, parser->name, master->name);
break;
}
}
return ret;
}
int mtd_is_partition(const struct mtd_info *mtd)
{
struct mtd_part *part;
int ispart = 0;
mutex_lock(&mtd_partitions_mutex);
list_for_each_entry(part, &mtd_partitions, list)
if (&part->mtd == mtd) {
ispart = 1;
break;
}
mutex_unlock(&mtd_partitions_mutex);
return ispart;
}
EXPORT_SYMBOL_GPL(mtd_is_partition);
/* Returns the size of the entire flash chip */
uint64_t mtd_get_device_size(const struct mtd_info *mtd)
{
if (!mtd_is_partition(mtd))
return mtd->size;
return PART(mtd)->master->size;
}
EXPORT_SYMBOL_GPL(mtd_get_device_size);